daily.out

2011-09/10/11-xx Review: Macs in the Age of APT

In diesem Artikel mache ich ein Review des Vortrages "Macs in the Age of APT" von der Black Hat USA 2011. Nachdem mir beim Überfliegen grobe Fehler aufgefallen waren, spendiere ich ihren Folien einen Realitäts-Check.

Hier ist Version 1.2 meiner Randnotizen in ihrem Vortrag.

Vorgeschichte

Ein paar Jahre vorher: Ich schaute mir eine Privileg-Eskalation durch SystemLoginItems, nicht zu verwechseln mit StartupItems oder Login Items, an:

Wenn man unter /Library/Preferences eine Konfigurationsdatei für SystemLoginItems anlegte, dann wurde nach einem Neustart ein dort konfiguriertes Programm unter root ausgeführt. Da zum Anlegen der Datei nur Admin-Rechte nötig waren, eskalierte man damit also indirekt seine Privilegien auf root.

SystemLoginItems waren unter 10.5 bereits deprecated und unter 10.6 deaktiviert, das Problem also mit Snow Leopard behoben. Seit 10.7 ist /Library und die meisten seiner Unterverzeichnisse inklusive /Library/Preferences nur noch für root schreibbar. Selbst wenn SystemLoginItems also nicht sowieso schon deaktiviert wären, würde keine Privilegien-Eskalation mehr stattfinden können, weil Admins dort die nötige Datei nicht mehr anlegen können. Das Problem ist also unter Lion aus gleich zwei Gründen nicht mehr existent.

Rixstep, die einen Proof of Concept (PoC) bezüglich SystemLoginItems brachten, schrieben, es funktioniere auf 10.6. Da hatten sie aber ihre Hausaufgaben nicht gemacht, denn der Mechanismus ist wie bereits gesagt seit 10.5 deprecated und seit 10.6 nicht mehr aktiv. Wenn sie ihre Behauptungen und ihren PoC mal selbst auf 10.6 ausprobiert hätten, könnten sie sich diese Falschaussage sparen.

Ihr PoC basiert auf Angaben von MacShadows (seit einiger Zeit offline), die allerdings nur über Versionen bis 10.5.5 berichteten und sich um Änderungen danach nicht mehr scherten. Verständlich, denn mit 10.6 war es ja vorbei.

Rixstep machte sich die Mühe, das PoC-Programm zu schreiben, probierte es aber nicht mal selbst aus gegen 10.6, behauptet jedoch trotzdem, es würde auf 10.6 funktionieren. Was soll das?

Zurück zur Gegenwart

Im August 2011 gab es Schlagzeilen wie "Klatsche für Mac OS X Lion: Unsicherer (im Netzwerk) als Windows 7". Ursache dafür war ein Vortrag von iSEC Partners auf der Black Hat USA 2011. iSEC Partners ist eine Security Consulting Firma, die ihre Dienste gerne auch an Firmen mit Macs verkaufen möchte und darum mit diesem Vortrag auf der Blackhat für sich warb.

Ich warf einen kurzen Blick auf ihre Folien, an denen 5 Leute dieser Firma mitgewirkt hatten:

• Tom Daniels, Security Consultant bei iSEC Partners
• Aaron Grattafiori, Senior Security Consultant bei iSEC Partners
• William (B.J.) Snow Orvis, Security Consultant bei iSEC Partners
• Alex Stamos, Mitgründer und technischer Leiter (CTO) von iSEC Partners
• Paul Youn, Senior Security Consultant bei iSEC Partners

Der Vortag besteht aus einer allgemeinen Einleitung bezüglich Advanced Persistent Threats, in der anhand bekannter Windows-Fälle diese Angriffsart erläutert wird. Anschließend erfolgt eine Erörterung wie man das mit Macs machen könnte und am Schluß dann diesbezüglich ein Vergleich der aktuellen Client- und Server-Versionen von Windows und Mac OS X bestehend aus Windows 7 und 2008 R2, sowie Mac OS X 10.7 und Server.

Auf Seite 53, auf der es darum geht, den eroberten Zugriff zu behalten und den Reboot zu überleben, fällt mir ins Auge: Das ginge mit dem "com.apple.SystemLoginItems.plist Exploit". Hallo, McFly, jemand zuhause?

Die saßen zu fünft an dem Pamphlet, alles Fachleute, zwei Security Berater, zwei sogar Senior Security Berater und der technische Chef war höchstselbst mit dabei. Was sind das für Sicherheits-Schießbudenfiguren, wenn ihnen solche offensichtlich falschen Aussagen unterlaufen. Ein Fehler, den sich jemand mit Ahnung von Mac-Sicherheit nicht geleistet hätte. Offenbar haben sie einen veralteten und dadurch inzwischen fehlerhaften Artikel ungeprüft verwendet. Welche Qualität muß ihr Beitrag zur Black Hat haben, wenn sie nicht mal die Grundlagen korrekt auf die Reihe kriegen?

Der zweite Blick

Für mich war der Fall damit erledigt, aber ich bekam von anderen Mac-Usern Anfragen bezüglich dieser Schlagzeilen, was ich zum Anlaß nahm, erstmal ein paar verwandte Sicherheits-Artikel auf meiner Seite für Lion zu aktualisieren und mir die Server-Version von Lion anzusehen. Dann habe ich einen zweiten detailverliebten Blick auf das Papier von iSEC geworfen:

Es geht gar nicht um die generelle Sicherheit

Der Beitrag geht über "Advanced Persistent Threats" (APTs) und wie gut die Betriebssysteme dagegen gerüstet sind. APTs sind Angriffe, die typischerweise gegen ausgesuchte einzelne Ziele gefahren werden von hochspezialisierten professionellen Agressoren, meist staatliche wie Geheimdienste. Sie setzen dabei erhebliche technische, finanzielle und personelle Mittel ein, um ihr Ziel zu erreichen. Weiterhin ist charakteristisch, daß der Angriff kein einmaliger Versuch, sondern härtnäckig, persistent ist, also immer wieder über lange Zeit auf verschiedenen Wegen stattfindet, bis sie es irgendwie schaffen.

Die iSEC-Leute glauben, daß Windows APTs besser standhalten könne. Tatsächlich beginnen sie jedoch ihren Vortrag damit, wie Windows solchen Angriffen in diversen Fällen zum Opfer fiel. Ein vergleichbarer erfolgreicher Angriff auf Macs ist derzeit noch nicht bekannt. Ich vermute, daß iSEC wie die Antiviren-Industrie es auch seit langem versucht, ihren Anteil am Mac-Kuchen zu sichern. Und dafür wollen sie mit ihrem Beitrag den Bedarf wecken und koste es auch die Wahrheit.

iSEC geht es in dem Beitrag überhaupt nicht um die generelle Sicherheit von Mac OS X versus Windows, das ist gar nicht ihr Thema, sondern um die Widerstandsfähigkeit gegen einen bestimmten Angriffstypus. In der Presse wurde das jedoch zum generellen Sicherheits-Vergleich hochstilisiert, was es definitiv nicht ist. Die Presse hat den Beitrag von iSEC entweder nicht gelesen oder nicht verstanden, denn die Nachrichten-Seiten stellten es immer als einen prinzipiellen Sicherheitsvergleich dar, was es jedoch weder sein will, noch ist.

Es geht nicht mal um generelle APTs

iSEC beschreibt die Anatomie eines APTs. iSEC sagt, es beginne mit Social Engineering. Das ist jedoch nur eine von vielen Möglichkeiten. Man kann auch direkt Lücken im System nutzen. iSEC betrachtet jedoch nur Angriffe, die auf Social Engineering (Trojanischen Pferden) basieren. Sämtliche anderen Angriffswege die als initialen Schritt über Viren oder Würmer oder Systemschwachstellen gehen und nicht über Social Engineering, lassen sie außen vor. Würden sie das mit reinrechnen, wäre Windows auf jeden Fall Toast. Aber ihr Ziel war es ja, Mac OS X schlechter als Windows darzustellen.

