Search This Blog

Tuesday, March 18, 2014

Apache HTTP Server mod_dav DoS Vulnerability (CVE-2013-6438)



1. Summary

So a while back, a colleague and I looked at Apache mod_dav, and we noticed an issue with it. We reported the vulnerability to Apache and have waited for a few months to disclose. Today, Apache finally made it public. 

And now we can post our summary of the vulnerability that has been assigned CVE-2013-6438.  The issue exists in all versions of Apache prior to 2.4.8.

2. Apache WebDAV Module (mod_dav)

The Apache mod_dav module ships with all the recent stable Apache source code (2.0, 2.2, and 2.4). It provides WebDAV functionality, allowing Apache to utilize the extensions noted by WebDAV for the HTTP protocol to create, move, copy, and delete resources and collections, and modify their properties on a remote web server [5].  Figure 4. WebDAV File Upload provides an example of a file upload and response from Apache with mod_dav enabled.

           Figure 4. WebDAV File Upload


We can easily see that this makes uploading files to the web server very easy. Figure 5. WebDAV Get Contents provides an example of fetching contents of a specific file from the web server.

 
       Figure 5. WebDAV Get Contents


We can also modify property attributes of a file by sending XML formatted data using a PROPPATCH HTTP/1.1 extended WebDAV request. Figure 6. WebDAV Resource Property Update provides an example of a property update on the file test.txt. The XML data sent uses the XML namespace DAV: defined by xmlns:D=”DAV:”.  The properties author and notes of the file are modified with the contents provided. You can see that this is performed by placing the request inside the WebDAV propertyupdate method. The entire request is in XML format. Note also the server’s response of HTTP/1.1 200 OK informing us of successful update of the two properties for the file file.txt.

 
       Figure 6. WebDAV Resource Property Update


As noted, WebDAV provides a great flexibility for managing resources and collections using HTTP and a web server.  Many websites today use Apache along with the mod_dav WebDAV module for performing routine operational tasks.

3. Apache Subversion WebDAV Module (mod_dav_svn)

Apache Subversion is Apache Software Foundation’s collaborative open-source project for the version control system originally developed by CollabNet Inc. in 2000 [6]. The subversion project includes a suite of version control tools for managing resources (files, directories, properties). It includes client, server, and administrative binaries for version control across systems using local or network file:/// path access scheme, WebDAV/DeltaV over HTTP or HTTPS, and a custom SVN protocol over tcp:3690 [6].

The Apache Subversion source distribution includes the mod_dav_svn module for the Apache web server. This module provides the WebDAV/DeltaV based SVN capabilities across HTTP/HTTPS using the http(s)://host/path access scheme [7].  In order to leverage existing modules within the Apache web server source distribution, the mod_dav_svn module includes the mod_dav module as part of its source inclusions. mod_dav_svn utilizes methods in mod_dav which in turn expose the vulnerable mod_dav functions noted above. Details of this relationship are provided in the next section.

4. Vulnerability Analysis

As noted above, the vulnerability is mainly due to a string length counter issue in the dav_xml_get_cdata() function of the util.c source file of the mod_dav module.  As leading whitespace is removed and the string pointer is updated, the length of the string is not updated (len variable).  This is noted in section 3.1. util.c : dav_xml_get_cdata(…).

Overall, this vulnerability will allow an adversary to inject NULLs into memory locations to cause memory corruption and denial of service. The memory utilized by the function is the Apache memory resource pool (apr_pool), which is implemented as a doubly linked list. By padding requests with whitespace to make the string size slightly less than 8KB (the page size), we can force a new malloc to be called. With a few requests to the server, the vulnerability can cause a segmentation fault (SIGSEGV) when trying to write outside process memory space, or data corruption in the header sections of the current malloc block in the Apache (apr_pool). When the Apache process or thread tries to walk the list or free memory, the corruption causes a crash with a SIGBUS signal. The remaining sections provide a detailed overview of the vulnerability and how the Apache mod_dav_svn module exposes it.

4.1. util.c : dav_xml_get_cdata( … ) 

The dav_xml_get_cdata(…) function is declared in the mod_dav.h file. Figure 7. dav_xml_get_cdata Declaration shows the declaration.

 
        Figure 7. dav_xml_get_cdata Declaration


The function variables passed to it include a pointer to XML element of type apr_xml_elem, pointer to the current memory pool of type apr_pool_t, and an integer controlling whether to strip whitespace or not. The int stripwhite variable is a critical variable. As you can see in Figure 8. Vulnerability, strip_white is checked using an if-statement. The vulnerable instructions are only executed if strip_white is a positive value yielding a Boolean True.

 
        Figure 8. Vulnerability


