Razer gaat bug fiksen die gebruiker admin-rechten geeft op Windows via installer

Hardwaremaker Razer gaat een bug fiksen, waarmee gebruikers admin-rechten kunnen krijgen op Windows 10 of Windows 11 door hardware van Razer aan te sluiten en vanuit de installer door te klikken naar een PowerShell. Een beveiligingsonderzoeker ontdekte dat.

De fix zou 'zo snel mogelijk' moeten komen, meldt beveiligingsonderzoeker John Hat. Hij ontdekte de bug en toen hij geen reactie kreeg, postte hij zijn bevindingen afgelopen weekend openbaar op Twitter en in een video. Nu er aandacht voor is gekomen, gaat Razer alsnog iets met zijn melding doen.

Hat heeft in een video getoond hoe de exploit werkt. Het inpluggen van een muis of toetsenbord van Razer onder Windows 10 of 11 leidt ertoe dat Windows automatisch vanaf Windows Update een driver installeert voor die hardware en vervolgens een installer start voor Razer-software. Die geeft de optie om in een zelfgekozen map de software te installeren. Vervolgens is het mogelijk om vanuit die map PowerShell te openen, waarbij PowerShell de rechten meekrijgt van de map vanwaaruit die is geopend.

Vanuit daar is het mogelijk om van alles te doen met die admin-rechten. De exploit vereist fysieke toegang tot een computer en de mogelijkheid om hardware van Razer in te pluggen of dat te emuleren. Daardoor is de schaal waarop dit misbruikt kan worden beperkt.

Reacties (71)

[dabronsg]

Is dit niet een Windows tekortkoming? De gebruiker krijgt admin rechten zonder het juiste wachtwoord in te voeren...

[Accretion]

Exact, als Razer dit "fikst" kun je toch gewoon met een oudere versie van de installer aan de gang?

Of een hacker kan een vergelijkbaar stuk software draaien?

[henk717]

Nee, wat hier gebeurt is dat Windows vanaf microsoft de update server een installer download en opent. Omdat dit als system begint heb je automatisch admin. Je kunt vervolgens via een dialoog box alles starten en ze kunnen dit makkelijk oplossen door het dialoog te veranderen. Download je de pude versie zal die niet als admin draaien tenzij je daar toestemming voor geeft.

[Jay-v]

Toch vreemd dat je zomaar een child process kan spawnen of niet? Zou Microsoft of Razer niet de driver/installer signature kunnen intrekken?

[kalikatief]

Powershell starten is gewoon standaard systeem functionaliteit dat inhaakt op het rechtklik menu in Explorer, waar de zogeheten 'common dialogs' dus ook gebruik van maken. Het is eigenly best logisch; soms wil een administrator of programmeur of andere IT vogel even snel iets in de folder doen waar ze met een programma bezig zijn. Dit maakt het aardig wat makkelijker.

Wat hier fout gaat is dat Razer op de een of andere manier een GUI proces start zonder de rechten in te perken tot die van de ingelogde gebruiker. Het is logisch dat Windows de driver installatie systeemrechten geeft: zelfs vandaag kunnen niet alle drivers in usermode draaien en krijgt een driver sowieso dus al alle sleutels van het digitale koninkrijk. Directe toegang tot de kernel en hardware is immers een beveiligingsrisico - denk maar aan het afluisteren van communicatie of het verpesten van cryptografische functies die aan alle beveiliging ter gronde liggen.

Maar eigenlijk is het stomste dat dit uberhaupt een installer start. Drivers zijn gewoon hardware functionaliteit en daar gebruikerssoftware staat daar helemaal los van. Met de eeuwenoude .INFjes worden al jaar en dag zonder installer drivers geinstalleerd die de hardware laten werken. Maar deze extra-saus software? Dat hoor je naar mijn mening helemaal niet uit Windows Update aan te slingeren, en al zou je dat wel doen, dan zou dat niet op de driver-installatie moeten meeliften, maar gewoon direct door Windows moeten worden aangeboden als 'bijbehorende software' oid. En op dat moment kan Windows dat proces gewoon onder de huidige gebruiker starten zoals het hoort.

[GertMenkel]

