TCP-kapning

TCP-kapning  - En variant av Man -in-the-Middle-attacken där en angripare kan spionera på nätverksmedlemmars paket och skicka sina egna paket till nätverket. Attacken använder anslutningsetableringsfunktionerna i TCP- protokollet och kan utföras både under en "trippel handskakning" och under en etablerad anslutning.

Problemet med eventuell spoofing av TCP-meddelanden är viktigt, eftersom analysen av FTP- och TELNET- protokollen implementerade på basis av TCP-protokollet visade att problemet med att identifiera FTP- och TELNET-paket helt och hållet tilldelas transportnivån av dessa protokoll, dvs. , till TCP.

Upprätta en TCP-anslutning

För att identifiera ett TCP-paket i TCP-huvudet finns det två 32-bitars identifierare som också spelar rollen som en paketräknare - Sekvensnummer och Kvitteringsnummer. I händelse av att värd A vill upprätta en TCP-förbindelse med värd B, s.k. "trippelt handslag", under vilket värdarna utbyter följande paket:

Detta paket slutför anslutningskonfigurationen, så i nästa paket skickar värd A användbar information till värd B

Angreppsprincip

Med tanke på anslutningskonfigurationsschemat som beskrivs ovan kan du se att de enda identifierare med vilka slutvärden kan skilja mellan TCP-abonnenter och TCP-anslutningar är fälten Sekvensnummer och Bekräftelsenummer. Således, om en angripare bestämmer ISSa- och ISSb-värdena för en given anslutning, kan han generera ett falskt TCP-paket som kommer att accepteras och bearbetas av den slutliga värden.

En typ av attack innebär att angriparen bäddar in RST (Reset)-kontrollbiten i TCP-paketet. Enligt RFC 793 berättar denna flagga för målvärden att avbryta anslutningen utan ytterligare kommunikation. Baserat på sekvensnummerfältet bestämmer målvärden om återställningskommandot ska behandlas eller ignoreras, och målet är förbjudet att skicka ett svar med RST-biten inställd. Det är viktigt att notera att målvärden endast autentiserar RST-begäran mot sekvensnumret och stänger anslutningen om den faller inom det aktuella TCP-fönstret. Och även om målvärden kan beräkna bekräftelsenumret, är det inte nödvändigt att göra det, och de flesta TCP-stackar ignorerar helt enkelt detta steg.

Ett mottaget RST-paket kommer alltid att avsluta anslutningen. Långtidsanslutningar, såsom BGP - anslutningar mellan routrar, är extremt känsliga för sådana attacker. Först och främst kommer angriparen att ha tillräckligt med tid för att implementera ett noggrant planerat paket, och å andra sidan kommer DoS att orsaka enorma förluster . Routrar måste konfigurera om grannbordet, vilket kan ta flera minuter i verkligheten.

Mindre uppenbart är det faktum att SYN-flaggan också kan krascha anslutningen. Enligt RFC 793 , när SYN-flaggan sätts när en anslutning upprättas, innehåller sekvensnummerfältet ett initialt värde som kommer att användas senare. Om ett SYN-paket därefter tas emot på denna anslutning kommer RFC 793 att behandla detta som ett fel. Som ett resultat måste mottagaren avbryta anslutningen genom att skicka ett RST-paket. Till skillnad från ett RST-paket kommer värden att svara på ett SYN-paket genom att skicka ett RST-paket. Detta öppnar möjligheten för ännu en DoS-attack. Angriparen kan därefter använda offrets bandbredd. Denna attack är särskilt framgångsrik på ADSL- linjer.

Medan RST- och SYN-attacker inte använder nyttolasten från ett IP-datagram , injicerar en tredje teknik data i en befintlig anslutning. Angriparen kan infoga vilken data som helst som gör att anslutningen avbryts, eller noggrant skapa data som leder till ett feltillstånd, eller utföra någon funktion till förmån för angriparen. Offret kanske inte ens märker dessa manipulationer. Till exempel kontrollerar inte FTP- och TelNET-protokollen avsändarens IP-adress , och därför, om en falsk TCP-begäran genereras framgångsrikt, kommer de att svara på angriparens riktiga IP-adress, som helt kommer att fånga upp anslutningen.

Så för att utföra en attack måste du känna till två TCP-anslutningsparametrar. Om en angripare direkt kan avlyssna kommunikationskanalen mellan värdarna A och B, bestäms dessa parametrar genom enkel trafikanalys. Annars måste du ta till mer komplexa metoder.

Matematisk uppskattning av ISN-parametern

Denna metod bygger på antagandet att valet av initialparametrarna ISSa och ISSb (det så kallade ISN  - Initial Sequence Number) vid upprättande av en förbindelse på något sätt beror på tiden. Det skulle vara bäst ur säkerhetssynpunkt att välja ett ISN som är helt godtyckligt, vilket skulle göra förutsägelsen praktiskt taget otillämplig, men i beskrivningen av TCP-protokollet i RFC 793 rekommenderas det att öka värdet på denna räknare med 1 var fjärde mikrosekund, vilket gör förutsägelsen av detta värde trivial. I praktiken bekräftar analys av källkoden för äldre Linux- kärnor , såväl som beteendet hos Windows NT 4.0 och tidigare operativsystem, det funktionella beroendet av det valda ISN-värdet i tid.

