Microsoft: Chinese hackers stalen signingkey via crashdump en gehackt account

Staatshackers die door experts aan China worden gelieerd, hebben eerder dit jaar de signingkey van Microsoft-software weten te achterhalen uit een crashdump die via het gehackte account van een werknemer benaderbaar was.

Microsoft schrijft dat in een blogpost naar aanleiding van een hack die eerder dit jaar plaatsvond. Hackers die Microsoft aanduidt als de groep Storm-0558 drongen toen binnen bij de e-mailaccounts van verschillende bedrijven en West-Europese en Noord-Amerikaanse overheidsinstellingen waaronder het Amerikaanse ministerie van Binnenlandse Zaken. Microsoft heeft het onderzoek naar die hack nu afgerond.

De aanval begon al in april 2021. Toen vond er een crash plaats in een signingsysteem van een klant, waaruit een zogenoemde crashdump kwam rollen. Dat is een snapshot van wat er precies fout ging. Microsoft concludeert nu dat er een signingkey in die crashdump stond waarmee het mogelijk was om bepaalde systemen of systeemonderdelen te ondertekenen en waarmee de hackers zich als legitiem voor konden doen. Microsoft erkent dat die key niet in de crashdump had moeten staan en heeft dat probleem inmiddels gerepareerd.

De crashdump met daarin de sleutel stond aanvankelijk in een afgesloten omgeving, maar werd uiteindelijk verplaatst naar een debuggingomgeving die via internet bereikbaar was. De hackers wisten 'later' het account van een Microsoft-werknemer te hacken en zo toegang te krijgen tot die debuggingomgeving. Microsoft blijft daar wel vaag over; het bedrijf vertelt bijvoorbeeld niet wanneer dat account bijvoorbeeld werd gehackt en hoe dat gebeurde. Het is dus niet duidelijk hoe lang de hackers in de systemen van Microsoft zaten. Het bedrijf noemt specifiek dat het scannen op keys in crashdumps niet gebeurde, maar niet hoe het kon dat de aanvallers zo lang onopgemerkt bleven. Ook zegt Microsoft dat het geen concreet bewijs heeft dat de aanvaller via het ene account aan de crashdump kwam, omdat Microsoft door zijn eigen logretentiebeleid die logs niet meer heeft. "Maar dit was de meest waarschijnlijke manier waarop de aanvaller de sleutel wist te bemachtigen", schrijft het bedrijf.

Microsoft heeft naar aanleiding van het incident verschillende andere wijzigingen doorgevoerd. Zo scant het bedrijf voortaan meer op credentials en heeft het bepaalde library's bijgewerkt zodat die automatisch cryptografische sleutels valideren. In juli maakte het bedrijf cloudlogging ook al gratis voor zakelijke gebruikers van Exchange en Microsoft 365.

Reacties (59)

[CH4OS]

De crashdump met daarin de sleutel stond aanvankelijk in een afgesloten omgeving, maar werd uiteindelijk verplaatst naar een debuggingomgeving die via internet bereikbaar was.

Waarom zou je een debugging omgeving benaderbaar willen hebben via het internet? Zoals ik dit interpreteer zou dat betekenen dat het open en bloot naar het internet toe open stond. Ik kan me niet voorstellen dat MS een dergelijke blunder maakt.

EDIT @ 13:19: Citaat toegevoegd.

[Reactie gewijzigd door CH4OS op 22 juli 2024 14:21]

[PolarBear]

https://msrc.microsoft.co...orm-0558-key-acquisition/

After April 2021, when the key was leaked to the corporate environment in the crash dump, the Storm-0558 actor was able to successfully compromise a Microsoft engineer’s corporate account. This account had access to the debugging environment containing the crash dump which incorrectly contained the key. Due to log retention policies, we don’t have logs with specific evidence of this exfiltration by this actor, but this was the most probable mechanism by which the actor acquired the key.

Niets open en bloot naar het internet open.

[EnigmA-X]

Letterlijk twee regels boven de tekst van jouw quote:

We found that this crash dump, believed at the time not to contain key material, was subsequently moved from the isolated production network into our debugging environment on the internet connected corporate network.

