Je geeft aan:
Gevolg: notepad start (met de privileges van gebruiker B).

Dus de gebruiker kon toch al Notepad starten met zijn Privileges....
Het zou interessanter zijn wanneer de gebruiker meer kon uitvoeren dan wat zijn rechten zijn...

Punt is dat de hacker in deze de T&notepad heeft gemaakt die wordt uitgevoerd door gebruiker B. Stel dat die hacker een T&malware.exe had gemaakt? Die malware.exe had 'ie zelf als hacker nooit kunnen uitvoeren vanwege te weinig rechten, maar gebruiker B kan dat wel.

Dit is volgens mij geen lek in cmd.exe maar in de programmeurskunsten van de scriptschrijver.
Je ziet ook veel Unix/Linux shellscripts die falen als er spaties of andere speciale tekens (zoals &) in de filenaam staan
maar daarmee is dat nog geen vulnerability van de shell. Het betekent alleen dat de programmeur de quoting nog niet
zo door heeft.

Ik zie het probleem niet direct, notepad kunnen openen is wat anders dan een (random) script kunnen uitvoeren.
Mbt malware heb je fysieke toegang nodig, of minimaal admin-rights.

Wat ik véél erger vind, is dat gebruikers "B" (Guest?) blijkbaar scripts, batch-files (executables) kan uitvoeren e/o CMD kan benaderen. Dáár zit het probleem IMHO.

Behalve een command kunnen gebruikers direct of indirect ook VB, Powershell en andere script talen gebruiken.
Het krachtige gebruik van al die scripts is dat ze ook via het web uitgevoerd kunnen worden. Code injection ligt op de loer.
Deze aanvalsvectoren zijn as goed bekend.

Het gaat er niet echt om met welk gereedschap ze aan de slag zouden kunnen gaan.
Het gaat er om welke gegevens gevoelig (datakwalificatie) zijn en welke maatregelen je nodig acht en hebt om die gegevens afdoende te beveiligen.

Als er Nerds zijn die het normale werken van gebruikers te veel onmogelijk maken gaan ze vanzelf omwegen zoeken.
Informatieveiligheid gaat niet in de eerste plaats over techniek maar over gedragen gemeenschappelijke bedrijfsdoelen waar techniek als hulpmiddel gezien moet worden.
Een cmd.exe gebruiken al of niet heeft niet heeft IMHO op dat vlak geen toegevoegde beveiligingswaarde. Het kan daarmee averechts uitpakken. Ooit zware kostbare projecten gezien om maar http links zien te voorkomen.

Onlangs nog in het nieuws: een kamerlid die de beveiliging "gekraakt had" door het te printen. Vervolgens werd de security gebasht, zijn neefje kon het veel beter.

Mijn post bevat een PoC. Ga eerst https://en.wikipedia.org/wiki/Proof_of_concept#Security lezen als je niet weet wat dat betekent.

Met dit soort posts probeer ik serieuze en security-aware admins te waarschuwen zonder daarbij script kiddies, verveelde eindgebruikers (al dan niet met BOFH) en trollen te helpen. Dat naïeve beheerders onder collateral damage vallen is helaas pindakaas (het lezen van posts op deze site is dan wel een goed begin).

Als je meent niet onder de laatste vier categoriën te vallen, kijk dan eerst verder voordat je wat blaat. Klik bijvoorbeeld op de link die ik gaf, daar staan enkele voorbeeld-exploits in (hoe makkelijk kan het zijn).

Aan de eerste categorie: zorg dat je begrijpt wat dit betekent en kijk of je scripts gebruikt die je in problemen zouden kunnen brengen.

gewoon issue erkennen en fixen zeg ik voor ms.
Wat een gebruiker kan is niet hun zorg, of de applicatie goed werkt wel.

Het antwoord van MS in de aangewezen link is duidelijk.
Input valdiatie hoort bij degene die het script maakt, de programmeur. Dat script is niet de verantwoordelijkheid van MS maar van de beheerder voor MS de gebruiker van Windows.
Dat zelfde uitgangspunt is ook op OWASP terug te vinden. https://www.owasp.org/index.php/Category:Principle
Ik ben het Met Erik van Straten eens dat: dat soort kennis bij de security awareness van admins thuishoort.

Thanks voor de heads up TS.
Veel negatieve reacties. Jammer dit.

[shields down] Dank! Hoewel ik aan de hand van enquetes op security.nl (meestal 1000+ "klikkers" versus slechts enkele reacties) vermoed dat bijdragen zoals die van mij best wel gelezen zullen worden, helpt dit wel! [shields up] ;)

