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

[Tronix]

@foo_1337
Ziemlich interessante Ansicht die du vertrittst…

Wenn bsplw. Computerbase Opfer eines Hacks wird, und dein PW im Netz landet bist einzig und allein DU schuld, weil du hier Mitglied bist? Wenn dein Bankkonto mal aufgrund einer Sicherheitslücke geknackt wird, und du ein paar Tsd Euros verlierst, bist DU schuld, weil du genau bei der Bank Kunde bist?

Okey… Why not...

 

[foo_1337]

Wenn bsplw. Computerbase Opfer eines Hacks wird, und dein PW im Netz landet bist einzig und allein DU schuld, weil du hier Mitglied bist?

Wenn mein PW leaken sollte, ist es futsch. Ist mir in dem Fall relativ egal. Leider gibt es jedoch mehr als genug User, die das selbe Passwort noch an zig anderen Seiten und idealerweise noch für die registrierte email Adresse verwenden. Also wieder: Selber schuld. Das hat man selbst in der Hand.

Und der Vergleich mit der Bank greift in dem Fall nur dann, wenn ich selbst dafür sorge, dass Pin + TAN übernommen werden können. Daher: Selbst schuld.
Falls die Bank selbst Opfer eines Angriffs wird, verliere ich kein Geld.

 

[el.com]

Ich sehe das nach wie vor pragmatisch: Wenn jemand meine Kisten owned, bin ganz alleine ich daran Schuld, that's it.

Naja, das finde ich jetzt übertrieben kurz gegriffen. Natürlich hast du recht, dass ein Mindestmaß an Eigenverantwortung dazu gehört. Und das beinhaltet eben auch Punkte wie Systemhärtung, Schließung von nicht-benötigten Ports, regelmäßiges Einspielen von Patches, Verwendung sicherer Authentifikationsmethoden (insb. in Bezug auf Passwörter) u.v.m.
Alleine durch Einhaltung des grundlegenden Security-Einmaleins lassen sich schon viele Angriffe vermeiden. Aber ein IT-System das aus dem Internet erreichbar sein muss kann man nicht immer zu 100 % sicher machen. Siehe die Heartbleed-Lücke damals. Ein Bug in der eingesetzten Software kann immer mal auftreten. Und wenn der dann auch noch eine RCE ermöglicht, vllt sogar verbunden mit einer Privilege Escalation, muss daran nicht unbedingt der Anwender schuld sein. Und auch nicht sofort der Hersteller. Meiner Ansicht nach geht es bei Bekanntwerden einer Lücke viel mehr darum, wie (und vorallem wie schnell) der Hersteller dann reagiert. Man kann von niemandem verlangen von Beginn an absolut sichere Software liefern zu müssen. Also solche, die sich zweifelsfrei nicht hacken lässt. Das ist ein Ding der Unmöglichkeit. Aber man kann sehr wohl Hersteller in die Verantwortung nehmen, wenn diese dann bei Bekanntwerden nicht oder nur mangelhaft darauf reagieren.

 

[foo_1337]

Nope, sehe ich anders. Aber vermutlich liegt es auch an meinem Umfeld. Ich bin für das was ich und mein Team machen voll verantwortlich, habe umgekehrt aber auch sehr freie Hand. Und Heartbleed ist übrigens ein gutes Beispiel: Kaum jemand scherte sich danach darum etwas zu ändern. Da wurde halt openssl aktualisiert und weiter gemacht wie vorher. Ich hatte diese Diskussionen früher auch mit local root lücken: "Ist doch nicht so schlimm, alle lokalen User haben doch sowieso sudo rechte, können wir auch später patchen". Nein, das muss sofort gepatched werden, denn wenn die webapp ne Lücke hat, kommt eines zum anderen. Klar hast du bei einem 0day verloren, aber dann gilt es eben VORHER dafür zu sorgen, dass der Schaden dadurch minimiert ist. Und genau davon spreche ich. Sei es nun durch privsep, jails, lxc, east-west schutz, waf usw usf. Auch musste ich mir in der Vergangenheit oft anhören, dass lokale Paketfilter ja nix bringen. Ja, sie sind leichter aushebelbar und ersetzen nicht den Schutz außerhalb der Zone. Aber innerhalb der Zone helfen sie sehr wohl, denn acuh da muss nicht alles exposed sein. Mittlerweile dank NSX auch anders machbar. Und all die Dinge tragen am Ende zu einem guten Konzept bei und so bleibt dann in den allermeisten Fällen der Schaden bei einem 0day gering. Und genau das liegt eben in meiner Hand.

