Skip to content
KitploitKITPLOIT
ToolsBlog
Log in
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2026-12960 — CVE-2026-12960 - Unsachgemäßer Export von Android-Anwendungskomponenten in der ASUS Router App (com.asus.aihome). PoC, Exploit-APK, Video und Anbieterbericht. Behoben in 1.0.0.9.74. | Kitploit
Tools/GitHubGitHub/l0lsec/cve-2026-12960
Android-SicherheitSchwachstellenanalyseExploitationMobile App-PenetrationstestsPenetrationstestsMobile Sicherheit
GitHubl0lsec/cve-2026-12960

CVE-2026-12960

CVE-2026-12960 - Unsachgemäßer Export von Android-Anwendungskomponenten in der ASUS Router App (com.asus.aihome). PoC, Exploit-APK, Video und Anbieterbericht. Behoben in 1.0.0.9.74.

Repository anzeigen
20vor 2 MonatenNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen
Webseite

CVE-2026-12960

Unsachgemäßer Export von Android-Anwendungskomponenten in der ASUS Router App

Eine Komponente, die in der Android-App „ASUS Router“ (com.asus.aihome) enthalten ist, wurde mit android:exported="true" und ohne android:permission deklariert. Jede andere App auf demselben Gerät, ohne jegliche Berechtigungen, konnte ihr einen manipulierten Intent senden und die ASUS Router App dazu bringen, im Namen des Benutzers eine vom Angreifer kontrollierte URI zu öffnen.

Am 17.03.2026 an ASUS gemeldet. Von ASUS behoben und am 03.07.2026 als CVE-2026-12960 veröffentlicht.

Entdeckt und gemeldet von Sedric Louissaint von Show Up Show Out Security.


Zusammenfassung

CVECVE-2026-12960
ProduktASUS Router App für Android (com.asus.aihome)
Betroffen≤ 1.0.0.9.71
Behoben in1.0.0.9.74
SchwachstelleCWE-926: Unsachgemäßer Export von Android-Anwendungskomponenten
CVSS 4.06.0 Medium CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N
CNAASUS
Herstellerhinweishttps://www.asus.com/security-advisory/
Getestet aufcom.asus.aihome 1.0.0.9.71 (Google Play), Android-11-Emulator

Technische Details

Die App enthält das Baidu Push SDK, das Folgendes deklariert:

<service
    android:name="com.baidu.android.pushservice.CommandService"
    android:exported="true" />

Es gibt kein android:permission-Attribut, daher greift Androids Zugriffskontrolle auf Komponentenebene nie ein. Jede installierte App kann startService() auf den Dienst aufrufen.

CommandService.onStartCommand() liest ein PublicMsg-Parcelable aus dem public_msg-Extra des eingehenden Intents und übergibt es an handlePrivateNotification(), das anhand des vom Angreifer gelieferten mOpenType-Felds verzweigt:

mOpenTypeVerhalten
1startActivity(ACTION_VIEW, Uri.parse(mUrl)) mit der mUrl des Angreifers
2Intent.parseUri(mPkgContent, 0), dann startActivity() / sendBroadcast()

Weder der Absender noch die Nutzlast wird validiert. Da die resultierende Activity aus der eigenen UID und dem eigenen Prozess der ASUS-App gestartet wird, scheint alles, was auf dem Bildschirm erscheint, von der vertrauenswürdigen Router-Verwaltungs-App zu stammen, die der Benutzer gerade geöffnet hat.

In der Wirkung ist daran nichts Baidu-spezifisch. Das SDK liefert die exportierte Komponente, die Host-App erbt sie, und die Identität der Host-App ist es, die ausgeliehen wird.

Angriffskette

  1. Eine bösartige App konstruiert ein PublicMsg-Parcelable, das dem Feldlayout des Ziels entspricht.
  2. Setzt mOpenType = 1 und mUrl auf eine vom Angreifer kontrollierte URI.
  3. Sendet den Intent an CommandService. Keine Berechtigung erforderlich, keine SecurityException.
  4. onStartCommand() → handlePrivateNotification().
  5. startActivity(ACTION_VIEW, Uri.parse(mUrl)) wird aus dem Prozess der ASUS-App ausgelöst.

Die PublicMsg-Feldreihenfolge, die aus writeToParcel im dekompilierten Smali-Code rekonstruiert und in poc/PublicMsg.java neu implementiert wurde:

