News Hafnium-Exploits: Lücken in Exchange Server werden für Spionage genutzt

[iSight2TheBlind]

@greatdisaster Nur dass hier nicht die Exchange-Server von selbst aufgestanden sind, sich ins Flugzeug setzten und ihre Festplatten dann in China abgeliefert haben.
Dein Beispiel mit dem selbstfahrenden Fahrzeug ist so nicht ausreichend, da es den Teil mit dem aktiven Angriff ignoriert.
Passender wäre es wenn das autonome Fahrzeug ein Kind überfährt, weil jemand aktiv dafür gesorgt hat, dass das Auto die Situation in der es sich befindet nicht korrekt erkennen kann, beispielsweise indem Fehler wie dieser https://ps.is.mpg.de/news/color-patch-could-throw-self-driving-vehicles-off-track ausgenutzt werden.
Wenn also beispielsweise jemand Plakate mit so einem Muster an den Straßenrand bei einer Schule hängt, im Bewusstsein, dass damit die Computer Vision von Fahrzeugen lahmgelegt wird.
Die Entwickler müssen natürlich dafür sorgen dass solche Fehler nicht vorkommen können, dass der Fehler in dieser Situation jedoch zu einem Unfall führte ist dann kein unglücklicher Zufall sondern pure Absicht des Manipulators.

Flugzeuge stürzen bei der Landung eigentlich recht selten ab, wenn dann jedoch Leute mit einem hochgezüchteten Laserpointer auf landende Flugzeuge zielen steigt das Risiko eines Absturzes deutlich!

@Rickmer Die Steinzeit war doch eigentlich nicht soooo schlecht und immerhin ohne IT-Probleme.
Nur dann haben wir hier...ähm, ich meine am Lagerfeuer... darüber Diskussionen wer nun der Schuldige ist wenn jemand einen brennenden Stock auf die Strohhütte wirft, derjenige der den Stock geworfen hat oder derjenige der die Hütte aus Stroh gebaut hat statt einfach in einer Höhle zu leben.

 

[andy_m4]

Die wichtigste Stellschraube hat der Kunde selbst in der Hand, nutzt keine offline Software, die immer irgendwelche nicht geschlossene Lücken haben wird sondern online Dienste für die der Anbieter die volle Verantwortung trägt.

Das ist so auch wenig zielführend. Bei Cloud-Computing ist die Situation ja nicht wirklich besser. Das war ja auch so ein Versprechen (wenn sie Software bei uns läuft können wir sie auch für Dich pflegen; also die Pflege ist in professionellen Händen!!!!) was letztlich sich als nicht haltbar heraus gestellt hat.
Klar. Wenns Dir nur darum geht irgendwelche Verantwortlichkeiten durch die Gegend zu schieben, kann man das gern machen (wobei Du dann trotzdem Dir noch die Frage gefallen musst, warum Du Dir nen ranzigen Anbieter ausgesucht hast der sich hacken lässt), hilft Dir in der Sache aber nicht weiter.

Das dann ein Fix der auf zig Systemen laufen muss und zunächst einmal ausführlich getestet wird, einige Zeit benötigt bevor er auf die Allgemeinheit losgelassen wird, liegt in der Natur der Sache.

Das erklärt immer noch nicht, warum die Betroffenen nicht vorab gewarnt worden sind. Die hat man schlicht ins offene Messer laufen lassen.
Klar kann man sagen: Man hat deshalb keine Warnung ausgegeben, damit böse Buben erst gar nicht auf die Lücke aufmerksam gemacht werden.
Das dumme ist nur, die bösen Buben haben das trotzdem mitgekriegt. Die Angriffe fanden ja vermehrt statt. Der Einzige der nicht Bescheid wusste war der Exchange-Admin, ums mal plakativ zu formulieren.

Stelle dir vor Microsoft hätte einen verbuggten Hotfix im Januar losgelassen, was wäre das Geschrei dann groß gewesen.

Ähm. Microsoft hat vorher schon ein fehlerhaftes Produkt auf die Menschheit losgelassen was überhaupt erst zu den zahlreichen Hacks geführt hat. Das ist offenbar kein Problem. Oder wie?