Der Stuxnet-Wurm war zum Beispiel ein APT und nutzte dafür zahlreiche Lücken unter anderem in Windows aus. Darunter gleich 4 verschiedene Windows-Zero-Day-Exploits, was für einen normalen Angriff Verschwendung wäre, aber für APTs dank koste-es-was-es-wolle kein Thema ist. Stuxnet benötigte kein Social Engineering, keinen Trojaner. Die initiale Infektion passierte durch das Ansehen eines bösartigen Shortcuts. Es genügte, daß das Icon des bösen Shortcuts im Explorer-Fenster als Teil der Liste der Dateien eines Verzeichnisses angezeigt wurde. Es mußte nicht angeklickt, nicht doppelgeklickt und nicht manuell gestartet werden. Kein User mußte durch Social Engineering dazu gebracht werden, die schädliche Datei zu berühren.

iSEC klammert also ganze Klassen von APTs aus. iSEC beschränkt seine Diskussion auf eine Teilmenge von APTs, nämlich die, die mit Social Engineering starten. Egal was dabei herauskommt, sie können keine generelle Aussage über die Widerstandsfähigkeit gegen APTs im allgemeinen dadurch machen, sondern nur über APTs, die einen initialen Trojaner nutzen. iSEC wird damit seinem Anspruch "Macs im Zeitalter von APT" nicht gerecht, sondern deckt höchstens "Macs im Zeitalter von trojanerbasierten APTs" ab und das auch nur schlecht, wie der Rest vorher und nachher zeigt.

Fehler ungleich Fehler

iSEC bemüht ein paar Statistiken, die besagen, bei Mac-Software gäbe es fast so viele Fehler wie für Windows-Software. Der Vergleich hinkt allerdings: Erstens veröffentlicht Apple jeden eigenen und Dritthersteller-Fehler während Microsoft auch schon mal heimlich fixt und somit nicht alle Fehler bekannt macht. Zweitens wird die Schwere der Fehler nicht berücksichtigt und banale Fehler mit systemkritischen in einen Topf geworfen.

Anhand der Quantität der freiwillig bekanntgemachten Fehler für Software einer Plattform will iSEC die Sicherheit dieser Plattform festmachen. Höre ich da jemand "Milchmädchen-Rechnung" reinrufen? Sehr gut mitgedacht!

Falsches Gemischtes

Botnetze würden sich für Macs nicht lohnen, weil es prozentual zu wenige sind? Unter welchem Stein hat iSEC die letzten Jahre gelebt? Es gibt kleine Botnetze, weil sie ein besseres Aufwand/Leistungs-Verhältnis bieten und nicht so schnell entdeckt werden. Vielleicht sollte sich iSEC informieren, bevor sie sich blamieren.

Apples Computer sollen nur 6-8% Marktanteil haben. Tatsächlich waren es im August zum Vortragszeitpunkt 9,6% und im September 2011 10,6%. Wen stören schon solch falsche Zahlen?

Dan Guido, Senior Security Consultant bei iSEC, hat recherchiert, daß keine Exploits gegen Macs in Crimeware-Toolkits vorhanden wären. Dann hat er wohl den Trojaner-Baukasten Weyland-Yutani verpaßt im Mai des gleichen Jahres.

Angriffe würden sich wie MacDefender auf Social Engineering konzentrieren. Das ist richtig, denn Viren für Mac OS X sind auch schwieriger.

Apple-User würden sich sicherer fühlen, weil es bislang keine Exploit-Historie für das System gebe. Tatsächlich gab es immer wieder Exploits für Bugs. Vielleicht sollten sie mal mit Charles Miller reden.

