[o1] TiKu am 09.12. 11:50
+8
-11
[re:1] Helmut Baumann am 09.12. 12:15
@Helmut Baumann: Leider scheint hier keiner mehr qualifizierte Kommentare abzugeben...
Die Powershell ist zwar deutlich mächtiger gleichzeitig aber auch sehr viel sicherer als die alte CMD Shell über die auch ohne das Umgehen von Sicherheitsmaßnahmen alle möglichen Skripte ausgeführt werden können!
Die Powershell ist zwar deutlich mächtiger gleichzeitig aber auch sehr viel sicherer als die alte CMD Shell über die auch ohne das Umgehen von Sicherheitsmaßnahmen alle möglichen Skripte ausgeführt werden können!
@Themis: powershell -Command "(New-Object Net.WebClient).DownloadFile('http-quelle', 'zieldatei')" ergibt exakt zero rueckmeldungen und laedt ohne meckern jeden sch**ss runter... soviel zum thema sicherheit
@laforma: Browser sind noch unsicherer. http-link anklicken und schon hast du nen Virus runtergeladen. Nur das Nutzer der PS eben meist ungefähr wissen, was sie da tun.
@Bautz: Du hast nur scheinbar übersehen das der Aufruf eines HTTP Links maximal zu einem Download (eher zur einer Nachfrage ob und wohin etwas geladen werden soll) führt. Ausgeführt wird die Datei aber nicht. Dazu braucht es eine mind. eine eher mehrere Sicherheitlücken. Bei Powershell ist das nicht der Fall. Da reichte ein noramler User aus der einen Anhang öffnet. Daher schlecht vergleichbar. Das hat auch nichts damit zu tun ob man Powershell Nutzer ist oder nicht. Es ist in Windows fest eingebaut und kann von Schadsoftware genutzt von PowerShell Nutzern wie auch von nicht Nutzern.
@Helmut Baumann: ich staune immer wieder, wo all die Leute herkommen, welche einfach nur alberne oder gar dumme Kommentare ständig als Ironie ansehen. Es scheinen doch jeden Tag neue Langzeitkomapatienten aufzuwachen und sich stracks in die Foren dieser Welt zu begeben - und viele sind nicht wirklich wach :-P
Kein einziges Wort dazu, wie die Powershell nun angreifbar sein soll...
Wird sie per Script angegriffen, so dass der (unbedarfte) Nutzer aktiv tätig werden muss, oder wird sie über allgemeine Schwachstellen angegriffen? Muss der Nutzer händisch die Sicherheitspolicy anpassen, oder ist diese nicht ausreichend, bzw. umgehbar?
Dieser Artikel enthält keinen einzigen Fakt, oder übersehe ich da irgendwas? Für mich sieht das einfach nur nach ein bisschen Werbung für Symantec aus...
Wird sie per Script angegriffen, so dass der (unbedarfte) Nutzer aktiv tätig werden muss, oder wird sie über allgemeine Schwachstellen angegriffen? Muss der Nutzer händisch die Sicherheitspolicy anpassen, oder ist diese nicht ausreichend, bzw. umgehbar?
Dieser Artikel enthält keinen einzigen Fakt, oder übersehe ich da irgendwas? Für mich sieht das einfach nur nach ein bisschen Werbung für Symantec aus...
@Sy: Wenn etwas für uns zu überwältigend, zu schmerzhaft ist,
leugnen wir es und glauben lieber an etwas anderes.
leugnen wir es und glauben lieber an etwas anderes.
@Gast11962: Sy hat Recht der Artikel ist dürftig. Seine Fragen sind berechtigt und stellen keineswegs eine Leugnung von Sicherheitsproblemen dar. Deine Reaktion auf Sys Post ist dürftig
Standardmässig führt die PS keine Scripte aus. Die Executionpolicy muss händisch angepaßt werden. Arbeite man mit signierten Scripten und der entsprechenden Executionspolicy dürfte es schwierig sein externe Malwarescripten zum Laufen zubringen.
Ebenso ist es ein Unterschied ob PS im User- oder im Administratorkontext ausgeführt.
Zugefügt:
Ich hab mal das Beispiel des verlinkten Reports nachgestellt.
Ergebnis
cmd.exe /c powershell -executionpolicy -noprofile
C:\irgendwas\Programm>powershell -executionpolicy -noprofile
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. Alle Rechte vorbehalten.
. : Die Datei "C:\Users\Hotzenplotz\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1" kann nicht geladen
werden, da die Ausführung von Skripts auf diesem System deaktiviert ist.
Weitere Informationen finden Sie unter "about_Execution_Policies"
(http://go.microsoft.com/fwlink/?LinkID=135170).
In Zeile:1 Zeichen:3
+ . 'C:\Users\Hotzenplotz\Documents\WindowsPowerShell\Microsoft.Pow ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : Sicherheitsfehler: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess
Das sieht mal übel nach Schwachstelle aus ;-)
Standardmässig führt die PS keine Scripte aus. Die Executionpolicy muss händisch angepaßt werden. Arbeite man mit signierten Scripten und der entsprechenden Executionspolicy dürfte es schwierig sein externe Malwarescripten zum Laufen zubringen.
Ebenso ist es ein Unterschied ob PS im User- oder im Administratorkontext ausgeführt.
Zugefügt:
Ich hab mal das Beispiel des verlinkten Reports nachgestellt.
Ergebnis
cmd.exe /c powershell -executionpolicy -noprofile
C:\irgendwas\Programm>powershell -executionpolicy -noprofile
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. Alle Rechte vorbehalten.
. : Die Datei "C:\Users\Hotzenplotz\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1" kann nicht geladen
werden, da die Ausführung von Skripts auf diesem System deaktiviert ist.
Weitere Informationen finden Sie unter "about_Execution_Policies"
(http://go.microsoft.com/fwlink/?LinkID=135170).
In Zeile:1 Zeichen:3
+ . 'C:\Users\Hotzenplotz\Documents\WindowsPowerShell\Microsoft.Pow ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : Sicherheitsfehler: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess
Das sieht mal übel nach Schwachstelle aus ;-)
@wori: Das Powershell ein Einfalltor für Schadsoftware ist , ist mit schon seit ~2013 bekannt, geht seit dem "Vierteljährlich" durch die Fachpresse!
Ich erinner gern an Win32/Bedep. (A -D) das reihenweise ohne Zutun der Nutzer Systeme mittels Powershell befallen hat, sie damit Kompromittiert hat!
Etwas nicht zu Wissen ist eine Sache, aufgrund dieses Nichtwissens einen Sachverhalt zu verleugnen, zusätzlich durch eine Unterstellung/Behauptung diesen zu Relativieren, ist einfach nur Krank!
Ich erinner gern an Win32/Bedep. (A -D) das reihenweise ohne Zutun der Nutzer Systeme mittels Powershell befallen hat, sie damit Kompromittiert hat!
Etwas nicht zu Wissen ist eine Sache, aufgrund dieses Nichtwissens einen Sachverhalt zu verleugnen, zusätzlich durch eine Unterstellung/Behauptung diesen zu Relativieren, ist einfach nur Krank!
@Gast11962: Aber dir ist schon aufgefallen, daß das Reportbeispiel nicht ausgeführt wurde.
Es ist eine Frage der Einstellungen ob Powershell ein Einfallstor ist.
Der User muss seinen Rechenr erst mit Win32/Bedep infizieren, damit diese Malware eine unzureichende Executionpolicy nutzen kann.
Ansonsten:
Etwas nicht zu Wissen ist eine Sache, aufgrund dieses Nichtwissens einen Sachverhalt zu verleugnen, zusätzlich durch eine Unterstellung/Behauptung diesen zu Relativieren, ist einfach nur krank!
Es ist eine Frage der Einstellungen ob Powershell ein Einfallstor ist.
Der User muss seinen Rechenr erst mit Win32/Bedep infizieren, damit diese Malware eine unzureichende Executionpolicy nutzen kann.
Ansonsten:
Etwas nicht zu Wissen ist eine Sache, aufgrund dieses Nichtwissens einen Sachverhalt zu verleugnen, zusätzlich durch eine Unterstellung/Behauptung diesen zu Relativieren, ist einfach nur krank!
@wori: ich hab eine kleine batch geschrieben, die ein patch fuer unsere kunden bei bedarf per ps script manuell runterlaedt - bei keinem kam die meldung das scripte nicht erlaubt sind. dies galt fuer admin wie auch user accounts. scheint also eine einstellung zu sein, die man explizit aktivieren muss. das hat dann nicht viel mit sicherheit zu tun, weil dies mit sicherheit nur ein bruchteil der user einstellt, da sie gar nicht wissen, dass es eine solche option gibt.
@laforma: Wobei du ja auch dann zugriff auf deren Systeme hattest bzw. sie dazu gebracht hast, irgendwas von dir bereitgestelltes auszuführen. Da brauchts keine Powershell um schaden anzurichten, es ist nur etwas bequemer.
@laforma: Beim mir ist die Defaulteinstellung. Dann hat jemand bei Euch die Executionpolicy per Profil geändert. Die Einstellungen macht in einem administrierten Windowsnetzwerk auch nicht der User. Kann er auch nicht. Das macht der Admin per Grouppolicies. Ebenso wie die Administration für die Sicherheit zuständig ist.
Aber nur mal angenommen man würde Powershell nicht brauchen, währe es denn nicht sinnvoll es vollständig Deinstallieren zu können bzw. vollständig zu Deaktivieren?
Das ist eben das Problem bei Windows, zufiele aufgezwungene Dienste die der Normalnutzer im Leben nicht braucht, öffnen wiederum zufiele Türen für Angreifer!
Aber anstatt das weniger wird, wird es immer mehr, um das dann zu beseitigen braucht man wiederum Powershell, "schon hat die Katze den eigenen Schwanz im Maul". :(
Das ist eben das Problem bei Windows, zufiele aufgezwungene Dienste die der Normalnutzer im Leben nicht braucht, öffnen wiederum zufiele Türen für Angreifer!
Aber anstatt das weniger wird, wird es immer mehr, um das dann zu beseitigen braucht man wiederum Powershell, "schon hat die Katze den eigenen Schwanz im Maul". :(
@Gast11962: Im Prinzip hast du recht. Allerdings steht die Ausführungsrichtlinie der PS standardmäßig auf restricted womit eigentlich keine Skripte ausführbar sein sollten. Im Firmenumfeld würde ich ausschließlich signierte Skripte zulassen und diesen Schutz wenn dann nur für kurze Tests deaktivieren oder in abgeschlossenen Umgebungen entschärfen.
Das Problem ist, dass es ein paar Möglichkeiten gibt diese Sicherheitsmaßnahme zu umgehen. Hier sollte Microsoft meiner Meinung nach ansetzen.
Das Problem ist, dass es ein paar Möglichkeiten gibt diese Sicherheitsmaßnahme zu umgehen. Hier sollte Microsoft meiner Meinung nach ansetzen.
@Themis: Das Microsoft nachbessern muss, ist doch nun wirklich keine Synapse wert um darüber nachzudenken!
Das ist keine TuDu Sache, sondern eine Verpflichtung die schnellst möglich umgesetzt gehört für Microsoft, alles andere währe groß fahrlässig!
Ich stelle Grundsätzlich die Maximum Installationen (je nach Version) infrage, die nur immer mehr die Stabilität und Sicherheit auf allen Ebenen gefährden, anstatt je nach Bedarf einzelne Dienste nach zu installierten, was ein System Schlank hält!
Das ist keine TuDu Sache, sondern eine Verpflichtung die schnellst möglich umgesetzt gehört für Microsoft, alles andere währe groß fahrlässig!
Ich stelle Grundsätzlich die Maximum Installationen (je nach Version) infrage, die nur immer mehr die Stabilität und Sicherheit auf allen Ebenen gefährden, anstatt je nach Bedarf einzelne Dienste nach zu installierten, was ein System Schlank hält!
@Gast11962: Wovon redest Du? Die ist schon umgesetzt.
Das passiert wenn ich auf meiner maschine ein Beispiel des Reports nachstelle:
cmd.exe /c powershell -executionpolicy -noprofile
C:\irgendwas\Programm>powershell -executionpolicy -noprofile
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. Alle Rechte vorbehalten.
. : Die Datei "C:\Users\Hotzenplotz\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1" kann nicht geladen
werden, da die Ausführung von Skripts auf diesem System deaktiviert ist.
Weitere Informationen finden Sie unter "about_Execution_Policies"
(http://go.microsoft.com/fwlink/?LinkID=135170).
In Zeile:1 Zeichen:3
+ . 'C:\Users\Hotzenplotz\Documents\WindowsPowerShell\Microsoft.Pow ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : Sicherheitsfehler: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess
Das passiert wenn ich auf meiner maschine ein Beispiel des Reports nachstelle:
cmd.exe /c powershell -executionpolicy -noprofile
C:\irgendwas\Programm>powershell -executionpolicy -noprofile
Windows PowerShell
Copyright (C) 2016 Microsoft Corporation. Alle Rechte vorbehalten.
. : Die Datei "C:\Users\Hotzenplotz\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1" kann nicht geladen
werden, da die Ausführung von Skripts auf diesem System deaktiviert ist.
Weitere Informationen finden Sie unter "about_Execution_Policies"
(http://go.microsoft.com/fwlink/?LinkID=135170).
In Zeile:1 Zeichen:3
+ . 'C:\Users\Hotzenplotz\Documents\WindowsPowerShell\Microsoft.Pow ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : Sicherheitsfehler: (:) [], PSSecurityException
+ FullyQualifiedErrorId : UnauthorizedAccess
Was für eine Clickbait überschrift... können wir als nächstes bitte einen Artikel dazu haben, dass 99,9% aller Malware direkt oder indirekt die Win32 API verwendet und diese daher abgeschafft werden sollte?
Was der Autor des Artikels glaube ich verkennt, ist die Werbeabsicht von Symantec. Der Originalartikel bezieht sich rein auf Angriffe aus Emails heraus und es werden entsprechende Lösungen des Unternehmens vorgeschlagen. Der Symantec Artikel stellt auch eindeutig klar, dass der eigentliche Angriff daraus besteht, dass in Spam-Emails Javascript oder Office Dokumente mit entsprechenden Makros zum Einsatz kommen die dann die Powershell instrumentalisieren. Die eigentliche Gefährlichkeit liegt also nicht an der Powershell sondern schon vorher. Gerade daher wünscht sich ja Symantec von den Nutzern ja auch "nur" die Powershell aktuell zu halten und bissle mehr Logging wäre schön. (Damit natürlich die eigenen Tools da besser Gefahren erkennen)
In keinster Weise kommt bei Symantec die Gefährlichkeit der Powershell rüber wie Winfuture es hier darstellen möchte. Weil die ist nicht gegeben. Mit den Policies etc. ist die Powershell weit sicherer als die bestehende Kommandozeile und die Möglichkeiten über den Windows Scripting Host Skripte auszuführen. Die Darstellung der Thematik hier auf Winfuture ist komplett verzerrt und im Satz " In den meisten Fällen geht es schlicht darum, dass aus Office-Makros oder in Webseiten eingebettete JavaScripts über PowerShell Downloader zum Einsatz gebracht werden, die dann weitere Routinen nachladen und zur Ausführung bringen." ist der Teil, dass die Powershell durch Javascript von Webseiten auf Clientseite instrumentalisiert werden kann, komplett falsch. Das ist technisch nicht möglich.
Die inhaltliche Qualität des Artikels ist echt bescheiden....
In keinster Weise kommt bei Symantec die Gefährlichkeit der Powershell rüber wie Winfuture es hier darstellen möchte. Weil die ist nicht gegeben. Mit den Policies etc. ist die Powershell weit sicherer als die bestehende Kommandozeile und die Möglichkeiten über den Windows Scripting Host Skripte auszuführen. Die Darstellung der Thematik hier auf Winfuture ist komplett verzerrt und im Satz " In den meisten Fällen geht es schlicht darum, dass aus Office-Makros oder in Webseiten eingebettete JavaScripts über PowerShell Downloader zum Einsatz gebracht werden, die dann weitere Routinen nachladen und zur Ausführung bringen." ist der Teil, dass die Powershell durch Javascript von Webseiten auf Clientseite instrumentalisiert werden kann, komplett falsch. Das ist technisch nicht möglich.
Die inhaltliche Qualität des Artikels ist echt bescheiden....
Wenn ein Angreifer in der Lage ist in das System einzudringen und Powershellkommandos in der Registry abzulegen, habe ich ganz andere Probleme als eine aktivierte PS. Und das Ganze ist das selbe unter Linux, Unix oder OSX: Angreifer mit Admin- oder Systemrechten können sich auch da nach Belieben austoben, wenn sie einmal drin sind