TCP-eltérítés

TCP-eltérítés  – A Man -in-the-Middle támadás olyan változata, ahol a támadó képes kémkedni a hálózati tagok csomagjai után, és saját csomagjaikat elküldeni a hálózatra. A támadás a TCP -protokoll kapcsolatlétesítési funkcióit használja , és végrehajtható egy „hármas kézfogás” és egy létrejött kapcsolat során is.

Az esetleges TCP üzenethamisítás problémája azért fontos, mert a TCP protokoll alapján megvalósított FTP és TELNET protokollok elemzése azt mutatta, hogy az FTP és TELNET csomagok azonosításának problémáját ezek a protokollok teljes egészében a szállítási szinthez rendelik, azaz , TCP-re.

TCP kapcsolat létrehozása

A TCP-csomagok azonosításához a TCP-fejlécben két 32 bites azonosító található, amelyek egyben a csomagszámláló szerepét is betöltik – Sorozatszám és Nyugtázási Szám. Abban az esetben, ha A host szeretne TCP kapcsolatot létesíteni a B gazdagéppel, az ún. "hármas kézfogás", amely során a házigazdák a következő csomagokat cserélik:

Ez a csomag befejezi a kapcsolat beállítását, így a következő csomagban A gazdagép hasznos információkat küld B állomásnak

A támadás elve

Figyelembe véve a fent leírt kapcsolatbeállítási sémát, láthatja, hogy az egyetlen azonosító, amellyel a végállomás megkülönböztetheti a TCP-előfizetőket és a TCP-kapcsolatokat, a Sorozatszám és a Nyugtázási szám mező. Így, ha egy támadó meghatározza az ISSa és ISSb értékeket egy adott kapcsolathoz, akkor létrehozhat egy hamis TCP-csomagot, amelyet a végső gazdagép elfogad és feldolgoz.

A támadások egyik típusa azt jelenti, hogy a támadó beágyazza az RST (Reset) vezérlőbitet a TCP-csomagba. Az RFC 793 szerint ez a jelző utasítja a célállomást, hogy minden további kommunikáció nélkül szakítsa meg a kapcsolatot. A Sorozatszám mező alapján a célállomás határozza meg, hogy feldolgozza-e vagy figyelmen kívül hagyja-e a reset parancsot, és a célállomásnak tilos választ küldeni beállított RST bittel. Fontos megjegyezni, hogy a célállomás csak a Sorozatszám alapján hitelesíti az RST-kérést, és lezárja a kapcsolatot, ha az az aktuális TCP-ablakba esik. És bár a célállomás ki tudja számítani a nyugtázási számot, nem szükséges, és a legtöbb TCP-verem egyszerűen figyelmen kívül hagyja ezt a lépést.

A fogadott RST csomag mindig megszakítja a kapcsolatot. A hosszú távú kapcsolatok, például az útválasztók közötti BGP - kapcsolatok rendkívül érzékenyek az ilyen támadásokra. Először is, a támadónak elegendő ideje lesz egy gondosan megtervezett csomag megvalósítására, másrészt a DoS óriási veszteségeket fog okozni . Az útválasztóknak újra kell konfigurálniuk a szomszéd táblát, ami a való életben több percig is eltarthat.

Kevésbé nyilvánvaló, hogy a SYN jelző is összeomolhatja a kapcsolatot. Az RFC 793 szerint , amikor a SYN jelző be van állítva a kapcsolat létrehozásakor, a Sorozatszám mező egy kezdeti értéket tartalmaz, amelyet később használunk. Ha ezt követően SYN-csomag érkezik ezen a kapcsolaton, az RFC 793 ezt hibaként kezeli. Ennek eredményeként a címzettnek meg kell szakítania a kapcsolatot egy RST-csomag elküldésével. Az RST-csomagoktól eltérően a gazdagép a SYN-csomagokra RST-csomag küldésével válaszol. Ez egy újabb DoS támadás lehetőségét nyitja meg. A támadó ezt követően használhatja az áldozat sávszélességét. Ez a támadás különösen sikeres az ADSL - vonalakon.

Míg az RST és SYN támadások nem használják fel az IP-datagramok hasznos terhét , egy harmadik technika beilleszti az adatokat egy meglévő kapcsolatba. A támadó bármilyen adatot beilleszthet, amely a kapcsolat megszakítását okozza, vagy gondosan kialakíthat olyan adatokat, amelyek hibaállapothoz vezetnek, vagy végrehajthat valamilyen funkciót a támadó javára. Lehet, hogy az áldozat észre sem veszi ezeket a manipulációkat. Például az FTP és a TelNET protokollok nem ellenőrzik a küldő IP-címét , ezért ha sikeresen generálnak egy hamis TCP-kérést, akkor a támadó valós IP-címére válaszolnak, ami teljesen elfogja a kapcsolatot.

Tehát a támadás végrehajtásához két TCP-kapcsolati paramétert kell ismernie. Abban az esetben, ha a támadó közvetlenül lehallgathatja az A és B gazdagép közötti kommunikációs csatornát, ezeket a paramétereket egyszerű forgalomelemzés határozza meg. Ellenkező esetben összetettebb módszerekhez kell folyamodnia.

Az ISN paraméter matematikai becslése

Ez a módszer azon a feltételezésen alapul, hogy az ISSa és ISSb kezdeti paraméterek (az ún. ISN  - Initial Sequence Number) kiválasztása a kapcsolat létesítésekor valamilyen módon az időtől függ. Biztonsági szempontból az lenne a legjobb, ha teljesen önkényes ISN-t választanánk, ami gyakorlatilag használhatatlanná tenné az előrejelzést, azonban a TCP protokoll RFC 793-as leírásában javasolt ennek a számlálónak az értékét növelni. 4 mikromásodpercenként 1-gyel, ami triviálissá teszi ennek az értéknek az előrejelzését. A gyakorlatban a régebbi Linux kernelek forráskódjának , valamint a Windows NT 4.0 és korábbi operációs rendszer viselkedésének elemzése megerősíti a választott ISN-érték funkcionális függőségét az időtől.

Általános esetben, ha létezik ilyen függőség, akkor azt valamilyen ISN = F(mcsec) képlettel fejezzük ki, ahol mcsec a vizsgált operációs rendszer hardveres órájának megfelelő mikroszekundumok száma.

Így a támadónak elemeznie kell a hozzárendelt ISN-érték függvényét az idő függvényében. Ehhez egy sor szokásos kérést küldenek a TCP -kapcsolat létrehozására a vizsgált hálózati operációs rendszernek, és minden egyes időpontban megkapják a megfelelő számú választ az operációs rendszer ISN-jének aktuális értékeivel. Ezzel egyidejűleg mérik a kérésekre adott válaszok megérkezésének időintervallumát (mikroszekundumban). Ha elkészítjük a kapott ISN-ek függését a kísérlet kezdete óta eltelt t időtől táblázatot, és ezt bármilyen matematikai eszközzel közelítjük, akkor a kiindulási adatok hibájával összemérhető hibával egy folytonos eredményt kapunk. az ISN t-től való változásának függvénye, adott időintervallumra érvényes: ISN(t) = F (t);

Ez a képlet lehetővé teszi, hogy az előző ISN-értéket felhasználva a kijelölése óta eltelt idő mérésével megkapjuk az adott időpontban aktuális ISN-értéket.

A jövőben a támadónak csak figyelnie kell a vizsgált gazdagépek viselkedését, és a kapcsolat létrehozásának pillanatának kiszámítása után hozzávetőlegesen meg kell becsülnie a gazdagépek által választott ISSa és ISSb értékek értéktartományát. Mivel ez a módszer hozzávetőleges, nem kerülhető el némi felsorolás, azonban a matematikai modellezés sok nagyságrenddel (~-től ~-ig) lehetővé teszi a támadónak a sikeres támadás végrehajtásához szükséges csomagok számának csökkentését.

