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.
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.
Please be aware there is a Samba remote code execution vulnerability that has been published today in Metasploit and mass exploitation is likely to follow or be used to self-propagate in the form of a worm.
The vulnerability affects all versions of Samba over the past 7 years, the open source Unix/Linux implementation of the Microsoft File and Print Sharing service, and a patch was released yesterday.
The vulnerability is triggered by connecting to a writeable file share (it can be abused as an anonymous user or with credentials) then uploading a Unix .so shared object file which is then executed on the server.
Many Linux and Unix based operating systems are vulnerable, as are products like NAS (Network Attached Storage) file servers such as Synology, mediacentres and modems etc.
CVE-2017-7494 has been assigned to this issue and reports indicate over 100,000 internet accessible systems are currently vulnerable.
If you are unable to patch immediately, the vulnerable feature can be disabled by setting the 'nt pipe support = no' directive within the /etc/samba/smb.conf file and restarting the service.
The web server has directory listings enabled, which may reveal folder contents that might otherwise be hidden from an attacker looking for sensitive information,
Modify the apache2.conf file and set the folder “Options” directive to -Indexes, so that directory indexing is disabled and restart the service.
WordPress versions equal or greater than v2.5 use a salted hash to prevent Rainbow Table attacks, based on the work by Solar Designer. Previous releases (v2.4 and below) use an MD5 unsalted hash.
To verify a salted hash is used, you can check the contents of the wp-includes\class-phpass.php file.
The hash is stored in the MySQL database, inside the wp_users table.
If you're able to crack the hash, then you can simply log in to the /wp-admin/ page with the correct password and administer the website. Alternatively, it is common to discover that people re-use passwords in other locations, so the plain-text password may be used for the cPanel installation or the MySQL database root user.
There are a few tools out there which support PHPass salt and hash.
One example is hashcat, which can be downloaded from http://hashcat.net/hashcat/.
The software comes pre-compiled, with versions for both 32bit and amd64 architectures, and Windows and Linux binaries.
There is also the optional GUI which can be downloaded from http://hashcat.net/hashcat-gui/
In our example, we are running a Linux operating system.
So lets say you've managed to recover the admin hash from the wp_users table, which in our example is:
Create an empty text file and paste the hash into the document and save the file as 'hash.txt'. Next, run hashcat with '-m 400' which is the PHPass / WordPress cipher mode and provide a suitable dictionary file.
Note: the .bin extension is for Linux operating system. Use the .exe files for execution under Windows.
$ ./hashcat-cli64.bin -m 400 hash.txt /usr/share/dict/cracklib-small
Initializing hashcat v0.43 by atom with 8 threads and 32mb segment-size...
Added hashes from file hash.txt: 1 (1 salts)
Activating quick-digest mode for single-hash with salt
NOTE: press enter for status-screen
All hashes have been recovered
The example hash password is 'aaron' – we can then login to /wp-admin/ as 'admin' with password 'aaron'
It is worth noting that hashcat supports dictionary, bruteforce, hybrid and other modes. Use the '--help' switch for further information.
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.
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.
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
The version of Outlook Web Access contains a URL redirection vulnerability. However, this would require user interaction to be abused such as embedded URL within an email that is clicked on.
It is possible to provide an arbitrary "url" value.
Informational only. Microsoft expects this to be resolved in Exchange 2007.