Vulnerability Remediation — Fight for the Users

Sep 1 · 8 min read

Off the Grid

When you’re zooming by on your light cycle, er.. looking through your most recent vulnerability assessment or penetration testing results, I challenge you to be more like Tron and fight for your users. He’s a security program after all! What I mean is that typically organizations are focused on the vulnerabilities that directly affect their environment, and understandably so. What about the risk of an indirect attack though? We still have a tendency today to think of our networks as a castle with a strong perimeter to keep us safe from the chaos of the Internet. It’s amazing to me how often customers will approach the task of remediation from the mindset of protecting only their hosts and services from a direct attack. Vulnerabilities that affect the customers (users) of that organization are not just deprioritized, they’re often times flat out ignored.

It’s true that most vulnerabilities which affect the users have a lower severity and shouldn’t be prioritized to the same level as Remote Code Execution (RCE) on a server with a Critical severity, but they also shouldn’t be downplayed. Often times it feels like the likelihood of attack for some of these is far off, or maybe it doesn’t seem like a concern because the attack would have to occur off of your network (external MITM), but they could still pose a serious risk to the organization if exploited by a dedicated adversary.

Like This Guy! (Master Control Program)

I’ll Clu You In

A common example of a vulnerability that affects a user may be one that’s carried out by a Man-in-the-Middle (MITM) attack. Take for example, an SSL/TLS Downgrade or Weak Encryption Cipher/Algorithm issue. These are common in vulnerability reports due to the number of encrypted web services available on the external and internal environments and the rate in which ciphers, algorithms, and certificates become outdated and are no longer strong or valid. When a customer sees these, I can almost hear the eyes rolling from over the speaker phone. Perhaps they start out sounding concerned, “Is this like Heartbleed? Can they capture leaky data from the server?” To which I reply, “Well no.. but if someone was positioned between a user and the server they could potentially intercept data in cleartext.” They usually scoff at this point among themselves and make a remark about how unlikely such an event would be. They’re willing to “accept the risk”. This is especially true when the vulnerability is internally facing only. As I said before, even if it is less likely due to the nature of the setup for such an attack, it could potentially be devastating for a business. Think about what kind of information is being sent to and from your external web services. Are there credentials involved for remote administrative services? Where else are these domain credentials leveraged externally? Even if those services are secure, it may not matter if credentials were obtained via another vulnerable one. Where would these credentials lead an unauthorized user in a threat model?

I think also from a risk perspective they may simply not believe it’s their responsibility. They want to protect the village within the castle walls and don’t really think of the users external to their environment as assets they need to help protect, especially when these users are not employees. We have a tendency to put our arms around our internal systems and users. Let’s save the peasants!

Let’s Like, Talk Examples, Man.. (in the voice of Jeff Bridges)

Man in the Middle (MITM)

We talked about weak encryption already, but services that offer no encryption such as HTTP, FTP, and Telnet to name a few, do little or nothing to protect the end user and the server from traffic interception. All of these may lead to information disclosure in the form of captured credentials, passwords, or whatever sensitive information is in use by the service, but can also lead to the modification of the data in transit. I’m speaking to the “Integrity” component of the CIA Triad, specifically. This essentially means the user is on their own when attempting to determine the authenticity and integrity of the service and data they are interacting with. They may disclose information to an attacker directly or indirectly and they could download malware, etc.

I’m sure many of you are aware of the scenarios in which this type of attack can be pulled off. If it’s an internal system, the attacker would have to already have a foothold into the environment in question. Which, isn’t as difficult as you’d imagine if you were to ask any penetration tester. If this is external, (on the perimeter of the target’s environment) this data could be intercepted by someone sharing the same network as the victim. This could be a public WiFi hotspot in a coffee shop or airport. You may not think so, but there are bored hackers in airports that like to see what they can sniff out. I uh, know a friend.

Self Signed and Expired Certs

