Kritiek op Github om verwijdering exploitcode Exchange-kwetsbaarheden

Github ligt onder vuur omdat het bedrijf exploitcode voor kwetsbaarheden in Microsoft Exchange-servers offline heeft gehaald. De code werd gepubliceerd nadat Microsoft een patch uitbracht voor de kwetsbaarheden, maar werd alsnog offline gehaald tot ergernis van gebruikers.

De code werd online gezet door onafhankelijk beveiligingsonderzoeker Nguyen Jang. Met deze code kunnen, met wat kleine aanpassingen, Exchange-servers zonder patch worden gehackt. Github haalde de code binnen een paar uur offline na de publicatie volgens Jang.

Dit ligt gevoelig omdat Microsoft eigenaar is van Github. Verschillende gebruikers lieten zich kritisch uit over de actie van Github. Bijvoorbeeld beveiligingsexpert Dave Kennedy. Hij dreigt in een bericht op Twitter om zijn code weg te halen bij Github, omdat hij de actie van het bedrijf belachelijk vindt.

Een woordvoerder van Github bevestigde in een verklaring tegenover Motherboard dat de code offline is gehaald door het bedrijf. De woordvoerder gaf aan dat "hoewel ze begrijpen dat de publicatie en distributie van een proof-of-concept van een exploit van educatieve en wetenschappelijke waarde is, dit in balans moet zijn met de veiligheid van het hele ecosysteem". In dit geval zou de code van Jang een bedreiging zijn voor de servers die nog niet de nieuwe patch hebben geïnstalleerd.

De kwetsbaarheden in Microsoft Exchange-servers werden begin dit jaar ontdekt. Toen bleek dat de kwetsbaarheden actief werden misbruikt door Chinese hackers. Naar schatting zijn er honderdduizenden servers getroffen. Het gaat om vier zeroday-kwetsbaarheden die in de versies 2013, 2016 en 2019 zaten van Exchange Server. De kwetsbaarheden werden op 2 maart gedicht door Microsoft.

Reacties (109)

[eltweako]

Het is inmiddels al onder elk artikel gepost, dus zal ik het hier volledigheidshalve ook maar even posten:

Het betreft de volgende CVE nummers:
CVE-2021-26855
CVE-2021-26857
CVE-2021-26858
CVE-2021-27065

De patch betreft KB5000871 en is hier te vinden voor Exchange server 2013,2016 en 2019:
https://support.microsoft...21-4ee7-b9da-fa85b3e1d23b

Dit is een script van Microsoft om te controleren of het lek misbruikt is op je exchange server:
https://github.com/microsoft/CSS-Exchange/tree/main/Security

Als je niet in staat bent om te patchen, dan is hier een lijst met mitigations:
https://msrc-blog.microso...s-mitigations-march-2021/

Het mag voor zich spreken dat je zo snel mogelijk je servers moet beschermen mocht je dat nog niet gedaan hebben.
Als je besmet bent wordt in de meeste gevallen een backdoor in de IIS geïnstalleerd. Dit betekent dat de meeste backdoors via poort 443 bereikbaar zijn. Mocht je dus vermoeden dat er iets mis is, je exchange server nog niet gepatcht hebben of je vertrouwt de boel gewoonweg niet dan zou het blokkeren van poort 443 vanaf internet naar je exchange server in de firewall zou in principe bescherming moeten bieden tegen de exploit en backdoor.

[Reactie gewijzigd door eltweako op 22 juli 2024 23:01]

[SkiFan]

Ja, alleen is dat een beetje onhandig, want heel veel verkeer naar je Exchange gaat over 443. Dingen als de client, webclient, al dat soort zaken lopen over 443. 443 Dicht gooien is zoiets als de motor uit je auto halen.

[eltweako]

Zeker, bijzonder onhandig. En zeker geen oplossing voor het probleem.

Maar als het door omstandigheden (tijdelijk) niet mogelijk is om te patchen is het blokkeren van poort 443 een mogelijkheid om je exchange werkend te houden. Alleen moeten je gebruikers nu eerst de VPN opstarten of verbinding maken met de remote werkplek om toegang te krijgen tot de mail.
Inkomende en uitgaande mail blijft gewoon werken.

De motor ligt nog steeds in je auto, alleen moet je nu via de kofferbak instappen.

[Reactie gewijzigd door eltweako op 22 juli 2024 23:01]

[SkiFan]

Nee, Exchange gebruikt nog steeds 443 voor je client verbindingen. Je kunt het pas voorkomen als je het op de firewall dichtgooit.

[eltweako]

Correct, je gooit het niet dicht op je exchange server zelf, maar op de firewall tussen het internet en je server.
Ik heb mijn bericht even aangepast zodat het duidelijker is wat ik bedoel.

[SkiFan]

Ah, heb je wel ruzie met iedereen die een smartphone heeft :-) Ik zie mijn gebruikers niet eerst een VPN op hun smartphone opstarten om mail te lezen. Enige optie zou dan een reverse proxy zijn en de EWS open te laten, maar goed. De mijne was op tijd gepatched. Geen lek.

[eltweako]

Niemand had zijn server op tijd gepatcht dat je geen lek had is puur mazzel hebben.
Het lek wordt al sinds 3 januari dit jaar actief misbruikt.
https://krebsonsecurity.c...f-the-exchange-mass-hack/

Natuurlijk, als je niet patched is het een kwestie van tijd totdat je gehacked wordt. Maar feit is dat we allemaal te laat waren. De patch kwam relatief laat, maar dat kost nu eenmaal tijd.
Enige wat Microsoft echt te verwijten valt is dat ze niet eerder met een waarschuwing en mitigaties gekomen zijn.

