heartbleed-Lücke in SSL - der GAU ist da

[rihntrha]

Nochmal aus dem Link von oben:
Das heißt, du musst lediglich deine Android-Version kennen, um zu wissen, ob dein Android betroffen ist.

Nun ja, wenn der Hersteller ein Image baut dann kann er da ja eigentlich jede beliebige SSL Version reinpacken, er kann sie beliebig patchen und nach belieben Features aktivieren/deaktivieren.

Ich denke die Aussage von Google bezieht sich auf plain stock Android.

cu

 

[rudolf]

Für diejenigen die betroffen sind erst mal eine einfache Vorgehensweise für's erste:

1. Mit Heartbleed Detector und/oder Heartbleed Scanner schauen, ob man betroffen ist.

Wenn ja,

2. Alles möglichst mit Firefox machen, auch die e-mail, der ist sicher.

3. Möglichst wenige apps nutzen, die mit einem Konto verbunden sind, insbesondere keine Banking oder Bezahlapps.

Ich hatte in Beitrag #8 schon geschrieben, dass ich bei mir die libssl.so von 4.1.2 eingespielt hatte. Dann hab ich mit Heartbleed Detector und Heartbleed Scanner geschaut, ob es betroffen ist. Die erwartete Antwort was "OK". Dann hab ich wieder die libssl.o von meinem 4.1.1 eingespielt, und Überraschung, war auch ok. Somit sind die Pressemeldungen nicht vollständig, man sollte besser prüfen. Mein 4.1.1 wurde übrigends Januar 14 erzeugt, vielleicht hat da einer mitgedacht.

Daher müsste ein Betroffener dieses experiment wieterführen. das geht so:

1. 4.1.2 Rom runterladen, ich hab das 3.1 genommen:
[ROM/4.1.2] [Feb 01 2013] CM10 | Jelly Bean 4.1.2 - v3.1 - xda-developers
Aus der .zip /system/lib/libssl.so auf die SD vom Telefon kopieren.

2. Mit einem rootfähigen Dateimanager (ich: totalcommander) zuerst die alte libssl.so in /system/lib umbenennen, dann die neue reinkopieren. Dann sofort die Rechte auf rw- r-- r-- ändern.

3. Neu starten, und testen.

Man sollte besser dazu ein TWRP recovery draufhaben, denn ohne gültige libssl fährt mein Telefon nicht hoch. Mit dem TWRP und dessen Filemager kann man im Notfall das original libbsl.so wieder richtig benennen. Dazu muss vorher /system gemountet werden.

Wenn der bug noch da ist eventuell den cache löschen (wipe cache, nicht den dalvik), und wieder testen.

Falls der bug weg ist, aber das System nicht richtig läuft, kann man probieren auch die lib in /system/lib/ssl/engine rüber zu kopieren, und bei MTK boards ggf. auch die /system/lib/libssladp.so.


Ich habe ein Alcatel 997d. wer auch eins hat könnte mal testen ob auch ihr entgegen der Pressemeldungen den Fehler nicht habt.

 

[Rak]

Nun ja, wenn der Hersteller ein Image baut dann kann er da ja eigentlich jede beliebige SSL Version reinpacken, er kann sie beliebig patchen und nach belieben Features aktivieren/deaktivieren.

Davon habe ich bisher nirgends etwas gelesen. Wenn du da eine Quelle hast, her damit .

Überall lese ich nur Android 4.1.x. Daher gehe ich davon aus, dass es nicht herstellerspezifisch ist. Sonst würde man davon erfahren, denke ich.

Aufgedeckt wurde dies von Sicherheitsforschern des SANS ICS-Institute in Australien. Es wird derzeit davon ausgegangen, dass nur 4.1.1 die Heartbleed-Sicherheitslücke in OpenSSL aufweist, wie Google auch per Blogbeitrag mitteilt. Einigen Berichten zufolge sei aber auch 4.1.0 betroffen

Heartbleed-Bug: OpenSSL-Lücke steckt auch in Android 4.1 Jelly Bean - CNET.de

 

[rudolf]

Das heißt, du musst lediglich deine Android-Version kennen, um zu wissen, ob dein Android betroffen ist.

Eben nicht!

 

[Rak]

Heißt das, dass du sagst, z.B. auch Android 4.2.x aufwärts selbst sei betroffen?

Wieso?

(Abgesehen wieder von dem bereits von mir genannten Problem der einzelnen Apps)

 

[pybcu]

Die ganze Diskussion darüber, ob die clientversion betroffen ist oder nicht ist letzten Endes eh egal.
Der Angriff erfolgt i.d.R. gegen den Server, mit dem man vorher kommuniziert hat. Also egal ob man selber eine betroffene openSSL version verwendet oder nicht: Tut es der Server, hat man die Arschkarte.

