Computerbeveiliging - Hoe je bad guys buiten de deur houdt

TCP seq nr attack: Off-Path TCP Sequence Number Inference

21-05-2012, 23:24 door Bitwiper, 10 reacties
Op het IEEE Symposium on Security and Privacy (http://www.ieee-security.org/TC/SP2012/program.html) zullen morgen Zhiyun Qian and Z. Morley Mao (University of Michigan) een presentatie geven over:

Off-Path TCP Sequence Number Inference Attack - How Firewall Middleboxes Reduce Security

De bijbehorende publicatie is al beschikbaar als PDF: http://web.eecs.umich.edu/~zhiyunq/pub/oakland12_TCP_sequence_number_inference.pdf

Als ik het goed begrijp is voor een aanval nodig:

- Een client device waarop al malware draait, echter unprivileged en zonder toegang tot andere applicaties;

- Het client device bevindt zich aan de schone kant van een firewall die TCP pakketjes dropt waarvan de sequence nummers buiten het TCP window vallen. Deze functionaliteit is niet nodig in een firewall (endpoints kunnen dat prima) maar de gedachte is dat je zo vervalste pakketjes al in de firewall blokkeert en zo minder verkeer in je schone netwerk overhoudt. Volgens de publicatie doen bijna alle grote firewall makers dit, waaronder Cisco, Juniper en CheckPoint;

- Een legitieme server aan de internetzijde van de firewall;

- Een aanvaller (eveneens aan de internetzijde van de firewall) die op de hoogte gehouden wordt door de malware op het device.

[   client  ]                    .––  X  ––[legitieme server]
[    met   ]––[firewall]––+
[malware]                     `–––––––[aanvaller]

De aanvallen kunnen vervolgens bestaan uit het redirecten van de verbinding, opgezet door de client, van de server naar de aanvaller. Ook kan de aanvaller ordinair verbindingen verbreken. De attacks werken doordat de aanvaller in combinatie met de malware aan de andere kant van de firewall het gedrag van die firewall kan observeren en misbruiken.

In het bijzonder mobiele devices zouden zo gevaar lopen; zowel de KPN als Vodafone GPRS/UMTS netwerken zouden kwetsbaar zijn volgens het artikel en de reacties in http://tweakers.net/nieuws/82078/onderzoekers-leggen-kwetsbaarheid-in-firewalls-bloot.html. Dat neemt niet weg dat vergelijkbare aanvallen op PC's achter firewalls met genoemde functionaliteit zouden kunnen plaatsvinden.

Voor de duidelijkheid: het gaat dus om een soort privilege escalation attack op een device waarop reeds malware draait. Als voorbeeld wordt verwezen naar http://www.youtube.com/watch?v=T65lQtgUJ2Y waarin te zien is dat een "wallpaper app" de logon op je Facebook pagina kan kapen. Het gaat dus niet om een generieke attack op TCP sequence nummers.

Nb. Tweakers stelt:
Door Dimitri Reijerman, maandag 21 mei 2012 18:03: het gebruik van ssl- en tls-protocollen dus enige bescherming zouden bieden
Dat is onzin. SSL/TLS verbindingen zijn niet te bypassen met deze techniek (bugs in implementaties van SSL/TLS, zwak geconfigureerde endpoints en onbetrouwbare CA's daargelaten). Uit de publicatie:
Door Zhiyun Qian en Z. Morley Mao: In general, SSL should be able to defeat most attacks. Hopefully one of the results of our study is to help push the HTTPS-only world. We do note that even if SSL is employed by the websites, there is a special case where an attack may still succeed. Specifically, when a user types in a URL such as www.chase.com, the default browser behavior is to initiate a normal HTTP request first unless the user specifically types in https://www.chase.com. It is generally the server that subsequently redirects the browser to the https site via a “301 – Moved Permanently” HTTP response. Instead of redirecting the browser, an attacker can simply respond directly with a phishing page to the initial HTTP request. In this case, the only difference is that the browser will not show the https icon. However, average users may not notice.
Gebruikers moeten gewoon leren om https in te tikken.

De redactie zal hier morgen waarschijnlijk ook wel een artikel over publiceren, maar de nachtbrakers hebben het in elk geval al op security.nl kunnen lezen!

Aanvulling, korte uitleg door de auteurs met plaatjes en filmpje is hier te vinden: http://web.eecs.umich.edu/~zhiyunq/tcp_sequence_number_inference/.
Reacties (10)
22-05-2012, 00:04 door Whoops
Door Bitwiper: Gebruikers moeten gewoon leren om https in te tikken.
Webmasters moeten gewoon leren om http automatisch door te linken naar https!
Waarom de gebruiker hiermee belasten?
22-05-2012, 00:06 door Bitwiper
Door Whoops:
Door Bitwiper: Gebruikers moeten gewoon leren om https in te tikken.
Webmasters moeten gewoon leren om http automatisch door te linken naar https!
En dat is dus totaal zinloos.
22-05-2012, 00:41 door Whoops
Door Bitwiper: En dat is dus totaal zinloos.
Ik bedoel natuurlijk alleen wanneer dat noodzakelijk is :)
22-05-2012, 00:50 door [Account Verwijderd]
[Verwijderd]
22-05-2012, 01:04 door Bitwiper
Laat ik het doel van https nog maar eens kort uitleggen:

(1) Je weet zeker dat je met de site in de URL balk communiceert;
--en daarna--
(2) Om te voorkomen dat een derde kan meekijken (en/of gegevens kan wijzigen) is de verbinding versleuteld.

Stap 2 is zinloos als je stap 1 niet hebt gedaan: als je niet weet met wie je communiceert, waarom zou je de verbinding dan versleutelen?

Als je een web sessie begint met http kan een aanvaller (zoals beschreven in de Off-Path TCP Sequence Number Inference Attack) de verbinding kapen voordat de bedoelde server de kans krijgt je te redirecten naar een https pagina. Je krijgt dan de pagina van de aanvaller te zien. Dat kan http zijn (zonder dat je het opmerkt) of keurige https met een afwijkende hostname die wellicht ook niet opvalt.

Omdat je gebruikers niet moet willen belasten met het dubbelchecken van URL's en certificaten achter slotjes (en het doorgronden van fake meldingen als "door een storing van onze algemene site is er tijdelijk geen versleutelde verbinding") nadat de verbinding tot stand is gekomen moet je ze leren meteen https in te tikken. Of beter: eenmalig invoeren en meteen de URL bookmarken.

Aanvulling 08:46 - met die laatste alinea was ik afgelopen nacht wat te kort door de bocht. Ook na het intikken van een https URL (of klikken op een bookmark/favoriet/internet snelkoppeling) moet je nog wel checken of je op de bedoelde site terecht bent gekomen, want het DNS systeem is -helaas- ook allesbehalve betrouwbaar.
22-05-2012, 11:02 door SirDice
Ik heb het even snel gelezen, misschien nog niet goed genoeg, maar wat is het verschil met een 'standaard' TCP session hijack?

http://tazforum.thetazzone.com/viewtopic.php?f=28&t=1847
22-05-2012, 22:18 door Bitwiper
Door SirDice: Ik heb het even snel gelezen, misschien nog niet goed genoeg, maar wat is het verschil met een 'standaard' TCP session hijack?

http://tazforum.thetazzone.com/viewtopic.php?f=28&t=1847
Beetje jammer dat je m'n samenvatting niet helemaal leest, en me vervolgens naar een vage site stuurt waarvoor ik een account moet hebben om iets te kunnen zien. Maar okay, jij staat ook altijd klaar met meestal uitstekende adviezen, het is je vergeven...

Het verschil met een standaard TCP session hijack (https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_hijacking) is dat:

- Er malware op het device "in LAN" achter de firewall moet staan onder besturing van de aanvaller (de malware moet in elk geval contact kunnen opnemen met de aanvaller). In de voorbeelden is er sprake van een smartphone via GPRS/UMTS achter een firewall van een telecom provider;

- Zowel de aanvaller als het bedoelde endpoint (meestal een server) zich aan de internetzijde bevinden.

Het doel is een privilege escalation attack waarmee unprivileged malware op de smartphone andere TCP verbindingen van/naar die smartphone kan kapen. Dit lijkt nauwelijks zinvol (in elk geval het account van de smartphone bezitter is gecompromitteerd) maar dit geldt natuurlijk net zo goed voor PC's (en terminal servers).

Denk aan update processen met verhoogde rechten. Als zij niet alles wat ze downloaden checken (digitale handtekeningen etc) zijn zo privilege escalation attacks denkbaar. Ook kan unprivileged malware, zonder injection technieken en BHO's, browsers naar een fake bank site sturen ipv naar de echte (vergelijkbaar met DNS aanvallen). Dus niet dramatisch, wel weer een extra aanvalsvariant. Op een terminal server kan dit waarschijnlijk tussen verschillende sessies, dat maakt de aanval wel wat gevaarlijker.

Check het fillmpje http://www.youtube.com/watch?v=T65lQtgUJ2Y en je snapt het.
23-05-2012, 10:50 door SirDice
Door Bitwiper:
Door SirDice: Ik heb het even snel gelezen, misschien nog niet goed genoeg, maar wat is het verschil met een 'standaard' TCP session hijack?

http://tazforum.thetazzone.com/viewtopic.php?f=28&t=1847
Beetje jammer dat je m'n samenvatting niet helemaal leest, en me vervolgens naar een vage site stuurt waarvoor ik een account moet hebben om iets te kunnen zien. Maar okay, jij staat ook altijd klaar met meestal uitstekende adviezen, het is je vergeven...
Zo'n vage site is dat niet. Het is ooit begonnen door een aantal mensen die Anti-Online zat waren. Ik ben inmiddels alweer vele jaren moderator daar. Vreemd dat 't niet werkt zonder in te loggen. Deze is waarschijnlijk beter dan:
http://www.thetazzone.com/tutorial-a-quick-introduction-to-tcp-session-hijacking/


Het verschil met een standaard TCP session hijack (https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_hijacking) is dat:

- Er malware op het device "in LAN" achter de firewall moet staan onder besturing van de aanvaller (de malware moet in elk geval contact kunnen opnemen met de aanvaller). In de voorbeelden is er sprake van een smartphone via GPRS/UMTS achter een firewall van een telecom provider;

- Zowel de aanvaller als het bedoelde endpoint (meestal een server) zich aan de internetzijde bevinden.
Zover volgde ik het nog prima.

Het doel is een privilege escalation attack waarmee unprivileged malware op de smartphone andere TCP verbindingen van/naar die smartphone kan kapen.
Ergo, een session hijack. Het enige verschil is dat de hijack niet van "buitenaf" gedaan wordt maar van "binnenuit". Het is en blijft nog steeds een TCP session hijack. Ik bedoel, wat is het verschil met bijv. het overnemen van een telnet sessie van iemand die root is?

Het enige wat ik me kan voorstellen is dat de TCP sequence nummers van smartphones voorspelbaar zijn. Iets wat in de PC wereld jaren geleden al eens is aangepakt door deze wat moeilijker voorspelbaar te maken.
23-05-2012, 11:28 door Bitwiper
@SirDice: ik ben (helaas) niet zo'n held in korte beschrijvingen, maar ene "jws" kan het in een paar regels: http://news.ycombinator.com/item?id=4007646. Hopelijk maakt dat het duidelijk?
23-05-2012, 11:49 door SirDice
Ah. Iets duidelijker. Maar 't is evengoed nog steeds een standaard TCP hijack. Het enige verschil is dat de firewall feitelijk een aanvaller helpt door pakketjes met invalide sequence nummers te droppen. Wat er dus doorheen komt moet dan een valide sequence nummer hebben. Daarmee moet het inderdaad makkelijker zijn om zo'n hijack uit te voeren.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.