Schlagwort-Archive: Windows

Windows-Update – Fehler 0x800f0831 beheben

Hinweis: Die Screenshots sind von einem älteren System, die Meldungen, Pfade und Vorgehensweisen sollten sich jedoch auch auf aktuelle Versionen übertragen lassen.

Und wieder das übliche Bild: Auf einem Windows-System sind nicht alle Updates installiert. Keine gute Idee, insbesondere bei Systemen, die an einem Netzwerk betrieben werden. Also schnell in die Einstellungen und Updates installieren – in der Theorie. Leider passiert es nach meiner Beobachtung immer wieder, dass Updates quer sitzen und sich nicht installieren lassen. Auch im aktuellen Fall sah man bereits: “Failed” war im letzten Installationsversuch zu erkennen.

8 offene Windows-Updates, letzter Installationsversuch fehlgeschlagen

Auch ein manueller Versuch über “Install updates” brachte kein Erfolg. Der Assistent schien fehlerfrei zu laufen, nach dem im Anschluss angeforderten Reboot war jedoch das Bild wieder identisch: Die Updates standen erneut als offen drin. Also erster Blick: Welche waren überhaupt betroffen. In den Details fanden sich neben den meist wenig aussagekräftigen Bezeichnungen auch die KB-Nummern, welche bei Microsoft die zugehörigen Dokumentationen beschreiben.

Liste der offenen Updates mit KB-Nummern

Hier kam dann der Microsoft Catalog unter https://www.catalog.update.microsoft.com/ ins Spiel: Über diese Webseite lassen sich per KB-Nummer einzelne Updates suchen und per Hand herunterladen. Hierbei etwas aufpassen: Oft sind die Updates für verschiedene Betriebssystemversionen und CPU-Architekturen mit der selben KB-Nummer eingestellt, beim Download lohnt es sich also doppelt hin zu schauen.

Microsoft Update Katalog-Webseite mit einzelnen Updates

Die zum Download angebotenen MSU-Dateien sollten sich direkt per Doppelklick öffnen lassen und einen Setup-Assistenten zeigen. Leider brachte auch die händische Installation keine Besserung – am Ende des Assistenten vermeldete das Ergebnis ein wenig aussagekräftiges “The following updates were not installed“. Auch die Ereignisanzeige des Betriebssystems verriet nicht mehr als eben jene wenig hilfreiche Statusmeldung.

An dieser Stelle wird oft eine Reparatur mit DISM.exe /Online /Cleanup-image /Restorehealth bzw. Sfc /scannow oder gar eine Neuinstallation empfohlen. Ist jedoch klar, dass das System keine weiteren Probleme hat, ist eine gezielte Reparatur jedoch oft weniger Zeitintensiv als eine vollständige Neuinstallation, insbesondere wenn die betroffenen Systeme nicht über ein Konfigruationsmanagement/Orchestration zur automatischen Installation verfügen.

Glücklicherweise erstellt Windows Update an diversen Stellen erweiterte Protokolle, welche die Fehlersuche erleichtern. Bei Installationsfehlern sind die CBS-Logs meist die hilfreichste Anlaufstelle. Die Korrekte Datei findet sich unter %systemroot%\Logs\CBS\CBS.log. Eine Suche nach ” Error ” (mit ein paar Leerzeichen dahinter) sollte die relevante Stelle schnell sichtbar machen. In diesem Fall handelte es sich um eine Inkonsistenz im Updatespeicher, die zugehörige KB-Nummer ist in solchen Fällen in der Fehlermeldung erkennbar. Wer diese vergleicht wird feststellen, dass es sich hierbei nicht um eins der zur Installation vorgemerkten Updates handelte. Stattdessen betraf es ein älteres Update, welches für die aktuelle Installation benötigt wurde. Das genannte, ältere Update war laut System installiert, fehlte in Realität jedoch. Ein solcher Zustand ist oft zu finden, wenn bei einem vorherigen Update der Rechner abstürzte.

Ausschnitt CBS-Log. Vorausgesetzte KB-Nummer in der Fehlermeldung erkennbar

