Nieuwe man-in-the-middle-aanval voor Windows blootgelegd

Beveiligingsonderzoekers hebben een nieuwe aanval voor een oude kwetsbaarheid in Windows beschreven waarmee kwaadwillenden dataverkeer door kunnen sluizen naar eigen systemen om zo inlognamen en wachtwoorden buit te maken.

De onderzoekers hebben de kwetsbaarheid Redirect to SMB gedoopt en deze vindt zijn oorsprong in een kwetsbaarheid die al in 1997 werd ontdekt maar nooit werd gedicht. Als Internet Explorer een url geserveerd kreeg met het woord 'file', zoals file://1.1.1.1, probeerde Windows verbinding te maken en zich te authenticeren bij een smb-server, zoals in het voorbeeld met ip-adres 1.1.1.1. De onderzoekers vonden hier een nieuwe aanval voor die met alle versies van Windows werkt.

Aanvallers kunnen http-requests onderscheppen en http-redirect gebruiken om verkeer van systemen door te sluizen naar kwaadaardige smb-servers. Veel programma's handelen http-redirects op de achtergrond af. Als de redirect een url met het 'file://'-type is, zal Windows automatisch tot authenticatie bij de smb-server overgaan en de credentials van de gebruiker overhandigen. De aanvaller kan de inlognamen en wachtwoorden onderscheppen en de versleuteling ongedaan maken via bijvoorbeeld een brute-force aanval.

Aanvallers hoeven een doelwit dus niet meer via de browser naar een smb-server door te sluizen maar kunnen wachten op de geautomatiseerde http-requests van applicaties op de achtergrond, om zo aanzienlijk sneller en heimelijk smb-logs met persoonlijke inlog-informatie te verkrijgen. "We hebben vier veelgebruikte Windows-api-functies geïdentificeerd die redirects van http of https naar smb toestaan", schrijft beveiligingsbureau Cylance, dat de aanvalsmethode ontdekte. "Uit tests blijkt dat veel softwarefunctionaliteit zoals updaters en usage reporting-tools, die api-functies gebruiken."

Cylance constateerde dat de methode in combinatie met veel software werkt, waaronder Adobe Reader, Apple QuickTime, Apple Software Update, Internet Explorer, Windows Media Player, Excel 2010, Symantec’s Norton Security Scan, AVG Free, TeamViewer en Github for Windows.

De kans op grootschalig misbruik is beperkt, maar gerichte aanvallen door geavanceerde aanvallers, via kwaadaardige advertenties en via bijvoorbeeld open wifi-netwerken acht Cylance wel mogelijk. Microsoft heeft de kwetsbaarheid niet gedicht. In de tussentijd kunnen gebruikers de tcp-poorten 139 en 445 voor smb-verkeer sluiten.

Reacties (48)

[johnkeates]

Tsja, dan komt er nu vast een sandbox of filter die overhead gaat veroorzaken. Dan moet een redirect van HTTP naar SMB opeens gecontroleerd worden, of er moet een vlag gelezen worden of het wel of niet mag... dat gezegd, HTTP heeft volgens mij helemaal geen voorziening om naar andere protocollen te redirecten, is dit misschien vooral een probleem in Microsoft's implementatie? Andere URL schemes dan HTTP of HTTPS ondersteunen valt buiten de HTTP spec, maar HTTP redirects vallen er weer binnen. Dus je zou kunnen stellen dat een HTTP API nooit HTTP redirect naar non-HTTP URI's zou moeten toestaan. Een HTTP payload met daarin een redirect zou dan wel weer moeten kunnen.

[Alfa1970]

Ik ben nog niemand tegengekomen die verkeer voor deze twee poorten op z'n firewall toestaat. Naar binnen niet en naar buiten niet.
Dus ik zie het niet zo'n vaart lopen.
Dat beperkt het feitelijk tot een intern netwerk probleem.

URI is een standaard op zich (RFC 2396), dus dat de HTML standaard daar niet al te veel over zegt lijkt me logisch.

Gopher, Mailto, FTP, File, het zijn allemaal valide Uri's.
En zoals Curry684 omschrijft, allemaal valide te gebruiken in een redirect.

[Lennie]

Ik ben benieuwd of je niet gewoon een poort-nummer kunt toevoegen in de URL:

file://1.1.1.1:4444/

[Alfa1970]

Zojuist getest, en gezien dat dat niet werkt.

[Reactie gewijzigd door Alfa1970 op 24 juli 2024 14:47]

[jimbo123]

Nee? Ik denk dat 90% van de particuliere gebruikers met een fritzbox (xs4all) of een experiabox (kpn) of een modem van Ziggo deze poorten uitgaand open heeft staan! Volgens mij kunnen deze routers niet eens uitgaande poorten blokkeren. En in de Windows Firewall staat uitgaand verkeer standaard volledig open!

