Offenlegung von Zugriffskontrolllisten-Dateien für unbefugte Kontrollsphäre

Beschreibung

Offenlegung von Zugriffskontrolllisten-Dateien für unbefugte Kontrollsphäre ist eine Schwachstelle, bei der ein Produkt Zugriffskontrolllisten-Dateien (ACL) in einem Verzeichnis oder anderen Container speichert, der für Akteure außerhalb der beabsichtigten Kontrollsphäre zugänglich ist. ACL-Dateien definieren Berechtigungen und Zugriffsrechte für Systemressourcen, Benutzer und Anwendungen. Wenn diese Dateien für unbefugte Parteien offengelegt werden, können Angreifer detaillierte Kenntnisse über Sicherheitskonfigurationen erlangen, Schwachstellen in Zugriffskontrollrichtlinien identifizieren, vertrauenswürdige Systeme und Konten entdecken und möglicherweise die ACLs modifizieren, um sich selbst unbefugten Zugriff zu gewähren.

Risiko

Offengelegte ACL-Dateien bieten Angreifern eine Landkarte der Sicherheitsarchitektur. Das Wissen darüber, welche Benutzer administrativen Zugriff haben, hilft bei der Identifizierung hochwertiger Ziele für eine Kompromittierung. Das Verständnis von Berechtigungsstrukturen enthüllt Wege zur Privilegieneskalation. Die Identifikation vertrauenswürdiger IP-Adressen oder Systeme ermöglicht Angreifern, vertrauenswürdige Quellen zu fälschen oder das Angreifen dieser Systeme zu priorisieren. Wenn ACL-Dateien nicht nur lesbar, sondern auch schreibbar sind, können Angreifer Berechtigungen direkt modifizieren, um sich selbst Zugriff zu gewähren. Selbst die reine Lese-Offenlegung ermöglicht Aufklärung, die den für erfolgreiche Angriffe erforderlichen Aufwand dramatisch reduziert.

Lösung

Speichern Sie ACL-Dateien in Verzeichnissen mit eingeschränkten Zugriffsberechtigungen, die Lese- und Schreibzugriff nur auf autorisierte Systemadministratoren beschränken. Verwenden Sie Betriebssystem-Dateiberechtigungen zum Schutz von ACL-Dateien. Vermeiden Sie das Speichern von ACL-Dateien in web-zugänglichen Verzeichnissen. Implementieren Sie Überwachung und Alarmierung für Zugriffe auf ACL-Dateien. Verwenden Sie Versionskontrolle für ACL-Änderungen mit angemessenen Zugriffskontrollen. Erwägen Sie die Verschlüsselung von ACL-Dateien im Ruhezustand. Prüfen Sie regelmäßig Dateiberechtigungen für sicherheitsrelevante Konfigurationsdateien. Implementieren Sie das Prinzip der geringsten Privilegien für Prozesse, die ACL-Konfigurationen lesen müssen.

Häufige Auswirkungen

AuswirkungDetails
VertraulichkeitBereich: Vertraulichkeit

Anwendungsdaten lesen - Angreifer können ACL-Dateien lesen, um Berechtigungsstrukturen zu verstehen, administrative Konten zu identifizieren und vertrauenswürdige Systeme zu entdecken.
ZugriffskontrolleBereich: Zugriffskontrolle

Schutzmechanismus umgehen - Kenntnis von Zugriffskontrollkonfigurationen ermöglicht Angreifern, Schwachstellen in Sicherheitsrichtlinien zu identifizieren und auszunutzen oder Kontrollen durch Angriff auf vertrauenswürdige Systeme zu umgehen.

Beispielcode

Verwundbare Konfiguration

