iOS Mail: Ungereimtheiten im Bugreport
Die Presse und das BSI machen aus Vermutungen und Spekulationen handfeste Warnungen.
Was ist passiert?
Die mir bislang unbekannte Firma ZecOps veröffentlichte einen Bugreport zur iOS Mail.app und behauptet, damit wäre die Einschleusung von Schad-Code möglich. Die allererste Information auf der Seite ist ein Hinweis auf ein Tool der Firma, das für solche Probleme verkauft wird.
Die meisten Nachrichten und das BSI in seiner Pressemittleilung springen auf den Zug auf und schlagen Alarm, raten zum Löschen von Mail.app. Heise schiebt ein Update nach und erwähnt, daß mindestens ein renommierter iOS-Hacker, Dino Dai Zovi, Zweifel an der Ausnutzbarkeit der genannten Bugs hat.
Zweifel
Die ganze Sache hat ein Geschmäckle, das bei mir aufgrund verschiedenenr Fakten entstanden ist:
Glauben statt Wissen
Der Artikel von ZecOps relativiert seine Kernaussagen mit "wir glauben" (believe) und "wir vermuten" (surmise). Sie haben keinen Proof-of-Concept, der zeigt, daß das Einschleusen von Code möglich ist. Sie können Mail.app zum Absturz bringen. Sie haben sich Crash-Reports, die iOS automatisch erstellt, angesehen. Sie haben sich die Code-Stellen angesehen. Sie belegen ihre Vermutungen und Spekulationen über die Möglichkeit zum Einschleusen von Schadcode jedoch an keiner Stelle.
Eine Menge Song & Dance, aber keine harten Beweise. Crash! Boom! Bang!
Von Profis nicht nachvollziehbar
Dino Dai Zovi, den nicht nur ich in den letzten 10 Jahren öfters erwähnt habe, hat detaillierte Zweifel an der Darstellung von ZecOps geäußert und den Autor auch direkt konfrontiert. Nun möchte ZecOps irgendwann noch mehr Details nachhreichen.
Dino Dai Zovi nimmt diesen Artikel von Reuters und die Darstellung von ZecOps selbst als Ausgangspunkt:
Ich habe da ein paar Fragen hierzu: "Avraham (ZecOps) basiert die meisten seiner Schlußfolgerungen auf 'Crash Reports', die automatisch erzeugt werden, wenn eine App abstürzt. Er war dann in der Lage, kontrolliert Crashes zu provozieren."
I have questions: "Avraham based most of his conclusions on data from 'crash reports,' which are generated when programs fail in mid-task on a device. He was then able to recreate a technique that caused the controlled crashes."
Meine Frage ist im Prinzip diese: Wenn der Exploit die (zum Angriff gesendeten) Emails löscht, wenn er erfolgreich war, dann würde er wohl auch entweder nicht crashen oder den Crash-Report ebenfalls löschen. Daher ist der Crash-Report wahrscheinlich von einem fehlgeschlagenem Exploit. In diesem Fall wäre der Exploit nicht in der Lage, die (zum Angriff gesendete) Email zu löschen.
My question is basically this: if the exploit deletes the e-mails when it succeeds, it probably also would either a) not crash or b) delete the crash report too. So the crash report is likely from a failed exploit. In that case, it wouldn't have been able to delete the email.
Außerdem kann ich nicht nachvolziehen, wie die beschriebenen Crashes benutzt werden könnten, um verläßlich Schadcode einschleusen zu können auf diesen Versionen (12 und 13) von iOS. Das soll nicht heißen, es wäre nicht möglich, aber ich sehe einfach nicht, wie Dir die MIME-Dekodierung ein vorhersagbares Heap-Layout verschafft und/oder eine Speicher-Adresse verrät, um eine ROP-Chain (Return Oriented Programming - Befehlskette) zu erstellen etc.
I also didn't follow how the crashes described could be leveraged for reliable RCE on those versions of iOS. That doesn't mean it's not possible, just that I don't see how MIME decoding gets you a predictable heap layout and/or address leak feedback to craft ROP chain, etc.
Ich würde mich über eine Fortsetzung des Blog-Posts freuen mit einer Erklärung, wie diese Bugs denn ausgenutzt werden können.
I'd love to read a follow-up blog post on how to exploit these vulnerabilities.
Man müßte doch wenigstens die Server-Logs vom Empfang der Emails haben. Die Angreifer können die ja nicht löschen.
@DennisF That was another question that I had. You should at least have the server logs of receiving the e-mail from the sender. They can't delete those.
Wenn eine Email reinkommt, entstehen typischerweise mehrere Kopien auf der Platte des Servers. Daher kann die Forensik oft diese temporären Kopien der gelöschten Emails wiederherstellen. Andere Mail-Server könnten ebenfalls Kopien in anderen Bereichen der Inboxen des betroffenen Users haben.
@addelindh @DennisF Not sure if sarcastic, but receiving an e-mail typically creates multiple copies on the server's disk, so forensics can often recover those temporary copies of deleted e-mails. Different mail servers may also have copies in slack space of other representations of users' inboxes.
Ich habe mit verschiedenen Mail-Servern Erfahrung, die zwar eine Weile her ist im Moment, aber ich habe schon Server-Forensik gemacht, um gelöschte Emails wiederherzustellen.
@addelindh @DennisF No worries, hard to gauge tone on the Tweeters. My mail server knowledge is primarily Sendmail, Postfix, and very dated at this point, but I have done server forensics to recover deleted e-mails before.
An den Autor von ZecOps: Ich würde mich über jede weitere Info zu dem Thema freuen!
@ihackbanme I'm looking forward to any follow-up posts with more info!
An den Autor von ZecOps: In Eurem FAQ steht, daß Ihr überprüft habt, daß die Bugs über das Netz ausnutzbar sind. Aber der größte Teil des Artikels geht darüber, wie die Bugs augelöst werden können. Kannst Du etwas mehr darüber sagen, was über das Auslösen der Bugs hinaus getan wurde, um sicherzustellen, daß die Bugs einen Remote Exploit ermöglichen?
@ihackbanme The FAQ says, "We verified that the bugs were remotely exploitable" but most of the blog post talks about how to trigger the bugs. Can you share a little more about what beyond triggering the bugs was done to verify the bugs were remotely exploitable?
impstrsyndrome an Dino Dai Zovi:
Der ganze Artikel von ZecOps klingt wie: "Wir haben einen reproduzierbaren Crash und wir nehmen einfach mal an, daß ein Exploit möglich ist, aber wir konnten selbst keinen Proof of Concept erstellen."
@dinodaizovi The whole thing reads like - “we have a reproducible crash, and we are just going to assume it’s exploitable, but haven’t been able to build a PoC ourselves”
Ich würde tatsächlich glauben, daß es irgendwelche Bugs in Mail gibt, die verläßliche Remote Exploits möglich machen könnten. Ich bin allerdings nicht überzeugt, daß es diese von ZecOps genannten Crashes sind.
@thegrugq @benhawkes @taviso @n_joly I would also absolutely believe that there indeed are reliably remotely exploitable vulnerabilities in Mail, I'm just not yet convinced that these particular crashers are them.
Ich habe mal gehört, daß, wenn Dein Exploit crasht, dann mußt Du ihn eben noch weiter entwickeln.
@daveaitel @halvarflake I heard somewhere that if your exploit crashed, you just needed to do more typey-typey? :)
Dino hält die von ZecOps genannten Bugs nicht für ausreichend, um Mail.app anzugreifen. Er fordert eine Beschreibung, wie das möglich sein soll und einen Demo-Exploit. Außerdem kommt ihm komisch vor, daß ZecOps zwar behauptet, es hätte konkrete Angriffe gegeben, sie aber keine Beispiel-Emails vorlegen können, die man auf den Mail-Servern noch finden müßte.
Apples Untersuchung
Apples Stellungnahme deckt sich mit dem, was Dino oben beschrieben hat:
Wir haben den Bericht von ZecOps genau untersucht und sind basierend auf diesen Informationen zu dem Schluß gekommen, daß keine umittelbare Gefahr für die User besteht. Die genannten Bugs in Mail sind nicht ausreichend, um die Sicherheitsmechanismen von iPhone und iPad zu umgehen, und wir haben keinen Beweis gefunden, daß sie gegen unsere Kunden eingesetzt wurden.
We have thoroughly investigated the researcher’s report and, based on the information provided, have concluded these issues do not pose an immediate risk to our users. The researcher identified three issues in Mail, but alone they are insufficient to bypass iPhone and iPad security protections, and we have found no evidence they were used against customers.
Apple hat die Bugs in iOS 13.4.5, das zur Zeit als Beta verfügbar ist, bereits behoben.
ZecOooooops
Mit so schwachen und unbelegten Spekulationen, die ZecOps hier liefert, kann man sich bei keinem Sicherheitsforscher blicken lassen. Wenn man jeden provozierbaren Crash als möglichen Remote Exploit verkaufen will, dann müßten praktisch alle Programme auf allen Plattformen gelöscht werden per BSI-Hinweis. Da müssen schon handfestere Beweise geliefert werden.
Es ist der Normalzustand, daß Apps gecrasht werden können. Manche Crashes basieren auf Bugs, die einen Remote Exploit ermöglichen könnten. Aber dies wird je nach Plattform auf diverse Weisen erschwert. Und iOS ist in dem Punkt besonders gut.
Vielleicht liefert ZecOps ja noch irgendetwas nach. Bislang ist das nicht passiert.
BSI Ooooops
Das BSI schreibt:
Medienberichten zufolge werden die Schwachstellen bereits aktiv ausgenutzt
Medienberichte? Das BSI hat es also nicht selbst geprüft. Sie haben Nachrichten gelesen und dann mal eben ihr Warnungs-Template ausgefüllt.
ermöglicht es den Angreifern, weite Teile der Mail-Kommunikation auf den betroffenen Geräten zu manipulieren
Wie kommt das BSI zu dieser unbelegten Behauptung? Sie beziehen sich auf keinen Exploit und haben auch selbst keinen vorzuweisen.
Das BSI als Gerüchte-Schleuder.
Dann macht das BSI noch auf dicke Hose und will Apple am 23.04.2020 in bester teutscher (ja, mit "t", kommt von den Teutonen) schulmeistern:
Wir sind im Austausch mit Apple und haben das Unternehmen aufgefordert, hier schnellstmöglich eine Lösung zur Sicherheit ihrer Produkte zu schaffen.
Hat das BSI nicht "in Medienberichten" gelesen, daß Apple die Bugs bereits schon am 15./16. April behoben hat in seiner öffentlichen Beta?
April 15/16th – Vendor patches both vulnerabilities in the publicly available beta
Offenbar hat das BSI eine sehr selektive Wahrnehmung.
Was vermutlich wirklich geschah
Mein Eindruck von dem, was hier passiert ist:
- ZecOps hat bei seinen Kunden diese Crashreports in ihrem Tool gesehen
- ZecOps hat gehofft, daß sie einen Angriff entdeckt haben, um ihr Tool zu promoten
- ZecOps kann keinen Angriff nachweisen, weil passende Emails nicht mal auf dem Server zu finden sind
- ZecOps kann auch keine konkreten Schäden bei Usern nachweisen
- ZecOps kann auch selbst keinen Exploit bauen, um einen möglichen Angriffsweg zu beweisen
- ZecOps meldet die Bugs an Apple und Apple behebt sie in der öffentlichen Beta
- ZecOps schreibt seinen Bericht und weist darin mehrmals auf seine Sicherheits-Tools hin
- Die Medien überschlagen sich vor Freude über eine Apple-Schlagzeile
- Das BSI nimmt sich voll wichtig und zeigt, wie man auch ohne Beweise die User in Angst versetzen kann
- Sicherheitsforscher wie Dino Dai Zovi sagen, die Behauptungen von ZecOps sind eben halt nur Behauptungen und die Bugs sähen nicht mal ausnutzbar aus und fordern Erklärungen
Was für ein schlechter Film. Außer Dino. Der war cool.
Was wäre wenn?
Angenommen, die Bugs wären exploitable, was wäre dann?
Die meisten Leute haben keine Emails, die lohnenswert sind. Für mehr Aktionen (außerhalb der iOS Mail.app) braucht es noch mehr Bugs. Und da die meisten Emails nicht Ende-zu-Ende verschlüsselt sind, kann man auch ohne diesen Bug zumindest mitlesen. Was Google Mail (serverseitig) ja z. B. macht für gezielte Werbung, soweit ich mich erinnere.
Link: osx.realmacmark.de/blog/osx_blog_2020-04-a.php