An dem Tag wo man sowas publik macht, braucht man dann stabile und funktionierende Patches, weshalb bei allen Sicherheitslücken die entdeckt werden, egal ob bei Microsoft, Google, Apple oder jeden beliebigen anderen Anbieter es Vorlaufzeiten gibt, bevor man damit publik geht und lange davor werden Partner und große Dienstleister informiert.

Ja. Das hat ja wirklich "super" geklappt.
Ich frag mich nur, wie oft noch irgendwelche Computersysteme explodieren müssen, bis mal jemand auf die Idee kommt diese ganze Gammel-IT zu entsorgen und mal was Ordentliches hinzustellen.

Du bringst die Diskussion gerade auf ein Niveau, welches weit über unser beiden Gehaltschemen liegt…

Das stimmt. Wenn Du meinst, mit irgendwelchen Sanktionen haben nen signifikanten Anteil an Verbesserung von Computer-Security, dann brauchen wir wirklich nicht weiter drüber reden.

Ja, IMHO, und wenn nachweislich chinesische/nordkoreanische Hacker einen großangelegten koordinierten staatlichen Angriff auf Exchange Server in der EU durchgeführt haben, MUSS man Sanktionen gegen China/Nordkorea in den Raum werfen…

Komm doch mal vom diesem Hacker-Ding weg. Von der Seite kriegst Du die Sache nicht in den Griff. Das scheitert schon allein daran, das Du im Zweifel nicht mal genau weißt woher der Angriff kommt. Der Ausgangsrechner ist möglicherweise selbst nur Teil eines Botnetzes was von völlig woanders gesteuert wird.

 

[xexex]

Würde ein Autobauer defekte Bremsanlagen verbauen und diesen Mangel wider besseren Wissens nicht beseitigen (durch Rückrufe und Produktrevisionen), könnte man ihn für daraus resultierende Unfälle haftbar machen. Warum ist das in der IT nicht so?

Weil dieser Punkt nicht gegeben ist, denn wäre die Lücke bekannt, wäre sie geschlossen worden.

Du machst es dir aber auch zu leicht, weil letztlich ist die Sicherheit eines solchen Produkts von dessen Konfiguration abhängig. Wer seine Festplatte im Notebook nicht verschlüsselt und dann seine Daten im Netz wiederfindet, wird sich nicht auf den Hersteller berufen können, er sei für den Datengau zuständig.

Wer einen Exchangeserver "hochsicher" betreiben will und muss, hängt davor noch mindestens eine WAF, platziert die Clientserver in eine DMZ und überwacht sein Netzwerk sowieso auf jegliches verdächtige Verhalten.

Wer auf das alles verzichtet, der kann sich nicht nachträglich darüber beschweren, wen er einem Angriff ausgesetzt wurde, weil es nun mal bekannt ist, dass keine Software der Welt 100% fehlerfrei ist.

 

[Evil E-Lex]

Bei Exchange ist das halt AFAIK (ich bin kein Windows Mensch) so, dass Mailbox Server und IIS auf der selben Kiste laufen müssen

Das ist schon lange nicht mehr so. Wird aber dennoch bei vielen Installationen so gemacht, weil die Umgebung schlicht zu klein ist, mehrere Exchange-Server mit verschiedenen Rollen zu rechtfertigen.
Das ist eine der Ursachen für die jetzigen Probleme. MS positioniert Exchange klar als Enterprise-Produkt, verkauft es aber weiterhin lustig an Klein- und Kleinstunternehmen, damit ja die installierte Basis nicht verloren geht. Die andere Ursache sind die altgedienten Exchange-Admins, die noch mit ihrem Exchange 5.5 oder 2000 Mindset an die Sache rangehen, aber dabei verkennen, dass sich die IT-Welt seitdem ordentlich weitergedreht hat.

 

[andy_m4]

Also das Ganze auf "Microsoft ist schuld" herunterzubrechen ist sicherlich auch Quatsch.
Denn wenn man es so sieht: Microsoft ist ein profitorientiertes Unternehmen. In dieser Eigenschaft wollen die natürlich ihren Gewinn maximieren. Produkte und Dienstleistung verkaufen bringt geht. Bugs fixen bzw. generell ordentliche Qualität abliefert ist da ein Kostenfaktor. Der Softwarehersteller hat da halt kein natürliches Interesse das zu tun, weils halt der Profitmaximierung entgegensteht.

