Die Outlook Schwachstelle CVE-2023-23397 wird derzeit aktiv ausgenutzt, besonders kritisch ist dies, da die Ausnutzung ohne Interaktion des Benutzers möglich ist. Angreifer können durch Ausnutzung der Schwachstelle an NTLM Hashes des Benutzers kommen und diese möglicherweise für folgende Angriffe verwenden. Zum Ausnutzen der Schwachstelle reicht es eine präparierte E-Mail oder eine Kalendereinladung an den Benutzer zu schicken, welche eine Erinnerung hervorruft und einen benutzerdefinierten Ton für die Erinnerung abspielen soll. Hier mal ein Beispiel:
Für die Erinnerung wird nun aber nicht eine lokale WAV-Datei angegeben, welche Outlook abspielen soll, sondern ein Pfad zu einem Server des Angreifers aus dem Internet, beispielsweise so:
Zum Erinnerungszeitpunkt (bei 0 Minuten sofort) versucht Outlook nun den Server per SMB im Internet zu erreichen. Antwortet nun der Server des Angreifers und fordert die Authentifizierung des Clients an, sendet Outlook den NTLM Hash an den Angreifer. Hier gibt es dazu weitere Details und auch eine Demonstration:
Wie bereits eingangs erwähnt, wird diese Schwachstelle aktiv ausgenutzt, daher muss möglichst schnell gehandelt werden, folgendes ist nun zu tun:
Port 445 (SMB) an der Perimeter Firewall blocken
Eigentlich sollten ja alle ungenutzten Ports an der Perimeter Firewall geschlossen sein, aber leider gibt es häufig die Konfiguration, dass zwar von Außen nach Innen nur die nötigen Ports geöffnet werden, aber von Innen nach Außen alle Ports und Protokolle zugelassen werden. Oft ist dies bei günstigen Routern der Fall, welche oft im HomeOffice eingesetzt werden. An der Perimeter Firewall des Unternehmens ist also hoffentlich der Port 445 in Richtung Internet schon blockiert, wenn nicht dann unbedingt umsetzen.
Zusätzlich muss man nun aber auch die vielen Home Office Nutzer denken. Wenn möglich sollte auch hier Port 445 in Richtung Internet gesperrt werden. Wenn es hier aber keine zentrale Verwaltung für die Home Office Firewalls oder Router gibt, dann sollte hier jetzt nicht zu viel Zeit investiert werden, sondern lieber das verfügbare Sicherheitsupdate installiert werden oder die Benutzerkonten zur Gruppe „Protected Users“ hinzugefügt werden.
Benutzerkonten im HomeOffice zur Gruppe „Protected Users“ hinzufügen
Damit der Client erst gar nicht versucht eine NTLM Authentifizierung durchzuführen, können die Benutzeraccounts in die Active Directory Gruppe „Protected Users“ aufgenommen werden. Durch diese Gruppe wird NTLM als Authentifizierungsmethode abgeschaltet. In den meisten Fällen wird es hier aber zu Problemen mit anderen Anwendungen kommen, welche NTLM benutzen. In der aktuellen Situation ist es aber ein gutes Pflaster, bis das Sicherheitsupdate installiert wurde. Den Port 445 an der Firewall zu schließen und die Benutzer in die Gruppe „Protected Users“ aufzunehmen geht schnell und hilft erst einmal gegen die Ausnutzung der Schwachstelle.
Sicherheitsupdate für Outlook installieren
Microsoft hat für Outlook ein Sicherheitsupdate veröffentlicht, welche die Schwachstelle schließt. Die verfügbaren Sicherheitsupdates sollten daher möglichst schnell installiert werden. In diesem Artikel finden sich die Download Links für die Updates:
An dieser Stelle kann man erst einmal aufhören zu lesen und alle Outlook Installationen aktualisieren. Wenn die Updates erledigt sind, kann weiter gemacht werden.
CVE-2023-23397 Script ausführen
Microsoft hat ein PowerShell Script veröffentlicht, welches die Postfächer nach Mails und weiteren Elementen durchsucht und diese schädlichen Elemente auch löschen kann. Das Script kann hier runtergeladen werden:
Je nach Anzahl und Größe der Postfächer, kann die Suche nach den Elementen aber recht lange dauern. Außerdem muss bei einem Treffer davon ausgegangen werden, dass die Schwachstelle erfolgreich ausgenutzt wurde. Auch wenn der Port 445 an der Perimeter Firewall im Unternehmen blockiert war, könnte sich der betreffende Benutzer zum Zeitpunkt der Ausnutzung im Home Office oder unterwegs beim Kunden befunden haben, wo möglicherweise kein Schutz bestand. Bevor das Script ausgeführt wird und nach betroffenen Benutzern gesucht wird, sollten daher unbedingt die ersten drei beschriebenen Schritte durchgeführt werden.
Das Script lässt sich meiner Meinung nach am schnellsten direkt auf den Exchange Servern ausführen. Bei mehreren Exchange Servern und mehreren Datenbanken lässt sich das Script auch parallel auf mehreren Servern ausführen und spart somit Zeit. Um das Script auf den Exchange Servern auszuführen, können die folgenden Schritte durchgeführt werden („BENUTZER“ durch das Konto ersetzen, welches das Script ausführt):
New-ThrottlingPolicy "CVE-2023-23397-Script"
Set-ThrottlingPolicy "CVE-2023-23397-Script" -EWSMaxConcurrency Unlimited -EWSMaxSubscriptions Unlimited -CPAMaxConcurrency Unlimited -EwsCutoffBalance Unlimited -EwsMaxBurst Unlimited -EwsRechargeRate Unlimited
Set-Mailbox -Identity "BENUTZER" -ThrottlingPolicy "CVE-2023-23397-Script"
New-RoleGroup -Name "CVE-2023-23397-Script" -Roles "ApplicationImpersonation" -Description "Permission to run the CVE-2023-23397"
New-ManagementRoleAssignment -name:CVE-2023-23397-Script -Role:ApplicationImpersonation -User:BENUTZER
Danach muss die EWS Schnittstelle runtergeladen werden. Es handelt sich bei dem Paket eigentlich um ein NuGet Paket mit der Dateiendung NUPKG, die Endung kann aber einfach zu ZIP umbenannt werden. Der Ordner „lib“ aus dem ZIP Archiv kann nun in den gleichen Ordner wie das Script auf dem Exchange Server kopiert werden:
Das Script lässt sich nun starten. Alle Postfächer lassen sich beispielsweise mit dem folgenden Befehl nach schädlichen Elementen durchsuchen:
Get-Mailbox -ResultSize Unlimited | .\CVE-2023-23397.ps1 -Environment Onprem -EWSServerURL https://localhost/EWS/Exchange.asmx -IgnoreCertificateMismatch -DLLPath C:\Scripts\CVE-2023-23397\lib\40\Microsoft.Exchange.WebServices.dll
Der Befehl muss in der Exchange Management Shell ausgeführt und der Pfad zur Microsoft.Exchange.WebServices.dll entsprechend angepasst werden.
Bei mehreren Datenbanken und Exchange Servern könnte man das Script auf jeden Exchange Server immer eine Datenbank durchsuchen lassen, so kann man das Script parallel auf mehreren Servern ausführen und Zeit sparen. Hier mal ein Beispiel:
Get-Mailbox -Database "MEINEDB1" -ResultSize Unlimited | .\CVE-2023-23397.ps1 -Environment Onprem -EWSServerURL https://localhost/EWS/Exchange.asmx -IgnoreCertificateMismatch -DLLPath C:\Scripts\CVE-2023-23397\lib\40\Microsoft.Exchange.WebServices.dll
In großen Umgebungen braucht das Script unter Umständen ewig bis es durchgelaufen ist, es kann daher Sinn machen den Zeitrahmen einzuschränken, hier mal das Beispiel von oben, welches nur die letzten 14 Tage durchsucht:
Get-Mailbox -Database "MEINEDB1" -ResultSize Unlimited | .\CVE-2023-23397.ps1 -Environment Onprem -EWSServerURL https://localhost/EWS/Exchange.asmx -IgnoreCertificateMismatch -StartTimeFilter ((get-date).AddDays(-14)) -EndTimeFilter (get-date) -DLLPath C:\Scripts\CVE-2023-23397\lib\40\Microsoft.Exchange.WebServices.dll
Es gibt allerdings Hinweise dass die CVE-2023-23397 schon seit April 2022 ausgenutzt wird, daher wiegt die Suche innerhalb eines kurzen Zeitraums möglicherweise in trügerischer Sicherheit und es sollte mindestens das letzte Jahr durchsucht werden.
Wenn es Treffer gibt, erstellt das Script eine CSV Datei mit den gefunden Elementen. Diese CSV Datei sollte man sich einmal anschauen, ich hatte da ein paar False Positive drin. Die schädlichen Elemente lassen sich nun mit dem folgenden Befehl löschen:
.\CVE-2023-23397.ps1 -Environment Onprem -CleanupAction ClearItem -EWSServerURL https://localhost/EWS/Exchange.asmx -IgnoreCertificateMismatch -CleanupInfoFilePath "PFADZURCSV"
Kennwörter betroffener Benutzer zurücksetzen
Wenn das Script Treffer findet, sollte erst einmal davon ausgegangen werden, dass die Ausnutzung der Schwachstelle erfolgreich war. Möglicherweise befand sich der Benutzer gerade nicht im Einzugsbereich der Firewall des Unternehmens. Es ist daher ratsam das Passwort des Benutzers zu ändern und den Benutzer in die Gruppe „Protected Users“ aufzunehmen. Auch sollte dann überwacht werden, ob es verdächtige Login Versuche dieser Benutzerkonten gibt, beispielsweise via VPN oder OWA.
CVE-2023-23397 und Office 365 / Exchange Online?
Da CVE-2023-23397 eine Schwachstelle in Outlook und nicht in Exchange oder Exchange Online ist, dürfen nun auch Exchange Online Admins ans Werk. Das Test Script von Microsoft lässt sich auch gegen Exchange Online und Office 365 ausführen. Die beschriebenen Schritte gelten also auch, wenn Office 365 eingesetzt wird.
Hallo in die Runde, das Hinzufügen der Benutzerkonten zur Gruppe „Protected Users“ war bei uns keine so gute Idee. Anschließend poppte beim Outlook-Start dieser User immer ein Anmeldefenster hoch, welches man weder wegklicken, noch irgend eine gültige Anmeldung durchführen konnte. Sprich Outlook war schlicht nicht mehr nutzbar- große Aufregung bei der Belegschaft!
VG
Microsoft hat die Releaseinformation zum März SU für noch unterstützt Exchange-Versionen (2013/2016/2019) ergänzt:
„Exchange Server (with March 2023 SU) and Exchange Online drop the PidLidReminderFileParameter message property at TNEF conversion when new message is received from outside of the organization“
Please note that Exchange Server March 2023 SUs contain a „defense in depth“ change that removes the value of the property that can be exploited on unpatched Outlook for Windows clients for messages that are newly delivered to user mailboxes from outside of the organization. No admin action is necessary other than installing March 2023 (or later) SU.
Heißt:
Auch ungepatchte Outlookversionen sind sicher, wenn neue schädlichen Mails von außerhalb der Organisation kommen UND bei Exchange das März 2023-SU installiert ist, da der Exchange das filtert und Outlook den schädlichen Inhalt gar nicht erst bekommt.
Wenn man dann noch Port 445 ausgehend auf der Firewall sperrt, sollte man sicher sein.
Gerade bei Borncity gelesen: Der Patch schützt wohl nicht komplett. Momentan hilft nur den Port TCP445 abgehend sperren oder User in die Protected Group packen. Wobei das Port sperren weitaus weniger Nebenwirkungen hat.
Hier der Link zum Artikel: https://www.borncity.com/blog/2023/03/24/outlook-schwachstelle-cve-2023-23397-nicht-vollstndig-gepatcht-absicherung-erforderlich/
Hi,
mal eine Verständnisfrage: Kriegen die Anwender es eigentlich mit, wenn sie so eine präparierte Mail erhalten? Immerhin müsste dann doch ein Termin in ihrem Kalender auftauchen oder so? Und falls dem so wäre, findet das Script die Mail überhaupt, wenn die Anwender sie gelöscht haben?
Danke
Hyper
Das habe ich mich auch schon gefragt.
Außerdem: Welche Funktionen innerhalb einer präparierten Mail sind denn überhaupt in der Lage, solche Ereignisse – welche dann z. B. Benachrichtigungen haben – auszulösen? Spontan fallen mir bei der Kalenderfunktion die Termin- und die Ferienfunktion ein.
Wie viel würde es dann an dieser Stelle bringen, im Mailgatway z. B. die Endungen .ifb, .ics, .ical, .icalendar sowie .hol zu blockieren?
Viele Grüße
Simon
Hallo zusammen,
ich habe alles nach Anleitung ausgeführt – ohne Fehler.
Der User, der berechtigt wurde, mit dem wird auch das Skript ausgeführt.
Beim Ausführen des Skripts und nach Eingabe der User-Daten kommt folgende Meldung:
Unable to connect to EWS endpoint. Please make sure you have enter valid credentials. Inner Exception
The request failed. Der Remoteserver hat einen Fehler zurückgegeben: (401) Nicht autorisiert.
Hat hier noch jemand das Problem / die Meldung?
Jup, heute früh nach Aktualisierung des Scripts. Vorher funktionierte als Credential „Benutzername“ + Kennwort, nach der Aktualisierung gab es Fehler 401. Abhilfe schaffte bei mir „benutzername@domain.de“ + Kennwort als Credential
hey, also ich bekomm den fehler auch und ich hab schon alles probiert bei den credentials. muss in den iis für die default web site vllt noch was beachtet werden? Gruß
Ich nutze folgenden Befehl für das Script, vielleicht hilfts:
Get-Mailbox | .\CVE-2023-23397.ps1 -Environment Onprem -EWSServerURL „https://exchangeserverip/EWS/Exchange.asmx“ -IgnoreCertificateMismatch -Credential benutzername@domain.de
Am IIS musste ich nichts ändern. Ex2016 auf Srv2016
Ich nutze folgenden Befehl für das Script, vielleicht hilfts:
Get-Mailbox | .\CVE-2023-23397.ps1 -Environment Onprem -EWSServerURL „https://exchangeserverip/EWS/Exchange.asmx“ -IgnoreCertificateMismatch -Credential benutzername@domain.de
Achte bitte beim Kopieren auf korrekte Anführungszeichen in der ExchangeShell ;-)
Am IIS musste ich nichts ändern. Ex2016 auf Srv2016
Bei mir hat es geholfen den lokalen Servernamen mit entsprechendem Port zu verwenden:
„https://servername.domain.local:444/EWS/Exchange.asmx“
Vielen Dank für alle Antworten!
Letztendlich war es ein Mix daraus :-)
Get-Mailbox | .\CVE-2023-23397.ps1 -Environment Onprem -EWSServerURL „https://servername.domain.local:444/EWS/Exchange.asmx“ -IgnoreCertificateMismatch -Credential benutzername@domain.de
Hier mit einem EX2016 auf Server2016 das gleiche Problem, egal ob ich den Admin-User mit Domain\username oder username@domain angebe.
Moin,
gibt es irgendeine Möglichkeit zu prüfen, ob das Skript sich aufgehangen hat?
Hier hängt er aktuell bei einer (2 b fair ziemlich gigantischen) Mailbox. Allerdings schon seit 3 Std. Davor wurden ebenfalls große Postfächer bearbeitet und die gingen ratz fatz.
Danke schonmal :) und auch Danke @ Franky für die Anleitung!
Moin,
gilt das auch für IMAP / POP Konten, die im Outlook eingerichtet sind?
Danke!
Hallo Namensvetter, jaa das gilt auch für IMAP / Pop Konten. Es geht hier um eine Outlook Lücke, nicht um Exchange :)
Danke dir Franky für die mal wieder sehr ausführliche, einfach umzusetzende Anleitung. Auch großes Danke an die alle die hier entsprechende Fragen zu Fehlermeldungen gepostet haben, zwei davon haben mir echt den Abend gerettet.
Hat denn mal jemand einen positiven Treffer oder alle nur false positives? Wie sieht sowas ggf. denn aus?
Bei mir nur false positives. als PidLidReminderFileParameter ist dann z.B. „Reminder.wav“ eingetragen.
Wenn bei PidLidReminderFileParameter ein UNC-Pfad stehen würde, wäre das kein false positive.
Bei uns sieht auch fast alles nach false positiv aus. Interessant sind einige wenige Treffer. Ich werde mir die mit „reminder.wav“ im Suchergebnis auf jeden Fall näher anschauen. Einige wenige „E-Mail“ Treffer sind auch dabei.
Wenn das Script was findet, schreibst es eine AuditLog_***.csv.
Diese dann editieren und am Ende für alle Einträge, die gelöscht werden sollen aus dem N ein Y machen.
Dann das Script mit dieser Datei (CleanupFileInfoPath) aufrufen.
Ja das ist klar. Aber woran erkennst du, dass das keine legitimen Elemente sind?
Müssten UNC-Pfade in einem der Fehler zu sehen sein.
Sobald UNC-Pfade in einem der Felder zu sehen sind.
ok. Danke :)
Nur leeres Feld oder Reminder.wav. Ich nehme das mal als gutes Zeichen :-)
Gleiche Spiel bei uns, auch nur ein paar reminder Treffer die sehr alt sind..
Hallo Alle,
woran lässt sich den erkennen, ob es sich um einen false Positiv handelt oder nicht?
Wenn an der WAW ein extern Server stünde?
Hat jemand Mal eine (anonymisierte) Zeile aus dem MS Script, die wirklich ein Problem darstellt?
Mfg
Hat jemand schon mal einen Positiv Fall gehabt?
Zur Simulation auf einem ungepatchten System, habe ich einen UNC Pfad als Sounddatei in einen Termin konfiguriert.
Die Wave Datei wurde auch vom Fileserver geholt und abgespielt.
Leider hat das Script, welches ohne Fehlermeldung funktioniert, nichts gefunden.
Wo ist der Denkfehler?
Muss ich überhaupt eine Throttling policy setzen, wenn ein globaler exchange admin vorhanden ist?
Sprich mit dem Account wo auch die Security patche installiert werden usw.?
Ist mir nicht so ganz klar, ob ich da Skript nicht einfach so ausführen kann
Ja, denn der darf auch per Standard nicht in die Postfächer schauen und die ews Richtlinien gelten normalerweise auch für ihn.
Geht es nur mir so, oder gibts auf der Microsoft Seite keinen Patch für Office/Outlook 2019?? Der Download Link existiert nicht und bei „Article“ steht nur Run now, aber da steht nix brauchbares….
Hallo Clu,
für Office 2019 gibt es nur noch Full Updates und keine Security Updates mehr.
Du musst auf die Build 10396.20023 aktualisieren um die Lücke zu schließen.
Hi zusammen.
Ich bekomme folgenden Fehler nachdem das Script einige Postfach problemlos durchsuchen konnte:
Unable to process mailbox hanswurst@glueckstadt.com as it seems to be inaccessible. Inner Exception:
Ausnahme beim Aufrufen von „Bind“ mit 2 Argument(en): „The response received from the service didn’t contain valid XML.“
Kann mir jemand helfen?
Vielen lieben Dank im Voraus.
Hat niemand eine Idee für mich?
VG
Kurze Frage zu diesem Abschnitt:
You can also create a new Throttling Policy to prevent the user who runs the script from being throttled. Make sure to revert the throttling policy after you’re done running the script.
Please note that this is for Exchange on-premises environments only.
Wie setze ich das ganze danach wieder zurück?
https://learn.microsoft.com/en-us/powershell/module/exchange/get-throttlingpolicy?redirectedfrom=MSDN&view=exchange-ps
Ist Werte aufschreiben und nach dem Scan wieder auf die alten Werte zurücksetzen.
Abfragen welche Policy dem User zugeordnet ist via Get-ThrottlingPolicyAssociation
Und wenn du ein Ergebnis zurückbekommst, diese Policy hinterher wieder mit Set-Mailbox -Identity „BENUTZER den du verwenden willst“ -ThrottlingPolicy „Policy aus dem Ergebnis“ setzen. Wenn da keine Policy zurück kommt, dann einfach auf $null setzen.
hinter Get-ThrottlingPolicyAssociation natürlich noch den Benutzer angeben, sonst listet der Befehl alle Nutzer auf.
Hallo Franky,
ein kleiner Hinweis: Bei uns haben wir uns für die Mobilen User mit der „Protected Users“-Group ein schönes Eigentor geschossen.
Da diese dann nicht mehr die Logindaten lokal zwischenspeichern, ist ein Login außerhalb der Domäne nicht mehr möglich. Es gibt folgende Fehlermeldung „Sie können mit diesen Anmeldeinformationen nicht angemeldet werden, weil Ihre Domäne nicht verfügbar ist“
Ergänze den Hinweis doch bitte, hat mir einige verärgerte Kollegen eingebracht. Zumindest führe ich das Verhalten auf diese Gruppe zurück – lasse mich aber gerne eines besseren Belehren ;-)
Hi,
das Verhalten kommt definitiv durch die protected user Group, da dadurch eine offline-Anmeldung an einem Gerät nicht mehr möglich ist.
Vor diesem Problem stehen wir nun auch.
Benutzer welche teils hunderte von Kilometern vom nächsten Office arbeiten, können sich an Windows nicht mehr anmelden.
Habt Ihr hierzu eine Idee?
Vor dem selben Problem stehen wir nun auch.
Benutzer welche teils mehrere hundert km enfernten vom nächsten Office sind können sich nicht mehr in Windows anmelden.
Habt Ihr dazu eine Idee?
Glaube es hilft nur in den sauren Apfel beisen und ins nächste Office fahren.
Kennwörter der lokalen Admins rausgeben, die User damit anmelden lassen, VPN aufbauen, Patch einspielen und dann die User wieder aus der Gruppe nehmen. Abschließend Kennwort des lokalen Admins ändern.
Es ist von einer CSV die Rede. Wo wird diese standardmäßig erstellt?
Leider bekomme ich einige dieser Meldungen:
Ausnahme beim Aufrufen von „FindItems“ mit 3 Argument(en): „The request failed. Timeout für Vorgang überschritten“
Error while scanning Archiv 2016-2018 of the mailbox xxx@xxxxx.de. Inner Exception:
Hallo zusammen,
danke wieder mal für den super Artikel.
Ich bekomme folgenden Fehler für die einzelen Postfächer bei Aufruf des Scripts:
Unable to access mailbox:
Inner Exception: Der SMTP-Adresse ist kein Postfach zugeordnet.
Kann mir da jemand weiterhelfen?
Danke!
Den Fehler hatte ich auch.
Schau mal in der GUI nach, ob der Benutzer, unter dem Du das Script laufen lässt, wirklich Mitglied der angelegten Role-Group ist.
Danke für den Hinweis! Der User war tatsächlich nicht in der Gruppe. Hat aber leider noch nicht geholfen.
Das Problem tritt auf wenn du versuchst das Script mit einem Admin User auszuführen der kein Postfach hat.
Ich habe mir auch erst noch ein Postfach für den Benutzer erstellen müssen.
Ich glaube zumindest das war die gleiche Fehlermeldung.
Achtest Du bei der Credentialeingabe auf domain\user?
Ich hatte dort ursprünglich nur user eingegeben, was dann auf dem Exchange einen lokalen Admin laufen lässt.
Danke, das war der entscheidene Tipp.
Hallo zusammen,
danke wieder mal für den super Artikel.
Ich bekomme folgenden Fehler für die einzelen Postfächer bei Aufruf des Scripts:
Unable to access mailbox: xxxxx@xxxxxx.de
Inner Exception: Der SMTP-Adresse ist kein Postfach zugeordnet.
Kann mir da jemand weiterhelfen?
Danke!
Eine – vielleicht blöde – Frage, aber:
Funktioniert der Angriff, wenn die Clients ihre Internetverbindung ausschließlich über einen Proxy herstellen?
Würde der SMB-Auf/Abruf der (z.B.) WAV-Datei dann nicht scheitern?
Und entsprechend würde dann auch keine Authentifizierungsanfrage vom WAV-Server an den Client gesendet und
dann in der Folge natürlich auch nicht der NTLM-Hash vom Client an den WAV-Server gesendet werden?
DANKE!
Dann muss man als Angreifer eben erst einen internen SMB Server „bereitstellen“. Also unmöglich ist das alles nicht und der Proxy hilft halt nicht pauschal.
Kann mir jemand sagen wie ich erkennen kann ob ein Treffer tatsächlich ein Treffer oder nur FalsePositiv ist?
Das würde mich tatsächlich auch interessieren!
Das würde mich auch brennend interessieren
Hier die Antwort
https://github.com/microsoft/CSS-Exchange/issues/1585
detto…hab einpaar Zeilen drinnen aber ich denke das hat nichts damit zu tun…
Sobald UNC-Pfade in der Liste auftauchen.
Ich scheitere auch schon bei dem Befehl:
New-ThrottlingPolicy „CVE-2023-23397-Script“
Fehlermeldung:
New-ThrottlingPolicy : Die Benennung „New-ThrottlingPolicy“ wurde nicht als Name eines Cmdlet, einer Funktion,
einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des Namens, oder
ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.
In Zeile:1 Zeichen:1
+ New-ThrottlingPolicy „CVE-2023-23397-Script“
+ ~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (New-ThrottlingPolicy:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
Inner Exception: Das Konto ist nicht berechtigt, die Identität des angeforderten Benutzers anzunehmen.
No vulnerable item found
Die erste Fehlermeldung ist dann normal? Oder muss ich dafür noch etwas einstellen das ich „dies“ auch kann?
Danke für jeden Tipp
Läuft – Hatte einen Tippfehler bei New-ManagementRoleAssignment drin ;)
unglaublich wirklich. das Script läuft bei mir nicht, seit 1-2 Tagen am probieren aber keine Chance.
1. Imperso User und „Rolegroups“ gem. Anleitung von MS bereits erstellt (vor 1 Tag, aslo RBAC erstmal außen vor)
2. Script mit und ohne EWSURL, mit und ohne ADMIN, alles keine Chance.
Fehler „usnahme beim Festlegen von „ImpersonatedUserId“: „Der Wert „Microsoft.Exchange.WebServices.Data.ImpersonatedUserId“ vom Typ „Microsoft.Exchange.WebServices.Data.ImpersonatedUserId“ kann nicht in den Typ „Microsoft.Exchange.WebServices.Data.ImpersonatedUserId“ konvertiert werden.““
.DLL File von Microsoft genommen, dies wird auch erkannt..
Ideen?
Ich scheitere auch schon an dem Befehl
New-ThrottlingPolicy „CVE-2023-23397-Script“
Fehlermeldung:
New-ThrottlingPolicy : Die Benennung „New-ThrottlingPolicy“ wurde nicht als Name eines Cmdlet, einer Funktion,
einer Skriptdatei oder eines ausführbaren Programms erkannt. Überprüfen Sie die Schreibweise des Namens, oder
ob der Pfad korrekt ist (sofern enthalten), und wiederholen Sie den Vorgang.
In Zeile:1 Zeichen:1
+ New-ThrottlingPolicy „CVE-2023-23397-Script“
+ ~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (New-ThrottlingPolicy:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
Hey, sicher das du die Exchange Powershell offen hast? :)
Lade die *.dll nochmal neu herunter. Der Link wurde seitens Microsoft nochmal angepasst. Wenn du die falsche dll-Datei heruntergeladen hast, funktioniert es nicht.
Hi Mona,
ich hatte das selbe Problem. Heute habe ich dann gesehen, dass Microsoft in Ihrem Post (https://microsoft.github.io/CSS-Exchange/Security/CVE-2023-23397/) eine falsche / eine andere DLL zum Download verlinkt hatten. Diesen Link haben sie gestern angepasst.
Vor gestern war noch die „exchange.webservices.managed.api (Version 2.2.1.2)“ verlinkt, seit gestern Abend die „microsoft.exchange.webservices (Version 2.2.0)“
Hier einmal der richtige / neue Link:
https://api.nuget.org/v3-flatcontainer/microsoft.exchange.webservices/2.2.0/microsoft.exchange.webservices.2.2.0.nupkg
Ansonsten wieder das selbe Spiel:
– nupkg herunterladen
– in „.zip“ umbenennen
– Entpacken
– WICHTIG: Eine neue PowerShell-Session öffnen, nachdem die Daten entpackt worden sind –> Keine bestehende / vorhandene Session verwenden
– Script erneut mit der DLL „lib\40\Microsoft.Exchange.WebServices.dll“ laufen lassen
Die Schritte und die Download-Links findest du aber auch nochmal im Post von Microsoft unter „Steps to Download Microsoft.Exchange.WebServices.dll:“ oder ganz unten unter „Cannot convert the „Microsoft.Exchange.WebServices.Data.WebCredentials“
https://microsoft.github.io/CSS-Exchange/Security/CVE-2023-23397/
Ich muss mal wieder dumm fragen. Ich habe alle Clients mit Outlook gepatched. Den Port muss ich nun nicht mehr extra schließen oder ?
Nein, aber solltest du. ;)
jaa danke – für die Zukunft sinnvoll jaa. prima :)
Die csv Datei muss noch angepasst werden „N“ muss in „Y“ geändert werden
LG
Rene
bei mir zeigt er, dass er 0 von X Einträge gelöscht hat.
No entries were removed. Please update the Cleanup column for the items you wish to cleanup
Was muss ich denn hier anpassen?
Dankeschön
bei mir zeigt er, dass er 0 von X Einträge gelöscht hat.
No entries were removed. Please update the Cleanup column for the items you wish to cleanup
Wenn ich die CSV so anpasse (N durch Y ersetzen) dann bekomme ich die Fehlermeldung
No Id present for entry number
Was muss ich denn hier anpassen?
Dankeschön
Den Fehler hatte ich auch.
Bearbeite die csv Datei nur im Editor und nicht über Excel, dann sollte es keine Probleme geben.
Office Updates können per GPO angestoßen werden:
Script beim Start ausführen lassen. Script muss auf einem Laufwerk liegen, was für jeden Nutzer erreichbar ist. Netzwerk und UPN-Adresse klappt auch.
cd „C:\Program Files\Common Files\Microsoft Shared\ClickToRun“
OfficeC2RClient.exe /update user
Warum nimmst du nicht den vorhandenen Office Update Task(Office Automatic Updates 2.0) und passt den an? Der hat doch schon mehrere Trigger definiert.
Hey Servus,
erstmal ganz Herzlichen Dank!
*Wenn es Treffer gibt, erstellt das Script eine CSV Datei mit den gefunden Elementen.
Die CSVwird immer erstellt, oder? Auch bei keinen Treffern.
VG