Wir würden unsignierte Binaries bedenkenlos laufen lassen. Dem widerspricht, daß der App-Store signierte Binaries erzwingt.

Wir würden AV-Software für überflüssig halten. Das ist korrekt. Und das sehen auch die bekannten Hacker so.

Mac OS X wäre auch verwundbar durch Malware. Ja, allerdings hat Malware typischerweise erstmal weniger Rechte als unter Windows. Und Mac OS X hat weniger Architekturfehler, die ganz ohne Bugs jeder Schadsoftware die Arbeit erleichtern.

Exploitation in APT

Die initiale Infizierung würde über ein Browser- oder Plugin-Exploit erfolgen. Das wird nicht so leicht, da alle Safari-Plugins mit Lion in einem eigenen Prozeß laufen und Safari ab Lion selbst sandboxed ist.

Sie schreiben immer von Lion, zeigen aber meist Screenshots von alten Systemen.

XProtect würde noch in den Kinderschuhen stecken. Was für ein Blödsinn. Es funktioniert perfekt. Punkt.

Mitigations

Dann vergleichen sie, wann welche Mitigations verfügbar waren. Stack Protection soll Windows seit 2003 gehabt haben. Allerdings war die Art der Stack Protection ziemlich nutzlos bis Windows 2008 Server. Stichwort "Structured Exception Handler". OS X hat 2007 eine gescheite Stack Protection eingeführt, war also effektiv ein Jahr eher brauchbar.

Heap Protection in OS X datieren sie auf 10.6 in 2009. Richtig ist jedoch 10.5 in 2007.

Daten-Ausführungs-Schutz gab es ab 10.4.4 (Intel) in 2006. Dabei unterschlagen sie, daß es früher gar nicht möglich war, weil der PPC kein NX-Support hatte.

Bei ASLR unterschlagen sie, daß OS X Server das schon 2007 hatte, Windows Server jedoch erst 2008.

Xcode können sie auch nicht korrekt schreiben, was das schlampige Bild abrundet. Neben den falschen Datumsangaben bedenken sie nicht, daß verfügbar nicht gleichbedeutend mit im Einsatz ist. Die Mitigations waren bei Windows aus Kompatibilitätsgründen nämlich typischerweise erstmal ausgeschaltet, wenn sie eingeführt wurden. Und sie konnten auch nicht immer problemlos genutzt werden. Apple ist da wesentlich konsequenter: Einmal eingeführt, sind die Mitigations default und funktionieren. Es nützt ja nichts, wenn es Mitigations gibt, die erstmal keiner nutzt wie bei Windows.

NX/DEP wäre nicht konfigurierbar auf OS X. Darin sehen sie einen Nachteil. Man kann es nicht abschalten und das ist gut so. Bei Windows kann man es abschalten. Das gleiche Spiel mit ASLR. Nicht konfigurierbar sei es, jammern sie. Nicht abschaltbar ist es, sage ich. Bei Windows kann man es abschalten, was die Sicherheit nicht erhöht. Die Jungs von iSEC haben eine echt kranke Sichtweise.

Local Privilege Escalation

Die Login Keychain könne benutzt werden, um das User-Paßwort per Brute-Force anzugreifen. Tja, die Keychain und der User können jedoch unterschiedliche Paßworte haben, so daß so ein Angriff gar nichts bringt, selbst wenn er das Paßwort findet. Was nun, iSEC?

Wenn der User sudoer ist, kann das Paßwort direkt Privilegien eskalieren. Ja, das stimmt. Sie sollten jedoch erwähnen, daß man beim typischen Windows-User dafür nichtmal das Paßwort herausfinden muß, weil er bereits schon praktisch allmächtig ist, auch auf Vista und Windows 7.

Dann gehen sie davon aus, daß das User-Paßwort die Login-Keychain öffnen kann. Wenn beide gleich sind ja, aber das ist nicht zwingend der Fall.