Nun gibts zwei Möglichkeiten darauf zu reagieren. Entweder mit (gesetzlicher) Regulierung der halt die Hersteller zwingt zumindest bestimmte Mindeststandards einzuhalten. Ist übrigens nichts Neues. Haben wir in anderen Bereichen auch. Im Grunde genommen ist der Softwaremarkt da noch der einzige Bereich, der da wenig reguliert ist. Allenfalls der Finanzmarkt kann da noch mithalten. ;-)

Die zweite Möglichkeit (man kann auch beide kombinieren; muss kein entweder-oder sein) ist halt Wettbewerb im freien Markt. Der bringt die Unternehmen halt dazu gute Produkte zu bauen, weil sonst macht es die Konkurrenz.

Unglücklicherweise haben wir diesen Wettbewerbseffekt nicht.
Das liegt aber auch oftmals an uns selbst. Wenn irgendwie was Groupware-mäßiges gebraucht wird und ich will da irgendeine Open-Source-"Bastellösung" einführen dann hab ich nämlich immer ein Verantwortungsrisiko. Wenn etwas schief geht, wird der Chef mir sagen: "Warum haben wir nicht was vom Marktführer genommen?"

Nehm ich Exchange und was schief geht, dann zählt immer die Ausrede "Na aber das nehmen doch alle!". Ich werde also eher zu Exchange greifen. Aber nicht, weil es das bessere Produkt ist. Sondern weil das Risiko das ich einen auf den Deckel krieg, wenn was schief geht, geringer ist.

Aber genau das setzt quasi diesen Wettbewerb um das bessere Produkt zumindest zum Teil außer Kraft.
Genau dieses Wettbewerbsding muss ich halt am laufen halten.

Wer einen Exchangeserver "hochsicher" betreiben will und muss, hängt davor noch mindestens eine WAF, platziert die Clientserver in eine DMZ und überwacht sein Netzwerk sowieso auf jegliches verdächtige Verhalten.

Genau. Komplexität mit noch mehr Komplexität zu erschlagen hat sich ja schon immer bewährt.

weil es nun mal bekannt ist, dass keine Software der Welt 100% fehlerfrei ist.

Ja. Das ist immer die Ausrede die gebracht und völlig unkritisch übernommen wird.
Also ja. Fehler völlig wegkriegen ist nicht. Das heißt aber nicht, das man gar nichts machen kann. Man kann sehr wohl auch systematisch bestimmte Fehler zumindest arg verringern.

Interessant fand ich folgende Beobachtung an mir selbst. Früher wenns ein "Softwarepproblem" gab hab ich immer bei mir selbst geguckt ob ich irgendwo was falsch gemacht hab. Weil ganz oft war das eben auch so, das der Fehler bei mir lag. Das es tatsächlich mal ein Bug in der Software gab, kam vor, war aber eher selten.

Wenn heute was schief geht, dann guck ich zuerst bei der Software. Guck in Bugtracker etc. Weil erfahrungsgemäß werde ich dann auch ziemlich rasch fündig.
Gut. Das ist jetzt eine Einzelerfahrung. Aber die bekomme ich auch hin und wieder von anderer Seite bestätigt. Ich glaub das liegt auch daran, das patchen heute (Dank Internet) sehr einfach ist. Wenn Du früher Software ausgeliefert hast, dann waren Fehlerkorrekturen auszurollen ein riesen Aufwand. Du hast halt lieber einmal mehr getestet als möglicherweise ne fehlerhafte Software auszuliefern wo Du dann irgendwie Disketten mit Patches etc. verschicken musst.
Und wenns mal Patches gab, dann wurde auch nicht irgendwie Dateien getauscht oder so, sondern da hat man dann gern mal einen Binärpatch gekriegt, der irgendwie zwei Bytes in Deinem Binary getauscht hat. Die sollten halt auch nicht groß sein.

Kann sich heute gar keiner mehr vorstellen. Wenn Du heute ne nagelneue Software installierst, dann lädt die erst mal ein paar GB Software vom Updateserver. :-)