Also zurück zum Catalog, dort kann man das defekte Update manuell herunterladen und nochmals installieren. Ist dies Erfolgreich sind Updatespeicher und Realität an dieser Stelle wieder auf einem konsistenten Stand und die Installation der neueren Updates kann fehlerfrei erfolgen. Möglicherweise muss der Vorgang für mehrere ältere Updates wiederholt werden. Hier kann es helfen in der Updatehistorie zu prüfen, welche Updates mit dem Betroffenen zeitgleich installiert wurden und diese – sofern nicht ersetzt – präventiv ebenfalls neu zu installieren. Am Ende sollten sich alle Updates installieren und das System so auf einen aktuellen Stand bringen lassen.

BitBastelei #349 – VPN mit Wireguard

BitBastelei #349 - VPN mit Wireguard

(186 MB) 00:37:55

2019-09-08 10:00 🛈

In perfekten Netzen könnte jeder mit jedem kommunizieren, in der Praxis sieht es oft anders aus. Mittels VPN kann man ein “virtuelles Netzwerkkabel” zwischen zwei PCs oder Routern aufbauen. Eine solche VPN-Software ist Wireguard, welches für alle gängigen Betriebssysteme verfügbar und vergleichsweise einfach einzurichten ist.

Inhalt

  • 00:10 Was ist ein VPN
  • 05:42 Klassische VPN-Lösungen
  • 08:26 Wireguard
  • 10:04 Installation & Konfiguration unter Debian Linux (CLI)
  • 18:00 Installation & Konfiguration unter Arch Linux (CLI)
  • 24:45 Zugriff auf’s Internet: Forwarding & NAT
  • 27:51 Installation & Konfiguration unter Arch Linux (NetworkManager)
  • 29:59 Installation & Konfiguration unter Windows
  • 32:30 Installation & Konfiguration unter Android

Links

BitNotice #145 – Inkscape-Standardeinstellungen ändern

BitNotice #145 - Inkscape-Standardeinstellungen ändern

(9 MB) 00:01:48

2019-03-27 17:30 🛈

Inkscape präsentiert bei jedem Öffnen erst mal ein DIN A4-Blatt – nicht gerade hilfreich, wenn man eher mit anderen Formaten wie z.B. dem bei Videos verbreiteten 16:9 arbeitet. Einen offensichtlichen Weg um die Vorgaben zu ändern scheint es nicht zu geben, mit etwas Wissen zur korrekten Schraube lässt sich das Ziel dennoch erreichen.

  • *nix: ~/.config/­inkscape/
  • Windows: %userprofile%\­Application Data\­Inkscape\

Windows RDP: “Die angeforderte Funktion wird nicht unterstützt” (CredSSP)

Zugegeben, ich bin etwas spät dran, aber heute bin ich bei einer Stelle mit CredSSP und RDP dann auch mal auf die Schnauze gefallen. Da mir das – dank sonst gepflegter Infrastruktur – bisher nicht begegnet ist hier nochmal zum Nachlesen. Und mich als Gedächtnisstütze.

Vorgeschichte

Verursacher der ganzen Misere ist CredSSP, der Credential Security Support Provider. Dieses Windows-Modul ist unter Anderem für die Authentifizierung von Nutzern bei Verbindungen über RDP (Remote Desktop Protocol) und WinRM (Windows Remote Management) zuständig. Durch einen Fehler im Umgang mit den Sitzungen (CVE-2018-0886) können Angreifer einen Man-in-the-Middle-Angriff ausführen und so die bestehende Sitzung übernehmen. Da RDP und WinRM häufig für administrative Zwecke genutzt wird, können sich so Unbefugte ggf. weitrechende Zugriffe auf die verwalteten Systeme beschaffen. Betroffen ist so ziemlich alles – vom einfachen Windows 7 über die Server-Produkte bis hin zum aktuellen 10 sowie Server 2016.

Fixing

Microsoft hat den Fix in mehreren Stufen ausgerollt. Erstmals erschienen passende Updates im März, welche das Problem prinzipiell beheben. Sofern sie überall installiert werden. Zwei Monate später, im Mai, zog der Hersteller dann die Sicherheitsschrauben an: Ab diesem Patch ist die Nutzung der Mitigation zwingend erforderlich.

Wer nicht plant guckt in die Röhre

