Patch Scanning with MBSA
February 22, 2010 by Dan_Holton · Leave a Comment
If you can’t verify a security control is in place… then don’t count on it being in place. In talking to a friend, a large part of his company’s security protections relied on their firewall, Anti-virus, and patching. As we dug deeper into it, I found that they don’t really review the firewall logs, and both the AV and OS/Software patches were pushed centrally, but that’s where their process ended. They did no verification to make sure that the patches were successfully installed. Unfortunately, this practice of not validating the company’s protection mechanisms is fairly common.
Not every company can justify running out and buying Retina, or Shavlik’s NetChk, but it’s hard to argue with just getting an initial scan done to gague the existing patch status using a free tool like Microsoft’s MBSA (Microsoft Baseline Security Analyzer.) If you haven’t looked at this tool recently (or have never looked at it), it’s work checking out. Let’s start with the negative. It only scans against Microsoft systems, it only scans against some Microsoft products (it won’t tell you if users are running vulnerable versions of Adobe Reader or FireFox), and you need to run the scan with an account that has administrative privileges on the system being scanned.
Now for the good stuff. MBSA can scan a single system, IP range, or all of the computers in your domain. It offers a gui and command line options. In addition it not only scans for missing Windows patches, but it scans for missing SQL and IIS patches, as well as common configuration vulnerabilities. These common configuration vulnerabilities include things like weak password configurations, enabled guest accounts, firewall status, whether IIS sample applications are installed, SQL install folder permissions, CmdExec access, and more. With the quality of the scans, I think that (after proper testing), most small buisnesses should look at performing a scan of their whole network, and mid-large companies that don’t validate their patch status should at least look into performing scans against their key systems (you may be surprised at what you’ll find.)
Okay, so with that… let’s take a look at the tool. To begin with, MBSA can currently be downloaded from here: http://technet.microsoft.com/en-us/security/cc184924.aspx.
The download and installation is straightforward, so I won’t go over it here. After installing and lanching MBSA, you’re presented with a screen asking if you want to scan one computer, multiple computers, or view the reports from previous scans. If you select to scan multiple computers, you’re presented with the following window which lets you select what domain/IP range you want to scan, and what you want to scan for.
Then just click “Start Scan” and let it run. The reports are easy to read, and have links to more information on what was checked, and how to fix errors.
After the scan completes, you’ll be able to view the reports from the main page.
Details to the problem found, and steps to fix it are available for each issue by clicking the link below it.
The command line tool (mbsacli.exe) is installed by default in the same directory that MBSA was installed to. It can be ran by just opening a command prompt in the directory where mbsacli.exe is located, and running
mbsacli /r 192.168.1.1-192.168.1.101
(where /r stands for range, and the IP range you want to scan is specified after it)
mbsacli offers additional options for specifying the username and password to use to connect to the remote computer, as well as what checks to run. The scan results can be viewed from the command line, or from the gui tool.
Verifying Checksums
February 9, 2010 by Dan_Holton · Leave a Comment
These days, it’s not uncommon to download a known application from an unknown source. It may be because the site uses multiple download mirrors (many linux distributions are downloaded this way), because the software was downloaded from a torrent, given to you by a friend, or for any number of other reasons. The good news is that it’s also not uncommon for software writers to post a checksum of the software on their website, to give users a way of validating the software. This checksum does no good if you don’t actually check it, so here are very easy steps on how to do that.
What does the cheksum do for us? Let’s say that we have a program that was created by ABC corp. We trust that they didn’t do anything malicious to the file, and they’ve posted a link to download the file, along with the checksum of the file on their site. When you actually go to download the file, you’re taken to numerous download sources. You download the file from XYZ corp, but you want to make sure that you’re getting the file just as ABC corp wrote it, and not any malicious code that an intern hacker at XYZ corp decided to add to the code. In addition, verifying the checksum can help make sure that you don’t have a corrupted version of the file. Any changes (even adding a single space somewhere) will make the resulting checksum very different. So after you download the file, you generate a checksum of that downloaded copy, and compare it to what the creator of the file said it should be. As long as the two values match, you can be reasonably sure that no one has modified the file.
To validate a checksum, you’ll need three things. You’ll need a utility that can generate the checksum, the actual file that you want to validate, and the checksum of the file as defined by the provider of the file.
First, you’ll need software that can generate a checksum. Many Linux distributions include one of these by default. For Windows, Microsoft provides the File Checksum Integrity Verifier (FCIV) as a separate download (currently located here: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=b3c93558-31b7-47e2-a663-7365c1686c08). Once you’ve downloaded and extracted this file, open a command prompt, and go to the directory that the extracted file was saved to.
Second, from the command prompt, you’ll tell fciv what file you want to validate the checksum for. For this example, I want to validate an installer on the network for Python version 2.6.4. Curently, the Python site http://www.python.org/download/releases/2.6.4/ has the MD5 checksum for the .msi install listed as being 2e2b60ae73e9e99cd343a3fe9ed6e770.
To validate this, I return to the command prompt that we opened earlier which is in the directory where fciv.exe is downloaded to. Type the command
fciv.exe <file to verify>
for example
fciv.exe C:\Tools\Python\python-2.6.4.msi
(note: due to weaknesses that were found in MD5, many files are now posted with the SHA1 hash as well as the MD5 hash. To get fciv to generate the SHA1 hash, just add a “-SHA1” flag at the end of the command. For example, the above command would now be “fciv.exe C:\Tools\Python\python-2.6.4.msi -SHA1”
This results in the hash being returned. As we can see, this hash is the same that was listed on the python download page. This quick step helps make sure that the file we’re running hasn’t been tampered with or accidentally corrupted.
Built in Windows Port Re-director
January 3, 2010 by Dan_Holton · Leave a Comment
The other day I was in the situation pictured below. Basically I had a command shell with admin privileges on Server1. What I really wanted was RDP (Remote Desktop) access to Server2, but I didn’t have direct access to it due to firewall restrictions. In this particular situation, trying to install any 3rd party tool would have been problematic. So what I needed was a built-in port re-director.
Luckily for me, the web server was installed on a Windows 2008 server. Windows 2008 installs with IPv6 by default, so it supports the netsh portproxy command, which does just the port redirection I was looking for. (Note: The portproxy command is actually serviced by the IPV6MON.DLL, so IPv6 needs to be installed for the redirection to work.)
In this situation, the initial firewall had port 8080 opened but unused to the web server. It’s important that the port be unused so no valid/noticeable traffic is interrupted. The problem was that the firewall between the web server and the back-end server I was trying to get access to was configured to only the web server’s IP through. The port restrictions coming from the two IPs’ to the inside host weren’t as restrictive as they should have been, but that’s another story.
By typing the command:
netsh interface portproxy add v4tov4 listenport=8080 connectaddress=192.168.1.59 connectport=3389
I went from:
The initial connection directly to Server2 fails
To:
Attempting to connect to Server1 on the proxied port
Server1 successfully proxies the request to Server2
Perfect.
What’s wrong with an LM Hash?
December 23, 2009 by Dan_Holton · Leave a Comment
I’ve heard that storing the LM hash is a bad idea. Why?
Hmmm, where to start.. To begin with, before hashing the password, all lower-case characters are converted to upper case. This significantly reduces the number of hash combinations that need to be attempted to crack the password. When looking at the reduced character set, we can add in the fact that LM supports ANSI characters, as compared to the full unicode character set supported by NTLM (142 characters vs. 65,536). Secondly the passwords are all exactly 14 characters. For passwords less than 14 characters, they are padded with null characters. To make things worse, instead of storing a full 14 character password, the 14 characters are broken into 2, 7 character passwords. Obviously it’s much harder to crack one 14 character password than it is to crack 2 7 digit passwords. As a side note, I should point out that it’s commonly mentioned that the LM Hash isn’t really a hash. It’s actually a (weak) one way function. The two 7 byte halves are used as keys (after being combined with parity bits) to encrypt an ASCII string. The resulting cyphertext values are combined to form the 16 byte value that is used as the LM Hash.
Password Salts
December 23, 2009 by Dan_Holton · Leave a Comment
Salting a password. As we’ve already discussed it the “Obtaining Windows Password Hashes” article, when you set your password (using Microsoft Windows as an example), it hashes your password, stores the hash, and then discards the actual password you supplied. So when user1 sets their super secrete password to “password”, the system will hash it, and end up storing the resulting hash. The problem with the way windows generates this hash, is that it doesn’t utilize a salt. A salt would prepend an additional value to the password before it is hashed. So instead of generating a hash for “password” a hash is generated and stored for (as an example) “<domain\username>+password”. This does a few things for us. First, it immediately invalidates any pre-generated list of hashes (rainbow tables.) Secondly, since every user has a different salt, an attacker can’t generate a single rainbow table to attack every account on a system. A separate table would need to be generated for each account. The nonce combined with a strong password, and (hopefully) lack of LM hash makes using rainbow tables an increasingly costly, and decreasingly effective attack.
While Windows doesn’t salt passwords for local or domain users, it does utilize a salt when storing cached credentials. Cached credentials are used to log on domain users when they aren’t connected to the domain. The common example for this is a laptop user who is traveling. While outside of the office, they can’t contact a domain controller, so the only way for windows to verify their login is by using a local verifier. This locally stored password verifier is known as a cached credential. This cached credential is actually the password salted with the user name (and domain name where applicable.) In addition to being salted, the cached credential (or password verifier) is also hashed twice, so is actually a hash of a hash. This makes cracking the password take a significant amount of time longer then cracking the LM/NTLM hash.
Cracking the hash
December 23, 2009 by Dan_Holton · Leave a Comment
After obtaining the password hash (for ways to do this, see the article here), we have to figure out what the password actually is. Well, okay, depending on what you’re trying to accomplish, you may be able to just pass the hash, but for the sake of this article we want to find out what the password actually is. The attack types we’ll look at here are:
- Dictionary
- Brute force
- Rainbow Table
A Dictionary attack attempts to find the password by using a word list. This is typically just a text file with each word to test listed on a separate line. When performing a dictionary attack in Cain, additional attack options are available. For example, number substitution (5ecrete, 3ncrypt), and appending numbers to the end of the dictionary words (password1, secrete20). The word list included in the default install of Cain currently includes over 300,000 words, and there are even larger lists available online. To make word lists even more effective, consider using lists for other languages, or lists that include common industry jargon.
Cain Dictionary Attack
Dictionary attacks typically run fairly quickly, but are ineffective against passwords not based on a dictionary word. For example, a dictionary attack is unlikely to find the password &&Fw!WIDK*@.
Personally, I like to run dictionary attacks when auditing internal user’s passwords, and as a quick first line attack. This type of check is typically most appropriate for auditing internal users since the goal there is to make sure user’s are following best-practices (i.e. not using dictionary-based words, or their own names), and not necessarily to obtain their passwords.
The next type of attack we’ll cover is the brute force attack. This attack attempts to take a defined character set (i.e. abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789), and tries to combine them in every possible way until the correct combination is found. As you would expect, this attack would take a prohibitively large amount of time to complete. This attack can be a reasonable option if you suspect the password may be a short one, or using a restricted character set. Due to limitations in the way an LM Hash is generated (breaks the password into 2, 7 character chunks, and converts all letters to uppercase), if the LM Hash is present, then a brute force attack is a fairly reliable way to get the password. In environments with strict password requirements (letter of varying case, number, and special character along with > 8 character length), brute force attacks tend to succeed much less often due to the amount of time it would take to try all permutations.
Cain Brute Force Attack
Finally, a rainbow crack uses a pre-generated table of hashes to identify the password. RainbowCrack (downloadable at http://project-rainbowcrack.com/index.htm#download), can generate rainbow tables for various algorithms and charsets. The power of using a rainbow table is in the fact that it can crack non-dictionary based passwords in a matter of seconds. These tables can be quite large. For example, the rainbowcrack site shows the table holding the hashes for just lowercase passwords up to 9 characters long is 28GB. Rainbow tables can be defeated by systems that implement a salt on the passwords before storing them. They are also ineffective against passphrases or long + complex passwords. Even with the downsides associated with rainbow tables, with the drop in storage space (it’s not hard to find 1TB drives for less than $100), it can be an effective option.
To generate the tables, you’ll need to download rainbowcrack. The download and instructions for generating tables are available from here http://project-rainbowcrack.com. The basic steps for generating rainbow tables are to use the rtgen executable to make the tables, and then using rtsort.exe to sort them so that they’ll be usable.
The syntax for rtgen is ‘rtgen hash_algorithm charset plaintext_len_min plaintext_len_max table_index chain_len chain_num part_index’. Typically you’ll break the tables apart, so will need to run the table generations in chunks. For example:
rtgen ntlm ascii-32-95 1 7 1 3800 33554432 0 rtgen ntlm ascii-32-95 1 7 2 3800 33554432 0 rtgen ntlm ascii-32-95 1 7 3 3800 33554432 0 ... <etc>
note: This will limit the hashes to being generated for passwords up to 7 characters in length. If you’ll be using this for purposes other then testing, you’ll likely need to increase this limit.
Then after the tables are generated, you’ll need to sort them by running rtsort.exe <filename.rt>.
At this point, we have working hashes, so all we have to do is actually use them to crack a hash. You can use rcrack to do this by typing ‘rcrack <path to .rt file> -l <path to hash file>’. For example
rcrack c:\users\dan\hack\rt\tables\*.rt -l c:\hashlist.txt
Another option is to use Cain to attack the hash. I like this option since we used Cain for the other attacks, and this lets us keep all of the hashes/results in one place. To use Cain, return to the Cracker tab, and right-click on the user/s you’d like to crack. Select Cryptanalysis Attack > NTLM Hashes > via RainbowTables (RainbowCrack).
Cain RainbowTable
Click the Charsets button, and browse to the charset.txt file that was included in the rainbowcrack download. Then click on the ‘Add Table’ button, and select all of the .rt files that you generated. Then just click the start button to start the crack. While a strong/long password or passphrase can defeat rainbow tables, it’s a nice attack in the sense that it was able to crack passwords like ‘aZ!&$C5′, and ‘H0L3S#!’ in under a minute.
Obtaining Windows Password Hashes
December 21, 2009 by Dan_Holton · Leave a Comment
When attempting to determine the password on a windows system, the first step is to get access to the hashed version of the password. Notice that I said that you’re trying to get the hashed version of the password, and not that you’re trying to get the actual password. This is an important distinction to make, and one that sometimes causes confusion in people new to the topic.To be clear, if you configure your login password as “mYpasSword”, windows doesn’t store that string somewhere. What it does is pass the password through a hash function, and stores the resulting hash. A hash is a mathmatical function that that takes input and returns a fixed block bit stream. The resulting stream is very different even with slight changes to the password. (note:The following examples are generated with the MD4 hashing algorithm.)
So, for example, if a user configures their password to be ‘cat’, the resulting hash that windows would store would be ‘1c3ea6f2b8cf5653460ddf549a52ff4b’. Some important features of any cryptographic hash function are:
- Making a small change to the password has a significant change on the hash. For example, the password for ‘bat’ would be: ‘f1af0722af2b86261ae6956048ff0fc6′.
- The resulting hash is a fixed string. So longer passwords don’t result in longer hashes. The password ‘&&$ks0(–REALLYLONGPASSWORDEXAMPLE904903$$’ results in a hash of ‘47e738e4225a494e39f8b7a8014ffe3c’
- Generating the hash for the same input will consistently give you the same output. This is why some (non-windows) systems salt passwords… a topic we’ll get into a little later.
Okay, so how do we get to the hash? Typically, you’ll need one of two things. Either you’ll need admin access to the system storing the hash, or you’ll need physical access to the system. We’ll extract the hash of a windows 7 system using both of these methods. Note: Even though all of the following examples are done on a Windows 7 system, they will still work on older versions of Windows.
If you have admin access to a system, then one of the easiest ways to get access to the hash is with one of my favorite tools, Cain and Abel. You can download Cain and Abel from http://www.oxid.it/cain.html. As you can see, this tool offeres a LOT of features related to password cracking including options to perform dictionary, brute-force, and rainbow attacks against hashes. If you don’t know the difference between these, you can read about them here.
After you’ve downloaded and installed C&A on the system storing the hashes you’d like to discover, just launch Cain from the programs list. On Vista/7 you’ll need to right-click on Cain and select the option to run it as administrator.
The main page looks like this:
Select the Cracker tab, and then click “LM & NTLM Hashes” from the long list of options on the left. Note all of the other options including cracking MD5, SHA1, CHAP, and WPA-PSK Hashes.
Click in the blank area of the window and hit the insert button (or right-click and select add to list).
Leave the “Import Hashes from local system” radio button selected and click Next.
There are two VERY important things to notice with the result from my test machine below.
- All of the LM hashes show as the same. This is because by default, Windows 7 (Vista too) no longer enable the storage of the LAN Manager credentials by default! This is a VERY nice thing to see from the security side (not so nice for the attacker), since LM was so insecure. If you aren’t running Vista or 7, you can manually disable the storage of the LM hash by following the instructions here.
- The NTLM hash values for user1 and user2 are the same. You may think this is expected since their passwords are the same. Unfortunately, Windows 7 still doesn’t take advantage of a password salt, which would result in the same password generating a different hash. This simple mechanism defeats many hash attacks, and has been in use by other systems since the 70’s. Note, I’ve seen a LOT of confusion about salts, so I’ve written a small blurb about them to (hopefully) help clarify this subject a bit more.
Now that we have the hashes, it’s time to try to figure out what the passwords are. Since we’re using Cain for this, we can do this discovery right from the same window. Just right click on the hash you’d like to test (or hold control and select multiple hashes), and select the type of attack you’d like to perform against the hash. I’ve given an overview of each of the different attack types in the article Cracking the Hash.
You can still easily get the password hashes from a system that you do not have admin access on if you have physical access to the system. This is done by using a bootable CD, and then accessing the hashes outside of windows.
One popular option for attempting to get the hashes this way is Ophcrack (available from http://ophcrack.sourceforge.net/). Since a lot of articles on this site will rely on the BackTrack, we’ll be using it to get the hashes in this demonstration.
BackTrack is a bootable linux build that comes pre-loaded with tools useful for penetration testing. It can be downloaded from http://www.remote-exploit.org/backtrack_download.html. After downloading and burning it to a CD, you should be able to BackTrack from the CD and run it without making any changes you your installed OS. This process is fairly straight forward, so I won’t go into details about it here. After you’ve booted to backtrack (you can type startx at the prompt to launch the gui if you want to have it up for easier exploration), we’ll need to do three things.
First, we need to make our windows drive accessible. To do this, we’ll create a mount point, and mount our system drive. In my test system, the windows partition was on /dev/sda2, but your location may vary. To make the mount point, type
mkdir /mnt/a
Then to actually mount your windows partition, type
mount -t ntfs /dev/sda2 /mnt/a
That should allow you to successfully browse your windows files.
Next we’ll need to recover the syskey bootkey from the system hive. We’ll need this key to decrypt the SAM file (which is encrypted with 128 bit encryption) which is where the password hashes live. The syskey provides an added layer of security between you and the hashes in the SAM database. BackTrack already includes the tool we need to get the syskey, which is bkhive. From the command prompt run
bkhive /mnt/a/Windows/System32/config/SYSTEM out
That should successfully extract the needed key.
Finally, we just need to take the key retrieved in the last step, and use it to dump out our hashes. We’ll use the samdump2 app to do this.
samdump2 /mnt/a/Windows/System32/config/SAM out
will dump all of the user hashes on the system.
(Note: The above image truncates the output of the hash. Storing the result directly into a text file as demonstrated below will keep the entire hash.)
This can be copied into a text file easily by doing this:
samdump2 /mnt/a/Windows/System32/config/SAM out > hashes.txt
At this point we’ve successfully retrieved our hashes, both from within windows using a privileged account, and from a bootable CD taking advantage of having physical access to the system.
Now the fun begins. To actually discover the passwords from the found hashes, we can use a number of methods, all covered in the article “Cracking the Hash“.