Juletip 2: Ethernet og ARP

Ups, jeg var lige ved at glemme julekalenderen!

Ethernet

Når vi snakker netværk idag er det typisk TCP/IP protokollerne - som er dem der bruges på internet. Tidligere da jeg begyndte at arbejde med netværk var der andre ting som IPX og NetBEUI. Når vi så bruger TCP/IP, dvs IP protokollerne på vores netværk er det ofte ved hjælp af Ethernet og de mange varianter af Ethernet som findes.

Så lad os starte fra grunden, helt nede ved de hardwarenære protokoller som Ethernet, Address Resolution Protocol (ARP) og se hvad vi finder.

Fra Wikipedia artiklen finder vi den formelle beskrivelse af Ethernet følgende tabel:

Kilde: Wikipedia artiklen

og med Wireshark kan det se sådan ud:

På dette screendump kan man ligeledes se nogle yderligere informationer, som jeg vil gennemgå:

• Modtager for den valgte (pakken er markeret med mørkeblå) er broadcast adressen ff:ff:ff:ff:ff:ff - MAC destination
• Afsender adressen på min laptop 00:23:6c:9a:f5:2c - MAC source
• Typen er ARP med værdien 0x0806 - Ethertype fra Wikipedia artiklen refereret ovenfor

Ethernet er altså dejligt simpelt, der er et fast format, afsender, modtager og en type - punktum super og nemt :-) (Specielt hvis vi her kun tænker på det vi ser med Wireshark fra Ethernet niveauet og glemmer alt med de fysiske signaler, preamble og intergap osv.).

Address Resolution Protocol

Hvad er det så jeg har opsamlet?
Det vi ser på billedet er den første ARP pakke som min laptop sender ud på nettet for at finde en MAC adresse på en anden maskine. Denne første pakke sendes i broadcast, altså til alle - men med min laptops MAC adresse som afsender. Den næste pakke, pakke nr. 23 i Wireshark sendes derfor direkte fra systemet med den pågældende IP-adresse tilbage til min laptop. Årsagen? den er såmænd blot at jeg ville bruge Ping programmet til at sende pakker til en maskine turbi med IP adressen 10.0.42.44 henover noget Ethernet, men da en switch arbejder med MAC adresser skal jeg altså finde MAC adressen før jeg kan sende IP pakkerne.

Før ARP pakkerne er sendt kan de to systemer ikke sende data over Ethernet, men efter ARP pakkerne kan de fint sende Ethernet pakker til hinanden, og har følgende ARP tabeller:

Bigfoot - min laptop

hlk@bigfoot:hlk$ arp -an 
? (10.0.42.1) at 0:0:24:c8:b2:4c on en1 ifscope [ethernet]
? (10.0.42.44) at 0:40:63:c9:f3:11 on en1 ifscope [ethernet]

Turbi - en OpenBSD ca. version 4.6

hlk@turbi:hlk$ arp -an
? (10.0.42.1) at 00:00:24:c8:b2:4c on vr0
? (10.0.42.95) at 00:23:6c:9a:f5:2c on vr0

NB: disse tabeller er dynamiske så der sendes fra tid til anden nye ARP pakker ud, og ændring af netkort eller maskine/bundkort vil således få effekt efter kort tid.

(Disse maskiner vil blive brugt resten af julekalenderen)

ARP virker altså som den skal og Ethernet switchen gør som den skal og funktionaliteten er:

hlk@bigfoot:hlk$ ping 10.0.42.44
PING 10.0.42.44 (10.0.42.44): 56 data bytes
64 bytes from 10.0.42.44: icmp_seq=0 ttl=255 time=3.669 ms
64 bytes from 10.0.42.44: icmp_seq=1 ttl=255 time=3.646 ms
^C
--- 10.0.42.44 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 3.646/3.657/3.669/0.012 ms

Wooohoooo ping, hvis du følger med så langt keder du dig åbenbart ret meget ;-) Men ovenstående viser hvordan Ethernet, ARP og IP basalt set virker - på et lokalnetværk.

Det er nok også lige på sin plads at angive nogle af de vigtigste Ethertypes, altså Ethernet typer som vi bruger i dagligdagen:

• 0x0806 ARP, som beskrevet ovenfor
• 0x0800 IP - altså IP version 4
• 0x86dd IPv6 - IP version 6
• 0x8100 IEEE 802.1Q VLAN Tagging

- eller du kan se en lang liste på Wikipedia Ethertype.

ARP spoofing

Nu har jeg så brugt lang tid på at gennemgå ARP ned til en del detaljer, men hvad med sikkerheden?

Lad det være sagt med det samme, grundholdningen i IP - når man læser RFC'er m.v. er at hvis man skal bruge sikkerhed er det IPsec man skal se på (og det gør vi senere :-) ). I praksis er det dog ofte SSL/TLS der benyttes, og det er så på TCP niveau.

Der er ikke i ARP indbygget magisk sikkerhed der sikrer at KUN den rigtige maskine svarer, eller at man overhovedet får ARP pakker fra den maskine man forventer. Det betyder at man på et tidspunkt har fundet ud af at man kan lave ARP spoofing på Ethernet switche - og så kan man opsamle traffik fra andre maskiner på et switchet netværk. Dette er specielt et problem fordi ... mange protokoller ignorerer sikkerhed, fordi IPsec har løftet om at sikre data - men IPsec bliver jo ikke brugt i praksis på lokalnetværk, faktisk er LAN protokoller ofte ENDNU mere usikre :-)

