Don’t Let Leaky Apps Bring You Down
TAKE A SECURITY-FIRST MINDSET TO MINIMIZE EXPLOITABLE VULNERABILITIES
DATA THEFT and data leaks are so common today that many people just expect one to happen to them at some point in their lives. There are so many different pieces of technology that
connect to the internet in a variety of ways that it’s relatively easy for cyber-
criminals to find a vulnerability somewhere in the chain and exploit
it. “Leaky applications” are one area where cybercrime is booming. When
an app is leaky, it means that the app can either be used as a gateway to
attack other systems or as a target for an attack in its own right. For ex-
ample, an attacker might use a vulnerability in an app to steal credentials
that can be used to log in to a more valuable system, or they may just use that vulnerability to get in the app itself to essentially hijack it. When trying to determine whether
leaky apps are a problem, all you have to do is look at how much mobile device usage has grown over the past few years and how many apps ship with vulnerabilities from the start. For its 2016
Mobile Security Report, NowSecure analyzed more than 400,000 applications that were available on the Google Play store and gathered some interesting and concerning statistics. As far as usage is concerned, mobile device users spend more than 87% of their
time on the device accessing applications, and when it comes to the devices themselves, 74% of organizations either already have policies in place or will put policies in place in the near future
to allow BYOD and personally owned devices in the workplace.Those statistics on their own don’t
illustrate a problem and in fact just reflect how businesses are going mobile and being more flexible when it comes to how devices are used. The problem is that NowSecure’s study also found that 24.7% of mobile apps had at least one high-risk security flaw; 50% of popular applications sent data, in- cluding phone numbers, location in- formation, and more to advertising
networks; and 10.8% of all applications analyzed actually leaked sensitive in- formation over a connected network. Add to this the fact that business ap- plications are three times more likely
than other types of applications to leak log-in credentials, and you have too many attack vectors for businesses to realistically keep track of. Fortunately, enterprises have new methodologies they can put in place to prevent vulnerabilities from ending up in released applications. If vulnerabili-
ties are discovered once the app is actu-ally in production, there are even ways to patch them on-the-fly or quarantine certain vulnerabilities for a brief pe-riod to give the business time to react.
However, the first place you need to start when thinking about leaky apps is to understand that the types of attacks on those apps are always evolving and difficult to track.
Be Aware Of New Attack Types In the early days of leaky applica-tions, and when they were first dis-covered a few years ago, the concept primarily centered on games. In fact,
today, according to NowSecure, games are still 1.5 times more likely to have
a high-risk vulnerability than other applications. This is especially con-
cerning for companies that allow personally owned devices in the work-
place, because there’s a good chance they will have games installed. If a
cybercriminal were able to get to the phone through that gaming applica-
tion, then she could grab hold of any data stored on the device or any data
the device has access to. This idea of hijacking a mobile de-vice, a computer, or an account falls
right into the area of ransomware, which is where a cybercriminal locks
a user out of an important system and forces that party to pay a fee to re-
gain access. The problem with ran-somware is that attackers in that space
don’t discriminate based on size. “Ransomware is transactional cyber-crime, and what I mean by that is that it’s a business that’s characterized by a large number of small to medium-
sized transactions,” says Doug Cahill, senior analyst at Enterprise Strategy Group. “The ransoms aren’t typically huge. Sometimes they do get into seven figures, but very often they’re a
couple thousand dollars or $10,000. It depends on the target, but what that
means is that organizations of all sizes are at risk. Even if you’re an SMB,
you’re still subject to ransomware.” When it first started, ransomware
typically made its way onto a system via web or email, but Cahill says that
attackers are more often using ap- plications, and especially cloud apps, to inject malware. The reason for this is that organizations and their em- ployees have gotten better at spot-
ting potential spearfishing schemes and socially engineered emails, which means attackers are having to find new ways to get in. One way to do this is using file-sharing services, which often have mobile app counterparts that can cause multiple problems if
credentials are stolen. “Let’s say you and I talk once every month and you get an email
from me that says ‘Hey, I talked to you a couple weeks ago about leaky applications and I put together a pre-sentation on it that you can get from here,’” says Cahill. “You’re condi-
tioned to get content from Dropbox and get emails from not only col-leagues that work in the same orga-nization, but also third parties. That’s now being used as a way to introduce
ransomware into the environment.”What makes this worse is that many enterprise file-sync-and-share ser-vices use what Cahill calls a “one-to-many sync dynamic,” which means
that many people have their tablets, smartphones, and laptops all set up to automatically sync to a cloud folder. If that system is being used by the entire enterprise, then multiple users may
have information in that same folder. “If I can successfully insert a piece of ransomware or another type of mal-ware into that cloud storage folder, I get a one-to-many effect because all of
you have configured auto-sync,” says Cahill. “When I spearfish, I get it into one place, but if I do it via file sync and share, I can potentially infect multiple devices at once.”
Learn How To Identify Leaky Apps
To spot vulnerabilities in applica-
tions that may lead to data leaks, start
by keeping all of your technology up-
dated. Cahill points out that applica-
tions aren’t the only leaky systems.
Other possibilities include browsers,
browser plug-ins, and even entire op-
erating systems. “If you think about
how much time we all spend in a web
browser, that’s probably the first thing
is to make sure you’re patching regu-
larly and make sure you’re patching
the plug-ins that are used within a
browser,” says Cahill. “We’re constantly
getting messages to update Flash.
Ideally, you’re running client software
that automatically updates itself. That
would be sort of step one is to configure
auto-update.”
Another important step in identi-
fying leaky apps is to have some form of
vulnerability management solution in
place that “correlates software running
in a production environment with a list
of known vulnerabilities.” MITRE, for
example, has its CVE (common vulner-
abilities and exposures) database that is
free and open to the public and can be
used to find potential vulnerabilities in
software. Rapid7 and Tenable also offer
solutions in this space that are meant to
continuously scan environments and
applications for vulnerabilities, and
some even scan operating systems to
make sure there are no vulnerabilities at
that level.
Employ A DevSecOps Philosophy Although individual solutions are great, especially when it comes to vulnerability scanning, companies will need to adopt entirely new security phi-
losophies and methodologies to keep up with threats and prevent the release of leaky apps. Cahill says that most organizations are moving toward this concept of Agile software development,
which includes facets of DevOps, as a way to more quickly develop, test, and deliver applications. This may sound dangerous and that it might actually introduce more vulnerabilities, but Cahill
chooses to have a more optimistic outlook where companies can add security into their DevOps strategies and start to embrace a DevSecOps mindset with “continuous everything,” including
continuous testing, integrating, monitoring, and security. “Application security (AppSec) is
one of those security best practices and controls that should be part of DevSecOps,” Cahill says. That in-volves checking for coding practices, or scanning for vulnerabilities getting introduced at the time of software development, so bad code doesn’t get delivered. “We want to be checking
for bad code before it goes into pro-duction, so we should be applying application security things like code scanning, which is doing static anal-ysis of code before it gets delivered
to production. It’s amazing that more people don’t do this, because soft-ware vulnerability is one of the most common attack methods. Once it goes into production and is out in the wild,
then it’s vulnerable.” Even with this idea of scanning for vulnerabilities throughout the pro-
cess of developing an application, Cahill says you won’t be able to catch every vulnerability before the app goes into production, but you will be able
to catch some of them. That’s why he stresses that companies should consider putting a solution in place that not only integrates with your development tools and your development environments
but also one that can automatically per-form the scanning to truly fit into the DevOps methodology. Solutions from vendors such as Vericode, Threat Stack, and Trend Micro can handle this type
of scanning both internally and in the cloud. Of course, even with these so-lutions, you aren’t going to catch all
vulnerabilities, which is why you may
want to consider taking advantage of
other technologies that make it easier
to patch applications or at least prevent
vulnerability exploits while you work
on a patch.
“There’s an approach called vir-
tual patching,” says Cahill. “Let’s say I
have a vulnerability in production, but
I don’t want to patch it yet because I
don’t want to bring it down, but I want
to protect against any exploits that take
advantage of that vulnerability. What
you’re doing is running software that is
doing behavior analysis and looking for
exploits. I know an exploit will behave
this way, so I’m going to look for soft-
ware that behaves this way, and if I see
it, I’m going to prevent it. That allows
me to buy some time before I have to
actually patch the vulnerability.”
In the end, not any single solution is
going to prevent all apps from leaking
data, so you’ll need to take a multi-
layered approach that includes vulnera-
bility scanning and automatic patching,
but also foundational security con-
cepts such as encryption, firewalls, and
good old-fashioned policy. DevSecOps is a great model for including security throughout the entire application development process, but you also need to expand that concept to the organization as a whole. If you can put security first in all things, then you should be able to deal with leaky applications and vulnerabilities as they come along.
“As part of that hand-off between Agile software development and DevOps, you can incorporate doing application security tests, looking for vulnerabilities, and doing code scanning before it goes into production, and you can automate it, which is what DevOps is all about. It’s moving fast vis-à-vis automation. So we’re talking about leaky apps. What if you try to plug some of the leaks before you even get into production? That’s really the essence of adding application security as part of your DevOps methodology.”
DOUG CAHILL
Senior Analyst
Enterprise Strategy Group