[Reactie gewijzigd door eltweako op 22 juli 2024 23:01]

[tonkie_67]

Ja ze waren allemaal te laat maar tussen 3 jan 21 en release van patch waren er slecht 1 of enkele gebruikers vd kwetsbaarheid die waarschijnlijk een bepaalde (nog steeds grote) doelgroep(en) had.
Sinds patch en bekendmaking waren aantal mogelijke gebruikers vd hack veel groter: zeker als je de PoC code kan copy/pasten van github.

[johnkeates]

Je doet alsof het erg is dat je gebruikers er last van hebben dat je archaïsche on-prem exchange even dicht moet om dat ie anders gehackt wordt en dan sowieso door de stoute hackers kapot gemaakt wordt en dan alsnog niet werkt.

In dit geval is het niet een 'vervelende maatregel' maar een 'als je het zelf niet doet doet iemand met kwade bedoelingen het wel'-situatie.

[FreshMaker]

Jup, wij hadden een aantal dagen 'ongemak' omdat dit zo gedaan was.
Maar met uitleg, en wat voorlichting was iedereen tevreden.

na we de rest van de week getest en wat extra security monitoring toegepast waren er geen dreigingen te zien, en konden we voorzichtig de boel weer open gooien.
Op basis van tredes in toegang krijgt nu iedereen weer mondjesmaat toegang ( eerst rudimentair op IPadres in Nederland, steeds verder uitbouwend naar meer mogelijkheden )

Lastig, ja ... noodzakelijk - zeker

[Alex3]

Bij ons hebben we nog steeds VPN nodig voor Outlook en webmail. Die hadden we toch al om vanaf thuis bij de netwerkschijven te komen. Op m'n telefoon gebruik ik imap. Dat kan zonder VPN.

[SkiFan]

Bij ons niet, en Outlook anywhere vinden gebruikers erg handig. Risico is inderdaad dit soort gein, maar in -tig jaar Exchange is dit de eerste keer een zero-day die ik meemaak.

[SkiFan]

Nee, je leest verkeerd. Ze vinden het juist wel handig.

[Damusic2me]

als ik de code goed gelezen heb, zou je dit ook kunnen mitigeren, door te zorgen dat je een applocker policy hebt die geen powershell executions toe staat op je exchange server. Voor de initiele acties gebruikt deze expoit powershell (.net in de backend) uitgevoerd met de permissies van e user uiteraard.
Zolang je dus niet met je admin account gaat spelen op de exchange server, wat al jaren good practise is, en t beheer ff via de web interface doet, dan kan deze expoit niks doen.

[pfismvg]

Het exchange admin center doet alles met powershell. En ook de exchange powershell connect volgens mij naar de exchange servers om daar remote powershell op te starten. dus die applocker policy op je exchange is niet aan te raden 🥴

[GertMenkel]

Aan de ene kant begrijp ik dat de patch uit is, dat iedere competente hacker dezelfde diff kan uitvoeren op de updates, en dat het verwijderen van de code een beetje schijnveiligheid is. Daarnaast is het nog eens een exploit tegen een product van Microsoft ook, wat het nogal een geopinieerde moderatieactie doet lijken.

Aan de andere kant zijn Exchange-beheerders blijkbaar niet in staat in een normaal tempo updates te installeren en zo wordt het wel makkelijker voor scriptkiddies om de exploit te hergebruiken voor hun eigen botnets.

Ik ben in tweestrijd, maar ik denk dat uiteindelijk de exploit openbaar hebben beter is. In tegenstelling tot controversiëlere gevallen als zerodays die Microsoft niet op tijd kan of wil patchen, is het nu een kwestie van op de updateknop drukken als je servers nog steeds kwetsbaar zijn. De kwetsbaarheid zou onderhand nagenoeg nutteloos moeten zijn op servers verbonden met het internet, en hopelijk zet dit wat vaart achter bedrijven waar men terughoudend is in patchen omdat "de exploit toch nog niet uit is" (iets dat daadwerkelijk gebruikt wordt als onderbouwing om patchen zo lang mogelijk uit te stellen). Als bitcoinhackers de exploit ook hebben, moet men wel snel patchen en zullen staatshackers minder aan de hack hebben.

Niet echt chic van Microsoft om een exploit tegen hun eigen code weg te halen maar andere exploitcode gewoon te laten staan. Wees consistent, of je de code verwijdert of niet.

[kodak]

hopelijk zet dit wat vaart achter bedrijven waar men terughoudend is in patchen omdat "de exploit toch nog niet uit is" (iets dat daadwerkelijk gebruikt wordt als onderbouwing om patchen zo lang mogelijk uit te stellen)

Alleen was er al bekend dat er exploits werden gebruikt, waarom er snel update verschenen. Het argument dat bedrijven dan nu sneller zouden gaan patchen lijkt niet op te gaan en ook niet heel realistisch. De bedrijven die nog niet gepatched hadden lijken dus al niet te letten op het bekend zijn van exploits. Dan kiezen om exploits publiek te maken klinkt meer als niet zoveel geven dat die bedrijven dan geraakt kunnen worden en dan maar hadden moeten patchen. Dat is eerder onverantwoord, wat je ook van de bedrijven mag vinden die nog niet gepatched hebben zelfs als er al exploit code was.

[GertMenkel]

Het argument dat er nog geen publieke exploit is, zit in de risicobeoordeling van veel bedrijven verwerkt. Toen er schimmige verhalen over ETERNALBLUE rondingen maar er nog geen code bekend was, wist men dat er een exploit was maar was de kans dat dit tegen je bedrijf gebruikt werd zo klein dat het niet realistisch was om daar meteen een noodprocedure voor uit te moeten voeren. Als je bedrijf wat logger is en je managers meer geven om uptime dan om veiligheid, kan ik goed voor me zien hoe een bedrijf zo een maand lang hun kritieke patches uitstelt.

