Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Einreichen
ToolsExploitsBlog
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
FRAGNESIA-Charan-cve-2026-46300 — Gehärtetes Container-Staging-Framework mit seccomp-Syscall-Whitelisting und eBPF-Telemetrie, um Container-Escape- und Kernel-ULP-Korruptionsversuche zu erkennen und zu blockieren. | Kitploit
Tools/GitHubGitHub/azdevops143/fragnesia-charan-cve-2026-46300
Container-SicherheitSchwachstellenanalyseExploitationCloud-SicherheitEinbruchserkennungLernen & Bildung
GitHubazdevops143/fragnesia-charan-cve-2026-46300

FRAGNESIA-Charan-cve-2026-46300

Gehärtetes Container-Staging-Framework mit seccomp-Syscall-Whitelisting und eBPF-Telemetrie, um Container-Escape- und Kernel-ULP-Korruptionsversuche zu erkennen und zu blockieren.

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen
Repository anzeigen
14vor 3 MonatenNoch nicht geprüft

Charantej Architecture: Hardened Container Staging & Syscall Telemetry Lab

Ein unternehmensgerechtes, mehrschichtiges Framework zur Container-Eindämmung und Laufzeitsicherheits-Telemetrie. Entworfen aus der Perspektive eines Cisco Lead Cybersecurity Architects, isoliert die Charantej-Architektur Staging-Laufzeiten, schränkt Systemaufrufsflächen ein und instrumentiert Echtzeit-Kernel-Telemetrie mittels Host-Level-Auditing, um moderne Linux-Containerbereitstellungen abzusichern.


High-Level Design (HLD)

Die Charantej-Architektur erzwingt Isolation, Least-Privilege-Eindämmung und Out-of-Band-Überwachung, um sicherzustellen, dass Sicherheitsgrenzen widerstandsfähig gegen Kompromittierungsvektoren des Host-Kernels bleiben.

flowchart TD
    subgraph HostOS ["Host OS (Secured Linux Node)"]
        subgraph Docker ["Docker Container Runtime"]
            App["Audited App Namespace"]
        end
        
        subgraph Auditor ["Host Auditor (Falco Engine)"]
            eBPF["eBPF Probes"]
        end
        
        Kernel["Host Linux Kernel"]
    end
    
    SIEM["SIEM / Log Repository"]

    App -->|System Calls| Kernel
    Kernel -->|Trace Events| eBPF
    eBPF --> Auditor
    Auditor -->|Telemetry Logs| SIEM
    
    style HostOS fill:#1e1e1e,stroke:#333,stroke-width:2px
    style Docker fill:#2a2a2a,stroke:#007bff,stroke-width:2px
    style Auditor fill:#2a2a2a,stroke:#dc3545,stroke-width:2px
    style Kernel fill:#333,stroke:#ffc107,stroke-width:2px
    style SIEM fill:#1e1e1e,stroke:#28a745,stroke-width:2px,stroke-dasharray: 5 5

Trust Boundaries

  1. Container Runtime Sandbox: Der Container-Namespace läuft strikt als nicht-privilegierter Benutzer und entzieht alle Standard-Linux-Fähigkeiten (CAP_SYS_ADMIN, CAP_NET_ADMIN, CAP_NET_RAW, usw.), um systemnahe Netzwerkmanipulationen zu blockieren.
  2. Syscall-Whitelisting: Ein benutzerdefiniertes Secure Computing Mode (seccomp)-Profil fungiert als Gatekeeper zwischen containerisierten Prozessen und dem Host-Kernel und verhindert den Zugriff auf gefährliche Systemaufrufe für Sockets oder Namespace-Änderungen.
  3. Out-of-Band-Instrumentierung: Die Ereignisüberwachung wird out-of-band auf Host-Ebene über eBPF-Tracing-Proben durchgeführt. Dadurch wird sichergestellt, dass selbst bei Kompromittierung der Container-Laufzeit die Telemetrieprotokollierung nicht aus dem Container-Kontext heraus manipuliert oder deaktiviert werden kann.

Low-Level Design (LLD)

Das Low-Level Design definiert die operative Syscall-Validierungslogik, Filterpfade und Überwachungsendpunkte innerhalb der Kernel-Grenze.

flowchart TD
    subgraph ContainerSpace ["Container Namespace (User Space)"]
        App["Audited Process"]
    end

    subgraph SeccompBoundary ["Seccomp Syscall Filter Boundary"]
        Syscall["Syscall Invocation"]
        Filter{"Syscall in Whitelist?"}
        Block["SCMP_ACT_ERRNO (Block & Fail)"]
        Allow["Allow & Pass"]
    end

    subgraph KernelSpace ["Linux Host Kernel Space"]
        Handler["System Call Handler"]
        Subsystem["Target Subsystem (e.g., Network/Memory)"]
    end

    subgraph TelemetryLayer ["Host Auditing Layer"]
        eBPF["eBPF Probe Instrumentation"]
        Falco{"Event Matches Rule?"}
        Alert["Log syslog / SIEM Alarm"]
    end

    App -->|1. Invokes Syscall| Syscall
    Syscall --> Filter
    Filter -->|No: e.g., setsockopt/socket| Block
    Filter -->|Yes: e.g., read/write| Allow
    Allow --> Handler
    Handler --> Subsystem
    Handler -->|2. Traces Execution| eBPF
    eBPF --> Falco
    Falco -->|Yes| Alert

