In June 2015 I attended the Blackhat Mobile Security Summit in London, a 2 days event filled with talks from various researchers and security professionals, there was a 3rd day in the form of a workshop for anyone attending the Interop London hosting event
Blackhat is historically a USA based event with its main conference taking place in Las Vegas every year, lately they started to host similar (but smaller) conferences around the world such as in Singapore and Amsterdam (which I blogged about last year here).

This London edition was definitely on the "smaller" side and this actually had a few advantages:

You could attend all the sessions as none were run in parallel

It was easier to mingle among fellow participants and speakers

There was less "walking"! :)

The quality of the talks were high, as you would expect from the "Blackhat" brand, with only a couple having a speaker struggling to deliver their presentation in English. You can download most presentations and relevant white papers from the Blackhat summit page .

Below are the key take aways from this summit sessions:

---

1. The machines that betrayed their masters [Mobile Data leakage]
2. Android Security State of the Union [Google speaking about their security controls]
3. Abusing android apps and gaining remote code execution [a new type of mobile attack vector]
4. SAP Mobile: Attack and Defense [Common issues with SAP mobile dev]
5. Blackbox iOS app testing with idb [iOS hacking technics]
6. Security analysis of android factory resets [Problems with secure delete on Android]
7. Witchcraft for windows phone breakers [Windows hacking technics]
8. SCADA and Mobile [SCADA systems at remote risk because of mobile]
9. Malware network view [Cell network malware monitoring]

---

1. The machines that betrayed their masters (click for BH description)
Presenter: Glen wilkinson
Contact: @Glennzw
Glen put an interesting twist to a now common security topic: how much data your personal/portable devices leak about you.
Using the tool he created, Snoopy he started the presentation by showing how many people in the room had attended his previous talks and where about they lived.
He did that by comparing some unique identifiers he gathered through the years presenting and what he could detect on the day.

I found interesting that he went beyond the "MAC address" as a unique identifier, instead labelling it as the most common, easiest to gather identifier available at the moment but also one of many others: apps network signatures, email access pattern, browser signatures, etc.
Adding all this together not only leaks information about the victim but also helps identifying it.

Snoopy-ng (the new version) looks like an interesting tool, somewhat similar to the WIFI Pineapple but also different: Distributed, Centralised and with a recon element. It does not require any specific hardware and can run on relatively low performance Linux based machine such as a Raspberry Pi. It tracks what it finds in a central database (location and time). It does sound quite promising and worth trying as part of your Pen Test Arsenal.

Glen also mentioned a few interesting technologies such as "Xbee" which is a long range (4 to 8km) radio solution, the fact its tool can query Wiggle.net to benefit from the popular war drive database.
And finally a good tip: iPhones are becoming increasingly silent when it comes to leak their known/saved WIFI networks but if an attacker creates a hidden SSID, apparently this makes all the iPhone around quite noisy again!


2. Android Security State of the Union
Presenter: Adrian Ludwig
Adrian is in charge of Android security at Google
I have to admit, I initially found strange that a "Vendor" was here to talk about how great their product was and it did feel a little bit awkward at the beginning when Adrian was clearly painting a very different picture as to what most researchers see, mainly that Android OS platform has many security flaws and issues.
Nonetheless, it was a very interesting talk and it help getting a very clear message across: Google is taking its ecosystems' cyber security seriously, they have been/are implementing new security measures and... it is working!
The last part, "it is working" was indeed echoed by at least 2 further researchers/presentations during the summit.

Adrian explained Android officially has about 1 billion users, but they suspect it is closer to 2 billion because of some countries lack of visibility such as China. He acknowledged that because Android is open source, it is very diverse with thousands of unique devices, hundreds Of OEM and security solutions.
Android's security has grown in recent years with features such as application isolation, exploit mitigation (Nx, ASLR, Fortified apps) and security checks (Google play scan of apps, Safe browsing for chrome, Verify apps which is similar to AV, Safety net, device manager, device integrity, Android for work, etc).