Toen een paar maanden later de exploit lekte was het natuurlijk al wel lang, lang tijd dat die systemen gepacht waren en dat was bij bedrijven als MAERSK duidelijk nog steeds niet in orde. Echter kun je met een geheime exploit, helemaal als die lastig uit te voeren is vanwege de manier waarop hij werkt, prima stellen dat je nog wel een week ofzo de tijd hebt om rustig je systemen voor te bereiden voor onderhoud.

Juist omdat het bekend was dat er al exploits waren, maakt het eigenlijk geen zak uit of er een publieke PoC is of niet. Je systeem was kwetsbaar, is kwetsbaar, en wordt bij publicatie even kwetsbaar. Het is niet alsof de IPv4-scanners de afgelopen weken je server niet gevonden hebben, heel IPv4 port scannen op 443 is met een paar dagen gedaan zelfs als je maar 1 VPS tot je beschikking hebt.

Het is niet dat ik iets heb tegen de bedrijven die hun patches niet op orde hebben ofzo, maar dit afschuiven op degene die de code publiceert vind ik nogal makkelijk. Alsof dit de kans dat je gehackt wordt ook maar een klein beetje vergroot. Als de PoC een gevaar oplevert voor je server, heb je grote kans dat je server vorige week al gehackt is.

Het voelt een beetje als de politici die bozer zijn op degene die uitlekt dat er in hun appgroepen verkeerde grappen worden gemaakt dan dat ze boos zijn op de grappen zelf. Voor hun is het probleem dat ze met hun neus in de feiten worden gedrukt belangrijker dan het onderliggende probleem.

[Reactie gewijzigd door GertMenkel op 22 juli 2024 23:01]

[kodak]

Het opvallende is dat je er geheel niet aan lijkt te willen dat niet alle bedrijven perse risicomanagement hebben of perse meewegen dat het nog erger kan. Er zijn miljoenen bedrijven op de wereld, dan kan je onmogelijk doen alsof het werkelijk voor al die bedrijven uit maakt om sneller te gaan patchen. Voor die bedrijven die er wel aan doen en de grens hebben die jij beschrijft zal het meewegen als ze er weet van hebben, maar dat gaat gewoon niet zomaar op. Daarbij lees ik ook niet dat je rekening wil houden dat zelfs als een bedrijf nu zou beslissen die patches ook niet meteen uitgerold zijn.

Je kan het afschuiven noemen dat een onderzoeker kritiek krijgt op het na een paar dagen al breed publiek maken van zeer gevaarlijke exploit code maar ik lees die onderzoeker op geen enkele manier verantwoordelijkheid nemen als het door zijn toedoen mis gaat bij die tienduizenden bedrijven die nog niet gepatched hebben. Hij had ook de moeite kunnen nemen om bij Microsoft aan te geven wanneer de exploit code bekend zou worden zodat die klanten gewaarschuwd konden worden. Maar dat doet de onderzoeker niet, die plaatst het gewoon online en die bedrijven en al die gebruikers zoeken het kennelijk verder maar uit. Dat klinkt echt niet heel verantwoordelijk.

[GertMenkel]

Als je als bedrijf niet aan risicomanagement doet, ben je wel enorm dom bezig om dit soort dingen zelf te hosten. Dan betwijfel ik ook of je ooit patches geïnstalleerd hebt; we hebben het hier over self-hosted exchange, dat is niet een dienst die de schilder om de hoek even opzet voor z'n mailtjes. Het is ook niet de eerste exploit van deze grootte voor exchange, dus deze hele molen zijn bedrijven al eerder doorgegaan, en hopelijk hebben ze daarvan geleerd.

Dat bedrijven nog niet gepacht zijn snap ik. Of ze dat nh niet willen of kunnen, er zijn duizenden mailservers in Nederland die hier nog wijd open voor staan. De vraag is alleen of het uitmaakt dat de code nu publiek is. De exploits waren al uit en servers werden al automatisch geïnfecteerd ver voor de exploit chain publiek werd. De exploit is opnieuw opgebouwd uit publiekelijk beschikbare informatie. De implementatie online bevatte bovendien bugs, waardoor aanvallers zonder kennis er nog steeds niks aan hebben. Wat voegt het toe?

Ik zie niet zo wat overleggen met Microsoft hier mee van doen heeft, eigenlijk. Microsoft heeft hun partners al gewaarschuwd dat dit lek een tijd lang actief geëxploit heeft, heeft patches uitgebracht, meerdere advisories, fingerprints voor logs, een scanner om te zien of je waarschijnlijk al geïnfecteerd bent. Je kunt er nog een keer een advisory overheen gooien ("hier is hoe de exploit werkt") maar ik vraag me af of daar iemand naar kijkt.

Het zou misschien netjes zijn om even te wachten met de exploit, of om de code niet online te gooien, maar een random onderzoeker op internet is niet verantwoordelijk voor je gebrek aan patches of mitigaties. In die trant zoeken bedrijven het ook zelf maar uit, inderdaad.

De updates zijn nu 10 dagen uit, en na drie dagen kon je er al op rekenen dat de exploit online verkocht werd door reverse engineers.

Ik ben eigenlijk wel benieuwd waarom bedrijven vorige week de patches niet al geïnstalleerd hebben. Wellicht komt het omdat ik zelf normaal met Linux werk, maar remote een update starten om vier uur 's nachts vanuit het serverbeheersystemen is nou niet echt lastig ofzo.