Ik heb enkele jaren terug al screenshot gezien van de Razer-installer die midden in de Windows 10-installatie naar voren kwam. Als je installer draait voordat er überhaupt gebruikers zijn aangemaakt, moet je als ontwikkelaar toch wel begrijpen dat je buitengewone rechten aan een GUI-programma toewijst?

Ik geloof niet dat Razer niet op de hoogte is van de risico's die hun troep met zich meebrengt. Als ze er wel pas nu achter komen, zijn hun programmeurs incompetent op gebied van security en is hun software compleet niet te vertrouwen. Als ze er al vanaf wisten, is hun management incompetent en zijn hun verkooppraatjes niet te vertrouwen. Microsoft heeft hier ook een aandeel in, ze hebben willens en wetens deze software voor Windows Update gecertificeerd. Ik heb overigens zo'n zelfde popup ook bij een Logitec-muis gezien. Hopelijk zijn die lui slim genoeg om dit niet te doen.

Ik zal nooit of te nimmer Razer-hardware kopen of aanraden, in elk geval.

[Verwijderd]

Razer is volgens mij meer dan op de hoogte. Grote kans dat ze echter intern dit soort dingen simpelweg niet goed aanpakken/communiceren, of (onwaarschijnlijk) dat ze het expres een beetje onder het tapijt vegen:

- https://twitter.com/Swift...tatus/1429315642797199364
- https://twitter.com/sluphes/status/1361167315518316544
- https://twitter.com/_MG_/status/1429293811226742787
- https://twitter.com/tifkin_/status/1429233998547591170

Ook is er inmiddels vol-automatische USB-pentest tooling beschikbaar die deze exploit gebruikt om system-level privileges te krijgen vanaf een guest account: https://twitter.com/_MG_/status/1429293225181814784

Verder zorgt Razer software overigens ook voor andere problemen, zoals Docker for Windows die niet wil starten omdat beide programma's hun single-running-copy check op de zelfde verkeerde manier doen:
https://twitter.com/Foone/status/1229641258370355200

Anyway, eindig ik even voor relevantie even met deze quote van _MG_:

And this is mostly a Windows issue. We dug a bit more and found some similar opportunities in other devices. So even if Razer did modify their installer to avoid this, it’s still fundamentally a Windows issue for allowing it.

[Reactie gewijzigd door Verwijderd op 24 juli 2024 04:43]

[Suspiria]

Ik sluit mij aan bij de andere meningen, en:

Het "opschakelen" van user naar Administrator rechten vond ik programmeertechnisch heel straight-forward. (bijv. een runas ShellExecute in C#) Maar het "afschakelen" van Administrator naar user rechten dat kan dus helemaal niet op diezelfde wijze. Dat was echt even zoeken en vinden.

En ik vermoed dat dat de "reden" is dat ze het toen maar even zo gelaten hebben, en het vervolgens vergeten zijn. Ik speculeer dat er echt wel een dev geweest is die bij die execute zoiets had van "nah" maar het vervolgens om wat voor reden dan ook toch niet als todo genoteerd heeft.

Maar wat ik eigenlijk het meest opmerkelijk vind is dat Microsoft dit soort third party drivers kennelijk dusdanig vertrouwt dat deze zonder UAC met admin-rechten gelanceerd mogen worden. Misschien bewijst dit lekje dat dat niet per sé het meest wijze beleid is.

[bloq]

Ik heb bij de 3e versie van de Chroma software zelfs meegemaakt dat ik Overwatch niet kon verwijderen omdat Razer een dll had vervangen van Overwatch voor eentje die ze zelf hadden gemaakt om mijn Hue lights mee aan te sturen (wat uiteraard zo buggy was dat het onbruikbaar was). Daarnaast was het een vaste prik om op mijn blue screen te zien dat het veroorzaakt werd door Razer software. Helaas was de software essentieel om de buggy dual sensor van mijn muis dagelijks te corrigeren. De oude deprecated versie van de software was, slechts wat minder tenenkrommend. Mediamarkt retourpolicy heb ik in ieder geval helemaal uitgemolken, uiteindelijk besloten dat ik gewoon geen Razer meer wil.

Ik denk dat dit ook de reden is dat ik nu een Ducky toetsenbord heb, software loze hardware is best wel een verademing.

[dennisameling]

en al zou je dat wel doen, dan zou dat niet op de driver-installatie moeten meeliften, maar gewoon direct door Windows moeten worden aangeboden als 'bijbehorende software' oid

Dat wordt door Microsoft al aangeraden en is onderdeel van de "DCH Design Principles and Best Practices". Die richtlijn beschrijft letterlijk:

Declarative (D): Install the driver by using only declarative INF directives. Don't include co-installers or RegisterDll functions.

Eventuele ondersteunende software moet via een losstaande "Hardware Support App (HSA)" worden aangeboden via de Microsoft Store. Bijv. HP doet dit al met de HP Smart app voor printers.

Zou goed kunnen dat ze dit in de toekomst verplicht gaan stellen voor drivers om nog door de validatie heen te komen, maar heb hier nog geen berichtgeving over gezien.

[Reactie gewijzigd door dennisameling op 24 juli 2024 04:43]

[delphium]

Dan is de fout toch dat Windows een GUI opent voor een normale gebruiker, van een door het systeem/admin gestart proces? Dat zou nooit mogen gebeuren.

[jorisvergeerTBA]

Dat is niet de verantwoordelijkheid van Windows. De software ontwikkelaar heeft die verantwoordelijkheid.

Als ik als softwarebouwer een applicatie bouw. Misschien voor een een of andere niche markt, of een interne tool die gewoon even zijn dingetje moet doen. Die die functionaliteit nodig heeft. Dat moet windows die functionaliteit gewoon aanbieden.

[delphium]

Dat is niet de verantwoordelijkheid van Windows. De software ontwikkelaar heeft die verantwoordelijkheid.

Dus volgens jouw redenatie is de veiligheid van het besturingssysteem afhankelijk van externe software leveranciers? Dat lijkt me een zeer ernstige ontwerpfout in het systeem.

Als ik als softwarebouwer een applicatie bouw. Misschien voor een een of andere niche markt, of een interne tool die gewoon even zijn dingetje moet doen. Die die functionaliteit nodig heeft. Dat moet windows die functionaliteit gewoon aanbieden.

Dat kan ook, maar voordat dat kan zou je wel even je wachtwoord moeten opgeven. Als die stap kan worden overgeslagen is er m.i. iets goed mis met de implementatie van je authenticatiesysteem.

[MSalters]

Het gaat hier over externe hardware leveranciers. Dat is een essentieel verschil. Hardware leveranciers kunnen drivers laten installeren, en drivers draaien inherent met SYSTEM rechten. Er is niet iets als een per-user driver install, terwijl per-user software installs wel mogelijk zijn.

Zoals Microsoft het uitdrukt: als je fysieke toegang hebt en hwrdware kunt installeren, heb je toegang tot een systeem. Of het nu keyloggers zijn of dit soort methoden, een goede beveiliging begint met fysieke beveiliging van de werkplek.

[delphium]

Hardware leveranciers kunnen drivers laten installeren, en drivers draaien inherent met SYSTEM rechten.

Dat klopt en precies daarom zou bij het installeren van drivers altijd om een administrator wachtwoord gevraagd moeten worden. Dat is hier dus klaarblijkelijk niet nodig. Sterker nog, er wordt zelfs een GUI gepresenteerd door een proces dat draait als SYSTEM, aan een gebruiker die niet die rechten heeft.

Zoals Microsoft het uitdrukt: als je fysieke toegang hebt en hwrdware kunt installeren, heb je toegang tot een systeem. Of het nu keyloggers zijn of dit soort methoden, een goede beveiliging begint met fysieke beveiliging van de werkplek.

Dat vind ik nogal een zwakte bod. Net alsof je computer toch al verloren is als iemand fysieke toegang heeft. Beveiliging komt in lagen en beveiliging van de werkplek is er eentje van, maar zeker niet de enige.

[the_stickie]

Als jij erin slaagt je software te signen en op Windows update te zetten heb je helemaal gelijk
Dat is niet alleen praktisch lastig te verwezenlijken, je bent ook bij MS geregistreerd/bekend.

[kiddingguy]

Zo kun je het ook zien, maar waarom/hoe kan Razer het dan fixen?
Minder rechten toekennen aan dergelijke processen wellicht?

[henk717]

Razer moet ofwijl geen installer openen ofwijl die installer voorzien van de eenvoudige map selectie zodat je geen run dialoog hebt. Zij wijken af van het standaard automatische installatie principe dus het is echt hun fout.

[jimshatt]

Mee eens. Tenminste, wanneer je als standaardgebruiker dat apparaat inplugt. De driver zelf moet nog wel kunnen denk ik, maar software installeren zou niet moeten mogen.

[Speeder]

Het is al raar dat die driver door de WHQL controle heen gekomen is en dus in de driver store van Microsoft zelf staat. Volgens mij is het namelijk niet toegestaan om software op deze manier te installeren.

[latka]

Logitech doet iets soortgelijks (Logitech options aanbieden na het inprikken). Komt blijkbaar vaker voor.

[Speeder]

Aha, was het zelf nog niet eerder tegen gekomen maar lijkt dan een trend te worden... Dan moeten we maar allemaal bij Microsoft gaan klagen dat ze hier beter op gaan controleren.

[Accretion]

Beide zijn toch fout?

Windows voert automatisch een third party script uit als admin? Een die ze blijkbaar niet checken.

Als alleen Razer het fikst, is er 0 garantie dat een andere fabrikant niet hetzelfde probleem heeft of krijgt in hun software.

[Raymond Deen]

Hmmm, dus terwijl Windows toestaat dat een programma een foutieve actie start is het de fout van dat programma en niet van het beveiligingsmodel in Windows?

Beveiliging is niet zomaar een laagje dat je kunt aanbrengen ergens bovenop, maar een integraal onderdeel van het systeemontwerp tot op het diepste niveau en daar is nu gewoon een fout in naar boven gekomen.

[Skit3000]

De installatie start vanzelf na het inpluggen van een apparaat, dus wordt waarschijnlijk gedownload via de Windows Update servers.

Het is trouwens juist een hele gevaarlijke bug omdat iedereen met een Razer apparaat nu met een simpele handeling binnen een minuut toegang kan krijgen tot elke fysieke machine waar ze bij kunnen.

[kiddingguy]

Dan is de vraag... gebeurt dit ook bij andere installers van andere leveranciers?
Bij wel wat devices draait Windows Updater ook (HID_xxx updates etc)

En heb je hier dan per sé fysieke toegang toegang tot een computer voor nodig, of kan de code ook remote geinstalleerd en gedraaid worden?

[Z80]

Heb je wel gelezen? Of het filmpje bekeken? Het is dus NIET!!! de driver zelf die het probleem is.
Het is de software de er vervolgens achteraan geïnstalleerd wordt. Vanuit de SOFTWARE installer kan er een powershell gestart worden met admin rechten.

[kiddingguy]

Filmpje heb ik bekeken. Vandaar ook mijn vraag of dit ook bij andere installers opgestart kan worden.
Kennelijk wordt er via WU wat getriggerd dat dit mogelijk gemaakt kan worden binnen Windows. Met een admin-/system-account.

En dan lijkt het me dat dit niet alleen een Razer-dingetje is, maar meer systeembreed /yikes

[Z80]

Het probleem zit toch echt in de Razer software. Vanuit de softwareinstaller kan er een uitstapje gemaakt worden. Iets dat niet mogelijk zou moeten zijn.
En ja het zou bij elke softwareinstaller voor kunnen komen. Het is gewoon een programmeerfout. Wel eentje die reeds heel lang bekend is en waar normaal gesproken ook op gecontroleerd word.

En nee het komt niet uit de Windows Update server. Deze levert enkel de driver. De driver haalt vervolgens de software van Razer en start deze.

[kiddingguy]

Klopt dat er vanuit de installer een detour gemaakt kan worden, richting GUI/nieuwe, eigen, installer.
Maar.... dit zou toch eigenlijk niet moeten kunnen?!

Waarschijnlijk kip-ei verhaal dit.
Goed dat het is aangekaart en nu kunnen de wijze programmeurs van Razer (en Microsoft?) een fix hiervoor gaan bedenken & programmeren.

[Speeder]

Erger nog het is onder het System-account.

[SunnieNL]

Nee, want hij voert geen wachtwoord in. Dat hij dat in het begin doet is om de monitoring tools te mogen starten.

Het probleem zit na de driver installatie. De drivers staan erop, maar starten na installatie automatich een extra installatie van de verschillende software die er nog bij hoort. Deze installatie draait al in admin-modus. Iets wat totaal overbodig is. Die admin modus zou de installatie moeten aanvragen op het moment van installeren, niet op het moment dat er gevraagd wordt wat je wilt installeren en waar dat geinstalleerd moet worden.

[turbojet80s]

Microsoft zal er echter niets meer aan doen. De ondersteuning voor Vista is voor mainstream gebruikers ongeveer 10 jaar geleden verlopen en de extended support is in 2017 verlopen.

[Jeroen73]

Het inpluggen van een muis of toetsenbord van Razer onder Windows 10 of 11 leidt ertoe dat Windows automatisch een driver installeert voor die hardware en vervolgens een installer start voor Razer-software.

[Pascal]

Wauw, waarom doet microsoft dit? Een installer starten als admin, vraag me af hoeveel andere hardware devices(installaties) betroffen zijn hiervan. Met een USB VID/PID Spoofer (Travis Facedancer) kan je alle hardware emuleren die je erin plugt.

[Reactie gewijzigd door Pascal op 24 juli 2024 04:43]

[the_stickie]

1) een systeem dat fysiek gecompromitteerd is (waar je dus een een usb stick in mag knallen) is bij voorbaat verloren voor een orchestrated attack
2) je kan alle usb drivers uit windows update installeren met je methode, dan heb je inderdaad nog een kwetsbaarheid nodig in één van die drivers of installers.

