CVE-2026-56423 — MISP deleteSelection Fehlerhafte Zugriffskontrolle

Proof of Concept für eine fehlende Autorisierungsschwachstelle in MISPs Massenlöschungsvorgängen für Event Reports und Sharing Groups. Die deleteSelection-Handler autorisieren jedes ausgewählte Element mit einem Callback, der das Element ignoriert und stattdessen die globale Rollenberechtigung des Aufrufers (perm_add / perm_sharing_group) zurückgibt, anstatt eine pro-Objekt-Eigentümerprüfung durchzuführen. Ein Beitragender mit niedrigen Berechtigungen (die Standardrolle "User") kann daher Berichts-IDs/UUIDs einreichen, die einer beliebigen Organisation gehören, und sie instanzweit hart löschen, obwohl die korrekt geschützte pro-Objekt-delete-Aktion genau dieselbe Anfrage ablehnt.

Ursache

app/Controller/EventReportsController.php (Tag v2.5.40):

public function deleteSelection($id = null)
{
    return $this->CRUD->deleteSelection($id, [
        'modelName' => 'EventReport',
        ...
        'checkModifyCallback' => function($itemId) {
            return $this->userRole['perm_add'];   // ignoriert $itemId → globaler Rollen-Boolean
        },
    ]);
}

CRUDComponent::deleteSelection ruft diesen checkModifyCallback für jede ausgewählte ID auf und löscht das Objekt, wenn er true zurückgibt:

$canModify = call_user_func($options['checkModifyCallback'], $itemId, $item);
if (!$canModify) { $fails[] = $cid; continue; }
if ($Model->delete($itemId)) { $successes[] = $cid; }

Da der Callback $this->userRole['perm_add'] zurückgibt – ein globaler Boolean, der für die Standardrolle "User" true ist – wird der Besitz des Zielberichts nie überprüft. Im Gegensatz dazu ruft die Einzelobjekt-Aktion delete($id) korrekt EventReport::fetchIfAuthorized($this->Auth->user(), $id, 'delete') auf und lehnt fremde Berichte ab.

SharingGroupsController::deleteSelection hat denselben Fehler mit perm_sharing_group.

Der Fix in 2.5.42 (Commits ada02fa, f99b3f1) ersetzt den Callback durch eine pro-Element EventReport::fetchIfAuthorized($user, $itemId, 'delete').

Siehe ANALYSIS.md für den vollständigen Durchlauf.

Voraussetzungen (ehrlich dokumentiert)

1. Der Angreifer besitzt ein Konto, dessen Rolle perm_add hat – die eingebaute User-Rolle, die normalen Beitragenden auf Multi-Org-Instanzen gewährt wird.
2. MISP.enable_themes = true. Die Aktion deleteSelection ist in der ACL durch AND(theming_enabled, perm_add) geschützt, wobei theming_enabled auf die Einstellung MISP.enable_themes abgebildet wird. Diese Einstellung ist standardmäßig deaktiviert, aber ein normales UI-Feature-Flag, das auf vielen Instanzen aktiviert ist (es betreibt die v2-Index/Listen-UI). Wenn es deaktiviert ist, gibt die Aktion HTTP 403 zurück, bevor der fehlerhafte Callback ausgeführt wird.

Exploit

python3 exploit.py https://127.0.0.1:443 \
    --attacker-key <contributor_authkey> \
    --admin-key   <admin_authkey_used_only_to_confirm_the_target> \
    --report-id   <id_of_a_report_owned_by_another_org>

[1] contributor legit delete/2   -> HTTP 404  (DENIED (expected))
[2] contributor deleteSelection [2] -> HTTP 200  {"saved":true,"success":true,"name":"EventReport deleted."...}
[+] CONFIRMED: contributor hard-deleted another org's Event Report via deleteSelection

Reproduktion

cd lab
./setup.sh          # MISP core v2.5.40 + attacker org + contributor + victim report
source /tmp/misp_poc.env
python3 ../exploit.py https://127.0.0.1:443 \
    --attacker-key "$CONTRIB_KEY" --admin-key "$ADMIN_KEY" --report-id "$VICTIM_REPORT_ID"

# patched build denies the same request:
CORE_RUNNING_TAG=v2.5.42 ./setup.sh
./teardown.sh

Grenze VERWUNDBAR/BEHOBEN (empirisch)

Dieselbe Anfrage wechselt über den Fix von Erfolg zu Ablehnung, und das korrekt geschützte pro-Objekt-Löschen wird in beiden Fällen abgelehnt – was beweist, dass der Fehler die fehlende pro-Objekt-Autorisierung in deleteSelection ist, nicht ein falsch konfiguriertes Konto. Vollständiges Transkript in EVIDENCE.txt.

Auswirkungen

Jeder Benutzer mit niedrigen Berechtigungen auf einer gemeinsam genutzten MISP-Instanz kann unwiderruflich Event Reports – Analystenbeschreibungen, die an Threat-Intel-Ereignisse angehängt sind – und Sharing Groups, die anderen Organisationen gehören, instanzweit hart löschen. Dies ist ein mandantenübergreifender Integritäts-/Verfügbarkeitskompromiss einer Threat-Intelligence-Plattform, auf die CERTs, ISACs und SOCs angewiesen sind.

Abhilfe

• Aktualisieren Sie MISP auf 2.5.42 oder höher.
• Der Fix erzwingt EventReport::fetchIfAuthorized($user, $itemId, 'delete') pro ausgewähltem Element; dasselbe Muster wird auf Sharing Groups angewendet.

Erkennung

Überprüfen Sie MISP-Protokolle auf EventReports/deleteSelection- (und SharingGroups/deleteSelection-)Anfragen, bei denen die Organisation des handelnden Benutzers von der besitzenden Organisation des gelöschten Objekts abweicht.

Credits

Forschung und PoC von Caio Fabrício (@BiiTts).

Lizenz

MIT — siehe LICENSE.