Phishing for Admin

Obwohl ihr Vortrag über Lion gehen soll, zeigen sie hier anhand eines Screenshots eines alten Systems, wie ein unechter Dialog für ein Admin-Paßwort aussehen könnte, der angeblich vom Software-Update käme. Der wesentliche Unterschied hierbei ist, daß man ab Lion die Details nicht erst nach Mausklick enthüllt bekommt, sondern die Gründe für die Abfrage direkt und verständlich präsentiert bekommt. Das fehlt natürlich bei ihrem Fake. Außerdem könnte man die Fälschung daran erkennen, daß beim diesem scheinbaren Softwareupdate gar kein Software-Update-Prozeß läuft und auch die sonst üblichen Meldungen zuvor fehlen. Das Fälschen ist daher nicht so trivial, wie sie glauben.

Um uns zu trösten, heißt es dann, den UAC-Dialog von Windows könne man auch fälschen. Das ist jedoch gar nicht notwendig, da ein Programm ohne UAC-Dialog beim typischen Windows-User seine Systemrechte nutzen kann.

Ein typisches Beispiel, bei dem sie ein Patt sehen, während OS X tatsächlich besser aufgestellt ist. In diesem Fall offenbar in Unkenntnis beider Systeme.

Network Privilege Escalation

Leopard Server (10.6) hätte angeblich 28 Netzwerk-Ports offen nach einer Default-Installation. Daran sind gleich mehrere Dinge merkwürdig: Sie nennen keine Details und das nicht ohne Grund, denn das ist Unfug. Sie reden von 10.6, dabei soll doch hier 10.7 mit Windows verglichen werden. Die Dienste, die den Server vom Standard-OS X unterscheiden, sind per default alle aus. Die, die angeschaltet sind, hätten einen Punkt in der Liste und unten in der Zusammenfassung würden sie auch explizit gelistet.

Unrealistisches Szenario

Sie konstruieren ein unrealistisches Szenario aus Apple Remote Desktop (ARD) und Bonjour. Was ist daran falsch?

1. Es soll eigentlich um Lion gehen. Apple Remote Desktop aber ist ein separates Produkt, das weder Teil von Mac OS X noch von Mac OS X Server ist. Sie reden hier also von zusätzlicher Software, die eigentlich nichts mit Lion zu tun hat.
2. ARD und Bonjour sind für ganz unterschiedliche Einsatzbereiche und schließen sich daher von der Zielgruppe aus. Bonjour ist für Heimnetze und für Ad-Hoc-Netzwerke, für die man keinen richtigen Netzwerk-Administrator hat. Apple Remote Desktop ist nicht für solche Netze, sondern für IT-Profis, die Geräte in beständigen Firmennetzen verwalten wollen.
3. ARD und Bonjour schließen sich in der Praxis auch technisch aus. Bonjour arbeitet link-local, also innerhalb eines Subnetzes. Bonjour kann keine Router überqueren und kann das Subnetz nicht verlassen. Apple Remote Desktop kann das. Außerdem haben Firmen typischerweise Netzwerke, die aus diversen Subnetzen bestehen, und die Administratoren sitzen in der Regel in einem anderen Subnetz als die betreuten Rechner. Bonjour ist daher aufgrund der Subnetze nicht für Firmennetze geeignet, ARD schon.

Die Kombination aus Bonjour und ARD ist ein unrealistisches Szenario: Wenn Du ARD benötigst, dann kann Dir Bonjour nicht helfen, weil Router dazwischen liegen. Aus dem gleichen Grund siehst Du auch nicht alle Macs im ganzen Internet, wenn Du mit Bonjour nach Diensten suchst. Und wenn Du Bonjour nutzen kannst, dann ist der andere Rechner direkt neben Dir und Du benötigst kein ARD.

