Sunday, October 04 2015
Tuesday, September 01 2015
Black Hat Europe November, Amsterdam NL. ALL YOUR ROOT CHECKS BELONG TO US: THE SAD STATE OF ROOT DETECTION by Azzedine Benameur & Nathan Evans & Yun Shen.
ANDROBUGS FRAMEWORK: AN ANDROID APPLICATION SECURITY VULNERABILITY SCANNER by Yu-Cheng Lin.
AUTHENTICATOR LEAKAGE THROUGH BACKUP CHANNELS ON ANDROID by Guangdong Bai.
FAUX DISK ENCRYPTION: REALITIES OF SECURE STORAGE ON MOBILE DEVICES by Daniel Mayer & Drew Suarez.
FUZZING ANDROID: A RECIPE FOR UNCOVERING VULNERABILITIES INSIDE SYSTEM COMPONENTS IN ANDROID by Alexandru Blanda.
LTE & IMSI CATCHER MYTHS by Ravishankar Borgaonkar & Altaf Shaik & N. Asokan & Valtteri Niemi & Jean-Pierre Seifert.
TRIAGING CRASHES WITH BACKWARD TAINT ANALYSIS FOR ARM ARCHITECTURE by Dongwoo Kim & Sangwho Kim.
Secret Conference October 9th, NYC. Talks by Jon Callas and Dan Ford from Silent Circle / Blackphone.
Ruxcon October 24-25 Melbourne, Aus. TEAM PANGU on
DESIGN, IMPLEMENTATION AND BYPASS OF THE CHAIN-OF-TRUST MODEL OF IOS. MARK DOWD on
MALWAIRDROP: COMPROMISING IDEVICES VIA AIRDROP.
JOSHUA KERNELSMITH SMITH on HIGH-DEF FUZZING: EXPLORING VULNERABILITIES IN HDMI-CEC.
BABIL GOLAM SARWAR on
HACK NFC ACCESS CARDS & STEAL CREDIT CARD DATA WITH ANDROID FOR FUN &PROFIT.
COLBY MOORE on
SPREAD SPECTRUM SATCOM HACKING: ATTACKING THE GLOBALSTAR SDS.
ToorCon San Diego October 24-25, San Diego, CA.
The Phr3$h Pr1nc3 0f Bellk0r3 on Fuzzing GSM for fun and profit.
SyScan360i October 21-22 Beijing China.
Fuzzing Android System Service by Binder Call to Escalate Privilege by Guang Gong.
PacSec November, Tokyo JP.
BlueToot / BlueProx - when Bluetooth met NFC by Adam Laurie.
ZeroNights 25-26 November, Russia.
Extracting the painful (Blue)tooth by Matteo Beccaro and Matteo Collura.
HP / ZDI will not run Mobile Pwn2Own at PacSec (in Japan) due to export restrictions.
Source Dragos Ruiu.
This is unfortunate.
Personal note: Since September I'm working for Square doing mobile security engineering. This blog will only be temporarily affected by the job switch as I get settled I will return to more then one post per month.
Tuesday, August 18 2015
Black Hat Europe Nov 12-13 Amsterdam. (IN-)SECURITY OF BACKEND-AS-A-SERVICE by Siegfried Rasthofer & Steven Arzt. ALL YOUR ROOT CHECKS BELONG TO US: THE SAD STATE OF ROOT DETECTION by Azzedine Benameur & Nathan Evans & Yun Shen. AUTHENTICATOR LEAKAGE THROUGH BACKUP CHANNELS ON ANDROID by Guangdong Bai. LTE & IMSI CATCHER MYTHS by Ravishankar Borgaonkar & Altaf Shaik.
Ruxcon Oct 25. Melbourne Australia. HIGH-DEF FUZZING: EXPLORING VULNERABILITIES IN HDMI-CEC by JOSHUA 'KERNELSMITH' SMITH. DESIGN, IMPLEMENTATION AND BYPASS OF THE CHAIN-OF-TRUST MODEL OF IOS by Team Pangu.
Hacker Halted September 17th, Atlanta GA. One SMS to hack a company by Dmitry Chastuhin. Why You'll Care More About Mobile Security in 2020 by Tom Bain.
Virus Bulletin September 29th, Prague. Mobile banking fraud via SMS in North America: who's doing it and how by Cathal Mc Daid. Will Android trojan, worm or rootkit survive in SEAndroid and containerization? by William Lee and Rowland Yu. Dare 'DEVIL': beyond your senses with Dex Visualizer by
Jun Yong Park and Seolwoo Joo. Android ransomware: turning CryptoLocker into CryptoUnlocker (live demo) by Alexander Adamov.
Unfortunately I had to cancel my talk at Android Security Symposium in
Vienna due to a scheduling conflict. It is a real bummer but I can't do anything about it. The replacement talk is
done by my friend and research buddy Matthias
he is doing a talk on one of our previous mitigation projects.
The iOS KeyRaider malware looks rather interesting. It combines a lot of different functionality. Such as
steeling AppStore credentials and a ransomware module. This malware again only targets jailbroken iOS devices, users specifically had to download apps from third-party Cydia repositories. So this is not a general threat but a threat to people who jailbreak their device. If you jailbreak you likely have a very specific need and you hopefully know what you are doing. If not, just don't jailbreak your device (no matter what OS is runs).
I just found this recently published paper titled: Header Enrichment or ISP Enrichment? Emerging Privacy Threats in Mobile Networks. The paper studies HTTP header
modifications and injection that is done by mobile network operators. The paper more or less is a direct follow up to my
paper on the same subject titled: Privacy Leaks in Mobile Phone Internet Access. Their paper looks at what happens to smart phones that actually use HTTP (my work was mostly focused on phones that used the WAP technology - even though WAP was translated to HTTP to access regular web pages). Anyway their paper provides a good insight in what is happening. If you run a website that get a lot of mobile traffic you should look if you see some of the HTTP headers that are injected by the mobile carriers.
A rather short updates this time. Until next time!
Tuesday, July 21 2015
Finally I have time to write a new blog post again.
The last couple of weeks have been super busy for me.
I had to finish a project, prepare a talk about it, and give a bunch of talks at various places in July and August.
T2 Helsinki, Finland. LTE (in) Security Ravishankar Borgaonkar & Altaf Shaik.
BalcCon Novi Sad, Vojvodina, Serbia. Private communications with mobile phones in the post-Snowden world, the _open_source_ way by Bojan Smiljanic.
APPSEC USA San Francisco, CA. QARK: Android App Exploit and SCA Tool by Tushar Dalvi and Tony Trummer. SecureMe - Droid' Android Security Application by Vishal Asthana and Abhineet Jayaraj. OWASP Reverse Engineering and Code Modification Prevention Project (Mobile) by Jonathan Carter. ShadowOS: Modifying the Android OS for Mobile Application Testing by Ray Kelly.
GrrCon Grand Rapids, MI. Phones and Privacy for Consumers by Matthew and David
I recently bought an Apple Watch.
The primary reason was fun. Also since I switched to Two-Factor Authentication (2FA) for all my private
infrastructure and all my web accounts that support it I though it would make life easier. I use Duo 2FA for my own stuff and they have a Watch app which is pretty convenient.
Before I owned the first pebble watch. I liked that a lot
even tho I had a lot of issues with the Bluetooth connection between the pebble and my Nexus 5. Sometimes it worked great and sometimes it just didn't work at all.
I also got a LG G Watch R (W110) (Android Wear) but I didn't really use it.
It was much too big for my wrist. Also the round display was kinda strange. Some of the apps seem to not be designed for it and cut off parts of the
information that should be displayed.
I also found the interface to be confusing, but this might be due to my very very short trial run of the watch.
Between the pebble and the LG Watch I also had a Toq but the Toq had many issues besides its size so I never really
used it. I tried to wear it like once.
Anyway the only reason I write about smartwatches is because I really like the Duo 2FA watch app. This makes 2FA much much easier and user friendly.
I known I'm not the first to write about smartwatches or wearables in the security context but the user friendliness could really make a difference.
Also a watch is harder to loose then a token (if you still use one of those).
I guess I don't have to say much about the Stagefright series of Android security vulnerabilities. The vulnerabilities are present in Android's media format handling library (named stagefright). Several factors make
this bugs interesting. First, every Android version after 2.2 was vulnerable (at the time of discovery) that was around 95% of all devices.
Second, the bug can be remotely triggered via MMS. Yes MMS once again provides the ultimate attack vector against smartphones. Who would have known? ;-)
The bug was patched relatively fast by Google since Joshua provided patches. Google started shipping OTA updates for their Nexus devices relatively fast.
Still most Android devices will not get patched or will receive their patches super late (and thus users will not be protected in a timely fashion). The
reason for this is mostly the mobile ecosystem which is largely not suited for fast patch deployment. I provided some comments about this issue
on NPR in late July.
While patches/updates were rolled out Jordan from Exodus found that the patches are not complete and contain more vulnerabilities
in the exact code that was fixed in the update. His blog post describing the issue is here.
The only way to protect yourself is to update your device to firmware version that does not contain the vulnerability.
If you are one of the many people who own phones that did not yet receive an update your only chance is to disable MMS auto-download.
This will not kill the bug since you can still be attacked using other vectors (e.g. download and play a .mp4 file) but disabling
MMS auto-download will at at least remove the automatic remote exploitation problem. A step by step way to disable MMS auto-download
for various MMS clients is provided by Lookout here.
Tuesday, June 23 2015
Everybody heard that Hacking Team got hacked
While I think this is pretty great since they are kinda known to be scumbags since they
sell to repressive governments I found out about not so great things around this hack.
Actually I didn't find out myself put was pointed to it by other people on Twitter
, via email, and personal (thanks Michael Weissbacher!).
Basically I was told that Hacking Team used a bunch of my Android tools to build their monitoring
software for Android.
What got me really upset is this email:
This person thinks that I wrote the Android voice call interception for Hacking Team.
This is obviously not the case! Hacking Team took my ADBI framework and tools to build their
software around it. The software this specific email is talking about is hackedteam/core-android-audiocapture (the link goes to the hackedteam GitHub repository). You can see that they kept even the original filenames (e.g. libt.c) that was
part of my original ADBI release.
I was analysing recent leak of hacking team from italy, and saw you supply the core android audiocapture for hijack voice calls on android. Have you updated it to new devices like lollypop?
The reason why someone might think I wrote those tools for Hacking Team are pretty obvious once you take
a look at the leaked code. Take, for example, the libt.c file from the HackedTeam repository. Hacking Team left all the copyright information (my name, website, and email address) in those files.
In addition to my ADBI framework Hacking Team also used my SMS fuzzer injector that I wrote in 2009
while working on the SMS fuzzing project together with Charlie Miller. Their Android fuzzer also made use of my ADBI framework.
I'm pretty angry and sad to see my open source tools being used by Hacking Team to make products
to spy on activists. Even worse is the fact that due to the lazy way they managed their source
repository less informed people might get the idea that I developed parts of their tools for them.
Just to make this very clear: I did not write any of those tools for Hacking Team.
For the future I will use a license for all my software that excludes use for this kind of purpose.
I have no clue yet how this license would look like so if anybody has a hint about pre existing open source licenses that exclude this kind of usage please drop me an email.
Obviously Hacking Team also used other open source software such as Cuckoo Sandbox. I hope everybody
is going to think about future license to prevent this kind of usage.
I'm not a lawyer but I would be interested in what legal action one could take if their software
license excluded the use case of Hacking Team.
Below some links to the Hackedteam GitHub repository and the link to my ADBI repository. You can clearly
see that it is based on my software.
Comments welcome via email to: collin AT mulliner.org
Monday, June 08 2015
Defcon QARK: Android App Exploit and SCA Tool
Tony Trummer and Tushar Dalvi (this is the only talk that was added after my last post)
All other conferences still have their CFPs open and didn't post any talks yet. The BreakPoint schedule is also not final yet.
Breakpoint 22-23 October, Melbourne, Australia. TEAM PANGU:
DESIGN, IMPLEMENTATION AND BYPASS OF THE CHAIN-OF-TRUST MODEL OF IOS; JORDI VAN DEN BREEKEL:
RELAYING EMV CONTACTLESS TRANSACTIONS WITH OFF-THE-SHELF ANDROID DEVICES; DMITRY KURBATOV: ATTACKS ON TELECOM OPERATORS AND MOBILE SUBSCRIBERS USING SS7.
I wanted to point to something that apparently not many people know about: Pangu jailbreak installs unlicensed code on millions of devices. Pangu has their own statement about this.
The Wikipedia page about Pangu Team states that they didn't have to sign an NDA for the training and therefore can use the vulnerability. Stefan's point is not about the vulnerability but about his code. All in all I can't verify all claims but I would say I know Stefan well enough to say that he would not make this up simple because he doesn't need to. He is very well known anyway so this is not a publicity issue for him. I 100% agree with Stefan's point of view about denying people from speaking at conferences if they are known to take credit or sell code they don't own or have a license for.
I encourage everybody to read up on this and to read statements made by BOTH sides. Please share your opinion with people who run conferences.
Android now has a bug bounty program, or as the call it Android Security Rewards Program.
Pretty cool, I wonder if they get more submissions because of this.
Apple tries to kill plain-text connections "If you're developing a new app, you should use HTTPS exclusively.". This feature is called
App Transport Security (ATS) and in the current iOS 9 version it can still be disabled. See: Configuring App Transport Security Exceptions in iOS 9 and OSX 10.11.
Android has had a similar feature for some time. Android M introduces a new Manifest option to declare if an app uses
clear text traffic or not. Deepening on this option the framework can deny clear text traffic from the app. A decent writeup on this topic is here: Android M and the war on clear text traffic.
Thursday, May 28 2015
Black Hat USA
AH! UNIVERSAL ANDROID ROOTING IS BACK by Wen Xu; ANDROID SECURITY STATE OF THE UNION by Adrian Ludwig; ATTACKING YOUR TRUSTED CORE: EXPLOITING TRUSTZONE ON ANDROID by Di Shen; CERTIFI-GATE: FRONT-DOOR ACCESS TO PWNING MILLIONS OF ANDROIDS by Ohad Bobrov & Avi Bashan; CLONING 3G/4G SIM CARDS WITH A PC AND AN OSCILLOSCOPE: LESSONS LEARNED IN PHYSICAL SECURITY by Yu Yu; COMMERCIAL MOBILE SPYWARE - DETECTING THE UNDETECTABLE by Joshua Dalman & Valerie Hantke; CRASH & PAY: HOW TO OWN AND CLONE CONTACTLESS PAYMENT DEVICES by Peter Fillmore; FAUX DISK ENCRYPTION: REALITIES OF SECURE STORAGE ON MOBILE DEVICES by Daniel Mayer & Drew Suarez; FINGERPRINTS ON MOBILE DEVICES: ABUSING AND LEAKING by Yulong Zhang & Tao Wei; FUZZING ANDROID SYSTEM SERVICES BY BINDER CALL TO ESCALATE PRIVILEGE by Guang Gong; MOBILE POINT OF SCAM: ATTACKING THE SQUARE READER by Alexandrea Mellen & John Moore & Artem Losev; REVIEW AND EXPLOIT NEGLECTED ATTACK SURFACES IN IOS 8 by Tielei Wang & HAO XU & Xiaobo Chen; STAGEFRIGHT: SCARY CODE IN THE HEART OF ANDROID by Joshua Drake; THIS IS DEEPERENT: TRACKING APP BEHAVIORS WITH (NOTHING CHANGED) PHONE FOR EVASIVE ANDROID MALWARE by Yeongung Park & Jun Young Choi; TRUSTKIT: CODE INJECTION ON IOS 8 FOR THE GREATER GOOD by Alban Diquet & Eric Castro & Angela Chow
Defcon RFIDiggity: Pentester Guide to Hacking HF/NFC and UHF RFID by Francis Brown and Shubham Shah; How to Shot Web: Web and mobile hacking in 2015 by Jason Haddix; LTE Recon and Tracking with RTLSDR by Ian Kline; Extracting the Painful (blue)tooth by Matteo Beccaro and Matteo Collura; Stagefright: Scary Code in the Heart of Android by Joshua J Drake; Build a free cellular traffic capture tool with a vxworks based femoto by Yuwei Zheng and Haoqi Shan
This year Black Hat US really has a large number of mobile related talks!
There is not too much to talk about otherwise. I still have to read all the stuff about Android M, some stuff is covered in the links section below. Make sure to checkout some of the HITB Amsterdam 2015 slides. Some good stuff in there for us mobile sec people.
I was really amazed how much publicity the iOS messaging crash got. Yes, it was easy to trigger. But yes, this kind of stuff happened before.
I bought an Amazon Dash button just when it was released. A few weekends ago I had time to play with it and here is my write up. This is not really a security write up, I was just interested in how it works. There is a decent hardware focused overview available here: Inside the Amazon 802.11b/g/n Dash Button. This overview is more on the software side!
The Dash button connects to Wifi and sends a HTTP POST every time you press the Dash's button.
The Dash is completely shutdown until you press the button, it will switch off seconds after the HTTP request is done with a small timeout to wait for the server's reply. The HTTP connection is protected via SSL but the Dash button doesn't check the certificate and can be easily intercepted. The main part of the data exchange seems to be the Dash Serial Number (DSN).
The Dash button is a simple way to reorder a specific item from Amazon.
The item that is ordered needs to be preselected at setup time, so far each button
only allows you to select from a very small list of related items.
My Cottonelle button only allows to pick one out of four Cottonelle products.
So unfortunately you cannot just order ANY Amazon item :-(
Below: my mock-up for what people actually want to use the Dash button for (beer, bacon and condoms).
The setup process is pretty straight forward. You install the Amazon app on your phone and go to My Account and select the Dash Button menu.
The app takes you through the steps and your Dash is configured.
Some interesting parts of the setup are.
The Wifi is configured from the app using an audio channel. In the setup mode of the Dash
it receives the audio and demodulates it to set the Wifi network name and the password.
In addition to the audio based configuration the Dash also creates a Wifi access point named Amazon ConfigureMe. Once you connect to it you can go to http://192.168.0.1 and configure the Wifi settings via the web interface. Once you click Configure the Dash reboots. I actually didn't manage to connect the Dash after configuring it through the Wifi interface (I also didn't try that hard).
As the last part of the setup you select that product you want to reorder every time you press the Dash button.
While playing with the Dash I discovered a number of small things.
Conclusion / stuff to do:
The Dash opens ports 80 and 443. I was NOT able to connect to 443. Port 80 obviously provides the web interface to configure the Wifi settings (previous paragraph).
The Dash shows up as WICED*DHCP*Client on your Wifi router host list.
All communication goes to parker-gateway-na.amazon.com on port 443.
The Dash button does NOT check the certificates so you can easily MITM it and look at the network traffic.
I used my Wifi router's DNS service to resolve parker-gateway-na.amazon.com to a local IP address running webmitm (from the dsniff package). Using the generated key/cert you can easily look at all the network traffic using ssldump or wireshark.
How to generate network traffic without ordering anything!
The one problem with the Dash is that it is only online (connected to the Wifi) for a short time when you press the button. Pressing the button will initiate an order, so playing with your Dash could end up in a lot of toilet paper showing up at your doorstep.
One easy way to avoid this is by skipping the last step of the configuration. If you skip that last step your Dash button thinks it is configured but the backend doesn't. The last step of the configuration is selecting the product you want to order. Basically you need to quit/kill the Amazon app when it asks you to select a product for your Dash button. Once you do this you can press the Dash button as often as you want without triggering an order of toilet paper. The Dash button will come online connect to your Wifi and connect back to the Amazon backend. This gives you the time to collect network traffic or port scan the Dash.
Dash network traffic
I only looked at the traffic between the Dash and the Amazon server. I didn't look at the traffic from the Amazon app to the Amazon server during setup. I should have done this but I didn't. Now I don't have the time to do it. I barely have the time for this writeup.
From what I can see the Dash sends only a few messages to the server. The first thing you see is that the messages always contain the Dash serial number (DSN) that is printed on the back of the Dash button.
All communication is carried out via HTTP POST. Content-type is set to: binary/rio. The encoding is set to chunked. The encoded data is a mix of ASCII and binary with a length fields for specific parts. I didn't have the time to reverse the message format, I just took a brief look at it. The last part of each message seems to be 20 bytes of binary data.
During setup the Dash sends some data such as RSSI values to the Amazon backend. There is a status bit field message and of course there is the message that is sent when the button has been pressed and the Dash thinks it is fully configured. If the Dash thinks it is not setup correctly pressing the button will just lead to a blinking red light.
If it thinks it is configured it will connect to the Wifi and send a specific message. The message is rather short and mainly consists of the DSN followed by the 20 bytes of binary data. The server answers to this with different messages. The only message I saw so far was the message for a not fully configured Dash button (HTTP 412 Precondition Failed). So far I was not in the mood to actually order something. I leave this exercise for other people.
Message sent during setup:
Some status message:
Some message sent from the Dash to the server:
Message sent when the Dash button is pressed and the Dash thinks it is configured:
Server answer when the Dash button does not have a product associated:
The Dash seems like a fun toy, I wish you could just configure it to order any item from Amazon.
I know the current version is just a trial and I hope in the future they will allow you to select any product.
Happy further hacking!
One thing that I found strange is that there is no back communication from the server to the Dash button at setup time. The only message that is sent from the server to the Dash is after the server receives an order item message after pressing the Dash's button. This must mean that you can either modify the message and change the DSN to initiate an order for another Dash button. OR The last 20 bytes provide integrity protection for the message.
Hacking Todo List:
Sniff traffic of an actual order. Specifically the answer from the server.
Open the device and dump the firmware!
Reverse message format. What are the last 20 bytes in the message? My guess this is for integrity protection. Like an HMAC. But this is just wild speculation.
Sniff communication between Amazon App and server during Dash setup.