Kritik: Mac-Security Artikel in Mac&i 2018/3

In der Mac&i 2018/3 habe ich zwei Artikel gelesen, die mir fachlich nicht gut genug sind: "Auf Nummer sicher: 10 Passwort-Manager für macOS, iOS und Web" und "Abgeschirmt: Die Sicherheitsarchitektur von macOS 10.13". Da Mac&i das wichtigste deutschsprachige Apple-Magazin ist, kann ich das nicht unkommentiert stehen lassen.

Prinzipiell finde ich Mac&i gut, weil man einen umfassenden Blick auf die Apple-Welt bekommt. Bei Sicherheitsthemen haben sie meist auch Interviews mit kompetenten Leuten wie Charlie Miller oder Patrick Wardle. Aber manchmal geraten Sicherheitsartikel etwas daneben.

Paßwort-Manager

Wie man einen Artikel über Paßwort-Manager für macOS, iOS und Web schreiben kann, ohne den Schlüsselbund von macOS und iOS zu erwähnen, ist für mich nicht nachvollziehbar. 🤯😳 Zumal dieses Bordmittel nicht nur der Standard ist, den jeder kennen sollte, sondern auch kostenlos und besser als Tools von Drittanbietern.

Keychain ist komfortabler und kann mehr als 3rd Party Tools, meine Favoriten sind z. B.:

Weitergabe/Anfrage von WLAN-Paßworten an/von Kontakten in der Nähe
Einfügen von SMS-Codes in Paßwortdialoge (seit WWDC 2018)

Nicht jeder weiß, daß man in iOS unter anderem manuell in Einstellungen > Passwörter & Accounts Zugriff auf die Daten der Keychain hat. Und in automatisch erscheinenden GUIs bei Bedarf, die selbsterklärend sind und einen nicht mit Details über die dahinterliegende Keychain behelligen. Die Paßwortliste ist komfortabel mit Touch bzw. Face ID abgesichert, so daß man ruhig ein komplexes Master-Paßwort nutzen kann, ohne genervt zu werden.

Seit der WWDC 2018 kann man sogar Siri auf dem Mac (wie unter iOS) nach Paßworten fragen.

Die Keychain kann zwischen allen Geräten synchronisiert und voll verschlüsselt in der iCloud gehalten werden ohne Zugriff durch Apple. Laut dem Mac&i-Test können die meisten anderen Tools ihre Daten nicht einmal in sichere Archive exportieren bzw. aus solchen importieren, was bei Keychain schon ewig zu den Standardfunktionen gehört.

Konkurrebzlos nahtlos dürfte auch die Zusammenarbeit zwischen Keychain und Paßwortfeldern in System, Apps und Webseiten sein. Merken, ausfüllen, vorschlagen direkt dort, wo man es braucht, das praxisnahe Sicherheit.

Einziger Nachteil von Keychain wäre, daß es das Tool nur bei Apple gibt. Aber das war kein Kriterium im Test von Mac&i.

Sicherheitsarchitektur von macOS

Beim Lesen dieses Artikels habe ich regelrecht Schluckauf bekommen. So viele fachliche Schlaglöcher und Bodenwellen 😳 haben mich aus dem Lesefluß geworfen, daß ich sie erstmal systematisch verarbeiten muß. Im Folgenden zitiere und kommentiere ich die fraglichen Stellen und hebe die kritischen Punkte im Zitat optisch hervor:

Das neue plattformübergreifende Dateisystem APFS bringt zudem ein granulares, sehr detailliertes Berechtigungs- und Verschlüsselungskonzept.

Beim neuen Dateisystem APFS hat Apple die Verschlüsselung auf Dateisystemebene nochmals verbessert. APFS kann nicht nur das komplette Dateisystem, sondern auch einzelne Dateien kodieren.

An den Berechtigungen aka File Permissions hat sich nichts geändert.

