Intercepting HTTP and HTTPS / SSL Mоbile traffic using Burp Suite.

Burp Suite:

Burp Suite is a interceptiоn and web prоxy tооl tо perfоrming security testing оf web applicatiоns tо finding and explоiting security vulnerabilities. Burp gives yоu full cоntrоl, letting yоu cоmbine advanced security testing techniques and alsо yоu can autоmatiоn, tо make yоur wоrk easy, faster and mоre effective.

Dоwnlоad and install Burp Suite frоm here : https://pоrtswigger.net/burp/dоwnlоad.html

Cоnfiguring an Andrоid Device tо Wоrk With Burp:

Tо test web applicatiоns using an Andrоid device yоu need tо cоnfigure yоur Burp Prоxy listener tо accept cоnnectiоns оn all netwоrk interfaces, and then cоnnect bоth yоur device and yоur cоmputer tо the same wireless netwоrk. If yоu dо nоt have an existing wireless netwоrk that is suitable, yоu can set up an ad-hоc wireless netwоrk.

Set up an ad-hоc wireless netwоrk in Andrоid:

Navigate tо yоur WiFi settings, lоcated in Settings.
Lоng press the WiFi netwоrk that yоu’re cоnnected tо
Click оn Manage Netwоrk Settings
Click оn Shоw Advanced оptiоns
Under Prоxy, select Manual.

The Prоxy Pоrt shоuld say 8080, which is the default listening pоrt fоr Burp. Heads up: Just because the field says 8080 in it, dоesn’t mean it’s actually set tо pоrt 8080 (very annоying). Yоu actually have tо enter 8080 intо the field. If yоu’ve cоnfigured Burp tо listen оn anоther pоrt, cоnfigure it tо that pоrt instead.

Installing the Certificate:

Nоw that the settings оn yоur device have been cоnfigured, yоu’re ready tо install the certificate.

First check tо make sure settings have been cоrrectly cоnfigured by navigating tо http://burp оn the prоxied device. It shоuld direct yоu tо the website where yоu can dоwnlоad the certificate.

2. Click оn CA Certificate. In mоst cases, it shоuld autоmatically dоwnlоad the certificate.

3. when yоu dоwnlоad the certificate by default it will be cacert.der .We have tо change it tо cacert.cer.

4. оnce yоu’ve installed the Burp Suite certificate оn yоur mоbile device, Burp Suite is nоw trusted, and encrypted cоmmunicatiоn can nоw be decrypted when being prоxied.

5. Nоw navigate tо an HTTPS site, such as http://bugcrоwd.cоm. If Intercept is оff, yоu shоuld be able tо see the traffic in HTTP Histоry, including the cоntent within the requests that wоuld оtherwise be encrypted due tо SSL/TLS.

Cоnfigure the Burp Prоxy listener:

In Burp, gо tо the “Prоxy” tab and then the “оptiоns” tab.In the “Prоxy Listeners” sectiоn, click the “Add” buttоn.

In the “Binding” tab, in the “Bind tо pоrt:” bоx, enter a pоrt number that is nоt currently in use, e.g. “8080”.Then select the “All interfaces” оptiоn, and click “оk”.

The request shоuld be intercepted in Burp.

Cоnfiguring an IОS Device tо Wоrk With Burp:

Tо test web applicatiоns using an IОS device yоu need tо cоnfigure yоur Burp Prоxy listener tо accept cоnnectiоns оn all netwоrk interfaces, and then cоnnect bоth yоur device and yоur cоmputer tо the same wireless netwоrk. If yоu dо nоt have an existing wireless netwоrk that is suitable, yоu can set up an ad-hоc wireless netwоrk.

Set up an ad-hоc wireless netwоrk in IОS:

Set yоur iPhоne tо use the Burp prоxy. Yоu can dо this by gоing intо yоur wireless netwоrk settings and selecting “Manual” under “HTTP PRОXY”. Then, just fill in the details.

Installing the Certificate:

First check tо make sure settings have been cоrrectly cоnfigured by navigating tо http://burp оn the prоxied device. It shоuld direct yоu tо the website where yоu can dоwnlоad the certificate.
Click оn CA Certificate. In mоst cases, it shоuld autоmatically dоwnlоad the certificate.
Install the certificate. Click “Install”, enter yоur PIN, and yоu’re all set.

Cоnfigure the Burp Prоxy listener:

In Burp, gо tо the “Prоxy” tab and then the “оptiоns” tab.In the “Prоxy Listeners” sectiоn, click the “Add” buttоn.

In the “Binding” tab, in the “Bind tо pоrt:” bоx, enter a pоrt number that is nоt currently in use, e.g. “8080”.Then select the “All interfaces” оptiоn, and click “оk”.

The request shоuld be intercepted in Burp.

Nоw yоu shоuld be able tо оpen any app оr website оn yоur iDevice and see the plaintext traffic in Burp оr Charles. This will help yоu understand the data the applicatiоn sends and receives as well as the endpоints оn the server side. But even better, nоw yоu can repeat netwоrk requests, change parameters and оbserve hоw the server reacts, alsо edit data as cоmes back frоm the server and оbserve the app’s behaviоur with the mоdified respоnse.

How To Use Noisy To Hide Your Browsing Habits

We’ve explored several tools on previous tutorials, which allow you to protect your browsing data from others through the use of VPNs. They help us by allowing all traffic to be rerouted somewhere else; therefore all traffic we generate will look as if coming from another location, wherever our VPN server is located at. Now, we’re going to take a different approach.

In this tutorial we will discuss how we can use automated tools that generate random traffic from our host computer. For this, we will look at Noisy. A Python script created by Github user 1tayH, that generates random HTTP(S) and DNS noise traffic in the background while you browse the web; therefore providing extra obscurity from anyone looking for browsing patterns.

Installing Dependencies

Before we begin installing the script, we need to verify whether we have the correct version of Python installed on our system. As you can see in the screenshot below, as long as we have either Python 2.7 or 3.6, we’ll be good to go.

You can use the python -V, python2 -V, or python3 -V commands to verify the versions of Python that are installed in your computer.

As you can see, we already have both versions of Python. Namely 2.7 and 3.6, which means that we’re ready to continue.

Next up, we need to install the requests python library with the following command:

Installation

Following the installation of dependencies, we’re ready to download the script by using the git clone command.

We can now go into the noisy/ directory, and list its contents:

Noisy Usage

In order to understand how Noisy works, we can open the config.json file with a text editor.

We’re mainly interested in the contents of the root_urls parameter, which contains a list of the websites to which Noisy will be making requests.

As we can see, the default list is quite small. We can make it better by adding more websites to it. Thankfully, Github user holdTheDoorHold has compiled a quite large list of websites that can be used, and set them up in config.json file that we can download from the NoisyConfigg repository. You’ll notice the file is 26 MB in size.

If we click on the View Raw link, we can see its contents, similarly to the screenshot below.

From here, we can go ahead and create a backup of the original configuration file.

Next, we need to download the new configuration file into the appropriate directory. For this example, it is under the noisy folder in the home directory of the currently logged-in user.

Upon this, the contents of the folder should be as such:

To run Noisy, enter the following command.

Remember that Noisy is a Python script, which is why we need to call the Python interpreter first. The –config flag tells Noisy to use the config.json configuration file, which is given as a parameter.

Once we run the command, we can see that Noisy is automatically generating requests to the websites listed in the configuration file.

To stop execution of Noisy, press Ctrl+C at any time.

You can view the Help options by using the –help flag.

Conclusion

From what we’ve done, you can see that Noisy is a really simple way to create diversions in order to mislead anyone who might be spying on our traffic; in attempts to generate a profile, based upon our browsing habits.

One important thing to note is that Noisy will generate a new request every second. This is relatively good for most uses. However, we can do much better than that, by spinning up a few docker containers, which would allow us to generate even more requests per second.

That way, anyone inspecting the network packets for our device will have a much harder time defining any potential browsing patterns from the data they collect. We will look into how to do that in the next section.

Moving Forward

First, we need to install Docker. Since we’re using Kali Linux for this tutorial, we can install it with apt:

Next, we need to check the status of the docker service, starting and enabling it if needed.

Once docker is running, we can check the current working directory for Noisy, where we will find a Dockerfile that we can use to build a Docker container, like so.

Remember that you need to build docker images as root! If you don’t you’ll likely see this error message. If you’re not logged in as root, you can enter the sudo command as a prefix to docker.

From the second screenshot, you’ll see that the Docker image was built successfully. We can now run the docker images command, as root, to get a list of currently available images.

Following the requirements for Noisy, we now need to install the docker-compose package, as it’s needed to run the containers for Noisy properly.

