Common Software Vulnerabilities

Two categories of software vulnerability

When we are working with software, what tends to come up is these common vulnerabilities. When we are talking about software vulnerabilities, I feel like there are two different approaches, or two different categories, that we can talk about.

The first one is the business application side. This is software that we purchase as a company. Maybe it is video conferencing software. We are going to go out and find the right vendor that is going to supply this video conferencing software, we are going to implement it, and then our users within our network are going to manage and use it.

That is a little different approach than if we are a company that is a SaaS company or some sort of software company. If we are developing software in house at all, there are a different set of concerns. If we are writing code, there are things that we need to watch out for. We still have to watch out for these in code that we purchase, but the thing is that the vendor should be taking care of that. For the most part, we are going to do an evaluation from a security perspective to make sure the vendor is doing their part to keep their software secure, but we are going to evaluate things on a different level than if we had in-house development. Then we take a different look into what that code looks like and whether there are common software vulnerabilities inside that code.

As an example, let us say we need to purchase some sort of video conferencing. We need to evaluate and purchase this video conferencing, and maybe we are choosing between Microsoft Teams and Zoom. Those are our two selections, and we need to make sure that the companies are compliant with our security and with the level of security that we need for this video conferencing. That is going to be a very different scenario, purchasing that and then setting up and making sure it is configured correctly so there are no security holes, than if we were developing something in-house.

Let us say we are developing something in house that is video conferencing. At that point in time we have a whole bunch of other stuff we need to be concerned about. For instance, maybe it is buffer overflow, or injection attacks, or those types of vulnerabilities.

Here I am primarily going to be addressing business applications and what that looks like, as a brief overview, and then I will briefly mention software development. In another module we get heavier into software development and some vulnerabilities that we would see when we are developing software, and things that we need to watch out for as security professionals.

System software, applications and web applications

Software is a broad category that just says anything that is lines of code that tell the computer what to do. We can break it down into system software and application software.

System software is more like the operating system, which is the base set of instructions for the computer and what it is supposed to be doing; the drivers, which are how it interfaces with the physical equipment; and the utilities that help us manage the computer.

Then under applications, those are all of the different applications or different programs that allow us to carry out and do our jobs. They allow us to perform certain tasks for our jobs, or maybe it is for entertainment, for personal life, or whatever the case may be. But it really is about doing tasks and doing different things for us.

Then from a security standpoint I would also make a subcategory of web applications, because there is a whole other set of concerns when it comes to web applications.

Common business application vulnerabilities

Some of the common vulnerabilities that I see with these business applications are that they are just misconfigured, or they are not updated. A lot of times they come with some sort of default credentials, and when you have default credentials then anybody can access that, understand what these default credentials are, get in there and start manipulating and changing things. Even if you change the default credentials, there could be some other misconfigurations within the system that expose that software to whoever is trying to hack the system.

Then of course we need to make sure that whatever we have is being patched on a regular basis. It is critical to keep our systems patched and updated. This is where a lot of the vulnerabilities come into play when it comes to the software we are running on our enterprise networks.

The vulnerability life cycle

Vulnerabilities do have a life cycle. Some sort of software is released and it has a vulnerability that exposes a risk. At this point in time we call this a zero day. A zero day means that whoever developed the software and released this vulnerability has had zero days to actually fix anything. They do not even know that it exists.

At some point in time it gets discovered. Somebody discovers that this is an issue. Maybe it is internal; somebody discovers it, hopefully, and they can release a fix right away. Or maybe it is external, and some sort of hacker discovers that there is an issue. Now we have a problem: somebody understands there is a vulnerability and can exploit that vulnerability for some sort of malicious purpose.

Then at some point in time it gets reported and it goes on the common vulnerabilities and exposures list. Now everybody has access to see what this exposure is, and now there is a real danger. There was danger when it was first discovered, but now that everybody can see it, it becomes a real problem.

Then whoever released this software creates a patch for it, they put the patch out there, and then the company deploys it. So between the time when we deploy it as security professionals and when it gets discovered, this is the window that is really critical. As soon as we can, we do this patching, because this is when we are opened up for some sort of attack.

Malicious updates and hardening

There is such a thing as a malicious update as well. We are going to patch our systems and update those systems, but there are times when the updates themselves can either have that vulnerability, or perhaps somebody has snuck code into that malicious update, where maybe we are not getting it from the right source, or maybe the source is infected, or whatever the case may be, and that malicious update can cause problems on our machine as well. That is one of the reasons we typically will validate some sort of update before we actually deploy it, similar to hardware and firmware and the different things that we roll out.

Same thing with software: it is going to have a lot of open ports or unused ports, or software that is running that opens us up for vulnerabilities as well. So one thing we want to do is go and harden our equipment, making sure that they do not have vulnerabilities opened up on this equipment.

Vulnerabilities in software we develop

There are definitely concerns over business applications and how we set those up, but there are even more concerns when we are developing software in-house. Just to name a few, and I get more in depth into this in other lessons:

• Buffer overflow vulnerabilities.
• Embedded secrets inside the software, which is problematic because you are exposing those secrets to other people if they can see that code or that software.
• Poor exception handling: what happens when there is some sort of exception, and how does your program handle that.
• Race conditions.
• Injections, where we can inject some sort of code. One example of that is SQL code injected into there.
• Cross-site scripting.
• A lot of times when we are developing software we rely on other dependencies or third-party libraries, and that has its own concerns.