Aber ich seh' schon: Ich stoße mit meiner Mentalität hier nicht gerade auf Anklang. Macht auch nichts, ich bin ja (hoffentlich) kein Kunde von euch Meine Kunden hingegen freut es.

 

[Tronix]

Kein Thema, ist deine Meinung und wird zur Kenntnis genommen…

Meine ist eher anders, speziell beim Exchange Leak:
1. Schuldiger: Hacker
2. Schuldiger: Microsoft, verantwortlich ein sicheres Produkt zu liefern
3. Schuldiger: Leichtsinniger Admin

Zwischen 1-3 könnte man noch die Firma nennen, die sich für die Software entschieden hat, oder den Auftraggeber für den Hack (vl staatlich inszeniert?), oder den Netzbetreiber der sich um Sicherheit im Netz nicht kümmert (Bruteforce Unterbindung zb) etc. etc.

Und der Anwender? Der letztendlich den größten Schaden hat, da SEINE Daten betroffen sind? Nö, den sehe ich nicht mal ansatzweise als Schuldigen. Selbst wenn sein Passwort nur aus „123“ besteht, geht das Grundproblem erstmal von den 3 Punkten oben aus…

 

[snaxilian]

@el.com Das beliebte Security 1x1 gilt aber auch für Architekten und Entwickler. Viele Programmiersprachen erlauben "Schlampigkeit", schöner Hintergrundartikel dazu: https://www.heise.de/hintergrund/En...ftware-und-Programmierfehler-ist-4879795.html

Die Richtung von @andy_m4, @foo_1337 oder auch der Artikel von Bruce Schneier geht in die gleiche Richtung. Sobald das Grundgerüst und der Updater halbwegs funktioniert wird es verkauft/veröffentlicht, Fehler erst ausgebügelt wenn diese auffallen oder aktiv ausgenutzt werden. Das gilt für Open Source genauso wie für Closed Source Software. Hauptsache schnell in den Markt und noch zwei Features mehr als die Konkurrenz.
TDD, Function-, Unit- und Integrationstests kommen so laaaaangsaaam erst in der Breite an aber das hilft halt nicht mehr bei der ganzen ranzigen und gammligen Software, die wir bereits haben und verwenden.

Die Betreiber/Admins solcher Software können dann nur noch mit haufenweise Mitigationen drum herum versuchen zu retten was möglich ist fahren im besten Fall was @foo_1337 erwähnte und noch ein paar Dinge mehr.

Aber das kostet Zeit und Geld und bringt dem unternehmerisch denkenden Entscheidungsträgern keinen Mehrwert solange es keine Regulatorien gibt, die die Betreiber dazu verpflichten. In manchen Bereichen ist dies in DE beispielsweise schon so, siehe KRITIS. Da hapert es oft leider an der Umsetzung, dass viel mehr Papier produziert wird mit Begründungen warum man etwas leider nicht umsetzen kann oder will anstatt es zu machen aber am Ende steht da dann eine Zahl drunter und diese Risiken müssen die Entscheidungsträger dann tragen.

Nachtrag zu #125:
Wieso genau akzeptieren wir haufenweise vermeidbare Fehler und verzichten auf Produkthaftung bei Software aber nicht bei anderen Dingen? Fenster bisschen schief eingebaut im neuen Haus? Aaaach nicht so schlimm, hier ein bisschen Mörtel, da ein bisschen Silikon, dann wird das schon halten und dicht sein.
Lebensmittel ein bisschen verunreinigt? Aaaach nicht so schlimm, Dreck reinigt ja den Magen und kleine Kinder haben früher auch viel Sand gefuttert.

