[English]Kleiner Nachtrag von gestern – Microsoft will ja schon lange die Unterstützung für die Script-Sprache VBScript in Windows beerdigen. Nun hat man VBScript als veraltet (deprecated) erklärt und gibt auch einen Zeitplan an, wann der Support aus Windows komplett entfernt wird. Die Zeiten des Sicherheitsproblems VBScript sind also gezählt.
Anzeige
VBScript seit 1996 verfügbar
Visual Basic Scripting Edition, oder kurz als VBScript bezeichnet, ist eine Skriptsprache, die 1996 von Microsoft eingeführt wurde. Die Sprache ist bisher als Systemkomponente im Windows-Betriebssystem verfügbar und wurde häufig zur Automatisierung von Aufgaben und zur Steuerung von Anwendungen auf Windows-basierten Systemen verwendet.
VBScript konnte auch in HTML-Seiten eingebettet werden, um Webseiten dynamische Interaktivität und Funktionalität hinzuzufügen. Im Microsoft-Umfeld kommt VBScript beispielsweise bei Active Server Pages (ASP) und beim Windows Script Host (WSH) zum Einsatz.
Ein Problem bei VBScript war aber einerseits, dass es ursprünglich mit dem Internet Explorer eingeführt wurde, der aber aus dem Support gefallen ist. Weiterhin galt VScript längst als Sicherheitsrisiko, weshalb dieses Feature 2019 im Internet Explorer bereits deaktiviert wurde (siehe Microsoft deaktiviert ab August VBScript im Internet Explorer). Und im Oktober 2023 wurde VBScript unter Windows abgekündigt (siehe Windows: Drei weitere Funktionen im Nov. 2023 abgekündigt und Windows ADK für Windows 11 22H2: PE-Build neuer als Basis, VBScript.dll fehlt (Sept. 2023)). Seit März 2023 gibt es die Möglichkeit, VBScript über optionale Funktionen zu deinstallieren (siehe die Anmerkung bei deskmodder.de).
Fahrplan zum Entfernen von VBScript
Im Techcommunity-Beitrag VBScript deprecation: Timelines and next steps vom 22. Mai 2024 hat Microsoft nun die nächsten Schritte skizziert, um VBScript in Rente zu schicken.
Anzeige
- Phase 1: VBScript wird in allen Windows 11 Version 24H2 und höher, standardmäßig als Feature on Demand (FOD) vorinstalliert sein. Dadurch soll sichergestellt werden, dass eine Abhängigkeit von VBScript (Anwendungen, Prozesse und dergleichen) noch berücksichtigt wird, während die Nutzer von VBScript weg migrieren. Administratoren können die standardmäßig aktivierten VBScript-FODs unter Start > Einstellungen > System > Optionale Funktionen sehen.
- Phase 2: Ab 2027 werden die VBScript-Feature on Demand (FOD) nicht mehr standardmäßig aktiviert sein. Nutzer, die VBScript-Unterstützung benötigen, müssen dies über Feature on Demand (Einstellungen > System > Optionale Funktionen) aktivieren.
- Phase 3: VBScript wird in den Ruhestand geschickt und aus zukünftigen Versionen von Windows entfernt. Das bedeutet, dass alle dynamischen Link-Bibliotheken (.dll-Dateien) von VBScript entfernt werden. Projekte, die auf VBScript angewiesen sind, werden nicht mehr funktionieren.
Microsoft schlägt die Migration von Webseiten mit VBScript-Code auf JavaScript vor. Bei Windows Script Host wäre der Wechsel von VBScript auf PowerShell-Scripte anzugehen. Weiteres Details lassen sich dem Techcommunity-Beitrag entnehmen.
Anzeige
Jetzt müssen noch die Makros aus Office raus fliegen, so wäre die (IT) Welt wenigstens ein kleines bisschen sicherer :-)
>>> Die Zeiten des Sicherheitsproblems VBScript sind also gezählt.
Ja, ist aber puncto Informationssicherheit ohne Belang. PowerShell ist als Framework für Angriffswerkzeuge derart mächtig (nur ein Bsp.: PowerSploit (1)), dass keine Wünsche offen bleiben. VBScript ist das Wählscheibentelefon unter den Programmiersprachen.
(1) attack.mitre.org/software/S0194/
execution policy signed
und schon ist dein "angriffsvektor" eine phantasie.
Gibt halt noch Firmen und Nutzer die nicht jede Malware freiwillig selbst ausführen. Muss wieder eines dieser Viren sein, die ich selbst installieren muss
¯\_(ツ)_/¯
>>> execution policy signed und schon ist dein "angriffsvektor" eine phantasie.
LOL, lern' Du erst mal PowerShell bevor Du Dich hier als Bundes-CISO vorstellst.
Set-ExecutionPolicy : Cannot bind parameter 'ExecutionPolicy'. Cannot convert value "signed" to type "Microsoft.PowerShell.ExecutionPolicy". Error: "Unable to match the identifier name signed to a valid enumerator name.
Alles klar? Ich hoffe doch.
Und dann wende Dich Materialien zu, die man euch in der Berufsschule vorenthält: netspi.com/blog/technical-blog/network-pentesting/15-ways-to-bypass-the-powershell-execution-policy/
Die Aussage ist so nicht richtig. Da wir bei der PowerShell ein voll umfängliches Logging einschalten können, ist dieser Weg schon lange nicht mehr bevorzugt.
z.B. mit einem kostenlosen SIEM wie WAZUH, ist dann relativ einfach Hinweise auf ungewollte Tätigkeiten in der Shell zu bemerken.
Auch zu erkennen daran, dass viele dieser Frameworks wie PowerSploit schon seit Jahren nicht mehr aktualisiert oder weiterentwickelt werden.
Wenn in der Shell bereits "gefährliche", Aktivitäten möglich sind, hat man eventuell schon an einer anderen Stelle ein Sicherheitsproblem, über das erhöhte Rechte erreicht werden konnten.
>>> Da wir bei der PowerShell ein voll umfängliches Logging einschalten können, ist dieser Weg schon lange nicht mehr bevorzugt.
Ah ja, Gebrüder Meier Innen- und Aussengewinde en gros und en détail haben Logging eingeschaltet. Prompt haben Black Basta & Co. PowerShell auf 's Altenteil geschickt, Ironie off. Mensch Leute , in welcher Welt lebt ihr?
Auch das ist nicht richtig.
Black Basta nutzt höchstens die Powershell um weitere Skripte nachzuladen, hier könnte man aber auch diverse andere Dinge auf einer Windows Box missbrauchen.
Fakt ist aber, die genannten und veralteten "Powershell Frameworks" zum "Hacken" nutzt kaum jemand.
Black Basta kommt über die üblichen FileFormate, welche ausgeführt werden müssen (User Schulungen) und dann werden die üblichen LOLbins, falsche Datei-Ordnerberechtigungen ausgenutzt, um welche sich Admins und Microsoft viel mehr kümmern sollten z.B. Calc.exe, Certutil.exe, jedes Office Programm etc. Updates zeitnah verteilen, ist weiterhin der größte Schutz.
Das alles gilt übrigens auch für Linux.
AppLocker deployen und nur noch signierte PoSh Skripte erlauben. Eine GPO, drei Minuten Arbeit. Es kann so einfach sein…
slmgr und winrm werden endlich als .exe oder cmdlet von MS bereitgestellt? juhuu!
Frage mich auch gerade wie Microsofts eigenes MDT Deployment Toolkit dann noch funktionieren soll :D
Dieses basiert ja auf einer Sammlung von VBScript Dateien
Das MDT wird ja offiziell nicht mehr gepflegt und es wird der Umstieg auf die teuren Lösungen empfohlen. Leider.
Alternativ gäbe es noch das PowerShell Deployment for MDT (PSD) das eine Erweiterung für MDT ist aber halt nichts offizielles ist.
das ist ja leider schon mit der PE vom Win11 ADK kaputt, ohne IE Ressourcen.
MDT supported oder nicht, es funktioniert immer noch ohne Probleme (auch Win11 oder Server 2022) und die erwähnte, alternative Version PSD, ist eigentlich sogar besser als der Vorgänger. Die ganze Installation nur noch über HTTP(s) abzuwickeln, ist alleine schon ein Gamechanger.
Es gibt auf Github auch ein Projekt was die Konfiguration von MDT per DSC erledigt, falls man auch das automatisieren möchte.
Vieles was man man mit MDT gemacht hat, kann man auch auf andere Tools aufteilen z.b. Images mit OSDBuilder Tasks oder Packer, vorbereiten, mit einem Package Manager wie Chocolatey Software/Treiber/Dateien nachreichen und konfigurieren über Richtlinien/DSC/OpenSource Alternativen etc. .
>>> MDT supported oder nicht, es funktioniert …
Was Du daher salbaderst und den Leuten Worte im Munde herumdrehst, geht auf keine Kuhhaut. Im Beitrag von techee 24. Mai 2024 um 09:22 Uhr ist überhaupt nicht die Rede von supported. Dagegen ist in dem vom Bornschen Artikel zitierten Blogbeitrag (1) zu lesen: "The feature will typically continue to work and is fully supported until it's officially removed." D. h. wenn MDT in den Zustand nicht supported eintritt, wird es zugleich auch verschwunden sein. Von wie von Dir behauptet "es funktioniert immer noch ohne Probleme" kann perspektivisch also keine Rede sein!
Des weiteren besagen die Microsoftschen Lifecyle Definitions (1), dass es Security Updates nur in den Phasen Mainstream Support und Extended Support gibt. Deine Betonung auf "es funktioniert" im Zusammenhang mit einer Sicherheitsdiskussion ist also absurd.
Notabene: Die Phase "Extended Security Update (ESU) Program" wird von Microsoft als "past the end of support." umschrieben. Wer also ein nicht mehr supportetes Produkt einsetzen will, muss Geld in die Hand nehmen, um sicher zu bleiben. Aber eigentlich ist das alles bedeutungslos, da i. Z. von MDT ja nicht von Supportphasen sondern von einem "Deprecation Plan" die Rede ist.
Die Zukunft von MDT muss vor dem Hintergrund der Abkündigung von VBScript also als ungewiss angesehen werden.
>>> … Vieles was man man mit MDT gemacht hat, kann man auch auf andere Tools aufteilen …
Resümee für mitlesende Auszubildende: Je mehr und besinnungsloser ihr Tools in eure Tool Chain hängt, desto übersichtlicher, stabiler und sicherer wird das Ganze. Ironie off.
(1) techcommunity.microsoft.com/t5/windows-it-pro-blog/vbscript-deprecation-timelines-and-next-steps/ba-p/4148301
(2) https://learn.microsoft.com/en-us/lifecycle/definitions
Ich verdrehe keine Worte, ich berichte das es *aktuell* mit allen aktuellen Windows Versionen funktioniert, ohne Probleme, da ein Teilnehmer dieser Diskussion auf IE Probleme hingewiesen hat, Zitat "das ist ja leider schon mit der PE vom Win11 ADK kaputt, ohne IE Ressourcen.".
Es gibt aktuell, oder für die Zukunft eine Alternative die viel besser ist und ich finde durch das aufteilen der Vorgänge auf andere Tools, die man früher hauptsächlich über MDT gemacht, bekommt man einen viel besseren und übersichtlichen Prozess, den man auch vielseitiger nutzen kann.
Auch mit dem neuen MDT nutze ich Osdbuilder oder Chocolatey (auch mit dem alten MDT, schon ewig), für vor oder nachgelagerte Tätigkeiten.
Da ich das alte MDT aufgrund von PXE Boot und Passwörtern in "öffentlichen" Dateien, grundsätzlich in abgeschotteten Netzwerken zum installieren nutzen muss, ist die "Diskussion um Sicherheit" irgendwie hinfällig, da es immer ein unsicherer Vorgang ist, der abgefangen oder missbraucht werden kann, wenn er zu öffentlich zugänglich ist. Ich habe und werde niemandem dazu raten, nicht mehr servicierte Software zu nutzen, Alternativen wurden hier ja in den Kommentaren angeboten.
Da werden sich dank des Clearscript Projekts von MS vermutlich schnell freie VBScript Alternativen finden. Sicherer wird da nix solange JS wie gehabt vom Scripting Host ausgeführt wird. Da sitzt inzwischen eine Entwicklergeneration bei MS die auf sowas schlicht keine Lust hat.
Da ich selbst auch ASP-Webseiten gebaut habe, ist diese Nachricht suboptimal. Alles nun auf JS umbauen? Und das ist dann sicherer?
Wie sieht es dann mit dem HTA (HyperTextApplivation) aus, daß basiert doch auf VBScript. Es nutzt zwar die hta.exe und nicht die wscript.exe, aber ich vermute, dass es dann auch nicht mehr lauffähig ist.