image

Ernstig lek in meeste Windows applicaties

vrijdag 20 augustus 2010, 12:57 door Redactie, 10 reacties

Niet veertig, maar bijna alle Windows applicaties hebben te maken met een ernstig 'nieuw' soort beveiligingslek. "Bijna alle Windows applicaties zijn kwetsbaar", aldus Mitja Kolsek, CEO van Acros Security. Het Sloveense beveiligingsbedrijf ontdekte het probleem een aantal maanden geleden. Sindsdien heeft het bedrijf meer dan tweehonderd lekke applicaties ontdekt, waarin meer dan vijfhonderd verschillende bugs zitten. Microsoft zou vier maanden geleden al zijn ingelicht.

Details
Het idee was om de details pas te onthullen als er een patch voor was, maar gisteren liet beveiligingsonderzoeker H.D. Moore via Twitter weten dat hij veertig Windows applicaties met een gemeenschappelijk lek had ontdekt. Hij ontdekte de kwetsbaarheid bij het onderzoek naar het Windows LNK-lek. Om welke programma's het gaat wilde de hacker niet vertellen, maar inmiddels zou er al een module voor hackertoolkit Metasploit klaarstaan.

"We hebben meer dan 220 applicaties van ongeveer de honderd grootste leveranciers onderzocht, en ontdekt dat bijna elke applicatie het lek heeft", zegt Kolsek tegenover IDG. Het beveiligingsbedrijf heeft inmiddels een speciale tool gebouwd die onderzoekers laat zien welke applicaties kwetsbaarzijn. Het probleem zit in de manier waarop de meeste applicaties dll en uitvoerbare bestanden laden.

Patch
Kolsek noemt het nieuwe lek "remote binary planting" en het zou eenvoudig te misbruiken zijn. De aanval is voornamelijk mogelijk omdat Windows de huidige directory in de zoekopdracht toevoegt bij het laden van uitvoerbare bestanden. Aanvallers kunnen dat gebruiken om Windows applicaties kwaadaardige bestanden te laten laden. De meeste Windows applicaties zouden de functionaliteit gebruiken om te kunnen werken, wat het lastig maakt voor Microsoft om één beveiligingsupdate uit te rollen.

Microsoft zou echter wel de werking van de functionaliteit kunnen aanpassen, zo merkt Kolsek op. Toch zou deze oplossing talloze applicaties kunnen breken. De CEO verwacht echter dat Microsoft snel met een oplossing komt. Tijdens de DeepSec beveiligingsconferentie geeft Acros een lezing over remote binary planting, waardoor het goed mogelijk is dat Microsoft hiervoor het probleem zal oplossen.

Oud
Volgens Moore gaat het misschien niet om een nieuw lek, maar zou het probleem al tien jaar geleden zijn gerapporteerd. Hij wijst naar deze melding, die een 'Microsoft Windows DLL Search Path Weakness' beschrijft.

"Als een programma op Microsoft Windows wordt uitgevoerd, kan het aanvullende code in DLL-bestanden vereisen. Deze bestanden worden dynamisch gelokaliseerd tijdens run time en indien nodig geladen. Er bestaat een zwakte in het algoritme dat wordt gebruikt voor het lokaliseren van deze bestanden." Deze omschrijving lijkt erg veel op het probleem dat Acros ontdekte. Moore zal maandag meer details over het probleem prijsgeven.

Reacties (10)
20-08-2010, 13:43 door Anoniem
Dus wat hij feitelijk zegt is dat je het spul alleen van een 'current directory' zonder write access moet draaien. Als je er tenslotte niks neer kunt zetten, heb je het probleem ook niet... En andere directories met code zijn - neem ik aan- voor een normal user al read-only...
20-08-2010, 13:55 door SirDice
Door Anoniem: Dus wat hij feitelijk zegt is dat je het spul alleen van een 'current directory' zonder write access moet draaien. Als je er tenslotte niks neer kunt zetten, heb je het probleem ook niet... En andere directories met code zijn - neem ik aan- voor een normal user al read-only...
Bedenk dat de CWD meestal de gebruiker z'n home directory is. Zeker in het geval een applicatie via explorer wordt gestart.