Manuelles Gefrickel ist halt mehr so Handwerk und weniger Industriestandard aber hey vielleicht regelt das "der Markt" bald von selbst, siehe: https://twitter.com/isotopp/status/1366990737355780103

 

[greatdisaster]

Der Hacker ist doch nicht schuld sondern zu 100% Microsoft und dazu noch die Firmen die trotz der ganzen Probleme mit Active Directory und Ransomware weiterhin das überleben der Firmen an Microsoft Produkte binden. Dazu noch etwas Antiviren Snakeoil und schon denkt sich der Admin er wäre aus der Verantwortung.

 

[iSight2TheBlind]

@greatdisaster Wenn der Hacker nicht schuld ist sondern Microsoft sollten wir jetzt also besser mal das FBI nach Redmond schicken damit die Satya Nadella verhaften und den Hackern schicken wir am besten noch 100.00$ Belohnung, weil sie die Welt auf die kriminellen Machenschaften von Microsoft hingewiesen haben, ja?

Natürlich sind auch Anwender und Entwickler nicht vollkommen unbeteiligt am Schaden und dass IT-Systeme mittlerweile wenn sie durch Anwender- oder Adminfehler failen im großen Stil failen können sollte definitiv angegangen werden.
(Kein Anwender klickt absichtlich auf den Verschlüsselungstrojaner damit dann das gesamte Kliniknetz verschlüsselt wird und dass es dann das gesamte Kliniknetz erwischt ist ein großes Problem - aber ohne Verschlüsselungstrojaner keine Verschlüsselung)
Wenn ich einen Eimer Nägel vor deinem Auto von einer Brücke auf die Autobahn schütte, ist es dann deine Schuld, dass du die Autobahn genutzt hast, weil du kein Fahrzeug mit Kettenantrieb verwendest oder die deines Autoherstellers, weil sie aus Kostengründen keine Reifen verwendeten die durchstichsicher sind?

Oder ist es vielleicht doch meine Schuld, weil ich die Nägel auf die Fahrbahn geschüttet habe?

In der realen Welt kommt so etwas nur sehr selten vor, da es nur wenige "böse" Menschen gibt die so etwas tun würden und davon dann auch noch ein Teil Angst vor der Bestrafung hat, aber im Internet sieht man sich mit den "bösen" Menschen der gesamten Welt konfrontiert und die Gefahr der Bestrafung ist geringer, während die möglichen Gewinne (siehe Verschlüsselungstrojaner) bei wenig Aufwand ungleich höher sind.

Den Hacker hier aus der Schuld vollkommen rauszulassen ist absolut nicht angemessen.

 

[andy_m4]

Wieso genau akzeptieren wir haufenweise vermeidbare Fehler und verzichten auf Produkthaftung bei Software aber nicht bei anderen Dingen?

Wobei das ja (leider) auch in andere Bereiche rüberschwappt. Man denke nur an die Automobilindustrie, wo es ja auch Hotfixes (Rückrufe) gibt und wo es auch ne Art Patchday (Service nach 30 tkm).
Von der Softwareindustrie lernen heißt siegen lernen. ;-)

Den Hacker hier aus der Schuld vollkommen rauszulassen ist absolut nicht angemessen.

Du hast im Prinzip Recht. Die Frage ist ja eher, was bringt es mir dem Hacker die Schuld zu geben.
Dazu hatte ich mich ja in Posting #115 schon mal geäußert.
Schuldzuweisungen per se helfen mir ja auch nicht weiter. Es muss ja auch für die Zukunft etwas draus folgen. Ich muss mir also überlegen: Kann ich etwas ändern, was auch in meiner Einflusssphäre liegt.
Die Hacker krieg ich nicht weg. Aber das gammlige Exchange wegkriegen, das ist schon eher drin.

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.