Once installed, we can go into the examples/docker-compose/ directory inside the noisy/ folder. Here we’ll find the docker-compose.yml file, which will help us run our Noisy instances.

From here, we can run the docker-compose up –scale noisy=10 command. The up parameter tells docker-compose to run the container image. The –scale flag with the noisy=10 parameter tells Noisy to use 10 instances, therefore allowing us to generate 10 requests per second.

You will then see that each of our containers will be named as noisy_N, where N is the index of each of the 10 containers we created for this example. Remember, of course, that you can run as many or as few containers as you want, as long as your computer has the processing capabilities to sustain such loads.

If we run a packet inspection utility, such as Wireshark, we will notice that there are hundreds, even thousands, of requests being generated by Noisy.

On the following 2 screenshots, take a close look at the Time column. You’ll notice that, in just under 80 seconds, Wireshark has already detected close to 15,000 packets transiting outside and inside our computer; with our host having the 192.168.10.105 IP address.

Finally, if you want to stop all of your Noisy containers, you just need to go to the terminal window where you started them, and press Ctrl+C, like so. It may, however, take a bit until all containers are fully stopped.

How to Build an ARP Network Enumeration Tool Using Python

Welcome back my fellow hackers! We’ve covered host discovery tactics before; specifically, we’ve covered ping scans and ARP scans. But we didn’t go very in-depth when we covered ARP scans. Today we’re going to dive head first into this enumeration tactic by building our own ARP sniffer!

This tool will use ARP to find other hosts on the network, that way we know who our neighbors are. We’ll be writing this tool in Python, so brush on that if you haven’t already. We’ll also be using the Scapy library for manipulating the packets. We’ve already covered the basic usage of Scapy, so if you don’t know (or just need a refresher) you can find it here. First we’ll go through the script chunk by chunk and explain what everything does, then we’ll test our script to make sure it works. So, let’s get started!

Building the Script

Step 1: Path and Imports

Our fist step is very simple, we’re going to set the interpreter path, and import most of the libraries we’ll be using:

Now this actually looks way more complicated than it is. We start by setting our interpreter path (#! /usr/bin/python), and then we get to importing modules. First we take the entire sys module, then we take datetime out of datetime. Now here’s the weird part. Since Scapy is a third party library, not everyone will have it installed on their machine, so we need to take that into consideration when building our script.

Instead of import Scapy directly, we place it within a try/except block, so that if the import fails (since it isn’t installed) there aren’t errors spilled everywhere. This keeps everything nice and tidy. Within the try/except block we import getLogger and ERROR out of the logging module. We then run the getLogger function as seen above. This will stop Scapy from spilling out its own errors when we import it. We then import everything from Scapy, and set the conf.verb to zero. This will stop Scapy from throwing out messages that packets and been sent and received, which also helps keep things clean. Now that we have all our importing done, we can get to the fun stuff!

Step 2: Declaring the Class and Setting up

In order to make sure this script is as clean as possible, we’re going to keep all the functions for our sniffer inside a single class:

We’ve named our class ArpEnumerator. Next, we define our __init__ function. This function will automatically run when a new instance of this class is made. This is where we can set up variables that will be used throughout the entire class. We’ve taken quite a few arguments in our __init__ function, don’t worry about these for now, just note that the default value for all of them is False.

Now we can set up the variables for our class. We start by simply copying all our arguments into variables that share the same name. Now we can access these arguments across the whole class. Next, we declare a dictionary, but we leave it empty. We will use this to keep track of the hosts we find later. The filter variable is simply set to the string of “arp.” This is a good time to mention that this script will also have a passive mode, in which it doesn’t sent any packets, but still listens for them. This filter will change later to fit the needs of the user. Our final variable is simply the value of the datetime.now function. This will allow us to track when the enumeration starts and stops, so we can tell the user how long it took. Now that we have all our variables set up and ready to rock, let’s move on.

Step 3: Making the Functions

In this step we’re going to create all the functions that our class will use. They are relatively simple, so they should all fit nicely under one section. First, we’re going to make the functions to handle passive mode:

This function serves as a sort of packet handler for the sniffing we’ll be doing later. First, it checks to see if this host is already in our dictionary of discovered hosts, if it is, we move on, if it is not, we print the IP address and the MAC address of the newly discovered host, and place it in the dictionary. This function does nothing on it’s own, it is designed to be used in our next function:

The function seen above will actually perform the sniffing. We start by checking the range variable we set earlier to see if it contains anything. If it does contain something, we edit the filter variable and add the desired range of addresses to it. This way the attacker can sniff for a specific range of addresses, or all the addresses at once. Now that we have our filter ready to go, we call the sniff function inside of a try/except block. We set our filter, and our handler function. We also set store to zero, since we won’t be inspecting these packets any further.

The reason for try/except block is that sniffing in an indefinite process. Once it starts, it will not stop until the user forcibly interrupts it. Since we placed it inside our try/except block, we can handle keyboard interrupts, and properly stop the sniffing. Once our sniffing is complete, we report that sniffing has stopped followed by the duration of the sniffing. Now that we have our passive portion complete, we can move on to the active portion:

This functions gets a little more complicated than the others. First, we tell the user that we’re beginning the scan. Then, we use the srp function from Scapy to send out ARP requests for all the hosts in the range of addresses provided by the user. Once we’ve gathered all the response packets, we store them in the ans variable (note that we’ve also built a try/except block to handle any errors that occur). Now that we have all our response packets stored in a list, we iterate through them and store them in our dictionary of discovered hosts. We also print out the addresses of the host while we store them. Once this iteration is complete we tell the user the scan is done and stop the clock for the scan duration.

We’re almost done here so just stick with me! The final function of our class does not effect the sniffing in any way, but it’s a nice little added feature:

This function simply opens a new file (named by the user) and writes the contents of the discovered hosts dictionary to it. This way the user can output the results to file very easily! Now that we have our class and functions ready to go, let’s use them!

Step 4: Input and Execution

You may think it’s a little weird that we’re taking input so late in the script, but it’s actually not. We’re going to be using another module called argparse in order to take command line arguments in a very clean and easy manner:

If you feel intimidated by this large chunk of code, don’t. It’s just importing argparse and setting up all our arguments. I’m not going to go through and talk about every single argument, as they should be very self-explanatory since we just built the functions that use them. Let’s move on:

Now we just have to do a few checks before to execute our scan. Here, we check the arguments given to make sure everything lines up. We check for a specified network interface, and then we check to see if a range is given for the active scan (since the active scan is required to have a range). Now that we’ve made sure everything is in order, we can finally execute our scan:

We use some basic if statements to find what kind of scan our user wants, and then we create a new instance of our class under the enum variable. Once we’ve got the scan type figured and the class instance created, we execute our scan! Now that the scan is complete, we need to see if the user wants to output the results to a file:

That does it, our script is complete! Now that we’ve spent so long building it, we can finally test it!

Testing the Script

We’ll start by view the help page that argparse generates for us:

Looking good! Let’s go ahead and test the active scan, we’ll also output the results to a file named enum.txt:

We started a scan looking for all addresses within the 10.0.0.0/24 range, and it worked! We also successfully output our results to a text file, let’s check that file to make sure it went well:

Excellent. Our scan worked and our output file looks good. Now that we know the active scan works, let’s give the passive scan a try:

It works! It’s worth noting that passive sniffing will normally take a rather long time. I had mine running for a few minutes and only managed to catch two hosts. The perks of passive sniffing is that no packets are sent out, so the victim has no way to tell that they’re being watched! This helps us prevent tripping security devices such as an intrusion detection system, which can be set off by sending too many packets at once.

There we have it! Our script works like charm. Now that we’ve got our hands dirty and built our very own ARP enumerator, we should have a much deeper understanding about how ARP enumeration works. Remember: The best way to learn how something works, is to tear it apart and build it yourself!

How Hackers Redirect Web Traffic with DNS Spoofing

Welcome back my fellow hackers! There have been some articles I’ve been wanting to write regarding social engineering, more specifically, stealing passwords. But, in order to do that, there are some basic concepts and methods we needs to have a grasp of. The first of these concepts is Man in the Middle Attacks. Since we’ve already covered that, we’re going to cover the next concept, DNS spoofing. First, we’ll cover what DNS is exactly, then we’ll quickly discuss the anatomy of the DNS spoofing attack, and finally, we’ll perform the attack! So, let’s get started!

What is DNS?

This question is actually fairly simple. DNS stands for Domain Name System. You know when you go to a website using a browser, you type in a URL instead of the IP address of the server? That’s DNS working it’s magic! What DNS does is it keeps track of what IP addresses reside at what URLs, that way we don’t have to remember the addresses, just the URLs! Pretty neat, huh? Like I said, DNS is fairly simple, so let’s move on to the next part, the anatomy of a DNS spoofing attack.

Anatomy of a DNS Spoofing Attack

Since this can be a bit difficult to talk about without a reference, we’re going to be dissecting this attack based on this diagram:

As we can see here, the attacker starts by pretending to be the DNS server. Then, when the victim requests the address for the desired site, the fake server responds with whatever address the attacker wants, which in this case, directs the victim to a fake site. This attack is very simple, but can often play a part in a larger attack. Now that we know the ins and outs of DNS spoofing, let’s perform it ourselves!

Performing a DNS Spoofing Attack

Setting up the Attack

Before we really get started, there are a couple of things that we need to prepare. Namely, we need to prepare the fake website, and set up the configuration file for the DNS spoofing tool.

Let’s start by setting up the website. First, we’ll whip up some basic HTML code so we actually have a site. We’ll be using gedit. The proper file can be opened with the following command:

Now that we have our file open, just go ahead and erase everything in it. I’ll be replacing it with the following:

Feel free to replace the words with whatever you like, as long as you follow the HTML tags, everything should be fine.

Now that we have our website’s HTML code ready, we can go ahead and start the server that will serve the website. We’ll just be using the pre-installed Apache2 webserver, which can be started with the following command:

Now that we have the site up and running, we need to quickly edit the configuration file for the DNS spoofing tool. We’re just going to be modifying the /etc/hosts file and using it for our attack. We can open the file with the same command we used previously, but with the new file path. Once we have the file open, we can set up the file to tell the spoofing tool what sites we want to spoof. Before we do that, we need to know our local IP address, which we can find with the ifconfig command:

We can see that our local IP address is 10.0.0.16. Now that we know it, we can edit the file. We’re just going to be adding this line:

The line we added (the bottom one), will tell the spoofing tool that we want www.hackingloops.com to be redirected to our local IP address, which will then serve them our website instead of the real one! That’s it for the setting up, now it’s time to execute the attack!

Executing the Attack

Now, if we’re going to be redirecting traffic that isn’t ours, we need to be able to read it. This is where the Man in the Middle Attack comes into play. We’re going to place ourselves between the victim and the gateway, so that all of the victim’s DNS requests have to go through us. We can then sniff these requests and redirect them with our spoofed responses! To start, we need to know the gateway’s IP address, which we can find with the route command with the -n flag:

We can see by the above output that the address of the gateway is 10.0.0.1. For the sake of keeping this relatively short, we already have our victim’s address, which is 10.0.0.13. Note that all these addresses are on the same network. This form of DNS spoofing only works if the victim is on your LAN. Now that we have the addresses, we can start the Man in the Middle attack (finally)! We’re going to be using arpspoof for this attack, and we’ll be using the -i, -t, and -r flags to specify the interface to attack on and the addresses to attack:

Once we execute this, the MitM will start.

DO NOT FORGET: You must enable IP forwarding, so the data from the victim doesn’t get hung up on the attacking system. This can be done with this command: echo 1 > /proc/sys/net/ipv4/ip_forward

Now that we have our MitM running, we should have all the victim’s traffic flowing through the attacker system. Since we can see all this traffic, we can start the DNS spoofing tool (dnsspoof) to listen for DNS requests for www.hackingloops.com and respond to them with our IP address! Let’s go ahead and start dnsspoof now. We use the -i flag for giving an interface, and the -f flag for giving the path to the hosts file. The command to start the attack should look something like this:

We can see that dnsspoof is now listening for UDP traffic on port 53 (port 53 is the DNS port, and UDP is the transport protocol DNS uses) from all address but our own! Now that our attack is up and running, let’s move over to our victim PC and try and access www.hackingloops.com from a web browser:

Now, before we celebrate, let’s look back at dnsspoof to see the output:

There we have it! We were able to start a Man in the Middle attack, and use it to perform a DNS spoofing attack, which redirected a legitimate request for www.hackingloops.com to our fake website!

There are multiple reasons for this article. For one, we’ll be needing these attacks very soon in order to steal passwords from an unsuspecting user. Secondly, it’s a proof of concept of sorts. It shows that these smaller attacks (MitM, DNS spoofing, etc.) aren’t just one trick ponies. We can combine these attacks to achieve even greater things. Many times, when performing an actual hack, you will need to combine many different kinds of attacks at once to achieve a goal, this just proves that. I’ll see you next time!