Nu kann man natürlich sagen:
Ja mag ja sein das früher die Programme weniger Bugs hatten, aber die waren ja auch einfacher. Da hattest Du nicht irgendwie ne GUI und zahllose Funktionen usw. Software ist umfangreicher geworden.

Das ist korrekt (wobei man an der Stelle eigentlich noch mal auf die Thematik unnötige Komplexität eingehen müsste). Auf der anderen Seite hat sich aber auch die Softwareentwicklungsseite enorm verbessert. Damals wurde halt noch mit nem Faustkeil die Bits auf nem Magnetband geritzt. Wenn Du die heute ne moderne IDE anschaust dann unterscheidet sich das halt grundlegend.
Auch die ganzen moderne Programmiersprachen die ganze Fehlerklassen eliminieren und sonstige Tools die Dir helfen, das hattest Du früher einfach nicht.

Ich glaube dieses "Software ist komplexer geworden" und "Fehler sind unvermeidbar" sind in erster Linie Schutzbehauptungen, um die eigene Softwarequalität zu rechtfertigen. Anhand von Open-Source-Software lässt sich das manchmal auch sehr gut beobachten. Bei Closed-Source-Software sieht es meist ne ne ganze Ecke schlimmer aus, weil da halt keiner reingucken kann was letztlich bedeutet, das die Entwickler pfuschen ohne Ende (Stichwort: Crunchtime; und Zeit fürs Aufräumen wird sich nicht genommen, weil es dann schon darum geht das nächste Feature zu implementieren oder kritische Bugs wegzufixen die man durch das Herumgeschlampe angehäuft hat).

Ich find diese Einstellung "Jede Software hat Fehler" auch deshalb sehr kritisch. Weil Du dann gar nicht darüber nachdenkst was Du prozessmäßig besser machen könntest, wenn Du Fehler eh als gottgegeben annimmst.
Das Fehler passieren ist die eine Sache. Wenn Du Fehler aber nicht zum Anlass nimmst um daraus zu lernen, dann ist das noch mal ne ganz andere Hausnummer.

 

[xexex]

Genau. Komplexität mit noch mehr Komplexität zu erschlagen hat sich ja schon immer bewährt.

Willst du ein sicheres Netzwerk brauchst du eine heterogene Struktur und mögliche Fehler eines Herstellers so weit wie möglich auszuschließen. Das ist keine Erfindung der Neuzeit und große Firmen handhaben es eben nun mal auch so.

Der Exchange Server ist zu dem kein Sicherheitsprodukt und wenn die Sicherheit wichtig ist, brauchst du auch Produkte, Lösungen und das Wissen um diese zu gewährleisten.

Also ja. Fehler völlig wegkriegen ist nicht. Das heißt aber nicht, das man gar nichts machen kann

Man kann ganz vieles machen und eben vermeiden, dass solche mit Sicherheit vorhandene Lücken ausgenutzt werden können.

Hast du dir mal je ein Guide angeschaut wie eine Exchange Server Bereitstellung auszusehen hat? So hat es nicht erst seit heute auszusehen.

Fakt ist jedoch, dass es bei den kleinen Kunden so nicht aussieht und wenn du deine Haustür offen lässt, darfst dich nicht darüber beschweren, wenn dir jemand was klaut oder den Hersteller deines Kühlschranks verklagen, dass dieser nicht diebstahlsicher gebaut wurde.

Ergänzung (10. März 2021)

Ich find diese Einstellung "Jede Software hat Fehler" auch deshalb sehr kritisch. Weil Du dann gar nicht darüber nachdenkst was Du prozessmäßig besser machen könntest, wenn Du Fehler eh als gottgegeben annimmst.

Genau das verstehst du falsch! Jede Software hat Fehler, also muss ich dafür sorgen, dass mindestens eine andere Software solche Fehler erkennt oder den Schaden der dadurch entstehen kann reduziert. Wenn ich darauf verzichte, gehe ich bewusst ein Risiko ein, denn "jede Software hat Fehler" ist eine Konstante in dieser Rechnung, wie man damit umgeht hingegen nicht.

 

[andy_m4]