Adrian went on speaking about the threats facing the Android platform and what Google was doing about it:
- Malware:
Looking for bad behaviour of an app but also trying to identify unique malware developer info (Copyright string, Order of method in the code, etc), Safety Net (Millions of scan per day of devices with Russia devices scanned every day! and the rest of the world only about every 6 days). Interestingly, Malware is called PHA ("Potentially Harm for Applications") within Google. Except rooting because users who root device want that.
Google acknowledges about 10 times more PHA on unchecked sources, their ultimate goal is not to have 0 malware but a small and manageable number. Among other things, they are using machine learning to detect bad behaviour.
They believe users should have choice, but it is critical that users must have a good device integrity, therefore Google is fighting rooting but won't stop people doing it.
- Platform vulnerabilities:
Google chose this Blackhat event to introduce their Android Security Reward program . In a nutshell they will pay up to $38K for vulnerability disclosure and pay more if you also provide, test, patch data, etc
- App vulnerabilities:
Besides the standard Sandboxing, access permissions, etc., they are now also issuing developer security warnings when they try to upload new versions of their apps to the Google Store that may contain security issues such as vulnerable OpenSSL libraries. They may even prevent a developer to upload new versions of their software if they do not fix the issue, which seems a bit odd as it would still leave vulnerable apps on the Google Store (why not removing it instead?)


3. Abusing android apps and gaining remote code execution (click for BH description)
Presenter: Ryan Welton
Contact: @fuzion24
Ryan described a new attack technique (in the mobile space) using zip directory traversal: with a carefully crafted zip file it might be possible to unzip the file outside of its app directory. It is because the Android Zip library is not checking correctly the unzip path.
This new technique could become a very easy and common attack vector to distribute payload on Android and potentially other OS (iOs, Windows Phone). As a result quite a few subsequent presenters got excited about it and were already thinking at ways to combine it with their work.

Ryan went on and demonstrated how it could be used with 2 examples:
- Zip Video:
Many free apps use videos adverts for revenue and those videos are usually delivered in a ZIP package, with a popular video app framework called Vungle which is vulnerable. As a result a popular app such as "My Talking Tom" could be hack through a "bad proxy" (hostapd, amnesia) and its executable replaced with a custom one even on a non rooted device!
- Samsung Keyboard:
Swiftkey is a custom app that is installed by default on new Samsung phones, it has the ability to install new custom keyboards through "plugins/packages". As you may have already guessed, those packages are sent to the phone as zip files!
The attack surface could be seen as minimal as it would require users to want/need to install new keyboards, but Ryan also found critical updates to the keyboards are sent using the same method. Therefore it is possible to simulate such critical update and force the payload to be installed.
Ryan used mitmproxy in his example (mitmproxy -host -T -s script.py -p 10000)
The media picked up on this specific issue , without really reporting on the fact the underlying security flaw has a much wider security implication.


4. SAP Mobile: Attack and Defense (click for BH description)
Presenters: Julian Rapisardi and Fernando Russ
SAP is a business solution software used by most major companies and as such can be a target of Espionage, Sabotage and Fraud. This technology, like many others, is going mobile (64+ android apps alone) which brings new security issues. The talk was focus on the main and standard SAP mobile development framework called "SAP FIORI" which provides a plugin to interface with a mobile platform and allow communication between the backend system and mobile devices.

To illustrate the attack surface they designed a test app, emulating a booking system for multiple airlines companies managing flight connections. As much as I don't really like the use of "mock-up" apps when doing vulnerability demonstrations, their app was developed using recommended and standard practises and as such should be seen as a realistic representation of SAP mobile app issues.

SAP App architecture:
- Apache Cordova : A platform for building native mobile apps using html, css and JavaScript. This is not compiled, which means your source code is available along with your application
- Kapsel framework : Plugins for Cordova to interact with SAP.
No effort was made to secure the application, just using standard library and tutorial available online.

SAP App security related issues:
- Standard library uses basic auth for login, it means base64 encoding
- Afaria plugin can deliver single sign on signing offering some security: SSL/TLS. The danger is that if you do a MiM and intercept the token you can then use that token within the enterprise! There is a certificate based auth, but it is complex to implement and not many companies use it.
Furthermore, they discovered a vulnerability related to poor encryption algorithm implementation, meaning it is possible to decrypt SAP mobile communication . This issue hasn't yet been publicly disclosed.


