Ligt het aan mij, of is het de meest stom gekozen naam die ze konden verzinnen?

Het is natuurlijk altijd mogelijk dat het specifiek die naam moest zijn om het probleem op te lossen...

Begrijp ik nu goed dat een directory die bij IIS hoort op systemen die helemaal geen IIS bevatten wordt aangemaakt als onderdeel van een beveiligingsupdate en niet moet worden verwijderd omdat de bescherming van je systeem ervan afhangt?

Dat klinkt alsof er dingen met elkaar verweven zijn die niets met elkaar te maken zouden moeten hebben.

En als je de map al verwijderd hebt? Is deze terug te halen?

Jammer voor Microsoft maar hun uitleg zoals nu gegeven is onzin. Als de aanval vector local is dan kan die folder net zo goed dus niet aangemaakt worden. Sterker nog ik zou juist een IDS alert zetten op die folder als *wel* getracht wordt deze aan te maken en de actie blokkeren.

Los daarvan zou ik hem verwijderen en zelf opnieuw aanmaken als je hun advies vertrouwt om het daarna immutable te maken als folder. Maar het aanmaken van lege folders is simpelweg geen goede security practice dit is een amateuristisch lapmiddel voor een Process Activation Elevation die niet had mogen gebeuren in the first place.

Lege folder strategie pas je toe als je iets wilt saboteren als service. Zo saboteer ik mijn browser achtergrond update service omdat het niet tmp kan wegschrijven in bepaalde folder en dus ook geen updates kan deployen zonder dat ik er van weet. Daar is het nuttig voor maar een OS maker hoort gewoon de boel op een nette manier op te lossen niet met een lapmiddel.

Als er een goede reden is laat ze het maar uitleggen het antwoord trust us is *geen* accepteerbaar antwoord.

Dit is natuurlijk van de zotte!! Wat een ongelooflijk slecht besturingssysteem. Nu wist ik al dat je er niks met huid en haar uitkrijgt. Er blijft altijd wel wat in het register achter maar dit slaat werkelijk alles.

Windows is altijd al troep geweest.
Zelfs DOS toendertijd.

Weet u nog... de beruchte foutmelding van DOS:
"Keboard not found
Press any key to continue"

Ja inderdaad en die “any key” was bovendien nergens te vinden want die zat er gewoon niet op.

Dat is weer zo'n volkomen legitieme vraag waarop je hier, maar ook bij Microsoft zeer waarschijnlijk nooit een effectief antwoord zult krijgen of anders - indien wel - een antwoord dat niet effectief zal blijken te zijn, let wel: ook weer vermoedelijk niet.

Een voorbeeld dat zich bij mij voordeed.

Zo'n 7 jaar geleden gebruikte ik op een van mijn computers Windows 8.1 naar volle tevredenheid.
Het is te lang terug in de tijd en ook vanwege het feit dat ik nu alleen nog Linux als actief OS gebruik ben ik de exacte details vergeten, maar op zeker moment was in een patch pakket een fout geslopen in de volgorde waarin onderdelen moesten worden geïnstalleerd.(*)
Een specifieke update was van belang om als eerste te worden geïnstalleerd om toekomstig nog updates aangeboden te krijgen. Microsoft was hiermee in de fout gegaan.