Wer seine Systeme im Griff hat wird nicht viel merken – ist alles auf einem aktuellen Patchstand wird man von den Umstellungen nichts merken. Anders sieht es aus, wenn man bei den Updates nachlässig handelt. Hat der eigene Rechner bereits aktuelle Patches installiert, das Zielsystem jedoch seit März keine Wartung erfahren, hat man Pech: Der RDP-Client bzw. WinRM verweigern die Verbindung mit dem Zielsystem. “Die angeforderte Funktion wird nicht unterstützt”. Selbes dürfte auch für die andere Richtung gelten.

Und nu?

Was folgt sind zwei Dinge: Erst mal sollte man dem Verantwortlichen Admin des Zielsystems eine Schulung zu IT-Sicherheit verpassen, denn inzwischen mehr als ein halbes Jahr lang keine Updates installieren ist – zumindest meiner Meinung nach – grob fahrlässig. Danach sollte das Zielsystem natürlich auf einen aktuellen Stand gebracht werden – für den Zugriff mindestens notwendig ist der entsprechende CredSSP-Patch, welcher sich auch einzel im dazugehörigen Artikel finden lässt. Da für den nur ein Dopelklick notwendig ist kann das ggf. auch ein Poweruser mit passenden Zugriffen vor Ort erledigen. Hat man keine Möglichkeit das System selbst zu verändern muss man am Client ran: Hier kann man über die Registry oder per GPO auch unsichere Verbindungen zulassen und somit eine Verbindung zu den betroffenen Zielen wieder ermöglich. Dies sollte immer nur temporär geschehen – umstellen, verbinden, Fix installieren und wieder zurück. Keinesfalls sollte man während die Lockerung aktiv ist Verbindungen zu anderen Systemen aufbauen.

Registry

Hierzu liegt man unter HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters ein neues REG_DWORD mit dem Namen “AllowEncryptionOracle” an und gibt diesem den Wert “2“.

GPO

Das Pendant in GPO-Form findet sich unter Computerkonfiguration\Administrative Vorlagen\System\Delegierung von Anmeldeinformationen\Encryption Oracle Remediation. Diese muss aktiviert und die Schutzebene auf “Vulnerable” eingestellt werden.

EOF

Patchmanagement etablieren. Systeme zeitnah Patchen. Spart Arbeit. Und Axteinsätze bein den zuständigen Systembetreuern.

BitBasics – ESP8266 – 1a2: Windows-Treiber für Arduino-Boards finden (NodeMCU, Wemos, ProMini,…)

BitBasics - ESP8266 - 1a2: Windows-Treiber für Arduino-Boards finden (NodeMCU, Wemos, ProMini,…)

(49 MB) 00:06:20

2018-02-25 12:00 🛈
Einen Arduino unter Windows zu betreiben ist meist ganz einfach: Einstecken und los geht es – zumindest beim Original. Wer andere Boards wie den ESP8266 oder eines der vielen Arduino-Nachbauten verwenden möchte wird oft auf das Problem stoßen, dass Windows die nötigen Treiber nicht automatisch finden kann. In diesem Video zeige ich wie man den zuständigen USB-Controller des Boards findet, wo man passende Treiber herbekommt und wie man die bekanntesten installiert.

Treiber-Links

BitBasics – ESP8266 – 1a1: Arduino Installation und Einrichtung unter Windows

BitBasics - ESP8266 - 1a1: Arduino Installation und Einrichtung unter Windows

(40 MB) 00:06:08

2018-02-25 11:00 🛈
Um mit dem ESP8266 zu starten benötigen wir eine Programmierumgebung. In meiner Serie werde ich auf Arduino aufbauen, eine der verbreitetsten Systeme für den ESP und viele andere Mikrocontroller. In diesem Video zeige ich die Installation der Arduino-Umgebung und der nötigen Zusätze für den ESP8266 unter Windows.

Links:

Deinstallation von Kaspersky Endpoint / Total / Select Security

Wenn es eine Software gibt, welche potentiell mehr Schaden anrichten kann und schwerer zu entfernen ist als ein Virus, dann handelt es sich um ein Produkt aus der Schlangenölbranche. Ein besonderes Schätzchen ist hier Kaspersky, deren Firmenchef sich gerne als Gehilfe diverser Dienste positioniert und aktuell unter Beschuss steht. Aber genug Themenausflug – mein Wunsch ist schnell definiert: Deinstallieren. Vorzugsweise automatisch. Nicht wegen den aktuellen Problemen, sondern eher da die Systeme sauber sein sollen.

