Beveiligingsonderzoeker verkrijgt systeemrechten op Windows 10 S

Onderzoeker Matthew Hickey van beveiligingsbedrijf Hacker House heeft aangetoond hoe rechten op system-niveau in Windows 10 S te verkrijgen zijn. Microsoft blijft bij zijn onlangs geuite claim dat het systeem niet kwetsbaar is voor ransomware.

Hickey, ook bekend onder de naam Hacker Fantastic, voerde de actie uit op verzoek van ZDNet. Daarmee wilde de site de recente claim van Microsoft op de proef stellen dat 'geen enkele bekende ransomware op Windows 10 S werkt'. Om dit te onderzoeken, werd gebruikgemaakt van een Surface Laptop, die Microsoft in mei aankondigde en die het nieuwe systeem draait. Windows 10 S kent verschillende beperkingen. Zo is het alleen mogelijk om applicaties uit de Windows Store te installeren. Bovendien is er geen toegang tot een opdrachtprompt of PowerShell, aldus ZDNet.

De onderzoeker ging te werk door een kwaadaardig Word-document met macro's te creëren, waarmee het mogelijk is om een dll-injectie uit te voeren. Om het te openen, was het nodig om Word met beheerdersrechten te starten vanuit taakbeheer, al zou dit volgens Hickey te automatiseren zijn met een uitgebreidere macro. Om de restricties van 'protected view', die voorkomen dat gedownloade documenten macro's kunnen uitvoeren, te omzeilen, opende hij het kwaadaardige bestand vanuit een netwerklocatie. Op die manier kon hij de macro uitvoeren door op de corresponderende waarschuwing te klikken.

Vervolgens werd de code uitgevoerd, waardoor Hickey toegang kon krijgen tot een shell met beheerdersrechten. Daardoor was hij in staat een Metasploit-payload te downloaden, die hem de hoogste toegangsrechten op systeemniveau liet bereiken. Van daaruit kan hij bijvoorbeeld antivirus en firewalls uitschakelen en het systeem kwetsbaar maken voor kwaadaardige software, inclusief ransomware, zo legt Hickey aan de site uit. Dit deed hij echter niet, naar eigen zeggen om het netwerk niet in gevaar te brengen. Het hele proces duurde drie uur en was volgens de onderzoeker 'makkelijker dan verwacht'.

Microsoft reageerde op de bevindingen van Hickey met: "Begin juni zeiden wij dat Windows 10 S niet kwetsbaar is voor bekende vormen van ransomware en op basis van de ontvangen informatie is deze bewering nog steeds waar." Volgens ZDNet is te beargumenteren dat de getoonde aanval te gecompliceerd is voor een werkelijke aanval, omdat deze afhankelijk is van fysieke toegang of social engineering.

Reacties (87)

Om het te openen, was het nodig om Word met beheerdersrechten te starten vanuit taakbeheer,

In andere woorden, hij kreeg beheerdersrechten toen hij een applicatie startten met beheerdersrechten?

Ja, nogal logisch dat je dan beheerdersrechten hebt. Je start de applicatie als beheerder op, dan heb je dus ook beheerdersrechten, zoals de naam al aangeeft.

Op deze manier gaat het natuurlijk nergens over. Als je als root inlogged op je Linux-machine heb je immers ook root-rechten.

In andere woorden, hij kreeg beheerdersrechten toen hij een applicatie startten met beheerdersrechten?

Onder Windows is er nog iets boven "Administrator", namelijk SYSTEM. Het is niet de bedoeling dat mensen dat niveau bereiken. Hij logde in met Administrator-rechten en verkreeg daarna SYSTEM-rechten.

Dan nog:
A) hij opende word met beheerdersrechten. Iets wat al niet 123 zomaar kan
hij zette het bestand op een veilige locatie waardoor protected view werd uitgeschakeld, belangrijk daarin: dan moet je ook nog eens het document zelf geschreven hebben. Bestanden die je download krijgen namelijk een flag mee van onveilig die blijft bestaan als je hem op een veilige plek zet. Die moet je dan eerst deblokkeren.

Laat hem eerst maar zien dat het kan via internet of gemaild bestand, dan praten we verder.

best wel ver gezocht inderdaad. Macro melding zal je toch wel krijgen als die al niet uitgeschakeld staan. Al zou iemand al macros gebruiken, dan ook nog is trusted zones instellen. Tja dan ben je gewoon niet handig bezig. Aangezien het wel bekend is dat je met macros een hoop kan doen.

Bewust kan ik vrij eenvoudig SYSTEM rechten krijgen onder Windows 10. heb 2 Executables nodig of de mogelijkheid om CSCRIPT.EXE of CMD uit te voeren. Vanuit Word en Excel is het eigenlijk vrij simpel als je eenmaal admin bent.

Het is vrij eenvoudig ook anders te benaderen, ik doe het ook ook wel eens met SchTasks.exe. Als Administrator kan je gewoon het commando:

schtasks /create /sc onstart /tn "name" /tr "cscript.exe C:\jouwapplicatie.vbs" /ru SYSTEM

Uitvoeren. In dit VBS Script maak je een interactive scheduled task aan of spawn je een nieuwe vbs, of cmd of wat dan ook als interactief proces. Dat geeft je dan interactief SYSTEM rechten.

Maar zo lastig is het niet hoor om dat alsnog te krijgen. Ik heb ooit eens een tool geschreven om de distributed.net client over een windows netwerk op alle verbonden machines tre kunnen installeren, verwijderen en beheren. Daar gebruikte ik dat ook om de service als system te kunnen starten. Eens zoeken in de source code. Als je admin bent kun je zo system krijgen:
[code]
//------------------------------------------------------------------------------
// Handle any missing privileges
//------------------------------------------------------------------------------
bool __fastcall TAccountForm::HandlePrivs()
{
// See if the current user has SE_TCB_NAME (act as part of the OS)
bool hasSeTcbNameRight = CheckAccountPrivilege("SeTcbPrivilege");
// We first check if we can add this privilege. To add it we require
// admin rights. We assume only admins have SeTakeOwnershipPrivilege.
bool hasAdminRights = CheckAccountPrivilege("SeTakeOwnershipPrivilege");

if ( !hasSeTcbNameRight ) {
if ( !hasAdminRights ) {
MessageBox(NULL, "Your current account has insufficient rights to change the user context this program runs under!\nTo change this you should allow the current user to run as part of the operating system.\nTo add this privilege you require administrative rights, which you currently don't have.", Application->Title.c_str(), MB_OK|MB_ICONWARNING);
} else if ( MessageBox(NULL, "Your current account has insufficient rights to change the account this program runs under!\nTo change this you should allow the current user to run as part of the operating system.\nShall I try to add this privilege to your account now?", Application->Title.c_str(), MB_YESNO|MB_ICONWARNING) == IDYES ) {
hasSeTcbNameRight = AddAccountSeTcbPrivilege();
}
}
return hasSeTcbNameRight;
}

//------------------------------------------------------------------------------
// Add the SeTcbPrivilege to the current account.
//------------------------------------------------------------------------------
bool __fastcall TAccountForm::AddAccountSeTcbPrivilege()
{
bool result = false;
// Get SID of current account. This method allocates the memory to hold
// this SID so it should be freed later.
if ( GetCurrentSID(&fSid) ) {
if ( !AddTcbPrivilege(fSid) ) {
MessageBox(NULL, "The program failed to add the required privilege to your account.", Application->Title.c_str(), MB_OK);
} else {
result = true;
MessageBox(NULL, "The program added the required privilege to your account.\n\nYou need to logoff and login again or to reboot to make the changes take effect.", Application->Title.c_str(), MB_OK);
}
}
// Free memory allocated for SID.
if( fSid )
HeapFree(GetProcessHeap(), 0, fSid);

return result;
}

//------------------------------------------------------------------------------
// Add the SeTcbPrivilege to the user account. For this method to succeed the
// caller requires administrative rights.
//------------------------------------------------------------------------------
bool __fastcall TAccountForm::AddTcbPrivilege(void* psid)
{
NTSTATUS result = -1;
LSA_HANDLE hPolicy = 0;
LSA_UNICODE_STRING usPriv;
wchar_t str[32];

memset(str, 0, sizeof(str));
wcscpy(str, L"SeTcbPrivilege");
USHORT strLen = (USHORT)wcslen(str);

usPriv.Buffer = str;
usPriv.Length = (USHORT)(strLen * sizeof(wchar_t));
usPriv.MaximumLength = (USHORT)((strLen + 1) * sizeof(wchar_t));

LSA_OBJECT_ATTRIBUTES oa;
memset(&oa, 0, sizeof(oa));

DynamicLsaOpenPolicy(NULL, &oa, POLICY_LOOKUP_NAMES | POLICY_CREATE_ACCOUNT, &hPolicy);
if ( hPolicy ) {
result = DynamicLsaAddAccountRights(hPolicy, psid, &usPriv, 1);
DynamicLsaClose(hPolicy);
}
return (result == STATUS_SUCCESS);
}
[/code]

Edit: hoe krijg ik dit fatsoenlijk ingesprongen?

[Reactie gewijzigd door Morgan4321 op 23 juni 2017 18:55]

Maar werkte dit ook met Windows 10 S?

Dit is code uit 2001 en ik zie in de comments nog iets staan dat er in XP iets veranderd was t.o.v. windows 2000. Dat zou ik dus moeten testen, maar ik heb hier geen windows 10 (s of anders). Ik zou er niet voetstoots van uit gaan. Onder windows 7 werkt het in elk geval.

Maar dan heb je admin rechten eh.
Verder is Windows 10 verandert dat je verhaal niet opgaat.
Misschien eerst eens dubbelchecken? Je +2 geeft al aan dat je verwarring zaait.
Niet handig in een Windows 10 nieuwspost.

