A munkamenet feltörésének és lopás elleni védelmének módjai

A legtöbb internetes oldal nyitott a hackerek külső behatásaira. Még a nagyszabású drága internetes projekteket is feltörik: nyomokat hagynak maguk után, vagy elveszik az adatbázist. Ennek eredményeként az erőforrás tulajdonosa és a látogatók szenvednek.

A hackelési problémák elkerülése érdekében a fejlesztés során számos intézkedésre van szükség. A telephely üzemeltetése során bizonyos megelőző intézkedéseket kell végrehajtani.

A korábbi cikkekben bemutattam, hogyan működnek a szerverek, valamint a szerverek. Ma a munkamenetek hackerek általi lehallgatásáról és védelméről fogunk beszélni.

A webhely munkamenete

A PHP valószínűleg a webhelyek legelterjedtebb szerveroldali programozási nyelve. A php-ben a webhely munkamenete a session_start() paranccsal indul el. Mielőtt elkezdené, megadhatja Extra lehetőségek. A munkamenet általában fontos személyes információkat tárol a felhasználóról: bejelentkezési név, név, jelszó, ..

Munkamenet-eltérítés

A munkamenet-azonosító kétféleképpen tárolható: cookie-kban és bennük címsor. Az első lehetőség biztonságosabb, mint a második, de mindkettő különböző mértékben feltörhető. Ez a típus A feltörést munkamenet-eltérítésnek nevezik.

Az azonosítót tároljuk a webhely URL-jében. Egy bejelentkezett látogató, aki végigjárja webhelyének oldalait, együtt dönt valakivel. A hivatkozás közzétételekor a munkamenet azonosítójával együtt adja meg a hivatkozást. Ha az oldal nem rendelkezik további védelmi módszerekkel, akkor egy ilyen hivatkozásra kattintva egy új látogató már első felhasználóként bejelentkezik, ha a munkamenet még nem fejeződött be. Ezután a szabályok által megengedett keretek között csináljon az oldalon, amit akar.

A sütikkel bonyolultabb a dolog, de minden könnyen elkapható. Sok webhely nem szűri a böngésző szkriptjeit, amikor a felhasználók információkat tesznek közzé. Egy potenciális hacker elhelyez egy ilyen szkriptet egy oldalon. A bejelentkezett látogató meglátogat egy oldalt... A szkript beolvassa a cookie értékét vagy a címsort, és átadja a munkamenet-azonosítót egy másik webhelynek. A másik oldal a hackeré. Ráadásul minden egyszerű. Hamisítanak egy cookie-t, vagy beírják a kívánt munkamenet-azonosítóval rendelkező webhely oldalának címét.

Munkamenet Hackelés

Amikor egy munkamenet elindul, a munkamenet fájlok létrejönnek az ideiglenes könyvtárban. Ezek a fájlok információkat tárolnak. Ha használja, akkor általában a munkamenetek tárolására szolgáló ideiglenes mappát a kiszolgáló összes webhelye megosztja. Ezenkívül bizonyos módon a munkamenet adatait a saját szkriptje olvassa be. Ehhez a támadónak fiókkal kell rendelkeznie ugyanazon a szerveren. Ennek eredményeként, ha a munkamenetben egy webhelyről származó jelszót vagy egy hitelkártyaszámot tárolnak cvv kóddal, akkor mindez hasznos információ támadó kezébe kerül.

Munkamenet-adat-feltörés elleni védelem

  • Tárolja a munkamenetet cookie-kban. Nehezebb elvinni.
  • Kösd össze a munkamenetet a számítógép IP-címével. Másik IP-ről történő belépéskor a szkript beállításoktól függően új munkamenet jön létre.
  • Kösd össze a munkamenetet a böngésző felhasználói ügynökével. Ha másik böngészőből jelentkezik be, a munkamenet nullázódik.
  • A munkamenetnek átadott paraméterek titkosítása. Ha egy támadó megkapja a munkamenetfájlt, nem tudja elolvasni. Habár bizonyos készségekkel rendelkezik, a munkamenet visszafejtése is lehetséges.
  • Tárolja a munkamenet-azonosítókat egy külön mappában. A php-ben erre van egy session_save_path($elérési_könyvtár) parancs. Ugyanez a beállítás írható be a php.ini fájlba. A paraméter neve session.save_path.
  • Használja a session_set_save_handler() parancsot a php-ben a munkamenet tárolásának felülbírálásához. A PHP 5.4 óta pedig átadhat egy SessionHandlerInterface típusú objektumot a session_set_save_handler()-nek.

