IDN-spoofing is het genereren van domeinnamen die “vergelijkbaar” zijn met de geselecteerde, meestal gebruikt om de gebruiker te dwingen een link naar de bron van een aanvaller te volgen. Laten we vervolgens eens kijken naar een meer specifieke aanvalsoptie.

Laten we ons voorstellen dat het aangevallen bedrijf eigenaar is van het organisatie.org-domein, en binnen dit bedrijf wordt de interne bron portal.organization.org gebruikt. Het doel van de aanvaller is om de inloggegevens van de gebruiker te verkrijgen en om dit te doen, stuurt hij een link via e-mail of de messenger die door het bedrijf wordt gebruikt.

Als u zo'n bericht heeft ontvangen, is de kans groot dat u niet merkt dat de link ergens naar de verkeerde plaats leidt. Nadat u op de link heeft geklikt, wordt u om een ​​login/wachtwoord gevraagd en zal het slachtoffer, in de veronderstelling dat hij zich op een interne bron bevindt, zijn accountgegevens invoeren. De kansen van de aanvaller zijn vooral groot als hij de perimeter al is binnengedrongen, het systeem van een medewerker in gevaar heeft gebracht en nu vecht voor systeembeheerdersrechten.

Het is onmogelijk om hier absolute “foolproofing” te bedenken, maar je kunt proberen deze aanval te onderscheppen in het stadium van de naamresolutie via een DNS-verzoek.

Ter bescherming moeten we de namen die we tegenkomen in onderschepte DNS-verzoeken opeenvolgend onthouden. Het bedrijf maakt gebruik van zijn interne bronnen, wat betekent dat we deze snel zullen vinden in een verzoek aan portal.organization.org. Zodra we een naam tegenkomen die “vergelijkbaar” is met een eerder aangetroffen naam, kunnen we het DNS-antwoord vervangen door een fout terug te sturen in plaats van het IP-adres van de aanvaller.
Welke algoritmen kunnen er zijn om ‘overeenstemming’ te bepalen?

