Privileg mit unsicheren Aktionen definiert

Beschreibung

Privileg mit unsicheren Aktionen definiert ist eine Schwachstelle, die auftritt, wenn ein bestimmtes Privileg, eine Rolle, eine Fähigkeit oder ein Recht Aktionen ermöglicht, die nicht über dieses Privileg zugänglich sein sollten, selbst wenn es der entsprechenden Entität korrekt zugewiesen ist. Das Problem liegt nicht darin, wer das Privileg hat, sondern darin, was das Privileg zu tun erlaubt. Dies kann auftreten, wenn Rollendefinitionen zu breit sind, wenn Privilegien ohne Berücksichtigung aller möglichen Aktionen, die sie ermöglichen, entworfen werden, oder wenn Systemfähigkeiten unbeabsichtigte Nebeneffekte haben, die über ihren primären Zweck hinausgehen. Das Ergebnis ist, dass legitim autorisierte Benutzer Aktionen ausführen können, die Sicherheitsrichtlinien verletzen oder die Systemintegrität gefährden.

Risiko

Privilegien mit unsicheren Aktionen erzeugen systemische Sicherheitsrisiken, da die Schwachstelle in der Privilegiendefinition selbst liegt, nicht in ihrer Zuweisung. Jeder Benutzer mit dem Privileg kann unbeabsichtigte Aktionen ausführen, was die potenzielle Auswirkung verstärkt. Debug-Privilegien, die Speicherinspektion erlauben, können Passwortextraktion ermöglichen. Datenbankrollen, die Zugang zu Stored Procedures gewähren, können Datenmodifikation über den beabsichtigten Umfang hinaus ermöglichen. Administrative Tools mit übermäßig breiten Fähigkeiten können Benutzern erlauben, ihre eigenen Privilegien zu eskalieren. Das Risiko ist besonders schwer in Systemen mit zahlreichen Benutzern, die das betroffene Privileg halten, da jeder einen potenziellen Vektor für Missbrauch darstellt. Zusätzlich bleiben diese Schwachstellen oft unentdeckt, weil das Privileg wie beabsichtigt zu funktionieren scheint.

Lösung

Entwerfen Sie Privilegien nach dem Prinzip der geringsten Privilegien und analysieren Sie sorgfältig alle Aktionen, die jedes Privileg ermöglicht. Führen Sie Privilegienauswirkungs-Analysen vor dem Deployment durch, um unbeabsichtigte Fähigkeiten zu identifizieren. Trennen Sie gefährliche Aktionen in separate, restriktivere Privilegien, anstatt sie mit gängigen Operationen zu bündeln. Implementieren Sie Defense in Depth, wobei sensible Aktionen mehrere Privilegien oder zusätzliche Autorisierung erfordern. Überprüfen und verfeinern Sie Privilegiendefinitionen regelmäßig, wenn sich Systemfähigkeiten entwickeln. Dokumentieren Sie den beabsichtigten Umfang jedes Privilegs und implementieren Sie technische Kontrollen, um diese Grenzen durchzusetzen. Verwenden Sie fähigkeitsbasierte Sicherheitsmodelle wo möglich, um feingranulare Kontrolle über Aktionen zu bieten. Testen Sie Privilegiendefinitionen, indem Sie versuchen, unbefugte Aktionen mit jeder Rolle auszuführen.

Häufige Auswirkungen

Auswirkung	Details
Zugriffskontrolle	Bereich: Zugriffskontrolle Benutzer mit korrekt zugewiesenen Privilegien können auf eingeschränkte Funktionalität und sensible Informationen über den beabsichtigten Umfang hinaus zugreifen. Dies kann administrative Fähigkeiten, Modifikation geschützter Daten oder Zugang zu Konten anderer Benutzer durch unbeabsichtigte Nebeneffekte des gewährten Privilegs umfassen.

Beispielcode

Anfälliger Code (SQL/Datenbank)

