Handtekening MSI-bestand ongewijzigd bij toevoegen malware
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.
Waarom vindt microsoft het allemaal wel best? Omdat het hen om de controle gaat, niet om de veiligheid.
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"?
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:
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
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\Wow6432Node\Microsoft\Cryptography\WinTrust\Config\
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.
....
(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)
.....
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'.
....
(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)
.....
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 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).
Waarom vindt Microsoft het allemaal wel best? Omdat het hen om de controle gaat, niet om de veiligheid.
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.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Information Security Officer (2fte)
Een uitdagende rol waarbij jij, op basis van security, de vertaalslag maakt tussen business en IT en direct bijdraagt aan de veiligheid van informatie binnen de gemeente Almere. Dat is in een notendop waar jij als Information Security Officer mee bezig bent. Interesse gewekt? Door groei van de organisatie zijn we op zoek naar twee nieuwe collega’s.
Specialiseer je in Forensisch ICT
Online informatieavond 19 november
Wil jij je specialiseren in digitaal forensisch onderzoek? Je kennis verbreden en tech-nische vaardigheden ontwikkelen? Ontdek de cursus- en opleidingsmogelijkheden van Hogeschool Leiden:
- Bachelor Informatica Forensisch ICT (deeltijd)
- Master Digital Forensics (vol- en deeltijd)
- Module Mobile Forensics
- Module Data Analytics
Interesse? Meld je aan!
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
