Vertrauen in Systemereignisdaten

Beschreibung

Vertrauen in Systemereignisdaten ist eine Schwachstelle, die auftritt, wenn Software sich auf Systemereignisinformationen verlässt — wie Fensternachrichten, Tastatur/Maus-Events, Accessibility-Callbacks oder UI-Automation-Events — für Sicherheitsentscheidungen ohne ordnungsgemäße Validierung oder Authentifizierung der Ereignisquelle. Auf vielen Plattformen, insbesondere Windows, fehlt dem Event-Messaging-System inhärente Authentifizierungsmechanismen, was jeder Anwendung in der gleichen Sitzung ermöglicht, Nachrichten an Fenster oder Prozesse ohne Verifizierung zu senden. Diese architektonische Einschränkung ermöglicht "Shatter-Angriffe", bei denen bösartige Anwendungen gefälschte Events an höher privilegierte Anwendungen senden und diese manipulieren, unautorisierte Aktionen durchzuführen. Ähnlich können Accessibility- und UI-Automation-Frameworks, die entwickelt wurden, um Benutzern mit Behinderungen zu helfen, von Malware missbraucht werden, um sensible Daten zu lesen, Eingaben einzuschleusen oder Anwendungen zu manipulieren. Das fundamentale Problem ist, dass Anwendungen darauf vertrauen, dass Events aus legitimen Quellen wie Benutzereingabe oder dem Betriebssystem stammen, obwohl sie tatsächlich von bösartiger Software kommen können.

Risiko

Das Vertrauen in Systemereignisdaten ermöglicht lokale Privilegieneskalation, Datendiebstahl und Sicherheitskontroll-Bypass. Klassische Windows-Shatter-Angriffe ermöglichten unprivilegierten Anwendungen, beliebigen Code im Kontext von Systemdiensten auszuführen, indem speziell präparierte Fensternachrichten (WM_TIMER, WM_SETTEXT) an privilegierte Prozesse gesendet wurden. Während Windows Vistas User Interface Privilege Isolation (UIPI) viele Shatter-Szenarien abmilderte, bleibt das zugrunde liegende Designmuster in anderen Kontexten ausnutzbar. Moderne Angriffe missbrauchen Accessibility-Frameworks und UI-Automation-APIs: Die Coyote-Banking-Malware verwendet Windows UI Automation, um Anmeldedaten zu stehlen, während sie alle getesteten EDR-Lösungen umgeht. Android-Banking-Trojaner wie FluBot und MysteryBot missbrauchen Accessibility Services für Keylogging, erfassen 2FA-Codes, überlagern gefälschte Anmeldebildschirme, gewähren sich selbst Berechtigungen und blockieren die Deinstallation. Akamai-Forscher demonstrierten, dass UI-Automation-Missbrauch Daten aus Browsern exfiltrieren, Chat-Anwendungen wie WhatsApp und Slack manipulieren, Browser auf Phishing-Seiten umleiten und Kreditkarteninformationen ernten kann — alles ohne Erkennung durch Endpoint-Sicherheitsprodukte. Die Angriffsfläche ist riesig, weil Accessibility- und Automation-Frameworks mit erhöhten Privilegien entwickelt wurden, um mit anderen Anwendungen zu interagieren.

Lösung

