nickstadb/pocRepo di exploit e strumenti di prova di concetto.
Repository di exploit proof of concept e strumenti.
Exploit di esecuzione remota di comandi non autenticato per l'agente RSCD di BMC Server Automation. L'exploit funziona contro i server affetti da CVE-2016-1542 (rilevato da Nessus).
Questo è ora un modulo Metasploit, vedi exploits/multi/misc/bmc_server_automation_rscd_nsh_rce
L'exploit è stato creato facendo sì che Nessus eseguisse la scansione di uno script Python che registrava i pacchetti e li rimandava/spediva a Nessus. Con i pacchetti catturati, il formato dei dati è stato banale da "reversare" per creare un exploit semi-funzionante. In seguito ho avuto accesso al software dell'agente interessato e sono riuscito a usare un debugger e un po' di fuzzing per risolvere i problemi e trasformarlo in un exploit RCE solido.
Dai un'occhiata ai miei post sul blog su come ho costruito l'exploit per maggiori dettagli:
Exploit di esecuzione remota di codice non autenticato per HP Device Manager versioni 5.0.0 - 5.0.3 (CVE-2020-6926, CVE-2020-6927).
L'exploit sfrutta un servizio Java RMI non autenticato che presenta una vulnerabilità di iniezione Hibernate Query Language. L'iniezione ORM viene utilizzata per introdurre un payload di SQL injection in Postgres e sovrascrivere il file pg_hba.conf sul server HP Device Manager, consentendo l'accesso remoto al database Postgres incluso in HPDM. Una volta abilitato, un account superutente backdoor viene utilizzato per autenticarsi al database Postgres ed eseguire comandi arbitrari del sistema operativo.
Dai un'occhiata al mio post sul blog su come ho scoperto queste vulnerabilità per maggiori dettagli:
Mentre questo exploit funziona solo contro HPDM 5.x, il servizio Java RMI non autenticato è presente in tutte le versioni di HPDM precedenti alla 5.0.4 e alla 4.7 service pack 13. L'impatto dello sfruttamento di questo servizio potrebbe essere inferiore, ma rimane comunque una vulnerabilità HQLi/SQLi, insieme alla possibilità di estrarre la configurazione (potenzialmente incluse le password per altri servizi), e tutti i nomi utente degli account HPDM con i corrispondenti hash MD5 delle password.
Exploit di esecuzione remota di codice non autenticato per endpoint del servizio Java JNBridge configurati in modo non sicuro. Basato sul lavoro di Moritz Bechler (CVE-2019-7839).
Il protocollo di rete implementato da JNBridge è progettato esclusivamente per facilitare l'esecuzione remota di codice per l'interoperabilità tra applicazioni Java e .NET. Pertanto, tecnicamente non è un exploit, ma solo un pratico piccolo script Python per eseguire comandi arbitrari su un endpoint Java JNBridge.
Dai un'occhiata al mio post sul blog per una descrizione del mio percorso dall'avviso di sicurezza alla creazione di un exploit completo:
Questo exploit colpisce la funzionalità di aggiornamento automatico non sicura di WordPress per rilasciare una shell PHP sul server sottostante. L'exploit è stato testato con successo fino a WordPress 4.9.8, che è l'ultima versione alla data di pubblicazione.
Quando WordPress controlla gli aggiornamenti, tenta una connessione HTTPS sicura a api.wordpress.org. Se questa connessione fallisce, ad esempio perché viene presentato un certificato non attendibile, WordPress ripiega su una connessione HTTP non sicura.
Il secondo problema è che WordPress si fida degli aggiornamenti delle traduzioni. Non aggiorna automaticamente plugin, temi o versioni principali del core, presumibilmente a causa dei rischi di installare nuovo codice sul server. Tuttavia, aggiorna automaticamente le traduzioni. Sfortunatamente WordPress non riesce a convalidare correttamente gli archivi delle traduzioni, quindi finché il file ZIP della traduzione contiene almeno un file con estensione .po e uno con estensione .mo, WordPress estrae il contenuto sul server sottostante (inclusa la shell inserita lì dal MitM).
Mi sono imbattuto in questi problemi per caso, ma quando li ho segnalati (novembre 2017) il team di WordPress ha sostanzialmente detto WONTFIX per via della compatibilità con le versioni precedenti. Se qualcuno esegue WordPress su un server che non riesce a stabilire una connessione SSL/TLS in uscita, dovrebbe comunque essere in grado di aggiornare automaticamente WordPress per motivi di sicurezza, dicono.
¯\_(ツ)_/¯
Dai un'occhiata al mio post sul blog per maggiori dettagli:
Alcuni frammenti JS da usare per sfruttare le vulnerabilità XSS di WordPress.
