[English]Neue Information für Nutzer bzw. Interessenten der eingestellten Classic Shell: Das Folgeprojekt wurde schon wieder umbenannt und heißt jetzt Open-Shell-Menü. Hier ein paar Informationen und ein Hinweis, warum man eher 'Obacht' sagen muss (obwohl die Entwickler offenbar nachgebessert haben).
Anzeige
Es gibt Software, die hält sich durch Umbenennungen im Aufmerksamkeitsfokus. Die Fortsetzung des Classic Shell-Projekts würde ich zu dieser Kategorie zählen, denn dieses Projekt hat sich wieder umbenannt.
Zum Hintergrund
Der Entwickler der Classic Shell, Ivo Beltchev, hat die Entwicklung der Software vor einiger Zeit eingestellt. Aber er übergab den Quellcode an die Community zur weiteren Pflege. Ich hatte im Blog-Beitrag Windows: Aus für Startmenü-Ersatz Classic Shell? thematisiert. Das ist schon mal gut.
Ständige Namenswechsel
Was aber für meinen Geschmack eher nicht so schön ist: Momentan glänzt das Projekt eher durch Umbenennungen. Kurze Zeit rangierte das Tool unter dem Namen Classic Start. Ich hatte dies im Blog-Beitrag Windows: Info-Splitter, Name für Redstone 5, Classic Shell etc. erwähnt. Gut, eine Umbenennung wäre ok.
Dann kam die Community auf die Idee, das Projekt in NeoClassic-UI/Menu umzutaufen (siehe den Beitrag Classic Start ist jetzt NeoClassic-UI/Menu). Außer dem neuen Namen gab es Ende Juli 2017 nichts neues zu vermelden – also 'gehen Sie weiter, es gibt hier nichts zu sehen'.
Nun heißt es Open-Shell-Menü
Bei den Kollegen von deskmodder.de lese ich, dass die Entwickler doch wirklich noch einen neuen Namen gefunden haben. Der Startmenü-Ersatz firmiert jetzt unter dem Namen Open-Shell-Menü. Die aktuelle Installationsdatei heißt nun OpenShellSetup_4_4_126.exe. Geändert hat sich wohl nichts an der Funktionalität. Das Projekt ist auf GitHub erreichbar, die Links sind aber noch nicht alle funktional. Die aktuelle Nightly Build ist hier abrufbar, wobei diese nach 6 Monaten ablaufen.
Anzeige
Die größte Baustelle: Sicherheit!
Jetzt könnte man den umgefallenen Sack Reis in China wieder aufheben und weiter gehen. Ich weise aber an dieser Stelle darauf hin, dass man von diesem Tool erst einmal Abstand halten sollte (unabhängig von dem, was die Community sich morgen einfallen lässt. Warum diese deutliche Warnung?
Beachtet den Kommentar von Stefan Kanthak, der nicht von der Hand zu weisen ist. Aus Gründen der Komfortabilität glauben die Entwickler einen .exe-Installer (statt einer .msi-Datei) ausliefern zu müssen. Dieser Installer muss mit administrativen Berechtigungen ausgeführt werden, um die Software zu installieren. Dabei entpackt der Installer die benötigten Dateien in ein (ungeschütztes) TEMP-Verzeichnis. Problem: Liegt eine Schadsoftware auf dem System vor, die momentan nur mit den Rechten eines eingeschränkten Benutzerkontos läuft, schlägt die Falle möglicherweise zu.
Diese Malware kann den Vorgang des Entpackens mitbekommen (es gibt Windows-APIs, die das melden und eine 'Hook-Funktion' der Malware aufrufen können). Dann reicht es, eine DLL-Datei mit einem bestimmten Namen in den TEMP-Ordner zu kopieren (da dieser ungeschützt ist, geht dies mit begrenzten Nutzerrechten). Der Installer versucht während des Installationsvorgangs die vermeintliche Windows-DLL zu laden, greift aber – auf Grund von Windows-Eigenarten – auf die von der Schadsoftware platzierte DLL zu. Und prompt erhält die Malware über die DLL administrative Berechtigungen.
Das Ganze segelt unter dem Begriff DLL search order hijacking, ist lange bekannt, als potentielles Sicherheitsrisiko verpönt und sollte unbedingt vermieden werden. Stefan Kanthak hat einige Links und weitere Details im Kommentar dazu gepostet. Das Projekt würde imho gut daran tun, sich weniger umzubenennen, sondern an den von Kanthak benannten Baustellen zu arbeiten.
Weitere Erkenntnisse
Ergänzung: An dieser Stelle muss ich temporär etwas zurückrudern. Ich habe mir jetzt mal den Installer (unter Windows 7, allerdings nur den Startmenü-Teil) zu Gemüte geführt. Interessante Feststellung: Martin Feuerstein hatte ja im Kommentar darauf hingewiesen, dass die .exe einen Schalter zum Extrahieren der .msi-Installer aufweist – lässt sich mit /? anzeigen. Man kann also die Geschichte entpacken und die passende 32-/64-Bit-Variante per .msi installieren. Werden die .msi-Dateien zur Installation benutzt, gibt es die obige Schwachstelle nicht.
Scheinbar läuft der .exe Installer-Wrapper während des Entpackens auch nur mit Standardrechten, entpackt die .msi-Dateien und ruft die passende Variante auf. Diese aktiviert dann per Manifest die UAC-Abfrage und installiert das Tool. Damit wäre ein Angriffsvektor wie oben beschrieben nach meinem bisherigen Wissen – wenn ich nichts übersehen habe – ausgehebelt (ob die richtige msi die UAC aufruft, lässt sich ja im UAC-Dialogfeld kontrollieren). Auch scheint in der .exe-Datei keine Abhängigkeit auf bestimmte Windows-Ressourcen zu existieren. Denn die von mir benutzte Test DLL-Datei wurde nicht getriggert. Die geäußerten Bedenken scheinen also in dieser Version nicht (mehr) zu gelten.
Nachtrag: Stefan Kanthak hat in den Kommentaren weiter unter ja darauf hingewiesen, dass die Dateien nicht digital signiert sind (das ist vermutlich den Nightly Builds geschuldet). Er hat mir folgendes mitgeteilt: Ruft man den Installer ClassicStartSetup_4_4_109.exe mit folgendem Link-Befehl auft:
LINK.exe /DUMP /DEPENDENTS ClassicStartSetup_4_4_109.exe
werden die nachfolgenden Abhängigkeiten angezeigt.
COMCTL32.dll, VERSION.dll, KERNEL32.dll, USER32.dll, ADVAPI32.dll, SHELL32.dll
Diese DLLs hängen aber wieder von GDI32.dll, MSVCRT.dll, RPCRT4.dll, SECUR32.dll und SHLWAPI.dll ab. Da VERSION.dll seit Windows Vista keine "known DLL" ist, wird jede Datei gleichen Namens aus dem Verzeichnis der jeweiligen Anwendung geladen. Das Gleiche gilt für SECUR32.dll und RPCRT4.dll.
Anmerkung: In den Screeshots und dem obigen Beispiel wird noch die ältere ClassicStartSetup_4_4_109.exe verwendet. Ich habe den Test auch mit der OpenShellSetup_4_4_126.exe (ist die momentan aktuell Nightly Build) durchgeführt – gleiches Ergebnis. Auch digitale Signaturen fehlen. Daher habe ich den Screenshot und den Befehl in obigem Beispiel nicht mehr angepasst.
Stefan Kanthak hat mir einige seiner Test-DLLs überlassen. Man kann sich z.B. die Datei Forware.cab herunterladen, und dann unter Windows in einen Testordner (ich habe einen Unterordner von Downloads verwendet) entpacken. Anschließend kopiert man das zu testende Programm in den gleichen Ordner und führt es danach aus. Ich habe gleich mal die ClassicStartSetup_4_4_109.exe sowie die aktuelle OpenShellSetup_4_4_126.exe in dieser Testumgebung ausgeführt. Dazu habe ich die Programme aus dem Fenster der Eingabeaufforderung gestartet, um auch Optionen angeben zu können. Hier das Ergebnis (die Ausgabe ist für beide Programmversionen, bis auf die Programmnamen, identisch):
(Zum Vergrößern klicken)
Bereits beim Versuch des Aufrufs des Hilfedialogs mit den Aufrufoptionen gibt es eine Warnung, dass die Datei hätte manipuliert werden können. Ich habe im Anschluss die .msi-Installer extrahieren lassen. Bei deren Ausführung wird keine Warnung mehr ausgegeben. Da diese .msi-Installer aber (in den Nightly Builds) bisher unsigniert sind, könnte Malware diese manipulieren. An dieser Stelle habe ich den Test abgebrochen. Falls sich neue Erkenntnisse ergeben, trage ich diese nach.
Ähnliche Artikel
Windows: Aus für Startmenü-Ersatz Classic Shell?
Windows: Info-Splitter, Name für Redstone 5, Classic Shell etc.
Classic Start ist jetzt NeoClassic-UI/Menu
Anzeige
Dann lädt man sich die MSI auf einem sauberen System (oder einem Live-System) herunter und entpackt den MSI-Installer, dafür gab es zumindest in ClassicShell einen Kommandozeilenparamter, um diesen dann für die Bereitstellung im Netzwerk zu verwenden. Das mit den Bootstrappern hat aber schon einen gewissen Sinn, um fehlende Abhängigkeiten nachzuladen, z. B. VC++, .NET Framework, VSTO oder was auch immer (noch mehr ausführbare Dateien im Temp-Verzeichnis ;-)).
Andererseits lässt sich mit einem Windows Installer per Custom Action auch jedes Programm ausführen oder auch Schadsoftware nachladen usw. Und selbst wenn ich mir ein sauberes MSI herunterlade, liegt dieses normalerweise in einem Verzeichnis, welches potentiell Schreibzugriffe durch den Benutzer, das Systemkonto und auch Schadsoftware erfahren kann.
Andere MSI(!)-Installer kapseln nur EXE-Installer, meines Wissens z. B. Flash Player und AIR (korrigiert mich, wenn ich falsch liege). Früher gabs Programme, die genau für die faulen Admins gestrickt wurden, um eben sowas zu erreichen (Windows Installer Wrapper Wizard). Der Java RE-Installer entpackt sich ins Appdata\LocalLow des Benutzers als MSI, da sagt auch keiner was. Und auch Microsoft verpackt seinen Windows Installer für Office hinter einer Setup.exe (auch wenn da wohl nix ins Temp geschrieben wird). Bei den "Großen" wird also auch Mist gebaut.
Und wenn der eigene Computer mit Schadsoftware belastet ist, hat man imho ganz andere Probleme als ein DLL-Hijacking durch den Classic- oder "wie auch immer"-Shell-Installer. Da kann der Stefan Kanthak bei doofen Installern meinetwegen auch nochmal 100 Puls mehr kriegen.
Und wer (wie ich) EXE-Installer für die Verteilung nicht gebrauchen kann, die Produkte aber dennoch verteilen muss, kann sich die Installer auch "einfach" selbst bauen (zumindest bei Open Source ohne rechtliche Probleme, alternativ beim Hersteller anfragen). So kann man sich dann sicher sein, das am Netzwerk-Bereitstellungspunkt (der durch die Clients nur lesend zugreifbar ist) eine saubere Installationsquelle zur Verfügung steht.
Bringt mich dazu: wenns danach gehen würde, müsste eigentlich jedes Programm mit jeder neuen Version (und Update) auf einem nicht-schreibbaren Datenträger vertrieben werden, sei es nun auf CD/DVD-ROM, Floppy (mit ausgebrochenem Read-Only-Schalter), SD-Karte (mit Schreibschutzschalter) oder Read-Only-USB-Stick. Und dann müsste man von PC zu PC laufen für die Installation mit diesem einen Medium. Die Zeiten sind schon etwas her, aber das will auch niemand wieder zurück :-D
Nein, wenn die .exe-Installer in Verzeichnisse entpacken würden, auf die ein Nutzer mit eingeschränkten Benutzerrechten keine Schreibrechte besitzt, wäre (imho) der Angriffsvektor weg.
Das Benutzerkonto hat ja schon Schreibrechte auf das Verzeichnis, in welchem die heruntergeladene Datei liegt, nicht nur aufs Temp-Verzeichnis – und muss die Datei von dort aus starten.
Alternativ würde der Benutzer die Datei mit einem administrativen Konto herunterladen und ausführen müssen, was dann wieder zum gleichen Problem führt. Dann hätte zwar das normale Benutzerkonto keinen Schreibzugriff mehr auf die Installationsdatei, es bleibt aber das größere Gefahrenpotential durch das Surfen mit erhöhten Rechten (mit bösen Popups, Flash und allem was dazugehört).
Abgesehen von einer Bereitstellung in einem schreibgeschützten Verzeichnis, in dem der Benutzer das Installationsprogramm selbst nicht gespeichert haben kann, fällt mir spontan keine Lösung ein. Und selbst bei einer schreibgeschützten Bereitstellung z. B. im Netzwerk muss mindestens der Administrator der Umgebung Schreibzugriff gehabt haben – und auch der hat das Installationsprogramm meist aus dem Internet heruntergeladen.
Bei Datenträgern hat mindestens der Hersteller Schreibzugriff, also auch da ist nicht zwangsläufig der Schutz vor Manipulation an der Quelle gegeben.
Also doch zurück zu selbstgestanzten Lochkarten. Ich meine du hattest vor einiger Zeit mal einen Beitrag zu deinem Werdegang gemacht, in dem auch die Arbeit mit Lochkarten enthalten war.
Martin: Ich muss mich korrigieren – ich habe es oben im Text als Ergänzung nachgetragen. Die .exe scheint nur ein Wrapper zum Entpacken zu sein und läuft mit Standardrechten. Die .msi-Installer aktivieren die UAC [internes Manifest legt das fest] selbst (da erkenne ich aktuell keinen Angriffsvektor mehr).
AMEN!
Zum Entpacken (s)einer Nutzlast in ein sicheres, d.h. für unprivilegierte Benutzer/Prozesse nicht beschreibbares Verzeichnis müsste der Entpacker mit Administratorrechten laufen. Gleiches gilt, wenn der Entpacker ein solches sicheres Verzeichnis unterhalb von %TEMP% (oder sonstwo) anlegt.
Damit öffnet sich allerdings der DIREKTE Angriffsvektor auf den Entpacker.
Also: die VOLLIDIOTEN, sie ausführbare Installationsprogramme oder selbst-extrahierende Entpacker frickeln, haben die freie Wahl zwischen Pest und Cholera.
Alle Anderen liefern ein signiertes *.MSI, oder eine signierte*.CAB mit einem signierten *.INF: *.MSI werden von MSIExec.exe verwurstet, und (in *.CAB eingebettete) *.INF vom per RunDll32.exe AdvPack.dll aufgerufenen SetupAPI.
Beide sind PRINZIPIELL nicht per DLL spoofing/hijacking angreifbar: sie liegen im System-Verzeichnis.
Weder SetupAPI noch der Windows Installer müssen die in *.MSI oder *.CAB enthaltenen Dateien entpacken, sondern verarbeiten diese DIREKT aus dem Paket/Archiv, OHNE Umweg über ein möglich^Wtypischerweise unsicheres %TEMP%-Verzeichnis.
Zudem prüfen SetupAPI und Windows Installer die Authenticode-Signaturen der *.MSI und *.CAB sowie deren Nutzlasten.
Eine Fälschung oder Modifikation führt beim Windows Installer zu einer Warnung und beim SetupAPI zum Abbruch.
Wie üblich: AHNUNGSLOS!
Wer garantiert die Authentizität der auf einem (nicht)schreibgeschützten Medium gespeicherten Dateien?
Die Authentizität von heruntergeladenen *.MSI und *.CAB, aber auch *.EXE stellt jeder nicht völlig bescheuerte Anbieter mit einer digitalen Signatur sicher.
Bei der Verarbeitung von *.MSI und *.CAB stellt Windows sicher, dass unprivilegierte Benutzer/Prozesse keinen Einfluss nehmen können. Bei *.EXE ist das NICHT der Fall.
DAS IST DER KLEINE UNTERSCHIED!
win8.1 Defender schlägt bei deiner Seite (https://skanthak.homepage.t-online.de/) an, dass, bei Aufruf, da was bereinigt worden sei, warum? Vtotal sagt 0 / 67…
Das machen auch die Security Essentials. Der Hintergrund (habe ich mal vor langer Zeit mit Stefan Kanthak diskutiert – ich zitiere mal aus unserem Mail-Austausch):
Ich hoffe, das reicht als Erklärung. Wir haben Schlangenöl und ne Menge Schlangengruben …
aus diesem Grunde plane ich hier auch weitere Artikel von 'Zeugx', welches ich von Stefan Kanthak zugeschickt bekommen habe, aufzubereiten.
bleibt immer noch mehr so abschreckend. für normale Nutzer.
Was soll ich ins tiefere html-etc. eintauchen (wollen), um irgendwas merkwürdiges einer x-beliebigen Seite nachvollziehen zu können – wozu? Weiss mit meiner Zeit besseres anzufangen.
Es fehlt ein (Warn-)Hinweis auf dieser Seite, indiskutabel. Das kann man sich nu schönlügen – oder aber, sinnvoller, sowas links liegen lassen. Weil Null Mehrwert.
@monddulbe: Es bleibt dir unbenommen, die Seite links liegen zu lassen und ich sehe dich von den Seiteninhalten nicht als Zielgruppe (ich kann sogar deine Reaktion verstehen). Aber der Ansatz, einen data Tag mit dem Eicar-Testvirus zu bestücken, dieses Element aber nicht in einem Seitenscript abzurufen und zu sehen, was passiert, ist imho bestechend.
Das ist ja im Grunde die Schizophrenie: Die Leute wollen maximal sicher sein, installieren sich das neueste Windows (wird in höchsten Tönen gelobt) und on Top kommt der neueste Kaspersky oder was weiß ich. Wird dann mal aufgezeigt, was da alles im Argen liegt, fängt die Mannschaft sofort an, zu relativieren (machen andere doch auch so) und abzuwiegeln (lässt sich das ausnutzen, zu kompliziert etc.). Beobachte ich bei einigen meiner Artikel aus diesem Genre.
Mein Fazit nach diversen Artikeln der letzten 2 Wochen: Die Leute wollen belogen werden oder nichts davon hören, und erwarten weiße Salbe … Beherzigt man das, dann segelt es sich als Blogger am leichtesten ;-).
PS: Ich werde nie Sicherheitscrack werden – aber bei bestimmten Themen löckt mich halt der Stachel – ergo greife ich so was auf und wenn's zum Test ist, ob vorhersehbare Reaktionen auf einen Artikel kommen.
PPS: Gerade die proof in diesem Artikel (geht um elektronische Wahlmaschinen aus den USA, die auf der Defcon von einem 11 jährigen Mädchen manipuliert werden konnten) gefunden, dass es anderen auch nicht anders geht.
'Bei den "Großen" wird also auch Mist gebaut.' Nun, da kann ich dir leider nicht widersprechen – und speziell bei MS gibt es Dokumente (sind ein paar Jahre alt), die erklären, was man aus Sicherheitsgründen nicht machen soll. Aber da hält sich niemand dran.
Bzgl. der ose.exe (Office Installer) – ich habe es nicht veröffentlicht. Mir liegt eine Info des MS-Entwicklerteams an Kanthak vor, dass man diese Schwachstelle nach seinen Hinweisen entfernt hat. Ob es final zutrifft, kann ich nicht sagen – man wird es ggf. hören.
"Werden die .msi-Dateien zur Installation benutzt, gibt es die obige Schwachstelle nicht."
AUTSCH!
Wie überprüfst Du die Authentizität der entpackten *.MSI?
Weder diese noch der Entpacker sind digital signiert, sie können von Hinz&Kunz manipuliert worden sein … oder von einer der DLLs, die der Entpacker aus seinem "application directory" geladen hat, und die die volle Kontrolle über diesen Prozess haben.
Nur so zur Ehrenrettung: Die alten Releases von Ivaylo Beltchev *sind* digital signiert.
Die neuen Releases von Coddec sind tatsächlich (noch?) nicht digital signiert – es sind aber auch "nur" ein "Developer Release" und darauf aufbauend ein "Hotfix for Windows Insider Preview" verfügbar, also eigentlich noch nix für den Endanwender (es steht – anders als bei Kaffeebechern von McD, die warnen, dass der Kaffee heiß sein könnte – nicht dabei, dass man das nur installieren sollte, wenn man auch weiß, was man da tut).
Ja, das stimmt – hatte ich nicht bedacht. Muss die ganze Geschichte unter die Lupe nehmen, sobald die Endversion vorliegt.
@Stefan und Günter:
Ich möchte (hierzu halbwegs passend) mitteilen, dass selbst vom BSI explizit für die Verarbeitung von VS-NfD-eingestuften Daten zugelassene Programme (siehe https://www.bsi.bund.de/DE/Themen/Sicherheitsberatung/ZugelasseneProdukte/Liste_Produkte/Liste_Produkte_html.html ) diese Probleme aufweisen. Ich nutze sowohl Ecos SBS als auch Sirrix/Rohde und Schwarz Trusted Disk. Der Sentinel von Herrn Kanthak schlägt sowohl beim Enrollment von Ecos an, als auch beim Verwenden der Trusted Disk Hilfskomponente CardOS API von ATOS.
Man sollte meinen, dass das BSI solche Dinge in seinen Prüfungen finden sollte. Ich habe dies auch vor längerer Zeit dem Support von ATOS mitgeteilt, erhielt aber keine Antwort.
Ich frage mich, ob diese Lücken, die Herr Kanthak vorführt, überhaupt ernst genommen werden. Ich kenne selbst zwei Programme, die diese aufweisen (gefunden über Kanthaks Sentinel), und diese Programme sind in dieser Version derzeit sogar vom BSI geprüft und zugelassen für Verarbeitung von eingestuftem Datenmaterial (Geheimschutz: VS-NfD): Ecos SBS und Rohde und Schwarz Trusted Disk (siehe Liste https://www.bsi.bund.de/DE/Themen/Sicherheitsberatung/ZugelasseneProdukte/Liste_Produkte/Liste_Produkte_html.html ). Trusted Disk benutzt zum Beispiel die Hilfskomponente ATOS CardOS API 5.4 U11, welche ein Autostartelement installiert, bei welchem Sentinel anschlägt. Habe ATOS informiert, keine Reaktion, keine Änderung.
Interesse?
Ich nehme an, die beiden mit dem Wix Toolset verbrochenen *.MSI tragen den Pfadnamen zum installierten Programm cardoscp.exe unter
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run]
"CardOS API"="C:\Program Files\…\cardoscp.exe"
ohne die notwendigen Anführungszeichen ein.
Siehe https://cwe.mitre.org/data/definitions/428.html
Solche ANFÄNGER-Fehler sind Industriestandard!
JEDER nicht völlig ahnungslose Entwickler und erst recht dessen Tester und JEDE Qualitätssicherung dürfte die fehlenden Anführungszeichen übersehen … zumal sie eine der MINIMAL-Anforderungen der inzwischen 23 Jahre alten "Designed for Windows"-Richtlinien Microsofts sind.
Dummerweise können seit Vista nur Administratoren C:\Program.exe anlegen, daher spielen viele Frickelbuden diese Ausprägung des Anfängerfehlers herunter … obwohl das bei der Windows-Installation angelegte Benutzerkonto noch immer ein "Administrator" und die Benutzerkontensteuerung ein SEHR schlechter Scherz ist!
Da C:\Program.exe mit den Rechten des sich gerade anmeldenden Benutzers ausgeführt wird kann es nicht mehr Schaden anrichten als jedes andere Programm, das dieser Benutzer beispielsweise in seinem "Downloads"-Ordner zur Ausführung bringt…
"Hübscher" sind die von Ahnungslosen verbrochenen "custom actions":
1) cmd.exe /c "pnputil -a setup.inf"
2) BIN_vc_redistEXE_x86 /q /norestart
JEDER nicht völlig ahnungslose Entwickler würde %SystemRoot%\System32\PnPUtil.exe natürlich DIREKT mit seinem vollqualifizierten Pfad aufrufen, anstatt indirekt über den Kommandoprozessor, und auch den wohlbekannten vollqualifizierten Pfad der setup.inf angeben.
BIN_vc_redistEXE_x86 ist ein von Microsoft mit einem veralteten Wix Toolset 3.7.3813.0 verbrochenes Installationsprogramm (für die MSVCRT 2015), das TRIVIAL angreifbar ist.
Siehe dazu http://seclists.org/bugtraq/2016/Jan/105 sowie https://www.firegiant.com/blog/2016/1/20/wix-v3.10.2-released/
Zur Demonstration empfehle ich, die NTFS-ACE (D;OIIO;WP;;;WD) auf %TEMP% sowie %SystemRoot%\Temp zu setzen. Letzteres kann der während der Windows-Installation angelegte Benutzer ohne UAC-Intervention sobald https://support.microsoft.com/en-us/kb/950934 einmal zugeschlagen hat.
Du hast Recht bezüglich der Anführungszeichen. Noch mehr: Ausgabe von Sentinel:
ATTENTION!
This might have been the call and the execution of a malicious executable (worm, virus, trojan horse)!
Executed process: C:\Program.exe
Executed command: C:\Program Files\CardOS API\bin\chkscreg.exe
Calling process: cardoscp.exe
Current directory: C:\WINDOWS\System32
—
und ein zweites Mal:
Executed process: C:\Program.exe
Executed command: C:\Program Files\CardOS API\bin\chkscreg64.exe
Calling process: cardoscp.exe
Current directory: C:\WINDOWS\System32
Danke für den Kommentar.
@Bernhard Diener & Stefan Kanthak: Ich habe das Thema jetzt mal im Blog-Beitrag Schwachstellen in IT-Sicherheitsprodukten mit BSI-Freigabe? zusammen gefasst. Gleichzeitig geht gerade eine Anfrage an das BSI mit der Bitte um Stellungnahme. Vielleicht klärt sich ja was.
OK.
Ich habe mir gestern nur die beiden *.MSI angeschaut, d.h. eine KURZE statische Analyse vorgenommen, und ihre Inhalte entpackt. Ich habe sie nicht installiert, und auch die zu installierenden Programme weder angeschaut noch gestartet, also keine dynamische Analyse vorgenommen.
Der zweite Anfängerfehler steckt im Programmcode von cardoscp.exe, wo
CreateProcess(NULL, "C:\\Program Files\\CardOS API\\bin\\chkscreg.exe …", …) aufgerufen wird.
Meissle den Abschnitt "Security remarks" von https://msdn.microsoft.com/en-us/library/ms682425.aspx#Security_Remarks Falls in starke Granitplatten und appliziere die bei den Verbrechern dieses Schrotts!
Ergänzend: https://skanthak.homepage.t-online.de/verifier.html sowie https://skanthak.homepage.t-online.de/!execute.html
ich verstehe und beachte den hier erhaltenen hinweis .msi statt .exe installer zu nehmen wo immer man die auswahl hat, ist ja recht häufig. gehört für mich zum beruf wenn man dazu lernt und kunden einem vertrauen schenken. danke für die hinweise!