image

Einde SHA-1 probleem voor Windows XP SP2 en Android 2.2

vrijdag 12 september 2014, 10:47 door Redactie, 6 reacties

Zowel Microsoft als Google zijn bezig om de ondersteuning van certificaten met het SHA-1-algoritme af te bouwen, wat vooral een probleem is voor gebruikers van Windows XP Service Pack 2 en Android versie 2.2 en ouder, omdat deze besturingssystemen geen nieuwere SHA-versies ondersteunen.

Het Secure Hash Algorithm (SHA) is een verzameling cryptografische hashfuncties ontworpen door de Amerikaanse National Security Agency (NSA) en gepubliceerd door het Amerikaanse National Institute of Standards and Technology (NIST). Volgens Google is het uitvoeren van collision-aanvallen tegen SHA-1 nu zo betaalbaar geworden dat dit niet meer te negeren valt. Bij een collision-aanval is het mogelijk om een vals SSL-certificaat te maken, waarbij de SHA-1-hash nog steeds overeenkomt met de hash van het legitieme certificaat dat door een Certificaat Autoriteit is uitgegeven.

Websites, organisaties en bedrijven krijgen dan ook het advies om hun SHA-1-certificaten te vervangen door SHA-256-certificaten. Zowel oudere serverplatformen zoals Windows Server 2003 als oudere clients ondersteunen standaard geen SHA-256 en kunnen dan ook tegen problemen aanlopen als deze certificaten straks worden gebruikt. Windows XP Service Pack 2 ondersteunt bijvoorbeeld geen SHA-256. Hetzelfde geldt voor Android 2.2 en ouder, dat op nog zeker 0,7% van de Android-toestellen is geïnstalleerd.

XP SP2-gebruikers kunnen naar Service Pack 3 upgraden, dat SHA-256 wel ondersteunt. Het upgraden voor Android-gebruikers kan lastiger zijn, afhankelijk of er voor hun toestel een upgrade naar Android 2.3 beschikbaar is. Beveiligingsbedrijf Qualys adviseert websites dan ook om gedurende de overgangsperiode SHA-256 als standaard aan te bieden en SHA-1 voor clients die SHA-256 niet ondersteunen. Volgens statistieken van het bedrijf gebruikte in september pas 15% van de websites een SHA-256-certificaat.

Reacties (6)
12-09-2014, 11:04 door Erik van Straten - Bijgewerkt: 12-09-2014, 11:05
Gezien alle plotselinge ophef zou het mij niet verbazen als er voor SHA1 een vergelijkbare aanval is ontdekt als gebruikt bij de Flame malware voor MD5 (zie o.a. http://arstechnica.com/security/2012/06/flame-crypto-breakthrough/), maar dat men details daarover niet durft te publiceren gezien het wijd verspreide gebruik van SHA1 en onze afhankelijkheid ervan. Het lijkt me verstandig om rekening te houden met dit scenario.

Ivan Ristic van Qualys verwijst in zijn advies naar een pagina van GlobalSign (een Certificate Service Provider) met een erg handig overzicht van besturingssystemen en software die SHA256 wel of (nog) niet ondersteunen, en bij welke toepassing: zie https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility (of dit 100% klopt weet ik niet, en op sommige plaatsen is nog sprake van software draaiend onder XP).

Wat mij bijzonder opviel in de GlobalSign pagina is dat Windows 7 m.b.t. code signing van kernel drivers niets beters dan SHA1 zou ondersteunen.

Hoewel bijv. XP SP3 (plus aanvullende patches, ik vermoed dat die nodig zijn) wel SSL server certificaten (dus voor https verbindingen) ondersteunt, worden lang niet alle andere certificaten die van SHA256 gebruikmaken ondersteund.

Van XP SP3, Vista en Server 2003 R2 was al bekend dat zij geen problemen met een code signing certificaat dat zelf gesignd is met SHA256 en een file die gesignd is met eveneens SHA256, maar dat er bij timestamp signatures die van SHA256 gebruik maken iets mis gaat. Zie de (lange) discussie opgestart door Spiff in https://www.security.nl/posting/386805.
12-09-2014, 11:37 door Erik van Straten - Bijgewerkt: 12-09-2014, 11:39
Veel Windows bestanden (waaronder .sys bestanden in C:\Windows\System32\Drivers\) lijken niet digitaal te zijn ondertekend; als je er met de rechter muistoets op klikt en voor Eigenschappen (Properties) kiest ontbreekt vaak een tabblad voor digitale handtekeningen.

Didier Stevens beschrijft in [1] dat die bestanden meestal zijn ondertekend middels een zogenaamde detached (ontkoppelde) signature, en dat je o.a. "SigCheck.exe" [2] van Mark Russinovich (SysInternals en Microsoft) kunt gebruiken om de signature te checken. Voorbeeld:

sigcheck -i c:\windows\system32\drivers\afd.sys

Het bovenstaande commando laat zien dat afd.sys (Ancillary Function Driver for WinSock) digitaal is ondertekend. Het laat ook zien waar de zogenaamde "catalog file" (met signatures) staat. Door "-i" worden alle betrokken certificaten getoond, en de daarin gebruikte hashes; op mijn Windows 7 x64 PC is dat in alle gevallen SHA1.

Belangrijk: wat in de output niet getoond wordt is het gebruikte hashalgoritme over de file zelf, noch het gebruikte hashalgoritime over een nog groter deel van het bestand dat is gebruikt voor de timestamp. Ik weet niet of signtool (naast sigcheck genoemd door Didier Stevens) deze informatie wel geeft.

Nb. afd.sys is met KB2961072 [3], een update van Juli 2014, nog bijgewerkt, en ik vermoed dat heel Windows Update nog van SHA1 aan elkaar hangt. Microsoft moet heel nodig aan de bak hiermee...

[1] http://blog.didierstevens.com/2008/01/11/the-case-of-the-missing-digital-signatures-tab/
[2] http://technet.microsoft.com/en-us/sysinternals/bb897441.aspx
[3] http://support.microsoft.com/kb/2961072
12-09-2014, 12:09 door Spiff has left the building
Door Erik van Straten, 11:04 uur:
Van XP SP3, Vista en Server 2003 R2 was al bekend dat zij geen problemen met een code signing certificaat dat zelf gesignd is met SHA256 en een file die gesignd is met eveneens SHA256, maar dat er bij timestamp signatures die van SHA256 gebruik maken iets mis gaat. Zie de (lange) discussie opgestart door Spiff in https://www.security.nl/posting/386805.
Dank je, Erik, voor die beschrijving en die verwijzing.
Ik vind je omschrijving een mooie aanduiding van de essentie van de bevindingen in die eerdere thread.
De discussie in die eerdere thread was extreem uitvoerig (zelfs Bitwiper zou niet weten waar te beginnen wat bits te wipen om die boel nog overzichtelijk te krijgen ;-) Geen zinnig mens zal daarom die eerdere thread nog gaan doornemen, daarom is je vermelding van de essentie zo prettig.
Ik heb je beschrijving daarom als aanvulling ingevoegd in de startpost van die eerdere thread, als "de Essentie".
Nogmaals bedankt.
12-09-2014, 13:55 door Anoniem
Hoe,is het dan als je Mullvad openvpn gebruikt i.s.m Tunnelclick?.
Via deze vpnserver wordt ook dit protocol gebruikt.
Dus ook zij moeten een andere methode kiezen om het internet te coderen.
12-09-2014, 20:24 door Briolet
Door Anoniem: i.s.m Tunnelclick?.

Het is Tunneblick'. Blick is Duits voor zicht. Dus in het Nederlands: Tunnelzicht. Dat maakt de naam ook logischer en makkelijker te onthouden.
12-09-2014, 23:19 door Anoniem
Geen probleem voor XP en Android, maar voor de standaard browsers. Naast upgraden kan je er natuurlijk ook gewoon een fatsoenlijke browser op gooien.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.