# Verwundbar: ACL-Dateien in von allen lesbarem Verzeichnis
$ ls -la /var/www/html/config/
-rw-r--r-- 1 www-data www-data 1024 Jan 15 10:00 acl.conf
-rw-r--r-- 1 www-data www-data 2048 Jan 15 10:00 permissions.xml
-rw-r--r-- 1 www-data www-data  512 Jan 15 10:00 .htaccess
-rw-r--r-- 1 www-data www-data 4096 Jan 15 10:00 users_roles.json

# Alle diese Dateien sind von allen lesbar und web-zugänglich!
# Angreifer kann herunterladen über:
# http://example.com/config/acl.conf
# http://example.com/config/permissions.xml
<!-- Verwundbar: ACL-Datei im Webroot offengelegt -->
<!-- /var/www/html/config/permissions.xml -->
<?xml version="1.0"?>
<access-control>
  <roles>
    <role name="admin" level="100">
      <users>
        <user>john.admin</user>
        <user>mary.sysadmin</user>
        <user>backup_service</user>  <!-- Dienstkonto offengelegt -->
      </users>
      <permissions>
        <permission>read</permission>
        <permission>write</permission>
        <permission>delete</permission>
        <permission>admin</permission>
      </permissions>
    </role>
    <role name="api_access" level="50">
      <trusted_ips>
        <ip>10.0.0.100</ip>        <!-- Interne Server-IPs offengelegt -->
        <ip>10.0.0.101</ip>
        <ip>192.168.1.50</ip>
      </trusted_ips>
    </role>
  </roles>
</access-control>
// Verwundbar: Benutzerrollen-Datei über Web zugänglich
// /var/www/html/data/users_roles.json
{
  "admin_users": [
    {"username": "admin", "password_hint": "Firmenname + Jahr"},
    {"username": "superuser", "email": "[email protected]"},
    {"username": "backup_admin", "service_account": true}
  ],
  "api_keys": {
    "internal_api": "allowed_from: 10.0.0.0/8",
    "partner_api": "allowed_from: 203.0.113.0/24"
  },
  "bypass_rules": [
    {"path": "/admin/*", "allowed_ips": ["10.0.0.1", "192.168.1.1"]},
    {"path": "/api/internal/*", "no_auth_required": true}
  ]
}
<?php
// Verwundbar: PHP-Anwendung mit offengelegtem ACL-Pfad
class VulnerableAuthManager {
    // Verwundbar: ACL-Datei im Webroot
    private $aclFile = '/var/www/html/config/acl.php';

    // Verwundbar: Datei als PHP-Quellcode lesbar
    public function loadAcl() {
        include($this->aclFile);
        return $acl;
    }
}

// /var/www/html/config/acl.php - direkt zugänglich!
$acl = [
    'admin' => ['admin_user', 'superuser', 'root'],
    'moderator' => ['mod1', 'mod2'],
    'api_whitelist' => ['10.0.0.50', '10.0.0.51'],
    'bypass_auth' => ['/api/health', '/api/status'],
];

Behobene Konfiguration

# Behoben: ACL-Dateien mit eingeschränkten Berechtigungen
$ ls -la /etc/myapp/
drwx------ 2 root root 4096 Jan 15 10:00 .
-rw------- 1 root root 1024 Jan 15 10:00 acl.conf
-rw------- 1 root root 2048 Jan 15 10:00 permissions.xml
-rw------- 1 root root 4096 Jan 15 10:00 users_roles.json

# Behoben: Dateien nur von root lesbar
# Anwendung läuft mit Berechtigung, bestimmte Dateien zu lesen
# Behoben: Ordnungsgemäße Berechtigungen setzen
#!/bin/bash

# Behoben: Sicheres Verzeichnis für ACL-Dateien erstellen
mkdir -p /etc/myapp/acl
chown root:myapp-group /etc/myapp/acl
chmod 750 /etc/myapp/acl