Another example I see commonly of ways we’re not doing our users any favors is in the form of self signed or expired certificates. Generally the attitude is, “Well it’s better that we have encryption right?” or “I don’t see the harm since the data in transit is using strong encryption ciphers”. The main problem here, in my opinion, is that we’re desensitizing our users who should be looking for warning signs. This is the opposite of security awareness training, in that we’re telling our users, “When you see this warning in your browser you should ignore it and add the exception.” An attacker can then substitute their own self-signed certificate to view data in cleartext and the user would be unlikely to notice. Again, it also does little to provide any authenticity assurance that we’re interacting with a trusted server like we believe we are. If cost is an issue, consider a free Certificate Authority such as Let’s Encrypt or getting a wild-card certificate for your organization and using a subdomain for these services. This is usually such a small change for the administrative staff and a big victory for the end users.

I’ll Just go Ahead and Click “I Understand the Risks”..

Insecure Handling of Sensitive Information

This category of vulnerabilities is more Application Security focused in my mind (it doesn’t have to be), but deals with the transmission of sensitive information. A few specific examples of this may be passwords that are sent over GET requests instead of POST, session tokens in the URL, and HTML form fields that do not explicitly tell the browser to ignore autocomplete for sensitive input fields such as passwords and credit cards. These can all result in the interception of sensitive user information even if the service is properly encrypted and the user does everything right. This data might be accidentally exposed in server logs or on the client’s local workstation. These are issues the development team should be aware of as they design and build the application.

Session Issues

Here’s another AppSec category that describes issues which put the user of the application at risk. I’m referring to session issues such as broken session termination, overly long or non-existent timeouts, and fixation vulnerabilities. Like most of these examples this may not leave the application itself open to a direct takeover, but indirectly exposes the users to risk that could then lead to something more serious for the organization. For example, remote attackers may be able to hijack a user’s session and use their new vantage point to look for post-authentication vulnerabilities that may be inaccessible without credentials. Or, maybe depending on the user, such as an admin, they can do a lot under the context of that hijacked account. Another example may be malware on a victim’s machine that allows someone to jump into an active session because it never expired or logged out successfully. I’ve done this personally on many red team engagements thanks to people leaving their browser tabs open and logged in, with the application not having a care in the world.

Third Party Client Vulnerabilities

The final example I’ll use to help make my point relates to third party patching issues, which I see a lot of. Now these users are internal users typically but could be external customers if you design software. Not only do I see this finding a lot during most assessments we perform, I don’t see it resolved at the same rate missing Operating System patches are applied. For one thing it’s not built directly into the update process by default so third party applications are inherently more difficult to keep up to date. That, and if you allow your users to install their own files (DON’T OR YOU’LL BE DEREZZED!) this makes managing the inventory very difficult. Programs such as Ninite, SCCM, and others can help keep these applications up to date.

Users use.. applications such as their browser, Adobe Reader, Flash (is this still a thing?), Java (is this still a thing?) and others in order to perform their daily job responsibilities. However, leaving your users exposed could open them up to a watering-hole or drive-by download attack. Maybe they are phished and open a PDF but they “didn’t click on anything”. They may be compromised and in turn expose the organization to a breach by means of lateral moment and escalation.

End of Line

Users often are a cause of frustration for us when it comes to security, so there’s a bit of a stigma that comes with supporting users. (ID10T!) Whether it’s in the form of a phishing victim, accidentally installed malware, configuration mistake, or some other user error, there’s only so much we as security professionals can do to lower the risk. For the things that are more outside of our influence, we try to correct behaviors with security awareness, secure code development, and internal social engineering training. However, if we can proactively help our users by taking steps to secure our back end systems that we do have control over, no matter how small the risk may seem, each “fix” will be another cumulative brick in our walls to help protect the environment.

Thanks all! Stay in the game!

“Greetings. The Master Control Program has chosen you to serve your system on the Game Grid. Those of you who continue to profess a belief in the Users will receive the standard substandard training, which will result in your eventual elimination.”

Curtis Brazzell

Written by

Passionate geek for Information/Cyber Security! I’m always learning and am happy to contribute anything I can share with the community. Follow me @ Twitter!

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade