|
There have been reports of a new remote information disclosure vulnerability in Apache HTTP Server, when the HTTP "OPTIONS" method is enabled and a misconfiguration occurs. While the misconfiguration trigger seems rare in production environments, the Apache .htaccess file ability enables users of virtual hosting services to intentionally introduce the bug in a shared environment and thus be able to abuse the vulnerability condition.
The bug has been assigned CVE-2017-9798 and reportedly affects the latest Apache release. There is a proof of concept example available to trigger the fault, however after hours of testing at OSI Security we were unable to reproduce the information leak. Reportedly, it only occurs in high traffic Apache websites and the examples used were from the Alexa Top 400 Global Websites, where the author noticed HTTP responses that included abnormal returned bytes of system memory outside of expected use, or HTTP server content destined for other website visitors / cached in memory. Example request: OPTIONS /index.html HTTP/1.0 Example vulnerable response: HTTP/1.0 200 OK Allow: GET,HEAD,OPTIONS,,HEAD,,HEAD,,HEAD,, HEAD,,HEAD,,HEAD,,HEAD,POST,,HEAD,, HEAD,!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd" It is clear from the disclosed example, that the Allow header should only include GET, HEAD and OPTIONS (or others such as PUT and DELETE) however the server leaks information from other memory locations. The vulnerability is reportedly triggered where the Apache server is used, with the OPTIONS request enabled, with a <Directory> definition (or a .htaccess file) which contains a e.g. <Limit GET> access control which contains an invalid method name. An example would be <Limit GETT>, as a system administrator introduced typo. At this stage the vulnerability appears to be impractical and of low risk, however we suggest checking your Apache server configuration for Limit directives which may contain errors. At the same time as this report, during a client penetration test we discovered a minimal risk/impact vulnerability in the latest release of Apache which we reported to the security team. The bug has since been patched in source code and should be included in the next stable release. The NSA ShadowBrokers exploit leak included a tool known as “BenignCertain” which triggers an information leak which may result in credential and private key disclosure to unauthenticated parties. Cisco IOS routers, PIX and ASA firewalls with VPN IKE IPSec enabled may be affected.
The NSA toolkit's bc-genpkt, bc-id and bc-parser binaries can be used to generate vulnerability triggering packets, send the packet and store the response, and parse the information leak to reveal VPN credentials such as username and password. Alternatively, the Metasploit Framework contains a module to scan for and trigger this vulnerability known as cisco_ike_benigncertain. Example: The device appears to leak RAM contents when the fault is triggered: 0000 00 00 00 00 00 00 00 02 00 00 00 00 00 00 2e e0 0010 00 00 2e e0 12 a1 fb 48 00 00 00 00 00 00 00 00 0020 00 00 09 ec 00 00 09 d0 00 00 00 01 01 00 00 0e 0030 00 00 09 c4 00 00 00 01 00 00 00 01 0b 83 d4 d4 ... [ snip ] ... 0470 0f ff ff ff 0f ff ff ff 00 00 00 00 00 00 00 00 0480 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0490 00 00 00 00 00 00 00 06 A1 44 93 40 00 00 00 00 When conducting subsequent tests, the memory bytes disclosed appear to change which indicates that this is likely vulnerable. Non-Cisco IPSec devices to not dump excessive bytes when responding to the vulnerability trigger (e.g. 10 bytes vs 2500+ bytes for vulnerable devices device). However, it is important to note that the usable exploit only affects Cisco PIX devices. This device may be vulnerable but due to slightly different implementation may be leaking less valuable information to an attacker or requires tweaking using the NSA bc-genpkt tool. Recommendation: Ensure the latest patched IOS firmware is installed. If the firmware is confirmed as vulnerable, the preshared VPN keys should also be changed and private keys on the device should be regenerated. Risk: High. Intro
The server reveals its internal IP address when specifying a WebDAV PROPFIND request. Method Issue a PROPFIND request with a HTTP v1.1 empty Host header: telnet example.com 80 Trying 123.123.123.123... Connected to example.com. Escape character is '^]'. PROPFIND / HTTP/1.1 Host: HTTP/1.1 302 Redirect Content-Length: 140 Content-Type: text/html Location: / Server: Microsoft-IIS/6.0 Date: Tue, 08 Jun 2010 07:05:08 GMT Document Moved Object Moved This document may be found here Recommendation Reconfigure IIS to return the FQDN value instead: http://support.microsoft.com/kb/q218180/ Refs OSVDB 13431 Introduction
If a PPTP service has been detected, as part of the protocol the software (and/or hardware) vendor is meant to disclose this information. Generally the server hostname is also revealed, which may aid in an attack. Method There are many ways to determine this, but a simple scenario would be to create a new "dial-up" connection within Windows with a connection type of VPN -> PPTP and connect whilst running a Wireshark packet capture. By following the captured stream within Wireshark and looking at the protocol dissector, the vendor and hostname will be disclosed. Introduction
IIS + .NET may reveal sensitive information when an exception occurs. Often this information may include the system path to the webroot (i.e. C:\Inetpub\wwwroot) which may further aid in attacks where a malicious user may upload content, but is not sure where the file is located on the remote system. Method By requesting a document with an .ashx extention, the server reveals the path (e.g. D:\sites\secret\uploads). It also reveals the version of .NET in the footer, such as "Microsoft .NET Framework Version:1.1.4322.2407; ASP.NET Version:1.1.4322.2407". The Framework version can then be used to check for known vulnerabilities, such as NULL byte issues. Recommendation Within the Machine.config or Web.config file, specify a directive of "customErrors" of either "RemoteOnly" or "On". See also: http://msdn.microsoft.com/en-us/library/h0hfz6fc.aspx 1.In Microsoft Windows, open Administrative Tools, and then click Internet Information Services (IIS) Manager.
IIS Manager appears. 2.Under Internet Information Services, expand Servername (local computer), expand Web Sites, right-click either Websitename or Default Website, and then click Properties. The Web Site Properties dialog box appears. 3.Click the Home Directory tab, and then click Configuration. The Application Configuration Settings dialog box appears. 4.Click the Debugging tab. 5.Change the radio button from "Send detailed ASP error messages to client" to "Send the following text error messages" and specify an error. |
Archives
September 2017
Categories
All
|
RSS Feed
|
|
|
|
|
|
|
OSI Security is proud to support a number of recognised charities, development projects and industry groups...
|
|
|
|
|