Windows Software Security Auditing - DLLs

[sh4d0wman]

Als onderdeel van een checklist ben ik mij aan het verdiepen in de verschillende attack surfaces van Windows applicaties. Op dit moment ben ik bij DLL's / Shared Libraries aangekomen. De volgende checks zijn geen probleem:

1. Incorrecte file-system permissies: dynamische test om permissies te acherhalen. Bij verkeerde permissies een test-dll plaatsen/overschrijven.
2. DLL Planting / Hijacking: dynamische/statische tests voor: niet bestaande DLL/verkeerd gespelde DLL/geen volledig pad. Vervolgens test-dll plaatsen (eventueel met stub functies).
3. DLL OLE Sideloading: dynamische test om GUIDs te achterhalen en test RTF te maken.
4. Gevoelige Functies: dynamische en statische tests om gevoelige functies te vinden, b.v. uitschakelen zelf-protectie AV. Vervolgens een PoC schrijven welke deze DLL functie aanroept en test voor success (privileged / unprivileged user).

Vraag:
De volgende checks wil ik graag toevoegen maar daar heb ik nog geen goede tooling voor of snap ik niet voldoende. Input is welkom Zijn er nog andere zaken om te testen?

1. Versie Check: bekende vulnerabilities.
Op dit moment print ik een overzicht van applicatie DLL's en kijk gebaseerd op naam welke interessant kunnen zijn. B.v. 7-zip, xml, e.d. Vervolgens Googlen op versie info. Dit is echter vrij omslachtig. Is er een applicatie welke dit kan auditen?

2. DLL Fuzzing: de enige voorbeelden die ik kan vinden worden door de applicatie zelf getriggered, b.v. parsen van een file of netwerk packet. Het zou echter ook mogelijk moeten zijn om DLL exports/functies direct te fuzzen, iemand die hier ervaring mee heeft of goede tutorials kan linken? Peach zou er support voor hebben en een commercieel product BeStorm.

[Squ1zZy]

1. Dit zou met PowerShell wel moeten kunnen.

[sh4d0wman]

Squ1zZy schreef op donderdag 16 november 2017 @ 07:15:
1. Dit zou met PowerShell wel moeten kunnen.

Bedankt voor je input dit kan inderdaad wat tijd besparen. Echter blijft het probleem dat er geen een centrale repository/db is om tegen te checken. OWASP had ooit "Dependency Checker" maar dat ziet er dood uit (2013).

Ik zal nog eens een demo van Nessus installeren en kijken of/wat deze client-side kan detecteren.

Mocht dat ook niks opleveren dan skip ik deze check.
(Ik test voornamelijk voor bug-bounties en dan zijn de exports/gevoelige functies + fuzzing/memory corruption de belangrijkste factoren om te testen.)

[Squ1zZy]

Nessus checkt niet een DLL, maar aan de hand van een versie of er een exploit voor beschikbaar is. Echter is die dan al bekend.

Als je wilt gaan voor een bug bounty zal je toch moeten reverse engineren als het om closed source gaat.

Doe je het fuzzen niet vanuit de applicatie? De DLL functies worden dan geladen en zal je vanuit de applicatie moeten fuzzen toch?

Ik denk dat je de applicatie wel kan scannen met tools en of die kwetsbaar zijn. Al vraag ik me af of je bestaande bugs kan melden en een bug-bounty kan ontvangen

Ik zou gaan reverse engineren...

Edit: Wel interessant vragen trouwens. Kan zelf redelijk goed Assembly en dan is bugs zoeken wel leuk. Wil nog altijd mijn eigen exploit schrijven. Ik hou de topic in de gaten

[ Voor 13% gewijzigd door Squ1zZy op 16-11-2017 09:55 ]

[sh4d0wman]

Squ1zZy schreef op donderdag 16 november 2017 @ 09:53:
Edit: Wel interessant vragen trouwens. Kan zelf redelijk goed Assembly en dan is bugs zoeken wel leuk. Wil nog altijd mijn eigen exploit schrijven. Ik hou de topic in de gaten

Hehe dat was snel!

A.
Ik weet wat Nessus doet En hoop dus dat deze bijvoorbeeld diverse bekende DLLs op kan pikken aangezien software veel deelt en hergebruikt. Bijvoorbeeld een applicatie welke een 7-zip DLL gebruikt uit het jaar kruik waar een buffer overflow in zit. (ooit ontdekt in een AV product)

B.
Fuzzen op applicatie niveau kan, bijvoorbeeld als het een bestand verwerkt en daarvoor een DLL functie aanroept.

Echter speel ik ook met de gedachte dat er functies in een DLL zitten welke niet door de applicatie aangeroepen worden (b.v. trial vs full version of standard vs enterprise, legacy code, etc.)
Ik moet alleen nog testen of deze aanname juist is

Die zouden we dan buiten de applicatie moeten triggeren en van input voorzien.

