Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Microsoft dicht actief aangevallen kritiek lek in nieuwe patchronde

Microsoft heeft bij zijn maandelijkse patchronde, oftewel patch tuesday, in totaal 68 patches uitgebracht, waarvan 21 voor kritieke lekken. Een daarvan wordt actief gebruikt bij aanvallen, net als één minder ernstig lek.

Bij de aangevallen kwetsbaarheid, ook wel bekend als CVE-2018-8174, gaat het om een lek in de VBScript Engine in verschillende versies van Windows, waaronder Windows 10. Dat laat een aanvaller op afstand code uitvoeren met de rechten van de ingelogde gebruiker. Als die een beheerder is, bestaat de mogelijkheid om het systeem over te nemen, aldus Microsoft. Een aanvaller zou het lek kunnen misbruiken via een website of een Office-document met kwaadaardige VBScript-code.

Het tweede aangevallen lek, dat niet de aanduiding 'kritiek' heeft gekregen en dat het kenmerk CVE-2018-8120 draagt, laat een aanvaller volgens Microsoft hogere rechten op een systeem verkrijgen, waarna hij het kan overnemen. Dit is echter alleen van belang voor Windows 7-systemen en verschillende versies van Windows Server 2008. Veel van de overige door Microsoft aangepakte kritieke lekken hebben te maken met scripting engines in Microsofts browsers. Er zijn verschillende overzichten te vinden, bijvoorbeeld van Talos of Trend Micro.

Onder de gedichte kwetsbaarheden is ook CVE-2018-8897, dat door de ontdekkers in een technische analyse is omschreven. Een Cert-waarschuwing stelt dat het lek te maken heeft met 'de interpretatie door ontwikkelaars van bestaande documentatie van bepaalde interrupt- of exceptie-instructies van de Intel-architectuur'. Een aanvaller zou aan de hand van het lek gevoelige data in het geheugen kunnen uitlezen, aldus de waarschuwing. Niet alleen Microsoft zou door het lek zijn getroffen, maar ook Apple en verschillende Linux-distributies.

Er zijn al verschillende patches beschikbaar, waaronder voor macOS en de Linux-kernel, zo merkt The Register op. De site schrijft dat het erop lijkt dat het lek niet door een fout van Intel is ontstaan, maar dat het te wijten zou zijn aan kernelontwikkelaars. Intel heeft wel een geüpdatete versie van zijn handleiding voor ontwikkelaars gepubliceerd met verduidelijkingen.

Door

[HQ] Nieuwsredacteur

35 Linkedin Google+

Reacties (35)

Wijzig sortering
Als ze dit nou eens dichten, want dat is volgens mij nog steeds niet gebeurd. Dat is ook best een spannend foutje ...
Die ‘aanval’ werkt alleen als je toch al SYSTEM-rechten hebt op het betreffende systeem dus waarom vind je dat zo’n spannend foutje?
Voor iedereen die scenario's niet snapt. DE onderstaande scenario's zijn fictief, gebeuren niet bij mij, maar wel bij een heleboel mensen! Als je denkt dat dat niet zo is, dan leef je in een nagenoeg perfecte wereld, maar geen realistische helaas.

Scenario:

Ik als domain admin disconnect mijn sessie. Iemand met enkel local admin rechten op de term. server kan mijn sessie vinden en overnemen, en kan vervolgens alles.

Ja, het is intern, maar nee, dat betekend niet dat dit dan geen boeiende fout is. Dat dit mogelijk is is niet best. Als je hiervan de risico's niet van inziet heb je of 1) je rechtenstructuur niet op orde, want dan kan iedereen al alles of het maakt je niet uit?! 2) een erg nalatige interpretatie van security. (naar mijn mening)


Scenario 2:

Een externe partij kan als local admin software installeren, maar met dit truucje dus ook mijn domain admin sessie overnemen.

Zo zijn er nog wel wat scenario's te bedenken.

[Reactie gewijzigd door Qlusivenl op 9 mei 2018 13:25]

Het is goed dat je zo nadenkt over security maar de scenario's die jij omschrijft zijn inherent aan Windows en hebben niks met het RDP-'lek' te maken wat je noemde.

Domain administrators zouden nooit moeten inloggen op systemen behalve de domain controllers. Wanneer zij dit toch doen, kunnen alle local administrators van dat systeem inderdaad domain administrative privileges krijgen. Hiervoor kunnen zij een reeks aan inherente security risico's misbruiken, waaronder enkele voorbeelden: LSASS.exe dumpen, Mimikatz reflectief in memory laden, process injection van een process dat gespawnt is als de domain adminsitrator (wat dus sowieso het geval is bij jouw scenario's aangezien er op dat moment een domain administrator is ingelogd), en inderdaad de RDP-mogelijkheid die jij noemde.

