Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 55 reacties

Het Internet Storm Center heeft de alarmfase voor de internetveiligheid opgehoogd naar geel nu de organisatie op grote schaal misbruik ziet van een kritiek lek in de Windows-component http.sys. Microsoft heeft het lek gedicht, maar het gat wordt nu gebruikt voor ddos-aanvallen.

Volgens het Internet Storm Center zijn er 'internetbreed' netwerkscans en exploits gesignaleerd die zoeken naar kwetsbare webservers die de kwetsbaarheid in http.sys nog niet gepatcht hebben. De servers die IIS-webserversoftware draaien bovenop Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1 en Windows Server 2012 R2 kunnen zo slachtoffer worden van ddos-aanvallen.

Een schatting van beveiligingsbedrijf Netcraft komt uit op potentieel 70 miljoen websites die kwetsbaar zijn op circa 900.000 servers. Mede om deze reden en het feit dat er steeds meer scans en exploits worden gesignaleerd, heeft het Internet Storm Center de alarmfase verhoogd naar geel. Daarmee geeft de organisatie aan dat het om een gevaarlijk beveiligingsprobleem gaat waarvan de precieze gevolgen nog onbekend zijn.

Microsoft bracht eerder deze week een patch uit om het veiligheidslek te dichten. Ook stelde de softwaregigant dat het lek in http.sys in bepaalde gevallen misbruikt kan worden om een systeem over te nemen door een aangepaste http-request te versturen. Naast het patchen van Windows kan ook het caching-mechanisme van IIS tijdelijk uitgeschakeld worden maar dit heeft prestatieverlies tot gevolg.

Moderatie-faq Wijzig weergave

Reacties (55)

Als je wilt testen of je systeem vatbaar is kan je het volgende commando gebruiken:

wget -O /dev/null --header="Range: 0-18446744073709551615" http://[ip address]/

If the server responds with "Requested Header Range Not Satisfiable", then you may be vulnerable.

Met deze exploit is het trouwens ook mogelijk om systemen een bluescreen te geven, dus updaten kan zeker geen kwaad.
Wat vul ik exact in bij [ip address]? Remote of lokaal?
Maakt niet uit; het probleem zit 'm in de afhandeling van een "Range:...." header waarbij het "to" argument in de range (het getal 18446744073709551615 in de bovenstaande post) een buffer-overflow veroorzaakt (met potentieel kwalijke gevolgen; deze nieuwspost over DDOSen is er één mogelijke uitkomst van maar het kan nog wel kwalijker). Of je IIS (of andere services die http.sys gebruiken zoals self-hosted OWIN/Katana WebAPI's bijv.) nou lokaal of remote die header stuurt maakt geen kont uit.

Hier en/of hier een POC "exploit" welke enkel aantoont of je vulnerable bent of niet (naast voorgenoemde manieren).

[Reactie gewijzigd door RobIII op 16 april 2015 21:32]

Er is twijfel aan de tot nu toe gebruikte testmethode, zie: http://blog.erratasec.com...canning-for-ms15-034.html - wat is zo snel lees is dat alleen statische content op deze manier kwetsbaar is, dynamische content niet.

"I suspect the biggest reason is that the "Range" header only is parsed when there is a static file being served. If a script generates the page, then it'll ignore the range. I also suspect that virtual-hosting gets in the way -- that unless the correct DNS name is provided, then it'll reject the request.

Thus, the testing is inconclusive. While I can find some vulnerable responses, just because a server gives me some other response doesn't mean it's not also vulnerable. Thus, I can't really say anything about the extent of the vulnerability."
Hmmm, interessant. That kind of makes sense. Ik zal eens kijken of ik daar wat van kan reproduceren en/of uitsluiten.

Edit: Op een IIS6 bak heb ik 't (nog) niet voor elkaar gekregen om de "not satisfyable" te krijgen; noch op static files, noch op dynamic content:
Robs-MacBook-Air:~ rob$ telnet ******.nl 80
Trying **.**.**.**...
Connected to ******.nl.
Escape character is '^]'.
GET /img/test.png HTTP/1.1
Host: ******.nl
Range: bytes=0-18446744073709551615