Kaspersky besteht dabei in der Business-Variante aus drei Teilen:

Das Kaspersky Security Center (KSC, ehemals Kaspersky Administration Kit oder auch KAK), welches zentral installiert ist und für Management und Deployment zuständig ist

Der Kaspersky Administration Agent, einem kleinen Tool, welches auf allen Rechnern installiert ist und primär die Verbindung zwischen dem Security Center und den Schutzprogrammen des Rechners herstellt. Weiterhin kann es zur Installation von beliebigen Programmen und Patches genutzt werden.

Zuletzt das eigentliche Schutzprogramm, auf Nutzerseite meist Kaspersky Endpoint Security, welches Dienste wie Signaturscan, Software-Firewall und Gerätekontrolle bereitstellt.

Leider ist das Management an vielen Stellen trotz der langen Reife noch ausbaufähig. Verschiedene Sprachversionen oder gar Rechner mit unterschiedlichen Service-Packs der Software lassen sich nur schwer gemeinsam verwalten oder gegeneinander austauschen, die Managementverbindung geht gerne mal verloren und für die Rechnergeschwindigkeit ist eine solche Software ebenfalls nur wenig zuträglich.

Zur Deinstallation hatte ich hierzu üblicherweise eine “Geheimwaffe”: Den KAVRemover. Dieses Tool des Herstellers ist in der Lage viele Installationen auf dem verwendeten Rechner mit einem Schlag zu entfernen. Aus Sicherheitsgründen hat sich der Hersteller jedoch dazu entschieden die Deinstallation mit einem CAPTCHA abzusichern. Da ich nun eine größere Charge Rechner vor mir hatte tut diese Unmöglichkeit der Automation natürlich weh. Also ran an die offiziellen Deinstallationsroutinen.

Erstes Problem: Passwörter. Insgesamt gibt es 2-3 Passwortebenen, mit denen eine lokale Installation im genannten Konstrukt geschützt ist:

Endpoint Security nutzt, wenn in der entsprechenden Policy angegeben, einen Passwortzugang zu allen administrativen Funktionen. Dieses wird auch zur Deinstallation benötigt. Bei neueren Versionen (ab 10.2ish) wird zusätzlich ein Benutzername verlangt, welcher jedoch augenscheinlich auf “KLAdmin” hardcoded ist.

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2016/07/kavmenu-300×70.pngIst dieses Passwort nicht bekannt, jedoch Zugang und Verbindung zum Security Center noch vorhanden, kann man den Passwortschutz per Policy einfach ausschalten und so die Deinstallation etwas vereinfachen. Hierzu öffnet man die zum Produkt gehörende Policy und entfernt unter “Advanced Settings” -> “Interface” die Checkbox “Enable password protection”. Dies muss selbstverständlich für jede Sprache und Service-Pack-Version wiederholt werden.

Der Administration Agent nutzt eine separate Policy und hat ein dediziertes Passwort für die Deinstallation gesetzt. Ob sich dies ebenfalls irgendwo abschalten lässt habe ich nicht geprüft.

Das Passwort lässt sich glücklicherweise bei der Deinstallation als Parameter – natürlich je nach Version mit anderem Namen – angeben. Um die Funktion nutzen zu können muss man das Passwort jedoch vorher umrechnen: Es muss als ASCII-String einer HEX-Repräsentation des Passworts als 16Bit-ASCIIish (sieht aus wie ein Byte-Invertiertes UTF16) eingetragen werden. Besser keine Fragen stellen.

Also rechnen wir mal: Wäre unser Passwort “Geheim” müssen wir dies erst mal in Hex konvertieren. Hierzu kann man – bei einfachen Zeichen – die gute, alte ASCII-Tabelle bemühen. G ist in HEX 0x47, e 0x65 – und so weiter. Am Ende erhalten wir “47 65 68 65 69 6D”. Da wir jedoch noch die 00en für 16 Bit brauchen wird daraus ein “470065006800650069006D00”. Mit diesem String können wir dann weiter an’s Werk. Zu beachten ist, dass einige Versionen der 10er-Serie (10.0.3361) zwischendrin plötzlich mal nur 8 Bit brauchten um beim nächsten Update wieder auf 16 zu springen. Kurzfassung: Wenns nicht geht einfach anders nochmal versuchen.

