Tuesday, 8 April 2014

OpenSSL "Heartbleed" Vulnerability

You may have already seen reference to the OpenSSL 'Heartbleed' vulnerability which was published this week (http://heartbleed.com/).

If you have not yet seen this advisory, this is a very serious vulnerability in OpenSSL version 1.0.1 through 1.0.1f inclusive, and when exploited this bug allows a connecting attacker to retrieve sensitive memory contents from affected servers.

Exploitation of this vulnerability will allow an attacker to retrieve the private keys used by vulnerable servers, and consequently decrypt past and future traffic, and impersonate the service at will. Following the retrieval of the key material, the protection offered by the use of encrypted connections is nullified, and protected content (including personal data, usernames and passwords) may also be compromised.

The researchers who have identified the vulnerability are unsure whether it is currently being actively exploited, but the attack leaves no obvious trace in logs and consequently there is no way to ascertain whether systems (and key material) have been compromised. OpenSSL versions in the wild have been vulnerable to the attack since March 2012.

OpenSSL is, of course, widely used and a number of your applications may be affected. We strongly recommend that you take action to identify any OpenSSL-based services within your infrastructure that are vulnerable to this attack via their version, including web servers, VPNs, email and instant messaging systems.

All vulnerable OpenSSL installations should be upgraded immediately, or recompiled to prevent heartbeats - see https://www.openssl.org/news/secadv_20140407.txt

Following this, all key material that was exposed on vulnerable servers should be replaced - certificates should be revoked and reissued for public-facing services since these keys may already have been compromised.

Where applications have been protected by vulnerable OpenSSL versions, all existing session cookies and tokens should be considered compromised and invalidated. Passwords and other secondary encryption keys protected by vulnerable services should also be considered compromised, and users should be encouraged to change these details once certificates have been replaced.

Please contact us for further advice or assistance.

Wednesday, 5 February 2014

Obtaining NTDS.dit Using In-Built Windows Commands

Further to our article on Password Audit of a Domain Controller, we've discovered a couple of short-cuts that greatly simplify the process.

Using the same underlying technique (Volume Shadow Service), there is an in-built command (Windows 2008 and later) that does a backup of the crucial NTDS.dit file, and the SYSTEM file (containing the key required to extract the password hashes), without the need to use VB Script, third-party tools or injecting into running processes.

All you need is a command prompt running with administrator privileges, and the following commands:

C:\>ntdsutil
ntdsutil: activate instance ntds
ntdsutil: ifm
ifm: create full c:\pentest
ifm: quit
ntdsutil: quit



Copy/move the created folder from the target DC to your machine, and you have all necessary files to conduct an offline password audit of the domain.

If you want to perform in-depth analysis of the directory (e.g. group membership), we'd currently recommend esedbtools and NTDSXtract as per our last post. If you're running Windows, there is a new tool on the block - named ntds_decode.exe (referenced here - http://insecurety.net/?p=884), which seems to work fine in our lab, without requiring a number of rather convoluted steps to achieve our goal. Unfortunately source code isn't available at this moment in time, so take normal precautions before running.