[Reactie gewijzigd door Tweaker1234 op 24 juni 2017 00:42]

Je kunt er een pastebin van maken.

SYSTEM is niet "hoger" dan een local administrator. Het enige verschil is dat SYSTEM een security prinicpal zonder wachtwoord is, en geen normaal account.

Verder zijn er wat zaken (bv. bepaalde registry keys) waar system standaard wel bij mag, en een administrator niet. Maar die rechten kan een administrator simpel eenvoudig aanpasen. Een administrator mag immers alles, hij mag dus ook processen starten in de context van een security principal.

Funny; boven 'SYSTEM' staat natuurlijk de MICROSOFT Organisation.
Nu weten we echt niet meer wat de computer doet. Big brother is watching you.

Ik denk dat het er om gaat dat dan niet alleen word die rechten heeft, maar ook de code van de macro. Je kan dus praktisch alles doen dan.

Ja, dat is nogal logisch. Als je Word uitvoert als admninistrator, wordt alles wat je vanuit Word start ook onder die credentials uitgevoerd.

Maar in de praktijk open je Word (of welke applicatie dan ook) nooit als admin, maar gewoon als normale user.

Ik vind dit bijzonder vergezocht allemaal.

Ja, dat is nogal logisch. Als je Word uitvoert als admninistrator, wordt alles wat je vanuit Word start ook onder die credentials uitgevoerd.

Maar in de praktijk open je Word (of welke applicatie dan ook) nooit als admin, maar gewoon als normale user.

Ik vind dit bijzonder vergezocht allemaal.

Dat vind ik een nogal gemakkelijke aanname van je.
Ik heb minimaal 1 programma/programmeeromgeving die dat (run as administrator) vereist voor een deel van de acties.

[...]
Dat vind ik een nogal gemakkelijke aanname van je.
Ik heb minimaal 1 programma/programmeeromgeving die dat (run as administrator) vereist voor een deel van de acties.

Slecht geschreven en voldoet niet aan de Microsoft Guidelines. Of het voert bepaalde acties uit die alleen als Administrator kunnen omdat dat de bedoeling is.

[Reactie gewijzigd door Wim-Bart op 24 juni 2017 02:26]

Visual Studio (van Microsoft) moet in Administrator mode draaien om IIS-processen te kunnen debuggen.

[Reactie gewijzigd door comecme op 24 juni 2017 12:58]

Klopt helemaal. Dat is dan ook een bewuste keuze omdat het anders niet kan

Daarom debug je sites het liefst ook niet in IIS, maar in IIS Express. Er zijn natuurlijk uitzonderingen maar voor web development zou je over het algemeen geen administrator rechten nodig moeten hebben in VS.

Als je je doelwit echter eerst Word in admin-mode kan doen openen om daar dan vervolgens een besmet document in te laten openen dan kan je net zo goed meteen het slachtoffer overtuigen om je malware in admin-mode uit te voeren.

al zou dit volgens Hickey te automatiseren zijn met een uitgebreidere macro

Dit zou een interessanter deel zijn mocht hij dit daadwerkelijk voor elkaar krijgen.
Zelfs nagebootste muisklikken vanuit een user-mode programma worden namelijk niet doorgegeven aan toepassingen die als administrator lopen.
Maar goed, daar heeft hij vooralsnog geen proof of concept van, dus echt veel is er momenteel nog niet aan de hand.

Die malware kan niet geïnstalleerd worden (met die creds) omdat dergelijke applicaties niet uit de windows store gedownload kunnen worden.

Met windows S 10 zou het per ongeluk installeren van Malware omdat je niet goed oplet verleden tijd moeten zijn.

Het duurde in totaal 3 uur dus eenvoudige macro zal het niet zijn.

Totaal 3 uur, je moet eerst allerlei dingen uitzoeken en testen voordat je een daadwerkelijk werkende macro hebt. 3 uur = simpel.

Laten we het erop houden dat Windows 10 S in essentie natuurlijk gewoon gelijk is aan Windows 10. De meeste hacks waarbij je fysieke toegang hebt tot een systeem zullen hier ook werken. Echter is de claim dat ransomware geen vat kan nemen op dit systeem. En mensen die ransomware verspreiden hebben over het algemeen geen fysieke toegang tot de systemen die ze infecteren.

De code die bij deze hack gebruikt is zal dus al lang bestaan. Dit is geen nieuwe infectie methode. Hij zal wel creatief moeten zijn met het laten uitvoeren van de code. Omdat Windows 10 S je alleen toestaat om code uit te voeren van applicaties die uit de store komen. Daar hoort Word dus ook bij. Hier zit natuurlijk het probleem waar deze hacker gebruik van maakt. Namelijk dat Word code uit macro's uitvoert. Deze komen natuurlijk niet uit de store. Al zit hier wel wat beveiliging op, die ook omzeilt is, dat Word geen macro's uitvoert van een onbekende bron.

