Microsoft zwijgt week na ontdekking nog over patch voor Follina-bug

Microsoft heeft nog steeds geen officiële patch beschikbaar voor de Follina-bug die vorige week openbaar werd. Ook kan het bedrijf niet zeggen wanneer zo'n patch er komt. Ondertussen wordt via de Follina-bug actief in verschillende landen aangevallen.

Securitybedrijf Proofpoint zegt dat het diverse actieve aanvallen via Follina op Europese en Amerikaanse overheidsinstanties heeft afgeslagen. Het bedrijf zegt niet welke instanties dat zijn, maar de gevolgen zouden met 'minder dan tien Proofpoint-klanten' relatief beperkt zijn. De instanties werden aangevallen via de Follina-bug die vorige week naar buiten kwam. Follina is een kwetsbaarheid in de Support Diagnostics Tool die het mogelijk maakt om van een afstand code uit te voeren met rechten van het gebruikte programma. Volgens Proofpoint vielen de aanvallers de slachtoffers aan door een phishingmail te sturen en na het klikken PowerShell aan te roepen. Dat maakt de bug erg gevaarlijk.

Desondanks heeft Microsoft nog steeds geen patch voor de zeroday uitgebracht. Het bedrijf publiceerde vorige week wel een workaround voor CVE-2022-30190, maar er is vooralsnog geen patch beschikbaar die de kwetsbaarheid repareert. Het bedrijf verwees daarbij naar een blogpost waarin het meer informatie geeft. Die is maandag voor het laatst bijgewerkt, maar slechts met meer vragen en antwoorden. Het bedrijf spreekt nog steeds niet over een definitieve oplossing.

Reacties (60)

[Byron010]

Sorry hoor maar wat een titel.. ze zwijgen helemaal niet, ze hebben een workaround gepubliceerd en een blog die gisteren is bijgewerkt met de informatie die ze publiekelijk kunnen/willen maken. Blijkbaar kost het wat tijd om een daadwerkelijke goeie patch te maken. Je wilt natuurlijk niet een halve patch waarbij over een week weer nieuws komt dat de patch een kwetsbaarheid bevat waardoor X mogelijk is.

[CAPSLOCK2000]

Sorry hoor maar wat een titel.. ze zwijgen helemaal niet, ze hebben een workaround gepubliceerd en een blog die gisteren is bijgewerkt met de informatie die ze publiekelijk kunnen/willen maken. Blijkbaar kost het wat tijd om een daadwerkelijke goeie patch te maken. Je wilt natuurlijk niet een halve patch waarbij over een week weer nieuws komt dat de patch een kwetsbaarheid bevat waardoor X mogelijk is.

En dit is dus waarom ik zo graag de broncode heb zodat ik zelf een tijdelijke fix kan (laten) schrijven voor mijn organisatie. Zodat ik zelf de afweging kan maken of een 'halve patch' beter is dan de workaround (uitschakelen). Een leverancier als MS moet de belangen van eindeloos veel klanten balanceren en komt met één oplossing voor iedereen en kan daar pas mee komen als die "af" is. Het is niet meer dan logisch dat die 'one size fits all' oplossing niet voor iedereen de beste oplossing is en een goede universele oplossing soms lang op zich kan laten wachten.

Uiteraard moet je dat wel kunnen (of iemand huren die het kan) en het kan duur of riskant zijn maar dat is een keuze en soms is het de betere keuze. Gewoon wachten op de leverancier kan ook altijd nog.

[Brahiewahiewa]

Sorry hoor, maar dat is het hele idee van een support contract. Dat je het coderen van een OS overlaat aan degene die het support. Anders krijg je dat jij een zelfgemaakte fix draait voor dit probleem en iemand anders een andere zelfgemaakte fix draait voor een ander probleem, and so on. Zouden ze dus 1 miljard verschillende versies van windows moeten supporten. Als je daar even over nadenkt begrijp je denk ik wel dat MS daar niet aan wil beginnen

[CAPSLOCK2000]

Sorry hoor, maar dat is het hele idee van een support contract. Dat je het coderen van een OS overlaat aan degene die het support.

Dat is uiteindelijk een kosten/baten analyse. Bij een normaal support contract van MS krijg je geen patches op maat maar ben je gewoon een van de velen en moet je het maar doen met wat MS levert, of dat nu geschikt is voor jouw omgeving of niet. In de meeste gevallen werkt dat prima maar het is wel eenheidsworst. Soms is die eenheidsworst gewoon niet geschikt of te laat. Als bedrijf wil je keuzes hebben.