Willst du ein sicheres Netzwerk brauchst du eine heterogene Struktur und mögliche Fehler eines Herstellers so weit wie möglich auszuschließen.

Natürlich kann und sollte man rund herum noch Sicherheitsmaßnahmen ergreifen, das wenn es mal zu nem Störfall kommt der potentielle Schadeneingedämmt ist.
Aber zuvorderst darf Software keine Bugs haben. Wenn wir darüber diskutieren müssen, ob und in welchen Umfang Bugs akzeptabel sind, dann können wir es direkt sein lassen.
Und hier bei Exchange haben wir nen glasklaren Fall eines Bugs. Microsoft sagt selber: "Ja. Hier haben wir Mist gebaut. Wir bessern nach". Worüber diskutierst Du da eigentlich noch?

Genau das verstehst du falsch! Jede Software hat Fehler, also muss ich dafür sorgen, dass mindestens eine andere Software solche Fehler erkennt oder den Schaden der dadurch entstehen kann reduziert. Wenn ich darauf verzichte, gehe ich bewusst ein Risiko ein, denn "jede Software hat Fehler" ist eine Konstante in dieser Rechnung, wie man damit umgeht hingegen nicht.

Du verstehst das falsch. :-)

Klar muss ich mit Fehlern rechnen. Aber wichtig ist vor allem solche Fehler zu vermeiden. Weil umso fehlerhafter die Software ist, umso komplexer müssen drum herum die Sicherheitsmaßnahmen sein. Umso komplexer die Sicherheitsmaßnahmen sind, umso höher ist die Wahrscheinlichkeit das da auch Fehler sind (ich verstehe schon diese Denke nicht, das auf der einen Seite Gammelsoftware akzeptiert wird aber auf der anderen Seite wird dann plötzlich angenommen das dieses ganze InstrusionDetectionFirewall-AV-Gedöns dann fehlerfrei ist).
Um dann Deine komplexe Firewall zu schützen packst Du dann noch ne Firewall davor. Und weil Du bei der auch nicht sicher sein kannst noch eine davor. Ist jetzt ein wenig pointiert formuliert, aber letztlich ist es so.

Dann lässt sich auch sehr schön in der Praxis bestaunen, wo Du nen Trend dahin hast, das Komplexität und Bugs gar nicht mehr versucht wird zu verhindern, sondern nur noch verwaltet und weiter aufgestapelt.
Der Turm wird höher und höher und natürlich wackliger. Genau deshalb hast Du das, was Du in der Praxis beobachtest. Das Dir die Systeme reihenweise zusammenbrechen.

Wie gesagt. Das sind nicht irgendwie theoretische Überlegungen oder so. Das ist das, was man beobachtet.

Dein Ansatz ist: Weiter so (völlig ignorierend, das links und rechts alles wegbrennt). Wir haben hier zwar ne Strohhütte, aber wenn wir hier ein bisschen Panzertype drüber kleben und da ein bisschen flammhemmende Farbe draufkleistern passt das schon.

Mein Ansatz ist: Wir müssen diesen Teufelskreislauf durchbrechen. Das Konzept Strohhütte hat sich als unzureichend erwiesen. Lass es uns doch mal mit Stein (oder wenigstens Holz) probieren. Klar. Auch ein Stein-Haus muss ich Brandschutzmaßnahmen haben. Aber das hat halt ne ganz anderes Niveau, weil nicht jeder Funkenflug gleich automatisch nen Flächenbrand auslöst.

 

[Evil E-Lex]

Natürlich müssen wir den Teufelskreis durchbrechen. Das gelingt aber nur, wenn alle mitziehen. Solange die Mentalität bei den Entscheidern weiterhin lautet "Das war ein Softwarefehler, da kann man nichts machen.", kannst du auf technischer Ebene rein gar nichts ändern. Erschwerend kommt hinzu, dass der Markt für Groupware nunmal keine brauchbaren Alternativen bietet. Was will man statt Exchange nehmen? Domino, Groupwise, oder OSS (das am Ende für ein Produkt aus dutzenden verschiedenen Projekten steht, alle mit ihren eigenen Problemen)? Ich sehe da kurzfristig ehrlich gesagt nur Probleme, aber keine Lösungen.

 

[xexex]