Als je als Linux user een applicatie opstart met sudo, en die applicatie dropt je in een rootshell, dan heb je een vergelijking (En dan heb ik het niet over een shell opstarten via sudo ). Een app draaien met verhoogde rechten betekent nog niet dat je toegang hoort te krijgen tot alles met die rechten; dat is het hele idee van sudo (en het starten van een app als administrator onder windows).

"Om het te openen, was het nodig om Word met beheerdersrechten te starten vanuit taakbeheer, "

Ja ja.. zo lust ik er nog wel een.

Volgende news bericht wordt dan : Linux is te kraken dmv de applicatie met sudo op te starten waarna root rechten verkregen kunnen worden.

"Om het te openen, was het nodig om Word met beheerdersrechten te starten vanuit taakbeheer, "

Ik neem aan dat het hier om SYSTEM-rechten gaat. Het allerhoogste niveau dat alleen bedoelt is voor het OS zelf en niet voor gebruikers. Ook niet voor gebruikers met Administrator-rechten.
Als Linux-gebruiker vind ik het een gek idee dat ik als eigenaar van het systeem niet alles mag doen en bepaalde rechten van me worden weggehouden, maar zo werkt het nu eenmaal onder Windows.

Volgens mij verschillen de rechten tussen admin en system niet wezenlijk, het is er niet om jou rechten te onthouden maar om bepaalde processen en services toegang te verlenen wanneer er geen gebruiker ingelogd is, zoals tijdens een installatie of in het lock/loginschem. Daarom moet dit ook gescheiden gehouden worden en is het dus ook niet de bedoeling dat je daarbij kan, je hebt als admin al volledige bestandstoegang en windows klaagt volgens mij enkel als je met bestanden gerelateerd aan draaiende processen in de windows dir gaat zitten klooien, doe je dit vanuit een recovery omgeving oid dan kan het vaak weer wel met diezelfde admin rechten.

Volgens mij kun ie als system zelfs je windows dir verwijderen, ofwel je windows snel corrupt maken. Iets dat als admin weer beveiligd is

Enkel in een "online" omgeving dus, wanneer je als admin in de recovery omgeving inlogt kun je naar hartenlust je windows directory verneuken. Het blijft echter veilig omdat daarvoor fysieke toegang benodigd is.

Vergelijkbaar met 'sudo rm -rf /'. Een actie die je maar beter niet doet op een Linux systeem, tenzij je een verse install in gedachten hebt.

je hebt als admin al volledige bestandstoegang en windows klaagt volgens mij enkel als je met bestanden gerelateerd aan draaiende processen in de windows dir gaat zitten klooien

Dat klinkt op zich interessant genoeg, al weet ik niet genoeg van Windows om het echt goed te beoordelen. Mij lijkt geheime toegang tot dat soort processen handig als je computer van een systeembeheerder wilt gebruiken als opstapje naar groter hacks.

Ik snap er ook niet veel van, maar wat ik uit popNL z'n verhaal opmaak is dat SYSTEM eigenlijk de root user is, en admin's ook alleen kan SYSTEM processen draaien on-boot zonder dat er een user ingelogd is. Admin's kun je dan gelijk trekken met de mensen in je sudo'ers file ( afhankelijk van je setup natuurlijk), en dat ze dan op Windows blijkbaar niet het recht hebben op system-wide startup processen te starten.

Mogelijk dat het ook helemaal niet de bedoeling is van Windows om als gebruiker überhaupt ingelogd te kunnen zijn als SYSTEM user, maar was de gebruikte exploit nodig om de 'sandbox' van Windows 10 S te omzeilen.

Een soort root user, maar dan bedoeld voor system-wide startup processen en niet bedoeld om actief op in te kunnen loggen denk ik zo.