Sok felhasználó nem is veszi észre, hogy a bejelentkezési név és a jelszó megadásával egy zárt internetes erőforráson történő regisztrációkor vagy engedélyezéskor és az ENTER lenyomásával ezek az adatok könnyen lehallgathatók. Nagyon gyakran nem biztonságos formában továbbítják a hálózaton. Ezért, ha a webhely, amelyen megpróbál bejelentkezni, a HTTP protokollt használja, akkor nagyon könnyű rögzíteni ezt a forgalmat, elemezni a Wireshark segítségével, majd speciális szűrők és programok segítségével megtalálni és visszafejteni a jelszót.

A jelszavak lehallgatásának legjobb helye a hálózat magja, ahol az összes felhasználó forgalma zárt erőforrásokra (például levelezésre) vagy a router elé kerül, hogy hozzáférjen az internethez, amikor külső erőforrásokon regisztrál. Felállítunk egy tükröt, és készen állunk, hogy hackernek érezzük magunkat.

1. lépés Telepítse és futtassa a Wiresharkot a forgalom rögzítéséhez

Néha ehhez elég, ha csak azt a felületet választjuk ki, amelyen keresztül a forgalmat tervezzük rögzíteni, és kattintson a Start gombra. Esetünkben vezeték nélkül rögzítünk.

Megkezdődött a forgalom rögzítése.

2. lépés: A rögzített POST-forgalom szűrése

Megnyitjuk a böngészőt, és megpróbálunk bejelentkezni bármely erőforrásba felhasználónévvel és jelszóval. Az engedélyezési folyamat befejezése és az oldal megnyitása után leállítjuk a Wireshark forgalmának rögzítését. Ezután nyissa meg a protokollelemzőt, és tekintse meg a nagyszámú csomagot. Ez az a szakasz, amikor a legtöbb informatikus feladja, mert nem tudja, mit tegyen. De ismerjük és érdekelnek minket azok a POST adatokat tartalmazó csomagok, amelyek a helyi gépünkön generálódnak, amikor kitöltünk egy űrlapot a képernyőn és elküldjük távoli szerver amikor rákattint a "Bejelentkezés" vagy az "Engedélyezés" gombra a böngészőben.

Adjon meg egy speciális szűrőt az ablakban a rögzített csomagok megjelenítéséhez: http.kérés.módszer == "PONT”

És ezer csomag helyett csak egyet látunk a keresett adatokkal.

3. lépés Keresse meg a felhasználónevet és a jelszót

Gyors kattintás jobb gomb egérrel, és válassza ki a menüből Kövesd a TCPSteamet


Ezt követően egy új ablakban megjelenik egy szöveg, amely a kódban visszaállítja az oldal tartalmát. Keressük meg a jelszónak és felhasználónévnek megfelelő "password" és "user" mezőket. Egyes esetekben mindkét mező könnyen olvasható és nem is titkosított lesz, de ha a forgalmat próbáljuk rögzíteni, amikor olyan jól ismert forrásokhoz férünk hozzá, mint például: Mail.ru, Facebook, Vkontakte stb., akkor a jelszó a következő lesz: kódolva:

HTTP/1.1 302 Talált

Szerver: Apache/2.2.15 (CentOS)

X-Powered-By: PHP/5.3.3

P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"

Set-Cookie:password= ; lejár=Cs, 2024. november 07., 23:52:21 GMT; útvonal =/

Helyszín: loggedin.php

Tartalom hossza: 0

Csatlakozás: zárható

Tartalom típusa: szöveg/html; charset=UTF-8

Tehát a mi esetünkben:

Felhasználónév: networkguru

Jelszó:

4. lépés Határozza meg a kódolás típusát a jelszó visszafejtéséhez

Felmegyünk például a http://www.onlinehashcrack.com/hash-identification.php#res webhelyre, és beírjuk jelszavunkat az azonosítási ablakba. Kaptam egy listát a kódolási protokollokról prioritási sorrendben:

5. lépés: A felhasználói jelszó visszafejtése

Ebben a szakaszban használhatjuk a hashcat segédprogramot:

~# hashcat -m 0 -a 0 /root/wireshark-hash.lf /root/rockyou.txt

A kimeneten egy dekódolt jelszót kaptunk: simplepassword