Aber zuvorderst darf Software keine Bugs haben.

Was bei keiner Software der Fall ist, da brauchen wir nicht darüber zu diskutieren.

Worüber diskutierst Du da eigentlich noch?

Darüber, dass nachdem die Lücke geschlossen wurde, bestimmt noch 10 weitere Lücken existieren, von deren Existenz wir aktuell nichts wissen. Das System ist nun genauso sicher oder unsicher wie vorher, wenn es nicht zusätzlich entsprechend abgesichert wird.

Weil umso fehlerhafter die Software ist, umso komplexer müssen drum herum die Sicherheitsmaßnahmen sein.

Vollkommen richtig! Um einen Exchange Server korrekt abzusichern, reicht keine portbasierte Firewall sondern wird mindestens eine WAF und ein SMTP Gateway benötigt. Der Exchange Server ist sogar nach der Installation so konfiguriert, dass er nur Mails von internen Quellen akzeptiert.

Das dies von kleinen Buden ignoriert wird und der Server dann oft direkt hinter einem "Baumarkrouter" platziert wird, ist durchaus sehr oft der Fall. Das eine solche Installation dann keineswegs als sicher gelten kann, sollte jedem Admin bewusst sein, wird aber auch von Seiten der Kunden genau so hingenommen.

auf der anderen Seite wird dann plötzlich angenommen das dieses ganze InstrusionDetectionFirewall-AV-Gedöns dann fehlerfrei ist

Ohne das "Gedöns" kannst du einen Einbruch in dein Netzwerk gar nicht feststellen und wenn Microsoft oder ein anderes Unternehmen eine Lücke publik macht, sind deine Daten, sofern sie irgendwie relevant waren schon längst ausgespäht.

Ich wiederhole es noch einmal, dass eine Software Bugs enthält ist eine Konstante und je komplexer eine Software ist desto komplexer und häufiger sind die Bugs.

Um dann Deine komplexe Firewall zu schützen packst Du dann noch ne Firewall davor. Und weil Du bei der auch nicht sicher sein kannst noch eine davor. Ist jetzt ein wenig pointiert formuliert, aber letztlich ist es so.

Genauso wird es in größeren Firmen gehandhabt, wie ich dir bereits auf dem Bild gezeigt habe. Eine Firewall schützt das Frontend, eine weitere dahinter das Backend und im besten Fall hängt ein Intrusion Detection System noch dazwischen.

Was glaubst du wie die Sicherheitslücke im Exchange Server entdeckt wurde?

In January 2021, through its Network Security Monitoring service, Volexity detected anomalous activity from two of its customers’ Microsoft Exchange servers. Volexity identified a large amount of data being sent to IP addresses it believed were not tied to legitimate users. A closer inspection of the IIS logs from the Exchange servers revealed rather alarming results.
https://www.volexity.com/blog/2021/...-microsoft-exchange-zero-day-vulnerabilities/

Zwei Monate später wurde die Lücke publik gemacht und ein Patch veröffentlicht, glaubst du sowas nehmen Firmen die sensible Daten haben ohne umfassende Schutzmaßnahmen einfach in Kauf?

 

[chartmix]

Ich glaube ja dieses "Die-Hacker-sind-schuld"-Gequatsche ist letztlich auch nur dafür da, um von den eigenen Defiziten abzulenken (klang hier im Thread ja auch schon an). Wenn die Hacker schuld sind dann ists für mich halt bequem, weil ich mich dann nicht drum kümmern muss bei mir selbst mal aufzuräumen.

Warum klingt das so eindimensional? Why not both?

 

[konkretor]

Also wer mehr Wissen will was da genau gepatcht wurde findet alle Infos in diesem Blog Eintrag


https://www.praetorian.com/blog/reproducing-proxylogon-exploit/

 

[Tronix]

Seit dem Patch knallt mir mein Server 4-5x Mal am Tag folgendes in die Eventlog:

Quelle: ASP.NET 4.0.30319.0
Ereignis ID: 1309

Spoiler: Ereignis ID: 1309