Ja, det kommer måske ikke som en overraskelse for jer som kender til sikkerhed - men vær forvisset om at dette er rigtigt og nu vil jeg forklare lidt om hvorfor det virker og så bliver det op til jer at lege med det selv :-) Der findes et væld af tutorials der viser hvordan man gør det med Ettercap, Cain og andre programmer. Jeg anbefaler at man henter BackTrack og installerer en hackermaskine :-)

Grunden til at ARP spoofing virker er at der ingen indbygget sikkerhed er i ARP protokollen, eller ARP pakkerne. Systemer der modtager en ARP pakke kan altså ikke validere indholdet men må stole på at den pågældende MAC adresse passer til den angivne IP adresse. Ligeledes er der et par forudsætninger for at kunne udføre ARP spoofing, eksempelvis giver det ikke mening at snakke om ARP spoofing på trådløse netværk for at kunne sniffe data, idet alle data i forvejen er trådløse og kan opsamles.

Det ARP spoofing kan er altså at angive forkerte MAC adresser til systemer på et lokalnetværk, eller mere præcist et Ethernet segment. Deraf navnet, man spoofer adresser ved brug af ARP protokollen. Resultatet ved denne spoofing er derefter at systemerne der skal sende data som Ethernet pakker angiver en forkert modtager for pakkerne - hvorefter Ethernet switchen udfører sit arbejde til punkt og prikke, ved at sende pakken til hackeren. På tegningen er forsøgt gengivet hvad der sker:

ARP spoofing i praksis

Nu lyder det jo svært, men hvor svært er ARP spoofing i praksis - på en skala fra skoledreng til elitehacker er det, skoledreng. Med de tilgænge værktøjer er det ekstremt nemt.

Det første program vi kan bruge er arpspoof, som følger med i dsniff og er med på BackTrack. Dette program udfører kun ARP spoofing, så man skal sørge for at aktivere IP forwarding! Men lad os eksempelvis spoofe adressen på default gateway overfor turbi, den maskine som har adressen 10.0.42.44. Det gør jeg fra min BackTrack med:

hlk@bt4-pre:~$ sudo arpspoof -t 10.0.42.44 10.0.42.1
0:c:29:76:7a:5c 0:40:63:c9:f3:11 0806 42: arp reply 10.0.42.1 is-at 0:c:29:76:7a:5c
0:c:29:76:7a:5c 0:40:63:c9:f3:11 0806 42: arp reply 10.0.42.1 is-at 0:c:29:76:7a:5c

Det betyder at arpspoof programmet sender falske beskeder til 10.0.42.44, med MAC adressen for min laptop, og ARP tabellen fra før:

hlk@turbi:hlk$ arp -an
? (10.0.42.1) at 00:00:24:c8:b2:4c on vr0
? (10.0.42.91) at 00:23:6c:9a:f5:2c on vr0
? (10.0.42.95) at 00:23:6c:9a:f5:2c on vr0

ændres således til:

hlk@turbi:hlk$ arp -an 
? (10.0.42.1) at 00:23:6c:9a:f5:2c on vr0 --- denne linie er ændret
? (10.0.42.91) at 00:23:6c:9a:f5:2c on vr0
? (10.0.42.95) at 00:23:6c:9a:f5:2c on vr0
hlk@turbi:hlk$ 

Princippet kaldes også for Gratuitous_ARP

Hov, så vil turbi altså sende pakkerne der skal til default gateway (10.0.42.1) via MAC adressen for min laptop bigfoot (00:23:6c:9a:f5:2c) - og her stopper angrebet så effektivt, for jeg har ikke enablet IP forwarding på min laptop :-) Det er forøvrigt en af måderne man opdager ARP spoofing, eller det mere almindelige, IP konflikt på - netværket opfører sig underligt.

Istedet for arpspoof, og den manuelle procedure kunne man vælge Ettercap (start med BackTrack ettercap --gtk) Med dette værktøj kan man nemt scanne netværket, udvælge targets med musen og vupti - så er man igang med ARP spoofing.

Opsummering

Hvordan beskytter man sig så mod ARP spoofing? Jo, det første man gør er at opdele sit netværk i flere adskilte segmenter, som man router imellem - og gerne med en speciel router som kan se på pakkerne, det vi også kalder en firewall :-) Når det så er sagt vil det i praksis være nemmest at indkøbe switche der understøtter IEEE 802.1Q som giver mulighed for at adskille porte og trafikken direkte i switchen, uden hensyntagen til den fysiske kabling.

Det vil yderligere give muligheder for at holde trådløse netværk, telefoni osv. adskilt - og med mulighed for bedre kvalitet:

Hvis man har et ekstremt lille netværk kan man også integrere flere enheder i en, eksempelvis med de små firewalls der tillader bridging mellem interfaces og evt. også har wireless AP indbygget.

Når man derefter har redesignet sit netværk sikrer man sig at man bruger gode protokoller som er immune overfor aflytning, dvs SSH istedet for Telnet og FTP, osv. og det er pointen idag - brug sikre protokoller og vær opmærksom på de laveste lag i IP protokollerne.