[Alfa1970]

Gevalletje beroeps deformatie mijnerzijds en daardoor niet duidelijk genoeg.

Ik heb het over een echte (professionele) firewall, en daar staat alles dicht tenzij je het expliciet zelf open zet.

De zaken die je aanhaalt zijn niet serieus een firewall te noemen in mijn ogen.

[johnkeates]

We hebben het over MITM attacks. Je moet dus al een man in the middle positie aangenomen hebben he.

[InsanelyHack]

Dat beperkt het feitelijk tot een intern netwerk probleem.

Dat is een achterhaalde conclusie. Andere malware die wel met de buitenwereld in verbinding staat kan de interne exploit misbruiken waardoor de exploit dus ook extern te misbruiken is.

[Alfa1970]

Daar zat ik inderdaad ook aan te denken nadat ik het gepost had.
Maar je moet al heel wat bewerkstelligen wil je het voor elkaar krijgen.
En daar komt bij, als je het component intern krijgt dat dit bewerkstelligd, dan zijn er wel makkelijkere manieren om gegevens te stelen dan deze methode, want dan kun je net zo goed een keyboard logger installeren de gegevens over poort 80 naar buiten stuurt. Over die poort ben je er vrij zeker van dat het gaat lukken. In de meeste gevallen toch..

[Reactie gewijzigd door Alfa1970 op 24 juli 2024 14:47]

[InsanelyHack]

Ja en Nee (snap trouwens niet waarom we een 0 moderatie krijgen maar goed) de exploit is te misbruiken als MITM attack waardoor een node of gebruiker met een kwetsbare werkplek toch misbruikt kan worden om informatie uit te lezen waar deze gebruiker normaal gesproken helemaal geen toegang heeft. Dus de werkplek van de receptioniste wordt misbruikt door een MITM attack om vervolgens login gegevens te ontfutselen van de RD share. Dit alles te besturen extern via malware op de receptie PC.

[Alfa1970]

Volgens mij steekt de vulnerability zo niet in elkaar.
Voor zover ik het begrijp zorg je er door de MITM voor dat er een redirect plaatsvindt naar een file://.
Dat kan een share zijn.
De webbrowser zal vervolgens automatisch proberen te authenticeren op de share.
Maar dat zal wel zijn met de login gegevens van de gebruiker die de webbrowser op dat moment aan het gebruiken is.

Als die gebruiker toegang heeft tot de share, ok, dan weet je dat.
Maar als die gebruiker geen toegang heeft, dan is het hoogst haalbare de login credentials van die gebruiker.
En daar moet je dan nog wel eerst een brute force op toepassen.
Natuurlijk zijn dat waardevolle gegevens om te achterhalen, mja, met een keylogger heb je volgens mij meer zekerheid, want een brute force is nog geen garantie dat je binnen afzienbare tijd de encryptie kan kraken..

[curry684]

De HTTP standaarden schrijven terecht niks voor op dat gebied. Bij een 3xx redirect hoort een server de Location header te zetten met een absolute URI. Daar mag vervolgens als altijd eender welk protocol in gebruikt worden, van https tot tel, en van mailto tot file.

Zie ook http://www.w3.org/Protoco...c2616-sec14.html#sec14.30, IE conformeert prima - de automatische authenticatie is het potentiële probleem.

[Reactie gewijzigd door curry684 op 24 juli 2024 14:47]

[Engineer]

Als het met een http redirect header niet lukt, lukt het allicht wel met een javascript redirect. Nooit geprobeerd om naar file:// te redirecten, maar volgens mij kun je virtueel in de adres balk typen met location.href = "ergens".

http://www.w3schools.com/jsref/prop_loc_href.asp

Specifies the URL of the link.
Possible values:

An absolute URL - points to another web site (like location.href="http://www.example.com/default.htm")
A relative URL - points to a file within a web site (like location.href="default.htm")
An anchor URL - points to an anchor within a page (like location.href="#top")
A new protocol - specifies a different protocol (like location.href="ftp://someftpserver.com", location.href="mailto:[e-mail]" or location.href="file://host/path/example.txt")

[Reactie gewijzigd door Engineer op 24 juli 2024 14:47]

[Dysmael]

Dit is alles behalve nieuw. Exact wat hier wordt beschreven heb ik een aantal weken geleden in een testomgeving uitgevoerd. I.c.m. SMB Relay (smbrelayx.py uit Impacket) kan je in een domein bij een andere machine authenticeren en zo vaak vrij eenvoudig volledig toegang krijgen tot de systemen.

