nbsp

Wat is Bitsquatting?

Bitsquatting is een vorm van cybersquatting die afhankelijk is van bit flip fouten die optreden tijdens het maken van een DNS verzoek. Deze bit flips kunnen optreden als gevolg van factoren zoals defecte hardware of kosmische straling. Wanneer een dergelijke fout optreedt, kan de gebruiker die het domein aanvraagt, worden doorgestuurd naar een website die is geregistreerd onder een domeinnaam die lijkt op een legitiem domein, behalve met één bit omgedraaid in hun respectievelijke binaire representaties.

nbsp

Een Black Hat paper uit 2011 bevatte een gedetailleerde analyse waarbij acht legitieme domeinen het doelwit waren van eenendertig bitsquat domeinen. In de loop van één dag werden 3.434 verzoeken gedaan aan bitsquat domeinen.

Bitsquatting verwijst naar de registratie van domeinnamen die een beetje anders zijn dan een populair domein. De naam komt van typosquatting: het registreren van domeinnamen met één toetsdruk anders dan bij een populair domein. Bitsquatting zijn vaak opgeloste domeinnamen die het mogelijk maakt om computerhardwarefouten via DNS te misbruiken. 

nbsp

Invoering

Verslag van een onderzoek door Artem Dinaburg.

Computers hebben last van fouten die zich manifesteren als geheugenbeschadiging van een of meer bits. De oorzaken van deze fouten variëren van fabricagefouten tot omgevingsfactoren zoals kosmische straling en oververhitting. Hoewel de kans op een enkele fout minuscuul is, is de hoeveelheid met internet verbonden hardware extreem groot: er waren in 2010 ongeveer 5 miljard apparaten verbonden met internet. De beste manier om een ​​kleine kans te conceptualiseren, verdeeld over vele rondes, is door te denken aan een loterij. De kans om de jackpot te winnen is oneindig klein, maar als er genoeg spelers zijn, zal er iemand winnen.

Onderzoekers hebben bit-fouten eerder op verbazingwekkende manieren uitgebuit. Maar bit-fouten kunnen op nieuwe manieren op internet brede schaal worden opgespoord en misbruikt. Een van deze manieren is door middel van bitsquatting, of het registreren van domeinnamen die een bit anders zijn dan vaak opgeloste domeinen.

Theorie van de werking

Als er bitfouten optreden, kunnen ze de geheugeninhoud wijzigen. De inhoud van het computergeheugen heeft een semantische betekenis. Soms is die betekenis een domeinnaam. En applicaties die dat geheugen gebruiken, zullen de verkeerde domeinnaam gebruiken.

Een voorbeeld kan dit duidelijker illustreren. Het volgende is een binaire weergave van cnn.com:

0110001101101110011011100101110011000110110111101101101
cnncOm
Bron: dinaburg.org

Stel dat u een computer gebruikt met een defecte geheugenmodule. U bladert naar een pagina, zoals deze, met een link naar cnn.com. U klikt op de link. Hoe vaak wordt de binaire weergave van cnn.com gekopieerd in het geheugen van uw computer? Er zijn verschillende mogelijkheden die we kunt bedenken:

  • door de TCP / IP-stack van kernel naar gebruikersmodus [verschilt per implementatie]
  • door uw browser wanneer deze HTML parseert
  • … en wanneer het een interne weergave van de DOM structuur creëert
  • … en wanneer het een nieuw HTTP verzoek maakt
  • door uw OS API’s tijdens domeinresolutie

Laten we verder aannemen dat een van deze kopieerbewerkingen naar de defecte geheugenmodule schrijft. De binaire weergave verandert met één bit. Het vertegenwoordigt nu con.com.

011000110110111 1011011100101110011000110110111101101101
cOncOm
Bron: dinaburg.org

Als u op de link klikt, gaat uw browser naar con.com in plaats van naar cnn.com.

Experiment

