Cynob
Enthusiast
- 1.019
Ich mach das alles auf nem Linux - ob und wie das in Windows funktioniert müsst ihr jemand anderes fragen 
Auf dem Linux hab ich zuerst das Android SDK und NDK installiert und eingerichtet. Später kam noch die komplette AOSP build Umgebung dazu.
Ihr könnt gleich das AOSP Gedöns installieren - da is alles mit dabei
Wie man das einrichtet sollte hier jetzt aber nicht bestandteil sein.
Jetzt aber Schritt für Schritt:
Versuch 1:
Der erste Versuch den ich machte war mit der dirtyCOW Bug.
Dort ist beschrieben was der so macht und wie er funktioniert:
Dirty COW (CVE-2016-5195)
So dann fand ich zuerst noch die Umsetzung von "tlmwr"
GitHub - timwr/CVE-2016-5195: CVE-2016-5195 (dirtycow/dirtyc0w) proof of concept for Android
Damit hab ich zuerst mal über das NDK was lauffähiges erstellen können.
Das läuft so:
Im CVE-2016-5195-master Ordner:
Makefile auf unsere (6.0.1/23) api Version geändert.
Dann in die run-as vor "return 0":
execl("/system/bin/id", "id", (char *)NULL);
eingefügt.
Nun beim Smartphone debugging aktiviert und über USB mit dem PC verbunden
Dann hab ich mit "make root-arm8" das ganze kompilieren lassen. - wie in der Makefile zu lesen ist kopiert das Script die passenden binarys nach /data/local/tmp aufs Telefon.
Daraufhin wird mit Hilfe der dirtyCOW run-as in /system/bin überschrieben und darauf folgend gestartet.
Unsere umgeschriebene run-as sollte uns jetzt als Benutzer und Gruppe root anzeigen. Leider im falschen Kontext von SELinux.
Wenn man jetzt ein wenig spielen will kann man mit dem execl Befehl zumindest die init.rc Dateien auf dem Phone auslesen.
Aber wir können festhalten das der Exploit läuft.
Das Problem: SELinux möchte nicht das Daten wirklich auf den emmc Speicher geschrieben werden -unser Exploit schreibt nur ins Journal von der ext Partition. Das heißt das beim Neustart unsere Änderungen flöten gehn.
Dann hat SELinux noch so ne tolle Rechtevergabe. Man braucht nen bestimmten SELinux Kontext um bestimmte Sachen machen zu dürfen (Der run-as Kontext darf z.B. kein /system rw mounten - blöd sonst hätten wir gleich root). Diese SELinux Settings kann man übers Terminal sich mit "ls -Z" anschauen.
So das ganze hat mich daraufhin auf folgende Idee gebracht:
Versuch 2:
Nach lesen dieses Threads war ich auch um einiges schlauer:
How do you spawn a shell after exploit? · Issue #9 · timwr/CVE-2016-5195 · GitHub
(Und ja ihr solltet euch das wirklich alles antun - das ist echt informativ!)
Also nahm ich GitHub - jcadduono/android_external_dirtycow: CVE-2016-5195 (dirtycow/dirtyc0w) - recowvery fork
in meine (ca. 85GB Download!) AOSP build Umgebung auf.
Es funktioniert theoretisch folgendermaßen:
man schreibt zuerst die geänderte "applypatch" aufs Phone.
danach die umgeschriebene app_process64.
Durch das Überschreiben der app_process64 stürzt dieselbe ab und wird vom System neu gestartet - wenn diese gestartet wird lädt sie applypatch nach welches wiederum ein image vom kernel lädt, dieses umschreibt so dass SELinux deaktiviert ist > schreibt das ganze zurück und man kann mit reboot recovery ins "offene" System booten.
So es scheitert schon bei mir daran das das ganze Telefon neu startet und der dirtyCOW Exploit nichtmal wirklich mit dem schreiben fertig werden kann wenn ich versuche die app_process64 zu überschreiben.
Was man versuchen könnte: app_process64 nachbauen so das er nicht abschmiert und dann dort über n Backdoor applypatch ausführen.
Ich hab das jetzt nicht weiter verfolgt...
Dann fand ich den cve-2016-0728
Analysis and Exploitation of a Linux Kernel Vulnerability (CVE-2016-0728)
Versuch 3:
Da bin ich zur Zeit dran.
Was erreicht werden soll:
Mithilfe des Bugs ne root shell öffnen!
So was ich zur Zeit für Infos hab:
cve-2016-0728 for Android
auf githup: GitHub - nardholio/cve-2016-0728
So das Problem ist nun das selbst mit dem "run-as" root von den Versuchen davor sich die /proc/kallsyms nur mit 0x0000.. zurückmeldet.
Nun fand ich folgendes wie ich an die Symbol Adressen kommen könnte:
Bits, Please!: Effectively bypassing kptr_restrict on Android
Methode 2 und 3 hören sich echt brauchbar an - ich hab nur keine Ahnung ob die Symbole in der /proc/kallsyms statisch sind oder dynamisch vergeben werden.
Dann müsste man wenn das geht die Namen zu den Adressen mappen und könnte somit den Exploit ausnutzen.
Auf dem Linux hab ich zuerst das Android SDK und NDK installiert und eingerichtet. Später kam noch die komplette AOSP build Umgebung dazu.
Ihr könnt gleich das AOSP Gedöns installieren - da is alles mit dabei
Wie man das einrichtet sollte hier jetzt aber nicht bestandteil sein.
Jetzt aber Schritt für Schritt:
Versuch 1:
Der erste Versuch den ich machte war mit der dirtyCOW Bug.
Dort ist beschrieben was der so macht und wie er funktioniert:
Dirty COW (CVE-2016-5195)
So dann fand ich zuerst noch die Umsetzung von "tlmwr"
GitHub - timwr/CVE-2016-5195: CVE-2016-5195 (dirtycow/dirtyc0w) proof of concept for Android
Damit hab ich zuerst mal über das NDK was lauffähiges erstellen können.
Das läuft so:
Im CVE-2016-5195-master Ordner:
Makefile auf unsere (6.0.1/23) api Version geändert.
Dann in die run-as vor "return 0":
execl("/system/bin/id", "id", (char *)NULL);
eingefügt.
Nun beim Smartphone debugging aktiviert und über USB mit dem PC verbunden
Dann hab ich mit "make root-arm8" das ganze kompilieren lassen. - wie in der Makefile zu lesen ist kopiert das Script die passenden binarys nach /data/local/tmp aufs Telefon.
Daraufhin wird mit Hilfe der dirtyCOW run-as in /system/bin überschrieben und darauf folgend gestartet.
Unsere umgeschriebene run-as sollte uns jetzt als Benutzer und Gruppe root anzeigen. Leider im falschen Kontext von SELinux.
Wenn man jetzt ein wenig spielen will kann man mit dem execl Befehl zumindest die init.rc Dateien auf dem Phone auslesen.
Aber wir können festhalten das der Exploit läuft.
Das Problem: SELinux möchte nicht das Daten wirklich auf den emmc Speicher geschrieben werden -unser Exploit schreibt nur ins Journal von der ext Partition. Das heißt das beim Neustart unsere Änderungen flöten gehn.
Dann hat SELinux noch so ne tolle Rechtevergabe. Man braucht nen bestimmten SELinux Kontext um bestimmte Sachen machen zu dürfen (Der run-as Kontext darf z.B. kein /system rw mounten - blöd sonst hätten wir gleich root). Diese SELinux Settings kann man übers Terminal sich mit "ls -Z" anschauen.
So das ganze hat mich daraufhin auf folgende Idee gebracht:
Versuch 2:
Nach lesen dieses Threads war ich auch um einiges schlauer:
How do you spawn a shell after exploit? · Issue #9 · timwr/CVE-2016-5195 · GitHub
(Und ja ihr solltet euch das wirklich alles antun - das ist echt informativ!)
Also nahm ich GitHub - jcadduono/android_external_dirtycow: CVE-2016-5195 (dirtycow/dirtyc0w) - recowvery fork
in meine (ca. 85GB Download!) AOSP build Umgebung auf.
Es funktioniert theoretisch folgendermaßen:
man schreibt zuerst die geänderte "applypatch" aufs Phone.
danach die umgeschriebene app_process64.
Durch das Überschreiben der app_process64 stürzt dieselbe ab und wird vom System neu gestartet - wenn diese gestartet wird lädt sie applypatch nach welches wiederum ein image vom kernel lädt, dieses umschreibt so dass SELinux deaktiviert ist > schreibt das ganze zurück und man kann mit reboot recovery ins "offene" System booten.
So es scheitert schon bei mir daran das das ganze Telefon neu startet und der dirtyCOW Exploit nichtmal wirklich mit dem schreiben fertig werden kann wenn ich versuche die app_process64 zu überschreiben.
Was man versuchen könnte: app_process64 nachbauen so das er nicht abschmiert und dann dort über n Backdoor applypatch ausführen.
Ich hab das jetzt nicht weiter verfolgt...
Dann fand ich den cve-2016-0728
Analysis and Exploitation of a Linux Kernel Vulnerability (CVE-2016-0728)
Versuch 3:
Da bin ich zur Zeit dran.
Was erreicht werden soll:
Mithilfe des Bugs ne root shell öffnen!
So was ich zur Zeit für Infos hab:
cve-2016-0728 for Android
auf githup: GitHub - nardholio/cve-2016-0728
So das Problem ist nun das selbst mit dem "run-as" root von den Versuchen davor sich die /proc/kallsyms nur mit 0x0000.. zurückmeldet.
Nun fand ich folgendes wie ich an die Symbol Adressen kommen könnte:
Bits, Please!: Effectively bypassing kptr_restrict on Android
Methode 2 und 3 hören sich echt brauchbar an - ich hab nur keine Ahnung ob die Symbole in der /proc/kallsyms statisch sind oder dynamisch vergeben werden.
Dann müsste man wenn das geht die Namen zu den Adressen mappen und könnte somit den Exploit ausnutzen.
