Blog

CVE-2013-2028 and nginx/1.4.0: Are You Secure?

On May 7th, Greg MacManus, of iSIGHT Partners Labs, found a security problem in several recent versions of nginx. As per the nginx-announce mailing list announcement, “A stack-based buffer overflow might occur in a worker process while handling a specially crafted request, potentially resulting in arbitrary code execution (CVE-2013-2028).”

The problem affects nginx 1.3.9 – 1.4.0 and is fixed in 1.5.0 and 1.4.1 as indicated by the nginx.org official changelog.

As with most web server vulnerabilities, exploit proof of concept code was quickly released to take advantage of the issue as was a Metasploit exploit module. Detailed analysis and commercial exploits followed shortly thereafter.

According to the latest May 2013 Web Server Survey by Netcraft there are more than 104 million nginx application servers running on the Internet – right behind Microsoft IIS at 112 million and Apache at 359 million. Though there is a wide gap between nginx and Apache usage, the fact remains that the targeting of nginx application servers still presents a sizable opportunity for malicious actors.

Figure 1 – Netcraft data
nginx Netcraft

To illustrate a sense of just how many of these 104 million nginx servers might be vulnerable we can turn to the popular search engine SHODAN. According to SHODAN, there are 2,809 servers, in the United States, that are running nginx/1.4.0 (ref: http://www.shodanhq.com/search?q=nginx%2F1.4.0). The total number of nginx/1.4.0 servers reported globally is 7,234 which means that the United States accounts for roughly 39% of vulnerable nginx servers in this data set. SHODAN’s results also provides us with the latitude and longitude of the servers in question so we were able to generate a map that illustrates their location. It should be no surprise that the servers align with major population centers – a common trend frequently pointed out by Jay Jacobs of Verizon Business.

Figure 2 – SHODAN Results Map
SHODAN Results Map nginx 1.4.0

The majority (2,340) of servers are running the vulnerable nginx version on TCP port 80 (TCP/80) and 23 servers were running on TCP/8080. Coincidentally, 443 servers were running the vulnerable version of nginx on TCP/443 but only 3 were running on TCP/8443.

Figure 3 – Port Distribution
nginx port summary

The servers in the data set were a mix but Linux and BSD-based servers dominated. Linux 3.x-based servers came in at 227 servers, Linux 2.6.x at 130, Linux 2.4 – 2.6, FreeBSD 9.x at 3, Windows XP at 2, and FreeBSD 8.x with a single server.

Figure 4 – Operating System Distribution
nginx os summary

Though we didn’t research nginx/1.3.9 extensively, it was interesting to see that Bulgaria had the highest number of nginx servers of that version with 2,771 compared to China’s 1,654, and the United State’s 606 (ref: http://www.shodanhq.com/search?q=nginx%2F1.3.9).

Though the SHODAN results provide a relatively small sample of vulnerable servers in the wild, the results should serve to illustrate the speed at which vulnerabilities in application server stacks can be exploited.

To mitigate the impact of CVE-2013-2028, It is highly recommended that customers upgrade to the latest nginx revision. If that’s not possible, the official patch for the problem can be found here. If you are unable to patch your servers right now, the following temporary workaround can be used in each server{} block to mitigate the attack:

if ($http_transfer_encoding ~* chunked) {
return 444;
}

Customers should also make sure to monitor server and application configurations to ensure that malicious actors are not taking advantage of potentially exploitable configurations or changing configurations to further their exploitation. Similarly, file integrity monitoring should be employed to monitor servers, application stacks, and application code for any changes that deviate from the enterprise baseline – a likely indicator of compromise.

Finally, the continuous monitoring of logs is of great importance as the repeated hammering of your web server from a single IP address is yet another indicator. Consider sending your server and application logs to a SIEM or Log Management platform such as Splunk or SumoLogic in addition to adding some triggers that would allow for automatic remediation (such as server isolation or IP blocking) via provided APIs.

Related Posts