By Chris Crowley
It's going to happen sooner or later...sooner probably. You're going to be asked about your company's mobile app or a mobile app your company wants to install across all mobile devices. They'll put the request in the "yet another duty as assigned" (YADAA) category/bucket. You look at the network traffic; it's using TLS so you can't see the content. Cool, right? Maybe, maybe not. Can an attacker get man in the middle position by tricking users, or by attacking the very root of trust (well, one of the 100 or so root CAs) that is used to sign a TLS server cert? It is a complicated situation and requires a thorough understanding of several systems and protocols to address. I want you to be smart on the subject, so when that YADAA comes your way, you can answer the question knowledgeably and authoritatively. So here you go...read on.
The first installment of this two-part blog post will provide some background on TLS (Transport Layer Security) certificates
By Lee Neely
In the first installment of this 2-parter, I discussed the use of mobile device fingerprint scanners to unlock the device. As a follow-up, I'd like to discuss how a developer can integrate the scanner into their applications. This discussion may provide some insights into how to secure mobile apps, or even inspire some hacking ideas (this is a pen test related blog, after all). At the end of the article below, I'll discuss some ideas for compromising this type of environment.
In part one, I introduced the secure environment used to manage fingerprints. This environment is called by a couple of names. Most commonly it's called the Trusted Execution Environment (TEE) and Secure Enclave. In both cases, the terms describe a separate environment consisting of hardware and software, which performs
By Lee Neely
Mobile device administrators and end users need to be more cognizant of the risks of allowing unauthorized access to their smartphones and take steps to raise the bar on accessing those devices to mitigate those risks.
This is part one of two articles on securing mobile device access. In this article, I am going to focus on securing access to the physical device itself. In part two, I will discuss on-device security APIs and how one would know they are still in place.
The case for a strong passcode
When the first smartphones were introduced, they were corporate owned, managed, and secured to business standards. Device access was on par with accessing corporate laptop systems. The number, variety, and quantity of applications and personal or sensitive information stored on the device was far less than we see in modern iOS, Android, Windows Mobile, and other devices. While there were
By Joshua Wright
In the last installment of this article
, we looked at the IsItDown
application, and how it is designed not to run in the Android Emulator, and to include a super-annoying banner ad. We showed how the Apktool
utility can be used to decompile an Android APK file, and how we can evaluate and modify the produced Smali code to manipulate the application's functionality.
In this final installment, we'll re-build the IsItDown application with our Smali file changes, then
By Joshua Wright
As a security professional, I'm called on to evaluate the security of Android applications on a regular basis. This evaluation process usually takes on one of two forms:
- Evaluate app security from an end-user perspective
- Evaluate app security from a publisher perspective
While there is a lot of overlap between the two processes, the difference effectively boils down to this: whose risk perspective does my customer care about the most?
When an app publisher wants me to evaluate the security of their Android app, I need to determine if the app employs sufficient controls to protect the required app functionality and publisher brand. Often, this