Für die Deinstallationen benötigt man weiterhin die MSI-IDs der Produkte. Einige seien hier mal gelistet, wer weitere hat: Die Kommentare stehen offen. Wer sich nicht sicher ist sollte in der Registry unter HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall und HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall nach Kaspersky-Einträgen suchen.

Danke an dawinci für das Listen der auswärtigen Agent-IDs

  • Kaspersky Endpoint Security 8.x Deutsch
    • {D72DD679-A3EC-4FCF-AFAF-12E2552450B6}
  • Kaspersky Endpoint Security 10.x (Deutsch, 64Bit)
    • {04CF7FBD-E56C-446D-8FC9-DD444BDBEE8E}
  • Kaspersky Endpoint Security 10.x (English, 32Bit)
    • {7A4192A1-84C4-4E90-A31B-B4847CA8E23A}
  • Kaspersky Admin Agent 9.x/10.x (Deutsch)
    • {2F383CB3-6D7C-449D-9874-164E49E1E0F5}
  • Kaspersky Admin Agent 9.x/10.x (English)
    • {BCF4CF24-88AB-45E1-A6E6-40C8278A70C5}
  • Kaspersky Admin Agent 9.x/10.x (Arabisch)
    • {FA7BF140-F356-404A-BDA3-3EF0878D7C63}
  • Kaspersky Admin Agent 9.x/10.x (Bulgarisch)
    • {4DBF6741-FA51-4C14-AFD2-B7D9246995F6}
  • Kaspersky Admin Agent 9.x/10.x (Tschechisch)
    • {478A6A0B-D177-4402-B703-808C05C56B13}
  • Kaspersky Admin Agent 9.x/10.x (Französisch)
    • {2924BEDA-E0D7-4DAF-A224-50D2E0B12F5B}
  • Kaspersky Admin Agent 9.x/10.x (Ungarisch)
    • {8899A4D4-D678-49F8-AD96-0B784F58D355}
  • Kaspersky Admin Agent 9.x/10.x (Italiänisch)
    • {DC3A3164-36B3-4FB4-B7BF-16A41C35A728}
  • Kaspersky Admin Agent 9.x/10.x (Japanisch)
    • {790C176F-7780-4C84-8B9C-455F5C0E61C5}
  • Kaspersky Admin Agent 9.x/10.x (Koreanisch)
    • {70812A40-973B-4DA1-96B9-C2011280CD99}
  • Kaspersky Admin Agent 9.x/10.x (Polnisch)
    • {1A7B331A-ABBE-4230-995E-BCD99C5A18CF}
  • Kaspersky Admin Agent 9.x/10.x (Portugiesisch / Brasilien)
    • {0F05E4E5-5A89-482C-9A62-47CC58643788}
  • Kaspersky Admin Agent 9.x/10.x (Rumänisch)
    • {FF802D76-E241-41D3-AAB4-DC7FBD659446}
  • Kaspersky Admin Agent 9.x/10.x (Russisch)
    • {ED1C2D7E-5C7A-48D8-A697-57D1C080ABA7}
  • Kaspersky Admin Agent 9.x/10.x (Chinesisch, vereinfacht)
    • {FBD7C01E-49CB-4182-8714-9DB1EAE255CB}
  • Kaspersky Admin Agent 9.x/10.x (Chinesisch, Traditionell)
    • {F6AD731A-36B4-4739-B1D4-70D6EDA35147}
  • Kaspersky Admin Agent 9.x/10.x (Spanisch / Mexiko)
    • {29748B5F-D88A-4933-B614-1CCCD6EFB0B7}
  • Kaspersky Admin Agent 9.x/10.x (Türkisch)
    • {2475A66D-698B-4050-93FF-9B48EE82E2BA}

Die Deinstallationsbefehle für die Endpoint Security lauten:

  • Kein Passwort
    • MsiExec.exe /x {MSI-ID} /qb- REBOOT=ReallySuppress
  • Nur Passwort
    • MsiExec.exe /x {MSI-ID} /qb- REBOOT=ReallySuppress KLPASSWDHEX=470065006800650069006D00
    • bzw. MsiExec.exe /x {MSI-ID} /qb- REBOOT=ReallySuppress KLPASSWDHEX=47656865696D
    • Alternativ kann man bei KES statt KLPASSWDHEX die Variable KLPASSWD verwenden und das Kennwort in Klartext angeben
  • Nutzername + Passwort
    • MsiExec.exe /x {MSI-ID} /qb- REBOOT=ReallySuppress KLLOGIN=KLAdmin KLPASSWDHEX=470065006800650069006D00

