Dus dit is iets zoals een stun-server maar dan zonder poort forwarding?

Is dit ook niet gewoon mogelijk met ssh tunneling?

Nice find. Bijzonder, en ontbrekend in bovenstaande tekst: in tegenstelling tot bij Skype is er geen third party server nodig!

Eng is wel dat malwaremakers dit snel zullen oppakken voor hun botnetpraktijken. Als echt alle NAT routers ICMP time exceeded pakketjes zo afhandelen als beschreven kunnen gecompromitteerde PC's onderling eenvoudig communiceren.

Dit gaat niet werken met een goede stateful firewall zoals OpenBSD. Het is udp gebaseerd (staat hier iig dicht) en maakt gebruik van firewall piercing technieken die er van uitgaan dat udp pakketten van binnen naar buiten mogen en dat er dan een antwoord (zonder check op originating ip) door mag. In andere woorden: geen goede stateful filtering is een vereiste.

Het verhaal is overigens toch al te kort door de bocht: "Any unprivileged user can set UDP source and dest ports." Niet geheel juist, poorten onder de 1024 zijn ook voor udp priviledged, dus alleen root mag die openen.

Niets nieuws onder de zon, doorlopen, er is niets te zien hier. :)

EJ

Nee, maar je moet _wel_ het _ip adres_ van de server weten. Duh. ;-) Handig hoor, dat je ook geen dns nodig hebt. De centrale server bij skype is alleen nodig (te kort door de bocht, ik weet het) om niet op te hoeven geven met welk ip adres je wilt kletsen, dat wordt op de skype server bijgehouden. Hier moet je dat dus allemaal zelf regelen. Leve de vooruitgang.

EJ

Er is niemand die zegt dat je geen DNS mag gebruiken.

Met de door Samy beschreven techniek is het mogelijk om elke thuis-PC (of bedrijfs-PC), ook achter NAT, als server malware te laten hosten. M.b.v. fast-flux technieken (zie http://en.wikipedia.org/wiki/Fast_flux) kunnen internet-hufters zo een nauwelijks te bestrijden "server" netwerk bouwen. Doodeng.

Even een vraag aan jouw Bitwiper: wat gebeurt er als er achter de NAT nog een netwerkfirewall op je systeem zit? Gaat deze grap dan nog op?

Een port listening zetten dan heb je gelijk. Dit gaat echter over het maken en verzenden van UDP packetjes. En dat kan en mag iedereen.

Dit is helemaal niets nieuws. _Dat_ is mijn punt. Zoek maar eens op firewall piercing technieken. Bovendien is het appje alleen maar beschikbaar voor linux en Mac OSX. Je komt met netcat al een heel eind, even scriptje er om heen en klaar ben je. Echt absoluut niets bijzonders.

Volgens mij is de combinatie met fast flux netwerken ook al niet bijzonder. Denk niet dat de technieken van bijvoorbeeld conficker erg afwijken van dit proces.

Tenslotte blijf ik bij mijn stelling dat een beetje firewall dit erg goed en erg hard tegenhoudt.

EJ

een tool downloaden van een hacker, lijkt mij ook iets wat ik zou doen, duh

Overigens is dit weer eens een bewijs dat NAT geen firewall is. Nooit geweest ook.

EJ

Ik was even verbaasd dat zoiets bij NAT nodig is. Maar er wordt hier PAT bedoeld en niet NAT.

Even voor degenen die het nog niet weten:
NAT is Network Address Translation.
Een intern IP adres wordt 1-op-1 vertaald naar een vast extern IP adres. Dit wordt meestal gebruikt voor netwerken waarbij het externe adres nog wel eens wijzigt. Bijvoorbeeld een wat groter bedrijf dat meer aansluitingen heeft. Iedere aansluiting met voldoende IP adressen om alle interne adressen mee te nemen. Maar vanwege redundantie doet men dat niet. En ja, daar kun je ook BGP o.i.d. voor gebruiken. Maar niet iedereen kan daar goed mee overweg.

PAT is Port Address Translation, oftewel IPmasquarade. Hierbij wordt een intern IP adres vertaald naar het ene externe IP adres en wijzigt het externe poort adres. De PAT-gateway houdt bij welke poort bij welke internet IP/port combinatie hoort. Dit is midden 90'er jaren ontwikkeld voor Linux t.b.v. mensen die meer dan 1 machine aan wilde sluiten op hun kabel- of adsl-aansluiting. Juist dat soort aansluitingen bood in die tijd geen mogelijkheid voor meer dan 1 IP adres.

NAT is simpel. Voor PAT moet veel meer gedaan worden om een en ander goed te kunnen laten draaien.

Peter

Nee een ssh tunnel vereist configuratie op je NAT router (port forwarding)

Je hoeft het tooltje niet te downloaden. Hij heeft ook de source code beschikbaar gesteld !

Conficker gebruikt over het algemeen een pull mechanisme om updates binnen te halen van een server. Gebruikmakend van deze techniek kan je hier een push mechanisme van maken, dat altijd werkt ook al draait de client achter een NAT. Dit push mechanisme heeft zelfs geen server nodig want elke geinfecteerde client kan een andere geinfecteerde client tot upgrade dwingen. Met andere woorden een Command and Control server is niet meer nodig. Resultaat een onuitroeibaar botnet.

Ik denk niet dat je het helemaal goed gelezen hebt. In eerste instantie wordt er verkeer naar een willekeurig IP-adres (3.3.3.3) gestuurd om het IP-adres van de NAT-gateway te achterhalen. Daarna wordt er verkeer gestuurd naar de uiteindelijk bedoelde ontvanger. Dit zou dus ook - als je verder geen UDP van binnen naar buiten filtert - op OpenBSD werken.

Ik denk dat het handig is als ik uitleg hoe Samy's pwnat werkt (ik hoop dat ik het goed begrepen heb, correct me if I'm wrong).

