Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
Whireshark smart tv arp broadcast (ARP cache poisoning attack?)
02-02-2015, 23:53 door Anoniem, 3 reacties
Whireshark geeft aan dat mijn samsung smart tv constant arp broadcast berichten stuurt met de tekst who has 192.168.x.x tell 192.168.x.x
Dit terwijl mijn smart tv een vast ip heeft en een werkende internet connectie.
Wat betekend dit?
Overigens gaf eset smart security in het verleden wel eens een ARP cache poisoning attack aan. Dacht toen dat het een false positive was.
Misschien dat hier iemand er meer over weet of nuttig leesvoor heeft
Dit terwijl mijn smart tv een vast ip heeft en een werkende internet connectie.
Wat betekend dit?
Overigens gaf eset smart security in het verleden wel eens een ARP cache poisoning attack aan. Dacht toen dat het een false positive was.
Misschien dat hier iemand er meer over weet of nuttig leesvoor heeft
Reacties (3)
Hoi Anoniem,
Antwoord + verdiepend leesvoer kun je hier vinden:
https://ask.wireshark.org/questions/5412/what-does-arp-42-who-has-19216811-tell-192168133-mean
Het komt er op neer dat een apparaat (de TV in dit geval) data wil verzenden naar een ander apparaat BINNEN je netwerk.
De verzender (TV) heeft wel het IP van de ontvanger, maar niet het bijbehorende MAC, en vraagt daar middels dit verzoek om, aan alla andere apparaten binnen je netwerk.
Niet direct iets om je zorgen over te maken dus.
Dat gezegd hebbende:
Ik kan het niemand aanraden een smart-TV aan het net te hangen tenzij je daar voordeel uit haalt dat je niet op een andere manier behalen kan.
Dit omdat de firmware (vaak sterk verouderde en niet up-te-daten Java) van veel smart-apparaten zo brak is als een balletje en dus vatbaar is voor (eenvoudige) exploits, welke reeds beschikbaar zijn.
Ook sturen de meeste smart-apparaten (allemaal?) constant informatie over de gebruiker door naar de fabrikant, leverancier e/o andere commerciële partijen.
Duidelijk zo?
NB: Het anonimiseren van intern toegewezen IP's (192.168.x.x) heeft geen nut, daar dit geen IP's zijn die van buiten het netwerk te bereiken zijn, Sterker nog, het zou best handig zijn om te weten naar welk apparaat je TV probeert te zenden, wat je natuurlijk zelf kan afleiden uit het IP.
Tenminste, bij iemand die WS kan gebruiken ga ik daar wel even van uit ;)
NB2: M.b.t. ARP poisoning: http://nl.wikipedia.org/wiki/Address_Resolution_Protocol#Misbruik_van_het_ARP-protocol
Enkel als er reeds een apparaat binnen je netwerk besmet is, of iemand toegang heeft tot je netwerk kan dat een factor zijn. De kans is echter klein, er zijn minder opvallende manieren om pakketten te onderscheppen, ARP-poisoning wordt inmiddels door de meeste AV's wel herkend namelijk.
Antwoord + verdiepend leesvoer kun je hier vinden:
https://ask.wireshark.org/questions/5412/what-does-arp-42-who-has-19216811-tell-192168133-mean
Het komt er op neer dat een apparaat (de TV in dit geval) data wil verzenden naar een ander apparaat BINNEN je netwerk.
De verzender (TV) heeft wel het IP van de ontvanger, maar niet het bijbehorende MAC, en vraagt daar middels dit verzoek om, aan alla andere apparaten binnen je netwerk.
Niet direct iets om je zorgen over te maken dus.
Dat gezegd hebbende:
Ik kan het niemand aanraden een smart-TV aan het net te hangen tenzij je daar voordeel uit haalt dat je niet op een andere manier behalen kan.
Dit omdat de firmware (vaak sterk verouderde en niet up-te-daten Java) van veel smart-apparaten zo brak is als een balletje en dus vatbaar is voor (eenvoudige) exploits, welke reeds beschikbaar zijn.
Ook sturen de meeste smart-apparaten (allemaal?) constant informatie over de gebruiker door naar de fabrikant, leverancier e/o andere commerciële partijen.
Duidelijk zo?
NB: Het anonimiseren van intern toegewezen IP's (192.168.x.x) heeft geen nut, daar dit geen IP's zijn die van buiten het netwerk te bereiken zijn, Sterker nog, het zou best handig zijn om te weten naar welk apparaat je TV probeert te zenden, wat je natuurlijk zelf kan afleiden uit het IP.
Tenminste, bij iemand die WS kan gebruiken ga ik daar wel even van uit ;)
NB2: M.b.t. ARP poisoning: http://nl.wikipedia.org/wiki/Address_Resolution_Protocol#Misbruik_van_het_ARP-protocol
Enkel als er reeds een apparaat binnen je netwerk besmet is, of iemand toegang heeft tot je netwerk kan dat een factor zijn. De kans is echter klein, er zijn minder opvallende manieren om pakketten te onderscheppen, ARP-poisoning wordt inmiddels door de meeste AV's wel herkend namelijk.
03-02-2015, 12:15 door
Erik van Straten
Route tabel
Elk device met een IP-adres dat een IP-netwerkpakketje naar een ander device met een IP adres wil sturen, bepaalt aan de hand van zijn interne route tabel via welke netwerkinterface dat het beste kan (die tabel kun je zien met het commando route print in een cmd prompt/DOS box).
Lokaal of via router
Als de optimale route via een ethernet interface (bedraad of draadloos) loopt, zijn er twee mogelijkheden:
1) het doel IP-adres valt binnen het lokale subnet
2) het doel IP-adres valt buiten het lokale subnet
In geval 1 kan er direct, via ethernet, mee worden gecommuniceerd. Het zendende device zal onderzoeken of het ethernet adres (ook wel MAC adres genoemd) van het doel IP-adres nog bekend is (in de ARP cache zit). Zo ja, dan wordt het IP-pakketje als een brief beschouwd en in een envelop gestopt met op de voorzijde het ethernet adres van het doel device (en op de achterzijde het afzender ethernet adres). Deze brief wordt via de ethernet interface de kabel op (of de lucht in) geschoten, waarna het netwerk verantwoordelijk is voor de aflevering.
ARP cache
De ARP cache bevat relaties, elk bestaande uit 1 of meer IP adressen en 1 ethernet adres. Gebruikelijk is dat device entries in de ARP cache van het type "dynamisch" zijn. Dat wil zeggen dat het device ze na enige tijd (vaak 5 minuten) vergeet.
Net zoals een hosts file vaste relaties tussen domainnames en IP-adressen kan bevatten, zijn ook statische ARP entries mogelijk (hier bestaat geen specifiek bestand voor). Gebruikelijk is dit echter niet (voor end devices). In een cmd-prompt kun je op elk moment de inhoud van de ARP cache zien met het commando arp -a.
ARP requests
Als een device een IP-pakket naar een "lokaal" device (binnen subnet) wil sturen, maar daar het ethernet adres niet (meer) van kent, zal het device een ARP-request uitsturen. Ook hiervoor wordt weer zo'n "brief" gemaakt, echter gericht aan ethernet adres FF-FF-FF-FF-FF-FF (een ethernetadres is 6 bytes lang en wordt hexadecimaal genoteerd, decimaal zou dit 255-255-255-255-255-255 zijn. Nb. 255 is de hoogste waarde die in een byte past). Als 192.168.0.20 het ethernet adres van 192.168.0.1 wil weten, staat in de brief die wordt verzonden:
Who has 192.168.0.1? Tell 192.168.0.20
Ethernet broadcast pakket
Elke ethernet interface (kaart) die een netwerkpakket met doeladres FF-FF-FF-FF-FF-FF ontvangt, hoort dit door te geven aan de IP-stack "erboven" (onderdeel van het besturingssysteem). Zo'n pakketje heet dan ook een "broadcast" pakket. Nb. het netwerk dient dit soort pakketjes bij elke PC en andere ethernet devices af te leveren.
Elk ontvangend device vraagt zich vervolgens af: ben ik dat, d.w.z. is dat mijn IP-adres? Zo ja, dan wordt een antwoord gemaakt en gestuurd (dat antwoord wordt direct naar de aanvrager gestuurd, dit is geen broadcast pakket). In dat antwoord zit het ethernetadres van het doel apparaat, dat de aanvrager in zijn ARP-cache zal opslaan.
Communiceren met Internet
In geval 2) (doel IP-adres buiten subnet) kan niet direct via ethernet met het doeldevice worden gecommuniceerd. In dat geval stelt het zendende device, aan de hand van de route tabel, vast welke router (gateway) moet worden benaderd om de aflevering af te handelen. Zodra de router bekend is, wordt daar het ethernetadres van opgezocht in de ARP-tabel. Zit dat er niet in, dan wordt het aangevraagd middels een ARP request. Vervolgens wordt het IP-pakketje naar de router gestuurd met de opdracht: zoek jij het maar uit (jij bent router en weet de weg verder op internet).
TV -> Internet
Het kan zijn dat jouw TV regelmatig informatie met een server op internet wil uitwisselen. Daarvoor moet hij het ethernetadres van jouw router weten. Ik vermoed dat dit de ARP request pakketjes zijn die jij ziet in Wireshark, waarschijnlijk is er dus niets aan de hand.
Ethernet address poisoning attacks
Niet fris is het als afzender ethernet adressen worden vervalst. Als grote aantallen pakketjes met steeds wisselende (valse) afzender ethernet adressen worden verzonden, kunnen ARP caches "overlopen", maar vooral ook tabellen in netwerk switches (waardoor ze als "hub" kunnen gaan werken - het voert te ver om hier nu op in te gaan). Thuis zul je zo'n aanval niet snel tegenkomen.
ARP spoofing
Wel kan een gehackte PC zich voordoen als router, bijv. door eerder antwoord op een ARP-request te sturen dan de echte router (ook kan zo'n gehackte PC ongevraagd vervalste ARP antwoorden sturen die in ARP caches kunnen worden opgenomen). Daardoor kunnen andere devices denken dat ze pakketjes bestemd voor internet via die gehackte PC moeten sturen, waardoor een aanvaller bijv. wachtwoorden kan meelezen (dit heet een ARP spoofing attack, zie bijv. https://en.wikipedia.org/wiki/ARP_spoofing).
Onzichtbare unicast pakketjes bestemd voor een andere device
Er kunnen twee redenen zijn dat je met Wireshark op een PC wel ARP requests ziet van andere devices (zoals je TV) naar je router, maar niet de antwoorden. De eerste is dat netwerkapparatuur (switch-functionaliteit in dit geval) zoveel mogelijk "unicast" (tegenhanger van broadcast) pakketjes uitsluitend naar doeldevices stuurt. Met een gewone router (met ingebouwde switch) is hier niet simpel iets aan te doen. Uitzondering: als je een Fritz!Box hebt kun je die laten sniffen (zie https://www.security.nl/posting/410452/Wireshark+gebruiken+voor+traffic+sniffen+andere+pc#posting410458).
Promiscuous mode
De tweede reden is dat een netwerkinterface, by default, unicast pakketjes met een ander MAC adres dan van hemzelf, niet doorzet naar "software erboven", inclusief Wireshark. Veel netwerkinterfaces ondersteunen echter "promiscuous mode" waarmee ze alle ontvangen pakketjes doorzetten (zie de capture options in Wireshark om dit aan te zetten).
Elk device met een IP-adres dat een IP-netwerkpakketje naar een ander device met een IP adres wil sturen, bepaalt aan de hand van zijn interne route tabel via welke netwerkinterface dat het beste kan (die tabel kun je zien met het commando route print in een cmd prompt/DOS box).
Lokaal of via router
Als de optimale route via een ethernet interface (bedraad of draadloos) loopt, zijn er twee mogelijkheden:
1) het doel IP-adres valt binnen het lokale subnet
2) het doel IP-adres valt buiten het lokale subnet
In geval 1 kan er direct, via ethernet, mee worden gecommuniceerd. Het zendende device zal onderzoeken of het ethernet adres (ook wel MAC adres genoemd) van het doel IP-adres nog bekend is (in de ARP cache zit). Zo ja, dan wordt het IP-pakketje als een brief beschouwd en in een envelop gestopt met op de voorzijde het ethernet adres van het doel device (en op de achterzijde het afzender ethernet adres). Deze brief wordt via de ethernet interface de kabel op (of de lucht in) geschoten, waarna het netwerk verantwoordelijk is voor de aflevering.
ARP cache
De ARP cache bevat relaties, elk bestaande uit 1 of meer IP adressen en 1 ethernet adres. Gebruikelijk is dat device entries in de ARP cache van het type "dynamisch" zijn. Dat wil zeggen dat het device ze na enige tijd (vaak 5 minuten) vergeet.
Net zoals een hosts file vaste relaties tussen domainnames en IP-adressen kan bevatten, zijn ook statische ARP entries mogelijk (hier bestaat geen specifiek bestand voor). Gebruikelijk is dit echter niet (voor end devices). In een cmd-prompt kun je op elk moment de inhoud van de ARP cache zien met het commando arp -a.
ARP requests
Als een device een IP-pakket naar een "lokaal" device (binnen subnet) wil sturen, maar daar het ethernet adres niet (meer) van kent, zal het device een ARP-request uitsturen. Ook hiervoor wordt weer zo'n "brief" gemaakt, echter gericht aan ethernet adres FF-FF-FF-FF-FF-FF (een ethernetadres is 6 bytes lang en wordt hexadecimaal genoteerd, decimaal zou dit 255-255-255-255-255-255 zijn. Nb. 255 is de hoogste waarde die in een byte past). Als 192.168.0.20 het ethernet adres van 192.168.0.1 wil weten, staat in de brief die wordt verzonden:
Who has 192.168.0.1? Tell 192.168.0.20
Ethernet broadcast pakket
Elke ethernet interface (kaart) die een netwerkpakket met doeladres FF-FF-FF-FF-FF-FF ontvangt, hoort dit door te geven aan de IP-stack "erboven" (onderdeel van het besturingssysteem). Zo'n pakketje heet dan ook een "broadcast" pakket. Nb. het netwerk dient dit soort pakketjes bij elke PC en andere ethernet devices af te leveren.
Elk ontvangend device vraagt zich vervolgens af: ben ik dat, d.w.z. is dat mijn IP-adres? Zo ja, dan wordt een antwoord gemaakt en gestuurd (dat antwoord wordt direct naar de aanvrager gestuurd, dit is geen broadcast pakket). In dat antwoord zit het ethernetadres van het doel apparaat, dat de aanvrager in zijn ARP-cache zal opslaan.
Communiceren met Internet
In geval 2) (doel IP-adres buiten subnet) kan niet direct via ethernet met het doeldevice worden gecommuniceerd. In dat geval stelt het zendende device, aan de hand van de route tabel, vast welke router (gateway) moet worden benaderd om de aflevering af te handelen. Zodra de router bekend is, wordt daar het ethernetadres van opgezocht in de ARP-tabel. Zit dat er niet in, dan wordt het aangevraagd middels een ARP request. Vervolgens wordt het IP-pakketje naar de router gestuurd met de opdracht: zoek jij het maar uit (jij bent router en weet de weg verder op internet).
TV -> Internet
Het kan zijn dat jouw TV regelmatig informatie met een server op internet wil uitwisselen. Daarvoor moet hij het ethernetadres van jouw router weten. Ik vermoed dat dit de ARP request pakketjes zijn die jij ziet in Wireshark, waarschijnlijk is er dus niets aan de hand.
Ethernet address poisoning attacks
Niet fris is het als afzender ethernet adressen worden vervalst. Als grote aantallen pakketjes met steeds wisselende (valse) afzender ethernet adressen worden verzonden, kunnen ARP caches "overlopen", maar vooral ook tabellen in netwerk switches (waardoor ze als "hub" kunnen gaan werken - het voert te ver om hier nu op in te gaan). Thuis zul je zo'n aanval niet snel tegenkomen.
ARP spoofing
Wel kan een gehackte PC zich voordoen als router, bijv. door eerder antwoord op een ARP-request te sturen dan de echte router (ook kan zo'n gehackte PC ongevraagd vervalste ARP antwoorden sturen die in ARP caches kunnen worden opgenomen). Daardoor kunnen andere devices denken dat ze pakketjes bestemd voor internet via die gehackte PC moeten sturen, waardoor een aanvaller bijv. wachtwoorden kan meelezen (dit heet een ARP spoofing attack, zie bijv. https://en.wikipedia.org/wiki/ARP_spoofing).
Onzichtbare unicast pakketjes bestemd voor een andere device
Er kunnen twee redenen zijn dat je met Wireshark op een PC wel ARP requests ziet van andere devices (zoals je TV) naar je router, maar niet de antwoorden. De eerste is dat netwerkapparatuur (switch-functionaliteit in dit geval) zoveel mogelijk "unicast" (tegenhanger van broadcast) pakketjes uitsluitend naar doeldevices stuurt. Met een gewone router (met ingebouwde switch) is hier niet simpel iets aan te doen. Uitzondering: als je een Fritz!Box hebt kun je die laten sniffen (zie https://www.security.nl/posting/410452/Wireshark+gebruiken+voor+traffic+sniffen+andere+pc#posting410458).
Promiscuous mode
De tweede reden is dat een netwerkinterface, by default, unicast pakketjes met een ander MAC adres dan van hemzelf, niet doorzet naar "software erboven", inclusief Wireshark. Veel netwerkinterfaces ondersteunen echter "promiscuous mode" waarmee ze alle ontvangen pakketjes doorzetten (zie de capture options in Wireshark om dit aan te zetten).
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.