De reden dat de installer als admin moet draaien is om bestanden en registry entries te kunnen zetten in beschermde mappen/locaties.

[Pascal]

Een muis en toetsenbord erin knallen mag toch altijd? (Behalve als dat zo dicht gezet is dat alleen merk x met device y toegelaten is)

Microsoft moet geen gui-installers toelaten als system/admin gewoon inf/sys bestandjes inladen zonder gui. En als de gebruiker dan de extra RGB functionaliteit wil gebruiken, moeten ze maar zelf via gui installeren.

[the_stickie]

Neen, dat mag niet altijd. Dat mag/kan alleen als als aanvaller fysieke toegang hebt tot een systeem. In dat geval moet je het systeem sowieso al als verloren beschouwen.

Ik weet niet of driverinstalls zonder GUI altijd kunnen, maar het lijkt me sowieso juist dat Razor en Microsoft een gedeelde verantwoordelijkheid hebben als ene driver met privilege escalation vulnerability in de driverstore van Windows update belandt.

[Henk Poley]

Bij Apple zijn ze in ieder geval van de mening '1)' afgestapt:

[..] I’ve always thought “if they have physical access, it’s game over” to be a stupidly self-defeating security assertion. There’s no reason that needs to be true, other than that it takes a lot of work over a long time to close down all the avenues of attack