The pointer to the XML data passed is char* cdata and the length of this character array is apr_size_t len. Prior to reaching the vulnerable instructions, the function initially parses through the XML data (linked list apr_xml_elem *elem) finding all elements and noting the size and count.  This can be seen in Figure 9. XML Element Walk.

 

        Figure 9. XML Element Walk.


After completing an inventory of all XML elements, the function checks for quick cases where there is no element, or just one element and strip_white is set to false. Otherwise, it allocates enough memory using apr_palloc(pool, len+1). This can be seen in Figure 10. Memory Allocation.

 

        Figure 10. Memory Allocation

Note that both cdata and s point to the same Apache apr memory pool. After allocating enough memory, all the XML elements are copied into the allocated Apache apr memory pool buffer. This is shown in Figure 11. XML Element Copy.

 

        Figure 11. XML Element Copy

After completing the copy, a check is made whether to strip leading and trailing whitespace from the buffer. At this point, cdata points to the beginning of the buffer.  As shown in Figure 8, the while loop walks across the buffer incrementing cdata if whitespace is found. Keep in mind that the len variable is not decremented as cdata is incremented. Next, the trailing whitespace is removed and the length is decremented for each trailing whitespace. Finally, a NULL is written at the end of the string using the length variable len. Knowing this, any whitespace introduced at the beginning of the XML element input will cause a shift to the end of the buffer tracked by the len variable. 

This allows an adversary to inject leading whitespace and cause the NULL value to be written (when not causing a SIGSEGV) into arbitrary memory locations depending on the length of the leading white space and injected content. Keep in mind, that the vulnerable instructions are only executed when the variable flag strip_white is true. In the mod_dav implementation, this flag is only set in two function calls in mod_dav.c:

·    static int dav_method_checkout(request_rec *r)
·    static int dav_method_merge(request_rec *r)

Figure 12. Checkout Exposure and Figure 13. Merge Exposure show the mod_dav functions that call dav_xml_get_cdata() with the strip_white value set to true. This enables the vulnerable instructions allowing for leading whitespace to cause a shift in the boundary referencing by len.


 
        Figure 12. Checkout Exposure


 
        Figure 13. Merge Exposure


However, these function calls that enable the vulnerability are inherently not implemented as part of the WebDAV implementation.  Hooks are placed and the functions are exposed when mod_dav_svn is enabled.

4.2. mod_dav_svn Exposures

Requests are handled by the mod_dav_svn module as part of the SVN to WebDAV mapping. As requests are received, with mod_dav_svn module enabled, hooks are placed for the CHECKOUT and MERGE [3][4] requests utilizing mod_dav to fulfill requests. This exposes the function calls noted above. In addition, the mod_dav_svn module exposes other functions as well that utilize the same dav_xml_get_cdata() function with the strip_white variable set to true. These are listed in Figure 14. mod_dav_svn Exposures.



     Figure 14. mod_dav_svn Exposures


5. Exploitation of Vulnerability

The vulnerability can be easily exploited with basic WebDAV based CHECKOUT and MERGE requests. One can also send requests related to SVN based functions as listed above. However, the easiest approach is to just use CHECKOUT and MERGE. For the purposes of this research, we developed two small exploit frameworks that create attack payloads and subsequently send the requests along with the payloads to cause the memory corruption. The frameworks are basic BASH shell scripts that create the payloads and utilize curl [18] to send the requests via HTTP. The following sections provide an overview of both exploits.

5.1. WebDAV Checkout Exploit

The CHECKOUT exploit sends a CHECKOUT request to the Apache server.  Initially, a template (attack.template) is used to generate various payloads where whitespace is introduced. Each new payload introduces additional leading whitespace causing the shift for the end of the cdata buffer pointed to by cdata[len+1] where a NULL is written causing memory corruption. Figure 15. Checkout Payload Template shows the initial payload template used.

           Figure 15. Checkout Payload Template

We need an XML header followed by enough WebDAV fields for a CHECKOUT request. This includes the <D:checkout xmlns:D=”DAV:”>, <D:activity-set>, and <D:href> elements. The payload inside the <D:href> tag consists of 4096 A’s and a little over 4k of whitespace followed by the URL to check out. The attack-gen.sh script, shown in Figure 16. attack-gen.sh, uses the template to generate in.X payload files where X is from 1 to 300.  Once the payloads are generated, the attack.sh (Figure 17. attack.sh) will perform the attack against the Apache web server. In our testing, about 4-6 requests are needed with enough whitespace using in.30 to in.36 payloads to cause a crash as shown in Figure 18. Attack Console and Figure 19. Apache Crash.

       Figure 16. attack-gen.sh


       Figure 17. attack.sh




       Figure 18. Attack Console


       Figure 19. Apache Crash

5.2. WebDAV Merge Exploit

