<--  | Home  | Map  | Index  | Zoek

door Eric Detoisien <valgasu(at)club-internet.fr> Over de auteur: Eric Detoisien is een expert in computer beveiliging. Dol als hij is om alles dat te maken heeft met beveiliging, is hij een van de experts van de rstack groep - www.rstack.org - Vertaald naar het Nederlands door: GH Snijders <ghs(at)linuxfocus.org> Inhoud: Fragment Aanvallen Tiny Fragments Fragment Overlapping IP Spoofing TCP Session Hijacking ARP Spoofing DNS Spoofing DNS ID Spoofing DNS Cache Poisoning Het configuratie probleem Bugs Buffer overflow Scripts Man in the Middle Applicatie denial of service Netwerk denial of service SYN Flooding UDP Flooding Packet Fragment Smurfing Distributed denial of service Conclusie Links Talkback voor dit artikel

Externe aanvallen Kort: Dit artikel werd voor het eerst gepubliceerd in een speciale editie van Linux Magazin Frankrijk, gefocust op beveiliging. De redacteur en de autheurs waren zo vriendelijk om LinuxFocus toe te staan om ieder artikel uit deze speciale uitgave te publiceren. Aansluitend, zal LinuxFocus deze presenteren zodra de vertaling naar het Engels gereed is. Met dank aan alle mensen die betrokken zijn bij dit werk. Deze abstract zal gereproduceerd worden voor artikelen van dezelfde oorsprong. Dit artikel laat verschillende externe aanvallen zien, die een cracker kan gebruiken tegen machines in een netwerk. We zullen de aanval op het netwerk zelf bespreken, een paar aanvallen op applicaties en de Denial Of Service aanvallen. _________________ _________________ _________________

Netwerk aanvallen

De netwerk aanvallen berusten op zwakheden die direct gerelateerd zijn aan de protollen of de implementatie ervan. Er bestaan er vele. Echter, de meeste zijn varianten van de vijf goed bekende netwerk aanvallen.

Fragment Aanvallen

Tiny Fragments

Volgens RFC (Request For Comment, vraag om commentaar) 791 (IP), moeten alle Internet nodes (routers) in staat zijn om pakketten van minimaal 68 bytes te transporteren, zonder deze te fragmenteren (op te delen). De minimale grootte van een IP pakket is 20 bytes, zonder opties. Als er opties aanwezig zijn, bedraagt de maximale grootte 60 bytes. Het IHL (Internet Header Length ) bevat de lengte van het pakket in 32 bit woorden. Dit veld gebruikt 4 bit, het aantal mogelijke waarden is dus 2^4 - 1 = 15 (de waarde 0000 is niet toegestaan). Tenslotte, het Fragment Offset veld, welke het begin van de eerste byte van het fragment, in verhouding tot het volledige datagram, aangeeft, is 8 bytes blocks groot. Een data fragment bevat dus minimaal 8 bytes. Dit maakt samen echt 68 bytes.

De aanval bestaat uit het opzetten van een TCP connectie, verdeeld over 2 IP pakketten (gefragmenteerd). Het eerste IP pakket van 68 bytes bevat alleen de eerste 8 bytes van de TCP header (bron en doel poorten en volgorde nummer). De data in het tweede IP pakket bevat dan het TCP connectie verzoek (SYN flag is 1, ACK flag is 0).

Echter, IP filters passen dezelfde regel toe aan alle fragmenten in een pakket. Het filter van het eerste fragment (Fragment Offset = 0) definieert de regel, waarop deze ook wordt toegepast op de andere fragmenten (Fragment Offset = 1) zonder enige andere controle. Dus, wanneer gedefragmenteerd op IP niveau van de doel machine, wordt het verbindings verzoek opnieuw opgebouwd en doorgegeven aan de TCP laag. De verbinding wordt opgezet, ondanks het IP filter ertussen, welke dit had moeten tegenhouden.

Afbeelding 1 en 2 laten beide fragmenten zien en afbeelding 3 laat het gedefragmenteerde pakket op de doelmachine zien:

Afb.1: Fragment 1

Afb.2: Fragment 2

Afb.3: Gedefragmenteerd pakket

Fragment Overlapping