[PolarBear]

Internet connected is iets anders dan vrij via internet beschikbaar. Dat je kan browsen en e-mailen vanaf het corporate netwerk is natuurlijk niet hetzelfde als open en bloot naar het internet open. Zonder de stap van het account van de Microsoftmedewerker waren ze er niet bij gekomen. En eigenlijk hadden de credentials/keys in de dump gefilterd moeten worden voordat ze beschikbaar waren vanaf het corporate netwerk.

[EnigmA-X]

Ja, je hebt helemaal gelijk. Zo beschrijf ik het ook een paar berichten hierboven (al voor jouw reactie).

Zoals ik jouw commentaar las: niets open en bloot naar het internet open (vanuit het corporate network). Met de nadruk op "naar internet".

Zoals ik @CH4OS zijn commentaar las: open en bloot vanaf het internet open.

Details

[djwice]

Omdat er Covid was en mensen vanaf remote ergens bij moesten kunnen?
En typisch heeft een non-prod geen gevoelige productie data... toch?

In de praktijk zijn er ook mensen die boos worden als ze hun Windows server/Applicatie niet met productie data mogen testen voordat ze de machine overzetten naar een prod environnement.

In de praktijk zijn er nog veel mensen die geen representatieve test data kunnen maken zonder simpelweg een op een data, met hooguit wat maskering of pseudoniemisering, van productie te slepen. Sterker nog die maskering gebeurt vaak pas als de data in non-prod aan komt, als die al gebeurd.

[Reactie gewijzigd door djwice op 23 juli 2024 01:12]

[CH4OS]

Omdat er Covid was en mensen vanaf remote ergens bij moesten kunnen?
En typisch heeft een non-prod geen gevoelige productie data... toch?

Ik zie niet waarom COVID (nog altijd?) het toverwoord moe(s)t zijn om iets via internet beschikbaar te hebben. Fijn dat zaken opengesteld worden voor de thuiswerkende medewerkers (COVID of niet!), maar ik mag toch wel hopen dat die toegang dan wel veilig achter minstens een VPN-verbinding zit.

In de praktijk zijn er ook mensen die boos worden als ze hun Windows server/Applicatie niet met productie data mogen testen voordat ze de machine overzetten naar een prod environnement.

Het heeft niet helemaal met mijn opmerking te maken, maar ook dit is op zich niet eens zo'n hele rare gedachte. In klantdata staat ook data waar de interne tests niet aan gedacht hebben, dus kan dat dergelijke data op zich nog wel interessante tests (en daarbij behorende resutaten) kunnen opleveren.

Maar nogmaals, dat is helemaal het punt niet dat ik maken wil.

[djwice]

Wat maakt het uit welke versleutelde verbinding gebruikt wordt? VPN of TLS?
Beide moeten de communicatie goed versleutelen en beide horen gecombineerd te worden met een goede toegangsbeveiling tot het systeem.

[CH4OS]

Omdat je middels een VPN zaken kan uitsluiten en TLS alléén de data over de lijn versleuteld. Dat iets met TLS is versleuteld, betekend niet dat het opeens goed beveiligd is.

[EnigmA-X]

Dat iets via internet benaderbaar is, betekent niet dat alles open en bloot publiek toegankelijk is.

Ook voor een VPN verbinding heb je uiteindelijk internet connectiviteit nodig (tenzij je het via HAM-radio doet ofzo)

Het is dus maar een beetje hoe je het leest. Het lijkt mij niet dat het hele "corporate network" van Microsoft (waar die debugging-omgeving draaide) publiek open en bloot toegankelijk is via internet.

Als je echter account credentials hebt losgerommeld en jezelf van de MFA hebt vrijgemaakt (die er hopelijk op zat), dan stelt toegangsbeveiliging voor een VPN-client vaak ook niet zoveel meer voor.

[Houtenklaas]

Ook voor een VPN verbinding heb je uiteindelijk internet connectiviteit

Nee hoor, dat is niet zo. Je kan keurig private xDSL aansluitingen huren die 100% losstaan van het internet. Dat heet ook "VPN", wordt nog veel gebruikt in de financiële sector. Tuurlijk, wat minder flexibel dan "internet", maar qua veiligheid onovertroffen. Stukje leesvoer.