Het beste wat je kan doen om jouw scenario's te mitigeren is te zorgen dat domain administrators hun DA accounts alleen gebruiken voor de domain controllers, en een ander account met minder rechten voor de andere systemen. Zodra domain administrators inloggen op andere systemen kun je er van uit gaan dat andere mensen ook domain administrator rechten hebben of kunnen krijgen. Bron: ben al enkele jaren een penetratietester en dit komen we echt bij heel veel organisaties tegen
Volgens mij zou je al niet moeten disconnected maar uitloggen. Probleem begint in beide gevallen bij het niet uitloggen.
Dat klopt, maar dat betekend niet dat t altijd gebeurd. Kwestie van opvoeding :)
Of een internetverbinding die wegvalt tijdens remote werk ;)
Kwestie van afdwingen met policies dat uiterlijk 1 uur 'disconnected' zijn, de sessie gewoon uitlogt.
Breek me de bek niet open zeg. Mailtje 10 milljoen en 1 met een lijstje wie er op server X zit ingelogd met een disconnected session en hoe lang ze al disconnected zijn. Record dat ik gezien heb was 11 weken van notabene dé admin van de organisatie.

De gemiddelde sessie was c.a. 200mb. (specifieke tools enz)
Maar 10x200Mb is wel 2gb geheugen. Ik vraag me af of windows zo slim is dat ze dat in virtual mem dumpen. Ik betwijfel het.

Anyway: Log uit beste mensen, laat die sessies niet week in week uit open staan.
Volgens mij dichten deze updates deze lekken niet. Bovenstaande scenario's zijn altijd al mogelijk geweest als een domain admin niet uitlogt maar alleen disconnect.
En een een local admin kan een domain admin nooit 'disconnecten' ? Als dat wel kan, dan is zodra de domain admin ooit inlogt deze aanval mogelijk.
Stroomuitval... zie delen Schiphol en AMC laatst.
'Ik disconnect mijn sessie' en ik moest eigenlijk al niet meer verder lezen.

Hoewel ik er zelf ook af en toe aan zondig is het gewoon not done om je sessie te gaan disconnecten ipv af te loggen.
Ik kan geen enkele reden bedenken waarom een sessie (met admin privileges dan nog) zou moeten blijven openstaan.

En uiteraard zijn er bepaalde (oude) toepassingen die dit nodig hebben om te kunnen blijven draaien, maar dan is de toepassing gewoon slecht gemaakt. Dan dien je dat probleem op te lossen en niet op de bank te staan roepen dat Microsoft haast moet maken om een lek te dichten.

Wat uiteraard niet wil zeggen dat het lek zomaar mag blijven openstaan, maar toch ...
Man man man, het is een scenario. Ik zeg niet dat ik dat doe, maar het gebeurd wel. Als je denkt dat dat niet zo is, dan heb je geen realistisch beeld van het bedrijfsleven..
Wat uiteraard niet wil zeggen dat het lek zomaar mag blijven openstaan, maar toch ...
inderdaad :)

[Reactie gewijzigd door Qlusivenl op 9 mei 2018 13:26]

In het MKB/KMO zal een zeer hoog percentage van de servers wel een disconnected domain admin sessie hebben.
Zoals je het schetst is het echter ook best eenvoudig 'op te lossen': log gewoon uit, in plaats van alleen te disconnecten... Zeker met een account met zoveel rechten.

Het is niet netjes dat deze fout in het systeem zit, maar deze scenario's voor misbruik klinken tegelijkertijd ook als nalatigheid.
Zoals gezegd helpt dat weinig: local admin kan gewoon een achtergrondproces starten die zijn werk doet zodra een domain admin inlogt.
Er is wel een RDP lek gedicht. Bij ons kregen wij allemaal een foutmelding toen wij met onze cloud dienst wilden verbinden. Update staat bekend als "CVE-2018-0886" Na een aanpassing in de group-policy(Encription Oracle Remediation op vulnerable zettten) kunnen wij iedergeval tijdelijk weer verbinden met onze cloud omgeving en de beheerder daarvan gelijk even ingelicht.
Het zal waarschijnlijk om deze update gaan :
https://support.microsoft...ndows-10-update-kb4103721

Wat verdere info over wat er allemaal in zit :
https://portal.msrc.micro...26-e811-a968-000d3a33a34d
Het welbekende "USB virus" is toch ook een .vbs script dat uitgevoerd wordt en zich daarna via de geinfecteerde PC en USB door verspreiden naar andere slachtoffer PC's en USB apparaten..
Betreft het ook een oplossing hiervoor?

Alle bestanden en folders op een USB worden verborgen en er worden neppe shortcut's gemaakt van de bestanden. Zodra je deze opent installeer je het virus op je computer. Ik kom dit vaak tegen bij studenten en schoolpersoneel.

Als je bewerken klikt op het script zie je een verwijzing naar de webcam.

[Reactie gewijzigd door Balder© op 9 mei 2018 11:26]

De 8 mei update lost verder ook het probleem op dat bijv. Chrome of Cortana de scherm driver vast laten lopen (Windows 10 1803), en een ontbrekende fix voor de Meltdown patch (Windows 10 1709) is nu gepatched.