Nah, valt wel mee, soms wat ondoordacht. In elk geval zijn er mensen die durven te reageren, dat doet ook niet iedereen. Maar ook negatieve en/of ontkennende reacties zijn goed. Ik maak fouten en het komt voor dat ik issues verkeerd inschat (naast ervaring speelt onderbuikgevoel mee, en aan waarschuwingen achteraf heeft niemand iets, dus ben ik soms te snel). Uitdagende reacties zetten vaak aan tot doordenken en het doen van verder onderzoek en/of betekenen dat ik zaken onvoldoende duidelijk heb verwoord. Een dilemma daarbij is dat ik niet met hapklare exploits wil strooien. Ik leer nog elke dag!

Overigens lastige materie dit soort bugs, vaak begrijpen we niet goed wat er gebeurt. Mooi voorbeeld, uit http://lcamtuf.blogspot.nl/2014/10/bash-bug-how-we-finally-cracked.html:

Als ik je goed begrijp kan gebruiker A, gebruiker B een programma naar keuze laten uitvoeren (hier notepad) door hem over te halen een ander programma naar A's keuze te laten uitvoeren (hier script.bat). Begrijp ik het verkeerd? Want dat lijkt me niet extreem boeiend, dan zou ik in dat script gewoon format c: zetten oid.

Veel negatieve reacties inderdaad.
Sowieso lijkt met het een goed idee om met policy restrictions/3rd party programma's o.i.d. te limiteren welke gebruikers cmd.exe mogen uitvoeren en met welke rechten het dan draait. Vergeet dan niet dit ook toe te passen op Windows Scripting Host en PowerShell.

Dat kan een goed idee zijn maar hier helpt dat niet tegen.

Het risico is hier dat juist privileged gebruikers (Administrator, backup operators etc) cmd.exe draaien en daarmee (al dan niet via batchfiles) environmentvariabelen, gerelateerd aan paden, verwerken (zoals %CD%, %~0 en %~f0) - waarbij die paden door untrusted en minder privileged users kunnen zijn gemaakt.

Voorbeeld: een gebruiker weet dat jij (admin) bij problemen altijd eerst https://gist.github.com/darcyparker/5264774 draait. Boem.

Niet om het één of ander Erik, maar als je een script-bug (uhm.., feature) gaat vergelijken met een RCE als Bash, kun je verwachten dat er kritische reacties komen.
Als je dan ook (bedoeld of niet) denigrerend overkomt, ga je nóg minder bijval krijgen, althans dat lijkt me een logisch gevolg.

OT: Een aanvaller heeft toegang (met rechten) nodig, is afhankelijk van reeds aanwezige non-complience scripts en kan alleen worden gebruikt op (semi-)publieke file-servers.

Wel even wat anders dan Shellshock hé...

... en waarbij die paden niet op de juiste manier quoted zijn.
Ik neem meteen aan dat veel WIndows .bat files wat dat betreft gammel zijn, maar daarmee is het nog geen
vulnerability van cmd.exe. Want in bash kun je die fouten ook maken, dat gaf ik al aan.

Wat het hooguit in cmd.exe (en command.com) erger maakt is dat er speciale afhandeling in zit waardoor
dingen als het weglaten van de spatie tussen CD en een directorynaam niet erg is, cd doet ie evengoed wel. En dat
het hele afhandelen van quoting in die programma's een beetje een zootje is, waardoor het voor de naieve programmeur
totaal onduidelijk is waar quotes nu wel en waar niet nodig zijn. Microsoft denkt wellicht mensen te helpen maar je
ziet wat het effect is.

Erik ik ben niet negatief over je acties. Je bent mogelijk te snel met reacties zoals je zelf aangaf.
Wat er nu allemaal gebeurt, je hebt weinig keus, je moet mee met de patch updates (snel).

Voor de "root-cause" analyse is het denkwerk echt lastiger. We zitten op een heel ander niveau als de SQL code injection. Niemand heeft toen beweerd dat het door SQL of de RDBMs opgelost moest worden. Daar was het logische dat bij binnenkomst van SQL de inputvalidatie gedaan moest worden. Ook geen keus.

Bij de redeneringen zie ik het argument langskomen dat je als je root bent root kunt worden. Windows als je admin ben kun admin worden ... uh kringredeneringen liggen op de loer.