[..] I’ve heard it frequently throughout my career so I decided to do something about it while at Apple

Bron: https://twitter.com/XenoKovah/status/1425854015619964934

[the_stickie]

Bij Microsoft heel zeker niet.
Overigens kan je met fysieke acces altijd een DOS attack doen, door de boel stuk te maken. Privilege escalation is zover ik weet zowel bij Windows, iOS als Linux mogelijk door een custom boot te doen naar een voorbereid medium - en neen het wachtwoord op je bios gaat daar weinig aan voorkomen. Ook heb je allerlei mogelijkheden voor fysieke mitm om informatie te exfiltreren.

Mij lijkt het dus verstandig fysieke toegang als eerste beveiligingsstap te blijven zien.

[P-e-t-j-e]

Is daar safeboot/bitlocker/Tpm etc niet voor bedacht? Alleen booten vanaf vertrouwd medium/bootgedeelte?

[the_stickie]

Dat klopt. Bij een correcte implementatie van diskencryptie zoals bitlocker en tpm kan je niet zomaar van iets anders booten of de nodige aanpassingen doen op de bootschijf.
Langs de andere kant kan je met fysieke toegang ook rechtstreeks gebruik maken van systeembussen zoals pci-e en firewire waarmee je “simpelweg” de cpu kan laten doen wat je ook maar wil

[MSalters]

