Pages

Friday, August 19, 2011

User Agent / SSL Version and SSL2_READ_INTERNAL:bad mac decode

During SSL version verification and testing, one might encounter different issues on different platforms. The output greatly depends on the type of User agent is used and the SSL configuration parameters on server side. In certain scenarios, one might encounter SSL2_READ_INTERNAL:bad mac error while testing for SSLv2 on the server. For example: let's have a look the example below

[Request/Response - 1]

root@bt:~# curl -v -2 https://www.examplebank.com:443 -k
* About to connect() to www.examplebank.com port 443 (#0)
* Trying ... connected
* Connected to examplebank.com port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv2, Client hello (1):
* SSLv2, Server hello (4):
* SSLv2, Client key (2):
* SSLv2, Client finished (3):
* error:140EC071:SSL routines:SSL2_READ_INTERNAL:bad mac decode
* Closing connection #0

root@bt:~# openssl s_client -connect www.examplebank.com:443 -ssl2
CONNECTED(00000003)
depth=0 /1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/2.5.4.15=Private Organization/serialNumber=2927442/C=US/postalCode=75202/ST=Texas/L=Dallas/streetAddress=1201 Main Street/O=Bank Corporation/OU=WebSphere Ecomm
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/2.5.4.15=Private Organization/serialNumber=2927442/C=US/postalCode=75202/ST=Texas/L=Dallas/streetAddress=1201 Main Street/O= Bank/OU=WebSphere Ecomm
verify error:num=27:certificate not trusted
verify return:1
depth=0 /1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Delaware/2.5.4.15=Private Organization/serialNumber=2927442/C=US/postalCode=75202/ST=Texas/L=Dallas/streetAddress=1201 Main Street/O=Bank /OU=WebSphere Ecomm
verify error:num=21:unable to verify the first certificate
verify return:1
2170:error:140EC071:SSL routines:SSL2_READ_INTERNAL:bad mac decode:s2_pkt.c:274:


[Request/Response - 2]
root@bt:~# curl -v -2 https://examplebank.com:443 -k
* About to connect() to examplebank.com port 443 (#0)
* Trying ... connected
* Connected to examplebank.com (171.159.228.150) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv2, Client hello (1):
* Unknown SSL protocol error in connection to examplebank.com.com:443
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to examplebank.com:443

root@bt:~# openssl s_client -connect examplebank.com:443 -ssl2
CONNECTED(00000003)
2179:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428:


The above presented response information is from the same target. The first request has "www" prefix appended to the domain name and second request is without "www" prefix.

The first case results in half handshake and server side verification fails. This error usually occurs when server detects a specific padding option chosen for the the protocol version (SSLv2 in this case). It typically looks like a Protocol Rollback Attack. The server only negotiates successfully when only SSLv2 is enabled on the server. However, hostname (www.examplebank.com) also plays a role because there is always a SSL redirection implemented on the server side.

The second case simply rejects the SSLv2 handshake. The hostname (examplebank.com) is used does not have "www" prefix. The point is while testing SSL version different errors should be fuzzed appropriately before raising a red flag.

Enjoy!

0 comments: