Skip to content
KitploitKITPLOIT
StrumentiExploitsBlog
Log in
Invia
StrumentiExploitsBlog
Invia

Strumenti di Hacking, PenTest e Cybersecurity per il tuo Arsenale di Sicurezza!

Kitploit è una directory di strumenti di hacking, cybersecurity e pentesting. Scopri gli ultimi aggiornamenti dei progetti per trovare vulnerabilità, analizzare sistemi, automatizzare i test e rafforzare la tua sicurezza.

FeedContattoPrivacy© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
CVE-2022-26134-OGNL-Injection — Exploit per CVE-2022-26134, una vulnerabilità di iniezione OGNL in Atlassian Confluence Server e Data Center, che consente l'esecuzione remota di codice senza autenticazione. | Kitploit
Strumenti/GitHubGitHub/roodhelios/cve-2022-26134-ognl-injection
Generazione di PayloadAnalisi delle VulnerabilitàExploitSfruttamento di Applicazioni WebPenetration Testing
GitHubroodhelios/cve-2022-26134-ognl-injection

CVE-2022-26134-OGNL-Injection

Exploit per CVE-2022-26134, una vulnerabilità di iniezione OGNL in Atlassian Confluence Server e Data Center, che consente l'esecuzione remota di codice senza autenticazione.

Più Popolari

Vedi tutti →

Scopri gli strumenti più utilizzati dalla nostra community.

Esplora tutti gli strumenti

Sfoglia la nostra collezione di strumenti

Vedi tutti gli strumenti →
Vedi Repository
523 giorni faNon ancora revisionato
Condividi

CVE-2022-26134: caso di studio difensivo

Analisi locale riproducibile delle evidenze relative all'URI della richiesta e dei registri di mitigazione per la vulnerabilità di iniezione OGNL di Atlassian Confluence.

Il repository conserva l'artefatto di ricerca accademica originale e aggiunge strumenti Python per l'analisi dei log, la gestione dei casi e la revisione delle evidenze di mitigazione. Questi flussi di lavoro utilizzano fixture locali. Non inviano richieste di exploit né scansionano host.

Inizia da qui

ObiettivoPunto di ingresso
Leggere il caso di studio originalePanoramica della ricerca
Leggere il documento tecnicoDocumento originale
Visualizzare la presentazioneSlide originali
Eseguire gli strumenti difensiviGuida al rilevamento e alle evidenze
Esaminare il flusso della richiestaNote di analisi

Leggere un report di rilevamento sintetico

Usa Python 3.11 o versioni successive. Questa guida rapida richiede solo la libreria standard. Esegui dalla radice del repository:

python -m detection.report_reader_cli \
  CVE-2022-26134-OGNL-Injection/tests/fixtures/report-v1.golden.json

Il report riassume due righe analizzate, una richiesta corrispondente, un finding emesso e la tecnica candidata T1190. Un URI corrispondente è un'evidenza di rilevamento, non una prova che un attaccante abbia eseguito codice.

Esaminare un fixture di mitigazione

python -m detection.mitigation_evidence_cli tests/fixtures/mitigation-evidence-v1.json

Il deployment sintetico restituisce review_required con priorità urgent. Un nodo dichiara una versione corretta; un altro registra una soluzione temporanea. Questo deliberatamente non etichetta l'intero cluster come corretto. Anche le corrispondenze dei set di file locali sono etichettate come non verificate, poiché la presenza dei file non può stabilire il riavvio del servizio o il successo della mitigazione.

Capacità operative

Trasforma un fixture locale di log di accesso in un caso analista memorizzato, invece di partire da un report precompilato:

python -m detection.log_case_cli tests/fixtures/local-case-access.log --scope synthetic \
  --created-at 2026-10-19T00:01:00Z --output /tmp/confluence-log-case.sqlite
python -m detection.case_store_verify_cli /tmp/confluence-log-case.sqlite

Usa un nuovo percorso di output su POSIX. Aspettati due richieste analizzate, una richiesta corrispondente, un finding emesso e la coda application-security. Il caso memorizzato lega il suo riepilogo all'SHA-256 dell'input e allo scope dichiarato, senza copiare gli URI grezzi delle richieste né il percorso del log locale alla macchina. Conserva il log originale separatamente e in modo privato. Un risultato no_findings non crea alcun caso o database e non dimostra che un deployment sia sicuro. Vedi i limiti del flusso log-to-case.

Rileggi il caso effettivamente memorizzato per la revisione dell'analista, non solo i conteggi di verifica:

python -m detection.case_export_cli /tmp/confluence-log-case.sqlite \
  --output /tmp/confluence-case-review.json

Attendersi report_type: case-document-export, verification.case_count: 1 e una voce in cases contenente il documento completo del caso, la sua sequenza e il digest del payload. Ispezionare la sua coda, i passaggi di revisione e il riepilogo della fonte prima di agire. Utilizzare un database chiuso senza scritture WAL o journal in sospeso e un percorso di output nuovo su POSIX. Il contratto di esportazione spiega i limiti di snapshot, privacy e verifica della fonte.

Riprodurre quel caso memorizzato dalla sua fonte conservata in un processo separato:

python -m detection.log_case_verify /tmp/confluence-log-case.sqlite \
  tests/fixtures/local-case-access.log --scope synthetic

Atteso status: reproduced. Questo ricontrolla il database, i byte originali, il riepilogo di rilevamento, il routing e il documento completo del caso. È più rigoroso del controllo del solo hash del payload memorizzato, ma non autentica la fonte né il timestamp di creazione.

Per il sottoinsieme documentato dei log combinati Apache, aggiungi --log-format combined a entrambi i comandi e usa tests/fixtures/combined-access.log. Produce la stessa revisione con due richieste e un rilevamento senza richiedere una riscrittura in formato lab. Il valore predefinito resta lab; non viene effettuato alcun rilevamento automatico del formato. Consulta il contratto dei log combinati per i campi accettati e i formati personalizzati non supportati.

Prova l'autenticazione delle evidenze del cluster senza preparare report o file di chiavi:

python -m detection.cluster_demo

Questo costruisce in memoria due report di nodo fabbricati, li aggrega e verifica un manifest con una chiave HMAC casuale effimera. Il riepilogo mostra review_required, unchanged_manifest: verified e controlli rifiutati per un nodo modificato, un diverso deployment e un'osservazione obsoleta. La freschezza utilizza un orologio di dimostrazione fisso. Nessuna chiave, MAC, dato host o file viene emesso o conservato. Nessun host Confluence viene contattato. Un manifest verificato non rende il cluster sintetico mitigato né stabilisce che le affermazioni di una fonte siano vere.

Per conservare tali report sintetici per la verifica in un altro processo, utilizzare cluster_demo --output-dir NEW_DIRECTORY --key-file PRIVATE_EXTERNAL_KEY. La guida al rilevamento include la preparazione della chiave, i comandi di verifica e il limite dell'orologio fisso. La chiave non viene mai copiata nella directory delle evidenze.

Eseguire l'intero percorso sintetico da report a caso con un solo comando:

python -m detection.demo

Legge il report golden, seleziona la coda application-security, costruisce un caso, lo memorizza in SQLite temporaneo, ritenta lo stesso inserimento e verifica l'integrità memorizzata. Il riepilogo riporta un caso memorizzato e status: verified; il nuovo tentativo non crea righe duplicate. I file temporanei vengono rimossi dopo l'esecuzione. Questa è una verifica locale del case-store, non una prova che un incidente reale o un deployment Confluence sia sicuro.

Per conservare evidenze verificabili invece di eliminarle, scegli una nuova directory di output:

python -m detection.demo --output-dir /tmp/confluence-synthetic-review
python -m detection.case_store_verify_cli /tmp/confluence-synthetic-review/cases.sqlite
python -m detection.bundle_verify /tmp/confluence-synthetic-review
Scarica lo strumento