Source Code, Please? Don’t Hand Hackers Your Vulnerabilities on a Silver Platter
Applications are under siege. As demonstrated by the recent Equifax breach and many others, hackers leveraged everything from compromised mobile apps to cloud-based vulnerabilities. The result? Enterprise IT teams are recognizing that they’re being targeted – particularly their critical apps.
The challenge? Since more enterprises are increasing their app development, and since these are being targeted more aggressively by hackers, this creates a new vulnerability many companies haven’t dealt with at an enterprise level yet. If the code is open-source or if the source code is easy to reverse engineer with free tools, hackers can review, debug and disassemble your application at their leisure and look for security vulnerabilities. It’s tantamount to handing over network security on a silver platter. Instead, here’s how you can make it harder for them, and easier for enterprise-level IT and code security staff.
Root Causes
While there’s no single explanation for the rise of application compromise, it’s possible to identify key trends shifting the hacker market and making business apps top priority. Key drivers include:
- Endpoint Explosion — As noted by Tech Target, estimates suggest that 30 billion connected devices will exist across public and corporate networks by 2020. The problem? Eighty-five percent of IT and networking professionals aren’t confident about the number of devices on their networks. As a result, hacked devices or endpoints may go unnoticed until hackers have penetrated deeply enough that removal is impossible and remediation is extremely difficult.
- IoT Security — Internet of Things (IoT) devices are everywhere. From “smart” homes and cars to fitness trackers, connected watches and Web-enabled printers and point-of-sale machines, the sheer number of devices provide opportunities for motivated hackers. More worrisome? Poor security. According to Network World product developers have underestimated the need for IoT security, with many devices running vulnerable services, or protected by default credentials — or none at all.
- Copycat Code — There’s no reason for app developers to create all-new code from the ground up every time they write a new application. In fact, it’s long been considered a best practice *not* to do so. The problem? Using common code can lead to widespread and easily exploited vulnerabilities such as HeartBleed or WannaCry. And as the IEEE points out, there’s often a significant delay in patching multiple apps which contain the same flaw — in fact, the median number of vulnerable hosts patched after exploit discovery is no more than 14 percent.
Application Hacks are on the Rise
Think hacking is overblown?
Hackers recently exploited a flaw in open-source Java server software in the Equifax site (which is discoverable by looking at the code) to steal records containing personal information on up to 143 million American consumers. For open-source code, a hacker can simply monitor releases, and look at differences, to see what code was patched and then exploit the vulnerability.
And consider a recent ZDNet piece, which reports an “unpatchable” flaw that attackers could exploit to take control of airbags, ABS brakes and power-steering, or remotely shut down any of the vehicle’s computerized components.
Or take a look at something really worrisome: The recent FDA recall of 465,000 pacemakers because they contained vulnerabilities which let hackers gain complete control. While previous attempts at hacking pacemakers showed that it was possible and the FDA began issuing warnings against potential backdoors in 2012, it’s clear the message didn’t quite hit the mark.
According to ICS-CERT, pacemakers manufactured by Accent/Anthem, Accent MRI, Assurity/Allure and Assurity MRI prior to August 28th, 2017 are vulnerable. Fortunately, a three-minute firmware fix will solve the problem but until that happens hackers could “gain unauthorized access to a pacemaker and issue commands, change settings, or otherwise interfere with the intended function of a pacemaker.” Three types of vulnerabilities were identified: Improper authentication, improper restriction of power consumption and missing encryption of sensitive data.
A Vulnerability Example
An important step every organization should take is to first find and fix all potential vulnerabilities, but it might be literally impossible to find them all. As an example, improper authentication happens when application code doesn’t prove or insufficiently proves that users are who they claim to be. If this flaw is missed then hackers could compromise admin functions. The flaw might take the form:
if (GetCookie("loggedin") != "true") {
if ( !AuthenticateUser(username, password) ) {
throw new NotAuthenticatedException("You need to log in first.")
} else {
SetCookie( "loggedin", "true" )
}
}
If a hacker has access to the code above, they would quickly discover that the server is improperly trusting a client provided cookie and they could easily bypass the authentication check.
Target Hardening
So how do companies handle the triple threat of increasingly quick app development, an unknown number of holes to plug, and the availability of common code for hackers to examine and exploit? Think about it like this: Just as every home is potentially vulnerable to burglary, so is every app vulnerable to compromise. If criminals are determined enough, they’ll find a way to break in and grab anything valuable.
As a result, companies need to adopt the practice of “target hardening.” Recommended to homeowners by many police agencies, it’s the process of limiting obvious vulnerabilities to convince bad actors they should pick another target. For houses this means installing security cameras, using automatic lights and ensuring valuables such as jewelry, wallets and keys are kept out of sight. For applications this means leveraging security solutions that can find and fix vulnerabilities, detect unwanted intrusion and removing access to source code. Could hackers still find it if they look hard enough? Absolutely. But moving code out of plain sight and eliminating common security issues — such as not quickly patching known vulnerabilities, fixing easily-manipulated SQL queries, etc. — can frustrate attackers. And if hackers can’t find easy ways to compromise apps, they may look elsewhere.
For the enterprise-level CIO, this means they need to take control of app development throughout their entire organizations, and not rely on development teams to take the necessary “target hardening” steps on their own. Uniform code security policies and practices must be mandated and standardized for complete and proper protection.
Bottom Line
Software is more and more critical to every aspect of business, and limited development time pushes IT to use common code and get code out quickly — and no matter how much you try, some critical vulnerabilities might slip through. Reduce the risk a bit more and make hackers work harder for smaller gains by keeping your proprietary source code under wraps and better understanding the risks if you use open-source.