Tikkie meer ontopic, dat Microsoft wat vaag doet over onderdelen van de hack doet wel vermoeden dat de benaderbaarheid wellicht niet de gewenste moeilijkheidsgraad had. Sleutels opslaan in een dump had natuurlijk nooit mogen gebeuren maar zijn typisch van die dingen die met testen over het hoofd worden gezien als mogelijkheid. Dan nog had je daarmee één sleutel in handen gehad, waar je in een goed doordacht systeem er nog veel meer had moeten hebben om binnen te komen.

[djwice]

Een bedrijf in de financiële sector, incl. bank, verzekeringen, pensioenen etc., met tienduizenden werknemers waar ik voor werkte gebruikte gewoon VPN via normaal internet voor alle medewerkers (incl. IT en directie) naar intern netwerk.

Maar ook gewoon TLS verbindingen met IP-whitelisting of een ZeroTrust voor communicatie met productie én non-productie systemen over internet. De meeste vereisten MFA.

Naar welke financiële bedrijven verwijs jij die private xDSL gebruiken?

[Reactie gewijzigd door djwice op 23 juli 2024 01:12]

[Gamebuster]

Ik doe tegenwoordig dit soort tests in een RAM-disk. Ik download de subset aan data naar mijn ramdisk, maak een postgresql tablespace op die ramdisk, laadt de dev-omgeving in op die ramdisk + de subset productie data, doe mijn tests, en verwijder de ramdisk.

Poef, alles weg

[Willem_54]

Als een Ramdisk op een SSD wordt opgeslagen, dan is het helaas niet “poef weg”, tenzij de SSD hardwarematig versleuteld was. Een Ramdisk in het interne geheugen is wel veilig genoeg mits je het systeem opnieuw opstart na het verwijderen van de Ramdisk.

[Gamebuster]

Als een Ramdisk op een SSD wordt opgeslagen, dan is het helaas niet “poef weg”

De RAM-disk is zo ongeveer per definitie niet op een SSD opgeslagen

tenzij de SSD hardwarematig versleuteld was

wat als ik softwarematige versleuteling heb?

[Reactie gewijzigd door Gamebuster op 23 juli 2024 01:12]

[supersnathan94]

Totdat je jouw PC in hibernate gooit om een dag later weer verder te kunnen.

Windows maakt by default een hyberfile.sys aan op de main ssd ter grootte van het geïnstalleerde werkgeheugen. Hie schrijft het dan alle data naar weg als je je PC “uitzet”.

Tegenwoordig is een shutdown een hybrid sleep waarin ram data dus wel degelijk naar disk wordt geschreven.

[MrMonkE]

Nou bij mij is de ramdisk weg bij een reboot en ook bij een shutdown.
Shutdown is UIT. Niet slapen.


Ik denk zelfs dat als ik uitlog en opnieuw inlog dat hij weg is.
Even testen.. brb, edit volgt. Nee dan blijft hij netjes bestaan

[Reactie gewijzigd door MrMonkE op 23 juli 2024 01:12]

[supersnathan94]

Shutdown is UIT. Niet slapen.

Niet als het aan MS ligt. Hybrid sleep is de default en in nieuwere builds van win11 kun je dat al niet eens meer zelf zomaar wijzigen. Dus ook je desktop doet lekker een hybrid sleep.

Een reboot cycled nog wel daadwerkelijk volledig.

Afhankelijk van je OS zullen er dus wel degelijk nog dingen aanwezig zijn.

Wat jij zegt over dattie weg is betekent dat de drive weg is, maar weet je heel zeker dat het niet nog op disk staat? Die hyberfile is er immers nog wel en daar heb je niet naar gekeken.

[MrMonkE]

Ah, ok. Zit in linux.

Maar als je zo gaat denken moet je gewoon hibernate uit zetten want die Hyberfile kan van alles in staan.
Maar hopelijk wordt er gebitlockered
Zelf gebruik ik nooit hibernate op desktop. Op windows niet en op linux niet.

[supersnathan94]