Wenn ich einen Eimer Nägel vor deinem Auto von einer Brücke auf die Autobahn schütte, ist es dann deine Schuld, dass du die Autobahn genutzt hast, weil du kein Fahrzeug mit Kettenantrieb verwendest oder die deines Autoherstellers, weil sie aus Kostengründen keine Reifen verwendeten die durchstichsicher sind?

Na wenn Du schon vergleichen willst, dann richtig. In dem Fall wäre Microsoft der Autobahnbetreiber. Der weiß, das da Nägel rumliegen tut aber monatelang nix. Als dann im Januar die ersten Unfälle bekannt werden sagt er sich: "Gut. Da müssen wir wohl mal was machen. Lasst uns das mal im März wegräumen."

Und da hab ich noch nicht mal davon angefangen darüber zu reden, das Microsoft den Fahrbahnbelag blöderweise auch noch so gemacht hat, das drauffallende Nägel immer mit der Spitze nach oben liegen bleiben :-)

 

[Tronix]

Wobei man auch sagen muss: Microsoft hat sicherlich nicht 2 Monate das Problem in die Ecke gelegt, ignoriert und dann innerhalb von 24 Stunden am 3. März schnell den Patch entwickelt und rausgegeben.

Problemanalyse, Nachvollziehbarkeit, Fix erstellen & Lücke schließen dauert auch mal länger als einen Tag - gerade bei einem komplexeren System wie nem Exchange.

Aber ja ich gebe schon recht, Microsoft hat den Umfang der Lücke bestimmt auch unterschätzt. Aber dennoch alles auf MS schieben, ist nicht korrekt. Mutwillige Hacker sind immer noch das größte Puzzlestück im Gesamtbild…

 

[xexex]

Wer war nun der Hauptschuldige?

Der Dieb, denn Diebstahl von fremden Eigentum bleibt Diebstahl vom fremden Eigentum auch wenn dieser nicht ausreichend geschützt ist.

 

[andy_m4]

Aber ja ich gebe schon recht, Microsoft hat den Umfang der Lücke bestimmt auch unterschätzt.

Ich befürchte, die Situation ist schlimmer.
Bei solchen Software-Projekten gibts immer 3 Eskalationsstufen.

1. Wir haben Bugs und die müssen wir fixen.
2. Wir haben mehr Bugs als wir schaffen zu fixen also fixen wir nur die sicherheitsrelevanten
3. Wir haben mehr sicherheitsrelevante Bugs als wir fixen können also fixen wir nur noch die, wo es grad brennt

Bei 1 müsstest Du eigentlich schon mit nem Verkaufsstopp reagieren. Weil Du wissentlich ein kaputtes Produkt verkaufst. Stell Dir mal vor, Du würdest irgendwie Hammer verkaufen wo der Siel angebrochen ist. Dem Kunden ziehst Du dafür die Kohle ab und vertröstest ihn damit, das nächste Woche mal jemand vorbei kommt und den Stiel klebt (wobei es in Wirklichkeit noch perfider ist, weil Dir der Hersteller vorher gar nicht sagt was kaputt ist und Du kriegst ja auch kein Zeitplan a-la "nächste Woche machen wir den Stiel und übernächste Woche fixen wir das Problem das das Metallteil so wackelt").

Exchange steht bei Stufe 3 und ist damit außerhalb jeglicher Diskussion. Da sehe ich auch kein Spielraum sich das irgendwie Rechtfertigungsmäßig noch zurechtzubiegen.

Mutwillige Hacker sind immer noch das größte Puzzlestück im Gesamtbild…

Wie gesagt. Was bringts mir?
Also um jetzt noch mal das Beispiel mit dem nordkoreanischen Hacker zu bemühen. Was machste dann?

Ich stelle mir das grad mal so vor. Du rufst bei Kim Jong-un an und sagst ihm einer seiner Jungs hätte Dich gehackt und so ginge es ja nicht wegen Straftat und so. Er wiederum geht dann in sein Cyber-Offensive-Center zum verantwortlichen Hacker und stellt den zur Rede und schickt den auf die stille Treppe damit er mal darüber nachdenken kann, was er falsch gemacht hat.

