Skip to content

Drucksache: windows.developer Magazin 5.2014 - PowerShell sicher einsetzen

Im windows.developer 5.2014 ist ein Artikel über die Sicherheit der PowerShell erschienen: Wie wird die PowerShell vor Missbrauch geschützt, welche Angriffe auf/über die PowerShell gibt es, und auf was muss man bei ihrem Einsatz achten?

Die PowerShell ist, wie der Name schon nahe legt, ein sehr mächtiges Werkzeug. So etwas reizt natürlich auch die Cyberkriminellen, denn was Entwickler und Benutzer im positiven nutzen, lässt sich natürlich genau so gut auch für bösartige Zwecke missbrauchen. Besonders die Möglichkeit, die Shell über Skripte zu steuern, lockt natürlich Angreifer an.

Update: Es gibt nicht 1, sondern 2 Schädlinge

Aus aktuellen Anlass hier ein Nachtrag zum Artikel. Am Anfang steht, dass eine schnelle Recherche nur einen tatsächlichen Schädling zum Vorschein gebracht hat, der die PowerShell nutz: Eine russische Ransomware verwendet die PowerShell zum Verschlüsseln bestimmter Dateien.

Inzwischen gibt es einen zweiten Schädling, der auf die PowerShell zurück greift: Trend Micro hat Ende März einen Wurm entdeckt, der alle seine Aktionen nicht über eigenen Code, sondern die PowerShell ausführt. Der Schädling kommt als infizierte Word- oder Excel-Datei auf den Rechner und lädt ein PowerShell-Skript nach, über dass dann die Aktionen wie zum Beispiel das Sammeln von Informationen und die Infektion vorhandener Word- und Excel-Dateien durchgeführt werden.

Nachtrag 8.4.:
Symantec hat einen weiteren die PowerShell nutzenden Schädling entdeckt: Eine Backdoor.
Ende des Nachtrags vom 8.4..

Das darf man aber zumindest aus PowerShell-Sicht nicht überbewerten. Ich zitiere dazu einfach mal aus meinen Fazit zum Artikel:

"Über bereits auf den Rechner eingedrungene Angreifer oder eingeschleusten Schadcode müssen Sie sich dagegen wenig Gedanken machen - wer bereits Programme starten und Code ausführen kann, kann jede Menge Schaden anrichten. Ganz unabhängig davon, ob er die PowerShell nutzt oder nicht."

Oder anders formuliert: Schadsoftware will man sowieso nicht auf seinem Rechner haben. Egal wie die ihre Schadfunktionen ausführt.

Und hier noch die Links und Literaturverweise aus dem Artikel:

Nachtrag 7.4.:
Ein Thema ist im Artikel leider "untergegangen": PowerShell Remoting. Das hatte ich erst oben erwähnt, dann aber wieder gelöscht. Stattdessen wollte ich es im Fazit erwähnen, habe es da aber dann vergessen.

Prinzipiell gilt für jeden Remote-Zugang zu einer Shell, dass er gut gesichert sein muss und nur über eine verschlüsselte Verbindung genutzt werden darf. PowerShell Remoting ist in dieser Hinsicht gut ausgestattet: Das verwendete Windows Remote Management (WinRM) akzeptiert nur verschlüsselte Verbindungen (über Negotiate oder Kerberos Security Service Provider (SSP)), außerdem kann zusätzlich HTTPS verwendet werden. Für die Authentifizierung wird Kerberos verwendet (ansonsten gilt das im Artikel zur Authentifizierung geschriebene), und es wird kein interaktives LogOn, sondern nur ein Netzwerk-LogOn verwendet. Es können also Befehle auf dem entfernten Rechner ausgeführt werden, von diesem aus aber keine Verbindungen zu weiteren Rechnern aufgebaut werden.
Welche Vorteile PowerShell Remoting insbesondere im Rahmen des "Incident Response" hat, wird in einem Artikel im Blog "SANS Digital Forensics and Incident Response" beschrieben (Vielen Dank an @PeterKriegel für den Tipp, durch den mir auch erst aufgefallen ist, dass mir PowerShell Remoting unter den Tisch gefallen ist).
Ende des Nachtrags vom 7.4..

Carsten Eilers

Trackbacks