( Ik heb helemaal geen verstand van Windows policies dus correct me if I'm wrong ).

Volgens mij probeerde je dan ook Windows z'n veiligheid te discrediteren door te kijken naar hun policies. Ik denk dat dat wel snor zit, maar dat de onveiligheid zit in het feit dat de Windows code base 1 grote monolith is met legacy zooi waar niemand veel omkijken meer naar heeft. (Ze hebben hun enorme code-base toch naar git weten te zetten door een speciaal filesystem te bouwen voor git + nog meer aanpassingen zodat git niet vastloopt. Bron https://blogs.msdn.micros...-git-virtual-file-system/)

Dus gaan ze maar reactief security issues oplossen als iemand hun er op wijst (zou ik doen). Echter werk ik niet bij Microsoft dus dit hierboven zijn allemaal aannames en is het van mijn kant ook maar gissen.

[Reactie gewijzigd door Oerdond3r op 23 juni 2017 19:15]

Een soort root user, maar dan bedoeld voor system-wide startup processen en niet bedoeld om actief op in te kunnen loggen denk ik zo.

Ja, dat is wel waar SYSTEM in de kern voor bedoeld is, maar er zijn nog wel een paar nuances. Zo zijn bepaalde security-gevoelige windows APIs enkel en alleen door de SYSTEM account aan te roepen en door geen enkele andere account, ook niet door administrators.

Je zit zover ik weet toch niet ver naast de werkelijkheid hoor.
Ik dacht inderdaad ook dat System rechten voor opstarten etc zij en niet om in te loggen.

Kan me nog herinneren dat iemand zei dat je een 1 of 2 mappen van de boot op 'onzichtbaar/hide' moet zetten en dan rebooten. Dan blijf je in een boot-loop steken omdat hij de dingen niet kan vinden. Bizar maar effectief. Succes met daaruit te komen. Leuk om eens op school te doen op een Desktop, op een server heb je echt vlaggen

Deze 'hack' is inderdaad interessant maar zoals ze zelf al aangeven vooral eigenlijk klinisch. Want in de praktijk zal het erg moeilijk zijn dit te verwezenlijken. Toch goed gedaan en Microsoft weet wat ze ertegen kunnen doen. Ik denk effectief dat dit nog wel eens de veiligste Windows kan zijn tot nu toe.

Nee die moet geopend worden met adminrechten.
De systemrechten zijn er na metasploit.

[...]
Ik neem aan dat het hier om SYSTEM-rechten gaat. Het allerhoogste niveau dat alleen bedoelt is voor het OS zelf en niet voor gebruikers. Ook niet voor gebruikers met Administrator-rechten.

Op normale Windows builds (ik heb geen ervaring met de S versie is het volkomen normaal (en 'by design') dat je als Admin (of eigenlijk: user die lid is van de lokale groep 'Administrators') voldoende rechten om processen te starten als System. Daar zijn geen geheimzinnige tools voor nodig.*

Omdat processen en installaties die uitgevoerd worden als onderdeel van een automatische installatie van Windows via bijvoorbeeld SCCM ook allemaal als localsystem worden uitgevoerd is testen op basis van deze rechten voor mijn werk ook heel normaal.

Je kunt het vergelijken met rechten op domain-niveau: Als je al 'Domain Admin' bent heb je in een single domain voldoende rechten om jezelf 'Enterprise Admin' te maken op datzelfde domain; ook dat is geen fout.

Beide voorbeelden geven aan dat met het uitdelen van rechten voorzichtig moet worden omgesprongen; met grote rechten komen grote verantwoordelijkheden.

Dat de ontwikkelaar uit dit artikel deze rechten ook kan krijgen op de S versie van Win10 geeft vooral aan dat het OS zich kennelijk op dit onderdeel als een normale Windows gedraagt.

*De Microsoft/SysInternals tool PSEXEC kent overigens wel een hele snelle methode om snel iets te testen als 'System'.

Op een normaal Windows systeem kun je met PSEXEC system krijgen, maar dan moet je PSEXEC wel als administrator starten. Het system account heeft dan wel meer rechten dan een user account met administrator privileges, het is wel bereikbaar als je eenmaal die administrator privileges hebt.

Wat hier aan de hand is, is volgens mij het volgende. Die Windows S is geen gewone windows, dit is een versie die alleen software uit de Windows Store kan installeren. Een beetje a la iPad dus. Het ding is dus vooral dit te omzeilen door middel van een DLL injectie in een goedgekeurd proces, MS Word. Wat er daarna gebeurd is eigenlijk vrij standaard, als admin een stuk code draaien dat vergelijkbaar is met PSEXEC.

Wat dit vooral aantoont is dat, zodra er een proces op de groene lijst staat, dit zo'n beetje alles mag wat een normaal proces op een normale Windows versie ook mag.

Ik vond het ook nogal obvious klinken. Zolang Word op een Windows pc staat en je kan een kwaadaardige macro injecteren (door middel van een kwaadaardige mail met bijlage bijvoorbeeld), ben je de sjaak.

[Reactie gewijzigd door AnonymousWP op 23 juni 2017 17:45]

Niet per se dus, zo een macro kan blijkbaar alleen iets uitrichten als Word met adminrechten gestart wordt.

Op Windows bakken heb je nog een niveau boven administrator: SYSTEM. Hij heeft na het krijgen van Administrator rechten ook SYSTEM rechten gekregen, iets wat dus echt niet zou moeten kunnen, ook al open je iets als administrator

Als local admin is het niet moeilijk om system rechten te krijgen. INSSVC.EXE en RUNSVC.EXE zijn voldoende, CMD.exe als subprocess en je bent klaar. Zodra je Administrator bent kan je alles. Eventueel een VBS als service met de juiste systemcall exports er in voor stopService en startService en je bent er ook.

En dat alles zou dus op Windows 10S niet moeten kunnen volgens MIcrosoft ;-)

Als admin kun je zonder moeite system rechten krijgen. Is nooit een uitdaging geweest.

met @batjes heeft Microsoft dus een probleem met hun nieuwe OS variant

Je vergeet een stukje.

... al zou dit volgens Hickey te automatiseren zijn met een uitgebreidere macro

Uhuh, laat maar zien dan.
Teveel Steven Spielberg films gezien: "I am a hacker." -> beweegt wat met de muis -> "hacked."

Inderdaad, deze hacker weet niet eens dat je het taakbeheer niet kan besturen zonder directe hardware input of signed drivers?

Success om via een script oid iets via de task manager uitgevoerd te krijgen.

Je kan dat iemand laten doen door een probleempje te creëren en dan die 'oplossing' aandragen.

"Om het te openen, was het nodig om Word met beheerdersrechten te starten vanuit taakbeheer, "

Ja ja.. zo lust ik er nog wel een.

Volgende news bericht wordt dan : Linux is te kraken dmv de applicatie met sudo op te starten waarna root rechten verkregen kunnen worden.

Je kan dat iemand laten doen door een probleempje te creëren en dan die 'oplossing' aandragen.

Had ie net zo goed een cmd kunnen openen op die wijze. Wat een flut onderzoek.

Dit soort nieuwsberichten vind ik eigenlijk smerig. Windows 10 S is (naar mijn mening) een goede poging om een veilig OS op de markt te brengen. Het is gewaagd, dat wel. Maar als Jan met de pet nu al artikels leest als "Beveiligingsonderzoeker verkrijgt systeemrechten op Windows 10 S", dan denken ze onmiddellijk al dat het systeem brak is. En dit is niet het geval. Deze kwetsbaarheid zal zeer onwaarschijnlijk een probleem vormen.

Waarom denk je dat? Mij lijkt het juist een ernstig 'lek' (eigenlijk is het geen lek. De gebruiker hoeft alleen maar een (domme) fout te maken). Het kan als volgt gebeuren: crimineel/hacker/you name it, hoeft alleen maar een mail te versturen met daarin een kwaadaardig Word document. Vervolgens schakelt de gebruiker macro's in, en het is gebeurd.

@wildhagen @Blokker_1999 En ja, je moet dat vanuit taakbeheer doen, maar via een kwaadaardig script dat wordt geïnjecteerd is dat zo gebeurd.

[Reactie gewijzigd door AnonymousWP op 23 juni 2017 17:58]

"Om het te openen, was het nodig om Word met beheerdersrechten te starten vanuit taakbeheer."
Wie start er nu Word via taakbeheer.

Ik heb daar even overheen gelezen. Ach, via een kwaadaardig script dat wordt geïnjecteerd is dat zo gebeurd.

[Reactie gewijzigd door AnonymousWP op 23 juni 2017 17:48]

Is dat zo? Als de gebruiker geen admin is, is dat vrij lastig. Dan moet je al credentials hebben van een admin gebruiker.
Lijkt me dus ook nog niet helemaal zo evident.

Als ie het trucje kan als regular user is het misschien nieuwswaardig. Als je al een app hebt runnen met admin rechten is er natuurlijk niet veel meer over om te hacken.

heel die omweg is juist om tot een shell met adminrechten te komen, waar je dus ... een script kunt uitvoeren

Nee dat is niet zo gebeurd. Processen onder Windows die met admin rechten draaien, zijn beschermed tegen "random" input.

Je kan een task manager alleen bedienen via een hardware input zoals keyboard en muis. Of je moet een door MS gesigneerde driver zien te installeren.

Dat gaat je via een macro scriptje echt niet lukken.

Het artikel zegt echter wel:

Om het te openen, was het nodig om Word met beheerdersrechten te starten vanuit taakbeheer, al zou dit volgens Hickey te automatiseren zijn met een uitgebreidere macro.

Let op het woordje "zou".

Natuurlijk kan deze beveiliging ook een gat bevatten, theoretisch is het onwaarschijnlijk dat het niet te kraken valt.

Maar met een simpel macro scriptje, ga je niet de taak beheerder kunnen beinvloeden. Je moet al admin rechten hebben wil je dat kunnen, of zoals gezegd, MS zo ver zien te krijgen je driver te signen. (en dan nog krijg je het niet zonder admin rechten geinstalleerd).

in Windows kunnen processen die onder een lagere privilege draaien niet de processen beïnvloeden die op hogere privileges draaien.

Neem maar als voorbeeld Teamviewer. Start eens Quicksupport op een computer zonder admin rechten. Het werkt wel. Maar zodra een taakbeheer, MMC console of iets wat onder admin rechten uitgevoerd worden zul je achter komen dat het QuickSupport tool van Teamviewer niet deze processen kunnen beinvloeden. Dit komt omdat deze processen een hogere privilege draaien dan Teamviewer Quick Support op het moment.

Dus dat theoretische scriptje die de taakbeheer beinvloed is dan ook op die manier van de kaart geveegd.

"Om het te openen, was het nodig om Word met beheerdersrechten te starten vanuit taakbeheer."
Wie start er nu Word via taakbeheer.

Wetenschappers die geïnteresseerd zijn in de gaten, niet in saaie code er om heen om de exploit geschikt te maken voor criminelen. De onderzoeker schrijft zelf al dat het niet noodzakelijk is om het met de hand te doen, met een beetje moeite programmeer je dat zo er bij. Dat is voor wetenschappers alleen niet interessant.

Maar je bent nog steeds administrator om dit alles te kunnen doen. Dat is een vrij onwaarschijnlijke status op een netwerk voor een user.

Niet alleen dat, wie start het dan expliciet met admin-rechten?

Nee, want die macro's worden dan uitgevoerd onder de user-credentials, en hebben dan geen toegang tot het systeem.

Volgens het artikel heeft hij Word met beheerdersrechten gestart (wat in de praktijk dus niemand doet), en meldt vervolgens dat hij beheerdersrechten heeft. Ja, nogal logisch...

En beheerdersrechten forceren vanuit een macro, zoals hij stelt, zou ik knap vinden., Hoe ziet hij dat voor zich dan, met dingen als UAC etc ertussen die dat gaan dwarsbomen?

Daar zou het toch ook een exploit voor zijn? Als het zomaar kon was er geen hacker voor nodig. En als alles was zoals Microsoft het bedoelt of verkoopt had WannaCry geen bestaansrecht gehad.
Maar helaas, er zitten fouten in software die misbruikt kunnen worden.

Zeker, maar de volgorde is hier heel anders, Je moet eerst admin zijn om de zaak aan het rollen te krijgen. Als admin kun je wel akeliger zaken doen zonder al dez eomwegen.

Onder Windows 10 S dus niet volgens Microsoft... dat is nou net mijn punt. Op een normaal systeem: ja. Maar onder S zegt MS dat het niet kan, maar het kan dus wel. Omdat het als admin moet gestart worden zal het inderdaad niet zo 1-2-3 als een stuk ransomware binnenkomen, maar bottom line is dat er (nu al) in het systeem binnengedrongen kan worden.

Er wordt niet binnengedrongen, de admin zit al binnen. Nu is er een omslachtinge methode bedacht op als admin een macro te starten die vervolgens ( na negeren waarschuwing) onder die admin account zaken doet.
Als een admin de schijf gaat formateren is dat ook geen "lek", maar je bent wel al je data kwijt.
Microsoft geeft aan dat er geen bestaande malware op Ws geinstalleerd kan worden. Dat is niet weerlegd door deze "test".

Daar zou het toch ook een exploit voor zijn? Als het zomaar kon was er geen hacker voor nodig. En als alles was zoals Microsoft het bedoelt of verkoopt had WannaCry geen bestaansrecht gehad.
Maar helaas, er zitten fouten in software die misbruikt kunnen worden.

Ik geef een inbreker de sleutel van mijn huis, en vraag hem om aan te tonen dat hij kan inbreken zonder via de deur in te breken maar hij mag wel via de deur naar binnen om te prepareren. Hij loopt naar binnen met de sleutel, zet een raam open. Komt weer naar buiten en klimt door het open raam naar binnen

En inbraak gelukt...

Moet je nog altijd, zonder dat de gebruiker iets moet doen, Word starten met admin rechten. Zie MS binnenkort nog een office update uitbrengen die voorkomt dat Office kan uitgevoerd worden met verhoogde rechten.

@AnonymousWP ; als het zo eenvoudig is kan je je natuurlijk afvragen waarom hij het niet in zijn POC heeft meegenomen.

[Reactie gewijzigd door Blokker_1999 op 23 juni 2017 18:01]

Naast wat de anderen al noemen, kun je het ook niet emailen. Dan opent het bestand namelijk in protected modus. Daarom moest het vanaf een netwerk locatie worden geopend. Ook iets wat niet heel veel gebruikers tegenwoordig nog doen.

Maar dan moet Microsoft niet gaan zeggen dat hun systeem 'niet te kraken is'.

Wordt anders (ook) niet beweerd...

niet kwetsbaar is voor bekende vormen van ransomware

_{betekent iets anders dan jouw bewering}

Wordt anders (ook) niet beweerd...

maar wel geimpliceerd. Ze hebben het echt wel opzettelijk zo verwoord dat een hoop mensen horen dat Windows10S bestand is tegen alle malware. De reactie van MS spreekt boekdelen: "op basis van de ontvangen informatie is deze bewering nog steeds waar."
Geen "Hey wat slim dat je toch iets hebt gevonden, bedankt voor het publiceren!" maar een zure en listige opmerking waarin ze nog een keer suggereren dat Win10S onkraakbaar is.

Het is gewoon allemaal marketing. Dat hoort er nu eenmaal bij. Gelukkig hebben we dit soort wetenschappers dat voor een reality check zorgt.

[Reactie gewijzigd door CAPSLOCK2000 op 23 juni 2017 18:42]

Is dit reality? Een administrator die rare zaken doet is zonder meer een probleem. Daar heb je geen OS voor nodig. En zonder de admin basis gebeurt er dus met deze opzet helemaal niets.

Dit heeft MS ook nooit beweerd. Dat zou naïef zijn. Ze zeiden dat geen enkele bekende ransomeware op Windows 10 S werkt. En deze nieuwe kwetsbaarheid lijkt me die statement niet direct te ontkrachten.

Dit soort nieuwsberichten vind ik eigenlijk smerig. Windows 10 S is (naar mijn mening) een goede poging om een veilig OS op de markt te brengen. Het is gewaagd, dat wel. Maar als Jan met de pet nu al artikels leest als "Beveiligingsonderzoeker verkrijgt systeemrechten op Windows 10 S", dan denken ze onmiddellijk al dat het systeem brak is. En dit is niet het geval. Deze kwetsbaarheid zal zeer onwaarschijnlijk een probleem vormen.

De meeste mensen denken nooit na over computerveiligheid en denken dat het allemaal wel vanzelf goed zal komen. Zelfs met het veiligste OS zal je zelf op moeten blijven letten en er niet van uitgaan dat de computer je wel zal beschermen. Wat dat betreft kan ik het dus niet erg vinden dat mensen verteld wordt dat Windows 10S ook niet de heilige graal is.

Agree.

En dan een +2 voor de post van Morgan4321 zegt weer het een en ander over hoe de post begrepen wordt door sommige consumenten. Levert meer verwarring dan duidelijkheid op.

Microsoft heeft een ongenuanceerde, misschien niet zo slimme claim gemaakt, en ZDNet heeft een hacker ingehuurd om binnen 3 uur te laten zien dat die claim niet klopt.

Microsoft het overkomen alsof het 100% dichtzat en dat blijkt dus niet het geval, in zekere zin wel handig voor mensen om te weten.

Maar de exploit is in de praktijk echter verwaarloosbaar ( dus hoe groot is de nieuwswaarde inderdaad ) . Je kunt er alleen niet van uit gaan dat als je je laptop aan handige personen uitleent je hem nog 100% virus / scam- / spywarevrij terugkrijgt denk ik dan?

[Reactie gewijzigd door Oerdond3r op 23 juni 2017 19:12]

klinkt spanned, maar hij moet dus eerst word in admin modes zien op te starten, dan moet hij een geinfecteerd bestand van een netwerk locatie zien te openen om daarna verder te kunnen. In hoevere is dat in de praktijk uit te voeren zonder dat de eigenaar van het systeem je doorheeft?

Als ik dit zo lees zit de exploit in Word/Office en niet zo zeer in Windows 10 zelf. Nu is Word toevallig ook van Microsoft zelf, maar dit zou net zo goed elk ander programma kunnen zijn...

Naast dat je word dus eerst ook nog als beheerder moet opstarten..

Van daaruit kan hij bijvoorbeeld antivirus en firewalls uitschakelen en het systeem kwetsbaar maken voor kwaadaardige software, inclusief ransomware, zo legt Hickey aan de site uit. Dit deed hij echter niet, naar eigen zeggen om het netwerk niet in gevaar te brengen. Het hele proces duurde drie uur en was volgens de onderzoeker 'makkelijker dan verwacht'.

Is dit niet juist het essentiële ding hier? Leuk dat je de rechten hebt, maar Windows 10 S gaat geen installatie van buiten de Store om toestaan, dus wat is het punt? Ransomware zal gewoon net dezelfde muur voor zijn neus krijgen als normale software die je van het internet download.

Ja, maar dan was het hem dus niet gelukt en was het hele clickbait artikel mute. Nu doet hij suggereren voor leken dat het wel onveilig is en dat ms's claim onzin is, wat dus nier zo is.

Is Windows S niet eerder een wanhoopspoging om google chrome af te stoppen?
Alles op dezelfde technologie - is dat ook niet onveilig - een lek en alles om zeep?

Weer iemand die zijn 15 minutes of fame weer/reclame inkomsten probeert te halen met een onzin 'onderzoek'. Wat hij doet is dus gewoon zelf al beheerdersrechten activeren voor Word, EN dan ook nog waarschuwingen negeren, tja, dan is er niet meer echt sprake van een ransomware exploit. Kom maar terig zodra je dit puur met een gebruikers account kunt doen. Nu is het gewoon een pure clickbait artikel...

De enige nieuwswaarde hiervan is, dat MS een soort hackers uitdaging heeft uitgeroepen. "Windows S is niet te kraken", en hier is bewijs dat het wel kan.

Maar dit is enkel mogelijk met fysieke toegang tot het systeem, tenzij je op andere wijze admin rechten weet te verkrijgen.

Iets als beheerder op starten vanuit de taak beheerder, lukt alleen via echte hardware input (keyboard/muis), of via signed drivers (zoals Teamviewer het doet).

Dit is geen echte exploit, het is al sinds jaar en dag op Windows mogelijk SYSTEM rechten te bemachten als je eenmaal admin rechten in je bezit hebt. Ik had wel verwacht dat het op Windows S wat lastiger zou zijn, maar het is geen verassing.