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:
- [1] Don Jones: "Windows PowerShell: Sichern der Shell"
- [2] Anand Ajjan, Sophos Naked Security: "Russian ransomware takes advantage of Windows PowerShell"
- [3] Running Windows PowerShell Scripts
- [4] Don Jones: "Windows PowerShell: Abwehren von schädlichem Code"
- [5] Windows PowerShell 4.0: about_Execution_Policies
- [6] Don Jones: "Windows PowerShell: Hier signieren, bitte"
- [7] Carlos Perez: "PowerShell Basics - Execution Policy and Code Signing Part 2"
- [8] Lee Holmes, Windows PowerShell Blog: "PowerShell’s Security Guiding Principles"
- [9] David Kennedy, Joshua Kelley; Black Hat USA 2010: "Microsoft Powershell - It's time to own"
- [10] Get-Credential
- [11] ConvertTo-SecureString
- [12] ConvertFrom-SecureString
- [13] Carsten Eilers: "How to write Secure Code: DPAPI"
- [14] Read-Host
- [15] Lee Holmes, Windows PowerShell Blog: "PowerShell Security Best Practices"
- [16] Windows Vista Authentication Features and Changes for Developers - Credential Security Service Provider (CredSSP)
- [17] Ed Wilson, Hey, Scripting Guy! Blog: "Enable PowerShell "Second-Hop" Functionality with CredSSP"
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..
Trackbacks
Dipl.-Inform. Carsten Eilers am : Kommentare zu OpenSSL, Heartbleed, Windows PowerShell und einem Android-Schädling
Vorschau anzeigen