Wormable Windows HTTP Hole – Vad du behöver veta – Naken Security

Wormable Windows HTTP Hole – Vad du behöver veta – Naken Security

Igår var den första patchtisdagen 2022, där över 100 säkerhetsbuggar fixades.

Vi skrev en översikt över uppdateringen, som vi gör varje månad, på vår systersajt news.sophos.com: Första patch tisdag 2022 102 Bug Repair,

På gott och ont har en uppdatering fått mer uppmärksamhet i media än någon annan, nämligen CVE-2022-21907, mer fullständigt. kallas Fjärrkörningsproblem för HTTP-protokollstack för exekvering av kod,

Felet var ett av sju säkerhetshål som rapporterades den här månaden som kan leda till fjärrkörning av kod (RCE), den typ av bugg som innebär att någon utanför ditt nätverk kan komma åt en dator i ditt nätverk utan att först fråga om tillstånd. Den här typen av program kan luras att köra.

Inget behov av att logga in i förväg; Inga popup-varningar i andra änden; Nej Är du säker (J/N)? frågor.

Ge bara kommandot och skadlig programvara körs.

Det är principen i alla fall.

RCE-bugg anses vara oroande

En sak att komma ihåg om de flesta RCE-sårbarheter är att om du kan attackera någon annans dator från utsidan och instruera dem att köra ett skadligt program som du väljer…

… så det är möjligt, kanske till och med möjligt, att du kan säga åt den att köra samma program som du använde för att starta din egen attack.

Med andra ord, du kanske kan använda sårbarheten för att lokalisera och infektera Victim 1 med det skadliga programmet W som instruerar Victim 1 att lokalisera och infektera Victim 2 med det skadliga programmet W som instruerar Victim 2 att lokalisera Victim 3… och så vidare , kanske till och med i det oändliga.

I denna typ av attack ger vi programmet ett speciellt namn: vi kallar det en ,

maskar utgör en lämplig delmängd av en typ av skadlig programvara (eller kort sagt) som är allmänt känd som en bred term för självreplikerande skadlig programvara av något slag.

Detta betyder att de flesta RCE-buggar åtminstone i teorin kommer att , vilket innebär att de potentiellt kan utnyttjas för att lansera en rad automatiska, självförökande och självförsörjande malwareinfektioner.

Logiken här är tydlig: om en RCE-bugg låter dig köra valfritt program på någon annans dator, till exempel Pop Up CALC.EXE eller start av NOTEPAD, så kommer det nästan säkert att ge dig en . gör det möjligt att köra valfritt program, såsom mask.

Vissa buggar är värre än andra

Som du kan föreställa dig anses vissa klasser av RCE-buggar vara mycket mer oroande än andra, speciellt buggar som kan utlösas direkt genom en enkel nätverksinteraktion.

Nyligen var det en risk för stor oro i Log4Shell Saga, där en booby-fälld webbförfrågan med lite nyfiken men annars oemotståndlig ASCII-text kan utlösa godtycklig fjärrkörning av kod.

Tyvärr är CVE-2022-21907 en bugg i samma kategori som Microsofts egen säkerhetsbulletin I sin FAQ-sektion som tydligt säger följande:


*How could an attacker exploit this vulnerability?*

In most situations, an unauthenticated attacker could send a specially crafted packet to a targeted server utilizing the HTTP Protocol Stack (HTTP.sys) to process packets.

*Is this wormable?*

Yes. Microsoft recommends prioritizing the patching of affected servers.

Har det något med IIS att göra?

var och hur blir man aktiv?

Är detta ett problem som är unikt för Windows Server, som Microsofts bulletin antyder när det gäller att patcha “berörda servrar”?

Huruvida attacken är tillgänglig beror på om du har en känd webbserver som Microsoft IIS () redan installerad och aktiverad?

Svaren på dessa frågor är följande:

HTTP.sys är en del av Windows och är tillgänglig för alla program som använder ASP.NET. HTTP.sys fungerar på Windows 7-klienten Och senare. HTTP.sys fungerar på Windows 2008 R2 Server Och senare. HTTP.sys är inte en del av IIS, Och IIS behöver inte vara installerat.

Den sista punkten ovan gör det klart att du kan ha flera appar i bruk – kanske utan att inse det – som tillhandahåller ett HTTP-baserat gränssnitt via HTTP.sys, oavsett om du har distribuerat IIS eller inte.

Faktum är att Microsofts egen dokumentation noterar det