HTTP/1.1 206 Partial Content
Cache-Control: max-age=3600
Content-Length: 1015
Content-Type: image/png
Content-Range: bytes 0-1014/1015
Last-Modified: Mon, 09 Jun 2008 21:34:46 GMT
Accept-Ranges: bytes
ETag: "8fdf57a378cac81:10200"
Server: Microsoft-IIS/6.0
Date: Thu, 16 Apr 2015 23:00:46 GMT
OWIN heb ik (nog) niet zo ver gekregen noch static noch dynamic:
Robs-MacBook-Air:~ rob$ telnet ******.** 80
Trying **.**.**.**...
Connected to ******.**.
Escape character is '^]'.
GET / HTTP/1.1
Host: ******.**
Range: bytes=0-18446744073709551615

HTTP/1.1 200 OK
Content-Length: 23
Content-Type: text/plain; charset=utf-8
Server: Microsoft-HTTPAPI/1.0
Date: Thu, 16 Apr 2015 23:12:05 GMT
IIS8.5 static én dynamic wel vulnerable (zonder patch):
telnet ******.** 80


GET / HTTP/1.1
Host: *****.**
Range: bytes=0-18446744073709551615

HTTP/1.1 416 Requested Range Not Satisfiable
Content-Type: text/html
Last-Modified: Wed, 05 Nov 2014 19:48:50 GMT
Accept-Ranges: bytes
ETag: "4f65638531f9cf1:0"
Server: Microsoft-IIS/8.5
X-Powered-By: ASP.NET
Date: Thu, 16 Apr 2015 23:55:06 GMT
Content-Length: 362
Content-Range: bytes */701

[Reactie gewijzigd door RobIII op 17 april 2015 01:57]

IIS6 heeft geen Kernel Mode Caching. Pas vanaf IIS 7 zit dit er in.

Zie ook: Devster in 'nieuws: Internet Storm Center signaleert actief misbruik van lek in http.sys'

En: https://twitter.com/riyazwalikar/status/588337045270962176
"Kernel mode caching needs to be enabled and request has to be made to a file that is cacheable."
IIS6 heeft geen Kernel Mode Caching.
Dat klopt, echter:
IIS 6.0 uses HTTP.sys, which is part of the networking subsystem of the Windows operating system, as a core component.
MS heeft 't inderdaad over kernel-mode caching, maar dat kan natuurlijk ook "preliminary" zijn totdat blijkt dat het niet alleen door kernel-mode caching mis gaat maar ook door X, Y of Z. De workaround (disable kernel-mode caching) die MS aandraagt suggereert idd dat dit de oorzaak zou zijn, maar meten = weten denk ik dan maar ;) Ik ben nog even aan 't kijken of ik bij een IIS7/8/8.5 bakkie kan komen. Helaas ligt internet er hier uit en mis ik een aantal VPN tunnels en zit ik tethered op een iPhone te posten :X Het is effe behelpen dus 8)7
Het verschil is dat vanaf IIS7 er Output Caching is, juist voor dynamische content: http://blogs.iis.net/bill...-asp-and-php-applications

