TCP-aanval maakt vervalsen van IP-adres mogelijk
Twee studenten van de Fontys Hogeschool Eindhoven hebben onderzoek uitgevoerd naar het spoofen van TCP-verbindingen en een aanval ontdekt waardoor het mogelijk is om IP-adressen te vervalsen. Het Transmission Control Protocol (TCP) wordt gebruikt voor het uitwisselen van data over netwerken.
Een ander protocol dat hiervoor wordt gebruikt is het User Datagram Protocol (UDP). Bij UDP, dat geen garantie biedt dat uitgewisselde pakketten ook zijn aangekomen, is het bekend dat een IP-adres kan worden gespooft. TCP gebruikt echter een handshake met beveiligingsgetal, waardoor werd aangenomen dat het bij dit protocol niet zou kunnen. Studenten Raoul Houkes en Luc Gommans hebben een manier gevonden dat het beveiligingsgetal is te raden en IP-adressen zonder man-in-the-middle, ARP-spoofing of andere bekende aanvallen zijn te spoofen. Volgens de studenten gaat het voor zover zij weten om een geheel nieuwe aanval.
TCP-protocol
Het TCP-protocol is het meestgebruikte transportprotocol, gevolgd door UDP en ICMP. Het is populair doordat het de juiste overdracht van data vrijwel garandeert, alsmede verifieert dat het IP-adres van de afzender klopt. Hiervoor wordt een zogeheten handshake opgezet, waarbij beide partijen een getal van de ander terug moeten sturen. Wanneer iemand een vals IP-adres opgeeft als afzender, zal het getal daarheen worden gestuurd, wat nooit aankomt bij de werkelijke afzender. Die partij zal zich dan ook niet kunnen verifiëren.
De getallen die worden uitgewisseld liggen tussen de 0 en 4,2 miljard en kunnen door een aanvaller worden geraden. Het getal wordt door beide partijen willekeurig gegenereerd. Om de aanval uit te voeren moet de aanvaller dan ook allerlei getallen genereren en proberen. Gemiddeld kost het 120GB aan netwerkverkeer voordat een poging slaagt (50% kans), aldus de onderzoekers. Het is echter niet zo dat er na 240GB een 100% kans is. Doordat opnieuw moet worden gestart na enkele seconden (een verbinding verloopt als het te lang onbevestigd blijft) kan het door domme pech ook langer duren.
Een moderne verbinding van 10 gigabit zou de aanval daarmee in gemiddeld 103 seconden kunnen uitvoeren, en een meer gangbare 1-gigabit verbinding neemt gemiddeld nog geen 18 minuten in beslag. De aanvaller krijgt trouwens geen bevestiging terug als hij het juiste getal heeft gevonden, aangezien het antwoord naar de partij gaat als wie hij zich voordoet. Als hij bijvoorbeeld probeert om een database te verwijderen zal dit echter buiten de handshake om zichtbaar zijn.
Oplossing
Volgens de onderzoekers lijkt het voorkomen van de aanval simpel, door verdere berichten na een aantal ongeldige berichten te negeren. "Het probleem hierbij is dat dit weer als Denial of Service-aanval kan worden misbruikt: blijf ongeldige pakketten sturen met als afzender een bepaald IP-adres, en de werkelijke eigenaar van dat IP-adres zal nooit meer een goede verbinding op kunnen zetten", zegt Gommans tegen Security.NL. Telkens bij het opzetten van een verbinding zou zo'n vals pakket aankomen en de verbinding ontregelen.
Een ander idee is om het veld in het TCP-bericht te vergroten van 32- naar 64-bits, maar dat zou een structurele aanpassing zijn van een ontzettend wijdverspreid protocol, aldus de studenten. "Naar IPv6 kijkend zou dat best weleens 20 jaar kunnen duren. Een simpele methode om de aanval structureel af te slaan is er dus niet", merkt Gommans op. Aanvullende beveiliging zoals TLS zal voor nu dan ook moeten worden gebruikt, zo stellen de studenten. Ze hebben in deze blogposting de aanval technisch uitgewerkt.
Reacties (27)
Ligt het aan mij of zie ik het nut van die aanval niet echt in? Worse case scenario is dat je een legitiem IP-adres op een blacklist weet te krijgen. Ik kan me namelijk geen scenario voorstellen waarin een firewall (of zelfs maar een router) het toe laat dat er 100+ GB aan ongeldig verkeer van een bepaald IP-adres komt.
Als je het probeert als een DoS op de service die je aanvalt door allerlei random IP-adressen te gebruiken, is het een bijzonder omslachtige en ineffeciente manier. Een UDP aanval met een reflection component is door de multiplier dan vele malen effectiever.
Als je het probeert als een DoS op de service die je aanvalt door allerlei random IP-adressen te gebruiken, is het een bijzonder omslachtige en ineffeciente manier. Een UDP aanval met een reflection component is door de multiplier dan vele malen effectiever.
30-11-2015, 13:29 door
Erik van Straten
Nog een reden om zoveel mogelijk over te stappen op degelijk geauthenticeerde (en vervolgens versleutelde) verbindingen, zoals mogelijk met https.
En tevens nog een reden om domain-validated en "Let's Encrypt" certificaten niet te vertrouwen.
En tevens nog een reden om domain-validated en "Let's Encrypt" certificaten niet te vertrouwen.
30-11-2015, 13:32 door
buttonius
Elk serieus bedrijf en elke serieuze Internet provider zou haar switches en routers zo moeten instellen dat deze verkeer dat binnenkomt op een verkeerde poort binnenkomt direct wegdonderen.
Een verkeerde poort is een poort waar verkeer, op grond van de afzender (die in de berichtenstroom staat), niet vandaan hoort te kunnen komen).
Daarmee is dit probleem opgelost. Dat hoeft echt geen 30 jaar te duren.
Een verkeerde poort is een poort waar verkeer, op grond van de afzender (die in de berichtenstroom staat), niet vandaan hoort te kunnen komen).
Daarmee is dit probleem opgelost. Dat hoeft echt geen 30 jaar te duren.
"hebben onderzocht"? Dit is eerder een citaat uit een literatuurstudie. De onderbouwing van sequence nummers en mogelijke aanvallen hierop staan volgens mij zelfs als in de originele RFCs.
Verder moet je ook nog source port guessing doen en werkt het alleen op nagenoeg idle tcp verbindingen.
Verder moet je ook nog source port guessing doen en werkt het alleen op nagenoeg idle tcp verbindingen.
Door Erik van Straten:En tevens nog een reden om domain-validated en "Let's Encrypt" certificaten niet te vertrouwen.
Zou je dit willen toelichten? Waarom zou deze aanval die het versturen van gespoofte TCP-pakketen mogelijk maakt, ervoor zorgen dat DV certificaten ook maar iets minder te vertrouwen zijn dan het geval zou zijn zonder het bestaan van deze aanval?Door buttonius: Elk serieus bedrijf en elke serieuze Internet provider zou haar switches en routers zo moeten instellen dat deze verkeer dat binnenkomt op een verkeerde poort binnenkomt direct wegdonderen.
Een verkeerde poort is een poort waar verkeer, op grond van de afzender (die in de berichtenstroom staat), niet vandaan hoort te kunnen komen).
Daarmee is dit probleem opgelost. Dat hoeft echt geen 30 jaar te duren.
De aanval heeft niets met poortnummers te maken, maar met sequence numbers in de TCP header (aanvulling: zie offsets 4 en 8 in het "plaatje" in https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure).Een verkeerde poort is een poort waar verkeer, op grond van de afzender (die in de berichtenstroom staat), niet vandaan hoort te kunnen komen).
Daarmee is dit probleem opgelost. Dat hoeft echt geen 30 jaar te duren.
In aanvulling op Anoniem van 13:33: deze aanval is overigens absoluut niet nieuw (Google: tcp sequence number randomness). Destijds waren in veel besturingssystemen deze nummers voorspelbaar bijv. omdat ze met 0 begonnen en/of telkens met 1 werden opgehoogd.
Of vergroten van 32 naar 64 bit zoveel meer zekerheid biedt is nog maar de vraag. Feitelijk heb je "onvoorspelbare" randomness (uit een CSPRNG = Cryptographically Secure Random Number Generator) nodig. Maar met steeds sneller wordende netwerken heb je op de meeste systemen veel te weinig entropie om in een enorm tempo van dat soort getallen te kunnen genereren. Virtualisatie helpt daar ook nog eens niet bij.
Aanvulling 13:58: verwijzing naar wikipedia met TCP header toegevoegd
30-11-2015, 14:12 door
Luc Gommans
Door Erik van Straten:
In aanvulling op Anoniem van 13:33: deze aanval is overigens absoluut niet nieuw (Google: tcp sequence number randomness). Destijds waren in veel besturingssystemen deze nummers voorspelbaar bijv. omdat ze met 0 begonnen en/of telkens met 1 werden opgehoogd.
In aanvulling op Anoniem van 13:33: deze aanval is overigens absoluut niet nieuw (Google: tcp sequence number randomness). Destijds waren in veel besturingssystemen deze nummers voorspelbaar bijv. omdat ze met 0 begonnen en/of telkens met 1 werden opgehoogd.
Het gaat hier echter niet om de (CS)PRNG voorspellen, dat is inderdaad jaren oud. Het nieuwe hieraan is dat de netwerksnelheden tegenwoordig dusdanig hoog zijn dat die 32 bits niet voldoende bescherming bieden. In de jaren 80 (TCP komt uit 1981) werd dat echt onmogelijk geacht. Dat het mogelijk is om een TCP verbinding op deze manier op te zetten, zonder Man in the Middle te zijn of de getallen te kunnen voorspellen, hebben wij niet ergens anders kunnen vinden.
Door Anoniem: Verder moet je ook nog source port guessing doen en werkt het alleen op nagenoeg idle tcp verbindingen.
Source port guessing is hiervoor niet nodig. Ik snap ook niet zo goed waar de opmerking vandaan komt.Door Anoniem: Ik kan me namelijk geen scenario voorstellen waarin een firewall (of zelfs maar een router) het toe laat dat er 100+ GB aan ongeldig verkeer van een bepaald IP-adres komt.
Ik denk dat je zult ondervinden dat vrijwel elk systeem dat prima binnenlaat. Maar stel je hebt een doelwit dat inderdaad actief reageert en 24/7 monitort, dan kun je bijvoorbeeld de aanval verdelen over honderd valse IP-adressen die dan elk 10mbps laten gebruiken. Kost dezelfde tijd (18 minuten gemiddeld) voordat er een slaagt, en niemand heeft door dat alle honderd valse IP-adressen eigenlijk van één bron komen.Quote:
Het werkt dus alleen maar op verbindingen die heel lang open staan, genoeg om minimaal 120G data te versturen.
En de kans dat dat op wirespeed over een lijn gaat is eigenlijk alleen binnen een LAN aanwezig
Ofwel: misschien een potentieel probleem voor interne backup-sessies waarbij een image backup gedraaid wordt, en niet voor "normaal Internet verkeer". En ja, een SSL-vpn kan lang open staan en veel data versturen, maar bevat weer een encryptie laag dus het injecteren van gespoofde pakketten wordt door de crypto laag gedetecteerd.
Q
Gemiddeld kost het 120GB aan netwerkverkeer voordat een poging slaagt (50% kans),...
enEen moderne verbinding van 10 gigabit zou de aanval daarmee in gemiddeld 103 seconden kunnen uitvoeren, en een meer gangbare 1-gigabit verbinding neemt gemiddeld nog geen 18 minuten in beslag...
Het werkt dus alleen maar op verbindingen die heel lang open staan, genoeg om minimaal 120G data te versturen.
En de kans dat dat op wirespeed over een lijn gaat is eigenlijk alleen binnen een LAN aanwezig
Ofwel: misschien een potentieel probleem voor interne backup-sessies waarbij een image backup gedraaid wordt, en niet voor "normaal Internet verkeer". En ja, een SSL-vpn kan lang open staan en veel data versturen, maar bevat weer een encryptie laag dus het injecteren van gespoofde pakketten wordt door de crypto laag gedetecteerd.
Q
Door Erik van Straten: Nog een reden om zoveel mogelijk over te stappen op degelijk geauthenticeerde (en vervolgens versleutelde) verbindingen, zoals mogelijk met https.
En tevens nog een reden om domain-validated en "Let's Encrypt" certificaten niet te vertrouwen.
HTTPS ligt een laag hoger en heeft dus niks hiermee te maken. Het gaat hier om een verbinding maken, dus voordat er data verstuurd kan worden.En tevens nog een reden om domain-validated en "Let's Encrypt" certificaten niet te vertrouwen.
Verder zie ik het enige hier dat je een communicatie kanaal kan openen voor een ander IP adres, maar verder dan dit kom je niet. En zeker gezien de hoeveelheden aan data dat verstuurd moet worden is dit best wel kansloos.
Het nieuwsbericht is ook echt in jip/janneke taal geschreven. Ik had nogal moeite met verstaan waar het precies over ging
Door Erik van Straten:
In aanvulling op Anoniem van 13:33: deze aanval is overigens absoluut niet nieuw (Google: tcp sequence number randomness). Destijds waren in veel besturingssystemen deze nummers voorspelbaar bijv. omdat ze met 0 begonnen en/of telkens met 1 werden opgehoogd.
Of vergroten van 32 naar 64 bit zoveel meer zekerheid biedt is nog maar de vraag. Feitelijk heb je "onvoorspelbare" randomness (uit een CSPRNG = Cryptographically Secure Random Number Generator) nodig. Maar met steeds sneller wordende netwerken heb je op de meeste systemen veel te weinig entropie om in een enorm tempo van dat soort getallen te kunnen genereren. Virtualisatie helpt daar ook nog eens niet bij.
Aanvulling 13:58: verwijzing naar wikipedia met TCP header toegevoegd
Door buttonius: Elk serieus bedrijf en elke serieuze Internet provider zou haar switches en routers zo moeten instellen dat deze verkeer dat binnenkomt op een verkeerde poort binnenkomt direct wegdonderen.
Een verkeerde poort is een poort waar verkeer, op grond van de afzender (die in de berichtenstroom staat), niet vandaan hoort te kunnen komen).
Daarmee is dit probleem opgelost. Dat hoeft echt geen 30 jaar te duren.
De aanval heeft niets met poortnummers te maken, maar met sequence numbers in de TCP header (aanvulling: zie offsets 4 en 8 in het "plaatje" in https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure).Een verkeerde poort is een poort waar verkeer, op grond van de afzender (die in de berichtenstroom staat), niet vandaan hoort te kunnen komen).
Daarmee is dit probleem opgelost. Dat hoeft echt geen 30 jaar te duren.
In aanvulling op Anoniem van 13:33: deze aanval is overigens absoluut niet nieuw (Google: tcp sequence number randomness). Destijds waren in veel besturingssystemen deze nummers voorspelbaar bijv. omdat ze met 0 begonnen en/of telkens met 1 werden opgehoogd.
Of vergroten van 32 naar 64 bit zoveel meer zekerheid biedt is nog maar de vraag. Feitelijk heb je "onvoorspelbare" randomness (uit een CSPRNG = Cryptographically Secure Random Number Generator) nodig. Maar met steeds sneller wordende netwerken heb je op de meeste systemen veel te weinig entropie om in een enorm tempo van dat soort getallen te kunnen genereren. Virtualisatie helpt daar ook nog eens niet bij.
Aanvulling 13:58: verwijzing naar wikipedia met TCP header toegevoegd
Erik, wat de poster bedoeld is dat de ISP zulk verkeer naar een verkeerde poort moet doorverwijzen als beveiligingslayer.
30-11-2015, 14:42 door
Overcome
Een ander protocol dat hiervoor wordt gebruikt is het User Datagram Protocol (UDP). Bij UDP, dat geen garantie biedt dat uitgewisselde pakketten ook zijn aangekomen, is het bekend dat een IP-adres kan worden gespooft. TCP gebruikt echter een handshake met beveiligingsgetal, waardoor werd aangenomen dat het bij dit protocol niet zou kunnen.
Dat klopt niet. Het was in 1985 al bekend dat TCP verkeer gespoofed kon worden. Zie het artikel van Robert Morris (de man achter de eerste Internetworm): https://pdos.csail.mit.edu/~rtm/papers/117.pdf. Hij behandelt in zijn artikel inderdaad niet een brute-force aanval maar richt zich op sequence number prediction, een techniek die wellicht ook nog heden ten dage sneller is dan de aanval die in dit artikel is beschreven, hoewel ik niet meer heb bijgehouden hoe sequence numbers tegenwoordig worden gegenereerd bij de verschillende besturingssystemen. Het was de aanval die Kevin Mitnick o.a. gebruikte om binnen te komen bij Tsutomu Shimomura. Ik heb er in 1998 nog een scriptie aan gewijd als onderdeel van mijn studie. Het idee is dus zeker niet nieuw, maar deze uitvoering wellicht wel.
Ja dit stelt duidelijk niks voor, alles wat daar staat is allang bekend en niet praktisch inzetbaar.
Echter feit blijft dat BCP38 moet worden ingevoerd. Providers die geen BCP38 doen moeten gewoon
een negatief stempel krijgen.
Echter feit blijft dat BCP38 moet worden ingevoerd. Providers die geen BCP38 doen moeten gewoon
een negatief stempel krijgen.
30-11-2015, 14:12 door Luc Gommans: Het gaat hier echter niet om de (CS)PRNG voorspellen, dat is inderdaad jaren oud. Het nieuwe hieraan is dat de netwerksnelheden tegenwoordig dusdanig hoog zijn dat die 32 bits niet voldoende bescherming bieden. In de jaren 80 (TCP komt uit 1981) werd dat echt onmogelijk geacht. Dat het mogelijk is om een TCP verbinding op deze manier op te zetten, zonder Man in the Middle te zijn of de getallen te kunnen voorspellen, hebben wij niet ergens anders kunnen vinden.
Leuk dat je zelf reageert!Gezien jouw reactie begijp ik de aanval niet goed. In http://lgms.nl/blog-2, onder "Proof of concept" zie ik het volgende (ik gebruik bewust het m.i. verwarrende woord "target" niet):
Alice: 192.168.36.17 is een SSH server (TCP poort 22)
Bob: 192.168.36.18 (doet niets, zijn identiteit / IP-adres wordt gespoofed)
Mallory: 192.168.36.11, stuurt pakketjes naar Alice met het IP-adres van Bob (192.168.36.18) als afzender
Helaas vertel je er niet bij waar je met Wireshark hebt opgenomen (ik vermoed op Alice).
De IP-adressen doen vermoeden dat alle hosts zich op 1 subnet bevinden. Ervan uitgaande dat je een switch gebruikt en geen hub, en er geen sprake is van ARP-spoofing aanvallen of aanvallen waardoor de switch als hub gaat werken, zal Mallory nooit TCP (unicast dus) pakketjes met antwoorden van Alice aan Bob ontvangen.
OK. Mallory stuurt een SYN pakketje, met als afzender Bob, naar Alice. Alice stuurt het antwoord naar Bob; Mallory ontvangt dit niet, waardoor Mallory geen idee heeft van het door Alice gekozen acknowledgement (sequence) nummer.
Laten we ervan uitgaan dat Bob uit staat en geen RST pakketjes terugstuurt.
Je laat zien dat Mallory vervolgens net zolang nummers gaat genereren totdat deze overeenkomen met wat Allice verwacht van Bob. Zodra dat lukt, stuurt Alice braaf een SSH header "terug" - naar Bob, opnieuw niet naar Mallory.
Hoe weet Mallory (die nooit antwoorden ontvangt) nu dat zij het juiste het juiste sequence nummer heeft geraden? En hoe kan zij de rest van de sessie kapen?
30-11-2015, 15:48 door
buttonius
Door Erik van Straten:
...
Door buttonius: Elk serieus bedrijf en elke serieuze Internet provider zou haar switches en routers zo moeten instellen dat deze verkeer dat binnenkomt op een verkeerde poort binnenkomt direct wegdonderen.
Een verkeerde poort is een poort waar verkeer, op grond van de afzender (die in de berichtenstroom staat), niet vandaan hoort te kunnen komen).
Daarmee is dit probleem opgelost. Dat hoeft echt geen 30 jaar te duren.
De aanval heeft niets met poortnummers te maken, maar met sequence numbers in de TCP header (aanvulling: zie offsets 4 en 8 in het "plaatje" in https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure).Een verkeerde poort is een poort waar verkeer, op grond van de afzender (die in de berichtenstroom staat), niet vandaan hoort te kunnen komen).
Daarmee is dit probleem opgelost. Dat hoeft echt geen 30 jaar te duren.
...
Ik bedoelde niet TCP poort nummers, maar de fysieke poorten op de switch of router.
Door Luc Gommans:
Door Anoniem: Ik kan me namelijk geen scenario voorstellen waarin een firewall (of zelfs maar een router) het toe laat dat er 100+ GB aan ongeldig verkeer van een bepaald IP-adres komt.
Ik denk dat je zult ondervinden dat vrijwel elk systeem dat prima binnenlaat. Maar stel je hebt een doelwit dat inderdaad actief reageert en 24/7 monitortIk weet niet wat voor firewall beheerder je daar aan denkt, maar ik heb gewoon standaard in al mijn firewalls een rule
staan dat als er binnen een bepaalde tijd teveel TCP sessies worden opgezet die niet established worden, dat source
adres automatisch voor een tijdje geblacklist wordt.
Tuurlijk kun je daarmee een DOS doen, maar dat is een gevolg van de wereldwijde laksheid bij internet providers en daar
komt wel een keer een eind aan als niemand meer diensten wil afleveren bij een provider die geen BCP38 doet.
Door Anoniem: Ja dit stelt duidelijk niks voor, alles wat daar staat is allang bekend en niet praktisch inzetbaar.
Echter feit blijft dat BCP38 moet worden ingevoerd. Providers die geen BCP38 doen moeten gewoon
een negatief stempel krijgen.
+1Echter feit blijft dat BCP38 moet worden ingevoerd. Providers die geen BCP38 doen moeten gewoon
een negatief stempel krijgen.
30-11-2015, 17:40 door
Overcome
Ik wist dat Phrack er ook ooit iets over had gepubliceerd, en zie hier:
http://phrack.org/issues/48/14.html
http://phrack.org/issues/48/14.html
Door Overcome: Ik wist dat Phrack er ook ooit iets over had gepubliceerd, en zie hier:
http://phrack.org/issues/48/14.html
http://phrack.org/issues/48/14.html
Er zijn tig hacker bladen en blogjes die iets over TCP spoofing gepubliceerd hebben.
Zo ook Phrack. Het Phrack artikel is een vrij algemene introductie (voor mensen die TCP niet zo goed kennen), en doet de aanname dat de sequence numbers voorspelbaar/herleidbaar zijn.
30-11-2015, 21:49 door
Erik van Straten
30-11-2015, 13:50 door Anoniem:
Neem als voorbeeld www.example.com. Domain validated betekent in de praktijk dat de rechthebbende eigenaar, maar dit kan ook een aanvaller zijn, op een specifiek moment toegang moet hebben tot een e-mail adres van iets dat lijkt op "admin" bij example.com om een geldig DV certificaat voor dat domein, of een subdomein daarvan, te kunnen krijgen.Door Erik van Straten: En tevens nog een reden om domain-validated en "Let's Encrypt" certificaten niet te vertrouwen.
Zou je dit willen toelichten? Waarom zou deze aanval die het versturen van gespoofte TCP-pakketen mogelijk maakt, ervoor zorgen dat DV certificaten ook maar iets minder te vertrouwen zijn dan het geval zou zijn zonder het bestaan van deze aanval?In elk geval de volgende aanvalsscenario's zijn denkbaar (het zouden er best meer kunnen zijn):
1) Het lukt de aanvaller om een e-mail account te maken bij example.com dat klinkt als "admin" (maar het zou me niet verbazen als bij sommige CSP's (Certificate Service Providers) dat "klinkt als" niet eens hoeft en elk account volstaat). Zie bijv. https://www.security.nl/posting/422488/XS4ALL-klant+krijgt+certificaat+xs4all_nl+via+e-mailverzoek.
2) De aanvaller weet toegang te krijgen tot de mailbox van maakt-niet-uit-welke-admin bij example.com. Mogelijk volstaat de mailbox van een willekeurige gebruiker bij example.com. Inbraken in mailboxes komen voor (voorbeeld:http://blogs.microsoft.com/cybertrust/2014/01/24/recent-phishing-attack-targets-select-microsoft-employees/), maar kennelijk realiseert niet iedereen zich (ook aanvallers niet) hoe eenvoudig je daarmee mogelijkerwijs ook DV certificaten zou kunnen aanvragen.
3) De aanvaller weet tijdelijk DNS MX-records te manipuleren zodanig dat hij alle mail voor example.com ontvangt. Mail waarin hij niet geïnteresseerd is, kan hij natuurlijk doorsturen (desgewenst geheel ongewijzigd) naar de echte mail-exchanger van example.com. Effectief is dit dus een MitM aanval tussen de CSP en een (al dan niet bestaande) e-mail inbox. Voor zover ik weet ook niet gebruikt om valse Lenovo certificaten aan te vragen, zie http://www.tripwire.com/state-of-security/security-data-protection/how-hackers-can-hijack-your-website-and-read-your-email-without-hacking-your-company/.
4) Een aanval met vergelijkbaar resultaat als 3 is denkbaar door route-tabellen (tijdelijk) te manipuleren waardoor e-mail van de CSP ook ergens anders terechtkomt dan zou moeten. Voorbeeld van BGP hijacking (voor zover ik weet niet misbruikt voor certificaataanvragen): https://www.security.nl/posting/441253/Koenders%3A+IP-adressen+ministerie+via+BGP-hijacking+gekaapt.
5) Als de aanval ontdekt door Luc Gommans et al. werkt, en je daarmee IP-adressen kunt spoofen, zou dit een aanvullende aanvalsmogelijkheid kunnen vormen.
Let's encrypt is vergelijkbaar en wellicht eenvoudiger uit te voeren, maar daar vroeg je niet naar.
30-11-2015, 22:13 door
Erik van Straten
30-11-2015, 14:32 door bbecko:
Klopt, TLS zit hoger in de stack.Door Erik van Straten: Nog een reden om zoveel mogelijk over te stappen op degelijk geauthenticeerde (en vervolgens versleutelde) verbindingen, zoals mogelijk met https.
En tevens nog een reden om domain-validated en "Let's Encrypt" certificaten niet te vertrouwen.
HTTPS ligt een laag hoger en heeft dus niks hiermee te maken. Het gaat hier om een verbinding maken, dus voordat er data verstuurd kan worden.En tevens nog een reden om domain-validated en "Let's Encrypt" certificaten niet te vertrouwen.
Maar bij juiste implementatie (en begrijpende gebruikers - wat, toegegeven, knap lastig is) van TLS elimineer je de onzekerheid over de serveridentiteit, onafhankelijk van alle onderliggende lagen (en, bij gebruik van een fully qualified domainname, ook van DNS).
Andersom: proberen het identiteitsprobleem op te lossen in de TCP laag (of daaronder: IP, ARP, Ethernet, cabling) is gedoemd te mislukken in de huidige setup.
30-11-2015, 22:22 door
Erik van Straten
30-11-2015, 15:48 door buttonius:
Ik bedoelde niet TCP poort nummers, maar de fysieke poorten op de switch of router.
Excuus, ik had beter moeten lezen!Door Erik van Straten:
...
Door buttonius: Elk serieus bedrijf en elke serieuze Internet provider zou haar switches en routers zo moeten instellen dat deze verkeer dat binnenkomt op een verkeerde poort binnenkomt direct wegdonderen.
Een verkeerde poort is een poort waar verkeer, op grond van de afzender (die in de berichtenstroom staat), niet vandaan hoort te kunnen komen).
Daarmee is dit probleem opgelost. Dat hoeft echt geen 30 jaar te duren.
De aanval heeft niets met poortnummers te maken, maar met sequence numbers in de TCP header (aanvulling: zie offsets 4 en 8 in het "plaatje" in https://en.wikipedia.org/wiki/Transmission_Control_Protocol#TCP_segment_structure).Een verkeerde poort is een poort waar verkeer, op grond van de afzender (die in de berichtenstroom staat), niet vandaan hoort te kunnen komen).
Daarmee is dit probleem opgelost. Dat hoeft echt geen 30 jaar te duren.
...
Ik bedoelde niet TCP poort nummers, maar de fysieke poorten op de switch of router.
Ik ben het absoluut met je eens dat er te weinig aan egress filtering wordt gedaan (droppen van pakketjes met zodanig vervalst IP afzenderadres dat het niet vanuit het achterliggende netwerk verzonden hoort te worden). Dat zou een hoop DDoS leed schelen!
Maar je lost er niet alle problemen mee op; in het voorbeeld in de blog van Luc Gommans zitten de IP adressen ongeveer naast elkaar.
30-11-2015, 23:12 door
Luc Gommans
Door Anoniem: Ik weet niet wat voor firewall beheerder je daar aan denkt, maar ik heb gewoon standaard in al mijn firewalls een rule
staan dat als er binnen een bepaalde tijd teveel TCP sessies worden opgezet die niet established worden, dat source
adres automatisch voor een tijdje geblacklist wordt.
Tuurlijk kun je daarmee een DOS doen, maar dat is een gevolg van de wereldwijde laksheid bij internet providers en daar
komt wel een keer een eind aan als niemand meer diensten wil afleveren bij een provider die geen BCP38 doet.
Die "feature" kende ik niet. Klinkt interessant, maar het is lang niet voor iedereen te doen door de DoS-mogelijkheid zoals je zelf ook zegt. Als Google.com dit zou implementeren komt er niemand meer op Google. Maar voor een thuissysteem of misschien mkb-website lijkt het inderdaad wel een mogelijke oplossing. Bedankt voor de tip!staan dat als er binnen een bepaalde tijd teveel TCP sessies worden opgezet die niet established worden, dat source
adres automatisch voor een tijdje geblacklist wordt.
Tuurlijk kun je daarmee een DOS doen, maar dat is een gevolg van de wereldwijde laksheid bij internet providers en daar
komt wel een keer een eind aan als niemand meer diensten wil afleveren bij een provider die geen BCP38 doet.
En zoals je zegt, BCP38 moet eindelijk eens overal geïmplementeerd worden. Ik heb even kort nagevraagd bij XS4ALL en KPN en zij implementeren het allebei wel (technische vragen aan KPN stellen is trouwens nagenoeg onmogelijk als niet-pers zijnde, het is dat ik toevallig iemand uit het security team ken...). Ik heb dit niet verder genoemd omdat ik dan alle ISP's in Nederland een gelijke kans had moeten geven om de vraag te beantwoorden en daarmee goed in het nieuws te komen. Ik zie wel redelijk veel Nederlandse leden bij MANRS, wat zich hier ook mee bezig houdt. Dat is ook al een goede stap.
Door Erik van Straten:
Gezien jouw reactie begijp ik de aanval niet goed. In http://lgms.nl/blog-2, onder "Proof of concept" zie ik het volgende (ik gebruik bewust het m.i. verwarrende woord "target" niet):
Alice: 192.168.36.17 is een SSH server (TCP poort 22)
Bob: 192.168.36.18 (doet niets, zijn identiteit / IP-adres wordt gespoofed)
Mallory: 192.168.36.11, stuurt pakketjes naar Alice met het IP-adres van Bob (192.168.36.18) als afzender
Helaas vertel je er niet bij waar je met Wireshark hebt opgenomen (ik vermoed op Alice).
De IP-adressen doen vermoeden dat alle hosts zich op 1 subnet bevinden. Ervan uitgaande dat je een switch gebruikt en geen hub, en er geen sprake is van ARP-spoofing aanvallen of aanvallen waardoor de switch als hub gaat werken, zal Mallory nooit TCP (unicast dus) pakketjes met antwoorden van Alice aan Bob ontvangen.
OK. Mallory stuurt een SYN pakketje, met als afzender Bob, naar Alice. Alice stuurt het antwoord naar Bob; Mallory ontvangt dit niet, waardoor Mallory geen idee heeft van het door Alice gekozen acknowledgement (sequence) nummer.
Laten we ervan uitgaan dat Bob uit staat en geen RST pakketjes terugstuurt.
Je laat zien dat Mallory vervolgens net zolang nummers gaat genereren totdat deze overeenkomen met wat Allice verwacht van Bob. Zodra dat lukt, stuurt Alice braaf een SSH header "terug" - naar Bob, opnieuw niet naar Mallory.
Hoe weet Mallory (die nooit antwoorden ontvangt) nu dat zij het juiste het juiste sequence nummer heeft geraden? En hoe kan zij de rest van de sessie kapen?
Gezien jouw reactie begijp ik de aanval niet goed. In http://lgms.nl/blog-2, onder "Proof of concept" zie ik het volgende (ik gebruik bewust het m.i. verwarrende woord "target" niet):
Alice: 192.168.36.17 is een SSH server (TCP poort 22)
Bob: 192.168.36.18 (doet niets, zijn identiteit / IP-adres wordt gespoofed)
Mallory: 192.168.36.11, stuurt pakketjes naar Alice met het IP-adres van Bob (192.168.36.18) als afzender
Helaas vertel je er niet bij waar je met Wireshark hebt opgenomen (ik vermoed op Alice).
De IP-adressen doen vermoeden dat alle hosts zich op 1 subnet bevinden. Ervan uitgaande dat je een switch gebruikt en geen hub, en er geen sprake is van ARP-spoofing aanvallen of aanvallen waardoor de switch als hub gaat werken, zal Mallory nooit TCP (unicast dus) pakketjes met antwoorden van Alice aan Bob ontvangen.
OK. Mallory stuurt een SYN pakketje, met als afzender Bob, naar Alice. Alice stuurt het antwoord naar Bob; Mallory ontvangt dit niet, waardoor Mallory geen idee heeft van het door Alice gekozen acknowledgement (sequence) nummer.
Laten we ervan uitgaan dat Bob uit staat en geen RST pakketjes terugstuurt.
Je laat zien dat Mallory vervolgens net zolang nummers gaat genereren totdat deze overeenkomen met wat Allice verwacht van Bob. Zodra dat lukt, stuurt Alice braaf een SSH header "terug" - naar Bob, opnieuw niet naar Mallory.
Hoe weet Mallory (die nooit antwoorden ontvangt) nu dat zij het juiste het juiste sequence nummer heeft geraden? En hoe kan zij de rest van de sessie kapen?
"Helaas vertel je er niet bij waar je met Wireshark hebt opgenomen (ik vermoed op Alice)." Klopt, in dit voorbeeld is vanuit Alice gecaptured. Ik zet het erbij!
"Hoe weet Mallory dat ze het goede heeft geraden en hoe kan de rest van de sessie gekaapt worden?" Niet, dat is inderdaad een limitatie hier. Tenzij het op een bepaalde manier zichtbaar is, bijvoorbeeld als je een commando uitvoert dat de database dropt (random voorbeeld) wat op de site dan zichtbaar is, kun je niet weten wanneer het geslaagd is. Net als met bijvoorbeeld een CSRF is het een blinde aanval.
Door Erik van Straten:
Ik ben het absoluut met je eens dat er te weinig aan egress filtering wordt gedaan (droppen van pakketjes met zodanig vervalst IP afzenderadres dat het niet vanuit het achterliggende netwerk verzonden hoort te worden). Dat zou een hoop DDoS leed schelen!
Maar je lost er niet alle problemen mee op; in het voorbeeld in de blog van Luc Gommans zitten de IP adressen ongeveer naast elkaar.
Nou zijn die wel in een privénetwerk, daar is het ook logisch dat ze vrijwel naast elkaar liggen. In het echt zou je dan dezelfde ISP moeten zitten en geluk hebben dat ze binnen het subnet niet ook filtering doen. Bijvoorbeeld van XS4ALL weet ik dat ik zelfs mijn buurman niet kan bereiken met een gespoofd bericht, dat is heel veilig dus. (Andere providers heb ik die vraag niet specifiek gesteld, dus of XS4ALL de enige is weet ik niet.)Ik ben het absoluut met je eens dat er te weinig aan egress filtering wordt gedaan (droppen van pakketjes met zodanig vervalst IP afzenderadres dat het niet vanuit het achterliggende netwerk verzonden hoort te worden). Dat zou een hoop DDoS leed schelen!
Maar je lost er niet alle problemen mee op; in het voorbeeld in de blog van Luc Gommans zitten de IP adressen ongeveer naast elkaar.
Maar momenteel zijn er genoeg providers die het niet filteren... en eigenlijk blijft de aanval ook wel relevant tot de laatste ISP op aarde het implementeert. Je kan het altijd spoofen vanaf die laatste ISP, dus de ontvanger is dan nog altijd in het donker.
------
Ik denk dat ik zo alle comments heb gehad. Ik kijk nog wel eens globaal of er nieuwe, directe vragen zijn, maar ik refresh niet 24/7 de pagina. Mocht iemand een vraag aan ons (of mij persoonlijk) hebben, dan is de meest directe communicatiemethode Twitter of e-mail. Zie hiervoor mijn website: http://lgms.nl
01-12-2015, 07:32 door
Erik van Straten
30-11-2015, 23:12 door Luc Gommans: "Hoe weet Mallory dat ze het goede heeft geraden en hoe kan de rest van de sessie gekaapt worden?" Niet, dat is inderdaad een limitatie hier. Tenzij het op een bepaalde manier zichtbaar is, bijvoorbeeld als je een commando uitvoert dat de database dropt (random voorbeeld) wat op de site dan zichtbaar is, kun je niet weten wanneer het geslaagd is. Net als met bijvoorbeeld een CSRF is het een blinde aanval.
OK, maar kun je dan een concreet voorbeeld geven van een aanval waarbij iemand tot nu toe onbekende risico's loopt?Of moeten we de resultaten van jullie onderzoek zien als iets waarop een andere aanval wellicht op verder zou kunnen bouwen?
Geef die mannen eens het boek "TCP/IP illustrated" cadeau, want dit is een issue dat reeds gekend was bij het design van het TCP protocol..
In de praktijk werkt een dergelijke brute force aanval touwens ook niet omdat men zoiets als firewalls gebruikt.
Een goed geconfigureerde firewall houd een sessionsate bij en geen pakketten door met foute sequence nummers.
In de praktijk werkt een dergelijke brute force aanval touwens ook niet omdat men zoiets als firewalls gebruikt.
Een goed geconfigureerde firewall houd een sessionsate bij en geen pakketten door met foute sequence nummers.
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