Je kan proxy worden door b.v. WPAD-responder, root bridge worden (STP) of IPv6 gateway advertisements en dan met een tool zoals Burp suite de http-stream aanpassen en opgehaalde html-code wijzigen zodat daar een verwijzing naar een UNC pad in staat. Het resultaat is dat Windows zal willen authenticeren bij dat UNC pad.

Wat ik niet teruglees is de beperking dat dit alleen op interne netwerken werkt.

[Neko Koneko]

Dit is alles behalve nieuw.

Daarom staat er in het artikel dat de kwetsbaarheid al sinds 1997 bekend is

[atlaste]

En PS dit heeft ook duidelijk nut, nl. Enterprise Search, waar je dit kan gebruiken om links te genereren naar files op het systeem waar de gebruiker toegang voor heeft. Op deze manier link ik al sinds 1999 files vanaf een Enterprise Search engine, waarbij je de authorizaties van de gebruiker in tact houd. Super nuttig. :-)

Andere browsers werken via file://, smb:// en zo nog het een en ander. Ik dacht dat KDE overigens, de prefix file:///// [...] nodig had.

[Verwijderd]

De aanvaller kan de inlognamen en wachtwoorden onderscheppen en de versleuteling ongedaan maken via bijvoorbeeld een brute-force aanval.

Waarop moet die aanval dan plaatsvinden?
Als je die gegevens onderschept heb je toch geen echte SMB server waartop je die gegevens kan brute forcen?
Tenzij je zelf al op het private netwerk zit en dan kun je sowieso als je iemands http requests kan onderscheppen sowieso al informatie onderscheppen waarmee je kan brute forcen

[Reactie gewijzigd door Verwijderd op 24 juli 2024 14:47]

[johnkeates]

Als je credentials hebt overal waar je die credentials kan gebruiken. Stel dat je op een intern netwerk zit en daar lekkere MITM aanvallen zit te doseren, dan kan je dus credentials onderscheppen die je toegang tot afgeschermde services geeft. Denk aan SMB shares op andere servers op het netwerk, of met NT credentials toegang tot AD en Exchange. Of in het geval van password recycling aan andere services die door de gebruiker gebruikt worden, om dat je dan met datzelfde wachtwoord ook bij die services van authenticeren.

[Verwijderd]

Ja, maar als je op een intern netwerk een MITM kan uitvoeren dan kun je de credentials toch ook onderscheppen zonder een redirect aanval?
Gewoon door het verkeer naar de betreffende servers die je wilt hacken direct al te onderscheppen.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 14:47]

[johnkeates]

Ja, maar dat maakt een downgrade attack lastiger en als je dan bijv. met kerberos zit wordt het al helemaal lastig. Wat je wil is bijv. NTLM hashes onderscheppen. Dat kan alleen als die verstuurd worden, en dat gebeurt alleen als de SMB server dat nodig heeft Met AD is dat vaak niet zo als kerberos gewoon draait. Bovendien kan je dan niet een client forceren een SMB authenticatie te doen wat het wat lastiger maakt om doelgericht te tappen. Stel dat iemand er niet is maar de computer wel aan staat, dan kan je gewoon alle HTTP requests redirecten, en om dat windows credentials stuurt die opgeslagen zijn krijg je ook dan data binnen Komt er niet eens een persoon aan te pas!

[Reactie gewijzigd door johnkeates op 24 juli 2024 14:47]

[Bierfustje]

NT hashes kan je niet onderschappen aangezien die niet over het network gaan...
NTLM is een challenge response authenticatie mechanisme. Een mechanisme dat uiteraard middels brute-force te kraken is en waarbij de sterkte van je wachtwoord cruciaal is. Lees: gebruikers met een sterk wachtwoord zullen hier geen last van hebben

[johnkeates]

Dat is waar, maar als je als MITM attacker de challenges kan vaststellen (en dan eerst een NTML v1 downgrade doet) kan je dat net zo makkelijk met een rainbow table gebruiken om het originele wachtwoord te bemachtigen.

Het idee van een challenge is dat het versturen van het wachtwoord niet meer nodig is, maar gezien je als je vooraf een challenge kan bedenken en daar alle mogelijke wachtwoorden voor kan uitrekenen met de challenge responses is dat dus niet anders dan een andere hash reversing. Het is dan wel weer zo dat de challenge niet bepaald lang is, dus misschien krijg je dan meer 'last' van collisions, maar helemaal zeker weet ik dat niet.

[goarilla]

Je hebt dan een NTLM hash ofzo en je wilt het plain-text passwoord, want pass-the-hash heeft maar een beperkt bereik.

[Verwijderd]

Maar als apps gewoon HTTPS inlogschermen gebruiken zijn ze niet zo kwetsbaar toch? Of kan men die vervangen door HTTP varianten?

