Last updated at Mon, 21 Aug 2017 17:16:19 GMT

I wanted share a brief example of using a full scan of IPv4 to estimate the exposure level of a vulnerability. Last week, Craig Young, a security researcher at Tripwire, wrote a blog post about a vulnerability in the ReadyNAS network storage appliance. In an interview with Threatpost, Craig mentioned that although Netgear produced a patch in July, a quick search via SHODAN indicates that many users are still vulnerable, leaving them exposed to any attacker who can diff the patched and unpatched firmware.

This seemed like a great opportunity to review our Project Sonar HTTP results and tease out recent exposure rates from a single-pass scan of the IPv4 internet. The first thing I did was a grab the patched and unpatched firmware, unzipped the archives, extracted them with binwalk, and ran a quick diff between the two. The vulnerability is obviously on line 17 and is the result of an attacker-supplied $section variable being interpreted as arbitrary Perl code. Given that the web server runs as root and Metasploit is quite capable of exploiting Perl code injection vulnerabilities, this seems like a low bar to exploit.

Identifying ReadyNAS devices ended up being fairly easy. In response to a GET request on port 80, a device will respond with the following static HTML.

<meta http-equiv="refresh" content="0; url=/shares/">
 
<!--
Copyright 2007, NETGEAR
All rights reserved.
-->

Our scan data is in the form of base64-encoded responses stored as individual lines of JSON:

{"host": "A.B.C.D", "data": "SFRUUC8xLjAgNDAwIEJhZCB...", "port": 80}

I wrote a quick script to process this data via stdin, match ReadyNAS devices, and print out the IP address and Last-Modified date from the header of the response. I ran the raw scan output through this script and made some coffee. The result from our October 4th scan consisted of 3,488 lines of results. This is a little different than the numbers listed by SHODAN, but they can be explained by DHCP, multiple merged scans, and the fact that the ReadyNAS web interface is mostly commonly accessed over SSL on port 443. The results looked like the following:

xxx.xxx.xxx.169   Thu, 07 Oct 2010 00:53:51 GMT
xxx.xxx.xxx.42    Thu, 07 Oct 2010 00:53:51 GMT
xxx.xxx.xxx.94    Tue, 02 Jul 2013 01:42:23 GMT
xxx.xxx.xxx.113   Mon, 29 Aug 2011 23:04:43 GMT

The interesting part about the Last-Modified header is that it seems to correlate with specific firmware versions. Version 4.2.24 was built on July 2nd, 2013 and we can assume that all versions prior to that are unpatched.

$ cat readynas.txt  | perl -pe 's/\d+\.\d+\.\d+\.\d+\t//' | sort | uniq -c | sort -rn
    717 Tue, 02 Jul 2013 01:33:54 GMT
    510 Tue, 02 Jul 2013 01:42:23 GMT
    429 Fri, 24 Aug 2012 22:55:26 GMT
    383 Wed, 05 Sep 2012 07:33:52 GMT
    212 Mon, 13 Jul 2009 20:56:46 GMT
    209 Mon, 29 Aug 2011 23:04:43 GMT
    200 Fri, 02 Sep 2011 00:51:04 GMT
    189 Sat, 06 Nov 2010 00:10:06 GMT
    133 Thu, 02 May 2013 17:00:27 GMT
    112 Thu, 31 May 2012 18:40:25 GMT
    .................................

If we exclude all results with a Last-Modified date equal to or newer than July 2nd, 2013, we end up with 2,257 of 3,488 devices vulnerable, or approximately 65% of ReadyNAS devices with their web interface exposed to the internet on port 80 are remotely exploitable.

It isn't clear whether these stats would change significantly if the same scan was performed on port 443 or how the exposure rate has changed since this particular scan was run. This does give us a starting point to figure out how popular these devices are and what specific industries and regions are most affected, but I will leave that to a future blog post.

If you are interested in seeing an exploit in action, Craig is hosting a demo on Tuesday, October 29th.

-HD