none
Powershell Security RRS feed

  • Frage

  • Hallo zusammen,

    wir handhabt ihr es mit der Powershell Security?

    wir hatten gestern zufällig einen Workshop besucht bei dem auch gezeigt wurde wie inzwischen Ransomware mittels Powershell verteilt wird bzw. mittels Powershell lokale Adminrechte erschlichen werden. Echt schlimm.

    Man könnte ja mittels GPO die CurrentUser und LocalMaschine auf Restricted setzen und wenn wir intern etwas ausführen müssen vorher ein unrestricted duchführen? Oder habt ihr bessere Ansätze.

    powershell Set-ExecutionPolicy unrestricted -scope CurrentUser -force
    powershell -f "\\ntsds\LogonTools\Scripts\ScanDirAmt.ps1"
    powershell Set-ExecutionPolicy undefined -scope CurrentUser -force


    Chris

    Donnerstag, 16. März 2017 13:27

Antworten

  • Hallo, 

    ich wäre mir gar nicht so sicher, dass die ExecutionPolicy wirklich ausreicht, um die Ausführung von Skripten zu unterbinden. Es gibt mehrere Wege, diese zu umgehen: Z.B. weil die PowerShell.exe der ExecutionPolicy nicht unterliegt, solange man nur Codezeilen ausführt, kann man beliebig viele Befehle direkt an die PowerShell.exe schicken.

    Hier gibt es sogar 15 Wege, die ExecutionPolicy zu umgehen (ohne dass ich sie getestet hätte)

    https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy/

    Viele Grüße

    Christoph 



    • Bearbeitet hpotsirhc Donnerstag, 16. März 2017 14:07
    • Als Antwort markiert -- Chris -- Donnerstag, 16. März 2017 14:33
    Donnerstag, 16. März 2017 14:06
  • Dazu betone ich immer: die Execution-Policy ist keine Sicherheitsmassnahme im eigentlichen Sinne und ist auch nicht so gedacht. Es ist mehr die etwas weitergehende Umsetzung von "Sind sie sicher?" in der Shell. Der Grund für die E-Policy ist der Ärger mit dem I-love-u-Virus und ähnlichem Getier, bzw. dem Bestreben zu verhindern das User oder Admins ungewollt Scriptcode ausführen.

    Die EP macht ein System nicht wirklich sicherer und ist in den meisten Fällen relativ leicht zu iumgehen (siehe: 15 Ways to Bypass the PowerShell Execution Policy ).
    Für die Sicherheit auf Windows ist das Windows Account Modell zuständig. Powershell erlaubt dem User/Admin nur soviel Schaden anzurichten wie der Account Rechte hat. Wenn er diese nicht hat, ist eigentlich auch keine Execution-Policy nötig. Wenn er sie hat, solte der User wissen was er tut. Du kannst mit Powershell nichts anrichten, was du nicht auch auf anderem Weg anrichten kannst.

    Lange Rede kurzer Sinn, bei mir steht das Ding für Server auf "Bypass". Bei Clients hängts vom DAU-Grad der User ab. Viel wichtiger als die EP ist aber ein vernünftiges Rechtemodell im Netzwerk.

    Grüße, Denniver


    Blog: http://bytecookie.wordpress.com

    Kostenloser Powershell Code Manager v5: Link
    (u.a. Codesnippets verwalten + komplexe Scripte graphisch darstellen)

    Hilf mit und markiere hilfreiche Beiträge mit dem "Abstimmen"-Button (links) und Beiträge die eine Frage von dir beantwortet haben, als "Antwort" (unten).
    Warum das Ganze? Hier gibts die Antwort.

    Donnerstag, 16. März 2017 14:25
    Moderator
  • > wenn du das gestern gesehen hätte wir die nicht einmal Profihacker es relativ einfach schaffen sich Zugang zum System und Adminrechten zu verschaffen, da läuft es einem kalt über den Rücken....
     
    Dann hakt es aber wo anders... Nicht bei der ExecutionPolicy.
     
    Restriktives Application Whitelisting (auch für Skripts!) ist für mich übrigens das Mittel der Wahl. Ein Standarduser darf nichts ausführen aus Speicherorten, wo er Schreibrechte hat.
     
    > Windows ist einfach nicht sicher. Daher so viele beschädigte Systeme.
     
    Das stimmt nicht. Aber Sicherheit ist immer unkomfortabel, deshalb ist der Default relativ unsicher konfiguriert. Sonst kommt der SOHO-User leicht in Rage :-)
     
    • Als Antwort markiert -- Chris -- Dienstag, 21. März 2017 06:46
    Donnerstag, 16. März 2017 16:19
  • > wenn du das gestern gesehen hätte wir die nicht einmal Profihacker es relativ einfach schaffen sich
    > Zugang zum System und Adminrechten zu verschaffen,

    Also das zu glauben, damit hab ich meine Schwierigkeiten. Nicht dir, sondern das das so einfach geht. Wäre mir zumindest neu.Von wem war denn der Workshop? Gibts dazu noch ein paar Details?

    Z.b. wäre es interessant ob da einem Account/dem Code wirklich mehr Rechte verliehen wurden. Oder wurde hier vielleicht nur z.b. ein Elevation-Prompt geschickt verschleiert?  Am ehesten kann ich mir vorstellen, das da ein bisher ungepatchter Bug ausgenutzt wird, ein prinzipielles Problem ist es denke ich nicht.

     Grüße, denniver

    Blog: http://bytecookie.wordpress.com

    Kostenloser Powershell Code Manager v5: Link
    (u.a. Codesnippets verwalten + komplexe Scripte graphisch darstellen)

    Hilf mit und markiere hilfreiche Beiträge mit dem "Abstimmen"-Button (links) und Beiträge die eine Frage von dir beantwortet haben, als "Antwort" (unten).
    Warum das Ganze? Hier gibts die Antwort.

    • Als Antwort markiert -- Chris -- Dienstag, 21. März 2017 06:45
    Donnerstag, 16. März 2017 18:49
    Moderator