Und auch die Per-File Crypto, also die Verschlüsselung einzelner Dateien, konnte die HFS+ Version für iOS/tvOS/watchOS bereits vorher. Apple hat mit APFS die im Laufe der Jahre an HFS drangeflanschten Features durch eine einzige neue Komplettumsetzung ersetzt plus diverse neue Features. Aber das Berechtigungs- und Verschlüsselungskonzept ist kein neues Feature. Es ist in APFS weder granularer noch detaillierter. Siehe Introducing Apple File System. APFS bietet allerdings auch noch aufgrund der Funktionsweise von Snapshots und Clones eine Per-Extent Encryption an, also separate Verschlüsselung jeder Region einer Datei, was noch etwas anderes ist als Per-File Crypto. Per-Extent Encryption wird jedoch wohl eher selten in der Praxis zum Einsatz kommen. Daher ändern sich die praxisrelevanten Verschlüsselungsmöglichkeiten mit dem Umstieg von HFS und seinen Erweiterungen auf APFS nicht.

Für Verschlüsselung auf Dateisystemebene hätten einfach nur die Änderungen auf den anderen drei Plattformen auf macOS übernommen werden können. Apple wollte jedoch alles insgesamt mal glattziehen und das bis zum Abwinken MacGyver-te HFS mit etwas ersetzen, das für den heutigen Job nicht im roten Bereich laufen muß. So kommt Verschlüsselung bei APFS ohne Core Storage aus.

Wirklich neu durch APFS hingegen sind so Sachen wie beispielsweise Space Sharing von Partitionen, Cloning von Dateien und Verzeichnissen ohne Platzverlust, Snapshots, schnelle Bestimmung der Verzeichnisgröße und atomares sicheres Speichern von Verzeichnis-Dokumenten wie .rtfd. Außerdem werden HDDs (bei SSDs ist das egal) im laufenden Betrieb degragmentiert laut What's New in Apple File System. Und weil im Gegensatz zu HFS und seinen MacGyver-ten Verbesserungen die Inode-Datenstrukturen in APFS flexibel sind, können zukünftig Features hinzugefügt werden ohne die Rüchwärtskompatibilität zu verlieren.

Die Dokumentation von APFS fällt indes mager aus. Apple verschweigt zum einen, wie die Verschlüsselung im Detail funktioniert, und bietet zum anderen keinerlei Systemwerkzeuge für APFS.

Apple dokumentiert APFS in diesen Quellen:

Und in den FAQs zum Apple File System Guide heißt es:

Is APFS open source?

An open source implementation is not available at this time. Apple plans to document and publish the APFS volume format specification.

Die komplette Dokumentation ist also geplant.

An Systemwerkzeugen für APFS finde ich einiges. So bietet das hdiutil Unterstützung für APFS und dann haben wir noch

APFSUserAgent(8) - APFS new container observer
apfs.util(8) - APFS file system utility
apfs_hfs_convert(8) - convert an existing HFS file system to APFS file system
fsck_apfs(8) - APFS consistency check
mount_apfs(8) - mount an APFS volume
newfs_apfs(8) - construct a new APFS volume

und natürlich das Disk Utility (Festplatten Dienstprogramm) mit Unterstützung für APFS, sowie tmutil -- Time Machine utility und die Time Machine App.

Als Schutzmaßnahme besitzt macOS eine Firewall.

Tatsächlich hat macOS mehrere Firewalls. Dieser Fehler ist ihnen, wie dort geschildert, schon einmal unterlaufen.

Sie [die Firewall] kontrolliert lediglich die TCP- und UCP [gemeint ist UDP]-Ports der eingehenden Verbindungen.

Die wichtigste und per GUI einstellbare Firewall ist in den letzten Jahren bei macOS die Application Firewall. Die filtert den Netzverkehr jedoch nicht nach Ports, sondern nach dem benutztem Programm.

Gleichzeitig sollten Sie unter „Weitere Optionen“ den Tarnmodus einschalten, der den Rechner im Netzwerk weitgehend unsichtbar macht.

