By default the Play! Framework web service will disclose the version number used which can aid an attacker in conducting targeted attacks using known vulnerabilities.

To hide the version number, modify the conf/application.conf file and set the directive http.exposePlayServer to equal ‘false’.

The HTTP Strict-Transport-Security standard (HSTS) is a HTTP server header sent by SSL/TLS enabled websites to prevent communication over HTTP in order to protect content and authentication cookies from interception or alteration.

To enable this header on the nginx web server, modify the nginx.conf file. Within the server block, find and edit the location block and set the "add_header" directive with a value of e.g. Strict-Transport-Security "max-age=31536000"; (for 365 days).

E.g:

server {
 location / {
  add_header Strict-Transport-Security "max-age=31536000";
​ }
​}

This is a quick email to bring your attention to a recently publicised OpenSSL security vulnerability known as "Heartbleed". The Common Vulnerabilities and Exposures list has assigned CVE-2014-0160 for this issue.

The vulnerability is currently being exploited in the wild on a small scale.

The vulnerability is a memory disclosure bug. That is, a malicious user can send a trigger packet to an HTTPS service with a vulnerable OpenSSL instance, and the server will respond with the raw memory contents of the HTTP server (such as Apache) or OpenSSL.

Examples include:

1. Revealing the SSL private key, such as .PEM file.
2. Disclosing cached contents of the HTTP/S server, such as username and password sent over SSL to authentication forms.
3. Data stored within the HTTP/S server, such as source code, database connection strings, and information normally only accessible as an authenticated user logged in to the system.
4. Internal memory addressing and security defence mechanisms.

The issue is not only HTTP/S related, but may include other protocols which implement OpenSSL functions (such as SMTP/S, POP3/S etc).  

Am I vulnerable?

Only OpenSSL versions 1.0.1, 1.0.1a through to 1.0.1f are vulnerable. Version 1.0.1 was released March 2012. Version 1.0.1g was released today and is immune (many distributions have not yet released updates, but they should become available within 24 hours). Versions prior to 1.0.1, such as 1.0.0 and the 0.9.x variants do not include this specific vulnerability.

You can check what version you have by running openssl with the version switch:

# openssl version
OpenSSL 1.0.1f 6 Jan 2014 (vulnerable)

This bug is specific to OpenSSL only. Microsoft products may not be affected, however Windows products which utilise OpenSSL may be affected. Most Linux and unix variants utilise OpenSSL. 

It is worth determining what risks this presents to your organisation. As the private key can be compromised and traffic decrypted, consider whether a new private key should be issued and signed by CA (once the server has been patched).

Introduction
Often you will find yourself in a situation where you can upload arbitrary content to a web server.
If the webserver accepts dynamic content (e.g. ASP, PHP, EXE, PL, etc) then you may want to upload a "backdoor shell" to provide a web based GUI for the command line.

Method
Examples include;

• ASPX Shell by LT
• c99 / c99shell.php PHP shell by Pedram
• Metasploit payloads

Recommendation
None - however keep in mind the following:
1) The backdoor shell may be trojaned. Read the code FIRST!
2) Don't leave it there for too long, as someone else may find it or worse - Google may index it!

The server is running the PHP programming language which is configured to expose details about the target host. This information may be useful to an attacker in determining the software versions installed.

Example HTTP response header:

• X-Powered-By: PHP/5.4.16

Example URLs:

• https://[target]/?=PHPE9568F35-D428-11d2-A769-00AA001ACF42 
• https://[target]/?=PHPB8B5F2A0-3C92-11d3-A3A9-4C7B08C10000 
• https://[target]/?=PHPE9568F34-D428-11d2-A769-00AA001ACF42 

Recommendation:
Modify the php.ini file and set the directive 'expose_php' to 'Off' and restart the service.

Risk:
Low.

Introduction
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.
​
Technique

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:

$P$BNCFzhkOgblRnMahSc8aRW.2O2oCYZ0

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
$P$BNCFzhkOgblRnMahSc8aRW.2O2oCYZ0:aaron
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.

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
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

Introduction
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.

Method
It is possible to provide an arbitrary "url" value.

http://mail.[victim].com/exchweb/bin/auth/owalogon.asp?url=http://[attacker]/Exchange&reason=0
​
Recommendation
Informational only. Microsoft expects this to be resolved in Exchange 2007.

Introduction
The portal requires users submit a username and password to authenticate. This communication is not encrypted.

Method
Check the HTML source code on the form page, and examine whether the FORM ACTION is GET/POST to a HTTPS:// URI.
​
Recommendation
1) Enable SSL and disable HTTP for the portal
2) Use two-factor tokens (one time password) for strong authentication.
3) Modify the HTML source to ensure the data is POST'ed to a HTTPS URL.

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.