String mMsgId, mAppId, mTitle, mDescription, mUrl, mPkgName
int    mPkgVercode, mNotificationBuilder, mNotificationBasicStyle
int    mOpenType, mUserConfirm
String mCustomContent, mPkgContent
int    mAdvertiseStyle
String mAdvertiseSmallIconUrl, mAdvertiseLargeIconUrl, mAdvertiseClickUrl,
       mAdvertiseBigPictureUrl, mAdvertiseBigPictureClickUrl, mAdvertiseDownloadClickUrl

Bei falscher Reihenfolge wird das Parcel zu Datenmüll entserialisiert. Bei korrekter Reihenfolge akzeptiert der Dienst die Nachricht, als hätte Baidus eigene Push-Infrastruktur sie gesendet.

Demonstrierte Nutzlasten

Sechs URI-Schemata, ein exportierter Dienst, null Berechtigungen:

#SchemaErgebnis
1https:Browser öffnet eine vom Angreifer kontrollierte Phishing-Seite
2sms:SMS-Editor, vorausgefüllt mit einer Social-Engineering-Nachricht
3tel:Telefon-App, vorausgefüllt mit einer vom Angreifer kontrollierten Nummer
4mailto:E-Mail-Editor, vorausgefüllt zum Exfiltrieren von Anmeldedaten
5market:Play-Store-Umleitung für eine Malware-Installation
6geo:Maps-Umleitung zu einem gefälschten Service-Center

Proof of Concept

media/poc_commandservice.mp4 ist der vollständige 31-sekündige Durchlauf: Build, Installation, Auslösen, und der Emulator, der nacheinander auf jede Nutzlast reagiert.

Angriff 1: Phishing-SeiteAngriff 2: SMS-EditorAngriff 3: Telefon-AppBerechtigungen der PoC-App
Browser, geöffnet zu einer Angreifer-URLSMS-Editor, vorausgefüllt mit einem gefälschten ASUS-SicherheitshinweisTelefon-App, vorausgefüllt mit einer Angreifer-NummerAndroid-App-Info-Bildschirm mit der Anzeige „Keine Berechtigungen angefordert“

Dieser letzte Screenshot ist das gesamte Argument. Keine Berechtigungen angefordert. Die App, die gerade sechs Aktionen über die ASUS Router App ausgelöst hat, hat den Benutzer um überhaupt nichts gebeten.

Reproduktion

Erfordert ADB, ein JDK und die Android-SDK-Build-Tools (aapt2, d8/dx, zipalign, apksigner) sowie platforms;android-30.

./poc/poc_commandservice_exploit.sh <device_serial>

Das Skript durchläuft drei Phasen:

  1. Zugriffsprüfung. Sendet die drei CommandService-Aktionen von com.android.shell aus und meldet, ob eine abgelehnt wird. Ein berechtigungsgeschützter Dienst würde hier eine SecurityException auslösen. Dieser Dienst akzeptierte alle drei.
  2. Build. Kompiliert den PoC, verpackt und signiert exploit_commandservice.apk und installiert ihn. Eine vorgefertigte Kopie liegt in poc/, falls du diesen Schritt überspringen möchtest.
  3. Ausführung. Bringt die ASUS-App in den Vordergrund, startet den PoC aus einem privilegienfreien App-Kontext und zeichnet die Logcat-Beweise auf.

Phase-1-Ausgabe auf einem verwundbaren Gerät:

[ACCESS]  passthrough.notification.CLICK → service accepted intent
[ACCESS]  privatenotification.CLICK      → service accepted intent
[ACCESS]  privatenotification.DELETE     → service accepted intent

  Phase 1 result: 3/3 actions accepted without permission check

Und der ServiceRecord von dumpsys activity services, der den Aufrufer aufzeichnet:

intent={act=com.baidu.android.pushservice.action.privatenotification.CLICK
        cmp=com.asus.aihome/com.baidu.android.pushservice.CommandService}
recentCallingPackage=com.android.shell
startRequested=true callStart=true

Phase 3, von einer echten privilegienfreien App statt von der Shell:

W PoCExploit: [OK] attack1_url_open → com.asus.aihome/com.baidu.android.pushservice.CommandService
W PoCExploit: [OK] attack2_sms_compose → ...
(all 6 succeed)

startService() gab den Ziel-ComponentName statt null zurück, und es wurde keine SecurityException ausgelöst. Android hat den Intent aufgelöst und zugestellt.

Tool herunterladen