Anders krijg je dat jij een zelfgemaakte fix draait voor dit probleem en iemand anders een andere zelfgemaakte fix draait voor een ander probleem, and so on. Zouden ze dus 1 miljard verschillende versies van windows moeten supporten.

Je krijgt uiteraard geen support op je eigen veranderingen, nou ja, tenzij je daar voor betaalt, maar het is ook niet realistisch dat er massaal eigen fixes worden geschreven of dat die lange tijd in gebruik blijven. Zo werkt het in praktijk niet.

Voor de duidelijkheid, ik heb het niet over een theoretisch scenario. Dit is de dagelijkse praktijk voor Linux. Ik zit een omgeving waar mensen daadwerkelijk zelf fixes en work-arounds schrijven of aanpassen als de leverancier te lang op zich laat wachten en ik werk niet eens voor een IT-bedrijf. Daarbij ontstaan er geen 1 miljard verschillende versies. Typisch is het zo dat de community een quick & dirty patch ontwikkelt terwijl er gewacht wordt op een nette oplossing. Wie het wil kan de tijdelijk patch gebruiken. Of dat verstandig is dat is uiteindelijk de professionele inschatting van de beheerder.

[CodeCaster]

Wat houdt het zelf hotfixen van applicaties op Linux dan concreet in? Wat voor wijzigingen breng je aan, in wat voor software, en (hoe) compileer en distribueer je die vervolgens?

Er is nogal een verschil in een env-variabele of commandline-flag toevoegen in een script dat een daemon opstart, en een tool met een buildstraat van hier tot Tokio uitbreiden met custom C++/Go/...-patchfiles, dat succesvol laten compileren en dat op de machines van je eindgebruiker laten terechtkomen zonder dat de volgende update iets sloopt.

[CAPSLOCK2000]

Wat houdt het zelf hotfixen van applicaties op Linux dan concreet in? Wat voor wijzigingen breng je aan, in wat voor software

Vooral in de software die ik zelf gebruik en dat is voornamelijk vrij gespecialiseerde (security) software. Het "soort" wijziging is meestal iets als "niet kapot gaan als er een spatie in de naam zit", "negeer vreemde tekens" , "zoek het bestand op de nieuw locatie" of "dit bestand heeft alleen leesrechten nodig".
Meestal is de verandering zelf triviaal. Door er zelf een uur in te steken kan ik verder in plaats van dat ik een maand moet wachten tot de leverancier reageert.

, en (hoe) compileer en distribueer je die vervolgens?

Nou vooruit, omdat het blijkbaar onbekend terrein is zal ik gewoon een compleet voorbeeld geven van het proces. In praktijk gaat het zo op mijn Debian systemen.

1. aptitude source <hetpakket>
Dit download alle soures die je nodig hebt
2. aptitude build-deps <hetpakket>
Dit download alle ander software die je nodig hebt zoals compilers.
3. dch --nmu
Geef in de changelog aan wat je doet
4. quilt new mijnfix.patch
Maak een nieuwe patch aan
5. quilt edit src/een/bestand.c
Doe je verbetering
6. quilt refresh
Stop alle veranderingen in je patch
7. dpkg-buildpackage
Bouw een nieuwe pakket met je eigen fix er in.
8. dpkg -i <hetpakket>
Installeer het nieuwe pakket en test je veranderingen.

Kwartiertje werk als je het vaker doet, uiteraard uitgezonderd de tijd die je nodig hebt om te bedenken wat er mis is en hoe je dat oplost. In 9/10 gevallen gebruik ik een fix die door de community is aangedragen

Er is nogal een verschil in een env-variabele of commandline-flag toevoegen in een script dat een daemon opstart, en een tool met een buildstraat van hier tot Tokio uitbreiden met custom C++/Go/...-patchfiles, dat succesvol laten compileren en dat op de machines van je eindgebruiker laten terechtkomen zonder dat de volgende update iets sloopt.

Ik heb het over tijdelijke security fixes, niet over nieuwe features. De meeste security fixes zijn een slechts 1 regel lang en bevatten een kleine correctie voor een denk of tikfout. Het is niet de bedoeling om een lokale fix lange tijd te onderhouden maar slechts de periode te overbruggen tot er een betere oplossing is, zoals een patch van de leverancier.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 20:29]