[Jaahp]

Zoals in het voorbeeld waarbij een .gif wordt aangevraagd hoeft de request helemaal niet naar een inlogpagina te leiden. Zolang als er een MITM attack mogelijk is kan de request door de aanvaller worden afgehandeld, de aanvaller kan dan zeggen 'nee, het plaatje staat hier: file://1.3.3.7/', en dan stuurt het slachtoffer automatisch zijn gebruikersnaam en wachtwoord (als het goed is via een beveiligde verbinding) naar file://1.3.3.7/, de binnenhaalserver van de aanvaller.

[RoestVrijStaal]

Zo te lezen in de gelinkte artikelen is er nog veel onduidelijk.
Hoe zit dit trouwens met Samba? Kunnen andere browsers dan IE de gebruikte exploit ook niet triggeren?

[Verwijderd]

Bij een samba installatie heb je normaal aparte "smb" users gedefinieerd. Samba gebruikt standaard een aparte passwd file en kan me niet inbeelden dat iemand daar een root user (als dat überhaupt al toegestaan is) aan toevoegd.

[Soldaatje]

Als ik het goed begrijp is dit totaal niet gevaarlijk als je een stevig wachtwoord gebruikt, 8+ karakters.
Het enige wat ze krijgen is je inlog en versleutelde wachtwoord, die moeten ze dan gaan brute-forcen.
En stel dat ze het weten te kraken, dan kunnen ze nog niks, zonder lokale toegang.

[Bierfustje]

Klopt, hoewel een 8 karakter wachtwoord in een enkel uur te kraken is met hedendaagse consumenten hardware.
Gewoon een zinnetje gebruiken en de attack is kansloos

[Bierfustje]

Ik heb fysiek toegang tot een willekeurig netwerk en reageer op ARP requests --> klaar
Ik heb fysiek toegang tot een willekeurig netwerk en reageer op DNS requests --> klaar

Ongeacht het besturingsysteem, wanneer de aanwezige veiligheidsmaatregelen tegen dit soort MitM attack uit staan, kan je voor elk OS een MitM uitvoeren.
En ongeacht het authenticatie protocol, wanneer je dit onderschept (ivm je MitM attack) en het betreft een gebruiker met een zwak* wachtwoord, dan zal je wachtwoord eenvoudig gekraakt worden.

*: denk bijvoorbeeld aan het veel gebruikte 8 karakter wachtwoord, of een wachtwoord dat in een woordenboek staat (al dan niet met substitution karakters (e.g. de @, $, 0, 3 en !), en/of non-alfebatische karakters aan het einde (e.g. 01, !, etc)).

[Jaahp]

Dat van die advertenties vind ik nog best een interessant scenario.

Stel ik bied een advertentie aan op mijn server www.schadelijkewebsite.nl/plaatjes/muis.jpg en deze advertentie wordt op andere sites geplaatst. Iedereen die deze site bezoekt doet een request naar mijn plaatje, maar in plaats van een plaatje stuurt mijn server een omleiding naar file://schadelijkewebsite.nl/wachtwoordverzameling, IE gaat hier dan op in en stuurt automatisch een request met naam en wachtwoord naar file://schadelijkewebsite.nl/wachtwoordverzameling om 'in te loggen', aan de serverkant wordt dit opgeslagen en zo makkelijk een database van ip adressen, namen en wachtwoorden gemaakt.

[RoffaboyS]

Goed opletten tot dat microsoft het gepatched heeft als je echt zeker wilt zijn kun je het beste de tcp-poorten uitzetten.

[raro007]

patchen? Ze hebben al meer dan 18 jaar niks tegen gedaan! !!

[RoffaboyS]

Ja misschien in windows 11 of 12 wie weet hahaha!

[Amiga3000]

Tja wie zijn firewall voor die poorten heeft open staan is gewoon zelf niet goed bezig.
En ja als ik een virus of trojan heb geinstalleerd kan dit ook allemaal en zelfs via http,

Onzinnig artikel, uitkomst als je niet weet waar je mee bezig bent ga dan niet je systemen op internet aansluiten.

Ook wordt er vaak bij intranet applicaties automatisch ingelogd en werkt dit mechanisme ook.

Het is dus ook geen exploit, explorer kan gewoon direct bij bestanden en ja dan moet je authenticeren.
En ja als je dan op de machine een applicatie hebt draaien die zich rechten heeft laten krijgen om mee te luisteren dan kan je vervelende dingen doen.

Dus volgens mij zet elke firewall tegenwoordig Netbios verkeer uit en kan het dus al jaren geen kwaad.

En voor de mensen die zelf zaken veranderen zorg ervoor dat iemand met verstand van de materie je helpt.