[Reactie gewijzigd door Henk Poley op 9 mei 2018 12:20]

Scripts.... Daarom gebruik ik altijd de Chrome extension ScriptSafe. Ook NoScript zou je kunnen gebruiken en er zullen vast wel meer van dat soort extensions/add-ons zijn.

Helaas werken dit soort add-ons niet echt gebruiksvriendelijk, want voor iedere site moet ik aangeven welke onderdelen wel of niet uitgevoerd mogen worden, dus is het niet echt een optie voor de niet-computermindedTweaker.
Er zijn veel scripttalen, en script engines, en dit ging specifiek over VBScripts. Knappe jongen die dat in een webbrowser uitvoert -- dit zijn echt VBS files. Een techniek, hoewel her en der nog wel wát in gebruik, toch echt wel voorbij is...
VBscript kan gewoon uitgevoerd worden vanaf een website in Internet Explorer hoor ;)

In IE11 staat het standaard uit in de normale Standards rendering mode. Maar met een simpele header op de webserver (of een tag in de HTML code) kan je IE forceren om in IE compatibility mode de webpagina uit te voeren en dan werkt je VBscript gewoon.

[Reactie gewijzigd door GoBieN-Be op 9 mei 2018 14:22]

(gelukkig) niet meer by default, tevens is Internet Explorer zelf by default wat verborgen. Gelukkig.
Nou, CEBKAC dus (Cause Exists ...) :+
Toevoeging: de bekende 'open cd speler' script die je op het internet kan vinden is gemaakt in VBScript.
f the instruction following the MOV to SS or POP to SS instruction is an instruction like SYSCALL, SYSENTER, INT 3, etc. that transfers control to the operating system at Current Privilege Level (CPL) < 3, a debug exception is delivered after the transfer to CPL < 3 is complete. Such deferred #DB exceptions by MOV SS and POP SS may result in unexpected behavior.

Therefore, in certain circumstances after the use of certain Intel x86-64 architecture instructions, a debug exception pointing to data in a lower ring (for most operating systems, the kernel Ring 0 level) is made available to operating system components running in Ring 3. This may allow an attacker to utilize operating system APIs to gain access to sensitive memory information or control low-level operating system functions.
Ook al point debug data nog naar bepaalde plekken in het geheugen, waarom laat het OS toe om dit te accessen?
Afgelopen middag kreeg ik de melding kritieke fout en dat mijn machine binnen 1 minuut opnieuw werd opgestart. Toen begon de machine met updates uit te voeren en na een half uur was hij weer bruikbaar, zou dit hiermee te maken hebben gehad?
Johoor is heb gelezen dat computers met een core I7 1e 2e 3e gen nog maar op halve snelheid werken. De rest word opgevreten door de beveiliging pats van microsoft.

Ik vraag mij af of het medicijn niet erger is dan de kwaal.

Ik vind het überhaupt schandalig dat er processors op de markt komen die kwetsbaar zijn voor kwaadaardige software.

Het lijkt er op dat Microsoft deze pats preventief gaat installeren. Ik hoop dat ik deze pats dan ook weer kan verwijderen. Ik zit niet te wachten op slak trage computers dan neem ik het risico wel.

Zo zie je maar dat computers met een Intel processor weggooi computers zijn.

[Reactie gewijzigd door LEX63 op 10 mei 2018 06:01]

Ik heb er verder geen verstand van, maar.... sinds Windows 1803 (1 a 2 weken) heb ik al een keer of 4 een Blue screen gehad. Iets met WHEA.

Kwam eerder nooit voor.
Een tikkeltje off-topic; Maar dat is de WHEA UNCORRECTABLE ERROR. Deze heeft te maken met het energy management van je CPU.

Ik heb zelf sinds de update dat de laptop keihard uit gaat (niet afsluiten, gewoon uit & geen error logs) wanneer het batterijniveau 20% bereikt heeft en de energy saving aan zou moeten gaan. Het lijkt dat 1803 nog wat serieuze bugs heeft in het energy management.

Tip : Zet de functie om stroom te besparen als de batterij een bepaald niveau heeft UIT.
(Batterij icoon in de taakbalk > Batterij instellingen)
Je reactie is wel echt off-topic hier. Post je probleem anders even in de juiste categorie op het forum. Wie weet kunnen we je helpen. Sorry reactie van 360 had ik nog niet gezien toen ik deze reactie typte.

[Reactie gewijzigd door Nelis19821 op 9 mei 2018 12:05]


Om te kunnen reageren moet je ingelogd zijn


Call of Duty: Black Ops 4 HTC U12+ LG W7 Samsung Galaxy S9 Dual Sim OnePlus 6 Battlefield 5 Microsoft Xbox One X Apple iPhone 8

Tweakers vormt samen met Tweakers Elect, Hardware.Info, Autotrack, Nationale Vacaturebank en Intermediair de Persgroep Online Services B.V. © 1998 - 2018 Hosting door True

*