[trisje]

als het zo eenvoudig is waarom heeft microsoft het dan niet in een half uurtje gefixt. ? Willen ze het dan niet of blijkt het toch iets ingewikkelder te zijn dan jij het nu even voorsteld.? Ik heb er geen verstand van ik kijk gewoon logisch naar de resultaten tot nu toe en concludeer dat het kennelijk het laatse betreft.

[nullbyte]

Dat vroek ik me ook al af. Er wordt gebruik gemaakt van een buffer overflow in MSDT. Er ontstaan problemen bij meer dan 4096, dat leek mij niet zo moeilijk op te lossen.

[CAPSLOCK2000]

als het zo eenvoudig is waarom heeft microsoft het dan niet in een half uurtje gefixt. ? Willen ze het dan niet of blijkt het toch iets ingewikkelder te zijn dan jij het nu even voorsteld.? Ik heb er geen verstand van ik kijk gewoon logisch naar de resultaten tot nu toe en concludeer dat het kennelijk het laatse betreft.

Ik heb nooit gezegd dat deze bug eenvoudig is. Ik weet het niet want ik kan de code niet zien. Maar mijn ervaring is wel dat dit soort bugs meestal simpel zijn. Hoe het echt zit zal je aan Microsoft moeten vragen.
Waarschijnlijk heeft het er mee te maken dat ze een oplossing voor de hele wereld proberen te bouwen die werkt in alle denkbare gevallen.

Zoals altijd heeft iedere keuze voor en nadelen, daarom zijn problemen vaak makkelijker op te lossen als je een kleine doelgroep hebt. Soms kun je dan een eenvoudig oplossing kiezen omdat bepaalde nadelen niet van toepassing zijn op jouw situatie. Zo hadden we laatst met een printerdriver. Dus hebben we printen uitgezet op die computers want ze printen toch niet. Dat werkt voor ons maar niet voor alle computers in de wereld.

[KirovAir]

Dit is echt zulke onzin. Je hebt geen idee hoe een echte IT organisatie in elkaar zit en als ik het zo lees ook geen idee hoe een echte exploit fix werkt. Je geeft ook zelf aan niet bij een IT bedrijf te werken.

Alles wat ik lees is hobby-bob gehalte. De use-case van 99.99% van de Windows gebruikers is even iets anders dan een in elkaar gechefte Linux omgeving met handmatige patches en fixes. Het aanpassen van een rw’tje op een dir? Met de hand? Ja succes, dan heeft dit artikel inderdaad niks te maken met jouw use case en ik snap de vergelijking of oproep aan broncode dan ook niet.

Geen bedrijf die zijn vingers wilt branden aan de linux sysops die eigen patches gaat toepassen op elk stukje software om even de bleeding edge fix te pakken. Enig idee wat voor security risk dat met zich mee brengt? En ja, de linux sysops begrijpt uiteraard exact wat er geïnstalleerd is met welke regeltjes code aan fixes. Maar ga dat maar verantwoorden als manager of als de sysops opstapt.

Niks tegen Linux verder, onze hele omgeving stampt er data mee weg maar dit hele argument slaat echt als een tang op een varken.

[Reactie gewijzigd door KirovAir op 22 juli 2024 20:29]

[CAPSLOCK2000]

Alles wat ik lees is hobby-bob gehalte.

Alleen als je uit gaat van een omgeving met beheerder die zelf niks kunnen en voor alles afhankelijk zijn van de leverancier.

De use-case van 99.99% van de Windows gebruikers is even iets anders dan een in elkaar gechefte Linux omgeving met handmatige patches en fixes.

Je zegt nu dus dat het beter is om een onveilig systeem zonder patches door te laten draaien? Of durf jij je systemen uit te zetten tot die patch er wel is? Mijn bussiness wil dat we alles doen om de applicaties in de lucht te houden. Als we een gat zelf kunnen dichten dan doen we dat want dat is goedkoper dan de tent sluiten tot de leverancier met een fix komt.

Het aanpassen van een rw’tje op een dir? Met de hand? Ja succes, dan heeft dit artikel inderdaad niks te maken met jouw use case en ik snap de vergelijking of oproep aan broncode dan ook niet.