[kodak]

Ik zie niet zo wat overleggen met Microsoft hier mee van doen heeft, eigenlijk. Microsoft heeft hun partners al gewaarschuwd dat dit lek een tijd lang actief geëxploit heeft,

Je stelling was dat het publiek maken van exploit code uit zou maken voor bedrijven die daar rekening mee houden. In dit geval was er al exploit code, maar het werd nu helemaal publiek. Dat weten die tienduizenden bedrijven niet opeens omdat het op github of ergens anders is geplaatsts. Iemand zal ze dus moeten informeren, anders kunnen ze het risico daarop niet inschatten. Dan lijkt het een goed begin dat een security research dan Microsoft waarschuwt over dat extra risico bij hun product en klanten, zodat die de klanten en andere organisaties kan waarschuwen dat het nog meer publiek gaat.

[GertMenkel]

Microsoft werkt hun adviezen doorgaans bij, net als het NCSC, als er een proof of concept uit is. Ik weet niet of ze de pagina gisteren hebben bijgewerkt, maar toen ik gisteren hun pagina checkte gaven ze ook al aan dat de proof of concept publiekelijk was.

Misschien was het inderdaad verstandig om te melden dat over een paar uur de PoC uit zou komen zodat ze hun advies konden updaten, maar zoals in het bronartikel duidelijk wordt, monitor Microsoft dit soort dingen zelf ook al. Microsoft is een groot bedrijf en het duurt even voordat je de juiste persoon te pakken krijgt, het is waarschijnlijk sneller om het gewoon op Github te gooien dan om de interne bureaucratie daar langs te gaan.

Daarnaast hebben veel grote bedrijven er een handje van advocaten te sturen als je ze voor dit soort dingen waarschuwt. Zie maar dat verhaal met dat incompetente management van Walibi bijvoorbeeld, maar nu op wereldschaal. Microsoft heeft hier al aangegeven dat hun eigen gebruiksvoorwaarden ondergeschikt zijn aan hun eigen opvattingen, dus mocht ik zelf ooit in soortgelijke situatie terechtkomen, zou ik sterk twijfelen of ik wel met MS wil communiceren hierover.

[CrazyBernie]

Ze zijn dus consistent hierin. in het verleden is dit al vaker gebeurt ook voor producten van andere partijen dan microsoft.

Hieronder kopie van het statement van github aan motherboard.

We understand that the publication and distribution of proof of concept exploit code has educational and research value to the security community, and our goal is to balance that benefit with keeping the broader ecosystem safe. In accordance with our Acceptable Use Policies, we disabled the gist following reports that it contains proof of concept code for a recently disclosed vulnerability that is being actively exploited.

Ik vind het zelf trouwens een moeilijke afweging want voor wel of niet is allebei iets te zeggen. Ik vind in elk geval dat over een maand een en ander wel mogelijk moet zijn op github anders klopt er zeker iets niet.

[GertMenkel]

Zo consistent vind ik ze eigenlijk niet. Misschien dat ze consistent zijn bij exploits die de media halen, maar als ik zoek op Github vind ik meer dan genoeg exploits eigenlijk.

Ook worden oude exploits die ook actief zijn/worden misbruikt gewoon op Github gelaten.

Ik weet niet of ik een maand zou willen eisen, eigenlijk. De norm onder beveiligingsonderzoekers is 90 dagen nadat de bug is gemeld aan de maker van de software, en in de meeste gevallen wordt code gedeeld zodra de updates uit zijn omdat dan de exploits meteen algemeen bekend zijn. Als je de readup die bij de exploit hoort leest, kun je ook precies zien hoe de proof of concept gemaakt is; als een hobbyist dat uit kan vogelen, kan een cryptolockermaker dat waarschijnlijk ook wel.

[SPee]

Ook worden oude exploits die ook actief zijn/worden misbruikt gewoon op Github gelaten.

Hier geef je het zelf al aan wat het verschil is.
Zoals ze zelf zeggen; exploitaties van recente vulnerabilities mogen niet.
Dus over een paar weken opnieuw proberen.

[GertMenkel]

Mwah, de huidige exploits zijn onderhand ook oud. De nieuwe cryptolocker die zich met dit lek verspreid heeft een handtekening gelijkend aan de proof of concept die Microsoft zelf met antivirusmakers gedeeld heeft, dus zelfs Microsoft's geheime club heeft de exploits van twee weken geleden gelekt.

Een exploit is een exploit, en na twee weken en een hele lading persberichten denk ik dat het lek nu onderhand wel oud nieuws genoemd mag worden.

[Murfy]

De vraag is of ze dit ook zouden doen moest het om een exploit gaan die niet in het Microsoft-ecosysteem valt natuurlijk. Die historiek staat niet in het artikel, dus ofwel is die er niet, ofwel is het niet opgenomen in het artikel.

Disclaimer: ik heb niet gezocht

[CrazyBernie]

Dat staat wel onder het artikel op ars Technica. Het beleid is dat ze vanuit github exploits die plug en play zijn pas toestaan als er ruim voldoende tijd is geweest om te patchen. Dus is niet alleen voor ms producten zo.

Omdat het zo'n eenvoudig uit te voeren hack is ben ik het er ook mee eens voor dit moment. Je ziet trouwens ook dat sits zoals wired en ars Technica geen links plaatsen naar een kopie van deze github repo. Met exact dezelfe reden namelijk dat er nog te weinig tijd tussen de patch datum zit en deze voorbeeld code.

[The Zep Man]

Het beleid is dat ze vanuit github exploits die plug en play zijn pas toestaan als er ruim voldoende tijd is geweest om te patchen.