Für den Kaspersky Administration Agent lauten die Befehle:

  • Ohne Passwort
    • MsiExec.exe /x {MSI-ID} /qb- REBOOT=ReallySuppress
  • Mit Passwort
    • MsiExec.exe /x {MSI-ID} /qb- REBOOT=ReallySuppress KLUNINSTPASSWD=470065006800650069006D00

Beim Admin-Agent schlägt die Installation teilweise trotz richtigem Passwort mit dem Exit-Code 1603 fehl. In dem Fall kann es helfen einfach mal bis 10 zu zählen und die Deinstallation nochmal zu starten.

Bei /qb- wird ein Fortschrittsbalken angezeigt, welcher leider auch “abbrechen” ermöglicht. Alternative /qn komplett im Hintergrund.

In meinem Fall habe ich eine Loop, welche für jede bekannte MSI-ID alle Deinstallationsbefehle mehrmals durchprobiert. Bei ca. 90% der Rechner funktioniert holzhammer(); – immerhin etwas weniger Arbeit.

Windows: Wo ist Java?

Ich bin von Linux ja irgendwie verwöhnt: Alle Binärdateien sind üblicherweise unter /usr/bin und lassen sich direkt über den Namen des Programms aufrufen. Unter Windows gibt es mit $PATH zwar eine ähnliche Funktion, jedoch ist dort meist nur der Systempfad eingetragen. Da es für fast jedes Programm ein eigenes Verzeichnis gibt hat man so keine direkte Möglichkeit ein Programm zu starten ohne an den Systemvariabeln herumzueditieren.

In vielen Fällen nicht wirklich ein Problem – einmal gefunden kann man den Pfad in seinen Scripten hinterlegen und so die Software ansprechen. Leider ist das bei Programmen wie Java nicht so einfach: Diese legen ein Verzeichnis mit der Versionsnummer an, z.B. C:\Program Files\Java\jre_8.0.121\bin\java.exe. Ergebnis: Nach jedem Update versteckt sich die gesuchte EXE an einer anderen Stelle.

Hier ein Quick&Dirty CMD, welches die Java-Binary aufspüren sollte. Nicht Ideal, da z.B. nur das Systemlaufwerk unterstützt wird und diverses Errorhandling fehlt, aber immerhin zuverlässiger als hardcoded…

REM Find Java :/
pushd "%ProgramFiles%\java\jre*\bin\"
echo %JAVADIR%cd > %TEMP%\findjava.txt
set /p JAVADIR=<%TEMP%\findjava.txt
del %TEMP%\findjava.txt
popd
%JAVADIR%\java -jar meinesoftware.jar

 

YubiKey: GPG-Kartenfehler / Sharing Violation unter Windows

Ugh – Windows und Sicherheitsfunktionen passt irgendwie immer noch nicht zusammen. Schon länger nutze ich einen YubiKey als GPG-Smartcard um E-Mails zu signieren und entschlüsseln. Das funktionierte mit GPG4Win und Thunderbird bisher auch recht brauchbar – also bis auf den Windows-GPG-Agent-Bug.

Wie gesagt: Bisher. Heute dann ein etwas seltsamer Bug:

# gpg --card-status
gpg: selecting openpgp failed: Card error
gpg: OpenPGP card not available: Card error

Wat. Schnell nochmal den Daemon durchstarten: Nix. Im Log findet man folgende Info:

scdaemon: pcsc_connect failed: sharing violation (0x8010000b)
scdaemon: reader slot 0: not connected

Bild: https://www.adlerweb.info/blog/wp-content/uploads/2017/02/wp-1485952629803-300×225.jpgWait. Sharing violation? Greift sonst noch wer zu? Jepp, natürlich tut das Jemand. Ich hatte zwischenzeitlich auf dem YubiKey für ein anderes System X.509-Zertifikate (aka PIV) eingerichtet. Diese kommen z.B. zur Authentifizierung zum Einsatz und können unter Windows auch z.B. für Remote-Logins und das entschlüsseln von Bitlocker-Festplatten verwendet werden. Entsprechend hat nun also auch Windows die PIV-Smartcard gefunden und belagert das Device dauerhaft – somit ist der Zugriff für gpg nicht mehr möglich. Abhilfe schafft hier den Dienst “CertPropSvc” (aka “Zertifikatverteilung”) zu beenden bzw. neuzustarten. In letzterem Fall bleibt das Gerät frei bis man die nächste Software mit PIV-Zugriff (z.B. Remotedesktop) startet.

