Probleem met certificaten

05-05-2014, 00:14 door Ilja. _V V

Ja, Spiff, ik had er zelf al wat over gelezen vorige week, moest het even opnieuw opzoeken omdat het een Microsoft https-pagina is & die worden niet opgeslagen in mijn geschiedenis.

Volgens mij zoek je naar dit:

https://support.microsoft.com/kb/2964759

Hop, hupemetdate, jij! ;-)

05-05-2014, 00:48 door Anoniem

Zo te zien zou het heel goed te maken kunnen hebben met die plotselinge tsunami van certificaten in april.
Maar heb je nu eigenlijk die "fixit" van http://support.microsoft.com/kb/2801679 al gedaan?
Komt zo te lezen neer op:
1. Backup registry maken
2. Delete registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates
Hiermee zouden dan alle Third-party Root Certication Authorities moeten worden gewist.
Vervolgens zou het systeem die zooi normaalgesproken via Windows Update weer fris en fruitig binnen moeten laden,
zoniet spontaan, dan maar geforceerd.
Afijn, lees de KB eerst eens goed door (voor zover dit nog niet is gedaan), met zonodig nog ergens een "second opinion"
just to be sure. Dan kun je verder zelf bepalen wat je doet. (at your own risk) Mvg, cluc-cluc

05-05-2014, 01:04 door Spiff has left the building - Bijgewerkt: 05-05-2014, 01:17

Door Ilja. _V V, 00:14 uur:

Volgens mij zoek je naar dit:
https://support.microsoft.com/kb/2964759
Hop, hupemetdate, jij! ;-)

Hai Ilja,
Dankjewel, maar wat bedoel je nu precies?
Dat EMET 4.1 op mijn systeem een probleem zou veroorzaken met de de verwerking van certificaten zoals ik dat hierboven heb beschreven en dat EMET 4.1 Update 1 dat verhelpt?
Op wat baseer je dat dan?
Welk aangrijpingsmechanisme van EMET?
Voor mij is dit alles nu eventjes nog zeer raadselachtig.

De EMET 4.1 Update 1 informatie vermeldt wel:
- Expired Certificate Trust rules are now highlighted in the user interface (UI).
- Expired Certificate Trust rules no longer trigger notification.
- Extends the expiration date for all default Certificate Trust rules to 8/1/2015.
Maar ik meen dat dat EMET's Certificate Trust bescherming voor te bezoeken websites betreft, en niet de certificaten die Windows gebruikt bij de beoordeling van de details van digitale handtekeningen van reeds gedownloade bestanden etc.

Of zie ik nu wat over het hoofd?

05-05-2014, 01:50 door Ilja. _V V

Volgens mij betreft het echt zowel een update als een Fix-It voor het probleem dat je beschrijft, & is 29 of 30 april j.l. uitgebracht, dacht ik. Omdat er nogal wat MS, TN & MSDN links in mijn geschiedenis zitten, plus een aantal daarvan niet in de lijst wegens https, is het lastig terugvinden. Bovendien is er nog niet veel over geschreven.

Ondertussen wel deze hervonden:

http://blogs.technet.com/b/srd/archive/2014/04/30/continuing-with-our-community-driven-customer-focused-approach-for-emet.aspx (met de Fix-It)
http://www.microsoft.com/en-us/download/details.aspx?id=41138 (downloadpagina, zie Details)

Gevonden via:

http://social.technet.microsoft.com/Forums/security/en-US/9b01619e-4349-4cef-b52c-1e50f0d7e838/how-to-update-emet-41-silentunattended-to-emet-41-update-1?forum=emet

Nog even mijn zoekstring:

https://www.google.nl/search?hl=nl&source=hp&q=site%3Amicrosoft.com+emet+versions+system+requirements&meta=&aq=f&oq

Kom je daar verder mee?

05-05-2014, 11:49 door Spiff has left the building - Bijgewerkt: 05-05-2014, 11:50

Door Anoniem, 00:48 uur:
heb je nu eigenlijk die "fixit" van http://support.microsoft.com/kb/2801679 al gedaan?
Komt zo te lezen neer op:
1. Backup registry maken
2. Delete registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates
Hiermee zouden dan alle Third-party Root Certication Authorities moeten worden gewist.
Vervolgens zou het systeem die zooi normaalgesproken via Windows Update weer fris en fruitig binnen moeten laden,
zoniet spontaan, dan maar geforceerd.

Bijzonder interessante tip, dankjewel.
Hoewel de genoemde problemen en ook de systemen waarop van toepassing niet overeenkomen met de mijne, zou de toegepaste oplossing toch wel eens kunnen werken.
Zeker waard om uit te proberen.

Door Anoniem, 00:48 uur:
zonodig nog ergens een "second opinion", just to be sure.

Ja, een "second opinion" zou geen kwaad kunnen.
Ik hoop dat de meedenkers en meelezers in deze thread zowel het probleem zoals ik dat beschreef in mijn startpost van deze thread en de genoemde Fix met het verwijderen van die registry key eens willen bekijken, en hun opinie willen geven.

05-05-2014, 12:07 door Spiff has left the building - Bijgewerkt: 05-05-2014, 12:09

Door Ilja. _V V, 01:50 uur:
Volgens mij betreft het echt zowel een update als een Fix-It voor het probleem dat je beschrijft, & is 29 of 30 april j.l. uitgebracht, dacht ik.

Met de Fix-It:
http://blogs.technet.com/b/srd/archive/2014/04/30/continuing-with-our-community-driven-customer-focused-approach-for-emet.aspx

Downloadpagina, zie Details:
http://www.microsoft.com/en-us/download/details.aspx?id=41138
Gevonden via:
http://social.technet.microsoft.com/Forums/security/en-US/9b01619e-4349-4cef-b52c-1e50f0d7e838/how-to-update-emet-41-silentunattended-to-emet-41-update-1?forum=emet

Hai Ilja,
Dankjewel opnieuw.
Hoewel ik nog steeds meen dat het genoemde probleem waar die fix voor bedoeld is niet overeenkomt met het mijne, maar specifiek van toepassing is op EMET's Certificate Trust bescherming voor te bezoeken websites en EMET's omgang met Root Certificate Authority regels, en enkel EMET's Certificate Trust configuration zal updaten, en niet de certificaten verzameld binnen Windows' beïnvloedt, kan het geen kwaad de Fix uit te voeren (of EMET te updaten, uiteraard).

Net zoals met de tip van Anoniem van 00:48 uur zijn "second opinions" welkom.
En uiteraard ook nog andere inzichten in en oplossingen bij het probleem zoals ik dat beschreef in mijn startpost van deze thread.

05-05-2014, 22:09 door Eric-Jan H te D

3B1EFD3A66EA28B16697394703A72CA340A05BD5
staat bij mij in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates
en betreft
Microsoft Root Certificate Authority 2010

"EMET Setup 4.1 u1.msi" verwijst bij mij naar
Microsoft Root Certificate Authority 2011
de hash
8F43288AD272F3103B6FB1428485EA3014C0BCFE
daarvan staat bij mij in de door jouw genoemde key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates

Het tussenliggende
Microsoft Code Signing PCA 2011
certificaat met hash
F252E794FE438E35ACE6E53762C0A234A2C52135
indien geïnstalleerd (hoeft niet)
staat ook in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates

05-05-2014, 22:22 door Spiff has left the building - Bijgewerkt: 05-05-2014, 22:50

Update

Inmiddels heb ik (na het aanmaken van een Herstelpunt en een Systeemimage) de fix die was getipt door Anoniem van 00:48 uur uitgevoerd:
http://support.microsoft.com/kb/2801679
Achtereenvolgens het exporteren en dan verwijderen van deze registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\
en vervolgens een reboot.
Dat ruimde lekker op na de overdaad aan certificaten die waren binnengebracht via het eerder uitgevoerde downloaden en installeren van "Update for Root Certificates for Windows Vista [November 2013] (KB931125)".
Er waren nu nog 13 certificaten over, in certmgr.msc, Certificate Manager, Certificaten.
Microsoft Root Certificate Authority 2011 ontbrak nu echter!
Na Windows Update was Microsoft Root Certificate Authority 2011 echter al weer terug, 14 certificaten in totaal nu.

Vervolgens heb ik de Fix it voor EMET 4.0 en 4.1 uitgevoerd, zoals getipt door Ilja:
https://support.microsoft.com/kb/2961016/en
Dat bracht het aantal certificaten onder Certificate Manager op 15.

Na nog een reboot en nogmaals Windows Update en na enige tijd ingelogd te zijn, is het aantal certificaten onder Certificate Manager nu opgelopen naar 23.

Echter:
de registry key met de SHA1 hash van Microsoft Root Certificate Authority 2010, zoals in genoemd door Erik van Straten:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\
3B1EFD3A66EA28B16697394703A72CA340A05BD5
die ontbreekt nog altijd!
En misschien ontbreken nóg een aantal sleutels? Het aantal certificaten onder Certificate Manager is inmiddels opgelopen naar 23, maar onder
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\
zijn op dit moment pas 'slechts' 16 sleutels aanwezig.
N.B.
Toegevoegde update binnen deze update:
Dat raadsel met het register is nu opgelost!
Zie de bijdrage van Eric-Jan H te A van 22:09 uur, hierboven (dat bericht had ik nog niet gezien toen ik de eerste versie van deze reactie schreef)
en zie mijn bijdrage van 22:44 uur, hieronder.

Controle van de digitale handtekening van de installatiebestanden van EMET 4.1 Update 1 of EMET 5.0 Tech Preview 2 levert echter nog steeds de foutmeldingen zoals vermeld in mijn startpost.

Om zot van te worden!

Opnieuw dan maar weer:
Hoe nu verder te zoeken naar eventueel een oorzaak, maar vooral naar een praktische en veilige oplossing, voor het probleem bij het checken van de details van de digitale handtekening van de EMET installers?

05-05-2014, 22:44 door Spiff has left the building

Door Eric-Jan H te A:
3B1EFD3A66EA28B16697394703A72CA340A05BD5
staat bij mij in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates
en betreft
Microsoft Root Certificate Authority 2010

Geweldig! Bij mij ook.
En daar staan ook de andere 6 die ik niet vond onder
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates
N.B.
Dat is dan betreffend de sleutel met de hash van "Microsoft Root Certificate Authority 2010" afwijkend van wat Erik van Straten aangaf betreffende de locatie daarvan.
N.B.
Eric-Jan H te A, met die hash op die registerlocatie ervaar jij anders dan ik geen problemen bij het checken van de details van de digitale handtekening van de EMET installers, neem ik aan?

Door Eric-Jan H te A:
"EMET Setup 4.1 u1.msi" verwijst bij mij naar
Microsoft Root Certificate Authority 2011
de hash
8F43288AD272F3103B6FB1428485EA3014C0BCFE
daarvan staat bij mij in de door jouw genoemde key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates

Ja, daar staat die bij mij ook.

Door Eric-Jan H te A:
Het tussenliggende
Microsoft Code Signing PCA 2011
certificaat met hash
F252E794FE438E35ACE6E53762C0A234A2C52135
indien geïnstalleerd (hoeft niet)
staat ook in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates

Die is bij mij niet aanwezig onder Certificate Manager en niet in het register.
Maar als die niet noodzakelijkerwijs geïnstalleerd hoeft te zijn, dan is dat geen probleem, neem ik aan.

Geweldig.
We schieten nu op.

Maar tegelijkertijd ben ik nu weer helemaal terug bij de vraag waarom op mijn systeem het checken van de details van de digitale handtekening van de EMET installers een foutmelding geeft, en hoe dit op te lossen.

05-05-2014, 23:28 door Spiff has left the building

En nog een kleine update:
Het aantal aanwezige certificaten onder Certificate Manager, Trusted Root Certification Authorities, dat loopt nog steeds zachtjes aan op. Inmiddels zijn het er 26, zie ik.

P.S.
Wat is er soms toch een moeite gedaan om Engelstalige standaard Windows-termen te vertalen naar Nederlands.
Trusted Root Certification Authorities Certificates heten in mijn Nederlandstalige Vista "Vertrouwde basiscertificeringsinstanties certificaten".
Het is soms handig om een Nederlandstalige Windows-versie te gebruiken bij communicatie met een andere gebruiker van een Nederlandstalige Windows-versie, maar bij issues zoals het certificaten-gedoe zoals in deze thread kan de Nederlandstalige terminologie af en toe nogal krompraterig en daarmee onduidelijk zijn.
Maar dit terzijde.

06-05-2014, 00:13 door Eric-Jan H te D

Met de door mij genoemde certificaten heb ik geen problemen met de verificatie van "EMET Setup 4.1 u1.msi".
De issuer is "Microsoft Code Signing PCA 2011" en de signing time is dinsdag ?29 ?april ?2014 19:43:45.

Windows 7 x64 HP EN

06-05-2014, 01:56 door Spiff has left the building - Bijgewerkt: 06-05-2014, 02:04

Door Eric-Jan H te A, 00:13 uur:
Met de door mij genoemde certificaten heb ik geen problemen met de verificatie van "EMET Setup 4.1 u1.msi".

Dank je. Dat nam ik al aan, maar het is fijn dat je het nog even bevestigde.
De vraag is dan wat op mijn systeem de factor is die dwarsligt.

Door Eric-Jan H te A, 00:13 uur:
De issuer is "Microsoft Code Signing PCA 2011"

Dat wordt bij mij ook netjes weergegeven.

Door Eric-Jan H te A, 00:13 uur:
en de signing time is dinsdag 29 april 2014 19:43:45.

En dat is hetgene dat op mijn Vista systeem om een of andere reden niet weergegeven kan worden, met die nieuwe EMET installers, en waardoor de digitale handtekening als ongeldig wordt weergegeven.

06-05-2014, 03:44 door Ilja. _V V

Nou, even doorgezocht, nu dus moe, vandaar rapport:

Zelf even de digitale handtekening van EMET 4.1 Update 1 geopend, & kreeg dezelfde foutmelding natuurlijk, & daarom het certificaat bekeken, details waar na enige tijd me dit opviel onder uitgebreid sleutelgebruik:

Handtekening bij programmacode (1.3.6.1.5.5.7.3.3)
Onbekend sleutelgebruik (1.3.6.1.4.1.311.76.8.1)

Dat heb ik weer even gecontroleerd in een Windows 7 installatie-bestand van DigitalRiver.com, & daar staat alleen Handtekening bij programmacode (1.3.6.1.5.5.7.3.3) in.

Als ik bij Microsoft op Onbekend sleutelgebruik ga zoeken, krijg ik dus een enorme lijst met gigantische handleidingen over certificaten, maar die of de code staat er niet bij, & de code zelf geeft nul resultaten. Ik kan ook de term Onbekend sleutelgebruik niet juist/goed naar het Engels vertalen. Best guess voor zover ik gelezen heb is dat degene die het certificaat gecreeerd heeft, te vroeg zijn/haar smartcard uit het werkstation getrokken heeft, zoiets.

Overigens nog een EMET-bug tegengekomen, geen onderwerp waard, alleen ter informatie: Op XP-systemen waarop een multi-boot met de Herstel-Console, zal bij het starten daarvan na de installatie van EMET de volgende foutmelding verschijnen:

INF-bestand txtsetup.sif is beschadigd of ontbreekt. Status: 14

Setup kan niet doorgaan.
Druk op een toets om het installatieproces af te sluiten.

Oplossing is de Herstel-Console even opnieuw installeren. Maar wel frappant.

06-05-2014, 09:14 door Erik van Straten

Door Ilja. _V V: Nou, even doorgezocht, nu dus moe, vandaar rapport:

Zelf even de digitale handtekening van EMET 4.1 Update 1 geopend, & kreeg dezelfde foutmelding natuurlijk, & daarom het certificaat bekeken, details waar na enige tijd me dit opviel onder uitgebreid sleutelgebruik:

Handtekening bij programmacode (1.3.6.1.5.5.7.3.3)
Onbekend sleutelgebruik (1.3.6.1.4.1.311.76.8.1)

In Win7 64 zie ik ook "Unknown Key Usage (1.3.6.1.4.1.311.76.8.1)" als ik naar het code signing certificaat van EMET 4.1 Update 1 kijk, maar dit leidt niet tot het afkeuren van de Authenticode signature, en dit lijkt niets te maken te hebben met het probleem dat Spiff meldde (weigeren van het time stamping certificaat).

Met wat zoeken vond ik http://www.alex-ionescu.com/?p=146 getiteld "Protected Processes Part 3 : Windows PKI Internals (Signing Levels, Scenarios, Root Keys, EKUs & Runtime Signers)".

Halverwege die pagina, onder "EKU to Signing Level Mapping", staat een tabel waarin helaas in elke OID (Object ID, zo'n 1.3.6... nummer) ".1" is weggevallen. In plaats van
1.3.6.1.4.1.311.76.8.1 Microsoft Publisher
staat er
1.3.6.1.4.311.76.8.1 Microsoft Publisher

Volgens de blog van Alex Ionescu zijn dit OID's gebruikt onder Windows 8 en later.

In http://support.microsoft.com/kb/287547 kun je zien dat 1.3.6.1.4.1.311 is toegekend aan Microsoft.

Door Spiff:

Door Eric-Jan H te A:
3B1EFD3A66EA28B16697394703A72CA340A05BD5 staat bij mij in
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\ROOT\Certificates en betreft Microsoft Root Certificate Authority 2010

Geweldig! Bij mij ook.
En daar staan ook de andere 6 die ik niet vond onder
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates
N.B. Dat is dan betreffend de sleutel met de hash van "Microsoft Root Certificate Authority 2010" afwijkend van wat Erik van Straten aangaf betreffende de locatie daarvan.

De reden voor het bestaan van zowel de ROOT als de AuthRoot subkeys is mij niet duidelijk (historische redenen?), in certmgr.msc worden deze "bij elkaar opgeteld" als ik onder "Trusted Root Certification Authorities" kijk en vermoedelijk gelijkwaardig behandeld (onder "Third-Party Root Certification Authorities" zie ik uitsluitend de certificaten uit AuthRoot).

Door Spiff:

Door Eric-Jan H te A:
Het tussenliggende Microsoft Code Signing PCA 2011 certificaat met hash F252E794FE438E35ACE6E53762C0A234A2C52135 indien geïnstalleerd (hoeft niet) staat ook in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates

Die is bij mij niet aanwezig onder Certificate Manager en niet in het register.
Maar als die niet noodzakelijkerwijs geïnstalleerd hoeft te zijn, dan is dat geen probleem, neem ik aan.

Deze staat bij mij in HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates\CA\Certificates\F252E794FE438E35ACE6E53762C0A234A2C52135 en zie ik in certmgr.msc terug onder "Intermediate Certification Authorities". Belangrijk hierbij is dat je wel ingelogd met het juiste account moet kijken!

@Spiff: als CAPI2 eventlogs geen indicatie geven over wat er mis is en je problemen met certificaten blijft houden, raad ik je aan je systeem opnieuw te installeren, zeker als je de PC ook gebruikt voor internetbankieren e.d.

06-05-2014, 09:58 door Fwiffo

Hoi Spiff. Ik had al eerder kunnen reageren, maar jouw probleem is geen probleem eigenlijk.
Wat doet die handtekening nu eigenlijk: Het laat jou weten dat EMET 4.1u1 bij Microsoft vandaan komt. Maar dat wist je al omdat Erik dat in de vorige thread onder Windows 7 gecontroleerd heeft. Die handtekening klopt dus!

Ik heb gisteren ook EMET 4.1u1 gedownload (ben niet van plan die te installeren om andere redenen) en kreeg de volgende SHA-1 hash:

gpg --print-md sha1 "EMET Setup.msi"
EMET Setup.msi: 3DA9 3A83 D318 D440 1DD1 AF1A 3A81 CA96 3F7C 72B8

Nog steeds virusvrij volgens F-Secure onder Windows Vista 32bits. Erik had in de vorige thread dezelfde SHA-1. Dus wat zijn de kansen dat jij een andere op je computer hebt gedownload?!

Ik heb dus Vista 32 bits Engels en kan je de Engelse meldingen geven.
[1] Digital Signature Information
This digital signature is not valid.
Ik heb geen timestamp in het onderste venster.

[2] Certificate Information
The digital signature of the object did not verify.
Issued to: Microsoft Corporation
Issued by: Microsoft Code Signing PCA 2011
Valid from 24-9-2013 to 24-12-2014

De drie certificaten in de Certification Path zijn stuk voor stuk 'OK'.

Wat aan de hand is is dat Vista gewoon strenger is in de controle van digitale handtekeningen als XP en Windows 7 en dat de controle daardoor mislukt. Maar je weet:
[1] Er zit geen virus in EMET 4.1u1
[2] Hij is hetzelfde als door anderen gedownload is
[3] De handtekening is juist op de andere systemen

Zelf heb ik hem via links in de blogs van Microsoft gedownload als ik mij goed herinner.
Deze download is gewoon goed en veilig! Alleen de signature (die pas op het laatst is toegevoegd) is onjuist onder Vista. Geen probleem tenzij Vista gaat klagen hierover bij het installeren.

Slordig is het wel van Microsoft. Dat zeker.

06-05-2014, 13:57 door Spiff has left the building

Ilja. _V V, Erik van Straten, en Fwiffo,
Heel hartelijk bedankt voor jullie bijdragen en analyses van vanochtend.

Allereerst -
Opvallend dat ook Ilja en Fwiffo dezelfde foutmelding als ik krijgen bij het controleren van de EMET 4.1u1 handtekening,

Door Ilja. _V V, 03:44 uur:
Zelf even de digitale handtekening van EMET 4.1 Update 1 geopend, & kreeg dezelfde foutmelding natuurlijk

Door Fwiffo:
Vista 32 bits
This digital signature is not valid.
geen timestamp in het onderste venster.

Fwiffo eveneens op een Vista 32 bit systeem.
En Ilja? Was dat ook met een Vista systeem, of was dat je XP systeem, of een Win7 of Win8 systeem?

Door Erik van Straten, 09:14 uur:

Door Spiff:

Door Eric-Jan H te A:
Het tussenliggende Microsoft Code Signing PCA 2011 certificaat met hash F252E794FE438E35ACE6E53762C0A234A2C52135 indien geïnstalleerd (hoeft niet) staat ook in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates

Die is bij mij niet aanwezig onder Certificate Manager en niet in het register.
Maar als die niet noodzakelijkerwijs geïnstalleerd hoeft te zijn, dan is dat geen probleem, neem ik aan.

Deze staat bij mij in
HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates\CA\Certificates\
F252E794FE438E35ACE6E53762C0A234A2C52135
en zie ik in certmgr.msc terug onder "Intermediate Certification Authorities".

Ja, gevonden, dankjewel.

Door Erik van Straten, 09:14 uur:
@Spiff: als CAPI2 eventlogs geen indicatie geven over wat er mis is en je problemen met certificaten blijft houden, raad ik je aan je systeem opnieuw te installeren, zeker als je de PC ook gebruikt voor internetbankieren e.d.

Ik internetbankier niet, dus dat is niet het probleem.
Maar ik vrees het het evenzeer van belang kan zijn bij de heel enkele keer dat ik een aankoop betaal door middel van PayPal of creditcardinformatie doorgeef bij een aankoop? Of betreft dat een ander gebruik van certificaten?

Het feit dat Ilja en Fwiffo dezelfde foutmelding als ik krijgen bij het controleren van de EMET 4.1u1 handtekening ("This digital signature is not valid" en geen timestamp in het onderste venster), dat geeft uiteraard te denken.
Is er werkelijk wel wat mis met mijn installatie, of is er mogelijk standaard iets afwijkends met de controle van digitale handtekeningen onder Vista, dat hierbij nu pas aan het licht komt?
Of is er zowel met mijn, Iljas, en Fwiffos systeem wat mis?

De uitkomst daarvan gaat bepalen hoe hard het nodig wordt dat ik binnenkort mijn systeem ga herinstalleren.
(Ik had al lang plannen voor een nieuwe installatie, met Win7, en op nieuwe HDD's, dat ligt al lang gereed, maar door ontbrekende noodzaak en beslist een ontbrekend overschot aan beschikbare tijd en puf is dat plan altijd nog steeds blijven liggen.)

Door Erik van Straten, 09:14 uur:
als CAPI2 eventlogs geen indicatie geven over wat er mis is

Ik weet nog niet of die logs geen indicatie geven over wat er mis is.
Een flink deel van de informatie weet ik niet te interpreteren.
Misschien kan jij of kunnen jullie er wel wat mee?
Zal ik die logdetails eens hier posten?
Zo ja, in de beschrijvende weergave, of in de XML-weergave, of wellicht het beste allebei?
Zijn er standaard bepaalde elementen die weergegeven worden in die logs die ik veiligheidshalve niet online moet plaatsen?
Computernaam, gebruikersnaam, en Security UserID, die kan ik in ieder geval verwijderen voor het posten, maar staat er standaard mogelijk nog meer in die beschrijvende weergave en in de XML-weergave dat beter niet hier gepost kan worden?

Door Fwiffo, 09:58 uur:
Ik heb dus Vista 32 bits Engels en kan je de Engelse meldingen geven.
[1] Digital Signature Information
This digital signature is not valid.
Ik heb geen timestamp in het onderste venster.
[2] Certificate Information
The digital signature of the object did not verify.
Issued to: Microsoft Corporation
Issued by: Microsoft Code Signing PCA 2011
Valid from 24-9-2013 to 24-12-2014
De drie certificaten in de Certification Path zijn stuk voor stuk 'OK'.

Dank je. Bij mij idem.
Handig om nu die meldteksten ook in het Engels beschikbaar te hebben.

Door Fwiffo, 09:58 uur:
Wat aan de hand is is dat Vista gewoon strenger is in de controle van digitale handtekeningen als XP en Windows 7 en dat de controle daardoor mislukt.

Zou dat het zijn?

Door Fwiffo, 09:58 uur:
Deze download is gewoon goed en veilig!

Dat is duidelijk.

Door Fwiffo, 09:58 uur:
Alleen de signature (die pas op het laatst is toegevoegd) is onjuist onder Vista.

De oorzaak daarvan is echter nog onduidelijk.

Door Fwiffo, 09:58 uur:
Geen probleem tenzij Vista gaat klagen hierover bij het installeren.

Dat zal ik binnenkort een keer gaan merken, ik ben benieuwd.

06-05-2014, 15:42 door Ilja. _V V

Spiff: Net even nagekeken, & de fout doet zich bij mij alleen voor op XP (P - 32bits) & Vista (HP - 32bits), op Windows 7 (U - 32bits) staat er Deze digitale handtekening is in orde, maar de Onbekende sleutel staat wel in de Details van het certificaat.

Erik van Straten: Dat zocht ik! Kom er trouwens net achter dat mijn Vista in het Engels is...
Is dat een typo of word die "1" expres weggelaten omdat het tot de eerste lijst bovenaan behoort, Windows 8.1 Signing Levels?
Ik zie die EKU ook niet in de MS KB, die springt van 311.45 naar 311.88.

Het lijkt erop dat de certificaten zijn geschreven voor 7/8.x. Wat ik (vannacht) zover heb gelezen over certificaten, is dat als Vista of Xp een ongeldigheid of beschadiging vinden & daardoor niet kunnen verifieren, het certificaat afgekeurd word.

06-05-2014, 16:11 door Spiff has left the building

Door Ilja. _V V, 15:42 uur:
Spiff: Net even nagekeken, & de fout doet zich bij mij alleen voor op XP (P - 32bits) & Vista (HP - 32bits),
op Windows 7 (U - 32bits) staat er Deze digitale handtekening is in orde, maar de Onbekende sleutel staat wel in de Details van het certificaat.
[...]
Het lijkt erop dat de certificaten zijn geschreven voor 7/8.x. Wat ik (vannacht) zover heb gelezen over certificaten, is dat als Vista of Xp een ongeldigheid of beschadiging vinden & daardoor niet kunnen verifieren, het certificaat afgekeurd word.

Dank je, Ilja.
Zou je misschien kunnen aangeven wat de bron of bronnen waren die je gevonden had die dat verschil in certificaatverwerking van XP+Vista en Win7+8 vermelden?

En kun je misschien ook aangeven (of iemand anders, uiteraard) aan wat voor soort merkwaardigheid in de ondertekening van die nieuwste EMET installers het dan zou kunnen liggen dat Vista (en XP) daarin niet de timestamp kunnen herkennen en de ondertekening daarom als ongeldig beschouwen?

Vista deed nog netjes mee, vond ik, maar dit soort rarigheidjes zijn toch wel wat irritant.

06-05-2014, 16:32 door Ilja. _V V

Dat word beschreven aan het begin in de link die Erik van Straten al gaf: http://www.alex-ionescu.com/?p=146
Blijkbaar is dat wel doorgevoerd in 7, maar niet in oudere versies.

06-05-2014, 16:59 door Anoniem

Gisteren EMET 4.1 update 1 geinstalleerd op een computer die op windows 7 draait. Echter krijg ik de melding dat er onvoldoende gegevens zijn on het certificaat Te controlleren.

06-05-2014, 17:28 door Spiff has left the building

Door Ilja. _V V:
Dat word beschreven aan het begin in de link die Erik van Straten al gaf: http://www.alex-ionescu.com/?p=146
Blijkbaar is dat wel doorgevoerd in 7, maar niet in oudere versies.

Ha, dank je, Ilja.
Ik had dat stuk vanochtend alleen even vluchtig doorgenomen in verband met die Object ID nummers.
Informatie over het verschil in certificaatverwerking van XP+Vista en Win7+8 was me toen nog niet opgevallen.
Ik zal het stuk straks/vanavond even goed bekijken.

06-05-2014, 21:20 door Spiff has left the building

Aan het bestuderen van dat artikel van Alex Ionescu’s blog, waarvan Ilja aangaf dat dat weergeeft dat de certificaatverwerking van XP en Vista anders is dan die van Win7 en Win8, daaraan ben ik nog niet toegekomen, hopelijk later vanavond.
Maar wel is hier een nieuw feitje en vraagje:
Ik heb net zowel de web-installer als de offline installer voor Microsoft .NET Framework 4.5.2 gedownload.
De digitale handtekening en de timestamp daarvan wordt gewoon keurig herkend.
Wat is er dan zo afwijkend aan de recente EMET installers?

06-05-2014, 23:43 door Anoniem

Door Spiff: Aan het bestuderen van dat artikel van Alex Ionescu’s blog, waarvan Ilja aangaf dat dat weergeeft dat de certificaatverwerking van XP en Vista anders is dan die van Win7 en Win8, daaraan ben ik nog niet toegekomen, hopelijk later vanavond.
Maar wel is hier een nieuw feitje en vraagje:
Ik heb net zowel de web-installer als de offline installer voor Microsoft .NET Framework 4.5.2 gedownload.
De digitale handtekening en de timestamp daarvan wordt gewoon keurig herkend.
Wat is er dan zo afwijkend aan de recente EMET installers?

Spiff, wat ik zojuist heb ontdekt is dat het EMET4.1 installatiebestand toch duidelijk anders is ondertekend dan bijv. het EMET3.0 of EMET4.0 installatiebestand.
In Windows XP (32-bit) zie ik de volgende verschillen:

1.Verschillen in het certificeringspad.
Voor EMET3.0/EMET4.0 is dit pad:
Microsoft Root Certificate Authority ->
Microsoft Code Signing PCA ->
Micosoft Corporation

maar voor EMET4.1 is het pad:
Microsoft Root Certificate Authority 2011 ->
Microsoft Code Signing PCA 2011 ->
Micosoft Corporation

2. Voor EMET3.0/EMET4.0 is een controlehandtekening aanwezig van "Microsoft Time-Stamp Service".
Maar voor EMET4.1 is er GEEN ENKELE controlehandtekening aanwezig (veld is leeg!)

Mogelijk dat dit laatste dus veroorzaakt dat de hele digitale ondertekening van EMET4.1 wordt afgekeurd.
Want ga je namelijk naar "Certificaat weergeven" -> "Certificeringspad",
dan geven alle drie items in het pad na aanklikken gewoon: "Dit certificaat is in orde".
(tip: bij de bovenste twee items even opnieuw op "Certificaat weergeven" klikken, en dan weer op "Certificeringspad")
Misschien dat jij dit in Vista ook kunt zien en reproduceren?

Conclusie: óf MS heeft die zogenaamde "controlehandtekening" hier domweg vergeten, óf er wordt een andere manier van digitaal ondertekenen gebruikt bij het EMET4.1-bestand, die incompatible is met een ouder OS.

(b.t.w.: voor de gein heb ik de installatiebestanden ook even onder het antieke Windows Millenium bekeken, en dan blijkt
dat een "digitale handtekening"-tab bij EMET4.1 in zijn geheel ontbreekt!!! (wel aanwezig bij de andere twee))

Mvg, cluc-cluc

06-05-2014, 23:44 door Spiff has left the building

Door Erik van Straten, 09:14 uur:
als CAPI2 eventlogs geen indicatie geven over wat er mis is

Door Spiff, 13:57 uur:
Ik weet nog niet of die logs geen indicatie geven over wat er mis is.
Een flink deel van de informatie weet ik niet te interpreteren.
Misschien kan jij of kunnen jullie er wel wat mee?
Zal ik die logdetails eens hier posten?

Hieronder de CAPI2 eventlogs
voor het checken van de details van de digitale handtekeningen van EMET [4.1u1] Setup.msi.
In de hoop dat iemand er iets wetenswaardigs uit kan afleiden.

Achtereenvolgens vier logs met het niveau "Informatie",
en het laatste, vijfde log, met het niveau "Fout".

(N.B. "url"-aanduidingen heb ik vervangen door "ur|", omdat anders de weergave in de soep loopt doordat url tussen haken als BBcode wordt gelezen.)

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

- System

- Provider

[ Name] Microsoft-Windows-CAPI2
[ Guid] {5bbca4a8-b209-48dc-a8c7-b23d3e5216fb}

EventID 41

Version 0

Level 4

Task 41

Opcode 2

Keywords 0x8000000000000005

- TimeCreated

[ SystemTime] 2014-05-06T21:00:10.110Z

EventRecordID 185253

Correlation

- Execution

[ ProcessID] 3704
[ ThreadID] 12184

Channel Microsoft-Windows-CAPI2/Operational

Computer XXXXXXX

- Security

[ UserID] XXXXXXX

- UserData

- CertVerifyRevocation

- Certificate

[ fileRef] F252E794FE438E35ACE6E53762C0A234A2C52135.cer
[ subjectName] Microsoft Code Signing PCA 2011

- IssuerCertificate

[ fileRef] 8F43288AD272F3103B6FB1428485EA3014C0BCFE.cer
[ subjectName] Microsoft Root Certificate Authority 2011

- Flags

[ value] 0

- AdditionalParameters

[ timeToUse] 2014-05-06T21:00:10.094Z
[ currentTime] 2014-05-06T21:00:10.110Z
[ urlRetrievalTimeout] PT15S

- RevocationStatus

[ index] 0
[ error] 0
[ reason] 0
[ actualFreshnessTime] P51DT2H14M45S

- CertificateRevocationList

[ location] TvoCache
[ ur|] http://crl.microsoft.com/pki/crl/products/MicRooCerAut2011_2011_03_22.crl
[ fileRef] EB51DE8F544732860A34FDDB7FFA608AE65681FC.crl
[ issuerName] Microsoft Root Certificate Authority 2011

- EventAuxInfo

[ ProcessName] Explorer.EXE

- CorrelationAuxInfo

[ TaskId] {89359956-E4EF-4A3F-8D9A-436AC2BD8BE4}
[ SeqNumber] 4

- Result

[ value] 0

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

- System

- Provider

[ Name] Microsoft-Windows-CAPI2
[ Guid] {5bbca4a8-b209-48dc-a8c7-b23d3e5216fb}

EventID 41

Version 0

Level 4

Task 41

Opcode 2

Keywords 0x8000000000000005

- TimeCreated

[ SystemTime] 2014-05-06T21:00:10.110Z

EventRecordID 185255

Correlation

- Execution

[ ProcessID] 3704
[ ThreadID] 12184

Channel Microsoft-Windows-CAPI2/Operational

Computer XXXXXXX

- Security

[ UserID] XXXXXXX

- UserData

- CertVerifyRevocation

- Certificate

[ fileRef] 6474839AF67AB79C91007FF62FE08E2ACF016B83.cer
[ subjectName] Microsoft Corporation

- IssuerCertificate

[ fileRef] F252E794FE438E35ACE6E53762C0A234A2C52135.cer
[ subjectName] Microsoft Code Signing PCA 2011

- Flags

[ value] 0

- AdditionalParameters

[ timeToUse] 2014-05-06T21:00:10.094Z
[ currentTime] 2014-05-06T21:00:10.110Z
[ urlRetrievalTimeout] PT15S

- RevocationStatus

[ index] 0
[ error] 0
[ reason] 0
[ actualFreshnessTime] P51DT2H3M4S

- CertificateRevocationList

[ location] TvoCache
[ ur|] http://www.microsoft.com/pkiops/crl/MicCodSigPCA2011_2011-07-08.crl
[ fileRef] 5C7A33B1CD5AE5ACEA73BF8576E537F9E7244DDD.crl
[ issuerName] Microsoft Code Signing PCA 2011

- EventAuxInfo

[ ProcessName] Explorer.EXE

- CorrelationAuxInfo

[ TaskId] {89359956-E4EF-4A3F-8D9A-436AC2BD8BE4}
[ SeqNumber] 6

- Result

[ value] 0

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

- System

- Provider

[ Name] Microsoft-Windows-CAPI2
[ Guid] {5bbca4a8-b209-48dc-a8c7-b23d3e5216fb}

EventID 11

Version 0

Level 4

Task 11

Opcode 2

Keywords 0x8000000000000003

- TimeCreated

[ SystemTime] 2014-05-06T21:00:10.110Z

EventRecordID 185256

Correlation

- Execution

[ ProcessID] 3704
[ ThreadID] 12184

Channel Microsoft-Windows-CAPI2/Operational

Computer XXXXXXX

- Security

[ UserID] XXXXXXX

- UserData

- CertGetCertificateChain

- Certificate

[ fileRef] 6474839AF67AB79C91007FF62FE08E2ACF016B83.cer
[ subjectName] Microsoft Corporation

ValidationTime 2014-05-06T21:00:10.094Z

- AdditionalStore

- Certificate

[ fileRef] F252E794FE438E35ACE6E53762C0A234A2C52135.cer
[ subjectName] Microsoft Code Signing PCA 2011

- Certificate

[ fileRef] 6474839AF67AB79C91007FF62FE08E2ACF016B83.cer
[ subjectName] Microsoft Corporation

- ExtendedKeyUsage

- Usage

[ oid] 1.3.6.1.5.5.7.3.3
[ name] Handtekening bij programmacode

- Flags

[ value] 40000001
[ CERT_CHAIN_CACHE_END_CERT] true
[ CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT] true

- ChainEngineInfo

[ context] user

- CertificateChain

[ chainRef] {C92488BE-76D0-4593-95D9-C328480D7978}
[ revocationFreshnessTime] P51DT2H14M45S
- TrustStatus

- ErrorStatus

[ value] 0

- InfoStatus

[ value] 100
[ CERT_TRUST_HAS_PREFERRED_ISSUER] true

- ChainElement

- Certificate

[ fileRef] 6474839AF67AB79C91007FF62FE08E2ACF016B83.cer
[ subjectName] Microsoft Corporation

- TrustStatus

- ErrorStatus

[ value] 0

- InfoStatus

[ value] 102
[ CERT_TRUST_HAS_KEY_MATCH_ISSUER] true
[ CERT_TRUST_HAS_PREFERRED_ISSUER] true

- ApplicationUsage

- Usage

[ oid] 1.3.6.1.5.5.7.3.3
[ name] Handtekening bij programmacode

- Usage

[ oid] 1.3.6.1.4.1.311.76.8.1

IssuanceUsage

- RevocationInfo

[ freshnessTime] P51DT2H3M4S
- RevocationResult

[ value] 0

- CertificateRevocationList

[ location] TvoCache
[ ur|] http://www.microsoft.com/pkiops/crl/MicCodSigPCA2011_2011-07-08.crl
[ fileRef] 5C7A33B1CD5AE5ACEA73BF8576E537F9E7244DDD.crl
[ issuerName] Microsoft Code Signing PCA 2011

- ChainElement

- Certificate

[ fileRef] F252E794FE438E35ACE6E53762C0A234A2C52135.cer
[ subjectName] Microsoft Code Signing PCA 2011

- TrustStatus

- ErrorStatus

[ value] 0

- InfoStatus

[ value] 102
[ CERT_TRUST_HAS_KEY_MATCH_ISSUER] true
[ CERT_TRUST_HAS_PREFERRED_ISSUER] true

- ApplicationUsage

[ any] true

- IssuanceUsage

- Usage

[ oid] 1.3.6.1.4.1.311.46.3

- RevocationInfo

[ freshnessTime] P51DT2H14M45S
- RevocationResult

[ value] 0

- CertificateRevocationList

[ location] TvoCache
[ ur|] http://crl.microsoft.com/pki/crl/products/MicRooCerAut2011_2011_03_22.crl
[ fileRef] EB51DE8F544732860A34FDDB7FFA608AE65681FC.crl
[ issuerName] Microsoft Root Certificate Authority 2011

- ChainElement

- Certificate

[ fileRef] 8F43288AD272F3103B6FB1428485EA3014C0BCFE.cer
[ subjectName] Microsoft Root Certificate Authority 2011

- TrustStatus

- ErrorStatus

[ value] 0

- InfoStatus

[ value] 10C
[ CERT_TRUST_HAS_NAME_MATCH_ISSUER] true
[ CERT_TRUST_IS_SELF_SIGNED] true
[ CERT_TRUST_HAS_PREFERRED_ISSUER] true

- ApplicationUsage

[ any] true

- IssuanceUsage

[ any] true

- EventAuxInfo

[ ProcessName] Explorer.EXE

- CorrelationAuxInfo

[ TaskId] {89359956-E4EF-4A3F-8D9A-436AC2BD8BE4}
[ SeqNumber] 7

- Result

[ value] 0

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

- System

- Provider

[ Name] Microsoft-Windows-CAPI2
[ Guid] {5bbca4a8-b209-48dc-a8c7-b23d3e5216fb}

EventID 90

Version 0

Level 4

Task 90

Opcode 0

Keywords 0x8000000000000200

- TimeCreated

[ SystemTime] 2014-05-06T21:00:10.110Z

EventRecordID 185257

Correlation

- Execution

[ ProcessID] 3704
[ ThreadID] 12184

Channel Microsoft-Windows-CAPI2/Operational

Computer XXXXXXX

- Security

[ UserID] XXXXXXX

- UserData

- X509Objects

- Certificate

[ fileRef] 6474839AF67AB79C91007FF62FE08E2ACF016B83.cer
[ subjectName] Microsoft Corporation
- Subject

CN Microsoft Corporation

OU MOPR

O Microsoft Corporation

L Redmond

S Washington

C US

- SubjectKeyID

[ computed] false
[ hash] 242B3DCA909C9E2875723CCF0CB33DE6AC245659

- Issuer

CN Microsoft Code Signing PCA 2011

O Microsoft Corporation

L Redmond

S Washington

C US

SerialNumber 330000001A77BB74B307D116B800000000001A

NotBefore 2013-09-24T17:41:41Z

NotAfter 2014-12-24T17:41:41Z

- Extensions

- ExtendedKeyUsage

- Usage

[ oid] 1.3.6.1.5.5.7.3.3
[ name] Handtekening bij programmacode

- Usage

[ oid] 1.3.6.1.4.1.311.76.8.1

- SubjectAltName

- DirectoryName

SERIALNUMBER 31642+2860b52e-c4a3-454d-bc1e-32c5add17e90

OU MOPR

- AuthorityKeyIdentifier

- KeyID

[ hash] 486E64E55005D382AA17373722B56DA8CA750295

- BasicConstraints

[ critical] true
[ cA] false

- Certificate

[ fileRef] F252E794FE438E35ACE6E53762C0A234A2C52135.cer
[ subjectName] Microsoft Code Signing PCA 2011
- Subject

CN Microsoft Code Signing PCA 2011

O Microsoft Corporation

L Redmond

S Washington

C US

- SubjectKeyID

[ computed] false
[ hash] 486E64E55005D382AA17373722B56DA8CA750295

- Issuer

CN Microsoft Root Certificate Authority 2011

O Microsoft Corporation

L Redmond

S Washington

C US

SerialNumber 610E90D2000000000003

NotBefore 2011-07-08T20:59:09Z

NotAfter 2026-07-08T21:09:09Z

- Extensions

- KeyUsage

[ value] 86
[ CERT_DIGITAL_SIGNATURE_KEY_USAGE] true
[ CERT_KEY_CERT_SIGN_KEY_USAGE] true
[ CERT_CRL_SIGN_KEY_USAGE] true

- BasicConstraints

[ critical] true
[ cA] true

- AuthorityKeyIdentifier

- KeyID

[ hash] 722D3A02319043B914054EE1EAA7C731D1238934

- CertificatePolicies

- Policy

[ oid] 1.3.6.1.4.1.311.46.3

- Certificate

[ fileRef] 8F43288AD272F3103B6FB1428485EA3014C0BCFE.cer
[ subjectName] Microsoft Root Certificate Authority 2011
- Subject

CN Microsoft Root Certificate Authority 2011

O Microsoft Corporation

L Redmond

S Washington

C US

- SubjectKeyID

[ computed] false
[ hash] 722D3A02319043B914054EE1EAA7C731D1238934

- Issuer

CN Microsoft Root Certificate Authority 2011

O Microsoft Corporation

L Redmond

S Washington

C US

SerialNumber 3F8BC8B5FC9FB29643B569D66C42E144

NotBefore 2011-03-22T22:05:28Z

NotAfter 2036-03-22T22:13:04Z

- Extensions

- KeyUsage

[ value] 86
[ CERT_DIGITAL_SIGNATURE_KEY_USAGE] true
[ CERT_KEY_CERT_SIGN_KEY_USAGE] true
[ CERT_CRL_SIGN_KEY_USAGE] true

- BasicConstraints

[ critical] true
[ cA] true

- Properties

FriendlyName Microsoft Root Certificate Authority 2011

- CertificateRevocationList

[ fileRef] EB51DE8F544732860A34FDDB7FFA608AE65681FC.crl
[ issuerName] Microsoft Root Certificate Authority 2011
- Issuer

CN Microsoft Root Certificate Authority 2011

O Microsoft Corporation

L Redmond

S Washington

C US

ThisUpdate 2014-03-16T18:45:25Z

NextUpdate 2014-06-15T07:05:25Z

- Extensions

- AuthorityKeyIdentifier

- KeyID

[ hash] 722D3A02319043B914054EE1EAA7C731D1238934

CRLNumber 20

NextPublishTime 2014-06-14T18:55:25Z

- CertificateRevocationList

[ fileRef] 5C7A33B1CD5AE5ACEA73BF8576E537F9E7244DDD.crl
[ issuerName] Microsoft Code Signing PCA 2011
- Issuer

CN Microsoft Code Signing PCA 2011

O Microsoft Corporation

L Redmond

S Washington

C US

ThisUpdate 2014-03-16T18:57:06Z

NextUpdate 2014-06-15T07:17:06Z

- Extensions

- AuthorityKeyIdentifier

- KeyID

[ hash] 486E64E55005D382AA17373722B56DA8CA750295

CRLNumber 23

NextPublishTime 2014-06-14T19:07:06Z

- EventAuxInfo

[ ProcessName] Explorer.EXE

- CorrelationAuxInfo

[ TaskId] {89359956-E4EF-4A3F-8D9A-436AC2BD8BE4}
[ SeqNumber] 8

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

- System

- Provider

[ Name] Microsoft-Windows-CAPI2
[ Guid] {5bbca4a8-b209-48dc-a8c7-b23d3e5216fb}

EventID 81

Version 0

Level 2

Task 80

Opcode 2

Keywords 0x8000000000000040

- TimeCreated

[ SystemTime] 2014-05-06T21:00:10.110Z

EventRecordID 185258

Correlation

- Execution

[ ProcessID] 3704
[ ThreadID] 12184

Channel Microsoft-Windows-CAPI2/Operational

Computer XXXXXXX

- Security

[ UserID] XXXXXXX

- UserData

- WinVerifyTrust

ActionID {189A3842-3041-11D1-85E1-00C04FC295EE}

- UIChoice WTD_UI_NONE

[ value] 2

- RevocationCheck

[ value] 0

- StateAction WTD_STATEACTION_VERIFY

[ value] 1

- Flags

[ value] 80000000
[ CPD_USE_NT5_CHAIN_FLAG] true

- FileInfo

[ filePath] D:\Gebruikers\XXXXXXX\Downloads\Microsoft EMET\EMET 4.1 Update 1\EMET Setup.msi
[ hasFileHandle] true

- RegPolicySetting

[ value] 23C00
[ WTPF_OFFLINEOK_IND] true
[ WTPF_OFFLINEOK_COM] true
[ WTPF_OFFLINEOKNBU_IND] true
[ WTPF_OFFLINEOKNBU_COM] true
[ WTPF_IGNOREREVOCATIONONTS] true

- CertificateChain

[ chainRef] {C92488BE-76D0-4593-95D9-C328480D7978}

- StepError

[ stepID] 32
[ stepName] TRUSTERROR_STEP_FINAL_OBJPROV
- Result De digitale handtekening van het object kan niet worden gecontroleerd.

[ value] 80096010

- EventAuxInfo

[ ProcessName] Explorer.EXE

- CorrelationAuxInfo

[ TaskId] {89359956-E4EF-4A3F-8D9A-436AC2BD8BE4}
[ SeqNumber] 9

- Result De digitale handtekening van het object kan niet worden gecontroleerd.

[ value] 80096010

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

07-05-2014, 00:20 door Spiff has left the building

Door Ilja. _V V, 15:42 uur:
Spiff: Net even nagekeken, & de fout doet zich bij mij alleen voor op XP (P - 32bits) & Vista (HP - 32bits),
op Windows 7 (U - 32bits) staat er Deze digitale handtekening is in orde, maar de Onbekende sleutel staat wel in de Details van het certificaat.
[...]
Het lijkt erop dat de certificaten zijn geschreven voor 7/8.x. Wat ik (vannacht) zover heb gelezen over certificaten, is dat als Vista of Xp een ongeldigheid of beschadiging vinden & daardoor niet kunnen verifieren, het certificaat afgekeurd word.

Door Spiff, 16:11 uur:
Dank je, Ilja.
Zou je misschien kunnen aangeven wat de bron of bronnen waren die je gevonden had die dat verschil in certificaatverwerking van XP+Vista en Win7+8 vermelden?

Door Ilja. _V V, 16:32 uur:
Dat word beschreven aan het begin in de link die Erik van Straten al gaf:
http://www.alex-ionescu.com/?p=146
Blijkbaar is dat wel doorgevoerd in 7, maar niet in oudere versies.

Hai Ilja,
Ik heb dat stuk nu grondiger doorgenomen dan vanochtend, maar ik vind niet die informatie over het verschil in certificaatverwerking van XP+Vista en Win7+8 die jij noemde.
Is het mogelijk dat ik daar helemaal overheen kijk?
Kun je me dan preciezer aanduiden waar die informatie staat?
Of heb je je mogelijk vergist, en staat die informatie niet op die pagina, maar had je het op een heel andere pagina gelezen?

07-05-2014, 01:06 door Spiff has left the building

Door Anoniem, di.06-05-2014, 16:59 uur:
Gisteren EMET 4.1 update 1 geinstalleerd op een computer die op windows 7 draait. Echter krijg ik de melding dat er onvoldoende gegevens zijn on het certificaat Te controlleren.

Een signaal dat blijkbaar ook op Windows 7 de controle van het certificaat van EMET [4.1u1] Setup.msi niet helemaal gesmeerd loopt, of dat er iets raars aan de hand is met de ondertekening van het bestand.

07-05-2014, 01:06 door Spiff has left the building

Door Anoniem "cluc-cluc", di.06-05-2014, 23:43 uur:
Spiff, wat ik zojuist heb ontdekt is dat het EMET4.1 installatiebestand toch duidelijk anders is ondertekend dan bijv. het EMET3.0 of EMET4.0 installatiebestand.
In Windows XP (32-bit) zie ik de volgende verschillen:

1.Verschillen in het certificeringspad.
Voor EMET3.0/EMET4.0 is dit pad:
Microsoft Root Certificate Authority ->
Microsoft Code Signing PCA ->
Micosoft Corporation

maar voor EMET4.1 is het pad:
Microsoft Root Certificate Authority 2011 ->
Microsoft Code Signing PCA 2011 ->
Micosoft Corporation

Voor alle duidelijkheid, bedoel je EMET 4.1 Update 1?

Dat wat je onder 1. vermeldde was blijkbaar nog niemand anders opgevallen, mij in elk geval niet.
Bij nakijken zie ik het nu ook (onder Vista):

Voor EMET 4.0 en ook nog voor EMET 4.1 is het certificeringspad dit:
Microsoft Root Certificate Authority ->
Microsoft Code Signing PCA ->
Micosoft Corporation

Maar voor de recente EMET 4.1 Update 1 is het certificeringspad dit:
Microsoft Root Certificate Authority 2011 ->
Microsoft Code Signing PCA 2011 ->
Micosoft Corporation

Mooie constatering, Anoniem "cluc-cluc"!

Door Anoniem "cluc-cluc", di.06-05-2014, 23:43 uur:
2. Voor EMET3.0/EMET4.0 is een controlehandtekening aanwezig van "Microsoft Time-Stamp Service".
Maar voor EMET4.1 is er GEEN ENKELE controlehandtekening aanwezig (veld is leeg!)
Mogelijk dat dit laatste dus veroorzaakt dat de hele digitale ondertekening van EMET4.1 wordt afgekeurd.

Voor alle duidelijkheid, bedoel je EMET 4.1 Update 1?
Ja, niet dat weergeven van de timestamp voor EMET [4.1u1] Setup.msi dat was al geconstateerd,
en dat zal er inderdaad waarschijnlijk de reden voor zijn dat de ondertekening wordt afgekeurd.

Door Anoniem "cluc-cluc", di.06-05-2014, 23:43 uur:
Want ga je namelijk naar "Certificaat weergeven" -> "Certificeringspad",
dan geven alle drie items in het pad na aanklikken gewoon: "Dit certificaat is in orde".
(tip: bij de bovenste twee items even opnieuw op "Certificaat weergeven" klikken, en dan weer op "Certificeringspad")
Misschien dat jij dit in Vista ook kunt zien en reproduceren?

Klopt, daar wordt overal weergegeven "Dit certificaat is in orde".
Ook Fwiffo had dat gisteren (di.06-05-2014, 09:58 uur) geconstateerd.

Door Anoniem "cluc-cluc", di.06-05-2014, 23:43 uur:
Conclusie: óf MS heeft die zogenaamde "controlehandtekening" hier domweg vergeten, óf er wordt een andere manier van digitaal ondertekenen gebruikt bij het EMET4.1-bestand, die incompatible is met een ouder OS.

Ja, mogelijk.
Dat laatste is een vermoeden dat aansluit bij wat Fwiffo (di.06-05-2014, 09:58 uur) en ook Ilja (di.06-05-2014, 15:42 uur) aangaven.

07-05-2014, 02:30 door Ilja. _V V

Ok, als jij, Fwiffo, cluc-cluc & ik in zowel ME, 2K (had ik vanmiddag even getest, zelfde resultaat als cluc-cluc in ME), XP, 2K3 (! - Net getest - !) & Vista, dan mag er ondertussen weloverwogen zowel logischerwijze & redelijkerwijze aangenomen worden dat er bij Microsoft iets faliekant mis is gegaan in de produktie van dit certificaat, & niet met de getroffen besturingssystemen.

(Mogelijk is Windows 8.x voor de Microsoft (beveiligings-)technici net zo moeilijk als voor de normale gebruikers, waarbij Microsoft zichzelf een koekie van eigen deeg heeft gegeven. Het is dan natuurlijk helemaal een blamage dat dit ook nog eens n.b. gebeurd bij een beveiligingscertificaat voor een, weer n.b., een beveiligingsprogramma, dat, nog eens n.b., volgens de downloadpagina toch echt alle Windows vanaf XP ondersteunt. Poetische gerechtigheid!)

Hier is het citaat wat ik bedoelde in het bijna begin van http://www.alex-ionescu.com/?p=146:

Signing Levels in Windows 8

Before Windows 8.1 introduced the protection level (which we described in Part 1 and Part 2), Windows 8 instituted the Signing Level, also sometimes referred to as the Signature Level. This undocumented number was a way for the system to differentiate the different types of Windows binaries, something that became a requirement for Windows RT as part of its requirement to prohibit the execution of Windows “desktop” applications. Microsoft counts among these any application that did not come from the Windows Store and/or which was not subjected to the AppContainer sandboxing technology enforced by the Modern/Metro programming model (meanwhile, the kernel often calls these “packaged” applications).

I covered Signing Levels in my Breakpoint 2012 presentation, and clrokr, one of the developers behind the Windows RT jailbreak, blogged about them as well. Understanding signing levels was critical for the RT jailbreak: Windows introduced a new variable, SeILSigningPolicy, which determined the minimum signing level allowed for non-packaged applications. On x86, this was read from the registry, and assumed to be zero, while on ARM, this was hard-coded to “8?, which as you can see from clrokr’s blog, corresponds to “Microsoft” – in effect allowing only Microsoft-signed applications to run on the RT desktop. The jailbreak, then, simply sets this value to “0?.

Another side effect of Signing Levels was that the “ProtectedProcess” bit in EPROCESS was removed — whether or not a Windows 8 process is protected for DRM purposes (such as Audiodg.exe, which handles audio decoding) was now implied from the value in the “SignatureLevel” field instead.

Signing Levels in Windows 8.1

In Windows 8.1, these levels have expanded to cover some of the needs introduced by the expansion of protected processes. The official names Microsoft uses for them are shown in Table 1 below. In addition, the SeILSigningPolicy variable is no longer initialized through the registry. Instead, it is set through the Secure Boot Signing Policy, a signed configurable policy blob which determines which binaries a Windows 8.1 computer is allowed to run. The value on 8.1 RT, however, remains the same – 8 (Microsoft), still prohibiting desktop application development.

Enzovoort... Volgens mij is dat functionaliteit waar alleen Windows 7 & 8.x (& de server-varianten) over beschikken.

Wat ik verder ook opmaak na het doornemen van die gigantische handleidingen, iets wat iedere keer terugkomt, is dat als tijdens het controleproces van het certificaat iets niet gevalideerd of gecontroleerd kan worden, automatisch & subiet het certificaat ongeldig verklaard word.

Als ik hier in IE8 op de pagina ga zoeken, dan kom ik in je log al 4x de waarde false tegen. Voor zover ik nu begrijp omdat XP, Vista, etc... die gegeven informatie niet kunnen controleren c.q. valideren, omdat het niet binnen het besturingssysteem aanwezig is.

Ik zal nog even de meest relevante zoekstrings die ik gebruikt heb hieronder neerzetten:

https://www.google.nl/search?hl=nl&source=hp&q=site%3Amicrosoft.com+emet+4.1+valid+certificate++content+empty&meta=&aq=f&oq

https://www.google.nl/search?q=site%3Amicrosoft.com+Onbekend+sleutelgebruik+certificaat&hl=nl

https://www.google.nl/search?hl=nl&source=hp&q=site%3Amicrosoft.com+emet+4.1+display+certificate+content+empty&meta=&aq=f&oq

07-05-2014, 10:00 door Erik van Straten

Door Ilja. _V V: Ok, als jij, Fwiffo, cluc-cluc & ik in zowel ME, 2K (had ik vanmiddag even getest, zelfde resultaat als cluc-cluc in ME), XP, 2K3 (! - Net getest - !) & Vista, dan mag er ondertussen weloverwogen zowel logischerwijze & redelijkerwijze aangenomen worden dat er bij Microsoft iets faliekant mis is gegaan in de produktie van dit certificaat, & niet met de getroffen besturingssystemen.

Daar ben ik nog niet zo zeker van.

Microsoft heeft de afgelopen jaren gereserveerde OID's in gebruik genomen en daarbij oudere besturingssystemen niet (geheel) bijgewerkt. Voorbeeld: ook W7 weet nog geen naam aan de EKU (Enhanced Key Usage) OID 1.3.6.1.4.1.311.76.8.1 te koppelen en kan deze dus ook niet interpreteren. Dat is echter geen probleem omdat er in het betreffende certificaat ook een andere EKU waarde bestaat die al lang bekend is (1.3.6.1.5.5.7.3.3 = Code Signing), waarmee de validatiestap kan worden uitgevoerd en W7 niet verder klaagt. Ik vermoed dat dit niet de oorzaak is van het afkeuren van de signature door Vista en ouder, maar wat dan wel weet ik ook niet (wellicht een bug die optreedt door een bepaalde combinatie van certificaten).

De 4x False in bovenstaande CPAI2 logs lijken mij geen foutmeldingen. Er staat 2x "[ cA] false" wat denk ik aangeeft dat het betreffende certificaat (vanaf "- Certificate" erboven) geen CA certificaat is. De 2x "[ computed] false" geeft vermoedelijk aan dat de erop volgende hash niet is berekend maar uit het certificaat is gekopieerd. Ik zie zo snel geen aanwijzingen in die CAPI2 logs voor wat er misgaat.

07-05-2014, 10:11 door Anoniem

Ja inderdaad, waar ik in mijn vorige bericht "EMET4.1" schreef, bedoelde ik "EMET 4.1 update 1"
Mij overigens een raadsel waarom MS er "update 1" aan toe heeft gevoegd.
Als men het "EMET 4.1 update 1" noemt, dan suggereert deze naam dat je eerst EMET 4.1 moet installeren,
en daarna "EMET 4.1 update 1" er overheen moet installeren.
Echter ik vind nergens een bestand dat alleen maar "EMET 4.1" heet... (???)
(is het misschien gedaan "to confuse the ennemy" met alle trammelant die gaande is op het wereldtoneel of zo?) ;)

Afijn.
Al met al ondertussen toch wel een "I think I saw a pussycat!..." -berichtje waard naar het EMET feedback e-mailadres
met een beknopte weergave van onze bevindingen?
mailto: switech@microsoft.com (bron: pdf user's guide die je bij EMET kunt downloaden:
http://www.microsoft.com/en-us/download/confirmation.aspx?id=41138)
Het zou uiteraard fijn zijn als je de community alhier van het antwoord van MS op de hoogte brengt.

(klukje geen e-mail. Mij meer gehecht aan rooksignalen. Aan rooksignalen, wigwam en tiepmiep hehehe) ;)

07-05-2014, 10:42 door Spiff has left the building - Bijgewerkt: 07-05-2014, 18:59

Door Ilja. _V V, 02:30 uur:
Hier is het citaat wat ik bedoelde in het bijna begin van http://www.alex-ionescu.com/?p=146:
[...] Enzovoort...
Volgens mij is dat functionaliteit waar alleen Windows 7 & 8.x (& de server-varianten) over beschikken.

Dank je voor het citeren en voor je cursivering, Ilja.
Zonder jouw nadrukkelijke aanduiding ervan had ikzelf er niet uit afgeleid dat dat stuk van Alex Ionescu’s blog weergeeft dat de certificaatverwerking van XP en Vista anders is dan die van Win7 en Win8.
Het geeft me overigens nog steeds de indruk dat er niet een verschil aangeduid wordt tussen enerzijds Windows Vista en eerder en anderzijds Windows 7 en 8.x, maar dat er een verschil aangeduid wordt tussen enerzijds Windows 7 en eerder en anderzijds Windows 8 en Windows 8.1. De grens dus niet tussen Vista en Win7, maar tussen Win7 en Win8.

[Aanpassing: typo]

07-05-2014, 10:44 door Spiff has left the building

Door Erik van Straten, 10:00 uur:
Ik zie zo snel geen aanwijzingen in die CAPI2 logs voor wat er misgaat.

Bedankt voor het bekijken ervan, Erik.

07-05-2014, 12:00 door Anoniem

Aanvulling op 16:59 (anoniem) gisteren (06-05)

Bij het installeren van EMET krijg ik de melding:

"Wilt u het volgende de programma van een onbekende uitgever toestaan wijzigingen aan aan deze computer aan te brengen?"

Bij uitgever staat dan: "onbekend".

Als ik bij eigenschappen ga kijken van het installatie bestand (EMET Setup.msi) staat er bij digitale handtekening details:

"Het certificaat in de handtekening kan niet worden gecontroleerd."

bij gegevens van de ondertekenaar staat wel alles ingevuld dus ook bij naam.

vervolgen bij certificaat weergeven staat er dan bij certificaatinformatie:

"Er zijn onvoldoende gegevens om dit certificaat te controleren."

Verleend aan, verleend door en geldig van t/m is wel ingevuld.

Er is dus hier (denk ik) iets met de computer mis want bij een ander computer die ook op Windows 7 draait ging de installatie zonder problemen.

Het kan zijn dat ik hier een ander probleem heb want tijdstip van handtekening is ingevuld (dinsdag 29 april 2014 19:43:45).

07-05-2014, 12:46 door Spiff has left the building

Door Anoniem, "klukje", 10:11 uur:
Mij overigens een raadsel waarom MS er "update 1" aan toe heeft gevoegd.
Als men het "EMET 4.1 update 1" noemt, dan suggereert deze naam dat je eerst EMET 4.1 moet installeren,
en daarna "EMET 4.1 update 1" er overheen moet installeren.
Echter ik vind nergens een bestand dat alleen maar "EMET 4.1" heet... (???)

Ja, die naamgeving is inderdaad merkwaardig. "EMET 4.2" was wellicht logischer geweest.
Maar EMET 4.1 update 1 kan uiteraard geïnstalleerd worden zonder dat EMET 4.1 geïnstalleerd is.
En EMET 4.1 (de eerdere versie voor EMET 4.1 update 1) die wordt na het uitbrengen van EMET 4.1 update 1 niet meer aangeboden.

Door Anoniem, "klukje", 10:11 uur:
Al met al ondertussen toch wel een "I think I saw a pussycat!..." -berichtje waard naar het EMET feedback e-mailadres, met een beknopte weergave van onze bevindingen?
mailto: switech@microsoft.com (bron: pdf user's guide die je bij EMET kunt downloaden:
http://www.microsoft.com/en-us/download/confirmation.aspx?id=41138)
Het zou uiteraard fijn zijn als je de community alhier van het antwoord van MS op de hoogte brengt.

Ja, dat ben ik uiteraard van plan, zowel het berichten aan EMET Feedback, als het hier overbrengen van de respons.
In een eerder stadium had ik al even contact met EMET Feedback, maar toen leek het er nog op dat het fenomeen alleen mijn systeem betrof, en dat is inmiddels veranderd.

Overigens, ja, de EMET User's Guide is inderdaad te downloaden, maar wordt tevens ook automatisch meegeïnstalleerd met de EMET installatie.
En betreffend het EMET Feedback adres,
opvallend dat de EMET User's Guide in tekst vermeldt emet_feedback@microsoft.com
terwijl daaronder de koppeling mailto:switech@microsoft.com wordt aangeboden.
In het aankondigings-artikel op TechNet Blogs wordt onder "let us know" de koppeling mailto:emet_feedback@microsoft.com geboden.
http://blogs.technet.com/b/srd/archive/2014/04/30/continuing-with-our-community-driven-customer-focused-approach-for-emet.aspx
Contact via switech@microsoft.com daar heb ik geen ervaring mee.
Wel met contact via emet_feedback@microsoft.com

07-05-2014, 12:51 door Spiff has left the building

Inmiddels heb ik EMET 4.1 Update 1 met succes geïnstalleerd en geconfigureerd.
Het in deze thread beschreven fenomeen betreffend de foutweergave van de ondertekening, dat dwarsboomde op geen enkele manier de installatie. Het enige dat gebeurde dat was dat bij uitvoeren van de installer uiteraard een waarschuwing gegeven werd dat het bestand niet ondertekend zou zijn.

07-05-2014, 13:59 door Spiff has left the building - Bijgewerkt: 07-05-2014, 14:05

Door Anoniem, di.06-05-2014, 16:59 uur:
Gisteren EMET 4.1 update 1 geïnstalleerd op een computer die op windows 7 draait. Echter krijg ik de melding dat er onvoldoende gegevens zijn on het certificaat Te controleren.

Door Anoniem, 12:00 uur:
Aanvulling op 16:59 (anoniem) gisteren (06-05)

Bij het installeren van EMET krijg ik de melding:
"Wilt u het volgende de programma van een onbekende uitgever toestaan wijzigingen aan aan deze computer aan te brengen?"
Bij uitgever staat dan: "onbekend".

Ik denk dat dat de Gebruikersaccountbeheer (User Account Control) (UAC) melding is, waarbij Gebruikersaccountbeheer om een of andere reden niet herkent dat het werkelijk een legitiem ondertekend Microsoft programma betreft.
Dat laat zien dat er dus blijkbaar ook met Windows 7 iets merkwaardigs aan de hand kan zijn met de beoordeling van de digitale handtekening van de EMET 4.1 Update 1 installer.

Door Anoniem, 12:00 uur:
Als ik bij eigenschappen ga kijken van het installatie bestand (EMET Setup.msi) staat er bij digitale handtekening details:
"Het certificaat in de handtekening kan niet worden gecontroleerd."
Bij gegevens van de ondertekenaar staat wel alles ingevuld dus ook bij naam.

Het kan zijn dat ik hier een ander probleem heb want tijdstip van handtekening is ingevuld (dinsdag 29 april 2014 19:43:45).

Ja, dat laatste is anders dan onder Windows Vista bij mij en Fwiffo, en anders dan onder XP en eerder in Iljas tests.

Door Anoniem, 12:00 uur:
Vervolgens bij certificaat weergeven staat er dan bij certificaatinformatie:
"Er zijn onvoldoende gegevens om dit certificaat te controleren."
Verleend aan, verleend door en geldig van t/m is wel ingevuld.
Er is dus hier (denk ik) iets met de computer mis want bij een ander computer die ook op Windows 7 draait ging de installatie zonder problemen.

Het kan zijn dat ik hier een ander probleem heb want tijdstip van handtekening is ingevuld (dinsdag 29 april 2014 19:43:45).

Ook Erik van Straten gaf eerder aan dat de beoordeling van de digitale handtekening van de EMET 4.1 Update 1 installer op zijn Windows 7 systeem normaal was.
Mogelijk is er op je ene Windows 7 systeem iets afwijkends aan de hand, ik overzie echter zo gauw nog niet wat precies. (Misschien heeft iemand anders een idee?)

Mocht je eerder de installatie van EMET 4.1 Update 1 hebben afgebroken vanwege die afwijkende melding, maar wil je nu EMET 4.1 Update 1 toch alsnog installeren, upload de EMET 4.1 Update 1 installer dan zekerheidshalve eerst even naar VirusTotal om te zien of de SHA256 gewoon netjes klopt,
SHA256: 148f84041938745eace1586f6a4ede8029cb424e4ba430d19a3af5c408dc4a9a
en of onder Bestandsgegevens gewoon netjes wordt vermeld "Signature verification: Signed file, verified signature".
Zo ja, dan is er met het installatiebestand niet iets mis, en kun je het gewoon installeren, ondanks de afwijkende melding door Gebruikersaccountbeheer.

07-05-2014, 14:14 door Spiff has left the building

Zonet heb ik Microsoft Nederland geattendeerd op het fenomeen zoals beschreven in deze thread, en Microsoft Nederland naar deze thread verwezen.
Het lijkt me waardevol dat een Nederlandstalige Microsoft-medewerker de details in deze thread kan bestuderen, en op basis daarvan actie kan laten ondernemen.
Ik heb ook verzocht of Microsoft aansluitend ook zou willen reageren in deze thread.
Microsoft heeft mijn attendering doorgezet naar de betreffende afdeling of medewerkers.
Er kon echter niks beloofd worden over de termijn waarbinnen Microsoft aan het bestuderen van deze thread zou toekomen.

Later vandaag zal ik nog melden aan EMET Feedback, zoals ik dat 12:46 uur aangaf.
Maar eerst even pauzeren nu.

07-05-2014, 15:32 door Anoniem

Bedankt Spiff voor je reactie op anoniem 12:00. Ik heb EMET 4.1 update 1 nu ook met succes geïnstalleerd op het Windows 7 systeem waar ik de waarschuwing op krijg van Gebruikersaccountbeheer.

07-05-2014, 18:01 door Erik van Straten

@Spiff: om te bepalen welke certificaten het probleem veroorzaken, zou je http://download.microsoft.com/download/7/C/5/7C514257-287C-49A9-BF50-F86BB3D4E60C/1033/x86/PowerPivot_for_Excel_x86.msi kunnen downloaden (let op, deze is 95MB groot).

Het gaat me natuurlijk niet om dat bestand zelf (voor info daarover zie http://msdn.microsoft.com/en-us/library/ee210599.aspx) maar om de authenticode signature.

Voor dit bestand zijn exact dezelfde intermediate (en dus ook root-) certificaten gebruikt als voor EMET4.1u1, zowel code signing (F252E794FE438E35ACE6E53762C0A234A2C52135 en 8F43288AD272F3103B6FB1428485EA3014C0BCFE) als time stamping (2AA752FE64C49ABE82913C463529CF10FF2F04EE en 3B1EFD3A66EA28B16697394703A72CA340A05BD5), zie "File detail" in https://www.virustotal.com/en/file/b37f90250ca38259620a26f8440ab386b931ce0692c0bae323bf53b86b54bdfb/analysis/.

De certificaten voor het ondertekenen en time-stampen wijken dus wel af. Kun je genoemd bestand downloaden, de handtekening checken en terugmelden of dat wel of niet goed gaat?

07-05-2014, 18:52 door Spiff has left the building

@ Erik van Straten, 18:01 uur,

Heel goed idee!

Resultaat:
Het fenomeen zoals beschreven in deze thread is niet gelimiteerd tot de recente EMET installers,
maar treed ook op met PowerPivot_for_Excel_x86.msi

Alle details zijn zoals je beschreef in je bericht van 18:01 uur.
Enkel de SHA256 voor de naar VirusTotal geuploade PowerPivot_for_Excel_x86.msi is anders, zie:
https://www.virustotal.com/nl/file/74070ab50b9e3e173f28b0240fd535042408a0c5266319f7c597caba66c2e711/analysis/1399479816/
Een nieuwere bestandsversie?
Niettemin, de beschreven details zijn verder identiek.

Het resultaat bij het controleren van de details van de digitale handtekening op mijn Windows Vista systeem is identiek aan dat van de recente EMET installers:

Gegevens voor Digitale handtekening
Deze digitale handtekening is ongeldig.
Gegevens van de ondertekenaar
Tijdstip van handtekening: Niet beschikbaar
Controlehandtekeningen: (niets weergegeven)
Certificaat weergeven -->
Certificaatinformatie
De digitale handtekening van het object kan niet worden gecontroleerd.

Het beschreven fenomeen/probleem is dus beslist niet gelimiteerd tot de recente EMET installers.

N.B.
Ik was vandaag nog niet toegekomen aan het melden aan EMET Feedback, en ik wacht daar nu maar eens mee.
Het is immers geen fout van het EMET team, maar het probleem is duidelijk breder.
Ik hoop dat Microsoft Nederland zoals beloofd deze thread doorneemt en actie zal of laat ondernemen.
Andere suggesties misschien nog?

PSje
De upload-limiet voor VirusTotal is formeel 64 MB.
Niettemin kon ik met succes dat 98,5 MB grote PowerPivot_for_Excel_x86.msi uploaden voor controle. Netjes.

07-05-2014, 20:31 door Erik van Straten - Bijgewerkt: 07-05-2014, 20:47

Door Spiff:
Enkel de SHA256 voor de naar VirusTotal geuploade PowerPivot_for_Excel_x86.msi is anders, zie:
https://www.virustotal.com/nl/file/74070ab50b9e3e173f28b0240fd535042408a0c5266319f7c597caba66c2e711/analysis/1399479816/
Een nieuwere bestandsversie?

In elk geval is er een ander time stamping certificaat gebruikt, of de binary zelf anders is weet ik niet.

Als ik nu zou moeten gokken wat het probleem in Vista en eerder is: in het intermediate time stamping certificaat (2AA752FE64C49ABE82913C463529CF10FF2F04EE) is een "Certificate Policy" opgenomen met attribuut critical. In oudere intermediate certificaten kom ik geen "Certificate Policy" tegen. Critical betekent dat de parser deze moet interpreteren (anders is dit optioneel). Het -later uitgegeven- intermediate code signing certificaat bevat ook een Certificate Policy maar in dat geval deze is niet critical.

Aangezien ik de OID "1.3.6.1.4.1.311.46.3" bijna nergens terugvind op internet vermoed ik dat deze "te nieuw" is voor Vista en ouder. Als dat zo is, is het door Vista afkeuren van de als Critical gedefinieerde Certificate Policy terecht.

Helaas heb ik nog geen downloadable binary kunnen vinden ondertekend met een recent code signing certificaat en een ouder time stamping certificaat om e.e.a. aan te kunnen tonen.

Aanvulling: Googlen naar F252E794FE438E35ACE6E53762C0A234A2C52135 site:virustotal.com lijkt uit te wijzen dat alle bestanden die Microsoft heeft ondertekend gebruik makend van intermediate code signing certificaat "Microsoft Code Signing PCA 2011", een time stamp hebben die gebruik maakt van intermediate time stamping certificaat "Microsoft Time-Stamp PCA 2010" (2AA752FE64C49ABE82913C463529CF10FF2F04EE), d.w.z. met de critical Certificate Policy. Ik puzzel nog even verder...

07-05-2014, 20:48 door [Account Verwijderd] - Bijgewerkt: 07-05-2014, 22:03

De tip van Erik van Straten (07-05-2014 18:01) heb ik ook uitgeprobeerd en dus het bestand gedownload en uitgeprobeerd op beide windows 7 systemen. (Hiermee bedoel ik de Windows 7 systemen die ik in 07-05-2014 12:00 Anoniem omschreef).

Hierbij kreeg ik het zelfde probleem als dat ik in Anoniem 12:00 omschreef Op een Windows 7 systeem (32 bits) is er niks aan de hand en is het certificaat in orde, maar op het ander Windows 7 systeem (64 bits) krijg ik bij details weer hetzelfde probleem als wat ik omschreef in Anoniem 12:00.

Dus ook hier gaat het niet alleen mis bij het installeren van EMET 4.1 update 1

Wat bij mij wel weer anders is als wat Spiff omschrijft in 07-05-2014 18:52, is dat ik wel een tijdstip van handtekening zie staan op het systeem waar de problemen zich voordoen. Dit verschil was ook bij EMET 4.1 update 1

07-05-2014, 21:19 door Spiff has left the building - Bijgewerkt: 07-05-2014, 23:38

Door Erik van Straten, 20:31 uur:
Aangezien ik de OID "1.3.6.1.4.1.311.46.3" bijna nergens terugvind op internet vermoed ik dat deze "te nieuw" is voor Vista en ouder. Als dat zo is, is het door Vista afkeuren van de als Critical gedefinieerde Certificate Policy terecht.

Zou dat in dat geval dan ook een verklaring zijn voor het feit dat door Vista niet alleen wordt weergegeven dat de digitale handtekening ongeldig zou zijn, maar dat onder gegevens van de ondertekenaar zelfs wordt aangegeven dat het tijdstip van handtekening niet beschikbaar zou zijn en dat onder controlehandtekeningen in het geheel niets wordt weergegeven?

Gegevens voor Digitale handtekening
Gegevens van de ondertekenaar
Tijdstip van handtekening: Niet beschikbaar
Controlehandtekeningen: (niets weergegeven)

Of heeft dat weer een andere reden?

08-05-2014, 08:48 door Ilja. _V V

Toevallig gisteren nog iets frappants gevonden, tijdens een scan van Hitman Pro, alleen EMET werd eruit gepikt, hieronder het log:

HitmanPro 3.7.9.216
www.hitmanpro.com

Computer name . . . . :
Windows . . . . . . . : 5.1.3.2600.X86/1
User name . . . . . . :
License . . . . . . . : Trial (Expired)

Scan date . . . . . . : 2014-05-08 02:04:54
Scan mode . . . . . . : Normal
Scan duration . . . . : 23m 35s
Disk access mode . . : Direct disk access (SRB)
Cloud . . . . . . . . : Internet
Reboot . . . . . . . : No

Threats . . . . . . . : 0
Traces . . . . . . . : 14

Objects scanned . . . : 790.712
Files scanned . . . . : 15.655
Remnants scanned . . : 77.924 files / 697.133 keys

Suspicious files ____________________________________________________________

C:\Program Files\EMET 4.1\EMET_agent.exe
Size . . . . . . . : 81.416 bytes
Age . . . . . . . : 8.7 days (2014-04-29 10:28:08)
Entropy . . . . . : 7.0
SHA-256 . . . . . : 02377C6EA2C7D121ACDC7228493B58BC5E786B9E71CD725471DCFAE7E9A625C4
Product . . . . . : Enhanced Mitigation Experience Toolkit
Publisher . . . . : Microsoft Corporation
Description . . . : EMET_Agent
Version . . . . . : 4.1.5228.513
Copyright . . . . : © Microsoft Corporation. All rights reserved.
RSA Key Size . . . : 2048
Gossip . . . . . . : EMET 4.1
Authenticode . . . : Invalid
Running processes : 456
Fuzzy . . . . . . : 24.0
Program is altered or corrupted since it was code signed by its author. This is typical for malware and pirated software.
Entropy (or randomness) indicates the program is encrypted, compressed or obfuscated. This is not typical for most programs.
Program is running but currently exposes no human-computer interface (GUI).
Uses the Windows Registry to run each time the user logs on.
Program starts automatically without user intervention.
The file is in use by one or more active processes.
Time indicates that the file appeared recently on this computer.
The file appears to be part of an installation package or setup program. This is typical for most programs.
Startup
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\EMET 4.1 Update 1 Agent
References
HKU\S-1-5-21-1708537768-813497703-725345543-1003\Software\Microsoft\Windows\ShellNoRoam\MUICache\C:\Program Files\EMET 4.1\EMET_agent.exe
HKU\S-1-5-21-1708537768-813497703-725345543-1006\Software\Microsoft\Windows\ShellNoRoam\MUICache\C:\Program Files\EMET 4.1\EMET_Agent.exe
HKU\S-1-5-21-1708537768-813497703-725345543-501\Software\Microsoft\Windows\ShellNoRoam\MUICache\C:\Program Files\EMET 4.1\EMET_agent.exe

C:\Program Files\EMET 4.1\HelperLib.DLL
Size . . . . . . . : 124.424 bytes
Age . . . . . . . : 8.7 days (2014-04-29 10:28:08)
Entropy . . . . . : 5.9
SHA-256 . . . . . : 21E3A0D30F8FBB00F5A982D8037E5499959B21F6720E6975DFE7CAE416AFA897
Product . . . . . : HelperLib
Description . . . : HelperLib
Version . . . . . : 4.1.5228.512
Copyright . . . . : Copyright © 2013
RSA Key Size . . . : 2048
Authenticode . . . : Invalid
Fuzzy . . . . . . : 22.0
Program is altered or corrupted since it was code signed by its author. This is typical for malware and pirated software.
File belongs to an identified security risk.
Program is running but currently exposes no human-computer interface (GUI).
The file is in use by one or more active processes.
Time indicates that the file appeared recently on this computer.
Authors name is missing in version info. This is not common to most programs.
The file appears to be part of an installation package or setup program. This is typical for most programs.

C:\Program Files\EMET 4.1\PKIPinningSubsystem.DLL
Size . . . . . . . : 52.232 bytes
Age . . . . . . . : 8.7 days (2014-04-29 10:28:04)
Entropy . . . . . : 6.1
SHA-256 . . . . . : 1C215DD1CF48EC878BD1DD7AAF650556F2D4FC81ED0C3784B8BF9F02B7793035
Product . . . . . : PKIPinningSubsystem
Description . . . : PKIPinningSubsystem
Version . . . . . : 4.1.5228.512
Copyright . . . . : Copyright © 2013
RSA Key Size . . . : 2048
Authenticode . . . : Invalid
Fuzzy . . . . . . : 22.0
Program is altered or corrupted since it was code signed by its author. This is typical for malware and pirated software.
File belongs to an identified security risk.
Program is running but currently exposes no human-computer interface (GUI).
The file is in use by one or more active processes.
Time indicates that the file appeared recently on this computer.
Authors name is missing in version info. This is not common to most programs.
The file appears to be part of an installation package or setup program. This is typical for most programs.

C:\Program Files\EMET 4.1\ReportingSubsystem.DLL
Size . . . . . . . : 37.896 bytes
Age . . . . . . . : 8.7 days (2014-04-29 10:28:08)
Entropy . . . . . : 6.7
SHA-256 . . . . . : 2C92492E4E502F422213BC2FB2437894F6D9901703ACE4AE2475BC89479CD62F
Product . . . . . : ReportingSubsystem
Description . . . : ReportingSubsystem
Version . . . . . : 4.1.5228.513
Copyright . . . . : Copyright © 2013
RSA Key Size . . . : 2048
Authenticode . . . : Invalid
Fuzzy . . . . . . : 22.0
Program is altered or corrupted since it was code signed by its author. This is typical for malware and pirated software.
File belongs to an identified security risk.
Program is running but currently exposes no human-computer interface (GUI).
The file is in use by one or more active processes.
Time indicates that the file appeared recently on this computer.
Authors name is missing in version info. This is not common to most programs.
The file appears to be part of an installation package or setup program. This is typical for most programs.

C:\Program Files\EMET 4.1\TrayIconSubsystem.DLL
Size . . . . . . . : 32.776 bytes
Age . . . . . . . : 8.7 days (2014-04-29 10:28:08)
Entropy . . . . . : 6.7
SHA-256 . . . . . : 4C36235C73A0B9A0977DE504CA33AE2546408B4DDD9D077BDB52BDAB0F6317E2
Product . . . . . : TrayIconSubsystem
Description . . . : TrayIconSubsystem
Version . . . . . : 4.1.5228.513
Copyright . . . . : Copyright © 2013
RSA Key Size . . . : 2048
Authenticode . . . : Invalid
Fuzzy . . . . . . : 22.0
Program is altered or corrupted since it was code signed by its author. This is typical for malware and pirated software.
File belongs to an identified security risk.
Program is running but currently exposes no human-computer interface (GUI).
The file is in use by one or more active processes.
Time indicates that the file appeared recently on this computer.
Authors name is missing in version info. This is not common to most programs.
The file appears to be part of an installation package or setup program. This is typical for most programs.

08-05-2014, 09:11 door Erik van Straten

@kraai: certificaatproblemen kunnen verschillende redenen hebben. Bijv. als een rootcertificaat niet aanwezig is op de PC en de PC (tijdelijk) geen internetconnectiviteit heeft, zal de handtekening niet gevalideerd kunnen worden.

@Spiff: de als critical gemarkeerde Certificate Policy zou de oorzaak van de problemen op Vista en ouder kunnen zijn, maar het blijft een gok. Uit RFC 5280 (https://tools.ietf.org/html/rfc5280#section-4.2.1.4):

4.2.1.4. Certificate Policies
[...]
Applications with specific policy requirements are expected to have a list of those policies that they will accept and to compare the policy OIDs in the certificate to that list. If this extension is critical, the path validation software MUST be able to interpret this extension (including the optional qualifier), or MUST reject the certificate.
[...]

Nogmaals, een gok; ik sluit niet uit dat er iets anders aan de hand is (en Vista en ouder de criticallity negeren en/of OID "1.3.6.1.4.1.311.46.3" wel kunnen verwerken).

Echter, opvallend is dat het intermediate code signing certificaat, dat een jaar later is uitgegegeven, ook een Certificate Policy heeft (zelfde OID), maar deze niet als critical markeert. Het lijkt er dus op dat de Certificate Policy in het intermediate time stamping certificaat (Microsoft Time-Stamp PCA 2010, 2AA752FE64C49ABE82913C463529CF10FF2F04EE) onterecht als critical is gemarkeerd.

Opvallend is ook dat, in dat intermediate time stamping certificaat, de URL in de critical Certificate Policy (http://www.microsoft.com/PKI/docs/CPS/default.htm) een 404 oplevert - terwijl dat certificaat nog 11 jaar geldig is... Buitengewoon slordig, maar niet critical:

The CPS Pointer qualifier contains a pointer to a Certification Practice Statement (CPS) published by the CA. The pointer is in the form of a URI. Processing requirements for this qualifier are a local matter. No action is mandated by this specification regardless of the criticality value asserted for the extension.

@ Ilja. _V V: dat is op Vista, neem ik aan? Wat zegt sigcheck.exe van die bestanden (http://technet.microsoft.com/en-us/sysinternals/bb897441) gedraaid als: sigcheck -i -a -h filename?

08-05-2014, 09:41 door Fwiffo

Het probleem met Windows Vista staat ondertussen ook op http://social.technet.microsoft.com/Forums/systemcenter/en-US/9b01619e-4349-4cef-b52c-1e50f0d7e838/how-to-update-emet-41-silentunattended-to-emet-41-update-1?forum=emet! Met afbeeldingen.

Misschien komt er een Update 2 van EMET met 'ouderwetse' signatures. Misschien wordt Windows Vista geupdated met een nieuwe crypto module. Windows XP is EOL, dus daar zal wel geen update meer voor komen (terwijl die Windows versie EMET het hardst nodig zal hebben vanwege 0-days).

Microsoft kan zich hier ook makkelijk vanaf maken en dit probleem in een KB zetten ofzo. Met de tip te upgraden naar Windows 8.1 voor de beste 'user experience' ;-) [met of zonder tegeltjes!!!]

08-05-2014, 10:17 door Spiff has left the building - Bijgewerkt: 08-05-2014, 11:08

Door Ilja. _V V:
Toevallig gisteren nog iets frappants gevonden, tijdens een scan van Hitman Pro, alleen EMET werd eruit gepikt, hieronder het log:

HitmanPro 3.7.9.216
www.hitmanpro.com

Computer name . . . . :
Windows . . . . . . . : 5.1.3.2600.X86/1

Door Erik van Straten:
@ Ilja. _V V: dat is op Vista, neem ik aan?

Nee, aan de Windows versie te zien niet.
Windows Vista x86 is 6.0.2.6002.X86/2

Hieronder mijn HitmanPro log voor Windows Vista x86:

HitmanPro 3.7.9.216
www.hitmanpro.com

Computer name . . . . : XXXXXXX
Windows . . . . . . . : 6.0.2.6002.X86/2
User name . . . . . . : XXXXXXX\XXXXXXX
UAC . . . . . . . . . : Enabled
License . . . . . . . : Paid (293 days left)

Scan date . . . . . . : 2014-05-08 09:55:18
Scan mode . . . . . . : Normal
Scan duration . . . . : 5m 43s
Disk access mode . . : Direct disk access (SRB)
Cloud . . . . . . . . : Internet
Reboot . . . . . . . : No

Threats . . . . . . . : 0
Traces . . . . . . . : 10

Objects scanned . . . : 2.058.577
Files scanned . . . . : 13.736
Remnants scanned . . : 210.235 files / 1.834.606 keys

Suspicious files ____________________________________________________________

C:\Program Files\EMET 4.1\EMET_Agent.exe
Size . . . . . . . : 81.416 bytes
Age . . . . . . . : 0.9 days (2014-05-07 11:41:23)
Entropy . . . . . : 7.0
SHA-256 . . . . . : 02377C6EA2C7D121ACDC7228493B58BC5E786B9E71CD725471DCFAE7E9A625C4
Product . . . . . : Enhanced Mitigation Experience Toolkit
Publisher . . . . : Microsoft Corporation
Description . . . : EMET_Agent
Version . . . . . : 4.1.5228.513
Copyright . . . . : © Microsoft Corporation. All rights reserved.
RSA Key Size . . . : 2048
Gossip . . . . . . : EMET 4.1
Parent Name . . . : C:\Windows\Explorer.EXE
Authenticode . . . : Invalid
Running processes : 5012
Fuzzy . . . . . . : 25.0
Program is altered or corrupted since it was code signed by its author. This is typical for malware and pirated software.
Entropy (or randomness) indicates the program is encrypted, compressed or obfuscated. This is not typical for most programs.
Program is running but currently exposes no human-computer interface (GUI).
Uses the Windows Registry to run each time the user logs on.
Program starts automatically without user intervention.
Time indicates that the file appeared recently on this computer.
The file is in use by one or more active processes.
The file appears to be part of an installation package or setup program. This is typical for most programs.
Startup
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\EMET 4.1 Update 1 Agent
References
HKU\S-1-5-21-813194417-2881826187-4116504105-1000\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache\C:\Program Files\EMET 4.1\EMET_Agent.exe
HKU\S-1-5-21-813194417-2881826187-4116504105-1001\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\MuiCache\C:\Program Files\EMET 4.1\EMET_Agent.exe
Forensic Cluster
-3.7s C:\Users\XXXXXXX\AppData\Local\Temp\CFG3301.tmp
-0.4s C:\Program Files\EMET 4.1\
-0.4s C:\Program Files\EMET 4.1\DevExpress.XtraEditors.v12.2.dll
-0.3s C:\Program Files\EMET 4.1\PKIPinningSubsystem.DLL
-0.3s C:\Program Files\EMET 4.1\EMET_CE64.dll
-0.3s C:\Program Files\EMET 4.1\DevExpress.Utils.v12.2.dll
-0.3s C:\Program Files\EMET 4.1\Deployment\Protection Profiles\
-0.3s C:\Program Files\EMET 4.1\Deployment\Protection Profiles\Recommended Software.xml
-0.3s C:\Program Files\EMET 4.1\Deployment\
-0.2s C:\Program Files\EMET 4.1\DevExpress.Data.v12.2.dll
-0.1s C:\Program Files\EMET 4.1\DevExpress.XtraTreeList.v12.2.dll
-0.1s C:\Program Files\EMET 4.1\HelperLib.DLL
-0.1s C:\Program Files\EMET 4.1\Deployment\Protection Profiles\Popular Software.xml
-0.1s C:\Program Files\EMET 4.1\Deployment\Protection Profiles\CertTrust.xml
-0.1s C:\Program Files\EMET 4.1\EMET64.dll
-0.1s C:\Program Files\EMET 4.1\TrayIconSubsystem.DLL
-0.1s C:\Program Files\EMET 4.1\EMET_GUI.exe
-0.1s C:\Program Files\EMET 4.1\Privacy Statement.rtf
-0.1s C:\Program Files\EMET 4.1\ReportingSubsystem.DLL
-0.1s C:\Windows\AppPatch\AppPatch64\
-0.1s C:\Windows\AppPatch\AppPatch64\EMET64.dll
-0.1s C:\Program Files\EMET 4.1\Deployment\Group Policy Files\
-0.1s C:\Program Files\EMET 4.1\Deployment\Group Policy Files\EMET.admx
-0.0s C:\Program Files\EMET 4.1\EMET_CE.dll
-0.0s C:\Program Files\EMET 4.1\EMET User's Guide.pdf
-0.0s C:\Windows\AppPatch\EMET.dll
0.0s C:\Program Files\EMET 4.1\SdbHelper.dll
0.0s C:\Program Files\EMET 4.1\EMET_Agent.exe
0.0s C:\Program Files\EMET 4.1\MitigationInterface.DLL
0.0s C:\Program Files\EMET 4.1\EMET.dll
0.0s C:\Program Files\EMET 4.1\Deployment\Group Policy Files\EMET.adml
0.0s C:\Program Files\EMET 4.1\EMET_Conf.exe
0.1s C:\Program Files\EMET 4.1\DevExpress.UserSkins.HighContrast.DLL
0.1s C:\Program Files\EMET 4.1\EULA.rtf
0.1s C:\Program Files\EMET 4.1\DevExpress.XtraBars.v12.2.dll
0.2s C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Enhanced Mitigation Experience Toolkit\
0.2s C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Enhanced Mitigation Experience Toolkit\EMET User's Guide.lnk
0.2s C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Enhanced Mitigation Experience Toolkit\EMET GUI.lnk
1.4s C:\Windows\Installer\820bc.msi
4.1s C:\Windows\Installer\{6A09FEB2-691C-456B-B982-2F6D21B19602}\
4.1s C:\Windows\Installer\{6A09FEB2-691C-456B-B982-2F6D21B19602}\_6FEFF9B68218417F98F549.exe
4.1s C:\Windows\Installer\{6A09FEB2-691C-456B-B982-2F6D21B19602}\_473CF2B5F1EA938530A0D6.exe
4.1s C:\Windows\Installer\{6A09FEB2-691C-456B-B982-2F6D21B19602}\_525CC45CD60B26F71FB442.exe

C:\Program Files\EMET 4.1\EMET_CE64.dll
Size . . . . . . . : 91.648 bytes
Age . . . . . . . : 0.9 days (2014-05-07 11:41:22)
Entropy . . . . . : 5.7
SHA-256 . . . . . : F84A436B8F01794766BFA2185ACE65BD839046A991FB5C391ED304754BDBFCF2
RSA Key Size . . . : 2048
Authenticode . . . : Invalid
Fuzzy . . . . . . : 22.0
Program is altered or corrupted since it was code signed by its author. This is typical for malware and pirated software.
File belongs to an identified security risk.
Authors name is missing in version info. This is not common to most programs.
Version control is missing. This file is probably created by an individual. This is not typical for most programs.
Time indicates that the file appeared recently on this computer.
The file appears to be part of an installation package or setup program. This is typical for most programs.
Forensic Cluster
-3.4s C:\Users\XXXXXXX\AppData\Local\Temp\CFG3301.tmp
-0.1s C:\Program Files\EMET 4.1\
-0.1s C:\Program Files\EMET 4.1\DevExpress.XtraEditors.v12.2.dll
0.0s C:\Program Files\EMET 4.1\PKIPinningSubsystem.DLL
0.0s C:\Program Files\EMET 4.1\EMET_CE64.dll
0.0s C:\Program Files\EMET 4.1\DevExpress.Utils.v12.2.dll
0.0s C:\Program Files\EMET 4.1\Deployment\Protection Profiles\
0.0s C:\Program Files\EMET 4.1\Deployment\Protection Profiles\Recommended Software.xml
0.0s C:\Program Files\EMET 4.1\Deployment\
0.1s C:\Program Files\EMET 4.1\DevExpress.Data.v12.2.dll
0.2s C:\Program Files\EMET 4.1\DevExpress.XtraTreeList.v12.2.dll
0.2s C:\Program Files\EMET 4.1\HelperLib.DLL
0.2s C:\Program Files\EMET 4.1\Deployment\Protection Profiles\Popular Software.xml
0.2s C:\Program Files\EMET 4.1\Deployment\Protection Profiles\CertTrust.xml
0.2s C:\Program Files\EMET 4.1\EMET64.dll
0.2s C:\Program Files\EMET 4.1\TrayIconSubsystem.DLL
0.2s C:\Program Files\EMET 4.1\EMET_GUI.exe
0.3s C:\Program Files\EMET 4.1\Privacy Statement.rtf
0.3s C:\Program Files\EMET 4.1\ReportingSubsystem.DLL
0.3s C:\Windows\AppPatch\AppPatch64\
0.3s C:\Windows\AppPatch\AppPatch64\EMET64.dll
0.3s C:\Program Files\EMET 4.1\Deployment\Group Policy Files\
0.3s C:\Program Files\EMET 4.1\Deployment\Group Policy Files\EMET.admx
0.3s C:\Program Files\EMET 4.1\EMET_CE.dll
0.3s C:\Program Files\EMET 4.1\EMET User's Guide.pdf
0.3s C:\Windows\AppPatch\EMET.dll
0.3s C:\Program Files\EMET 4.1\SdbHelper.dll
0.3s C:\Program Files\EMET 4.1\EMET_Agent.exe
0.3s C:\Program Files\EMET 4.1\MitigationInterface.DLL
0.3s C:\Program Files\EMET 4.1\EMET.dll
0.3s C:\Program Files\EMET 4.1\Deployment\Group Policy Files\EMET.adml
0.3s C:\Program Files\EMET 4.1\EMET_Conf.exe
0.4s C:\Program Files\EMET 4.1\DevExpress.UserSkins.HighContrast.DLL
0.4s C:\Program Files\EMET 4.1\EULA.rtf
0.4s C:\Program Files\EMET 4.1\DevExpress.XtraBars.v12.2.dll
0.5s C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Enhanced Mitigation Experience Toolkit\
0.5s C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Enhanced Mitigation Experience Toolkit\EMET User's Guide.lnk
0.5s C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Enhanced Mitigation Experience Toolkit\EMET GUI.lnk
1.7s C:\Windows\Installer\820bc.msi

4.4s C:\Windows\Installer\{6A09FEB2-691C-456B-B982-2F6D21B19602}\
4.4s C:\Windows\Installer\{6A09FEB2-691C-456B-B982-2F6D21B19602}\_6FEFF9B68218417F98F549.exe
4.4s C:\Windows\Installer\{6A09FEB2-691C-456B-B982-2F6D21B19602}\_473CF2B5F1EA938530A0D6.exe
4.4s C:\Windows\Installer\{6A09FEB2-691C-456B-B982-2F6D21B19602}\_525CC45CD60B26F71FB442.exe

C:\Windows\AppPatch\AppPatch64\EMET64.dll
Size . . . . . . . : 153.608 bytes
Age . . . . . . . : 0.9 days (2014-05-07 11:41:23)
Entropy . . . . . : 6.0
SHA-256 . . . . . : 946B513BA70892196FBD5DE54616511EBE7C74F52F133B3B2D6B071C42574AF8
Publisher . . . . : Microsoft Corporation
Description . . . : EMET SHIM
Version . . . . . : 4.1.5228.513
Copyright . . . . : © Microsoft Corporation. All rights reserved.
RSA Key Size . . . : 2048
Authenticode . . . : Invalid
Fuzzy . . . . . . : 22.0
Program is altered or corrupted since it was code signed by its author. This is typical for malware and pirated software.
Time indicates that the file appeared recently on this computer.
Forensic Cluster
-3.7s C:\Users\XXXXXXX\AppData\Local\Temp\CFG3301.tmp
-0.3s C:\Program Files\EMET 4.1\
-0.3s C:\Program Files\EMET 4.1\DevExpress.XtraEditors.v12.2.dll
-0.3s C:\Program Files\EMET 4.1\PKIPinningSubsystem.DLL
-0.3s C:\Program Files\EMET 4.1\EMET_CE64.dll
-0.2s C:\Program Files\EMET 4.1\DevExpress.Utils.v12.2.dll
-0.2s C:\Program Files\EMET 4.1\Deployment\Protection Profiles\
-0.2s C:\Program Files\EMET 4.1\Deployment\Protection Profiles\Recommended Software.xml
-0.2s C:\Program Files\EMET 4.1\Deployment\
-0.1s C:\Program Files\EMET 4.1\DevExpress.Data.v12.2.dll
-0.1s C:\Program Files\EMET 4.1\DevExpress.XtraTreeList.v12.2.dll
-0.1s C:\Program Files\EMET 4.1\HelperLib.DLL
-0.1s C:\Program Files\EMET 4.1\Deployment\Protection Profiles\Popular Software.xml
-0.1s C:\Program Files\EMET 4.1\Deployment\Protection Profiles\CertTrust.xml
-0.0s C:\Program Files\EMET 4.1\EMET64.dll
-0.0s C:\Program Files\EMET 4.1\TrayIconSubsystem.DLL
-0.0s C:\Program Files\EMET 4.1\EMET_GUI.exe
0.0s C:\Program Files\EMET 4.1\Privacy Statement.rtf
0.0s C:\Program Files\EMET 4.1\ReportingSubsystem.DLL
0.0s C:\Windows\AppPatch\AppPatch64\
0.0s C:\Windows\AppPatch\AppPatch64\EMET64.dll
0.0s C:\Program Files\EMET 4.1\Deployment\Group Policy Files\
0.0s C:\Program Files\EMET 4.1\Deployment\Group Policy Files\EMET.admx
0.0s C:\Program Files\EMET 4.1\EMET_CE.dll
0.0s C:\Program Files\EMET 4.1\EMET User's Guide.pdf
0.0s C:\Windows\AppPatch\EMET.dll
0.1s C:\Program Files\EMET 4.1\SdbHelper.dll
0.1s C:\Program Files\EMET 4.1\EMET_Agent.exe
0.1s C:\Program Files\EMET 4.1\MitigationInterface.DLL
0.1s C:\Program Files\EMET 4.1\EMET.dll
0.1s C:\Program Files\EMET 4.1\Deployment\Group Policy Files\EMET.adml
0.1s C:\Program Files\EMET 4.1\EMET_Conf.exe
0.1s C:\Program Files\EMET 4.1\DevExpress.UserSkins.HighContrast.DLL
0.1s C:\Program Files\EMET 4.1\EULA.rtf
0.1s C:\Program Files\EMET 4.1\DevExpress.XtraBars.v12.2.dll
0.2s C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Enhanced Mitigation Experience Toolkit\
0.2s C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Enhanced Mitigation Experience Toolkit\EMET User's Guide.lnk
0.2s C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Enhanced Mitigation Experience Toolkit\EMET GUI.lnk
1.5s C:\Windows\Installer\820bc.msi
4.2s C:\Windows\Installer\{6A09FEB2-691C-456B-B982-2F6D21B19602}\
4.2s C:\Windows\Installer\{6A09FEB2-691C-456B-B982-2F6D21B19602}\_6FEFF9B68218417F98F549.exe
4.2s C:\Windows\Installer\{6A09FEB2-691C-456B-B982-2F6D21B19602}\_473CF2B5F1EA938530A0D6.exe
4.2s C:\Windows\Installer\{6A09FEB2-691C-456B-B982-2F6D21B19602}\_525CC45CD60B26F71FB442.exe

C:\Windows\AppPatch\EMET.dll
Size . . . . . . . : 552.456 bytes
Age . . . . . . . : 0.9 days (2014-05-07 11:41:23)
Entropy . . . . . : 5.5
SHA-256 . . . . . : F7D1AD6959D3229D21C29033FED782AC9C9C7A9E7BA20AF49DC3A3E01EF1318B
Publisher . . . . : Microsoft Corporation
Description . . . : EMET SHIM
Version . . . . . : 4.1.5228.513
Copyright . . . . : © Microsoft Corporation. All rights reserved.
RSA Key Size . . . : 2048
Authenticode . . . : Invalid
Fuzzy . . . . . . : 24.0
Program is altered or corrupted since it was code signed by its author. This is typical for malware and pirated software.
Time indicates that the file appeared recently on this computer.
The file is in use by one or more active processes.
Forensic Cluster
-3.7s C:\Users\XXXXXXX\AppData\Local\Temp\CFG3301.tmp
-0.4s C:\Program Files\EMET 4.1\
-0.4s C:\Program Files\EMET 4.1\DevExpress.XtraEditors.v12.2.dll
-0.3s C:\Program Files\EMET 4.1\PKIPinningSubsystem.DLL
-0.3s C:\Program Files\EMET 4.1\EMET_CE64.dll
-0.3s C:\Program Files\EMET 4.1\DevExpress.Utils.v12.2.dll
-0.3s C:\Program Files\EMET 4.1\Deployment\Protection Profiles\
-0.3s C:\Program Files\EMET 4.1\Deployment\Protection Profiles\Recommended Software.xml
-0.3s C:\Program Files\EMET 4.1\Deployment\
-0.2s C:\Program Files\EMET 4.1\DevExpress.Data.v12.2.dll
-0.1s C:\Program Files\EMET 4.1\DevExpress.XtraTreeList.v12.2.dll
-0.1s C:\Program Files\EMET 4.1\HelperLib.DLL
-0.1s C:\Program Files\EMET 4.1\Deployment\Protection Profiles\Popular Software.xml
-0.1s C:\Program Files\EMET 4.1\Deployment\Protection Profiles\CertTrust.xml
-0.1s C:\Program Files\EMET 4.1\EMET64.dll
-0.1s C:\Program Files\EMET 4.1\TrayIconSubsystem.DLL
-0.1s C:\Program Files\EMET 4.1\EMET_GUI.exe
-0.0s C:\Program Files\EMET 4.1\Privacy Statement.rtf
-0.0s C:\Program Files\EMET 4.1\ReportingSubsystem.DLL
-0.0s C:\Windows\AppPatch\AppPatch64\
-0.0s C:\Windows\AppPatch\AppPatch64\EMET64.dll
-0.0s C:\Program Files\EMET 4.1\Deployment\Group Policy Files\
-0.0s C:\Program Files\EMET 4.1\Deployment\Group Policy Files\EMET.admx
-0.0s C:\Program Files\EMET 4.1\EMET_CE.dll
-0.0s C:\Program Files\EMET 4.1\EMET User's Guide.pdf
0.0s C:\Windows\AppPatch\EMET.dll
0.0s C:\Program Files\EMET 4.1\SdbHelper.dll
0.0s C:\Program Files\EMET 4.1\EMET_Agent.exe
0.0s C:\Program Files\EMET 4.1\MitigationInterface.DLL
0.0s C:\Program Files\EMET 4.1\EMET.dll
0.0s C:\Program Files\EMET 4.1\Deployment\Group Policy Files\EMET.adml
0.0s C:\Program Files\EMET 4.1\EMET_Conf.exe
0.1s C:\Program Files\EMET 4.1\DevExpress.UserSkins.HighContrast.DLL
0.1s C:\Program Files\EMET 4.1\EULA.rtf
0.1s C:\Program Files\EMET 4.1\DevExpress.XtraBars.v12.2.dll
0.2s C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Enhanced Mitigation Experience Toolkit\
0.2s C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Enhanced Mitigation Experience Toolkit\EMET User's Guide.lnk
0.2s C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Enhanced Mitigation Experience Toolkit\EMET GUI.lnk
1.4s C:\Windows\Installer\820bc.msi
4.1s C:\Windows\Installer\{6A09FEB2-691C-456B-B982-2F6D21B19602}\
4.1s C:\Windows\Installer\{6A09FEB2-691C-456B-B982-2F6D21B19602}\_6FEFF9B68218417F98F549.exe
4.1s C:\Windows\Installer\{6A09FEB2-691C-456B-B982-2F6D21B19602}\_473CF2B5F1EA938530A0D6.exe
4.1s C:\Windows\Installer\{6A09FEB2-691C-456B-B982-2F6D21B19602}\_525CC45CD60B26F71FB442.exe

08-05-2014, 10:34 door Spiff has left the building

Door Fwiffo:
Het probleem met Windows Vista staat ondertussen ook op http://social.technet.microsoft.com/Forums/systemcenter/en-US/9b01619e-4349-4cef-b52c-1e50f0d7e838/how-to-update-emet-41-silentunattended-to-emet-41-update-1?forum=emet! Met afbeeldingen.

Ha, dank je voor de tip.
Of ben je zelfs misschien zelf die poster? Bedankt voor het posten op TechNet Forums dan.
In dat geval zou het wellicht waardevol zijn dat dan naast de afbeeldingen van de "Certificate" pagina ook nog even een afbeelding van de "Details" pagina bijgevoegd zou worden, waarop zichtbaar is dat daarop wordt weergegeven dat daar onder "Gegevens van de ondertekenaar" voor "Tijdstip van handtekening" "Niet beschikbaar" wordt weergegeven en onder "Controlehandtekeningen" niets wordt weergegeven. Dit aanvullend op de korte beschrijving daarvan die nu slechts vermeld wordt, "It turned out that on Windows Vista the signing time of the certificate is not available and the certificate isn't validated correctly."
Ik zou het zelf even doen, als ik een Engelstalige Vista editie had. Een afbeelding met Nederlandse tekst zal voor velen wellicht niet duidelijk zijn.

08-05-2014, 10:58 door Anoniem

Ook bij mij vertoonde dat PowerPivot_for_Excel_x86.msi in Windows XP (32bit) een soortgelijk gedrag als bij EMET4.1u1.
Ook nu weer geen controlehandtekening zichtbaar.
Alleen werd nu wel binnen de ondertekening het afzonderlijke certificaat van "Micosoft Corporation" afgekeurd,
omdat het verlopen is, zodat sowieso de hele ondertekening werd afgekeurd.
Dit was met EMET4.1u1 niet zo. En dat is wel even een duidelijk verschil.

Ook heb ik PowerPivot_for_Excel_x86.msi eens voorgelegd aan windows ME.
Het bleek dat nu alle tabs ontbraken(!), behalve de tab "Algemeen".
(bij EMET4.1u1 ontbreekt onder Windows ME alleen de tab "digitale handtekeningen")

Het begint er wat mij betreft steeds meer op te lijken dat het een "parser <-> certificaat" compatibliteitsprobleem is,
en/of dat er een probleem zit in de subsystemen waar de parser gebruik van maakt.
Het ligt ook wel voor de hand dat ieder OS weer een net iets andere parser heeft, die standaard uitgaat van een
certificaatstructuur die "normaal" was ten tijde dat het OS uitkwam. (evt. met updates nog wel eens wat bijgespijkerd)
Door voortschrijdend inzicht en de stand van de techniek verandert de gangbare certificaatstandaard.
Maar oudere parsers kunnen dan interpretatieproblemen krijgen. Daarom geeft m.i. Windows ME ook de grootste afwijkingen: de parser van ME is oorspronkelijk niet voor onze moderne hedendaagse certificaten gemaakt.

Je ziet in de door ons onderzochte ondertekeningen/certificaten onderling ook wel enkele structurele verschillen.
De oudere certificaten gebruiken het sha1-algoritme. Bij de meest recente wordt opeens sha256 gebruikt.
En als je heel nauwkeurig de certificaatdetails van de geteste bestanden met elkaar vergelijkt, dan stuit je af en toe
op net even een andere volgorde van velden, of een andere benaming, of op een (nieuw) veld meer of minder.
Bij PowerPivot_for_Excel_x86.msi staat er bijv. in de "details"-lijst een veld méér dan bij EMET4.1u1.
De certificaatstructuur is m.i. hierdoor net even anders. En de vraag is of iedere parser daar correct mee om gaat.

Ook factoren als het wel of niet hebben van internetconnectie (i.v.m. controleren van ingetrokken certificaten e.d.)
en of er wel of niet bepaalde updates zijn uitgevoerd, zou het verschil kunnen maken tussen een goedgekeurde en een afgekeurde ondertekening. Just saying and sharing my thougths.
Mvg, cluc-cluc

08-05-2014, 10:59 door Spiff has left the building

Door Erik van Straten:

@ Ilja. _V V: Wat zegt sigcheck.exe van die bestanden (http://technet.microsoft.com/en-us/sysinternals/bb897441) gedraaid als: sigcheck -i -a -h filename?

Als Ilja er niet de tijd voor zou hebben, dan zou ik dat vanmiddag eventueel kunnen onderzoeken.
Maar dan heb ik het wel nodig even bij de hand genomen te worden met een detail-uitleg over hoe Sigcheck precies toe te passen op die EMET-files.
Ik ben geen pro en heb nooit goed geleerd hoe onder CMD met CD commando's te werken. Dat is nog altijd erg moeilijk voor me. Ik heb daardoor grote moeite met het toepassen van Sigcheck op files op andere plekken dan direct onder C:\
In de voorgaande thread heb ik dat toen maar opgelost door toen zowel sigcheck.exe en de te checken EMET installer tijdelijk maar even onder C:\ te plaatsen en Sigcheck daar uit te voeren onder CMD. Dát lukte me nog wel.
Maar geavanceerder navigeren met CD commando's, om Sigcheck nu toe te passen op die vier EMET files, daarvoor heb ik een uitgebreide handleiding of wellicht beter nog kant en klaar geformuleerde commando's nodig.

Ha, ik vraag nogal wat ;-)
Misschien dat Ilja op Fwiffo beter thuis zijn in navigeren met CD commando's en een van hen Sigcheck kan toepassen op die in de HitmanPro-log genoemde EMET-files.
En dan misschien bij voorkeur Fwiffo, omdat dat een Vista systeem betreft, en het bij Ilja een XP systeem betreft?

08-05-2014, 11:07 door Fwiffo

Door Spiff:Ha, dank je voor de tip.
Of ben je zelfs misschien zelf die poster? Bedankt voor het posten op TechNet Forums dan.

Nee hoor, hij had Aero niet uitstaan zodat je kan proberen te achterhalen wat er op zijn bureaublad staat. Zou ik niet zo snel doen.
Daarnaast probeer ik mijn aanwezigheid op het internet tot een minimum te beperken tegenwoordig. En daarmee ook het aantal accounts waar ik wachtwoorden voor beheer :-) Security.nl is al een uitzondering eigenlijk. Bovendien gebruik ik EMET niet meer vanwege problemen na microsoft update met IE 9. Die zijn nu allemaal over.

08-05-2014, 11:24 door Spiff has left the building - Bijgewerkt: 08-05-2014, 11:27

Door Fwiffo:
Bovendien gebruik ik EMET niet meer vanwege problemen na microsoft update met IE 9.

O ja, da's waar, dat had je verteld, eind vorige week, in de thread betreffend update KB2964358.

Dan zou het Ilja (op XP?) of ikzelf (met bij de hand genomen te worden met een detail-uitleg) moeten zijn die Sigcheck kan toepassen op die in de HitmanPro-log genoemde EMET-files.

PSje
Mijn probleem vorige week na installeren van update KB2964358 had helemaal niets met die update te maken, weet ik inmiddels. Mijn probleem toen is hoogswaarschijnlijk het gevolg geweest van het negeren van een firewall-verzoek om netwerkverbinding voor een bepaalde groep processen, zie https://www.security.nl/posting/386491#posting387203.
Maar dit terzijde.

08-05-2014, 11:46 door Anoniem

Door Fwiffo:
Misschien komt er een Update 2 van EMET met 'ouderwetse' signatures. Misschien wordt Windows Vista geupdated met een nieuwe crypto module. Windows XP is EOL, dus daar zal wel geen update meer voor komen (terwijl die Windows versie EMET het hardst nodig zal hebben vanwege 0-days).

Misschien moeten XP-gebruikers met alternatieve methoden de integriteit testen, zoals filesize, sha1 en/of sha256 en md5 checks... ;) Moet MS de juiste hashes wel even op hun downloadpagina vermelden. Mvg, cluc-cluc

08-05-2014, 12:01 door Spiff has left the building - Bijgewerkt: 08-05-2014, 12:02

N.B.
Betreffend HitmanPro en EMET 4.1 Update 1 zou het interessant zijn te weten of HitmanPro onder Windows 7 (of onder Windows 8) niet iets verdachts ziet in een geïnstalleerde EMET 4.1 Update 1, of eveneens.
Heeft iemand dat al onderzocht?

08-05-2014, 12:08 door Fwiffo

Door Spiff:Ik ben geen pro en heb nooit goed geleerd hoe onder CMD met CD commando's te werken. Dat is nog altijd erg moeilijk voor me. Ik heb daardoor grote moeite met het toepassen van Sigcheck op files op andere plekken dan direct onder C:\
In de voorgaande thread heb ik dat toen maar opgelost door toen zowel sigcheck.exe en de te checken EMET installer tijdelijk maar even onder C:\ te plaatsen en Sigcheck daar uit te voeren onder CMD. Dát lukte me nog wel.
Maar geavanceerder navigeren met CD commando's, om Sigcheck nu toe te passen op die vier EMET files, daarvoor heb ik een uitgebreide handleiding of wellicht beter nog kant en klaar geformuleerde commando's nodig.

Even uit mijn hoofd (zit onder linux): 'd:' (ga naar schijf d:, druk op enter) 'cd p' (druk op tab, desnoods meerdere malen, dan enter) 'cd EMET' (druk op tab, dan enter). Nu zit je als het goed is onder "D:\Program Files\EMET 4.1".
sigcheck kan je ook met de tab bereiken door er het volledige path (en de drive) voor te zetten (met behulp van [TAB]). Probleem hierbij kunnen verborgen directories zijn (kan je zichtbaar maken met 'dir /a').
Dit werkt niet voor versies ouder dan Windows 95 iirc, maar toen had je nog directories van maximaal 8 tekens :-) Een stuk overzichtelijker.

08-05-2014, 13:03 door Erik van Straten

Door Anoniem 2014-05-08 10:58 Ook bij mij vertoonde dat PowerPivot_for_Excel_x86.msi in Windows XP (32bit) een soortgelijk gedrag als bij EMET4.1u1.
Ook nu weer geen controlehandtekening zichtbaar.
Alleen werd nu wel binnen de ondertekening het afzonderlijke certificaat van "Micosoft Corporation" afgekeurd,
omdat het verlopen is, zodat sowieso de hele ondertekening werd afgekeurd.

Dit lijkt te bevestigen dat het probleem zit in de check op de time stamp.

Het idee achter Authenticode is dat de meegestuurde timestamp aangeeft dat alle gebruikte certificaten geldig waren op het moment van ondertekenen. Als daarna een of meer certificaten verlopen, dan maakt dat niet uit voor de check op authenticiteit en integriteit (zie bijv. "Best Practice: Time-stamping" onderaan http://blogs.msdn.com/b/ieinternals/archive/2011/03/22/authenticode-code-signing-for-developers-for-file-downloads-building-smartscreen-application-reputation.aspx).

Of het verstandig is te vertrouwen op verlopen certificaten (met mogelijk korte RSA sleutel en/of kraakbare hash techniek) is een andere discussie, maar de relatief korte geldigheidsduur van "end entity" certificaten maakt zo'n soort maatregel helaas noodzakelijk.

Doordat XP de timestamp onder PowerPivot_for_Excel_x86.msi niet kan checken, meldt deze dus terecht dat het signing certificate is verlopen.

08-05-2014, 13:08 door Spiff has left the building

Door Anoniem "cluc-cluc", 10:58 uur:
Ook bij mij vertoonde dat PowerPivot_for_Excel_x86.msi in Windows XP (32bit) een soortgelijk gedrag als bij EMET4.1u1.
Ook nu weer geen controlehandtekening zichtbaar.
Alleen werd nu wel binnen de ondertekening het afzonderlijke certificaat van "Micosoft Corporation" afgekeurd,
omdat het verlopen is, zodat sowieso de hele ondertekening werd afgekeurd.
Dit was met EMET4.1u1 niet zo. En dat is wel even een duidelijk verschil.

Je hebt gelijk.
Dat viel me gisteren ook op, maar het was erbij ingeschoten dat te vermelden.
Goed dat jij dat nog even vermeldde.

08-05-2014, 13:35 door Spiff has left the building

Door Erik van Straten:
@ Ilja. _V V: Wat zegt sigcheck.exe van die bestanden (http://technet.microsoft.com/en-us/sysinternals/bb897441) gedraaid als: sigcheck -i -a -h filename?

Door Spiff:
Als Ilja er niet de tijd voor zou hebben, dan zou ik dat vanmiddag eventueel kunnen onderzoeken.
Maar dan heb ik het wel nodig even bij de hand genomen te worden met een detail-uitleg over hoe Sigcheck precies toe te passen op die EMET-files.
Ik ben geen pro en heb nooit goed geleerd hoe onder CMD met CD commando's te werken. Dat is nog altijd erg moeilijk voor me. Ik heb daardoor grote moeite met het toepassen van Sigcheck op files op andere plekken dan direct onder C:\
In de voorgaande thread heb ik dat toen maar opgelost door toen zowel sigcheck.exe en de te checken EMET installer tijdelijk maar even onder C:\ te plaatsen en Sigcheck daar uit te voeren onder CMD. Dát lukte me nog wel.
Maar geavanceerder navigeren met CD commando's, om Sigcheck nu toe te passen op die vier EMET files, daarvoor heb ik een uitgebreide handleiding of wellicht beter nog kant en klaar geformuleerde commando's nodig.

Door Fwiffo:
Even uit mijn hoofd (zit onder linux): 'd:' (ga naar schijf d:, druk op enter) 'cd p' (druk op tab, desnoods meerdere malen, dan enter) 'cd EMET' (druk op tab, dan enter). Nu zit je als het goed is onder "D:\Program Files\EMET 4.1".
sigcheck kan je ook met de tab bereiken door er het volledige path (en de drive) voor te zetten (met behulp van [TAB]). Probleem hierbij kunnen verborgen directories zijn (kan je zichtbaar maken met 'dir /a').

Dank je, Fwiffo, maar het spijt me, daarmee kom ik er niet uit.
Ik begrijp je uitleg waarschijnlijk niet goed (of anders zijn je aanwijzingen mogelijk niet toepasbaar onder CMD in Vista).
Ik heb werkelijk een uitgebreide detail handleiding of wellicht beter nog kant en klaar geformuleerde commando's nodig.

Beter nog, ik moet zelf eens gaan leren over directory navigatie en het uitvoeren van bestanden specifiek voor bepaalde directories onder Windows Command Prompt. Dus: Aan de slag met een aantal Beginners guides to the Windows Command Line. Maar dat gaat even duren.
Om de vaart erin te houden zou het om Sigcheck nu vlot toe te kunnen passen op die vier EMET files die aangestipt worden door HitmanPro handig zijn om even werkelijk 'bij de hand genomen' te worden.

08-05-2014, 13:42 door Anoniem

Door Erik van Straten: Dit lijkt te bevestigen dat het probleem zit in de check op de time stamp.

Hoezo Erik? Ik meende gezien te hebben dat het "Microsoft Corporation" certificaat van het "PowerPivot"-bestand o.a. een andere geldigheidsdatum heeft, en dat dit certificaat dus terecht wordt afgekeurd. De EMET4.1u1 had meende ik een recenter "Microsoft Corporation"-certificaat, en daarom wordt die dus niet afgekeurd. Lijkt me correct.
(M.a.w.: de twee bestanden hebben volgens mij gewoon niet exact hetzelfde "Microsoft Corporation" certificaat)
Mvg, cluc-cluc

08-05-2014, 14:12 door Anoniem

Hallo

Ik weet niet of je hier iets aan hebt. (maar ik dacht kan het altijd even plaatsen om te kijken of je hier veder mee komt of niet)

Er van uitgaande dat je in de map Program files op de C: schijf staat zal je het volgende kunnen proberen.
(ik heb de commando's tussen " " geplaatst . Deze kun je overnemen zonder de ".)

Als je in CMD niet op de C; schijf begint maar in een directory (bijvoorbeeld C:\windows) dan moet je eerst terug naar de C:\ Dit kan je doen door de commando "cd\"
Nu zal er moeten staan C:\.
Je geeft nu de commando "cd progra~1" (dit omdat er maximaal 8 karaters in dos kan hebben).
er zal nu staan C:\progra~1 (of c:\Programfiles)
Daarna geef je de commando "cd EMET" (ervan uitgaande dat de directory Emet is anders afkorten tot 6 karater gevolgd door een ~1 een spatie in windows word in dos een _ (underscore))
Er zal nu staatn C:\progra~1\EMET (ervan uitgaande dat de directory EMET is.

Kort nog even de de commando's
cd\ = ga terug naar de root
cd = go to directory
meer dan 8 karakter afkorten tot 6 gevolgd door ~1
een spatie en windows word een _ (Underscore) in dos
Ik hoop dat dit je verder kan helpen.

08-05-2014, 14:24 door Spiff has left the building - Bijgewerkt: 08-05-2014, 14:26

Door Erik van Straten:
Wat zegt sigcheck.exe van die bestanden (http://technet.microsoft.com/en-us/sysinternals/bb897441) gedraaid als: sigcheck -i -a -h filename?

Toch reeds gelukt zonder 'bij de hand genomen' te hoeven worden ;-)

Sigcheck toegepast op de vier EMET files die aangestipt worden door HitmanPro zoals weergegeven in het HitmanPro log dat ik vandaag om 10:17 uur plaatste (https://www.security.nl/posting/386805#posting387259).

Hieronder de Sigcheck weergave:

Sigcheck v2.1 - File version and signature viewer
Copyright (C) 2004-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\Program Files\EMET 4.1\EMET_Agent.exe:
Verified: De digitale handtekening van het object kan niet worden gecontroleerd.
Link date: 10:17 25-4-2014
Publisher: Microsoft Corporation
Description: EMET_Agent
Product: Enhanced Mitigation Experience Toolkit
Prod version: 4.1.5228.513
File version: 4.1.5228.513
MachineType: 32-bit
Binary Version: 4.1.5228.513
Original Name: EMET_Agent.exe
Internal Name: EMET_Agent.exe
Copyright: ® Microsoft Corporation. All rights reserved.
Comments: EMET_Agent
Entropy: 7.036
MD5: 9A6902AA5C3F47987B0B5018AE3DCFD7
SHA1: B531E8C1BE23C3691AEEE8E90312801E5D04AEBF
PESHA1: B579C2D040FAF7B1E95AA51AF32692F01A80A9B6
PE256: n/a
SHA256: 02377C6EA2C7D121ACDC7228493B58BC5E786B9E71CD725471DCFAE7E9A625C4

Sigcheck v2.1 - File version and signature viewer
Copyright (C) 2004-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\Program Files\EMET 4.1\EMET_CE64.dll:
Verified: De digitale handtekening van het object kan niet worden gecontroleerd.
Link date: 10:33 25-4-2014
Publisher: n/a
Description: n/a
Product: n/a
Prod version: n/a
File version: n/a
MachineType: 64-bit
Binary Version: n/a
Original Name: n/a
Internal Name: n/a
Copyright: n/a
Comments: n/a
Entropy: 5.712
MD5: 3223CE03772DF3F4481552D1BE7852C8
SHA1: 07879C690CD8418A6BA83D814D669E9C06CBC705
PESHA1: F0770E50F85C215143DC0EF855A4C2F497C9A42D
PE256: n/a
SHA256: F84A436B8F01794766BFA2185ACE65BD839046A991FB5C391ED304754BDBFCF2

Sigcheck v2.1 - File version and signature viewer
Copyright (C) 2004-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\Windows\AppPatch\AppPatch64\EMET64.dll:
Verified: De digitale handtekening van het object kan niet worden gecontroleerd.
Link date: 10:22 25-4-2014
Publisher: Microsoft Corporation
Description: EMET SHIM
Product: n/a
Prod version: 4.1.5228.513
File version: 4.1.5228.513
MachineType: 64-bit
Binary Version: 4.1.5228.513
Original Name: n/a
Internal Name: n/a
Copyright: ® Microsoft Corporation. All rights reserved.
Comments: n/a
Entropy: 6.02
MD5: F7CB1B3BAA2BAE6FF8878FBFD9929A28
SHA1: 4772294A6CFFBAB56CDA4DE28A1016A528B45700
PESHA1: 0314BC1DC0246CD412D099C7523D203E7077BF11
PE256: n/a
SHA256: 946B513BA70892196FBD5DE54616511EBE7C74F52F133B3B2D6B071C42574AF8

Sigcheck v2.1 - File version and signature viewer
Copyright (C) 2004-2014 Mark Russinovich
Sysinternals - www.sysinternals.com

C:\Windows\AppPatch\EMET.dll:
Verified: De digitale handtekening van het object kan niet worden gecontroleerd.
Link date: 10:22 25-4-2014
Publisher: Microsoft Corporation
Description: EMET SHIM
Product: n/a
Prod version: 4.1.5228.513
File version: 4.1.5228.513
MachineType: 32-bit
Binary Version: 4.1.5228.513
Original Name: n/a
Internal Name: n/a
Copyright: ® Microsoft Corporation. All rights reserved.
Comments: n/a
Entropy: 5.497
MD5: 749189F8372856DC4959BF8E39CDA351
SHA1: 38C943B950F0F70A32E26326378508F1374C22D3
PESHA1: 8F6F8490A5218D6BF1B2E76B67424488A2ADF355
PE256: n/a
SHA256: F7D1AD6959D3229D21C29033FED782AC9C9C7A9E7BA20AF49DC3A3E01EF1318B

08-05-2014, 15:51 door [Account Verwijderd] - Bijgewerkt: 08-05-2014, 15:53

Naar aanleiding van de reactie van Erik van Straten (08-05-2014 9:11), op het Windows 7 systeem waarbij de problemen waren, EMET 4.1 update 1 verwijderd. Vervolgens verbinding gemaakt met internet en EMET 4.1 update 1 opnieuw gedownload en met internetverbinding geïnstalleerd.

Deze keer was alles in orde en stond er bij de melding van Gebruikersaccountbeheer ook gecontroleerde uitgever. EMET is dus op beide Windows 7 systeem met succes geïnstalleerd. Bedankt :-)

08-05-2014, 16:06 door [Account Verwijderd] - Bijgewerkt: 08-05-2014, 16:07

@Spiff, op 07-05-2014 om 12:51 gaf je aan dat je EMET 4.1 update 1 inmiddels met succes had geïnstalleerd en geconfigureerd. krijg je ook bij het open voor van EMET4.1u1 wanneer je deze wilt configureren de melding dat de digitale handtekening ongeldig is of is dit alleen bij de installatie van EMET4.1u1?

08-05-2014, 16:55 door Spiff has left the building

Door kraai, 15:51 uur:
Naar aanleiding van de reactie van Erik van Straten (08-05-2014 9:11), op het Windows 7 systeem waarbij de problemen waren, EMET 4.1 update 1 verwijderd. Vervolgens verbinding gemaakt met internet en EMET 4.1 update 1 opnieuw gedownload en met internetverbinding geïnstalleerd.
Deze keer was alles in orde en stond er bij de melding van Gebruikersaccountbeheer ook gecontroleerde uitgever. EMET is dus op beide Windows 7 systeem met succes geïnstalleerd.

Mooi!
En interessant.
Bedankt voor je melding.

08-05-2014, 16:55 door Spiff has left the building

Door kraai, 16:06 uur:
@Spiff,
op 07-05-2014 om 12:51 gaf je aan dat je EMET 4.1 update 1 inmiddels met succes had geïnstalleerd en geconfigureerd.
Krijg je ook bij het open voor van EMET4.1u1 wanneer je deze wilt configureren de melding dat de digitale handtekening ongeldig is of is dit alleen bij de installatie van EMET4.1u1?

Bij het openen van de geïnstalleerde EMET 4.1 Update 1 geeft Gebruikersaccountbeheer deze melding:

Een onbekend programma wil toegang tot uw computer verkrijgen
Voer het programma niet uit tenzij u weet waar het vandaan komt of als u het eerder hebt gebruikt.
EMET_GUI.exe
Onbekende uitgever
"C:\program Files\EMET 4.1\EMET_GUI.exe"

08-05-2014, 17:21 door [Account Verwijderd] - Bijgewerkt: 08-05-2014, 17:21

Door Spiff:

Door kraai, 16:06 uur:
@Spiff,
op 07-05-2014 om 12:51 gaf je aan dat je EMET 4.1 update 1 inmiddels met succes had geïnstalleerd en geconfigureerd.
Krijg je ook bij het open voor van EMET4.1u1 wanneer je deze wilt configureren de melding dat de digitale handtekening ongeldig is of is dit alleen bij de installatie van EMET4.1u1?

Bij het openen van de geïnstalleerde EMET 4.1 Update 1 geeft Gebruikersaccountbeheer deze melding:

Een onbekend programma wil toegang tot uw computer verkrijgen
Voer het programma niet uit tenzij u weet waar het vandaan komt of als u het eerder hebt gebruikt.
EMET_GUI.exe
Onbekende uitgever
"C:\program Files\EMET 4.1\EMET_GUI.exe"

Als je eigenschappen gaat kijken en dan onder digitale handtekening van het bestand waar de link naar toe verwijst die je in de waarschuwing krijgt van Gebruikersaccountbeheer, Staat daar misschien dan iets van informatie?

08-05-2014, 17:41 door Spiff has left the building

@ Anoniem, 14:12 uur,
Dankjewel voor je tips voor directory navigatie.
Je bericht werd als reactie van oningelogde poster pas later geplaatst.
In de tussentijd had ik het navigeren door middel van cd inmiddels al onder de knie gekregen.
Enkel het uitvoeren van sigcheck commando's terwijl sigcheck.exe in een andere deel van het path staat, dat is me niet gelukt (dat moet ik nog eens leren voor een andere keer). Ik heb daarom tijdelijk sigcheck.exe naar de betreffende directories gekopieerd waar die uitgevoerd moest worden. Zo kreeg ik het wel voor elkaar om sigcheck uit te voeren voor de te checken files.
Nogmaals heel hartelijk bedankt voor je tips voor directory navigatie.

08-05-2014, 17:55 door Spiff has left the building - Bijgewerkt: 08-05-2014, 18:08

Door kraai, 17:21 uur:
Als je eigenschappen gaat kijken en dan onder digitale handtekening van het bestand waar de link naar toe verwijst die je in de waarschuwing krijgt van Gebruikersaccountbeheer, Staat daar misschien dan iets van informatie?

Voor C:\program Files\EMET 4.1\EMET_GUI.exe

Details van digitale handtekening
Gegevens voor Digitale handtekening
Deze digitale handtekening is ongeldig.
Gegevens van de ondertekenaar
Naam: Microsoft Corporation
Tijdstip van handtekening: Niet beschikbaar
Controlehandtekeningen: (niets weergegeven)

Certificaat
Algemeen
Certificaatinformatie
De digitale handtekening van het object kan niet worden gecontroleerd.
Verleend aan: Microsoft Corporation
Verleend door: Microsoft Code Signing PCA 2011
Geldig van 24-9-2013 t/m 24-12-2014

Certificaat
Certificerings pad
Microsoft Root Certificate Authority 2011
Microsoft Code Signing PCA 2011
Microsoft Corporation

Maar dat zal niet verbazen.
Ik neem aan dat de onderdelen van een geïnstalleerd programma dezelfde ondetekening dragen als de installer?

08-05-2014, 18:08 door [Account Verwijderd] - Bijgewerkt: 08-05-2014, 18:53

Door Spiff:

Door kraai, 17:21 uur:
Als je eigenschappen gaat kijken en dan onder digitale handtekening van het bestand waar de link naar toe verwijst die je in de waarschuwing krijgt van Gebruikersaccountbeheer, Staat daar misschien dan iets van informatie?

Voor C:\program Files\EMET 4.1\EMET_GUI.exe

Details van digitale handtekening
Gegevens voor Digitale handtekening
Deze digitale handtekening is ongeldig.
Gegevens van de ondertekenaar
Naam: Microsoft Corporation
Tijdstip van handtekening: Niet beschikbaar
Controlehandtekeningen: (niets weergegeven)

Certificaat
Algemeen
Certificaatinformatie
De digitale handtekening van het object kan niet worden gecontroleerd.
Verleend aan: Microsoft Corporation
Verleend door: Microsoft Code Signing PCA 2011
Geldig van 24-9-2013 t/m 24-12-2014

Certificaat
Certificerings pad
Microsoft Root Certificate Authority 2011
Microsoft Code Signing PCA 2011
Microsoft Corporation

Zoals je om 17:21 schreef krijg je een melding van Gebruikers accountbeheer waar onder anderen in staat "onbekende uitgever". Terwijl bij details van digitale handtekening wel een uitgever staat dit lijkt op het probleem wat ik eerst had, alleen ontbreekt er bij er het tijdstip van de handtekening wat ik er wel had staan

gewijzigd op 18:53
De digitale handtekening van het bestand waar de link die vermeld naartoe verwijst heeft een ander tijdstip van handtekening 29-04-2014 (2:36:51) als de installer (dinsdag 29 april 2014 19:43:45).

Maar het probleem is dus niet alleen bij de installatie van EMET4.1u1 begrijp ik.

08-05-2014, 18:18 door Spiff has left the building

Door kraai:
Maar het probleem is dus niet alleen bij de installatie van EMET4.1u1 begrijp ik.

Klopt.
Ook geeft Gebruikeraccountbeheer een afwijkende melding bij het openen van EMET, zoals ik hierboven 16:55 uur aangaf.
Maar dat verbaast niet, vermoed ik.
Want zoals ik aan mijn reactie van 17:55 uur net om 18:08 uur nog had toegevoegd - ik neem aan dat de onderdelen van een geïnstalleerd programma dezelfde ondetekening dragen als de installer? Wanneer Vista de ondertekening van de installer afkeurt/ niet herkent, dan zal het vervolgens ook de ondertekening van de onderdelen van een geïnstalleerd programma niet goedkeuren/ niet herkennen.

08-05-2014, 18:29 door Erik van Straten

Door Anoniem 2014-05-08 13:42:

Door Erik van Straten: Dit lijkt te bevestigen dat het probleem zit in de check op de time stamp.

Hoezo Erik? Ik meende gezien te hebben dat het "Microsoft Corporation" certificaat van het "PowerPivot"-bestand o.a. een andere geldigheidsdatum heeft, en dat dit certificaat dus terecht wordt afgekeurd. De EMET4.1u1 had meende ik een recenter "Microsoft Corporation"-certificaat, en daarom wordt die dus niet afgekeurd. Lijkt me correct.
(M.a.w.: de twee bestanden hebben volgens mij gewoon niet exact hetzelfde "Microsoft Corporation" certificaat)
Mvg, cluc-cluc

Inderdaad is voor de EMET download een ander signing certificaat gebruikt dan voor de PowerPivot download, en er is ook een ander time stamping certificaat gebruikt (dat bovendien ook is verlopen :)

De reden voor mij om Spiff te vragen de PowerPivot download te testen, was JUIST dat die certificaten afwijken, terwijl de root certificaten en intermediate certificaten identiek zijn.

Op mijn W7-64 machine hebben zowel de EMET download als de PowerPivot download een geldige handtekening, ongeacht verlopen certificaten in de PowerPivot download. Op de Vista PC van Spiff worden beide downloads afgekeurd.

Als je uit http://support.microsoft.com/kb/841290 Windows-KB841290-x86-ENU.exe downloadt (ca. 100KB) en de handtekening controleert, zul je zien dat die klopt. Echter, het signing certificaat, het time stamping certificaat en beide intermediate certificaten zijn verlopen.

Het probleem dat Spiff oorspronkelijk aankaartte lijkt te worden veroorzaakt door het niet kunnen verwerken van specifieke certificaten door besturingssystemen ouder dan Windows 7, niet door verlopen certificaten. Waarschijnlijk doordat het intermediate time stamp certificaat niet kan worden gevalideerd, kan de time stamp niet worden gevalideerd. Naast dat dit an sich een probleem is, leidt dit er bij de PowerPivot download ook toe dat het signing certificaat wordt afgekeurd omdat het verlopen is (iets dat niet zou gebeuren als de time stamp wel gevalideerd kan worden).

08-05-2014, 19:12 door [Account Verwijderd]

Door Spiff 08-05-2014, 18:18:
Want zoals ik aan mijn reactie van 17:55 uur net om 18:08 uur nog had toegevoegd - ik neem aan dat de onderdelen van een geïnstalleerd programma dezelfde ondetekening dragen als de installer? Wanneer Vista de ondertekening van de installer afkeurt/ niet herkent, dan zal het vervolgens ook de ondertekening van de onderdelen van een geïnstalleerd programma niet goedkeuren/ niet herkennen.

Ik ga er ook vanuit dat de onderdelen van een geïnstalleerd programma dezelfde ondertekening dragen als de installer. Ik denk dan ook dat we dus niet veel hebben aan wat ik in mijn reactie van 18:08 ( bijgewerkt op 18:53) schreef dat de digitale handtekening van de installer en De digitale handtekening van het bestand waar de link die vermeld naartoe verwijst (EMET_GUI.exe) een verschil hebben bij: "tijdstip van handtekening".

08-05-2014, 19:16 door Spiff has left the building

@ Erik van Straten,
Leverde de Sigcheck beoordeling die je Ilja had verzocht maar die ik om 14:24 uur heb geplaatst voor mijn Vista systeem (https://www.security.nl/posting/386805#posting387311) uitgaande van van het HitmanPro log voor mijn Vista systeem dat ik om 10:17 had geplaatst (https://www.security.nl/posting/386805#posting387259) misschien nog wat wetenswaardigs op?

08-05-2014, 21:12 door Ilja. _V V - Bijgewerkt: 08-05-2014, 21:14

Hier mijn XP Sigcheck Log:

c:\program files\emet 4.1\EMET_Agent.exe:
Verified: Bad Signature
Signing date: 10:28 29-4-2014
Publisher: Microsoft Corporation
Description: EMET_Agent
Product: Enhanced Mitigation Experience Toolkit
Version: 4.1.5228.513
File version: 4.1.5228.513
Strong Name: Unsigned
Original Name: EMET_Agent.exe
Internal Name: EMET_Agent.exe
Copyright: © Microsoft Corporation. All rights reserved.
Comments: EMET_Agent
MD5: 9a6902aa5c3f47987b0b5018ae3dcfd7
SHA1: b531e8c1be23c3691aeee8e90312801e5d04aebf
SHA256: 02377c6ea2c7d121acdc7228493b58bc5e786b9e71cd725471dcfae7e9a625c4

c:\program files\emet 4.1\HelperLib.DLL:
Verified: Bad Signature
Signing date: 10:28 29-4-2014
Publisher: n/a
Description: HelperLib
Product: HelperLib
Version: 4.1.5228.512
File version: 4.1.5228.512
Strong Name: Unsigned
Original Name: HelperLib.dll
Internal Name: HelperLib.dll
Copyright: Copyright © 2013
Comments: n/a
MD5: 576a12b5613972ae1caa756a819468da
SHA1: 5484da888b7859623902215f8b219f32268cae5c
SHA256: 21e3a0d30f8fbb00f5a982d8037e5499959b21f6720e6975dfe7cae416afa897

c:\program files\emet 4.1\PKIPinningSubsystem.DLL:
Verified: Bad Signature
Signing date: 10:28 29-4-2014
Publisher: n/a
Description: PKIPinningSubsystem
Product: PKIPinningSubsystem
Version: 4.1.5228.512
File version: 4.1.5228.512
Strong Name: Unsigned
Original Name: PKIPinningSubsystem.dll
Internal Name: PKIPinningSubsystem.dll
Copyright: Copyright © 2013
Comments: n/a
MD5: 1e7dec0ea7e802566eb01350eb295d94
SHA1: 3d6d8e68f0aef0d05d37d4208331f29b6effa501
SHA256: 1c215dd1cf48ec878bd1dd7aaf650556f2d4fc81ed0c3784b8bf9f02b7793035

c:\program files\emet 4.1\ReportingSubsystem.DLL:
Verified: Bad Signature
Signing date: 10:28 29-4-2014
Publisher: n/a
Description: ReportingSubsystem
Product: ReportingSubsystem
Version: 4.1.5228.513
File version: 4.1.5228.513
Strong Name: Unsigned
Original Name: ReportingSubsystem.dll
Internal Name: ReportingSubsystem.dll
Copyright: Copyright © 2013
Comments: n/a
MD5: 5a9e8904a709ed01404c2d64b1a80ac4
SHA1: 954a4444ff119af38083c8148440d5df0d0bc710
SHA256: 2c92492e4e502f422213bc2fb2437894f6d9901703ace4ae2475bc89479cd62f

c:\program files\emet 4.1\TrayIconSubsystem.DLL:
Verified: Bad Signature
Signing date: 10:28 29-4-2014
Publisher: n/a
Description: TrayIconSubsystem
Product: TrayIconSubsystem
Version: 4.1.5228.513
File version: 4.1.5228.513
Strong Name: Unsigned
Original Name: TrayIconSubsystem.dll
Internal Name: TrayIconSubsystem.dll
Copyright: Copyright © 2013
Comments: n/a
MD5: 103925205724030358a827086a0bd1dd
SHA1: 7f0bd0f773ae91a071f1dd900e2f98bd52a5160e
SHA256: 4c36235c73a0b9a0977de504ca33ae2546408b4ddd9d077bdb52bdab0f6317e2

Map- en bestandsnamen kopieren uit logbestand of Explorer adresbalk. In Opdrachtprompt tussen apostrofes plakken d.m.v. RechterMuisKlik DOS-icoon linksboven, Bewerken, Plakken.
Uitvoeren naar textbestand: Om te openen: > bestandsnaam, om aan te vullen: >> bestandsnaam.

C:\Documents and Settings\<Gebruikersnaam>>chdir "C:\Documents and Settings\<Gebruikersnaam>\Mijn documenten\Portable.Pack\SysinternalsSuite"
C:\Documents and Settings\<Gebruikersnaam>\Mijn documenten\Portable.Pack\SysinternalsSuite>sigcheck -i -a -h "C:\Program Files\EMET 4.1\EMET_Agent.exe" > "C:\Documents and Settings\All Users\Documenten\HitmanPro_20140508_0229.txt"
C:\Documents and Settings\<Gebruikersnaam>\Mijn documenten\Portable.Pack\SysinternalsSuite>sigcheck -i -a -h "C:\Program Files\EMET 4.1\TrayIconSubsystem.DLL" >> "C:\Documents and Settings\All Users\Documenten\HitmanPro_20140508_0229.txt"

08-05-2014, 21:54 door Anoniem

Door Spiff:
Of ben je zelfs misschien zelf die poster? Bedankt voor het posten op TechNet Forums dan.
In dat geval zou het wellicht waardevol zijn dat dan naast de afbeeldingen van de "Certificate" pagina ook nog even een afbeelding van de "Details" pagina bijgevoegd zou worden, waarop zichtbaar is dat daarop wordt weergegeven dat daar onder "Gegevens van de ondertekenaar" voor "Tijdstip van handtekening" "Niet beschikbaar" wordt weergegeven en onder "Controlehandtekeningen" niets wordt weergegeven. Dit aanvullend op de korte beschrijving daarvan die nu slechts vermeld wordt, "It turned out that on Windows Vista the signing time of the certificate is not available and the certificate isn't validated correctly."
Ik zou het zelf even doen, als ik een Engelstalige Vista editie had. Een afbeelding met Nederlandse tekst zal voor velen wellicht niet duidelijk zijn.

Bij dezen :-)

W. Spu

08-05-2014, 22:57 door Spiff has left the building

Door Fwiffo, 09:41 uur:
Het probleem met Windows Vista staat ondertussen ook op http://social.technet.microsoft.com/Forums/systemcenter/en-US/9b01619e-4349-4cef-b52c-1e50f0d7e838/how-to-update-emet-41-silentunattended-to-emet-41-update-1?forum=emet! Met afbeeldingen.

Inmiddels is daar voor dat probleem onder Vista (en eerder) met EMET [4.1u1] Setup.msi nu ook nog een afbeelding van de weergave van het "Digital Signature Details" venster toegevoegd, die eerder nog ontbrak.
Op volgorde:
http://social.technet.microsoft.com/Forums/getfile/454522
http://social.technet.microsoft.com/Forums/getfile/454521
http://social.technet.microsoft.com/Forums/getfile/453503
http://social.technet.microsoft.com/Forums/getfile/453506
Voor wie zelf wil zien hoe die weergave er nu precies uitziet.

08-05-2014, 23:33 door Spiff has left the building

Door Anoniem, "W. Spu", 21:54 uur:
Bij dezen :-)
W. Spu

Je oningelogd geposte reactie van 21:54 uur was om 22:57 uur nog niet zichtbaar,
maar aan m'n reactie van 22:57 uur zie je dat ik toen inmiddels zelf net ontdekt had dat in die TechNet Forums thread afbeeldingen waren bijgevoegd.
Mooi, dankjewel!

09-05-2014, 00:07 door Anoniem

Door Spiff: Je oningelogd geposte reactie van 21:54 uur was om 22:57 uur nog niet zichtbaar,
maar aan m'n reactie van 22:57 uur zie je dat ik toen inmiddels zelf net ontdekt had dat in die TechNet Forums thread afbeeldingen waren bijgevoegd.
Mooi, dankjewel!

Ik heb gisteren geprobeerd me te registreren. Helaas krijg ik de registratie mail niet binnen. Opnieuw registreren werkt niet omdat het mail adres en/of alias al bekend zijn. Ook een wachtwoord reset werkt niet. Ik heb (bij gebrek aan beter) de redactie hierover al gemaild maar ook daar nog geen reactie op gehad....

W. Spu

09-05-2014, 00:26 door [Account Verwijderd] - Bijgewerkt: 09-05-2014, 00:34

[Verwijderd]

09-05-2014, 03:05 door Anoniem

Eventjes een pas op de plaats tussen alle onderzoeken door: ;)

Bij win7 wordt EMET4.1u1 dus goedgekeurd
(maar kennelijk niet altijd zondermeer, gezien de ervaringen van kraai)
Bij XP en Vista niet: zie http://social.technet.microsoft.com/Forums/getfile/454521
Deze melding "This digital signature is not valid" heeft natuurlijk een reden.
Waar zit dan de oorzaak?

Wel, die zit in het feit dat het certificaat van de eindentiteit ergens een probleem heeft.
De foutmelding afkomstig van het certificaat van de eindentiteit luidt immers:
"the digital signature of the object did not verify"
Zie http://social.technet.microsoft.com/Forums/getfile/453503
En dáárom wordt dus de hele digitale handtekening ongeldig verklaard:
"This digital signature is not valid"

Maar gaat het hier nu om een aanwezig onderdeel dat niet deugd, of om een onderdeel dat ontbreekt?
De Nederlandse versie meldt: "De digitale handtekening van het object kan niet worden gecontroleerd."
Daarbij zou ik eerder denken aan iets dat ontbreekt of onleesbaar is: het kan niet worden gecontroleerd omdat
het er niet is (of anders omdat het door het systeem niet gevonden kan worden, bijv. omdat de datastructuur niet aan alle vereiste criteria voldoet, waardoor de parser zich er geen raad mee weet)

Daarom wil ik nu graag even iets heel zeker weten, wat ik niet met voldoende zekerheid uit de geschiedenis haal
en hier ter plekke niet zelf kan achterhalen.

Want kijk, die hele digitale handtekening bestaat enerzijds uit een keten van drie certificaten.
Deze keten zie je in http://social.technet.microsoft.com/Forums/getfile/453506
Anderszijds hoort er dan ook nog het zgn. "time-stamping certificaat" aanwezig te zijn.
Het time-stamping certificaat zou eigenlijk moeten staan onder "Countersignatures" in:
http://social.technet.microsoft.com/Forums/getfile/454521
Maar zoals je kunt zien, is dit veld in Vista (en ook in XP) helemaal leeg.

En mijn vraag is nu eigenlijk heel eenvoudig:

Is er bij win7 heus echt een timestamping certificaat in de digitale handtekening zichtbaar aanwezig,
die je kunt weergeven, en waarin dan ook duidelijk in de "Algemeen" of "General"-tab omschreven staat
dat dit certificaat is bedoeld voor "*het met de actuele tijd tekenen van gegevens" of zoiets???

Wat ik wil uitsluiten is dat win7 misschien gemakkelijker goedkeurt, of alternatieve controlemogelijkheden kent,
waar XP en Vista geen weet van hebben.
En dan kan het zijn dat win7 in het originele EMET4u1-bestand evengoed geen "time-stap certificaat" ziet
(omdat het er niet is). Maar op één of andere manier toch voldoende reden ziet om de digitale handtekening gewoon
goed te keuren. (als bijv. de hele certificaatketen 100% klopt, is die timestamp-controle dan nog wel zo belangrijk?...)

Ik vraag dit ook mede omdat ik het wat merkwaardig vond, dat de win7 PC van kraai eerst ook problemen had,
maar na een hernieuwde poging met internetconnectie opeens niet meer...

Dus mijn vraag is:
Is er in win7 systemen absoluut zo'n time-stamping certificaat aanwezig in het EMET4.1u1-bestand?
Zo ja, dan kunnen we denk ik wel vaststellen dat er een compatibiliteitsprobleem bestaat tussen Vista/XP
en de nieuwe generatie certificaten. En zo niet, dan heeft MS toch echt een misser met timestamps gemaakt.
Zoiets is al eens eerder gebeurd:
http://blogs.technet.com/b/srd/archive/2012/10/09/security-advisory-2749655-and-timestamping.aspx
(en nee, helaas, de 2749655-update helpt in dit geval niet :( (reeds uitgeprobeerd op XP))

Mvg. cluc-cluc

09-05-2014, 08:07 door Erik van Straten

Dank aan allen voor het posten van Hitman Pro en SigCheck logs. Mijn hoop was dat SigCheck details zou geven over wat er fout gaat, maar helaas is dat niet het geval. Kennelijk gebruiken beide tools Windows functionaliteit en melden daardoor slechts dat de handtekening niet klopt (wat onzin is).

Daarbij valt wel iets op: onder Vista (NL) is de melding van SigCheck: "De digitale handtekening van het object kan niet worden gecontroleerd" terwijl onder XP (UK) de melding luidt: "Bad Signature". Dat klinkt niet als een 1 op 1 vertaling, "Bad signature" kan ook worden uitgelegd als dat de handtekening niet klopt.

09-05-2014, 09:48 door Spiff has left the building

Door Anoniem, cluc-cluc, 03:05 uur:

Mijn vraag is nu eigenlijk heel eenvoudig:

Is er bij win7 heus echt een timestamping certificaat in de digitale handtekening zichtbaar aanwezig,
die je kunt weergeven, en waarin dan ook duidelijk in de "Algemeen" of "General"-tab omschreven staat
dat dit certificaat is bedoeld voor "het met de actuele tijd tekenen van gegevens" of zoiets???

Wat ik wil uitsluiten is dat win7 misschien gemakkelijker goedkeurt, of alternatieve controlemogelijkheden kent,
waar XP en Vista geen weet van hebben.
En dan kan het zijn dat win7 in het originele EMET4u1-bestand evengoed geen "time-stap certificaat" ziet
(omdat het er niet is). Maar op één of andere manier toch voldoende reden ziet om de digitale handtekening gewoon
goed te keuren. (als bijv. de hele certificaatketen 100% klopt, is die timestamp-controle dan nog wel zo belangrijk?...)

Dus mijn vraag is:
Is er in win7 systemen absoluut zo'n time-stamping certificaat aanwezig in het EMET4.1u1-bestand?
Zo ja, dan kunnen we denk ik wel vaststellen dat er een compatibiliteitsprobleem bestaat tussen Vista/XP
en de nieuwe generatie certificaten.
En zo niet, dan heeft MS toch echt een misser met timestamps gemaakt.

Een heel goeie vraag, denk ik.
Ik hoop dat iemand dat wil en kan onderzoeken en vermelden betreffend Windows 7.

09-05-2014, 11:38 door [Account Verwijderd]

Door Anoniem, cluc-cluc 09-05-2014 03:05:
Dus mijn vraag is:
Is er in win7 systemen absoluut zo'n time-stamping certificaat aanwezig in het EMET4.1u1-bestand?
Zo ja, dan kunnen we denk ik wel vaststellen dat er een compatibiliteitsprobleem bestaat tussen Vista/XP
en de nieuwe generatie certificaten. En zo niet, dan heeft MS toch echt een misser met timestamps gemaakt.

dit heb ik even gecontroleerd en bij windows 7 staat bij eigenschappen van de installer van EMET 4.1u1 controle handtekening ingevuld (onder tijdstempel staat: 29 april 2014 19:43:45)

Dus dan zou het zgn. "time-stamping certificaat" aanwezig moeten zijn.

09-05-2014, 12:35 door Anoniem

dit heb ik even gecontroleerd en bij windows 7 staat bij eigenschappen van de installer van EMET 4.1u1 controle handtekening ingevuld (onder tijdstempel staat: 29 april 2014 19:43:45)

Dus dan zou het zgn. "time-stamping certificaat" aanwezig moeten zijn.

Okee, dank je wel kraai. Dit komt overeen met wat Eric-Jan H te A op 06-05-2014, 00:13 schreef.
En ik ontdekte nog een link over dit onderwerp:
http://stackoverflow.com/questions/21930249/digital-signature-timestamp-not-available-on-xp-vista-causing-verification-fa

Al met al ben ik nu wel overtuigd.
De oorzaak moet haast wel een incompatibiliteit zijn van de nieuwe generatie certificaten met het oudere XP en Vista.
Er zal vast wel een fix gevonden kunnen worden, maar persoonlijk denk ik dan in de eerste plaats aan een aangepaste ondertekening door Microsoft, zodat ook XP en Vista alles weer goed kunnen herkennen en normaal behandelen.

Jullie mogen nog wel verder gaan, maar hiermee haak ik nu in principe af van deze thread, en het was mij een bijzonder groot genoegen om met iedereen dit onderwerp eens te onderzoeken. Allen bedankt! :)
Mvg, cluc-cluc

09-05-2014, 14:19 door Spiff has left the building - Bijgewerkt: 09-05-2014, 14:44

Door Anoniem, cluc-cluc, 12:35 uur:

En ik ontdekte nog een link over dit onderwerp:
http://stackoverflow.com/questions/21930249/digital-signature-timestamp-not-available-on-xp-vista-causing-verification-fa

Als ik het goed zie, betreft dat toch weer net wat anders.
De auteur van die post schrijft daar (overigens niet betreffend EMET, maar betreffend ReportViewer 2012 Runtime):

The signature is there, but the timestamp reports "Not available". Hitting Details also tells me the signing time is "Not available". The file itself is signed by an expired certificate, so naturally verification fails without this timestamp.

However, if I download the same file to a Windows 7 machine, the timestamp is present. Hitting Details shows me the countersignature, verification works, and installation proceeds correctly.

Dat detail "The file itself is signed by an expired certificate", dat is afwijkend van de Vista-weergave betreffend EMET 4.1u1. Betreffend EMET 4.1u1 wordt onder Vista geen verlopen certificaat vermeld.

Dat detail "The file itself is signed by an expired certificate" maakt het echter des te interessanter dat de auteur in het tweede deel van dat certificaat vermeldt dat Windows 7 géén probleem opmerkt. Is het certificaat verlopen, dan zou ook Windows 7 de ondertekening van het bestand niet mogen goedkeuren.

Op basis daarvan vraag ik me af:
Zou het mogelijk zijn dat, naast het verschijnsel dat onder Windows Vista de parser zich onvoldoende raad lijkt te weten met de ondertekening van de recente EMET installers, in tegenstelling daarop onder Windows 7 een ondertekening van een bestand met verlopen certificaat juist ten onrechte wordt goedgekeurd, zoals de geciteerde Stack Overflow post suggereert?
Dat zou dan niet slechts hinderlijk zijn zoals onder Vista, maar onder Windows 7 dan zeer kwalijk zijn.

Zie ik iets verkeerd?

09-05-2014, 14:49 door [Account Verwijderd]

Bij de installer van EMET4.1u1 heeft op Windows 7 toch geen verlopen certificaat? Deze zou namelijk geldig van :24- 9- 2013 t/m 24- 12- 2014.

De controle handtekening zou geldig zijn van 27- 3- 2013 t/m 27- 6- 2013.

Zie ik misschien ook iets verkeerd?

09-05-2014, 15:33 door Anoniem

Door Spiff: @ Anoniem, 14:12 uur,
Dankjewel voor je tips voor directory navigatie.
Je bericht werd als reactie van oningelogde poster pas later geplaatst.
In de tussentijd had ik het navigeren door middel van cd inmiddels al onder de knie gekregen.
Enkel het uitvoeren van sigcheck commando's terwijl sigcheck.exe in een andere deel van het path staat, dat is me niet gelukt (dat moet ik nog eens leren voor een andere keer). Ik heb daarom tijdelijk sigcheck.exe naar de betreffende directories gekopieerd waar die uitgevoerd moest worden. Zo kreeg ik het wel voor elkaar om sigcheck uit te voeren voor de te checken files.
Nogmaals heel hartelijk bedankt voor je tips voor directory navigatie.

Graag gedaan.
Die commando's kon ik nog herinderen van toen we thuis een 386 hadden (dos pc).
Ik heb nog even gegoogled naar een websie met DOS commando's. Mischien dat je daar de volgende keer wat aan hebt.
Ik kwam uit op de volgende website:
http://nl.wikipedia.org/wiki/Lijst_van_MS-DOS-commando's
hierop staan de meenste comando's die werken in DOS.

09-05-2014, 15:48 door Spiff has left the building - Bijgewerkt: 09-05-2014, 15:57

Door kraai:

Bij de installer van EMET4.1u1 heeft op Windows 7 toch geen verlopen certificaat? Deze zou namelijk geldig van :24- 9- 2013 t/m 24- 12- 2014.
De controle handtekening zou geldig zijn van 27- 3- 2013 t/m 27- 6- 2013.
Zie ik misschien ook iets verkeerd?

Nee, inderdaad, de installer van EMET4.1u1 heeft geen verlopen certificaat.
De auteur van die post op Stack Overflow had het niet over EMET, maar over ReportViewer 2012 Runtime.
Dat wat ik om 14:19 uur aangaf dat betreft niet EMET4.1u1.
Maar ik kan me voorstellen dat mijn bericht van 14:19 uur verwarring kan geven.
Daarom ter verduidelijking:

Ik opperde dat er sprake zou kunnen zijn van twee verschillende fenomenen:
1.
Het verschijnsel dat onder Windows Vista en eerdere Windows versies de parser zich onvoldoende raad lijkt te weten met de ondertekening van de recente EMET installers.
2.
Hypothetisch, op basis van het beschrevene in die post op Stack Overflow:
Een verschijnsel dat onder Windows 7 een ondertekening van een bestand met verlopen certificaat mogelijk juist ten onrechte wordt goedgekeurd. Dit betreft niet de recente EMET installers, maar volgens de formulering van die post op Stack Overflow was of leek dat wel het geval met een ReportViewer 2012 Runtime installer.
Zou die berichtgeving op Stack Overflow een correcte weergave van de feiten zijn, dan betekent dat dat het ten onrechte goedkeuren van een verlopen certificaat onder Windows 7 mogelijk ook in andere gevallen van toepassing zou kunnen zijn. Op de recente EMET installers is dat niet van toepassing, maar de mogelijkheid dat het op andere installers met wel verlopen certificaten wél van toepassing zou kunnen zijn, dat was wat ik opperde als mogelijkheid en wat ik nog niet kan uitsluiten.

Dit staat dus los van alles dat we hierboven hebben besproken en onderzocht, maar lijkt een ander fenomeen te zijn.
Maar naast het feit dat ik een dergelijk fenomeen met Windows 7 niet kan uitsluiten, is ook niet uit te sluiten dat de weergave in die post op Stack Overflow niet klopt, en dat er helemaal niets mis is met de certificaatbeoordeling onder Windows 7.

09-05-2014, 16:01 door Anoniem

Screenshots van digital signatures van EMET Setup.msi op een Windows 7 systeem toegevoegd aan http://social.technet.microsoft.com/Forums/security/en-US/9b01619e-4349-4cef-b52c-1e50f0d7e838/how-to-update-emet-41-silentunattended-to-emet-41-update-1?forum=emet

W. Spu

09-05-2014, 16:22 door [Account Verwijderd]

@Spiff bedankt voor het wat uitgebreider uitleggen van je reactie van 14:19. Ik heb in je reactie van 14:19 over het hoofd gezien dat het niet betreffende EMET was, maar ReportViewer 2012 Runtime. Hierdoor dacht ik dat het over de installer van EMET4.1u1 ging,

ik zal voortaan beter lezen :-)

10-05-2014, 01:14 door Eric-Jan H te D - Bijgewerkt: 10-05-2014, 01:20

Zal binnenkort eens een Vista VM optuigen. Het gaat er bij mij namelijk (nog) niet in dat de certificaatscontrole van W7 en WV zo'n verschillende uitkomst kunnen hebben. Kan dan ook met Process Monitor een vergelijking draaien als er wel verschillen zijn. Er wordt veel te moeilijk gedacht, althans als je uitgaat van de stelling dat: "computerproblemen meestal een verrassend eenvoudige oorzaak hebben". Zoals: "Heb je de stekker er wel ingedaan".

10-05-2014, 01:51 door Ilja. _V V

Een dergelijk idee heb ik eigenlijk ook:

Door Eric-Jan H te A 10-5-2014, 01:14 :Zoals: "Heb je de stekker er wel ingedaan".

Zoals ik schreef in:

Door Ilja. _V V 06-05-2014, 03:44:Best guess voor zover ik gelezen heb is dat degene die het certificaat gecreeerd heeft, te vroeg zijn/haar smartcard uit het werkstation getrokken heeft, zoiets.

En:

Door Ilja. _V V 07-05-2014, 02:30:(Mogelijk is Windows 8.x voor de Microsoft (beveiligings-)technici net zo moeilijk als voor de normale gebruikers, waarbij Microsoft zichzelf een koekie van eigen deeg heeft gegeven. Het is dan natuurlijk helemaal een blamage dat dit ook nog eens n.b. gebeurd bij een beveiligingscertificaat voor een, weer n.b., een beveiligingsprogramma, dat, nog eens n.b., volgens de downloadpagina toch echt alle Windows vanaf XP ondersteunt. Poetische gerechtigheid!)

10-05-2014, 11:44 door Spiff has left the building

Door Eric-Jan H te A:
Zal binnenkort eens een Vista VM optuigen. Het gaat er bij mij namelijk (nog) niet in dat de certificaatscontrole van W7 en WV zo'n verschillende uitkomst kunnen hebben. Kan dan ook met Process Monitor een vergelijking draaien als er wel verschillen zijn. Er wordt veel te moeilijk gedacht, althans als je uitgaat van de stelling dat: "computerproblemen meestal een verrassend eenvoudige oorzaak hebben". Zoals: "Heb je de stekker er wel ingedaan".

Mooi, Eric-Jan H te A,
en Ilja. _V V bedankt voor de ondersteuning.
Fijn dat jullie nog niet moegestreden zijn.

Ik begon al te neigen naar het opstellen van een samenvatting met een halfbakken conclusie,
maar als Eric-Jan, en Ilja, en misschien ook anderen nog verder willen onderzoeken, dan is dat geweldig, en dan hoeven we geen genoegen te nemen met slechts de aanname dat onder Windows Vista en eerdere Windows versies de parser zich onvoldoende raad lijkt te weten met de ondertekening van de recente EMET installers.

Wat betreft het onderzoeken van Vista in een VM, daarbij hoop ik wel dat een en ander zich in een VM hetzelfde gedraagt als in real life. (Maar mocht dat om een of andere reden niet zo zijn, dat zou dát overigens gelijk weer een uitgangspunt kunnen zijn voor verder denken.)

Bij voorbaat alvast bedankt voor je initiatief, en succes toegewenst.
Ik ben benieuwd of je wat interessants gaat vinden.

10-05-2014, 14:26 door Anoniem

Ik gebruik geen EMET vanwege alle config-bugs (features) die het opleverde, maar doe gewoon ook even mee:

EMET 3.0, 4.0 en 4.1 van MS erbij gehaald icm Win7-64 en WinXP-32:
Dezelfde certificaat-issues met 4.1 in XP als Ilja & Spiff, te weten dat verificatie is mislukt. Ook vind ik de volgende melding opvallend:
"Subjecttype=Eindentiteit
Beperking voor padlengte=Geen"

Alle andere combinaties functioneren normaal (behalve die onbekende 1.3.6.1.4.1.311.xxx dan).

Mijn 1e gedachte:
Is er een verschil in signing (het maken / ondertekenen van een certificaat dus) van certificaten tussen een 32 en 64 bits OS?
Ik kan me vergissen natuurlijk, maar meen me te kunnen herinneren dat het maken van certificaten met 32-bit XP moest gebeuren uit een advisory oid van een CA. Ah! Gevonden (24 april 2014): https://support.globalsign.com/customer/portal/articles/1231847-code-signing-certificate-overview---vista-windows-7-64-bit

In dat geval zou het gewoon een kleine signing-'feature' van MS kunnen zijn ;)

10-05-2014, 17:41 door Eric-Jan H te D

Globaal gezien wijkt een VM nauwelijks af van "real life". Slechts op het niveau van het aanspreken van de hardware en het bestandssysteem kun je verschillen verwachten. Wel aandacht verdient eventuele bijkomende problemen van het gebruik van de Firewall.

't Zal me benieuwen.

Volgens mij heb je een nieuw record met het aantal reacties gevestigd.

10-05-2014, 18:06 door Spiff has left the building

Door Eric-Jan H te A:
Globaal gezien wijkt een VM nauwelijks af van "real life". Slechts op het niveau van het aanspreken van de hardware en het bestandssysteem kun je verschillen verwachten.
't Zal me benieuwen.

Ha, mooi, dank je voor de uitleg.
En ik ben uiteraard ook zeer benieuwd.

Door Eric-Jan H te A:
Volgens mij heb je een nieuw record met het aantal reacties gevestigd.

Nog lang niet.
Kijk eens naar deze thread, die nog altijd reacties krijgt en nu op 178 reacties staat:
https://www.security.nl/posting/38085/Gebeld+door+Windows+service+centre

Maar onze thread hier heeft wel veel reacties in relatief korte tijd gekregen.
Misschien dat we daarmee een record hebben.
En ik zal inmiddels betreffend het aantal van míjn reacties in een thread misschien mijn éigen record gebroken hebben ;-)

Jammer genoeg is zo'n thread met zo'n massa reacties wel ontmoedigend voor nieuwe instappers, vrees ik.
Als Microsoft Nederland deze thread nog bekijkt, zoals beloofd, dan zal het doornemen van de thread een hele kluif zijn.
Ik hoop dat dat Microsoft niet zal afschrikken, en dat we op een gegeven moment een reactie van Microsoft zullen zien.

10-05-2014, 18:18 door Eric-Jan H te D

Door Spiff: Jammer genoeg is zo'n thread met zo'n massa reacties wel ontmoedigend voor nieuwe instappers, vrees ik.

Daar heb je helemaal gelijk in. Ik moest zelfs even slikken toen ik, na een tijdje van de thread te zijn weggeweest weer terugkwam. Hele listings met voor een groot gedeelte niet ter zake doende info helpen dan niet.

Ik werk meestal van de nieuwste naar de oudste. En de rest wordt vluchtig gescand.

10-05-2014, 18:48 door Erik van Straten - Bijgewerkt: 10-05-2014, 19:05

Het is vermoedelijk geen certificaat probleem maar een wijziging in Authenticode (de manier waarop bestanden digitaal ondertekend worden).

Ik heb getest met een XP SP3 setup en had dezelfde problemen als anderen hierboven hebben gemeld, o.a. "geen timestamp" in de EMET download. Op een W7 systeem heb ik het time stamping certificaat en het bovenliggende intermediate certificaat geëxporteerd naar bestanden. Na het in XP importeren van het intermediate certificaat kon ik het timestamping certificaat probleemloos bekijken met als resultaat "This certificate is OK". (Aanvulling 19:05) Voordat iemand het vraagt, het importeren van dat intermediate certificaat verhelpt het probleem niet, er is nog steeds geen time stamp zichtbaar in de EMET download onder XP.

Tenzij de authenticode check van andere certificaat validatie routines gebruikt dan de GUI, ga ik er nu vanuit dat het door Spiff aangekaarte probleem (in Vista) niet een probleem met certificaten is.

Wat opvalt is dat alle certificaten in de EMET download van SHA-256 (i.p.v. SHA-1) gebruik maken, en ook de signatures in de EMET download lijken gebruik te maken van SHA-256. Dit is in lijn met http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx.

Echter, in https://support.globalsign.com/customer/portal/articles/1491089-kernel-mode-driver-signing-%E2%80%93-windows-7-8 lees ik:

Last Updated: Apr 16, 2014 03:59PM EDT Note: Windows 7 does not currently support SHA-256 for kernel drivers. For Windows 7 support, please issue your certificate as SHA1 until a patch is released.

Nb. de kernel heeft minimale authenticode support om tijdens opstarten drivers te kunnen checken.

Het zou kunnen dat de Authenticode routines voor time stamping in Vista en XP geen (volledige) ondersteuning voor SHA256 bieden. In elk geval ga ik er nu vanuit dat er iets in Authenticode structuren (in bestanden) is gewijzigd wat leidt tot het schijnbaar ontbreken van time stamps in Vista en XP.

10-05-2014, 19:18 door [Account Verwijderd] - Bijgewerkt: 10-05-2014, 20:31

[Verwijderd]

10-05-2014, 21:08 door Spiff has left the building

Door Anoniem, 14:26 uur:
Ik gebruik geen EMET vanwege alle config-bugs (features) die het opleverde, maar doe gewoon ook even mee:

EMET 3.0, 4.0 en 4.1 van MS erbij gehaald icm Win7-64 en WinXP-32:
Dezelfde certificaat-issues met 4.1 in XP als Ilja & Spiff, te weten dat verificatie is mislukt.

Voor de duidelijkheid, ik neem aan dat je EMET 4.1 Update 1 bedoelde?
Het lijkt misschien gezeur dat ik dat vraag, maar het verschil is nogal relevant, omdat het verschil nu juist optreed tussen EMET 4.1 en eerder enerzijds en EMET 4.1 Update 1 anderzijds.

Door Anoniem, 14:26 uur:
Ook vind ik de volgende melding opvallend:
"Subjecttype=Eindentiteit
Beperking voor padlengte=Geen"

Waar kreeg je die melding?

Door Anoniem, 14:26 uur:
Mijn 1e gedachte:
Is er een verschil in signing (het maken / ondertekenen van een certificaat dus) van certificaten tussen een 32 en 64 bits OS?
Ik kan me vergissen natuurlijk, maar meen me te kunnen herinneren dat het maken van certificaten met 32-bit XP moest gebeuren uit een advisory oid van een CA. Ah! Gevonden (24 april 2014):
https://support.globalsign.com/customer/portal/articles/1231847-code-signing-certificate-overview---vista-windows-7-64-bit

In dat geval zou het gewoon een kleine signing-'feature' van MS kunnen zijn ;)

Bijzonder interessant artikel waar je naar verwijst
en een bijzonder interessante gedachte!

Het eerste deel van dat artikel:

Code Signing Certificate Overview - Vista/Windows 7 64-bit
Last Updated: Apr 24, 2014 08:13AM EDT

Note: Windows Vista & Windows 7 currently do not support SHA-256 signed kernel drivers. Please issue as SHA1 until a patch has been released.

Overview of Using a Code Signing Certificate in Vista/Windows 7 64-bit

Before Signing Your Code
- For best results, use a 32-bit Windows XP machine to perform the signing operation. Vista and Windows 7 64-bit machines do not yield a successful signing result.
- Make sure the GlobalSign root certificate is removed from the certificate store on the local machine. If the GlobalSign root is present, SignTool will fail to embed the cross certificate.
- Make sure the cross certificate is available to the SignTool application.
- Make sure the GlobalSign ObjectSign end entity certificate is available in the local certificate store.

Mijn interpretatie daarvan:
Ondertekening van een bestand op een Vista of Windows 7 64-bit machine levert een ondertekening op waarvan de controle momenteel niet correct ondersteund wordt op Vista/Windows 7 32-bit machines.
Heeft Microsoft die recente EMET installers mogelijk ondertekend op een Windows 7 64-bit machine?
Terwijl Windows Vista evenals Windows XP veelal in 32-bit versies werd gebruikt -- waardoor nu het fenomeen optreedt dat we in deze thread onderzoeken?

Om duidelijkheid te krijgen:
Mijn Vista systeem is inderdaad 32-bit.
Hoe zit het met de andere systemen waarop het fenomeen zich voordoet?
Zijn dat ook Vista en XP 32-bit systemen, of zit daar ook een 64-bit systeem tussen?
En de Windows 7 systemen waarop het fenomeen zich niet voordoet? Alle 64-bit, of zit daar ook een 32-bit systeem tussen?

En het lijkt me dat het bovenstaande aansluit op wat Erik van Straten schreef:

Door Erik van Straten, 18:48 uur:
Het is vermoedelijk geen certificaat probleem maar een wijziging in Authenticode (de manier waarop bestanden digitaal ondertekend worden).
[...]
Wat opvalt is dat alle certificaten in de EMET download van SHA-256 (i.p.v. SHA-1) gebruik maken, en ook de signatures in de EMET download lijken gebruik te maken van SHA-256. Dit is in lijn met
http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx.

Echter, in https://support.globalsign.com/customer/portal/articles/1491089-kernel-mode-driver-signing-%E2%80%93-windows-7-8 lees ik:

Last Updated: Apr 16, 2014 03:59PM EDT
Note: Windows 7 does not currently support SHA-256 for kernel drivers. For Windows 7 support, please issue your certificate as SHA1 until a patch is released.

Nb. de kernel heeft minimale authenticode support om tijdens opstarten drivers te kunnen checken.

Het zou kunnen dat de Authenticode routines voor time stamping in Vista en XP geen (volledige) ondersteuning voor SHA256 bieden. In elk geval ga ik er nu vanuit dat er iets in Authenticode structuren (in bestanden) is gewijzigd wat leidt tot het schijnbaar ontbreken van time stamps in Vista en XP.

11-05-2014, 01:42 door Erik van Straten

@Spiff: als ik me niet vergis heeft kraai geen problemen meer met W7 zowel 32 als 64 bits. Overigens vermoed ik dat het valideren met certificaten hetzelfde verloopt op 32 als op 64 bit systemen.

Genereren van certificaten is een soort black magic. De reden dat GlobalSign nu nog aanraadt om signtool.exe op XP32 te gebruiken, is dat zij stellen dat je, voor een goede werking, het GlobalSign rootcertificate uit de certificate store moet verwijderen; Vista en later zullen dit direct weer toevoegen indien verbonden met Internet. En die verbinding is noodzakelijk om te kunnen time-stampen.

Terug naar valideren, met nog wat Googlen vond ik de volgende pagina's:
https://support.globalsign.com/customer/portal/articles/1499561-sha-256-compatibility

Uit http://blogs.technet.com/b/pki/archive/2011/02/08/common-questions-about-sha2-and-windows.aspx:

Common Questions about SHA2 and Windows, Adam Stasiniewicz 8 Feb 2011 5:34 PM: [...]
Windows XP SP3 implements and supports the SHA2 hashing algorithms (SHA256, SHA384, and SHA512) in the X.509 certificate validation. The changes in the certificate validation are meant to enable the scenario of the SSL/TLS authentication. Other scenarios that involve certificate validation may not work if you use certificates that are secured by using the SHA2 algorithms if the protocols and the applications do not support the SHA2 hashing algorithms. For example, the S/MIME signed e-mail verification and the Authenticode signature verification do not support the SHA2 hashing algorithms on a computer that is running Windows XP SP3.
[...]

XP SP3 ondersteunt SHA2 dus in certificaten zelf, maar niet (geheel) bij Authenticode.

Ik vermoed dat hetzelfde geldt voor Vista. Aangezien Microsoft Vista nog ondersteunt zouden ze dit moeten fixen.

11-05-2014, 02:40 door Spiff has left the building

@ Erik van Straten,

Dankjewel voor je uitleg over genereren en valideren van certificaten.
Ik vreesde al een beetje dat ik za.10-5, 21:08 uur, met mijn interpretatie teveel buiten mijn deskundigheid redeneerde ;-)

En dankjewel voor het verder zoeken en redeneren betreffend het valideren van certificaten onder XP en Vista.
Zou dat wat je aangaf, XP SP3 die SHA2 ondersteunt in certificaten maar niet (geheel) bij Authenticode, als dat ook voor Vista zou gelden, een dekkende verklaring bieden voor het fenomeen waar we het in deze thread over hebben?

Ik wil nog niet vooruitlopen op de bevindingen en de inzichten van de anderen,
maar wanneer we op een gegeven moment gezamenlijk menen een duidelijk beeld te hebben,
wat zou dan de beste manier zijn om onze bevindingen aan Microsoft voor te leggen?
Bij bellen van Microsoft Nederland wordt wellicht opnieuw geadviseerd te posten binnen Microsoft Community of TechNet forums, maar of het van daaruit zal terechtkomen bij iemand die doorziet wat het probleem is en daarop actie inzet, dat is maar de vraag. Eerder met een melding betreffend een MSXML 4.0 update issue, had ik bepaald geen goede ervaring met het via die weg aankaarten van een probleem.
Bij enig aandringen wordt bij bellen van Microsoft Nederland misschien opnieuw beloofd de relevante post in deze thread te bekijken, maar of Microsoft dat ook waar kan maken, daarop is geen garantie te geven.
Kent iemand van jullie misschien een betere en directere methode om op een gegeven moment onze eind-bevindingen aan Microsoft over te brengen?

11-05-2014, 09:15 door Fwiffo

Door Erik van Straten: Uit http://blogs.technet.com/b/pki/archive/2011/02/08/common-questions-about-sha2-and-windows.aspx:

Common Questions about SHA2 and Windows, Adam Stasiniewicz 8 Feb 2011 5:34 PM: [...]
Windows XP SP3 implements and supports the SHA2 hashing algorithms (SHA256, SHA384, and SHA512) in the X.509 certificate validation. The changes in the certificate validation are meant to enable the scenario of the SSL/TLS authentication. Other scenarios that involve certificate validation may not work if you use certificates that are secured by using the SHA2 algorithms if the protocols and the applications do not support the SHA2 hashing algorithms. For example, the S/MIME signed e-mail verification and the Authenticode signature verification do not support the SHA2 hashing algorithms on a computer that is running Windows XP SP3.
[...]

XP SP3 ondersteunt SHA2 dus in certificaten zelf, maar niet (geheel) bij Authenticode.

Ik vermoed dat hetzelfde geldt voor Vista. Aangezien Microsoft Vista nog ondersteunt zouden ze dit moeten fixen.

Met het risico neergezet te worden als een zuur mannetje... Je quote komt uit 2011! Dus MS heeft ondertussen wel genoeg tijd gehad om dit aan te zien komen en om dit te fixen voor Vista. Bovendien zit Vista nu in Extended Support ook nog, en dit is niet echt een 'security' issue dat ze moeten repareren. Om eerlijk te zijn denk ik dat de kans dat Microsoft dit fixt ongeveer even groot is als dat we Internet Explorer 11 krijgen op Vista :-/ We mogen al blij zijn met Extended Support want dat was tot op het laatste moment ook niet zeker. Maar ja, zolang het werkt hoor je mij niet klagen. Dan maar geen EMET. Misschien dat een andere fabrikant in het gat springt (en nog met SHA-1 ondertekent).

11-05-2014, 11:04 door Anoniem

Door Spiff: Voor de duidelijkheid, ik neem aan dat je EMET 4.1 Update 1 bedoelde?
Het lijkt misschien gezeur dat ik dat vraag, maar het verschil is nogal relevant, omdat het verschil nu juist optreed tussen EMET 4.1 en eerder enerzijds en EMET 4.1 Update 1 anderzijds.

Oei, nee absoluut geen gezeur maar een onvolledigheid mijnerzijds; het gaat inderdaad om EMET 4.1 Update.

Door Spiff:

Door Mij, 14:26 uur:
Ook vind ik de volgende melding opvallend:
"Subjecttype=Eindentiteit
Beperking voor padlengte=Geen"

Waar kreeg je die melding?

Certificaat -> Details -> Alle (velden / details) -> Essentiële Beperkingen

Door Spiff:

Door Mij, 14:26 uur: Ah! Gevonden (24 april 2014):
https://support.globalsign.com/customer/portal/articles/1231847-code-signing-certificate-overview---vista-windows-7-64-bit

In dat geval zou het gewoon een kleine signing-'feature' van MS kunnen zijn ;)

Bijzonder interessant artikel waar je naar verwijst
en een bijzonder interessante gedachte!

Mijn Vista systeem is inderdaad 32-bit.

En het lijkt me dat het bovenstaande aansluit op wat Erik van Straten schreef:

Door Erik van Straten, 18:48 uur:
Het is vermoedelijk geen certificaat probleem maar een wijziging in Authenticode (de manier waarop bestanden digitaal ondertekend worden).

Ik weet bij lange na niet genoeg van de materie om daar over te kunnen oordelen.

Door Erik van Straten: XP SP3 ondersteunt SHA2 dus in certificaten zelf, maar niet (geheel) bij Authenticode.

Ik vermoed dat hetzelfde geldt voor Vista. Aangezien Microsoft Vista nog ondersteunt zouden ze dit moeten fixen.

Sluit het één het ander ook daadwerkelijk uit? (Alle respect, ik snap er maar de helft van.) + is dat nog van toepassing anno 2014? (Dat zou wel slecht zijn van MS lijkt me dan.)

Door Spiff: Ik wil nog niet vooruitlopen op de bevindingen en de inzichten van de anderen,
maar wanneer we op een gegeven moment gezamenlijk menen een duidelijk beeld te hebben,
wat zou dan de beste manier zijn om onze bevindingen aan Microsoft voor te leggen?

Zowel voor het meedenken over als het eventueel wereldkundig maken van bovenstaande materie zou ik een onafhankelijke expert op dit gebied proberen te benaderen. Ik kan niemand beter dan Didier Stevens bedenken: http://blog.didierstevens.com/ e/o e-mail: (string-append “didier” (string #\.) “stevens” (string #\@) “gmail” (string #\.) “com”) Ik denk niet dat hij prijs op spam stelt, vandaar ;)

Alle respect voor Erik van Straten natuurlijk, maar een extra paar ogen zijn nooit weg.

Ben benieuwd hoe dit topic zich verder gaat ontwikkelen!

11-05-2014, 11:09 door [Account Verwijderd] - Bijgewerkt: 12-05-2014, 12:50

Door Erik van Straten 11-05-2013 01:42: @Spiff: als ik me niet vergis heeft kraai geen problemen meer met W7 zowel 32 als 64 bits.

Klop ik heb inderdaad geen problemen meer met W7 zowel 32 als 64 bits.

het systeem waar een eerst wel problemen op had is een W7 64 bit systeem. Deze problemen waren echter verholpen naar dat ik naar aanleiding van de reactie van Erik van Straten op 08-05-2014 om 09:11, EMET4.1u1 opnieuw had geïnstalleerd op het W7 64 bit systeem met internetverbinding.

Door Anoniem 10-05-2014 14:26: Ik gebruik geen EMET vanwege alle config-bugs (features) die het opleverde, maar doe gewoon ook even mee:

EMET 3.0, 4.0 en 4.1 van MS erbij gehaald icm Win7-64 en WinXP-32:
Dezelfde certificaat-issues met 4.1 in XP als Ilja & Spiff, te weten dat verificatie is mislukt. Ook vind ik de volgende melding opvallend:
"Subjecttype=Eindentiteit
Beperking voor padlengte=Geen"

Goed gezien. Dit word inderdaad aangegeven bij details en dan essentiële beperkingen. (Staat overigens ook een geel driehoekje met een uitroepteken voor). Ik heb van een paar anderen installatie bestanden van Microsoft de certificaat details bekeken en die geven deze melding niet.

bijgewerkt
De reactie van Anoniem 11:04 was om 11:09 nog niet zichtbaar.

11-05-2014, 11:33 door Spiff has left the building - Bijgewerkt: 11-05-2014, 11:42

Door Anoniem, za.10-5, 14:26 uur:
Ook vind ik de volgende melding opvallend:
"Subjecttype=Eindentiteit
Beperking voor padlengte=Geen"

Door Anoniem, zo.11-5, 11:04 uur:
Certificaat -> Details -> Alle (velden / details) -> Essentiële Beperkingen

Door kraai, zo.11-5, 11:09 uur:
Goed gezien. Dit word inderdaad aangegeven bij details en dan essentiële beperkingen. (Staat overigens ook een geel driehoekje met een uitroepteken voor). Ik heb een paar anderen installatie bestanden beken van Microsoft en die geven deze melding niet bij certificaat details.

Ah, daar, dankjewel.

Details van digitale handtekening, Certificaat, tab Details,
Essentiële beperkingen:
Subjecttype=Eindentiteit
Beperking voor padlengte=Geen

Dankjewel, ik had er overheen gekeken, maar dat staat er bij mij uiteraard ook, bij de EMET 4.1u1 installer.
Het gele driehoekje met uitroepteken had ik wellicht waargenomen zonder me er werkelijk van bewust te worden, doordat de weergave van het symbooltje relatief klein en onopvallend is.

Wat betekent die vermelding? Is dat iets relevants?

[Bijgewerkt met aanvulling van het citaat van Anoniem van 11:04 uur.]

11-05-2014, 12:34 door Spiff has left the building

Door Spiff, 02:40 uur:
Ik wil nog niet vooruitlopen op de bevindingen en de inzichten van de anderen,
maar wanneer we op een gegeven moment gezamenlijk menen een duidelijk beeld te hebben,
wat zou dan de beste manier zijn om onze bevindingen aan Microsoft voor te leggen?
[...]
Kent iemand van jullie misschien een betere en directere methode om op een gegeven moment onze eind-bevindingen aan Microsoft over te brengen?

Door Anoniem, 11:04 uur:
Zowel voor het meedenken over als het eventueel wereldkundig maken van bovenstaande materie zou ik een onafhankelijke expert op dit gebied proberen te benaderen. Ik kan niemand beter dan Didier Stevens bedenken:
http://blog.didierstevens.com/
[...]
Alle respect voor Erik van Straten natuurlijk, maar een extra paar ogen zijn nooit weg.

Dank je voor de tip, Anoniem.
Wat denken de anderen ervan, zouden we Didier Stevens benaderen om mee te denken?
Ik ben nog wat terughoudend. Zou hij het interessant vinden, of niet relevant genoeg? (Dat weten we uiteraard pas wanneer we het vragen ;-)

11-05-2014, 12:35 door Anoniem

Door Spiff:

Door Anoniem, za.10-5, 14:26 uur:
Ook vind ik de volgende melding opvallend:
"Subjecttype=Eindentiteit
Beperking voor padlengte=Geen"

Door Anoniem, zo.11-5, 11:04 uur:
Certificaat -> Details -> Alle (velden / details) -> Essentiële Beperkingen

Wat betekent die vermelding? Is dat iets relevants?

Lijkt me wel, nooit eerder gezien en alleen kunnen dupliceren bij dat installatiebestand waar Erik je van vroeg om dat ook eens te bekijken (PowerPivot_for_Excel_x86.msi). Tevens is het de enige waarschuwing die wordt gegeven.

De grote vraag blijft mijns inziens dan ook of het probleem het gevolg is van het opmaken van het certificaat zelf, of dat bepaalde 32-bit Windows versies niet in staat zijn om alle (MS? SHA-256? MS+SHA-256?) certificaten te valideren. Dat laatste zou, indien het zo is, toch wijdverbreid bekend moeten zijn (bij MS) daar veel grote organisaties (nog steeds) XP draaien en EMET specifiek wordt aangeraden voor deze doelgroep. Vreemd...

Ik zou een hulplijn of 2 inschakelen ;)

11-05-2014, 12:45 door Erik van Straten - Bijgewerkt: 11-05-2014, 13:16

Het gele driehoekje met uitroepteken bij "Basic Constraints" duidt op een critical extension (in het Nederlands kennelijk een "essentiële beperking"). "Critical" wil zeggen dat de parser de informatie moet kunnen parsen en niet van de inhoud af mag wijken. Aanvulling 13:16: bij elk fatsoenlijk certificaat hoort dit gele driehoekje met uitroepteken bij "Basic Constraints" aanwezig te zijn; je moet het niet interpreteren als een waarschuwing voor een probleem zoals in device manager/aparaatbeheer!

Met deze extensie, "Basic Constraints" (ik weet niet hoe Microsoft dat het in NL vertaald heeft, wellicht basis beperkingen), wordt aangegeven of het ofwel om een "CA certificaat" (root- of intermediate) ofwel om een eind-certificaat gaat (de daadwerkelijk gebruikte, d.w.z. de onderste in de keten). Alleen bij CA certificaten kan een beperking op padlengte worden opgenomen (om aan te geven hoe diep genest intermediate a.k.a. sub-CA certificaten mogen worden uitgegeven). "End Entity" zorgt ervoor dat een eind certificaat nooit mag worden gebruikt om sub-certificaten uit te geven.

Eerder in deze thread schreef ik dat het intermediate certificaat voor timestamping (Microsoft Time-Stamp PCA 2010) onverwacht ook een geel uitroeptekentje heeft bij "Certificate Policies" (maar dat bleek toch niet de oorzaak van de problemen te zijn). Dat is onlogisch en kennelijk onbedoeld, want het, meer recente, intermediate code signing certificaat (Microsoft Root Certificate Authority 2011) bevat ook een "Certificate Policies" maar deze is niet als critical aangemerkt.

Nb. voor de mensen die verder willen spitten in Windows certificaat dialoogboxen: de onderste 2 of 3 regels in de tab "Details" (Engels: Thumbprint algorithm, Thumbprint en soms aanwezig: Extended Error Information) komen niet uit het certificaat zelf; die Thumbprint (hash) rekent Windows zelf uit over de binaire representatie van het certificaat.

Om Vista en XP gebruikers ervan te overtuigen dat het geen certificaatprobleem is, plaats ik hieronder het in de laatste EMET download gebruikte timestamping certificaat en het bijbehorende intermediate certificaat (die laatste met 2 uitroeptekentjes). Je kunt de tekst, inclusief de regels "-----BEGIN CERTIFICATE-----" en "-----END CERTIFICATE-----" plakken in kladblok en opslaan als "naam.cer" (let op dat kladblok er niet "naam.cer.txt" van maakt, zo ja die .txt eraf halen). Als je op een .cer file dubbelklikt opent de bekende certificaat dialoogbox.

Nogmaals, XPSP3 (32) en W7 (64) hebben geen enkel probleem met deze certificaten, naar ik aanneem Vista ook niet.

Gebruikte timestamping cert (Microsoft Time-Stamp Service.cer):

Intermediate (Microsoft Time-Stamp PCA 2010.cer):

Nb. lege regels achter "-----END CERTIFICATE-----" kunnen geen kwaad.

11-05-2014, 12:48 door [Account Verwijderd] - Bijgewerkt: 11-05-2014, 12:50

Door Spiff 11-05-2014 11:33:
Details van digitale handtekening, Certificaat, tab Details,
Essentiële beperkingen:
Subjecttype=Eindentiteit
Beperking voor padlengte=Geen

Door Spiff 11-05-2014 11:33::Wat betekent die vermelding? Is dat iets relevants?

Misschien geeft het volgende artikel ook iets meer duidelijkheid en een antwoord op de vraag van Spiff:

http://support.microsoft.com/kb/281245/nl
(vooral punt 5)

11-05-2014, 12:52 door Anoniem

Door Spiff: Dank je voor de tip, Anoniem.
Wat denken de anderen ervan, zouden we Didier Stevens benaderen om mee te denken?
Ik ben nog wat terughoudend. Zou hij het interessant vinden, of niet relevant genoeg? (Dat weten we uiteraard pas wanneer we het vragen ;-)

Groot gelijk, ik had beter een andere link kunnen geven, die beantwoord eigenlijk direct al je vragen:
http://blog.didierstevens.com/programs/authenticode-tools/ Hij heeft zeer effectieve open-source software geschreven om onafhankelijk certificaten e.d. te kunnen controleren en was vroegâh regelmatig actief op dit forum. Ik heb analyzePEsig (zijn software) gisteren al gebruikt om eens te kijken maar kom niets verder dan wat er hierboven al allemaal vermeld is, behalve misschien dat de timestamping wel degelijk in het certificaat aanwezig is, maar niet wordt weergegeven in WinXP / -Vista 32-bits.

Daarbij, ik heb zo het vermoeden dat hij het antwoord al weet zonder het grondig te hoeven onderzoeken, vandaar.

Succes in ieder geval, ik ben bang dat ik verder niet van veel toegevoegde waarde kan zijn maar ga het zeker bijhouden.

11-05-2014, 13:02 door Erik van Straten

M.b.t. Didier Stevens: ook ik heb bij het onderzoek zijn tool "AnalyzePESig" gebruikt. Dat werkt niet op MSI files, dus heb ik een exe file daaruit gepeuterd. Ik kreeg AnalyzePESig vervolgens niet zover om informatie over de timestamping check te geven. Didier is echter wel iemand die goed weet hoe authenticode structuren in elkaar zitten.

Mocht je Didier benaderen, geef dan aan dat je onder Vista tegen een authenticode probleem aanloopt, vermoedelijk doordat SHA256 gebruikt wordt voor timestamp verificatie. Maar of hij zin heeft om hiervoor een Vista systeem op te tuigen zul je moeten afwachten.

11-05-2014, 13:12 door Anoniem

Door Erik van Straten: M.b.t. Didier Stevens: ook ik heb bij het onderzoek zijn tool "AnalyzePESig" gebruikt. Dat werkt niet op MSI files, dus heb ik een exe file daaruit gepeuterd. Ik kreeg AnalyzePESig vervolgens niet zover om informatie over de timestamping check te geven. Didier is echter wel iemand die goed weet hoe authenticode structuren in elkaar zitten.

Mocht je Didier benaderen, geef dan aan dat je onder Vista tegen een authenticode probleem aanloopt, vermoedelijk doordat SHA256 gebruikt wordt voor timestamp verificatie. Maar of hij zin heeft om hiervoor een Vista systeem op te tuigen zul je moeten afwachten.

True, 0.2 werkt nog wel op .msi files, 0.3 niet meer. Waarom weet ik ook niet, heb 't gevraagd op z'n blog daarstraks. Ik liep met 0.3 ook tegen een non-dos-signature waarschuwing aan, maar het leek me verwarrend om analyzePEsig in dit toch al zo uitgebreide topic te bespreken, kortom: 0.2 werkt wel gewoon ;)

Sorry dat het wellicht zo over kwam dat ik je posts in twijfel trek, dat is niet het geval, ik snap er gewoon maar de helft van!
En de door jou geposte certificaten werken inderdaad prima in XP-SP3 (32).

11-05-2014, 14:45 door Spiff has left the building - Bijgewerkt: 11-05-2014, 15:00

Door Erik van Straten:
Mocht je Didier benaderen, geef dan aan dat je onder Vista tegen een authenticode probleem aanloopt, vermoedelijk doordat SHA256 gebruikt wordt voor timestamp verificatie.

Inmiddels heb ik Didier een e-mail gestuurd om zijn aandacht te vragen.
Ik ben zeer benieuwd of hij het issue interessant en belangrijk genoeg zal vinden om er tijd en energie aan te willen besteden.

12-05-2014, 11:15 door Anoniem

UGH... ATTENTIE! UGH... Clucje zojuist hebben gezien ROOKSIGNALEN uit KB2868626!!!

Nader onderzoek op een oude XPSP3-installatie heeft uitgewezen dat de digitale handtekening van
EMET4.1u1 HELEMAAL niet wordt weergegeven wanneer KB2868626 niet is geïnstalleerd!

(@spiff: misschien kun/wil jij het in VISTA ook eens uitproberen om update KB2868626 te verwijderen?
Bij mij lukte dat in XP simpel door uitvoeren van het commando C:\WINDOWS\$NtUninstallKB2868626$\spuninst\spuninst.exe.
Kijk daarna eens of de "digitale handtekening"-tab van het EMET4.1u1-bestand volledig in het niets is verdwenen?...
Maar oudere digitale handtekeningen, bijv. van EMET4.0, zouden ok moeten blijven)

Officieel is KB2868626 een security update van november 2013 die een vulnerabilty (D.o.S.) zou moeten tegengaan
met betrekking tot certificaten. Zie: https://technet.microsoft.com/library/security/ms13-095
Het lijkt erop dat deze update het tegelijk mogelijk maakt voor XP (en voor Vista?) om voortaan sha2-algoritmes
aan te kunnen in certificaten. (en zulke certificaten vinden we nu ook in digitale handtekeningen van bestanden...)

Er staat in de link over KB2868626 tamelijk onopvallend dat de update naast sha1 ook sha2 ondersteunt.
Maar als je bij certificaten die gebruik maken van sha2 algoritmes
zónder KB2868626-update zelfs de "digitale handtekeningen"-tab al niet eens meer ziet,
dan is het aannemelijk dat XP voorheen kennelijk géén certificaten met sha2 algoritmes aankon
in digitale handtekeningen (authenticode)!.
Zoals Erik van Straten schreef in zijn bericht van 11 mei 01:42:

Authenticode signature verification do not support the SHA2 hashing algorithms on a computer that is
running Windows XP SP3. XP SP3 ondersteunt SHA2 dus in certificaten zelf, maar niet (geheel) bij Authenticode.

"sha256" is zo'n "sha2"-algoritme. En we zagen dat alle probleemgevallen het sha256-algoritme gebruiken!
De problematiek wijst daarom dus in de richting van een onvolkomenheid in KB2868626 voor XP (en voor VISTA?),
waardoor (een deel van) de digitale handtekening in XP en (Vista) waarin sha256 voorkomt niet goed wordt geïnterpreteerd.
Zo te zien gaat het bij de controlehandtekening (countersignature) fout.
Immers bij win7 is deze controlehandtekening gewoon zichtbaar. Maar bij XP en Vista niet...

Er is dus ergens iets aan de hand wat veroorzaakt dat de controlehandtekening ("countersignature") in XP en Vista
niet goed wordt gelezen. Dáár zit volgens mij de oorzaak van het hele probleem.
Door dit gemis wordt vervolgens de hele handtekening getorpedeerd, omdat er immers een stukje
essentiële informatie ontbreekt dat bij moet dragen om de integriteit van het bestand te kunnen garanderen!
De vraag is echter: waarom leest/interpreteert het systeem die controlegegevens niet goed, en de rest wel???...

Je kunt de details van die controlehandtekening nog eens onder de loep nemen (in win7 onder "countersignatures"
even het enige item aanklikken. Vervolgens de knop "details" en "certificaat weergeven" etc.
Heel mischien ontdekt iemand nog ergens een opvallende onregelmatigheid waar de nieuwe met KB2868626 meegekomen programmacode voor "authenticode" in XP/Vista eventueel (terecht of onterecht) over zou kunnen struikelen.

Als ik overigens de geposte certificaten van Erik van Straten bekijk

Gisteren, 12:45 door Erik van Straten - Bijgewerkt: Gisteren, 13:16
met het in de laatste EMET download gebruikte timestamping certificaat en bijbehorend intermediate
certificaat

dan valt mij op dat het hier opeens dus weer certificaten met sha1 (en niet sha2) betreft...
(zou er iets stompzinnigs in de nieuwe authenticode zitten (die klaarblijkelijk met KB2868626 is meegekomen) die bijv. vereist dat alle certificaten sha2 moeten zijn als er elders in de digitale handtekening een certificaat met sha2 voorkomt?... Je weet maar nooit. Het is maar een suggestie, en ik ben helaas niet in staat om dit na te gaan)

Maar de focus is wat mij betreft nu dus gericht op KB2868626.

Hope this helps!
M.v.g., cluc-cluc ( 'k kon het niet laten ;)

12-05-2014, 12:25 door Spiff has left the building - Bijgewerkt: 12-05-2014, 12:26

@ Anoniem, cluc-cluc, 11:15 uur,

Dankjewel voor je analyse betreffend KB2868626.
Ik hoop dat de anderen inzicht hebben in de relevantie ervan en kunnen doorgaan op wat je aangeeft.
Ik wacht dat af voordat ik KB2868626 eventueel tijdelijk ga verwijderen.
Ikzelf kan zelf nog niet beoordelen hoe het tijdelijk verwijderen van KB2868626 ons aanvullend inzicht gaat geven.
Waarom ik terughoudend ben met het tijdelijk verwijderen van een eerdere beveiligingsupdate, dat is omdat opvolgende updates soms wat aanpassen dat door een eerdere update is toegepast en ik niet voldoende inzicht heb om te kunnen uitsluiten dat dat na KB2868626 misschien ook al is gebeurd en ik door het tijdelijk verwijderen en vervolgens opnieuw toepassen ervan teveel overhoop haal en ik mogelijk ook latere updates zou moeten gaan verwijderen en herinstalleren.

Ik gaf aan dat ik hoop dat de anderen inzicht hebben in de relevantie van je analyse betreffend KB2868626 en kunnen doorgaan op wat je aangeeft.
Mogelijk dat ook Didier Stevens de informatie die je aanreikte betreffend KB2868626 kan meenemen in zijn analyse. Didier vroeg me gisteren al even wat essentiële informatie (hebben anderen dan alleen ik het probleem al gereproduceerd, zou ook hij het probleem kunnen reproduceren), dus ik vermoed dat Didier de tijd wil nemen om dat authenticode probleem onder Vista te onderzoeken.

12-05-2014, 12:37 door Erik van Straten

Door Anoniem: Als ik overigens de geposte certificaten van Erik van Straten bekijk
dan valt mij op dat het hier opeens dus weer certificaten met sha1 (en niet sha2) betreft...

Geen kritiek (het is complexe materie en getoonde informatie is verwarrend), maar jouw conclusie is onjuist.

Beide certificaten gebruiken "sha256RSA" als "Signature algorithm" en "sha256" als "Signature hash algorithm".

Nb. laat je niet afleiden door de "sha1" thumbprint (vingerafdruk) onderin de dialoogbox. Zoals ik eerder schreef in deze thread: die komt niet voor in het certificaat zelf, maar wordt door Windows uitgerekend over de binaire (DER) representatie van het certificaat.

12-05-2014, 13:13 door [Account Verwijderd] - Bijgewerkt: 21-05-2014, 19:46

@ Anoniem, cluc-cluc, 11:15 uur, interessant wat er in je reactie staat over KB2868626.

Ik heb even gekeken en KB2868626 is ook een beveiliging update voor Windows 7 en windows 8.

Door Spiff 12-05-2014 12:25:
Ik hoop dat de anderen inzicht hebben in de relevantie ervan en kunnen doorgaan op wat je aangeeft.
Ik wacht dat af voordat ik KB2868626 eventueel tijdelijk ga verwijderen.
Ikzelf kan zelf nog niet beoordelen hoe het tijdelijk verwijderen van KB2868626 ons aanvullend inzicht gaat geven.
Waarom ik terughoudend ben met het tijdelijk verwijderen van een eerdere beveiligingsupdate, dat is omdat opvolgende updates soms wat aanpassen dat door een eerdere update is toegepast en ik niet voldoende inzicht heb om te kunnen uitsluiten dat dat na KB2868626 misschien ook al is gebeurd en ik door het tijdelijk verwijderen en vervolgens opnieuw toepassen ervan teveel overhoop haal en ik mogelijk ook latere updates zou moeten gaan verwijderen en herinstalleren.

Op de volgende pagina: http://support.microsoft.com/kb/2868626 staat dat KB2868626 een vervangende update is voor KB2661254. Of er vervolgens een update is die weer aanpassingen maakt of KB2868626 vervang weet ik niet (Ik zal nog even zoeken)

Verder is de volgende pagina met informatie over KB2661254 is misschien ook interessant om te lezen.
http://support.microsoft.com/kb/2868626

http://support.microsoft.com/kb/2661254/nl

update 21-05-2014 19:46
correctie spellingsfout.

12-05-2014, 13:20 door Spiff has left the building

Door kraai:
http://support.microsoft.com/kb/2661254
Verder is de volgende pagina met informatie over KB2661254 is misschien ook interessant om te lezen.
http://support.microsoft.com/kb/2868626

Dank je, kraai.
Ik had die pagina's al bekeken naar aanleiding van de post van cluc-cluc van 11:15 uur.

12-05-2014, 13:55 door Anoniem

Door Erik van Straten:

Door Anoniem: Als ik overigens de geposte certificaten van Erik van Straten bekijk
dan valt mij op dat het hier opeens dus weer certificaten met sha1 (en niet sha2) betreft...

Geen kritiek (het is complexe materie en getoonde informatie is verwarrend), maar jouw conclusie is onjuist.

Beide certificaten gebruiken "sha256RSA" als "Signature algorithm" en "sha256" als "Signature hash algorithm".

Nb. laat je niet afleiden door de "sha1" thumbprint (vingerafdruk) onderin de dialoogbox. Zoals ik eerder schreef in deze thread: die komt niet voor in het certificaat zelf, maar wordt door Windows uitgerekend over de binaire (DER) representatie van het certificaat.

Je hebt waarschijnlijk gelijk, maar in de certificaatdetails zoals ik die hier uitlees na het regenereren van het certificaat met jouw informatie van

Gisteren, 12:45 door Erik van Straten - Bijgewerkt: Gisteren, 13:16

stond dit niet direct in het geregenereerde certificaat vermeld (zoals ik in andere certificaten wél heb zien staan!).
Vandaar dat ik op dit punt even op het verkeerde been was gezet door wat ik dus wél zag staan.
En dat was inderdaad die sha1-thumbprint.

Overigens was de laatste alinea van mijn bericht ook alleen als suggestie bedoeld over hoe stompzinnig iets kan mislopen als bijv. de nieuwe authenticode uit KB2868626 voor XP/Vista een bug zou bevatten. In dat licht dient men het te lezen.
Niet als een "feit" maar als een suggestie. Maar het is prima dat je het terugkoppelt, zodat het kan worden opgehelderd. :) Maar kun je het in de kern met de rest van mijn verhaal eens zijn Erik?

@spiff: eveneens dank voor je reactie. Het aanvullende inzicht is dat je door reproductie van het verschijnsel de theorie
van mijn verhaal onderstreept, en dat het geen "toevalstreffer" betreft doordat er toevallig nog iets anders op mijn geteste XP-systeem aan de hand was. Dit is weliswaar zeer onwaarschijnlijk, maar we moeten het zo zeker mogelijk weten.
En ook of Vista net zo reageert als XPSP3.

De effecten van verwijderen van KB2868626 zijn niet geheel te overzien, al denk ik dat het erg mee zal vallen. De update is van November 2013, en dat is nog maar een paar maanden geleden. Dus zoveel haal je waarschijnlijk niet overhoop.
Je kunt volgens mij KB2868626 hierna gewoon weer herinstalleren. Maar als je het niet aandurft, doe het dan maar niet.
Als het voor jou een uiterst belangrijk systeem is, zou ik het daarop wellicht ook niet zo snel doen.
En eerlijk gezegd was de XP-installatie waarop ik het heb uitgeprobeerd niet tot en met de laatste update geïnstalleerd toen ik KB2868626 toevoegde en weer verwijderde, dus ik kan in dit geval niet uit ervaring volledig 100% iets garanderen over veronderstelde mogelijke neveneffecten. Hopelijk weet Didier of een andere Vista-gebruiker er dan wel raad mee.
Mvg, cluc-cluc

12-05-2014, 15:38 door Spiff has left the building - Bijgewerkt: 12-05-2014, 17:40

Door Anoniem, cluc-cluc, 13:55 uur:
@spiff: [...]
De effecten van verwijderen van KB2868626 zijn niet geheel te overzien, al denk ik dat het erg mee zal vallen. De update is van November 2013, en dat is nog maar een paar maanden geleden. Dus zoveel haal je waarschijnlijk niet overhoop. Je kunt volgens mij KB2868626 hierna gewoon weer herinstalleren. Maar als je het niet aandurft, doe het dan maar niet. Als het voor jou een uiterst belangrijk systeem is, zou ik het daarop wellicht ook niet zo snel doen.

Het is mijn basis-systeem, daarom zou ik voorafgaand aan een dergelijk onderzoek eerst een image maken en dat na de test weer terugzetten. Dat kost niet zo veel tijd, maar omdat ik de relevantie van het betreffende onderzoek volstrekt niet kan beoordelen, voer ik dat onderzoek pas uit wanneer ook anderen aangeven dat het nuttig en wenselijk is dat ik dat doe.
Dit is dus tevens een vraag aan de anderen:
Is het wel of niet nuttig en wenselijk dat ik tijdelijk KB2868626 verwijder, om de bevindingen van Anoniem cluc-cluc zoals beschreven om 11:15 uur te bevestigen op Vista?

12-05-2014, 17:46 door [Account Verwijderd] - Bijgewerkt: 12-05-2014, 17:46

[Verwijderd]

12-05-2014, 18:40 door Fwiffo

@Spiff.
Ik zie het somber in voor Windows XP en Vista (vooral voor XP vanwege EOL), maar ik heb nog wel een andere vraag voor je:
In deze draad kwamen de signatures op EMET 4.1 Update 1 ter sprake met HitmanPro. Wat is het effect van het niet ondertekend zijn van EMET onder Windows Vista en Windows XP? Ik verwacht een UAC melding (bij het opstarten van Vista), maar misschien worden onderdelen van EMET niet geladen. Dat zou betekenen dat EMET onder deze twee besturingssytemen, mogelijk gevaarlijk is (je verwacht/anticipeert een beveiliging die er niet is).
Is het als dit zo is misschien slim om EMET 4.1 te gebruiken, als die nog te downloaden is ergens?

Ik weet dat OS X Lion het niet leuk vindt als programma's niet ondertekend zijn en je ze uit wilt voeren. Je moet dan met de rechtermuis aan de gang om het programma toch te draaien. Lion kan je zo instellen dat er geen melding komt, maar het doel van EMET is natuurlijk niet dat je beveiligingen uit gaat schakelen om het te kunnen draaien (zoals UAC).

12-05-2014, 19:37 door Spiff has left the building - Bijgewerkt: 12-05-2014, 19:42

Door Fwiffo:
Wat is het effect van het niet ondertekend zijn van EMET onder Windows Vista en Windows XP?
Ik verwacht een UAC melding (bij het opstarten van Vista), maar misschien worden onderdelen van EMET niet geladen. Dat zou betekenen dat EMET onder deze twee besturingssystemen, mogelijk gevaarlijk is (je verwacht/anticipeert een beveiliging die er niet is).

Bij het openen van het EMET 4.1u1 installatiebestand krijgt de gebruiker direct deze beveiligingswaarschuwing:

Kan de uitgever niet bevestigen. Weet u zeker dat u deze software wilt installeren?
Dit bestand bevat geen geldige digitale handtekening die de uitgever ervan bevestigt.

Wellicht zal in het installatieproces UAC ongeveer hetzelfde opmerken als in die waarschuwing:

Onbekende uitgever, geen geldige digitale handtekening.

Bij het kiezen voor doorgaan met de installatie wordt EMET 4.1u1 geïnstalleerd.

Bij het openen van de geïnstalleerde EMET 4.1 Update 1 via de EMET snelkoppeling in Menu Start, of via EMET Notifier in het Windows Systeemvak geeft UAC deze melding:

Een onbekend programma wil toegang tot uw computer verkrijgen
Voer het programma niet uit tenzij u weet waar het vandaan komt of als u het eerder hebt gebruikt.
EMET_GUI.exe
Onbekende uitgever
"C:\program Files\EMET 4.1\EMET_GUI.exe"

Maar UAC geeft geen waarschuwing bij inloggen na het opstarten van Windows.
Dat zou zeer alarmerend zijn, zoiets zou ik uiteraard al vermeld hebben als dat het geval was.
Het ziet er naar uit dat EMET gewoon opstart met Windows en gewoon actief is.
Het proces EMET_Agent.exe is actief.
Horen er andere EMET processen, services of andere componenten actief te zijn?

Door Fwiffo:
Is het als dit zo is misschien slim om EMET 4.1 te gebruiken, als die nog te downloaden is ergens?

Mocht iemand aangeven dat ik buiten het proces EMET_Agent.exe bepaalde EMET processen, services of andere componenten mis, dan zou het downgraden naar EMET 4.1 waarschijnlijk beslist verstandig zijn. En dan wordt dit hele probleem in plaats van irritant ineens bijzonder vervelend. Maar vooralsnog wijst voor mij nog niets erop dat EMET niet volledig zou laden.

EMET 4.1 wordt door Microsoft niet meer aangeboden, maar ik heb de installer ervan nog wel. Ik bewaar veelal zekerheidshalve enige tijd tenminste één voorgaande installer.

12-05-2014, 22:51 door Erik van Straten

Door Anoniem:Overigens was de laatste alinea van mijn bericht ook alleen als suggestie bedoeld over hoe stompzinnig iets kan mislopen als bijv. de nieuwe authenticode uit KB2868626 voor XP/Vista een bug zou bevatten. In dat licht dient men het te lezen.
Niet als een "feit" maar als een suggestie. Maar het is prima dat je het terugkoppelt, zodat het kan worden opgehelderd. :) Maar kun je het in de kern met de rest van mijn verhaal eens zijn Erik?

Het zou kunnen dat KB2868626 een bug bevat, maar ik zie niet zo wat dat uitmaakt?

Dankzij Spiff die het probleem aankaartte en allen die aan deze boeiende thread hebben bijgedragen, hebben we vastgesteld dat fully patched Vista en XP systemen niet met de Authenticode signatures van EMET (maar ook andere bestanden) overweg kunnen, terwijl Windows 7 (zowel 32 als 64 bit) daar geen problemen mee heeft. Als "bonus" hebben we vastgesteld dat de toegepaste certificaten wel door XP en Vista geparsed kunnen worden, het gaat dus echt om een Authenticode probleem. Aangezien het gebruik van SHA256 nieuw lijkt te zijn bij timestamps, vermoed ik dat daar het probleem zit (maar dat zou ik best fout kunnen hebben).

Hopelijk besparen we andere gebruikers (met dezelfde problemen) tijd door op security.nl te posten (goed te vinden met Google). Om ook Engelstalige gebruikers te helpen heb ik vanochtend in https://isc.sans.edu/forums/diary/Beefing+up+Windows+End+Station+Security+with+EMET/18107 een zo kort mogelijke bijdrage gepost.

Voor zover ik zie in Microsoft's documentatie zou Vista dezelfde Authenticode functionaliteit moeten hebben als Windows 7 en 8. Wat mij betreft is Microsoft nu aan de bak, met de sourcecode erbij en een debugger is het voor hen veel eenvoudiger om vast te stellen wat de oorzaak is van genoemde problemen (voor zover ze die nog niet kennen).

13-05-2014, 10:17 door Anoniem

Door Erik van Straten: Het zou kunnen dat KB2868626 een bug bevat, maar ik zie niet zo wat dat uitmaakt? etc. etc.

Erik, uit je hele vorige bericht maak ik op dat we het wel aardig met elkaar eens zijn. Maar je onderschat denk ik de rol van KB2868626, omdat je je er niet in hebt verdiept, en daar eigenlijk ook niet zoveel zin meer in hebt.
En je staart je misschien een beetje blind op de laatste (niet zo belangrijke) alinea van mijn vorige bericht hierover.
(Dat is tenminste best voor te stellen na honderden berichten over dit topic... We worden er allemaal wat gammel van)

Maar testen in XPSP3 hebben uitgewezen dat er met KB2868626 dus een "nieuwe authenticode" is gekomen,
die het gedrag m.b.t. digitale handtekeningen met sha2 drastisch heeft veranderd!!!
In ieder geval in XPSP3. En het ligt voor de hand dat dit in Vista ook kan zijn gebeurd.
Dat is belangrijk, omdat je hiermee een concreet aangrijpingspunt hebt, dat specialisten verder kunnen onderzoeken.

Uit http://support.microsoft.com/kb/968730 blijkt dat authenticode met sha2 in XPSP3 oorspronkelijk niet
wordt ondersteund. Maar over authenticode met sha2 in Vista lees ik zoiets nergens... Jij wel???...
Sterker nog: er werd in deze url aangedrongen om over te stappen naar een nieuwer systeem, waaronder bijv. Vista.

Wat als Vista indertijd eigenlijk altijd al goed met sha2 in authenticode heeft kunnen werken?...
Dan zou het kunnen zijn, dat deze goede werking door "de Vista-implementatie van KB2868626" is getorpeeerd,
zodat Vista op dit punt opeens "XPSP3"-gedrag is gaan vertonen...
Dat Win7 en Win8 met deze update wél goed werken, zegt niets.
De implementatie van een update zal doorgaans voor ieder O.S. weer anders zijn.

Het is in dit geval zelfs niet uitgesloten dat het in Vista weer normaal werkt als voorheen, indien je KB2868626 verwijdert!
Je kunt nooit zeker weten als je niet de moeite neemt om het even uit te testen.
Nadeel is wel dat je dan die D.o.S. bescherming van KB2868626 mist.
Maar ook al los je dingen hiermee niet geheel op, dan heb je wél een goed verhaal en een goede indicatie om mee aan te komen bij een specialist, zodat het sneller opgelost kan worden!

Daarbij komt: je staat sterker met een goed verhaal.
Als spiff nog van plan is om er werk van te maken, dan kan hij natuurlijk niet als een pipo met één of ander onbevestigd verhaal van ene "kluk-kluk" aankomen met een constatering op een O.S. dat niet eens wordt ondersteund...
Dan moet hij een goed verhaal hebben, met een geverifieerde constatering op een (officieel nog ondersteund) Vista SP2 systeem.

Ik kan me voorstellen dat ook spiff er op dit moment even moe van is. Maar als het weer gaat en hij wil wat,
dan zou ik toch zeker aanraden om het op Vista eens zonder KB2868626 te proberen.
Het zou zonde zijn om na alle inspanningen die ons zó dicht bij de waarheid hebben gebracht, de boel op het laatste moment te laten schieten. Het is goed mogelijk dat Microsoft met die KB2868626-update gewoon in gebreke is!
En dat dit (op ondersteunde Vista-systemen) de oorzaak is dat je nu de integriteit van bestanden met "de nieuwe generatie sha2 signatures" niet meer fatsoenlijk kunt controleren... En dat nota bene met betrekking tot EMET...
Een instrument dat nu juist bedoeld is om de veiligheid zoveel mogelijk te waarborgen! (de ironie...)

Dan zou je als software- producent met veiligheid hoog in het vaandel in mijn ogen toch een behoorlijke flater slaan als je daar niets aan zou doen. (en het zou van Microsoft niet onverstandig zijn om, als het niet teveel moeite kost, om met een oplossing te komen die óók voor XP kan worden toegepast. Minimaal voor EMET4.1u1. Want als je voldoet aan de system-requirements van EMET4.1u1 (XPSP3 hoort daar bij!) dan behoort het gewoon goed te werken.
En dan moet je niet iets in de etalage gaan zetten dat zo'n stompzinnig gebrek vertoont, en je vervolgens achter de supportregels gaan verschuilen, terwijl iedereen weet dat de softwareproducent het vrij gemakkelijk op kan lossen. (anders stapt iedereen over naar Linux of zo...)
Ik kan me dus moeilijk voorstellen dat Microsoft zoiets niet op zou lossen.

Nog even een tip aan spiff (als je er de wil, de kans en de energie weer voor hebt): misschien kun je ook gewoon even naar een herstelpunt toegaan dat ergens vóór oktober 2013 ligt? Mvg, cluc-cluc.

13-05-2014, 12:00 door Spiff has left the building - Bijgewerkt: 13-05-2014, 12:01

@ Anoniem, cluc-cluc, 10:17 uur:

Dankjewel voor je vasthoudendheid!
Omdat ik de relevantie van je test en van je voorstel die test ook op m'n Vista systeem uit te voeren niet kon beoordelen en je voorstel niet werd ondersteund door de andere thread-deelnemers (N.B. maar ook niet nadrukkelijk werd afgewezen), twijfelde ik aan het nut van het uitvoeren van het uitvoeren ervan op mijn Vista systeem. Dat geldt nog steeds.
Maar zoals ik gisteren aangaf, voorafgaand aan een dergelijk onderzoek eerst een image maken en dat na de test weer terugzetten, dat kost niet zo veel tijd.
Ik zal je test daarom straks/ later vandaag uitvoeren en er dan vervolgens even over berichten.

Image maken,
KB2868626 verwijderen,
zien hoe dan vervolgens de weergave van de digitale handtekeningen is, van EMET 4.1u1 én van eerdere/andere installers,
KB2868626 terugplaatsen via Windows Update,
zien hoe dan vervolgens de weergave van de digitale handtekeningen is,
voorafgaand gemaakte image terugzetten.

Door Anoniem, cluc-cluc, 10:17 uur:
misschien kun je ook gewoon even naar een herstelpunt toegaan dat ergens vóór oktober 2013 ligt?

Uh, zúlke oude herstelpunten heb ik niet, hoor.
Met 15% van de systeempartitie van 90 GB gereserveerd voor herstelpunten worden om en nabij de 10 herstelpunten bewaard. Met het dagelijks aanmaken van herstelpunten levert dat dus een herstelpuntengeschiedenis tot ten hoogste zo'n 10 dagen geleden. Beslist niet tot voor oktober 2013.
Ik ga straks aan de slag met images.

13-05-2014, 15:51 door Anoniem

Door Erik van Straten:
Dankzij Spiff die het probleem aankaartte en allen die aan deze boeiende thread hebben bijgedragen, hebben we vastgesteld dat fully patched Vista en XP systemen niet met de Authenticode signatures van EMET (maar ook andere bestanden) overweg kunnen, terwijl Windows 7 (zowel 32 als 64 bit) daar geen problemen mee heeft. Als "bonus" hebben we vastgesteld dat de toegepaste certificaten wel door XP en Vista geparsed kunnen worden, het gaat dus echt om een Authenticode probleem. Aangezien het gebruik van SHA256 nieuw lijkt te zijn bij timestamps, vermoed ik dat daar het probleem zit (maar dat zou ik best fout kunnen hebben).

Voor zover ik zie in Microsoft's documentatie zou Vista dezelfde Authenticode functionaliteit moeten hebben als Windows 7 en 8.

Intussen ben ik in de veelheid van informatie gedurende de afgelopen 9 dagen het overzicht en het spoor een beetje kwijtgeraakt.

Ik zou het zeer waarderen, als Spiff, Erik van Straten of iemand anders ter afsluiting (als we daar intussen zijn aangeland) de conclusies zou willen samenvatten en ook zou willen aangeven wat ik als eenvoudige gebruiker van Windows 8.1 met EMET 4.1 (dus niet: EMET 4.1u1) op dit moment wel en niet zou moeten doen. Mijn kennis over deze materie gaat niet zover, dat ik dat op eigen kracht kan beoordelen.

Bij voorbaat erg veel dank.

Harry

13-05-2014, 16:04 door Spiff has left the building

Zoals ik 12:00 uur aangaf van plan te zijn,
heb ik inmiddels cluc-cluc's suggestie uitgevoerd:

KB2868626 verwijderen,
zien hoe dan vervolgens de weergave van de digitale handtekeningen is, van EMET 4.1u1 én van eerdere installers,
en vervolgens KB2868626 weer terugplaatsen via Windows Update.

Resultaat:
Na het verwijderen van KB2868626:
Voor EMET 4.0, 4.1 en TP(1):
"Deze digitale handtekening is in orde."
Voor EMET 4.1u1 en TP2:
"Deze digitale handtekening is ongeldig."

Geen verandering vergeleken met de situatie vóór het verwijderen van KB2868626.
Dit in afwijking van wat cluc-cluc constateerde onder XP.
Opvallend.
Valt hier nog iets uit te leren?

Vervolgens,
na het opnieuw installeren van KB2868626, via Windows Update:
Opnieuw geen verandering.

Hierna heb ik de oorspronkelijke situatie hersteld door middel van het terugzetten van een image dat ik gemaakt had voorafgaand aan het verwijderen van KB2868626.

13-05-2014, 16:34 door Spiff has left the building - Bijgewerkt: 13-05-2014, 16:35

Door Anoniem, Harry, 15:51 uur:
Intussen ben ik in de veelheid van informatie gedurende de afgelopen 9 dagen het overzicht en het spoor een beetje kwijtgeraakt.

Ik zou het zeer waarderen, als Spiff, Erik van Straten of iemand anders ter afsluiting (als we daar intussen zijn aangeland) de conclusies zou willen samenvatten en ook zou willen aangeven wat ik als eenvoudige gebruiker van Windows 8.1 met EMET 4.1 (dus niet: EMET 4.1u1) op dit moment wel en niet zou moeten doen. Mijn kennis over deze materie gaat niet zover, dat ik dat op eigen kracht kan beoordelen.

Ik kan me voorstellen dat je het overzicht kwijt bent.
Het is een extreme thread.

Het probleem zoals dat in deze thread besproken wordt, dat lijkt enkel Vista en nog eerdere Windows versies te betreffen.
Niemand heeft het probleem gemeld met Windows 7, en ook met Windows 8.1 heeft niemand het probleem gemeld.

Wil je op een Windows 8.1 systeem EMET 4.1 updaten naar EMET 4.1 Update 1, dan kun je daar gewoon EMET 4.1 Update 1 voor downloaden.
Het kan vervolgens uiteraard nooit kwaad om van het gedownloade en opgeslagen EMET 4.1 Update 1 installatiebestand even via rechtsklikken, Eigenschappen, Digitale handtekeningen, aanklikken, Details, te zien of gewoon wordt weergegeven "Deze digitale handtekening is in orde."
Maar er is niets dat er op wijst dat dat onder Windows 8.1 niet in orde zou zijn.
En uiteraard kun je dan gerust EMET 4.1 Update 1 installeren, als je dat wilt.

Verder -
Aan een afsluiting van deze thread zijn we nog niet aangeland.

Erik van Straten heeft gisteren, ma.12-5, 22:51 uur, al wel een mooie 'tussentijdse conclusie' neergezet,
https://www.security.nl/posting/386805#posting387782,
maar ik vermoed dat Didier Stevens nog van plan is om de tijd te nemen om dat Authenticode probleem onder Vista te onderzoeken, hij vroeg me zondag al even wat informatie, dus wellicht mogen we Didiers inzicht nog verwachten.

Is alles helemaal duidelijk vastgesteld, dan moeten we de boel nog bij Microsoft aan de orde zien te krijgen.
Misschien kan Didier Stevens' aandacht daaraan bijdragen.
En heel misschien zien we ook nog een reactie van Microsoft, wanneer Microsoft deze thread wil bestuderen, zoals me dat vorige week was toegezegd door Microsoft Nederland.

13-05-2014, 22:42 door Anoniem

Door Spiff:
Resultaat:
Na het verwijderen van KB2868626:
Voor EMET 4.0, 4.1 en TP(1): "Deze digitale handtekening is in orde."
Voor EMET 4.1u1 en TP2: "Deze digitale handtekening is ongeldig."
Vervolgens, na het opnieuw installeren van KB2868626, via Windows Update:
Opnieuw geen verandering.

Thanks Spiff ! Just to be sure:
1. Heb je zowel na verwijdering als na herinstallatie van KB2868626 beide keren ook nog een reboot gedaan?
2. Bleef de certificaatketen in het certificatenpad in orde, en was beide keren de countersignature afwezig?
Mvg, cluc-cluc

14-05-2014, 00:34 door Anoniem

Door Anoniem: of iemand anders ter afsluiting (als we daar intussen zijn aangeland) de conclusies zou willen samenvatten en ook zou willen aangeven wat ik als eenvoudige gebruiker van Windows 8.1 met EMET 4.1 (dus niet: EMET 4.1u1) op dit moment wel en niet zou moeten doen. Mijn kennis over deze materie gaat niet zover, dat ik dat op eigen kracht kan beoordelen.

Bij voorbaat erg veel dank.

Harry

Het gaat soms ook mijn pet te boven, duidelijk is wel dat geen eindgebruiker dit issue nog zelfstandig kan oplossen, en er is geen directe dreiging voor gebruikers van welk OS dan ook. Kort samengevat:

Gebruikers van oudere Win-32 OS (Vista & XP) krijgen een foutmelding tijdens installatie en bij het controleren van het certificaat van EMET 4.1 update, waardoor deze gebruikers niet eenvoudig vast kunnen stellen of het bestand dat zij uit willen voeren ook daadwerkelijk hetzelfde bestand is dat Microsoft heeft gepubliceerd. Met het bestand zelf is niets mis.

Tot nu toe betreft alleen enkele installatie-bestanden van MS. Of dit probleem in potentie ook andere CA's zou kunnen treffen kan ik niet met zekerheid zeggen, misschien kan Erik van Straten daar wat licht op werpen?

Ogenschijnlijk zit er een 'feature' (bug) in het stukje Windows-code dat certificaten moet controleren, de zgn. Authenticode. Met de certificaten op zich is dus niets mis, het gaat om de manier waarop Windows ze verwerkt. Op het moment is dit éxtra veilig, omdat er zelfs een waarschuwing wordt gegeven voor een legitiem bestand.
Het lijkt mij ook hoogst onwaarschijnlijk dat er misbruik gemaakt zou kunnen worden van deze 'feature.'

Voor alle duidelijkheid:
Op de >werking< van de betreffende software (EMET 4.1u) heeft het geen enkel effect!!!

14-05-2014, 00:34 door Spiff has left the building

Door Anoniem, cluc-cluc, 22:42 uur:
Just to be sure:
1. Heb je zowel na verwijdering als na herinstallatie van KB2868626 beide keren ook nog een reboot gedaan?
2. Bleef de certificaatketen in het certificatenpad in orde, en was beide keren de countersignature afwezig?

1. Ja, dat was noodzakelijk voor verwijderen en voor installeren van KB2868626.
2. Ja en ja. Niet anders dan eerder.

Merkwaardig dat dit voor jouw XP systeem en mijn Vista systeem zo anders uitpakte.
Heb je enig idee waardoor?
Valt hier iets uit af te leiden waar we nog wat aan hebben?

14-05-2014, 12:39 door Anoniem

Door Spiff: (00:34)
Merkwaardig dat dit voor jouw XP systeem en mijn Vista systeem zo anders uitpakte.
Heb je enig idee waardoor?
Valt hier iets uit af te leiden waar we nog wat aan hebben?

Inderdaad merkwaardig, maar ook weer niet helemaal compleet onverwacht: Vista is nu eenmaal geen XP.
Daarom heb ik het de moeite waard gevonden dat je het op Vista zou testen: als je daar een soortgelijk verschil zou zien
dan heb je een aangrijpingspunt in KB2868626. Zo niet, dan moet je andere mogelijkheden weer wagenwijd openhouden.

Intussen ben ik er achter dat KB2868626 een nieuwe versie van de crypt32.dll installeert.
Dit gebeurt in ieder geval op XPSP3. En ik verwacht dat dit op Vista ook zo is.

Maar waar dit op lijkt (een voorzichtige conclusie dus), is dat update KB2868626 voor XPSP3 naast het verhelpen
van de D.o.S. vulnerability óók stilzwijgend extra functionaliteit toevoegt om sha2 te ondersteunen.
Waarschijnlijk omdat die functionaliteit voorheen ontbrak (blijkt wel uit http://support.microsoft.com/kb/968730),
kon XPSP3 totaal niet met sha256 omgaan, zodat de digitale handtekening-tab ontbrak wanneer er sha256 in voorkwam.
Na update KB2868626 is dit kennelijk meteen ook maar even opgelost, tegelijk met die D.o.S. vulnerability.

Maar in In Vista was die ondersteuning voor sha2 waarschijnlijk al vóór KB2868626 aanwezig,
zodat je daar geen verschil ziet als je KB2868626 toevoegt.

Nogmaals: een voorzichtige conclusie, want de zaken zijn meestal complex. Wat mij betreft dienen de specialisten nu eerst eens na te gaan waarom het "Time-stamp certificaat" in Vista (en XP) ontbreken, en in win7/win8 niet.
Immers hiermee mist de digitale handtekening een belangrijk stuk controle-informatie, en de kans is bijzonder groot
dat om die reden de digitale handtekening in Vista en XPSP3 wordt afgekeurd. Om één of andere reden, kunnen XPSP3
en Vista die controlehandtekening niet goed uitlezen. Anders gezegd: de implementatie van Authenticode in XPSP3 en Vista werkt kennelijk net even anders dan in win7/win8. Mvg, cluc-cluc

14-05-2014, 16:41 door Anoniem

Voor alle zekerheid nog even deze aanvulling:

Het moge duidelijk zijn dat de problemen in XPSP3 en Vista tot nu toe alleen zijn optreden met digitale handtekeningen waarin het sha256-algoritme is gebruikt!... Handtekeningen met sha-1 zijn normaalgesproken geen probleem.

Dit sterkere sha256-algoritme dat tot de "sha2-familie" behoort, vindt de tijd snel opgang.
Op internet staan verschillende berichten van bedrijven en instanties die zijn overgegaan naar ondertekening met sha-2,
of die dit heel binnenkort zullen gaan doen.

Te verwachten is dus, dat je in de nabije toekomst steeds meer bestanden zult tegenkomen die met het voor XP en Vista (zoals het er nu naar uitziet) problematische sha2-algoritme zijn ondertekent,
en dat daarom het probleem waarschijnlijk groter is dan het op dit moment lijkt!...
Mvg, cluc-cluc.

15-05-2014, 14:21 door Spiff has left the building

Gezien het feit dat deze thread extreem lang en onoverzichtelijk is geworden, en gezien het feit dat sinds de oorspronkelijke post diverse zaken veel duidelijker zijn geworden, heb ik nu bovenaan mijn oorspronkelijke post van 4 mei de bijdrage van Erik van Straten van 12 mei (https://www.security.nl/posting/386805#posting387782) neergezet als update/aanvulling met voorlopige of tussentijdse samenvatting of voorlopige of tussentijdse conclusie.

15-05-2014, 17:38 door Erik van Straten

Prima Spiff!

Door Anoniem 2014-04-14 00:34:Tot nu toe betreft alleen enkele installatie-bestanden van MS. Of dit probleem in potentie ook andere CA's zou kunnen treffen kan ik niet met zekerheid zeggen, misschien kan Erik van Straten daar wat licht op werpen?

Als het probleem veroorzaakt wordt door SHA256 signed timestamps zal dit, vroeger of later, bij alle CA's gaan spelen verwacht ik (aangezien SHA-1 uitgefaseerd hoort te worden).

Als het probleem veroorzaakt wordt door een wijziging in Authenticode structuren met als gevolg het niet checken van de timestamp door Vista, is het denkbaar dat een correctie in het Microsoft code signing proces net even andere Authenticode structuren (met SHA256 signed timestamps) zou kunnen genereren die Vista -zonder aanpassingen- wel accepteert. In dat geval hangt het af van de gebruikte tooling voor het genereren van de Authenticode handtekening (die best complex is), dit is CA-onafhankelijk (de ondertekenaar kiest de tooling, bijv. een versie van Microsoft's signtool.exe).

Overigens, volgens https://en.wikipedia.org/wiki/Secure_Hash_Algorithm is SHA-1 ontworpen door de NSA (op die pagina staat ook wie SHA-2 ontworpen heeft). Gelukkig is op 1 april j.l. https://tools.ietf.org/html/rfc7169 gepubliceerd ;)

15-05-2014, 18:05 door Anoniem

Door Erik van Straten: Als het probleem veroorzaakt wordt door SHA256 signed timestamps zal dit, vroeger of later, bij alle CA's gaan spelen verwacht ik (aangezien SHA-1 uitgefaseerd hoort te worden).

Als het probleem veroorzaakt wordt door een wijziging in Authenticode structuren met als gevolg het niet checken van de timestamp door Vista, is het denkbaar dat een correctie in het Microsoft code signing proces net even andere Authenticode structuren (met SHA256 signed timestamps) zou kunnen genereren die Vista -zonder aanpassingen- wel accepteert. In dat geval hangt het af van de gebruikte tooling voor het genereren van de Authenticode handtekening (die best complex is), dit is CA-onafhankelijk (de ondertekenaar kiest de tooling, bijv. een versie van Microsoft's signtool.exe).

Overigens, volgens https://en.wikipedia.org/wiki/Secure_Hash_Algorithm is SHA-1 ontworpen door de NSA (op die pagina staat ook wie SHA-2 ontworpen heeft). Gelukkig is op 1 april j.l. https://tools.ietf.org/html/rfc7169 gepubliceerd ;)

Nuttige info, bedankt Erik!

NB: Om héél even op een vorig onderwerp terug te springen, analyzePESig van Didier Stevens:
http://blog.didierstevens.com/programs/authenticode-tools/#comment-165902

Is it me or doesn’t v3 work with .msi files anymore?

Comment by Anonymous — Sunday 11 May 2014 @ 10:15

Actually, I didn’t design AnalyzePESig to work with .msi files. In versions 0.0.1 and 0.0.2, it was a side-effect. But in version 0.0.3, I added many PE file checks,
and .msi is not a PE file.

Comment by Didier Stevens — Monday 12 May 2014 @ 21:04

Waren de antwoorden van MS maar zo snel & duidelijk ;)

19-05-2014, 15:58 door Anoniem

Nog een indicatie dat sha256 niet zomaar altijd goed werkt op Vista en XP:
zie: http://www.advancedinstaller.com/user-guide/digital-signature.html

Wat doet Advanded Installer?

Advanced Installer can digitally sign all of the following files that it creates: EXE, MSI, MSP (patches) and CAB files.

En hoe zit het hierbij dan met het gebruik van digest algoritme sha256?

By default Advanced Installer uses SHA1 as digest algorithm.
Microsoft recommends using SHA256 digest algorithm as they have detected certain scenarios
were SHA1 is insecure. However, it is very important to know that packages signed with SHA256
will not have their digital signature recognized on XP and Vista machines,
so if you still target XP and Vista machines we recommend using SHA1, i.e. do not enable this option.

M.a.w.: blijkbaar is het niet ongewoon dat XP en Vista problemen hebben met sha256...

Onze hoop is nu gevestigd op
http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx
waarin door MS ondermeer wordt gesteld dat:

"Windows XP Service Pack 3 supports SHA2 SSL certificates"

en verder:

Microsoft will give new consideration to the SHA deprecation deadlines in July 2015.
We will consider these among other conditions that may be prevalent at the time:

* whether SHA1 is still considered resistant to pre-image attacks by the security community, and
* whether a significant portion of the ecosystem is not capable of switching to SHA2. Third party
legacy systems and embedded devices that cannot be upgraded to SHA2 may be particularly susceptible.
We will continue to gather data on this portion of the ecosystem.

Naar ik heb begrepen is er al even met Microsoft Nederland gecommuniceerd. Maar heeft iemand inmiddels een bevestiging van Microsoft gekregen dat onze bevindingen (serieus) worden meegenomen?
Op 7 mei schijnt er al contact met MS te zijn geweest.
Op 11 mei 02:40 is er een vraag van Spiff geweest hoe één en ander nu het beste aan MS kan worden voorgelegd.
Ik zou zeggen: bepaal hen bij bovenstaande teksten en bind hen aan wat MS er zélf over heeft geschreven.
Wat mij betreft is het al voldoende duidelijk dat er een probleem is, en waar dit probleem mee te maken heeft,
namelijk met de overstap naar sha256.

Natuurlijk zijn ook bevindingen van Didier Stevens nog welkom, om daarmee eventueel nog meer kracht bij te zetten
(zijn laatste bericht: "I’ll try to make analysis of .msi possible again..." Ik mag aannemen dat dit betrekking heeft op AnalyzePESig v0.0.3...). Of hij er dan zelf ook verder nog mee aan de slag gaat, weet ik niet.
Maar in alle bescheidenheid: is het intussen eigenlijk al niet voldoende duidelijk waar de problemen vandaan komen?
Mvg, cluc-cluc

19-05-2014, 21:00 door Spiff has left the building - Bijgewerkt: 19-05-2014, 22:40

In reactie op Anoniem, cluc-cluc, 15:58,
Dankjewel voor die informatie.

Het blijkt dus bekend dat "packages signed with SHA256 will not have their digital signature recognized on XP and Vista machines" (http://www.advancedinstaller.com/user-guide/digital-signature.html).

En Microsoft voert stapje voor stapje een SHA1 deprecation door, ook voor Vista, waarbij Microsoft aangeeft "Windows users will not be affected by the transition to SHA2,"maar tevens "however Microsoft, CAs and their affected customers must assess the impact on legacy systems and devices now and not later on the timeline." (http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx)

Die tweede bron vermeldt "Windows users do not need to do anything in response to this new technical requirement – Windows XP Service Pack 3 supports SHA2 SSL certificates, and Windows Server 2003 Service Pack 2 or later add SHA2 functionality to SSL certificate by application of hotfixes (KB968730 and KB938397)."
Maar dat betreft SHA2 en SSL, en niet de SHA256 code signing certificates betreffend uitvoerbare bestanden zoals EMET, etc. Over SHA256 ondertekende bestanden in relatie met Vista, daarover zegt Microsoft niets in die bron - als ik me niet vergis.
Leest iemand anders dan mogelijk anders?

Vervolgens -
Hoe kunnen we die informatie uit die twee bronnen zo goed mogelijk combineren met wat eerder al is geconstateerd?
Ik neem aan dat het een aanvulling is op wat Erik van Straten eerder neerzette? (https://www.security.nl/posting/386805#posting387782)

Wie van jullie heeft het inzicht om op basis van de eerdere constateringen en de nieuwe informatie een voor Microsoft to-the-point stukje neer te zetten?
Zijn we inmiddels zo ver, of missen we nog informatie?

Kan iemand een samenvattend stukje produceren dat alle elementen bevat die voor Microsoft essentieel zijn, dan zou dat geweldig zijn. Ik hoop dat iemand een dergelijk samenvattend stukje kan produceren waar iedereen zich in kan vinden.
Ikzelf mis het diepere inzicht in de materie om een goeie samenvatting op te stellen.

Hebben we een nieuw samenvattend stukje dat alle elementen bevat die voor Microsoft essentieel zijn, dan plaats ik dat in de startpost van deze thread en verwijs ik Microsoft opnieuw naar deze thread, en tevens post ik die samenvatting dan tevens maar op Microsoft Community.

En cluc-cluc, je had het over het eerdere contact met Microsoft.
Op 7 mei heb ik gebeld met Microsoft Nederland, het probleem kort uiteengezet (N.B. dat was met de inzichten van dat moment) en Microsoft naar deze thread verwezen.
Microsoft heeft mijn attendering doorgezet naar de betreffende afdeling of medewerkers. Er kon echter niks beloofd worden over de termijn waarbinnen Microsoft aan het bestuderen van deze thread zou toekomen.
Zonder lelijk te willen doen over Microsoft, het zou zomaar zo kunnen zijn dat Microsoft de belofte deze thread te bekijken niet is nagekomen, of dat Microsoft is afgehaakt vanwege de lengte van de thread en het ontbreken van overzicht. In dat geval zou het beter zijn geweest om ons om een samenvatting te vragen.

En ten slotte,
cluc-cluc, je schreef, "Natuurlijk zijn ook bevindingen van Didier Stevens nog welkom."
Ik vond zonet een mailtje van Didier Stevens, waarin hij aangeeft dat hij het op het moment nogal druk heeft, en het Authenticode probleem onder Vista op zijn to-do-list zet om het later in detail te bekijken.

Bewerkingen:
21:07 uur: Informatie betreffend e-mail van Didier Stevens bijgevoegd.
22:38 uur: Mijn formulering betreffend SHA2 SSL en SHA256 code signing certificates aangepast.
22:40 uur: Correctie van een typo.

20-05-2014, 12:33 door Anoniem

Bedankt voor je reactie Spiff.

Misschien moeten we bij

Het blijkt dus bekend dat "packages signed with SHA256 will not have their digital signature recognized
on XP and Vista machines" (http://www.advancedinstaller.com/user-guide/digital-signature.html).

nog wel even opmerken dat dit slaat op signatures die met "Advanced Installer"-software zijn gegenereerd.
Maar er blijkt evengoed uit, dat XP/Vista kennelijk al snel problemen geven met digitale handtekeningen met SHA256.

Verder nog twee dingen:
1. Moet dat bericht aan Microsoft in het engels?
2. Eventueel nog vermeldenswaardig aan Microsoft, of anders gewoon voor de volledigheid hierbij de volgende info:

We zijn nog niet zo diep ingegaan op de eerder geposte CAPI2-log van Spiff.
Die liet aan het einde een 0x80096010 foutmelding zien.
Opgezocht in: http://msdn.microsoft.com/en-us/library/windows/desktop/dd542646(v=vs.85).aspx:
0x80096010 = TRUST_E_BAD_DIGEST = The digital signature of the object did not verify.

In XPSP3 nog even getest met analyzePESig v.0.0.2 (v0.0.3 werkt niet), aangezien CAPI2 niet werkt op XP.
AnalyzePESig geeft bij mij op XPSP3 wel een andere error: 0x800B0100 = TRUST_E_NOSIGNATURE.
Zie log hieronder. (opmerking: error code decimaal 2148204800 = hexadecimaal 0x800B0100...)

AnalyzePESig meldt dus in XP dat hij géén handtekening ziet: "TRUST_E_NOSIGNATURE".
Dit gebeurt zowel mét als zonder KB2868626.
Maar CAPI2 in Vista meldt: "TRUST_E_BAD_DIGEST."
Mogelijke oorzaak van dit "error-code" verschil:
a) een verschil tussen XP en Vista
b) een interpretatieverschil tussen CAPI2 en AnalyzePESig.
Het kan misschien interessant zijn om eens na te gaan welke error AnalyzePESig 0.0.2 aangeeft in Vista,
om daaruit af te leiden of XP en Vista nu wel of niet allebei op EXACT hetzelfde probleem stuklopen?

Opmerkelijk is ook, dat het in alle gevallen dus wel duidelijk een ándere foutmelding betreft dan 0x80096005 =
TRUST_E_TIME_STAMP = The timestamp signature and/or certificate could not be verified or is malformed.
Dat het time-stamp certificaat ("countersignature") in XP en Vista ontbreekt, is dus niet te wijten aan een certificaatfout.
(en dat het timestamp certificaat in principe in orde is, had Erik eerder in deze thread ook al bewezen)
M.a.w: het verificatie-proces ziet geen certificaatfout, maar de parser mist kennelijk gewoon de hele countersignature.

Volgens mij wordt met "digest" de "samenvattende" hash bedoeld, die als controle dient.
TRUST_E_BAD_DIGEST betekent dan, dat een tijdens het verificatieproces herberekende hash niet overeenkomt met de oorspronkelijke hash die als controlewaarde in de digitale handtekening staat vermeld.

Mijn idee is: als een stuk data niet (goed) wordt uitgelezen, dan zal dit gemiste stuk data vervolgens ook niet
(goed) worden meegenomen bij het herberekenen van de hash van de digitale handtekening tijdens het verificatieproces.
Gevolg: de uitkomst zal niet overeenstemmen met de controlewaarde die in de digitale handtekening staat vermeld.
Resultaat: 0x80096010 = TRUST_E_BAD_DIGEST = The digital signature of the object did not verify...

-------------------------------------------------------------------------------------------------------------------
Hieronder de resultaten van analyzePESig v.0.0.2 met het "EMET4.1 update1 installatiepakket" op een XPSP3-systeem:

ZONDER KB2868626:
--------------------------------

Filename: emetu1.msi
MD5: 9e13573ab8e03603f4516481e4461a44
Entropy: 7.95949
Creation time: 2014/05/19 21:09:03
Last write time: 2014/05/06 18:22:34
Last access time: 2014/05/19 00:00:00
File attributes: 32
File attributes decode: A
Characteristics: 0
Characteristics decode:
Sections:
Valid signature: 0
Error code: 2148204800 Geen handtekening aanwezig in het onderwerp.
From catalog file: 0
Count catalog files: 0
Catalog filename:
Issuer name:
Subject name:
Timestamp signature: 1601/01/01 01:00:00 (* hier is de parser overduidelijk op tilt gegaan! *)
Timestamp countersignature:
Extensions:
Root name:
Root thumbprint:
Signature hash algorithm:
File description:
Company name:

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

MÉT KB2868626:
-------------------------

Filename: emetu1.msi
MD5: 9e13573ab8e03603f4516481e4461a44
Entropy: 7.95949
Creation time: 2014/05/19 19:09:41
Last write time: 2014/05/06 18:22:34
Last access time: 2014/05/19 00:00:00
File attributes: 32
File attributes decode: A
Characteristics: 0
Characteristics decode:
Sections:
Valid signature: 0
Error code: 2148204800 Geen handtekening aanwezig in het onderwerp.
From catalog file: 0
Count catalog files: 0
Catalog filename:
Issuer name: Microsoft Code Signing PCA 2011
Subject name: Microsoft Corporation
Timestamp signature: 2014/05/19 20:02:43 (* merkwaardig tijdtip!... *)
Timestamp countersignature: (* countersignature wordt kennelijk weer niet gedetecteerd? *)
Extensions: 1.3.6.1.5.5.7.1.1,
2.5.29.14,
2.5.29.17,
2.5.29.19C,
2.5.29.31,
2.5.29.35,
2.5.29.37
Root name: C=US, S=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2011
Root thumbprint: 8f43288ad272f3103b6fb1428485ea3014c0bcfe
Signature hash algorithm: 2.16.840.1.101.3.4.2.1
Not before chain: 2013/09/24 18:41:41
Not after chain: 2014/12/24 18:41:41
Not before chain: 2011/07/08 21:59:09
Not after chain: 2026/07/08 22:09:09
Not before chain: 2011/03/22 23:05:28
Not after chain: 2036/03/22 23:13:04
Subject name chain: C=US, S=Washington, L=Redmond, O=Microsoft Corporation, OU=MOPR, CN=Microsoft Corporation
Subject name chain: C=US, S=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Code Signing PCA 2011
Subject name chain: C=US, S=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2011
Signature hash algorithm chain: 1.2.840.113549.1.1.11
Signature hash algorithm chain: 1.2.840.113549.1.1.11
Signature hash algorithm chain: 1.2.840.113549.1.1.11
Serial number chain: 330000001a77bb74b307d116b800000000001a
Serial number chain: 610e90d2000000000003
Serial number chain: 3f8bc8b5fc9fb29643b569d66c42e144
Thumbprint chain: 6474839af67ab79c91007ff62fe08e2acf016b83
Thumbprint chain: f252e794fe438e35ace6e53762c0a234a2c52135
Thumbprint chain: 8f43288ad272f3103b6fb1428485ea3014c0bcfe
Keylength chain: 2048
Keylength chain: 4096
Keylength chain: 4096
Issuer unique ID chain: 0
Issuer unique ID chain: 0
Issuer unique ID chain: 0
Subject unique ID chain: 0
Subject unique ID chain: 0
Subject unique ID chain: 0
Extensions chain: 1.3.6.1.5.5.7.1.1,
2.5.29.14,
2.5.29.17,
2.5.29.19C,
2.5.29.31,
2.5.29.35,
2.5.29.37
Extensions chain: 1.3.6.1.4.1.311.20.2,
1.3.6.1.4.1.311.21.1,
1.3.6.1.5.5.7.1.1,
2.5.29.14,
2.5.29.15,
2.5.29.19C,
2.5.29.31,
2.5.29.32,
2.5.29.35
Extensions chain: 1.3.6.1.4.1.311.21.1,
2.5.29.14,
2.5.29.15,
2.5.29.19C
File description:
Company name:
--------------------------------------------------------------------------------------------------------------------------------------------

Mvg, cluc-cluc

20-05-2014, 16:19 door Spiff has left the building

Door Anoniem, cluc-cluc, 12:33 uur:
Moet dat bericht aan Microsoft in het engels?

Dat is niet nodig, denk ik.
Wanneer ik Microsoft Nederland kan verwijzen naar een samenvattend stukje in deze thread dat alle elementen bevat die voor Microsoft essentieel zijn, en tevens naar eenzelfde (nog te posten) stukje in de Nederlandstalige Microsoft Community (answers.microsoft.com) (als Microsoft dat verkiest/vereist), en ik Microsoft op die manier (nogmaals) op de materie kan attenderen, dan kan Microsoft Nederland daaruit prima de gevolgtrekkingen maken die nodig zijn en de boel intern doorzetten, zo mag ik aannemen.

Door Anoniem, cluc-cluc, 12:33 uur:
Het kan misschien interessant zijn om eens na te gaan welke error AnalyzePESig 0.0.2 aangeeft in Vista,
om daaruit af te leiden of XP en Vista nu wel of niet allebei op EXACT hetzelfde probleem stuklopen?

Da's prima.
Hieronder de resultaten van analyzePESig v.0.0.2 met de EMET4.1 update1 installer op een Windows Vista SP2 x86 systeem:

Filename: EMET Setup.msi
MD5: 9e13573ab8e03603f4516481e4461a44
Entropy: 7.95949
Creation time: 2014/05/20 15:56:52
Last write time: 2014/05/06 21:17:56
Last access time: 2014/05/20 15:56:52
File attributes: 32
File attributes decode: A
Characteristics: 0
Characteristics decode:
Sections:
Valid signature: 0
Error code: 2148204800 Geen handtekening aanwezig in het onderwerp.
From catalog file: 0
Count catalog files: 0
Catalog filename:
Issuer name: Microsoft Code Signing PCA 2011
Subject name: Microsoft Corporation
Timestamp signature: 2014/05/20 15:59:14
Timestamp countersignature:
Extensions:
1.3.6.1.5.5.7.1.1,
2.5.29.14,
2.5.29.17,
2.5.29.19C,
2.5.29.31,
2.5.29.35,
2.5.29.37
Root name: C=US, S=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2011
Root thumbprint: 8f43288ad272f3103b6fb1428485ea3014c0bcfe
Signature hash algorithm: 2.16.840.1.101.3.4.2.1
Not before chain: 2013/09/24 19:41:41
Not after chain: 2014/12/24 19:41:41
Not before chain: 2011/07/08 22:59:09
Not after chain: 2026/07/08 23:09:09
Not before chain: 2011/03/23 00:05:28
Not after chain: 2036/03/23 00:13:04
Subject name chain: C=US, S=Washington, L=Redmond, O=Microsoft Corporation, OU=MOPR, CN=Microsoft Corporation
Subject name chain: C=US, S=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Code Signing PCA 2011
Subject name chain: C=US, S=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Root Certificate Authority 2011
Signature hash algorithm chain: 1.2.840.113549.1.1.11
Signature hash algorithm chain: 1.2.840.113549.1.1.11
Signature hash algorithm chain: 1.2.840.113549.1.1.11
Serial number chain: 330000001a77bb74b307d116b800000000001a
Serial number chain: 610e90d2000000000003
Serial number chain: 3f8bc8b5fc9fb29643b569d66c42e144
Thumbprint chain: 6474839af67ab79c91007ff62fe08e2acf016b83
Thumbprint chain: f252e794fe438e35ace6e53762c0a234a2c52135
Thumbprint chain: 8f43288ad272f3103b6fb1428485ea3014c0bcfe
Keylength chain: 2048
Keylength chain: 4096
Keylength chain: 4096
Issuer unique ID chain: 0
Issuer unique ID chain: 0
Issuer unique ID chain: 0
Subject unique ID chain: 0
Subject unique ID chain: 0
Subject unique ID chain: 0
Extensions chain:
1.3.6.1.5.5.7.1.1,
2.5.29.14,
2.5.29.17,
2.5.29.19C,
2.5.29.31,
2.5.29.35,
2.5.29.37
Extensions chain:
1.3.6.1.4.1.311.20.2,
1.3.6.1.4.1.311.21.1,
1.3.6.1.5.5.7.1.1,
2.5.29.14,
2.5.29.15,
2.5.29.19C,
2.5.29.31,
2.5.29.32,
2.5.29.35
Extensions chain:
1.3.6.1.4.1.311.21.1,
2.5.29.14,
2.5.29.15,
2.5.29.19C
File description:
Company name:

21-05-2014, 13:11 door Anoniem

Het ziet er naar uit dat het verschil in error code (CAPI2:0x80096010 ; AnalyzePESig(0.0.2): 2148204800 = 0x800B0100)
veroorzaakt wordt door een interpretatieverschil tussen CAPI2 en AnalyzePESig.
M.a.w.: dit heeft waarschijnlijk te maken met het gebruikte tool, en niet met het gebruikte O.S.

De symptomen in XP en in Vista stemmen zoveel overeen, dat de veronderstelling nu wel gerechtvaardigd lijkt,
dat de geconstateerde problemen in XP en in Vista min of meer dezelfde oorzaak hebben.
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Voor wat betreft de samenvatting aan Microsoft: dit kan denk ik tamelijk eenvoudig blijven.

1. Microsoft heeft security-software in de etalage staan. Ze noemen het EMET (Enhanced Mitigation Experience Toolkit).
2. De laatste officiële versie van EMET is naar hun eigen zeggen óók geschikt voor Windows Vista en Windows XPSP3.
Te downloaden via: http://www.microsoft.com/en-us/download/details.aspx?id=41138
3. O.a. jij (Spiff) hebt met Vista (SP2?) geconstateerd dat het er op lijkt alsof er met dit installatiepakket is geknoeid.
O.a. ik (cluc-cluc) heb hetzelfde geconstateerd onder XPSP3. (alle standaard aanbevolen patches geïnstalleerd)
Beide systemen geven aan dat de digitale handtekening van het bestand ongeldig zou zijn.
Het valt op dat de digitale handtekening geen controlehandtekening ("countersignature") toont.
4. Vervolgens is gebleken dat dit een valse melding is: hetzelfde bestand wordt op win7/win8 in orde bevonden.
En de controlehandtekening ("countersignature") is daar wél normaal zichtbaar.
5. Wij zijn van mening dat het nogal onprofessioneel overkomt dat Microsoft een stuk beveiligingsgereedschap
in de etalage zet, dat meteen al zulke gebreken vertoont op Vista en XPSP3.
Wij wijzen Microsoft er op, dat zoiets het vertrouwen in Microsoft kan ondermijnen,
vooral als men het niet binnen een redelijke termijn fatsoenlijk zou oplossen.

6. De community van security.nl heeft onderzocht (voor zover de mogelijkheden reiken) waar het probleem zit.
Meerdere mensen hebben hieraan bijgedragen, aan wie de nodige dank en eer is verschuldigd.
Een bijzonder opvallend verschil tussen "EMET4.1 update1" en alle voorgaande versies van EMET is,
dat de digitale handtekening van "EMET4.1 update1" het SHA256-algoritme gebruikt.
7. We zijn uiteindelijk tot de conclusie gekomen, dat het probleem hier hoogst waarschijnlijk mee te maken heeft.
We hebben geconstateerd dat een ander bestand met SHA256 van Microsoft, PowerPivot_for_Excel_x86.msi,
te downloaden via: http://www.microsoft.com/en-us/download/confirmation.aspx?id=29074,
dezelfde problemen met de digitale handtekening vertoont .
Nog een andere indicatie dat SHA256 niet goed werkt op Vista en XP-systemen vonden wij op:
http://www.advancedinstaller.com/user-guide/digital-signature.html
8. Wij hebben de indruk dat er met update KB2868626 in XPSP3 door Microsoft een belangrijke stap voorwaarts is gezet
met het herkennen van SHA2 in XPSP3, zodat de functionaliteit wat dit betreft op het niveau van Vista is gekomen.
Maar het werkt kennelijk nog niet goed genoeg om digitale ondertekeningen van bestanden voor de volle 100% te
kunnen verifiëren.

9. Wij doen op grond van al onze bevindingen, zowel in het belang van EMET-gebruikers op Vista/XPSP3
als in het belang van Microsoft zélf (nl. om gezichtsverlies wegens onprofessionaliteit te voorkomen),
hierbij de volgende verzoeken aan Microsoft:

a. mocht er voor het geconstateerde probleem toch nog ergens een patch bestaan, a.u.b. de community hierover te
informeren. En indien zo'n patch niet bestaat:

b. Zo spoedig mogelijk een "EMET4.1 update1" -versie on-line te zetten, die de hier geschetste problemen
met Vista en XPSP3 niet kent. (bijvoorbeeld een installatiepakket dat is ondertekend met SHA1 i.p.v. SHA256?)

c. Voor evt. toekomstige versies ven EMET die op XPSP3 en Vista kunnen draaien rekening te houden met de
leesbaarheid van de digitale ondertekening van het EMET-installatiepakket op zulke systemen.

d. Gedegen bezinning op de voorgenomen policy om SHA-1 zondermeer uit te faseren en naar SHA256 over te gaan.
Te verwachten is immers dat er nog geruime tijd XP en Vista gebruikers zullen bestaan (aangezien lang niet iedereen
op deze wereld een goed gevulde beurs heeft om over te kunnen stappen...)
Wanneer het zulke Microsoft XP/Vista-gebruikers dan hele basale veiligheidsbeginselen (zoals bevestiging
van authenticiteit en integriteit van bestanden) zou moeten ontberen, dan zouden zulke oudere systemen
gemakkelijk een grote bron van virussen en malware etc. kunnen gaan worden.
En daar zullen dan niet alleen deze gebruikers zélf, maar ook andere internetgebruikers last van krijgen.

Wij hopen dat Microsoft wat dit betreft zijn verantwoordelijkheid neemt, en zich op zo'n basaal punt
niet gaat verschuilen achter "XP wordt niet meer gesupport". (het lijkt er trouwens ook op dat KB2868626
deze ondersteuning voor SHA256 allang had moeten bieden, maar dat deze update helaas faalt in geval van het
controleren van digitale handtekeningen van bestanden met SHA256, en dat Microsoft dit niet heeft voorzien)

10. Graag een schriftelijke bevestiging van ontvangst van Microsoft, en hoe Microsoft dit bericht verder af zal handelen.

Mvg, cluc-cluc

21-05-2014, 14:16 door Spiff has left the building

In reactie op Anoniem, cluc-cluc, 13:11 uur,

Hartelijk dank voor de mooie samenvatting plus tevens oproep aan Microsoft.

Alvorens ik vervolgens Microsoft hierop ga attenderen door een telefonische verwijzing plus plaatsen op en verwijzen via de Nederlandstalige Microsoft Community (answers.microsoft.com), eerst nog even deze twee punten:

1.
Hebben de andere bijdragers in deze thread (Erik van Straten, Eric-Jan H te A, Fwiffo, Ilja. _V V, _kraai__, W. Spu, anderen) mogelijk nog commentaren op, dan wel wijzigingsvoorstellen bij cluc-clucs samenvatting plus oproep?
Zo ja, geef dan graag zo nauwkeurig mogelijk aan welk deel van cluc-clucs bijdrage je zou willen veranderen en/of zou willen aanvullen en graag tevens ook woordelijk hoe of wat.

2.
Zelf ben ik van mening dat, ondanks het feit dat de zaak zowel Vista als ook XP (en eerdere Windows versies) raakt, het wellicht verstandiger zou zijn om betreffend de aan Microsoft te verzoeken actie Windows Vista en Windows XP te ontkoppelen.
Dit vanwege het simpele feit dat Vista nog tot april 2017 ondersteund wordt betreffend beveiliging, en XP inmiddels niet meer ondersteund wordt (behalve enkel nog met een contract voor custom support) .
Ondanks het feit dat EMET 4.1 Update 1 nog wél Windows XP ondersteunt, en daarom de ondertekening van de EMET 4.1 Update 1 installer op een juiste manier gecontroleerd zou moeten kunnen worden onder XP, denk ik dat we wegens de afgelopen ondersteuning van Windows XP niet meer van Microsoft mogen verwachten dat Microsoft problemen gaat oplossen met betrekking tot XP. Voor Vista ligt dat anders.
Om die reden denk ik dat het wellicht beter zou zijn om, betreffend de aan Microsoft te verzoeken actie, Vista en XP te ontkoppelen en de formuleringen betreffende Vista en XP te scheiden.

Ik wacht jullie reactie op die punten 1 en 2 even af.
Alvast hartelijk bedankt.

21-05-2014, 14:55 door W. Spu

Beste Spiff en cluc-cluc,

Het probleem speelt zeer waarschijnlijk ook op een Windows 2003 server waar het countersignature ook niet zichtbaar is en het certificaat niet geverifieerd kan worden. Ook heb ik het probleem geconstateerd in een driver van een anti virus leverancier die ondertekend is met het 'Microsoft Windows Early Launch Anti-malware Publisher' certificaat.

Verwacht trouwens niet zoveel van de Microsoft Community. Ik zelf heb al een tijdje geleden deze pagina aan gemaakt en nog van niemand een rectie gekregen. http://social.technet.microsoft.com/Forums/security/en-US/ddbad3af-38ea-4fe5-8994-e1890425ed92/emet-41-update-1-the-digital-signature-of-the-object-did-not-verify-on-vistaxp?forum=emet

Ook hebben we al contact met Microsoft en tot nu toe hebben we de vraag gekregen of het root certificaat wel geïnstalleerd is, of we de update KB931125 al geïnstalleerd hebben en of de group policy setting 'Turn off Automatic Root Certificates Update' soms enabled was. Microsoft zegt dat EMET 4.1 update 1 geschikt is voor Windows XP en zullen het probleem ook voor dat OS proberen op te lossen.

Hopelijk komt Microsoft snel met een oplossing ondanks dat we geen Vista hebben draaien (behalve een voor dit probleem een nieuwe geinstalleerde virtuele computer) en systemen met Windows XP gelukkig zeldzaam zijn geworden.

21-05-2014, 15:26 door Spiff has left the building

Door W. Spu:
Verwacht trouwens niet zoveel van de Microsoft Community.

Beslist niet. Een eerdere ervaring ermee in relatie tot een MSXML 4.0 update issue was een verschrikking.
Een Microsoft Community forumbeheerder moet het probleem snappen en de ernst ervan inzien voordat de zaak wordt geëscaleerd naar Microsoft, en de communicatie loopt dan via die forumbeheerder. In dat voorbeeld van dat MSXML 4.0 update issue was dat proces hemeltergend.
Mijn enige reden dat ik tevens op Microsoft Community wil posten, dat is omdat Microsoft Nederland eerder genegen is om daar een post te willen bekijken, dan elders zoals hier.

Door W. Spu:
Ook hebben we al contact met Microsoft en tot nu toe hebben we de vraag gekregen of het root certificaat wel geïnstalleerd is, of we de update KB931125 al geïnstalleerd hebben en of de group policy setting 'Turn off Automatic Root Certificates Update' soms enabled was. Microsoft zegt dat EMET 4.1 update 1 geschikt is voor Windows XP en zullen het probleem ook voor dat OS proberen op te lossen.

Heb je Microsoft ook naar deze thread op Security.nl verwezen?
Met de post van Erik van Straten van 12-05-2014, 22:51 uur, die ik ook in het startbericht van deze post geplaatst heb, zou Microsoft toch al aan de slag moeten kunnen, mag ik denken?
Zo niet, dan hopelijk met cluc-clucs post van vandaag, 13:11 uur (met al dan niet nog wijzigingen/ aanvullingen).

21-05-2014, 17:59 door Anoniem

Hee Spiff,
Je hebt wat jouw punt 2 betreft in zoverre gelijk dat het uiteraard vooral gaat om besturingssytemen die nog worden ondersteund. Het minste dat je mag verwachten, is dat Microsoft dáár in ieder geval structureel iets aan gaat doen.

Maar ik zou XP niet ontkoppelen, omdat het naar alle waarschijnlijkheid om nagenoeg hetzelfde probleem gaat.
M.a.w.: heeft men de oorzaak en de oplossing voor Vista gevonden, dan heeft men het voor XP ook al bijna opgelost...
Verder dient XP als "doublecheck" dat er kennelijk heus een probleem bestaat met die digitale handtekeningen met sha256. Eventueel zou je wél de nadruk nog iets scherper kunnen leggen op een oplossing van Microsoft voor Vista.

In punt 9d is toegelicht waarom er ook reden bestaat om XP-gebruikers op dit punt nog één keer tegemoet te komen
(net zoals ze onlangs hebben gedaan met die Explorer-vulnerability) ook al wordt XP officieel niet meer ondersteund.
Microsoft is immers in de veronderstelling dat sha2 inmiddels gewoon goed zou moeten werken op XPSP3.
(anders hadden ze natuurlijk nooit sha256 in EMET4.1u1 toegepast!!!)
Maar nu blijkt dit voor digitale handtekeningen van bestanden opeens toch NIET te werken.
Een zichzelf respecterend bedrijf zegt in zo'n geval tegen zichzelf: "oeps... dat fixen we dan nog maar even".
Mede ook vanwege het belang dat er mee gemoeid is, en omdat het om een heel basaal veiligheidsrisico gaat,
dat eigenlijk niet zou mogen gebeuren... Plus dat het nog vervelende risico's kan hebben voor de toekomst,
die Microsoft relatief gemakkelijk kan vermijden door de oplossing voor Vista ook in XP te implementeren.

Zoiets heet: "verantwoordelijkheid nemen". (let op punt 9d tot aan punt tien)
MS hoeft volgens de regels misschien niets te doen, maar doet het in het algemeen belang in dit geval tóch, omdat MS
wel inziet dat het iedereen (inclusief MS zelf...) uiteindelijk alleen maar zou schaden als MS niets zou doen.

We moeten hierbij beseffen dat de wereld groter is dan het vooroplopende, rijke Nederland.
Wereldwijd zullen er voorlopig heus nog wel een aanzienlijk aantal XP-machines aan het internet hangen.
En niet-kritische gebruikers in armere streken zullen zich niet zo druk maken over hun security op internet.
Vooral als ze onvoldoende middelen hebben om aan iets beters te komen. Vergis je niet.
Zie het nog niet eens zo oude bericht: http://webwereld.nl/software/81184-windows-xp-vergroot-marktaandeel
en http://webwereld.nl/beveiliging/82372-windows-xp-gebruiker-laat-aloud-os-maar-niet-los
Daarbij komt: de huidige hoeveelheid XP-gebruikers is nog altijd bijna 6x zo groot als het aantal Vista gebruikers!...
Mvg, cluc-cluc.

21-05-2014, 19:09 door Anoniem

Door Spiff: Hebben de andere bijdragers in deze thread ... mogelijk nog commentaren op, dan wel wijzigingsvoorstellen bij cluc-clucs samenvatting plus oproep?
...
Alvast hartelijk bedankt.

1] Algemeen: Ik zou een beetje uitkijken met de toon en het stellen van eisen, met stroop vang je een stuk meer MS-vliegen.
Daarnaast is dit geen kritiek veiligheidsprobleem, maar meer een "slordigheidje."

Inhoudelijk:

1&2 = overbodig.
3 = Beginnen met constatering, certificaat van Emet 4.1u1 lijkt niet te kloppen in Win XP, Vista & Server 2003, vervolgens de exacte melding weergeven natuurlijk.
4 = prima, Win7 & 8 werken wel.
5 = overbodig
6 = Snapte het niet, wilde geen "domme" vragen stellen, topic gestart op security.nl
7 = Samen met communtiy vast kunnen stellen dat het:
A] reproduceerbaar is op >>>IEDER<<< XP, Vista & Server 2003 systeem, voorzien van >>>ALLE<<< KB's
B] niet aan het certificaat zelf lijkt te liggen
C] het lijkt te gaan om de authenticode in het OS zelf icm SHA-256

En nu komt het*:
D] Zijn er meer SHA-256 certificaten van andere CA's te vinden? Hebben die hetzelfde probleem?
E] Geldt het voor de gehele SHA-2 familie?
F] Geldt het voor webcertificaten?

Vervolgens kun je dan motiveren dat je het niet vindt kunnen dat een systeem als Vista, dat tot zeker 2017 ondersteunt wordt, op het eerste gezicht niet overweg kan met SHA-256 certificaten van MS zelf, zeker omdat er vanaf 2016 enkel nog SHA-2 certificaten geaccepteerd zullen worden en er vanaf 2017 geen SHA-1 certificaten gebruikt mogen worden. Ook zou ik de andere overwegingen van cluc-cluc nog eens bekijken vanuit MS-oogpunt alvorens ze te gebruiken. Dat gezegd hebbende zoek ik naar een oplossing in plaats van dat ik het zelf waard vind een "klacht"in te dienen. De Gulden Weg zal zoals wel vaker, ergens in het Midden liggen ;)

Door Spiff: Zelf ben ik van mening dat, ondanks het feit dat de zaak zowel Vista als ook XP (en eerdere Windows versies) raakt, het wellicht verstandiger zou zijn om betreffend de aan Microsoft te verzoeken actie Windows Vista en Windows XP te ontkoppelen.

Zou ik niet doen, exact hetzelfde probleem is cross-platform, en omdat het met 100% zekerheid 3 platformen treft is het a] belangrijker en b] makkelijker te diagnosticeren voor MS.

Just my 2 cents.

*: Ik denk dat het handig is eerst nog die 3 dingen uit te zoeken voor je een volledige melding maakt.
Het alternatief is melden dat het certificaat niet klopt in Vista en daarmee basta -> laat MS het maar uitzoeken.

21-05-2014, 19:42 door [Account Verwijderd] - Bijgewerkt: 21-05-2014, 21:21

Een mooie sammenvating van Anoniem, cluc-cluc, 13:11 uur

Alleen het volgende:

Door Anoniem cluc-cluc op 21-05-2014 13:11 :
8. Wij hebben de indruk dat er met update KB2868626 in XPSP3 door Microsoft een belangrijke stap voorwaarts is gezet
met het herkennen van SHA2 in XPSP3,

Hierbij vraag ik mij af: KB2868626 is niet alleen een update voor XPSP3 maar ook voor andere Windows versie (onder andere Windows Vista en Windows 7). Kun je het hier dan wel alleen over XPSP3 hebben?

Overigens ben ik het eens met wat Spiff in zijn reactie op 21-05-2014 om 14:13 schrijft (2de punt).

bijgewerkt

De reactie van Anoniem , cluc-cluc 21-05-2014 17:59 was om 19:42 nog niet zichtbaar.

Overigens wat Anoniem , cluc-cluc in zijn reactie van 21-05-2014 17:59 schrijft, is ook wel weer een punt.

21-05-2014, 20:57 door W. Spu - Bijgewerkt: 21-05-2014, 21:04

Door Spiff:
Heb je Microsoft ook naar deze thread op Security.nl verwezen?

Ja zowel aan Microsoft Nederland als vandaag aan de engineer in de US. Ik denk echter dat dit forum een beetje moeilijk te lezen is voor de engineer in de US. Vanmiddag kregen we nog de melding dat ze het probleem nog niet hebben kunnen reproduceren en de vraag of het probleem speelt op alle computers. We hebben gereageerd dat het probleem speelt (en niet alleen bij ons) op XP, Vista (Home user + Enterprise) en Windows Server 2003 R2 en dat het gemakkelijk gereproduceerd kan worden op een schone installatie van Windows Vista zoals we zelf gedaan hebben op een virtuele computer.

21-05-2014, 23:19 door Anoniem

19:42 door kraai: Hierbij vraag ik mij af: KB2868626 is niet alleen een update voor XPSP3 maar ook voor andere Windows versie (onder andere Windows Vista en Windows 7). Kun je het hier dan wel alleen over XPSP3 hebben?

Klopt, KB2868626 bestaat inderdaad ook voor andere Windows versies.
Maar de implementatie van KB2868626 in XPSP3 lijkt als neveneffect iets extra's toe te voegen. In Vista (en de andere windows versies) merk je geen verschil als je KB2868626 toevoegt of verwijdert. Echter in XPSP3 heel duidelijk wel.
Vandaar dat ik het dus over KB2868626 in XPSP3 heb. (Zie ook reactie 14-05-2014, 12:39 door anoniem cluc-cluc:

waar dit op lijkt (een voorzichtige conclusie dus), is dat update KB2868626 voor XPSP3 naast het verhelpen
van de D.o.S. vulnerability óók stilzwijgend extra functionaliteit toevoegt om sha2 te ondersteunen.

Bij XPSP3 is er nl. totaal niets van een digitale handtekening van EMET4.1update 1 te bespeuren als KB2868626 niet is geïnstalleerd. Pas na installatie van KB2868626 in XPSP3 zie je deze handtekening met sha256 verschijnen zoals in Windows Vista. Doch in Vista is deze digitale handtekening altijd aanwezig, en ziet hij er ook steeds hetzelfde uit.
(maakt in Vista voor de zichtbaarheid van de digitale handtekening dus niet uit of KB2868626 wel of niet geïnstalleerd is)

19:09 door Anoniem: Just my 2 cents.

Alle beetjes helpen. We hoeven het niet volledig met elkaar eens te zijn, maar het is absoluut welkom en van waarde.

19:09 door Anoniem: Daarnaast is dit geen kritiek veiligheidsprobleem

Voor dit ene specifieke geval met EMET4.1update1 kwamen wij er samen best wel uit. No big deal, inderdaad.
Maar hoe controleer jij op een Vista/XP-systeem nu de integriteit van een willekeurig aangeleverd bestand met een sha256 ondertekening als Vista/XP het verschil niet meer kan maken tussen een geldige handtekening en een ongeldige handtekening? Hoe kun je dan zonder extra middelen nog eenvoudig zeker weten dat er niet met het bestand is geknoeid of malware is geïnjecteerd?!...

En nu komt het*:
D] Zijn er meer SHA-256 certificaten van andere CA's te vinden? Hebben die hetzelfde probleem?
E] Geldt het voor de gehele SHA-2 familie?
F] Geldt het voor webcertificaten?

Verwacht ik eerlijk gezegd met alle informatie die we tot nu toe hebben verzameld niet direct wereldschokkende dingen van, maar zou ik beslist ook niet nalaten als het simpel is na te trekken. Vooral punt D].
Weet iemand waar zo'n bestand beschikbaar is?
Mvg, cluc-cluc

22-05-2014, 00:04 door Spiff has left the building

Dankjewel W. Spu, cluc-cluc, Anoniem 19:09, en _kraai__, voor jullie reacties sinds mijn post van 14:16 uur.

D, E en F van Anoniem 19:09 zijn ook interessante aandachtspunten.
Heeft iemand inzicht daarin, antwoorden daarop? Of hoe zoeken we dat nog uit?

Ik wacht nog even af of wellicht ook Erik van Straten, Eric-Jan H te A, Fwiffo, Ilja. _V V, of anderen nog reageren en commentaren leveren op cluc-clucs stuk van 13:30 uur, en/of op de daaropvolgende reacties.

Besluiten we dat we nog onderzoek moeten doen naar de aandachtspunten D, E en F van Anoniem 19:09, dan moet dat nog volgen.

Zijn die drie punten D, E en F van Anoniem 19:09 ook uitgezocht,
en zijn vervolgens ieders commentaren, aanvullingen en wijzigingssuggesties binnen, dan hoop ik dat we het vervolgens eens kunnen worden over een verslag.
Ik weet niet of dat zo beknopt mag/moet zijn als het stukje van Erik van Straten van 12-05-2014, 22:51 uur (https://www.security.nl/posting/386805#posting387782), of zo uitgebreid als het stuk van cluc-cluc van vandaag 20-05-2014, 13:11 uur (https://www.security.nl/posting/386805#posting388752) plus bijgesteld naar aanleiding van de daaropvolgende reacties, maar ik hoop in ieder geval dat we iets gezamenlijks kunnen samenstellen waar iedereen zich in kan vinden.
Het samen kunnen bewerken van zo'n stuk zou handig zijn, maar dat is geen optie. Maar misschien lukt het ondanks dat toch om een gezamenlijk stuk vorm te geven.

Is het samen vormgeven van een stuk te moeilijk,
dan pak ik eind van de week of begin volgende week de URL's van de meest relevante posts en de commentaren daarop, zet die onder elkaar, en bied die dan met een kort commentaar aan Microsoft Nederland. Ik mag aannemen dat Microsoft daar uit moet kunnen komen.

Ten slotte nog een reactie specifiek op de post van W. Spu van 20:57 uur,

Door Spiff:
Heb je Microsoft ook naar deze thread op Security.nl verwezen?

Door W. Spu, 20:57 uur:
Ja zowel aan Microsoft Nederland als vandaag aan de engineer in de US.

Mooi.
Wanneer is het dat je Microsoft Nederland naar deze thread op Security.nl hebt verwezen?
Voor of na do.15-05-2014? Dat was de dag dat ik de bijdrage van Erik van Straten van 12-05-2014, 22:51 uur, in het startbericht heb geplaatst, wat al een hoop inzicht zou moeten geven.

Door W. Spu, 20:57 uur:
Ik denk echter dat dit forum een beetje moeilijk te lezen is voor de engineer in de US.

Dat lijkt me beslist.
Dat is waarom ik de materie via Microsoft Nederland wilde aankaarten, zodat die de boel kan bekijken, hier zo nodig vragen kan stellen, en vervolgens de boel intern kan doorzetten.

22-05-2014, 04:29 door Ilja. _V V

Ok, even snel & smerig:

We zijn ver gekomen. Niemand uitgezonderd.

Heel simpel: Als ik de emet*.msi open in XP, 2K3, Vista (waarschijnlijk 2K8 - Geen informatie beschikbaar) krijg ik (je) als 1ste een venster met een rood schild, & als je bereid bent om te lezen, dan blijkt dat de uitgever van het certificaat niet bekend is.

Een goede reden om het certificaat te controleren, maar:

Dat kan je, of niet.

Soms is het maar een "glitch" - een "schuifer" - & na het opnieuw downloaden moet het meestal wel in orde zijn. Niet in dit geval.

Kan je dat dan nog niet: Gooi het bestand gewoon weg! Niet meer naar omkijken...

Kan je het certificaat wel controleren, dan kan je een beslissing nemen. Bv: De datum is verlopen. Doet niets af aan de integriteit van het bestand noch het certificaat. Komt uit betrouwbare bron, etc... Even VirusTotal checken... Verstandig...

In dit specifieke geval, bijvangst daargelaten, gaat het om een gerenommeerde beveiligingstool, welke het's effectiviteit alom al heeft bewezen.

Daar gaat het mis op het punt dat de gebruiker ultiem moet vertrouwen: Het certificaat.

Daarmee blijkt het mis te gaan op verschillende punten in de genoemde besturingssystemen, alhoewel de uitgever - Microsoft - bij de gebruiker, doorgaans, bekend is.

Zover ik dit onderwerp, met toch wel genoegen, gelezen heb, begrijp ik dat de authenticode een oorzaak lijkt te zijn.

Ondertussen blijkt echter uit mijn eigen testen zoals hierboven beschreven, maar ook opnieuw met Hitman Pro, dit:

Op Windows 7 geen meldingen.
Op systemen lager dan Windows 7 - dus Vista, etc... - kreeg ik eerst 14 verdachte meldingen, net alvorens dit te schrijven nog eens getest, nu nog steeds 10 meldingen. Waarbij opmerkelijk is dat Emet_Agent.exe de ene scan wel & de andere niet, word gemotiveerd met "ongeldige handtekening". Bovendien staan er 2 grijze blokjes naast, de 1ste met een getal, de 2de met de tekst "RUN". ??? Geen idee wat Hitman Pro daarmee bedoeld. Ook is het me op hetzelfde systeem overkomen dat Hitman Pro gisteren even voor middernacht opeens maar 6 verdachte bestanden vond, waaronder weer de Emet_Agent...
(Log-bestanden beschikbaar)

Ongeacht alle technische problemen & (voor-)veronderstellingen: Een certificaat moet je gewoon kunnen vertrouwen.

Complete bedrijven zijn failliet gegaan, o.a. Diginotar, omdat certificaten niet in orde waren, met wereldwijde gevolgen, HeartBleed vers in het geheugen, & zelfs Microsoft heeft op dat punt pas op de plaats moeten maken & heeft de eigen certificaten in moeten trekken & vernieuwen!...

Beetje venijn naar Microsoft, zeker als die het echt verkeerd doet, zal zeer zeker gewaardeerd worden!...

Ilja. _\\//

22-05-2014, 09:07 door W. Spu

Microsoft is voor en na de 15e verwezen naar deze thread en daarna is de case door gezet naar één van de engineers in Verenigde Staten die ook op deze thread gewezen is...

22-05-2014, 09:57 door Spiff has left the building

Door W. Spu, 09:07 uur:

Microsoft is voor en na de 15e verwezen naar deze thread en daarna is de case door gezet naar één van de engineers in Verenigde Staten die ook op deze thread gewezen is.

Hoe is de situatie nu precies?
Jij hebt contact opgenomen met Microsoft Nederland, en daarbij verwezen naar deze thread, begrijp ik. Net als ik eerder, maar nu in een stadium dat er inmiddels veel meer informatie en een redelijke duidelijkheid beschikbaar is.
Bijzonder jammer dat Microsoft Nederland dan niet heeft gereageerd in deze thread, we hadden dan waarschijnlijk direct alle relevante vragen kunnen beantwoorden.

En op een gegeven moment heeft Microsoft Nederland de case doorgezet naar een van de engineers in de Verenigde Staten, of jij? En heeft Microsoft Nederland de engineer in de Verenigde Staten gewezen op deze thread, of jij?
Als het Microsoft Nederland is die de case heeft doorgezet naar een engineer in de Verenigde Staten, en het zou zo zijn dat Microsoft Nederland daarbij geen goede beschrijving en analyse van het probleem in het Engels heeft gegeven (dat meen ik te begrijpen uit je post van gisteren, 20:57 uur), maar slechts of voornamelijk heeft gewezen op deze thread, dan snap ik daar helemaal niks van. De Engelstalige engineer zal nóóit raad weten met deze Nederlandstalige thread.

Heb jij zelf nu contact met de Microsoft engineer in de Verenigde Staten?
Dat zou best gunstig kunnen zijn, mits we die dan de relevante informatie kunnen aanreiken.

Lukt het je misschien om op basis van het stukje van Erik van Straten van 12-05-2014, 22:51 uur (https://www.security.nl/posting/386805#posting387782) plus het stuk van cluc-cluc van gisteren 20-05-2014, 13:11 uur (https://www.security.nl/posting/386805#posting388752) (plus de daaropvolgende reacties) om de Microsoft engineer in de Verenigde Staten van alle relevante informatie te voorzien?

Indien niet, wat heb je daarvoor nodig? Een goed overzicht in het Engels?

Indien je dat nodig hebt, dan heeft het prioriteit dat we hier in deze thread snel tot consensus komen over wat er in het aan Microsoft aan te leveren overzicht moet staan, en dat we vervolgens een Engelstalig stuk kunnen formuleren.

22-05-2014, 09:57 door Anoniem

On behalf of the security.nl community to our english speaking friends:

Take some notice that the original subject-title of this thread can be misleading.
There is actually no problem at all with the certificates here.
The certificate-chain in the digital signature of EMET4.1 update1.msi has proven to be just fine.

But we found that the actual problem merely is caused by difficulties in the reading of digital signatures using sha256
by older Windows systems, like Vista, XP SP3 and (as we 've heard) also Windows 2003 Server.
This probably causes the annoying errors in the digital signature of the EMET4.1 update1.msi file.
(open the "digital signature"-tab in "Properties", and check the details)
Remarkable is also that no "countersignature" is showing up in "fully patched" Vista or XP (SP3) systems.

For now (as far as we from the security.nl community can see) this phenomenon is most likely caused by
a different Authenticode structure in case sha256 has been used.
Such structures seem to be incorrectly interpreted by the Vista/XPSP3/Server 2003 parsers during the verify/trust proces resulting in a rejection of the digital signature, and sometimes in rejection of a certificate.
So this is the actual thing which should be further investigated (and hopefully fixed) by Microsoft,
as it is a security risk if systems cannot make a difference any more between a "good" and a "bad"
digital signature if sha256 certificates are being used...

(this "misinterpretation" might also be the cause that analyzing tools like AnalyzePESig or Hitman Pro (possibly
using parts of the same windows verifying system?!...) almost jump into "tilted" mode generating all kinds of errors...)

22-05-2014, 10:48 door Fwiffo

Door Spiff: In reactie op Anoniem, cluc-cluc, 13:11 uur,

Hartelijk dank voor de mooie samenvatting plus tevens oproep aan Microsoft.

Alvorens ik vervolgens Microsoft hierop ga attenderen door een telefonische verwijzing plus plaatsen op en verwijzen via de Nederlandstalige Microsoft Community (answers.microsoft.com), eerst nog even deze twee punten:

1.
Hebben de andere bijdragers in deze thread (Erik van Straten, Eric-Jan H te A, Fwiffo, Ilja. _V V, _kraai__, W. Spu, anderen) mogelijk nog commentaren op, dan wel wijzigingsvoorstellen bij cluc-clucs samenvatting plus oproep?
Zo ja, geef dan graag zo nauwkeurig mogelijk aan welk deel van cluc-clucs bijdrage je zou willen veranderen en/of zou willen aanvullen en graag tevens ook woordelijk hoe of wat.

Ik ben het eens met de technische inhoud van de post van cluc-cluc, maar ben het ook eens met 'Gisteren, 19:09 door Anoniem' over de 'toon'. Microsoft hoeft namelijk helemaal niets. Bovendien hebben ze eigenlijk wel een punt met het afstappen van SHA-1. Zie:
http://blogs.technet.com/b/srd/archive/2013/11/12/security-advisory-2880823-recommendation-to-discontinue-use-of-sha-1.aspx
http://blogs.technet.com/b/msrc/archive/2013/11/12/authenticity-and-the-november-2013-security-updates.aspx.

Laten we na al het Snowden geweld ook Flame niet vergeten dat MD5 wist aan te vallen:
https://www.security.nl/posting/36723/Flame+besmet+computers+via+Windows+Update

Ik zou heel graag zien dat mijn Vista installatie tot het einde de best mogelijke beveiliging heeft, zelfs ten koste van XP. Maar zolang ik ermee kan internet bankieren en e-mailen ben ik al heel tevreden. Dus hoe de uitkomst ook wordt, ik blijf bij Windows Vista zolang er support op zit. Maar ik wens iedereen in deze draad succes met hun acties en ben dankbaar of dit nu uiteindelijk resultaten geeft of niet.

22-05-2014, 10:57 door tonykrij

Ik weet niet wie er verder van Microsoft Nederland is gevraagd om naar deze thread te kijken maar ik kreeg vannacht pas een verzoekje binnen van @Ilja om er eens naar te kijken. Als iemand mij kan doorgeven welke andere collega's benaderd zijn dan kan ik wel navragen of ze hier nog naar hebben gekeken. Zoals @Spiff ook al zegt lijkt me op dit moment een hoop bekend. Ik zit niet vaak op dit forum maar feel free om me de volgende keer een berichtje te sturen, tx! Tony (Microsoft Nederland).

22-05-2014, 11:23 door Spiff has left the building - Bijgewerkt: 22-05-2014, 14:13

Door tonykrij, 10:57 uur:
Ik weet niet wie er verder van Microsoft Nederland is gevraagd om naar deze thread te kijken maar ik kreeg vannacht pas een verzoekje binnen van @Ilja om er eens naar te kijken.
Als iemand mij kan doorgeven welke andere collega's benaderd zijn dan kan ik wel navragen of ze hier nog naar hebben gekeken.

Hai Tony,
Dankjewel voor je reactie.

Ikzelf heb op 7 mei gebeld met Microsoft Nederland en het probleem kort uiteengezet en Microsoft naar deze thread verwezen. (N.B. Dat was met de inzichten van dat moment, en dus ruim vóór het tussentijds samenvattende stukje van Erik van Straten van 12-05-2014, plus het stuk van cluc-cluc van gisteren 20-05-2014, plus de daaropvolgende reacties.)

Microsoft Nederland gaf op 7 mei aan mijn attendering door te zetten naar de betreffende afdeling of medewerkers, maar er is me daarbij geen specifieke afdeling of naam genoemd.

Door tonykrij, 10:57 uur:
Zoals @Spiff ook al zegt lijkt me op dit moment een hoop bekend.

Heb je/ heeft Microsoft voldoende aan het eerdere tussentijds samenvattende stukje van Erik van Straten van 12-05-2014, 22:51 uur (https://www.security.nl/posting/386805#posting387782) plus het stuk van cluc-cluc van gisteren 20-05-2014, 13:11 uur (https://www.security.nl/posting/386805#posting388752) plus de daaropvolgende reacties, plús de verduidelijking en samenvatting in het Engels door Anoniem vandaag 22-05-2014, 09:57 uur (https://www.security.nl/posting/386805#posting388857)?

Is er nog aanvullende informatie nodig, vraag het ons, dan kunnen we dat wellicht aanleveren.

Door tonykrij, 10:57 uur:
Ik zit niet vaak op dit forum maar feel free om me de volgende keer een berichtje te sturen, tx!
Tony (Microsoft Nederland).

Dankjewel voor het aanbod.
Hoe kunnen we je in zo'n geval het beste bereiken?

[Bewerking: Aangevuld met een verwijzing naar de bijdrage in het Engels door Anoniem van 09:57 uur.]

22-05-2014, 13:07 door Ilja. _V V

Hee, hallo Tony, da's snel!!! ThnX!...

Spiff: Via het contact-formulier op zijn blog, weet niet hoeveel tekens erin passen: http://blogs.microsoft.nl/blogs/tonykrijnen

22-05-2014, 13:08 door W. Spu

Beste Spiff en/of TonyKrij,

We hebben twee premier support calls geopend bij Microsoft m.b.t. EMET waarvan het certificaat probleem er één van is. In eerste instantie was er contact met Microsoft Nederland en onlangs is de case door gezet naar een collega in de verenigde staten. We hebben nog niet het idee dat Microsoft er van overtuigd is dat het hier NIET om een incident gaat. Contact gaat (mede vanwege het tijdverschil) moeizaam

We hebben nu via mail verzocht of er binnen Microsoft contact gezocht kan worden met TonyKrij.

22-05-2014, 14:04 door Spiff has left the building

@ Anoniem 09:57,
Dankjewel voor de verduidelijking en samenvatting in het Engels, for our English speaking friends.

@ Ilja,
Dankjewel voor de verwijzing naar de blog van Tony Krijnen.
Altijd goed om die contactmogelijkheid achter de hand te hebben.

@ W. Spu,
Mooi dat je via mail verzocht hebt of er binnen Microsoft contact gezocht kan worden met Tony Krijnen.

Ik neem aan dat de aandacht van Tony Krijnen er nu toe gaat leiden dat Microsoft meer duidelijkheid krijgt betreffend deze zaak en er nu werkelijk mee aan de slag kan.
Mijn eerdere voornemen om te gaan posten op Microsoft Community en Microsoft Nederland opnieuw telefonisch te gaan benaderen, dat mag daarmee komen te vervallen.

22-05-2014, 16:58 door W. Spu - Bijgewerkt: 22-05-2014, 17:13

@ Spiff

Ik denk dat het wel verstandig is om zelf (en wellicht ook anderen) contact op te nemen met Microsoft. Tony Krijnen is inmiddels ingelicht maar hoe meer mensen dit probleem melden hoe eerder het probleem serieus genomen en geescaleerd wordt.

22-05-2014, 17:40 door [Account Verwijderd] - Bijgewerkt: 22-05-2014, 17:57

Door Anoniem:

19:42 door kraai: Hierbij vraag ik mij af: KB2868626 is niet alleen een update voor XPSP3 maar ook voor andere Windows versie (onder andere Windows Vista en Windows 7). Kun je het hier dan wel alleen over XPSP3 hebben?

Klopt, KB2868626 bestaat inderdaad ook voor andere Windows versies.
Maar de implementatie van KB2868626 in XPSP3 lijkt als neveneffect iets extra's toe te voegen. In Vista (en de andere windows versies) merk je geen verschil als je KB2868626 toevoegt of verwijdert. Echter in XPSP3 heel duidelijk wel.
Vandaar dat ik het dus over KB2868626 in XPSP3 heb. (Zie ook reactie 14-05-2014, 12:39 door anoniem cluc-cluc:

waar dit op lijkt (een voorzichtige conclusie dus), is dat update KB2868626 voor XPSP3 naast het verhelpen
van de D.o.S. vulnerability óók stilzwijgend extra functionaliteit toevoegt om sha2 te ondersteunen.

Bij XPSP3 is er nl. totaal niets van een digitale handtekening van EMET4.1update 1 te bespeuren als KB2868626 niet is geïnstalleerd. Pas na installatie van KB2868626 in XPSP3 zie je deze handtekening met sha256 verschijnen zoals in Windows Vista. Doch in Vista is deze digitale handtekening altijd aanwezig, en ziet hij er ook steeds hetzelfde uit.
(maakt in Vista voor de zichtbaarheid van de digitale handtekening dus niet uit of KB2868626 wel of niet geïnstalleerd is)

Bedankt dat je me hier nog even op gewezen hebt Anoniem, cluc-cluc, 23:19. Ik had dit namelijk even over het hoofd gezien.

Wat ik in mijn reactie van 21:21 uur schreef is dan niet meer van toepassing.

Door _kraai__ 21:21 uur

Alleen het volgende:

Door Anoniem cluc-cluc op 21-05-2014 13:11 :
8. Wij hebben de indruk dat er met update KB2868626 in XPSP3 door Microsoft een belangrijke stap voorwaarts is gezet
met het herkennen van SHA2 in XPSP3,

Hierbij vraag ik mij af: KB2868626 is niet alleen een update voor XPSP3 maar ook voor andere Windows versie (onder andere Windows Vista en Windows 7). Kun je het hier dan wel alleen over XPSP3 hebben?
.

.

22-05-2014, 17:43 door Erik van Straten

The issue is that Vista (and XP) are unable to evaluate SHA256 based authenticode timestamps. Perhaps I can contribute by proving that EMET is not an incident.

An unrelated, but common factor, appears to be the use of an intermediate time stamping certificate "Microsoft Time-Stamp PCA 2010" with a specific SHA1 thumbprint. Googling for:

2AA752FE64C49ABE82913C463529CF10FF2F04EE site:virustotal.com 2014

currently appears to reliably identify files that have been time stamped using SHA256.

Unfortunately most of those files cannot simply be downloaded from the Microsoft site. However, there are exceptions: http://download.microsoft.com/download/1/6/B/16B06F60-3B20-4FF2-B699-5E9B7962F9AE/VSU4/vcredist_arm.exe (1.4MB) and
http://download.microsoft.com/download/F/B/7/FB728406-A1EE-4AB5-9C56-74EB8BDDF2FF/ENU/x86/ReportViewer.msi (7.5MB).
http://download.microsoft.com/download/7/C/5/7C514257-287C-49A9-BF50-F86BB3D4E60C/1033/x86/PowerPivot_for_Excel_x86.msi (95MB).

I just downloaded these files. All use an SHA256 timestamp that validates correctly under W7. I would be very much surprised if these file's signatures validate correctly in Vista (@Spiff: please check!)

Note: the second file was reported before in this thread on 09-05-2014, 12:35 by "cluc-cluc". The original reporter (see http://stackoverflow.com/questions/21930249/digital-signature-timestamp-not-available-on-xp-vista-causing-verification-fa) stated that the signing certificate had expired (which complicates matters for people who don't understand authenticode). However, ReportViewer.msi I just downloaded was signed with a certificate that has not yet expired. Hence all three files should exhibit the same signature validation behavior as EMET 4.1 Update 1.

To confirm that EMET 4.1 Update 1 still exhibits the same behavior, I just downloaded http://download.microsoft.com/download/7/A/A/7AA570E7-92DF-4C28-BE12-E72831797666/EMET%20Setup.msi and can confirm that it still is the same file (i.e. also uses an SHA256 timestamp).

22-05-2014, 18:14 door Anoniem

Door Anoniem (cluc-cluc) op 21-5 @ 23:19

19:09 door Anoniem: Just my 2 cents.

Alle beetjes helpen. We hoeven het niet volledig met elkaar eens te zijn, maar het is absoluut welkom en van waarde.

Ik ben het helemaal met je eens ;)

Door Anoniem (cluc-cluc) op 21-5 @ 23:19

19:09 door Anoniem: Daarnaast is dit geen kritiek veiligheidsprobleem

Voor dit ene specifieke geval met EMET4.1update1 kwamen wij er samen best wel uit. No big deal, inderdaad.
Maar hoe controleer jij op een Vista/XP-systeem nu de integriteit van een willekeurig aangeleverd bestand met een sha256 ondertekening als Vista/XP het verschil niet meer kan maken tussen een geldige handtekening en een ongeldige handtekening? Hoe kun je dan zonder extra middelen nog eenvoudig zeker weten dat er niet met het bestand is geknoeid of malware is geïnjecteerd?!...

Een gebrek aan veiligheidsmeldingen zou een zeer ernstig probleem zijn, het krijgen van een (incorrecte) melding is niet direct te misbruiken voor malversaties, vandaar mijn poging tot het aanbrengen van nuance (en verwachtingen) in de categorie "kritiek."

Het valideren van een bestand kan op meerdere manieren, het certificaat is het snelst en makkelijkst. Dat andere opties niet aan de gemiddelde eindgebruiker besteed zijn geef ik direct toe, vandaar ook mijn meedenken in dit topic, maar is een (grondige) certificaat-controle zelf dat dan wel??? En als iemand al een controle uitvoert, ligt Virustotal dan niet het meest voor de hand (tabje "bestandsgegevens")?
Niet om het een of ander, buiten Spiff heb ik hier niemand melding van horen/zien maken ondanks dat EMET wereldwijd gebruikt wordt door duizenden (miljoenen?) mensen. Daarbij is als gevolg van zijn observatie naar voren gekomen dat dit een cross-platform probleem is en van toepassing is op alle SHA-256 certificaten van deze MS-CA. Kwadratische cudo's voor Spiff dus!
Noot: Systeembeheerders die Server-Vista-XP-systemen beheren gebruiken vrijwel altijd een ander systeem om updates binnen te halen / uit te rollen op het interne netwerk, dus niet gelijk denken dat het wel héél triest gesteld is ^_^

Door Anoniem: On behalf of the security.nl community to our english speaking friends: ...
&
(this "misinterpretation" might also be the cause that analyzing tools like AnalyzePESig or Hitman Pro (possibly
using parts of the same windows verifying system?!...) almost jump into "tilted" mode generating all kinds of errors...)

Geniaal & AnalyzePESig gebruikt volgens mij juist andere input (calls, hooks, etc.), maar uiteindelijk wordt het wel tegen dezelfde lamp (certificaten-lijst) gehouden natuurlijk. Vandaar ook mijn eerdere advies om e.e.a nog net even wat dieper uit te graven. Ik vind het in ieder geval een prachtige samenvatting waar MS zeker wat mee moet kunnen!

Door Fwiffo:Ik ben het eens met de technische inhoud van de post van cluc-cluc, maar ben het ook eens met 'Gisteren, 19:09 door Anoniem' over de 'toon'. ...
&
Ik zou heel graag zien dat mijn Vista installatie tot het einde de best mogelijke beveiliging heeft, zelfs ten koste van XP. Maar zolang ik ermee kan internet bankieren en e-mailen ben ik al heel tevreden. Dus hoe de uitkomst ook wordt, ik blijf bij Windows Vista zolang er support op zit. Maar ik wens iedereen in deze draad succes met hun acties en ben dankbaar of dit nu uiteindelijk resultaten geeft of niet.

Iets met de oude vertrouwde Gulden, een poldermodel en de weg in het midden :) Bedankt voor je bijdrage vanuit het perspectief van security-bewuste eindgebruiker, leuk om te lezen maar "ten koste van" is wel een beetje evil hoor ;)

Door tonykrij: Zoals @Spiff ook al zegt lijkt me op dit moment een hoop bekend. Ik zit niet vaak op dit forum maar feel free om me de volgende keer een berichtje te sturen, tx! Tony (Microsoft Nederland).

Fijn om te lezen dat (de!) Tony Krijnen aandacht aan dit topic besteed!
Slimme zet van Ilja. _V V ook :)

Maar nu hoop ik natuurlijk wel dat het ook écht opgepakt wordt door MS, het liefst voor alle platformen ;)

22-05-2014, 18:14 door Spiff has left the building

Door W. Spu:
Ik denk dat het wel verstandig is om zelf (en wellicht ook anderen) contact op te nemen met Microsoft. Tony Krijnen is inmiddels ingelicht maar hoe meer mensen dit probleem melden hoe eerder het probleem serieus genomen en geëscaleerd wordt.

Ik wil even afwachten wat Tony Krijnens mening daarover is.
Als er hier al langs één of twee kanalen contact is met Microsoft, dan weet ik niet of een derde kanaal daar wat aan toevoegt. Nogmaals, ik wil graag even weten hoe Tony Krijnen daar tegenaan kijkt.
Daarnaast is mijn kennis betreffend de materie beperkt, ook om die reden zou contact via Tony Krijnen via deze thread wellicht de voorkeur hebben, zodat anderen met meer kennis van zaken dan ik antwoorden kunnen formuleren.

22-05-2014, 18:25 door Spiff has left the building - Bijgewerkt: 22-05-2014, 22:41

Door Erik van Straten, 17:43 uur:

http://download.microsoft.com/download/1/6/B/16B06F60-3B20-4FF2-B699-5E9B7962F9AE/VSU4/vcredist_arm.exe (1.4MB) and
http://download.microsoft.com/download/F/B/7/FB728406-A1EE-4AB5-9C56-74EB8BDDF2FF/ENU/x86/ReportViewer.msi (7.5MB).
http://download.microsoft.com/download/7/C/5/7C514257-287C-49A9-BF50-F86BB3D4E60C/1033/x86/PowerPivot_for_Excel_x86.msi (95MB).

I just downloaded these files. All use an SHA256 timestamp that validates correctly under W7. I would be very much surprised if these file's signatures validate correctly in Vista
(@Spiff: please check!)

[...]
To confirm that EMET 4.1 Update 1 still exhibits the same behavior, I just downloaded http://download.microsoft.com/download/7/A/A/7AA570E7-92DF-4C28-BE12-E72831797666/EMET%20Setup.msi and can confirm that it still is the same file (i.e. also uses an SHA256 timestamp).

I checked.
As expected:
None of those files' signatures validate correctly in Vista SP2 x86.

22-05-2014, 22:51 door Anoniem

Confirmed here on XP SP3 also: same issue with the files Erik mentioned at 17:43.

I 've been thinking what could possibly go wrong causing such a "weird countersignature/timestamp behaviour".
Many causes are possible. I'm aware things can be complicated. But my first two suggestions would be:

1. sha256 hashes are longer than sha1. Could this here be causing some unforeseen bufferoverflow somewhere?
2. I noticed these "problemsignatures" contain some countersignature (timestamp) -related OID: 1.3.6.1.4.1.311.3.3.1
This OID is NOT defined in: http://support.microsoft.com/kb/287547 (outdated list or not?...)
But this one is present in the list: SPC_TIME_STAMP_REQUEST_OBJID = 1.3.6.1.4.1.311.3.2.1
So almost the same OID-number. Almost... Might be worth checking.

Anyway: in my opinion it's up to Microsoft's software engineers now.
(I will still monitor this thread for some time, but less intensive and consider it solved) ;-)

cheers and good luck,
cluc-cluc

23-05-2014, 19:32 door Spiff has left the building

Door Anoniem, gisteren, do.22-05-2014, 18:14 uur:
Niet om het een of ander, buiten Spiff heb ik hier niemand melding van horen/zien maken ondanks dat EMET wereldwijd gebruikt wordt door duizenden (miljoenen?) mensen.

Wat bedoelde je precies?
Binnen of buiten deze thread?
In deze thread is het voor Vista ook bevestigd door Fwiffo en door W. Spu, en voor XP door cluc-cluc en door Ilja. Zie ik mogelijk nog iemand over het hoofd?
Buiten deze thread heeft W. Spu het gemeld op Microsoft TechNet forums.
Mogelijk zijn er inmiddels elders meer meldingen, maar hebben we die niet gevonden met de door ons gebruikte zoektermen. Maar je hebt wel gelijk, het is opvallend dat we niet meer meldingen hebben gevonden.

23-05-2014, 21:13 door Fwiffo

Door Anoniem:Niet om het een of ander, buiten Spiff heb ik hier niemand melding van horen/zien maken ondanks dat EMET wereldwijd gebruikt wordt door duizenden (miljoenen?) mensen.

Ik heb nog wat gevonden, waarschijnlijk buiten Nederland, op het Avast forum. Iemand constateert het probleem met de digitale handtekening en iemand anders reageert daarop dat dit bij hem ook zo is onder XP maar niet onder 7: http://forum.avast.com/index.php?topic=149749.0. Dus het is niet alleen een probleem van lezers van security.nl. Als dit wel zo was dan zouden we moeten uitzoeken wat Spiff, ik, W. Spu, Ilja en cluc-cluc gemeen hebben. Een provider ofzo of een bepaalde manier van onze firewall configureren.

Een mogelijke verklaring is dat buiten Nederland niet zoveel gebruik van forums wordt gemaakt en dat mensen daar geen digitale handtekeningen controleren en het dus niet opmerken. Zoals Spiff al eerder vermelde, EMET werkt gewoon onder Vista als je de melding bij het installeren en het openen van de GUI negeert.

23-05-2014, 22:37 door Anoniem

Door Spiff:

Door Anoniem, gisteren, do.22-05-2014, 18:14 uur:
Niet om het een of ander, buiten Spiff heb ik hier niemand melding van horen/zien maken ondanks dat EMET wereldwijd gebruikt wordt door duizenden (miljoenen?) mensen.

Wat bedoelde je precies?

Wat er letterlijk staat, al is communicatie van meer afhankelijk dan alleen de verzendende partij ;)

Binnen of buiten deze thread?

Overal, alle andere topics zijn gelinkt of een gevolg van deze voor zover ik kan beoordelen.

In deze thread is het voor Vista ook bevestigd door Fwiffo en door W. Spu, en voor XP door cluc-cluc en door Ilja. Zie ik mogelijk nog iemand over het hoofd?

Het gaat om wie het probleem het eerst vond! Reproduceren kan iedereen, iets vinden getuigt in dit geval van des te meer gezond wantrouwen en een strikte persoonlijke policy mbt pc-gebruik en dat vind ik mooi om te zien.

Maar je hebt wel gelijk, het is opvallend dat we niet meer meldingen hebben gevonden.

Zie dat dus maar als een compliment!

23-05-2014, 23:38 door Spiff has left the building

Door Anoniem, 22:37 uur:
Het gaat om wie het probleem het eerst vond! Reproduceren kan iedereen, iets vinden getuigt in dit geval van des te meer gezond wantrouwen en een strikte persoonlijke policy mbt pc-gebruik en dat vind ik mooi om te zien.
[...]
Zie dat dus maar als een compliment!

Okee, ik begrijp wat je bedoelt, dankjewel.
Maar uiteraard verdienen beslist ook al de andere bijdragers complimenten, voor hun vasthoudendheid en grondig meedenken en analyse.

En nu maar eens afwachten of Tony Krijnen ons na het weekend al wat positiefs kan vertellen over hoe een en ander hopelijk inmiddels door Microsoft geanalyseerd en opgepakt wordt.

24-05-2014, 11:27 door Anoniem

22-05-2014, 18:14 door Anoniem: Een gebrek aan veiligheidsmeldingen zou een zeer ernstig probleem zijn, het krijgen van een (incorrecte) melding is niet direct te misbruiken voor malversaties, vandaar mijn poging tot het aanbrengen van nuance (en verwachtingen) in de categorie "kritiek."

Met alle respect, maar ik denk dat je je op dit punt vergist.
Een waarschuwingslampje dat altijd aan is, vertelt je net zoveel als een lampje dat altijd uit is,
namelijk HELEMAAL NIETS. En zoals het nu lijkt, heb je bij bestanden die met sha256 zijn ondertekend
(al dan niet alleen bij MS CA's) in Vista/XP zo'n "waarschuwingslampje dat altijd aan is".
Dit is een onveilige situatie voor dit type bestanden, en de policy is dat er in rap tempo steeds meer van gaan komen.

De authenciteit (afkomst) mag in Vista/XP dan misschien nog kloppen (de certificaatketen in het certificaatpad
laat immers geen errors zien...) maar de integriteit is met deze error twijfelachtig: er kan malware geïnjecteerd zijn,
die er voor gaat zorgen dat er data gecompromiteerd kan worden zonder dat je daar verder meteen iets van merkt.
Ook zou je hele systeem via zulke malware stilzwijgend op afstand overgenomen kunnen worden.
Zulke zaken vallen in de "security rating" van Microsoft onder "Critical".
Zie http://technet.microsoft.com/en-us/security/gg309177.aspx

Wat jij voorstelt is een "workaround". En tot op zekere hoogte kan dat voldoende werken.
Tot zover ben ik het best wel met je eens. Maar zoiets is omslachtig en heeft zijn beperkingen.
Bijvoorbeeld vertrouwelijke gesigneerde Excel-bestanden ga je liever niet uploaden naar virustotal.
Tenzij jij virustotal volkomen vertrouwt, en meent dat al je geuploade data daar veilig is, en nooit
in handen van derden (of eigenlijk: vierden) kan komen door een hack, of door een commerciële overname
etc. van virustotal... ;) En wat moet iemand doen zonder internetaansluiting met zo'n bestand op CD/DVD?...

Ook al heb ik de woorden "kritische fout" niet gebruikt, ik blijf van mening dat het daar op zijn minst wél naar neigt.
Wel heb ik het een "basaal gebrek" genoemd. En ook dat het "onprofessioneel kan overkomen":
zoiets behoort gewoon goed te functioneren. Vooral in een security-tool.
Het is een basisbeginsel. Net zoals de bel of het slot op je fiets, en het oliedruklampje in je auto.
Je hebt niets aan een oliedruklampje dat bijvoorbeeld altijd aangaat als jij uit extra veiligheidsoverwegingen je verlichting overdag inschakelt of zo... Slaat gewoon nergens op als zoiets gebeurt!
(dat er massa's mensen domweg stug doorrijden als een goed functionerend oliedruklampje gaat branden
met het risico dat ze dan de hele motor in de soep draaien, dát is weer een hele andere kwestie...)

De "toon" van mijn samenvatting van 21-05-2014, 13:11 mag dan misschien wat streng klinken, maar ik maak geen onredelijke of al te heftige verwijten: ik consteer, en geef Microsoft nu een kans om het op te lossen, en help Microsoft hier juist mee om een misschien toch wat onprofessioneel aandoende "blunder" (namelijk een security-fout in een stuk software dat de security juist zou moeten bevorderen...) te herstellen, zodat MS zichzelf weer goed in the picture kan neerzetten. Zelf noem ik het liever "zakelijk, duidelijk en rechtvaardig".

En verder: stand up for your rights, en laat je niet kisten.
Mvg, cluc-cluc.

24-05-2014, 14:19 door Anoniem

;-)
"Ik durf het bijna niet op te merken, mag ik 'even' ? … … …

Door Spiff:

Okee, ik begrijp wat je bedoelt, dankjewel.
Maar uiteraard verdienen beslist ook al de andere bijdragers complimenten, voor hun vasthoudendheid en grondig meedenken en analyse.

Free service met een knipoog : de 'special thanks' aan betrokkenen 'even' gespecificeerd voor je

• Algemeen tussen-klassement bij "Recordpoging-security.nl-topic-'balletje'- hooghouden" (za 24 mei 2014 13:33 )

Reactie klassement score

1. Spiff - 68 reacties (multivoudig recordhouder)
2. _kraai__ - 17 reacties
2. Erik van Straten - 17 reacties
3. Ilja. _V V - 11 reacties
4. Fwiffo - 8 reacties
5. Eric-Jan H te - 5 reacties
6. W. Spu - 5 reacties
7. tonykrij - 1 reacties
Buitenbeentje is Anoniem met 40 Reacties

Totaal 172 reacties
Reacties en topic starter +1 maakt 173 Reacties

• Huidige Vermoede record houder topic reacties
In Computerbeveiliging
"Gebeld door Windows service centre"
179 Reacties

• Spannend op velerlei fronten!
Wie gaat er winnen, wie komt er met het verlossende antwoord?
We wachten met spanning af!

Gingen topics maar vaker met zoveel enthousiasme en betrokkenheid zo de diepte in!

:-) Stamp,stamp,stamp, hit those keys! We want more! We want more! (-:

24-05-2014, 15:18 door Spiff has left the building - Bijgewerkt: 24-05-2014, 15:19

@ Anoniem 14:19 uur,
Haha, dankjewel voor je uitgebreide specificatie van de bijdragen :-)
En ja, Anoniem is inderdaad een buitenbeentje, een mystery guest met meervoudige persoonlijkheid.
Een deel van de eerdere Anonieme bijdragen was van wie later gingen posten als _kraai__ en W. Spu, een flink deel van de Anonieme bijdragen is van Anoniem cluc-cluc, en daarnaast zijn er nog een aardig aantal ware Anonieme bijdragen van echte mystery guests. Special thanks aan allen.
En nu maar eens zien of Microsoft de kopende week de teller gaat doen oplopen met een of meer mooie bijdragen.

25-05-2014, 15:59 door Spiff has left the building

Opvallend:
Voor EMET 5.0 Technical Preview 3
https://connect.microsoft.com/emet/Downloads/DownloadDetails.aspx?DownloadID=53108
is weer gebruik gemaakt van SHA1, net zoals voor de eerdere EMET 4.0 en 4.1 en EMET 5.0 Technical Preview 1,
maar anders dan voor de recente EMET 4.1 Update 1 en EMET 5.0 Technical Preview 2, waarvoor SHA256 is gebruikt.
De ondertekening van de EMET 5.0 Technical Preview 3 wordt onder Vista dus weer correct gevalideerd.

25-05-2014, 21:11 door [Account Verwijderd]

Door Spiff: Opvallend:
Voor EMET 5.0 Technical Preview 3
https://connect.microsoft.com/emet/Downloads/DownloadDetails.aspx?DownloadID=53108
is weer gebruik gemaakt van SHA1, net zoals voor de eerdere EMET 4.0 en 4.1 en EMET 5.0 Technical Preview 1,
maar anders dan voor de recente EMET 4.1 Update 1 en EMET 5.0 Technical Preview 2, waarvoor SHA256 is gebruikt.
De ondertekening van de EMET 5.0 Technical Preview 3 wordt onder Vista dus weer correct gevalideerd.

Interessant, ik ben nu wel benieuwd hoe dit in de toekomst aangepakt gaat worden.

26-05-2014, 21:00 door W. Spu

Ik kan bevestigen dat EMET 5.0TP3 wel correct gevalideerd wordt.

Het is verder opvallend stil aan de kant van Microsoft. Er is al dagen geen reactie geweest op de Microsoft case en al helemaal niet op het Forum. Is het niet mogelijk om meer mensen op deze forum post te attenderen en te betrekken? Kan iemand niet bijvoorbeeld Marc en/of Eric Loman via twitter benaderen en vragen of HitManPro eigen functies gebruikt om te detecteren of een bestand gevalideerd kan worden of dat er simpelweg van Windows functies gebruik gemaakt wordt. Verder wordt er vaak op het blog van Brian Krebs gerefereerd naar EMET als beveiliging tegen een zero day exploit. Wellicht zijn er nog andere fora waar iemand een post kan doen.

26-05-2014, 23:31 door Spiff has left the building - Bijgewerkt: 26-05-2014, 23:35

Door W. Spu:
Het is verder opvallend stil aan de kant van Microsoft.

Misschien wordt er intern wel aan gewerkt?
Dat voor EMET 5.0 Technical Preview 3 ineens weer gebruik is gemaakt van SHA1, in plaats van SHA256, dat doet vermoeden dat er wel iets is doorgedrongen.
Ik hoop dat morgen of een van de komende dagen Tony Krijnen (of eventueel een andere Microsoft medewerker) ons kan vertellen of een en ander inmiddels door Microsoft opgepakt wordt, en hoe.

27-05-2014, 02:40 door Ilja. _V V

Rustig afwachten, Spiff, alle vertrouwen in Tony...

Ilja. _\\//

29-05-2014, 12:19 door W. Spu - Bijgewerkt: 29-05-2014, 14:46

Ik had op het forum van Microsoft onder Windows 7 IT Pro > Windows 7 Security een nieuwe vraag 'Validating digital signatures successfull on Win7 but fails on Vista/XP/W2K3' http://social.technet.microsoft.com/Forums/windows/en-US/fd7ca904-e83a-4f42-a5d8-e61ca59446ea/validating-digital-signatures-successfull-on-win7-but-fails-on-vistaxpw2k3?forum=w7itprosecurity gesteld. Iemand van Microsoft TechNet Community Support reageerde hier op met de vraag of er al geprobeerd is de security update http://support.microsoft.com/kb/2749655 te instaleren. Cluc-Cluc heeft in zijn reactie van "09-05-2014, 03:05 door Anoniem" al aan gegeven dat de update op XP geprobeerd te hebben maar dat het probleem hiermee ook niet opgelost werd. Heeft iemand de update al op Vista geprobeerd?

Microsoft heeft (via de support case) het 'probleem' nog niet kunnen reproduceren op een schonev Vista SP1 installatie en gevraagd http://support.microsoft.com/kb/968730 te testen. Op Windows XP heeft dit ook het probleem niet opgelost en op Vista krijg je bij het runnen van WindowsXP-KB968730-x86-ENU.exe de melding "KB968730 Setup Error: The version of Windows you have installed does not match the update you are trying to install. Microsoft gaat proberen deze hotfix te laten installeren op Vista.

29-05-2014, 13:21 door Spiff has left the building

@ W. Spu,

Microsoft lijkt via je contact betreffend de support case en ook in je contact via TechNet Forums uit te blinken in onlogische suggesties.

KB968730 is nooit bedoeld voor Vista.
Ik kan me voorstellen dat het toepassen ervan een setup error geeft.
Daarnaast heeft het betrekking op een heel ander probleem dan dat waar we het hier over hebben.
http://support.microsoft.com/kb/968730/en

KB2749655 is aanwezig op mijn Vista systeem.
Ik vermoed dat dat wellicht ook bij jou het geval zal zijn.
Zoek via Windows Update, Geschiedenis van updates weergeven, Geïnstalleerde updates, Zoeken: KB2749655
Overigens heeft ook KB2749655 geen betrekking op dat waar we het hier over hebben, maar eveneens op een heel ander probleem.
http://support.microsoft.com/kb/2749655/en
https://technet.microsoft.com/library/security/2749655

Zoals ik al zei, Microsoft reikt je zeer onlogische suggesties aan. Nogal frustrerend.

Ik hoop dat het Tony Krijnen intern lukt om diegenen te benaderen die kennis van zaken hebben en die ons probleem op de juiste wijze kunnen oppakken.

29-05-2014, 13:56 door Spiff has left the building - Bijgewerkt: 29-05-2014, 14:05

Door tonykrij,
22-05-2014, 10:57 uur:
Ik weet niet wie er verder van Microsoft Nederland is gevraagd om naar deze thread te kijken maar ik kreeg vannacht pas een verzoekje binnen van @Ilja om er eens naar te kijken.
[...]
Ik zit niet vaak op dit forum maar feel free om me de volgende keer een berichtje te sturen, tx!
Tony (Microsoft Nederland).

Door Spiff, 22-05-2014, 11:23 uur:
Dankjewel voor het aanbod.
Hoe kunnen we je in zo'n geval het beste bereiken?

Door Ilja. _V V, 22-05-2014, 13:07 uur:
Spiff: Via het contact-formulier op zijn blog, weet niet hoeveel tekens erin passen:
http://blogs.microsoft.nl/blogs/tonykrijnen

Door Spiff, 22-05-2014, 14:04 uur:
@ Ilja, Dankjewel voor de verwijzing naar de blog van Tony Krijnen.
Altijd goed om die contactmogelijkheid achter de hand te hebben.

De afgelopen week blijkt Microsoft de blogs ineens 'vernieuwd' te hebben.
De eerdere URL levert nu een dode pagina.
De nieuwe URL voor Tony Krijnens blog is nu: https://blogs.microsoft.nl/tonykrijnen/
Echter, daarop vind ik geen contactmogelijkheid meer voor Tony Krijnen.
Jammer. En lastig.
Ik had Tony een week na zijn eerdere reactie even willen vragen of er al nieuws is, maar dat lukt zo dus niet.
Ah, maar ik zie nu dat Tony ook een contactmogelijkheid biedt via een eigen website.
http://www.tonykrijnen.com/
Ik zal via die weg dan even opnieuw zijn aandacht vragen, en vragen of hij ons al wat kan vertellen over hoe een en ander hopelijk inmiddels door Microsoft geanalyseerd en opgepakt wordt.

29-05-2014, 21:42 door W. Spu

Op één Vista systeem was KB2749655 ook geïnstalleerd. Op de virtuele Vista Ent. SP2 was de update niet te vinden en bij installatie van Windows6.0-KB2749655-x86.msu kreeg ik de foutmelding "The update does not apply to your system".

29-05-2014, 22:51 door W. Spu - Bijgewerkt: 29-05-2014, 22:53

Microsoft support heeft net (29-5-2014 22:10) een mail gestuurd dat ze het probleem gevonden hebben en dat ze een nieuwe download hebben uitgegeven. EMET 4.1 Update 1 met de juiste certificaten is te downloaden via http://www.microsoft.com/en-us/download/details.aspx?id=41138. De download is schijnbaar nog niet naar alle download servers gesynchroniseerd aangezien 'EMET Setup.msi' via het ene netwerk verbinding wel een countersignature (Thursday, May 29, 2014 1:38:02 AM) heeft en via een ander netwerk verbinding (nog) niet. Er is zowel met Windows XP als Windows Vista getest.

Hopelijk kan Microsoft nog aan geven welk probleem ze hebben gevonden en of ze dit permanent opgelost hebben....

29-05-2014, 23:06 door Rorror

Ëén van de mystery guest was van bericht van: "Door Anoniem, 01-05-2014, 15:07 uur:"

Heb niet alle reacties terug gelezen, maar vroeg me af hoe ver je was gekomen.

29-05-2014, 23:14 door W. Spu

Als ik het Time-Stamping Service certificaat snel even vergelijk dan zie ik dat het nieuwe certificaat niet meer gebruik maakt van sha256RSA voor de 'Signature hash' property maar sha1RSA. De properties 'Signature hash algorithm' met de waarde 'sha256' ontbreekt en ook de property 'Basic Constraints' met het gele driehoekje met een uitroep teken ontbreekt.

29-05-2014, 23:30 door Spiff has left the building - Bijgewerkt: 29-05-2014, 23:43

@ W. Spu, 22:51 plus 23:14 uur,

Ik heb EMET 4.1 Update 1 zonet gedownload via
https://www.microsoft.com/en-us/download/confirmation.aspx?id=41138
Net zoals onlangs voor Voor EMET 5.0 Technical Preview 3 is voor de heruitgifte van EMET 4.1 Update 1 nu weer gebruik gemaakt van SHA1, net zoals voor de eerdere EMET 4.0 en 4.1 en EMET 5.0 Technical Preview 1, maar anders dan voor de vorige uitgifte van EMET 4.1 Update 1 en EMET 5.0 Technical Preview 2 waarvoor SHA256 is gebruikt.

Doordat nu gebruik gemaakt is van SHA1 in plaats van SHA256 wordt de ondertekening ook onder Vista weer correct gevalideerd.
Maar dat is uiteraard slechts een lapmiddel!
Het lost niet het probleem op dat met gebruikmaking van SHA256 ondertekende bestanden niet correct worden gevalideerd onder Vista.
Ik mag hopen dat Microsoft daar nog een oplossing voor bedenkt, want uiteraard zijn die EMET installers niet de enige bestanden met op SHA256 gebaseerde ondertekening, zoals we eerder hebben vastgesteld!

Overigens heb ik eerder vandaag Tony Krijnen even een e-mail gestuurd, met de vraag of hij ons misschien al wat kan vertellen over hoe een en ander hopelijk inmiddels door Microsoft geanalyseerd en opgepakt wordt.
(Nou hoop ik wel dat mijn bericht is aangekomen op Tony's Microsoft-adres, want mail-correspondentie met Microsoft Nederland was in het verleden problematisch. Microsoft Nederland gaf aan mijn mails niet te ontvangen, en ik ontving niet de mails waarvan Microsoft Nederland zei dat die verstuurd waren. Ik hoop dat mijn e-mail aan Tony Krijnen gewoon netjes is aangekomen.)

29-05-2014, 23:55 door Spiff has left the building

Door Rorror, 23:06 uur:
Heb niet alle reacties terug gelezen, maar vroeg me af hoe ver je was gekomen.

Er is al veel duidelijk, bekijk even de berichten van de afgelopen week, vanaf 22 mei.
Tony Krijnen van Microsoft Nederland heeft vorige week toegezegd intern navraag te doen.
We zijn aan het afwachten of Tony Krijnen, dan wel Microsoft Nederland, ons al wat kan vertellen over hoe een en ander hopelijk inmiddels door Microsoft geanalyseerd en opgepakt wordt.
Gezien vrije dagen wegens 'Hemelvaart-weekend' verwacht ik nu eerlijk gezegd pas volgende week een reactie.

30-05-2014, 13:53 door W. Spu

Voor diegenen die de geïnstalleerde versie van EMET 4.1 Update 1 (met de op SHA256 gebaseerde ondertekening) probeert te vervangen door EMET 4.1 Update 1 (met de op SHA1 gebaseerde ondertekening) krijgt de foutmelding dat er al een versie geïnstalleerd is. Ook 'MSIEXEC /i "EMET setup.msi" REINSTALL=ALL REINSTALLMODE=vomus' en dan de optie repair werkt niet. EMET moet eerst verwijderd worden. Voordat je dat doet is het misschien verstandig je applicatie settings en eventuele andere settings te exporteren om deze later weer te kunnen importeren. Na de installatie kun je weer kiezen voor de recommended settings of deze later in te stellen. Let wel op dat met de recommended settings ook de DeepHook optie ingeschakeld wordt die vaak voor problemen zorgt.

30-05-2014, 14:10 door Anoniem

Fijn om te zien dat voor wat betreft mijn samenvatting van 21-05-2014, 13:11 inmiddels aan punt 9a, 9b, en 9c is voldaan.

Ik kan me voorstellen dat de bezinning op punt 9d (mede gekoppeld aan de berichten van 21-05-2014, 17:59 en van
24-05-2014, 11:27) wat meer tijd kost. Als het erg lastig is, kan een update zelfs langer dan 180 dagen duren!
Zie https://www.security.nl/posting/388994/Microsoft+werkt+aan+patch+voor+maanden+oud+IE8-lek

Maar gezien de neiging van de "sha256-bug" naar "CRITICAL", en op basis van de inschatting dat op het eerste gezicht een oplossing voor dit probleem nu ook weer niet zó ontzettend moeilijk lijkt,
verwacht ik van Microsoft eerlijk gezegd dat het deze keer niet zo lang zal duren.
Het zou fijn zijn als Microsoft kan laten doorschemeren wat we op dit front mogen verwachten: komt er snel een update?
En is Microsoft ontvankelijk voor de argumenten in mijn eerdere postings om dit ook nog eens voor XP te doen?...

Maar de ergste kou lijkt op dit moment in ieder geval voorlopig weer uit de lucht. ;-) YES! JOEPIE!
Mvg, cluc-cluc

30-05-2014, 18:45 door Spiff has left the building

Door Anoniem, cluc-cluc, 14:10 uur:
Fijn om te zien dat voor wat betreft mijn samenvatting van 21-05-2014, 13:11 inmiddels aan punt 9a, 9b, en 9c is voldaan.

9a was het verzoek aan Microsoft "mocht er voor het geconstateerde probleem toch nog ergens een patch bestaan, a.u.b. de community hierover te informeren."
Microsoft support heeft W. Spu gemeld dat er een nieuwe EMET 4.1 Update 1 uitgifte met aangepaste ondertekening beschikbaar is. Dat is alvast wat, maar het is uiteraard nog geen patch voor de essentie van het probleem, het feit dat Windows Vista (en eerder) slecht overweg kan met SHA256 ondertekende bestanden.
Maar zoals je verder ook aangeeft, dat volgt later hopelijk nog.

Door Anoniem, cluc-cluc, 14:10 uur:
Het zou fijn zijn als Microsoft kan laten doorschemeren wat we op dit front mogen verwachten

Inderdaad. Hopelijk krijgen we na het weekend daarover een berichtje.

30-05-2014, 19:47 door [Account Verwijderd] - Bijgewerkt: 30-05-2014, 19:52

Het is mooi dat het certificaat van EMET4.1u1 nu ook op Windows Vista en Windows XP kan worden gecontroleerd. Overigens is inderdaad wel te hopen dat het probleem met het controleren van SHA256 op Windows Vista ook wordt opgelost (en als dit ook wordt opgelost bij Windows XP zou dit natuurlijk mooi zijn).

Overigens voor de zekerheid op Windows 7 maar EMET 4.1u1 waar SHA256 bij is gebruikt vervangen door de nieuwe uitgaven van EMET4.1u1 waarbij SHA1 is gebruikt. Misschien was dit nodig maar liever het zekere voor het onzekere :-)

30-05-2014, 21:19 door W. Spu

Microsoft heeft net weer een mail gestuurd met de vraag of de case gesloten kon worden omdat het probleem met de EMET installer opgelost is. Er is nogmaals aangegeven dat het probleem voor de EMET installer welliswaar is opgelost maar dat de oorzaak van het probleem nog niet opgelost is. Als Microsoft weer een bestand met een sha256RSA Time-Stamping Service certificaat ondertekend begint het probleem opnieuw. Tevens is Microsoft gevraagd of er een hotfix uitgebracht gaat worden.

30-05-2014, 22:31 door Spiff has left the building

@ W. Spu,

Mooi dat je Microsoft bij de les houdt.
Het Microsoft team waarmee je contact hebt heeft weinig inzicht, zo lijkt het, gezien de suggesties die je eerder kreeg en gezien het feit dat nu gedacht werd dat de zaak afgedaan was met het uitbrengen van een aangepaste versie van de EMET 4.1u1 installer. Argh!
Ik hoop dat het Tony Krijnen lukt om op basis van de gezamenlijke bevindingen in deze thread, waaronder ook jouw ervaringen, intern bij Microsoft de zaak goed geanalyseerd en opgepakt te krijgen.

30-05-2014, 22:45 door W. Spu

Helaas.... Microsoft Support is van mening dat de case met EMET opgelost is en dat de rest buiten de scope van de case is. Ze stellen voor een nieuwe case te openen met een verzoek voor een 'design change' voor hoe Windows Vista/Server 2003 producten om gaan met dit soort certificaten. Wie o Wie biedt zich aan?

31-05-2014, 00:02 door Spiff has left the building

In reactie op W. Spu, 22:45 uur,

Nou ja, zeg! Microsoft zal gelijk hebben dat de EMET case opgelost is, maar om dan vervolgens te besluiten dat jij/wij maar een nieuwe case moet(en) openen betreffende het onderliggende probleem, dat vind ik nogal kortzichtig van dat betreffende Microsoft team. Ze zouden toch zelf initiatief kunnen nemen, zo lijkt me, de zaak is voldoende duidelijk. Vrij ergerlijk dat dat betreffende Microsoft team blijkbaar niet een dergelijk initiatief wil ontplooien.

Zoals ik heb aangegeven wil ik nu eerst afwachten of we volgende week wat mogen vernemen van Tony Krijnen, dan wel van Microsoft Nederland, over hoe een en ander hopelijk inmiddels door Microsoft geanalyseerd en opgepakt wordt.
Wordt inmiddels intern al actie ondernomen waar we op dit moment nog niet van weten, dan lijkt het me nogal dubbelop om nu zelf weer een case te gaan openen op TechNet.

31-05-2014, 13:46 door Anoniem

http://nl.wikipedia.org/wiki/Paarse_krokodil
http://www.youtube.com/watch?v=mJipJwDPJ-g
Zucht...

31-05-2014, 18:42 door [Account Verwijderd] - Bijgewerkt: 31-05-2014, 18:48

Vandaag heb ik een interessante pagina gevonden op de website van Microsoft over toepassingen uitvoeren onder Windows Vista die zijn ondertekent met SHA 256.

http://support.microsoft.com/kb/2763674/nl

Ook wordt hier een oplossing geboden voor het niet kunnen uitvoeren van toepassingen onder Windows Vista die met SHA 256 zijn ondertekend.

Mischien ook een onverwachte vraag maar toch voor de zekerheid: Spiff zou je kunnen controleren of je KB2763674 hebt geïnstalleerd?

31-05-2014, 19:22 door Eric-Jan H te D - Bijgewerkt: 31-05-2014, 19:27

Door W. Spu: EMET moet eerst verwijderd worden.

tJa dat krijg je ervan wanneer je (MS) ervan uitgaat dat je je versienummer niet hoeft aan te passen wanneer je het certificaat vervangt. Ik ben dergelijk handelen al vaker bij MS tegengekomen (ik dacht bij Sysinternals onderdelen). Deze route zal wel genomen zijn om de bureaucratische hobbels van een nieuwe versie te vermijden.

Gelijktijdig blijkt hieruit onweerlegbaar dat het voortbrengingsproces bij MS niet gesloten is. Dat zou iedereen grote zorgen moeten baren. Iets voor mijnheer Tony Krijnen van Microsoft Nederland misschien?

31-05-2014, 19:27 door Spiff has left the building

@ _kraai__, 18:42 uur,

Ja, KB2763674 is aanwezig op mijn Windows Vista systeem.

KB2763674 biedt een oplossing voor het probleem dat een applicatie ondertekend met een SHA256 certificaat niet uitgevoerd kon worden op Windows Vista SP2 of Windows Server 2008 SP2.

Assume that you download an application from the Internet on a computer that is running Windows Vista Service Pack 2 (SP2) or Windows Server 2008 SP2. The application is signed with a Secure Hash Algorithm (SHA)-256 certificate or a certificate with a larger hash value. In this situation, you cannot run the application.
This issue occurs because the buffer that is provided by the GetCertHash() function is not big enough to store a hash value that is 256-bits (32-bytes) or larger.
To resolve this issue, install the following update on the computer. After you install the update, the GetCertHash() function can store hash values that are 512-bits (64-bytes) or smaller.

http://support.microsoft.com/kb/2763674/en
Maar dat is niet waar we het hier in deze thread over hebben betreffend het Authenticode probleem onder Vista.
Betreffend het Authenticode probleem onder Vista waar we het hier in deze thread over hebben, wordt een applicatie ondertekend met een SHA256 certificaat als ongeldig weergegeven, maar niettemin kan deze wel worden uitgevoerd.

31-05-2014, 19:40 door [Account Verwijderd]

Door Spiff: @ _kraai__, 18:42 uur,

Ja, KB2763674 is aanwezig op mijn Windows Vista systeem.

KB2763674 biedt een oplossing voor het probleem dat een applicatie ondertekend met een SHA256 certificaat niet uitgevoerd kon worden op Windows Vista SP2 of Windows Server 2008 SP2.

Assume that you download an application from the Internet on a computer that is running Windows Vista Service Pack 2 (SP2) or Windows Server 2008 SP2. The application is signed with a Secure Hash Algorithm (SHA)-256 certificate or a certificate with a larger hash value. In this situation, you cannot run the application.
This issue occurs because the buffer that is provided by the GetCertHash() function is not big enough to store a hash value that is 256-bits (32-bytes) or larger.
To resolve this issue, install the following update on the computer. After you install the update, the GetCertHash() function can store hash values that are 512-bits (64-bytes) or smaller.

http://support.microsoft.com/kb/2763674/en
Maar dat is niet waar we het hier in deze thread over hebben betreffend het Authenticode probleem onder Vista.
Betreffend het Authenticode probleem onder Vista waar we het hier in deze thread over hebben, wordt een applicatie ondertekend met een SHA256 certificaat als ongeldig weergegeven, maar niettemin kan deze wel worden uitgevoerd.

Ik wist niet zeker of dit misschien een verband met elkaar zou kunnen hebben daarom stelde ik voor de zekerheid de vraag of je kon controleren of KB2763674 is geïnstalleerd.

31-05-2014, 19:48 door Spiff has left the building

Door _kraai__:
Ik wist niet zeker of dit misschien een verband met elkaar zou kunnen hebben daarom stelde ik voor de zekerheid de vraag of je kon controleren of KB2763674 is geïnstalleerd.

Dat begrijp ik, hoor, en bedankt daarvoor.
Gezien hetgeen dat KB2763674 oploste zie ik geen verband, maar ik kan niet uitsluiten dat iemand anders toch wél een verband ziet.

31-05-2014, 20:18 door Eric-Jan H te D

Door Spiff: maar ik kan niet uitsluiten dat iemand anders toch wél een verband ziet.

Ik denk dat er wel degelijk een verband is.
- gedownloade programma's draaien vanuit een onveilige context (een folder waarin je zonder speciale machtigingen de installer hebt geplaatst). De controle is daar navenant. Zelfs programma's zonder certificaat draaien daar.
- geïnstalleerde programma's draaien vanuit een redelijk veilige (Program Files) omgeving. In deze directory kun je niet zomaar wijzigingen aanbrengen. Als daar dan ook een programma met certificaat staat, verlangt Windows op zijn minst dat dat certificaat in orde is. Directories van Windows zelf (zoals System32) worden door Windows met nog strengere blik beschouwd.

31-05-2014, 21:04 door Spiff has left the building

@ Eric-Jan H te A, 20:18 uur,

Ik begrijp mogelijk niet goed wat je bedoelt.

Als ik als voorbeeld neem de eerder uitgegeven EMET 4.1u1 installer die was ondertekend met gebruikmaking van SHA256: Die installer downloadde ik naar een persoonlijke folder, en voerde die uit vanuit die folder om EMET 4.1u1 te installeren. Bij dat uitvoeren ter installatie kreeg ik een waarschuwing dat de uitgever onbekend was (doordat de digitale handtekening van het object niet kon worden gecontroleerd). Bij het ondanks dat toch vervolgen van de installatie werd EMET 4.1u1 geïnstalleerd, en ook functioneerde de geïnstalleerde EMET 4.1u1 grotendeels correct. De enige afwijking was zichtbaar bij het openen van de EMET GUI, waarbij UAC de melding gaf "Een onbekend programma wil toegang tot uw computer verkrijgen [...] Onbekende uitgever".

De eerder uitgegeven EMET 4.1u1 die was ondertekend met gebruikmaking van SHA256, daarvan was dus niet alleen de installer uit te voeren vanuit een persoonlijke folder, maar het vervolgens geïnstalleerde programma (in Program Files) was ook gewoon actief, met enkel de beperking dat de GUI opende met een (uiteraard) afwijkende melding.

Er was dus geen sprake van het niet kunnen uitvoeren van de eerder uitgegeven EMET 4.1u1 die was ondertekend met gebruikmaking van SHA256, niet bij het installeren ervan, maar ook niet betreffend het in Program Files geïnstalleerde programma.

En dat is dus anders dan wat volgens mij werd bedoeld in het geval van KB2763674, waar werd aangegeven "In this situation, you cannot run the application."
(http://support.microsoft.com/kb/2763674/en)

Of misschien begrijp ik niet goed wat jij bedoelde met wat je aangaf om 20:18 uur, Eric-Jan H te A?

01-06-2014, 12:40 door [Account Verwijderd] - Bijgewerkt: 01-06-2014, 13:26

Verwijderd, de pagina met informatie die ik gevonden had, had waarschijnlijk alleen betrekking op certificaten van websites en e-mails. Was even de draad kwijt ;-)

04-06-2014, 11:15 door W. Spu - Bijgewerkt: 04-06-2014, 11:15

Ik ben benieuwd of Microsoft het SHA-3 crypto algoritme zal gaan ondersteunen op Vista en W2K3.... Zie ook http://threatpost.com/nist-seeks-public-comment-on-sha-3-crypto-algorithm/106444

04-06-2014, 11:56 door Spiff has left the building

Door W. Spu:
Ik ben benieuwd of Microsoft het SHA-3 crypto algoritme zal gaan ondersteunen op Vista en W2K3....
Zie ook http://threatpost.com/nist-seeks-public-comment-on-sha-3-crypto-algorithm/106444

Als SHA3 in gebruik genomen gaat worden voor het verstrijken van de ondersteuningsperioden van Windows Server 2003 en Vista, dan zou het wel zo netjes zijn dat het dan ook ondersteund gaat worden op Server 2003 en Vista. Maar gezien het feit dat momenteel SHA2-256 nog niet eens goed ondersteund wordt, durf ik er nog niet te hoopvol over te zijn.

En verder -
Ondanks Ilja's vertrouwen (https://www.security.nl/posting/386805#posting389434) begin ik nu toch wel wat gefrustreerd te raken dat we sinds Tony Krijnens reactie van 22 mei (https://www.security.nl/posting/386805#posting388867) niets meer van Tony Krijnen vernemen.
Het zou prettig zijn om te vernemen of de essentie van het probleem dat we hebben gemeld, het feit dat met gebruikmaking van SHA2-256 ondertekende bestanden niet correct worden gevalideerd onder Windows Vista (en eerder) (N.B. een probleem dat niet slechts EMET betrof) inmiddels door Microsoft geanalyseerd en opgepakt wordt.
Ik heb op 29 mei even Tony Krijnens aandacht gevraagd per e-mail, en omdat mail-correspondentie met Microsoft Nederland in het verleden problematisch was (Microsoft Nederland gaf aan mijn mails niet te ontvangen, en ik ontving niet de mails waarvan Microsoft Nederland zei dat die verstuurd waren), heb ik op 2 juni tevens nog een bericht verstuurd via het webformulier op Tony Krijnens website.
Ik vind het jammer dat we tot op heden nog steeds niets vernemen.

05-06-2014, 04:02 door Ilja. _V V

Ik merk tijdens het verloop van dit onderwerp dat ik vaak wil reageren, maar dat is teveel, vandaar even mijn belangrijkste punten.

Spiff, wat betreft Tony Krijnen: Misschien heeft hij tijdens zijn bezoek hier iets opgestoken, misschien werd het via het contactformulier op zijn oude blog gewoon te druk. Ik heb hem enkele keren persoonlijk ontmoet, & wegens enkele andere netelige kwesties een e-mail gestuurd. Expres heb ik hem voor dit onderwerp via het contactformulier op zijn blog geschreven, & wat schetste mijn verbazing dat hij nog sneller alhier reageerde op mijn kik (voor de meesten van jullie midden in de nacht, voor mij 's avonds laat) dan per persoonlijke e-mail.

Wat ik lees is dat er, achter de schermen, wel degelijk wat gebeurd, zoals een nieuwe EMET-4-Update-1-versie, met, akkoord, snel & smerig, een SHA-1 inplaats van een SHA-256 handtekening.

Eigenlijk eenieder die aan dit onderwerp heeft deelgenomen, heeft er aan bijgedragen, het zij door opmerkzaamheid, hetzij door onderzoek, hetzij door vragen te stellen. (Of dat in een toekomstig BB een vermelding waard is, ga ik nu niet op in.)

Voor Microsoft is het ook een probleem, want structureel werkt het - beveiligings - systeem niet (meer). Niet alleen bij EMET, maar ook andere programma's vertonen hetzelfde euvel. Daarbij is Microsoft een grote, & daardoor dus logge, organisatie. Zeker als Microsoft tot de constatering komt dat er op basaal niveau er iets mis is met de methode van bestandsbeveiliging.

Spiff ontdekt dat bij EMET. Nu is EMET niet echt een installatie die door huis-tuin- & keuken-kuikens zal worden uitgevoerd. Het zijn juist diegenen die wat beter in beveiliging zijn, die EMET installeren, maar dus ook in staat zijn om een waarschuwing te interpreteren, een certificaat te controleren, een installatiebestand uploaden naar VirusTotal, & desnoods een (deel van de) installatie keihard uit de kluwen halen & reverse engineren.

Kom ik bij W.Spu, die n.b. in het Engels dit onderwerp heeft aangekaart op het Microsoft forum, n.b. inclusief screenshots.

Wat me daarbij het meeste trof, was na verloop van tijd zijn melding dat hij te horen had gekregen dat de technici van Microsoft het probleem niet konden reproduceren, terwijl iedereen alhier wel kon.

Overigens is het wel normaal op de Microsoft fora, dat moderatoren, indien mogelijk & te vinden proberen door te sturen naar een al bestaand onderwerp met oplossing, of naar een andere beter voor het probleem geschikte rubriek (vandaar het doorsturen vanaf EMET naar Vista).

Ik laat het hier even bij, zal het later indien nodig nog even mooi bijwerken, maar voor nu stop ik, anders draai ik dol... :-P

19-06-2014, 13:05 door Anoniem

Sleutelgebruik 80%

19-06-2014, 13:35 door Spiff has left the building

Door Anoniem, 13:05 uur:
Sleutelgebruik 80%

Wat bedoel je daarmee?

19-06-2014, 20:58 door Anoniem

Door Spiff:

Door Anoniem, 13:05 uur:
Sleutelgebruik 80%

Wat bedoel je daarmee?

Ik neem aan dat hij/zij bedoelde te zeggen dat trollen ook een vak is, wat niet wegneemt dat dit wel een erg vreemde combinatie van letters en leestekens is bij een topic als dit inderdaad :o

Door Ilja. _V V: Wat me daarbij het meeste trof, was na verloop van tijd zijn melding dat hij te horen had gekregen dat de technici van Microsoft het probleem niet konden reproduceren, terwijl iedereen alhier wel kon.

Waar lees je dat? Heb je een link? Ik kom niet verder dan http://social.technet.microsoft.com/Forums/windows/en-US/fd7ca904-e83a-4f42-a5d8-e61ca59446ea/validating-digital-signatures-successfull-on-win7-but-fails-on-vistaxpw2k3?

19-06-2014, 23:27 door Ilja. _V V

Akkoord, lastig terug te vinden in dit onderwerp met veel links, logs, & lange reacties, maar het is me gelukt! ;-)

Door Anoniem:

Door Ilja. _V V: Wat me daarbij het meeste trof, was na verloop van tijd zijn melding dat hij te horen had gekregen dat de technici van Microsoft het probleem niet konden reproduceren, terwijl iedereen alhier wel kon.

Waar lees je dat? Heb je een link? Ik kom niet verder dan http://social.technet.microsoft.com/Forums/windows/en-US/fd7ca904-e83a-4f42-a5d8-e61ca59446ea/validating-digital-signatures-successfull-on-win7-but-fails-on-vistaxpw2k3?

Het was inderdaad W.Spu, die dit probleem heeft gepost op het Microsoft-forum, maar alhier hetvolgende schrijft:

Door W. Spu:

Door Spiff:
Heb je Microsoft ook naar deze thread op Security.nl verwezen?

Ja zowel aan Microsoft Nederland als vandaag aan de engineer in de US. Ik denk echter dat dit forum een beetje moeilijk te lezen is voor de engineer in de US. Vanmiddag kregen we nog de melding dat ze het probleem nog niet hebben kunnen reproduceren en de vraag of het probleem speelt op alle computers. We hebben gereageerd dat het probleem speelt (en niet alleen bij ons) op XP, Vista (Home user + Enterprise) en Windows Server 2003 R2 en dat het gemakkelijk gereproduceerd kan worden op een schone installatie van Windows Vista zoals we zelf gedaan hebben op een virtuele computer.

20-06-2014, 09:14 door Anoniem

Door Anoniem: Waar lees je dat?

Door Ilja. _V V: Het was inderdaad W.Spu, die dit probleem heeft gepost op het Microsoft-forum, maar alhier hetvolgende schrijft:

Door W. Spu:

Door Spiff:
Heb je Microsoft ook naar deze thread op Security.nl verwezen?

Ja zowel aan Microsoft Nederland als vandaag aan de engineer in de US. Ik denk echter dat dit forum een beetje moeilijk te lezen is voor de engineer in de US. Vanmiddag kregen we nog de melding dat ze het probleem nog niet hebben kunnen reproduceren en de vraag of het probleem speelt op alle computers. We hebben gereageerd dat het probleem speelt (en niet alleen bij ons) op XP, Vista (Home user + Enterprise) en Windows Server 2003 R2 en dat het gemakkelijk gereproduceerd kan worden op een schone installatie van Windows Vista zoals we zelf gedaan hebben op een virtuele computer.

Ahhhh OK, ik dacht al!
Maar W. Spu meldt toch nergens dat MS het probleem niet kan reproduceren? Ik snap dat je dat uit de reactie van MS haalt, maar dat is wel een stukje interpretatie. Ik lees dat MS te lui is om het na te kijken ;)

Maar zonder gekheid, ondanks dat MS (zoals altijd) weinig tot geen feedback geeft hebben ze wel maatregelen genomen door geen SHA-256 RSA meer te gebruiken, 'n "hotfix" dus...

20-06-2014, 11:11 door Spiff has left the building

Door Anoniem, 09:14 uur:

Maar zonder gekheid, ondanks dat MS (zoals altijd) weinig tot geen feedback geeft hebben ze wel maatregelen genomen door geen SHA-256 RSA meer te gebruiken, 'n "hotfix" dus.

Ja, voor EMET 5.0 Technical Preview 3, en voor een aangepaste nieuwe uitgifte van EMET 4.1 Update 1 is bij ondertekening weer gebruik gemaakt van SHA-1 en niet meer van SHA-256.

Maar zoals eerder in deze thread aangetoond speelde het probleem ook met ten minste enkele andere Microsoft software, én mogelijk zijn er ook andere software-aanbieders die SHA-256 toepassen, of gaan toepassen bij ondertekening.

De essentie van het probleem dat we hebben gemeld, het feit dat met gebruikmaking van SHA-256 ondertekende bestanden niet correct worden gevalideerd onder Windows Vista en onder Server 2003 (en tevens XP en eerder), dat is nog steeds niet opgelost, en er is geen feedback over gegeven door Microsoft.

Het is dus wachten op een ander belangrijk stuk software waarvoor bij ondertekening gebruik gemaakt is van SHA-256, en het hele gedonder begint weer van voren af aan.
Nou ja, voor ons dan niet helemaal van voren af aan, want wij weten inmiddels het probleem aan te wijzen, maar treedt het op onder gebruikers die het betreffende fenomeen niet kennen, dan begint voor hen de zoektocht wellicht weer bij het begin.

20-06-2014, 12:52 door Anoniem

Door Spiff: De essentie van het probleem dat we hebben gemeld, het feit dat met gebruikmaking van SHA-256 ondertekende bestanden niet correct worden gevalideerd onder Windows Vista en onder Server 2003 (en tevens XP en eerder), dat is nog steeds niet opgelost, en er is geen feedback over gegeven door Microsoft.

Absoluut, vandaar de gekozen term "hotfix" ;)

Het is sowieso irritant dat MS systematisch weigert checksums te publiceren van bestanden. Heel die bestandscertificaten-branche schiet niet op maar het levert omzet op hè...

Tot de tijd dat MS hier aandacht aan besteden gaat, blijft het "hopen" dat er geen SHA256 meer gebruikt wordt voor bestandscertificaten, al begrijp ik wel dat dit probleem geen hoogste prioriteit heeft in Redmond, aangezien een systeem er niet onveiliger of minder functioneel van wordt.
Dat neemt natuurlijk niet weg dat ze inmiddels op z'n minst zouden mogen aangeven dat het onderkend wordt en eventueel zelfs ooit eens onderzocht gaat worden.

Ik deel dan ook je ongenoegen (frustratie), MS customer service is één groot drama voor eindgebruikers en het MKB.

20-06-2014, 23:47 door Eric-Jan H te D

Door Anoniem:Ik deel dan ook je ongenoegen (frustratie), MS customer service is één groot drama voor eindgebruikers en het MKB.

MS-engineers zijn hartstikke druk met duurbetaalde "after life' service te leveren aan XP-klanten, zoals de Nederlandse overheid.

11-07-2014, 17:28 door Eric-Jan H te D

Goh al weer bijna een maand geleden. Even opnieuw aanslingeren.

Wat hier begon als een probleem met Vista en SHA256 heeft een broertje
bij W7 en SHA512

https://support.microsoft.com/kb/2973337

11-07-2014, 21:21 door Spiff has left the building

Door Eric-Jan H te A:
Wat hier begon als een probleem met Vista en SHA256 heeft een broertje
bij W7 en SHA512
https://support.microsoft.com/kb/2973337

Met dat verschil dat in dit geval met Windows 7 en Windows Server 2008 R2 een update wordt aangeboden om dat probleem te fixen. En gewoon via Windows Update, en met de standaardinstelling van Windows Update dus automatisch.
Nu nog zoiets voor Vista en Server 2003 en het hier eerder besproken SHA256 probleem.

12-07-2014, 12:16 door Fwiffo

Door Spiff: Met dat verschil dat in dit geval met Windows 7 en Windows Server 2008 R2 een update wordt aangeboden om dat probleem te fixen. En gewoon via Windows Update, en met de standaardinstelling van Windows Update dus automatisch.
Nu nog zoiets voor Vista en Server 2003 en het hier eerder besproken SHA256 probleem.

Er is misschien nog iets wat we over het hoofd hebben gezien, en dat is FIPS 140-2 level 1, waaraan Vista nu voldoet.
Als Microsoft dingen gaat veranderen in de crypto modules, dan moeten ze ook een nieuwe certificatie aanvragen. Dit is misschien te veel moeite voor ze. Ook omdat Vista in Extended Support zit en Windows 7 nog niet.

De keuze is dus voor Microsoft:
1) Geen FIPS 140-2 (grote klanten boos), maar wel SHA-256/512
2) Wel FIPS 140-2, maar geen SHA-256/512 (huidige situatie)

Als SHA-1 nu heel erg lek blijkt te zijn in de toekomst, dan willen de grote klanten van Microsoft misschien wel SHA-256 en SHA-512. Dit is denk ik het beste wat ons als gewone gebruikers kan overkomen. Maar als SHA-1 acceptabel blijft voor grote klanten, dan komt er denk ik geen fix en moeten we maar hopen dat SHA-256/512 nergens gebruikt wordt of dat dit geen gevolgen heeft voor ons gewone gebruikers.

12-07-2014, 12:53 door Spiff has left the building

Door Fwiffo:
De keuze is dus voor Microsoft:
1) Geen FIPS 140-2 (grote klanten boos), maar wel SHA-256/512
2) Wel FIPS 140-2, maar geen SHA-256/512 (huidige situatie)

Sluit FIPS 140-2 dan SHA-256/512 uit?
Zo ja, kun je dan aangeven waarom?
Of bedoelde je dat Microsoft misschien slechts de moeite wil nemen om een van die twee te onderhouden voor Vista in Extended Support?

12-07-2014, 15:50 door Anoniem

FIPS of geen FIPS, maar het schuingedrukte statement van MS in
http://blogs.technet.com/b/pki/archive/2011/02/08/common-questions-about-sha2-and-windows.aspx
en de laatste alinea die daar direct op volgt, impliceert volgens mij een belofte van Microsoft.

Immers MS zendt in dat statement in wezen de volgende boodschap uit:

"Mensen let op. Weliswaar is er sha2-ondersteuning aanwezig in Windows XP SP3 voor SSL/TLS-communicatie,
maar als je sha2 ook nog gebruikt voor andere protocollen en toepassingen,
dan zullen óók die andere protocollen en toepassingen sha2 moeten ondersteunen.
En, zo zegt MS hier zelf, o.a. "Authenticode signature verification" heeft die sha2-ondersteuning niet.
(de problemen die wij hebben waargenomen, komen hier dus waarschijnlijk uit voort. Immers validatie van digitale ondertekening van bestanden heeft alles te maken met "Authenticode signature verification". Dit treedt kennelijk niet alleen in Windows XP SP3 op, maar óók in Vista. Anders is het wel bijzonder merkwaardig dat de symptomen gelijk zijn.)

Vervolgens waarschuwen ze in de laatste alinea alvast dat Windows XP de EOS datum nadert.
En dat betekent in deze context dus, dat men er rekening mee dient te houden
dat zulke eventuele "problematische andere protocollen en applicaties die óók sha2 nodig hebben"
in XP SP3 waarschijnlijk niet meer gepatcht kunnen worden.
En daarom adviseert MS dringend om te migreren naar Windows Vista/2008 en nieuwere systemen.

M.a.w: XP SP3 moet je niet teveel op rekenen, maar Vista is okee: het wordt nota bene met name genoemd.
Conclusie: het probleem dat wij met de digitale ondertekening met sha2 hebben ondervonden,
zal m.i. gepatcht moeten worden in Vista. Vooral omdat we het probleem tijdig officieel aan MS hebben gemeld. (ja toch?)
Anders zou het "dringende advies" dat ze hierover op 8 Feb. 2011 hebben gegeven een leugen zijn,
en zou de betrouwbaarheid van MS behoorlijk ter discussie komen te staan...
Mvg, cluc-cluc

12-07-2014, 18:09 door Spiff has left the building

Door Anoniem, cluc-cluc, 15:50 uur:
[...]
http://blogs.technet.com/b/pki/archive/2011/02/08/common-questions-about-sha2-and-windows.aspx
[...]
Vervolgens waarschuwen ze in de laatste alinea alvast dat Windows XP de EOS datum nadert.
En dat betekent in deze context dus, dat men er rekening mee dient te houden
dat zulke eventuele "problematische andere protocollen en applicaties die óók sha2 nodig hebben"
in XP SP3 waarschijnlijk niet meer gepatcht kunnen worden.
En daarom adviseert MS dringend om te migreren naar Windows Vista/2008 en nieuwere systemen.

M.a.w: XP SP3 moet je niet teveel op rekenen, maar Vista is okee: het wordt nota bene met name genoemd.
Conclusie: het probleem dat wij met de digitale ondertekening met sha2 hebben ondervonden,
zal m.i. gepatcht moeten worden in Vista.
[...]

Ik lees het anders.
Ik zie die een na laatste en laatste alinea van die Windows PKI blog post als losstaand van elkaar.
De een na laatste alinea zegt "the Authenticode signature verification does not support the SHA2 hashing algorithms on a computer that is running Windows XP SP3" en de laatste alinea zegt "Customers are strongly encouraged to migrate systems to Windows Vista/2008 and newer", maar dat laatste betekent volgens mij niet dat onder Windows Vista/2008 en nieuwer Authenticode signature verification wél SHA2 hashing algorithms ondersteunt of zou (moeten) gaan ondersteunen.
Het door Microsoft pal achter elkaar zetten van die twee boodschappen lijkt een verband te suggereren, maar volgens mij was die boodschap 'upgrade naar Vista of nieuwer' slechts als een algemeen advies bedoeld wegens het einde van de support voor XP, zonder een verband met het voorgaande.

13-07-2014, 00:07 door Fwiffo

@Spiff 12:53: FIPS 140-2 is geen algoritme, maar een soort keurmerk/stempeltje van de Amerikaanse overheid dat een implementatie aan bepaalde eisen voldoet. Ik begrijp van wikipedia dat dit proces zo een jaar in beslag kan nemen. Wat een reden kan zijn dat Microsoft er geen zin in heeft.

Als code niet goedgekeurd is volgens FIPS 140-2, dan mogen allerlei klanten bij de overheid deze niet gebruiken. Terwijl de huidige FIPS 140-2 certificering van Vista niet is ingetrokken en dus wel gewoon gebruikt mag worden door diezelfde overheid.

13-07-2014, 10:58 door Spiff has left the building

@ Fwiffo, 00:07 uur,
Bedoel je dat het maken van een aanpassing om Vista geschikt te maken voor Authenticode signature verification support for SHA2 hashing algorithms [ik laat dat maar even onvertaald] tot gevolg zou hebben dat FIPS 140-2 certificering opnieuw aangevraagd zou moet worden (wat een jaar kan duren)? Is dat werkelijk zo?
Oeps, ja, in dat geval kan ik me voorstellen dat Microsoft daarmee nu niet meer aan de slag zou gaan. Tegen de tijd dat dan een vernieuwde FIPS 140-2 certificering rond zou zijn, loopt de ondersteuning van Vista al bijna tegen z'n eind.
Maar dan had Microsoft dit allemaal eerder kunnen en moeten bedenken en Vista jaren geleden al gereed moeten maken voor een nette Authenticode signature verification support for SHA2 hashing algorithms.

13-07-2014, 11:36 door Anoniem

Ik lees het anders.
Ik zie die een na laatste en laatste alinea van die Windows PKI blog post als losstaand van elkaar.
De een na laatste alinea zegt "the Authenticode signature verification does not support the SHA2 hashing algorithms on a computer that is running Windows XP SP3" en de laatste alinea zegt "Customers are strongly encouraged to migrate systems to Windows Vista/2008 and newer", maar dat laatste betekent volgens mij niet dat onder Windows Vista/2008 en nieuwer Authenticode signature verification wél SHA2 hashing algorithms ondersteunt of zou (moeten) gaan ondersteunen.
Het door Microsoft pal achter elkaar zetten van die twee boodschappen lijkt een verband te suggereren, maar volgens mij was die boodschap 'upgrade naar Vista of nieuwer' slechts als een algemeen advies bedoeld wegens het einde van de support voor XP, zonder een verband met het voorgaande.

Bij nader inzien heb je waarschijnlijk gelijk Spiff. xcuus.

Het is ook wel wat verwarrend dat ze deze laatste alinea scharen onder de kop:
"Clarification on Support for SHA2 and Windows XP/2003"
Dat wekt namelijk de indruk dat ze het hier nog steeds over "Support voor SHA2" hebben.

Verder kan de zinssnede "only XP SP3 and 2003 SP2 are supported" verwarring geven.
Maar men wil waarschijnlijk slechts wil benadrukken dat only XP SP3 and 2003 SP2 are supported.
(en dus geen andere versies van XP en 2003...)

Nog een opmerking over FIPS:
Wel merkwaardig dat men FIPS op Vista niet intrekt, nu er aan het licht is gekomen dat validatie van bestanden
niet goed werkt met SHA256, terwijl SHA256 de nieuwe standaard aan het worden is?...

Mvg, cluc-cluc

13-07-2014, 12:15 door Fwiffo

@Spiff 10:58: Vista support had volgens de plannen al moeten stoppen voor die van Windows XP. Namelijk op 10 April 2012.
Ik vestig mijn hoop erop dat de Amerikaanse overheid ook EMET wil gebruiken tegen (APT) digitale aanvallen. En dat ze FIPS 140-2 willen (moeten) gebruiken. En ze zullen hier en daar Vista gebruiken (daar zijn wel eens berichten over geweest).

Als Microsoft voor deze overheden SHA2 toevoegt op Vista, dan kunnen ze dat net zo goed voor iedereen doen met Vista. Is immers geen extra werk. En misschien koopt de overheid weer een extra jaar support op Vista. Net zoals nu met XP gebeurt.

Precies snap ik het ook niet allemaal. Las dat je FIPS 140-2 aan kunt zetten in de registry. En die modus gebruiken jij en ik dus niet. Waarom de verificatie dan toch fout gaat??

SHA3 komt er ook aan en die is volledig anders als SHA2 en SHA-1. Dus een aanval op SHAx werkt niet op SHA3. Misschien dat Windows 7 geen SHA3 meer krijgt?? Zelfde gedoe. Ik wacht op Windows 9 tot ik een nieuwe computer koop. Heb mijn lesje wel geleerd met Vista (die had ik vlak voor de release van Windows 7 nog gekocht).

(P.S. Windows Vista Business zou wel nog extended support krijgen tot 11 April 2017 volgens de oude plannen).

13-07-2014, 13:30 door Spiff has left the building

Door Fwiffo:

Vista support had volgens de plannen al moeten stoppen voor die van Windows XP. Namelijk op 10 April 2012.
[...]
P.S. Windows Vista Business zou wel nog extended support krijgen tot 11 April 2017 volgens de oude plannen.

Klopt.
Dat was een hele commotie in 2012,
en met toen ineens een verlengde ondersteuning voor álle Vista edities :-)
https://www.security.nl/posting/35366/
https://www.security.nl/posting/35368/
Wie weet is Microsoft achter de schermen wel aan de gang met een aanpassing om Vista voor de resterende looptijd van de ondersteuning toch nog geschikt te maken voor Authenticode signature verification support for SHA2 hashing algorithms. Maar gezien de aanhoudende oorverdovende stilte na het aankaarten van de betreffende problematiek ben ik daar echter niet al te optimistich over.

13-07-2014, 14:05 door Spiff has left the building - Bijgewerkt: 20-10-2015, 14:21

@ cluc-cluc, 11:36 uur,

Ja, verwarrend was die opmaak van die Windows PKI blog post zeer beslist.
Verwarrende teksten opstellen is uiteraard niet voorbehouden aan Microsoft, maar ze kunnen er wel wat van.
(Niet gerelateerd, maar onlangs ook al een formulering met een stevige potentie tot verwarring in de IEBlog, betreffend Passwords in IE11, zie https://www.security.nl/posting/392905#posting392919, https://www.security.nl/posting/392905#posting393013 en https://www.security.nl/posting/392905#posting393033.)

En je hebt misschien gelijk, dat het merkwaardig is dat FIPS 140-2 voor Vista niet ingetrokken wordt, nu gebleken is dat validatie van bestanden niet goed werkt met SHA256, terwijl SHA256 de nieuwe standaard aan het worden is.
Of mogelijk zegt FIPS 140-2 voor Vista niets over Authenticode signature verification support for SHA2 hashing algorithms en hoeft daarom die FIPS 140-2 voor Vista niet ingetrokken te worden?

13-07-2014, 15:57 door Anoniem

Wat ik op internet lees over FIPS, geeft mij de indruk dat het een verplichte standaard is binnen de overheden van de V.S. en Canada. Ook andere overheden, organisaties of personen kunnen deze standaard (volledig of gedeeltelijk) overnemen.

Uitgebreide uitleg over de implementatie van FIPS bij MS vond ik hier:
https://technet.microsoft.com/en-us/library/security/cc750357.aspx

De vraag is volgens mij nu, of MS een "FIPS-compliant module" moet gaan wijzigen om het SHA2-probleem met validatie
van bestanden op te lossen. Immers het lijkt er tot nu toe op, dat het probleem met SHA2 eerder zit in de Authenticode-module(s) dan in een (FIPS compliant) crypto-module. Maar ik zou niet durven zeggen of deze twee zaken
eventueel nog bij elkaar in één dll geïntegeeerd zijn of zo. Ik verwacht het niet direct, maar zeg nooit "nooit".
Eigenlijk zou je dus moeten weten in welke specifieke software module(s) precies het probleem zit,
en dan kijken of deze voorkomt in de lijst van "Microsoft FIPS 140 Validated Cryptographic Modules".
Komt de door MS te repareren software module hier niet in voor, dan is er volgens mij geen probleem.
Mvg, cluc-cluc

15-07-2014, 13:00 door [Account Verwijderd] - Bijgewerkt: 15-07-2014, 13:19

Ik vraag me af wat deze update precies gaat brengen

https://technet.microsoft.com/en-US/library/security/2915720

Het zou best kunnen dat dit niets te doen heeft met het probleem van dit topic dus als iemand misschien even er naar zou willen kijken. Ik wordt er zelf niet helemaal wijs uit.

15-07-2014, 14:36 door Erik van Straten

Door _kraai__: Ik vraag me af wat deze update precies gaat brengen

https://technet.microsoft.com/en-US/library/security/2915720

Voor zover ik weet heeft deze update niets te maken met ondersteunde hash-types in Authenticode.

KB2915720 / MS13-098 stond gepland om te worden geactiveerd op 10 juni maar is uitgesteld tot 12 augustus 2014. Zonder activatie checkt Authenticode de inhoud van het bestand tot en met de authenticode signature waardoor het mogelijk is om achter die signature informatie op te nemen die vervolgens niet onder de handtekening valt. Normaal gesproken kan een aanvaller zo geen code toevoegen die wordt uitgevoerd. Echter, indien een installer al gebruik maakt van deze "feature", kan een aanvaller natuurlijk wel die toegevoegde informatie wijzigen zonder dat dit tot een ongeldige signature leidt.

Voor meer info zie http://blog.didierstevens.com/2013/12/11/ms13-098-fixing-authenticode/ (hierin beschrijft Didier Stevens ook een issue met de registerwaarde EnableCertPaddingCheck) en http://blogs.technet.com/b/srd/archive/2013/12/10/ms13-098-update-to-enhance-the-security-of-authenticode.aspx.

15-07-2014, 16:30 door [Account Verwijderd] - Bijgewerkt: 15-07-2014, 16:39

@Erik van Straten 14:36 uur.

Oké, bedankt voor de uitleg en de twee links. Hierdoor begrijp ik nu wel hoe het werkt.

31-07-2014, 21:27 door W. Spu

De final version van EMET 5.0 is uitgekomen en de certificaten kunnen worden gevalideerd op Windows Vista.
De nieuwe versie is te downloaden via http://www.microsoft.com/en-us/download/details.aspx?id=43714 en de announcement blog post is te lezen op deze pagina http://blogs.technet.com/b/srd/archive/2014/07/31/announcing-emet-v5.aspx

Probleem met certificaten

Kerstkaart:

Wachtwoord Vergeten

Password Reset

Registreren