Application Security 202: Vulnerabilities Accepted

vul·ner·a·bil·i·ty

The quality or state of being exposed to the possibility of being attacked or harmed, either physically or emotionally.

This is the Oxford English Dictionary definition of vulnerability.  But I’m going to modify it a little bit to reflect our topic of application security.

ap·pli·ca·tion vul·ner·a·bil·i·ty

The state of being exposed to various interconnected systems, where malicious actors will exploit any weakness, potentially leading to a security breach.

Notice I said, “where malicious actors will exploit any weakness”.  Because they will.  There are estimates that hackers are stealing dozens of records per second and creating hundreds of thousands of new pieces of malware every day.  Despite this information, many businesses continue to believe they are not in the crosshairs of hackers.  Let's take a peek into why yes, you are a target.  Here are a few common misconceptions.

My business is too small and would not be worth the effort.

It’s not just the big corporations that attackers go after.  There are a multitude of ways a hacker could turn your data into a profit.  Even if you are selling a small number of goods or services, the information you may keep on your customers is valuable.  Sensitive user data can be leveraged for all kinds of illegal activities, from identity theft to extortion.  You don't want to put your customers or your reputation at risk. 

Consider that your database containing customer emails and passwords gets dumped by an attacker.  Best practice dictates to not use your work email for personal transactions and to not use the same logins and passwords across different applications.  But unfortunately, the amount of successful credential stuffing that we perform proves otherwise.  What if one of your customers works for a big corporation?  Maybe they ordered something on their lunch break using their work email.  If an attacker has your customer's work email and the password they used on your site, they may be able to reuse that information to compromise them on other applications, or even potentially gain access to their corporate network.  If that user has elevated privileges on the network the attacker could just be a few clicks away from doing some major damage.  And it’s not uncommon for an attacker to escalate the privileges of a user with limited access.  By leveraging misconfigurations, bugs, and insufficient access controls, a hacker can potentially increase the scope and scale of their permissions into one with full system access.  And the larger the company, the more difficult it becomes to manage all the users and what they have access to.

None of our applications are public-facing, so they are safe.

I can’t count the number of times we have found an application or application login page that the client considered “private” because:

1. It was on a non-standard port that redirected to an internal application.  
2. It had a non-publicly advertised domain, like internalclientapplication.mycompany.com
3. The application is on the firewalled DMZ

Numbers 1 and 2 use a method called “security through obscurity” and it’s not safe.  There are bots that will scour all 65,535 ports on an IP address looking for services to respond.  There are tools like Burp Suite that can be used to do everything from locating subdomains to tampering with request and response traffic.  

Number 3 has a DMZ.  How is that DMZ configured?  Is the DMZ sitting behind a WAF?  What is being used for authentication?  Is your application required to be PCI DSS compliant?  There is a lot to consider if you choose to allow traffic into your network.  The safest method would be to have the application on a separate server that is segmented off from the rest of the network.  But it’s not always feasible to do so.  

I’m using an SSL certificate.

This plays a crucial role in securing web applications, but they are still being compromised.  SSL will encrypt data in transit but it leaves the origin exposed.  There are other loopholes that can be taken advantage of depending on which version is being used and if it can be downgraded.  TLS is actually the improved version and successor protocol to SSL.  TLS 1.3 is currently the most up-to-date version and is considered the strongest and safest, though it’s impossible to say if any zero-day attacks exist at this time.  

An interesting report released recently on TLS failures can be found at the link below.  This is worth reading and assuming their results check out, could be the strongest argument yet for upgrading to TLS 1.3 as soon as possible.

Open to a fault: On the passive compromise of TLS keys via transient errors

Something else to keep in mind when considering your threats is that hackers don’t always hack for financial gain.  It’s the primary motivator, yes.  But there is a number of reasons you could be a target.  If you can see them coming, most hackers will fall into one or more of these categories below.  Which of these might be a threat to you? 

• Financially Motivated: These can be individuals, small groups, or highly organized criminals.  They will steal information and sell it on the dark web, rack up credit card charges, drain bank accounts, and demand ransoms. 
• Hacktivists: Usually politically motivated or fighting for a cause they believe in, with the goal of financially hurting, embarrassing, or damaging the reputation of the target.
• Jerks:  Whether they are bored, mean, experimenting, or just don’t care about the damage they may cause, sometimes there just isn't any clear motivation for an attack.
• Nation-State Actors: Backed by the government and the main players are China, North Korea, Russia, and Iran.
• Corporate Espionage: Some companies will actually hire hackers to steal information or ruin the reputation of competitors.  The nerve, right?
• Malicious Insiders: This is typically an individual that sees an opportunity for financial gain, or feels wronged by the company in some way.  They already have access and may even have privileged access, making them especially dangerous.

I intentionally left out ethical hackers like us, because we are talking about the “black hat” variety hacker here, not us white hats.  Our job is to find the weaknesses in your application before the black hats so you can fix them and increase the security posture of your business.  Reduce the attack surface.  Lessen the risk.  Accept that you probably are vulnerable, and you have taken the first step towards becoming less vulnerable.