Mal im ernst? Was erwartest Du Dir davon?

 

[foo_1337]

@xexex Rechtlich ja, deshalb habe ich ja auch gesagt "Wie sieht das der Richter?". Gesellschaftlich jedoch das Opfer selbst, denn jedem, dem er die Geschichte erzählen würde, würde ihm sagen oder zumindest denken: "Selbst schuld". Und auch die Versicherung sieht zwar nicht explizit das Wort "Schuld", aber sicher ein Mitverschulden durch grobe Fahrlässigkeit und wäre damit auch raus.

Und jetzt wieder on-topic: Wenn du einen Server für deine Kunden betreibst, grob fahrlässig handelst und das Ding geöffnet wird, wird dir dein Kunde auch dir die volle Schuld geben und nicht dem H4x0r.
Ergo: Irgendwelche Schuld dem H4x0r (ich hasse das Wort Hacker in diesem Kontext, denn in meiner Welt sind die die guten) zuspielen zu wollen ergibt keinen Sinn. Denn damit ist niemandem geholfen. Und wenn etwas so bekannt ist, dann ist es heute die Gruppe A, morgen Gruppe B und übermorgen scriptkiddie C. Daher bleibe ich dabei: Die Schuld liegt zunächst beim Betreiber. Immer. Und der kann im Zweifel die Schuld auf den Hersteller abwälzen und Schadensersatz fordern. Aber das wird in den seltensten Fällen gelingen.
Und in diesem Beispiel hier, wäre es, wenn man grundsätzlich Mißtrauisch Exchange ggü eingestellt ist, mit entsprechenden Maßnahmen im Vorfeld möglich gewesen, erst gar nicht betroffen zu sein.

 

[xexex]

Das sind die Stellschrauben an denen man drehen kann.

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. Microsoft hat von der Lücke im Januar erfahren, was glaubst du wann Microsoft diese Lücke bei deren Servern geschlossen hatte?

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. Stelle dir vor Microsoft hätte einen verbuggten Hotfix im Januar losgelassen, was wäre das Geschrei dann groß gewesen.

Ich kenne niemanden der von Hafnium angegriffen wurde, aber auf gut 95% der Server die wir betreuen, gab es am 03.03 Zugriffe die diese Lücke entweder ausnutzen wollten oder getestet haben ob man sie ausnutzen kann. 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.

 

[Tronix]

Du rufst bei Kim Jong-un an...

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

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…

Interessiert aber letztendlich eh keinen in der EU, weil ja augenscheinlich Microsoft an all dem schuld ist... also lassen wir das Thema...

 

[el.com]

Ich glaube auch dass die Diskussion über "Wer ist Schuld" wenig bringt. Um das zwar (juristisch) zu beantworten: Es ist der Hacker, der die Straftat begeht (bzw. dessen Auftraggeber); ggf. kommt eine Teilschuld für den Hersteller oder den Betreiber erschwerend dazu, sofern man denen Fahrlässigkeit nachweisen kann (durch Nichteinhaltung von gängigen Sicherheitsstandards).
Aber letztendlich bringt uns die Diskussion nicht zum Ziel, da die Täter meist in Regionen sitzen, wo sie sich unserer Jurisdiktion entziehen können. China oder Russland werden niemals für sie im Auftrag handelnde Hacker an die USA oder europäische Staaten ausliefern. Umgekehrt übrigens genau so wenig.

Der Geschädigte ist am Ende immer der Kunde, denn dessen Daten wurden kompromittiert, und nicht etwa die vom Hacker oder Hersteller. Leider machen es sich die Hersteller aber zu leicht, indem sie sich komplett aus der Verantwortung ziehen. Selbst wenn man dem Hersteller Fahrlässigkeit nachweisen kann (z.B. bei viel zu langsamer oder gar keiner Reaktion auf eine kritische Lücke), ist er trotzdem nicht haftbar. Warum eigentlich? Das ist auch so eine Eigenart in der Software-Branche. 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?

