My NFC Remains Enabled - Reflections on Mobile Pwn2Own 2014

In spite of several demonstrations of NFC-based vulnerabilities at this year’s Mobile Pwn2Own competition, the NFC service on my Android phone remains enabled.

And in spite of numerous flaws found in Android devices over the years, I happily use one myself for everything from gaming to banking. Many IT security articles have concluded that we should therefore be turning off NFC, but is this the only lesson to be learnt from this year’s competition?

For those of you unfamiliar with the Mobile Pwn2Own competition run by HP’s ZDI group, competing teams present zero-day exploits against a short list of the latest mobile devices. The teams can choose to attack a device from a pre-defined list of vectors, with more difficult vectors attracting a higher prize if successful. For all vectors, they must be remote attacks with little or no user interaction required, and they must demonstrate their success by recovering personal information from the device. Teams have thirty minutes to demonstrate their exploit on the day. This means that the exploits generated and used must be unique, and very reliable.

The Pwn2Own competition is fantastic in providing a counter point to vendors’ claims of their products’ security. It is difficult for end users to validate the claims made by vendors and unfortunately it often takes a security incident to occur for the true effectiveness of a product to be made clear. Although not always loved by the vendors, Pwn2Own allows mobile devices to be tested in public, with the results for all to see.

Although Pwn2Own demonstrates the latest types of attacks and demonstrates the ability for different platforms to stand up against them, we should be careful about making assumptions on the security of a given mobile platform based on such results. Due to the rules and the format of the competition, Pwn2Own exploits typically differ from the kind of exploits we often see in the wild. After all, why would a real world attacker bother using a zero day vulnerability when several known vulnerabilities still work, and existing exploits exist? Or alternatively, why use any kind of exploit which might be picked up by antivirus, when instead the attacker could use social engineering to trick users into performing actions on their behalf?

0-day vulnerabilities that use short range communications like NFC are only really a likely vector for well funded organisations seeking to deliberately target specific users’ devices. Although this is a genuine concern for certain individuals and groups, most people are far more likely to be targets of phishing and malware.

What can end users do to stay safe?

To this end, there are some simple steps that users can take to avoid malware. Most malware comes from outside of the official app stores, often in the guise of free or alternative downloads for legitimate apps. Some of these malicious versions have been found to contain spyware or ransomware, even simply replacing the advertising accounts in the app with their own to turn a tidy profit. If you can limit yourself to the official app stores, it will greatly reduce the risk of encountering malicious applications.

What can developers do?

For developers it is an important lesson of Pwn2Own to see that in spite of improvements to mobile security, there were a record number of entries for this years competition. This may seem counter-intuitive but it shows two things. Firstly, it shows an increase of interest in mobile security from researchers around the world. This year had seven entries, and the highest prize money yet offered for the competition. It is likely this will only increase in future events. Secondly, it shows that we can’t yet sit back and rely on the device doing all the security for us. For our exploits, we weren’t hindered by any of the security controls present in recent versions of Android (things like SE Linux, ASLR, DEP, application sandboxing or KNOX). Instead we used the functionality made available to us by the device. Developers should always consider not just the use but the potential misuse of their applications. Thinking about this early in a project can save a lot of time and money (not to mention the negative brand impact) over waiting for it to be found in the wild.

Developers for all the major platforms can find secure development guidelines that they should endeavour to include in their development lifecycle (such as the iOS guide). The level of investment by a company into their application’s security will obviously depend on the resources available and the level of risk the app is expected to have, but building an app with security principles in mind can greatly reduce risk of a security incident down the road.

Finally the technical details

Obviously we can not give out information that would enable attackers to take advantage of the vulnerabilities we found. As soon as the vendors have had time to provide a patch to their customers, we will publish full technical details.

In the meantime, there’s no harm in reducing your attack surface. If you aren’t using NFC, why not disable it?