Nee, met code. Software maakt nog wel eens files/directories aan met meer rechten dan nodig. Het is vrij simpel om dat te veranderen.

Geen bedrijf die zijn vingers wilt branden aan de linux sysops die eigen patches gaat toepassen op elk stukje software om even de bleeding edge fix te pakken. Enig idee wat voor security risk dat met zich mee brengt? En ja, de linux sysops begrijpt uiteraard exact wat er geïnstalleerd is met welke regeltjes code aan fixes. Maar ga dat maar verantwoorden als manager of als de sysops opstapt.

Als je afhankelijk bent van 1 persoon dan moet je je bedrijf anders inrichten, dat staat helemaal los van wat die persoon verder wel of niet doet. Een goede IT'er zorgt voor documentatie zodat collega's het over kunnen nemen.

[CodeCaster]

Dat ziet eruit als een zeer werkbare workflow, bedankt voor de toelichting!

[Bulkzooi]

Da's de workflow om iets met de Cloud te patchen. De native workflow is meer van belang voor cybersec en infosec. Ik bedoel, je wilt niet AWS of S3 een partij is; zeker nu niet meer, nu de politiek enkel homegrown promoot. Je wilt zo'n workflow van begin tot eind onder controle hebben.

Wat nou als er een bug in je quilt zit? Of in dch? Of in de taal zelf? Bovendien kan traffic ook onderschept worden. Of wat nou als AWS afspraken met de FBI heeft waar Nederland niks vanaf weet?

[Reactie gewijzigd door Bulkzooi op 22 juli 2024 20:29]

[robertlinke]

Of wat nou als AWS afspraken met de FBI heeft waar Nederland niks vanaf weet?

dan word AWS HELEMAAL afgebrand zodat dit bekend word. sorry, daar branden ze hun vingers niet aan.
behalve de al bestaande wettelijke regels gaan ze dat echt niet doen, dan zijn ze hun hele klantenbestand kwijt.

[Brahiewahiewa]

[...] Dit is de dagelijkse praktijk voor Linux. Ik zit een omgeving waar mensen daadwerkelijk zelf fixes en work-arounds schrijven of aanpassen als de leverancier te lang op zich laat wachten ...

Dan heb je dus de verkeerde keuze gemaakt toen je het OS selecteerde. Althans je beweert nu dat jij eigenlijk niet langer wil wachten tot MS het belieft een patch te publiceren. Lijkt me een professionele inschattingsfout om dan een closed source OS te kiezen

[CAPSLOCK2000]

Dan heb je dus de verkeerde keuze gemaakt toen je het OS selecteerde. Althans je beweert nu dat jij eigenlijk niet langer wil wachten tot MS het belieft een patch te publiceren. Lijkt me een professionele inschattingsfout om dan een closed source OS te kiezen

Ik heb juist heel erg goed gekozen, het misverstand is dat je denkt ik Windows gebruik.

Dat doe ik inderdaad niet, mede om de hier besproken redenen. In mijn ogen is dat OS niet geschikt voor een professionele omgeving maar als je dat zo kaal opschrijft dan levert dat maar flamewars op waar niemand beter wordt.. Daarom geef ik liever mijn argumenten en laat ik mensen zelf hun eigen conclusies trekken.

Het goede nieuws is in ieder geval dat jij terecht concludeert dat Windows niet voor mij is, de boodschap is over gekomen

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 20:29]

[Brahiewahiewa]

[...]

Ik heb juist heel erg goed gekozen, het misverstand is dat je denkt ik Windows gebruik. ...

Touché. Maar dan is de opmerking waarmee je deze discussie begonnen bent, namelijk dat je in dit soort gevallen de source code van Windows wilt hebben, wel behoorlijk overbodig.

...Het goede nieuws is in ieder geval dat jij terecht concludeert dat Windows niet voor mij is, de boodschap is over gekomen

O jee, daar gaat de waarde van mijn aandeeltjes MSFT ;o)

[CAPSLOCK2000]

Touché. Maar dan is de opmerking waarmee je deze discussie begonnen bent, namelijk dat je in dit soort gevallen de source code van Windows wilt hebben, wel behoorlijk overbodig.