Met fysieke access tot de systeembus kom je alsnog niet om een SecureBoot omgeving heen. De beveiliging is cryptografisch - alles is ondertekend. Ja, je kunt natuurlijk alles behalve de CPU er uit rukken en vervangen door iets anders, maar op dat punt kun je net zo goed de hele PC inclusief CPU swappen. (Dat laatste is overigens een reële aanvalsvector: swap de PC van de CEO met een nep-PC om zijn password te stelen)

[the_stickie]

Nee? Er zijn ander massas proof of concepts van 'fake' hardware die syteemtoegang mogelijk maakt. https://en.wikipedia.org/wiki/DMA_attack. Omdat dat met externe usb poorten met thunderbolt echt te gortig werd, zijn er op os level mitigations, maar die werken niet voor alle bussen

Geloof ik echt dat een DMA attack op de laptop van een CEO gaat gebeuren? Neen. Maar er zijn betere targets als dat, en ook eenvoudigere aanvallen (sniffers, keyloggers, stelen, kapotmaken...)

Kunnen we wel gaan discussiëren over verschillende aanvallen, mitigaties best practices en oplossingen... blijft staan dat fysieke toegang tot allerhande problemen kan leiden. Zoveel dat de fysieke laag als eerste laag van defensie telt in zowat elk model van layered security (of tweede na de regeltjes ) waar ik bekend mee ben.
De aanbeveling van mij (en zover ik weet ook (nog steeds) van het MSRC) is een systeem waar malversanten vrij mee konden rommelen, als gecompromitteerd te beschouwen en offline te nemen voor onderzoek zoals je met een virus geïnfecteerde machine zou doen.

[fluffy1]

en neen het wachtwoord op je bios gaat daar weinig aan voorkomen

Dat hangt tegenwoordig toch wel van het systeem af. Ik ben intussen al verschillende systemen tegengekomen waar dat BIOS wachtwoord niet meer afhankelijk is van CMOS (en dus de procedure van batterijtje weghalen overleeft), en waarbij een reset via de jumper ook niet helpt.

Je gaat dan al erg creatief moeten worden om nog een custom boot te doen. (Mogelijk door de PC open te gooien en een andere HDD eraan te hangen oid.) Maar dan kan je beter gewoon de HDD waar je target data op staat jatten.

Also, als Bitlocker ingeschakeld staat ga je niet veel opschieten met een custom boot. Als je niet aan de SSD kan houdt het al snel op.

[Henk Poley]

Het is zelfs System, en niet eens 'slechts' Administrator.

[the_stickie]

SYSTEM heeft niet zozeer meer, danwel een andere set default permissies als Administrator. Blijft een feit dat beide privileged accounts zijn die (desnoods met wat workarounds) accounts kunnen aanmaken en beheren en zichzelf alle nodige rechten kunnen toekennen.

[McBacon]

Als admin kun je anders vrij weinig met SYSTEM-owned troep zonder dat het helemaal fucked up raakt. Andersom is dat toch echt wel anders, dus SYSTEM heeft wel degelijk hogere/meer rechten. ;]

[the_stickie]

Zoals gezegd hebben beide accounts alle rechten om rechten en privileges te nemen (dat je het dan fucked ligt aan jou ). Ook kan je als admin domweg elk proces als SYSTEM starten...
In de default configuratie zijn er behoorlijke verschillen - maar er zijn ook dingen die de administrator kan, die SYSTEM niet kan...

[Pep7777]

Wat me opvalt is dat er heel wat installers zijn die bij installatie of erger nog bij de-installatie een browser openen en dat dan doen met administrator privileges. Dat lijkt me ook het mogelijke begin van vergelijkbare ellende

[Sebazzz]

Helaas is het niet zo gemakkelijk om een process unelevated te starten vanuit een elevated proces. Normaal kan je gewoon een ShellExecute of CreateProcess doen om een ander proces te starten, echter de andere richting op vereist wat aanvullend werk.

[Pep7777]

Ok dan mis ik misschien even iets. Want de browser draait duidelijk onder een andere user dan ikzelf.
Ik werk op windows met losse admin en normale gebruiker. Dus ik nam ook aan dat de browser dan met dezelfde rechten als de installer zou draaien.
Goed als dat gelukkig niet zo is (maar echt vertrouwen heb ik het nooit gedaan)

