Testing the Return of Bleichenbachers Oracle Threat (ROBOT) vulnerability

Testing the ROBOT (Return of Bleichenbacher's Oracle Threat) vulnerability

Name	Last Modified	Size	Type
bin/	2017-Dec-12 16:28:30	--	Directory
etc/	2017-Dec-12 16:19:30	--	Directory

testssl-robot.zip	2017-Dec-12 15:30:02	160.97KB	ZIP Compressed Archive
testssl-robot.zip.asc	2017-Dec-12 16:02:49	811.00B	ASC File
testssl.sh	2017-Dec-12 16:02:03	762.84KB	SH File
testssl.sh.asc	2017-Dec-12 16:02:57	811.00B	ASC File

On Dec 12, 2017 was a disclosure of the new ROBOT vulnerability, see announcement at robotattack.org (and paper). Here you can find a snapshot of the tool testssl.sh to check whether your service is vulnerable. It also supports all common STARTTLS protocols.

The code for checking this vulnerability is based on a PoC from Hanno Böck and ported to testssl.sh by David Cooper. testssl.sh is an open source project started by Dirk Wetter.

Result of Alexa top 10k

Research

Dec 14, 2017: I scanned the Alexa Top 10k on the 12th and 13, the result is rather disillusioning: Almost 15% of the Internet currently is broken! At least if take the number of hosts using HTTPS as a basis. If you subtract the hosts showing a weak oracle the percentage is still around 11.5%. Amongst them were lots of high profile hosts like ebay.com (and other TLDs), hp.com, citrix.com, cisco.com, apple.com, itunes.com, fidelity.com, aliexpress.com, walmart.com, verizonwireless.com – to name a few (see my twitter feed). I am probably going to publish the screenhots later here too.
Also banks I spotted quite a few: of 65 hosts in the top 10k having the pattern "bank" in their hostname 13 (20%) were vulnerable. "edu" was worse – which is given the hardware basis of this bug – quite surprising: 31 (21.6%) of 143 hostnames appear vulnerable.
If you did the math and were wondering: Adding all vulnerable and non-vulnerable hosts is more than the number of total hosts with HTTPS. This is due to the fact that hostnames resolving to more than one IPs address gave different results for different IP addresses (vulnerable + not vulnerable or not reachable). For the sake of simplicity those hosts I counted more than once, mathematically more exact would have been to use fractions of a hostname then.

Usage

testssl.sh is pretty much portable out of the box. There are only little dependencies so that in 99.9% of the case you do not have to install anything. testssl.sh is working on every Linux, Mac OS X, FreeBSD, NetBSD and OpenBSD (slow), on MSYS2/Cygwin and WSL=Bash on Windows (slower).
It is supposed also to work on any other unixoid systems. bash is a prerequisite – otherwise there would be no sockets.

Unzip it, cd to the directory created and run

./testssl.sh --robot <URI> or
./testssl.sh -BB <URI>

where URI is

host | host:port | URL | URL:port

(port 443 is the default). STARTTLS services can be tested like ./testssl.sh --robot --starttls <URI>. Examples (old, they do not work anymore):

userid@somehost:~ % ./testssl.sh --robot cisco.com

##########################################################
    testssl.sh       2.9dev from https://testssl.sh/dev/
    (7e62dc3 2017-12-07 09:59:58 -- )

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################


 Using "OpenSSL 1.0.2-chacha (1.0.2i-dev)" [~183 ciphers]
 on mr_robot:./bin/openssl.Linux.x86_64
 (built: "Jun 22 19:32:29 2016", platform: "linux-x86_64")


 Start 2017-12-12 00:08:06        -->> 72.163.4.161:443 (cisco.com) <<-- 

 further IP addresses:   2001:420:1101:1::a
 rDNS (72.163.4.161):    www1.cisco.com.
 Service detected:       HTTP


 Testing for Return of Bleichenbacher's Oracle Threat (ROBOT) vulnerability 

 ROBOT                                     VULNERABLE (NOT ok)

 Done 2017-12-12 00:08:19 [  15s] -->>.163.4.161:443 (cisco.com) <<-- 

userid@somehost:~ % ./testssl.sh -BB --starttls pop3 px.hboeck.de:110

###########################################################
    testssl.sh       2.9dev from https://testssl.sh/dev/
    (7e62dc3 2017-12-07 09:59:58 -- )

      This program is free software. Distribution and
             modification under GPLv2 permitted.
      USAGE w/o ANY WARRANTY. USE IT AT YOUR OWN RISK!

       Please file bugs @ https://testssl.sh/bugs/

###########################################################


 Using "OpenSSL 1.0.2-chacha (1.0.2i-dev)" [~183 ciphers]
 on mr_robot:./bin/openssl.Linux.x86_64
 (built: "Jun 22 19:32:29 2016", platform: "linux-x86_64")


 Start 2017-12-12 01:21:24        -->>.202.78.80:110 (px.hboeck.de) <<-- 

 rDNS (149.202.78.80):   ns3608653.ip-149-202-78.eu.
 Service set:            STARTTLS via POP3

 Testing for Return of Bleichenbacher's Oracle Threat (ROBOT) vulnerability 

 ROBOT                                     VULNERABLE (NOT ok)

 Done 2017-12-12 01:21:33 [  11s] -->> 149.202.78.80:110 (px.hboeck.de) <<-- 

userid@somehost:~ %

Development

Please note that this is a snapshot of the code from December 2017.. ~~I might update this here for a while (see timestamp) but~~ the development of testssl.sh in general including this check takes place at github.

For more info and further command line options please see the parent directory or the man page in the git repo.

Licence

License is GPLv2. Please respect the Copyleft.

Constraints

Testing is slow, especially for non-vulnerable servers. We did the best to speed things up but it lies in the nature of this bug that the check is slow. We could shorten execution time but that would be at the cost of reliability (false negatives).

Vendors

I worked with Cisco in order to track down the problem with the web interface from ASAs. All instances I spotted so far (my top 10k scans and at several customers) had a weak oracle. This work resulted in an advisory. Another case which popped up during my scans and was known (to Hanno, Juraj and last but not least IBM) was Lotus Domino, see my tweets. Despite me orderly filing this again to IBM's PSIRT, it is still unfixed as of today (end of February). The majority of Lotus Domino servers seem to have a weak oracle, some seemed not vulnerable and some seem to have a strong oracle.

Misc

Feedback, bugs and contributions are welcome! Bugs, bug fixes and PRs can by submitted at the git repo or send me a mail to dirk aet testssl dot sh. I post all significant updates on Twitter (@drwetter).

Imprint