Így a Wireshark segítségével nem csak az alkalmazások és szolgáltatások működésével kapcsolatos problémákat oldhatjuk meg, hanem hackerként is kipróbálhatjuk magunkat a felhasználók által a webes űrlapokon beírt jelszavak elfogásával. A jelszavakat is megtudhatja postafiókok A felhasználók egyszerű szűrőket használnak a megjelenítéshez:

  • A POP protokoll és a szűrő így néz ki: pop.request.command == "USER" || pop.request.command == "PASS"
  • Az IMAP protokoll és szűrő a következő lesz: Az imap.request tartalmazza a "login" kifejezést
  • SMTP protokollt, és meg kell adnia a következő szűrőt: smtp.req.command == "AUTH"

és komolyabb segédprogramok a kódolási protokoll visszafejtésére.

6. lépés: Mi van, ha a forgalom titkosított és HTTPS-t használ?

A kérdés megválaszolására több lehetőség is kínálkozik.

1. lehetőség: Csatlakozzon a felhasználó és a szerver közötti kapcsolat megszakítójához, és rögzítse a forgalmat a kapcsolat létrehozásának pillanatában (SSL kézfogás). A kapcsolat létrehozásakor a munkamenet kulcsa elfogható.

2. lehetőség: A HTTPS-forgalmat a Firefox vagy a Chrome által írt munkamenetkulcs-naplófájl segítségével dekódolhatja. Ehhez a böngészőt úgy kell beállítani, hogy ezeket a titkosítási kulcsokat egy naplófájlba írja (FireFox alapú példa), és meg kell kapnia ezt a naplófájlt. Lényegében el kell lopnia a munkamenet kulcsfájlját merevlemez egy másik felhasználó (ami illegális). Nos, akkor rögzítse a forgalmat, és használja a kapott kulcsot a visszafejtéshez.

Pontosítás. Egy olyan személy webböngészőjéről beszélünk, akinek a jelszavát ellopják. Ha a saját HTTPS-forgalmunk visszafejtésére gondolunk, és gyakorolni szeretnénk, akkor ez a stratégia működni fog. Ha más felhasználók HTTPS-forgalmát próbálja megfejteni anélkül, hogy hozzáférne a számítógépükhöz, ez nem fog működni – erre való a titkosítás és az adatvédelem.

Miután megkapta a kulcsokat az 1. vagy 2. lehetőség szerint, regisztrálnia kell azokat a WireSharkban:

  1. Lépjen a Szerkesztés - Beállítások - Protokollok - SSL menübe.
  2. Állítsa be a „Több TCP-szegmensre kiterjedő SSL-rekordok összeállítása” jelzőt.
  3. „RSA kulcsok listája”, majd kattintson a Szerkesztés gombra.
  4. Írja be az adatokat minden mezőbe, és írja be az elérési utat a fájlba a kulccsal

NÁL NÉL utóbbi évek változás tapasztalható a speciális szolgálatok által az Internet TLS/SSL legfontosabb biztonsági protokollja elleni támadási stratégiában. Ezentúl a közvetlen kriptográfiai támadás és hackelés már nemcsak szélsőséges, hanem gyakran szükségtelen is a keretek között. modern világ olyan intézkedés, ahol a pénz és a pénzügyi haszon válik a fő hajtóerővé.

A probléma fontossága miatt egy kiadványsorozat részeként a webhely áttekintést nyújt a TLS / SSL protokollverem biztonságáról, miközben konzisztens és szisztematikus stratégiákat mérlegel e protokollok titkosszolgálatok általi gyengítésére.

A világ biztonságos forgalmának egyharmada generálódik kriptográfiai eszközök szándékosan gyengített PRNG-vel?

Eltávolítva a csatornáról

Magunkként térjünk rá az orosz példára – az ügy utolsó bírósági tárgyalására volt tulajdonosa fizetési rendszer Chronopay Pavel Vrublevsky, akit az Aeroflot elleni DDoS-támadással vádolnak.

A kulcsfontosságú cselekmény lényege abban rejlett, hogy a bíróság belső levelezést kért a büntetőeljárás résztvevői között, amelyet a bíróságon keresztül folytattak le. személyes számlák Facebookon. Annak ellenére, hogy benne volt a legfontosabb terhelő információ, az alattomos amerikai közösségi háló nem vette figyelembe az orosz igazságszolgáltatás kérését, és megtagadta az Orosz Föderáció állampolgárainak magánlevelezéseihez való hozzáférést. És akkor bekövetkezik a nagyon drámai fordulópont ebben a történetben - az FSB a bírósági határozat végrehajtása során önállóan „kivonja” ezen állampolgárok levelezését.

Az FSZB Központi Tájékoztatási Irodája az operatív-nyomozói tevékenységről szóló törvénynek megfelelően független információgyűjtést végzett ezen személyek kommunikációs csatornáiról, és azokat DVD-re rögzítette.

Később ugyanis a védelmi oldal ellenőrizni tudta, hogy a Facebook akarata ellenére a szükséges személyes levelezést „teljes mértékben és mértékben eltávolították a hálózatból”. Ugyanakkor maguk ebben az ügyben a vádlottak tagadták, hogy jelszavaikkal és önbíráskodó levelezésükkel átadták volna a nyomozást. A RuNeten találkozhatunk olyan kirívó hírcímekkel, mint „Az orosz FSB feltörte a Facebook-szervereket”, de nem szabad odáig ugrani a következtetésekkel.

Először is, a Facebookkal folytatott összes kommunikációs munkamenet kizárólag a biztonságos HTTPS kommunikációs protokollon keresztül zajlik. Másodsorban az alperesek utolsó kapcsolatfelvételei óta, ill ezt a döntést bíróság előtt (és ebből következően az FSZB nyomozati intézkedései e határozat végrehajtása érdekében) sok idő telt el. Milyen „csatornáról” lehetne „eltávolítani” ezeket a „múltbeli adatokat”, ha maguk a vádlottak azóta sem léptek fel az internetre, nyomozás alatt állnak?

Figyelmen kívül hagyták ezeket a közvetlen kérdéseket, amelyeket az FSZB képviselőinek tettek fel a tárgyalás során. A válasz legkézenfekvőbb változata önmagát sugallta: az ezzel a levelezéssel járó HTTPS-forgalmat az FSB előre megszagolta / eltárolta, majd valahogy később feltörte.

Érdekesség, hogy szinte hasonló esetet rögzítettek korábban ugyanannak az ügynek az anyagaiban. Az FSZB CIB a nyomozás jegyzőkönyvére hivatkozva „az egyik vádlott internetkapcsolati forgalmának elmentésével és elemzésével a botnet vezérlőpultjáról (fizikailag egy egyesült államokbeli szerveren található) visszaszerezte a bejelentkezési nevet és a jelszót”, miután amelynek távirányítóját lefoglalta ezen a botnet felett. Tehát ugyanahhoz a webpanelhez a vádlottak ismét kizárólag titkosított HTTPS-kapcsolaton keresztül fértek hozzá a biztonsági intézkedéseknek megfelelően (például a jelszavak helyi számítógépére való mentése nélkül).

Így kijelentjük a HTTPS biztonságával kapcsolatos problémák fennállását, hivatkozva elképesztő esetekre, amikor az orosz speciális szolgálatok túllépték a TLS/SSL "védelmét".

működési módja

Egy titkosított HTTPS-munkamenet feltöréséhez két fő feladatot kell megoldani: a forgalmat figyelni (elfogni), illetve az ilyen biztonságos csomagba foglalt adatokat visszafejteni.

Nem foglalkozunk az első ponttal, mivel a speciális szolgáltatások szinte minden csatornához fizikai hozzáféréssel rendelkeznek. Azok, akik követik a SORMomostroeniya legfrissebb híreit, már tisztában vannak azzal, hogy az új törvény értelmében 2014. július 1-jétől minden orosz szolgáltatónak speciális berendezést kell telepítenie a hálózatára a tranzit internetforgalom teljes rögzítésére és tárolására. időtartama legalább 12 óra. Ezenkívül a biztonsági erők közvetlen hozzáférést kapnak az összes tárolt és tranzit adattömbhöz.

Ha a HTTPS-munkamenetek meghallgatásáról beszélünk, akkor azonnal megjegyezzük fontos pont- bizonyos esetekben szükség van az "aktív módú" hallgatásra, mert az elmentett forgalmat később nem mindig lehet feltörni. A HTTPS protokollhoz tartozó úgynevezett progresszív titkosítási módról (forward secrecy, FS) beszélünk, amely megakadályozza az adatok helyreállításának lehetőségét a kommunikációs munkamenet befejezése után (még akkor is, ha a támadó később érvényes helykulcsokat szerezhet meg). Egy ilyen mód jelenléte arra kötelezi a támadót, hogy "forró vasat kovácsoljon" - vagyis valós időben törje fel az adatokat, ami az esetek túlnyomó többségében technikailag aligha lehetséges.

A rossz hír az, hogy a Facebook a legtöbb nagy internetes portálhoz hasonlóan nem alkalmaz továbbító titkosítási módot, mert ez további komoly terhet ró az amúgy is túlterhelt közösségi gépezetre. Ezenkívül az ilyen fejlett DH-algoritmusok használata hátrányosan befolyásolhatja a kompatibilitást néhány népszerű böngészővel. Most már könnyen belátható, hogy a Netcraft 2013 nyári statisztikái szerint a megfigyelés során megfigyelt SSL-kapcsolatok körülbelül 70-99%-a egyáltalán nem használt FS-t.

Ez azt jelenti, hogy az esetek túlnyomó többségében a támadó biztonságosan tárolhatja a HTTPS-forgalmat későbbi kiválogatás és feltörés céljából (például amikor a privát szerverkulcs ismertté válik).

Fent egy teljesítménycsökkenés mérése látható egy 6 magos webszerver-processzoron, DHE-vel, illetve letiltva. A DHE-t a Perfect Forward Secrecy legnépszerűbb és példaértékű megvalósításának választották. Például a Google, amelynek szolgáltatásai szinte minden kripto-innovációt és felhasználói védelmét szolgáló eszközt támogatnak (ez feltűnő kivétel az általános internetes gyakorlattól), rövid életű ("tüntető") PFS-munkamenetkulcsokat valósít meg az ECDHE_RSA alapján. És nagyon-nagyon drága, hidd el!

Ennek a megjegyzésnek a ismeretében azt feltételezzük, hogy a forgalom elfogásával többé-kevésbé minden világos. Most pedig nézzük meg, mi a teendő a mentett titkosított adatfolyammal.

Úgy tűnik, hogy az általános algoritmus ebben az esetben valahogy így fog kinézni: az érdeklődésre számot tartó forgalom lehallgatásakor a HTTPS-munkamenetet elfogják hipotetikus speciális szolgáltatások Tájékoztatási rendszer keresési kérést kap az adatbázisához tartozó megfelelő kiszolgálókulcsra. Ha ilyen kulcs nem található, akkor sorba kerül további számításhoz (feltöréshez). Figyelembe véve az FS opció tényleges elérhetetlenségére vonatkozó megjegyzést, mindig érdemes csendben felhalmozni (írni) az érdeklődésre számot tartó forgalmat anélkül, hogy megvárná a rendszer válaszát a kulcs valós idejű visszafejtési készenlétéről / elérhetőségéről.

Az említett adatbázis tekintetében től szerver kulcsok, majd 2013 nyarán a Cnet információkat és egy példadokumentumot tett közzé egy NSA-kérelemről egy névtelen maradni kívánó nagy internetes cégnek. E forrás szerint ismertté vált, hogy más nagyobb internetes oldalak (Google, Microsoft, Apple, Yahoo, AOL, Verizon, AT&T stb.) is megkapták ugyanezeket a kéréseket. A Cnet hivatalosan is felvette a kapcsolatot ezekkel a szervezetekkel, hogy véleményt nyilvánítsanak. hasonló kérés, de az esetek túlnyomó többségében a vállalatok nem voltak hajlandók sem megerősíteni, sem cáfolni az NSA-val való ilyen interakciókat.

„Ismét megtörlöm a lábam a mítoszt, miszerint a nyílt forráskód a megbízhatósághoz vezető út. Ez a hiba a Debian OpenSSL-ben csaknem két éves volt."

Ezt a sebezhetőséget valóban csak a sajtó felzúdulása után lehetett lezárni. Maga a Debian projekt "meglehetősen furcsa történetnek" nevezte azt a helyzetet, amelyben az OpenSSL adattárában régóta fennálló hiba jelentkezett.

Ha már a hírhedt hardveres "könyvjelzőkről" beszélünk, akkor az utóbbi időben már a legváratlanabb helyeken is heves színben pompáznak: vasalóktól a kávéfőzőkig. Tehát a Spiegel, az NSA „Speciális hozzáférési műveletek” (Talored Access Operations, TAO) speciális részlege szerint. hosszú ideje tömeges lehallgatást hajtott végre a megvásárolt legtöbben különböző cégek valamint a számítógépes (és nem csak) berendezések országai a szállítótól a címzettig. Ugyanakkor az elfogott berendezés, amelyet az NSA érdeklődésére számot tartó ügyfélhez szállítottak, gyorsan átjutott a titkos TAO „gyáron”, ahol módosított szoftvereket vagy „hibákat” vezettek be. Az ellátási láncban a saját céljaira történő ilyen beavatkozást, amelyet az „eltiltás” speciális kifejezéssel jelölnek, maga az NSA a „modern műveletek leghatékonyabb típusaként” értékelte.