Also als weiterer Punkt auf dem nicht enden wollenden Wunschzettel für einen würdigen Nachfolger für die leider sicherheitstechnisch bedenklich gewordenen YubiKeys: Parallelität der SC-Reader…

Windows/GPG/Smartcard – GPG mit Powershell bei SC-Verbindung neu starten

Beim Thema E-Mail-Verschlüsselung ist GPG weit verbreitet. Die Gundfunktionen sind z.B. mit Thunderbird und Enigmail oder gar eine Appliance auch für Einsteiger nutzbar und durch das WoT erstpart man sich die Abhängigkeit von – teils Zweifelhaften – zentralen Zertifizierungsstellen. Ich selbst nutze seit einiger Zeit keinen Softwareschlüssel sondern ein dediziertes HSM (Hardware Security Module) in Form eines YubiKey. Hiermit befindet sich der Key nicht mehr auf dem PC und auch die Verschlüsselung/Signierung läuft in Teilen auf dem Prozessor des YubiKey. Was unter Linux ohne große Änderungen funktioniert macht bei Windows eher wenig Spaß. Zwar ist auch GPG4Win in der Lage mit CryptoCards & Co umzugehen, häufiges Ein- und Ausstecken führt jedoch schnell zu einem hängenden GPG-Agent oder Absturzen der scdaemon.exe (GPG SmartCard Daemon). Einzige Abhilfe: Alle GPG-Prozesse beenden und neu starten. Da Verschlüsselung und Windows ohnehin eher selten zu finden ist sind auch Informationen dazu dünn gesät. Da ich teilweise um das System aus Redmond nicht herum komme und ein Fix in GPG4Win nicht in Sichtweite ist muss also wieder einmal der Holzhammer her: Irgendwie muss beim Einstecken des USB-Gerätes das GPG-System zurückgesetzt werden.

Also frisch ans Werk. Als Sprache soll mal wieder Powershell herhalten – direkt verfügbar, halbwegs systemnah, sollte passen. Über WMI kann man sich auch über ab- und angesteckte Geräte informieren lassen. Leider konnte ich keine Möglichkeit finden weitere Infos wie z.B. Hersteller oder Treiber gleich mit zu erhalten. Da sonst eher wenig Gerätefluktuation zu erwarten ist ziehe ich die “passt scho”-Karte und werde das GPG-System bei jedem neu auftauchenden Gerät einmal zurücksetzen.

#Requires -version 2.0
Register-WmiEvent -Class Win32_DeviceChangeEvent -SourceIdentifier deviceChange
write-host (get-date -format s) " Beginning script..."
do {
    $newEvent = Wait-Event -SourceIdentifier deviceChange
    $eventType = $newEvent.SourceEventArgs.NewEvent.EventType
    $eventTypeName = switch($eventType) {
        1 {"Configuration changed"}
        2 {"Device arrival"}
        3 {"Device removal"}
        4 {"docking"}
    }
    write-host (get-date -format s) " Event detected = " $eventTypeName

    $newEvent.SourceEventArgs.NewEvent | fl

    if ($eventType -eq 2) {
            write-host (get-date -format s) " Starting task in 3 seconds..."
            start-sleep -seconds 3
            taskkill /T /F /IM gpg-agent.exe
            taskkill /T /F /IM scdaemon.exe
            taskkill /T /F /IM kleopatra.exe

            start -FilePath 'C:\Program Files (x86)\GNU\GnuPG\gpg-agent.exe' -ArgumentList '--daemon' -WorkingDirectory 'C:\Program Files (x86)\GNU\GnuPG\' -LoadUserProfile -WindowStyle Minimized
    }
    Remove-Event -SourceIdentifier deviceChange
} while (1-eq1) #Loop until next event
Unregister-Event -SourceIdentifier deviceChange