In jouw voorbeeld van support door HD via een RAT (Remote Access Tool) komt een ander persoon ook op de machine.
Dat kan via een eigen process (mijn voorkeur). Wat je vaak ziet is door overname van het scherm waarbij de helpdesk man onder jouw credentials instructies geeft en soms onder jouw credentials acties onderneemt . Als het nodig is om op de machine bijzondere aanpassingen te doen kan hij switchen naar local admin (niet domain admin) met runas.
Deze situatie komt voor desktopomgevingen met een gesloten benadering, Ofwel gebruikers kunnen niets zelf installeren / deinstalleren. Omdat alles vrij ver is dichtgetimmerd zijn dat soort omgevingen aardig stabiel.

Het gevaar zit meer in:
- mogelijke lekken in de Rat. Stel dat hackers die open krijgen.
- de reinstall / update optie van de machine. Als dat tool alles open heeft kan hij overal bij kan ook gehackt worden.
- De persoon die kwaad in zin heeft is de gebruiker van de machine, uh een eigen medewerker of "zoekgeraakte" hardware
- Het gebruik van cloudopslag mail bijlages . vrij internet etc.

De inperkingen schieten vaak te ver door, de beste security is een niet werkend systeem.
Er zijn gebruikersgroepen die voor hun werk een shell nodig hebben en dat het ook verantwoord is. Dat is vaak zeer lasting communiceren met security mensen. Deze gebruikers zoeken dan andere omwegen om toch hun werk uit te voeren.
Het gaat om ee balans wat is werkbaar wat is veilig en de kosten/impact.

Het schokkende van de Shellshock is dat het gebruik door gemaak zo ver is doorgesijpeld.
Had allemaal niet gehoeven bij defensief ontwikkelen. Ik kom net tegen:
http://docs.fedoraproject.org/en-US/Fedora_Security_Team/1/html/Defensive_Coding/ch11s03.html#sect-Defensive_Coding-Tasks-secure_getenv
http://docs.fedoraproject.org/en-US/Fedora_Security_Team/1/html/Defensive_Coding/sect-Defensive_Coding-Tasks-Processes.html#sect-Defensive_Coding-Tasks-Processes-execve
Met pogrammatuur die niet defensief opgebouwd is, maar snel klaar moest zijn heb je vaak een problem.

Je mist de essentie.
De aanvaller, een gebruiker met beperkte rechten, maakt een map aan met een getruukte naam (T&Notepad in het voorbeeld). Vervolgens draait een andere gebruiker met interessante (gevaarlijke) privileges een script dat de naam van het bestand of de map met de getruukte naam tijdens de verwerking middels de uitvoer van het CD commando aan een variabele toekent (als pwd in een shell onder *NIX). Deze toekenning van de mapnaam aan de variabele heeft tot gevolg dat onbedoeld het programma wordt uitgevoerd dat de aanvaller in de naam van de map heeft opgenomen. En dit is een aanvalsvector die mogelijkheden voor grote schade biedt!

Overigens, om het nog fijner te maken: shell scripting onder UNIX-achtigen is in het algemeen van een veel hogere kwaliteit dan onder MS Windows. De shell van CMD.EXE is echt rampzalig (het FOR commando als zwitsers zakmes, commando's als CD die geen resultaatcode zetten enz enz enz.) waardoor de kwaliteit, leesbaarheid en controleerbaarheid van dergelijke scripts beroerd is.

Wat een geblaat:
"RCE als Bash": wat ? bovendien is het niet Bash, maar bash (*NIX is letterkast gevoelig, ja da's wennen hè)
"denigrerend overkomt": hoezo?
"non-complience scripts": gewone taal a.u.b.,
"kan alleen worden gebruikt op (semi-)publieke file-servers": smullen voor een aanvaller, hij kan zelfs zonder persoonlijke rechten al aan de gang, toppie !
"Wel even wat anders dan Shellshock hé...": marketing framing, want noem eens een incident waar bewijsbaar schade aan is gericht met het onderkende probleem in bash.

Joep Lunaar, Sorry maar dat is struisvogelgedrag van de bovenste plank.

Het zal her en der voorgekomen zijn dat het bash-lek gebruikt is. Ik vermoed via web-servers, daar werd namelijk naar gewezen. Virtuele machines (fusion/mac na Het Echter niemand zal zoiets erkennen. Als ze het als zouden kunnen achterhalen, je kan vaak niet eens meer zien wat de oorzaken lekken echt waren. Een leuke in dat kader: https://news.ycombinator.com/item?id=8418809.

Credit card gegevens en pos terminals zijn nu hot item bij data-breaches (Target Home-depot US). Er is genoeg open gezet en gelekt. De beste aanpak is risico analyse doen en daar de er bij horende maatregelen nalopen.
En nee je hoeft niet alle hypes ale waarheid te zien.