Wat is ruim voldoende tijd voor Microsoft producten, en wat is ruim voldoende tijd voor producten van andere leveranciers?

Als die gelijk zijn, dan is er niets aan de hand.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 23:01]

[tonkie_67]

Ik denk dat die tijd niet hard in dagen of weken is te melden: ligt ook aan het produkt waar de hack voor is, hoe eemvoudig te patchen, hangen de onveilige systemen direct aan internet en indien bekend: hoe veel systemen zijn nog niet gepatcht.
En dan is het niet gek dat een kwetsbaarheid in een produkt als een on-prem mailserver die bij heel veel grote en ook kleinere organisaties draaien meer 'secret tijd' krijgen dan bijv een kwetsbaarheid in een meer obscure puur intranet systeem (kleinere impact en lastiger te misbruiken zonder opening naar inet) of een systeem dat uitsluitend door een beperkt aantal cloud providers beheerd wordt (cld providers kunneb geacht worden sneller te kunnen patchen of andere mitigerende acties te ondernemen: syst beheer is immers hun core business [althans zou moeten zijn: tokos die alleen de sales voor elkaar heeft en belabberd sys beheer bestaan helaas ook]

[punica]

Microsoft heeft de patch klaar staan, het gaat erover dat de gebruiker de patch niet installeerd. Daarom willen ze de exploit weghouden van github.

[FreshMaker]

Maar dat zou dan zijn dat in de echte wereld je geen mes meer mag kopen bij de Action, omdat niet iedereen zijn steekvest wil dragen.


Ik snap best dat je de code de eerste uren/dagen niet integraal online wilt hebben, maar dit soort zaken moet je als verantwoordelijke toch al wel op orde hebben

[ViTO_xp]

Je vergelijking gaat volledig mank...

[amx]

https://veiliginternetten...n-responsible-disclosure/

[ajolla]

Een exploitability die al 10 jaar bestaat...

[Maurits van Baerle]

Als ik het goed begrijp is de kritiek dat ze wel exploit code die niet op MS is gericht laten staan.

Het zou dan niet een algemeen “geen exploits” beleid zijn maar eerder een “geen exploits waar MS last van heeft” beleid zijn.

[Reactie gewijzigd door Maurits van Baerle op 22 juli 2024 23:01]

[System]

Snap het probleem niet eigenlijk. Dat is toch logisch? Github is geen liefdadigheidsinstelling toch?
Het is ook geen overheidsinstantie. Dus eigenlijk doen ze wat ze willen.

[Mangu429]

Dan kun je er nog wel kritiek op hebben.

[System]

Dat mag zeker hoor
Maar eigenlijk is het simpel. Als het het niet eens bent met hun policy, gebruik dan iets anders.
Ik heb ook geen Facebook meer.

[BLACKfm]

Helaas heeft facebook jou waarschijnlijk nog wel, maarja, je kunt lastig het hele internet de deur uit doen...

[System]

Er zijn zat manieren om cookies op een heel makkelijke en gebruiksvriendelijke manier te blokkeren/op te schonen.(cookies verwijderen bij sluiten browser, bepaalde cookies blokkeren, DuckDuckGo privacy essentials,...)
En bovendien acht ik de data die ze op halen via pixels en andere cookies minimaal als je zelf geen FB gebruikt.
Mijn ervaring is dat dit hier op tweakers heel vaak hard opgeblazen wordt en dat de soep bijlange niet zo heet gegeten wordt als dat ze opgediend is.

[Kontsnorretje]

Ik snap wel dat ze het (voorlopig) hebben verwijderd. Vooral bij de grotere bedrijven kan het war langer duren voor zo'n patch overal is doorgevoerd. Nog niet eens 2 weken is dan wel heel krap.

[eltweako]

Microsoft gaf aan dat je beter niet kon wachten tot je vaste patchmoment en de patch zo snel mogelijk moest uitvoeren.
Als dit niet mogelijk was zijn er een set van workarounds die je kon doorvoeren om het lek zo ver mogelijk te dichten.
https://msrc-blog.microso...s-mitigations-march-2021/

Dagen/Weken of zelfs maanden wachten is niet mogelijk bij dit lek, daarvoor is het te ingrijpend en te eenvoudig te misbruiken.
Het weghalen van de code van Github heeft natuurlijk geen enkel nut, de code is al op genoeg andere plekken te vinden.

[SillieWous]

Ja dat is inderdaad makkelijk makkelijk gezegd als je een server draaiende moet houden. Echter wanneer je een multinational hebt waar je niet een maar meerdere servers draait op verschillende locaties is dit niet altijd even eenvoudig. Ga maar eens uitleggen aan je chef dat vandaag niemand bij zijn mail kan omdat alle servers acuut geüpdatet moeten worden.

Daarvoor zijn juist momenten dat je dit kan doorvoeren, meestal het weekend. Dan kun je de tijd nemen om een backup server met lagere workload in te schakelen, de patch door te voeren en te testen. De maandag er op heb je alles weer draaiend als er geen problemen zijn. Afhankelijk van hoe het bedrijf is ingericht moet je daarna nog op andere locaties hetzelfde doen.

[eltweako]

Ik leg liever 20x aan mijn chef uit waarom vanavond niemand aan zijn mail kan dan dat ik 1x moet uitleggen wie HAFNIUM is en waarom ze in onze server zitten.

Bij een beetje fatsoenlijke omgeving kun je niet zomaar even een patch installeren. En ook een workaround kost tijd. Feit is wel dat iedere goede organisatie ook afspraken heeft hoe je om gaat met zero-day vatbaarheden. Als het management vind dat het onacceptabel is dat mail onverwacht off-line is, dan moeten ergens op papier staan dat het acceptabel is om een bepaalde tijd je server bloot te stellen aan aanvallen vanaf de hele wereld.

We hebben het hier niet over een aanval waarbij je met geavanceerde tools en ingewikkelde scripts uren bezig bent om een server te scannen, parameters aan te passen en hopen dat het lukt. We hebben het hier over een aanval waarbij je met een simpel script volledige toegang krijgt tot een server.

[mrdemc]

Onzin, de interim mitigation’s kun je doen zonder downtime. De meeste multinationals zullen, hoop ik, daarnaast meerdere servers hebben voor load balancing waarmee ze de servers zonder downtime kunnen updaten.

[supersnathan94]

Juist als je meerdere servers hebt is het makkelijker toch? Het hebben van meerdere servers is ook voor redundancy. Als er 1 uitvalt (gewenst of niet) draait het zaakje nog wel. Juist daardoor kun je rolling upgrades doen zonder dat je dienstverlening er mee kapt.

[mjtdevries]

Redundancy is super simpel bij Exchange. Dat is het probleem ook niet. Exchange kun je prima gedurende kantoor tijden patchen.
De reden dat bedrijven niet onmiddellijk na uitkomen van een patch die uitrollen is dat ze die eerst willen testen.

In dit geval was het risico echter zo hoog dat je die tijd niet had. Hoewel snel installeren op je test servers ook niet zoveel tijd hoeft te kosten. Meer een kwestie van al je andere werk uit je handen laten vallen en dit top prioriteit geven.
Bij grote bedrijven met dedicated Exchange admin is dat niet zo moeilijk te regelen.

Wat ik zo aan reacties heb gezien in de afgelopen week dan zijn het juist de kleine omgevingen die niet snel gepatch hebben. Kleine omgevingen waarin er maar 1 server is, waar er geen dedicated admin is.

[supersnathan94]

Ja precies. Het lijkt me juist op high end enterprise niveau eenvoudiger te regelen doordat je geen downtime hebt. Dan kan het dus gewoon tijdens kantooruren.

[ajolla]

Vraag je chef wat 'ie liever heeft: ransomware en geen email-geschiedenis meer, of even geen email.

[GertMenkel]

Hoewel dat voor kleine updates als bugfixes, DoS-bugs en elevation of privilege exploits te begrijpen valt, is dit nogal een alle-hens-aan-deksituatie. We hebben het letterlijk over een aanval die triviaal uit te voeren is, geen voorkennis over de server vereist, direct en betrouwbaar tot remote code execution leidt en ook nog eens een service aanvalt die direct integreert met het AD-systeem van een Microsoft-netwerk.

Zerologon fixen kan je misschien nog uitstellen omdat het veel tijd kost, maar dit is toch echt wel een update die je zo snel mogelijk moet patchen. Twee weken voor een bug met zo'n impact vind ik persoonlijk niet acceptabel, eigenlijk.

[Kontsnorretje]

En juist daarom is 2 weken ook te vroeg om een proof of concept te publiceren als het aan mij ligt.

[GertMenkel]

Dat begrijp ik ook wel, maar het nu de eerste automatisch cryptolockers (gemaakt met exploitcode van Microsoft zelf die ze met hun besloten antimalwarepartnergroep hebben gedeeld) rond gaan, maakt de PoC eigenlijk niet zoveel meer uit denk ik. Als je nu nog wordt gehackt, ligt dat aan je patchbeleid, niet aan het feit dat iemand je er nog een keer extra op hebt gewezen.

Dat gezegd hebbende moet je zoiets niet aan het eind van de week publiceren. Doe het dan op een maandag, dan hebben de systeembeheerders van de bedrijven met achterhaalde security nog een weekend. Wel zo sociaal.

[tonkie_67]

Gelukkig zullen er niet zoveel on prem exchange servers meer zijn bij mkb bedrijven zoals je bijvoorbeeld 10-15 jaar terug had als de aannemer om de hoek een 'small business server' setup had die ze eenmalig hadden laten opzetten door lokaal it bedrijf (of zoon van bevriende relatie tegen kleine vergoeding) en vervolgens het 'systeembeheer' werd toebedeeld aan de secretaresse of de boekhouder (niewe accounts aanmaken, hopelijk af en toe backup tape naar huis nemen en 2x per jaar op ja klikken voor update en reboot.....
Al zou het me ook niet verbazen als dat soort installs nog steeds online zijn....

[GertMenkel]

Ik verwacht het niet nee, helemaal nu managed exchange van Microsoft afnemen zo goedkoop en makkelijk is. Maandelijks de rekening voor de mail betalen is makkelijker dan de zoon van de secretaresse uit zijn les op de middelbare trekken omdat Josien ineens allemaal gekke mails krijgt. Met zo'n setup verwacht ik ook eigenlijk geen backups, moet ik zeggen...

Er zijn eerder al Exchange-kwetsbaarheden geweest die zo simpel en effectief code execution toestonden, dus ik denk dat bedrijven in de situatie die jij beschrijft toch al gehackt zijn. Misschien dat de botneteigenaren de servers dan voor je patchen zodat de concurrent er niet in kan, IT-beheer uitbesteden noemen we dat

[Verwijderd]

Exact dit. Kan het ook goed begrijpen. Bij de meeste bedrijven worden updates echt pas maanden later doorgevoerd vanwege uiteenlopende redenen.

[System]

De meeste bedrijven hebben hun patchen en updates net zoals consumenten.
Bedrijven die updates beheren zijn een minderheid.
Denk aan alle kleinere bedrijven met 100 of minder werknemers. Ik ken zelfs bedrijven met 500+ werknemers die dit niet doen.

[ajolla]

Bij zo'n exploit heb je 2 keuzes: óf je patcht onmiddellijk, óf je sluit de server af.

[Verwijderd]

absoluut, echter management of hoger denkt daar vaak heel anders over.

Uit mijn eigen ervaringen komt het echter vaak voor dat de servers ongepatched blijven een poosje, ( lees een maand) voordat er een patch word doorgevoerd. Is dat goed en steun ik dat? Nee. Echter is het wel de realiteit bij veel kleinere bedrijven die geen middelen voor een goede IT hebben, of het simpelweg niet willen uitgeven aan IT ( < veel voorkomend iets )

[ajolla]

Ja ik snap het, ben zelf ook maar een mens.

[nullbyte]

Ik niet, ik werk in een bedrijf met 70000 werknemers. De exchange servers zijn met een spoed change direct gepatched. En ik zie dan ook geen reden waarom een dergelijke change niet zo snel mogelijk uitgevoerd kan worden. Als het goed is zijn exchange servers redundant uitgevoerd ze kunnen dus makkelijk om en om patchen en herstarten.

Dat hoeft geen maanden te duren.

[Verwijderd]

Een bedrijf met zoveel werknemers heeft dan ook vaak meer middelen dan een gemiddeld klein bedrijf waar ik het over heb.

Goed om te horen dat dat in ieder geval goed geregeld is bij jullie.

[mrdemc]

Ik begrijp het niet. De code heeft sowieso al online gestaan, maar los daarvan maakt het verwijderen van deze code de niet-gepatchte servers niet ineens veiliger. Met of zonder deze repository zijn deze servers nog net zo onveilig. Ook zijn er meer plekken dan GitHub waarop je dergelijke code zou kunnen vinden en kunnen meer mensen het wiel opnieuw uitvinden. Het is niet ongewoon om dergelijke repositories op GitHub te hebben staan als proof of concept en educatief materiaal.

[punica]

Struisvogel politiek.

[mjtdevries]

Het is niet ongewoon om dergelijke repositories op GitHub te hebben staan als proof of concept en educatief materiaal.

En zou die educatieve waarde minder zijn als je er voor kiest alle proof of concept en exploit code pas na 4 weken op GitHub te plaatsen?

Dat het op andere plekken ook te vinden is, betekent niet dat je het perse nog makkelijker moet maken om het te vinden.
Wie heeft er een echte valide reden waarom dit binnen 4 weken op GitHub moet staan?

En dat staat volledig los van wat je patch beleid moet zijn, of hoeveel het al op andere plekken te vinden is. Maak 4 weken gewoon het standaard beleid.

[mrdemc]

Als het los zou staan van het patch beleid, wat zou dan nog een valide reden zijn om het níet te plaatsen? Waarom zou je dan die 4 weken moeten wachten en waarop?

De educatieve waarde wordt er inderdaad misschien niet minder om, maar bij andere code zul je ook geen 4 weken hoeven te wachten, waarom dan wel in zo’n geval als de patch al beschikbaar is? Het misbruik door kwaadwillenden wordt toch wel gedaan en hangt niet af van de beschikbaarheid van deze code op GitHub.

[mjtdevries]

Omdat je het aantal kwaadwillenden nu groter maakt. Nu stimuleer je ook scriptkiddies die verveeld thuis zitten om te gaan klooien.

Wat kan het kwaad om gewoon altijd een paar weken te wachten? Waarom kan en wil niemand daar een antwoord op geven?

Zeker kleine bedrijfjes hebben geen dedicated admin en die zijn juist degene die je nu extra schade berokkend.
En waarom 4 weken? Omdat je dan een makkelijke standaard hebt die voor alle patches geld. Ook die waarvoor je gewoon je normale tests uitvoert en die dus niet de volgende dag uitgerold worden. Ook voor de bedrijven die om welke reden dan ook trager zijn. (met name de kleine bedrijfjes die geen dedicated admins hebben)

[Platpoot]

Tjsa, maar of het verwijderen echt bijdraagt aan het niet misbruiken van het lek vraag ik me af.

En tsja wat is een groot bedrijf? Ik beheer geen kinderachtige omgeving met ongeveer 100000 mailboxen, en die zijn gewoon op een avond gepatcht. Het kan zijn dat er mogelijk een bug in zit in de update, maar in dit geval kies je voor mogelijke onbeschikbaarheid tov nagenoeg zeker dataverlies.

[MeMoRy]

Het is gepubliceerd op een openbaar stuk van het internet, dus intussen zal het op heel veel plaatsen staan.
Nu nog verwijderen heeft mijn inziens niet echt veel zin meer. Lijkt me echt een bedrijfpolitieke actie. En daarbij op de grens van machtsmisbruik (mijn mening).

[MrFax]

Die code is toch wel ergens anders te vinden. Security through obscurity werkt alleen als alleen maar een handjevol security experts de code hebben, maar als het al open en bloot is dan heb je daar niks meer aan.

[Reactie gewijzigd door MrFax op 22 juli 2024 23:01]

[Verwijderd]

Een denkbeeldig voorbeeld: Er zijn veel mensen die GPS tracking software gebruiken om te weten waar hun kinderen zich bevinden. (Ik wil geen discussie starten of dit goed of slecht is... het is maar een voorbeeld uit het leven gegrepen) Iemand ontdekt een exploit waarmee elke simpele gebruiker de software kan misbruiken op een manier waarop kinderen opeens ook gevolgd kunnen worden door kwaadwillenden. Iemand deelt die software op Github. Is dat verantwoord? Of moet men dat weghalen? Of is het gewoon simpel: ouders moeten maar stoppen met het gebruiken van de software totdat de software gepatched is en de software moet voor iedereen beschikbaar blijven zodat men het kan "onderzoeken"?

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:01]

[FreshMaker]

Dat ligt ook wel een beetje aan MS, In het verleden maakte zo'n grote patch meer kapot dan het ging oplossen

Veel bedrijven vertrouwen het niet meer, en willen het dus eerst testen.
En een securitypatch testen, is nu eenmaal lastiger dan een 'feature-update'

Dus in deze kan je beide kanten geen ongelijk geven, lijkt mij

[mjtdevries]

In het verleden maakte zo'n grote patch meer kapot dan het ging oplossen

Wat een onzin.
Ik heb Exchange beheerd van 5.5 naar 2016 en alle versies er tussen. En ik kan me geen enkele patch herinneren waar dat voor gold.
Op Microsoft is genoeg aan te merken, maar Exchange was altijd hun betere kwaliteit software.

En een securitypatch testen, is nu eenmaal lastiger dan een 'feature-update'[

Want? Ga jij daadwerkelijk kijken of daarna de exploit code niet meer werkt, of ga je gewoon testen of de Exchange functionaliteit blijft werken?
Dat laatste natuurlijk en dat is dus minder werk.
En security patches veranderen minder code en zijn daardoor minder riskant dan een feature update.

En laten we wel wezen. Hoe lang ben je nou daadwerkelijk aan het testen?
Voor een security patch test je de basis functionaliteit. Kan ik mailen, werkt OWA, werkt activesync, werkt UM. Het installeren van de patches duurt waarschijnlijk langer dan het testen.

[decide1000]

Ik snap wel dat ze het willen doen, maar ik snap niet dat ze het daadwerkelijk doen...
Gaan ze nu ook alle exploits van (concurrerende) software verwijderen? Of alleen iets wat hen zelf betreft?

[Cergorach]

Bij een hoop bedrijven waar niet direct actie is ondernomen is het al te laat, er poste vorige week al een tweaker dat donderdagochtend er zaken geïnstalleerd waren terwijl de voorbereidingen voor het patchen in gang waren gezet. Een hoop bedrijven zullen het zekere voor het onzekere hebben gekozen en de boel opnieuw hebben geïnstalleerd. Als je het nu nog patched ben je dus al geïnfecteerd!

[jurroen]

Een hoop bedrijven zullen het zekere voor het onzekere hebben gekozen en de boel opnieuw hebben geïnstalleerd.

Best case scemario. Ben echter bang dat het niet om een hoop bedrijven gaat, maar eerder om een hamdvol uitzonderingen.

[rjberg]

Zet er dan bij dat het tijdelijk is en dat over een aantal maanden de code terug kan. En geef beveiligingsonderzoekers op verzoek toegang. Daar zouden mensen denk ik wel genoegen mee nemen.

[Ellej_Harmsen]

Ja, zo iets dacht ik dus ook. Als de patch sinds 10 dagen beschikbaar is lijkt me het logisch dat het nog niet overal waar nodig gepatched is. Microsoft had het veel beter kunnen aanpakken door op de github pagina een boodschap te plaatsen met "Nu wegens mogelijk actief gebruik van de lek onbeschikbaar, over twee maanden is het vrij in te zien. Mocht u beroepshalve toch toegang nodig hebben tot deze expoit code, neem dan contact op met ..." Dan was er vast veel minder ophef geweest.

[SuperDre]

Nouja, ze hebben alle recht natuurlijk, Github is nu eenmaal van Microsoft. En zij liggen er echt niet wakker van dat zo'n 'onderzoeker' dreigt zijn code daar weg te halen, moet eerlijk zeggen dat ik het juist maar een zielige uitspraak vindt.

[punica]

Juiste reactie van GitHub. Deze exploit is een groot vangnet waarmee je hele servers leegtrekt. Geen doel, gewoon full dump. Kan tig jaar duren voordat erna gekeken wordt.

Maar als je je dan voorsteld dat dit China is, op zoek naar de krenten in de pap.... Dan is over 100 jaar de wereld een betere plek door deze reactie.

Hier zit een politieke beslissing achter. En daarbij, de info heeft een paar uur op github gestaan, dus een mirror is maar een paar uur verwijderd... Oh..shit...

Bron: joe rogan

[Reactie gewijzigd door punica op 22 juli 2024 23:01]

[effyouck]

Waar zijn al die neo-christelijke schtreijders voor vrijheid van meningsuiting? Valt dit er dan niet onder? Dit telt wél als gevaarlijke info dus mag wél echt gecensureerd worden? Is Github nu een mediakanaal of een uitgever? /s

Niet meer dan logisch dat deze code offline wordt gehaald.

[heszar]

Helemaal mee eens, je gaat toch ook geen source code van een Keygen zetten en dan huilen als die weg gehaald word.

[elmuerte]

Het is mij niet duidelijk op basis van wat Github deze repository verwijderd heeft. Het kan geen DMCA zijn. Iets uit de TOS van Github?
Men refereert naar https://docs.github.com/e...es#2-content-restrictions
Maar dit is geen malware of active exploit. Metasploit is bijvoorbeeld geen probleem for github.

[Reactie gewijzigd door elmuerte op 22 juli 2024 23:01]

[lilmonkey]

Maar dit is geen (…) active exploit

Erm, jawel?

[Rabb]

De patch is pas 12 dagen oud. Ja, deze exploit is active.

[lilmonkey]

(verwijderd, verkeerde plek)

[Reactie gewijzigd door lilmonkey op 22 juli 2024 23:01]