Event code: 3005
Event message: Es ist eine unbehandelte Ausnahme aufgetreten.
Event time: 11.03.2021 17:07:52
Event time (UTC): 11.03.2021 16:07:52
Event ID: 284c9122cddc488fae2529c7dcb559e7
Event sequence: 995
Event occurrence: 201
Event detail code: 0

Application information:
    Application domain: /LM/W3SVC/1/ROOT/owa-2-132598643
    Trust level: Full
    Application Virtual Path: /owa
    Application Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\
    Machine name: HOMESERVER

Process information:
    Process ID: 10684
    Process name: w3wp.exe
    Account name: NT-AUTORITÄT\SYSTEM

Exception information:
    Exception type: ArgumentException
    Exception message: Invalid input value
Parametername: input
   bei Microsoft.Exchange.Data.ApplicationLogic.Cafe.BackEndServer.FromString(String input)
   bei Microsoft.Exchange.HttpProxy.OwaResourceProxyRequestHandler.ResolveAnchorMailbox()
   bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.InternalBeginCalculateTargetBackEnd(AnchorMailbox& anchorMailbox)
   bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<BeginCalculateTargetBackEnd>b__3b()
   bei Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(TryDelegate tryDelegate, FilterDelegate filterDelegate, CatchDelegate catchDelegate)
   bei Microsoft.Exchange.HttpProxy.Diagnostics.SendWatsonReportOnUnhandledException(MethodDelegate methodDelegate, LastChanceExceptionHandler exceptionHandler)
   bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.CallThreadEntranceMethod(MethodDelegate method)



Request information:
    Request URL: https://homeserver:443/owa/auth/x.js
    Request path: /owa/auth/x.js
    User host address: 104.237.140.169
    User:
    Is authenticated: False
    Authentication Type:
    Thread account name: NT-AUTORITÄT\SYSTEM

Thread information:
    Thread ID: 150
    Thread account name: NT-AUTORITÄT\SYSTEM
    Is impersonating: False
    Stack trace:    bei Microsoft.Exchange.Data.ApplicationLogic.Cafe.BackEndServer.FromString(String input)
   bei Microsoft.Exchange.HttpProxy.OwaResourceProxyRequestHandler.ResolveAnchorMailbox()
   bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.InternalBeginCalculateTargetBackEnd(AnchorMailbox& anchorMailbox)
   bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<BeginCalculateTargetBackEnd>b__3b()
   bei Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(TryDelegate tryDelegate, FilterDelegate filterDelegate, CatchDelegate catchDelegate)
   bei Microsoft.Exchange.HttpProxy.Diagnostics.SendWatsonReportOnUnhandledException(MethodDelegate methodDelegate, LastChanceExceptionHandler exceptionHandler)
   bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.CallThreadEntranceMethod(MethodDelegate method)


Custom event details:

Die User host address ist eine IP aus den USA, ändert sich aber bei jedem Eintrag. (bzw. auch mal aus DE: 185.206.91.42)

Hat das sonst noch jemand beobachtet? Eventuell ein Crawler welcher weiterhin auf die Lücke scannt?

Dürften auch manch andere beobachtet haben: https://techcommunity.microsoft.com/t5/exchange/suspicious-events/m-p/2194366

 

[foo_1337]

Ist doch normal und logisch:

% grep -c owa /var/log/nginx/access.log
258

Und das ist nur eine von vielen Kisten hier, die mit Exchange überhaupt nichts zu tun haben. Und das wird auch noch die nächsten Monate so weiter gehen.

 

[Poulton]

Das klappt seit Server 2016 nicht, weil wenn du dort auf "Update suchen" gehst, wird auch direkt im Anschluss eine Aktualisierung gestartet.

sconfig nutzen. Darüber ist eine Auswahl der zu installierenden Updates noch möglich.

 

[leon_20v]

Hi zusammen, bei uns war es wohl zu spät mit dem Update. Ich habe am 05.03 gepatacht und der erste Eintrag ist vom 03.03 5 Uhr.

Am Virenscanner ging der ganze Müll vorbei und so kämpfe ich jetzt seit 3 Tagen die Kisten sauber zu bekommen. Allerdings habe ich das Problem, dass 7 Server folgende Seiten immer wieder aufrufen:
hXXp://cdn[.]chatcdn[.]net/p?low, hXXp://p[.]estonine[.]com/p