Sie schreiben, Bonjour wäre ein Ad-Hoc-DNS Service. Nope. Bonjour ist kein DNS. Es gibt keinen Domain Name Server bei Bonjour. Bonjour hat keinen zentralen Server, sondern ist Peer-To-Peer. Firmen-Server müssen über Subnetze hinweg gesehen werden können, daher können Firmen Bonjour für Namens-Auflösung überhaupt nicht verwenden.

In ihrem Szenario verwenden sie auch keine Public-Key-Infrastructure (PKI). Dies wäre jedoch Aufgabe der Firmen-IT-Admins. PKI nicht zu nutzen, bedeutet, daß die IT nicht wirklich gut ist.

ARD nutzt unter anderem das Diffie-Hellman-Verfahren zum Schlüsselaustausch. Dieses Protokoll gilt als sehr sicher, allerdings gibt es einen offensichtlich möglichen Man-In-The-Middle-Angriff zu Beginn der Kommunikation, wenn die öffentlichen Schlüssel ausgetauscht werden. Diesen Angriff kann man jedoch mit einer Public-Key-Infrastructure unterbinden, die man prinzipiell zum sicheren Einsatz asymmetrischer Kryptographie benötigt vor allem bei größeren User-Gruppen wie in Firmen. Die Firmen-PKI dient hierbei auch als Certification Authority (CA). Die öffentlichen Schlüssel der CA werden auf sichere Weise auf den Geräten vorinstalliert. Die Public Keys für Diffie-Hellmann können dann innerhalb eines Zertifikates, das von der CA signiert wurde, ebenfalls sicher übertragen werden – immun gegen Man-In-The-Middle-Angriffe.

Die iSEC-Jungs gehen jedoch davon aus, daß das Firmennetz von Laien betrieben wird, die nicht in der Lage sind, asymmetrische Verschlüsselung sicher zu betreiben. Aus dieser Annahme und der oben beschriebenen so sinnlosen wie unrealistischen Kombination aus Bonjour und ARD konstruieren sie dann ein Szenario, in dem man einen kompromittierten Mac als falschen ARD-Server ausgeben könnte. Das Kompromittieren erfolgt dabei auf dem noch weiter oben beschriebenen Weg, den sie wie gezeigt ebenfalls aus Angreifersicht geschönt haben.

So langsam bekommt man ein Gefühl dafür, an wieviel Stellen eines solchen APT-Angriffs iSEC hier die Realität manipuliert hat, nicht wahr?

Persistence

Hier ist nun die Stelle, an der sie darstellen, wie man nach Kompromittierung des Rechners den Neustart überlebt. Dazu nennen sie unter anderem die SystemLoginItems, die es seit 10.6 nicht mehr gibt, wie ich eingangs ausführlich beschrieben habe. Wieder zeigt iSEC, daß sie die Besten der Besten sind – sicheres Auftreten auch bei völliger Ahnungslosigkeit.

Sie behaupten ferner, wenn man existierende Binaries oder Dienste verändert, würde die dadurch ungültige gemachte Signierung generell nicht bemerkt werden. Das ist falsch, denn die Signatur wird mindestens für die Keychain, Parental Controls, die Application-Level Firewall und den Zugriff auf Task for PID geprüft.

Für diese und die anderen Punkte bleiben sie Beispiele schuldig. Vor allem das Persistieren in der Firmware hätte mich interessiert, da nach den initialen Boot-Schritten die Firmware die Kontrolle komplett über den Rechner verliert, das System also nicht beeinflussen kann.

In ihrer Historie über Userland Rootkits referenzieren sie Literatur zu mach_override und mach_inject in der Hoffnung, damit könne man ein Userland Rootkit erstellen. Das ist nicht möglich, allein schon weil der Zugriff auf task_for_pid() dafür im Userland zu eingeschränkt ist.

