Dark Tips: Setting Up an Evil Twin Wireless AP (Part 1)

When conducting a security audit, you should also make sure to test any wireless networks that may be setup. As these networks do not always require direct, physical access within the building housing the wireless access points, they can be exploited by someone in their car or even a pesky neighbor. In this tutorial, we will be utilizing Kali Linux in order to create an Evil Twin wireless access point, which can be useful in both testing the current wireless setup along with testing the human element of security.

An Evil Twin AP is a wireless AP that appears to be legitimate, sometimes even using the same SSID as another AP in the area, but allows an attacker to both view and control the data sent to/from any clients connected to it. Once connected to it, users typically would not suspect anything as they are able to successfully access any network assets and/or the Internet. Unfortunately for them, you are the Man-in-the-Middle and have visibility and control over their data packets.

Please note: The following tutorial is being tested against my own access point, and these steps should ONLY be performed against your own access point, or one you have been authorized to test against.

I. Equipment Needed
You will need a fairly decent wireless adapter in order to successfully perform this attack during an audit. I am currently using the Alfa AWUS036NH USB wireless adapter. This is perfect for using with Kali Linux, as it comes with the proper drives thus allowing you to get started quicker. You will also, naturally, need to be running Kali Linux.

II. Getting Started
Before we get started, you should go ahead and connect to a network that has Internet connectivity. You can do this via Ethernet or via WiFi. For this example, I will be connecting to a separate SSID of mine via my internal wireless card (wlan0). If you choose to use Ethernet, then in some of the example commands you will need to replace "wlan0" with "eth0."

Unless you already know the target SSID that you will be mimicking and the corresponding channel that it is operating on, you will need to run a quick wireless scan and determine that information. This can be quickly accomplished via the following command:

iwlist wlan1 scanning
After documenting both the SSID and channel of the target, let's enable our Alfa card to run in Monitor mode:

airmon-ng start wlan1
III. Configuring the Evil Twin
With the SSID and broadcasting channel of our target, we can begin by creating our own access point that will utilize this same information. This is done via the following command:

airbase-ng -e [Target's SSID] -c [Target's Channel] mon0

In this example, we are mimicking the SSID "SkyNet," which I have setup for testing.

Now you will need to configure the IP address and subnet mask for your access point. If you happen to know the IP scheme of your target, possibly by authenticating to it previously, then you should use its IP scheme.

ifconfig at0 up
ifconfig at0 [IP Address for Our AP] netmask [Subnet Mask for AP]

Next, we need to configure DHCP to run on our Evil Twin. Again, you should use the IP scheme of your target if you know that information already. Before enabling DHCP, we need to create a config file that we will be using. The following is the config file that is being used for this example:

     # Google's DNS servers
     option domain-name-servers 8.8.8.8, 8.8.4.4;
     default-lease-time 600;
     max-lease-time14400;
     option T150 code 150 = string;
     deny client-updates;
     one-lease-per-client false;
     allow bootp;
     ddns-updates off;
     ddns-update-style none;
     authoritative;
     # DHCP Scope & Configuration for our AP
     subnet 192.168.1.0 netmask 255.255.255.0 {
     interface at0;
     range 192.168.1.30 192.168.1.40;
     option routers 192.168.1.250;
     option subnet-mask 255.255.255.0;
     option broadcast-address 192.168.1.41;
     option domain-name-servers 8.8.8.8;
     allow unknown-clients;
     }

Using this configuration file, we can now we can enable DHCP on our AP:

dhcpd -d -f -cf /etc/dhcp/RogueAP_DHCPD.conf at0 &
IV. Configuring IP Forwarding
While we now have an access point that clients can connect to and obtain a proper DHCP address from, they still cannot connect to any network/Internet resources. In order to allow this, we will need to configure IP forwarding. This will allow anyone connecting to the fake SSID to have their connection routed through our other network adapter (wlan0).

We first need to add a static route and configure our access point's IP address as the local gateway.

route add -net [Network of our AP] netmask [Subnet mask of our AP] gw [AP's IP address]

Next, we can configure IP tables to accept routing using the following commands:

iptables -P FORWARD ACCEPT
iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
Finally, we activate IP Forwarding in the kernel by changing the value within the corresponding configuration file.

echo "1" > /proc/sys/net/ipv4/ip_forward
If you have followed all of these steps correctly, you should now have a functional Evil Twin access point that is mimicking the appearance of the targeted AP. Anyone connecting to what they believe is a legitimate access point will now have their data packets routed through your PC to the corporate network and/or Internet.

Tune in for part two where we go over some possibilities now that you have gained control over the clients' connectivity. To be continued...

Read More

Dark Tips: Brute-Forcing Web Logins with Hydra

If you ever find yourself doing a security assessment, you might run into a situation where you will want to brute-force the credentials to a web-based application. While initiating brute-force attacks against protocols like Telnet or FTP are fairly simple to setup, web-based logins can be a bit finicky. This is due to the fact that not all web logins accept credentials in the same manner, which will require a bit more work on your end. Let's go through an example to better understand this.

Standard web-based login page.
The first thing you will need to do is take a look at the source code of the login page itself. While you don't have to be a web designer in order to perform this task, it does help if you at least have a basic understanding of web code. It may vary from application to application, but you essentially need to find the code snippet that is responsible for actually submitting the credentials you have provided to the system itself. One of the easiest ways to do this is to search the source code for words like "password."

In the above example, you can see that line 139 contains exactly what we are looking for, and shows the URL that is used in order to submit the credentials to the system. Breaking it down to a more easily understood format, we end up with the following URL:

./cs57eb2e1b/config/System.xml?action=login&user=[USERNAME]&password=[PASSWORD]
Now that we have the URL that is being used to submit the credentials that we provide in the login page, we can perform a manual test with our web browser. We need to do this for two reasons. One being to verify that the URL we have obtained is correct, and the other is to discover what return string we will receive from the system in the event of a bad password. This is required to have prior to performing the brute-force with Hydra.

As you can see from the above image, the URL appears to be correct as we did not receive any "Page Cannot Be Found" or similar errors. We were also able to obtain the return string for a failed password, which is "Bad User or Password." Now that we have all of this information, we can begin using Hydra.

Assuming that you are utilizing Windows, you will need to download a compiled version for your OS. For this example, I used this one. You should also download a wordlist to be used with Hydra, preferably one that contains both usernames and passwords within it. There are far too many options available on the Internet for me to list just one, so you will need to search around until you find one that you like.

Now that you have Hydra installed, and have a wordlist to use, you can begin your brute-force attack against the web-based login. For this attack, we will be specifying Hydra to use the http-form-get service, due to our research earlier into how this login page submits credentials. We will also configure Hydra to use the URL that we discovered, and to pull the USERNAME and PASSWORD from the wordlist used. Knowing that an incorrect password returns the string "Bad User or Password," we will also add that into Hydra. Failing to do so will prevent Hydra from being able to determine a successful password from a failed one. With all of this information, our Hydra command should look something like the following:

     hydra -C Credentials.txt -t 1 -w 30 [Target IP] http-form-get "/cs57eb2e1b/config/System.xml?action=login&:user=^USER^&password=^PASS^:Bad User or Password"

Hydra should now begin its brute-force of the login page, going through each of the credentials within your wordlist. Looking at the packets with Wireshark confirms that Hydra is functioning correctly.

You can see that Hydra is going through each of the credentials in the wordlist correctly.
Depending on the size of your wordlist, this could take some time to complete. If you are lucky, however, you should eventually receive a response from Hydra showing that it has been able to determine the correct credentials for the application. Now you can login and move forward with your security assessment.

Read More