Category Archives: How do I test for …

The short answer is that it is a cryptographically hashed representation of a password.

The blank LM hash

The string “aad3b435b51404eeaad3b435b51404ee” is the LM hash for ‘no password’.  In other words, its empty.  Typically it could be seen at the top of a hash dump from windows and would look something like this:

Administrator:500:aad3b435b51404eeaad3b435b51404ee:8118cb8789b3a147c790db402b016a08:::

(before anyone asks – no, that’s not a real administrator hash)

What format is a pwdump in?

That excerpt is from a pwdump file generated by a tool commonly used in penetration tests and other cyber security assessments. It is just text-based output and so is just about human readable. The pwdump file has the following format:

<Username>:<User ID>:<LM hash>:<NT hash>:<Comment>:<Home Dir>:

More details about the LM hash

The hash above indicates that there is no LM hash for that user, but that there is an NTLM hash.  Typically if you see lots of  “404ee” at the end of the LM part you are up against a Windows 2008 (or later) domain which never required backwards compatibility.  This is because LM hashes are very easy to crack and are now considered obsolete. For this reason they are disabled by default in newer installations.  The file format still has them for backwards compatibility.

You might have also noticed that these is some repitition in the LM hash:

aad3b435b51404eeaad3b435b51404ee

In the LM hash above there are two sets of “aad3b435b51404ee”. This repetition is present because in Microsoft systems, this hash is actually two different hashes concatenated together. The result of this repetition from a user’s perspective is that their password is split into two chunks at a maximum length of 7 characters each and only contains uppercase characters. Both of these qualities make LM hashes very easy to crack.

The blank NTLM hash

The following text is the same thing, but for the newer NTLM hash:

31d6cfe0d16ae931b73c59d7e0c089c0

The blank hash in a Linux shadow file

Similarly, on Linux the following shows a user account with a blank password in the shadow file:

guest:U6aMy0wojraho

Linux is much more capable that Microsoft Windows in this area and so the ways to represent a user with a blank password can vary.

More reading…

If you are still interested in this topic, you can find lots of detail in this Wikipedia article.

The easiest way to find poor implementations of SSL and TLS encryption algorithms is to run the SSL Scan tool.  If you run it against this website you will get something along the lines of:

sslscan --no-failed www.yg.ht:443
_
___ ___| |___  ___ __ _ _ __
/ __/ __| / __|/ __/ _` | '_ \
\__ \__ \ \__ \ (_| (_| | | | |
|___/___/_|___/\___\__,_|_| |_|

Version 1.8.2
http://www.titania.co.uk
Copyright Ian Ventura-Whiting 2009

Testing SSL server www.yg.ht on port 443

Supported Server Cipher(s):
Accepted  SSLv3  256 bits  DHE-RSA-AES256-SHA
Accepted  SSLv3  256 bits  DHE-RSA-CAMELLIA256-SHA
Accepted  SSLv3  256 bits  AES256-SHA
Accepted  SSLv3  256 bits  CAMELLIA256-SHA
Accepted  SSLv3  168 bits  EDH-RSA-DES-CBC3-SHA
Accepted  SSLv3  168 bits  DES-CBC3-SHA
Accepted  SSLv3  128 bits  DHE-RSA-AES128-SHA
Accepted  SSLv3  128 bits  DHE-RSA-SEED-SHA
Accepted  SSLv3  128 bits  DHE-RSA-CAMELLIA128-SHA
Accepted  SSLv3  128 bits  AES128-SHA
Accepted  SSLv3  128 bits  SEED-SHA
Accepted  SSLv3  128 bits  CAMELLIA128-SHA
Accepted  SSLv3  128 bits  RC4-SHA
Accepted  TLSv1  256 bits  DHE-RSA-AES256-SHA
Accepted  TLSv1  256 bits  DHE-RSA-CAMELLIA256-SHA
Accepted  TLSv1  256 bits  AES256-SHA
Accepted  TLSv1  256 bits  CAMELLIA256-SHA
Accepted  TLSv1  168 bits  EDH-RSA-DES-CBC3-SHA
Accepted  TLSv1  168 bits  DES-CBC3-SHA
Accepted  TLSv1  128 bits  DHE-RSA-AES128-SHA
Accepted  TLSv1  128 bits  DHE-RSA-SEED-SHA
Accepted  TLSv1  128 bits  DHE-RSA-CAMELLIA128-SHA
Accepted  TLSv1  128 bits  AES128-SHA
Accepted  TLSv1  128 bits  SEED-SHA
Accepted  TLSv1  128 bits  CAMELLIA128-SHA
Accepted  TLSv1  128 bits  RC4-SHA

Prefered Server Cipher(s):
SSLv3  256 bits  DHE-RSA-AES256-SHA
TLSv1  256 bits  DHE-RSA-AES256-SHA

In that long list you are looking for any old cipher suites that have known cryptographic weaknesses.  For example any which use “SSLv2”.  You possibly want to also identify any symmetric algorithms that have a bit length smaller than 128 and a-symmetric algorithms that have a bit length smaller than 2048 as well.

It is important to keep relatively up-to-date with the various cipher suites available as over time weaknesses are found in older suites making them vulnerable to attack.  There are, for example, currently questions and indeed vulnerabilities for some of the encryption algorithms that are in popular use today.   Lookup the BEAST attack and the RC4 problems and decide for yourself what you would do.

Keep in mind that the list of known “good” and “bad” ciphers changes pretty often.

*** UPDATE *** The tool demonstrated above has changed significantly since this article was published as a result of many additional cryptographic qualities that need checking. The current version of SSLScan can be found here

YGHT can help you increase your cybersecurity

Learn how by contacting us

Testing bad cookie attributes is nice and simple.  There are automated tools that will alert you if these are not set.

But it is good to understand the technical detail as well.

So from an automated point of view, you could use a proxy such as the Burp Suite that is designed for web application testing. If it sees a cookie being set that isn’t given the “HttpOnly” flag, it will tell you.  The same applies for cookies that are provided over an SSL connection (i.e. when the pages are returned over HTTPS) that don’t have both the “HttpOnly” flag and the “secure” flag set.

• The “HttpOnly” flag tells the browser that the only way the cookie can be accessed is over the HTTP protocol.  In other words, no requests from Javascript etc are allowed.
• The “secure” flag tells the browser that the only way the cookie can be accessed is over an SSL encrypted connection.

Even if you don’t want to use an automated tool, you are looking for the same items.  In the response header provided by the server, you should see a header declaration “Set-Cookie:”. After which you will have the name of the cookie and the value that it is being set to.  The crucial bit is immediately after this as it should have the relevant flags set.

Cookie flags are important because they are used as an identifier for the server to recognise the user.  By recognising the user, the server is able to maintain a “session”.  This session holds details about the users experience with that web application.  For example, when a user logs into a web service, their session is recorded on the server as being an authenticated session.  If I were to gain a copy of someone elses session cookie, I would very easily be able to send that to the server and impersonate the user who the cookie belongs to, gaining access to everything the legitimate user had access to.  As a result it is vital that these session cookies are kept safe.

YGHT can help you increase your cybersecurity

Learn how by contacting us