Die Andere Richtung, also dass man sich mit einem bösartigen Server verbindet und so mitgelauscht wird dürfte die große Ausnahme sein.

Bzw. dann braucht es die Lücke gar nicht. Wenn sich einer mit geklautem Zertifikat dazwischenhängt (also vorher ein Angreifer den privaten Schlüssel eines Servers besorgt hat) gibt man dem die Daten ja dann "freiwillig". (der lauscht einfach mit und entschlüsselt den Datenverkehr, das hat dann aber nix mehr mit heartbleed zu tun)

 

[Koriolis]

Die ganze Diskussion darüber, ob die clientversion betroffen ist oder nicht ist letzten Endes eh egal.

Richtig. Und an dieser Stelle sowieso...

Nichtsdestotrotz hilft das Austauschen der /system/lib/libssl.so wie weiter oben beschrieben, um den Bug vom Androiden zu bekommen. Hab es gerade auf einem betroffenen Huawei Y300 getestet.

Der Austausch der Bibliothek ist auf gerooteten Geräten unkritisch. Allerdings muss man aufpassen, die richtige Version 1.01c zu benutzen, die von Google kastriert wurde (steht alles oben). Außerdem muss man nach dem Austausch das Gerät unbedingt neu booten. K9-Mail und die anderen OpenSSL-Programme laufen fehlerlos.

 

[rudolf]

Na das sieht doch gut aus. Gerade für diejenigen, wo der Hersteller kein Update liefert.

Hast Du die libssl aus der Quelle genommen, die ich nannte? Wenn nicht, woher?
Ich könnte wenn ich das weiss auf xda fragen ob dort einer eine signierte update.zip macht. Die könnten dann auch Leute ohne root nutzen.

 

[rudolf]

@ rudolf : Na, ich finde es schon wichtig den Druck auf die Hersteller zu erhöhen. Wenn hier drölfzehn Leute schreiben "Huawei ist ne lamer-Firma, weil die den Bug net fixen" wird sich mittelfristig bei Huawei was bewegen.
Die lesen hier ganz sicher mit, und negative Publicity mögen die auch net...

Volle Zustimmung! Ich meinte auch nicht, hier soll weniger geschrieben werden.

 

[perpe]

Es wird ja beispielsweise nicht untersucht, ob eine der installierten Apps ein eigenes OpenSSL mitbringt. Wie auch...

Das kann die App Bluebox Heartbleed Scanner (von mir nicht getestet)

 

[liontari]

Bluebox Heartbleed Scanner:
Scanner gerade getestet - hat 1 App (Office Suite 7.4) gefunden.
Vielen Dank für Deinen Hinweis auf die App!!
(Mein System: p6800, ICS 4.0.4, Android Vers. 1.0.0)

 

[Koriolis]

Hast Du die libssl aus der Quelle genommen, die ich nannte?

Genau diese libssl.so habe ich verwendet.

Größe: 224824 Byte. MD5-Hash: b8351b5de92151f29f13673eed5e7849

 

[Otandis_Isunos]

Naja, ich laufe bspw mit Android 4.1.2 und hab laut diversen Scannern 1.0.1c, aber bin sicher und keine von mir installierte App nutzt OpenSSL. Interessant. Egal. Passt schon

 

[Koriolis]

Naja, ich laufe bspw mit Android 4.1.2 und hab laut diversen Scannern 1.0.1c, aber bin sicher und keine von mir installierte App nutzt OpenSSL. Interessant.

Dazu eine kurze Erklärung, warum das so ist.

Google hat mit der Version 4 in seinem Android-Code die OpenSSL verbaut, aber ab Version 4.1.2 den Heatbeat abgestellt. Das war genau diese obige Version 1.0.1c der OpenSSL. Das hat zur Folge, dass nur die Androidversion bis 4.1.1 anfällig für den Bug ist. Ab Androidversion 4.1.2 tritt der Bug nicht mehr auf. Allerdings enthält Android 4.1.2 immer noch die an sich anfällige OpenSSL-Version, nur mit dem Unterschied, dass Heatbeat abgestellt wurde.

Auf diese Weise kommen die verwirrenden Meldungen der Heartbleed-Scanner zustande (...anfällige OpenSSL, aber kein Bug...).

PS: Die Funktion der OpenSSL heißt tatsächlich Hearbeat (Herzschlag), weil sie in regelmäßigen Abständen Lebenszeichen sendet, die eine aktive Verbindung anzeigen sollen, auch wenn gerade keine Daten übertragen werden. Als Wortspiel in Analogie zum Ausbluten des Herzens wurde der Bug dann Heartbleed (Herzbluten) genannt. Und inzwischen verdichten sich Indizien, dass die NSA ihre Stinkefinger im Spiel hatte. Spiegel Online

 

