Security Professionals
- ipfw add deny all from eindgebruikers to any
schannel CVE-2014-6321 (MS14-066 / KB2992611)
Laatste update: 2014-11-19 00:15 (zie onderaan dit artikel)
Zelden heb ik Microsoft in een MSjj-nnn advisory zo weinig bagatelliserende opmerkingen zien maken als in https://technet.microsoft.com/library/security/ms14-066#ID0EDOAE. Sterker, ik zie geen enkele "downplaying" opmerking. Er zijn geen workarounds, en zelfs EMET wordt niet als mitigerende maatregel genoemd. Er staat niets over rechten die een aanvaller krijgt, dus dat wordt SYSTEM.
==> Dit is een PATCH NOW!
Dat geldt initieel vooral voor servers, maar op termijn verwacht ik ook (valse) advertenties die naar kwaadaardige https servers (gecompromittteerd of "bullet-proof hosting", d.w.z. beheerd door cybercriminelen) zullen wijzen waardoor elke Windows PC risico loopt.
Nb. voor de mensen die nog XP draaien: aangezien Server 2003 kwetsbaar is, kun je ervan uitgaan dat ook XP kwetsbaar is (2003 en XP hebben, onder de motorkap, grote gelijkenissen).
Wanneer zijn aanvallen te verwachten?
Het zou mij niet verbazen als we binnen 1 a 2 dagen exploits zien (ik zou niet uitgaan van de week die isc.sans.edu vermoedt, zie https://www.security.nl/posting/408450/%22SSL-lek+in+Windows+binnen+week+aangevallen%22). Dit is puur gokken. Echter, reken maar dat cybercriminelen er veel geld voor over hebben om een dergelijke exploit in handen te krijgen.
Vergelijking met Heartbleed
Ik verwacht dat dit lek vergelijkbaar is met Heatbleed, en misschien nog wel iets erger.
Heartbleed kon meer anoniem worden uitgevoerd omdat webservers met OpenSSL de gebruikte commando's door aanvallers (om het RAM van de server uit te lezen) vaak niet worden gelogd. Hoewel het vaak wel het geval is met Heartbleed, heb je,als aanvaller, geen garantie dat je "zinvolle" vertrouwelijke informatie in handen krijgt.
SChannel is, ruwweg, wat OpenSSL is voor Linux en dergelijke. Het nu gemelde RCE (Remote Code Execution) lek maakt mogelijk meer "lawaai" dan Heartbleed, in de zin van dat er code op de server of PC wordt gestart.
Detectie van gecompromitteerde servers en PC's
De kans dat virusscanners aanvallen zullen detecteren acht ik klein. Immers, er is sprake van een versleutelde verbinding, waarna code in het geheugen (niet op schijf) wordt gestart, als onderdeel van het schannel "proces". Zo'n primaire exploit is vaak klein. Meestal is het eerste dat zo'n exploit doet, downloaden van aanvullende code. Dat zou op kunnen vallen, bijv. door de DNS requests die daarbij worden uitgevoerd. Als die aanvullende code op de schijf wordt weggeschreven (en daar weer vandaan geladen wordt), hebben virusscanners een betere kans om malware te detecteren. Vooral voor "bulk aanvallen" zal dit redelijk snel (uren tot enkele dagen) het geval kunnen zijn.
Voor high profile servers zullen cybercriminelen waarschijnlijk targeted, d.w.z. op maat getweakte, malware serveren die niet snel door virusscanners zal worden ontdekt. Reken er maar op dat er rootkits op dergelijke servers zullen worden geïnstalleerd, wat detectie door (antivirus) software op die server zelf enorm kan bemoeilijken. Het is handig als je, over langere periodes, statistieken hebt van CPU load en netwerkverkeer. Let ook vooral op pogingen om vanaf die server tot andere delen van je netwerk door te dringen.
Tot zover. Ik stel voor dat we elkaar op de hoogte houden!
Aanvulling 2014-11-13 00:41
Uit https://blogs.cisco.com/security/talos/ms-tuesday-nov-2014 (bron: http://www.zdnet.com/drop-what-youre-doing-and-patch-the-windows-schannel-bugs-now-7000035738/):
Aanvullingen 2014-11-14 11:07
Zoals verwacht vindt er onderzoek plaats naar wat Microsoft precies gewijzgd heeft in de gedistribueerde updates (t.o.v. de daarmee overschreven binaries) om "de lekken" (naar verluidt gaat het om meerdere, zie bovenstaande aanvulling) te dichten. Naast het dichten van lekken heeft Microsoft ook verschillende nieuwe functionaliteiten toegevoegd (zoals Anoniem op 2014-11-13 00:29 beschrijft). Echter, die nieuwe functionaliteiten zijn niet gerealiseerd in de schannel updates voor Server 2003 R2. Vandaar dat de meeste onderzoekers zich richten op wijzigingen gerealiseerd in updates voor Server 2003 R2.
In https://gist.github.com/hmoore-r7/01a2940edba33f19dec3 toont H.D. Moore wijzgingen in de gepatchte schannel.dll t.o.v. de vorige versie daarvan. Een analyse van H.D. Moore van de oude code vind je in https://gist.github.com/hmoore-r7/3379af8b0419ddb0c76b. Een vergelijbare analyse door "Romanian Security Team" vind je in https://rstforums.com/forum/91929-ms14-066-schannel-dll-spverifysignature-windows-2003-sp2.rst.
Uit onderstaande thread (waarvoor dank!):
In http://www.r00tsec.com/2014/11/list-of-resource-for-ms14-066.html vind je een aantal recente links. Interessant daarin vind ik:
- In http://pastebin.com/bsgX01dU - uit iemand, namens de "SChannel Shenanigans", het volgende dreigement:
- Interessanter is dat in https://github.com/anexia-it/winshock-test een test voor kwetsbare servers wordt aangeboden. Die is uitdrukkelijk niet gebaseerd op een exploit, maar checkt of de nieuwe functionaliteit (nieuwe cipher suites) die Microsoft in updates voor verschillende besturingssystemen heeft toegevoegd. Dat betekent dat deze test false positives kan opleveren, want ook gepatchte Server 2003 R2 systemen (en wellicht XP embedded en POS systemen) beschikken niet over genoemde functionele uitbreidingen. Desalniettemin een slim idee voor degenen die geen verouderde servers meer draaien!
Aanvullingen 2014-11-14 17:20
In http://emergingthreats.net/daily-ruleset-update-summary-11132014/ zijn (uitsluitend toegankelijk voor betalende gebruikers van snort) de volgende rules, gerelateerd aan "WinShock" (CVE-2014-6321) gepubliceerd, allen zijn "ETPRO EXPLOIT's":
Het feit dat detectie van exploits bestaat betekent dat bekend moet zijn hoe die exploits eruit kunnen zien. In de praktijk betekent dit meestal dat de achterliggende informatie snel publiek zal worden.
In https://isc.sans.edu/diary/SChannel+Update+and+Experimental+Vulnerability+Scanner+MS14-066/18953 heeft Johannes Ullrich (SANS.edu) een scanner gepubliceerd (vermoedelijk vergelijkbaar met de hierboven genoemde anexia-it scanner) die kwetsbare servers identificeert, maar uit de comments eronder maak ik op dat deze (nog) niet feilloos werkt. Ook Qualys (SSLLabs) lijkt hieraan te werken, zie https://community.qualys.com/thread/14013.
Aanvulling 2014-11-15 03:46
PoC is beschikbaar voor klanten van Immunity: zie "November 14, 2014 MS14-066 TLS default remote heap overflow trigger" in https://www.immunityinc.com/partners/ceu-index.html (naam+ww vereist voor https://ceu.immunityinc.com/immpartners/MS14_066_CEU.tar.gz).
Aanvullingen 2014-11-16 04:22
Uit http://permalink.gmane.org/gmane.comp.security.patch-managment/8859:
Uit http://darrenmyher.wordpress.com/2014/11/13/security-update-ms14-066-causes-major-performance-in-microsoft-access-sql-server-applications/:
Niet iedereen heeft die problemen, uit http://accessblog.net/2014/11/security-update-ms14-066-causes-major.html#c8239510880925355770:
Uit http://aws.amazon.com/security/security-bulletins/ms14-066-advisory/:
Uit https://support.microsoft.com/kb/2992611#MT1:
Aanvullingen 2014-11-17 10:22
Uit http://odetodata.com/2014/11/microsoft-patch-ms14-066-leads-to-https-problems-with-iis-and-google-chrome/:
Uit https://www.nartac.com/Products/IISCrypto/Default.aspx:
Ik heb deze tool wel gedownload maar zelf nog niet getest, gebruik is voor eigen risico. De tool is netjes voorzien van een digitale (Authenticode) handtekening. Aanvullende gegevens erover (zoals hashes) vind je in https://www.virustotal.com/en/file/e861deb0227dcf5b1961b652b011911f7dba0bbaa762f9d2b6b376940be75d24/analysis/1416177796/.
Advies: hou http://blog.gmane.org/gmane.comp.security.patch-managment in de gaten voor nieuwe informatie over problemen met deze patch (MS14-066/KB2992611).
Aanvullingen 2014-11-17 20:43
In http://blog.beyondtrust.com/triggering-ms14-066 wordt een behoorlijke tip van de sluier opgelicht over 1 van de lekken. Dit is nog geen hapklare exploit, maar kan daadwerkelijke exploits wel helpen versnellen.
Bron: http://www.heise.de/security/meldung/Jetzt-patchen-Details-zur-SChannel-Luecke-in-Windows-im-Umlauf-2458701.html
Aanvullingen 2014-11-18 23:06
Vanavond heeft Microsoft patch MS14-068 uitgebracht, maar kennelijk tegelijkertijd ook een update van MS-066. Pagina https://technet.microsoft.com/library/security/ms14-066 is bijgewerkt, maar (opvallend) https://support.microsoft.com/kb/2992611 (nog) niet.
Uit https://isc.sans.edu/diary/Microsoft+November+out-of-cycle+patch+MS14-068/18967:
In de comments in https://isc.sans.edu/forums/diary/Microsoft+November+out-of-cycle+patch+MS14-068/18967 zie ik dat meerdere mensen problemen rapporteren met de patches op Server 2003. Onduidelijk is of dat komt door de verse MS14-068, of door de update van MS14-066. Aangezien er, voor zover ik weet, nog geen exploit/PoC gepubliceerd is voor MS14-068 (Kerberos privilege escalation naar Domain Admin), is het wellicht verstandig om die update, zeker voor Server 2003, nog even te laten rusten (maar zie ook de aanvulling hieronder!).
Aanvullingen 2014-11-19 00:15
Uit http://blogs.technet.com/b/srd/archive/2014/11/18/additional-information-about-cve-2014-6324.aspx (let op, deze waarschuwing is voor MS14-068/Kerberos):
In http://article.gmane.org/gmane.comp.security.patch-managment/8918/match= meldt Susan Bradley dat er een nieuwe versie beschikbaar is van de hierboven door mij genoemde "IIS Crypto" tool van Nartac Software. Zie https://www.nartac.com/Products/IISCrypto/Default.aspx door meer info en downloads.
Zelden heb ik Microsoft in een MSjj-nnn advisory zo weinig bagatelliserende opmerkingen zien maken als in https://technet.microsoft.com/library/security/ms14-066#ID0EDOAE. Sterker, ik zie geen enkele "downplaying" opmerking. Er zijn geen workarounds, en zelfs EMET wordt niet als mitigerende maatregel genoemd. Er staat niets over rechten die een aanvaller krijgt, dus dat wordt SYSTEM.
==> Dit is een PATCH NOW!
Dat geldt initieel vooral voor servers, maar op termijn verwacht ik ook (valse) advertenties die naar kwaadaardige https servers (gecompromittteerd of "bullet-proof hosting", d.w.z. beheerd door cybercriminelen) zullen wijzen waardoor elke Windows PC risico loopt.
Nb. voor de mensen die nog XP draaien: aangezien Server 2003 kwetsbaar is, kun je ervan uitgaan dat ook XP kwetsbaar is (2003 en XP hebben, onder de motorkap, grote gelijkenissen).
Wanneer zijn aanvallen te verwachten?
Het zou mij niet verbazen als we binnen 1 a 2 dagen exploits zien (ik zou niet uitgaan van de week die isc.sans.edu vermoedt, zie https://www.security.nl/posting/408450/%22SSL-lek+in+Windows+binnen+week+aangevallen%22). Dit is puur gokken. Echter, reken maar dat cybercriminelen er veel geld voor over hebben om een dergelijke exploit in handen te krijgen.
Vergelijking met Heartbleed
Ik verwacht dat dit lek vergelijkbaar is met Heatbleed, en misschien nog wel iets erger.
Heartbleed kon meer anoniem worden uitgevoerd omdat webservers met OpenSSL de gebruikte commando's door aanvallers (om het RAM van de server uit te lezen) vaak niet worden gelogd. Hoewel het vaak wel het geval is met Heartbleed, heb je,als aanvaller, geen garantie dat je "zinvolle" vertrouwelijke informatie in handen krijgt.
SChannel is, ruwweg, wat OpenSSL is voor Linux en dergelijke. Het nu gemelde RCE (Remote Code Execution) lek maakt mogelijk meer "lawaai" dan Heartbleed, in de zin van dat er code op de server of PC wordt gestart.
Detectie van gecompromitteerde servers en PC's
De kans dat virusscanners aanvallen zullen detecteren acht ik klein. Immers, er is sprake van een versleutelde verbinding, waarna code in het geheugen (niet op schijf) wordt gestart, als onderdeel van het schannel "proces". Zo'n primaire exploit is vaak klein. Meestal is het eerste dat zo'n exploit doet, downloaden van aanvullende code. Dat zou op kunnen vallen, bijv. door de DNS requests die daarbij worden uitgevoerd. Als die aanvullende code op de schijf wordt weggeschreven (en daar weer vandaan geladen wordt), hebben virusscanners een betere kans om malware te detecteren. Vooral voor "bulk aanvallen" zal dit redelijk snel (uren tot enkele dagen) het geval kunnen zijn.
Voor high profile servers zullen cybercriminelen waarschijnlijk targeted, d.w.z. op maat getweakte, malware serveren die niet snel door virusscanners zal worden ontdekt. Reken er maar op dat er rootkits op dergelijke servers zullen worden geïnstalleerd, wat detectie door (antivirus) software op die server zelf enorm kan bemoeilijken. Het is handig als je, over langere periodes, statistieken hebt van CPU load en netwerkverkeer. Let ook vooral op pogingen om vanaf die server tot andere delen van je netwerk door te dringen.
Tot zover. Ik stel voor dat we elkaar op de hoogte houden!
Aanvulling 2014-11-13 00:41
Uit https://blogs.cisco.com/security/talos/ms-tuesday-nov-2014 (bron: http://www.zdnet.com/drop-what-youre-doing-and-patch-the-windows-schannel-bugs-now-7000035738/):
Door Cisco/Talos Group | November 11, 2014 at 11:38 am PST: MS14-066 covers a single CVE, CVE-2014-6321, in Microsoft’s Secure Channel security package in Windows, which provides security protocol support for applications. While it is covered by only a single CVE, there’s actually multiple vulnerabilities, ranging from buffer overflows to certificate validation bypasses.
Aanvullingen 2014-11-14 11:07
Zoals verwacht vindt er onderzoek plaats naar wat Microsoft precies gewijzgd heeft in de gedistribueerde updates (t.o.v. de daarmee overschreven binaries) om "de lekken" (naar verluidt gaat het om meerdere, zie bovenstaande aanvulling) te dichten. Naast het dichten van lekken heeft Microsoft ook verschillende nieuwe functionaliteiten toegevoegd (zoals Anoniem op 2014-11-13 00:29 beschrijft). Echter, die nieuwe functionaliteiten zijn niet gerealiseerd in de schannel updates voor Server 2003 R2. Vandaar dat de meeste onderzoekers zich richten op wijzigingen gerealiseerd in updates voor Server 2003 R2.
In https://gist.github.com/hmoore-r7/01a2940edba33f19dec3 toont H.D. Moore wijzgingen in de gepatchte schannel.dll t.o.v. de vorige versie daarvan. Een analyse van H.D. Moore van de oude code vind je in https://gist.github.com/hmoore-r7/3379af8b0419ddb0c76b. Een vergelijbare analyse door "Romanian Security Team" vind je in https://rstforums.com/forum/91929-ms14-066-schannel-dll-spverifysignature-windows-2003-sp2.rst.
Uit onderstaande thread (waarvoor dank!):
2014-11-14 07:13 door Anoniem: https://twitter.com/daveaitel/status/533064909387747328
LSASS eip control via ms14-066 + preauth RDP achieved in lab. Will be in CANVAS Early Updates tomorrow!!!
LSASS eip control via ms14-066 + preauth RDP achieved in lab. Will be in CANVAS Early Updates tomorrow!!!
In http://www.r00tsec.com/2014/11/list-of-resource-for-ms14-066.html vind je een aantal recente links. Interessant daarin vind ik:
- In http://pastebin.com/bsgX01dU - uit iemand, namens de "SChannel Shenanigans", het volgende dreigement:
Microsoft has until the end of day Friday the 14th to change MS14-066 Exploit-ability Assessment to "0- Exploitation Detected". If they do not, I will anonymously distribute "The Exploit".
Sowieso is het de vraag of dit bluf is, maar ik verwacht niet dat Microsoft op dit soort bedreigingen ingaat, en zoals "perthguppy" in http://www.reddit.com/r/netsec/comments/2m1alz/microsoft_security_bulletin_ms14066/ opmerkt: You don't think no one else is going to release a PoC before then?
Als het geen bluf is zal een exploit worden gepubliceerd, maar die verwachte ik (en de lezers van het bovenstaande die het met mij eens zijn) sowieso al.- Interessanter is dat in https://github.com/anexia-it/winshock-test een test voor kwetsbare servers wordt aangeboden. Die is uitdrukkelijk niet gebaseerd op een exploit, maar checkt of de nieuwe functionaliteit (nieuwe cipher suites) die Microsoft in updates voor verschillende besturingssystemen heeft toegevoegd. Dat betekent dat deze test false positives kan opleveren, want ook gepatchte Server 2003 R2 systemen (en wellicht XP embedded en POS systemen) beschikken niet over genoemde functionele uitbreidingen. Desalniettemin een slim idee voor degenen die geen verouderde servers meer draaien!
Aanvulling 2014-11-17 17:51 over winshock-test: onderaan https://isc.sans.edu/forums/diary/SChannel+Update+and+Experimental+Vulnerability+Scanner+MS14-066/18953#32457, suggereert "nathan" dat Windows Server 2012 R2 de cipher-suites waar "winshock-test" op controleert, out-of-the-box al ondersteunt. Als dat klopt is dit geen veilige testmethode: de tool zal van een niet gepatchte server waarschijnlijk onterecht (false negative) melden dat deze niet kwetsbaar is!
Aanvullingen 2014-11-14 17:20
In http://emergingthreats.net/daily-ruleset-update-summary-11132014/ zijn (uitsluitend toegankelijk voor betalende gebruikers van snort) de volgende rules, gerelateerd aan "WinShock" (CVE-2014-6321) gepubliceerd, allen zijn "ETPRO EXPLOIT's":
2809176 – DTLS Pre 1.0 HelloVerifyRequest CookieSize Heap Overflow
2809177 – DTLS 1.0 HelloVerifyRequest CookieSize Heap Overflow
2809178 – DTLS 1.2 HelloVerifyRequest CookieSize Heap Overflow
2809179 – DTLS Pre 1.0 HelloVerifyRequest Schannel OOB Read
2809180 – DTLS 1.0 HelloVerifyRequest Schannel OOB Read
2809181 – DTLS 1.2 HelloVerifyRequest Schannel OOB Read
2809192 – SChannel Possible Heap Overflow DSAWithSHA1
2809193 – SChannel Possible Heap Overflow DSAWithSHA224
2809194 – SChannel Possible Heap Overflow DSAWithSHA256
2809195 – SChannel Possible Heap Overflow ECDSAWithSHA1
2809196 – SChannel Possible Heap Overflow ECDSAWithSHA224
2809197 – SChannel Possible Heap Overflow ECDSAWithSHA256
2809198 – SChannel Possible Heap Overflow ECDSAWithSHA384
2809199 – SChannel Possible Heap Overflow ECDSAWithSHA512
2809177 – DTLS 1.0 HelloVerifyRequest CookieSize Heap Overflow
2809178 – DTLS 1.2 HelloVerifyRequest CookieSize Heap Overflow
2809179 – DTLS Pre 1.0 HelloVerifyRequest Schannel OOB Read
2809180 – DTLS 1.0 HelloVerifyRequest Schannel OOB Read
2809181 – DTLS 1.2 HelloVerifyRequest Schannel OOB Read
2809192 – SChannel Possible Heap Overflow DSAWithSHA1
2809193 – SChannel Possible Heap Overflow DSAWithSHA224
2809194 – SChannel Possible Heap Overflow DSAWithSHA256
2809195 – SChannel Possible Heap Overflow ECDSAWithSHA1
2809196 – SChannel Possible Heap Overflow ECDSAWithSHA224
2809197 – SChannel Possible Heap Overflow ECDSAWithSHA256
2809198 – SChannel Possible Heap Overflow ECDSAWithSHA384
2809199 – SChannel Possible Heap Overflow ECDSAWithSHA512
Het feit dat detectie van exploits bestaat betekent dat bekend moet zijn hoe die exploits eruit kunnen zien. In de praktijk betekent dit meestal dat de achterliggende informatie snel publiek zal worden.
In https://isc.sans.edu/diary/SChannel+Update+and+Experimental+Vulnerability+Scanner+MS14-066/18953 heeft Johannes Ullrich (SANS.edu) een scanner gepubliceerd (vermoedelijk vergelijkbaar met de hierboven genoemde anexia-it scanner) die kwetsbare servers identificeert, maar uit de comments eronder maak ik op dat deze (nog) niet feilloos werkt. Ook Qualys (SSLLabs) lijkt hieraan te werken, zie https://community.qualys.com/thread/14013.
Aanvulling 2014-11-15 03:46
PoC is beschikbaar voor klanten van Immunity: zie "November 14, 2014 MS14-066 TLS default remote heap overflow trigger" in https://www.immunityinc.com/partners/ceu-index.html (naam+ww vereist voor https://ceu.immunityinc.com/immpartners/MS14_066_CEU.tar.gz).
Aanvullingen 2014-11-16 04:22
Uit http://permalink.gmane.org/gmane.comp.security.patch-managment/8859:
2014-11-15 door Susan Bradley: POC for MS14-066 is buggy (and that's a good thingO)
https://twitter.com/nicowaisman/status/533309381124034560
Immunity is a company that has a POC for MS14-066. But as of yesterday it was "buggy"... that is it couldn't consistently gain control and was merely causing a DOS of lsass.
But there are lots of folks feverishly working on trying to make an exploit.
https://twitter.com/nicowaisman/status/533309381124034560
Immunity is a company that has a POC for MS14-066. But as of yesterday it was "buggy"... that is it couldn't consistently gain control and was merely causing a DOS of lsass.
But there are lots of folks feverishly working on trying to make an exploit.
Uit http://darrenmyher.wordpress.com/2014/11/13/security-update-ms14-066-causes-major-performance-in-microsoft-access-sql-server-applications/:
2014-11-13 door Darren Myher: Security Update MS14-066 causes major performance problems in Microsoft Access / SQL Server applications
[...]
Our customers are reporting that this security update causes MAJOR performance problems in any Microsoft Access application with a SQL Server backend (any version). For example, a simple operation such as clicking from one line of an order to another (without performing ANY data updates) can take from 5 to 15 seconds! For users having to update hundreds of lines of orders, the application becomes nearly unusable – an activity that used to take 5 minutes could take hours.to complete.
[...]
Update: as of 2014-11-14 1:30PM: Update from Microsoft on our open case: The SQL Team is working directly with the Windows team and have been able to reproduce performance issues. They’ve created a specific tool to gather performance stats related to the issue and are working with one of my techs to gather the stats in our lab environment with both the patch installed and with it removed.
Bron: Susan Bradley in http://permalink.gmane.org/gmane.comp.security.patch-managment/8861.[...]
Our customers are reporting that this security update causes MAJOR performance problems in any Microsoft Access application with a SQL Server backend (any version). For example, a simple operation such as clicking from one line of an order to another (without performing ANY data updates) can take from 5 to 15 seconds! For users having to update hundreds of lines of orders, the application becomes nearly unusable – an activity that used to take 5 minutes could take hours.to complete.
[...]
Update: as of 2014-11-14 1:30PM: Update from Microsoft on our open case: The SQL Team is working directly with the Windows team and have been able to reproduce performance issues. They’ve created a specific tool to gather performance stats related to the issue and are working with one of my techs to gather the stats in our lab environment with both the patch installed and with it removed.
Niet iedereen heeft die problemen, uit http://accessblog.net/2014/11/security-update-ms14-066-causes-major.html#c8239510880925355770:
Door Matthias Kläy: [...]
I believe that the title shoud be "Security Update MS14-066 *can* cause major performance problems..."
In the following configuration I do not experience any performance problems with the security update installed:
- Windows Sever 2008R2
- SQL Server 2012
- Acess 2010 Runtime
- ODBC Driver both {SQL Server} and {SQL Server Native Client 11.0}
- Login with both Trusted Connection and SQL Server Login
- Remote Desktop Access with Citrix XenApp
Note there is no domain and Active Director involved, and there is no ODBC acces over the network.
So it remains to be determined under which exact conditions these performance problems occur.
[...]
I believe that the title shoud be "Security Update MS14-066 *can* cause major performance problems..."
In the following configuration I do not experience any performance problems with the security update installed:
- Windows Sever 2008R2
- SQL Server 2012
- Acess 2010 Runtime
- ODBC Driver both {SQL Server} and {SQL Server Native Client 11.0}
- Login with both Trusted Connection and SQL Server Login
- Remote Desktop Access with Citrix XenApp
Note there is no domain and Active Director involved, and there is no ODBC acces over the network.
So it remains to be determined under which exact conditions these performance problems occur.
[...]
Uit http://aws.amazon.com/security/security-bulletins/ms14-066-advisory/:
2014/11/14 5:30PM PST
We are continuing to investigate the reported issues with the patch that was supplied for MS14-066. This updated status is being provided for the service below. We will continue to update this Security Bulletin for the other services previously identified as more information becomes available.
Amazon Relational Database Service (RDS):
Amazon RDS will build and deploy any required updates to affected RDS SQL Server instances. Any needed updates will require a restart of the RDS database instance. Communication of the specific timing of the update for each instance will be communicated via email or AWS Support directly to customers prior to any instance restart.
---------------------------------------------------------------
2014/11/12 9:30 PM PST
We have received reports that the patch that Microsoft supplied for MS14-066 has been causing issues, specifically that TLS 1.2 sessions are disconnecting during key exchange.
While we investigate this issue with the patch provided, we suggest that our customers review their security groups and ensure that external access to Windows instances have been appropriately restricted to the extent possible. Below is guidance that our customers can refer to when reviewing their security groups.
EC2 Windows instance security group documentation: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html
AWS Elastic Beanstalk security groups documentation: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.ec2.html
Amazon RDS SQL Server security group documentation: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html
[...]
Bron: Susan Bradley in http://permalink.gmane.org/gmane.comp.security.patch-managment/8827We are continuing to investigate the reported issues with the patch that was supplied for MS14-066. This updated status is being provided for the service below. We will continue to update this Security Bulletin for the other services previously identified as more information becomes available.
Amazon Relational Database Service (RDS):
Amazon RDS will build and deploy any required updates to affected RDS SQL Server instances. Any needed updates will require a restart of the RDS database instance. Communication of the specific timing of the update for each instance will be communicated via email or AWS Support directly to customers prior to any instance restart.
---------------------------------------------------------------
2014/11/12 9:30 PM PST
We have received reports that the patch that Microsoft supplied for MS14-066 has been causing issues, specifically that TLS 1.2 sessions are disconnecting during key exchange.
While we investigate this issue with the patch provided, we suggest that our customers review their security groups and ensure that external access to Windows instances have been appropriately restricted to the extent possible. Below is guidance that our customers can refer to when reviewing their security groups.
EC2 Windows instance security group documentation: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html
AWS Elastic Beanstalk security groups documentation: http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/using-features.managing.ec2.html
Amazon RDS SQL Server security group documentation: http://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Overview.RDSSecurityGroups.html
[...]
Uit https://support.microsoft.com/kb/2992611#MT1:
Known issues with this security update (MS14-066)
We are aware of an issue in certain configurations in which TLS 1.2 is enabled by default, and TLS negotiations may fail. When this problem occurs, TLS 1.2 connections are dropped, processes hang (stop responding), or services become intermittently unresponsive. You may also receive an error message that resembles the following in the System log in Event Viewer:
To work around this issue, delete the following cipher entries in the registry:
Bron: Susan Bradley in http://permalink.gmane.org/gmane.comp.security.patch-managment/8852We are aware of an issue in certain configurations in which TLS 1.2 is enabled by default, and TLS negotiations may fail. When this problem occurs, TLS 1.2 connections are dropped, processes hang (stop responding), or services become intermittently unresponsive. You may also receive an error message that resembles the following in the System log in Event Viewer:
Log Name: System
Source: Schannel
Date: Date and time
Event ID: 36887
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: ComputerName
Description:
A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 40.
Source: Schannel
Date: Date and time
Event ID: 36887
Task Category: None
Level: Error
Keywords:
User: SYSTEM
Computer: ComputerName
Description:
A fatal alert was received from the remote endpoint. The TLS protocol defined fatal alert code is 40.
To work around this issue, delete the following cipher entries in the registry:
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
<instructies voor aanpassen register volgen>TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
Aanvullingen 2014-11-17 10:22
Uit http://odetodata.com/2014/11/microsoft-patch-ms14-066-leads-to-https-problems-with-iis-and-google-chrome/:
November 15, 2014 by Cristian Satnic: Microsoft patch MS14-066 leads to https problems with IIS and Google Chrome
[...]
We applied this to servers running Windows Server 2012 with IIS and all of a sudden we started seeing problems with https and Google Chrome. Users running the latest version of Google Chrome (as of now 38.0.2125.122) were not able anymore to hit https sites served by IIS servers that had this patch applied to them. Chrome users were getting some very strange errors such as ERR_CONNECTION_ABORTED and ERR_TIMED_OUT. At the same time, users with Internet Explorer 11 and Firefox 33 (latest versions for those browsers) were able to browse the same https sites without a problem.
Very odd … what exactly is going on here?
It appears to be a problem that only comes up under some very specific (and not fully understood) conditions. It’s unclear for example if both the server and the client OS must have MS14-066 installed in order for the Google Chrome problems to start happening.
It took a few days but slowly signs that others were seeing similar issues began to emerge. See for example https://social.technet.microsoft.com/Forums/windowsserver/en-US/218cf562-3dab-4d09-adcc-74f65d0f29f1/winshock-kb2992611-patch-breaks-iis?forum=winserversecurity
[...]
Vervolgens stelt Cristian Satnic verschillende maatregelen voor, waaronder: [...]
We applied this to servers running Windows Server 2012 with IIS and all of a sudden we started seeing problems with https and Google Chrome. Users running the latest version of Google Chrome (as of now 38.0.2125.122) were not able anymore to hit https sites served by IIS servers that had this patch applied to them. Chrome users were getting some very strange errors such as ERR_CONNECTION_ABORTED and ERR_TIMED_OUT. At the same time, users with Internet Explorer 11 and Firefox 33 (latest versions for those browsers) were able to browse the same https sites without a problem.
Very odd … what exactly is going on here?
It appears to be a problem that only comes up under some very specific (and not fully understood) conditions. It’s unclear for example if both the server and the client OS must have MS14-066 installed in order for the Google Chrome problems to start happening.
It took a few days but slowly signs that others were seeing similar issues began to emerge. See for example https://social.technet.microsoft.com/Forums/windowsserver/en-US/218cf562-3dab-4d09-adcc-74f65d0f29f1/winshock-kb2992611-patch-breaks-iis?forum=winserversecurity
[...]
attempt to remove just the 4 new ciphers according to Microsoft’s instructions (this involves registry edits and does not appear to actually work since some of the registry keys mentioned are not directly accessible by administrators due to how permissions on those keys are set up)
Het bovenstaande conform het MS advies in https://support.microsoft.com/kb/2992611#MT1. November 15, 2014 by Cristian Satnic: Update 2: disabling TLS 1.2 on the server appears to fix the problem (temporarily) because that forces clients to use at most TLS 1.1 and get around the new ciphers added by Microsoft
[...]
One can also use the nice IIS Crypto tool – https://www.nartac.com/Products/IISCrypto/Default.aspx to manage security protocols and ciphers on IIS.
Bron: Susan Bradley in http://comments.gmane.org/gmane.comp.security.patch-managment/8863[...]
One can also use the nice IIS Crypto tool – https://www.nartac.com/Products/IISCrypto/Default.aspx to manage security protocols and ciphers on IIS.
Uit https://www.nartac.com/Products/IISCrypto/Default.aspx:
Door NARTAC Software: [/i]IIS Crypto is a free tool that gives administrators the ability to enable or disable protocols, ciphers, hashes and key exchange algorithms on Windows Server 2003, 2008 and 2012. It also lets you reorder SSL/TLS cipher suites offered by IIS, implement best practices with a single click and test your website.
Features
- Single click to secure your site using best practices
- Stop BEAST and POODLE attacks
- Easily disable SSL 2.0 and SSL 3.0
- Enable TLS 1.1 and 1.2
- Disable other weak protocols and ciphers
- Enable forward secrecy
- Reorder cipher suites
- Templates for compliance with government and industry regulations - FIPS 140-2 and PCI
What Does IIS Crypto Do?
IIS Crypto updates the registry following this article (https://support.microsoft.com/default.aspx?scid=kb;EN-US;245030) from Microsoft. We have tested IIS Crypto on Windows Server 2003, 2008, 2008 R2 and 2012 and 2012 R2. Note - Windows Server 2003 does not support the reordering of SSL cipher suites offered by IIS. However, you can still disable weak protocols and ciphers. Also, Windows Server 2003 does not come with the AES cipher suite. Microsoft has a hotfix (https://support.microsoft.com/kb/948963)for this.
Daaronder volgend download links en een verwijzing naar een FAQ pagina.Features
- Single click to secure your site using best practices
- Stop BEAST and POODLE attacks
- Easily disable SSL 2.0 and SSL 3.0
- Enable TLS 1.1 and 1.2
- Disable other weak protocols and ciphers
- Enable forward secrecy
- Reorder cipher suites
- Templates for compliance with government and industry regulations - FIPS 140-2 and PCI
What Does IIS Crypto Do?
IIS Crypto updates the registry following this article (https://support.microsoft.com/default.aspx?scid=kb;EN-US;245030) from Microsoft. We have tested IIS Crypto on Windows Server 2003, 2008, 2008 R2 and 2012 and 2012 R2. Note - Windows Server 2003 does not support the reordering of SSL cipher suites offered by IIS. However, you can still disable weak protocols and ciphers. Also, Windows Server 2003 does not come with the AES cipher suite. Microsoft has a hotfix (https://support.microsoft.com/kb/948963)for this.
Ik heb deze tool wel gedownload maar zelf nog niet getest, gebruik is voor eigen risico. De tool is netjes voorzien van een digitale (Authenticode) handtekening. Aanvullende gegevens erover (zoals hashes) vind je in https://www.virustotal.com/en/file/e861deb0227dcf5b1961b652b011911f7dba0bbaa762f9d2b6b376940be75d24/analysis/1416177796/.
Advies: hou http://blog.gmane.org/gmane.comp.security.patch-managment in de gaten voor nieuwe informatie over problemen met deze patch (MS14-066/KB2992611).
Aanvullingen 2014-11-17 20:43
In http://blog.beyondtrust.com/triggering-ms14-066 wordt een behoorlijke tip van de sluier opgelicht over 1 van de lekken. Dit is nog geen hapklare exploit, maar kan daadwerkelijke exploits wel helpen versnellen.
Bron: http://www.heise.de/security/meldung/Jetzt-patchen-Details-zur-SChannel-Luecke-in-Windows-im-Umlauf-2458701.html
Aanvullingen 2014-11-18 23:06
Vanavond heeft Microsoft patch MS14-068 uitgebracht, maar kennelijk tegelijkertijd ook een update van MS-066. Pagina https://technet.microsoft.com/library/security/ms14-066 is bijgewerkt, maar (opvallend) https://support.microsoft.com/kb/2992611 (nog) niet.
Uit https://isc.sans.edu/diary/Microsoft+November+out-of-cycle+patch+MS14-068/18967:
2014-11-18 21:43:49 UTC door Jim Clausing: Note: MS14-066 was also updated today to fix some of the issues previously discussed with the introduction of the additional TLS cipher suites. Folks running Server 2008 R2 and Server 2012 are urged to reinstall
In de comments in https://isc.sans.edu/forums/diary/Microsoft+November+out-of-cycle+patch+MS14-068/18967 zie ik dat meerdere mensen problemen rapporteren met de patches op Server 2003. Onduidelijk is of dat komt door de verse MS14-068, of door de update van MS14-066. Aangezien er, voor zover ik weet, nog geen exploit/PoC gepubliceerd is voor MS14-068 (Kerberos privilege escalation naar Domain Admin), is het wellicht verstandig om die update, zeker voor Server 2003, nog even te laten rusten (maar zie ook de aanvulling hieronder!).
Aanvullingen 2014-11-19 00:15
Uit http://blogs.technet.com/b/srd/archive/2014/11/18/additional-information-about-cve-2014-6324.aspx (let op, deze waarschuwing is voor MS14-068/Kerberos):
18 Nov 2014 10:17 AM door swiat: Today Microsoft released update MS14-068 to address CVE-2014-6324, a Windows Kerberos implementation elevation of privilege vulnerability that is being exploited in-the-wild in limited, targeted attacks.
In http://article.gmane.org/gmane.comp.security.patch-managment/8918/match= meldt Susan Bradley dat er een nieuwe versie beschikbaar is van de hierboven door mij genoemde "IIS Crypto" tool van Nartac Software. Zie https://www.nartac.com/Products/IISCrypto/Default.aspx door meer info en downloads.
Reacties (18)
De webserver die ik beheer kan geen connecties terug naar internet maken. Daardoor kan deze geen code downloaden
anders dan via de inkomende connectie. Dat zouden meer mensen zo moeten configureren.
anders dan via de inkomende connectie. Dat zouden meer mensen zo moeten configureren.
12-11-2014, 23:18 door
Erik van Straten
Door Anoniem: De webserver die ik beheer kan geen connecties terug naar internet maken. Daardoor kan deze geen code downloaden anders dan via de inkomende connectie.
Op zich een goed advies, dat kan zeker helpen, maar exfiltratie is van nature veel lastiger te voorkomen dat infiltratie. Zeker als het om een "server" gaat, meestal een ding bedoeld om informatie aan internetters (al dan niet geauthenticeerd) te verstrekken.Echter in dit specifieke geval: waarom zou aanvullende malware en/of instructies niet via een inkomende connectie aangeleverd kunnen worden? Wellicht kan een aanvaller een remote shell achter een specifieke URL inrichten.
Los daarvan, het is lastig, maar bijv. via DNS kan vaak toch vertrouwelijke informatie vanuit een secure omgeving naar buiten "gepushed" (gelekt) worden. Zie, recent doch Duitstalig, http://www.heise.de/security/meldung/Infizierte-Bezahlterminals-umgehen-Firewalls-2427476.html of Engelstalig, uit 2012 http://www.sans.org/reading-room/whitepapers/dns/detecting-dns-tunneling-34152 en eveneens Engels, uit 2005: http://www.enyo.de/fw/software/dnslogger/first2005-paper.pdf.
Deze patch brengt ook nieuwe ciphersuites naar systemen ouder dan windows 8, namelijk AES-GCM(128 en 256 bit) met DHE_RSA en RSA key-exchange. Voorheen was alleen AES-GCM met ECDHE_ECDSA ondersteund.
Weet iemand of dit ook geldt als je webserver achter een reverse proxy hangt?
Uit http://news.softpedia.com/news/Critical-Flaw-in-Secure-Channel-Package-Affects-All-Windows-Versions-464757.shtml:
Mag ik hieruit opmaken dat je niet kwetsbaar bent voor deze bug als je een simpele cliënt bent die alleen maar wat op het web rondsurft, en daarbij geen "server software" draait die op specifieke poorten luistert en connecties van verschillende clients accepteert??? (en zou het dan nog verschil maken of je Internet Explorer gebruikt of een andere browser???)
The glitch consists in failure to properly filter specially-crafted packets in malicious traffic intended for a Windows server.
Workstation systems are also impacted by the flaw because they can run server software that listens to specific ports and accepts connections from different clients.
Workstation systems are also impacted by the flaw because they can run server software that listens to specific ports and accepts connections from different clients.
Mag ik hieruit opmaken dat je niet kwetsbaar bent voor deze bug als je een simpele cliënt bent die alleen maar wat op het web rondsurft, en daarbij geen "server software" draait die op specifieke poorten luistert en connecties van verschillende clients accepteert??? (en zou het dan nog verschil maken of je Internet Explorer gebruikt of een andere browser???)
13-11-2014, 14:20 door
[Account Verwijderd]
[Verwijderd]
Door Anoniem: Deze patch brengt ook nieuwe ciphersuites naar systemen ouder dan windows 8, namelijk AES-GCM(128 en 256 bit) met DHE_RSA en RSA key-exchange. Voorheen was alleen AES-GCM met ECDHE_ECDSA ondersteund.
Klopt, dank voor de melding!Voor de geïnteresseerden: in https://www.security.nl/posting/408406/Microsoft+brengt+encryptie+Windows+8_1+naar+oudere+versies#posting408414 heb ik nog eens beschreven hoe Diffie-Hellman (de "DH" in bovenstaande cipher suites) werkt en wat de voordelen zijn boven RSA key exchange.
Door Anoniem: Weet iemand of dit ook geldt als je webserver achter een reverse proxy hangt?
Dat hangt van de reverse proxy af. Gebruikelijk is dat reverse proxies SSL/TLS verbindingen "termineren", als volgt:[Clients] --> https --> { internet } --> https --> [Reverse Proxy] --> http --> [Web server]
In dat geval hangt het ervan af van welke "stack" op de reverse proxy gebruik gemaakt wordt. Als dat schannel is, is die reverse proxy kwetsbaar. Als dat (up-to-date) OpenSSL is, ben je in principe safe.
Een hopelijk idiote situatie kan ik echter niet uitsluiten, namelijk twee SSL/TLS "tunnels" in elkaar. De buitenste https laag wordt dan getermineerd door de reverse proxy. Normaal gesproken zou een webserver die SSL pakketjes op poort 80 ontvangt daar niets mee moeten doen, maar ik heb Microsoft software wel vaker zien "meedenken" (bijv. door bij het openen van bestanden niet naar de extensie maar naar de inhoud te kijken, en op basis daarvan in een ander programma te openen dan verwacht). Ik zou, voor de zekerheid, die webserver toch ASAP patchen.
Als je een reverse proxy gebruikt die geen SSL/TLS termination doet (het nut daarvan ontgaat me, bij links en rechts http verkeer kun je wel filteren e.d.), d.w.z. alle pakketjes transparant doorgeeft aan de webserver, is de webserver natuurlijk wel kwetsbaar en moet zeker worden gepatched.
[Clients] --> https --> { internet } --> https --> [Transparante Reverse Proxy] --> https --> [Web server]
Door Anoniem:
Mag ik hieruit opmaken dat je niet kwetsbaar bent voor deze bug als je een simpele cliënt bent die alleen maar wat op het web rondsurft, en daarbij geen "server software" draait die op specifieke poorten luistert en connecties van verschillende clients accepteert???
Nee, je bent -vermoedelijk- wel degelijk kwetsbaar. Een scenario: je zit op een terras van een restaurant en maakt verbinding met een open WiFi netwerk. Je start MSIE en surft naar https://www.security.nl/. Hoewel ik de details van mogelijke exploits nog niet ken, sluit ik niet uit dat een MitM (Man-in-the-Middle) aanvaller op dat moment, zich voordoend als www.security.nl, gemanipuleerde https pakketjes naar jouw PC kan sturen, en zo een remote exploit uitvoeren. Patchen dus!Workstation systems are also impacted by the flaw because they can run server software that listens to specific ports and accepts connections from different clients.
Mag ik hieruit opmaken dat je niet kwetsbaar bent voor deze bug als je een simpele cliënt bent die alleen maar wat op het web rondsurft, en daarbij geen "server software" draait die op specifieke poorten luistert en connecties van verschillende clients accepteert???
(en zou het dan nog verschil maken of je Internet Explorer gebruikt of een andere browser???)
Deels. Firefox gebruikt een eigen SSL stack, er wordt geen gebruik gemaakt van schannel als je daarmee surft. Echter, op de achtergrond kan jouw PC bijv. Windows Updates checken of virusdefintities ophalen. Hoewel dat soort zaken vaak grotendeels via http gebeuren (slechte zaak trouwens), is een klein deel wel degelijk https, en maakt gebruik van schannel. Ook kan een webpagina geopend in Firefox een filmpje aanbieden dat geopend wordt in Media Player - en die gebruikt natuurlijk weer schannel. Dus loop je, bijv. op een openbaar WiFi netwerk, nagenoeg dezelfde risico's als ik hierboven schetste.Vergelijkbare risico's loop je als jouw internetverbinding gerealiseerd wordt via een gehackte modem/router (die hoeft niet van jezelf te zijn, dit kan natuurlijk ook bij familie/vrienden gebeuren). Kortom, ook PC's moeten gepatched worden voor dit schannel lek!
Door Picasa3: @Erik van Straten. Als er exploits gemeld worden (en ik zo'n sampel in handen krijg) dan ben ik bereid om dit om de zoveel uur naar VirusTotal te uploaden.
Toppie, ik zie ze graag gemeld worden (maar hoop stilletjes dat het nog even duurt voor exploits gepubliceerd worden).Ook kan een webpagina geopend in Firefox een filmpje aanbieden dat geopend wordt in Media Player - en die gebruikt natuurlijk weer schannel.
Okee thanks! Alleen:1. Heb je hier geen activeX voor nodig, en die ondersteunt Firefox default toch niet?
2. Dus ook Media Player is
"server software that listens to specific ports and accepts connections from different clients."
(???)Door Erik van Straten:
Tuurlijk accepteert de firewall INKOMENDE connecties op poort 80 en 443 naar de webserver, maar waarom zou deDoor Anoniem: De webserver die ik beheer kan geen connecties terug naar internet maken. Daardoor kan deze geen code downloaden anders dan via de inkomende connectie.
Op zich een goed advies, dat kan zeker helpen, maar exfiltratie is van nature veel lastiger te voorkomen dat infiltratie. Zeker als het om een "server" gaat, meestal een ding bedoeld om informatie aan internetters (al dan niet geauthenticeerd) te verstrekken.webserver UITGAANDE connecties moeten kunnen maken? Dat staat dus dicht.
Dit is geen finale oplossing maar het is gewoon een van de vele maatregelen die je kunt nemen en die in de praktijk heel
goed werken. Alle exploits voor webserver bugs die ik gezien heb beginnen meteen om extra code op te halen met
wget, curl of whatever, en dat lukt dan dus niet.
Wat ook goed helpt is geen C compiler op je systeem, en als je het niet gebruikt geen Perl.
14-11-2014, 01:21 door
Erik van Straten
Door Anoniem:
1. Heb je hier geen activeX voor nodig, en die ondersteunt Firefox default toch niet?
Firefox ondersteunt inderdaad geen ActiveX, maar als je naar het plaatje in https://support.mozilla.org/en-US/kb/set-how-firefox-handles-different-file-types kijkt, zie je dat Firefox, afhakelijk van "Content type", wel degelijk voor Media Player kan kiezen. Plugins als Flash en Silverlight maken waarschijnlijk ook gebruik van schannel als zij zelf verbindingen opzetten.Ook kan een webpagina geopend in Firefox een filmpje aanbieden dat geopend wordt in Media Player - en die gebruikt natuurlijk weer schannel.
Okee thanks! Alleen:1. Heb je hier geen activeX voor nodig, en die ondersteunt Firefox default toch niet?
Door Anoniem: 2. Dus ook Media Player is
Hmm... waar Softpedia die specifieke kennis vandaan haalt, mag Joost weten."server software that listens to specific ports and accepts connections from different clients."
(???)Totdat alle details bekend zijn (als dat al ooit gebeurt) zou ik hier niet vanuit gaan. In https verbindingen zit potentieel meer symmetrie dan je misschien vermoedt, denk maar aan (optionele) client certificaten. Als jouw redenatie is "op mijn PC draai ik geen server software die luistert op specifieke poorten en die verbindingen aanneemt van verschillende clients, en daarom patch ik niet" (op basis van een advies van softpedia) dan lijk mij dat knap naïef - maar be my guest ;)
https://twitter.com/daveaitel/status/533064909387747328
LSASS eip control via ms14-066 + preauth RDP achieved in lab. Will be in CANVAS Early Updates tomorrow!!!
LSASS eip control via ms14-066 + preauth RDP achieved in lab. Will be in CANVAS Early Updates tomorrow!!!
14-11-2014, 11:08 door
Erik van Straten
Door Anoniem: https://twitter.com/daveaitel/status/533064909387747328
LSASS eip control via ms14-066 + preauth RDP achieved in lab. Will be in CANVAS Early Updates tomorrow!!!
Thanks, ik verwijs naar jouw bijdrage in de aanvullingen, onderin mijn artikel (bovenaan deze pagina).LSASS eip control via ms14-066 + preauth RDP achieved in lab. Will be in CANVAS Early Updates tomorrow!!!
Door Erik van Straten:
Net even aan Joost gevraagd, maar die info lijkt bij Qualys vandaan te komen:Door Anoniem: 2. Dus ook Media Player is
Hmm... waar Softpedia die specifieke kennis vandaan haalt, mag Joost weten."server software that listens to specific ports and accepts connections from different clients."
(???)http://arstechnica.com/security/2014/11/potentially-catastrophic-bug-bites-all-versions-of-windows-patch-now
Ook tweakers vermeldt:
"Servers die op Windows draaien zijn daarom het meest in gevaar voor de kwetsbaarheid, maar de kwetsbaarheid kan ook desktops en laptops treffen. Dat kan als ze software draaien die op een port luistert, bijvoorbeeld een ftp-server of de web-interface van een torrent-client."
Totdat alle details bekend zijn (als dat al ooit gebeurt) zou ik hier niet vanuit gaan. In https verbindingen zit potentieel meer symmetrie dan je misschien vermoedt, denk maar aan (optionele) client certificaten. Als jouw redenatie is "op mijn PC draai ik geen server software die luistert op specifieke poorten en die verbindingen aanneemt van verschillende clients, en daarom patch ik niet" (op basis van een advies van softpedia) dan lijk mij dat knap naïef - maar be my guest ;)
Your mystery "XP-guest"? ;) Ook verlengde XP support schijnt namelijk nog geen patch te hebben.Maar inderdaad: wie wel kan patchen moet dat natuurlijk doen.
Thanks again.
14-11-2014, 17:42 door
Erik van Straten
Door Anoniem: Net even aan Joost gevraagd, maar die info lijkt bij Qualys vandaan te komen:
http://arstechnica.com/security/2014/11/potentially-catastrophic-bug-bites-all-versions-of-windows-patch-now
Klopt, en daarin staat: http://arstechnica.com/security/2014/11/potentially-catastrophic-bug-bites-all-versions-of-windows-patch-now
Amol Sarwate, director of engineering at Qualys, told Ars the flaw leaves client machines open if users run software that monitors Internet ports and accepts encrypted connections.
Dat maakt het nog weer een stuk geloofwaardiger, want Qualys is een bedrijf dat klanten beschermt tegen dit soort exploits. Zeer waarschijnlijk krijgen zij, via nauwe banden met Microsoft, inside info. Anderzijds ben ik er huiverig voor om, in dit stadium, attack vectors uit te sluiten. Uitgewisselde informatie kan al snel, bewust of onbewust, vertroebelen.Door Anoniem: Ook tweakers vermeldt:
"Servers die op Windows draaien zijn daarom het meest in gevaar voor de kwetsbaarheid, maar de kwetsbaarheid kan ook desktops en laptops treffen. Dat kan als ze software draaien die op een port luistert, bijvoorbeeld een ftp-server of de web-interface van een torrent-client."
Ik vermoed dat RDP ook van schannel gebruik maakt. Aangezien de meeste Windows PC's standaard op poort 3389/tcp staan te luisteren heb je mogelijk al een vector te pakken."Servers die op Windows draaien zijn daarom het meest in gevaar voor de kwetsbaarheid, maar de kwetsbaarheid kan ook desktops en laptops treffen. Dat kan als ze software draaien die op een port luistert, bijvoorbeeld een ftp-server of de web-interface van een torrent-client."
In de meeste gevallen zal die poort niet vanaf internet bereikbaar zijn, maar wormen trekken zich daar meestal niet zoveel van aan. Nimda en Blaster wisten destijds (via "geïmporteerde" gecompromitteerde notebooks) systemen in veel van Internet gescheiden netwerken te infecteren, inclusief ATM's/pin-automaten (voorbeeld: http://www.securityfocus.com/news/7517).
Voor Snort zijn nieuwe rules uitgebracht die een indruk geven van de (nu bekende) exploit mogelijkeden, zie de aanvulling onderaan mijn artikel (bovenaan deze pagina).
Weet iemand of er een betrouwbare test is om te toetsen of een server vulnerable is? winshock-test.sh van github zegt nog steeds vulnerable, ook al is KB2992611 geinstalleerd en IIS herstart (of zelfs hele server gereboot).
2014-11-17 10:04 door Anoniem: Weet iemand of er een betrouwbare test is om te toetsen of een server vulnerable is? winshock-test.sh van github zegt nog steeds vulnerable, ook al is KB2992611 geinstalleerd en IIS herstart (of zelfs hele server gereboot).
Uit https://github.com/anexia-it/winshock-test:
Important
winshock_test.sh does behavioural analysis based upon the available SSL ciphers. If you either do not have direct access to the target system due to SSL-offloading in any form or manually modified the available SSL ciphers the script will be giving false positives.
winshock_test.sh does behavioural analysis based upon the available SSL ciphers. If you either do not have direct access to the target system due to SSL-offloading in any form or manually modified the available SSL ciphers the script will be giving false positives.
Sowieso zijn de nieuwe cipher-suites niet beschikbaar gemaakt voor Windows Server 2003 SP2 (of R2, wat daar nou de laatst ondersteunde versie van is weet ik ook niet meer). Dat betekent dat je met dit soort tools, d.w.z. die checken of de server de nieuwe cipher-suites ondersteunt, nooit een zinvol resultaat zult bereiken.
Aanvulling 2014-11-17 17:47: onderaan https://isc.sans.edu/forums/diary/SChannel+Update+and+Experimental+Vulnerability+Scanner+MS14-066/18953#32457, suggereert "nathan" dat Windows Server 2012 R2 de cipher-suites waar "winshock-test" op controleert, out-of-the-box al ondersteunt. Als dat klopt is dit geen veilige testmethode: de tool zal van een niet gepatchte server waarschijnlijk onterecht (false negative) melden dat deze niet kwetsbaar is!
Daar komt bij dat t.g.v. de optredende problemen met MS14-066/KB2992611, Microsoft zelf in https://support.microsoft.com/kb/2992611#MT1 adviseert om de nieuwe cipher-suites te disablen. Daarna kun je, met genoemde tools, die server natuurlijk ook niet meer testen.
Aangezien Microsoft (voor zover ik weet) nog nauwelijks details heeft vrijgegeven over alle onderliggende en gepatchte kwetsbaarheden, is het per defintitie onmogelijk om een tool te maken die test of al die kwetsbaarheden zijn gerepareerd. Ik verwacht niet dat je zo'n tool zult vinden.
Terzijde, veel experts zijn overigens ontstemd dat Microsoft kennelijk, voor meerdere gepatchte kwetsbaarheden, maar 1 CVE entry (CVE-2104-6321) heeft gebruikt. Zoals nu blijkt zijn er problemen met minstens 1 van de feitelijk uitgevoerde reparaties, het is zeer wenselijk als je zo'n specifieke fix met een uniek CVE nummer kunt identificeren, en dat gaat nu niet.
Microsoft had eerder aangekondigd haar beveiligingsafdeling te zullen reorganiseren. Het lijkt erop dat dit, zoals zo vaak het geval bij reorganisaties, tot collateral damage leidt. Ik meen een tweet gelezen te hebben van een voormalig lid van het Microsoft team dat betrokken is bij de uitrol van (en communicatie over) patches, waarin hij aangaf niet gelukkig te zijn met de nieuwe gang van zaken. Die tweet kan ik echter niet meer vinden.
Feit is dat de kwaliteit van Microsoft updates de laatste maanden nogal te wensen overlaat. En dat heeft grote gevolgen voor de bereidheid onder beheerders om snel (of überhaupt) te patchen, met alle risico's van dien. Dit gaat niet goed zo...
Aanvulling 2014-11-18 23:10: die tweet was van Dustin Childs.
Meer daarvoor, en over de kwaliteit van Microsoft patches de laatste tijd, zie https://www.security.nl/posting/408923/Microsoft+noodpatch+voor+kritiek+Windows+Server-lek#posting408983.
18-11-2014, 23:11 door
Erik van Straten
Bump: Microsoft heeft een update uitgebracht van MS14-066. Zie onderin mijn artikel bovenaan deze pagina.
19-11-2014, 13:49 door
eMilt
De update van MS14-066 die als KB301823 is uitgekomen (wordt nu samen met KB2992611 wordt geïnstalleerd of opnieuw aangeboden als KB2992611) wordt alleen aangeboden op Server 2008, Server 2008R2 en Server 2012, niet op Server 2012R2. Overigens ook niet op Server 2003(R2).
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