Dat is dus het ding. Hibernate uitzetten is dus niet zo eenvoudig en de vraag is voor hoelang dat nog kan. Microsoft zet enorm hard in op hybrid sleep, ondanks alle problemen die het met zich meebrengt van laptops die bijvoorbeeld aan gaan in tassen. Ding trekt zichzelf dan volledig leeg en wordt gigantisch heet.

Heeft te maken met het feit dat als je hem dichtklapt en er nog een powercable in zit hij blijft denken dat hij aan de stroom hangt en dan allerlei vaag gedrag mbt back ground polling van zaken gaat doen of updaten. Een desktop in hybrid sleep heeft by default nog power tenzij je die hard wegneemt (zo’n verlengsnoer met knop bijvoorbeeld) en dan kan ie ‘s nachts gaan updaten.

Dit zijn functies waar MS steeds meer op gaat leunen, dus even uitzetten zit er straks ws niet meer bij.

[Verwijderd]

Ik denk dat je onderschat hoe weinig mensen er gereed waren voor een 100% digitale remote werkplek. Inclusief MS.

[CAPSLOCK2000]

Waarom zou je een debugging omgeving benaderbaar willen hebben via het internet? Zoals ik dit interpreteer zou dat betekenen dat het open en bloot naar het internet toe open stond. Ik kan me niet voorstellen dat MS een dergelijke blunder maakt.

Het is inderdaad een behoorlijke blunder, toch ben ik er vrij mild over dit stuk van het probleem. Shit happens. Mensen maken fouten. Daar moet je rekening mee houden zodat je een enkele fout geen grote gevolgen heeft. Die dump had niet openlijk online moeten staan maar eigenlijk vind ik dat maar een kleine fout.
Een groter probleem is dat die key niet in de dump had moeten staan. Of om precies te zijn had de key niet in de RAM moeten staan. Het probleem zit niet bij de dump. Als die key niet in een dump mag dan mag ie ook niet in RAM. MS probeert te voorkomen dat dergelijk info in dumps terecht komt maar dat moet je als extra beveiliging tegen blunders zien, niet als oplossing voor het probleem. Die detectie heeft hier niet goed gewerkt maar ook dat zie ik als kleine fout. De intentie was goed, de implementatie minder. Shit happens.

In veel gevallen zou ik dat nog steeds als een kleine fout zien of een acceptabel risico vanuit het oogpunt van de developer. Hoewel dit probleem helemaal te voorkomen is door een HSM te gebruiken is dat helaas geen algemene kennis. Maar in dit geval zijn er verzwarende omstandigheden. We hebben het namelijk over een 'signingsysteem'. Nu wordt het een gevalletje "you had one job...". Van de ontwerper van een signingsysteem verwacht ik wel dat die weet wat een HSM is en hoe je daar mee om moet gaan. Dat is geen kleine menselijke vergissing meer maar een fundamenteel gebrek aan kennis van je vak.
Ik weet niet wie dat signingsysteem heeft ontwikkeld, MS of de klant/partner maar het is in ieder geval niet goed.

Er is echter nog een groot probleem dat nog niet genoeg aandacht heeft gehad. Namelijk dat deze aanval al 2 jaar bezig is en gebruik maakt van een certificaat dat a) teveel rechten heeft en b) niet gecontroleerd werd op juistheid. Gebruikers van het certificaat gingen er onterecht van uit dat het wel elders in het systeem gecontroleerd zou worden. Ik heb moeite om dat nog onder "kleine menselijke" fouten te schuiven want we komen nu weer op het terrein waar alleen specialisten zouden moeten werken. Als je bij de deur staat om kaartjes te controleren kun je niet zeggen dat je er van uit ging dat iemand anders het kaartje al gecontroleerd zou hebben. Zelfs als dat waar is dan blijft het jouw opdracht om het kaartje te controleren.

Wat mij betreft is dit veel groter nieuws dan het uitlekken van zo'n sleutel. Dat sleutels uitlekken is onvermijdelijk en het systeem (certificaten) is opgezet om daar rekening mee te houden. Dat er af en toe een sleutel lekt zou geen groot nieuws hoeven zijn. Het is nu wel een groot probleem geworden omdat de sleutel niet gecontroleerd werd.