Het doel is om een verbinding vanaf een client naar een server op te zetten waarbij:
1. die server wenst dat een of meer clients verbinding met hem maken (deze moet voortdurend "uitnodigingen" verzenden)
2. de server achter een gangbare thuisrouter met PAT zit (ik ga de -off topic- NAT/PAT discussie maar even uit de weg)
3. het publieke IP adres van die PAT router bekend is (eventueel via DNS)
4. er niets bekend is van de client, ook geen IP-adres (elke client, ook achter een PAT router, kan verbinding maken)

De punten 1. en 2. betekent dat we te maken hebben met:
- ofwel een legitieme situatie (bijv. een simpele gebruiker die niet weet hoe je in een PAT router een "server" definieert)
- ofwel met de situatie dat iemand binnen een bedrijf een server wil draaien zonder toestemming van netwerkbeheer
- ofwel dat de PC pwned is door een kwaadwillende

Samy gebruikt een tweetraps proces (ik heb nog niemand deze twee trucs zien combineren, als dit al bekend was dan graag pointers naar concrete beschrijvingen daarvan):

(A) De server moet te weten zien te komen welke client (welk publiek IP-adres) verbinding met hem probeert te maken. Samy maakt hierbij gebruik van een bekende doch "by design" kwetsbaarheid in PAT (en NAT) routers die het mogelijk maakt om ICMP time exceeded packets afkomstig van "routers onderweg" (richting bestemming) door te sturen naar de zendende host.

Uitleg TTL (Time To Live) en het ICMP time exceeded pakket: om loops te voorkomen zit in elk IP pakket een "Time To Live" veld dat gewoon een tellertje is, en bij verzenden bijv. op 64 gezet wordt: elke router onderweg verlaagt dit tellertje. Als het tellertje de waarde 0 krijgt zal het pakket niet verder worden doorgestuurd; in plaats daarvan wordt er dan, door die laatste router, een "ICMP time exceeded" pakketje teruggestuurd. In dat pakketje zal die router als "payload" (bagage) het begin van het oorspronkelijke pakketje meesturen zodat de zendende host kan herleiden om welk pakket het ging. Zie ook http://en.wikipedia.org/wiki/ICMP_Time_Exceeded.

Hoewel PAT routers normaal gesproken "antwoorden" van onbekende IP-adressen zullen droppen, bevatten ze juist extra functionaliteit om ICMP time exceeded pakketjes door te laten. Daarbij maken PAT routers gebruik van de payload (het begin van het oorspronkelijk verzonden pakket) om te herleiden naar welke LAN PC het ICMP antwoordpakket toe moet (daarbij word ook in de payload het oorsponkelijke zendende adres terugvertaald).

Samy laat de "server" voortdurend pakketjes versturen naar een zwart gat, maar wel door de PAT router heen; daardoor kan die PAT router ICMP time exceeded pakketjes verwachten. Doordat Samy die verzonden pakketjes van een voorspelbaar begin voorziet, kan een willekeurige client ICMP time exceeded messages met dat begin naar de PAT router sturen, die ze als legitiem zal accepteren en zal doorzetten naar de server. Daarmee komt de server het IP-adres van de client te weten.

(B) In stap 2 wordt er een UDP sessie tussen de client en de server opgezet. Als zowel de client als de server achter PAT zitten, is daar Samy's chownat truc bij nodig. Zo'n UDP "verbinding" opzetten via 2 PAT routers is mogelijk als de machines elkaars IP-adres kennen en van afgesproken poortnummers gebruik maken.

Terug naar de vraag van Peter V: het gaat hier om een "aanval" waarbij zowel op de client als op de server iemand al de mogelijkheid heeft om pakketjes te versturen en te ontvangen. Tenzij je dat zelf wilt (bijv. voor een serverless Skype-achtig of file-sharing protocol) zal er sprake moeten zijn van een kwaadwillende met lokale of remote toegang tot jouw PC. Het is de vraag wat een personal firewall dan nog kan uitrichten.

Als jouw PC niet gecompromitteerd is en er geen kwaadwillenden zijn met fysieke toegang tot jouw PC hoef je je geen zorgen te maken achter jouw PAT router (in elk geval niet voor jouw PC, wellicht wel voor de staat van het Internet).

Deze techniek is geen aanvalscode. Een aanvaller kan immers wel ICMP time exceeded pakketjes naar een NAT sturen maar er moet wel een server applicatie achter die NAT draaien die weer terug antwoord geeft naar de client anders zal er weinig gebeuren. Het wordt voor een aanvaller pas interessant als er meerdere al geinfecteerde computers (een botnet) van deze techniek gebruik gaan maken. Deze bots kunnen dan direct met elkaar communiceren, ondanks dat ze achter een NAT verstopt zitten.

Niet altijd.
Ik heb een linux machine als (NAT-)router/firewall draaien en daarop draait ook een SSH server.
Als ik vanaf m'n werk dus een SSH sessie op zet naar mijn SSH server thuis, kan ik daar doorheen tunnelen naar systemen op mijn LAN. Portforwarding is dan niet nodig.

Ze leren het ook nooit hè. XD
Men haalt al die netwerk-dingen door elkaar. (en dan nog kijken ze je met een gezicht aan van; ga jij ff koffie halen of zo, maar zeik niet zo)

Je kent vast de betekenis van symantec; -- komt hier wat om de hoek kijken; -- ik kan het niet meer bewiizen, ik kan het gewoon even niet vinden, - de kloof tussen weten en niet weten;;