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

July 25, 2016 5009 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 Blog Posts

Protecting C# Applications That Use Dynamic Types

The dynamic type in C# provides flexibility that is not available in other statically-typed languages. Since its introduction in C# 4.0 (.NET 4.5), we have worked with customers who wanted to know more about how dynamic types are impacted by the obfuscation process.

Malicious actors — like any thieves — live by a simple rule: If the front door is locked, break the window.

It’s why threats like fileless malware and crypto-jacking have seen substantial gains over last few years. It’s why — despite increasing employee education and IT training — hackers are still hooking phish by developing more sophisticated and authentic-looking email spoofs. Cybercriminal communities, meanwhile, continue to grow on the dark web, allowing attackers to share info, purchase exploit kits and identify potential targets.

What does this mean for CISOs? That typical defense efforts are being outpaced as familiar attack vectors are replaced with non-traditional threats. But it’s not all bad news; here are three questions every CISO needs to ask to help close the doors, bolt the windows and leave hackers out in the cold.

Gabriel, you have been in the security industry for over 2 decades. You have seen many different tools and services. Why create a company around something as specific as obfuscation and in-app protection?

Our customers build a lot of really innovative apps that enable their users and customers to do new and cool things. These apps frequently run on untrusted client computers/devices and they control access to customer’s sensitive data or critical devices.

And after all the effort of designing, building, debugging, and deploying their applications, the last thing they want is for an attacker to steal their work or use it to look for vulnerabilities to break into their system.

Long ago, we built a Java code optimizer, but it became clear to us that our customer cared more about the obfuscation effects of the optimization than the actual performance improvement. That is when we really began to focus on app protection. First with Java, then .NET, Android, iOS, Xamarin, JavaScript, etc.

Gartner calls In-App Protection “crucial” in their July 2019 Market Guide for In-App Protection In-App Protection. The guide’s summary advises security and risk management leaders to “take due care in protecting their application clients” in order to avoid “security failure.”

This raises the question – what constitutes “due care?” Obviously, no development organization looks to recklessly expose their applications or sensitive data to attack or compromise. On the other hand, over-engineered (or poorly engineered) security controls can quickly lead to excessive development costs, performance and quality issues, and, ultimately, unacceptable user experiences. While terms and terminology may vary, there is broad consensus on how to best define “due care” for any given application/user scenario.

If you don’t follow application security closely, you might think of application obfuscation and symbol renaming as being synonymous – and with good reason. Many platforms and languages, like .NET, Java, and JavaScript have popular obfuscators that do little else--our own Dotfuscator Community Edition for .NET and ProGuard for Java are good examples. However, obfuscation is far more than symbol renaming – and in-app protection is far more than obfuscation. Much of this expansion has been driven by new security requirements, shifting attack vectors, the rise of mobile and IoT computing and, lastly, the growing recognition inside regulations and legislation of the exposure that can result from inadequately protected software.

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?

Protecting C# Applications That Use Dynamic Types

Non-Traditional Attack Vectors: Three Questions Every CISO Needs to Ask

Q&A With PreEmptive CEO Gabriel Torok

Gabriel, you have been in the security industry for over 2 decades. You have seen many different tools and services. Why create a company around something as specific as obfuscation and in-app protection?

The Secret to Effective In-App Protection

Symbol Renaming: App Security’s Maginot Line?

Latest Blog Posts

Protecting C# Applications That Use Dynamic Types

Non-Traditional Attack Vectors: Three Questions Every CISO Needs to Ask

Q&A With PreEmptive CEO Gabriel Torok

The Secret to Effective In-App Protection

Symbol Renaming: App Security’s Maginot Line?

Twitter