Nog steeds aan de hand van RFC 791 (IP), als twee IP fragmenten overlappen, zal de tweede de eerste overschrijfen. De aanval bestaat uit het verdelen van een IP pakket in twee fragmenten. Het IP filter accepteerd de eerste, welke 68 bytes bevat (zie Tiny Fragments) en daar het geen TCP connectie verzoek bevat (SYN = 0, ACK = 0). Wederom zal deze regel ook worden toegepast aan de volgende fragmenten. Het tweede pakket (Fragment Offset = 1) bevat het echte verbindings verzoek, en wordt geaccepteerd door het IP filter omdat deze niet ziet dat hier een verbinding wordt opgezet. Dus, tijdens het defragmenteren zal de data van het tweede fragment de data van de eerste overschrijven, te beginnen na de 8ste byte (de Fragment Offset = 1). Het opnieuw geassembleerde pakket is dan een geldig verbindings verzoek voor de doelmachine. De connectie wordt opgezet ondanks het IP filter ertussen.

Afbeeldingen 1 en 2 geven beide fragmenten weer en afbeelding 3 laat het gedefragmenteerde pakket op de doel machine zien:

Afb.4: Fragment 1

Afb.5: Fragment 2

Afb.6: Gedefragmenteerd pakket

IP Spoofing

Het doel van deze aanval is om het IP adres van een machine over te nemen. Dit stelt de cracker in staat om ofwel de oorsprong van zijn aanval te verbergen (gebruikt id Denial Of Service aanvallen) of om gebruik te maken van een vertrouwens relatie tussen twee machines. Hier zullen we het tweede gebruik van IP Spoofing bekijken.