Ha engedélyezve van Minden forgalom (titkosított és titkosítatlan) vagy Csak titkosítva az ügynök SSL-tanúsítvány-hamisítási technológiát használ a biztonságos webes munkamenetekben továbbított adatok lehallgatására. Amikor biztonságos kapcsolatot létesít egy kiszolgálóval, az ügynök lecseréli az eredeti kiszolgálótanúsítványt egy azonos nevű, de az ügynök gyökértanúsítványa által kiadott tanúsítvánnyal. A rendszer lehetővé teszi mind az előre telepített tanúsítványok, mind a manuálisan létrehozott tanúsítványok használatát aláírási jogosultsággal rootként.

A rendszer lehetővé teszi bizonyos tanúsítványok manuális telepítését helyettesítésre a megfelelő szerverek (webhelyek, programok) munkameneteinek lehallgatásakor, a tanúsítványnak a szerverhez való kapcsolásával.

Egyes esetekben a nem eredeti tanúsítvány használata lehetetlenné teheti a titkosított kapcsolat létrehozását a szerverrel. Ebben az esetben ki kell zárni a megfelelő szervereket az elfogásból, pl. tiltja az SSL-tanúsítványok helyettesítését az ilyen szerverekhez való csatlakozáskor. Ez visszaállítja az ilyen webhelyek vagy programok működőképességét, de nem fogják el a titkosított forgalmat.

Az SSL-forgalom elfogásának konfigurálása:

  1. A lap ablakban Ügynök beállítási profila profilszerkesztő területen válasszon lapot Hálózati forgalomszabályozás.
  2. Kattintson a gombra SSL-elfogási lehetőségekés kövesse az aktuális bekezdés ajánlásait.

Az SSL-tanúsítvány-hamisítási mód kiválasztása

A beállítások ablakban válasszon egy elfogadható lehallgatási módot:

  • Automatikus generáláshozügynök SSL gyökértanúsítvány a telepítés során a felhasználó számítógépére, válassza ki a lehetőséget Automatikus mód . A generált gyökértanúsítvány a megbízható tanúsítványkibocsátók adatbázisába kerül, és az ügynök automatikusan felhasználja az alapértelmezés szerint Falcongaze SecureTower kibocsátónévvel aláírt utódtanúsítványok kiadására.

A tanúsítvány kibocsátójának nevének megváltoztatásához, amely a kapcsolat biztonsági információi között lesz feltüntetve, adja meg a kívánt nevet a mezőben Név be SSL tanúsítvány .

  • Ha egyéni SSL-tanúsítványt szeretne gyökértanúsítványként használni a titkosított forgalom elfogása során, Válassz egy lehetőséget Felhasználói mód. A felhasználói tanúsítványt előre kell generálni, és hozzá kell adni a rendszer adatbázisához. Tanúsítvány megadásához a rendszeradatbázisból, válassza ki a nevét a legördülő listábólFelhasználói tanúsítványvagy kattintson a gombraFelhasználói tanúsítványok ehheztanúsítvány és privát kulcs fájlok hozzáadása a rendszer adatbázisához.

A megnyíló ablakban kattintson a gombra Tanúsítvány hozzáadásaés adja meg a tanúsítványt és a kulcsfájlokat a következő módok egyikén:

  1. Új tanúsítvány létrehozásához kattintson a gombra Tanúsítvány létrehozása. A megnyíló ablakban adja meg az új tanúsítvány nevét, érvényességi idejét, és adja meg az újonnan létrehozott tanúsítvány (*.cer) és privát kulcs (*.pvk) fájlok tárolási útvonalait. Kattintson a Generálás gombra.

  1. Ha olyan tanúsítványt szeretne hozzáadni, amelyet korábban PFX formátumban hoztak létre, kattintson a gombra Konvertálás tanúsítványból PFX formátumban. Adja meg a PFX formátumú tanúsítványfájl elérési útját és jelszavát, valamint a konvertálni kívánt tanúsítvány (*.cer) és privát kulcs (*.pvk) fájl elérési útját eredeti fájl. Kattintson a Konvertálás gombra az átalakítás befejezéséhez.

Kattintson a Tovább gombra az ablakban Felhasználói tanúsítványok hozzáadásaaz eljárás folytatásához kiegészítéseket . A megnyíló ablakban írjon be egy egyedi nevet, amellyel a hozzáadott tanúsítványt aláírja, és egy megjegyzést (nem kötelező).

