En als je het aanpast zodat het naar %TEMP% of %APPDATA% schrijft ga je alsnog nat.

Zo zijn er meer directories waar je naar toe kan schrijven. Een beetje trojan probeert meerdere directories lijkt mij. Werkt system32 niet, dan bijvoorbeeld de temp-dir.

De titel klopt niet helemaal. Adobe Reader wordt niet veiliger als de gebruiker minder rechten heeft. Het systeem is misschien minder 'open'.
Alleen Adobe kan Adobe reader veiliger maken...

My two cents.

Het gaat hier niet om de trojan, maar om de shellcode die de trojan zal downloaden en starten.

Kortom: de lokale rechten van die gebruiker doen niet terzake voor de veiligheid van het systeem, zolang een gebruiker ergens kan schrijven is elk systeem even vatbaar voor malware.
Dat impliceert dus dat Windows 7 net zo vatbaar is voor malware als Windows Vista, XP, 2000, 98, 95 en 3.11 en MS-DOS.
De veiligheid van een systeem wordt alleen bepaald door de hoeveelheid gebruikers (marktaandeel) en de mate waarin de gebruiker veilig werkt.
Alle inspanningen van Microsoft voor meer veiligheid zijn dus tevergeefs.
En dus zijn OS/X, linux, BSD-versies, AIX, HP-UX en noem ze maar op, allemaal net zo vatbaar voor malware als MS-DOS.
Dat er ondanks jaren van voorspellingen nog steeds vrijwel geen malware voor OS/X bestaat, komt alleen maar doordat het marktaandeel met 10% nog niet genoeg kritische massa heeft. Malware-schrijvers richten zich namelijk alleen op de grote aantallen, zoals elke Windows-gebruiker weet.

Didier, de shellcode krijgt dezelfde rechten als de gebruiker van de parent applicatie. Waarom de shellcode niet werken als je een beperkte gebruiker bent i.p.v. een administrator?

Je bedoelt als de malwaremakers het aanpassen. Feit is dat de meeste huidige malware naar laaghangend-fruit-mappen schrijft. Het zou me niet verbazen als ze dit bewust doen; de overlevingskansen van een zombie zijn gewoon kleiner indien ergens uit blijkt dat de gebruiker en/of beheerder van het systeem de moeite voor aanvullende maatregelen heeft genomen.

Daarnaast is het hebben van schrijfrechten in SYSTEM32 voor malware interessant om de volgende redenen:
- dat betekent dat de malware bestanden kan schrijven in een map die (voor elke gebruiker) relatief vooraan in %PATH% staat
- dat betekent over het algemeen dat de malware bestanden in SYSTEM32 kan overschrijven die al tijdens het bootproces worden uitgevoerd (en daarmee ook tijdens safe mode actief kunnen worden)
- dat betekent over het algemeen dat de gebruiker (en dus de malware) ook services kan installeren die draaien ongeacht of een, en welke, gebruiker is ingelogd
- dat betekent in de praktijk dat de malware ook onbeperkte schrijfrechten in het register heeft onder HKLM
- dat betekent in de praktijk dat de malware de mogelijkheid heeft om een rootkit te installeren
- dat betekent in de praktijk dat de malware alle aanwezige beveiligingssoftware "onschadelijk" kan maken of bijv. poorten kan openzetten in een personal firewall
- er zijn onbegrensde mogelijkheden voor het aanpassen van DNS instellingen, hosts file, toevoegen certificaten, installeren van backdoors om later nog eens terug te kunnen komen (signed maar buggy ActiveX-jes bijv), er kunnen minder fijne BHO's worden geinstalleerd, er kunnen policies op het systeem worden gezet die de rechten van de gebruikers beperken etc.
Kortom, de malware kan het systeem geheel naar zijn hand zetten; legio redenen om een betrouwbare zombie met lange levensduur te garanderen.

Natuurlijk wist jij (SirDice) dit allemaal al, maar lezers die jou niet kennen (zoals blijkt uit de op jouw post volgende reacties) zouden kunnen denken dat jij dit nog niet wist... ;)

Onzin. Het is dan niet het systeem dat vatbaar is voor die malware, maar de bestanden en het deel van het register waar de gebruiker schrijfrechten op heeft (bijv. het register: HKCU alleen van de betreffende gebruiker, het hele register voor admins). Zeker een systeem dat meerdere non-admin gebruikers (naast een beheerder) kent is netto minder vatbaar voor malware omdat slechts die gebruiker die de malware introduceert er last van heeft (malware die van zero-day privilege escalation exploits gebruik maakt moet ik nog tegenkomen).