5. Blackbox iOS app testing with idb (click for BH description)
Presenter: Daniel Mayer
Daniel provided a quick overview of iOS security controls (Canaries, PIE, Sandbox, ASLR, DEP, etc.) and highlighted a few security risks related to the iOS platform:
- Cache.db: SQLite database which caches every connection, it is not encrypted and may contain sensitive info such as credentials. Developers should not be using it as it is also available to other apps that use that log file.
- Inter process communication (IPC): : No API currently available and many apps just use the "Pasteboard" which is not private and any app can access. There is the possibility to use private pasteboards, but they only hide their names! By debugging an app you can find out what is that name and access it. This technic is therefore not secure either.
Apart from the 2 items mentioned above, this talk did not provide anything new about iOS application/penetration testing: you still rely on a Jail broken device and a controlled network proxy to test the security of your iOS apps.


6. Security analysis of android factory resets (click for BH description)
Presenter: Laurent Simon
Contact and papers: http://www.cl.cam.ac.uk/~lmrs2/
Related presentation: Cambridge Presentation
This talk was very interesting and highlighted major implementation flaws in most Android phones related to the deletion of data (remote wipe, secure delete, etc) which meant Laurent was able to recover data from second hand phones that were "securely" reset.

Laurent reminded the audience that SDD have a limited number of erase cycles, about 10000, as a result manufacturers/OS designers tend to be careful on how the OS manages HD blocks and by default there is no "strong erase" to save wear and tear. Most phone now have an eMMC which is a hardware chip in charge of disk access, the OS has no visibility of what happens when it is in use.

Laurent bought about 50 Android devices on eBay from June 13 to March 14, he did overwrite bit by bit the phones' partitions with identifying pattern, in order to identify any remains after a factory reset.
He got the following results:
- Old Android OS version was good, very secure delete with froyo
- Gingerbread used the wrong version of ioctl function, 90% of devices could get their data recovered!
- Sandwich used the right version, but still 60% of the devices could get data recovery. This was because those phones had been updated from Gingerbread. The phone manufacturers may not have updated the chipset drivers with compatible secure delete.
- Jelly Bean still had a problem with 10% of the phone samples. A Driver problem is very probable.
- Primary/Internal SD card (/sdcard) had worse results when compared to the data partition (/data)
- Secondary/External SD cards had 100% recovery!
- It was possible to recover passwords, Google master token, etc.

Finally Laurent discussed some possible mitigation controls, such as enabling full disk encryption. However, full disk encryption on Android does not support external SD card encryption and on it would still be possible to conduct an offline brute force attack on internal storage medium (hence the need for a strong PIN).
He pointed out that most mobile AV offering "secure delete" only leverage the remore wipe function. A few AV, such as Lookout, try to do more by also overwriting the data but they do not have system privilege on the device and cannot therefore overwrite everything, Laurent estimate that 90% of the data would still be recoverable!
The only way to really securely delete your data is to gain root access (jailbreak) on a device and do a bit by bit data overwrite (one pass should be enough)


7. Witchcraft for windows phone breakers (click for BH description)
Presenter: Luca de fulgentis
Luca stated Windows phones are becoming the new blackberry for business (what about iOS?!) and there is a growing interest in attacking such phones. He described 3 types of attacks: Logical, Physical and Network based attacks.
- Logical attacks:
Many apps are vulnerable to client side injections (HTML and JavaScript), it is also possible to attack the apps Inter process communication (IPC). There is also a Windows IPC specific attack because a Hidden IPC through "toast" messages. could be vulnerable to cross application navigation forgery attacks.
Luca also described issues with the Windows phone rendering API Webbrowser (XSS can be used to leak info) and Webview (8.1+ and harder to exploit)

- Physical attacks: Focusing on SD Card, Luca noted that whilst Windows Phone 8.0 access is read only and restrict the attack surface, in 8.1 read and write is allowed. You are also allowed to move apps to the SD card, it is then possible to replace the SD binary from the original app with a different exe and it would still run with the same privilege. Although apps are encrypted, when you replace the binary the OS reencrypt the app/container! It can be done through an exploit app that can be installed with a Ms developer account.
There are however a few caveats: The phone much be PIN unlocked, the SD Card Enabled and run OS 8.1 as Windows 10 doesn't appear to be vulnerable.

- Network attacks: Luca found some issues with the Windows App Store: Mix of TLS and non TLS traffic, Cert pinning badly implemented and MiM attacks are possible

