| 2014-10-20 00:31:39 |
rainkin |
description |
Recently, we are trying to find SSL security problems by static analysis. For example, as we all know, Hostname verification is an important step when verifying X509 certificates, however, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly.
Now, we find some SSL problems in epic4, the following is details:
-----------------------------------------------------------------------------
file : epic4/epic4-2.10.1/source/ssl.c
-----------------------------------------------------------------------------
function : SSL_FD_init
-----------------------------------------------------------------------------
SSL method : \
-----------------------------------------------------------------------------
call SSL_CTX_set_verify() : NOT FOUND
-----------------------------------------------------------------------------
Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO
-----------------------------------------------------------------------------
call SSL_get_peer_certificate(): YES (but NO X509 suite API for custom verification)
-----------------------------------------------------------------------------
call SSL_get_verify_result(): NO
-----------------------------------------------------------------------------
According to the above result, we think the SSL connection in epic4 is not secure.
More specifically , we can take function SSL_CTX_set_verify() for example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate at first. Then use X509 APIs or self-define function to verify the certificate we get. If the source code does not match this model, then we can deduce this code is vulnerable. And other APIs have similar problems.
To verify the result we make, we attack the software manually.
一.Hostname verification
1. change /etc/hosts in order to simulate the DNS hijack
46.137.23.30 attacker.com
（46.137.23.30 is a normal irc server）
2. #rainkin@rainkin:~$ epic4 rainkin attacker.com:6697:::OPN:irc-ssl
3. result : succeed!!!
The fetch succeeded, indicating the software didn't check the hostname against the signee of the certificate.
二. Also for expired time check,
1. change the system time to 2200 to guarantee the certificate to be expired.
2. run epic4 to connect to a normal irc server.
3. result:succeed!!
The fetch succeeded again and no warning was given, indicating the software didn't check whether the certificate expired or not.
PS: I have saved the SSL connection Wireshark packages, and upload these files.
for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf
and more details you can contact with us, we will be very glad for your responce.
Thanks. |
Recently, our group is trying to find SSL security problems by static analysis. When using Openssl, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly.
The source code we analysis was from ubuntu: apt-get source <package name>.And we use this command in Ubuntu 12.04.
Now we just check whether a software verify the certitiface chain when using Openssl.
一. How we ensure whether a software check the certificate chain or not?
We make a matching algorithm. If source code doesn't match this, the software is not secure.
Typically, when Openssl clients want to verify a certificate, there are the following choices:
1. Using built-in certificate verification(chain of trust verification, expired validation, etc)
[Example 1]
/**
* set VERIFY_PEER flag before the establishment of a SSL connection
* OPENSSL will drop connection during handshake if verification fails
* No custom callback function used.
*/
SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
[Example 2]
//check the built-in verification result after the SSL handshake
if(SSL_get_peer_certificate(ssl)!=NULL && SSL_get_verify_result(ssl)==X509_V_OK)
{
//PASS
}
else
{
//FAIL
}
2. Using custom verification.
[Example 3]
X509* usrcert = SSL_get_peer_certificate(ssl);
rootCertStore = X509_STORE_new();
.. ..
ctx = X509_STORE_CTX_new();
ret = X509_STORE_CTX_init(ctx,rootCertStore,usrCert,NULL);
ret = X509_verify_cert(ctx)
This example read the certificate out using SSL_get_peer_certificate API. Then it use X509 API suite to do certificate verification. X509 API is part of OPENSSL library. Theoretically, a developer can use any API in any libraries to do this verification, but in practice, we only identify the case above: using X509 API suite.
3. Add restrictions or relaxations to built-in certificate verification
The built-in certificate verification in OPENSSL library can be extended by using custom callback functions. By default, this callback option is NULL, indicating completely use built-in verification.
By adding this callback function, the developer can decide if they accept the verify result by openssl, and they can modify the result whenever they what.
[Example 4]
SSL_CTX_set_verify(ctx,VERIFY_PEER,mycallback);
static mycallback(int preverify_ok, X509_STORE_CTX *ctx)
{
....
....
return preverify_ok;
}
二. The analysis result
Now, we find some SSL problems in epic4, the following is details:
-----------------------------------------------------------------------------
file : epic4/epic4-2.10.1/source/ssl.c
-----------------------------------------------------------------------------
function : SSL_FD_init
-----------------------------------------------------------------------------
SSL method : \
-----------------------------------------------------------------------------
call SSL_CTX_set_verify() : NOT FOUND
-----------------------------------------------------------------------------
Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO
-----------------------------------------------------------------------------
call SSL_get_peer_certificate(): YES (but NO X509 suite API for custom verification)
-----------------------------------------------------------------------------
call SSL_get_verify_result(): NO
-----------------------------------------------------------------------------
According to the above result, we think the SSL connection in epic4 is not secure.
More specifically , we can take function SSL_CTX_set_verify() for example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate at first. Then use X509 APIs or self-define function to verify the certificate we get. If the source code does not match this model, then we can deduce this code is vulnerable. And other APIs have similar problems.
To verify the result we make, we attack the software manually.
一.Hostname verification
1. change /etc/hosts in order to simulate the DNS hijack
46.137.23.30 attacker.com
（46.137.23.30 is a normal irc server）
2. #rainkin@rainkin:~$ epic4 rainkin attacker.com:6697:::OPN:irc-ssl
3. result : succeed!!!
The fetch succeeded, indicating the software didn't check the hostname against the signee of the certificate.
二. Also for expired time check,
1. change the system time to 2200 to guarantee the certificate to be expired.
2. run epic4 to connect to a normal irc server.
3. result:succeed!!
The fetch succeeded again and no warning was given, indicating the software didn't check whether the certificate expired or not.
PS: I have saved the SSL connection Wireshark packages, and upload these files.
for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf
and more details you can contact with us, we will be very glad for your responce.
Thanks. |
|
| 2014-10-20 00:32:45 |
rainkin |
description |
Recently, our group is trying to find SSL security problems by static analysis. When using Openssl, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly.
The source code we analysis was from ubuntu: apt-get source <package name>.And we use this command in Ubuntu 12.04.
Now we just check whether a software verify the certitiface chain when using Openssl.
一. How we ensure whether a software check the certificate chain or not?
We make a matching algorithm. If source code doesn't match this, the software is not secure.
Typically, when Openssl clients want to verify a certificate, there are the following choices:
1. Using built-in certificate verification(chain of trust verification, expired validation, etc)
[Example 1]
/**
* set VERIFY_PEER flag before the establishment of a SSL connection
* OPENSSL will drop connection during handshake if verification fails
* No custom callback function used.
*/
SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
[Example 2]
//check the built-in verification result after the SSL handshake
if(SSL_get_peer_certificate(ssl)!=NULL && SSL_get_verify_result(ssl)==X509_V_OK)
{
//PASS
}
else
{
//FAIL
}
2. Using custom verification.
[Example 3]
X509* usrcert = SSL_get_peer_certificate(ssl);
rootCertStore = X509_STORE_new();
.. ..
ctx = X509_STORE_CTX_new();
ret = X509_STORE_CTX_init(ctx,rootCertStore,usrCert,NULL);
ret = X509_verify_cert(ctx)
This example read the certificate out using SSL_get_peer_certificate API. Then it use X509 API suite to do certificate verification. X509 API is part of OPENSSL library. Theoretically, a developer can use any API in any libraries to do this verification, but in practice, we only identify the case above: using X509 API suite.
3. Add restrictions or relaxations to built-in certificate verification
The built-in certificate verification in OPENSSL library can be extended by using custom callback functions. By default, this callback option is NULL, indicating completely use built-in verification.
By adding this callback function, the developer can decide if they accept the verify result by openssl, and they can modify the result whenever they what.
[Example 4]
SSL_CTX_set_verify(ctx,VERIFY_PEER,mycallback);
static mycallback(int preverify_ok, X509_STORE_CTX *ctx)
{
....
....
return preverify_ok;
}
二. The analysis result
Now, we find some SSL problems in epic4, the following is details:
-----------------------------------------------------------------------------
file : epic4/epic4-2.10.1/source/ssl.c
-----------------------------------------------------------------------------
function : SSL_FD_init
-----------------------------------------------------------------------------
SSL method : \
-----------------------------------------------------------------------------
call SSL_CTX_set_verify() : NOT FOUND
-----------------------------------------------------------------------------
Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO
-----------------------------------------------------------------------------
call SSL_get_peer_certificate(): YES (but NO X509 suite API for custom verification)
-----------------------------------------------------------------------------
call SSL_get_verify_result(): NO
-----------------------------------------------------------------------------
According to the above result, we think the SSL connection in epic4 is not secure.
More specifically , we can take function SSL_CTX_set_verify() for example, when using OPENSSL, if we call SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_NONE, null), we should verify the certificate by calling the function SSL_get_peer_certificate() to get the certificate at first. Then use X509 APIs or self-define function to verify the certificate we get. If the source code does not match this model, then we can deduce this code is vulnerable. And other APIs have similar problems.
To verify the result we make, we attack the software manually.
一.Hostname verification
1. change /etc/hosts in order to simulate the DNS hijack
46.137.23.30 attacker.com
（46.137.23.30 is a normal irc server）
2. #rainkin@rainkin:~$ epic4 rainkin attacker.com:6697:::OPN:irc-ssl
3. result : succeed!!!
The fetch succeeded, indicating the software didn't check the hostname against the signee of the certificate.
二. Also for expired time check,
1. change the system time to 2200 to guarantee the certificate to be expired.
2. run epic4 to connect to a normal irc server.
3. result:succeed!!
The fetch succeeded again and no warning was given, indicating the software didn't check whether the certificate expired or not.
PS: I have saved the SSL connection Wireshark packages, and upload these files.
for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf
and more details you can contact with us, we will be very glad for your responce.
Thanks. |
Recently, our group is trying to find SSL security problems by static analysis. When using Openssl, people tend to miss the step or to misunderstand the APIs when using SSL/TLS, which might cause severe man in the middle attack and break the entire TLS mechanism. And static analysis is a way of finding whether the APIs are called correctly.
The source code we analysis was from ubuntu: apt-get source <package name>.And we use this command in Ubuntu 12.04.
Now we just check whether a software verify the certitiface chain when using Openssl.
一. How we ensure whether a software check the certificate chain or not?
We make a matching algorithm. If source code doesn't match this, the software is not secure.
Typically, when Openssl clients want to verify a certificate, there are the following choices:
1. Using built-in certificate verification(chain of trust verification, expired validation, etc)
[Example 1]
/**
* set VERIFY_PEER flag before the establishment of a SSL connection
* OPENSSL will drop connection during handshake if verification fails
* No custom callback function used.
*/
SSL_CTX_set_verify(ctx,VERIFY_PEER,NULL);
[Example 2]
//check the built-in verification result after the SSL handshake
if(SSL_get_peer_certificate(ssl)!=NULL && SSL_get_verify_result(ssl)==X509_V_OK)
{
//PASS
}
else
{
//FAIL
}
2. Using custom verification.
[Example 3]
X509* usrcert = SSL_get_peer_certificate(ssl);
rootCertStore = X509_STORE_new();
.. ..
ctx = X509_STORE_CTX_new();
ret = X509_STORE_CTX_init(ctx,rootCertStore,usrCert,NULL);
ret = X509_verify_cert(ctx)
This example read the certificate out using SSL_get_peer_certificate API. Then it use X509 API suite to do certificate verification. X509 API is part of OPENSSL library. Theoretically, a developer can use any API in any libraries to do this verification, but in practice, we only identify the case above: using X509 API suite.
3. Add restrictions or relaxations to built-in certificate verification
The built-in certificate verification in OPENSSL library can be extended by using custom callback functions. By default, this callback option is NULL, indicating completely use built-in verification.
By adding this callback function, the developer can decide if they accept the verify result by openssl, and they can modify the result whenever they what.
[Example 4]
SSL_CTX_set_verify(ctx,VERIFY_PEER,mycallback);
static mycallback(int preverify_ok, X509_STORE_CTX *ctx)
{
....
....
return preverify_ok;
}
二. The analysis result
Now, we find some SSL problems in epic4, the following is details:
-----------------------------------------------------------------------------
file : epic4/epic4-2.10.1/source/ssl.c
-----------------------------------------------------------------------------
function : SSL_FD_init
-----------------------------------------------------------------------------
SSL method : \
-----------------------------------------------------------------------------
call SSL_CTX_set_verify() : NOT FOUND
-----------------------------------------------------------------------------
Have SSL_CTX_set_verify ( SSL_set_verify) callback : NO
-----------------------------------------------------------------------------
call SSL_get_peer_certificate(): YES (but NO X509 suite API for custom verification)
-----------------------------------------------------------------------------
call SSL_get_verify_result(): NO
-----------------------------------------------------------------------------
According to the above result, we think the SSL connection in epic4 is not secure.
三. How we prove the result we got?
for expired time check,
1. change the system time to 2200 to guarantee the certificate to be expired.
2. run epic4 to connect to a normal irc server.
3. result:succeed!!
The fetch succeeded again and no warning was given, indicating the software didn't check whether the certificate expired or not.
PS: I have saved the SSL connection Wireshark packages, and upload these files.
for more information, you can see the paper: http://people.stfx.ca/x2011/x2011ucj/SSL/p38-georgiev.pdf
and more details you can contact with us, we will be very glad for your responce.
Thanks. |
|