Vertrauen oder verlassen Sie sich niemals auf Informationen aus Events für sicherheitskritische Entscheidungen ohne unabhängige Validierung. Für Windows-Anwendungen validieren Sie, dass Fensternachrichten von erwarteten Quellen kommen und vermeiden Sie die Verarbeitung von Nachrichten, die zu Codeausführung führen könnten (wie WM_TIMER mit Callbacks) von nicht vertrauenswürdigen Ursprüngen. Führen Sie hochprivilegierte Dienste ohne GUI-Komponenten aus wo möglich; wenn GUI-Interaktion notwendig ist, verwenden Sie separate Prozesse mit angemessenen Integritätsstufen. Implementieren Sie User Interface Privilege Isolation (UIPI), indem Sie sicherstellen, dass Anwendungen auf angemessenen Integritätsstufen laufen. Für mobile Anwendungen erkennen Sie, wenn Accessibility Services mit sicherheitssensitiven Bildschirmen interagieren und warnen Sie Benutzer oder fordern Sie zusätzliche Verifizierung an (z.B. Geräteschütteln zur Bestätigung, wie Coinbase es macht). Unter Android verwenden Sie das AccessibilityDataSensitive-Flag, das in Android 16 eingeführt wurde, um sensible UI-Elemente zu schützen. Überwachen Sie auf ungewöhnliche Nutzung von Accessibility- und UI-Automation-APIs, einschließlich Prozesse, die UIAutomationCore.dll laden und unerwartete Named-Pipe-Verbindungen. Implementieren Sie Verteidigung in der Tiefe: Nehmen Sie nicht an, dass die Unfähigkeit, bestimmte Nachrichten zu senden, Sicherheitsgarantien bietet, da Umgehungstechniken sich weiterentwickeln.

Häufige Auswirkungen

Auswirkung	Details
Integrität	Umfang: Integrität Unautorisierten Code oder Befehle ausführen - Gefälschte Events können Ausführung von angreiferkontrolliertem Code im Kontext eines privilegierten Prozesses auslösen. Shatter-Angriffe ermöglichten historisch beliebige Shellcode-Ausführung in Systemdiensten durch manipulierte WM_TIMER-Callbacks.
Zugriffskontrolle	Umfang: Zugriffskontrolle Privilegien erlangen oder Identität annehmen - Angreifer können hochprivilegierte Anwendungen durch gefälschte Events manipulieren, um privilegierte Operationen durchzuführen, wodurch sie effektiv ihre Privilegien eskalieren, ohne traditionelle Speicherkorruptionsschwachstellen auszunutzen.
Vertraulichkeit	Umfang: Vertraulichkeit Anwendungsdaten lesen - Accessibility- und UI-Automation-Frameworks ermöglichen das Lesen von Bildschirminhalten, Eingabefeldern und Anwendungsdaten. Malware, die diese Frameworks missbraucht, kann Anmeldedaten keyloggen, 2FA-Codes stehlen und sensible Informationen aus jeder Anwendung ernten.

Beispielcode

Anfälliger Code

// ANFÄLLIG: Fensterprozedur, die allen eingehenden Nachrichten vertraut
LRESULT CALLBACK VulnerableWndProc(HWND hwnd, UINT msg,
                                   WPARAM wParam, LPARAM lParam) {
    switch (msg) {
        case WM_COPYDATA: {
            // ANFÄLLIG: Verarbeitet Daten von JEDEM Sender ohne Validierung
            COPYDATASTRUCT* cds = (COPYDATASTRUCT*)lParam;

            // ANFÄLLIG: Führt Befehl aus Nachricht direkt aus
            // Jeder Prozess auf demselben Desktop kann dies auslösen
            ExecuteCommand((char*)cds->lpData);
            break;
        }

        case WM_TIMER: {
            // ANFÄLLIG: Klassischer Shatter-Angriffsvektor
            // Angreifer kann Callback-Pointer auf Shellcode setzen
            TIMERPROC callback = (TIMERPROC)lParam;
            if (callback) {
                // ANFÄLLIG: Führt angreiferkontrollierten Funktionspointer aus
                callback(hwnd, WM_TIMER, wParam, GetTickCount());
            }
            break;
        }

        case WM_USER + 100: {
            // ANFÄLLIG: Benutzerdefinierte Nachricht löst privilegierte Aktion aus
            // Keine Verifizierung der Nachrichtenquelle
            PerformPrivilegedAction(wParam);
            break;
        }
    }
    return DefWindowProc(hwnd, msg, wParam, lParam);
}