In einer Referenz träumt Dino Dai Zovi davon, unsichtbare Threads in Safari zu injizieren. Das ist im Userland auch unter Lion nicht möglich, denn der angreifende Code müßte eine App mit entsprechender Deklaration in ihrer Info.plist sein und mit einem von Apple erhaltenem Zertifikat signiert sein, damit es technisch überhaupt vom System erlaubt wird, aber dann ist es nicht mehr "stealth" weil das System mit passenden Dialogboxen nachfragt.

Die Historie haben sie auch durcheinander gebracht, denn Jonathan Wofgang "Wolf" von Rentzsch erfand diese Technik. Und die Idee, einen Proxy zu verwenden, um Mach-Kommunikation netzwerkfähig zu machen, kam nicht ursprünglich von Dino Dai Zovi, sondern von Amit Singh Jahre vorher.

Da mach_override und mach_inject im Speicher stattfinden und man damit nicht mal an höhere Rechte kommt, nützt dies also nichts für eine "persistant attack".

Beim Abwägen der Abwehrmöglichkeiten vermissen sie eine einfache Möglichkeit, die Integrität des Systems zu prüfen. Mac OS X hat jedoch keine kryptische Registry oder dergleichen, sondern Textdateien, deren Integrität man ohne Spezialwerkzeug prüfen kann.

Es gäbe keine Signierung für Binaries und Driver. Unter welchem Stein hat iSEC die letzten Jahre eigentlich gelebt seit 10.5.0 Leopard?

Exploration

Account Home Directories wären im Netzwerk per Default gemountet. File Sharing ist ausgeschaltet per Default, meine lieben Freunde von iSEC. Also wird da erstmal gar nichts gemountet im Netz.

Summary: Comparison with Windows

Hier vergleichen sie nochmal Windows 7 und Windows Server 2008R2 mit Mac OS X 10.7 Client und Server nach Themen sortiert.

Initial Exploitation

Bei Stack Canary, Heap Hardening, Heap und Stack DEP/NX sowie ASLR sehen sie ein Patt. Ich nicht, denn solche Security Features werden von Microsoft für gewöhnlich mit "default off" eingeführt, während sie bei OS X an sind.

Diese Sicherheits-Features wären bei Windows mit dem "Enhanced Mitigation Experience Toolkit" (EMET) ein- und ausschaltbar und das hätte Lion nicht und das wäre ein Nachteil. Mädels, Sicherheits-Features ausschalten zu können, ist ein Sicherheits-Nachteil. Und man muß sie unter OS X nicht ausschalten können, weil wir die Probleme damit nicht haben, die Microsoft damit in Windows hat.

Local Privilege Escalation

Local Privilege Escalation ist bei Windows gar nicht nötig beziehungsweise trivial, weil Windows 7-User eh schon mit maximalen Rechten (und gleichzeitig anderen Rechten) arbeiten.

Sie sehen zwei Vorteile für Windows: Einmal User Interface Privilege Isolation (UIPI) und Secure Desk gegenüber Pop-Up Credential-Box. Die UIPI läßt sich jedoch leicht und mit offizieller API umgehen. Unter Windows kann man also völlig problemlos die System-Rechte des Users nutzen während der Mac-User gar keine Systemrechte hat.

Der andere Vorteil für Windows wäre, daß es keinen default Credential Store gibt und bei OS X die Login Keychain. Nun, das bedeutet, daß es für Windows keinen sicheren Speicher für Credentials gibt, für OS X hingegen schon.

Dann sehen sie noch zwei Vorteile für OS X und daher insgesamt ein Patt. Ich hingegen sehe auch hier einen Vorteil für OS X, weil die genannten Windows-Vorteile ein Trugschluß sind wie gerade beschrieben.

Network Privilege Escalation

Hier sehen sie ausschließlich Vorteile für Windows.

Drei Punkte mokieren das oben angesprochene ARD, was erstens gar nicht Teil von Lion ist und dessen Sicherheit man zweitens mit PKI gewährleisten kann, beziehungsweise dessen Kombination mit Bonjour keinen Sinn ergibt und an den Haaren herbeigezogen ist.