Ablakcsere

Az ISN értékek előzetes matematikai értékelése azonban nem mindig lehetséges. Ezenkívül bizonyos esetekben az értéket többé-kevésbé időfüggetlennek választják, és ezért a matematikai értékelés nehéz vagy lehetetlen. Ebben az esetben durvább módszerekhez kell folyamodni, mint például ezen paraméterek összes lehetséges értékének számbavétele. Az RFC 793 szabvány alapos tanulmányozása után azonban a helyzet némileg leegyszerűsödik.

Az első dolog, amit meg kell említeni, a TCP protokoll ablakozási mechanizmusa. A csomagok megelőzhetik egymást, ha az interneten terjesztik. Annak érdekében, hogy az elődöknél korábban érkezett csomagok ne veszítsenek el, a címzett létrehoz egy úgynevezett ablakot, amelyben visszaállíthatja a csomagok sorrendjét. Így, ha a Sorozatszám mező értéke a vevő ablakában van, a TCP elfogadja és feldolgozza ezt a csomagot. Ez nagymértékben csökkenti a támadó próbálkozásainak számát: ról -ra csökken .

Az operációs rendszertől függően az ablak mérete bájt ( Windows XP SP2 -vel ) és 5840 bájt ( Linux kernel 2.4 és 2.6) között változhat.

Az ablak csökkenti a támadónak használandó sorszámok számát. Windows XP esetén ez a szám értékre csökken . Más szóval, a támadónak csak támadási csomagokat kell generálnia ahhoz, hogy beinjektálja az RST-csomagot, és így összeomlik a kapcsolat. Ez nagyon kicsi szám.

A helyzet még rosszabb lesz, ha a kapcsolat résztvevői támogatják az átméretezhető ablakot. Ez a TCP-funkció növeli annak valószínűségét, hogy rövid időn belül megtalálják a megfelelő sorszámot. Az ablak átméretezése olyan kapcsolatokra szolgál, amelyek a nagy késleltetés vagy a túlterhelt sávszélesség miatt nagyobb ablakot igényelnek. Annak érdekében, hogy mindenki átfedések nélkül tudjon továbbítani, ez a technológia az ablak méretét 14 bitesre bővíti (Microsoft Windows), azaz .

A támadónak azonban még egy akadályt kell leküzdenie: a forrás és a cél IP-címét/ port quad . Az IP-cím aligha jelent problémát – a támadó általában tudja, hogy kit céloz; a célport is könnyen meghatározható. Kicsit nehezebb meghatározni a forrásportot, amely elméletileg 0-tól 65535-ig terjedhet. A gyakorlatban az 1024 alatti és az operációs rendszer által meghatározott küszöbérték feletti portok speciális feladatokra vannak fenntartva.

A 2.4-es vagy 2.6-os kernelverziójú Linux a -tól -ig számokat használ feladó portként .

A támadó örömére a fennmaradó lehetőségek nincsenek véletlenszerűen elosztva; a kernel meghatározott séma szerint osztja el őket. Így a támadónak nem lesz sok gondja a forrásport előrejelzésével. Csak néhány kivétel van, mint például az OpenBSD , amely tetszőlegesen osztja ki őket. Például a Windows XP az első csatlakozás portján indul, és minden további csatlakozásnál 1-gyel növeli a portot. Linux ( főleg Fedora Core 3 2.6.9-es kernellel) ismét növekedésekkel. A Cisco rendszerek minden új kapcsolatnál 512-vel növelik a port értékét, de ez nem teszi biztonságosabbá a mechanizmust.

A támadónak nem kell kitalálnia a port számát, ha ismert az áldozat gépén lévő kapcsolatok száma. A támadónak általában csak annyit kell tennie, hogy az első értékkel kezdi, és mondjuk 50 portot próbál ki. A támadónak sem nehéz kiderítenie az áldozat operációs rendszerét. Valójában tehát nem jelent komoly akadályt a kikötő meghatározása.