Wie in Schädlicher Tarnmodus beschrieben, wird man dadurch keinesfalls unsichtbar, sondern allenfalls inkompatibel zum Internet-Standard.

Trotzdem sollten Sie die Firewall im gleichnamigen Reiter der Systemeinstellung „Sicherheit“ aktivieren, […] Denn auch ohne aktive Serverdienste wie die Dateifreigabe können Sicherheitslücken dazu führen, dass ein Angreifer das System über das Netzwerk erfolgreich manipuliert (remote exploitation).

Wie man ein System ohne laufende Serverdienste remote angreift, verraten sie leider nicht. Klar ist: Nur Programme, die Netzverkehr brauchen, sind angreifbar. Schaltet man so einem Programm das Netz ab, dann funktioniert es nicht mehr. Dieser Ratschlag ist also schlicht unrealistisch und praxisfern.

Im sichersten System der Welt, iOS, ist keine Firewall aktiv, obwohl die Geräte direkt im Internet hängen:

On other platforms, firewall software is needed to protect open communication ports against intrusion. Because iOS achieves a reduced attack surface by limiting listening ports and removing unnecessary network utilities such as telnet, shells, or a web server, no additional firewall software is needed on iOS devices.

Die korrekte Maßnahme ist also, die Angriffsoberfläche zu reduzieren, d. h. weniger Netz-benutzende Programme zu installieren.

Und wie in OS X: Firewall-Nonsens beschrieben, habe ich hier weitere gut begründete Vorbehalte.

Eine zusätzliche Firewall wie Little Snitch für ausgehende Netzkommunikation trägt viel zur Sicherheit bei. […] Warum Apple auf eine so wichtige Funktion in macOS verzichtet, bleibt unverständlich.

Das Thema Little Snitch habe ich hier behandelt. Es fügt dem System weitere Verwundbarkeit zu und befriedigt allenfalls blinden Aktionismus.

Apple bietet so etwas nicht an, weil 1. siehe oben und 2. sind normale Menschen mit so etwas überfordert und die Wahrscheinlichkeit hoch, sich sein System/Apps kaputtzukonfigurieren.

XProtect, eine simple Antivirus-Software

XProtect mit Antivirus-Software zu vergleichen, ist von der Funktion her völlig unpassend.

Gatekeeper Path Randomization: Jede über File Quarantine geladene App wird in einem schreibgeschützten, zufällig erzeugten Verzeichnis ausgeführt. [1] Damit möchte Apple verhindern, dass böswillige Apps Schadcode mitbringen, ausführen oder nachladen. [2]

[2]: Es geht eben nicht um böswillige Apps, sondern um gutwillige Apps, die für das Repackaging-Problem anfällig sind. [1]: Die Path Randomization findet darum auch nur unter kritischen Umständen statt und nicht bei jeder App mit File Quarantine. Die Details sind in Gatekeeper Update und Dev-Tips für Repackaging-Problem nachzulesen.

Auch hat der Gatekeeper keine Ahnung, wer die Software signiert hat: Die Liste von gestohlenen Zertifikaten, mit denen Malware als vertrauensvoll ausgewiesen wurde, hat mittlerweile eine beachtliche Länge erreicht.

Apple macht diese Zertifikate ungültig und damit sind die damit signierten Apps deaktiviert. Wer sie signiert hat, interessiert dabei dann nicht mehr, sondern nur, daß sie mit einem kompomittiertem Zertifikat signiert wurden.

Per Sandbox geschützte Apps kommunizieren über die XPC-Services (Interprocess Communication and Services) mit dem Betriebssystem. [1] Um die sichere Kommunikation zwischen macOS und Apps zu gewährleisten, kommen XPC-Dienste zum Einsatz. [2]