Alle Antworten

  • Hallo, 

    ich wäre mir gar nicht so sicher, dass die ExecutionPolicy wirklich ausreicht, um die Ausführung von Skripten zu unterbinden. Es gibt mehrere Wege, diese zu umgehen: Z.B. weil die PowerShell.exe der ExecutionPolicy nicht unterliegt, solange man nur Codezeilen ausführt, kann man beliebig viele Befehle direkt an die PowerShell.exe schicken.

    Hier gibt es sogar 15 Wege, die ExecutionPolicy zu umgehen (ohne dass ich sie getestet hätte)

    https://blog.netspi.com/15-ways-to-bypass-the-powershell-execution-policy/

    Viele Grüße

    Christoph 



    • Bearbeitet hpotsirhc Donnerstag, 16. März 2017 14:07
    • Als Antwort markiert -- Chris -- Donnerstag, 16. März 2017 14:33
    Donnerstag, 16. März 2017 14:06
  • Dazu betone ich immer: die Execution-Policy ist keine Sicherheitsmassnahme im eigentlichen Sinne und ist auch nicht so gedacht. Es ist mehr die etwas weitergehende Umsetzung von "Sind sie sicher?" in der Shell. Der Grund für die E-Policy ist der Ärger mit dem I-love-u-Virus und ähnlichem Getier, bzw. dem Bestreben zu verhindern das User oder Admins ungewollt Scriptcode ausführen.

    Die EP macht ein System nicht wirklich sicherer und ist in den meisten Fällen relativ leicht zu iumgehen (siehe: 15 Ways to Bypass the PowerShell Execution Policy ).
    Für die Sicherheit auf Windows ist das Windows Account Modell zuständig. Powershell erlaubt dem User/Admin nur soviel Schaden anzurichten wie der Account Rechte hat. Wenn er diese nicht hat, ist eigentlich auch keine Execution-Policy nötig. Wenn er sie hat, solte der User wissen was er tut. Du kannst mit Powershell nichts anrichten, was du nicht auch auf anderem Weg anrichten kannst.

    Lange Rede kurzer Sinn, bei mir steht das Ding für Server auf "Bypass". Bei Clients hängts vom DAU-Grad der User ab. Viel wichtiger als die EP ist aber ein vernünftiges Rechtemodell im Netzwerk.

    Grüße, Denniver


    Blog: http://bytecookie.wordpress.com

    Kostenloser Powershell Code Manager v5: Link
    (u.a. Codesnippets verwalten + komplexe Scripte graphisch darstellen)

    Hilf mit und markiere hilfreiche Beiträge mit dem "Abstimmen"-Button (links) und Beiträge die eine Frage von dir beantwortet haben, als "Antwort" (unten).
    Warum das Ganze? Hier gibts die Antwort.

    Donnerstag, 16. März 2017 14:25
    Moderator
  • Danke für die Infos. Unsere User habe keine lokalen Adminrechte kein USB usw. (das half uns bisher dass wir von Ransomware verschont blieben), aber wenn du das gestern gesehen hätte wir die nicht einmal Profihacker es relativ einfach schaffen sich Zugang zum System und Adminrechten zu verschaffen, da läuft es einem kalt über den Rücken....

    Windows ist einfach nicht sicher. Daher so viele beschädigte Systeme.


    Chris


    • Bearbeitet -- Chris -- Donnerstag, 16. März 2017 14:34
    Donnerstag, 16. März 2017 14:32
  • > wenn du das gestern gesehen hätte wir die nicht einmal Profihacker es relativ einfach schaffen sich Zugang zum System und Adminrechten zu verschaffen, da läuft es einem kalt über den Rücken....
     
    Dann hakt es aber wo anders... Nicht bei der ExecutionPolicy.
     
    Restriktives Application Whitelisting (auch für Skripts!) ist für mich übrigens das Mittel der Wahl. Ein Standarduser darf nichts ausführen aus Speicherorten, wo er Schreibrechte hat.
     
    > Windows ist einfach nicht sicher. Daher so viele beschädigte Systeme.
     
    Das stimmt nicht. Aber Sicherheit ist immer unkomfortabel, deshalb ist der Default relativ unsicher konfiguriert. Sonst kommt der SOHO-User leicht in Rage :-)
     
    • Als Antwort markiert -- Chris -- Dienstag, 21. März 2017 06:46
    Donnerstag, 16. März 2017 16:19
  • > wenn du das gestern gesehen hätte wir die nicht einmal Profihacker es relativ einfach schaffen sich
    > Zugang zum System und Adminrechten zu verschaffen,

    Also das zu glauben, damit hab ich meine Schwierigkeiten. Nicht dir, sondern das das so einfach geht. Wäre mir zumindest neu.Von wem war denn der Workshop? Gibts dazu noch ein paar Details?

    Z.b. wäre es interessant ob da einem Account/dem Code wirklich mehr Rechte verliehen wurden. Oder wurde hier vielleicht nur z.b. ein Elevation-Prompt geschickt verschleiert?  Am ehesten kann ich mir vorstellen, das da ein bisher ungepatchter Bug ausgenutzt wird, ein prinzipielles Problem ist es denke ich nicht.

     Grüße, denniver

    Blog: http://bytecookie.wordpress.com

    Kostenloser Powershell Code Manager v5: Link
    (u.a. Codesnippets verwalten + komplexe Scripte graphisch darstellen)

    Hilf mit und markiere hilfreiche Beiträge mit dem "Abstimmen"-Button (links) und Beiträge die eine Frage von dir beantwortet haben, als "Antwort" (unten).
    Warum das Ganze? Hier gibts die Antwort.

    • Als Antwort markiert -- Chris -- Dienstag, 21. März 2017 06:45
    Donnerstag, 16. März 2017 18:49
    Moderator
  • mehr Infos habe ich leider nicht erhalten.

    1.) Mailbox ist voll Local Privilege Escalation

    In der ersten Demo mit gefälschten Outlook Webmail Login wurde eine Local Privilege Escalation Schwachstelle ausgenutzt.

    Darüber kann ein Nicht-Admin-User Vollzugriff auf das System erhalten. Dies ist aber nur durch Ausnutzung einer bereits bekannten und von Microsoft gepatchten Schwachstelle möglich. D.h. es wurden Updates nicht zeitnah durch die IT Abteilung ausgerollt.

    Siehe dazu: https://www.exploit-db.com/exploits/39719/

    2.) Bloodhound

    In der zweiten Live Demo haben wir Bloodhound (https://github.com/BloodHoundAD/BloodHound) eingesetzt um komplexe Infrastrukturen und deren Rechtekonfiguration grafisch abzubilden. Dazu sind KEINE Admin Rechte notwendig. Bloodhound nutzt lediglich Windows Funktionen um alle Domain User, alle auf allen Maschinen bestehenden Windows Sessions sowie alle administrativen Benutzer zu erheben. Diese Daten werden dann auf dem Rechner des Angreifers grafisch aufbereitet.


    Chris

    Dienstag, 21. März 2017 06:45