[Henk Poley]

Je leest Sebazzz bericht verkeerd om. Hij zegt, een hoge rechten (denk System, Administrator) proces kan erg lastig een proces met jouw (lage) rechten starten. Daarom draait die browser dus 'per ongeluk' als Administrator. Omdat ze niet weten hoe het veilig zou moeten.

[Remzi1993]

Er wordt ook uitgelegd hoe je het toch kan doen via een omweg, bijvoorbeeld via Explorer. Je vraagt Explorer of een andere API/proces om het voor je te openen, zodat het wordt geopend door de current user session.

[Reactie gewijzigd door Remzi1993 op 24 juli 2024 04:43]

[the_stickie]

en omdat het geen zin heeft. de gebruiker moet immers elevaten voor het uitvoeren van een 'normale' installer: er is dus geen sprake van privilege escalation.

[Henk Poley]

Als je een normale gebruiker aanmaakt op een verse Windows 10 21H1 installatie. Daar op inlogt, een USB apparaat inprikt dat zich identificeert als Razer muis, dan kan je (als normale gebruiker) System rechten krijgen. Zonder verder iets van wachtwoorden of wat dan ook in te voeren.

Valt dit onder jouw 'de gebruiker moet immers elevaten .. er is dus geen sprake van privilege escalation' ?

[the_stickie]

mijn reactie refereety naar die van Pep7777 waar hij het heeft over uninstallers die een browser openenen.

Ik heb dus niet ontkent dat er een privilege escalation in de driver package van Razor zit, das een heel ander scenario (trusted driver)

[MSalters]

Nee, nu pas jij weer een Linux redenering toe op Windows.

Onder Windows zijn de rechten van een Administrator proces niet automatisch hoge rechten. Onder Linux is root simpelweg root, maar onder Windows zijn die dingen gescheiden. Een hoge-rechten proces kan dus prima een lage-rechten proces onder dezelfde user account starten.

Ja, die browser draait dus als Administrator, met wel met gewone gebruikersrechten. "Save As" vanuit de browser schrijft dus naar de Admin Downloads folder , maar een broswer exploit kan geen stille installer launchen.

[the_stickie]

Ik denk niet dat dat an sich een probleem is, aangezien het installeren of de-installeren van installers adminrechten vereist.

[kiddingguy]

Oopsy.
Toch wel weer knap hoe dergelijke onderzoekers dit (weer) bloot weten te leggen...
en dat Razer, in dit geval, ook weer snel met een fix komt [ze zullen wel moeten...]

[Speeder]

Dit is alleen te fixen door het pad vast te zetten. Het op gegeven van een installatiepad is een standaard feature van windows installer. In 99% van de gevallen krijg je die optie als je iets gaat installeren. Dus hij gaat nu Razer dwingen iets te fixen wat ze niet kunnen fixen behalve door een standaard pad af te dwingen bij de gebruiker, iets wat je eigenlijk ook niet wil.

Hoe ze dit echt zouden moeten oplossen is door niet automatisch die software te gaan installeren na de driver installatie. Geef de gebruiker gewoon de optie om dat zelf te doen en dan heb je dit hele probleem niet.

Daar naast heeft niet iedereen standaard in de context-menu van de explorer "open een powershell-windows hier" optie staan.

[Reactie gewijzigd door Speeder op 24 juli 2024 04:43]

[terror538]

Het pad forceren als de installatie gedraaid wordt vanuit het systeem als er hw toegevoegd wordt lijkt mij de simpelste (en imho correcte) fix.
Als de installer handmatig gestart wordt kan je prima de map selectie toestaan.

Wat ik gevaarlijker vind is dat MS blijkbaar niet screened hierop én dit dus gewoon pushed via het update systeem. Lijkt mij dat MS daar juist moet afdwingen dat installers geen mogelijkheden bevatten die tot een potentiële privilege escalation leiden .

[Speeder]

Het zijn twee losse dingen die door Razer aan elkaar gekoppeld zijn om de gebruiker te dwingen de software te installeren.

Het pad forceren is niet de correcte oplossing. Gewoon niet de software afdwingen om te installeren op dat moment. Is gewoon een regel aanpassen in het inf-bestand van de driver-installatie.