I det allmänna fallet, om ett sådant beroende existerar, kommer det att uttryckas med någon formel av formen ISN = F(mcsec), där mcsec är antalet mikrosekunder enligt hårdvaruklockan för operativsystemet som studeras.

Därför måste angriparen utföra en viss analys av funktionen hos det tilldelade ISN-värdet kontra tid. För att göra detta skickas en serie vanliga förfrågningar om att skapa en TCP- anslutning till nätverksoperativsystemet som studeras och motsvarande antal svar med de aktuella värdena för ISN för operativsystemet vid varje tidpunkt tas emot. Samtidigt mäts tidsintervallen (i mikrosekunder) för ankomsten av svar på förfrågningar. Genom att konstruera en tabell över beroendet av de erhållna ISN:erna på tiden t som har förflutit sedan experimentets början, och approximera den med valfria matematiska verktyg, får vi, med ett fel jämförbart med felet för de initiala data, en kontinuerlig funktion av förändringen i ISN från t, giltig för ett givet tidsintervall: ISN(t) = F(t);

Denna formel gör det möjligt för oss att använda det tidigare ISN-värdet, genom att mäta den tid som förflutit sedan dess utnämning, för att erhålla det aktuella ISN-värdet vid den givna tidpunkten.

I framtiden behöver angriparen bara övervaka beteendet hos de värdar som undersöks, och efter att ha beräknat ögonblicket för att skapa anslutningar, ungefär uppskatta intervallet av värden för ISSa- och ISSb-värdena som värdarna valt. Eftersom denna metod är ungefärlig kan viss uppräkning inte undvikas, men matematisk modellering tillåter många storleksordningar (från ~ till ~ ) för att minska antalet paket som en angripare behöver för att utföra en framgångsrik attack.

Fönsterbyte

Det är dock inte alltid möjligt att göra en preliminär matematisk utvärdering av ISN-värden. I vissa fall är värdet också valt att vara mer eller mindre tidsoberoende, och därför är matematisk utvärdering svår eller omöjlig. I det här fallet måste man ta till mer grova metoder som uppräkning av alla möjliga värden för dessa parametrar. Men efter noggrann studie av RFC 793- standarden är situationen något förenklad.

Det första att nämna är fönstermekanismen i TCP-protokollet. Paket kan köra om varandra när de distribueras över Internet. För att inte tappa paketen som kommit tidigare än föregångarna upprättar mottagaren ett så kallat fönster där han kan återställa paketens ordning. Således, om värdet på sekvensnummerfältet ligger inom mottagarens fönster, kommer TCP att acceptera och bearbeta detta paket. Detta minskar avsevärt antalet försök som angriparen måste göra: det minskar från till .

Beroende på operativsystemet kan fönsterstorleken variera mellan byte ( Windows XP med SP2 ) och 5840 byte ( Linuxkärna 2.4 och 2.6).

Fönstret kommer att minska antalet sekvensnummer som angriparen behöver använda. I fallet med Windows XP sjunker detta nummer till . Med andra ord skulle angriparen bara behöva generera attackpaket för att injicera RST-paketet och därmed krascha anslutningen. Detta är ett mycket litet antal.

Saker och ting blir ännu värre om deltagarna i anslutningen stöder ett fönster som kan ändras storlek. Denna TCP-funktion ökar sannolikheten för att hitta ett lämpligt sekvensnummer på kort tid. Fönsterstorleksändring är avsedd för anslutningar som kräver ett större fönster på grund av hög latens eller upptagen bandbredd. För att alla ska kunna sända utan överlappning utökar denna teknik fönsterdimensionen till 14 bitar (Microsoft Windows), dvs.

Men angriparen måste övervinna ytterligare ett hinder: källan och destinationens IP-adress/ portkvadrat . IP-adressen är knappast ett problem - angriparen vet vanligtvis vem han riktar sig till; destinationsporten är också lätt att bestämma. Det är lite svårare att bestämma källporten, som teoretiskt sett kan variera från 0 till 65535. I praktiken är portar under 1024 och över det tröskelvärde som bestäms av operativsystemet reserverade för speciella uppgifter.

Linux med kärnversion 2.4 eller 2.6 använder nummer från till som avsändarport .

Till angriparens nöje är de återstående alternativen inte slumpmässigt fördelade; kärnan distribuerar dem enligt ett specifikt schema. Därför kommer angriparen inte att ha mycket problem med att förutsäga källporten. Det finns bara några få undantag, såsom OpenBSD , som allokerar dem godtyckligt. Till exempel startar Windows XP vid porten för den första anslutningen och ökar porten med 1 för varje efterföljande anslutning. Linux ( Fedora Core 3 med kärnan 2.6.9 i synnerhet) med återigen ökar i ordning. Cisco-system ökar portvärdet med 512 för varje ny anslutning, men detta gör inte mekanismen säkrare.

En angripare behöver inte gissa portnumret om antalet anslutningar på offrets dator är känt. Allt en angripare vanligtvis behöver göra är att börja med det första värdet och prova, till exempel, 50 portar. Det är inte heller svårt för en angripare att ta reda på offrets operativsystem. Så i själva verket är definitionen av hamnen inget allvarligt hinder.