Na lang zoeken vond ik een pagina op support Microsoft (niet gedacht dat die toch nog tussen m'n bladwijzers zat.)....
https://support.microsoft.com/nl-nl/windows/problemen-met-het-bijwerken-van-windows-oplossen-188c2b0f-10a7-d72f-65b8-32d177eb136c

Ik ga nu niet meer uitzoeken welke tool ik indertijd heb gebruikt want het is voor mij niet meer toepasselijk, maar het was een zeer landurige procedure die ik 's-nachts startte. 'S-ochtends vond ik de computer in de staat "Herstart de computer om de bewerkingen uit te voeren" o.i.d. Ik had goede hoop!
Maar....
Een volgende melding m.b.t. Patch Tuesday heb ik niet/nooit meer gezien... De Microsoft fout was persistent. Dus met 'dank' aan het Microsoft WUS broddelwerk was mijn tot dan fijn werkende Win 8.1 naar de gallemiesen geholpen.

(* AskWoody https://www.askwoody.com/ heeft aan deze miskleun van Microsoft indertijd nog aandacht besteed.)

---------------------------------------------------------------

Toegevoegd:

Ik zie dat de betreffende Microsoft pagina is aangepast voor Win10 en 11.
Misschien is hierop een antwoord te vinden voor het huidige probleem.

Succes!

Nogmaals voor andere geïnteresseerden dan Anoniem, 11-04, 19:32uur:

Misschien biedt deze pagina antwoorden:
https://support.microsoft.com/nl-nl/windows/problemen-met-het-bijwerken-van-windows-oplossen-188c2b0f-10a7-d72f-65b8-32d177eb136c

We hebben nog geluk dat Microsoft de directory niet PipoDeClown heeft genoemd.
Dan zat je voor altijd met een Windows circus systeem.

Vermoedelijk, indien mogelijk, de patch verwijderen en handmatig opnieuw installeren.

Of mogelijk afkijken van een andere computer waar die folder wel bestaat hoe die folder en inhoud ingesteld zijn qua (hidden/system) files, rights en (extended) attributes, om die vervolgens over te brengen naar de handgemaakte inetpub folder.

Let wel, extended atrributes worden niet door ieder backup of copy programma meegenomen omdat die in de MFT zitten.

Dan is er nog ADS waarmee je bestanden (ook executables) in bestanden kunt verstoppen (echo TEST > test.txt:test2.txt).
Overigens een manier om je antivirus te testen, stop een EICAR in een ADS en kijk wat er gebeurd.
Met onderstaande oneliner kun je die vinden, maar mogelijk niet allemaal (er zijn betere programma's te vinden).

for /r %F in (.) do @(pushd "%F"&&(for /f "tokens=1*" %A in ('dir /r^|findstr /el :$DATA') do @if .%~zB neq . echo %A %~fB)&popd)2>nul

(als security professional ga je bovenstaande eerst onafhankelijk controleren op validiteit en dergelijke natuurlijk, op een isolated burner system uiteraard)

Een zoekopdracht (met total commander) leverde mij daarnaast 4 bestanden en 3 directories op in de krochten van \ProgramData, \Users en ..\WinSxS

Malware moet onzichtbaar zijn voor virusscanners. Maar malware moet voorkomen dat het zichzelf dubbel installeert op een systeem.

De inetpub map kan gebruikt worden door een zero day om aan te geven dat de computer al besmet is en dat dit niet opnieuw hoeft te gebeuren.

Je bent behoorlijk eigenwijs als je mappen gaat verwijderen waarvan Microsoft aangeeft dat dat slecht is voor je beveiliging. De map kan een mitigation zijn! Blijf er af.

Ja en op start klikken in het menu om te stoppen

Voor windows heb je toch geen CLI nodig!

Dit laat wel zo'n beetje het failliete patchsysteem zien van dit vreselijk slecht te onderhouden marketing OS. Een update service geïnstalleerd door een applicatie omdat het microsoft update mechanisme alleen windows update en dan nog gaat het regelmatig mis dus lezen we hier. Ik zag dat ook al eens met Adobe en zelfs Libreoffice voor windows.
Het argument windows is veel gebruiksvriendelijke horen we ook al een tijdje niet meer. Linux is tegenwoordig gebruiksvriendelijker in alle opzichten.

Ik kreeg de map heel simpel terug door de aanwijzingen onderaan deze pagina te volgen:
https://www.bleepingcomputer.com/news/security/microsoft-windows-inetpub-folder-created-by-security-fix-dont-delete/

je start de afsluitprocedure.

Als Certified Microsoft Engineer zeg ik, weg met Windows. Een grote bak met rommel aan elkaar geplakte code.

Doe ff normaal Microsoft moet er met zijn poten van af blijven. Hier slaan alle IDS op tilt omdat de directory structuur is veranderd en niet door ons!

Dat dus.


Het antwoord van Microsoft is stupide tot en met. En ja dat eigenwijs zijn dat komt door decenia aan ervaring met de systemen. Dit is niet hoe je mitigation doet en het is ook niet wat een gewoonte mag worden.

Ik en menig ander verwijder wel meer dan enkel mappen ik sloop alles eruit dat niet nodig is voor de infra om te gebruiken. Printer drivers in een printloze omgeving? Eruit. microfoon camera ondersteuning waar niet nodig? Eruit. Achtergrond telemetrie dat zo stupide is opgezet dat het piggybacked over andere services? Eruit. En laat wel wezen dit gebeurt ook bij Linux achtige systemen. Je donderd alles eruit dat je niet gebruikt. Dat heet attack surface verkleinen. Het toevoegen van mappen is *niet* attack surface verkleinen.

Dus nee we blijven er niet van af het heeft niks te zoeken op onze infra. En gezien Microsoft niet wil zeggen waarom deze stupide methode nodig is wens ik ze veel succes met ITers overtuigen dat wat hun zeggen enige waarde heeft.

Dan is dat ten eerste malware die geen systemen wil besmetten waarop IIS is geïnstalleerd, want dan is die map er ook, en ten tweede zou ik het nogal verrassend vinden als malware die zichzelf zo goed verbergt dat het zelf niet meer op een directere manier kan zien of het al op systeem staat. Zo'n in het oog lopende map is dan geen handig controlemechanisme, je verbergt jezelf niet goed door luidkeels "hier is iets geks aan de hand!" te roepen en zo juist aandacht te trekken.

De kwetsbaarheid die het security bulletin noemt is "CWE-59: Improper Link Resolution Before File Access ('Link Following')". Een applicatie benadert een bestand of map op filenaam zonder te controleren of dat een link is naar iets dat niet de bedoeling is, afgaande op de beschrijving waarnaar CWE-59 linkt bij Mitre.

Je zou denken dat de oplossing dan is om in de betreffende applicatie die ontbrekende controle in te bouwen. Dat is duidelijk niet hoe dit is opgelost, wat suggereert dat dit niet meer dan een tijdelijke workaround is tot een betere oplossing gereed is. Dat men de inetpub-map heeft aangemaakt, die bij IIS hoort, suggereert dat IIS de applicatie is waar het om gaat. Het moet kennelijk specifiek systemen beschermen waarop IIS nog niet geïnstalleerd is, want als IIS al geïnstalleerd is dan is die map er al en doet deze workaround voor zover ik zie helemaal niets. Dan is de gedachte die bij mij opkomt dat de kwetsbaarheid in het installatieproces van IIS zit en inhoudt dat die bij installatie een bestaande inetpub-map accepteert zonder te controleren of dat een link is en of de rechten op de doelmap wel kloppen. Dat zou een aanvaller in staat stellen om bij een nieuwe IIS-installatie bij voorbaat controle over de aangemaakte website of websites te bemachtigen.

Laat me heel duidelijk zijn: dit is een gedachtegang op basis van heel weinig informatie en veel te weinig kennis; ik weet echt niet of ik gelijk heb. Er kunnen andere scenario's zijn waar ik domweg niet aan denk omdat ik er niet genoeg van weet.

Lees het artikel nog eens goed. Microsoft voegde de informatie pas toe aan het security bulletin nadat mensen er online vragen over gingen stellen, en toen hadden er al de nodige mensen die map verwijderd. Hier heeft Microsoft een steekje laten vallen in de communicatie erover.

je start de afsluitprocedure.[/quote]
Prima opgemerkt daarmee geef je aan dat het stoppen van het systeem een op zich staand proces is.
Dat is voor velen veel te moeilijk om te snappen die blijven liever in het oppervlakkige geschreeuw hangen.


Het onbegrijpelijke met de slechte kwaliteit van IOT en de zwakheden van de smarthpone worden ineens heel begrijpelijk.


Als je updates zonder controle of zonder te weten wat je doet klakkeloos uitvoert is dat het probleem, niet dat veranderd omdat er vanuit de leverancier een gegronde reden voor is. Je hebt een ander leveranciersprobleem, namelijk de betreffende IDS waar je zonder inzicht op acteert.

<snikkend van het lachen> Een Certified Microsoft Engineer bestaat niet eens, je lult uit je nekharen. Ik ben MCSE, maar jij weet vast niet waar dat een afkorting voor is. FYI: ik ben beheerder bij een bedrijf met 1200+ werkstations en servers, waaronder een flink aantal Unix apparaten, draait als een zonnetje.