Ik denk dat Moore gelijk heeft en dat het hier om het alom bekende DLL search path gaat.
20-08-2010, 14:16 door Jehjoa
Deze zwakheid is inderdaad al jaren bekend, en is de reden dat ik waar mogelijk altijd een volledig pad + bestandsnaam doorgeef aan LoadLibrary().
20-08-2010, 15:51 door [Account Verwijderd]
[Verwijderd]
20-08-2010, 16:26 door Anoniem
Sinds de invoering van dll bestanden bestaat dit al. En tegelijkertijd de achilleshiel van alle applicaties die hier geen voorzorg maatregelen hebben genomen. Ik draai al mee sedert MSDOS 2.x en eerlijk gezegd lach ik me constant helemaal wild.

En de reactie van Peter V valt me een beetje tegen, wist je dat echt niet?

Heden worden echter vroegere bugs als lekken gezien en die omslag zagen we de laatste jaren gebeuren en is ook deels financial driven voor vele partijen aan beide kanten.
20-08-2010, 16:38 door Anoniem
Het bekende Windowsbashen is er weer hoor. Is iemand zeker geschrokken van al die lekken in andere software, dus latren we Microsoft maar weer eens te grazen nemen. Nou, ik slaap er geen seconde minder om. Ik heb nooit, maar dan ook nog nooit in de praktijk ook maar iets gezien van al die "vreselijke" lekken.
20-08-2010, 22:03 door Anoniem
beveiligingsbedrijf heeft inmiddels een speciale tool gebouwd die onderzoekers laat zien welke applicaties kwetsbaarzijn.


Is deze tool ook voor huis en tuin gebruikers? en zo ja waar kunnen we hem downloaden?
21-08-2010, 11:31 door Anoniem
De reden waarom dit altijd kan worden gebruikt is omdat de API die de DDL aanbied onvoorwaardelijk kan worden gebruikt.
De informatie die word toegespeeld kan dan vervolgens worden gelogd of iets.

Als de interface maar het zelfde is maakt het niet waar deze vandaan komt.

En het spijt me om te zeggen dat Linux ook dit probleem (kan) hebben, want via /etc/so.ld.conf kan je paden opgeven, die worden gebruikt om Shared Objects te zoeken. Het is wel moeilijk(er) omdat je root-rechten nodig hebt. Maar het is mogelijk.
23-08-2010, 09:11 door Anoniem
Van http://msdn.microsoft.com/en-us/library/Aa297182:

With both implicit and explicit linking, Windows first searches the set of pre-installed DLLs such as the performance library (KERNEL32.DLL) and the security library (USER32.DLL). Windows then searches for the DLLs in the following sequence:

1. The directory where the executable module for the current process is located.

2. The current directory.

3. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.

4. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.

5. The directories listed in the PATH environment variable.

Note that the LIBPATH environment variable is not used.

Wat er waarschijnlijk "nieuw" is, is dat men een simpele manier heeft gevonden om je vanuit een webpagina je huidige directory een WebDAV URL te maken (waar een zooi kwaadaardrige dlls staan) en vervolgens een lek Windows programma aan te roepen.

Volgens http://msdn.microsoft.com/en-us/library/ms684175%28VS.85%29.aspx geldt het bovenstaande niet als je in LoadLibrary() het volledige pad gebruikt. Dit is wel lastig als je dll in een niet voorspelbare directory wordt geplaatst. De oplossing lijkt me:

1) zet al je eigen dlls in dezelfde directory als je .exe bestanden
2) laad dlls die je in een shared directory verwacht altijd met het volledige pad

Het wordt nog een hele klus om alle vendors al hun applicaties te laten fixen.
23-08-2010, 11:11 door SirDice
Door Anoniem: En het spijt me om te zeggen dat Linux ook dit probleem (kan) hebben, want via /etc/so.ld.conf kan je paden opgeven, die worden gebruikt om Shared Objects te zoeken. Het is wel moeilijk(er) omdat je root-rechten nodig hebt. Maar het is mogelijk.
Het aanpassen van /etc/so.ld.conf vereist root rechten. Als gebruiker zijnde is het beter om LD_PRELOAD en consorten te gebruiken om hetzelfde effect te krijgen.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.