RE is inderdaad nodig. De strategie die ik daar nu voor hanteer is de volgende:
DLLs vinden:
- Enumeratie van DLL's in applicatie directory
- Dump van DLL imports van target process / service
- Classificatie van de gevonden DLLs: vendor specifiek vs generiek
- Op basis van naamgeving en/of applicatie monitoring bepalen welke DLLs interessant kunnen zijn.

Voor alle interessante DLLs:
- Dumpen van alle exports
- Dangerous / banned API calls checken
- Afhankelijk van de functie: skeleton script schrijven en aanroepen / applicatie fuzzen / applicatie debuggen en on-the-fly iets aanpassen b.v. cmdi, path traversal.

Exploit voorbeelden:
1. AV-Hacker Handbook, skeleton script met DLL functie aanroep om self-protectie van de scanner aan/uit te zetten.
2. Exploit-db, memory corruption in x.dll while parsing a malformed file.

Off topic: Bug bounties zijn vreemd. Sommige zaken waarvoor je een beloning zou verwachten leveren niks op en omgekeerd. Daarom kun je maar beter ALLES wat je vind rapporteren of op safe spelen en alleen maar op zoek gaan naar high impact zaken zoals injections & memory corruption

[Squ1zZy]

Als je een PE bestand hebt dan kan je zien welke imports er gedaan worden met bijvoorbeeld Dependency Walker, maar dan zie je niet de functies die niet worden gebruikt door de PE.

Is er geen tool die dat makkelijk kan uitlezen? Ik gooi de DLL meestal in Olly.

Als je een interessante functie hebt gevonden dan ben je er nog lang niet? Je zou de functie moeten aanroepen vanuit de code. Zonder stack/buffer overflow etc gaat je dat niet lukken?

Ik kan wel eens een praktijk voorbeeld maken hoe een buffer overflow werkt in een DLL. Misschien leuk voor andere om te zien hoe het werkt?

[Kentsfield]

Denk niet dat Dll fuzzing erg zinvol is. Je moet de method signatures weten voor je er iets zinnigs mee kan. Wat wil je precies fuzzen?

[sh4d0wman]

Disclaimer: ik kom van Linux/Embedded auditing naar Windows applicaties dus vandaar mijn vragen en op sommige punten nog gebrek aan kennis / hand's on ervaring.

A. DLL Functies
Met PE Explorer kun je de DLL imports vinden en de aangeroepen functies.
Vervolgens kun je b.v. met "DLL Export Viewer" alle DLL exports van betreffende DLL verkrijgen en vergelijken.
Voor functie details worden door PE Explorer weergegeven of zou je anders via RE met IDA of Olly kunnen krijgen. Er schijnt ook nog een tool "API Monitor" te zijn welke hierbij zou kunnen helpen.

(Zie ook punt D.)

Voor .Net geeft men aan om .NET Reflector / ildasm te gebruiken maar dat heb ik nog niet getest.

Andere tooling:
Dependency Walker
list dlls - Sysinternals: view all loaded DLLs loaded by a process
dumpbin /IMPORTS should provide the function imported into that DLL
dumpbin /EXPORTS should provide the functions it exports.

B. Local vs Remote Exploitation
Ik had in eerste instantie dezelfde gedachte maar kwam toen op het AV voorbeeld en enkele andere cases.
Daarbij gaat men er van uit dat een aanvaller al enige toegang heeft tot het systeem b.v. guest of normale user.
De vulnerability is dan dat men de DLL functie kan triggeren welke een privileged actie uitvoert.
In dit geval d.m.v. custom Exe welke de DLL functie aanroept om self-protectie uit te schakelen.

Voorbeeld: Google/torrent even op "av hacker handbook". Bekijk P 196, P 271/272(Google censored)

Om het remote te triggeren moet je inderdaad eerst ergens een buffer overflow in de applicatie vinden waarna je de DLL kunt aanroepen.

C. BoF Voorbeeld
Mocht je een keer tijd hebben om een voorbeeld te maken dan zou dat zeker leuk zijn.

D. Fuzzing
Ik was aan het kijken of fuzzen een mogelijkheid was:
1. Zodat je niet de hele applicatie hoeft te starten (sneller)
2. Functies bereiken waar de applicatie geen gebruik van maakt / niet getriggered kunnen worden vanuit de applicatie (backdoor?)
3. Als vector welke waarschijnlijk minder aandacht heeft bij bug-bounties dus grotere kans iets te vinden

Fuzzing blijkt echter vrij lastig met name door de method signatures waar jij het over had.
Het lijkt dat men DLL fuzzing voornamelijk inzet op eigen gemaakt DLL's waar men dus source code en symbols van heeft. Na wat Google werk kwam ik ook de volgende discussie tegen: https://reverseengineerin...-from-an-unknown-dll/2135

Conclusie: fuzzen kan maar kost veel tijd en de vraag is of dat het waard is.
Waarschijnlijk is het nuttiger om file- en protocol fuzzing tegen de applicatie te gebruiken en specifieke functionaliteit handmatig te auditen/RE met IDA/Olly.