[jimshatt]

Installer achter UAC en/of niet starten wanneer je een standaardgebruiker bent.

[cricque]

Je moet het maar bedenken eigenlijk. Ik zou er nooit aan denken om effe powershell te openen in een directory als ik daar niet moet zijn ... Nuja gelukkig zijn er wel mensen die dit dus wel doen.
Nuja toch een kleine fout en als ontwikkelaar denk je hier nu ook niet bepaald echt aan. Maar als je wat doet met admin rechten, dan moet je toch een paar dingen extra testen. Dit zal wel opgenomen worden bij Razor als test

[SinergyX]

Ik begrijp nooit echt waarom er 'aanvullende' software aanwezig moet zijn voor een simpel iets als een muis te moeten laten werken, een Logitech apparaat werkt 'out of the box' probleemloos en moet je zelf achteraf (met voldoende rechten) de aanvullende software installeren.

Roccat had dit in de begin-jaren ook, inpluggen deed gewoon niets en moest je aparte software installeren die nodig was om uberhaubt te laten werken, die zal wel onder hetzelfde principe komen als deze exploit.

[Rabb]

Razer werkt (voor zover mijn ervaring) out of the box ook probleemloos. De software is voor extra's zoals makkelijk de dpi instellen en de rgb en macro's programmeren.

[Reactie gewijzigd door Rabb op 24 juli 2024 04:43]

[Settler11]

Gelukkig kan je dat ook, als je klaar bent met instellen, dat op je muis zelf opslaan. Daarna meteen de software verwijderd. Doei!

(Die van Logitech heb ik dan wel in de achtergrond ivm autoupdates)

[Rabb]

Maar is het dan dus ook mogelijk om de bug te gebruiken lang nadát de hardware is geïnstalleerd? Aangezien het probleem in de installatie map zit en niet in de installer.

[rikkert278]

Nee, want elke volgende keer wordt de Razer Synapse GUI software uitgevoerd door de gelimiteerde gebruiker zelf (ofwel in de context van de gelimiteerde gebruiker) zodra hij op zijn account inlogt. Als je na het inloggen bijvoorbeeld in Task Manager zou kijken, dan is User de eigenaar van het Razer Synapse GUI proces i.p.v. het systeem account.

Alleen als het apparaat voor het eerst wordt verbonden met de PC worden de benodigde drivers gedownload van het internet en vervolgens direct geïnstalleerd. Na het installeren van de drivers (waarvoor de allerhoogste privileges vereist zijn) wordt er direct in datzelfde proces, onder het systeem account en dus zonder de context terug te wisselen naar de momenteel ingelogde gebruiker, het Razer Synapse GUI programma opgestart.

Dit is de reden dat de user interface die direct na het installeren van de drivers aan de gebruiker met beperkte rechten wordt getoond in feite wordt uitgevoerd onder, en dus met de privileges van het systeem account. Als dat proces met systeem rechten dan bijvoorbeeld een opdracht prompt start (d.m.v. het trucje dat in de video wordt gebruikt), dan draait dat opdracht prompt dus in de context van het systeem account en heb je dus in feite als beperkte gebruiker toch nog volledig toegang tot de computer via het opdracht prompt.

En tot overmaat van ramp hebben alle processen die je vervolgens start via het opdracht prompt ook automatisch de privileges van het systeem account. Mocht je kwaad willen dan ben je op dit moment een olifant in een porseleinwinkel, want toegang tot het admin of systeem account krijgen (e.g. je privileges escaleren naar het hoogste niveau) is over het algemeen gezien het moeilijkste en meest tijdrovende onderdeel van het hacken van een systeem

context = het gebruikersaccount waaronder een proces wordt uitgevoerd, e.g. de 'eigenaar' van het proces

Dit is de kolom in kwestie in Task Manager: https://i.imgur.com/iPUg4io.png

Edit: het plaatje embedden wil niet werken, dus het moet dan maar met een linkje. Als je op de link klikt dan kun je een screenshot van taakbeheer bekijken waarin ik de kolom heb aangegeven die ik bedoel.

[Reactie gewijzigd door rikkert278 op 24 juli 2024 04:43]