PSA: Classic Shell is nu Open Shell Menu – en een waarschuwing

Nieuwe informatie voor gebruikers en geïnteresseerden van de Windows-tool Classic Shell: Het vervolgproject heeft alweer een nieuwe naam gekregen en heet nu Open Shell Menu. Hier volgt wat informatie en een hint waarom ik (momenteel) zou zeggen ‘wees voorzichtig’.

Er is software die zichzelf in de kijker houdt door hernoemingen. Ik zou het Classic Shell project in deze categorie indelen, omdat dit project weer een nieuwe naam heeft gekregen.

Enige achtergrond

De ontwikkelaar van de Classic Shell, Ivo Beltchev, is enige tijd geleden gestopt met de ontwikkeling van de software. Maar hij gaf de broncode aan de gemeenschap voor verder onderhoud. Ik heb daarover geblogd op mijn Duitse blog.

Maar wat niet zo mooi is naar mijn smaak: Op dit moment het project produceren gewoon koppen als gevolg van meerdere hernoemingen. Voor een korte tijd was de tool genaamd Classic Start. Toen besloot de gemeenschap om het eind juli 2018 te hernoemen naar NeoClassic-UI/Menu. Misschien zijn er goede redenen, ik weet het niet, ze zijn nooit genoemd.

De volgende nieuwe naam …

En nu is het project hernoemd naar Open-Shell-Menu. Het huidige installatiebestand heet nu OpenShellSetup_4_4_126.exe, maar de functionaliteit is waarschijnlijk niet veranderd. Het project is beschikbaar op GitHub, maar nog niet alle links zijn functioneel. De huidige Nightly Build is hier beschikbaar, die na 6 maanden vervalt.

De donkere kant van dit project: Security

Naast de ‘een zak rijst omgevallen in China, ga door, niets te zien’, wil ik u erop wijzen dat u uw handen van deze tool af moet houden (tenminste, totdat de ontwikkelaars een paar fundamentele dingen hebben opgelost). Waarom deze waarschuwing?

Ik heb sinds een tijdje contact met white hat hacker Stefan Kanthak (zie) (Microsoft neemt hem op in de Top 100 MSRC 2017 en ook in andere lijsten, zoals top 100 Finders in 2015). onderzoeker in 2015 (zie).

Stefan Kanthak heeft een Duits commentaar geplaatst, waarin hij een aantal kritische punten schetst. Hier volgt een kort fragment:

• Voor het gemak leveren de ontwikkelaars een .exe-installatieprogramma (in plaats van een .msi-bestand). Dit installatieprogramma moet worden uitgevoerd met beheerdersrechten om de software te installeren. De installer pakt de benodigde bestanden uit in een (onbeschermde) TEMP directory. Probleem: Als er malware op het systeem staat die momenteel alleen draait met de rechten van een beperkte gebruikersaccount, wordt de val geactiveerd.
• Deze malware kan het uitpakproces opmerken (er zijn Windows API’s die dit kunnen melden en een ‘hook-functie’ van de malware kunnen aanroepen). Dan is het voldoende om een DLL-bestand met een bepaalde naam naar de TEMP-map te kopiëren (omdat deze onbeschermd is, is dit mogelijk met beperkte gebruikersrechten).
• Tijdens het installatieproces probeert het installatieprogramma de veronderstelde Windows DLL te laden, maar krijgt toegang tot de DLL die door de malware is geplaatst als gevolg van Windows-eigenschappen. En de malware krijgt prompt administratieve rechten via de DLL.

Dit staat al lang bekend als DLL search order hijacking, een potentieel veiligheidsrisico en moet absoluut worden vermeden. Stefan Kanthak heeft enkele links en verdere details gepost in zijn Duitse commentaar. Als conclusie: Zolang het project deze problemen niet heeft aangepakt, zou ik het gebruik van dergelijke software vermijden/voorzichtig zijn.

Addendum: Op dit punt moet ik me een beetje terugtrekken. Ik heb eens gekeken naar het installatieprogramma (onder Windows 7). Interessante observatie: De Duitse lezer Martin Feuerstein had in een commentaar erop gewezen, dat de .exe installer een schakelaar heeft voor het uitpakken van de .msi installers – kan worden weergegeven met /? Dus je kunt de .msi uitpakken en de 32-/64-bit versie installeren via .msi installer.

Er is nog een andere observatie: Blijkbaar draait de .exe installer tijdens het uitpakken alleen met standaard gebruikersrechten, pakt de .msi bestanden uit en roept de juiste aan. De .msi installer activeert de UAC prompt door instellingen in zijn manifest en installeert de tool. Dit elimineert de aanvalsvector zoals hierboven beschreven volgens mijn huidige kennis (of de juiste msi de UAC aanroept kan gecontroleerd worden in de UAC prompt). Als er nieuwe bevindingen zijn, zal ik ze toevoegen.

Addendum 2: Volgens Stefan Kanthak heeft de installer ClassicStartSetup_4_4_109.exe de volgende afhankelijkheden – kan worden verkregen met:

LINK.exe /DUMP /DEPENDENTS ClassicStartSetup_4_109.exe

COMCTL32.dll
VERSION.dll
KERNEL32.dll
USER32.dll
ADVAPI32.dll
SHELL32.dll

En de bovenstaande DLL’s zijn afhankelijk van GDI32.dll, MSVCRT.dll, RPCRT4.dll, SECUR32.dll en
SHLWAPI.dll. Sinds Windows Vista is VERSION.dll geen “bekende DLL” en elk bestand met die naam zal worden geladen vanuit de directory van de toepassing, indien aanwezig. Hetzelfde geldt voor SECUR32.dll en RPCRT4.dll.

Note: In de onderstaande screenshots en in het voorbeeldcommando gebruik ik de oudere ClassicStartSetup_4_4_109.exe. Ik heb dezelfde tests ook uitgevoerd met OpenShellSetup_4_4_126.exe (de meest recente nachtelijke build) – hetzelfde resultaat. Ook geen digitale handtekening beschikbaar. Daarom laat ik de oude screenshots en commando’s in de tekst staan.

Stefan Kanthak liet me enkele van zijn test DLL’s gebruiken om ClassicStartSetup_4_4_109.exe in een testomgeving uit te voeren. Hier is het resultaat:

(Klik om te zoomen)

Een poging om de opties weer te geven resulteerde in een waarschuwing, dat een malware de bestanden gemanipuleerd zou kunnen hebben (voorliggend dialoogvenster). Daarna liet ik de .exe installer gewoon de .msi installers uitpakken. Toen ik de 64 bit msi installer uitvoerde, werden er geen waarschuwingen meer gegeven.

Maar de .msi bestanden die in het .exe installer bestand zitten, zijn momenteel niet digitaal ondertekend. De reden: Het zijn nachtelijke builds. Op dat punt ben ik gestopt met verder onderzoek. De nachtelijke builds zijn niet voor eindgebruikerssystemen. Laten we afwachten, hoe de uiteindelijke versie van die tool eruit ziet en of het dezelfde kwetsbaarheden heeft als hierboven geschetst.