The MERGE exploit sends a MERGE request to the Apache server.  Initially, a template (attack.template) is used to generate various payloads where whitespace is introduced. Each new payload introduces additional leading whitespace causing the shift for the end of the cdata buffer pointed to by cdata[len+1] where a NULL is written causing memory corruption. Figure 20. Merge Payload Template shows the initial payload template used.


       Figure 20. Merge Payload Template

We need an XML header followed by enough WebDAV fields for a MERGE request. This includes the <D:merge xmlns:D=”DAV:”>, <D:source>, and <D:href> elements. Again, the payload inside the <D:href> tag consists of 4096 A’s and a little over 4k of whitespace followed by the URL to check out. The attack-gen.sh script, shown in Figure 21. attack-gen.sh, uses the template to generate in.X payload files where X is from 1 to 300.  Once the payloads are generated, the attack.sh (Figure 22. attack.sh) will perform the attack against the Apache web server. On average, about 4-6 requests are needed with enough whitespace using in.30 to in.36 payloads to cause a crash as shown in Figure 23. Attack Console and Figure 24. Apache Crash.

 
       Figure 21. attack-gen.sh


       Figure 22. attack.sh


       Figure 23. Attack Console


       Figure 24. Apache Crash

6. Patch for Vulnerability

The fix for the vulnerability is very easy. The function simply needs to decrement the len value each time a leading whitespace is found. Therefore, the source code just needs the addition of a –len; in the while loop that trims leading whitespace as shown by Figure X. Patch below.



        Figure 25. Patch
  
7. Suggestions

Signature based IDS/IPS detection can be effective for known and non-polymorphic attacks.  In our case, you can establish some signatures for the specific exploits mentioned in this paper.  The main thing to look for is a large total size for the CHECKOUT and MERGE requests, as the adversary would need to send payloads slightly less than the normal 8KB page size used by malloc to make each request effective.  In addition, the adversary is required to use leading whitespace characters prior to the actual URL in the <D:href> element. Other signatures for the REPORT and PROPPATCH requests can be created as well using similar pattern matching for leading whitespace.

More importantly, patch your system!


8. References

[1] “About the Apache HTTP Server Project,” Apache Software Foundation, 2012. http://httpd.apache.org/ABOUT_APACHE.html.

[2] “December 2013 Web Server Survey,” Netcraft, December 2013. http://news.netcraft.com/archives/2013/12/06/december-2013-web-server-survey.html.

[3] HTTP Extension for Web Distributed Authoring and Versioning (WebDAV). RFC 4918, IETF, June 2007. http://tools.ietf.org/html/rfc4918.

[4] Versioning Extensions to Web Distributed Authoring and Versioning (WebDAV). RFC 3253, IETF, March 2002. http://tools.ietf.org/html/rfc3253.

[5] “Distributed Authoring and Versioning (WebDAV) functionality,” Apache Software Foundation, 2013. http://httpd.apache.org/docs/2.4/mod/mod_dav.html.

[6]  Apache Subversion. Apache Software Foundation, June 16, 2003, http://subversion.apache.org.

[7]Subversion’s use of the WebDav/DeltaV protocol”. Apache Software Foundation, accessed December 7, 2013. http://svn.apache.org/repos/asf/subversion/trunk/notes/http-and-webdav/webdav-protocol.

[8] National Vulnerability Database (NVD). National Institute of Standards and Technology (NIST), sponsored by DHS National Cyber Security Division/US-CERT, 2013. Search for ‘mod_dav’ in CVE database: http://web.nvd.nist.gov/view/vuln/search-results?query=mod_dav&search_type=all&cves=on.

[9] “Vulnerability Summary for CVE-2013-4558”, National Vulnerability Database. National Institute of Standards and Technology (NIST), 2013. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4558&cid=1

[10] “Vulnerability Summary for CVE-2013-4131”, National Vulnerability Database. National Institute of Standards and Technology (NIST), 2013. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-4131&cid=1

[11] “Vulnerability Summary for CVE-2013-1896”, National Vulnerability Database. National Institute of Standards and Technology (NIST), 2013. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1896&cid=1

[12] “Vulnerability Summary for CVE-2013-1884”, National Vulnerability Database. National Institute of Standards and Technology (NIST), 2013. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1884&cid=1

[13] “Vulnerability Summary for CVE-2013-1849”, National Vulnerability Database. National Institute of Standards and Technology (NIST), 2013. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1849&cid=1

[14] “Vulnerability Summary for CVE-2013-1847”, National Vulnerability Database. National Institute of Standards and Technology (NIST), 2013. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1847&cid=1

