Top 15 Software Security Weaknesses Or "Why are there so many zero days?"

Zero Day Vulnerabilities

It seems that everyday you see another headline about some cybercriminal wreaking havoc somewhere because of some newly discovered zero day vulnerability. ? Why does this keep happening????

Zero day vulnerabilities are merely software bugs that affect the security of applications.? ? More software = more bugs.? ? Depending on the source you are looking at, estimates of bugs in the software development process ranges somewhere between 10-70 per 1000 lines of code (Microsoft has published a range of 10-25 in the application division).????

Using some numbers from the Stackoverflow Developers Survey (not a scientific survey by any measure, but best I could find) you can derive an estimate of 90 billion lines of code generated each year.? ? Just to be extremely conservative let’s cut that in half and say 45 Billion lines of code.??

Let’s use the upper end of Microsoft’s bug number (since I am going to assume that they are better than average at writing software -- I will duck while everyone throws stones at me). ? Let’s assume that 90% of bugs get caught during testing (and that may be very generous). Adding some basic math, we can estimate that there are 112,500,000 bugs born into the world every year.???

How many of these bugs actually result in a security risk?? ? I have never seen any published studies on that subject, but it is an interesting and relevant question.? ? Maybe I will have to get a government grant to study that. ? The problem is that most of the bugs that lead to security problems are very difficult to detect in testing because they rarely affect the business logic being implemented (an argument for the painful process of code inspection). ? But the law of big numbers tells me that there are lots of zero days out there waiting for someone to find.

Security Bugs - Software Weaknesses

I realize that code inspection is expensive and software developers would rather follow an elephant around with a pooper scooper than do it. ? So if we can really only find these zero day bugs through code inspection, where should we look? ? Let’s concentrate on the most effective use of inspection time.

The good people at MITRE can help us out there. ? ? They have done some statistical analysis of CVEs and CISA’s Known Exploited Vulnerabilities databases to come up with the software errors that are the most frequent causes of security problems. ? Here are numbers 15-11, the countdown will continue next week.

15)? Hardcoded Security Credentials

This one was hard for me to believe. ? It is 2022 and we still have this going on.? ? It is happening much more frequently than you might think as well, I will be publishing an upcoming article dealing with this in greater detail along with where some of those hardcoded credentials are ending up.

14) Improper Authentication

This one has as much specific meaning as the term “Cyber Security”.? ? Let’s highlight a couple of the more important cases that they call out for problems observed in the wild:

Weak Encoding of passwords - Password management issues occur when a password is stored in plaintext in an application's properties or configuration file. A programmer can attempt to remedy the password management problem by obscuring the password with an encoding function, such as base 64 encoding, but this effort does not adequately protect the password.

No Password Aging Mechanism - If no mechanism is in place for managing password aging, users will have no incentive to update passwords in a timely manner.

Authentication Bypass - There are systems out there that don’t close all the holes. ? Spoofing and Capture/Replay schemes are the biggest culprits here.

?Improper use of Digital Certificates - Digital certificates can bring a great deal of security to your systems, but they must be used properly.? ? When they are in use, they must be properly validated including checking CA signatures, checking for certificate revocation and expiration date checks. ? Digital certificates also require care and feeding from the security and administration staff. ? Never forget that a bad certificate led to the breach at Equifax that exposed 147 million PII records, one of the largest breaches in history.

Forgetting to Require Authentication Everywhere -? There have been documented cases of applications that required authentication at the UI, but developers forgot to require the same credentials on the API (Big Facepalm Emoji).

Passwords - There are lots of variations to the password theme that MITRE points out. ? These include not including multi-factor authentication to short and badly protected passwords to systems that actually just validated the password at the client (the server then implicitly trusted the requests).? ? Bottom line is that if you are going to only use passwords, make them as complicated as possible and in general “Just say No!”

13)? Unchecked Variable Overflow

An overflow or wraparound occurs when a value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may wrap to become a very small or negative number. While this may be intended behavior in circumstances that rely on wrapping, it can have security consequences if the wrap is unexpected. This is especially the case if the overflow can be triggered using user-supplied inputs. This becomes security-critical when the result is used to control looping, make a security decision, or determine the offset or size in behaviors such as memory allocation, copying, concatenation, etc.

12)? Deserialization of Untrusted Data

It is often convenient to serialize objects for communication or to save them for later use. However, deserialized data or code can often be modified without using the provided accessor functions. Always sign your data blob using a digital certificate.

Data that is untrusted can not be trusted to be well-formed.

When developers place no restrictions on "gadget chains," or series of instances and method invocations that can self-execute during the deserialization process (i.e., before the object is returned to the caller), it is sometimes possible for attackers to leverage them to perform unauthorized actions, like generating a shell.

11) NULL Pointer Dereference

I remember when I was a young computer science student at Purdue and got my first assignment with a language with no seatbelts (K&R C for us old guys).? ? I can't remember how many times I saw the dreaded “Segmentation fault (core dumped)” message over those years, but eventually got it pounded into my head to check and double check any pointer I referenced to make sure there was actually something out there at the other side of the pointer.

Today, students tend to learn their algorithms using languages that have seatbelts to keep them safe from their own bad habits. ? Without the hard won experience to learn the lessons about real-world pointer use, they tend not to practice good memory management and pointer discipline when put in an environment without the seatbelts.

Most null pointer issues result in general software reliability problems, but if an attacker can intentionally trigger a null pointer dereference, the attacker might be able to use the resulting exception to bypass security logic or to cause the application to reveal debugging information that will be valuable in planning subsequent attacks.

Next Week?

Next week I will pick the list back up and look at software design and coding problems that are even more prevalent in the real world causing security vulnerabilities.