Geekly articles weekly

Ich kann Apple werden und du auch

Öffentliche Offenlegung der Sicherheitsanfälligkeit von Drittanbietern durch Apple-Code


Im Gegensatz zu einigen früheren Arbeiten erfordert diese Sicherheitsanfälligkeit keine Administratorrechte, keinen JIT-Code oder keine Speicherbeschädigung, um die Überprüfung der Codesignatur zu umgehen. Sie benötigen lediglich eine korrekt formatierte Fat / Universal-Datei. Die Überprüfung der Codesignatur zeigt ein gültiges Ergebnis.

Zusammenfassung


  • Wenn Sie einen Umweg gefunden haben, der von der Drittanbieter-API zum Signieren von Code verwendet wird, können Sie jeden von Apple signierten Code präsentieren.
  • Alle bekannten Open Source-Anbieter und -Projekte werden benachrichtigt (siehe Liste unten). Für sie stehen Patches zur Verfügung .
  • Es besteht die Möglichkeit, dass das Problem andere Programme von Drittanbietern betrifft, die die offiziellen Codesignatur-APIs von Apple verwenden.
  • Entwickler sind für die ordnungsgemäße Verwendung der Codesignatur-API verantwortlich. Es gibt Demo-Hacking-Tools (PoC) für Tests.
  • Gilt nur für macOS und ältere Versionen von OSX.

Betroffene Anbieter


  • VirusTotal - CVE-2018-10408
  • Google - Santa, Molcodesignchecker - CVE-2018-10405
  • Facebook - OSQuery - CVE-2018-6336
  • Zielentwicklung - LittleSnitch - CVE-2018-10470
  • F-Secure - xFence (auch LittleFlocker) CVE-2018-10403
  • Objective-See - WhatsYourSign, ProcInfo, KnockKnock, LuLu, TaskExplorer (und andere) - CVE-2018-10404
  • Yelp - OSXCollector - CVE-2018-10406
  • Ruß - Cb-Reaktion - CVE-2018-10407


Die Bedeutung der Codesignatur und ihre Funktionsweise unter macOS / iOS


Die Codesignatur ist ein Sicherheitskonstrukt, das eine Public-Key-Infrastruktur (PKI) verwendet, um kompilierten Code oder sogar Skripte digital zu signieren, um sicherzustellen, dass er vertrauenswürdig und der Code authentisch ist. Unter Windows können Sie fast alles kryptografisch signieren: von .NET-Binärdateien bis zu PowerShell-Skripten. Unter macOS / iOS bezieht sich die Codesignatur hauptsächlich auf Mach-O-Binärdateien und Anwendungspakete, damit nur vertrauenswürdiger Code im Speicher ausgeführt werden kann.

Antivirenprogramme, Sicherheitssysteme und die Reaktion auf Vorfälle sowie forensische Tools analysieren Signaturen, um vertrauenswürdigen Code unter nicht vertrauenswürdigen zu identifizieren. Die Überprüfung der Signatur beschleunigt die Analyse. Verschiedene Tools verwenden Codesignaturinformationen, um Sicherheitsmaßnahmen zu implementieren: Dies sind Whitelists, Antivirenprogramme, Systeme zur Reaktion auf Vorfälle und zur Suche nach Bedrohungen. Die Codesignatur in einem der gängigen Betriebssysteme zu gefährden bedeutet, die grundlegende Sicherheitskonstruktion zu untergraben, von der viele routinemäßige Informationssicherheitsvorgänge abhängen.

Probleme wurden bereits in der Codesignatur gefunden ( 1 , 2 , 3 , 4 , 5 ). Im Gegensatz zu einigen früheren Arbeiten erfordert diese Sicherheitsanfälligkeit keine Administratorrechte, keinen JIT-Code oder keine Speicherbeschädigung, um die Überprüfung der Codesignatur zu umgehen. Sie benötigen lediglich eine korrekt formatierte Fat / Universal-Datei. Die Überprüfung der Codesignatur zeigt ein gültiges Ergebnis.

Sicherheitslücken Details


Das Wesentliche an der Sicherheitsanfälligkeit ist, dass der Mach-O-Loader und die Codesignatur-API nicht zum falschen Überprüfen von Codesignaturen verwendet werden. Dieser Unterschied kann mit einer speziell gestalteten Universal / Fat-Binärdatei ausgenutzt werden.

Was ist eine Fat / Universal-Datei?

Fat / Universal ist ein Binärformat, das mehrere Mach-O-Dateien (ausführbare Datei, Dyld oder Paket) enthält, von denen jede auf eine bestimmte CPU-Architektur ausgerichtet ist (z. B. i386, x86_64 oder PPC).

Voraussetzungen


  • Das erste Mach-O in der Fat / Universal-Datei muss von Apple signiert sein. Es kann sich um eine i386-, x86_64-Datei oder sogar eine PPC-Datei handeln.
  • Ein selbstsignierter bösartiger binärer oder fremder Code muss unter i386 für macOS x86_64 kompiliert werden.
  • Die CPU_TYPE im Fat-Header der Apple-Binärdatei muss auf einen ungültigen Prozessortyp oder -typ eingestellt sein, der nicht für den Host-Chipsatz typisch ist.

