Expanding upon Rohit Kohli’s article (link to InfoSec article), A Look at ARP, this article will cover ways to leverage an ARP spoof attack and springboard to new attack surfaces. Sniffing someone else’s traffic can allow an attacker to view and record that traffic, but how can sniffing traffic be used to further an attack? It is recommend to have a solid comprehension of Kohli’s article before reading or attempting any of the attacks described here. As always, further reading is available at your nearest Internet search bar… all problems have solutions that can be answered with enough coffee, time and googling 🙂 Tool Chain
Ettercap is a newly revived open source ARP based man-in-the-middle attack suite (with GUI available). Ettercap provides a means to expand an ARP attack with additional modules such as black hole routing, DNS spoofing, and a handful of others. This article will use the command line interface (as I have found the GUI to be buggy and crash often) without any additional modules. Wireshark is the de facto GUI based network sniffing application. It places a network interface into promiscuous mode allowing the card to sniff all network frames on a LAN segment, including those not destined for the card. SSLstrip is a Python script created by Moxie Marlinspike. It requires the twisted web Python module to run. The tool watches traffic for HTTPS requests and then redirects and forces the connection to run over HTTP. The script uses a Linux command line firewall called Iptables to redirect all traffic from the HTTPS port (443) to the HTTP port 80. For the script to run correctly an attacker needs IP forwarding enabled on a Linux machine and a single active Iptables rule. Iptables is a packet filtering tool that can be used to create ACL or NAT rules for a Linux device. This article will use Iptables to assist SSLstrip in routing an ARP spoofed victim’s traffic through an attacking laptop. Hamster/Ferret are two pieces of code written by Errata Security. These two tools work as a team to listen on a network interface for web traffic that includes HTTP cookie related headers and present them to a user for replaying.
Preparing the attacking machine IP forwarding is a Linux kernel option that enables IPv4 packet forwarding. This option is usually disabled by default and it is generally a good idea to keep this option disabled. Devices that use the packet forwarding option would include routers, firewalls, and other (network) devices that focus on packet inspection. In the upcoming attack scenario this article will be routing victim traffic through an attacking machine. The attacking machine’s kernel will need the IP forwarding option turned on. This can be accomplished with a single command as seen below: [code] echo 1 > /proc/sys/net/ipv4/ip_forward [/code] /proc is a virtual directory created when the Linux operating system boots. It is located in memory and contains some interesting information about processes, kernel options, memory usage, device statics, and other bits and pieces the kernel needs to keep track of to properly operate (sorry, about the rant. It’s hard to talk tech without showing my love for Linux). If you want to know more about the inner workings of a Linux machine, /proc is a great directory to cd through – you’re destined to find some interesting files. For the attack scenario described in this article to work , the following Iptables rule must be active on the attacking machine [code] iptables -t nat -A PREROUTING -p tcp –destination-port 80 -j REDIRECT –to-port 53535 [/code] Breaking this rule down, we have the -t option which references the NAT table (built in), it consists of three routing chains (similar to the older Ipchains tool) pre-routing, output, and post-routing. The -a option references the chain this command will use and appends (hence the a) the rule to the end of the routing rules chain. The -p option matches the protocol, in this case TCP. The –destination-port option forces the rule to match against packets that are destined for a listening port 80. These include requests made to a web server by a browser that requests “gmail.com” or “mybanksite.com” as a URL instead of “https://gmail.com” or “https://mybanksite.com” (and how many people actually type the full https?). A web server will usually respond to these types of request with a redirect to port 443, informing the browser the request it made should be re-requested over an encrypted protocol. Continuing along in the command, the -j option determines which action should be taken when the rule is matched by a packet. In this case the action is to REDIRECT the packet to a different port which is provided by the –to-port option. We give the –to-port option the port number that SSLstrip is listening on. Continuing the preparation for the attack, a machine must have the SSLstrip code downloaded from Marlinspike’s home page found at http://www.thoughtcrime.org/software/sslstrip/ (the code can be wget’d directly from http://www.thoughtcrime.org/software/sslstrip/sslstrip-0.9.tar.gz). No compiling is needed for this tool, but Python is a system requirement to interpret Marlinspike’s scripts. To install Python on a Debian based Linux run the following command as root [code] aptitude install python [/code] Before running SSLstrip an attacker would need to install python-twisted-web module. This is a common package in most distribution repositories. On Debain-based Linuxes (or is the proper pluralization Linuces?) run the following command to install the twisted web module [code] aptitude install python-twisted-web [/code] An attacker could now start SSLstrip by running the following command [code] python sslstrip -k -f lock.ico -l 53535 [/code] This command runs the SSLstrip script with the options (-k) to kill and renegotiate current HTTPS connections, (-f) to use a favicon to attempt to reassure the user it is using a secure connection and (-l) to assign a listening port on the local system. A favicon image can be placed in the tab of all HTTP connections. Marlinspike has included a lock icon that might assure a victim the connection being used is secure. For more info on Iptables or SSLstrip check out Keatron Evan’s article (link to his article on Advanced Tutorial: Man in the Middle Attack Using SSL Strip – Our Definitive Guide) on the tools. At this point any TCP packets destined for port 80 from the attacking machine will be inspected by the Iptables rule, redirected to the SSLstrip program, and then passed onto the wire. Download and compile the Hamster/Ferret tools by visiting http://erratasec.blogspot.com/2009/03/hamster-20-and-ferret-20.html or directly at http://www.erratasec.com/erratasec.zip. Extract the folders and compile the tools. I built them by navigating to the build/gcc4 directories and running [code] make [/code] After compiling the source, both executables (for hamster and ferret) can be found in the bin directory of their respected parent directories. The Attack Once an attacker has the SSLstrip script running and the Iptables rule active that will redirect HTTPS to HTTP, an attacker could ARP spoof a victim machine and impersonate the victim’s default gateway. Ettercap could complete this man-in-the-middle ARP spoof attack. The following command (must be run as root) will middle any connections between two IP addresses using an ARP spoofing technique. [code] ettercap -Tqi wlan1 -M arp:remote /192.168.1.100/ /192.168.1.1/ [/code] This command will (-Tq) run ettercap in quiet text mode, (-i wlan1) use the wlan1 interface (-M arp:remote) ARP spoof remote connections between 192.168.1.100 and 192.168.1.1. 192.168.1.1 is intended to be the default gateway for 192.168.1.100. Any browser requests made from 192.168.1.100 that should be over the HTTPS will be in clear text, allowing an attacker to watch all the traffic with Wireshark. At this point any TCP packets destined for port 80 from the attacking machine will be inspected by the Iptables rule, redirected to the SSLstrip program, and then passed onto the wire, same as before. The only difference now is that the attacking machine is acting as a proxy to the victim’s machine. This creates a scenario where a victim is sending an attacker HTTP requests and an attacker is passing the requests on as HTTPS requests to the destined server.
Pivoting from the attack In October 2010, a Firefox plugin called Firesheep was released. Firesheep’s intention was to be used on an open WiFi network (think McDonalds or Starbucks). The Firesheep plugin would sniff for clear text HTTP session negotiations. Firesheep would then allow the user of the plugin to complete a session riding attack against a victim with the sniffed Cookies. This attack worked by presenting a real session identifier of an authenticated user of a web application to the web application’s server. After a client initialized a TCP connection to an HTTP server, the client sends a request message to an HTTP server. The server will respond with a HTTP status code (200 OK if no errors were encountered with the clients request), the file the client requested, and additional HTTP headers. HTTP headers are a means for HTTP clients and HTTP servers to include additional control data within responses and requests. For example, a request can include what language the response should be in or what the requesting browser version is (for compatibility purposes). A response can include headers such as when the page content expires (instructing the browser’s cache when to consider the content stale), the date the response was sent and cookies the browser should remember (a string the browser sends back to the server with each request moving forward). HTTP headers included in responses and requests can easily be seen by opening Wireshark, assigning Wireshark the correct network interface, and browsing to a website. A web request is easier to find if you type ‘http’ in the filter dialog box to filter out everything except HTTP.
Cookies are used by web servers to keep track of browser requests. They are used because HTTP is a stateless protocol meaning it provides no method of tracking communications. Cookies can have variable expiration times, but most, if not all, web application cookies will expire when a user initiates the log off feature. By sniffing for the Set Cookie header of an HTTP response, an attacker can copy the response and impersonate the requesting client, thus hijacking the account. This attack can be defeat easily by adding encryption to the HTTP connection so that the Set Cookie header string is encrypted. Fortunately, this attack scenario has a means of bypassing this security control. By stripping the encryption from the HTTP response an attacker is once again able to read the Set Cookie header string. Since the HTTP is a stateless protocol, web servers need a way to remember which connections are “signed in” to an application. Web application developers use session identifiers for this. Sessions often use cookies so that a web browser can be closed or restarted without forcing a user’s session to end and keeping a user remained “logged in” to an application. Once a user initiates (click on) a “log out” of the application the server marks the session identifier as expired. The session identifier cannot be used after it has expired. Until a session expires, an attacker can steal a session identifier and ride off of a legitimate session, thus impersonating a legitimate user’s connection to a web application. To fix the vulnerability Firesheep exploited, web applications force encryption on the entire communications by using the HTTPS even when a user is not logged in. By using SSLstrip and stripping the encryption of a connection, an attacker can once again ride off legitimate sessions. To start sniffing for active sessions run the hamster and ferret tools by issuing [code] ./hamster [/code] in one terminal and [code] ./ferret -i wlan1 [/code] in another terminal. Be sure to use the same interface used for the ARP attack, which can vary between computers and users. Set an HTTP proxy in your browser to http://127.0.0.1:1234, then browse to http://hamster. If you do not see the IP address of the interface you entered with the ferret command, click on “adapters” then enter your interface name. Soon targets will begin populating the left frame of this web page. Clicking on one of the links executes a session riding attack and replays a victim’s session. The tools offer their own set of instructions from the http://hamster site, seen below.
Cleaning Up Once the attack chain is complete, remnants of the attack are left on the attacking machine. Hamster is noisy in its directory and will write a few files. Remove the active Iptables rule (and all other Iptables rules) by flushing the rule list with the command [code] iptables -F [/code] Be sure to reARP the victim and its default gateway by pressing the ‘q’ key in the terminal ettercap is running. This will be sure the ARP caches of the victim and its default gateway are reset to the proper MAC addresses. Remove the HTTP proxy from your browser. Kill all running processes of hamster, ferret, SSLstrip, and Wireshark.
