RDanailov
The Third Party Thursday blog series aims to deliver vulnerability insights about software vulnerabilities that have been analyzed and verified by Secunia Research at Flexera. The blog frequently includes a monthly summary of vulnerabilities, and suggestions to security administrators, about different ways to prioritize and mitigate software vulnerabilities.
In this instance, we looked at the software vulnerabilities reported between July 26 - August 29 of 2019 by Secunia Research at Flexera.
Monthly Advisory Overview
Between July 26 - August 29 of 2019, Flexera has released 471 new Secunia Advisory IDs (SAIDs). Compared to the amounts seen in past months, we can notice a higher amount of newly published Secunia Advisories compared [1] April’s 469 SAIDs, [2] May’s 406 SAIDs, [3] June’s 384 SAIDs, and [4] July’s 405 results. If you need clarification about Secunia Advisories (SAIDs), read more at Helpnet.
The increase in the overall number of Secunia Advisory vulnerability reports, especially compared to the past three months, can be attributed to a slightly larger number of days this blog’s period focuses on – 33 days, but also to the increased amount of new advisories that have been identified to reside in the low advisory-criticality spectrum, as you will see next in this blog analysis.
Advisory Breakdown by Criticality
Here is how a breakdown by advisory criticality ratings looks like this month:
- “Extremely Critical” = 0 (-2)
- “Highly Critical” = 78 (-2)
- “Moderately Critical” = 164 (+23)
- “Less Critical” = 163 (+33)
- “Not Critical” = 66 (+12)
Each month we observe an approximate of 80 Highly Critical advisories. This month’s 78 advisories are within the expected volumes. The same could be told for the amount of Extremely Critical advisories – these are rare and we usually see a few of them per month, if we see any at all.
The numbers placed next to this month’s advisory counts for each criticality range represent the increase or decrease compared to last month’s advisory amounts. We see an increase of 23 Moderately Critical advisories, 33 more Less Critical advisories, and 12 more Not Critical SAIDs.
The increased workloads display the thoroughness of Secunia Research and its commitment to handling such increased workloads where required, to secure customers will full disclosure of every vulnerability being discovered. Every Secunia Advisory requires excellent quality of research to be confirmed, approved, published, and thereafter continuously supported and maintained to live up to Secunia Research world-class vulnerability assessment standards.
If we look at the average release rate for 33 days, that makes it an average of 14 new advisories released by Flexera per day over a 33-day month. This number represents a baseline of the average volume of security vulnerabilities every organization should be prepared to handle daily in the worst-case scenarios.
A drastic month-to-month increase in the number of security advisories could often be an indicator of a high-profile, very critical, widely exposed vulnerability, or many of them. One example could be the Intel’s ZombieLoad /RIDL/ Fallout hardware-based vulnerabilities disclosed in May of 2019 that exposed critical security flaws in every major computer operating system and platform of the likes of Unix, Windows, MacOSX, besides enabling a nasty virtual machine escape attack opportunity at every modern datacenter using Intel’s chipsets produced after 2011 by the software giant.
The following citation is from Charles P. Pfleeger who wrote it in his book back in 2006:
“A vulnerability is a weakness in the security system, for example, in procedures, design, or implementation, that might be exploited to cause loss or harm. For instance, a particular system may be vulnerable to unauthorized data manipulation because the system does not verify a user’s identity before allowing data access”
Spot on Charles!
You have predicted the same Intel failed to see in front of their own eyes, 5 years before the software giant even designed the new CPU optimization techniques in their CPUs that allowed malicious actors to be running bad code before any security validation is done. Intel did a good job of coordinating the disclosure and acted responsibly as a vendor by warning out responsibly their stakeholders. Nevertheless, the vulnerability continues to affect businesses to date, after it was left exposed for 7 years without any preventative control measures, completely unnoticed.
My example is not to point fingers, but to illustrate the depth of the science and personal intelligence that is required to understand conceptually and theoretically the eventuality of weakness and the possible ways of exploiting it, by imagining the design of the system, while those that wrote the very code miss to see it. That is a modern-day reality and hackers know it well. We should also note it.
The problem is that every individual with malicious goals and means to exploit software vulnerabilities has a natural advantage because of his position as an attacker calling the moves. What’s important is that organizations build security controls around as many security threats as they can discover through pro-active intelligence gathering, and apply extensive and frequent patching to isolate the risk windows of opportunity and keep vulnerabilities under tight control.
Charles P. Pfleeger also says in his book “Security in Computing” the following:
“[1] An intruder must be expected to use any available means of penetration. The penetration may not necessarily be by the most obvious means, nor is it necessarily the one against which the most solid defense has been installed. It certainly does not have to be the way we want the attacker to behave.
[2] Remember that computer security is a game with rules only for the defending team. The attacker can (and will) use any means they can. [3] The variety of attacks makes computer security very difficult.”
Every responsible security person should want to see an increase in the monthly advisory loads because, in my opinion, this is the fastest way to making software we use on a daily basis to live up to our security standards and expectations. By working with the software vendors, we can help them integrate processes for responsible disclosure in their workflows, and have them increase their security focus consistently by holding them responsible to patch security flaws quickly and irreversibly to the best of their abilities.
Monthly Vendors Overview
The list of unique vendors found vulnerable throughout 471 new advisories equals 84 vendor names. While IBM, Cisco, and few Unix-based vendors usually have most security advisories attributed to their software products, and that is the new normal, we have also seen surprising entries in the top 20 vulnerable vendors list.
The presence of Novell with 12 security advisories is one surprise that worth mentioning.
The 29 Secunia Advisories issued for various open-source technologies is not a surprise, but comparing back to past months, it shows a small increase in the number of advisories reported for what we refer to as the “vendor 0”.
It’s also important to note that some open source projects do have a vendor name based on various reasons, such as the FreeBSD Project, so there is more open-source deemed insecure in the full list of products researched and reported vulnerable during the past month.
The first ten vendors on this Top 20 list make it up for more than 55% of all new security advisories.
This means that these are the vendors you should want to tick off on a daily, weekly, monthly basis and the folks that usually have to be secured repeatedly over a calendar month. This statistic can be used in software purchase planning, as it translates into additional costs for the purchasing entity. This is how we can hold vendors responsible, and how we motivate them to outperform security-wise.
The remaining list of 64 other vendors includes large and small vendors. Some worth mentioning are McAfee, Tenable, Autodesk, Dell, Kaspersky, Symantec, Google, Valve, Xerox, Lenovo, Atlassian, GitLab, Tableau, Elasticsearch, SolarWinds, among others. You probably need to prioritize them if you haven’t done so in the past month because these vendors are more very likely to be deeply integrated into production environments.
Monthly Products Overview
237 unique software products released by 84 vendors in a total of 331 different product versions have been reported as vulnerable through Secunia Research between July 26 – August 29 of 2019.
The facts speak for themselves. A vulnerability may be exposed to many methods of exploitation. Every possible attack against one vulnerability is considered a threat to security. There can be many threats to one security vulnerability.
Now, multiply that by 237 product titles you use every day and you get a baseline for the risk introduced over a whole month. This data could serve as a baseline for the average number of threats reported over a full month for most of the common software used across businesses.
Software vulnerabilities account for 99% of the successful security breaches according to some cyber-security studies. This indicates that there has to be a mandatory day-to-day effort by the security teams to protect assets timely from vulnerability exploitation, or the risk windows derived from leaving your software unpatched can escalate beyond your control quickly and irreversibly.
The good news is that the vast vulnerabilities have a vendor patch available in up to 90% of the cases of a new vulnerability being reported in the public domain. You’ve seen the vendor rankings for the past month and you can get an orientation of where you need to focus, but the products that are affected must be tracked accordingly and more visibility is required.
We’ve made a similar monthly product ranking that can help you focus on the products at your network. Remember, this blog always comes later as a sum-up of the trends, but the reality of today requires much faster and pro-active remediation of software vulnerabilities. At the moment of writing this, there are hundreds of others of security threats released actively by the community.
The “Count” column represents the number of times a product title has appeared in different Secunia Advisory. You can see that a few Red Hat products have several similar product entries and advisory counts. This is a strong indicator that these products have all been reported to the same 51 advisories and that they share a common root vulnerability or many of them.
Secunia Research counts vulnerabilities per the product the vulnerability appears in. This method is applied to reflect the level of information the customers need, to keep their environments secure. Secunia Research provides verified intelligence listing all products affected by a given vulnerability.
When we think of vulnerabilities and how we should count them, we need to understand that one advisory may report on five different vulnerability identifiers that could be affecting ten different software versions or product lines for example.
Each CVE represents a single vulnerability in ten different versions. As you may maintain all of the versions in a widely distributed across continents environment, you should look at it as you have ten different vulnerabilities to handle worldwide for each vulnerability linked to the same advisory.
You would certainly not go patching vulnerabilities one by one. Secunia Advisories are focused to deliver the best and most widely applicable solution information directly within the advisory contents. Thus, the advisories are designed to cover maximum products and vulnerabilities, while linking to the best common fix. Therefore, by using Secunia Advisories as your intelligence source, you ensure that you follow the most direct approach to patch maximum threats with minimal effort. Flexera also provides unseen elsewhere patching capabilities with its SVM 2019 software to help you patch maximum software titles you need with Vendor Patch Module that supports 1K OOTB patches.
Monthly Vulnerability Overview
How many vulnerabilities are there to patch?
We already have said that Flexera counts vulnerabilities per the product they appear in. Other folks will count one CVE identifier as one vulnerability and will discount the fact that one vulnerability can lead to many affected systems and products.
Yes, you can count one CVE as one vulnerability! But, that has to be the base minimum in a far more complex and variable calculation that uses the baseline for initial risk assessment, but further down in the process workflows one also employs deeper research at the product context, user context, best security practices, and other factors that have impact on the assessment of how critical, severe, and widely enabled a vulnerability really is.
Secunia Research takes these under active consideration with every vulnerability verification. Flexera considers the risk of immediate exploitation-after-publication as very high, while also looking at other important threat factors. It’s a common-sense that vulnerability is far more likely to be reversed and exploited shortly after details about it are published. Many folks are ready for the challenge to figure out how a vulnerability can work for their profit.
471 new advisories contained exactly 2032 vulnerability identifiers. This number tells us how much times a member of Secunia Research assigned an individual vulnerability to any of the new advisories. This absolute number of 2032 vulnerability links actually includes the duplicated vulnerability identifiers, where a core weakness affects many products and/or vendors.
The absolute count of CVE-2019-Like vulnerabilities (domestic) shows this year’s vulnerability releases versus ‘alienated’ ones released in earlier years. You can estimate that around 25% of the total amount of vulnerabilities reported through 471 advisories have been released in earlier years.
Last month alone, Flexera has reported 40 vulnerabilities that have been released before 2017 with the oldest one being CVE-2009-0692. Yes, this is happening! 10-year old vulnerabilities are still affecting software products made in the year of 2019!
We received a total of 1255 unique vulnerability identifiers after removing duplicated identifiers. This number represents the absolute count of unique vulnerability identifiers linked to last month's released advisories. That results in an average of 3 unique vulnerabilities per new each new advisory. These statistics could be seen as a baseline of the vulnerability volume across all major vendors and products, for a month of time.
If we compare again the 1255 unique vulnerability identifiers to domestic and alienated year-wise, the comparison between them yields a significant 8% increase in the over percentage from 25% (1/4th) to 33% (1/3rd). Here is our expected monthly volume of unique software vulnerabilities.
This tendency shows the importance of prioritizing old software versions that have gone end of life or will be soon, for immediate upgrade to the latest and greatest versions available. Sometimes the attacks on the infrastructure can be obvious and sometimes may not be. People would normally wish to see them through and detect them, patch them quickly, but that may not always be the case.
The risk factor here increases exponentially with End-of-Life software because researching discontinued software is not at all profitable for white-hat researchers. The black-hatted hackers, on the other hand, know that there are a plethora of unpatched vulnerabilities laying around. "A system is most vulnerable at its weakest point" is another thing that Charles P. Pfleeger said in his book and one thing that is very true for End-Of-Life windows of opportunity that hackers aim to exploit.
"A perpetrator will not attempt to break into the house through a two-inch-thick metal door when a nearby window is wide open". Well, if you don't intend to patch your End-Of-Life software, then that would be equal to you leaving the window wide open, so why did you purchase that metal door?
As we speak of threats and malicious intent, we will look into that next. Before we dive into it, allow me first to provide a useful suggestion for our Flexera SVR users on how to obtain your list of CVEs.
Get your vulnerability stats with Powershell and Flexera APIs
You can re-use the script example provided at Helpnet to run a fully automated Powershell script against the Flexera SVR APIs and collect advisory data on the fly. You can also follow the below instructions, to find the unique vulnerability counts for any period you want to track.
You should consider adding your SVR account token into the bottom of the script before moving on. You can change the dates at the bottom of the script to define the window you want reporting on. You can remove, or leave intact, most of the member properties that are added under the “foreach ($Advistory in $Collection)” loop for the $Data object. You can add safely the next line under "Products" and before $Data = New-Object System.nObject in the script I pointed you out to:
foreach ($cve in $advisoryDetails.cve_str_list.split(" ") | Select -Unique)
{$cve | Out-File -FilePath C:\temp\NameYourFile.txt -Append -Force}
This simple loop will obtain the attached list of vulnerabilities for each advisory within a given period from the SVR API. It will then take the line and identify each word in it where one word equals a different CVE identifier. Because CVE naming conventions dictate that all parts of it are interconnected with dashes and no spaces between them, it becomes very easy to call the split() function in PowerShell and chop the every line we acquire, word by word, until we get every word to be written on a new row in the exported file. This makes it easy to work with the data afterward, count the vulnerability identifiers, and you are learning the API too.
Threat Intelligence Overview
Flexera’s Threat Intelligence module that is optional for both SVR and SVM products provides direct insight on vulnerabilities that are known to have had previously been exploited in cyber-attacks or are currently under attack. It tells customers of Flexera if there is a known intrusion method too.
Threat Intelligence will flag if a vulnerability identifier has been linked to known ransomware campaigns, and where possible, the Threat Intelligence module will also disclose the actual names, codenames, and categories of the known malware, virus, or ransomware that carries the risk of automated imminent attacks.
We’ve looked into the details for the 471 SAIDs released by Flexera in the past month. We are seeing very interesting trends. Flexera has seen multiple variations of the Wcry ransomware in circulation, to begin with. We've also seen NotPetya and even Stuxnet in circulation targetting very particular vulnerabilities. The computer worm “MyDoom” with a codename “KeKudk” has been seen to exploit nearly a dozen of different vulnerabilities and to have been linked to Recent cyber-attacks.
“Exploit Kit, Ransomware, Banking Trojan, Remote Access Trojan, Ransomware: CVE-2018-12130”
The malware category data provided here along with the CVE-2018-12130 identifier is an example of how data could be customized and automated for collection and analysis through the Flexera SVR APIs. The above line has been customized by ourselves to pick the malware category names while also writing the CVE ID linked to those malwares and their corresponding categories. SA90820 will show you how this data looks in the graphical visual interface and it will reveal more information on the very data example I provide here. Next, you will see the names of the malwares targetting CVE-2018-12130 in perfect order to match them easily to their categories.
“Fallout Exploit Kit Wcry GozNym FlawedAmmyy GandCrab: CVE-2018-12130”
Is it a coincidence that hackers are targeting extremely aggressively a Unix-based vulnerability which is less likely to be located at the front-desk entrance room, and more likely to be somewhere in a server room where the impact and damage are quantified as per the attacker’s demands for ransom and what not? This advisory has a ridiculous CVSS3 severity score of 8.8 and a pretty high threat score too, while actually being identified as "Less Critical". We can use a variety of methods to pick on such extraordinary advisories that report on harder-to-exploit vulnerabilities with lower risk factors while yet having been exploited ridiculously many times in the past, and present.
The Threat Intelligence module also shares the codenames of many of the exploit threats that it knows of, where these details are made public. Here is an example of the codenames of the 5 types of exploits that we referred to earlier. For the record, SoA6SP is the codename for Wcry.
“TX9Atf SoA6SP QYptuW VaxusM VH7iDs: CVE-2018-12130”
There are at least 30 other malware and viruses that have been identified and reported by Flexera. A total of 50% of the Secunia Advisories released in this period had been assigned with a positive threat score in less than one month than the advisory release. Data from past months tells us that every month there is the tendency of a minimum of half of all advisories to already have a known exploit at the date of their public disclosure. This fact is somewhat justified by our research where we clearly identified at least 33% of the monthly unique CVEs to be 'alienated' from earlier years. Hackers would have had months, or years, to develop their exploits knowing that these same vulnerabilities continue to be reported 'freshly' in modern software design with vulnerabilities in it.
CVSS3 Severity Overviews
The correlation of threat intelligence into the software vulnerability management cannot simply be effective enough without the underlying world-class human vulnerability research that solidifies Threat Intelligence assessment grounds. Threat Intelligence is predominantly a computing analysis system, and it works best if it sits on top of qualified, well verified and factual vulnerability intelligence done by humans. What can Threat Intelligence give you if you lack the vulnerability metrics that let you perform the base prioritization using the risk, urgency and severity determination as done by the world-class researchers you trust on a daily basis to keep you secure?
Here is an interesting insight that is drawn from a CVSS3 score correlation with Threat Scoring. It flags vendor 2 that is Microsoft and vendors 209 and 308 as the ‘outliers’ as analyzed against 471 security advisories for the past month.
More interesting scenarios show up if we decide to mix the CVSS3 severity score of the advisories containing vulnerabilities that are already linked to known threats. We can correlate the exact version ID of a product with the threat intel information of whether it is linked to known cyber-attacks, recent or past. The trick is to clean the data before importing it for analysis and to fetch all relevant fields from the API.
One more example of the rich intelligence correlation is this example of the CVSS3 advisory score matched with the links to ransomware delivered through as insight with the Threat Intelligence module.
We can make even more experiments with the data and get invaluable insights. For example, this next figure shows the total sum of criticality for 471 advisories. The pie chart has criticality correlated with the “Intrusion Links” dataset which shows intrusion methods data if available. The intrusion data was exported with the vulnerability that is threatened alongside it. This allows correlating the main dataset data with only the specific threatened CVE IDs that carry an imminent threat to network security.
Attack Vectors
The next figure shows another interesting insight that can be used in the prioritization process, especially at large networks with millions of application instances. It tracks vendors by their overall Attack Vector percentage while displaying the “Count” property value that translates into actual their advisory share. That is how we can analyze what vendor is most susceptible to a variety of different attacks. In this case Red Hat, with IBM and Canonical Ltd coming second and third.
One of the superb benefits of using the vendor name to measure risk and threats appearance is because it unifies larger quantities of data into more reasonable amounts. Counting to 84 is much easier than counting 237 products or 331 versions. People understand it better, and programs display it better. And you can then also look at it as a definition of the security investment you make in business partners.
We made a more complex comparison that should serve as a conclusion of this month's blog as it is relatively easy to understand what your priorities should be in terms of products to prioritize.
The final figure shows a comparison of the overall CVSS3, criticality, threat score, and attack vector as measured against the monthly vendor list on one side, and through a direct correlation of those to malware category information on the other. Once again, this graph clearly displays the necessity of traditional research metrics as the base for any vulnerability management prioritization, which is the absolutely mandatory base. It is the essence of understanding all risks.
Yet, this graph shows the advantages of having Threat Intelligence sitting on top of a world-class research metrics, and I really don't think there could be a better visual example to illustrate that. Threat Intelligence provides us with alternative methods and points of view that will often contradict common sense and logic, but that same insight may often drive a dramatic paradigm shift as soon as we realize that our perceptions have been tricked and that where we patch it is not where the hackers try to crack it.