Die folgenden Beispiele demonstrieren Privilegien mit unbeabsichtigten gefährlichen Fähigkeiten:

-- Anfällig: Rolle mit Zugang zu gefährlichen Stored Procedures
CREATE ROLE data_analyst;

-- Beabsichtigt: Analysten erlauben, Daten abzufragen
GRANT SELECT ON ALL TABLES IN SCHEMA public TO data_analyst;

-- Anfällig: Gewährt Zugang zu allen Prozeduren einschließlich gefährlicher
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO data_analyst;

-- Diese Prozedur existiert für Admins, ist aber jetzt für Analysten zugänglich
CREATE OR REPLACE FUNCTION change_user_password(
    target_user TEXT,
    new_password TEXT
) RETURNS VOID AS $$
BEGIN
    UPDATE users SET password_hash = crypt(new_password, gen_salt('bf'))
    WHERE username = target_user;
END;
$$ LANGUAGE plpgsql;

-- Analysten können jetzt das Passwort JEDES Benutzers ändern!
-- SELECT change_user_password('admin', 'gehackt');

# Anfällig: Debug-Privileg erlaubt übermäßigen Zugang
class VulnerablePrivilegeSystem:

    def check_permission(self, user, action, resource):
        # Debug-Rolle für Fehlerbehebung gedacht
        if 'debug' in user.roles:
            # Anfällig: Debug-Zugang umfasst gefährliche Fähigkeiten
            if action in ['read_logs', 'view_config', 'inspect_memory',
                         'read_environment', 'view_passwords',  # Gefährlich!
                         'modify_audit_log']:  # Sehr gefährlich!
                return True

        # Standard-Berechtigungsprüfung
        return self.standard_check(user, action, resource)


class VulnerableAdminPanel:

    def __init__(self, user):
        self.user = user

    def process_action(self, action, params):
        # Nicht-Root-Admin-Rolle für Benutzerverwaltung gedacht
        if 'non_root_admin' in self.user.roles:
            # Anfällig: Kann sich selbst zur Root-Gruppe hinzufügen!
            if action == 'modify_user_groups':
                user_to_modify = get_user(params['user_id'])
                new_groups = params['groups']
                # Keine Prüfung, die Selbstbeförderung zu Root verhindert
                user_to_modify.groups = new_groups
                user_to_modify.save()
                return True

// Anfällig: Traceroute-Privileg erlaubt Paketmodifikation
public class VulnerableNetworkDiagnostics {

    public void executeTraceroute(User user, String destination) {
        if (user.hasPrivilege("network_diagnostics")) {
            // Beabsichtigt: Traceroute für Fehlerbehebung erlauben

            // Anfällig: Privileg erlaubt auch Modifikation der Paketquelle!
            // Benutzer kann Pakete fälschen, die von jeder IP zu kommen scheinen
            PacketBuilder builder = new PacketBuilder();
            builder.setDestination(destination);

            // Dies sollte ein separates, restriktiveres Privileg erfordern
            builder.setSourceAddress(user.getRequestedSourceIP());

            sendPacket(builder.build());
        }
    }
}

Korrigierter Code (SQL/Datenbank)

-- Korrigiert: Separate Privilegien für verschiedene Fähigkeitsstufen
CREATE ROLE data_analyst;
CREATE ROLE user_manager;
CREATE ROLE password_admin;

-- Analysten: Nur-Lese-Zugang nur zu Datentabellen
GRANT SELECT ON ALL TABLES IN SCHEMA public TO data_analyst;
REVOKE ALL ON ALL FUNCTIONS IN SCHEMA public FROM data_analyst;

-- Nur spezifische sichere Funktionen für Analysten gewähren
GRANT EXECUTE ON FUNCTION generate_report TO data_analyst;
GRANT EXECUTE ON FUNCTION run_analysis TO data_analyst;

-- Gefährliche Funktionen erfordern spezifische erhöhte Rolle
GRANT EXECUTE ON FUNCTION change_user_password TO password_admin;

-- Benutzermanager können Passwörter nicht ändern, nur Benutzer-Metadaten
GRANT UPDATE(email, full_name, department) ON users TO user_manager;

-- Passwortänderungen erfordern password_admin UND können nicht eigenes Passwort ändern
CREATE OR REPLACE FUNCTION change_user_password_safe(
    target_user TEXT,
    new_password TEXT
) RETURNS VOID AS $$
DECLARE
    current_user_name TEXT;
BEGIN
    -- Aktuellen Session-Benutzer holen
    SELECT session_user INTO current_user_name;

    -- Kann eigenes Passwort nicht über diese Funktion ändern
    IF current_user_name = target_user THEN
        RAISE EXCEPTION 'Kann eigenes Passwort nicht über Admin-Funktion ändern';
    END IF;

    -- password_admin-Rolle erforderlich
    IF NOT pg_has_role(current_user_name, 'password_admin', 'MEMBER') THEN
        RAISE EXCEPTION 'Unzureichende Privilegien für Passwortänderung';
    END IF;

    UPDATE users SET password_hash = crypt(new_password, gen_salt('bf'))
    WHERE username = target_user;

    -- Audit-Log
    INSERT INTO audit_log (action, target, performed_by, timestamp)
    VALUES ('password_change', target_user, current_user_name, NOW());
END;
$$ LANGUAGE plpgsql SECURITY DEFINER;

# Korrigiert: Granulare Privilegien mit expliziten Fähigkeitsgrenzen
class SecurePrivilegeSystem:

    # Explizite Fähigkeitssätze für jede Rolle definieren
    ROLE_CAPABILITIES = {
        'debug': {
            'read_logs',
            'view_config',
            'inspect_request_state',  # Begrenzte Inspektion
            # Entfernt: 'inspect_memory', 'view_passwords', 'modify_audit_log'
        },
        'security_auditor': {
            'read_audit_log',
            'view_security_events',
            # Kann Audit-Log nicht ändern
        },
        'password_admin': {
            'reset_user_password',
            'force_password_change',
            # Kann eigenes Passwort nicht zurücksetzen
        }
    }

    # Aktionen, die mehrere Rollen oder zusätzliche Prüfungen erfordern
    PRIVILEGED_ACTIONS = {
        'view_passwords': {'required_roles': ['security_admin', 'emergency_access']},
        'modify_audit_log': {'required_roles': None},  # Nie erlaubt
        'inspect_memory': {'required_roles': ['kernel_debug'], 'mfa_required': True}
    }

    def check_permission(self, user, action, resource):
        # Prüfen, ob Aktion privilegiert ist
        if action in self.PRIVILEGED_ACTIONS:
            config = self.PRIVILEGED_ACTIONS[action]
            if config['required_roles'] is None:
                return False  # Aktion ist verboten

            # Alle spezifizierten Rollen erforderlich
            if not all(role in user.roles for role in config['required_roles']):
                return False

            # Zusätzliche MFA-Prüfung wenn erforderlich
            if config.get('mfa_required') and not user.mfa_verified:
                return False

        # Standard-Rollenfähigkeitsprüfung
        for role in user.roles:
            if role in self.ROLE_CAPABILITIES:
                if action in self.ROLE_CAPABILITIES[role]:
                    return True

        return False


class SecureAdminPanel:

    PROTECTED_GROUPS = {'root', 'wheel', 'admin', 'domain_admins'}

    def modify_user_groups(self, admin_user, target_user_id, new_groups):
        target_user = get_user(target_user_id)

        # Kann eigene Gruppen nicht ändern
        if admin_user.id == target_user.id:
            raise PermissionError("Kann eigene Gruppenmitgliedschaft nicht ändern")

        # Auf geschützte Gruppen-Hinzufügungen prüfen
        adding_protected = set(new_groups) & self.PROTECTED_GROUPS
        if adding_protected:
            if not admin_user.has_privilege('add_protected_groups'):
                raise PermissionError(
                    f"Kann Benutzer nicht zu geschützten Gruppen hinzufügen: {adding_protected}"
                )

        # Modifikation durchführen
        target_user.groups = new_groups
        target_user.save()

        # Audit
        self.audit_log.record('group_modification', admin_user, target_user, new_groups)