[Otandis_Isunos]

Naja, okay, soweit hatte ich das auch verstanden und ich hab das auch nur überprüft, weil es hier einige Missverständnisse zwischen 4.1.1 und 4.1.2 gab

Was mich allerdings mehr nervt: Warum man dafür unbedingt eine App braucht um zum prüfen, welche OpenSSL Version Android nutzt. Ich hab bestimmt n Brett vor dem Kopf, weil ich das via Terminal nicht rausgefunden habe

 

[rudolf]

Linux hat noch eine openssl binary(programm), womit man die Version vom Terminal aus abfragen kann. Bei android sind nur die ".so" bibliotheken vorhanden, und die kann man nicht direkt aufrufen. Eine einfache methode ist jedoch, mit einem Text oder Dateieditor einfach in der libssl.so nach "1.0" zu suchen. Man findet dann 1.0.1c als klartext.Das geht z.B. mit total commander auch ohne root.

In beiden libs, also der von 4.1.1 und in der 4.1.2 findet man auch mehrfach den text "heartbeat". Bei der 4.1.2 wurde die lib jedoch so compiliert, dass diese funktion nicht genutzt werden kann, sie ist vorhanden, aber abgeschaltet (not enabled). Daher auch die etwas eigenwillig anmutende Meldung der Prüf-Apps.

 

[Otandis_Isunos]

Ja eben, weil das ja unter Linux einfach mittels: "openssl version" geht, war ich etwas verdutzt, wie die Apps dann eigentlich an die Versionsnummer kommen

Aber okay, wieder was gelernt

Nachtrag:

Ah alles klar. mittel vi /system/lib/libssl.so kann man die Datei öffnen und dann mit /1.0 direkt nach der Version suchen.

Da brauchts keine App für

 

[Koriolis]

Nach der libssl.so auf dem Smartphone zu suchen reicht nicht. Die libssl.so versteckt sich auch in den dex-Dateien des Dalvik-Caches bzw. wurde in einer mitgebrachten eigenen Lib verbaut.

Ausgerechnet Orbot des Tor-Projekts ist so ein Beispiel. Da wurde in der libtor.so die OpenSSL eingebaut und ist entsprechend anfällig.

Auf meinem (gerooteten) Smartphone hab ich den ssh/sftp Daemon sowie den Midnight Commander installiert. Damit lässt sich per SSH auf einfache Weise nach weiteren Kandidaten suchen. Auch innerhalb von anderen Dateien...

 

[rudolf]

Die Meldung des Bluebox scanners das ich keine app auf dem Telefon hab die openssl nutzt hat mich stutzig gemacht. Denn wozu ist das openssl dann da, und warum sollte die google apps (z.B. browser, mail,...) das nicht nutzen?

Also hab ich mal bei Bluebox reingeschaut;
https://bluebox.com/technical/heartbleed-bug-impacts-mobile-devices/
und die schreiben:
"Additionally we scan all of the applications on your device and present you with ones that contain their own openssl library"
Das heist, der scanner zeigt nur die apps, die ihre eigene openssl version mitbringen und nutzen, und nicht die vom telefon verwenden. Diese eigene Version kann wiederum entweder gut oder schlecht sein.
Bluebox sagt mann soll den Hersteller der App fragen, darauf würde ich nicht vertrauen. Man kann jedoch zumindest die .apk Datei als zip öffnen, darin in /lib nachsehen, und die dortigen ".so" dateien auf versionstexte untersuchen. 1.0.1 bis 1.0.1f können betroffen sein. Das geht z.B. alles mit total commander auch ohne root.

Der ursprüngliche Beitrag von 12:12 Uhr wurde um 12:34 Uhr ergänzt:

Nach der libssl.so auf dem Smartphone zu suchen reicht nicht. Die libssl.so versteckt sich auch in den dex-Dateien des Dalvik-Caches bzw. wurde in einer mitgebrachten eigenen Lib verbaut.

Der Dalvik cache enthält nicht "kopien" der /system/lib/libssl.so, sondern "kopien" der ".apk" Dateien. Dort findet man also ggf. die "eigenen" openssl's von installierten apps.
Diese kopien entfernt man durch deinstallieren der app.

Der Menüpunkt "wipe cache" in vielen recoveries löscht übrigends einen völlig anderen cache (/cache, nicht /data/dalvik-cache).

 

[ebertplatzultra]

Hallo Rudolf, vielen Dank für Deine Anleitung zu Heartbleed!
Habe ein Archos Titanium 97 HD Tablett. Nach Austausch der libssl läuft alles wie es soll. Toll!