Ik maakte een algemene opmerking, niet specifiek over Windows. Ik wil van alle software de source, niet alleen van Windows. Als er (security)bugs in Windows gevonden worden wil ik graag de mogelijkheid hebben om zelf in de source te kijken en een oplossing toe te passen. Niet dat ik dat bij iedere bug daadwerkelijk ga doen, integendeel, maar het is fijn om opties te hebben.

[deadlock2k]

Dit is de dagelijkse praktijk voor Linux.

Het spijt me echt oprecht maar dat betekent simpelweg dat Linux geschikt is voor jouw use case en Windows niet. Niet meer, niet minder, het verhaal voor wat betreft support staat gewoon als een huis en als leverancier zou ik die wildgroei ook niet willen riskeren.

Het is misschien jouw vakgebied, maar kernel patches schrijven is zeer zeker niet het mijne en ik was ook niet van plan om die skill even meester te worden terwijl m'n dagelijkse werkzaamheden dingen met directories, databases en het provisionen van accounts is. Vandaar ook dat ik, net als bij een arts die me een behandeling voorschijft er van uit wil kunnen gaan van dat een fix goed werkt en als 't niet goed werkt dan is daar over het algemeen best wel outcry over.

Maar bovenal dus; je use case is nogal edge voor het overgrote gedeelte van de gebruikers.

[CAPSLOCK2000]

Vandaar ook dat ik, net als bij een arts die me een behandeling voorschijft er van uit wil kunnen gaan van dat een fix goed werkt en als 't niet goed werkt dan is daar over het algemeen best wel outcry over.

Ik vind het een passende vergelijking. Een arts is een hoop opgeleide profesional die zelf in staat is medische situaties in te schatten en oplossingen voor te stellen op grond van kennis van medicijnen, biologie en chemie. Natuurlijk niet in zoveel detail als een specialist die de hele dag niks anders doet maar genoeg om zelfstandig een inschatting te maken.
De huisarts zal je meestal naar specialist sturen maar kan ook besluiten om je naar de spoedeisende hulp te sturen omdat een probleem niet kan wachten tot de specialist tijd heeft.

[inversions]

In een bedrijf omgeving ga je niet zelf afwegen of je zelf een patch kan maken voor iets waar je business veelvuldig gebruik van maakt, zelfs niet met opensource waar je zelf niet actief op ontwikkeld. Dat laat je over aan de leverancier. Een bedrijf die wel doet houd zich niet bezig met hun corebusiness of heeft te veel mensen in dienst die niets beters te doen hebben.

[CAPSLOCK2000]

In een bedrijf omgeving ga je niet zelf afwegen of je zelf een patch kan maken voor iets waar je business veelvuldig gebruik van maakt, zelfs niet met opensource waar je zelf niet actief op ontwikkeld. Dat laat je over aan de leverancier. Een bedrijf die wel doet houd zich niet bezig met hun corebusiness of heeft te veel mensen in dienst die niets beters te doen hebben.

Dit soort denken is waarom er zo veel mis gaat in de wereld. Bedrijven denken dat ze alles kunnen uitbesteden en dan zowel lage prijzen als goede service krijgen. Als klant krijg je geen bijzondere behandeling maar moet je samen met de rest wachten en hopen op een oplossing.
Als je daar op kan wachten dan moet je dat doen maar soms is het beter om opties te hebben.

Een bedrijf die wel doet houd zich niet bezig met hun corebusiness of heeft te veel mensen in dienst die niets beters te doen hebben.

Bedrijven die zich volledig richten op een enkele "corebussiness" maken zichzelf kwetsbaar en afhankelijk. Bij onvoorziene problemen of onwillige leveranciers kun je geen kant op. Je bent steeds afhankelijk van advies en hulp van anderen en die anderen hebben vooral hun eigen belang voorop staan, niet de lange-termijn belangen van jouw organistatie.

Bij de meeste bedrijven komt de echte waarde ook niet uit de core-bussiness, dat zouden ze niet overleven want dat ene product verliest dan alle uniekheid. Alle handel gaat dan naar een ander bedrijf met exact dezelfde core-bussiness tenzij je bereid bent om onder de marktprijs te gaan zitten waarmee je per definitie niet levensvatbaar bent met je ene kernproduct.

Slim gebruik maken van leveranciers en kant-en-klaar producten is prima maar maak niet de vergissing te denken dat je daar helemaal op kan vertrouwen. Om het goed te doen heb je zelf mensen nodig die de situatie begrijpen en verstandige keuzes kunnen maken. Anders ben je speelbal van de leverancier. Natuurlijk verschilt dit ook per onderwerp maar in het algemeen zal je meer kennis nodig hebben hoe dichter je bij je kern komt.

