image

Handtekening MSI-bestand ongewijzigd bij toevoegen malware

dinsdag 15 januari 2019, 14:02 door Redactie, 6 reacties
Laatst bijgewerkt: 15-01-2019, 00:00

Aanvallers kunnen Java-malware aan gesigneerde MSI-bestanden toevoegen zonder dat de digitale handtekening van het bestand verandert en deze aanvalsvector is door VirusTotal waargenomen. VirusTotal is de online virusscandienst van Google waar mensen verdachte bestanden naar toe kunnen uploaden, die vervolgens door tientallen virusscanners worden gecontroleerd.

Softwareontwikkelaars kunnen bestanden signeren, zodat gebruikers de identiteit van de ontwikkelaar kunnen vaststellen en weten dat het bestand niet is aangepast. Als een gesigneerd .exe-bestand wordt aangepast zal Windows de digitale handtekening namelijk niet meer als geldig beschouwen. De aanwezigheid van een digitale handtekening zorgt er ook voor dat sommige beveiligingspakketten geen diepgaande scan bij gesigneerde bestanden uitvoeren.

Onderzoekers van VirusTotal hebben echter ontdekt dat het mogelijk is om in het geval van gesigneerde MSI-bestanden wel code aan het bestand toe te voegen, zonder dat Windows vervolgens alarm slaat. Het aangepaste bestand doorstaat het verificatieproces en zal de originele handtekening laten zien, zonder enige waarschuwingen. Op deze manier zou een aanvaller kwaadaardige code aan het MSI-bestand kunnen toevoegen, die vervolgens bij het openen van het bestand ook wordt uitgevoerd.

Het is echter niet mogelijk om elk willekeurig soort bestand toe te voegen. Afhankelijk van het soort bestand dat is toegevoegd moet de aanvaller al een onderdeel hebben dat op het systeem van het slachtoffer draait en de toegevoegde code in het MSI-bestand kan uitpakken en uitvoeren. Bij JAR-bestanden is dit echter niet van toepassing. JAR staat voor Java ARchive en beschikt over een eigenschap waardoor het ideaal voor deze situatie is, aldus Bernardo Quintero van VirusTotal.

Via een JAR-bestand is het namelijk mogelijk om een complete applicatie uit te rollen. Het JAR-formaat is daarnaast gebaseerd op Zip om de verschillende onderdelen van de applicatie op te slaan. Tevens kijkt Java bij het openen van een JAR-bestand naar het einde van bestand in plaats van het begin. Een aanvaller kan zodoende een kwaadaardig JAR-bestand aan een gesigneerd MSI-bestand van een vertrouwde softwareontwikkelaar zoals Google of Microsoft toevoegen. Het bestand kan vervolgens worden hernoemd met de .jar-extensie en nog steeds zal Windows de digitale handtekening als geldig beschouwen. Zodra de gebruiker dit bestand opent wordt ook de toegevoegde Java-malware uitgevoerd.

VirusTotal ontdekte de aanvalsvector bij een bestand dat naar de virusscandienst was geüpload. Er is echter nog geen bewijs gevonden dat deze techniek op grote schaal wordt toegepast om malware te verspreiden. Microsoft is over het probleem geïnformeerd, maar is niet voornemens om het in de huidige versies van Windows te verhelpen. De softwaregigant vond het verder prima dat VirusTotal de aanvalsvector bekendmaakt.

Reacties (6)
15-01-2019, 14:43 door Anoniem
Bam! Al het gehannes met certificaten en signeren, helemaal voor niets.

Waarom vindt microsoft het allemaal wel best? Omdat het hen om de controle gaat, niet om de veiligheid.
15-01-2019, 15:14 door Anoniem
Microsoft is over het probleem geïnformeerd, maar is niet voornemens om het in de huidige versies van Windows te verhelpen. De softwaregigant vond het verder prima dat VirusTotal de aanvalsvector bekendmaakt.