To mitigate those risks one could use Bitlocker (Disabled by default) or use the DPAPI as it can be used to encrypt app data per user. However, it might still be possible to defeat the DPAPI control because it is linked to the user, if an attacker gains access to the app privilege he can recover the key.


8. SCADA and Mobile (click for BH description)
Presenter: Alexander bolshev and Ivan Iushkevich
Contact: @Dark_k3y
This talk focused on Mobile apps used to access or control Industrial Control System (ICS). The very concept is such a bad idea! as traditionally ICS systems have been kept segregated as much as possible from the external world or even the wider company's Intranet.

Their research focused on Android where they found 100 of SCADA apps. Those apps face the typical 3 threat vectors: Unauthorised physical access to device, Communication compromised and App compromised.
The result of their research is that all apps had some vulnerabilities with different level of severities, Siemens apparently doing better than other vendors. Not surprisingly, they found remote apps were more vulnerable than control room applications.

Alexander provided two examples of severe issues providing full remote control of the ICS environment through an app.
- The first one was related to a weak hash implementation which meant you could reverse engineer what was being done and see the traffic in clear text. This was yet another example of not implementing your own crypto!
- The second example was worse, with a SCADA application using a very poorly designed authentication mechanism when asking for a userid and password to connect the app to the ICS environment. To check if the password provided by the user is correct, the app requests the correct password to the server, which in turn sends back that password in an encrypted format back to the app. The app can then compare what the user typed with what the server sent. I can see why a company might have done that, the developper must have read somewhere (on a pack of cereal?) that hardcoding passwords is bad. What is equally bad is sending the password back to the application and use bad crypto (base64 is not crypto). It means, by using this poorly designed app it was possible to see the server credentials in clear text, and the culprit was the server itself by providing us with the password!

Another type of attacks to take into consideration are attacks that may trigger a "Fault state" which means the integrity of the ICS environment is no longer guaranteed. It doesn't necessarily mean that the attacker stole secret information or stopped a whole ICS but it may have damaged or changed enough data/sensors to trigger that "Fault State".
Why does this matter?
Because unlike traditional IT System where you could just do a reboot within hours/days, some ICS may require days, months of even years to restart! This could cost a lot of money indeed.


9. Malware network view (click for BH description)
Presenter: Kevin McNamee
Although it was another vendor led presentation (Alcatel-Lucent) this was really interesting to hear that phone companies do monitor their mobile network for Malware. It may sound quite logical and somewhat obvious, but I never heard of it being officially done.

They are monitoring mobile network globally (not Russia), using snort sensor on GTP-C and GTP-U traffic (GPRS, GSM). Because they are using snort, it means they are only monitoring for known issues and not zero days or unusual patterns... officially at least, because I think they might be using learning machines (everyone seems to be using this technology at the moment).
Kevin presented some interesting statistics:
- Problem is growing: Phone companies do not report malware infection the same way as pure infection, they report only on severe impact, I.e. Verizon reports 0.003%, where infection is more like 0.6%. Dumballa reports are even lower, because of their stringent requirement for infection. Mobile devices network infection detection rate is half as much than PC, but as mobile usage and functionality grows, so will the infection rate of mobile.

- Android malware is dropping dramatically: This is thanks to the recent changes made by Google and explained in a previous talk. At the same time a sharp increase of malware on windows phone

- Android malware: On the positive side, they currently lack of sophistication, their C&C is not robust, they do not try toward too much, they can be easily removed: delete the app!
On the negative side, app hijacking is trivial as it is easy to insert Smali code, repackage and sign with self cert. It is harder on iOS because the App Store does not accept self signed cert.

- LTE users are 5x more times likely to be infected: This is not because of LTE but because the more active you are on the network the more likely you are to get infected

- PC malware has an impact on mobile network: This is because PC are connected to mobile network for Internet purposes (tethering). Phone carriers are increasingly concerned about that, i.e. botnet traffic

- Mobile network infrastructure issues: If a mobile device is not network active for 20s, its mobile network bandwidth is dropped. The problem is if a botnet only contacts its C&C every minute as it leads to many devices disconnecting and reconnecting all the time. This is due to intense handshake and bandwidth on cell tower that produces negative impact. Fundamentally, radio signal is an issue for carriers because they do not charge for that
Mobile networks are also susceptible to DDOS attacks as a simple network scanning can create DDOS for against a cell tower, because this wakes up every mobile connected to it