Maar ja, in deze wereld is bijna ieder bedrijf een IT-bedrijf, of ze dat nu zelf beseffen of niet. IT is het belangrijkste productiemiddel en het belangrijkste communicatiemiddel. Vrijwel ieder bedrijf in de wereld heeft enkele gespecialiseerde applicaties in gebruik, de meeste mensen zitten uren per dag achter een computer. Vrijwel ieder product met een stekker heeft een IT-component en vrijwel alles zonder stekker wordt gemaakt met machines met een IT-component.

Als je innovatief wil zijn ben moet je al helemaal zorgen dat je een brede set kennis en vaadigheden in huis hebt en de nodige flexbiliteit. Geen enkele ingehuurde consultant of partner gaat een succesvol nieuw product voor je bedenken.

[inversions]

Ik heb het helemaal niet over uitbesteden. Hoe wel je wel degelijk aangeschafte software hebt uitbesteed. Die heb je immers niet zelf ontwikkeld. het bouwen van je laptops en computers heb je ook uitbesteed. Het is maar waar je de grens trekt. ben zeker geen voorstander van alles uitbesteden, dat is een slechte zaak.

Waar ik het over heb is bezig houden van je corebusiness, daar is IT wel degelijk een onderdeel van. Maar corebusiness houd niet in bugs fixen in software dat je niet zelf hebt ontwikkeld.
Als je bezig bent met innoveren en product ontwikkeling heb je geen tijd om je bezig te houden met software bugs in een office pakket.

[CAPSLOCK2000]

Ik zie het als de lampen op kantoor. Als de lamp stuk is kunnen mensen niet werken. Als je dan 4 weken moet wachten tot de electricien tijd heeft om de lamp te komen vervangen heb je een probleem. Misschien kun je dan beter een concierge in vaste dienst hebben die zelf lampen kan vervangen.
Het is wel niet je core-bussiness maar zonder licht kun je je core-bussiness niet doen.

[Ruud2001]

Zo stond er dit weekend ook een goed stuk in de Volkskrant wat o.a. beschreef dat er steeds meer vaker wordt gedacht dat alles met een contract valt af te dichten.

Er zijn te weinig nerdfluisteraars bij bedrijven en overheden, vindt ict-expert Bert Hubert

[dasiro]

voor heel veel bedrijven is dat de makkelijkste en goedkoopste oplossing, anders had linux of weet ik veel welk ander OS OS al een veel groter marktaandeel gehad.

Wil jouw bedrijf het niet gebruiken (lees als "de eigenaar", niet "het (IT)-personeel"), veel succes dan op je zoektocht en bij het patchen ervan, maar ga niet plots eisen dat een commercieel bedrijf heel zijn business-model omgooit en alle technologie die ze jarenlang hebben ontwikkeld zomaar gratis op straat te grabbel gaat gooien.

[Transferno]

Ik heb geen cijfers van het exacte marktaandeel maar als ik in ons eigen bedrijf kijk gebruiken we voor onze core servers toch vaker linux dan windows, vooral omwille van stabiliteit en security.
Qua office IT is het dan weer vrijwel windows, vooral omwille van gebruiksgemak veronderstel ik.

[Ge Someone]

Uitschakelen lijt mij de snelste en veiligste optie. Heb je ooit Microsoft Support Diagnostic Tool nodig gehad?

[CAPSLOCK2000]

Ik gebruik geen Windows dus ik niet, maar ik begrijp dat je deze tool nodig hebt als je contact zoekt met Support.,

[Yolo]

Ik denk als je graag dit soort risico's wil mitigeren dan heb je natuurlijk al (unsigned) powershell execution geblokkeerd voor al je gebruikers.

[Xantax]

Ja zeker ff de broncode aanpassen
vergeet het maar,bouw dan zelf een OS

[SMD007]

Dit en ook: "Het bedrijf verwees daarbij naar een blogpost waarin het meer informatie geeft. Die is maandag voor het laatst bijgewerkt, maar slechts met meer vragen en antwoorden. Het bedrijf spreekt nog steeds niet over een definitieve oplossing."

Alsof het weken geleden is, maar maandag was gewoon gisteren nog..