Het concept achter het experiment is simpel: als bitfouten inderdaad domeinnamen in het apparaat geheugen muteren, dan moeten deze apparaten deze bitsquat domeinen oplossen en er verbinding mee maken. Daarom moeten bitsquats van vaak opgeloste domeinen worden bezocht door apparaten over de hele wereld.

De uitvoering van het experiment is niet zo eenvoudig. Ten eerste is er het probleem van het kiezen van domeinen voor bitsquat. Er is een verschil tussen populaire websites en vaak opgeloste domeinen. Er zijn veel vaak opgeloste domeinen die maar weinig mensen typen of kennen. Deze domeinen behoren tot de inhoudslevering en advertentienetwerken van internet; domeinen zoals fbcdn.net, 2mdn.net en akamai.com. Inhoudslevering en advertentiedomeinen zijn ook de beste experimentele doelen, aangezien het zeer onwaarschijnlijk is dat deze domeinen door mensen worden getypt. Ten tweede moet elke DNS-vraag worden beantwoord met twee antwoorden: één voor het oorspronkelijke domein en één voor het bitsquat-domein. Dit komt doordat de oorspronkelijke aanvrager mogelijk een antwoord voor de oorspronkelijke naam vraagt, en antwoorden voor ongeldige domeinen zal negeren. 

Voor het experiment heeft de onderzoeker de volgende domeinen geregistreerd. 

Let op: de registratie hiervoor is inmiddels verlopen en ze zijn niet langer in het bezit van de onderzoeker.

Bitsquat-domeinOrigineel domein
ikamai.netakamai.net
aeazon.comamazon.com
a-azon.comamazon.com
amazgn.comamazon.com
microsmft.commicrosoft.com
micrgsoft.commicrosoft.com
miarosoft.commicrosoft.com
iicrosoft.commicrosoft.com
microsnft.commicrosoft.com
mhcrosoft.commicrosoft.com
eicrosoft.commicrosoft.com
mic2osoft.commicrosoft.com
micro3oft.commicrosoft.com
li6e.comlive.com
0mdn.net2mdn.net
2-dn.net2mdn.net
2edn.net2mdn.net
2ldn.net2mdn.net
2mfn.net2mdn.net
2mln.net2mdn.net
2odn.net2mdn.net
6mdn.net2mdn.net
fbbdn.netfbcdn.net
fbgdn.netfbcdn.net
gbcdn.netfbcdn.net
fjcdn.netfbcdn.net
dbcdn.netfbcdn.net
roop-servers.netroot-servers.net
doublechick.netdoubleclick.net
do5bleclick.netdoubleclick.net
Bron: dinaburg.org

Hiervoor wordt door de onderzoeker een Python script gebruikt om DNS-vragen te beantwoorden en Apache om inkomende HTTP verzoeken in te loggen en te wachten op verbindingen. En tot mijn verbazing waren apparaten verbonden.

Experimentele bevindingen

De volgende bevindingen zijn gebaseerd op mijn Apache-logboeken van 26 september 2010 tot 5 mei 2011. Logboekvermeldingen als gevolg van crawlers van zoekmachines en scans op kwetsbaarheid van web apps werden handmatig gefilterd. Aangezien het proces handmatig was, kunnen sommige crawler / scannerverzoeken nog steeds in deze statistieken worden meegeteld.

Bevinding 1: Bit fouten kunnen worden misbruikt via DNS

Tijdens de registratieperiode waren er in totaal 52.317 bitsquat verzoeken van 12.949 unieke IP-adressen. Als we geen 3 gebeurtenissen meetellen die buitengewone hoeveelheden verkeer veroorzaakten, deden gemiddeld 59 unieke IP’s per dag HTTP verzoeken aan mijn 32 bitsquat domeinen. Deze verzoeken waren geen typefouten of andere handmatig ingevoerde URL’s, en sommige vertonen tekenen van verschillende bitfouten. 

Bevinding 2: niet alle bitfouten worden gelijk gemaakt