Ich stelle mir bei Exchange aber auch eine architektonische Frage (als Spoiler, da gefährliches Halbwissen; ich bin kein Exchange Admin):

Spoiler

Warum liegen hier eigentlich Datenbanken und Webapplikation auf der selben Kiste? Nehmen wir das Beispiel Onlineshop. Es gibt ein Web-Frontend (Webserver) und einen Daten-Backend (Datenbankserver). Die beiden Systeme kommunizieren über eine Schnittstelle miteinander. Das reduziert die Gefahr von Einbrüchen zumindest ein Stück weit, da bei einer Kompromittierung des Webservers nicht zwangsweise auch gleich der DB-Server betroffen sein muss. Warum ist das bei Exchange anders? Warum liegen hier die Datenbanken auf der gleichen Maschine, die auch das Webfrontend präsentiert?

 

[greatdisaster]

@greatdisaster Wenn der Hacker nicht schuld ist sondern Microsoft sollten wir jetzt also besser mal das FBI nach Redmond schicken damit die Satya Nadella verhaften und den Hackern schicken wir am besten noch 100.00$ Belohnung, weil sie die Welt auf die kriminellen Machenschaften von Microsoft hingewiesen haben, ja?

Selbstverständlich müsste es Konsequenzen geben bei Software Pfusch wie in diesem Fall.
Ein autonomes Fahrzeug überfährt ein Kind wegen eines Softwarebugs: Da müssten reichlich Leute des Herstellers direkt in den Knast wandern, insbesondere auch auf der Managerebene.
Diese Ausrede "war nur ein Softwarebug" kann man generell nicht mehr gelten lassen.

Wenn ich eine Software wie Exhange nicht sicher bekomme. dann muss ich einen sichere Zugangskontrolle davor schalten (z.b. VPN). und OWA dürfte von MIcrosofts Seite aus nicht so konfigurierbar gemacht werden das es offen im Web zu erreichen ist.

 

[foo_1337]

@el.com Das Problem ist, dass dir weder hier noch bei einer Webapp die Trennung* wirklich hilft, wenn es ums auslesen der Daten geht: Sowohl der Exchange wie auch die Webapp hat ohnehin den notwendigen Zugriff auf von der DB den relevanten Content zu lesen. Aber dennoch sollte man das getrennt halten
Bei Exchange ist das halt AFAIK (ich bin kein Windows Mensch) so, dass Mailbox Server und IIS auf der selben Kiste laufen müssen und du den IIS für active sync (oder wie auch immer der nachfolger heißt) zwingend brauchst, egal ob OWA oder nicht. Läuft ja mittlerweile alles über https.
Daher muss man hier zumindest dafür sorgen, dass der exchange smtp nicht direkt ins internet exposed wird und auch nicht der IIS. Bei letzterem sollte der reverse Proxy auch diverse Filter nutzen um Lücken wie diesen schon auf der Seite den Garaus zu machen Dann hat man hier zumindest mal den Schutz, bis der Exchange Admin mal aufwacht und etwas unternimmt.

*wenn der DB Server dediziert für nur diese App besteht. Bei einem DB Server der noch andere DB's beinhaltet, sieht es natürlich anders aus.

 

[Rickmer]

Nach der Argumentationsmethode von manchen hier dürfte man also schonmal pauschal keine Microsoft Produkte einsetzen. Linux fällt auch weg: https://madaidans-insecurities.github.io/linux.html

Und was nutzen wir dann jetzt noch?

 

[foo_1337]

Du hast offensichtlich nicht alles gelesen: Es geht darum das Zeug so zu betreiben, dass die Risiken soweit wie möglich minimiert sind. Und ja, da gehört auch die Auswahl der Software dazu. Und ich würde definitiv niemandem Empfehlen, Exchange selbst zu betreiben. Auch unabhängig von der Lücke hier. Die beweist die These nur massiv. Wer den MS kram unbedingt im Unternehmen braucht, soll o365 wählen.