Het principe van de aanval bestaat, voor de cracker, uit het vervalsen van zijn eigen IP pakketten (met programma's als hping2 of nemesis in welke hij, onder andere, het bron IP zal veranderen. IP Spoofing wordt ook vaak Blind Spoofing genoemd. De antwoorden van de valse pakketten gaan niet naar de machine van de cracker, daar het bron adres is aangepast. Dus gaan ze naar de gespoofde machine. Er bestaan echter twee methodes om toch antwoorden terug te krijgen:

1. Source Routing: Het IP protocol kent een optie genaamd Source Routing (bron omleiding) welke je in staat stelt aan te geven, welke route de IP pakketten zouden moeten nemen. Deze route bestaat uit een serie IP adressen die de pakketten dienen te volgen. Voor de cracker is het voldoende om een route aan te geven die langs een router gaat die onder zijn controle staat. Tegenwoording verwerpen de meeste TCP/IP stack implementaties deze optie;
2. Re-routing: router tabellen die gebruik maken van het RIP protocol kunnen veranderd worden door ze RIP pakketten te sturen met nieuwe routing informatie. Dit wordt gedaan om de pakketten om te leiden naar een router die de cracker controleerd.

Blind Spoofing wordt gebruikt tegen services als rlogin of rsh. Het authenticatie mechanisme van deze services kijkt alleen maar naat het bron IP adres van de client machine. Deze redelijk bekende aanval (Kevin Mitnick gebruikte het tegen Tsutomu Shimomura's machine in 1994) vereist een paar stappen:

• het IP adres vinden van een vertrouwde machine door, bijvoorbeeld showmount -e welke laat zien waar de bestandssystemen worden geëxporteerd, of rpcinfo welke meer informatie geeft;
• de vertrouwde host verstoren met een SYN Flooding, bijvoorbeeld (straks meer over Denial Of Service). Dit is van belang om te voorkomen dat de machine antwoorden verstuurd op de pakketten die verstuurd worden door de doel server. Anders zou deze proberen TCP RST pakketten te sturen welke de verbindingspogingen zouden afbreken;
• voorspellen van TCP volgorde nummers: ieder TCP pakket wordt geaccosieerd met een initieel volgorde nummer. De OS TCP/IP stack genereerd deze op een lineare manier, afhankelijk van de tijd random (willekeurig) of pseudo-random, afhankelijk van de gebruikte systemen. De cracker kan alleen systemen aanvallen die voorspelbare volnummers genereren (linieer of tijd-gebaseerd);
• tde aanval bestaat uit het openen van een TCP connectie op de gewilde poort (rsh bijvoorbeeld). Voor een beter begrip zullen we ter herinnering even kijken naar het openings mechanisme van een TCP connectie. Dit gebeurt in drie stappen (TCP Three Way Handshake):
  1. de vrager stuurt een pakket met de TCP SYN flag en een x volgnummer naar de doelmachine;
  2. het doel antwoordt met een pakket met de TCP SYN flag en de ACK flag (met een X=1 bevestigings nummer) geactiveerd. Het volgnummer is y;
  3. de vrager stuurd een pakket met de TCP ACK flag (met een y+1 bevestigingsnummer) terug naar de doelmachine.

De cracker gebruikt de machine A, terwijl C de vertrouwde machine voorsteld. De A(C) aanduiding betekend dat het pakket is verstuurd vanaf A met het gespoofde IP adres van C. Opmerking: er bestaat een programma met de naam mendax welke deze IP Spoofing mechanismes iplementeerd.

TCP Session Hijacking

TCP Session Hijacking (letterlijk: het kapen van een TCP sessie), staat de cracker toe om een TCP stroom om te leiden. Hiermee kan een cracker een wachtwoord bescherming (zoals in telnet of ftp) omzeilen. De noodzaak van luisteren (sniffen) beperkt deze aanval tot het fysieke netwerk van het doelwit. Alvorens de details te bespreken, zullen we eerst de basis principes van het TCP protocol toelichten.

We zullen hier niet het mystery van het TCP protocol uit de doeken doen, maar ons concentreren op de belangrijkste punten, om deze aanval te begrijpen. De TCP header bevat verschillende velden:

• de bron en de doel poort, waarmee de connectie tussen twee machines wordt geïdentificeert;
• het volgnummer dat iedere verzonden byte aangeeft;
• het bevestigings (ACK) nummer, corresponderend met de laatst ontvangen byte;
• de interessante flags zijn:
  • SYN, welke de volgnummers synchroniseerd zodra er een verbinding wordt opgezet;
  • ACK, de bevestigings (acknowledgement) flag van een TCP segment;
  • PSH, welke de ontvanger verteld de data door te sturen naar de applicatie.

Afbeelding 8 laat zien hoe het opzetten van een TCP connectie
Afb.8: Three Way Handshake

Hier, startte machine A een TCP connectie met machine B.
Afbeelding 9 geeft een doorvoer van TCP data weer:

De volgnummers zullen veranderen met het aantal verzonden bytes aan data. Het volgnummer wordt aangeduid met Seq(sequentie), het bevestigingsnummer (ACK) kan gevonden worden na de PSH en ACK flags en het aantal verzonden data bytes staat tussen haakjes.

Deze aanval veroorzaakt een staat van desynchronisatie aan beide kanten van de TCP connectie, en maakt het zo mogelijk om de verbinding te kapen. Een connectie raakt gedesynchroniseerd als het volgnummer van de volgende verzonden byte van de A machine afwijkt van het volgnummer van de volgende byte, te ontvangen door B. Andersom ook.

In het voobeeld van afbeelding 9, aan het eind van de eerste stap, al s B z'n pakket ontvangt, wacht A op een pakket met een bevestigings nummer van x+60. Als het volgende pakket dat door B wordt verstuurd, niet dit volgummer bevat, worden A en B beschouwd als gedesynchroniseerd.

Dus, een cracker met machine C wil een opgezette Telnet sessie tussen A en B kapen. Eerst luisterd C het telnet verkeer (TCP poort 23) tussen A en B af. Als de cracker denkt dat A de tijd heeft gehad om zich te authenticeren bij de Telnet service op de B machine, desynchroniseerd hij de A machine tegen B. Om dit te doen, creëert hij een pakket met het bron IP adres van A en het TCP bevestigingsnummer dat door B wordt verwacht, wat door de B wordt geaccepteerd. Behalve het verstoren van de TCP verbinding, stelt dit de cracker in staat een commando te injecteren in de telnet sessie die was gestart door A. In feite is dit pakket in staat om data te vervoeren (PSH flag = 1).

Afbeelding 10 geeft deze aanval weer:
Afb.10: TCP Session Hijacking

De B machine accepteerd het commando, verstuurd door C, en bevestigt dit door een pakket naar A te sturen met de ACK flag. Ondertussen, als A een pakket stuurd naar B, wordt het afgewezen omdat het volgnummer afwijkt van degene die door B wordt verwacht.

Een probleem dat vervolgens optreedt: de Ack Storm. Er worden zeer veel ACKs gegenereerd. Dit gebeurd als A een TCP pakket stuurd met een ongeldig volgnummer (A is immers gedesynchroniseerd), B wijst het af en stuurt A een ACK met het volgnummer dat het verwacht. A ontvangt deze ACK, en daar het volgnummer niet klopt met degene die werd verwacht, stuurt hij ook een ACK naar B en B doet het nog eens...

Dit ACK Storm probleem kan worden opgelost als de cracker gebruik maakt van ARP Spoofing. In dat geval, zal de C machine de ARP cache van B vergiftigen, door deze wijs te maken dat het IP adres van A nu bij het MAC adres van C hoord. Deze technieken worden geïmplementeerd door het hunt programma.

ARP Spoofing

Deze aanval, die ook wel ARP Redirect (ARP omleiding) wordt genoemd, leidt het netwerk verkeer van een of meerdere machines naar de machine van de cracker. Het wordt gedaan op het fysieke netwerk van de slachtoffers. Laten we eens kijken hoe wat het ARP protocol ook al weer was en hoe het werkt.

Het ARP protocol (Address Resolution Protocol) implementeerd het resolutie mechanisme om een IP adres te vertalen naar een Ethernet MAC adres. Netwerk apparatuur communiceerd door het uitwisselen van Ethernet frames (in een Ethernet netwerk, uiteraard), op de datalink laag. Om in staat te zijn om deze informatie te delen, is het nodig dat de netwerk kaarten over een uniek Ethernet adres beschikken: dit is het MAC adres (MAC=Media Access Control).

Zodra er een IP pakket wordt verstuurd, dient de zender het MAC adres van de ontvanger te weten. Om het te krijgen, wordt er een broadcast ARP verzoek vestuurd naar alle machines in het lokale netwerk. Dit verzoek vraagt: "Wat is het MAC adres dat bij dit IP adres hoort?". De machine met dit IP adres antwoordt met een ARP pakket, en vertelt de zender zo het gevraagde MAC adres. Vanaf dat punt weet de zender het MAC adres dat bij het IP adres hoort, waarnaar pakketten verzonden moeten worden. Deze wetenschap wordt een tijdje in een cache (buffer) opgeslagen (om verzoeken te voorkomen, iedere keer dat er een IP pakket wordt verstuurd).

Deze aanval vergiftigd de cache van de doelmachine. De cracker verstuurd ARP antwoorden naar de doel machine, om deze te vertellen dat het nieuwe MAC adres er een is die overeenkomt met een gateway (bijvoorbeeld) IP adres naar het adres van de cracker. De machine van de cracker zal vervolgens al het verkeer ontvangen dat verstuurd wordt naar de gateway. Zo is het dus voldoende voor hem om naar het verkeer te luisteren (en/of aan te passen). Daarna zal hij de pakketten doorsturen naar de echte bestemming, zodat niemand de verandering opmerkt.

ARP Spoofing is bruikbaar als een lokaal netwerk gebruik maakt van switches. Deze sturen de Ethernet farmes naar verschillende poorten (kabels), aansluitend met het MAC adres. Een sniffer kan in zo'n geval nauwelijks frames opvangen, voorbij z'n eigen kabel. Zo staat ARP Spoofing toe om te luisteren naar het verkeer tussen twee machines die zich op verschillende poorten bevinden.

Om een ARP Spoofing aanval te implementeren, kan een cracker gebruik maken van een pakket generator zoals ARPSpoof of nemesis. Voorbeeld: de "slachtoffer" machine (10.0.0.171), z'n default gateway (10.0.0.1) en de machine van de cracker (10.0.0.227). Voor de aanval is het resultaat van een traceroute:

[root@cible -> ~]$ traceroute 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 40 byte packets
 1  10.0.0.1  (10.0.0.1)  1.218 ms  1.061 ms  0.849 ms

En de ARP cache van de doel machine is:

[root@cible -> ~]$ arp
Address     HWtype  HWAddress       Flags Mask  Iface
10.0.0.1    ether   00:b0:c2:88:de:65   C       eth0
10.0.0.227  ether   00:00:86:35:c9:3f   C       eth0

De cracker gebruikt dan ARPSpoof:

[root@pirate -> ~]$ arpspoof -t 10.0.0.171 10.0.0.1
0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f
0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f
0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f
0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f
0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f
0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f
0:0:86:35:c9:3f 0:60:8:de:64:f0 0806 42: arp reply 10.0.0.1 is-at 0:0:86:35:c9:3f

De verzonden pakketten zijn ARP pakketten die de ARP cache van de 10.0.0.171 machine vergiftigen met een ARP Reply (antwoord) welke zeggen dat het MAC adres dat hoort bij 10.0.0.1 nu 00:00:86:35:c9:3f is.

De ARP cache van de 10.0.0.171 machine wordt:

[root@cible -> ~]$ arp
Address     HWtype  HWAddress       Flags Mask  Iface
10.0.0.1    ether   00:00:86:35:c9:3f   C       eth0
10.0.0.227  ether   00:00:86:35:c9:3f   C       eth0

Om te controleren dat het verkeer nu via de 10.0.0.227 machine loopt, is het voldoende om een nieuwe traceroute uit te voeren op de 10.0.0.1 gateway:

[root@cible -> ~]$ traceroute 10.0.0.1
traceroute to 10.0.0.1 (10.0.0.1), 30 hops max, 40 byte packets
 1  10.0.0.227  (10.0.0.227)  1.712 ms  1.465 ms  1.501 ms
 2  10.0.0.1  (10.0.0.1)  2.238 ms  2.121 ms  2.169 ms