Door een non-admin (onbedoeld) gedraaide malware kan zichzelf welliswaar autostartend maken, maar is dat alleen als de betreffende gebruiker weer inlogt. En zelfs daartegen zijn betrouwbare maatregelen denkbaar:
- een sandbox-achtige schil die Didier Stevens voorstelt zou kunnen voorkomen dat de malware naar de personal Startup map en/of HKCU/.../Run key (of andere autostart aanvliegroutes) schrijft
- je zou het bovenstaande ook middels permissies kunnen dichtzetten vanuit een admin account
- veel beveiligingssoftware zal autostart vectors sowieso bewaken en alarm slaan op het moment dat iets daarnaar probeert te schrijven (bij het openen van een PDF verwachten enigszins verstandige gebruikers dat niet).
Bij zo'n setup betekent het uit-en-weer-inloggen dat de malware niet meer actief is. Toegegeven dat helpt niet bij zogenaamde ransomware, maar dat spul komt nou ook weer niet zo heel veel voor.

Die twee regels zijn totaal met elkaar in tegenspraak:

1) Een gebruiker kan in elk geval veiliger werken op een systeem dat daarvoor de mogelijkheden biedt, d.w.z. op een systeem dat permissies gebruikt op bestanden, register, devices en andere systeem-objecten, d.w.z. NT en hoger, gebruikmakend van NTFS partitie(s). Voorwaarde daarbij is wel dat je ook iets zinvols doet met die permissies, d.w.z. als non-admin werkt, anders durf ik de stelling best aan dat Windows98SE het meest veilige Microsoft besturingssysteem ooit was.

2) Door als non-admin in te loggen hoor je tot een beperkte groep gebruikers (marktaandeel) waardoor je impliciet al niet meer tot de grootste doelgroep van de malwaremakers hoort.

Kortom, als non-admin werken loont. En als je dat doet, loont daarbovenop het draaien van "internet facing" applicaties in een sandbox, om te voorkomen dat eventuele malware er met jouw persoonlijke bestanden vandoorgaat en zich herstartend-bij-een-volgende-logon kan installeren.

Denk er ook om dat het niet altijd duidelijk is of zo'n sandbox ook draait indien PDF of Flash (c.q. PDF met daarin embedded Flash) bestanden embedded in een webpage of email worden geserveerd. Zet bij voorkeur het automatisch starten van Adobe apps "binnen" je webbrowser uit om infectie door een gekraakte webserver te voorkomen (of een niet gekraakte webserver die PDF/Flash malware i.p.v. reclame aanlevert vanaf een "overgenomen" reclamebannerserver).

Adobe is keer op keer rotzooi gebleken. Komt er bij mij niet meer in. Ik gebruik dan ook iets als Foxit Reader en geen Adobe meer. M\aar kritiek op Adobe zul je hier tevergeefs vinden. Zoals al vaker hier is gebleken: alles is de schuld van Microsoft. Daarom neem ik alles hier steeds meer met een flinke kilo zout. Objectiviteit is hier ver te zoeken. Sterker nog: je wordt hier geschoffeerd als je het ook maar waagt iets van Microsoft positief te vinden.

Neem Acrobat Reader. Veronderstel dat die draait met een restricted token (geen privileges, behalve 1 noodzakelijke privilege; geen member meer van de Local Admin groep of de Power Users groep).

De shellcode zal ook uitgevoerd worden met deze restricted token. Doorsnee shellcode doet dit:

1) downloaden trojan: werkt nog altijd, ook met restricted token
2) wegschrijven trojan naar SYSTEM32: werkt niet meer, maar de shellcode houdt hiermee geen rekening
3) shellcode draait verder en start een bestand dat niet bestaat in SYSTEM32: geen infectie
4) shellcode stopt ermee, bv. met een RET, meestal zal Adobe Reader hier crashen

De meeste malware ontwikkelaars bezitten de kennis niet om shellcode te schrijven. Ze hergebruiken bestaande shellcode, die meestal naar SYSTEM32 schrijft.
En shellcode is meestal simpel omdat het best zo kort mogelijk is om in de beperkte buffers te passen die overschreven worden, of om niet te groot te zijn voor een succesvole heap-spray.