Compile o Heartbleed.c Tester no CentOS 6.x

Question

Eu tenho procurado há dias por uma solução para isso, basicamente estou tentando testar minha rede para o bug heartbleed, mas não consigo compilar o testador no CentOS 6.x, quaisquer idéias ou sugestões são muito apreciadas ...

Link para o testador

http://www.exploit-db.com/download/32998

Erro estou recebendo

[root@www ~]# gcc heartbleed.c -o heartbleed -lssl -lssl3 -lcrypto
/tmp/cc4cZa2B.o: In function 'tls_bind':
heartbleed.c:(.text+0x47d): undefined reference to 'SSL_CTX_SRP_CTX_init'
collect2: ld returned 1 exit status
[root@www ~]# 

    

Answer 1

Para o CentOS, é sugerido adicionar o sinal -lss3 à sua linha de compilação. Link de suporte .

Você também pode tentar vincular estaticamente o OpenSSL à sua compilação, no mesmo link acima. Substituindo a localização dos seus arquivos *.a :

#!/bin/bash
# Emerge openssl with static-libs to obtain all the *.a
mkdir -p heartbleed.d
cd heartbleed.d
ar x /usr/lib/libssl.a
ar x /usr/lib/libcrypto.a
ar x /usr/lib/libgmp.a
ar x /usr/lib/libz.a
cd ..
gcc -o heartbleed heartbleed.d/*.o heartbleed.c -ldl

Se você está no Debian (por completo eu sei que esta questão é em relação ao CentOS 6.x) então você terá esse problema. Então este link pode ajudá-lo com seu problema , ele fornece a solução abaixo:

$ gcc heartbleed.c -o heartbleed -Wl,-Bstatic -lssl -Wl,-Bdynamic -lssl3 -lcrypto
$ uname -a
Linux xxxxx Debian 3.2.54-2 x86_64 GNU/Linux
$ ls -al heartbleed
-rwxr-xr-x 1 x x357603 Apr 11 23:20 heartbleed

Este link é meio confuso , ele apresenta o problema exato em 2013, mas apenas diz que eles atualizaram o cabeçalho para compilar. Então, talvez triplique verifique o arquivo de cabeçalho para comentários?

Outra solução para o seu problema pode ser responder ao seguinte. Qual versão do OpenSSL sua rede executa? Aqui está um trecho de HeartBleed.com

What versions of the OpenSSL are affected?

Status of different versions:

OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable OpenSSL 1.0.1g is NOT vulnerable OpenSSL 1.0.0 branch is NOT vulnerable OpenSSL 0.9.8 branch is NOT vulnerable

Foi corrigido no OpenSSL versão 1.0.1g: No OpenSSL Security Advisory :

Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.

Você pode recompilar versões mais antigas com esse sinalizador se não puder atualizar.

    

Answer 2

Parece que a função perdida foi desativada através das opções de construção da sua biblioteca OpenSSL. Você pode tentar compilar manualmente o openssl.

Como alternativa, você pode usar o nmap (primeiro verifique seu nmap atual versão, você pode ter o script heartbleed já.

    

Answer 3

gcc heartbleed.c -o heartbleed -lssl -lssl3 -lcrypto

Isso parece OK. -lssl são rotinas SSL / TLS do OpenSSL. -lcrypto são rotinas de criptografia do OpenSSL.

Mas não tenho certeza sobre -lssl3 . Que biblioteca é essa?

heartbleed.c:(.text+0x47d): undefined reference to 'SSL_CTX_SRP_CTX_init'

Parece que a sua versão do OpenSSL não suporta Secure Remote Password (SRP) de Thomas Wu . Ou foi compilado sem suporte para isso.

De acordo com o OpenSSL CHANGELOG , o SRP foi adicionado ao OpenSSL 1.0.1:

  *) Add SRP support.
     [Tom Wu <[email protected]> and Ben Laurie]

Você pode verificar se a biblioteca OpenSSL foi criada sem o SRP com o seguinte.

Primeiro, encontre a biblioteca OpenSSL SSL / TLS:

$ find /usr/ -iname libssl.*
/usr/lib/libssl.0.9.7.dylib
/usr/lib/libssl.0.9.8.dylib
/usr/lib/libssl.dylib
/usr/local/ssl/android-14/lib/libssl.a
/usr/local/ssl/android-14/lib/libssl.so
/usr/local/ssl/android-14/lib/libssl.so.1.0.0
/usr/local/ssl/android-18/lib/libssl.a
/usr/local/ssl/android-18/lib/libssl.so
/usr/local/ssl/android-18/lib/libssl.so.1.0.0
...

Em segundo lugar, veja se o símbolo é exportado:

$ nm /usr/lib/libssl.0.9.7.dylib | grep SSL_CTX_SRP_CTX_init
$

No meu caso, o SRP não está disponível porque a biblioteca padrão da Apple é tão abaixo do nível (versão 0.9.7).

Eu tenho outra cópia da biblioteca desmembrada (versão 1.0.1i):

$ nm /usr/local/ssl/macosx-x64/lib/libssl.dylib | grep SSL_CTX_SRP_CTX_init
0000000000034920 T _SSL_CTX_SRP_CTX_init

Minha versão 1.0.1i tem a rotina.

Às vezes, você pode criar sem SRP. Para verificar se o OpenSSL foi configurado sem SRP:

$ cat /usr/local/ssl/macosx-x64/include/openssl/opensslconf.h | grep -A 1 SRP
$

No caso acima, eu configurei para o SRP.

Aqui está o que parece quando o OpenSSL é configurado sem um recurso (eu configuro sem SSLv2):

$ cat /usr//local/ssl/macosx-x64/include/openssl/opensslconf.h | grep -A 1 SSL2
#ifndef OPENSSL_NO_SSL2
# define OPENSSL_NO_SSL2
#endif
--
# if defined(OPENSSL_NO_SSL2) && !defined(NO_SSL2)
#  define NO_SSL2
# endif

SSL_CTX_SRP_CTX_init é usado em dois lugares. Para corrigir isso, apenas comente.

Primeiro, linha 355:

 /* SSL_CTX_SRP_CTX_init(c->sslContext); */

Segundo, linha 499:

 /* SSL_CTX_SRP_CTX_init(c->sslContext); */

Relacionado, os autores do exploit provavelmente poderiam guardar o número da versão do OpenSSL. A biblioteca fornece OPENSSL_VERSION_NUMBER (3) apenas para esse tipo de coisa. Algo como:

#if (OPENSSL_VERSION_NUMBER >= 0x10001000L) && !defined(OPENSSL_NO_SRP)
    SSL_CTX_SRP_CTX_init(c->sslContext);
#endif