[DefaultError]

Bij Apple is zwijgen toch hun stokpaard. Microsoft heeft immers de workaround;-)

[wica]

Uhmmm.. wat is Follina?
/edit
Microsoft Support Diagnostic Tool (MSDT), waarom het zo niet noemen?

[Reactie gewijzigd door wica op 22 juli 2024 20:29]

[TijsZonderH]

Follina is een kwetsbaarheid in de Support Diagnostics Tool die het mogelijk maakt om van een afstand code uit te voeren met rechten van het gebruikte programma

[svenie3000]

Follina is een kwetsbaarheid in de Support Diagnostics Tool die het mogelijk maakt om van een afstand code uit te voeren met rechten van het gebruikte programma.

[ZeromaNoiS]

Onderzoekers geven CVE's met een grote impact soms een naam.... dat bekt beter dan CVE-2022-30190.

[CamelKnight]

Omdat het een bug is in de Microsoft Support Diagnastic Tool. De bug hebben ze Follina genoemd.

[robertlinke]

ik geloof dat de onderzoeker die de kwetsbaarheid gevonden heeft zo heette en dus de naamseer kreeg

[CAPSLOCK2000]

Uhmmm.. wat is Follina?
/edit
Microsoft Support Diagnostic Tool (MSDT), waarom het zo niet noemen?

Het praat makkelijker en voorkomt verwarring als er meerdere bugs zijn. In software die wat langer mee gaat zullen welk vaker bugs gevonden worden. Als we het steeds maar over "die Windows bug" hebben dan zou dat iedere week op iets anders kunnen slaan. Zelfs kritieke security bugs zijn eigenlijk een maandelijks terugkerend ding.

[computerjunky]

Kortom zoals ik het zie is het dus gewoon phishing dat het echte probleem is. De mens blijft ook hier de de falende factor net als bij zoveel van deze beveiliging issues is get alleen een probleem als de gebruiker dus blind op linkjes klikt.

[locke960]

Dat is wat kort door de bocht. Je kunt er niet vanuit gaan dat iedereen de kennis en ervaring heeft om phishing altijd te herkennen EN ook nog op elk moment van elke dag scherp genoeg te zijn om dat foutloos te doen.

Dus ja, je hebt gelijk, bij bijna elk security probleem is de mens de falende factor, maar dat is juist waarom de oplossing niet in de mens en zijn gedrag gezocht moet worden.

edit: In dit geval: je hebt maar 1 persoon in je organisatie van 100.000 mensen nodig die een foutje maakt, en je hebt een worm die andere office documenten op je netwerk gaat besmetten die andere mensen dan weer volledig ter goeder trouw openen. etc.

[Reactie gewijzigd door locke960 op 22 juli 2024 20:29]

[computerjunky]

Het ergert mij tot op het bot dat na 25 jaar email mensen nog steeds niet in staat zijn een statusbalk in een e-mail client te lezen als je met je muis overeen link staat. Als je je dat je medewerker al niet kan leren dat moeten ze denk ik gewoon wat anders gaan doen want dat is echt super basis.

Er lijkt echter na al die gevallen en vele jaren nog altijd geen enkele educatie hiertoe te zijn terwijl een basis cursus phishing herkennen nog geen half uur hoeft te duren.

[Mangu429]

Velen gebruiken email pas kort en geen 25 jaar, dus dat aantal jaar vermelden is onzinnig.

Je kunt beter voorkomen dat zo'n handeling nodig is.

[locke960]

Ik begrijp die ergernis echt wel hoor, ik ken hem ook
Maar ik zie die statusbalken ook elke dag. En ik zie ook die rood op gele tekst "Dit is een mailtje van buiten, pas op met attachments" die door ons mailsysteem behulpzaam aan ELK extern mailtje IN de tekst wordt toegevoegd.

Allemaal op/in mailtjes van externe partijen waar ik veel mee te maken heb, en die mij regelmatig een office bestand sturen. Ik ben er dus blind voor geworden. In het best geval is het ruis.

Wat moet ik doen als ik van een dergelijke partij een goed uitziend mailtje krijg met een attachment?
Het zou zomaar kunnen zijn dat hij besmet is en dat de worm zelf een mailtje heeft gestuurd vanuit zijn outlook. Moet ik nu altijd even bellen om zeker te zijn, voor het geval hij een fout heeft gemaakt en besmet is?