Kattintson a Kész gombra a folyamat befejezéséhez. A tanúsítvány bekerül a SecureTower rendszer felhasználói tanúsítvány adatbázisába. Kattintson rendben a kiegészítés befejezéséhez.Egyéni hozzáadva a tanúsítványt az ügynök automatikusan elhelyezi a megbízható készítők adatbázisába (ha ezt korábban a hálózati rendszergazda nem tette meg), majd az utódtanúsítványok kiadására fogja használni.

Jegyzet.

Felhasználói mód használatakor azt javasoljuk, hogy a hálózati adminisztrátor a felhasználói tanúsítványt a hálózaton lévő összes számítógéphez továbbítsa csoportszabályzat vagy manuálisan. Ez biztosítja a sikeres tanúsítványhitelesítést. Ellenkező esetben a tanúsítványt az ügynök automatikusan hozzáadja a megbízható tanúsítványtárolóhoz.

SSL-tanúsítvány kötése egy szerverhez

A "szerver-tanúsítvány" egyezés meghatározásához kattintson a gombra Tanúsítvány kötésekés kövesse az alábbi irányelveket:

  • Egy adott gyökértanúsítvány-kiszolgálóhoz való kapcsolódás a lapon Gyökértanúsítványok, nyomja meg a gombot Helytanúsítvány hozzáadása. Írja be a gazdagép nevét ( Domain név), amelyhez a gyermektanúsítványokat adják ki, és amelyhez a gyökértanúsítványt a Gazdanév (IP-cím) mezőben kötik. Válassza ki az egyik előre telepített gyökértanúsítványt a mező legördülő listából Gyökértanúsítvány vagy kattintson a gombra Felhasználói tanúsítványok a tanúsítvány és a privát kulcs fájlok hozzáadásához és megadásához a felhasználó számítógépén.
  • Ha egy már létező tanúsítványt egy adott szerverhez szeretne rendelni, válassza a lapot Felhasználói tanúsítványok. Az ügynök nem generál új gyermektanúsítványokat az ezen a lapon megadott kiszolgálókhoz, hanem a felhasználó által megadott tanúsítványokat használja a helyettesítési eljárásokhoz. A megnyíló ablakban a Gazdanév (IP-cím) mezőbe írja be azt a gazdagépnevet (tartománynevet), amelyhez a tanúsítvány hozzá lesz kötve. Válasszon ki egy tanúsítványt a Tanúsítvány : mező legördülő listájából (ha már korábban hozzáadott tanúsítványokat), vagy kattintson a gombra Felhasználói tanúsítványok felhasználói tanúsítványok listából történő kiválasztásához, vagy tanúsítvány- és privát kulcsfájlok hozzáadásához és megadásához a felhasználó számítógépén.

Jegyzet.

A mező kitöltéséhez Gazdanév (IP-cím) a gazdagép IP-címének használata megengedett, de csak olyan esetekben, amikor a csatlakozás során nem határozták meg a gazdagép nevét, és csak az IP-cím ismert.

A szerverek kizárása a titkosított forgalom elfogásából

A tanúsítványhamisítási folyamat alóli kivételek kezeléséhez kattintson a gombraSSL szerver kivételek.

A kizáráskezelő ablak megjeleníti azon kiszolgálók (gazdagépek) listáját, amelyek alapértelmezés szerint kizártak a cserefolyamatból. Új kizárás hozzáadásához kattintson a gombra Kivétel hozzáadása.

A megnyíló párbeszédpanel beviteli mezőjébe írja be a szerver (gazdagép) nevét (például accounts.google.com), a kis- és nagybetűket megkülönböztetve, majd kattintson a Hozzáadás gombra. A rendszer lehetővé teszi a nevek maszkkal történő bevezetését (engedélyezettek-e a ? és * karakterek, például a *.microsoft.* használatával elkerülhető a Microsoft-erőforrások megkettőződése a kizárási listán) az azonos család erőforrásainak kizárására. A beírt név megjelenik a kizárási listában.

Ezután ki kell választania a kizárási módot: Hamis tanúsítványok csak a fent felsorolt ​​SSL-kiszolgálókhoz, vagy Helyettesítse az SSL-t - tanúsítványok minden kiszolgálóhoz, kivéve a fent említetteket. Az első esetben a rendszer csak a kizárási listán szereplő kiszolgálók tanúsítványait hamisítja meg (és ezért képes lesz elkapni a megfelelő forgalmat). Az összes többi esetében a tanúsítványokat nem hamisítják, és a megfelelő titkosított forgalom lehallgatása lehetetlen lesz. A második esetben a rendszer lecseréli a tanúsítványokat az összes szerverre, kivéve a kivételek listájában meghatározottakat.