Ein vierter Punkt sieht Active Directory vor mDNS. Dabei vergessen sie, daß es Active Directory war, das in ihren Intro-Beispielen den Attacken zum Opfer fiel und daß mDNS kein zentraler DNS ist und nur link-local arbeitet.

Und von Privilege Escalation kann auch nicht gesprochen werden, denn selbst, wenn die genannten Dienste kompromittiert würden, hätte man keine höheren Rechte, da sie unter speziellen unprivilegierten Usern laufen.

Persistence

Hier finden sie gut, daß es viele Disk-Forensic-Tools für Windows gibt. Nun, die braucht man auch, weil sich Schädlinge bei Windows besser verstecken können dank Registry beispielsweise.

Den anderen Windows-Vorteil sehen sie in vielen RAM-Forensic-Tools. Ich sage, die Möglichkeiten der Shell-Programme am Mac genügen.

Sie glauben ernsthaft, man könne auf Windows leichter Malware erkennen und entfernen. Meine Erfahrung zeigt jedoch, daß das trotz haufenweiser Tools ein Problem ist, das Tage in Anspruch nehmen kann, während man Mac-Malware in wenigen Minuten mit ein paar Handgriffen beseitigen kann. Und sicher verstecken könne man Malware auf beiden Systemen. Die Praxis bestätigt das nicht.

Exploration und Exfiltration

Anonymes LDAP Browsing wäre ein Nachteil am Mac während Active Directory nur bekannte User LDAP browsen ließe. Sie vergessen dabei, daß die Malware zu der Zeit schon auf einem Rechner im Firmennetz ist und damit unter einem authentifizierten User läuft. Außerdem gibt es keine Security by Obscurity, schon vergessen? Und schon wieder vergessen, daß es das Active Directory war, was bei den großen bekannten APT-Attacken das Einfallstor war? Das findet iSEC jetzt plötzlich sicher?

Windows-Vorteil sei: Die Firewall könne ausgehende Regeln haben, die von OS X nicht. Natürlich bietet die ipfw "outbound rules" und toastet die von Windows damit ziemlich sicher. Weiß iSEC nicht einmal, welche Firewalls OS X hat und wie die funktionieren? Ahnungslose.

Summa summarum

Diese tabellarische Zusammenfassung, die bei ihnen knapp zugunsten von Windows ausging, war es, die an die große Glocke gehängt wurde von der Presse. Wie Ihr seht, bleibt davon jedoch eigentlich nichts wirklich an Vorteilen für Windows übrig, wenn man mit Fachkenntnis die Punkte überprüft hat.

Man sieht, daß iSEC einige grobe sachliche Fehler drin hat. Die eklantesten betreffen die SystemLoginItems, das Code-Signing, die Mac-Firewalls, die Keychain, die Mitigations, File Sharing, Userland Rootkits und die Windows-User-Rechte.

Zentrale Fehldarstellung ist die Kombination aus Bonjour und Apple Remote Desktop. Die ist unrealistisch und konstruiert. Auch sagen sie zwar nebenbei, daß man ARD mit PKI sichern kann, vergessen das aber in der Zusammenfassung. Zudem ist ARD nicht Teil von Mac OS X, also überhaupt nicht sinnvoller Teil eines Vergleichs zwischen OS X und Windows.

Der Vergleich von iSEC ist gar kein genereller Sicherheits-Vergleich der beiden Betriebssysteme, sondern nur ein Vergleich für eine spezielle Angriffsart: APTs. Und auch nicht für alle Arten von APTs, sondern nur für APTs, die mit Social Engineering beginnen. Und das Szenario für diese Unterart von APTs ist auch noch völlig unrealistisch konstruiert worden. Und obendrauf sind die technischen Vor- und Nachteile, die sie in dem Szenario nennen, auch noch fehlerhaft.

---