Als XPC neu war, hatte ich die Funktionsweise beschrieben. XPC dient der Zerlegung einer App nach Aufgabenarten, um jedem Bereich eine engere Sandbox geben zu können als einer monolithischen App. So kann man Netzzugriff auf eine Downloadkomponente der App und Plattenzugriff auf die Datenkomponente beschränken. Parser und GUI brauchen gar keine Rechte. Jede Komponente hat ihren eigenen Adreßraum. Wird nun eine Komponente kompromittiert, ist der Schaden begrenzt auf diesen Teil und dessen Rechte. Auch läuft der Rest der App weiter.

[1]: XPC dient der Kommunikation zwischen den App-Komponenten, nicht der Kommunikation zwischen der App und dem Betriebssystem. Eine App mit Sandbox ist nicht gezwungen, XPC zu benutzen.

[2]: XPC hat nichts mit sicherer Kommunikation zu tun zwischen macOS und Apps. Die XPC-Dienste der App sind nur für die App verfügbar und für nichts sonst, sie sind App-intern.

Bei einem Programm ohne Sandbox hat er [der Angreifer] hingegen Zugriff auf das gesamte System.

Der Angreifer hat bei einer App ohne Sandbox keinen Zugriff auf das gesamte System, sondern nur auf die Bereiche, auf die der aktuelle User Zugriff hat, und auf keinerlei Systembereiche.

Schließlich lässt sich Sicherheit nur durch strenge Prozesse und Qualitätskontrollen garantieren. Dann gibt es auch keine „schlechten Wochen“ mehr, wie Microsoft mit dem Security Development Lifecycle seit Beginn des neuen Jahrtausends beweist.

Wenn das so wäre, dann müßte diese Microsoft Security Vulnerabilities Liste ja leer sein. Und Project Zero hätte dann auch keine Berichte zu Windows, wie z. B. Windows Exploitation Tricks: Exploiting Arbitrary File Writes for Local Elevation of Privilege.

Was bei Microsoft mit Sicherheit funktioniert, ist das Marketing.

Anders als unter Windows darf Root traditionell alles.

Das ist auf so viele Weisen falsch. 🤦‍♂️ Windows ist kein Unix und hat nicht root, sondern den system account und den administrator account (Administrators group). Unter Windows dürfen die alles:

By default, the system account is granted full control to all files on an NTFS volume. Here the system account has the same functional privileges as the administrator account.

Weiterführend: UAC als Sicherheits-Placebo.

Eingeschränkter Root-Nutzer […] Mit der System Integrity Protection (SIP) stellt macOS einen weiteren Sicherheitsmechanismus bereit, auch als rootless bekannt. […] SIP schränkt den Zugriff auf bestimmte, von Apple definierte Ressourcen ein. […] Ein Prozess darf auch nicht das Startvolume des Mac ändern.

Die Ausführungen zu SIP sind unvollständig. Wie hier nachzulesen, schützt SIP bestimmte Programme nicht nur auf der Platte, sondern auch zur Laufzeit vor Manipulationen durch Debugging oder Code Injection. Desweiteren sorgt SIP dafür, daß nur noch ausgewählte Kernel-Extensions vom System akzeptiert werden.

Ferner geht es nicht darum, speziell den root User einzuschränken, sondern bestimmte Teile von macOS vor 3rd Party Manipulationen zu schützen, indem nur noch Apples Update-Routine kritische Stellen verändern darf. Und dieser Regel ist völlig egal, unter welchem User der Code läuft.

Sicherheitsrelevant für macOS sind zudem die Mechanismen XD [DEP] und ASLR

Zu ASLR, seiner Geschichte und Nutzlosigkeit habe ich schöne Hintergrundinfos. Ebenso zu DEP.

Bei anderen Features, etwa File Quarantine, XProtect und Gatekeeper, war eher der Wunsch Vater des Gedankens.

Diese Features zusammen mit dem "Killer bei Bedarf" (MRT) haben alle relevanten Schädlinge, von Flashback bis FruitFly beseitigt und zwar flächendeckend und eher und schneller als alle 3rd Party Tools.

Besucherzähler

Latest Update: 20. June 2018 at 11:44h (german time)
Link: osx.macmark.de/blog/osx_blog_2018-06-b.php