Das Grundkonstrukt selbst scheint von Andy.L13 zu stammen, die kläglichen versuche von Mass-Storage auf andere USB-Geräte umzustellen stammen von mir. In Zeile 24 kann man für WindowStyle statt Minimized auch Hidden nutzen um das Ganze im Hintergrund laufen zu lassen – ich bevorzuge ein optisches Feedback. Das Script kann passend in Autostart oder als geplanter Task verstaut werden.

Sicher keine saubere Lösung, aber “works for me”.


Edit: Stackoverflow (bzw warriorpostman) liefert

Das folgende Script reagiert nur noch auf den vom YubiKey emulierten Smartcard-Reader. Das Objekt $Event.SourceEventArgs.NewEvent.TargetInstance sieht wie folgt aus – die Informationen für’s Query sollten sich im Gerätemanager finden lassen:

__GENUS                     : 2
__CLASS                     : Win32_PnPEntity
__SUPERCLASS                : CIM_LogicalDevice
__DYNASTY                   : CIM_ManagedSystemElement
__RELPATH                   : Win32_PnPEntity.DeviceID="USB\\VID_1050&PID_0116&MI_02\\6&***&0&0002"
__PROPERTY_COUNT            : 24
__DERIVATION                : {CIM_LogicalDevice, CIM_LogicalElement, CIM_ManagedSystemElement}
__SERVER                    : TESTRECHNER
__NAMESPACE                 : root\CIMV2
__PATH                      : \\TESTRECHNER\root\CIMV2:Win32_PnPEntity.DeviceID="USB\\VID_1050&PID_0116&MI_02\\6&***&0&0002"
Availability                : 
Caption                     : Microsoft Usbccid-Smartcard-Leser (WUDF)
ClassGuid                   : {50dd5230-ba8a-11d1-bf5d-0000f805f530}
CompatibleID                : {USB\Class_0b&SubClass_00&Prot_00, USB\Class_0b&SubClass_00, USB\Class_0b}
ConfigManagerErrorCode      : 0
ConfigManagerUserConfig     : False
CreationClassName           : Win32_PnPEntity
Description                 : Microsoft Usbccid-Smartcard-Leser (WUDF)
DeviceID                    : USB\VID_1050&PID_0116&MI_02\6&***&0&0002
ErrorCleared                : 
ErrorDescription            : 
HardwareID                  : {USB\VID_1050&PID_0116&REV_***&MI_02, USB\VID_1050&PID_0116&MI_02}
InstallDate                 : 
LastErrorCode               : 
Manufacturer                : Microsoft
Name                        : Microsoft Usbccid-Smartcard-Leser (WUDF)
PNPDeviceID                 : USB\VID_1050&PID_0116&MI_02\6&***&0&0002
PowerManagementCapabilities : 
PowerManagementSupported    : 
Service                     : WUDFRd
Status                      : OK
StatusInfo                  : 
SystemCreationClassName     : Win32_ComputerSystem
SystemName                  : TESTRECHNER
PSComputerName              : TESTRECHNER

Ich werde mich am Service WUDFRd (aka Gerät mit Windows SmartCard-Treber) orientieren. Prinzipiell könne man aber auch auf die USB-ID triggern uns so Scripte bauen, welche bei einstecken eines USB-Sticks ein Backup durchführen oder bei verbinden einer unbekannten USB-Tastatur entsprechend reagieren (böse Ente). Das zugehörige Script:

$query =  "Select * FROM __InstanceCreationEvent WITHIN 2 WHERE TargetInstance ISA 'Win32_PnPEntity' AND TargetInstance.Service = 'WUDFRd'"

if( Get-EventSubscriber | Where-Object {$_.SourceIdentifier -eq "YubiHammer"}) {
    Unregister-Event YubiHammer
}

Register-WmiEvent -Query $query -SourceIdentifier YubiHammer -Action{
    $Global:RemoteProcMon=$event 

    start-sleep -seconds 3
    taskkill /T /F /IM gpg-agent.exe
    taskkill /T /F /IM scdaemon.exe
    taskkill /T /F /IM kleopatra.exe

    start -FilePath 'C:\Program Files (x86)\GNU\GnuPG\gpg-agent.exe' -ArgumentList '--daemon' -WorkingDirectory 'C:\Program Files (x86)\GNU\GnuPG\' -LoadUserProfile -WindowStyle Minimized
}