De feiten spreken voor zich: Mensen zijn dom. Als jij vandaag niet dom bent, dan ben ik het morgen wel. Organisaties en producten die dat niet erkennen zijn zelf nog dommer en een onderdeel van het probleem. Organisaties en producten kun je namelijk veranderen, mensen niet.

[trisje]

Hier versturen ze test phishing mails om gebruikers te leren dit soort mails te herkennen, zit hier ook in de IT, er zijn er maar een paar die weten van de test en ik moet zeggen dat sommige mailtjes echt wel moeilijk te herkennen zijn. uit ervaring herken ik ze dan wel en de meeste gebruikers hier ook wel. maar er zijn er nog altijd 2-4 % die op de link klikken.

[latka]

Nope, preview is al genoeg.

[GekkePrutser]

Overigens: De reden dat er niet voor 'responsible disclosure' is gegaan (waarbij de leverancier de tijd krijgt een patch te maken voor het bekend gemaakt wordt) was omdat deze zero-day al uitgebreid in het wild werd gebruikt.

Ook had de auteur het wel in April al gemeld aan Microsoft maar hun security team vond dat het geen security issue was. Kan me voorstellen dat je er dan gauw genoeg van hebt. Bron

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 20:29]

[useruser]

Die ervaring hebben meer mensen. Ms zegt vaak, als je user interactie nodig hebt is het niet belangrijk. Wat in praktijk heel anders uitpakt.

[GekkePrutser]

Ja en in dit geval is er in sommige gevallen zelfs geen interactie nodig (bijv. bij RTF files)

Update: Microsoft have indeed pointed to Protected View, saying it “prevent” the attack. I think this is stretching the truth — for example, if the document is a .RTF file and is opened Preview in Explorer, Protected View doesn’t apply and it becomes a zero click exploit. Microsoft know this, they just aren’t mentioning it to customers.

Je schijnt het niet eens te hoeven openen, de explorer preview is genoeg:

Protected View does kick in, although if you change the document to RTF form, it runs without even opening the document (via the preview tab in Explorer) let alone Protected View.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 20:29]

[nutty]

Iedereen die nu nog op phishingmail klikt zonder toestemming van de ict beheerder moet gewoon worden ontslagen.

[Mangu429]

En als ze het met toestemming doen?

[aikebah]

Dan krijgt de ict-beheerder die toestemming gaf een 'functie elders'.

[Marctraider]

Het gevaarlijkste is nog altijd mensen die zomaar ergens op klikken. Ik zie het nog zo vaak gebeuren, en dan niet alleen mensen van de oudere generatie.

[trisje]

Eerlijk gezegt zou het ergens op klikken helemaal niet zo probleem moeten zijn. Als je geen admin rechten hebt en bepaalde dingen niet uit zet. worden die verkeerde links wel gestopt door het besturings systeem of de virus scanner. immers als je over het internet surft, in google zoekt, klik je de heletijd op links.
Een goed belijd in een bedrijf met voorbeeld acties als het versturen van nep phishing mails naar het personeel en ze naar een waarschuwing pagina te sturen met uit na een klik op een link, helpt wel, maar je ziet iedere keer weer dat 2 tot 4 % toch op de link klikt.

[HKLM_]

Online gaat de naam Protocol Nightmare rond aangezien CVE-2022-30190 niet de enige is. Met de HKEY_CLASSES_ROOT\search-ms kan je namelijk ook vanuit een word document code uitvoeren maar microsoft weigert deze momenteel in het security center van defender te zetten of verder op te pakken.

[Reactie gewijzigd door HKLM_ op 22 juli 2024 20:29]

[BleghBlarg]

Is het nog wel een zero-day als hij al best wel publiekelijk bekend is?

[Cobalt]

Kan er zo snel niks over vinden in de issues https://github.com/PowerShell/PowerShell . Misschien moeten de vinders van de bug even een issue aanmaken?

[bartje]

Dat doe je normaal niet in openbaar bij security bugs. Die houdt je netjes 90dagen onder de radar om de fabrikant de mogelijkheid te geven deze te fixen.

[CodeCaster]

Het is dan ook geen bug in PowerShell, maar in de hulptool.

PS wordt slechts gebruikt om informatie over de computer te verzamelen en te uploaden naar een machine van de aanvaller.