# ANFÄLLIG: Android-App vertraut Accessibility-Service-Events
class VulnerableLoginActivity:
    def on_text_changed(self, event):
        # ANFÄLLIG: Keine Prüfung ob Event von bösartigem Accessibility Service ist
        # Keylogger-Malware kann allen getippten Text abfangen

        if event.source.resource_id == "password_field":
            password = event.text
            # Passwort für jeden Accessibility Service offengelegt
            self.validate_password(password)

    def on_focus_changed(self, event):
        # ANFÄLLIG: Malware kann erkennen wenn sensible Bildschirme geöffnet werden
        # Und gefälschte Anmeldedialoge überlagern
        pass

# ANFÄLLIG: Desktop-Automation ohne Sicherheitsüberlegungen
class VulnerableDesktopApp:
    def handle_automation_event(self, event):
        # ANFÄLLIG: Vertraut allen UI-Automation-Events
        # Malware kann sensible Daten aus jedem Feld lesen

        if event.property == "Value.Value":
            # Sensible Daten (Kreditkarten, Passwörter) offengelegt
            self.process_value(event.new_value)

Korrigierter Code

// KORRIGIERT: Fensterprozedur mit Nachrichtenquellen-Validierung
LRESULT CALLBACK SecureWndProc(HWND hwnd, UINT msg,
                               WPARAM wParam, LPARAM lParam) {
    switch (msg) {
        case WM_COPYDATA: {
            // KORRIGIERT: Absenderprozess validieren
            HWND senderWindow = (HWND)wParam;
            DWORD senderPid;
            GetWindowThreadProcessId(senderWindow, &senderPid);

            // KORRIGIERT: Nur von bekannten vertrauenswürdigen Prozessen akzeptieren
            if (!IsProcessTrusted(senderPid)) {
                LogSecurityEvent("WM_COPYDATA von nicht vertrauenswürdiger PID abgelehnt: %d",
                                 senderPid);
                return 0;
            }

            COPYDATASTRUCT* cds = (COPYDATASTRUCT*)lParam;

            // KORRIGIERT: Daten vor Verwendung validieren und bereinigen
            if (!ValidateCommandData(cds->lpData, cds->cbData)) {
                return 0;
            }

            // KORRIGIERT: Keine beliebigen Befehle ausführen - Allowlist verwenden
            ProcessAllowedCommand(cds->dwData, cds->lpData);
            break;
        }

        case WM_TIMER: {
            // KORRIGIERT: Niemals Callback von lParam verwenden - Shatter-Angriffsvektor
            // Stattdessen Timer-ID verwenden um bekannte Handler nachzuschlagen
            UINT_PTR timerId = wParam;

            // KORRIGIERT: Nur registrierte, bekannte Callback-Funktionen aufrufen
            TimerCallback handler = GetRegisteredTimerHandler(timerId);
            if (handler) {
                handler(hwnd, timerId);
            }
            break;
        }

        case WM_USER + 100: {
            // KORRIGIERT: Nachrichtenauthentizität validieren
            // Separaten IPC-Mechanismus mit Authentifizierung in Betracht ziehen
            if (!ValidatePrivilegedRequest(hwnd, wParam, lParam)) {
                LogSecurityEvent("Unautorisierte privilegierte Anfrage abgelehnt");
                return 0;
            }

            PerformPrivilegedAction(wParam);
            break;
        }
    }
    return DefWindowProc(hwnd, msg, wParam, lParam);
}

// KORRIGIERT: Prozess-Integritätsstufe prüfen (UIPI)
BOOL IsProcessIntegrityValid(DWORD processId) {
    // Prozesse mit niedrigerer Integrität können keine Nachrichten an höhere Integrität senden
    HANDLE hProcess = OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION,
                                   FALSE, processId);
    if (!hProcess) return FALSE;

    HANDLE hToken;
    if (!OpenProcessToken(hProcess, TOKEN_QUERY, &hToken)) {
        CloseHandle(hProcess);
        return FALSE;
    }

    DWORD integrityLevel = GetProcessIntegrityLevel(hToken);
    CloseHandle(hToken);
    CloseHandle(hProcess);

    // KORRIGIERT: Sicherstellen dass Sender mindestens unsere Integritätsstufe hat
    return integrityLevel >= GetCurrentProcessIntegrityLevel();
}

// KORRIGIERT: Android-App mit Accessibility-Service-Missbrauchserkennung
public class SecureLoginActivity extends AppCompatActivity {

    private static final String PASSWORD_HINT = "Passwort eingeben";

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);

        // KORRIGIERT: Potenziell bösartige Accessibility Services erkennen
        if (isUntrustedAccessibilityServiceEnabled()) {
            showSecurityWarning();
        }

        // KORRIGIERT: Sensible Felder markieren um Accessibility-Erfassung zu verhindern
        EditText passwordField = findViewById(R.id.password);

        // Android 16+: AccessibilityDataSensitive verwenden
        if (Build.VERSION.SDK_INT >= 36) {
            passwordField.setAccessibilityDataSensitive(
                View.ACCESSIBILITY_DATA_SENSITIVE_YES);
        }

        // KORRIGIERT: Zusätzlicher Schutz - automatisierte Eingabe erkennen
        passwordField.setOnEditorActionListener((v, actionId, event) -> {
            // Verifizieren dass Eingabe von echter Benutzerinteraktion kommt
            if (event != null && !isGenuineUserInput(event)) {
                logSecurityEvent("Verdächtige automatisierte Eingabe erkannt");
                showShakeToConfirmDialog();
                return true;
            }
            return false;
        });
    }

    private boolean isUntrustedAccessibilityServiceEnabled() {
        AccessibilityManager am = getSystemService(AccessibilityManager.class);
        List<AccessibilityServiceInfo> services =
            am.getEnabledAccessibilityServiceList(
                AccessibilityServiceInfo.FEEDBACK_ALL_MASK);

        for (AccessibilityServiceInfo service : services) {
            String packageName = service.getResolveInfo()
                .serviceInfo.packageName;

            // KORRIGIERT: Gegen Allowlist vertrauenswürdiger Services prüfen
            if (!isTrustedAccessibilityService(packageName)) {
                return true;
            }
        }
        return false;
    }

    private void showShakeToConfirmDialog() {
        // KORRIGIERT: Physisches Geräteschütteln zur Bestätigung erforderlich
        // Malware kann Schüttelsensordaten nicht simulieren
        new ShakeToConfirmDialog(this)
            .setMessage("Eine App versucht, mit Ihrem Passwort zu interagieren. " +
                        "Schütteln Sie Ihr Gerät zur Erlaubnis.")
            .setOnConfirmed(() -> proceedWithLogin())
            .show();
    }
}

Der anfällige Code demonstriert das Vertrauen in Fensternachrichten und Accessibility-Events ohne Validierung. Der korrigierte Code implementiert Absendervalidierung, vermeidet die Verwendung von Nachrichtenparametern als Funktionspointer (der klassische Shatter-Angriff), erkennt potenziell bösartige Accessibility Services und verwendet Schütteln-zur-Bestätigung für sensible Operationen, die nicht von Malware gefälscht werden können.

Ausgenutzt in der Praxis

Coyote-Banking-Malware - Windows UI Automation Missbrauch (Global, 2025)

Im Februar 2025 identifizierten Sicherheitsforscher die Coyote-Banking-Malware, die aktiv das Windows UI Automation Framework ausnutzt, um Anmeldedaten zu stehlen — der erste dokumentierte reale Fall dieser Angriffstechnik. Die Malware missbraucht Microsofts UI Automation Framework, das ursprünglich entwickelt wurde, um Benutzern mit Behinderungen zu helfen, um sensible Daten aus Browsern und Anwendungen zu lesen, während sie Endpoint-Detection-and-Response-(EDR)-Lösungen vollständig umgeht. Akamai-Forscher hatten im Dezember 2024 vor dieser Möglichkeit gewarnt und demonstrierten, dass Angreifer Daten exfiltrieren, Internet-Browsing manipulieren, Befehle ausführen und Nachrichten aus Anwendungen wie WhatsApp und Slack lesen/schreiben könnten, ohne von irgendeinem getesteten EDR-Produkt erkannt zu werden. Der Angriff funktioniert, weil UI Automation erhöhte Berechtigungen hat, um mit UI-Elementen über Prozesse hinweg zu interagieren, und Malware, die diese APIs nutzt, als legitimes Accessibility-Tooling erscheint.