A kivételektől eltekintve egyéb műveletek végrehajtásához kövesse a bekezdés vonatkozó ajánlásait

Megmutatom és elmondom, hogyan használhatod az sslstrip segédprogramot a biztonságos SSL-kapcsolaton keresztül továbbított adatok elfogására.
A példámban szereplő sslstrip segédprogram (miután ARP-hamisítást hajtott végre az áldozaton) elfogja az áldozat webes kliensének kérését, hogy hozzon létre biztonságos SSL-kapcsolatot, és a nem biztonságos HTTP protokoll használatára kényszeríti. Ezután csak megnézem, mit csinál az áldozat, nem figyelve arra, hogy nem HTTPS-en, hanem HTTP-n keresztül olvassa a leveleket.

Látni fogja, milyen egyszerű a támadások megszervezése típus MITM SSL-en az arp-spoof technikával és az sslstrip programmal.

Példámban az áldozat egy 10.10.11.163-as IP-című virtuális gép (egy közönséges autó Windows rendszerrel), a számítógép, amelyről támadok, 10.10.11.85, telepítve van a Kali OS és sslstrip (ez a segédprogram előre telepítve van a pentester Kali\BackTrack Linux disztribúciók). Közöttünk van egy átjáró IP 10.10.11.1.

1. Amikor az áldozat belép a gmail.com oldalra, a rendszer a https://gmail.com címre küldi, és ez normális. Természetesen nem látjuk tisztán a jelszavakat és a bejelentkezési adatokat az áldozat leveleihez.

2. Engedélyezem a forgalomirányítást PC-n a Kali segítségével:

echo "1" > /proc/sys/net/ipv4/ip_forward

és állítsa be az iptables-t úgy, hogy az összes http forgalom a 81-es portra irányuljon:

iptables -t nat -A ELŐUTATÁS -p tcp --cél-port 80 -j REDIRECT --a 81-es portra

arpspoof -i eth0 -t 10.10.11.163 10.10.11.1

most az áldozat forgalma az én autómon megy keresztül és (az iptables szabályom szerint) a 81-es portra van továbbítva.

3. Futtassa az sslstrip parancsot

sslstrip -a -l 81 -w /root/Desktop/ssllog.txt

ez létrehoz egy naplófájlt közvetlenül az asztalon, és elkezdi beleírni az elfogott http-forgalmat (valójában a HTTPS-t elfogja, de le lesz vonva). Nos, általában elkezdem nézni ezt a fájlt a konzolon:

tail -f /root/Desktop/ssllog.txt

4. Az áldozat a postájához megy

A levelek olvasásához az áldozat, mint mindig, bemászik az MS Explorerbe (hehe), és ott belép a gmail.com címre. De a böngésző valamiért nem irányítja át az áldozatot a https-re (a http címsorba)! Az alábbi ábra azt mutatja, hogy mit fog látni az áldozat az utolsó pillanatban, mielőtt megtudom a jelszavát és a bejelentkezését.

Az áldozat rákattint a "Bejelentkezés" gombra... és az ablakomon, ahol az elfogott forgalom megjelent, a következőket látom:

Amint látja, a jelszó 1q2w3e4r5t6y...

Az SSL-kapcsolat elejének elfogásával kapcsolatos fenyegetések elkerülése érdekében:
- ne használj kütyüt nem megbízható hálózatokban, még akkor sem, ha nagyon szükséges (egy gazember sokkal nagyobb valószínűséggel tud MITM-et elintézni, mondjuk egy reptéren egy szélhámos vezeték nélküli hozzáférési pont telepítésével, mint feltörésével vállalati hálózat az Ön szervezete);
- levelek titkosítása szimmetrikus titkosítási protokollokkal (PGP-n írok és gondolok);
- fizessen normális fizetést az adminisztrátornak, hogy ne legyen kedve ily módon kémkedni az alkalmazottai után;
- kövesse nyomon az ARP táblát, és használjon hardvert / szoftvert, amely figyeli a podbny támadásokat;
- rendszeresen frissítse a szoftvert megbízható legális forrásból.

Ne feledje, hogy ez a cikk azt szemlélteti, hogy mit tilt a törvény, és a benne található példák bemutatják, mennyire könnyű megtámadni az SSL-t kizárólag oktatási célból.