If you care about cybersecurity, you surely have heard the term ‘software vulnerability.’ But it can quickly happen that sometimes we take this term for granted nowadays. That is why I decided to write this article to revisit the terminology behind software vulnerabilities and how they affect the cyber threat landscape.
What are vulnerabilities in Software?
I assume that we are quite aware of the word vulnerability and its meaning. Without looking it up, I would say software vulnerability is the result of having a bug in the code that allows for unintended behavior.
Now, I will borrow the knowledge of NIST, which shares the definition of Software vulnerability:
A security flaw, glitch, or weakness found in software code that could be exploited by an attacker (threat source).
All right, this makes sense – so now we should know what makes software vulnerable. However, how does one now exploit this vulnerability, and what exactly is exploitation? We will learn this by traversing the Vulnerability Lifecycle. Note that we are not discussing the Vulnerability Management Lifecycle here.
There may be different interpretations when describing the vulnerability lifecycle, but my approach here will show different stages of the vulnerability lifecycle. They are not necessarily followed in order but are rather of descriptive nature of how this lifecycle works. Let’s start by defining the different stages.
Proof of Concept Code Available
Exploit Code Available
If most of the vulnerabilities would follow the stages in order as described in the above list, the cyber world would be a significantly better place. However, unfortunately, this order is not always true. Let’s step back and dive a bit deeper into each stage.
There are two different types of vulnerability disclosure.
One is, of course, the public one, where the vendor usually reports about the vulnerability. This is often done when the patch to fix the flaw is also ready for release.
The other is the one we do not hear about – it is the stage when the vulnerability is discovered, hopefully, by a good actor who reports it to the vendor. However, it could be that threat actors uncover a vulnerability, which may be disclosed then on Dark Web for sale.
There is also a middle-ground here, where the vendor is notified about the vulnerability, but it takes a really long time before they can provide a patch for it (if at all), and thus a threat actor discovers it, or the information gets somehow leaked.
The stage where the vendor owning the vulnerable product released a fix for the flaw causing that vulnerability. This can take a few days since the disclosure, but more likely, weeks or several months.
Proof of Concept Code
Proof of Concept (or PoC) code is the experimental code that could exploit the disclosed vulnerability. It is important to differentiate between PoC codes and actual Exploit Codes. PoC Codes are often also a tool to scam those looking to purchase exploit code for a given vulnerability because most of them do not actually work.
Now, at this stage, we have a real deal. Exploit is a code tested and proven to work to abuse the flaw in the software. It is not necessarily malicious by intent; it depends on how this tool/code is used.
Weaponization is the stage in the vulnerability lifecycle that comes at the end, when threat actors start weaponizing the exploit code. Exploit code as itself is not doing anything; it has to be executed in a given environment with several different parameters and requirements. This is why the weaponization stage exists, and this is where that happens.
All right, now that we are familiar with the vulnerability lifecycle let’s look at an example I prepared. We will look into CVE-2023-3436, better known as MOVEit File Transfer vulnerability, which was and still is widely exploited by the infamous CL0P Ransomware group.
MOVEit File Transfer Vulnerability Lifecycle
Below, we will depict a timeline view showing you the different stages of the vulnerability lifecycle described in the previous chapter. One thing to note is that due to vast intelligence sources, do not take every indicator on the graph for granted; try to disregard some obvious outliers and focus on the majority.
As it can be seen, specifically with the case of CVE-2023-3436, we have disclosure and patch available around the same time – which is what we would expect.
However, I want to point your attention to the Exploit and Weaponization stage. You can clearly notice that there were some activities with developing exploit code and weaponization before the vulnerability disclosure and patch.
If you recall CL0P Ransomware Group’s campaign spree that exploited this vulnerability, you should remember that their exploitation campaign also started before the disclosure date.
To infer, with the help of such intelligence on vulnerability’s lifecycle, we can better understand that exploits and weaponization can often happen much before the disclosure and patches – it is, however, often hidden from the public as it happens on Dark Web and underground forums, where such conversations may take place and exploits being sold.