# Behoben: Einzelne Dateien absichern
chmod 640 /etc/myapp/acl/*.conf
chown root:myapp-group /etc/myapp/acl/*.conf

# Behoben: SELinux-Kontext (falls zutreffend)
semanage fcontext -a -t etc_t '/etc/myapp/acl(/.*)?'
restorecon -R /etc/myapp/acl
# Behoben: Apache blockiert Zugriff auf Konfigurationsdateien
<VirtualHost *:80>
    DocumentRoot /var/www/html

    # Behoben: Alle Config-Verzeichnisse blockieren
    <DirectoryMatch "^.*/config">
        Require all denied
    </DirectoryMatch>

    # Behoben: Bestimmte Dateimuster blockieren
    <FilesMatch "\.(conf|xml|json|yml|yaml|ini)$">
        Require all denied
    </FilesMatch>

    # Behoben: .htaccess vom Download blockieren
    <Files ".htaccess">
        Require all denied
    </Files>

    # Behoben: ACL-bezogene Dateien blockieren
    <FilesMatch "(acl|permissions|roles|access)">
        Require all denied
    </FilesMatch>
</VirtualHost>
# Behoben: Nginx blockiert Konfigurationsdateien
server {
    listen 80;
    root /var/www/html;

    # Behoben: Config-Verzeichnisse blockieren
    location ~ /config/ {
        deny all;
        return 404;
    }

    # Behoben: Konfigurationsdatei-Erweiterungen blockieren
    location ~* \.(conf|xml|json|yml|yaml|ini)$ {
        deny all;
        return 404;
    }

    # Behoben: ACL-bezogene Dateien blockieren
    location ~* (acl|permissions|roles|access)\.(php|conf|json|xml)$ {
        deny all;
        return 404;
    }
}
# Behoben: Python-Anwendung mit sicherer ACL-Handhabung
import os
import stat
import json

class SecureACLManager:
    # Behoben: ACL außerhalb von Web-Verzeichnissen
    ACL_PATH = '/etc/myapp/acl/permissions.json'

    def __init__(self):
        self._verify_acl_permissions()

    def _verify_acl_permissions(self):
        """Verifiziert, dass ACL-Datei sichere Berechtigungen hat."""
        if not os.path.exists(self.ACL_PATH):
            raise FileNotFoundError("ACL-Datei nicht gefunden")

        # Behoben: Dateiberechtigungen prüfen
        mode = os.stat(self.ACL_PATH).st_mode

        # Von allen lesbar?
        if mode & stat.S_IROTH:
            raise SecurityError("ACL-Datei ist von allen lesbar")

        # Von allen schreibbar?
        if mode & stat.S_IWOTH:
            raise SecurityError("ACL-Datei ist von allen schreibbar")

        # Gruppenschreibbar?
        if mode & stat.S_IWGRP:
            raise SecurityError("ACL-Datei ist gruppenschreibbar")

    def load_acl(self):
        """ACL von sicherem Speicherort laden."""
        self._verify_acl_permissions()

        with open(self.ACL_PATH, 'r') as f:
            acl = json.load(f)

        # Behoben: ACL-Zugriff für Audit protokollieren
        self._audit_log("ACL geladen von Prozess " + str(os.getpid()))

        return acl

    def _audit_log(self, message):
        """Sicherheitsrelevante Ereignisse protokollieren."""
        import syslog
        syslog.syslog(syslog.LOG_AUTH | syslog.LOG_INFO, message)

CVE-Beispiele

Keine spezifischen CVEs sind in der MITRE-Datenbank für dieses CWE gelistet. Das Schwachstellenmuster ist jedoch häufig in:

  • Webanwendungs-Fehlkonfigurationen
  • Cloud-Speicher-Berechtigungsproblemen
  • Server-Härtungsfehlern

Referenzen

  1. MITRE. "CWE-529: Exposure of Access Control List Files to an Unauthorized Control Sphere." https://cwe.mitre.org/data/definitions/529.html

  2. OWASP. "Security Misconfiguration."

  3. CIS Benchmarks. "File System Permissions."