pineapple, raspberry and wifi - ensimag · pineapple, raspberry and wifi ... ber of threats, once...
TRANSCRIPT
Pineapple, Raspberry and WiFi
WiFi Man-in-the-Middle attacks
CLAURE CABRERAOscar Mike ú
MARTIN Xavier †
FIQUET Jean-David ‡ PÉQUIGNOT Louis §
ABSTRACT802.11 Wireless Networks, commonly known as WiFi, are lar-gely deployed in personnal and professionnal contexts and arebeing spread in cities through hotspots and free WiFi zones.Even if web browsing is becoming more and more secured,wireless connections still have security issues that allow ma-licious people to intercept or spy its data. The point of ourwork is to assess how much time and money it costs to setupa Man-in-the-Middle attack on WiFi network and to deployit in urban areas.
We figured out that within three weeks, a motivated personis capable of execute WiFi deauthentication attacks, createa rogue access point and bait people into connecting to it.This scenario enables to hijack transmitted data and to uncoverpersonnal informations like visited places, individual’s identity,browsing history or even credentials.
Our final device cost less than 120 euros and can remotly spoofSSIDs and spy data transfer. We also provide an e�cient deau-thenticating tool ran on another device due to power consump-tion issues. Despite the security protocol setup on the web, fea-sible attacks still exists on WiFi networks and represent serioussecurity threats.
1. INTRODUCTIONAs internet and networks users, we are exposed to a large num-ber of threats, once connected to a communication infrastruc-ture there always are malicious users, better known as hackers,that tries to access to personal data by taking advantage ofparticular networking vulnerabilities.
ú. Grenoble INP - [email protected]
†. Grenoble INP - [email protected]
‡. Grenoble INP - [email protected]
§. Grenoble INP - [email protected]
In spite of the e�orts to implement methods to secure theconnections, each of them always comes with its own set of se-curity issues which can put the systems and/or personal data atrisk. One of this weakness is the well-know Man-in-the-Middleattack, which is based on the idea to place a malicious nodebetween two communicating points and intercept, with the pos-sibility to modify, the transmitted information.
The goal of this paper is to show that network security isnot a complicated subject, and it is not mandatory to be awell-trained and experienced expert to stole personal infor-mation from careless internet users by implementing a WiFiMan-in-the-Middle attack using tools such as a python-scapybased deauthentication script and the mana toolbox implemen-ted into a Raspberry Pi 2 Model B.
2. MAN-IN-THE-MIDDLE ATTACKS
Figure 1: A typical Man-in-the-middle attack
A man-in-the-middle attack (MitM) is usually [13], in com-puter security, an attack in which the attacker secretly relaysand possibly alters or eavesdrops the tra�c between two partieswhich are unaware of the situation. The success of a man in themiddle attack depends whether the attacker is able to imper-sonate each endpoints. MitM attacks are feasible by leveragingexploits of security flaws in layers of the OSI [39] model.
We cover several MitM attacks against data link layer, and ap-plication layer.Data link layer provides means to tranfert data between nodesof a network, right above the physical layer. It uses ARP to
1
connect to the network layer (by mapping MAC addresses toIP addresses). In wireless networks (WLAN), the IEEE 802.11[3] protocol is responsible for the MAC address handling andconnection between hosts, in LAN, Ethernet [4] protocol is incharge of that. The applicaton layer is the highest layer in OSI[39] model, it regroups the protocols that define host to hostcommunication with an abstraction of the network that sup-port this communication. Domain Name System [26] (DNS) isan application layer protocol that handles the hosts’ naming byproviding domain name for each participant of a communica-tion, one of its tasks is to translate IP to domain name.
On the data link layer, ARP poisoning [37] can be used inanswering to ARP requests [36] and impersonate the gatewayby spoofing its MAC address. This exploit works because ofthe automated resolution of MAC addresses via ARP. Indeed,without any control, targets will accept every response and up-date their IP/MAC translation table accordingly. All we haveto do is to look for ARP response and once the gateway hasanswered, override its response with our own.Countermeasures exist with Ticket ARP or S-ARP which bothinvolve central servers and cryptography, and thus scalabilityproblems. Since this flaw has been exposed, other countersteps[28] aiming to be a tradeo� between security and perfomanceshave appeared, but because it remains uncommon, ARP poi-soning is still widely used.
On wireless networks (i.e. 802.11), there exists a similar ap-proach that we will discuss here. A client with registered accesspoints (AP) in its OS is expected to broadcast 802.11 ProbeRequest packets for each AP saved, and those in connectingprocess. By emitting Probe response with the asked SSID anda higher broadcast power than the original AP, we can imper-sonate it, even with WPA [16], Countermeasures have beendevelopped, among these solutions, some are central server ba-sed [33]. Another approach is by mesuring the clock skew ofeach AP [23], which depends on flaws in the chipsets that havea very high probability to be unique. However, since the coun-termeasures are complex either in terms of computing power orprecision (needed to measure clock skews), none of these solu-tions is implented in the most mainstream WLANs, like publicsecured or unsecured WiFi, which are the most valuable targetsfor MitM attacks.
Figure 2: Spoofing TotoAP’s SSID
But contrary to ARP poisoning, with SSID spoofing we cannot override the link between APs and clients which where
already connected when the attack started. SSID spoofing canonly set up MitM for not yet connected clients, however it isune�cient against already connected clients, they have to bedisconneted first. There are several WiFi DoS attack againstWLAN that leverage 802.11 security flaws. One could try tooccupy all client authentication slots by handshake flooding,and thus overwelming the AP, but it has a high computationpower. One could also simulate a deauthentication conversationbetween the client and the AP by sending 802.11 Deauth packetto both the AP and the client using the spoofed MAC address ofthe other party. The WiFi DoS problem is being addressed withsolutions like using superfluous bits of management frames tocarry random bit authentication [24], and thus paring Deauthattacks.
Figure 3: WiFi jamming by sending Deauth packets
On vulnerable WLAN, MitM attacks can be implemented. Apartfrom countermeasures, the bottleneck of this attack is the abi-lity to send enough packets (and to quantify it) to force aclient with an established connexion to iterate through the listof available AP until its starts to send probe requests to APsthat are not here (but saved in the client’s memory) which onecould impersonate with his rogue AP.
On the application layer, DNS is a potential target for MitMattacks, it is called DNS cache poisoning [32] or DNS spoofing.It consists of injecting poison DNS records in the targets’ DNScache by answering to DNS queries with spoofed UID. SinceDNS relies on UDP the UID is the only way to authenticateresponses, and according to the birthdays paradox, it is easy[34] to impersonate a DNS server’s responses. Since the at-tack have been revealed, countermeasures have appeared [38].However, none is bulletproof. Thus, DNS cache poisoning is aconsidered attack in our study.
3. COLLECTING METADATA3.1 What is metadata and what is it used for ?Metadata is the information generated from information. Usingthe example of a simple communication between devices / ser-vers - the one we are going to keep the rest of the section - thegathered metadata includes informations like : devices involved,numbers contacted, addresses or geolocations, type of commu-nication services used and duration. In essence metadata is dataabout data. [17]
At an individual level, metadata is a source of content, in mostcircunstances it could reveal the same (or even more) informa-tion that the main content. [27] A detailed analysis of multiplerecords of metadata can provide detailed informations of the
2
target such as : social networks, habits, environment and pat-terns.
3.2 Ways to collect itThere are many ways to collect metadata, one of the moste�cients is to put a node between the two communicatingpoints and gather all the informations required.
Doing this way, a government can implement equipment thatsplitt the whole tra�c and retransmit it to its private networkto then be stored into a huge database.
3.3 Metadata policies in FranceOn May 2015, the French Parliament aproved a law authorizingits secret services to install black boxes (boîtes noires inFrench), into the TSPs’ core network to gather communica-tions, treat them automatically in order to detect and avoidterrorism acts. [35]
As many privacy defending movements consider these tech-niques as a mass surveillance procedures[14] and as an outrageto individual privacy, delicate issues are being aborded currentlyat the French Parliament, due to the ambiguities on the specifi-cations of the algorithms used for this automatic treatment.
4. ATTACKS OVER HTTPSSince more and more applications rely on Web, securing HTTPhas become necessary. HTTP [21] Secured (HTTPS) or HTTPover TLS [30] is not a protocol by itself but a specitification ofhow to use HTTP protocol over Transport Layer Security [20]protocol which is an evolution of SSL. HTTPS was first usedfor sensible sites (e.g. banks, payments, authentication pages)but is now widespread across the Web.
TLS protocol - among other things [12] - provides an encryptedcommunication channel between a host and a server. Thus, theTLS payload, i.e HTTP packets, is fully encrypted and enablesusers to have a secured browsing. Moreover, TLS is also incharge of the server’s authenticity ensuring.
The communication channel is encrypted with symmetric keycryptography such as AES [18]. To be able to encrypt, bothparties need a shared secret, which is exchanged either by Di�eHellman or asymmetrical cryptographic algorithm (e.g. RSA).
Public key certificates or Certificates of Authenticity (CA) havebeen introduced to solve the problem of authentication. Thesecertificates are delivered by trusted entities such as Verisignand bind one or more domain name(s) to an identity. To en-sure the certificate is a genuine one, the browser performs acalculation of the digest of the TBSCertificate [31] field withthe signature field (e.g. RSAwithSHA3).
So far, it was still possible to deny TLS usage back to old fashio-ned HTTP between a target and a man-in-a-the-middle with asignificant success [15]. But in 2012 [29] the HSTS [22] proto-col has been approved by the IETF. This protocol allow serversto declare to web clients (e.g. web browser) that they shouldonly communicate with HTTPS connections. To do so, whenthe first HTTP request towards the server (which uses HSTS)is done, the field Strict-Transport-Security is added to theHTTP response, e.g. max-age=31536000; includeSubDomains;
value to this field means that any further request to this (orthese) subdomain(s) must be done using HTTPS. Thus, theHTTPS communication is established despite it started withHTTP. This protocol has been implemented by several modernbrowsers but not by all of them [29].
However, since the HTTP response is in charge of carrying theHSTS field, a man in the middle can still intercept it and re-move the field. Despite being more complicated to implement,man in the middle were still feasible. That is why modern web-browsers (e.g. Chromium [1]) include a static list of domainswhich have to use HTTPS otherwise it results in an error dis-played to the user stressing the lack of safety.
4.1 SSL StripSSL Strip is a MitM attack focused on HTTP rather thanTLS. Once a MitM is set up, the attacker changes on-the-flyHTML pages’ link that point to HTTPS and intercepts HTTP302 Response to strip the HTTPS redirection. An HTTPSsession is created between the server and the attacker whe-reas the client’s session is HTTP. From the server’s point ofview, everything seems to be secured, but the target’s data iscompletly eavesdropped by the MitM. This attack emphazisedon the fact that HTTP over TLS alone is not enough for itssecurity, and thus HSTS was added.
When this attack was revealed [25], Moxie Marlinkspike alsopresented more complex versions that leverage other attacks,such as homograph attacks. It consists of using characters thathave glyphs that look alike (e.g. ‘/’ and ‘ ?’ are interestingtargets). Thus, you can redirect a legitimate HTTP requestto a domain of your own that look alike and thus having anelaborated form of fishing.
4.2 SSL SplitEach browser comes with root CAs embedded, theses certifi-cates certify that a considered intermediate CA is authentic andcan be trusted. When a user wants to access a domain nameover HTTPS (by either typing ‘https’ or because of HSTS), thebrowser iterates through the certificate chaining until it finds acertificate that is trusted by the root CA.
SSL Split is an attack that is based on the fact that you own acertificate trusted by the target. Thus, you can set up a MitMand over it, a TLS legitimate connection with the server and aTLS connection to the target with your certificate. SSL Splitenables the attacker to forge HTTPS sessions with a on- the-flycertificate creation as long as you can make them trusted bythe target. Thus the main obstacle to this attack is to insertyour own certificate into the target’s trusted CA. One could forexample compromise an authenticated site which owns a certi-ficate in the client’s trusted chain. By this method, one couldmake sign all the certificates he wants and could compromisethe CA chain. But this case goes beyond our study.
5. EXPERIMENTATIONExperimentation is the core of our work, as we are bound to se-tup Man-in-the-middle attacks to measure how feasible theseattacks - and those which steam from it - are.We encountered a fair amount of technical problems that de-layed our project but also helped us apprehend the subtlety ofWiFi connections and SSL/TLS secured connections.
3
5.1 Problems encountered5.1.1 WiFi Pineapple Mk V
The initial objective of our project was to use theWiFi Pineapple Mk V in order to setup a Man-in-the-middleattack over WiFi. The WiFi Pineapple Mk V is a device pro-vided by Hak 5 gathering multiple tools for deauthenticating,spoofing, disabling security, etc. The WiFi Pineapple Mk V isa device that implements a lot of external open source tools inorder to diversify its field of action. It also provides a fully gra-phical interface for the user, allowing a fast, remote and simpleusage. Besides, a significant amount of "juice", or plugins, areprovided to customize the possible attacks with the device.
However, the WiFi Pineapple Mk V caused us several pro-blems which forced us to change the device. Indeed, many of"juices" supposed to work out of the box were not workingas expected. Furthermore, the graphical interface which is theonly way to execute the provided scripts does not display anyoutput or log when things do not work. This last point is parti-culary crippling when we were trying to figure out the problem.This is why instead of using an existing "juice" supposed todeauthenticate WiFi clients, we had to implement our own WiFiJammer based on python-scapy module.
Another module, Karma, which is the program used to spoofaccess point’s SSID, did not work as well. Although the userinterface designed to take control of this tool seemed prettysimple, things were not working as expected. Again, the lackof a clear output or logs prevented us from finding what wasgoing wrong.All we were able to do was to harvest SSIDs from probe requestsand spoof them but the connection to one of these SSID neverled to a seemingly normal internet connection.
In addition, even though Pineapple software is based on Li-nux, this MIPS version (OpenWRT) does not provide a packetmanager or the ability to easily install software from classicalpen-testing distribution like Kali-linux.As a conclusion, unreliabilty of the device and its graphicalinterface which does not provide significant logs caused a de-vice which did not work, neither let us know why. Fortuna-tely, we highlighted these problems early during the project sowe quickly decided to change the device used. Since all thetools we need are open source, and because we wanted to workon a device which could be a lightweight and portable hack-station as the WiFi Pineapple was designed to be, we choseto work on a Raspberry Pi 2. After some research, we foundan equivalent framework implementing hostapd-karma on aKali Linux distribution : FruityWiFi [2].
5.1.2 FruityWiFi
We first needed to order our Raspberry Pi 2 and WiFi an-tennas which delayed the entire project. We used this time tocreate and improve our own WiFi Jammer, but we still lostsome time waiting for our equipment. Second, we had decidedto use Fruitywifi, an open source tool similar to the softwareinside the WiFi Pineapple Mk V but written in Python. Ne-vertheless, we encountered the same problems as on the WiFiPineapple Mk V - that is to say absence of clear output andlogs, so we decided to completely abandon pre-constructed soft-ware to use command-line scripts instead, fully controlling whatis launch, when and how.
5.1.3 Raspberry Pi 2 B
We installed Mana[5] as an alternative to Karma on theRaspberry Pi 2 B in order to spoof SSIDs. If we managedto make everything work, contrary to the previous experimen-tation on the WiFi Pineapple Mk V, the Raspberry Pi 2 Bstill has its constraints, like power consumption for instance orantenna’s chipset compatibility.
We encountered early a hardware compatibility problem withour antennas. Indeed we first had two di�erent antennas : theAlfa AWUS036NEH [8] and the Alfa AWUS036H [7] which res-pectively use a Ralink and Realtek chipset. If we were able toget some results like actually receiving probe requests, any wor-king connection to the spoofed network was impossible. Even-tually, we figured out [5] that the chipset was in fault and thathostapd-mana only works well with Atheros chipsets.We then decided to buy two TP-LINK TL-WN722N antennas[11] and one Alfa AWUS036NHA [9], which delayed our projectfor few other days. Hopefully, once these antennas received,hostapd-mana was working fine and we finally were able tospoof SSID and connect to it.
Because our goal is to make a versatile device that can deau-thenticate, spoof and provide internet connection at the sametime without using a computer or plugging it, we decided touse these three antennas at the same time. Sadly, even suppliedwith a 2.1A battery, the energy consumption of the RaspberryPi 2 B antenna raises an energy problem. Indeed, RaspberryPi 2 B has a self-consumption of 600 mA and its PowerDistribution Unit (PDU) can provide a total of 1.2 A toits USB ports. Nevertheless, each of our antennas require ap-proximatively 1A. This power constraint forced us to changeour initial plans to use a separated computer to deauthenticateclients from WiFi. Moreover, we figured out that a computer ismore reliable for deauthenticating due to the maximal sendingspeed of packets and its stability for packet injection.Although this scenario works fine, we decided to switch theTP-LINK TL-WN722N responsible for acquiring a real WiFi connec-tion to a power consuming less interface : the Edimax EW-7811UN [10]. This change was really beneficial since our spoo-fed SSID connection is now fully stable.
5.2 WiFi Attacks5.2.1 WiFi Deauthentication
The first attack we set up is a WiFi deauthentication which ba-sically disconnect every clients around. Our script is written inPython, based on python-scapy package which allows to forgeour own deauthentification packets as well as sni�ng WiFi forsearching new clients to deauthenticate. Our code is inspiredfrom an existing WiFiJammer script [19].Our version contains a command line interface to select SSID todeauthenticate, provides a blacklist and a whitelist mode andalso allows to do not deauthenticate specific MAC addressesso that our devices are not disconnected when jamming. Weprovide two classes for that : the Scanner class which ana-lyses the WiFi network to allow user to select specific SSIDand the Jammer class which injects forged packets using thepython-scapy framework.
5.2.2 SSID Spoofing
As mentionned before, we use Mana in order to spoof SSID.Mana uses hostapd to create rogue access points : Mana
4
comes with an harvester which listen to any Probe Requestto forge fake SSIDs and to bait people into connecting to them.Mana works very fine but the harvester must be tightly control-led or it spams a huge amount of SSIDs, becoming obviouslymalicious.
However, the SSIDs we spoof are unsecured and so there can-not be an automatic reconnection point if the original SSIDswas secured. It then makes it more di�cult to force aMan-in-the-Middle, as long as it is more complicated to spoofa secure connection, because of the need of the authentica-tion key. Nevertheless, we can create fake free SSIDs and havepeople connecting to us. With the addition of Mana, we areable to make a full forwarding connection, allowing people toconnect to internet through our device.
Apart from very few modifications, Mana comes with fully func-tional scripts when installed. The first we used wasstart-mana-simple.sh. It is a simple way of forwarding net-work tra�c through our rogue AP. After we made sure every-thing was functionnal, we rewrote start-mana-nat-full.shto launch other tools like sni�ng-ones, sslsplit or sslplit.By customizing the iptables [6] rules, we were able to hijackclient tra�c but to let our own tra�c unaltered.The start-mana-nat-custom.sh, launched at boottime doesthat.
5.2.3 Traffic Sniffing
With people connecting through our Raspberry Pi 2 B, weare able to completely eavesdrop their tra�c, although there isstill an HTTPS secured connection issue.
The first way of Traffic Sniffing is by logging the meta-data. It describes who goes where and when. Cataloging andpost processing these data allows us to follow a particular ad-dress in his web browsing, or to know where everyone goes.For that we simply need to route tra�c from the SSID we pro-vide towards internet and analyse every packet which passes.Our traffic_sniffer script does that. Because packets areunaltered, this attack is virtually undetectable.
The second way is to access to sent data themselves. However,when a client access to a web sever via a HTTPS secured connec-tion, these data are encrypted. Because users usually do nottype https://... themselves, most of the HTTPS connectionare due to HTTP 302 redirection or direct URL. SSLstripallows us to intercept these first https queries and alter themto force client to use the basic HTTP protocol. Forcing a nonsecured connection between the client and us, we are able tofetch directly his data, including credentials or any sent infor-mations.Depending on the victim browser, this attack sometimes give usgreat results allowing us to e�ectively retrieve logins/passwordswe used for experimentation. On most recent browsers thatsupport it and depending on whether the website implementsit, the HSTS protocol counters SSLstrip by forcing a HTTPStransaction. We then require a more advanced program, nameSSLsplit to attack. However, SSLsplit is also countered bycertificate authentication which may display to the client asimple alert box easily clicked and dropped by him to continuesurfing, but it might also prevents the client from any furtherattempt to connect.Basically, we face an escalation between attack means and their
countermeasures.
To access these data, we use tools provided with Mana : Firelamband Firelog. The first one allows us to spy on cookies createdduring the connection on our spoofed AP, we can then poten-tially copy these cookies and spoof a user, connecting ourselveswith his session. The second one is a tool that spies on data. Ifall data are clear, we can find every single information into thelogs, passwords for instance. We also have a hand-made scriptto sni� on start-mana-simple.sh, used during our first stepswith Mana.
5.2.4 Problems with SSLstrip
As mentionned before, we used SSLstrip as a default confi-guration, but because it does not work properly every time, wehad to add SSLsplit to our implementation. The behavior ofSSLstrip depends on the device it is used against. For example,some web browsers do not accept non-HTTPS connections be-cause they already implement a HSTS static list of web-serversusing it. Some other browsers do not suspect anything.Because we do not have a compromised root certificate autho-rity, the SSL certificate validation we provide via SSLstrip isalso wrong. Strangely, not all web browsers seem to notice it,and when they do, the behavior di�ers. It sometimes pops up amessage asking if the certificate must be trusted (users usuallyaccept it because it’s a one-click button), and some other timesdisplay a very dissuasive web-alert that blocks all connections.
This behavior is particularly e�ective on smartphones. Someof them - those with the most recent browsers - will block allconnections tampered by SSLstrip whereas some others willaccept it without any alert.
Total blocking by browser annihilates our attacks, whereas whenbrowsers only ask for certificate validation, we can then sni�tra�c and have significant datas. Moreover, most people willnot consider security issues deriving from accepting our certifi-cate and thus will accept it.
6. RESULTSOn this section we present a summary of the achieved resultsafter the experimentation.
6.1 Deauthentication attackOur deauthentication attack is able to :
— Target access points on either Blacklisted SSIDs orWhitelisted SSIDs mode.
— Prevent specific users from being disconnected by provi-ding their MAC address in a Whitelisted Users mode.
— Any combination of the modes mentioned above.
The deauthentication attack has an excellent performance.We have tested it on a variety of situations, stopping theconnection between the AP(s) and User(s) successfully. Be-cause the script listen to any tra�c, it is able to prevent anynew incoming clients to reach the access point. Furthermore,this attack can be run continuously, preventing everyone butthose we allow to use WiFi connection.
5
6.2 SSID spoofingBy using the hostapd-mana tool we were able to :
— Send targeted Probe Responses as a reply from anyDirected Probe Request detected, giving to the clientthe illusion that a ’known’ Access Point is around him.
— By enabling the loud mode we are able to broadcast thespoofed SSIDs, so clients are allowed to connect to aspoofed AP with the SSID requested by another client.The drawback of broadcasting SSIDs this way, especiallyin a crowded place, is the enormous amount of di�erentvisible SSIDs for the users which could trigger distrust.
— Gather information about connected clients : MAC ad-dress and vendor, hostname, and the given IP address.
Figure 4 gives an example of gathered informations about clientswhich were connected to us.IP Information10.0.0.105 MAC: 00:c0:ca:xx:xx:xx
Status: UpHostname: ???Vendor: ALFA, INC.
10.0.0.100 MAC: e0:c9:7a:xx:xx:xxStatus: DownHostname: OscarMiesiPhoneVendor: Apple
10.0.0.101 MAC: 0c:41:3e:xx:xx:xxStatus: DownHostname: Windows-PhoneVendor: Microsoft Corporation
10.0.0.103 MAC: 10:68:3f:xx:xx:xxStatus: UpHostname: android-90c8f139c88d76a3Vendor: LG Electronics
10.0.0.106 MAC: f4:f1:e1:xx:xx:xxStatus: UpHostname: android-9208b57ba1028037Vendor: Motorola Mobility LLC
10.0.0.104 MAC: 00:14:9a:xx:xx:xxStatus: UpHostname: android_a5f40db78409899eVendor: ARRIS Group, Inc.
Figure 4: Output from monitor tool
As a conclusion, the SSID spoofing attack works well, wecan spoof unsecured access points regarding to the detectedDirected Probe Requests, but we have been facing problemson the automatic connection towards a spoofed AP which ori-ginally handles a secured connection (this information is storedsomewhere into the client’s memory, for example android andlinux devices uses the wpa_supplicant.conf file). The onlyway to achieve a connection on these cases is by, from theclient’s device, voluntary tapping on the spoofed SSID.Nevertheless, assuming that we are currently deauthicating everylegit WiFi, the attacked device continues to send DirectedProbe Requests showing us his entire access point history andwe just need one of these access points not to implement a se-cure connection for the device to trigger an automatic connec-tion.
6.3 Traffic Sniffing
By using the mana-toolkit which already implements SSLstripand SSLsplit modules, we were able to have a rogue AP in twomodes. When working without internet capabilities (i.e. noupstream mode), the client is redirected towards a fake captiveportal, which incites him to enter his login informations in orderto get a free internet connection. Of course all the insertedcredentials are stored on clear text.
Figure 5: Captive Portal, used to retrieve clients’ creden-tials. An example of redirection when the client demandedwww.skype.com
When working with internet capabilities (i.e. upstream mode),we redirect all the incoming tra�c towards internet. Thanks toour traffic_sniffer tool, we were able to log metadata. Inthe case where the client is using HTTPS connection, we retrievethe destination IP of the encrypted packets and perform a re-vert DNS lookup.Because we just sni� the transmitted packets, this attack iscompletly invisible for the user. An example of the logs is sho-wed below :2015-06-08 13:54:06.550768 10.0.0.100 <HTTPS> edge-star-shv-01-cdg2.facebook.com2015-06-08 13:54:06.574119 10.0.0.100 <HTTPS> edge-star-shv-01-cdg2.facebook.com2015-06-08 13:54:06.597169 10.0.0.100 <HTTPS> edge-star-shv-01-cdg2.facebook.com2015-06-08 13:54:06.626285 10.0.0.100 <HTTPS> edge-star-shv-01-cdg2.facebook.com2015-06-08 13:54:15.001704 10.0.0.100 <HTTPS> 108.168.176.241-static.reverse.softlayer.com2015-06-08 13:54:32.841265 10.0.0.100 <HTTPS> 108.168.176.241-static.reverse.softlayer.com2015-06-08 13:54:34.698297 10.0.0.100 GET www.google.com/2015-06-08 13:54:47.478297 10.0.0.100 GET www.google.com/2015-06-08 13:54:47.717776 10.0.0.100 GET csi.gstatic.com/csi?v=3&s=gmob&action=&rt=crf.807...2015-06-08 13:54:58.669591 10.0.0.100 <HTTPS> 248.128.153.77.rev.sfr.net2015-06-08 13:55:03.689533 10.0.0.100 <HTTPS> 218.128.153.77.rev.sfr.net2015-06-08 13:55:04.957320 10.0.0.100 GET www.google.com/2015-06-08 13:55:08.922640 10.0.0.100 <HTTPS> 218.128.153.77.rev.sfr.net...2015-06-08 13:55:30.491708 10.0.0.100 GET rma-api.gravity.com/v1/beacons/log?cbust=407-16&s...2015-06-08 13:55:38.319243 10.0.0.100 GET gscounters.us1.gigya.com/gscounters.sendReport?re...2015-06-08 13:55:40.002060 10.0.0.100 GET static.ak.facebook.com/connect/xd_arbiter/1ldYU13...2015-06-08 13:55:50.990102 10.0.0.100 GET www.nasa.gov/sites/all/modules/contributed/jrejec...2015-06-08 13:56:15.901258 10.0.0.100 GET www.google.com/2015-06-08 13:56:36.044088 10.0.0.100 GET sa.bbc.com/b/ss/bbcwglobalprod/1/H.22.1/s94496340...2015-06-08 13:56:48.615169 10.0.0.100 GET www.google.com/2015-06-08 13:56:56.340139 10.0.0.100 GET www.lemonde.fr/2015-06-08 13:57:00.472803 10.0.0.100 GET www.lemonde.fr/2015-06-08 13:57:08.193666 10.0.0.100 GET www6.smartadserver.com/h/maip?visit=v&pubid=21&st...2015-06-08 13:57:09.710401 10.0.0.100 GET mobile.lemonde.fr/ws/1/ticker/live/2015-06-08 13:57:25.856801 10.0.0.100 <HTTPS> 218.128.153.77.rev.sfr.net...2015-06-08 13:57:35.394314 10.0.0.100 GET ensimag.grenoble-inp.fr/medias/photo/ima-carou-pl...2015-06-08 13:57:40.551502 10.0.0.100 GET ensimag.grenoble-inp.fr/medias/photo/ima-actu-of_...2015-06-08 13:57:40.777241 10.0.0.100 GET ensimag.grenoble-inp.fr/medias/photo/ima-actu-can...2015-06-08 13:57:42.642054 10.0.0.100 GET www.youtube.com/embed/7LU4eE2Bd-0?rel=0
Figure 6: Logs from tra�c_sni�er
When we want to get more critical informations from our po-
6
sition, we use start-mana-custom.sh at boot which launchSSLstrip and SSLsplit. The trafic is logged via those twoscripts but also via firelamb and firelog modules which re-trieve the metadata associated to each device which have beenconnected to the spoofed AP. This metadata contains the brow-sing history and the cookies file. Moreover, by DNS spoofing,website spoofing and breaking the SSL/TLS secure protocol,all URL resolution requests, even those from clients with perso-nal DNS configurations, are being redirected towards a spoofedwebsite (locally hosted), forcing a non secured connection bet-ween the client and us, then we are able to directly fetch thisdata plainly. An example of the technique detailed above isshowed on Figure 7. Instead of https://www.google.com theclient is redirected towards http://wwww.google.com. Noticethat, the website have been spoofed (the URL contains four’w’), the SSL/TLS secured protocols were removed (there isno https connection) and the data is beeing transmitted unen-crypted between the client and the AP.
Figure 7: Spoofed website and unsecured connection bet-ween the client and the spoofed AP.
One of the major problems while working into this mode was theunstability of the results. We realize that factors like vendors(for portable devices), OS version, browser used and client’s be-haviors while using the browser app determine the penetrationof the attack.
For example if the client, once connected to the spoofed AP,searches for information by directly typing it into the URLfield (fast search) it usually raises an alert of No securedconnection, see Figure 8. On the other hand, if the clienttypes first www.google.com and then tries to search whate-ver he wants, he won’t notice any di�erence unless he carefullycheck the URL, which instead of https://www.google.com/*will be http://wwww.google.com/*
To quickly find credentials amongst the huge amount of datawe have collected, we have written a script that parses the login search of credentials. We show on Figure 9 the result of thisscript.
Figure 8: No secure connection alert.
/var/lib/mana-toolkit-log/15-06-05_15:23/sslsplit/20150605T091653Z-[10.0.0.102]:57127-[173.194.78.84]:443.log:...Email=ensimag1234%40gmail.com&Passwd=ensimag38&signIn.../var/lib/mana-toolkit/sslstrip.log:http%3A%2F%2Fwww.google.com...&Email=ensimag.test%40gmail.com&Passwd=P4$$w0rD&signIn.../var/lib/mana-toolkit/sslstrip.log:sitedomain=sns.mail.aol.com...&loginId=ensimag.test&password=AbC12345/var/lib/mana-toolkit/sslstrip.log:login=TestEnsimag%40hotmail.com&passwd=monSuperPassword&...
Figure 9: Output from password_finder.sh
Figure 10: Unknown certificate alert.
Mail-based applications can pop-up an alert ofUnknown certificate, which most people just ignore and tapon the Continue button. Figure 10 shows an example of thisalert.
7
7. CONCLUSIONOur objective was to establish a Man-in-the-Middle WiFi at-tack using an easy portable and independant device. We suc-ceed at making an e�cient WiFi Deauthenticator which is justa module on the Raspberry PI and also works as a rogue ac-cess point where we can redirect clients to internet, spying onthe transmitted packets. Our rogue AP can bypass security sys-tems, but we can not guarantee a total penetration. The resultsdi�er according to the vendor, OS version, browser used andclient’s behaviour.
We have been able to make a device that represents a realthreat to WiFi network security within just 3 weeks and cos-ting less than 120 euros. Extending our test to crowded envi-ronments, which is illegal, would allow us to harvest numerouscredentials without anyone suspecting it. Anyone with mali-cious intentions and more time is able to get a system like oursand walk in the street robbing credentials.
A way to reduce the penetration of this kind of attacks is to becareful while connecting to public AP, do not leave the WiFiinterface turned-on while not using it, always check the URLand never accept unknown certificates. Another more e�ectiveway to avoid this would be to use a VPN (Virtual PrivateNetwork) which encrypts all the outbound and inbound tra�c,without relying on WiFi security.
8. REFERENCES[1] Chromium : HSTS preloaded list. https://code.
google.com/p/chromium/codesearch#chromium/src/net/http/transport_security_state_static.json.
[2] Fruitywifi-github.https://github.com/xtr4nge/FruityWifi.
[3] IEEE 802.11T M WIRELESS LOCAL AREANETWORKS. http://www.ieee802.org/11/.
[4] IEEE 802.3 ETHERNET WORKING GROUP.http://www.ieee802.org/3/.
[5] Mana-github. https://github.com/sensepost/mana.[6] The netfilter.org "iptables" project.
http://www.netfilter.org/projects/iptables/.[7] wikidev-alfa-awus036h. https:
//wikidevi.com/wiki/ALFA_Network_AWUS036H.[8] wikidev-alfa-awus036neh. https:
//wikidevi.com/wiki/ALFA_Network_AWUS036NEH.[9] wikidev-alfa-awus036nha. https:
//wikidevi.com/wiki/ALFA_Network_AWUS036NHA.[10] wikidev-edimax.
https://wikidevi.com/wiki/Edimax_EW-7811Un.[11] wikidev-tp-link.
https://wikidevi.com/wiki/TP-LINK_TL-WN722N.[12] Wikipedia : Comparison of TLS implementations.
https://en.wikipedia.org/wiki/Comparison_of_TLS_implementations.
[13] Wikipedia : Man-in-the-middle attack. https://en.wikipedia.org/wiki/Man-in-the-middle_attack.
[14] Manifestation contre la surveillancegeneralisée, 2015. https://www.laquadrature.net/fr/8-juin-manifestation-contre-la-surveillance-generalisee.
[15] F. Callegati, W. Cerroni, and M. Ramilli.Man-in-the-middle attack to the HTTPS protocol. IEEESecurity & Privacy, (1) :78–81, 2009.
[16] A. Cassola, W. K. Robertson, E. Kirda, and G. Noubir. Apractical, targeted, and stealthy attack against wpaenterprise authentication. In NDSS, 2013.
[17] A. Cavoukian. A prime on metadata : Separating factfrom fiction. Information and Privacy Commissioner,Ontario, Canada, 2013.
[18] P. Chown. Advanced encryption standard (aes)ciphersuites for transport layer security (tls). 2002.
[19] DanMcInerney. github : Danmcinerney/wifijammer.https://github.com/DanMcInerney/wifijammer.
[20] T. Dierks. The transport layer security (tls) protocolversion 1.2. 2008.
[21] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter,P. Leach, and T. Berners-Lee. Rfc 2616, hypertexttransfer protocol–http/1.1, 1999. URL http ://www. rfc.net/rfc2616. html, 2009.
[22] J. Hodges, C. Jackson, and A. Barth. Rfc 6797 : Httpstrict transport security (hsts), 2012.
[23] S. Jana and S. K. Kasera. On fast and accuratedetection of unauthorized wireless access points usingclock skews. Mobile Computing, IEEE Transactions on,9(3) :449–462, 2010.
[24] Y.-S. Lee, H.-T. Chien, and W.-N. Tsai. Using randombit authentication to defend ieee 802.11 dos attacks.Journal of Information Science and Engineering,25(5) :1485–1500, 2009.
[25] M. Marlinspike. New tricks for defeating ssl in practice.BlackHat DC, February, 2009.
[26] P. Mockapetris. Rfc 1035—domainnames—implementation and specification, november1987. URL http ://www. ietf. org/rfc/rfc1035. txt, 1987.
[27] J. D. Mornin. Nsa metadata collection and the fourthamendment. 2014.
[28] S. Y. Nam, D. Kim, and J. Kim. Enhanced arp :preventing arp poisoning-based man-in-the-middleattacks. Communications Letters, IEEE, 14(2) :187–189,2010.
[29] O. W. A. S. Project. HTTP strict transport security.https://www.owasp.org/index.php/HTTP_Strict_Transport_Security.
[30] E. Rescorla. Http over tls. 2000.[31] D. Solo, R. Housley, and W. Ford. Internet x. 509 public
key infrastructure certificate and certificate revocationlist (crl) profile. 2002.
[32] S. Son and V. Shmatikov. The hitchhiker’s guide to dnscache poisoning. In Security and Privacy inCommunication Networks, pages 466–483. Springer,2010.
[33] S. Srilasak, K. Wongthavarawat, and A. Phonphoem.Integrated wireless rogue access point detection andcounterattack system. In Information Security andAssurance, 2008. ISA 2008. International Conference on,pages 326–331. IEEE, 2008.
[34] J. Stewart. Dns cache poisoning–the next generation,2003.
[35] M. Untersinger. La loi sur le renseignement mettra-t-elleen place une « surveillance de masse » ?, 2015.http://www.lemonde.fr/.
[36] R. Wagner. Address resolution protocol spoofing andman-in-the-middle attacks. The SANS Institute, 2001.
[37] S. Whalen. An introduction to arp spoofing. Node99
8
[Online Document], April, 2001.[38] L. Yuan, K. Kant, P. Mohapatra, and C.-N. Chuah. Dox :
A peer-to-peer antidote for dns cache poisoning attacks.In Communications, 2006. ICC’06. IEEE InternationalConference on, volume 5, pages 2345–2350. IEEE, 2006.
[39] H. Zimmermann. Osi reference model–the iso model ofarchitecture for open systems interconnection.Communications, IEEE Transactions on, 28(4) :425–432,1980.
9