Die Charantej-Architektur besteht aus drei miteinander verbundenen Konfigurationsschichten, um Sicherheitsgrenzen durchzusetzen.

1. Hardened Container Staging (Container Runtime)

Die Orchestrierungskonfiguration implementiert die folgenden Sicherheitskontrollen direkt über Laufzeit-Flags:

  • --cap-drop=ALL: Entzieht alle Standard-Linux-Kernel-Fähigkeiten und verhindert so, dass der Container administrative Low-Level-Berechtigungen erlangt.
  • --security-opt no-new-privileges:true: Verhindert, dass Kindprozesse mehr Rechte erlangen als ihr Elternprozess, indem setuid- oder setgid-Binaries blockiert werden.
  • --security-opt seccomp=seccomp-profile.json: Implementiert eine Whitelist-basierte Systemaufruffilterung.

2. Syscall Whitelist Gatekeeper (seccomp-profile.json)

Standardmäßig erlaubt der Docker-seccomp-Filter eine breite Liste von Systemaufrufen. Die Charantej-Architektur beschränkt dies auf das absolute Minimum, das für die grundlegende Prozessausführung erforderlich ist:

  • Standardaktion (SCMP_ACT_ERRNO): Blockiert alle Systemaufrufe, sofern sie nicht explizit im Profil auf die Whitelist gesetzt sind.
  • Erlaubte Syscalls: Erlaubt nur grundlegende Betriebsprimitive (wie read, write, exit, exit_group, futex, nanosleep, mmap, munmap, mprotect und close).
  • Blockierte Vektoren: Blockiert explizit socket-Manipulationen, setsockopt-Netzwerkänderungen, Namespace-Beitritte (setns) und Fähigkeitssätze (capset), wodurch unbefugte lokale Privilegieneskalationsversuche (LPE) neutralisiert werden.

3. eBPF Telemetry Tracing (Conceptual)

Host-Level-Tracing-Regeln überwachen konzeptionell Prozess- und Syscall-Grenzen:

  • Det_Anomalous_Networking: Prüft Socket-Optionen und löst einen sofortigen CRITICAL ALARM aus, wenn ein containerisierter Prozess versucht, Protokolle höherer Schichten oder ULP-Eigenschaften zu ändern (TCP_ULP optname).
  • Container_Privilege_Escalation_Attempt: Alarmiert bei unbefugten Versuchen, Namespaces zu betreten (setns) oder Fähigkeitssätze zu ändern (capset).

Live Exploit Demonstration (CVE-2026-46300 "Fragnesia")

Dieses Repository enthält eine Live-Exploit-Simulation für CVE-2026-46300, um die Wirksamkeit der Charantej-Architektur praktisch zu demonstrieren. Der Exploit versucht zwei Vektoren:

  1. Namespace Escape: Versucht, den Host-Mount-Namespace mittels setns() zu kapern.
  2. Kernel ULP Corruption: Versucht eine unbefugte ULP-Speichermanipulation über setsockopt(TCP_ULP).

Ausführen des Exploit-Tests

Ein Hilfsskript wird bereitgestellt, um den Exploit automatisch zu bauen und gegen einen ungeschützten Container (der ein verwundbares System darstellt) und den Charantej-gesicherten Container auszuführen.

  1. Stellen Sie sicher, dass Docker läuft.
  2. Führen Sie das Testskript aus:
    bash run_exploit.sh
    

Erwartete Ergebnisse

1. Ungeschützte Umgebung (Exploit-Phase)

Der Exploit wird erfolgreich sowohl setns() als auch setsockopt() ausführen und einen Status "VULNERABLE" melden.

sequenceDiagram
    participant App as Unprivileged App (Fragnesia Payload)
    participant Cap as Capability Check (Kernel)
    participant NS as /proc/self/ns/mnt (Host Namespace)
    participant Sys as Syscall Interface
    participant ULP as Kernel ULP Memory

    Note over App,ULP: STAGE 1: Namespace Hijacking
    App->>Cap: 1. setns(FD, 0)
    Cap-->>App: Allowed (No cap_drop)
    App->>NS: Hijack Host Namespace
    NS-->>App: SUCCESS: Container Isolation Bypassed

    Note over App,ULP: STAGE 2: ULP Memory Corruption (CVE-2026-46300)
    App->>Sys: 2. socket(AF_INET, SOCK_STREAM, 0)
    Sys-->>App: FD allocated
    
    App->>ULP: 3. setsockopt(FD, IPPROTO_TCP, TCP_ULP, "tls")
    Note right of ULP: Attempts unauthorized memory modification
    ULP-->>App: SUCCESS: Malicious payload injected
    Note over App,ULP: IMPACT: Host Kernel Memory Compromised!
Tool herunterladen