• UTS39 Confusable Detection (http://www.unicode.org/reports/tr39/#Confusable_Detection) Unicode is niet alleen een waardevolle symbooltabel, maar ook een reeks standaarden en aanbevelingen. UTS39 definieert een Unicode-algoritme voor het normaliseren van tekenreeksen, waarbij tekenreeksen die verschillen in homogliefen (bijvoorbeeld de Russische "a" en de Latijnse "a") worden teruggebracht tot dezelfde vorm
• Woorden die verschillen door herschikking van interne letters. Het is vrij gemakkelijk om organisatie.org en organisatie.org te verwarren
• Het domein op het eerste niveau vervangen. Het eerste niveau van de naam heeft meestal geen enkele betekenis en een medewerker van het bedrijf die ‘organisatie’ ziet, kan het verschil in .org of .net negeren, hoewel hier uitzonderingen mogelijk zijn.

Hoogstwaarschijnlijk zal de bedrijfsserver niet gebonden zijn, wat een standaard is voor webhosts of providers, maar een Microsoft DNS-server vanwege het wijdverbreide gebruik van active directory. En het eerste probleem dat ik tegenkwam bij het schrijven van een filter voor de Microsoft DNS-server was dat ik geen API kon vinden voor het filteren van DNS-verzoeken. Dit probleem kan op verschillende manieren worden opgelost, ik heb gekozen voor dll-injectie en een IAT-hook voor de socket-api.

Om de methodiek te begrijpen is kennis van het PE-format noodzakelijk; je kunt bijvoorbeeld meer in detail lezen. Het uitvoerbare bestand bestaat uit headers, een tabel met secties en de secties zelf. De secties zelf zijn een gegevensblok dat de bootloader in het geheugen moet toewijzen op een relatief adres (Relative Virtual Address - RVA), en alle bronnen, code en andere gegevens bevinden zich in de secties. Ook in de header zijn er links (RVA) naar een aantal tabellen die nodig zijn om de applicatie te laten werken; voor de doeleinden van dit artikel zullen er twee belangrijk zijn: de importtabel en de exporttabel. De importtabel bevat een lijst met functies die nodig zijn om de applicatie te laten werken, maar die zich in andere bestanden bevinden. De exporttabel is een “achterwaartse” tabel die een lijst bevat met functies die uit dat bestand worden geëxporteerd, of, in het geval van export forwarding, de naam van het bestand en de naam van de functie om de afhankelijkheid op te lossen.

We zullen de dll-injectie doen zonder de saaie CreateRemoteThread. Ik besloot PE-export forwarding te gebruiken - dit is een al lang bekende techniek waarbij, om het gewenste proces te laden, een dll wordt gemaakt in de map met het exe-bestand met een naam die gelijk is aan de naam van elke dll uit de import tabel van het exe-bestand (het belangrijkste is om HKEY_LOCAL_MACHINE\System\ CurrentControlSet\Control\Session Manager\KnownDLLs niet te gebruiken). In de gemaakte dll wordt de exporttabel van de doel-dll gekopieerd, maar in plaats van een verwijzing naar de code van de geëxporteerde functie, moet je RVA schrijven naar een voorwaartse string zoals “endpoint!sendto”. De Microsoft DNS-server zelf is geïmplementeerd als een service HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\DNS, die zich bevindt in %systemroot%\system32\dns.exe

Het uiteindelijke injectie-algoritme in de DNS-server zal er als volgt uitzien:

• Maak een map %systemroot%\system32\dnsflt (elke andere map is mogelijk, het is niet nodig om de map in system32 te lokaliseren).
• Kopieer %systemroot%\system32\dnsapi.dll daarheen - dit is de dll waaruit dns.exe iets importeert, u kunt elke andere “onbekende dll” selecteren.
• Hernoem de gekopieerde dll naar endpoint.dll - we zullen deze naam gebruiken in de voorwaartse regel.
• We nemen onze geïnjecteerde dll en voegen er de juiste exporttabel aan toe, kopiëren onze dll naar %systemroot%\system32\dnsflt
• In de registersleutel HKEY_LOCAL_MACHINE\System\CurrentControlSet\services\DNS wijzigt u het nieuwe binaire adres in ImagePath %systemroot%\system32\dnsflt\dns.exe
• Maak een symlink van %systemroot%\system32\dnsflt\dns.exe naar %systemroot%\system32\dns.exe

Waarom de laatste stap? Feit is dat Windows een ingebouwde firewall heeft en dat in de Windows-server standaard alleen de toepassing %systemroot%\system32\dns.exe het recht heeft om naar poort 53 te luisteren. Als u het vanuit een andere map probeert uit te voeren, heeft u geen netwerktoegangsrechten. Waarom heb ik het überhaupt gekopieerd? Om de impact op het hele systeem te minimaliseren en de originele dnsapi.dll niet aan te raken. Het blijkt dat als je weet hoe je een symlink naar een applicatie moet maken, je de netwerkrechten ervan kunt verkrijgen. Standaard hebben alleen beheerders rechten om symlinks te maken, maar het is nogal verrassend om te ontdekken dat door een gebruiker het recht te geven om symlinks te maken, je hem de mogelijkheid geeft om de ingebouwde firewall te omzeilen.

Nadat u vanuit DllMain in het proces bent geladen, kunt u een thread maken en een onderschepping instellen. In het eenvoudigste geval zal onze dns-service de client het IP-adres voor de naam vertellen door een UDP-pakket te verzenden vanaf poort 53 via de sendto-functie van ws2_32.dll. De standaard suggereert dat TCP-poort 53 kan worden gebruikt als de respons te groot is, en het onderscheppen van sendto zou in dit geval uiteraard nutteloos zijn. Het is echter mogelijk om de zaak met TCP op een vergelijkbare manier af te handelen, hoewel dit arbeidsintensiever is. Voor nu zal ik je het eenvoudigste geval met UDP vertellen. We weten dus dat de code in dns.exe de sendto-functie van ws2_32.dll zal importeren en deze zal gebruiken om op het DNS-verzoek te reageren. Er zijn ook heel wat verschillende manieren om functies te onderscheppen, de klassieke is splicing, wanneer de eerste sendto-instructies worden vervangen door jmp in zijn functie, en na voltooiing wordt er een overgang gemaakt naar de eerder opgeslagen sendto-instructies en dan naar binnen de sendto-functie. Het splitsen werkt zelfs als GetProcAddress wordt gebruikt om sendto aan te roepen in plaats van een importtabel, maar als er een importtabel wordt gebruikt, is het gemakkelijker om een ​​IAT-hook te gebruiken in plaats van te splitsen. Om dit te doen, moet u de importtabel vinden in de gedownloade dns.exe-afbeelding. De tabel zelf heeft een enigszins verwarrende structuur en voor details moet je naar de beschrijving van het PE-formaat gaan.

Het belangrijkste is dat het systeem tijdens het laden van de afbeelding een verwijzing naar het begin van de sendto-functie in de importtabel schrijft. Dit betekent dat u, om een ​​sendto-oproep te onderscheppen, eenvoudigweg het adres van de oorspronkelijke sendto in de importtabel hoeft te vervangen door het adres van uw functie.

Dus hebben we een onderschepping opgezet en zijn we begonnen met het ontvangen van gegevens. Het prototype van de sendto-functie ziet er als volgt uit:

Int sendto(_In_ SOCKET s, _In_ const char *buf, _In_ int len, _In_ int flags, _In_ const struct sockaddr *to, _In_ int tolen);
Als s een socket op poort 53 is, zal de buf-pointer een dns-antwoord van de grootte len bevatten. Het formaat zelf wordt beschreven in RFC1035. Ik zal kort beschrijven wat er moet gebeuren om bij de relevante gegevens te komen.

De berichtstructuur in de standaard wordt als volgt beschreven:

De header bevat de benodigde informatie: berichttype, foutcode en aantal elementen in secties. De kop zelf ziet er als volgt uit:

Structuur DNS_HEADER ( uint16_t id; // identificatienummer uint8_t rd: 1; // gewenste recursie uint8_t tc: 1; // ingekort bericht uint8_t aa: 1; // gezaghebbend antwoord uint8_t opcode: 4; // doel van bericht uint8_t qr: 1; // query/response-vlag uint8_t rcode: 4; // responscode uint8_t cd: 1; // controle uitgeschakeld uint8_t ad: 1; // geverifieerde gegevens uint8_t z: 1; // zijn z! gereserveerd uint8_t ra: 1 ; // recursie beschikbaar uint16_t q_count; // aantal vraagitems uint16_t ans_count; // aantal antwoorditems uint16_t auth_count; // aantal autoriteitsitems uint16_t add_count; // aantal resource-items );
Het vraaggedeelte moet worden gedemonteerd om bij het antwoord te komen. De sectie zelf bestaat uit het aantal blokken aangegeven in de header (q_count). Elk blok bestaat uit een naam, type en verzoekklasse. De naam wordt gecodeerd als een reeks strings, elk beginnend met een byte met de lengte van de string. Aan het einde is er een string met lengte nul. De naam homedomain2008.ru ziet er bijvoorbeeld als volgt uit:

De sectie Antwoorden ziet er hetzelfde uit: het blok bestaat uit een naam, type, klasse, ttl en aanvullende gegevens. Het IP-adres wordt vermeld in de advertentie. gegevens. Een andere moeilijkheid doet zich voor bij het ontleden van de naam. Blijkbaar kunt u, om de grootte van het bericht te verkleinen, in plaats van de lengte van het label een link naar een ander gegevensgebied vinden. Het wordt als volgt gecodeerd: als de twee meest significante bits van de lengte gelijk zijn aan 11, dan moeten de volgende byte, evenals de minst significante bits van de lengte, worden geïnterpreteerd als een offset in bytes ten opzichte van het begin van de lengte. bericht. Verdere ontleding van de naam moet worden gedaan door deze offset te doorlopen.

We hebben dus de vereiste API onderschept, het DNS-antwoord geparseerd, nu moeten we een beslissing nemen: sla dit antwoord verder over of retourneer een fout. Voor elke naam die nog niet in de database aanwezig is, moet u aan de hand van het antwoord controleren of deze “verdacht” is of niet.
We zullen die namen als “verdacht” beschouwen waarvoor het resultaat van de skeletfunctie van Unicode Technical Standard tr39 samenvalt met het resultaat van een van de namen uit de database, of die namen die verschillen van de namen die in de database aanwezig zijn door het herschikken van interne letters . Om controles uit te voeren, slaan we 2 tabellen op. De eerste zal bestaan ​​uit skeletresultaten voor alle namen uit de database, in de tweede tabel zullen we de rijen schrijven die zijn verkregen uit de databaserijen door het eerste en laatste teken van elk label te verwijderen, behalve het eerste niveau, en vervolgens de resterende te sorteren tekens van elk label. Als er nu een nieuwe naam in een van de twee tabellen staat, beschouwen we dit als verdacht.

Het doel van de skeletfunctie is om de gelijkenis van twee strings te bepalen; hiervoor worden karakters voor elke string genormaliseerd. Xlœ wordt bijvoorbeeld geconverteerd naar Xloe, en door het resultaat van de functie te vergelijken, kunt u de gelijkenis van Unicode-tekenreeksen bepalen.

Een voorbeeld van de implementatie van het bovenstaande is te vinden op github.
Het is duidelijk dat de geschetste oplossing in de praktijk geen normale bescherming kan bieden, omdat er naast kleine technische problemen met het afluisteren een nog groter probleem is met het detecteren van “soortgelijke” namen. Het zou leuk zijn om te behandelen:

• Combinaties van permutaties en homogliefen.
• Het toevoegen/vervangen van tekens waarmee skeleton geen rekening houdt.
• UTS tr39 is niet beperkt tot skeleton; je kunt ook het mixen van tekensets in één label beperken.
• Japanse punt- en andere labelscheider over de volledige breedte.
• En ook zulke prachtige dingen als

DNS-vergiftiging of DNS-spoofing is een soort cyberaanval waarbij systeemkwetsbaarheden in een DNS-server worden misbruikt om verkeer van legitieme servers naar nepservers om te leiden.

Hoe DNS-vergiftiging of DNS-spoofing werkt

DNS-cachevergiftigingscode wordt vaak aangetroffen in URL's die in spamberichten worden verzonden. In deze berichten proberen aanvallers gebruikers bang te maken en hen daardoor te dwingen op de bijgevoegde link te klikken, wat op zijn beurt hun computer zal infecteren. Banners en afbeeldingen, zowel in e-mail als op dubieuze websites, kunnen gebruikers ook naar deze code doorverwijzen. Eenmaal geïnfecteerd zullen computers gebruikers omleiden naar nepsites die de originele webpagina's nabootsen, waardoor ze worden blootgesteld aan risico's zoals spyware, keyloggers of wormen.

Risico's

DNS-vergiftiging veroorzaakt verschillende risico's, te beginnen met gegevensdiefstal. Websites van banken en populaire online winkels kunnen gemakkelijk worden vervalst, wat betekent dat elk wachtwoord, creditcard of persoonlijke informatie in gevaar kan worden gebracht. En als de websites van IT-beveiligingsdienstverleners worden vervalst, kan de computer van de gebruiker worden blootgesteld aan extra risico's, zoals infectie door virussen of Trojaanse paarden, omdat de beveiligingssystemen geen legitieme updates ontvangen. Ten slotte is het oplossen van DNS-cachevergiftiging erg moeilijk, omdat het opschonen van de geïnfecteerde server het probleem niet oplost, en het opschonen van computers die verbinding maken met de gecompromitteerde server ervoor zal zorgen dat ze opnieuw worden geïnfecteerd. Indien nodig kunnen gebruikers het probleem oplossen door hun DNS-cache te wissen.

Om DNS-vergiftiging te voorkomen, moeten gebruikers voorkomen dat ze op onbekende links klikken en hun computer regelmatig scannen op malware. Doe dit altijd met het programma dat op uw computer is geïnstalleerd, en niet met de online versie, die ook kan worden vervalst.

Origineel: Cyberaanvallen uitgelegd: DNS-invasies
Auteur: Prashant Phatak
Datum van publicatie: 22 februari 2012
Vertaling: A. Panin
Datum van vertaling: 8 december 2012

We zien vaak sites die onleesbaar zijn gemaakt, waarvan de hoofdpagina’s zijn vervangen door aanvallers. Hoe slagen hackers erin dergelijke aanvallen uit te voeren en hoe kunnen we onze netwerkinfrastructuur ertegen beschermen? In dit artikel wordt uitgelegd hoe aanvallers het DNS (Domain Name System) kunnen verstoren. DNS-aanvallen zijn technisch complex en gevaarlijk voor de netwerk- en webinfrastructuur. Netwerkbeheerders moeten zich bewust zijn van dit soort aanvallen en alle mogelijke maatregelen nemen om de veiligheid van de infrastructuur die zij onderhouden te waarborgen.

Zoals we weten, is de reden voor het bestaan ​​van DNS het feit dat een persoon niet veel IP-adressen kan onthouden om toegang te krijgen tot sites, maar hij kan gemakkelijk sitenamen onthouden die uit letters en cijfers bestaan. Het DNS-systeem is ontworpen in een tijd waarin internet werd gebruikt door vriendelijke mensen, wat leidde tot enkele kenmerken van het systeem in de moderne tijd.

Figuur 1 toont de fundamentele principes van de dienst voor het omzetten van netwerknamen. Wanneer een applicatie (zoals een browser) verbinding wil maken met een externe dienst, vraagt ​​deze de DNS-server om een ​​IP-adres. Dit verzoek in de vorm van een pakket wordt verzonden via UDP-poortnummer 53, waarna de server een antwoord retourneert in de vorm van een pakket. (Houd er rekening mee dat, omdat de gegevensgrootte van een UDP-datagram beperkt is tot 512 bytes, de protocolstack automatisch TCP gebruikt om verzoeken te doen en antwoorden te ontvangen.) Wanneer de client het antwoord accepteert, voegt deze de gegevens toe aan de lokale cache, die versnelt volgende oproepen naar hetzelfde domein. Lokale cache-items worden automatisch vernietigd nadat hun levensduur (TTL-parameter (Time to Live)) is verstreken.

Figuur 1: Domeinnaamresolutie

Het DNS-systeem gebruikt recordtypen zoals A, CNAME, SOA, MX en andere. Hoewel het beschrijven van dit soort records buiten het bestek van dit artikel valt, is het belangrijk dat systeembeheerders zich bewust zijn van wanneer en hoe ze moeten worden gebruikt, en dat er onderzoek moet worden uitgevoerd voordat ze worden gebruikt voor de toekomstige beveiliging van het systeem. Voordat we naar aanvallen op het DNS-systeem kijken, moeten we naar twee soorten zoekopdrachten kijken: iteratief en recursief.

• Iteratieve DNS-query's: terwijl een client een DNS-server vraagt ​​om informatie over een domein, kan de DNS-server al dan niet informatie over dat domein hebben. Als de DNS-server geen antwoord heeft, stuurt hij in plaats van het verzoek af te ronden, de naam van de hoogste DNS-server die mogelijk over de benodigde informatie beschikt naar de client. Dit proces wordt gewoonlijk DNS-verwijzing genoemd. De client stuurt een verzoek naar de volgende (gespecificeerde) server; als er geen antwoord komt, stuurt het de naam van de bovenste server naar de client. Dit proces gaat door totdat de client een IP-adres ontvangt of een foutmelding krijgt dat het verzoek niet kan worden voltooid.
• Recursieve DNS-query's: in dit geval begint het proces met het rechtstreeks door de client indienen van een verzoek om domeinnaamomzetting bij de DNS-server. Als de DNS-server geen antwoord heeft, wordt verwacht dat hij het werk doet van de communicatie met de servers op een hoger niveau in plaats van simpelweg hun namen aan de client door te geven. Nogmaals, als de upstream-server niet over de informatie beschikt om op het verzoek te reageren, stuurt hij het verzoek door naar de upstream-server. Dit proces gaat door totdat het verzoek de root-DNS-server bereikt, die over de benodigde informatie moet beschikken en een antwoord wordt teruggestuurd naar de client. Als de gevraagde naam niet bestaat, wordt er een foutmelding teruggestuurd naar de client langs de keten van servers. In tegenstelling tot de iteratieve methode wordt een recursieve zoekopdracht als agressiever beschouwd bij het verkrijgen van het resultaat.

Iteratieve query's worden meestal gemaakt door DNS-servers, terwijl recursieve query's worden gemaakt door clients, omdat dit soort query's de noodzaak van complexe verwerking van DNS-query-omleidingsprocessen elimineert. Vanuit het oogpunt van systeembeveiliging moeten beheerders de basisbeginselen van DNS-systemen begrijpen, omdat een organisatie mogelijk meerdere DNS-servers heeft draaien, die zonerecords synchroniseren om de gegevensconsistentie te behouden.

DNS-gegevens worden periodiek gesynchroniseerd zonder dat de systeemservices opnieuw hoeven te worden opgestart, en wanneer er wijzigingen worden aangebracht aan de rootserver, worden de wijzigingen automatisch naar downstream-servers verzonden. De tijd die nodig is om gegevens te synchroniseren wordt ingesteld door de levensduurparameter van elke record. In het geval van geografisch verspreide DNS-servers kan de datasynchronisatieperiode de hele dag duren, omdat elk van de servers in de keten zijn eigen cache gebruikt om de verwerking van zoekopdrachten te versnellen.

Aanvallen op DNS-systemen

Er is waargenomen dat systeembeheerders veel tijd besteden aan het ontwikkelen van beveiligingssystemen voor applicaties, servers en andere infrastructuurcomponenten, maar helaas hebben ze de neiging de beveiligingssystemen voor DNS-servers te vergeten. Kijk eens naar Figuur 2, waarin mogelijke zwakke punten in DNS-servers worden getoond, waardoor ze kwetsbaar zijn voor aanvallen. DNS is zo ontworpen dat de meeste communicatie via UDP plaatsvindt, geen ingebouwde beveiliging heeft en geen ingebouwde authenticatieondersteuning heeft, waardoor het kwetsbaarder is voor aanvallen dan andere netwerkdiensten. Laten we eens kijken naar enkele typen van de meest voorkomende DNS-aanvallen.

Figuur 2: Mogelijke zwakke punten van DNS-servers

DNS-cachevergiftiging

Deze aanval kan het naamomzettingsproces op twee manieren beïnvloeden. Bij de eerste methode installeert de aanvaller kwaadaardige software (een rootkit of virus) die de lokale DNS-cache op de computer van de klant zou moeten controleren. Vermeldingen in de lokale DNS-cache worden vervolgens aangepast zodat ze naar verschillende IP-adressen verwijzen.

Als een browser bijvoorbeeld probeert toegang te krijgen tot een site met het adres http://www.cnn.com/, ontvangt hij in plaats van het CNN IP-adres te ontvangen, een adres dat is ingesteld door de software van de aanvaller, en dat meestal verwijst naar een site die zich bevindt op een server die eigendom is van de aanvaller en die schadelijke software bevat of een bericht dat aanstootgevend is voor de gebruiker.

De tweede, gevaarlijkere manier is dat de aanvaller de DNS-server aanvalt en de lokale cache ervan wijzigt, waardoor alle servers die deze server gebruiken voor naamomzetting onjuiste IP-adressen zullen ontvangen, wat uiteindelijk zal leiden tot overtredingen en kan resulteren in de verlies of diefstal van informatie.

In zeer zeldzame gevallen kunnen aanvallers toegang krijgen tot de root-DNS-server, die master-rootdomeinrecords zoals .com, .net of landspecifieke domeinnaamsysteemrecords opslaat. Hackers kunnen records op deze server wijzigen en andere servers ontvangen de gewijzigde gegevens automatisch, wat kan leiden tot wereldwijde storingen van commerciële netwerkdiensten en sites. Hoewel dergelijke situaties zeer zeldzaam zijn, komen ze toch voor - nog niet zo lang geleden verstoorde een soortgelijke aanval het werk van een groot sociaal netwerk.

Vervanging van DNS-server (DNS-kaping)

Deze aanval wordt ook vaak gebruikt om de manier waarop DNS-systemen werken te veranderen. In dit geval worden er geen wijzigingen aangebracht in de DNS-cache van de client, maar worden er wijzigingen aangebracht in de instellingen, waarna alle verzoeken om naamomzetting worden gericht aan de persoonlijke DNS-server van de aanvaller. Doorgaans is deze aanval niet gericht op het stelen van gegevens, maar op het verzamelen van statistische informatie van de computer van de klant. Alle verzoeken om naamomzetting die naar de server van de aanvaller worden verzonden, worden correct voltooid, maar de aanvaller ontvangt informatie over de sites die door de client zijn bezocht.

Deze informatie kan vervolgens worden gebruikt om contextuele advertenties aan de klant te tonen. Sommige hackers leiden gebruikers door naar hun websites of zoekmachines om advertentie-inkomsten te genereren of eenvoudigweg om gegevens te stelen en social engineering-technieken te gebruiken. In gevallen waarin deze functie van de DNS niet voor persoonlijk gewin kan worden gebruikt, wordt deze door veel bekende sites en internetproviders gebruikt om statistische gegevens te verzamelen over de door de gebruiker bezochte bronnen.

DNS-spoofing

Deze aanval is een menselijke kaping waarbij de aanvaller controle verkrijgt over het netwerk waarop de DNS-server draait en de ARP-cache wijzigt met behulp van pakketspoofing. Zodra de controle over het netwerk op MAC-adresniveau is verkregen, achterhaalt de aanvaller het IP-adres van de DNS-server en begint hij met het monitoren en wijzigen van zoekopdrachten die voor die server zijn bedoeld.

Alle verzoeken van het netwerk gaan via de computer van de aanvaller en bereiken de echte DNS-server. Deze aanval kan ernstige gevolgen hebben, omdat alle computers in het netwerk op geen enkele manier het feit van de aanval zullen registreren en alle DNS-verzoeken naar het adres van de computer van de aanvaller zullen sturen.

Er is een alternatieve methode voor deze aanval: DNS ID-spoofing. Elk DNS-verzoek en -antwoord heeft unieke ID's die zijn ontworpen om onderscheid te maken tussen verzoeken die tegelijkertijd naar de DNS-server worden verzonden. Deze unieke identificatiegegevens worden vaak gevormd op basis van het MAC-adres, de datum en tijd waarop het verzoek is gedaan, en worden automatisch aangemaakt door de protocolstack.

De aanvaller gebruikt een sniffer om een ​​of meer verzoeken en antwoorden met de bijbehorende ID's vast te leggen, en maakt vervolgens een verzoek met de bijbehorende ID en een vervalst IP-adres. Als gevolg van deze acties wordt het vervalste IP-adres opgeslagen in de lokale cache van het aangevallen systeem. Hierna kan het aangevallen systeem beschadigd raken door kwaadaardige software op de server te plaatsen met het adres dat in het verzoek is opgegeven.

DNS-herbinding

Deze aanval wordt ook wel ‘DNS-pinning’ genoemd en is een bijzonder geavanceerde aanval. Tijdens dit proces registreert de aanvaller eerst zijn eigen domeinnaam en stelt vervolgens een minimale levensduurwaarde in die voorkomt dat informatie over die domeinnaam in de cache wordt opgeslagen.

DNS Denial of Service-aanvallen

Zoals we in het eerste artikel in de serie hebben geleerd, kan het bombarderen van poort 53 met een stortvloed aan UDP- of TCP-verzoekpakketten ervoor zorgen dat de server een Denial of Service ervaart. Een andere methode om deze aanval uit te voeren is door aan te vallen met een stortvloed aan ping-pakketten of TCP SYN-segmenten. Het belangrijkste idee achter deze acties is om het gebruik van serverbronnen (CPU en RAM) te maximaliseren, zodat de server niet meer op verzoeken reageert. Hoewel DNS-servers worden beschermd door firewalls, staat het domeinnaamresolutiesysteem open voor dit soort aanvallen als DNS UDP-poorten niet worden geblokkeerd voor toegang vanaf niet-vertrouwde netwerken.

Verhoogde belasting betekent dat de DNS-server wordt belast met taken die de server niet kan uitvoeren. Er zijn een aantal manieren om een ​​server te belasten en uiteindelijk onbruikbaar te maken. Eén methode maakt gebruik van kwaadaardige software (Trojan) om de lokale DNS-cache van meerdere hosts te wijzigen. Na deze acties beginnen alle knooppunten met een aangepaste cache verzoeken te sturen naar een specifieke naamserver, die eerder door de aanvallers is geselecteerd.

Elke server kan slechts binnen een beperkte tijd reageren op een beperkt aantal verzoeken (afhankelijk van de CPU-prestaties en configuratie) en begint uiteindelijk verzoeken aan de wachtrij toe te voegen. Hoe meer clients worden blootgesteld aan wijzigingen in de lokale DNS-cache, hoe meer verzoeken naar de wachtrij worden verzonden en uiteindelijk zal de server lamleggen.

Bij een ander type aanval wijzigt de aanvaller de cache van de DNS-server; In plaats van IP-adressen te vervangen die overeenkomen met A- of CNAME-records, worden domeinnamen gewijzigd. Om de zaken nog ingewikkelder te maken, kan elke domeinnaam enkele honderden of duizenden tekens lang zijn. Het gegevenssynchronisatieproces dat begint nadat wijzigingen zijn aangebracht, omvat het verzenden van vele kilobytes aan gegevens van de masternaamserver naar downstream-servers en uiteindelijk naar clients.

Nadat de TTL is verlopen, begint het gegevenssynchronisatieproces opnieuw en kan dit resulteren in het uitvallen van een of meer DNS-servers in de keten. Deze cache-effecten simuleren een gedistribueerde denial-of-service-aanval, die gevaarlijk en moeilijk te controleren is.

Bescherming van systemen op basis van vrije software

In de wereld van vrije systemen is er een implementatie van de dienst voor het oplossen van domeinnamen, die over de hele wereld bekend is vanwege de hoogste werkingssnelheid in vergelijking met analogen. Deze meest gebruikte en bekende oplossing is de Bind-service. Omdat de meeste aanvallen op DNS-services echter gebruik maken van protocolfouten, wordt de taak van het beschermen van open systemen waarop services voor het omzetten van domeinnamen draaien moeilijker.

De allereerste stap bij het ontwikkelen van een beveiligingssysteem zou het blokkeren op netwerkniveau moeten zijn. Naast poorten voor serveronderhoud mogen alleen poorten voor DNS-query's open blijven en moeten alle andere poorten worden geblokkeerd, zowel op de firewall als rechtstreeks op de server die het besturingssysteem gebruikt.

De volgende belangrijke stap is ervoor te zorgen dat er geen andere software dan de domeinnaamresolutieservice op de server is geïnstalleerd. Deze voorzorgsmaatregel moet vooral worden genomen als u werkt met een bedrijfsrootserver voor naamomzetting die de resolutie van alle interne domeinnamen ondersteunt en alle verzoeken om naamomzetting doorstuurt naar externe servers voor het lokale netwerk.

Het komt vaak voor dat een kwetsbaarheid in een programma van derden ervoor zorgt dat iemand een naamresolutieserver kan binnendringen. Hoewel de meest kritieke delen van de netwerkinfrastructuur worden beschermd door firewalls, Unified Threat Management en krachtige antivirusprogramma's, is het vaak nodig om de bescherming te versterken met een inbraakdetectiesysteem. Hiermee kunt u OSI Layer 2- en 3-aanvallen afweren, zoals ARP-spoofing, IP-spoofing, sniffer-aanvallen en andere soorten aanvallen.

Naast de essentiële voorzorgsmaatregelen die hierboven zijn beschreven, zijn er verschillende geavanceerde technieken die ook moeten worden toegepast. Zoals we eerder hebben geleerd, heeft elk verzoek zijn eigen unieke identificatie en wordt het in een UDP-pakket verzonden. Helaas zijn deze identifiers, vanwege het ontwerp van de DNS-stack dat wordt beschreven in de RFC-standaarden, gemakkelijk voorspelbaar, dus het gebruik van willekeurige getallen om identifiers te genereren is een goed idee om spoofing-aanvallen te helpen voorkomen. Op dezelfde manier is het UDP-poortnummer waarop de naamomzettingsserver verzoeken accepteert en reageert ook gemakkelijk voorspelbaar en kan worden gewijzigd in een willekeurig nummer.

Er zijn open source-programma's voor deze doeleinden, maar als u deze gebruikt, moet u er rekening mee houden dat ze een kleine vertraging in het verwerkingsproces van verzoeken introduceren. Een relatief nieuwe en populaire beveiligingstechnologie is DNSSEC (DNS Security Extensions). Het beschermt clients en servers tegen aanvallen die de DNS-cache wijzigen door records te ondertekenen met behulp van codering met openbare sleutels. De aanvrager en de responder werken op dezelfde manier als SSL en brengen een vertrouwde verbinding met elkaar tot stand, en zodra die tot stand is gebracht, begint het naamomzettingsproces.

Zodra het naamomzettingsproces is voltooid, wordt de sessie opnieuw ingesteld, waardoor de veiligheid van beide partijen behouden blijft. DNSSEC-technologie is geïmplementeerd op de meeste servers van internetproviders ter wereld.

DNS-interferentie is een veelvoorkomend type aanval. Het begint met het misbruiken van protocolfouten en leidt ertoe dat de aanvaller toegang krijgt tot de IT-infrastructuur of computers gebruikt om andere soorten aanvallen uit te voeren, zoals phishing. Op vrije software gebaseerde systemen zijn ook vatbaar voor deze aanvallen, dus systeembeheerders moeten technieken begrijpen en gebruiken om hun infrastructuur te beschermen tegen gegevensverlies of diefstal.

Dit artikel maakt deel uit van een reeks artikelen over cyberaanvallen, geschreven door dezelfde auteur (Prashant Phatak). Andere artikelen in deze serie.

Spoofing is een nogal interessante aanvalsmethode, die veel cybersecurityprofessionals verwaarlozen. Maar tevergeefs, heel erg tevergeefs. Uit dit artikel zul je begrijpen hoe misleidend deze diverse wereld kan zijn. Geloof je ogen niet!

WAARSCHUWING

Alle informatie wordt uitsluitend ter informatie verstrekt. Noch de redactie, noch de auteur zijn verantwoordelijk voor eventuele schade veroorzaakt door de materialen van dit artikel.

Intro

Ik hoor vaak van mijn collega's dat spoofing als aanvalsvector niet eens in overweging mag worden genomen. Ik kan je echter verzekeren dat als de spoofingmethoden zorgvuldig worden uitgedacht, ze voor heel veel dingen kunnen worden gebruikt. Bovendien zijn de omvang en de resultaten van dergelijke aanvallen soms catastrofaal. Nadat ik je ogen eenmaal heb bedrogen, zal ik je tenslotte nog meer misleiden. Het belangrijkste argument ten gunste van het feit dat spoofaanvallen een reëel gevaar vormen, is dat geen enkele persoon, inclusief professionals, er immuun voor is. Hierbij moet worden opgemerkt dat spoofing op zichzelf niets oplevert: om een ​​echte hackeraanval uit te voeren, moet je gebruik maken van post-exploitatie. In de meeste gevallen zijn de doelstellingen van post-exploitatie het standaard overnemen van controle, het opeisen van privileges, de massale verspreiding van malware en, als gevolg daarvan, diefstal van persoonlijke gegevens en elektronische digitale sleutels van banksystemen, met verder witwassen van geld tot gevolg. In dit artikel wil ik eerst vertellen welke spoofing-methoden er in het algemeen bestaan, en ten tweede wil ik je in detail vertellen over enkele moderne benaderingen. Uiteraard wordt alle informatie uitsluitend aan u verstrekt om u te helpen uzelf tegen dit soort aanvallen te beschermen.

Het verleden en heden van spoofing

Aanvankelijk werd de term ‘spoofing’ gebruikt als netwerkbeveiligingsterm, waarmee de succesvolle vervalsing van bepaalde gegevens werd bedoeld om ongeoorloofde toegang tot een bepaalde netwerkbron te verkrijgen. In de loop van de tijd begon deze term op andere gebieden van informatiebeveiliging te worden gebruikt, hoewel de meeste zogenaamde ouderwetse specialisten het woord ‘spoofing’ tegenwoordig alleen maar blijven gebruiken om het soort netwerkaanvallen te verduidelijken.

De eerste IDN-klonen

Een aanval waarbij gebruik werd gemaakt van IDN-homografen werd voor het eerst beschreven in 2001 door Evgeniy Gabrilovich en Alex Gontmakher van het Technion Institute of Technology in Israël. Het eerste bekende geval van een succesvolle aanval met deze methode werd in 2005 openbaar gemaakt tijdens de ShmooCon-hackerconferentie. Hackers zijn erin geslaagd een nepdomein paypal.com (xn-pypal-4ve.com in Punycode) te registreren, waarbij de eerste letter a Cyrillisch is. Een bericht op Slashdot.org bracht de kwestie onder de aandacht van het publiek, en zowel browsers als beheerders van veel topniveaudomeinen ontwikkelden en implementeerden tegenmaatregelen.

Dus toen het netwerk nog maar in de kinderschoenen stond, waren de meeste inspanningen van programmeurs en ontwikkelaars vooral gericht op het optimaliseren van de algoritmen voor de werking van netwerkprotocollen. Veiligheid was niet zo cruciaal als nu en kreeg, zoals vaak het geval is, zeer weinig aandacht. Als gevolg hiervan krijgen we banale en fundamentele fouten in netwerkprotocollen, die vandaag de dag nog steeds bestaan, ondanks verschillende soorten patches (omdat geen enkele patch een logische protocolfout kan patchen). Dit vereist totale veranderingen, die het Netwerk in zijn huidige vorm eenvoudigweg niet kan overleven. Bijvoorbeeld in het artikel “Aanvallen op DNS: gisteren, vandaag, morgen” (][ #5 2012) Ik had het over de catastrofale fundamentele kwetsbaarheden in DNS-systemen: het gebruik van UDP (dat, in tegenstelling tot TCP/IP, onveilig is omdat het geen ingebouwd mechanisme heeft om spoofing te voorkomen) en lokale cache.

Vectoren

Afhankelijk van de doelen en doelstellingen kunnen spoofingvectoren worden onderverdeeld in lokale en netwerkrichtingen. Dit zijn degenen die we in dit artikel zullen bekijken. Het doelwit van lokale vectoraanvallen is meestal het besturingssysteem zelf dat op de computer van het slachtoffer is geïnstalleerd, evenals bepaalde soorten applicaties, die vaak aanvullende analyse vereisen, afhankelijk van de situatie. De doelwitten van netwerkvectoraanvallen zijn daarentegen abstracter. De belangrijkste zijn de componenten van informatiesystemen, vertegenwoordigd door zowel lokale als mondiale netwerken. Laten we eens kijken naar de belangrijkste vormen van spoofing.

Spoofing TCP/IP & UDP - aanvallen op transportniveau. Vanwege fundamentele fouten bij de implementatie van de TCP- en UDP-transportprotocollen zijn de volgende soorten aanvallen mogelijk:

• IP-spoofing - het idee is om een ​​IP-adres te vervangen door de waarde van het bronveld in de hoofdtekst van het IP-pakket te wijzigen. Het wordt gebruikt om het adres van de aanvaller te vervalsen, bijvoorbeeld om een ​​antwoordpakket naar het gewenste adres te sturen;
• ARP-spoofing is een aanvalstechniek in Ethernet-netwerken waarmee u verkeer tussen hosts kunt onderscheppen. Gebaseerd op het gebruik van het ARP-protocol;
• DNS Cache Poisoning - vergiftiging van de DNS-cache van de server;
• NetBIOS/NBNS-spoofing is gebaseerd op de eigenaardigheden van het omzetten van lokale machinenamen binnen Microsoft-netwerken.

Verwijzerspoofing - vervanging van een verwijzer.

Vergiftiging van netwerken voor het delen van bestanden - phishing in netwerken voor het delen van bestanden.

Beller-ID-spoofing - vervanging van het bellende telefoonnummer in VoIP-netwerken

E-mailadres spoofing - vervanging van het e-mailadres van de afzender.

GPS-spoofing - vervanging van pakketten van een satelliet om het GPS-apparaat in verwarring te brengen.

Voicemailspoofing - vervanging van voicemailnummers met als doel de wachtwoorden van het slachtoffer te phishing.

SMS-spoofing is een spoofing-methode die gebaseerd is op het vervangen van de afzendernummers van een SMS-bericht.

De laatste ontwikkelingen op het gebied van spoofing

De meest voorkomende technieken zijn al behoorlijk oud en afgezaagd. Het mondiale netwerk wemelt letterlijk van de informatie over mogelijke variaties in de werking ervan en de bescherming daartegen. Vandaag zullen we kijken naar een aantal van de nieuwste spoofing-methoden, waarvan het gebruik alleen maar aan kracht wint, van lokale vectoren tot netwerkvectoren. Alles in orde dus.

Flamer en de schandalige spoofing van Microsoft-certificaten

Microsoft-beveiligingsadvies (2718704) - Ongeautoriseerde digitale certificaten kunnen spoofing tot gevolg hebben. Er werd iets nogal interessants gevonden in kopieën van de beruchte Flamer-spionagebot: op basis van de resultaten van reverse engineering van de componenten van deze malware werd een stuk code ontdekt dat verantwoordelijk was voor het uitvoeren van spoofing-aanvallen zoals phishing. Door het verstrekken van originele certificaten van grote bedrijven te simuleren, voerde de bot een MITM-aanval uit, met als doel persoonlijke gegevens van bedrijfsnetwerkgebruikers te onderscheppen en deze vervolgens naar de server van de ontwikkelaar te sturen. Dit spoofing-incident kreeg beveiligingsadvies nr. 2718704 met de ernstgraad Hoog.

Spoofing in OS 1. Extensiespoofing - spoofing van bestandsextensies

Een techniek die het levenslicht zag dankzij de ontwikkelingen van een Chinese onderzoeker op het gebied van informatiebeveiliging Zhitao Zhou. De essentie van deze techniek is om het controleteken 0x202E (RLO) in de bestandsnaam te gebruiken, waardoor u de volgorde van de tekens kunt wijzigen bij het weergeven van de bestandsnaam in Windows Verkenner (explorer.exe). Hier is een voorbeeld van het gebruik van deze eenvoudige techniek:

Supermuziek geüpload om 15.00 uur.SCR

Het 3pm.SCR-bestand is niets meer dan een uitvoerbaar bestand dat bepaalde functies implementeert (een Trojaans programma - Noot van de redactie). Als u het controleteken 0x202E aan het begin van de bestandsnaam “3pm.SRC” invoegt (zie figuur 1), dan is de volgorde van de tekens omgekeerd en wordt de bestandsnaam anders weergegeven in Windows Verkenner:

Supermuziek geüpload door RCS.mp3

Om het bestandspictogram te wijzigen, moet u een resource-editor gebruiken (Restorator, Resource Hacker). Deze techniek is ontworpen voor een onzorgvuldige gebruiker die dit bestand voor een nummer kan aanzien en het kan openen door erop te dubbelklikken, waardoor een kwaadaardig programma wordt gestart. Helaas werkt deze techniek niet in programma's vergelijkbaar met Explorer die Unicode ondersteunen. Hieronder staat de C#-code die de bestandsnaam wijzigt door het controleteken 0x202E ervoor te plaatsen:

Public Sub U_202E(bestand As String, extensie As String) Dim d As Integer = bestand.Lengte - 4 Dim u As Char = ChrW(823) Dim t As Char() = extension.ToCharArray() Array.Reverse(t) Dim dest As String = file.Substring(0, d) & u & New String(t) & file.Substring(d) System.IO.File.Move(file, dest) End Sub

2. Bestandsnaamspoofing - de bestandsnaam klonen

Deze techniek werd gepresenteerd door de Japanse onderzoeker Yosuke Hasegawa op de Security-Momiji-conferentie. Het is gebaseerd op het gebruik van tekens met lengte nul (ZERO WIDTH Characters), die op geen enkele manier invloed hebben op de weergave van de bestandsnaam (zie figuur 2). Hieronder staan ​​alle personages uit deze categorie:

U+200B (RUIMTE NUL BREEDTE) - U+200C (ZERO BREEDTE NIET-VERBINDINGSRUIMTE) - U+200D (ZERO BREEDTE VERBINDINGSRUIMTE) - U+FEFF (ZERO BREEDTE GEEN BREDE SPACE) - U+202A (LINKS-NAAR RECHTS INBEDDEN)

Bovendien is het mogelijk om UTF-codering te gebruiken om de namen van bestaande bestanden te vervalsen. Deze techniek wordt vaak gebruikt door moderne malware. Ik kwam voorbeelden tegen van malware die dit soort aanvallen uitvoerde. De TrojanDropper:Win32/Vundo.L-malware (gebruikt voor het phishing van de sites vk.com, vkontakte.ru, *odnoklassniki.ru) gebruikt bijvoorbeeld precies deze techniek.

Het bestand %SystemRoot%\system32\drivers\etc\hosts werd gekopieerd naar een “clone” hosts-bestand met het UTF “o”-teken (0x043E), waarna het originele hosts-bestand het verborgen bestandskenmerk kreeg en de inhoud ervan werd overschreven met de volgende vermeldingen toegevoegd:

92.38.66.111 odnoklassniki.ru 92.38.66.111 vk.com 92.38.66.111 vkontakte.ru

Spoofing van webbrowsers 1. Statusbalk/linkspoofing

Het principe van deze aanval is het dynamisch vervalsen van het adres van een hypertekstlink ( ). Het slachtoffer beweegt bijvoorbeeld de muiscursor over een link, waarna in de statusbalk van de browser het adres wordt weergegeven waar de link naartoe leidt. Na het klikken op de link vervangt de lastige JavaScript-code het overgangsadres in de dynamiek. Een onderzoeker die ik ken, bekend onder de bijnaam iamjuza, was bezig met het bestuderen en ontwikkelen van een PoC voor het gebruik van deze techniek in de praktijk, maar zijn ontwikkelingen waren niet universeel en werkten alleen in specifieke browsers. Na het uitvoeren van een soortgelijk onderzoek kreeg ik betere resultaten, omdat ik een universele werking van deze spoofertechniek voor alle browsermotoren kon bereiken. Proof-of-Concept gepubliceerd op 1337day.com. De technische implementatie ziet er als volgt uit:

Methode this.href=":