Ik ben benieuwd naar de risico-afweging van Microsoft om tot een dergelijke uitspraak te komen. Het klinkt me toch als een zwakheid in de oren die uitgebuit kan worden. Onder het mom van "de nieuwe Sigcheck detecteert deze aanval, dus gebruik dat maar"?
15-01-2019, 15:59 door Bitwiper
Dit is een bekend oud probleem (2013, zie https://support.microsoft.com/en-us/help/2893294/ms13-098-vulnerability-in-windows-could-allow-remote-code-execution-de).

Microsoft heeft toen ondersteuning voor een registerwaarde genaamd "EnableCertPaddingCheck" toegevoegd (voor diegenen die zich meteen wilden beschermen) en aangekondigd deze vanaf 10 juni 2014 by default op "1" te zullen zetten, maar dat is nooit gebeurd.

Uit bijvoorbeeld https://docs.microsoft.com/en-us/windows/desktop/api/wintrust/nf-wintrust-winverifytrustex:
WinVerifyTrustEx function - 12/05/2018 - 3 minutes to read:
Note

The TRUST_E_SUBJECT_NOT_TRUSTED return code may be returned depending on the value of the EnableCertPaddingCheck registry key under HKLM\Software\Microsoft\Cryptography\Wintrust\Config. If EnableCertPaddingCheck is set to "1", then an additional check is performed to verify that the WIN_CERTIFICATE structure does not contain extraneous information. The check validates that there is no non-zero data beyond the PKCS #7 structure. The EnableCertPaddingCheck key will be set to "1" by default on June 10, 2014. For more information, please refer to the following security advisory: http://technet.microsoft.com/security/advisory/2915720#section1
(die laatste URL doet nu een redirect naar https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2014/2915720#section1, voor de veiligheid zou ik op laatstgenoemde https variant klikken).

Microsoft loog en liegt dus, want dit is nooit gecorrigeerd waardoor deze issue elke keer weer voorbijkomt.

In W10 (64 bit) onder HKLM\Software\Microsoft\Cryptography\ en HKLM\Software\Wow6432Node\Microsoft\Cryptography\ bestaat de subkey WinTrust niet, maar als je beide genoemde keys (paden) maakt:
HKLM\Software\Microsoft\Cryptography\WinTrust\Config\
HKLM\Software\Wow6432Node\Microsoft\Cryptography\WinTrust\Config\
en onder bijde een value van het type string maakt en deze de waarde "1" geeft:
"EnableCertPaddingCheck"="1"
dan krijg je geen geldige digitale handtekening meer te zien op een gemanipuleerd bestand (dit werkt dus zelfs onder de laatste versie van Windows 10, een reboot was bij mij niet nodig).

PROBLEEM #1: je krijgt dus geen digitale handtekening meer te zien (het tabblad in bestandseigenschappen ontbreekt volledig) MAAR JE KRIJGT OOK GEEN WAARSCHUWING. Bizar...

PROBLEEM #2: er bestaat legitieme software die gebruik (misbruik?) maakt van deze "feauture", bijvoorbeeld de Sophos (voorheen Astaro) OpenVPN client installer, en de veel kleinere installer file met daarin alleen configuratiebestand, client certificaat en private key. Daarbij is de executable code van die installers beschermd door de authenticode handtekening, maar de aanvullende (en variabele, per client verschillende) informatie niet.
15-01-2019, 18:14 door Anoniem
Door Bitwiper:
....
(die laatste URL doet nu een redirect naar https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2014/2915720#section1, voor de veiligheid zou ik op laatstgenoemde https variant klikken)
.....
Klopt de info op die pagina (nog) wel?
De regfile die je moet uitvoeren is gebaseerd op 'Windows Registry Editor Version 5.00'. Op mijn Win7 draait 'Windows Registry Editor Version 6.1'.
15-01-2019, 21:19 door Bitwiper
Door Anoniem:
Door Bitwiper:
....
(die laatste URL doet nu een redirect naar https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2014/2915720#section1, voor de veiligheid zou ik op laatstgenoemde https variant klikken)
.....
Klopt de info op die pagina (nog) wel?
De regfile die je moet uitvoeren is gebaseerd op 'Windows Registry Editor Version 5.00'. Op mijn Win7 draait 'Windows Registry Editor Version 6.1'.
Ik heb vanmiddag de wijzigingen met de hand gemaakt (overigens moest ik wel rebooten nadat ik de wijzingen ongedaan had gemaakt om weer een "digital signatures" tabblad getoond te krijgen bij mij testfiles).

Ik vermoed dat als je de bedoelde tekst uit die pagina in een .reg bestand zet, dat je deze probleemloos kunt inlezen - maar dat heb ik niet getest. Maar als je op safe wilt spelen kun je de keys en values natuurlijk ook met de hand invoeren.

De reden van de opname van een versienummer is -vermoedelijk- dat als er een keer een format wijziging plaatsvindt, regedit ofwel weet hoe te converteren, ofwel de invoerfile kan weigeren.

Overigens heeft Didier Stevens al in 2009 laten zien dat Microsoft's authenticode signature niet voor elke byte in een bestand geldt, en ook heeft hij tools geschreven om van bestanden met authenticode signature te laten zien dat er bytes in zitten die niet tot het gesigneerde deel behoren, zie o.a. deze pagina https://blog.didierstevens.com/2013/12/11/ms13-098-fixing-authenticode/ en de links daarin naar Didier's Authenticode tools.

Overigens, naast dat Didier Steven zijn handige tools gratis beschikbaar stelt, is Didier een van de handlers van het Internet Storm Center (https://isc.sans.edu/) die uitstekend werk doen om het internet veiliger te maken. In het verleden heeft Didier ook wel eens op security.nl gepost (zie https://www.security.nl/profile?alias=Didier+Stevens).
16-01-2019, 12:47 door Anoniem
Door Anoniem: Bam! Al het gehannes met certificaten en signeren, helemaal voor niets.

Waarom vindt Microsoft het allemaal wel best? Omdat het hen om de controle gaat, niet om de veiligheid.
Controle? Ik denk eerder om geld, controle hebben ze al als je Windows 10 hebt ! Koop maar eens even een certificaat waar je een applicatie mee kunt signeren. Dan ben je dus maar een paar honderd euro verder. Doe je dit niet en je geeft je applicatie vrij zonder het certificaat. Dan krijgen al je Windows 10 gebruikers een meerdere zware melding voor de kiezen. Zoals smartscreen en de bekende "Unknown publisher" waarschuwing.

Het gaat om GELD, want je mij niet vertellen dat de beveiliging hier een enorme som geld is? Dus ik bedoel daarmee dat je het zo enorm duur maakt dat de criminelen het niet kunnen of willen betalen ?? Denk het niet hoor, een software leverancier of developer MOET wel anders krijgen de eindgebruikers een nare melding zoals ik al eerder zei. Heeft niets met beveiliging te maken, want als je software doet kraken loopt het ook gewoon nog, met hetzelfde certificaat. Je maakt me dus niet wijs dat je met een paar opcode wijzigingen in het gebruiken of op de schijf al je beveiliging in een plak in de vuilnisbak gooit? Bewijs zat dat het om geld gaat.

Integriteit (statisch) kun je ook anders afdwingen, of gewoon ouderwetse checksums met nieuwe algo's SHA2.
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.