Five Penetration Test Tips to Create Secure Mobile Apps

Just as businesses and consumers make the shift from desktop-driven digital change to mobile devices and applications, so are malicious actors. While traditional attack vectors still enjoy widespread success, increasing infosec knowledge about cybercriminal origins and threat profiles has pushed attackers down a new path: Mobile.

As noted by Threat Post, for example, advanced persistent threats (APTs) like RedDawn — which masquerades in app stores as “beta” versions of useful software — are now making the shift to mobile platforms. PC Authority, meanwhile, reports that fraudulent mobile transactions are up more than 600 percent from 2015, while Dark Reading points out that mobile users are now 18 times more likely to be targeted by phishing than traditional malware attack vectors.

What does all this movement mean for mobile app developers and owners? That just designing secure applications is not enough. Ongoing penetration testing and risk assessments are now critical to ensure that apps that were safe yesterday still hold up today — and won’t fall apart tomorrow.

In its recent GitHub $7.5B acquisition announcement, Microsoft promised to “bring its developer tools and services to new audiences.” “New audiences” in this context mean, quite literally, GitHub’s 28 million developer users. As the “largest open source community in the world,” GitHub audiences will most surely also mean new requirements, new priorities, and new expectations – but these will also come with old biases. And there is no better example of open source bias than code obfuscation.

For the typical open source developer, obfuscation is “like a pearl onion on a banana split” – it simply does not belong (with thanks and apologies to Philip Marlowe in Raymond Chandler’s The Long Goodbye).

The argument is simple enough – there is no reason to prevent the reverse engineering of open source applications because the source code is already public. It’s like picking an unlocked door.

I am not a superstitious person and I don’t believe in magic, but even still – I have to confess that the way Xamarin spits out Android and iOS apps (along with all the other platforms) feels kind of magical to me. Of course, when something breaks, I am reminded all too quickly that there is no magic happening here – Xamarin has just encapsulated a lot of complex steps into a neat and tidy black box.

For me, and I bet I am not alone here, I am very happy to leave that black box alone – and I am also happy to ignore as much of the platform-specific details as I possibly can.

Unfortunately, when it comes to security, there are platform-specific issues that simply cannot be ignored.

Welcome to the Support Corner, where we’ll occasionally talk about topics that we’re seeing while working with our customers. If you’d like to see more like this, please click the Support Corner Category.

In addition to Renaming and Control Flow, String Encryption is an obfuscation transform that can help protect your application. When customers enable String Encryption in Dotfuscator, they are often surprised to see that string constant definitions are still visible in decompiled code. Customers often contact us asking how to encrypt those string constants.

However, those string constants don’t need to be encrypted; they need to be removed entirely. Dotfuscator’s String Encryption feature takes the strings that have been inlined by the .NET compiler and encrypts them. That leaves the constant definitions behind, unused – and they can be removed.

Mobile App Security and Best Practices: Leveraging the OWASP 3-Layer Model

The mobile attack surface is expanding. As of January 2018 there were 3.7 billion unique mobile users worldwide choosing from more than 10 million verified applications across popular online stores. So it’s no surprise that security firms now detect millions of malicious install packages each quarter as hackers look for ways to compromise both existing mobile devices and their newest iteration, IoT.

In an effort to address the changing nature of mobile security the Open Web Application Security Project (OWASP) — well-known for its “top 10” vulnerability lists — has released version 1.0 of its Mobile AppSec Verification Standard (MASVS), which includes a three-layer model for application defense designed to “offer a baseline for mobile application security (MASVS-L1), while also allowing for the inclusion of defense-in-depth measures (MASVS-L2) and protections against client-side threats (MASVS-R). Here’s how your organization can leverage these layers to improve overall mobile app security.

Welcome to the Support Corner, where we’ll occasionally talk about topics that we’re seeing while working with our customers. If you’d like to see more like this, please click the Support Corner Category.

Recently, we’ve worked with a handful of customers who are using the Spring Boot framework. Spring Boot provides a simple way to create Spring-based applications. This blog explains how to protect jars created with the framework.

Spring Boot jars use an embedded class file structure which DashO does not directly recognize. DashO processes the regular class and package hierarchy. However, it does not embed the class files from the BOOT-INF/classes directory when writing the obfuscated jar.

1,000% increase in Dotfuscator usage among Xamarin app developers drives powerful new app and data security features.

SEATTLE, WA — May 8, 2018 — PreEmptive Solutions on Tuesday announced the immediate availability of Dotfuscator Professional Edition Version 4.35.0 and Dotfuscator CE 5.35.0. These concurrent releases include rooted device detection and response controls for Xamarin.Android apps.

Dotfuscator for Xamarin.Android

“Rooted device detection and response controls secure both Android apps and the data that flows through them,” said Gabriel Torok, CEO of PreEmptive Solutions. “Dotfuscator’s rooted device detection and response offers Xamarin.Android developers the first commercial implementation of this fundamental Android security measure, ensuring both effective risk management and auditability.”

How important is root detection?

• Rooted devices can be extremely dangerous: When running on a rooted device, an otherwise harmless App can unmount file systems, kill processes, or run any arbitrary command.
• Rooted devices are plentiful: In the annual Android Security 2017 Year in Review, Google reported that its SafetyNet service identifies over 14 million rooted devices DAILY.
• Sensitive applications must include controls to mitigate these risks: Recent PCI Security Council guidelines and NIST controls are just two notable examples where rooted device detection and response obligations are explicitly assigned to development organizations. More generally, rooted access is synonymous with unauthorized privilege escalation and is, therefore, incorporated by reference in virtually every privacy obligation developers face, e.g. GDPR, HIPAA...