Application Security Redux: It’s All about the Apps (Part 1)

If you would like to read the first part in this article series please go to:

• Application Security Redux: It’s All about the Apps (Part 2)
• Application Security Redux: It’s All about the Apps (Part 3)
• Application Security Redux: It’s All about the Apps (Part 4)
• Application security Redux: It’s All about the Apps (Part 5)
• Application security Redux: It’s All about the Apps (Part 6)
• Application Security Redux: It’s All about the Apps (Part 7)
• Application security redux: It’s All about the Apps (Part 8)

Introduction

Operating systems have always gotten the bulk of the attention when it comes to security, but for many years the stats have shown that applications are where many of the most dangerous vulnerabilities are lurking, and they are also less likely to be regularly updated than the OS. Today, application security is more complicated than ever, with traditional desktop programs, simpler “modern” apps, web apps, mobile apps and cloud apps all thrown into the mix.

There are many aspects to implementing application security in a business environment. Although a good patching policy lays the foundation, it’s only the beginning. You need to make a careful assessment and develop a strategy for dealing with applications that may include apps you want to block completely, apps you want users to have access to but for which you want to control some features or monitor what data is sent with them, and more.

Application Security: More than Meets the Eye

As with IT security in general, application security is a multi-faceted issue and the only way to address it is with a multi-layered approach that takes into account all the different aspects that are involved.

A comprehensive application security strategy will address the following:

• Preventing and patching coding defects (security vulnerabilities in the design of the software)
• Protecting applications from tampering or access
• Blocking undesirable applications
• Restricting what users can do with allowed applications
• Encrypting the data that is created, gathered or stored by applications

In this and subsequent parts of this series, we’ll take these one at a time and discuss examples and use case scenarios of each one, as well as how to accomplish ti.

Coding defects (application vulnerabilities)

If you’re a developer, you’re probably code-centric, so that when you think about application security, the first thing that comes to mind is flaws in the design of the application software that leave it vulnerable to exploit. Even if you’re not a dev, you wouldn’t be wrong to focus on that particular threat. According to a document from the Department of Homeland Security, the Software Engineering Institutes has estimated that approximately 90% of security incidents result from exploits against defects in software code.

The linked document lays out some guidelines for addressing this problem through the DHS’s Software Assurance Program. The stated goal is to reduce the number of vulnerabilities in software, to reduce the incidence of exploitation of those vulnerabilities that do exist, and to help developers create more reliable and secure applications.

Types of application software vulnerabilities

There are many different types of vulnerabilities and different techniques that can be used to exploit them. Memory corruption issues are very common these days, with stack overflows, heap overflows and integer overflows being some examples of subcategories of these.

Vulnerabilities that are classified as remote code execution or arbitrary code execution issues are often rated most critical, because if an attacker is able to run executables, he may be able to take complete control of a computer. That means he can access all the data (and change, delete or expose it), but the problem is bigger than that. If he gains administrative privileges, he can change permissions on files, add or remove other users from the admin group (or create new user accounts and delete other accounts altogether), change the configuration settings and even use the machine to bring down the network. Escalation of privilege vulnerabilities are often exploited in conjunction with RCE flaws, then, to gain that admin access.

Web browsers are one of the most commonly exploited applications, because unlike many applications, they are used by practically everybody who uses the Internet. We all have a web browser (or two, or four) installed on our machines and most of us use one every day. It’s no wonder the browser is a favorite target of attackers who hunt down flaw that they can leverage to do their dirty work, and a top focus for security researchers who seek to find and report vulnerabilities so they can be patched before exploits occur “in the wild.” In 2014, the number of web browser vulnerabilities increased sharply.

Cross-site scripting (XSS) flaws are a common type of vulnerability that’s often found in web applications. An attacker can exploit XSS vulnerabilities to inject malicious content into site and to bypass security policies such as same-origin policies that are designed to keep scripts from one web page from accessing data in another web page unless they have the same origin.

Web browser exploits often are aimed at add-in and web technologies such as ActiveX, Java and JavaScript, but can also target HTML or the browser’s PDF parser. Speaking of that, another type of application that is frequently targeted by attackers is PDF software. Again, this is because it is almost ubiquitous; we all need to read PDF files and so we all have Adobe Reader or some other PDF reader application installed.