Een ander punt wat meer aandacht zou moeten krijgen is dat het erg moeilijk blijkt om zo'n sleutel daadwerkelijk in te trekken. Zoals ik hierboven al aangaf is het systeem opgezet om rekening te houden met het verlies van sleutels. Die trek je dan in en je geeft een nieuwe uit en je vervangt alle sloten (de gesignede applicaties) en dan is het probleem weer opgelost, in theorie. In praktijk blijkt het vrijwel onmogelijk om de sloten te vervangen (de apps opnieuw te signen). De leverancier heeft geen zin om opnieuw geld/moeite/tijd wil investeren in zo'n oude applicatie. Als de leverancier uberhaupt nog gevonden kan worden en die de broncode en ontwikkelaars nog beschikbaar heeft. Als de leverancier niet meewerkt dan valt die software uit als de key wordt uitgeschakeld. De gebruiker gaan dan bij MS klagen dat MS hun software stuk heeft gemaakt. Ik snap ook wel dat MS geen zin heeft om daar de schuld van te krijgen.

Hoewel ik het allemaal kan begrijpen is de conclusie niet mals: het systeem werkt niet goed. Als puntje bij paaltje komt zijn wij (of MS) eigenlijk niet bereid om de stekker er uit te trekken want dat levert heel veel gezeik op.

Het zou veel verschil maken als we ons wat actiever zouden opstellen en zelf beslissen welke sleutels we op ons systeem hebben staan. Ik weet niet of het (praktisch gezien) mogelijk is om zelf deze sleutels selectief in te trekken. Ik neem aan dat die keys gewoon in de keystore staan en daar dus ook uitgehaald kunnen worden door de gebruiker, mits die weet welke sleutel waar voor gebruikt wordt.

Op Linux-servers ben ik gewend alle (CA) certificaten te verwijderen die ik niet nodig heb. Zeker in een besloten omgeving heb je er niet meer dan een handvol nodig. Dat is niks voor een consumentendesktop maar in een zakelijke (beheerde) omgeving zou het wel eens interessant kunnen zijn.

[sympa]

Op het forum van Heise vat iemand het (vrij vertaald) zo samen:

• De key is 4 jaar lang niet geroteerd
• De gelekte key werd door de enforcementendpointservers nog 2 jaar na de vervaldatum geaccepteerd.
• Microsoft gaat helemaal niet op bovenstaande punten in.

Ik vind het nogal wat. "You had one job..."

[kodak]

This is consistent with our standard debugging processes.

Blijkbaar vinden ze het acceptabel om debuggen van gegegevens van systemen uit een geïsoleerde omgeving in een standaad omgeving te doen omdat ze scannen/filteren op mogelijk zeer gevoelige gegevens.

Het klinkt mij als een afweging die vragen is om problemen. Isoleren is namelijk veel strengere scheiding. Het is gewoonlijk niet toegankelijk, tenzij. Het scannen lijkt sterk op toegang, tenzij. En zeker in crashdumps met toegang tot alle soorten vam gegevens die normaal beschermd zijn is het te verwachten dat het scannen gevoelige gegevens gaat missen. Als scanner heb je namelijk geen controle over hoe gegevens zich voor doen, hooguit hoe je ze op tikd hoopt te herkennen.

[SunnieNL]

Tja, elke RDP en Citrix omgeving staat ook open en bloot het internet op en wordt afgeschermd door credentials. In dit geval zal het wel een Azure VM zijn geweest. Die credentials hebben ze ook te pakken gekregen.
Je kunt ze hooguit verwijten dat er blijkbaar geen conditional access actief was, want die had een plotselinge inlog van een andere locatie opgemerkt en geblokkeerd door bv. te vragen naar MFA als extra beveiliging omdat er een anomalie is gedetecteerd.

[sympa]

Ik begrijp dat ze een key hebben laten lekken waarmee je als een willekeurige user kan inloggen. Dat kan iedereen overkomen. Maar deze key was veel langer geldig dan nodig. Heel veel langer. Dus eenmaal gelekt kon je er jarenlang mee aan de slag.
En om het nog erger te maken werd die geldigheidsduur ook nog eens niet gecontroleerd.