Ich habe schon einige Viren gefunden und auch entfernt. Ich habe auch schon einige WMI Objekte und Tasks gefunden und entfernt (auf dem Exchange), auf den anderen Servern waren die aber leider nicht zu finden.

Hat jemand den ganzen Rotz schon restlos runter bekommen oder komme ich um eine Neuinstallation nicht herum?

 

[sini]

Hi zusammen, bei uns war es wohl zu spät mit dem Update. Ich habe am 05.03 gepatacht und der erste Eintrag ist vom 03.03 5 Uhr.

Am Virenscanner ging der ganze Müll vorbei und so kämpfe ich jetzt seit 3 Tagen die Kisten sauber zu bekommen. Allerdings habe ich das Problem, dass 7 Server folgende Seiten immer wieder aufrufen:
hXXp://cdn[.]chatcdn[.]net/p?low, hXXp://p[.]estonine[.]com/p

Ich habe schon einige Viren gefunden und auch entfernt. Ich habe auch schon einige WMI Objekte und Tasks gefunden und entfernt (auf dem Exchange), auf den anderen Servern waren die aber leider nicht zu finden.

Hat jemand den ganzen Rotz schon restlos runter bekommen oder komme ich um eine Neuinstallation nicht herum?

7 Server? Meinst du Exchange-Server oder meinst du damit andere Server in der Domäne?

Die Infizierung ist ja jetzt schon ein paar Tage her ... die könnten sich sonstwo eingenistet haben. Wir haben das gelöst in dem wir den Exchange isoliert hatten und dann den Stand vom 02.03. wiederhergestellt, gepatch und die bis dahin eingegangen Mails manuell extrahiert und übertragen haben.

Wenn du den wiederherstellst oder neu installierst, widerstehe der Versuchung die alte Exchange-Datenbank wieder einzubinden! In der Datenbank kann sich sonst was verstecken ...

Habe am Freitag einen neuen Kunden bekommen, bei dem die Infizierung komplett frei bis jetzt gewütet hat. Wir stampfen nun ALLES ein. Server UND Clients werden neu installiert und das gesamte Netzwerk neu aufgesetzt.

 

[leon_20v]

Andere Server in der Domäne sind auch betroffen, aber anders. Diese haben diesen CryptoMiner Lemonduck in verschiedenen Varianten drauf.

Ich sehe nur in der Firewall wie versucht wird diese URLs zu öffnen um Schadsoftware nachzuladen. Die Virenscanner finden den Virus komischerweise nicht.

 

[Rickmer]

Wenn die gesamte Domäne zu dem Ausmaß kompromittiert ist musst du eigentlich alles neu aufsetzen oder aus dem Backup wiederherstellen... um ganz sicher zu sein sollte der Zeitpunkt der Wiederhestellung der 25./26. sein, also bevor die erste größere Welle an Schadware am 27./28. rausging

nicht vergessen, dich bei der Polizei und beim Datenschutzbeamten zu melden

 

[leon_20v]

Das es da keine Möglichkeit gibt diesen Schrott zu entfernen. Es ist echt zum Mäusemelken.

Echt scheisse dass es trotz Patch erst so spät aufgefallen ist.

Bis zum 26. ist eine ganz schön lange Zeit, da ist ja extrem viel Daten verloren.

Das schlimme ist ja, man weiß nicht mal welche Systeme betroffen sind. Ich habe in der Firewall gesehen, dass komische Seiten aufgerufen werden. Dem Virenscanner ist das herzlich egal weil er die Powershell oder Task oder was auch immer nicht kennt.

 

[sini]

Dem Virenscanner ist das herzlich egal weil er die Powershell oder Task oder was auch immer nicht kennt.

Naja ein Powershell oder Batch-Skript ist ja jetzt auch erstmal nichts "seltsames". Ich habe selbst Skripte mit curl.exe zum Download von Daten.

Der Virenscanner wird erst aktiv wenn tatsächlich Schadcode abgelegt wird. Wobei hier natürlich wieder die Frage wäre, "was ist Schadecode". Trojaner, Würmer usw. sind offensichtlich, aber wenn die jetzt so eine Art Teamviewer installieren ... ¯\(ツ)/¯