Your apps may be getting hacked – Why should you care? What can you do?

July 25, 2016 4641 Views Gabriel Torok

Today more than ever, applications are mobile and can be run worldwide. And many useful apps access sensitive data and have value-added functionality within them (such as trade secrets). Because traditional firewall type attacks are much more difficult today, hackers are increasingly targeting both consumer and enterprise mobile and desktop apps as a newer attack vector. So, those apps may be at risk from theft of IP/underlying sensitive data, malware injection and more advanced targeted threats.

Is your application at risk? Answer these two questions first.

Does your app contain trade-secrets or intellectual property such as unique algorithms or monetizable value that could create revenue loss if successfully hacked?
Does your app process sensitive information that should be protected from unauthorized access to safeguard the privacy or security of an individual or organization?

If the answer to both is no, then you may be less at risk to hacking, theft and tampering. You can stop reading.

If the answer is yes to either, then you should strongly consider “hardening” your application by incorporating enhanced security state checking, code obfuscation and encryption before it is released. These steps will complicate the reverse-engineering, debugging and tampering process and increase resistance against compromise and exploitation. They will help move a DevOps process to a DevSecOps process.

Why is this necessary?

Because of free and easily available tools, reverse engineering of code has become a common practice for outsiders wanting to understand how to compromise an application, to bypass security checks and controls or get at underlying data. For some applications, unmanaged access to source code can also pose material risks including application vulnerability exposure, increased likelihood of system attack, theft of intellectual property, privacy violations, and revenue loss through circumvention of usage and other metering enforcements. Techniques such as obfuscation and encryption can make it materially harder to reverse engineer code by breaking the reverse engineering tools and/or making the output extremely hard for a human to follow.

In addition, applications can be made to be resistant to tampering. This might involve automatically inserting overlapping and redundant checks to determine if an application was modified in any way. Or detecting if an application is begin run in a jailbroken device that might compromise some of the safety guarantees. Exploitation of applications can take many forms. For example, by using a debugger on a production application, a hacker without any special privileges can:

Read data from your application
Insert and modify data inside your application
Interrupt the flow your application
Expose logic and flow of your application
Bypass application logic

The hacker could view encryption functions and the values of dynamic keys and observe when and how sensitive information is saved to file systems and databases. Or, they might modify and release a tampered version of an application to bypass controls (such as license checks), or inject malware code to collect and transmit data, etc.

An effective debugger detection, defense, and mitigation strategy might include:

Detection: Inject overlapping and hard-to-remove logic to detect unauthorized application execution within a debugger.
If true:

Process termination: immediately kill the app, or force it to run in a reduced capacity OR
Execute a custom method: invoke local code to intelligently and contextually defend and mitigate threats AND/OR
Transmit an alert message: deliver telemetry in real-time with a payload including application and runtime stats and any additional custom telemetry that you may require.

The same techniques could be applied to tampered apps, apps running on a jailbroken device and other conditions that could lead to an app’s integrity being compromised.

For sensitive or high value applications, organizations in virtually every industry are incorporating application hardening and obfuscation into their DevSecOps process. Because many of these techniques are applied at the binary level they can be difficult or error-prone to apply manually. Fortunately, an application hardening and obfuscation tool can easily be added to the end of your build process making your apps more resistant to reverse engineering and hacking.

What now?

If you are building with .NET, a free tool called Dotfuscator Community Edition is included in Visual Studio can get your team started today. https://msdn.microsoft.com/en-us/library/dd551423.aspx

If you are building with Java, a free tool called Proguard is available and can get your team started. https://sourceforge.net/projects/proguard/

If you are building for iOS, a free tool called PPiOS-Rename is available and can get your team started. https://github.com/preemptive/PPiOS-Rename

Of course, commercial full featured solutions are also available at https://www.preemptive.com/preemptive-protection

Latest NIST publication reinforces Developer Obligations (and liability)

On June 11, NIST released Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework. While a solid piece of work in its own right, this document is noteworthy because it stands as one more proof point - in an already long list of proof points, that development processes, the developers themselves, and the organizations they belong to, ALL share some degree of responsibility (liability) for:

Untrusted Environments, Valuable Apps? Put the Protection in the App.

IT environments are evolving. Disappearing are the days of in-house, fixed-endpoint, limited access server stacks — replaced instead by a combination of private and public cloud solutions, mobile applications and IoT devices.

As noted by research firm IDC, public cloud spending now outpaces all other IT infrastructure with a growth rate topping 10 percent year-over-year, while Statista reports that users downloaded more than 178 billion apps in 2017 alone — and are on track to break 250 billion over the next few years.

What does this mean for organizations? That application environments are quickly moving beyond the purview of in-house IT, exposing both apps and network services to steadily growing risk. It creates a paradox: Companies can’t deny the benefits of third-party environments and application partnerships, but also can’t ignore the threat of app and data compromise or reverse-engineering and tampering.

In a recent developer survey, Xamarin.Android developers were 50% less likely to have included rooted device detection or anti-tamper prevention as their Java Android peers were. Yet, both sets of apps are being deployed through the same marketplaces onto the same devices and are governed by the same regulations (PCI, GDPR, HIPAA to name just a few that expect these kinds of controls).

Why are more Xamarin.Android apps going unprotected?

I recently had the opportunity to sit down with Sebastian Holst, PreEmptive’s Chief Strategy Officer, to talk about his most recent trip to Capitol Hill where the topic of the day was copyright protection for small businesses – and for development shops in particular.

The life of a security architect is rarely simple. Assessing, defending and improving corporate networks requires thorough knowledge of industry best practices designed to secure critical data, combined with real-world understanding of hacker tricks and tactics meant to undermine this purpose.

As noted by the InfoSec Institute, this is an in-demand job that often comes with high expectations, odd hours and the need for constant professional evolution to stay ahead of cybercriminal threats. Complicating matters is the breakneck pace of technological advancement. The rapid rise of cloud deployments, mobile applications and IoT devices can make even best-laid security strategies seem like flies in amber — hopelessly out-of-date and effectively immobile.

Here’s a look at what’s really bugging security architects — and how they can break the mold of static security to combat emerging threats.

Your apps may be getting hacked – Why should you care? What can you do?

Is your application at risk? Answer these two questions first.

Why is this necessary?

What now?

Latest NIST publication reinforces Developer Obligations (and liability)

Put the Protection in the App

Untrusted Environments, Valuable Apps? Put the Protection in the App.

Are Xamarin.Android app users at risk?

Changes are coming for US Copyright – Should Developers Even Care?

Fly in Amber: What’s Bugging Infosec Architects?

Latest Blog Posts

Latest NIST publication reinforces Developer Obligations (and liability)

Put the Protection in the App

Are Xamarin.Android app users at risk?

Changes are coming for US Copyright – Should Developers Even Care?

Fly in Amber: What’s Bugging Infosec Architects?

Twitter