Egentligen är IIS baserat på HTTP.sys, inte tvärtom, som Microsoft säger:

HTTP.sys är en mogen teknologi som skyddar mot många typer av attacker och ger robustheten, säkerheten och skalbarheten hos en fullfjädrad webbserver. IIS själv körs som en HTTP-lyssnare ovanpå HTTP.sys.

Enkelt uttryckt: I teorin kan du till och med installera appar på en stationär eller bärbar dator, vilket ger något slags webbaserat gränssnitt som betjänas av HTTP.sys-drivrutinkoden.

Silverfodret, åtminstone för vissa användare, är den del av HTTP.sys som innehåller CVE-2022-21907-felet:

Påverkar endast Windows 10 och senare skrivbordsversion. Påverkar endast Windows Server 2019 och senare Server Edition. inte aktiverat som standard På Windows Server 2019. Kan immuniseras mot denna bugg Helt enkelt genom att installera uppdateringen för januari 2022 Patch Tuesday.

Såvitt vi kan se är anledningen till att denna sårbarhet inte existerade i tidigare versioner av Windows och Windows Server att felet hittades i kod som hanterar HTTP-trailers (dessa är som HTTP-rubriker, förutom att de skickas) efter HTTP-data istället för före den); HTTP Trailer-stöd lades till först efter att HTTP/2 stöddes; Och HTTP/2-stöd kom bara i en tid präglad av Windows 10.

Vad ska man göra?

Om du inte kan patcha omedelbart och om du vet att du inte kör (eller åtminstone inte tänker köra) någon webbaserad programvara som använder HTTP.sys, kan du tillfälligt blockera HTTP.sys på din dator. Genom att ställa in följande registerpost:


HKLMSYSTEMCurrentControlSetServiceHTTPStart = DWORD(4)

Det typiska värdet för denna registerpost är 3, vilket indikerar , Om du ändrar värdet till 4 markerar föraren som ,

Efter omstart kan du kontrollera statusen för HTTP.sys från den vanliga kommandotolken SC (Service Control) Orders:


C:Usersduck> sc query HTTP
SERVICE_NAME: HTTP 
   TYPE               : 1  KERNEL_DRIVER  
   STATE              : 1  STOPPED    <--before applying the registry hack above, this line said: "4 RUNNING"
   WIN32_EXIT_CODE    : 1077  (0x435)
   SERVICE_EXIT_CODE  : 0  (0x0)
   CHECKPOINT         : 0x0
   WAIT_HINT          : 0x0
C:Usersduck>

Observera att vi endast har testat den här lösningen för de mest översiktliga syften. Vi installerade Server 2022, aktiverade IIS, skapade en hemsida och verifierade från en annan dator att det fungerade. Som nämnts ovan ändrade vi tjänstens startvärde för HTTP till 4 och startade om. Vår IIS-server var inte längre tillgänglig. Vi återställde registerposten till 3, startade om en gång till och verifierade att IIS automatiskt kom till liv igen. Av detta drar vi slutsatsen att inaktivering av HTTP-tjänsten faktiskt blockerar HTTP-baserad nätverksåtkomst till programvara på högre nivå som annars skulle kunna utsättas för denna bugg, och vi tror att detta tillfälligt kan åtgärda sårbarheten.” Outlösbar”.

Våra primära rekommendationer är:

Antag att alla RCE-sårbarheter är oroande. Som nämnts kan buggar triggas direkt via en vanlig nätverksanslutning, vilket är den största risken för att “spoila”, men i princip vilken bugg som helst som tillåter godtycklig fjärrkörning av kod Ja, masken kan tillåta kodexekvering. Låt oss bara säga att cyberbrottslingar redan aktivt gräver i detta och alla andra RCE-vulns tillkännagav denna patch på tisdagen. Du har säkert hört skämtet om Exploit Wednesday efter Patch Tuesday. Det finns också en touch av sanning i detta, med tanke på att även patchar med sluten källkod ofta kan rullas tillbaka – , på jargong – för att avslöja de interna detaljerna om buggen de förhindrar. (Och se punkt 1.) Plåster tidigt, lappar ofta. Använd inte lösningen som en vanlig del av din patchprocess för att köpa extra tid då och då. Patch utanför preferenser och ha lösningar för situationer där du verkligen behöver skjuta upp patchningen ett tag. (Och se punkterna 1 och 2.)

Dröj inte… gör det idag!

Läs mer om januari 2022 Patch Tuesday