Ohne die entsprechenden SecRequirementRef- und SecCSFlags zu übergeben , überprüft die Programmschnittstelle der Code Signing API ( SecCodeCheckValidity ) die erste Binärdatei in der Fat / Universal-Datei auf den Ursprung der Signatur (z. B. Apple) und stellt sicher, dass die Signatur authentisch ist. Anschließend überprüft die API alle anderen Binärdateien in der Fat / Universal-Datei auf Konformität mit Team Identifiers und Signaturauthentizität, ohne jedoch die Vertrauensbasis der Zertifizierungsstelle zu überprüfen . Der Grund, warum der Schadcode oder "nicht signierter" Code i386 sein muss, liegt darin, dass die Codesignatur-API standardmäßig so konfiguriert ist, dass die Codesignatur für die native CPU-Architektur (x86_64) überprüft wird.

Einer der Gründe, warum selbstsignierter Code den Test erfolgreich besteht, ist, dass das TeamIdentifier-Feld selbst in den Haupt-Apple-Binärdateien not set . Die folgende Abbildung zeigt die gültige Mach-O-Binärdatei, die von Apple (python.x64) signiert wurde, neben dem selbstsignierten Mach-O (ncat.i386). Beide haben "TeamIdentifier = nicht gesetzt".



Zum Beispiel habe ich die Binärdatei mit der Entwickler-ID signiert und in lipo versucht, sie mit der Apple-Binärdatei in einer Fat / Universal-Datei zu kombinieren. Diese Art der Codesignatur schlägt fehl.



Mein anfänglicher PoC ist ncat (von nmap), den ich ncat.frankenstein genannt habe. Hier enthält die resultierende Fat-Datei die von Apple signierte Python x86_64-Binärdatei und die selbstsignierte (adhoc) Binärdatei ncat i386. Eine selbstsignierte Binärdatei kann einfach mit codesign -s - target_mach-o_or_fat_binary . So sieht es in MachOView aus:



Wenn Sie diese Datei ausführen, wird Python x86_64 gestartet:



Und die Codesignatur wird überprüft:



Wie habe ich die selbstsignierte Binärdatei von ncat ausgeführt?

Dies erfolgt durch Festlegen eines ungültigen CPU_Type-Typs oder einer nicht nativen CPU (z. B. PPC). Dann überspringt der Mach-O-Loader die Mach-O-Binärdatei mit einer gültigen Signatur und führt bösartigen (nicht von Apple signierten) Code aus:



Dann wird ncat.frankenstein ausgeführt und das Validierungsergebnis ist valid :



Wir haben ncat.frankenstein und vier weitere Beispiele veröffentlicht, damit Entwickler nach Schwachstellen in ihren Produkten suchen können.

Empfehlungen


An der Kommandozeile

Hängt davon ab, wie Sie den signierten Code überprüfen. Wenn Sie Codesign verwenden, sind Sie wahrscheinlich mit den folgenden Befehlen vertraut:

  • codesign –dvvvv - Dump der Zertifizierungsstelle und TeamIdentifier (Entwickler-ID)
  • codesign –vv - strikte Überprüfung aller Architekturen


Um diese Art von Missbrauch korrekt zu überprüfen, müssen Sie die Anforderung für das Ankerzertifikat mit den folgenden Befehlen hinzufügen:

  • codesign -vv -R='anchor apple' ./some_application_or_mach-o # für von Apple signierten Code
  • codesign -vv -R='anchor apple generic' ./some_application_or_mach-o # für von Apple und Apple signierten Code

Ein solcher Befehl zeigt einen Fehler an, wenn Code mit der Signatur eines anderen überprüft wird:



Sie können den Befehl spctl , er erfordert jedoch eine sorgfältige Analyse der Ausgabe des Befehls. Beispielsweise gibt die Mach-O-Binärdatei mit der Signatur von Apple (/ bin / ls) und Safari Folgendes zurück:



Und hier ist das Ergebnis einer von Apple unterzeichneten Anwendung:



Beachten Sie die Zeile "(der Code ist gültig, scheint aber keine App zu sein)" für / bin / ls, die den Test nicht besteht. Zum Vergleich hier das Ergebnis der Datei Fat / Universal ncat.frankenstein:



Die Datei ncat.frankenstein Fat / Universal zeigt nicht an, dass der Code gültig ist. Daher kann ich spctl nicht empfehlen, um Offline-Mach-O-Binärdateien manuell zu überprüfen. Verwenden Sie einfach Codesign mit den entsprechenden Flags.

Für Entwickler

In der Regel überprüfen Entwickler Mach-O- oder Fat / Universal-Binärdateien mithilfe der APIs SecStaticCodeCheckValidityWithErrors () oder SecStaticCodeCheckValidity () mit den folgenden Flags:


Diese Flags sollten sicherstellen, dass der gesamte in den Speicher der Mach-O- oder Fat / Universal-Datei geladene Code kryptografisch signiert ist. Diese APIs bieten jedoch standardmäßig keine ordnungsgemäße Validierung. Daher müssen Entwickler von Drittanbietern jede Architektur in der Fat / Universal-Datei isolieren und überprüfen, ob die Identitäten übereinstimmen und kryptografisch robust sind.

Der beste Weg, um jede verschachtelte Architektur in der Fat / Universal-Datei zu testen, besteht darin, zuerst SecRequirementCreateWithString mit der Anforderung „ Ankerapfel “ und dann SecStaticCodeCheckValidity mit den kSecCSDefaultFlags | aufzurufen kSecCSCheckNestedCode | kSecCSCheckAllArchitectures | kSecCSEnforceRevocationChecks in Bezug auf die Anforderung; wie im gepatchten Quellcode von WhatsYourSign gezeigt .

Wenn Sie den "Ankerapfel" an die SecRequirmentCreateWithString-Funktion übergeben, funktioniert dieser Aufruf ähnlich wie der codesign -vv -R='anchor apple' , für den die Vertrauenskette "Apple Software Signing" für alle verschachtelten Binärdateien in der Fat / Universal-Datei erforderlich ist. Durch Übergeben von Flags und der Anforderung für SecStaticCodeCheckValidity werden außerdem alle Architekturen auf diese Anforderung überprüft und Sperrprüfungen angewendet.

Demonstrationen


Apples codesign Tool und die Notwendigkeit, das -R Flag zu verwenden.



LittleSnitch - Das Überprüfen der Fat / Universal-Datei auf der Festplatte funktioniert nicht, aber LittleSnitch überprüft den Prozess im Speicher korrekt.





LittleFlocker - F-Secure hat LittleFlocker gekauft und heißt jetzt xFence.



F-Secure xFence (ehemals LittleFlocker)



Ziel-Siehe Werkzeuge

Taskexplorer





WhatsYourSign



Facebook OSquery ist das Ergebnis von Malware-Beispielen und / bin / ls als gültiges Beispiel.



Google Santa-Ausgabe - Fileinfo zeigt, dass ncat.frankenstein auf der Whitelist steht:



Verweigern Sie die Ausführung von ncat (ohne Vorzeichen) und die Ausführung von ncat.frankenstein:



Santa.log-Protokoll mit Ereignissen aus dem vorherigen Beispiel:



Rußreaktion



VirusTotal - Beispiel bash_ppc_adhoc vor der Installation des Patches in VirusTotal:



Offenlegungstermine


22.02.2008: Ein Bericht und ein PoC wurden an Apple gesendet, um Sicherheitssysteme von Drittanbietern zu umgehen.

03/01/2018: Apple antwortete, dass Entwickler von Drittanbietern kSecCSCheckAllArchitectures und kSecCSStrictValidate mit der SecStaticCodeCheckValidity-API verwenden sollten, und die Entwicklerdokumentation wird entsprechend aktualisiert.

03/06/2018: Ein Bericht und ein PoC wurden an Apple gesendet, um Flags zu umgehen und das codesign streng zu überprüfen.

16.03.2008: Zusätzliche Informationen an Apple gesendet.

20.03.2008: Apple sagte, dies sei kein Sicherheitsproblem, das direkt angegangen werden sollte.

29.03.2008: Apple gab an, dass die Dokumentation aktualisiert werden könnte, aber "[...] Entwickler von Drittanbietern sollten zusätzliche Arbeit leisten, um zu überprüfen, ob alle Identitäten in der universellen Binärdatei gleich sind, wenn sie ein aussagekräftiges Ergebnis präsentieren möchten."

04/02/2018: Erster Kontakt mit CERT / CC und anschließende Zusammenarbeit zur Klärung des Umfangs und der Auswirkungen der Sicherheitsanfälligkeit.

04/09/2018: Alle bekannten Drittentwickler, die von der Sicherheitsanfälligkeit betroffen sind, werden in Abstimmung mit CERT / CC benachrichtigt.

18.04.2008: Letzter Kontakt mit CERT / CC mit der Empfehlung, dass die Veröffentlichung von Informationen in einem Blog am besten geeignet ist, um andere Entwickler von Drittanbietern zu benachrichtigen, die die Codesignatur-API von Apple privat verwenden.

06/05/2018: Endkontakt mit den Entwicklern vor Veröffentlichung.

06/12/2018: Offenlegung von Informationen.

Abschließend


Vielen Dank an alle Drittentwickler für ihre harte Arbeit und Professionalität bei der Lösung dieses Problems. Sicherheitslücken beim Signieren von Code sind besonders demoralisierende Fehler, insbesondere für Unternehmen, die versuchen, eine bessere Sicherheit als die Standardeinstellung im Betriebssystem bereitzustellen.


GMO GlobalSign Russia AKTION für Habr-Abonnenten


Weitere Informationen erhalten Sie, indem Sie sich telefonisch an den GlobalSign-Manager wenden: +7 (499) 678 2210, oder das Formular auf der Website mit dem Promo-Code CS002HBFR ausfüllen.

Source: https://habr.com/ru/post/de414011/

More articles:


All Articles