Mijn eerdere aanname dat alleen statische content geraakt wordt, is dus niet juist. Het gaat om cacheable content via Output Caching in Kernel mode.
Het verschil is dat vanaf IIS7 er Output Caching is, juist voor dynamische content: http://blogs.iis.net/bill...-asp-and-php-applications
Dat is me duidelijk, maar mogelijk (ondanks MS's (voorlopige?) conclusies) zit 't probleem niet zo zeer in de caching maar al in 't parsen van de Range-header (wat, logischerwijs, waarschijnlijk alleen gebeurt bij requests waar ranges überhaupt nut hebben). Maar als ik toch aan 't testen ben kan ik dus net zo goed even een IIS6 bakkie meenemen en 't zekere voor 't onzekere nemen ;)
(Ik heb overigens nog nergens van niemand gelezen dat IIS <7 vulnerable zou zijn... maar ik vertrouw 't niet helemaal :P )
Mijn eerdere aanname dat alleen statische content geraakt wordt, is dus niet juist. Het gaat om cacheable content via Output Caching in Kernel mode.
Daar waar ik, tot nu toe, static content getest heb is dat ook daadwerkelijk cachable content dmv Output Caching (geweest).

[Reactie gewijzigd door RobIII op 17 april 2015 01:58]

Alle PoC's die ik tot nu toe heb gezien zijn gebaseerd op static content.
Ehmm ik krijg dit:

HTTP request sent, awaiting response... 200 OK
Length: 2183 (2.1K) [text/html]
Saving to: '/dev/null'

/dev/null 100%[=====================>] 2.13K --.-KB/s in 0s

2015-04-16 21:22:19 (575 MB/s) - '/dev/null' saved [2183/2183]

Is dat goed?
Dat weet je dus niet, omdat de Range header alleen geparsed wordt als er een statische file wordt uitgevraagd. Bij dynamische content doet de opgegeven range niets.
Grootste probleem is dat deze vuln mensen in staat stelt de server over te namen door remote code execution. Patchen dus!!!
nanoChip, is het ook mogelijk dat de test die jij omschrijft een kwetsbaar systeem laat crashen?
Zet dan even het KB nummer erbij, dat zoekt wat makkelijker aangezien Windows Update alles in KB aanduidt.
- KB3042553
Kennelijk heb ik het nog niet geupdate, ik ben 1 van de 900.000.
Maar even snel doen dan.
KB nummers zijn niet zo boeiend, je hebt meer aan 't MS nummer: MS15-034 en/of de CVE (CVE-2015-1635). De fixes zijn inderdaad te downloaden op KB3042553.

[Reactie gewijzigd door RobIII op 16 april 2015 20:38]

Open eens Windows Update en kijk eens wat er achter elke regel tussen haakjes staat.
Als je Windows update opent zie je niets, wel als je daarna je updategeschiedenis laat zien.
Het KB nummer staat vóór de omschrijving beveiligingsupdate in je updategeschiedenis, niet erachter (in 8.1 iig)(en is vandaag al geïnstalleerd als je automatisch updaten aan hebt.)
Dat kan, AFAIK, per Windows versie verschillen (dus dat de Windows 2008 patch een ander KB nummer krijgt dan de Windows 2012 patch bijvoorbeeld). Dat is hier niet aan de orde though.

[Reactie gewijzigd door RobIII op 16 april 2015 20:43]

Koffiekan, theekan, waterkan.
Maar als je die pagina even leest zie je zo exact welk OS het gaat en hoef je hier niet te speculeren:
Applies to
•Windows Server 2012 R2 Datacenter
•Windows Server 2012 R2 Standard
•Windows Server 2012 R2 Essentials
•Windows Server 2012 R2 Foundation
•Windows 8.1 Enterprise
•Windows 8.1 Pro
•Windows 8.1
•Windows RT 8.1
•Windows Server 2012 Datacenter
•Windows Server 2012 Standard
•Windows Server 2012 Essentials
•Windows Server 2012 Foundation
•Windows 8 Enterprise
•Windows 8 Pro
•Windows 8
•Windows RT
•Windows Server 2008 R2 Service Pack 1, when used with:
Windows Server 2008 R2 Datacenter
Windows Server 2008 R2 Enterprise
Windows Server 2008 R2 Standard
Windows Web Server 2008 R2
Windows Server 2008 R2 Foundation
•Windows 7 Service Pack 1, when used with:
Windows 7 Ultimate
Windows 7 Enterprise
Windows 7 Professional
Windows 7 Home Premium
Windows 7 Home Basic
Windows 7 Starter
Duidelijker kan MS het niet maken.
Ik zei toch:
Dat is hier niet aan de orde though.
Ik bedoelde alleen te zeggen dat je, over 't algemeen, niet veel hebt aan KB nummers omdat het Knowledge Base artikelen zijn (met soms geassocieerde downloads); aan een "MS nummer" heb je meer omdat dat a) de geijkte manier is waarop gerefereerd wordt naar vulnerabilities voor MS producten en b) omdat het alle informatie bevat die je moet hebben, ook verwijzingen naar de betreffende KB-artikelen (wat er dus mogelijk meer dan 1 kunnen zijn).

Als volgende week blijkt dat Windows 2003 en XP en Vista ook een dergelijke vulnerability hebben dan zal 't security bulletin artikel worden aangevuld met de betreffende KB's voor die specifieke patch(es) (zouden die er nog komen; XP is al EOL en 2003 zo goed als bijna). De KB artikelen worden AFAIK dan niet bijgewerkt, hooguit met een "see also" verwijzing.

Jij zei: "Zet dan even het KB nummer erbij" en ik leg je uit waarom een KB nummer niet zo handig is als een security bulletin nummer en/of CVE nummer.

Maar goed, potato potato. Het zal wel. :w

[Reactie gewijzigd door RobIII op 16 april 2015 21:27]

Dus RobIII moet niet speculeren maar we zien wel of en wanneer er een ander KB nummer komt?......
Hier een website om te controleren of je webserver kwetsbaar is:

https://lab.xpaw.me/MS15-034/
Volgens mij zou 1 van onze servers toch wel kwetsbaar moeten zijn, en toch krijg ik "Cannot discern patch status of xxx. This most likely means it is not vulnerable."

Ben bezig met al onze servers de nodige updates te geven, maar deze specifieke server staat nog op de lijst.
En wat nu als de pagina niet me je targets kan verbinden :+
Is ook te verwachten als de exploit gratis te vinden is in alle exploit databases op het internet...
http://1337day.com/exploits/23518
Dat is niet de exploit, die code checkt gewoon of de server kwetsbaar is
ja maar het is niet moeilijk om deze om te vormen naar een andere hack. Zoals hieronder al aangegeven is een blue screen veroorzaken al mogelijk.
Daarin heb je gelijk, trouwens de post hieronder is eentje van mij :P
Ik vraag me af hoeveel beheerders ooit van interent storm center hebben gehoord en hen actief volgen.

Vroeger had je aan bugtraq maillinglist genoeg nu zijn er tientallen notificatie organisaties die vaak niet volledig over alles berichten.

Verder zou een bedrijf waar je voor licentie betaald wel zo vriendelijk mogen zijn om klanten expliciet direct te berichtten over een kritiek lek. Van Microsoft ontvang ik bijna wekelijks marketing onzin, maar over o.a. dit lek heb ik niets mogen ontvangen (als Microsoft partner) iemand wel iets ontvangen zo ja vanaf waar?

[Reactie gewijzigd door totaalgeenhard op 16 april 2015 20:19]

Ik vraag me af hoeveel beheerders ooit van interent storm center hebben gehoord en hen actief volgen.
Het ISC, onderdeel van SANS institute, is toch echt geen onbekende; wij gebruiken zelfs een aantal van hun API's om op basis daarvan (én andere factoren) malafide hosts te kunnen blacklisten etc. zoals bijvoorbeeld deze, deze of deze host.
The SANS Institute is a private U.S. company that specializes in information security and cybersecurity training. Since its founding in 1989, the SANS Institute has trained over 120,000 information security professionals in topics ranging from cyber and network defenses, penetration testing, incident response, digital forensics, and audit. In 1999, the SANS Institute formed Global Information Assurance Certification (GIAC), an independent entity that has granted over 58,000 certifications to validate the skills and knowledge of information security professionals. The SANS Institute also sponsors the Internet Storm Center, an Internet monitoring system staffed by a global community of security practitioners, and the SANS Reading Room - a research archive of information security policy and research documents that delivers over one million downloads per year to professionals globally.
En wat betreft je "klacht":
Verder zou een bedrijf waar je voor licentie betaald wel zo vriendelijk mogen zijn om klanten expliciet direct te berichtten over een kritiek lek.
Meer dan genoeg mogelijkheden lijkt me :?

[Reactie gewijzigd door RobIII op 16 april 2015 20:41]

Ik vraag me af hoeveel beheerders ooit van interent storm center hebben gehoord en hen actief volgen.
Meer dan je denkt, Jij dus niet in ieder geval.
Verder zou een bedrijf waar je voor licentie betaald wel zo vriendelijk mogen zijn om klanten expliciet direct te berichtten over een kritiek lek. Van Microsoft ontvang ik bijna wekelijks marketing onzin, maar over o.a. dit lek heb ik niets mogen ontvangen
Dat je je b.v. ooit een keer hebt geregistreerd voor een Microsoft seminar of whatever en daardoor wat commerciele spam krijgt en dat raar vind omdat je de kleine lettertjes niet hebt gelezen, betekend niet dat je op hetzelfde e-mail adres ook gelijk security notifications gaat ontvangen.

Ik heb al een tijd geleden gelezen dat er iets naars als dit zojuist bekend gemaakte lek aan zat te komen, en weet je waarom? ik heb me ingeschreven, zoals elke fatsoenlijke MS beheerder zou moeten doen, om de MS Advanced security bulletins te ontvangen. klik hier maar eens op: https://technet.microsoft.com/en-us/security/dd252948.aspx.

Wat voor een MS partner ben jij?

[Reactie gewijzigd door Druganov op 17 april 2015 01:50]

Dat je je b.v. ooit een keer hebt geregistreerd voor een Microsoft seminar of whatever en daardoor wat commerciele spam krijgt en dat raar vind omdat je de kleine lettertjes niet hebt gelezen, betekend niet dat je op hetzelfde e-mail adres ook gelijk security notifications gaat ontvangen.
Ik heb me ook al een keer ingeschreven enkele jaren terug op Microsoft security mailinglists en werd toen ook overspoeld door nonsens security artikels. Ik denk dat dat Network security mailinglists waren. Dat er kleine lettertjes waren dat kwam inderdaad ook niet bij mij op, moest dat ?
Ik heb al een tijd geleden gelezen dat er iets naars als dit zojuist bekend gemaakte lek aan zat te komen, en weet je waarom? ik heb me ingeschreven, zoals elke fatsoenlijke MS beheerder zou moeten doen, om de MS Advanced security bulletins te ontvangen. klik hier maar eens op: https://technet.microsoft.com/en-us/security/dd252948.aspx.
Dus ze wisten er op voorhand al van of ... het was de tijd van het jaar (zoveel maanden na vorige gevaarlijke kwetsbaarheid) ?
Wat voor een MS partner ben jij?
Sinds wanneer zijn klanten partners ?
http://map.ipviking.com/
je ziet hier een hoop attacks op http services
hoe en wat inhoudelijk is een beetje onduidelijk
maar hier waren er afgelopen avond een hele hoop van

misschien zien we de scans hier terugkomen
al kan het natuurlijk veel zijn, misschien alleen connections/exhaustion spam

[Reactie gewijzigd door 500749 op 16 april 2015 21:30]

In https://technet.microsoft...ry/security/ms15-034.aspx staat de volgende workaround genoemd:

"The following workaround may be helpful in your situation
Disable IIS kernel caching
This workaround is specific to IIS and can cause performance issues. For more information, see Enable Kernel Caching (IIS 7)."

Als je geen sites gepubliceerd hebt waarbij Kernel Mode Caching geconfigureerd is voor Output Caching in IIS zou de impact dus zeer waarschijnlijk beperkt zijn voor onze omgevingen.

Daarnaast gebruiken WinRM en PowerShell Remote geen Kernel Mode caching: https://twitter.com/Lee_Holmes/status/588464652708806656

Toch het blijft verstandig om servers snel te patchen voor deze (en andere) kwetsbaarheden!

Edit: User-Mode caching is blijkbaar niet kwetsbaar. Dit is ook logisch omdat http.sys in kernel-mode draait.

[Reactie gewijzigd door Devster op 17 april 2015 01:05]

Hoe Hiawatha in reverse proxy mode je kwetsbare webserver kan beschermen indien een patch nog niet beschikbaar was.
Hmm, schijnbaar zijn Vista en Server 2003 niet kwetsbaar, dat geeft goede hoop dat het nog oudere XP ook veilig is voor dit lek.
dat geeft goede hoop dat het nog oudere XP ook veilig is voor dit lek.
:D _O- Nee, gelukkig niet vatbaar voor dit lek. Dat via driehonderdéénentwintig andere lekken de zaak zo lek als een zeef is, en dat XP EOL is, vergeten we dan maar even ;) (Voor W2003 is dat overigens 14 juli a.s.) Als je nu nog XP draait is of je vatbaar bent voor CVE-2015-1635 wel je minste probleem :)

[Reactie gewijzigd door RobIII op 16 april 2015 21:20]

Uhm. Ja. Dit lek ja... Ondertussen de rest?
Naast het patchen van Windows kan ook het caching-mechanisme van IIS tijdelijk uitgeschakeld worden
Ik gebruik XAMPP om mijn website te hosten, mijn Windows 2012 is up to date maar toch heb ik een onderbuikgevoel dat dat niet genoeg is, firewall is op slot, IIS staat aan (wordt niet gebruikt) maar verder wordt er niks gedaan met die PC.

Hmm, toch maar de boel in de gaten houden dus.
Gewoon netjes de patches van afgelopen dinsdag installeren, daar wordt ook dit gat mee gedicht - hoef je je hier geen zorgen meer om te maken
Waarom installeer je de iis role als je hem niet gebruikt?
IIS stond er vanaf begin al erop.
Iis wordt niet standaard met het OS geinstalleerd sinds de modulaire role/features (win2008/Vista). Als je het installeerd en het niet gebruikt vergroot je onnodig de attack surface van je server.
Als je het niet gebruikt of nodig heb dus gewoon de role deïnstalleren, dan heb je ook niets meer te patchen.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True