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.
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 druk op een toets anders dan bij een populair domein. Bitsquatting zijn vaak opgeloste domeinnamen die het mogelijk maakt om computer hardware fouten via DNS te misbruiken.
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:
| 01100011 | 01101110 | 01101110 | 0101110 | 01100011 | 01101111 | 01101101 |
| c | n | n | | c | O | m |
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.
| 01100011 | 0110111 1 | 01101110 | 0101110 | 01100011 | 01101111 | 01101101 |
| c | O | n | | c | O | m |
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-domein | Origineel domein |
| ikamai.net | akamai.net |
| aeazon.com | amazon.com |
| a-azon.com | amazon.com |
| amazgn.com | amazon.com |
| microsmft.com | microsoft.com |
| micrgsoft.com | microsoft.com |
| miarosoft.com | microsoft.com |
| iicrosoft.com | microsoft.com |
| microsnft.com | microsoft.com |
| mhcrosoft.com | microsoft.com |
| eicrosoft.com | microsoft.com |
| mic2osoft.com | microsoft.com |
| micro3oft.com | microsoft.com |
| li6e.com | live.com |
| 0mdn.net | 2mdn.net |
| 2-dn.net | 2mdn.net |
| 2edn.net | 2mdn.net |
| 2ldn.net | 2mdn.net |
| 2mfn.net | 2mdn.net |
| 2mln.net | 2mdn.net |
| 2odn.net | 2mdn.net |
| 6mdn.net | 2mdn.net |
| fbbdn.net | fbcdn.net |
| fbgdn.net | fbcdn.net |
| gbcdn.net | fbcdn.net |
| fjcdn.net | fbcdn.net |
| dbcdn.net | fbcdn.net |
| roop-servers.net | root-servers.net |
| doublechick.net | doubleclick.net |
| do5bleclick.net | doubleclick.net |
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 bit fouten 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.
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.
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 bit fouten op netwerkniveau in DNS query’s zoals te zien bij domeinwortels. Zijn bevindingen geven aan dat fouten op bit niveau 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