Another vulnerability type that targets web applications is the SQL injection vulnerability, which attackers can exploit in order to read, change or delete data in a back-end database accessed over the web by submitting specially crafted malicious data to the application. The vulnerability is usually due to the failure of the application to validate or encode data that users input that is used in a query or a command. LDAP injection is another type of web application vulnerability that can be exploited to access and change objects in a Lightweight Directory Access Protocol (LDAP) directory tree.

Preventing application vulnerabilities

There are two aspects to addressing the application vulnerability threat:

• Preventing vulnerabilities from creeping into the code developed for your organization in the first place, and
• Fixing vulnerabilities that are discovered in the applications that your organization is using.

Obviously the first prevention of vulnerabilities in the development process is something that your organization has no control over in the case of commercial software provided by a third party vendor. However, if you have your own in-house devs who write custom software for your line-of-business tasks, then there are policies you can adopt and measures that you can take to ensure that the code is as vulnerability-free as possible when you put it into production.

Programmers should ensure, in writing the software, that input is validated properly by the application, rather than depending on the framework (e.g. .NET) or assume that application layer firewalls will provide all the protection that’s needed. Devs also need to test thoroughly for vulnerabilities before signing off on the software, and security testing should be ongoing since some vulnerabilities only present themselves in the context of specific configurations or use case scenarios.

Even in the case of off-the-shelf commercial software, there are still things that you can do – such as waiting to deploy brand new software products or versions rather than being an early adopter, that may (but is not guaranteed to) reduce your exposure to vulnerabilities.

Note:
While in theory the largest number of vulnerabilities would be present when the software is first released, and then it would become more and more secure as those flaws are discovered and patched, this doesn’t really work out that way in the real world – in part because the new code that is intended to patch one vulnerability can and all too often does introduce a brand new vulnerability.

Addressing existing vulnerabilities

Of course the primary means for addressing security vulnerabilities in software is to make sure it is regularly updated and that security patches are applied as soon as they’re released. Modern operating systems can be set to check for and apply updates automatically and in fact this is now usually the default (and with some versions of Windows 10, it’s difficult to turn off or circumvent auto update even if you want to).

Some applications can also update automatically. Other software applications must be updated manually. Application vendors – especially the smaller ones – often don’t respond as quickly to reports of vulnerabilities discovered by security researchers and don’t do as much in-house testing and research to find vulnerabilities, and/or may not issue patches as frequently as the large OS vendors do. Even a company as large as Oracle is on a quarterly patch cycle, so that you can easily have three months in between the time that a vulnerability is discovered (and potentially exploited) and the time that the vendor releases updates to fix the flaw.

Zero Day vulnerabilities – those that are exploited or made public prior to the vendor being informed of them or the availability of patches to fix them – are the most worrisome. However, general good security practices can help to protect your systems and networks from becoming one of those victimized by these exploits.

There are times when it’s not possible to update an application for some reason. Some application vendors don’t issue patches that address just the vulnerability, but instead fix it in a whole new version of the software, which contains other changes and may add or drop features. If your business has a dependency on one of the features that is removed in the new version, that can be a problem. In other cases, you might have a hardware or software configuration that has conflicts with the patch and causes system crashes or other problems that make the update contraindicative. Sometimes vendors will release workarounds that you can configure to make the software less vulnerable without applying the update, so check with the vendor about that.

Summary

Application security is a big topic, so it’s going to take more than one article to properly cover it. In this first part of a multi-part series, I’ve barely touched the tip of the iceberg, talking about the aspect of application security that we tend to think of first: vulnerabilities that are caused by flaws in the design of the software code. In Part 2, we’ll address who to protect applications from tampering or unauthorized access that isn’t related to code defects and thus can’t be fixed or prevented just by faithfully updating your programs.

If you would like to read the first part in this article series please go to:

• Application Security Redux: It’s All about the Apps (Part 2)
• Application Security Redux: It’s All about the Apps (Part 3)
• Application Security Redux: It’s All about the Apps (Part 4)
• Application security Redux: It’s All about the Apps (Part 5)
• Application security Redux: It’s All about the Apps (Part 6)
• Application Security Redux: It’s All about the Apps (Part 7)
• Application security redux: It’s All about the Apps (Part 8)