FluBot Android Banking-Trojaner - Accessibility Service Missbrauch (Europa, 2021)

FluBot, einer der produktivsten Android-Banking-Trojaner, missbrauchte extensiv Accessibility Services, um bösartige Aktionen durchzuführen, während er als legitime Paketlieferungsbenachrichtigungs-App erschien. Sobald Benutzer Accessibility-Berechtigungen gewährten, könnte FluBot alle Bildschirminhalte einschließlich Passwörter und 2FA-Codes lesen, gefälschte Anmeldebildschirme über Banking-Apps überlagern, um Anmeldedaten zu ernten, SMS-Nachrichten abfangen und weiterleiten, sich selbst zusätzliche Berechtigungen ohne Benutzerinteraktion gewähren, Google Play Protect deaktivieren und seine eigene Deinstallation verhindern, indem automatisch "Zurück" gedrückt wird, wenn Benutzer versuchten, seinen App-Info-Bildschirm anzuzeigen. Die Malware verbreitete sich 2021 schnell über Europa, hauptsächlich durch SMS-Phishing-Kampagnen. Ihr Erfolg demonstrierte, wie Accessibility-Frameworks, die für legitime Zwecke entwickelt wurden, für umfassende Gerätekompromittierung weaponisiert werden können.

Tools zum Testen/Ausnutzen

UIAutomationSpy — Microsofts Accessibility Insights Tool, das UI-Automation-Elemente inspizieren kann, nützlich um zu verstehen, welche Daten Accessibility-Clients ausgesetzt sind.
Shatter attack PoC tools — Proof-of-Concept-Tools, die klassische Windows-Shatter-Angriffstechniken für Sicherheitstests von Legacy-Anwendungen demonstrieren.
AccessibilityService analyzer — Tool zur Analyse der Android-Accessibility-Service-Nutzung und Erkennung potenziell bösartiger Implementierungen.

CVE-Beispiele

CVE-2004-0213 — Angreifer verwendete Shatter-Angriff, um GUI-erzwungenen Schutz zu umgehen, was Privilegieneskalation durch gefälschte Fensternachrichten ermöglichte.
CVE-2002-0864 — Windows Utility Manager ermöglichte lokalen Benutzern, beliebigen Code über eine speziell präparierte Nachricht auszuführen, was Shatter-Angriff-Ausnutzung demonstrierte.
CVE-2019-1388 — Windows UAC Privilegieneskalation durch UI-Manipulation, die Angreifern ermöglichte, erhöhte Prozesse durch Dialog-Interaktion zu starten.

Referenzen

MITRE Corporation. "CWE-360: Trust of System Event Data." https://cwe.mitre.org/data/definitions/360.html
Akamai. "Teaching an Old Framework New Tricks: The Dangers of Windows UI Automation." Dezember 2024. https://www.akamai.com/blog/security-research/2024-december-windows-ui-automation-attack-technique-evades-edr
Chris Paget. "Exploiting design flaws in the Win32 API for privilege escalation - Shatter Attacks." August 2002. https://www.helpnetsecurity.com/2002/08/08/exploiting-design-flaws-in-the-win32-api-for-privilege-escalation-shatter-attacks-how-to-break-windows/
SRLabs. "When your phone gets sick: FluBot abuses Accessibility features to steal data." https://www.srlabs.de/blog-post/flubot-abuses-accessibility-features-to-steal-data