Sommige machines regelen aanzienlijk meer verkeer dan andere. Hoewel een bitfout in het geheugen van een pc of telefoon slechts één gebruiker treft, kan een bitfout in een proxy, recursieve DNS-server of databasecache duizenden gebruikers treffen. Bitfouten in caches van webapplicaties, DNS resolvers en een proxyserver werden allemaal waargenomen in mijn experiment. Een kleine fout bij het wijzigen van fbcdn.net in fbbdn.net leidde er bijvoorbeeld toe dat meer dan duizend Farmville-spelers verzoeken aan mijn server deden.

Bevinding 3: Mobiele en ingebedde apparaten kunnen meer worden beïnvloed dan traditionele hardware

De volgende afbeelding toont een vergelijking van HTTP User-Agents van bezoekers aan Wikipedia in maart 2011 met User-Agents die mijn bitsquat domeinen bezoeken. De kolom “andere”, die verschillende telefoons, gameconsoles en andere ingebouwde apparaten bevat, kwam aanzienlijk vaker voor bij de bitsquat bezoekers. Vreemd genoeg zijn er aanzienlijk minder Mac-OS User-Agents die bitsquat domeinen bezoeken dan Wikipedia. Er is geen verklaring waarom dit zo is.

nbsp

Bevinding 4: Bitsquat verkeer vertegenwoordigt een deel van het normale verkeer

De bezoekers aan de bitsquat domeinen kwamen van over de hele wereld en omvatten elk groot besturingssysteem en embedded platform. Hoewel er aanzienlijke verschillen waren in het percentage bezoekers dat Mac-OS en mobiele platforms gebruikte, was het percentage bezoekers dat Windows, Linux, Android en iPhone gebruikte ongeveer hetzelfde als dat van Wikipedia-bezoekers. Bovendien kan voor de bezoekers die via een geoip database vastbesloten zijn in de Verenigde Staten te zijn, een dagelijks patroon worden waargenomen dat overeenkomt met het computergebruik.

Bevinding 5: HTTPS / TLS helpt niet. DNSSEC helpt een klein beetje.

HTTP 1.1 bevat een header veld genaamd Host . Dit veld wordt gevuld met het domein waarmee de cliënt denkt dat het is verbonden. Als de Host header het bitsquat-domein bevat, is er een bitfout opgetreden vóór de domeinresolutie. Als de Host header het oorspronkelijke domein bevat, is de fout opgetreden tijdens het omzetten van het domein. In 96% van de gevallen was de bitfout opgetreden vóór de DNS-resolutie.

nbsp

Transportbeveiligingstechnologieën zoals SSL en TLS zijn ontworpen om de vertrouwelijkheid, authenticiteit en integriteit te beschermen van gegevens die tussen twee knooppunten worden verplaatst. Bitfouten komen het vaakst voor bij gegevens wanneer deze “in rust” zijn op een van de knooppunten. DNSSEC lost alleen de 4% van de gevallen op waarin een bitfout is opgetreden in het oplossingsproces.

Verder onderzoek

Duane Wessels van Verisign zocht naar bewijs van bitfouten op netwerkniveau in DNS query’s zoals te zien bij domeinwortels. Zijn bevindingen geven aan dat fouten op bitniveau in het netwerk relatief zeldzaam zijn en met een verwachte snelheid optreden.

” Het doel van zijn onderzoek was om te bepalen of de 4% van de verzoeken met een niet bitsquat Host header te wijten was aan corruptie van UDP pakketten na verzending. De uiteindelijke vaststelling was dat het zeer onwaarschijnlijk was dat de pakketten beschadigd tijdens verzending op het netwerk. In zijn eigen woorden: “Wij geloven dat UDP checksums effectief zijn in het voorkomen van ‘bitsquat’-aanvallen en andere soorten fouten die optreden nadat een DNS query een DNS resolver verlaat en het netwerk binnendringt. Bitsquat fouten die optreden voordat het netwerk binnenkomt, zullen echter niet profiteren van UDP checksums, aangezien de afzender zijn checksum berekent op basis van de foutieve gegevens. “

Bron: dinaburg.org