[15] “Vulnerability Summary for CVE-2013-1846”, National Vulnerability Database. National Institute of Standards and Technology (NIST), 2013. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1846&cid=1
[16] “Vulnerability Summary for CVE-2013-1845”, National Vulnerability Database. National Institute of Standards and Technology (NIST), 2013. http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-1845&cid=1
[17] Extensible Markup Language (XML) 1.0 (Fifth Edition), W3C Recommendation, W3C, November 26, 2008. http://www.w3.org/TR/REC-xml/

[18] Daniel Stenberg, CURL. Haxx, 1996 – 2013.  http://curl.haxx.se.
[19] G. Stein, “Contents of /httpd/httpd/trunk/modules/dav/main/util.c,” Apache Software Foundation, February 7, 2001. http://svn.apache.org/viewvc/httpd/httpd/trunk/modules/dav/main/util.c?revision=88007&view=markup

Tuesday, January 14, 2014

NTP Cruft

Recently there have been numerous Distributed Denial of Service (DDoS) attacks utilizing the NTP protocol.This resurgence of DDoS attacks in the past few weeks have been noted by numerous security blogs, news outlets, and lists [1] [2] [3]. In addition, the folks on the oss-sec mailing list brought the issue into discussion, and MITRE assigned the issue CVE 2013-5211 [4].  Today, US-CERT/NCCIC issued TA14-013A noting the growing use of NTP for DDoS attacks and providing suggestions for mitigation of open NTP systems [5].

As originally noted by Cheetz, referencing HD Moore, NTP monlist requests return the last 600 IP addresses who queried the NTP server [6].  Attackers can leverage monlist to send crafted 8-byte NTP requests using spoofed sources to have the spoofed target receive approximately 6 packets with payload totaling 2,604 bytes [7] per NTP monlist request. In addition, the issue has been noted by Dave Hart on the ntp.org mailing list and bug tracker [8][9].  Unfortunately, it seems that the issue was resolved only in the DEV tree of NTP and not in the STABLE tree [8]. So, this is not something new.

All NTP systems publicly exposed on UDP port 123 and allowing NTP monlist requests are the culprit.  Adversaries can leverage this to send in spoofed UDP NTP monlist requests, where the responses are directed back to the targeted victim (spoofed source IP in the UDP packets). Utilized across a bot-net, the amplification would allow adversaries to cause a denial of service.

NTP systems can be hardened to not allow monlist requests. These are noted by Symantec and SANS [1] [2]. In addition, Team Cymru provides guidelines for securing NTP across popular devices and software [10]. You can scan routinely for open NTP  systems allowing monlist requests. Nmap's ntp-monlist.nse script can be used to conduct these scans [11]. So, take the time to scan your ranges routinely and follow proper guidelines to secure your NTP systems so the rest of us can sleep at night.

References:

[1] uulan. "Hackers Spend Christmas Break Launching Large Scale NTP-Reflection Attacks." Symantec Connect Blog, December 26, 2013. http://www.symantec.com/connect/blogs/hackers-spend-christmas-break-launching-large-scale-ntp-reflection-attacks

[2] SANS. "NTP Reflection Attack." SANS, ISC Diary, December 27, 2013. http://isc.sans.org/diary/NTP+reflection+attack/17300

[3] Kelly Higgins. "Attackers Wage Network Time Protocol-Based DDoS Attacks." Dark Reading, December 30, 2013. http://www.darkreading.com/attacks-breaches/attackers-wage-network-time-protocol-bas/240165063

[4] CVE Assign, MITRE. "CVE to the ntp monlist DDoS issue?" oss-sec, December 30, 2013. http://seclists.org/oss-sec/2013/q4/573

[5] TA-14-013A: NTP Amplification Attacks Using CVE-2013-5211. US-CERT/NCCIC. January 14, 2014. https://www.us-cert.gov/ncas/alerts/TA14-013A

[6] Cheetz. "Using NTP to Enumerate Client IPs." April 29, 2010. https://www.securepla.net/using-ntp-to-enumerate-client-ips/

[7] An Analysis of DrDoS SNMP/NTP/CHARGEN Reflection Attacks: Part II of the DrDoS White Paper Series. Prolexic White Paper, Prolexic, p.12-18, 2012.

[8] Dave Hart. "Remove ntpd support for ntpdc's monlist (use ntpq's mrulist)". bugs.ntp.org, April 20, 2010. http://bugs.ntp.org/show_bug.cgi?id=1532

[9] Dave Hart. "Odd Surge in Traffic Today."  lists.ntp.org, December 10, 2011. http://lists.ntp.org/pipermail/pool/2011-December/005616.html

[10] Team Cymru. "Secure NTP Template." Team Cymru, 2014. http://www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html

[11] jah. ntp-monlist NSE script. Nmap Project. http://nmap.org/nsedoc/scripts/ntp-monlist.html