Kijk, als het het eigen webforum is dan is het niet zo erg. Maar als je de data van de hele wereld in je cloud wil hosten moet je dat goed beveiligen. En niet in zowel het ontwerp als in de uitvoering zulke fouten maken.

[Janbraam]

... Ik kan me niet voorstellen dat MS een dergelijke blunder maakt....

Een bedrijf bestaat uit mensen. Mensen maken fouten (en maar goed ook, als wij altijd alles goed deden zouden we niks leren). Dat betekent dat mensen al snel gezien worden als de zwakste schakel. Een (social) hacker kan daar handig gebruik van maken (zou ik ook doen als ik hacker was).

Daarnaast bestaan er natuurlijk ook nog programma's-met-foutjes, zoals KeePass:
nieuws: Kwetsbaarheid in wachtwoordmanager KeePass, oplossing volgt in juni
- https://www.bleepingcompu...password-fix-coming-soon/

Daarin wordt uitgelegd hoe via dmp-bestanden bepaalde handelingen (die dus helemaal niet zouden mogen) opeens mogelijk waren.

En, zal MS alleen maar eigen software gebruiken? Software die tot in den treure is getest?

[Bor]

Zoals ik dit interpreteer zou dat betekenen dat het open en bloot naar het internet toe open stond.

Je trekt wel een conclusie die je op basis van de beschikbare informatie niet kan trekken imho; "via internet bereikbaar was" zegt niet dat het zonder beveiliging of bijvoorbeeld authenticatie te bereiken is. Een toegang via VPN met bv MFA beschermd is nog steeds "via het internet te bereiken".

[CH4OS]

Dat snap ik en ik ga er stiekem ook wel vanuit dat er iets van VPN tussen zat (al dan niet met MFA), maar imo is er wel een verschil tussen 'via het internet' (wat toch meer duidt op openbaar) dan 'via de VPN omgeving van Microsoft'.

[GekkePrutser]

Zo'n signingkey hoort natuurlijk in een HSM (Hardware Security Module) te staan. Niet in het geheugen van een PC. Dat het dan in een crashdump terecht is gekomen is een gevolg daarvan. Vreemd dat dat hier niet het geval was. Zo'n HSM is precies bedoeld om dit soort zaken te voorkomen.

Maargoed ze geven zelf ook al aan dat dit niet de bedoeling is geweest.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 01:12]

[jeffreytigch]

Dat is niet helemaal zo: https://security.stackexc...ept-out-of-program-memory

HSMs hold the key and can perform tasks that use the key, for example generating signatures, without the key ever being known outside the HSM. An HSM is not a box you keep an encryption key in, to be loaded out when it is used - the key stays in the box, the HSM is designed to never egress the key.

However, if your threat model includes attackers that have physical access to RAM, you have no hope. Thats like asking if it is possible to keep thieves out of your house while allowing them into all the rooms.

[GekkePrutser]

Het gaat daar over de RAM van de HSM zelf. Dit is vaak een server maar dan heel goed beveiligd en met een crypto coprocessor natuurlijk.

Maar het is niet het geval dat je die normaal loopt te debuggen ofzo, een crashdump zal je daar ook niet zomaar uit halen. Hooguit gaat die encrypted naar de leverancier. Thales maakt die dingen bijvoorbeeld.

Zoals gezegd: Als de private key in een HSM zat dan komt hij daar niet uit, en voor de klant (Microsoft) is de HSM een "black box", dus daar kan je verder niet op inloggen buiten de gewone beheer interface.

Als het in een crashdump van een computer terecht is gekomen dan stond hij vrijwel zeker niet in een HSM. Tenzij die crashdump van de HSM zelf was maar dat is echt heel onwaarschijnlijk.

[Reactie gewijzigd door GekkePrutser op 23 juli 2024 01:12]

[jeffreytigch]

Hoe ik het intepreteerde, is dat het geheugen in de crash dump terecht kwam. Dan klinkt het logisch. In andere gevallen, denk ik dat er dan een serieuse misconfiguratie is geweest.

[CAPSLOCK2000]

De uitleg van Gekke Prutser is juist. Het heel doel van een HSM is voorkomen dat de sleutels in het RAM van de pc/server/gebruiker terecht komt. Sleutels verlaten de HSM nooit*. Er is geen enkele manier om daar bij te komen.

Het is nog steeds heel gebruikelijk om geen HSM te gebruiken maar de sleutels gewoon op je PC te zetten. De grote meerderheid werkt zo en velen hebben nog nooit van een HSM gehoord (ook al zit er tegenwoordig één in iedere PC). Het is aannemelijk dat het hier zo ging aangezien die key blijkbaar in een crashdump stond.

* het is niet 100% waar, er zijn HSMs met een backupmogelijkheid. Dat heeft voor en nadelen. Als je het puur speelt zijn er geen backups want die data kan de HSM niet verlaten. Daarnaast kun je in theorie met een electronenmicroscoop en heel veel geduld zo'n HSM atoom voor atoom uit elkaar puzzelen maar dat is niet realistisch.

[Pinkys Brain]

TPM is te beperkt en traag, ME/PSP zijn niet bruikbaar voor derden. Tot Pluton er is hebben we niet echt nuttige HSMs in PCs, beetje jammer aangezien het hoognodig is voor passkeys.

[sympa]

En je hebt niet de hoofdsleutel als key die je gebruikt voor het signen van software.
Wat ik begreep kon je met de gelekte key alles, elke cloud-AD in, elke usersessie van welke klant op 365 ook vervalsen, etc.
En ... lekker onder de pet houden.

[Reactie gewijzigd door sympa op 23 juli 2024 01:12]

[Luchtbakker]

Voor mensen die graag meer details hierover willen:

https://www.microsoft.com...nauthorized-email-access/

[Verwijderd]

Dus het bewijs dat het China is komt door dezelfde werktijden? Verder wel toevallig dat die crashdump net heel belangrijke data bevat die er normaal niet in had/zou moeten zitten. Hoeveel dumps waren er nog meer op dat systeem?

[shadow1967]

Crash en memory dumps zijn nog steeds populaire informatiebronnen. Dev teams zullen het nooit leren om een verschil te maken tss normale dumps voor operationeel gebruik en onderzoek dumps. De risico's om teveel info te dumpen is nog steeds zwaar onderschat.

[AibohphobiA BoB]

Storm-0558
Dus lees- en uitvoerrechten voor de groep en de rest, maar niet de eigenaar.
Of heeft het een andere betekenis?

[Room42]

Hackers die Microsoft aanduidt als de groep Storm-0558

Het is de naam die Microsoft de hackers gegeven heeft.

[AibohphobiA BoB]

Ja dat staat er. Maar wat is het?

[wildhagen]

Ja dat staat er. Maar wat is het?

Gewoon een codenaam-systeem die Microsoft hanteert:

Microsoft categorizes threat actors into five key groups: nation-state hackers, financially motivated groups (Tempest), private sector offensive actors (Tsunami), influence operations (Flood), and groups in development (Storm).

If a threat is new or from an unknown source, then Microsoft will assign it a temporary “Storm” designation and a four-digit number instead of the previous “DEV” moniker Microsoft used to use.

Zie https://www.cybersecurity-help.cz/blog/3241.html

De 0558 is gewoon een volgnummer.

Er zit dus geen concrete verwijzing naar wat dan ook in, en er valt uit de naam verder ook niets uit af te leiden. Puur een codenaam+volgnummer, niet meer, niet minder.

[Reactie gewijzigd door wildhagen op 23 juli 2024 01:12]

[kodak]

Het is wel degelijk iets meer. Ze kiezen waarschijnlijk alleen een nieuwe naam als ze niet naar een bestaande eerdere keuze kunnen verwijzen. Dus of het is op zijn minst een criminele groep die ze niet herkennen, of het is een nieuwe groep.

[wildhagen]

Ze kiezen waarschijnlijk alleen een nieuwe naam als ze niet naar een bestaande eerdere keuze kunnen verwijzen.

Nee, dat is niet helemaal juist, of iig onvolledig.

Het komt ook regelmatig voor dat ze de groep oorspronkelijk niet herkennen, waardoor hij een Storm-XXXX entry krijgt, maar dat hij later alsnog wordt herkend als horende bij een reeds bekende groep, (bijvoorbeeld Tempest-1234). Dan wordt de Storm-code opgeheven en de aanval alsnog gekoppeld aan (in dit voorbeeld) Tempest-1234.

Daarom is Storm-XXXX ook geen aaneengesloten groep. Dat de groep uit dit artikel nu Storm-0558 heet, wil niet zeggen dat dit ook echt de 558e groep is die ze ontdekken. Veel tussenliggende nummers zullen inmiddels vervallen zijn door bovenstaande.

En de originele vraag was:

Storm-0558
Dus lees- en uitvoerrechten voor de groep en de rest, maar niet de eigenaar.

Dat soort zaken kan je NOOIT uit deze codenamen afleiden. Zo'n betekenis zit er helemaal niet in.

[Reactie gewijzigd door wildhagen op 23 juli 2024 01:12]

[kodak]

Dat het later kan veranderen sluit ik met mijn opmerking toch niet uit? Als het later wel ergens bij zou horen is dat een aanvulling of verandering op de oorspronkelijke keuze. Maar de vraag ging om de huidige situatie.

[AibohphobiA BoB]

En de originele vraag was:

[...]

Dat soort zaken kan je NOOIT uit deze codenamen afleiden. Zo'n betekenis zit er helemaal niet in.

Nee, dat was een grappig bedoelde conclusie. Een vraag kun je herkennen aan dat grappige kringeltje aan het einde van een zin, het 'vraagteken'.

[scsirob]

Als je op Unix/Linux rechten doelt, dat zal het niet zijn. Die zijn octaal en een 8 past daar niet in

[AibohphobiA BoB]

Ik geef meteen toe dat de grap niet helemaal sluitend was. 😊

[Dooxed]

Dank voor de grap, ik vond hem leuk

[CH4OS]

Ik denk dat het een andere betekenis is, het zou anders namelijk 0557 moeten zijn. Overigens is bij de vier-cijferige notatie het eerste getal voor root, het tweede voor user, de derde voor de group (waar de user in zit) en de vierde voor other.

Waarbij execute 1 is, write is 2 en read is 4. Heb je dus al deze rechten, kom je dan op 7 uit.

[Reactie gewijzigd door CH4OS op 23 juli 2024 01:12]

[DeFeCt]

Ik maak uit de tekst niet op dat het om Staatshackers zou gaan?

[wildhagen]

Microsoft zelf heeft het over:

Microsoft has mitigated an attack by a China-based threat actor Microsoft tracks as Storm-0558 which targeted customer emails.

In hun originele blog-post van 11 juli, waarin deze groep voor het eerst benoemd wordt.

"China-based" dus, zonder verder een uitspraak te doen over wie daar verder achter zit/zou zitten. De Tweakers-redactie heeft wellicht meer informatie van Microsoft ontvangen, dat ze nu dus weten dat het ook echt staatshackers zijn neem ik aan? Ze zullen dit vast niet zomaar posten lijkt me.

[D11]

Lijkt erop dat de debug omgeving niet met MFA beschermd was dan.

[lolsra]

Mogelijk compromitteerd dmv een valide session cookie. Dan geen MFA nodig.

[daily.data.inj]

Vreemd, had verwacht dat een verbetering op key rotation ook 1 van de uitkomsten zou zijn van het technisch onderzoek door Microsoft. Als er een signing key in april 2021 gelekt is, die in july 2023 nog valide is lijkt mij dat sowieso een verbetering. Hoe korter deze signings keys geldig zijn hoe beter, uiteraard rekening houdend met werkbare /operationele situaties. Wellicht zou er dan geen blast radius zijn ondanks de gebrekkige key scope validation (zoals beschreven in de blogpost van Microsoft).

[Reactie gewijzigd door daily.data.inj op 23 juli 2024 01:12]

[Qws]

En weer is Microsoft gehacked.

Het gebeurd echt bizar vaak vergeleken met Google en Apple.