Die Korrektur trennt gefährliche Fähigkeiten in separate Privilegien, implementiert explizite Fähigkeitsgrenzen, verhindert Selbstbeförderung und erfordert zusätzliche Autorisierung für sensible Aktionen.

---

Ausgenutzt in der Praxis

Datenbank-Stored-Procedure-Missbrauch (Mehrere Organisationen, Fortlaufend)

Datenbankrollen mit pauschalen "EXECUTE"-Berechtigungen auf Stored Procedures haben Privilegieneskalation ermöglicht, wenn administrative Prozeduren versehentlich zugänglich gemacht wurden. Angreifer mit Nur-Lese-Analysten-Rollen haben Daten modifiziert, Passwörter geändert und Privilegien durch für Administratoren gedachte Stored Procedures eskaliert.

• https://www.sqlinjection.net/

Unix-Debug-Privilegien führen zu Root (Verschiedene Systeme, Historisch)

Debug-Privilegien auf Unix-Systemen erlaubten historisch das Lesen von Prozessspeicher, was Passwörter und Verschlüsselungsschlüssel einschließen könnte. Benutzer mit für Fehlerbehebung gedachten Debug-Rechten könnten Anmeldedaten aus laufenden Prozessen extrahieren und zu Root-Zugang eskalieren.

• https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/

Cloud IAM überprivilegierte Rollen (AWS/Azure/GCP, Fortlaufend)

Cloud-IAM-Rollen mit übermäßig breiten Berechtigungen (wie *:* Wildcards oder PowerUser-Zugang) haben Benutzern ermöglicht, unbeabsichtigte Aktionen auszuführen, einschließlich der Erstellung neuer Admin-Benutzer, Modifikation von IAM-Richtlinien und Zugriff auf Ressourcen über Konten hinweg. Sicherheitsforscher identifizieren regelmäßig überprivilegierte Standardrollen in Cloud-Diensten.

• https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/

---

Tools zum Testen/Ausnutzen

• Pacu — AWS-Ausnutzungs-Framework, das überprivilegierte IAM-Rollen identifiziert und auf unbeabsichtigte Fähigkeiten testet.

• ScoutSuite — Multi-Cloud-Sicherheitsaudit-Tool, das übermäßig permissive Rollendefinitionen identifiziert.

• PowerView — Active-Directory-Enumerationstool zur Identifizierung von Privilegiendefinitionsschwächen.

---

CVE-Beispiele

• CVE-2002-1981 — Rolle gewährte Zugang zu gefährlichen Datenbankprozeduren über den beabsichtigten Umfang hinaus.

• CVE-2005-1816 — Nicht-Root-Administratoren könnten sich selbst zur Root-Gruppe hinzufügen.

• CVE-2001-1166 — Debug-Privileg erlaubte das Lesen des gesamten Prozessspeichers einschließlich Anmeldedaten.

• CVE-2000-0315 — Unprivilegierte Benutzer könnten Paketquelladressen durch Diagnosetools modifizieren.

---

Referenzen

1. MITRE Corporation. "CWE-267: Privilege Defined With Unsafe Actions." Common Weakness Enumeration. https://cwe.mitre.org/data/definitions/267.html

2. OWASP Foundation. "Broken Access Control." OWASP Top 10. https://owasp.org/Top10/A01_2021-Broken_Access_Control/

3. NIST. "Role-Based Access Control." NIST RBAC. https://csrc.nist.gov/projects/role-based-access-control