X
Kommentare zu:

Microsofts PowerShell wird zunehmend zu einem Sicherheits-Problem

oder

Zugangsdaten vergessen?

Jetzt kostenlos Registrieren!
[o1] TiKu am 09.12. 11:50
Na wie gut, dass die PowerShell gerade erst zur Standard-Shell gemacht wurde.
[re:1] Helmut Baumann am 09.12. 12:15
+5 -6
@TiKu: Leider scheint hier keiner mehr Ironie zu erkennen.
[re:1] Themis am 09.12. 12:52
+4 -3
@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!
[re:1] laforma am 09.12. 14:55
+3 -2
@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
[re:1] Bautz am 09.12. 15:27
+1 -3
@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.
[re:2] Nero FX am 09.12. 16:31
+2 -1
@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.
[re:3] eisteh am 12.12. 14:13
+ -
@Nero FX: Und führen sich diese Befehle einfach so aus, weil du deinen PC gerade hochgefahren hast? Da braucht es vorher auch einen Benutzer, der irgendwas ausführt oder anklickt. Durch die bloße Existenz der Powershell ist absolut nichts unsicherer als vorher.
[re:2] Drachen am 11.12. 14:10
+1 -
@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
[re:2] scar1 am 09.12. 12:33
+3 -1
@TiKu: das kratzt einen Angreifer glaub ich herzlich wenig ob die powershell-commandline dann die Standardshell ist oder ob einfach nur das Framework vorhanden ist.
[o2] Sy am 09.12. 11:58
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...
[re:1] Gast11962 am 09.12. 12:24
+1 -9
@Sy: Wenn etwas für uns zu überwältigend, zu schmerzhaft ist,
leugnen wir es und glauben lieber an etwas anderes.
[re:1] wori am 09.12. 12:55
+5 -
@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 ;-)
[re:1] Gast11962 am 09.12. 13:12
+1 -3
@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!
[re:1] wori am 09.12. 13:21
+1 -
@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!
[re:2] Gast11962 am 09.12. 13:22
+1 -3
@wori: So verzweifelt?
Tust mir echt Leid!
[re:3] wori am 09.12. 13:24
+1 -
@Gast11962: Starkes Argument und vorallem starke Ignoranz.
[re:4] laforma am 09.12. 15:02
+1 -2
@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.
[re:5] Bautz am 09.12. 15:30
+ -
@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.
[re:6] wori am 09.12. 16:35
+1 -
@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.
[o3] Gast11962 am 09.12. 12:17
+1 -4
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". :(
[re:1] Themis am 09.12. 12:47
+3 -1
@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.
[re:1] Gast11962 am 09.12. 13:02
+ -1
@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!
[re:1] wori am 09.12. 13:11
+1 -1
@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
[re:1] Gast11962 am 09.12. 13:20
+ -3
@wori: Also jetzt auch noch Unterstellungen, passt zu dir!
Ich habe nirgendwo die Behauptung aufgestellt, das Microsoft das Problem nicht korrigiert/behebt!

Mein Minus!
[re:2] wori am 09.12. 13:23
+2 -
@Gast11962: Störung im Leseverständnis?
Ich habe im meinem Post nicht behauptet, daß du irgendwo die Behauptung aufgestellt, das Microsoft das Problem nicht korrigiert/behebt!
[o4] Suchiman am 09.12. 12:53
+5 -4
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?
[re:1] laforma am 09.12. 15:06
+5 -
@Suchiman: 100% aller malware benutzt den verbauten ram...
[o5] Chuuei am 09.12. 15:13
+3 -
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....
[re:1] rallef am 25.12. 14:32
+ -
@Chuuei: Ich persönlich glaube ja, dass die Werbebotschaft durchaus bekannt und gewollt ist... und dass WF entsprechend eine kleine Gratifikation bekommt. Was durchaus legitim sein kann, wo wir doch alle mit Werbeblocker unterwegs sind.
[o6] rallef am 25.12. 14:38
+ -
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
☀ Tag- / 🌙 Nacht-Modus
Desktop-Version anzeigen
Impressum
Datenschutz
Cookies
© 2024 WinFuture