What to do with all these damn vulnerabilities? Part 1

Almost every day I get a notification from one or multiple sources saying that “Product X” has a new vulnerability which is marked as HIGH SEVERITY and CRITICAL. This is then of course a RCE (Remote Code Execution) which can then bypass authentication for some public facing service. Congrats! someone now has access to your internal resources using a PoC code they found on github..

This is a typical scenario, and it happens a bit too frequently. Where new vulnerabilities are published, someone builds a PoC, some baddies abuse the vulnerability either to get access which they then use to launch a ransomware attack (for let’s say a public service) or it might be a vulnerability on an internal service which they attackers then just add to their toolbox and a(use) it later.

Of course, some vendors (more than others) are the usual suspects when it comes to all these critical vulnerabilities.

Another issue is that the sheer number of vulnerabilities are increasing each year as well and given that most companies are getting increasingly complex tech stacks as well…well then it because increasingly difficult to handle this at scale as well.

This is a screenshot from a Cisco vulnerability that affected most of their core switches and routers late last year.

The best metric to see this on is from CVE (Common Vulnerabilities and Exposures) where the number in 2023 was close to 30,000 or use CVEDetails which gives a nice graph as well Browse CVE vulnerabilities by date (cvedetails.com) and also shows the increase from year to year.

While the numbers might sound scary, but bear in mind that these vulnerabilities are across hundreds of vendors, so maybe a few percent of those vulnerabilities actually impact your infrastructure.

But wait how critical are these vulnerabilities actually? let’s dive into some of them.

So, we are going to focus on the following vulnerabilities:

  • PrintNightmare: CVE-2021-34527
  • Zerologon: CVE-2020-1472
  • Citrix NetScaler ADC: CVE-2019-19781

PrintNightmare – which was a vulnerability that was published in July 2021. Using this
vulnerability, an attacker could run arbitrary code with system privileges on a remote system and
local system, so long as the Print Spooler service was enabled. So, in theory, you could utilize this
vulnerability to make the domain controllers run arbitrary code, so long as the Print Spooler service
was running. This is because of the functionality within a feature called Point and Print, which allows
a user to automatically download config information about the printers directly from the print server
to the client.

All Microsoft Common Vulnerabilities and Exposures (CVEs) get published on MSRC with dedicated
support articles, highlighting which systems are affected and recommendations in terms of workaround
and other countermeasures, as seen here for PrintNightmare: https://msrc.microsoft.com/
update-guide/vulnerability/CVE-2021-34527.


In regard to PrintNightmare, there were multiple scripts that the InfoSec community made that could
easily be used; as an example, here’s a simple PowerShell payload that exploited the vulnerability, which
did not require administrator access rights and comes with a predefined DDL file that creates a local
admin account on the machine: https://github.com/calebstewart/CVE-2021-1675.
Identity-based attacks

Benjamin Delpy, the creator of the popular tool called Mimikatz, also created a proof of concept by
setting up a public print server that you could then use from an endpoint to connect to that public
server, which would then automatically create a CMD pane running as a local system context.

It took Microsoft many weeks before they managed to provide patches and recommendations on how to
fix this. In the middle of August, only 1 month later, there were already news articles about ransomware
operators that were exploiting the PrintNightmare vulnerability to compromise organizations.
Microsoft provided recommendations when the vulnerability was known, which was to disable the
Print Spooler service until they managed to provide a security fix. It also allowed many administrators
to realize that the Print Spooler service is not required to run on servers that are not end user facing,
such as Citrix/RDS servers.

Zerologon – another high-severity CVE that exploits a vulnerability in the Netlogon
process in Active Directory, which allows an attacker to impersonate any computer, including a
domain controller.

To be able to leverage this vulnerability, the attack needed to be able to communicate with the domain
controllers, such as having a Windows client that is joined to the Active Directory domain.
Then, the attackers would spoof another domain controller in the infrastructure and use the MS-NRPC
protocol to change the password for the machine account in Active Directory, which is as simple as
sending a simple TCP frame with the new password.

Once the new password had been accepted, the attackers could then use that new account to start new
processes with an Active Directory domain controller context, which was then used to compromise
the remaining infrastructure. Zerologon has been used in many ransomware attacks to, through lateral
movement, compromise Active Directory and gain access to the domain controllers.
This vulnerability was fixed in a patch from Microsoft in August 2020. In September 2020, the security
researchers from Secura who discovered the vulnerability issued their research, and within a week,
there were already different proofs of concept published on how you can leverage the exploit. You can
find the link to the initial whitepaper on the vulnerability here: https://www.secura.com/
uploads/whitepapers/Zerologon.pdf.

In the months after, many organizations were hit by Ruyk, where they used the Zerologon vulnerability to gain access to the domain controllers.

Citrix – (CVE-2019-19781) Lastly, we have the vulnerability in the Citrix ADC (CVE-2019-19781), which was also a high-severity
vulnerability that allowed unauthenticated attackers to write a file to a location on disk. It turned out
that by using this vulnerability, you could run RCE on the ADC appliance.
This had multiple implications since an ADC is often a core component in the network to provide load
balancing and reverse proxy services for different services. Therefore, it most likely had many network
interfaces with access to different zones, and in many cases, had access to usernames/passwords and
SSL certificates.
The vulnerability itself was exploiting a directory traversal bug that calls a Perl script, which is used
to append files in XML format to the appliance. This is then processed by the underlying operating
system. This, in turn, allows for RCE.

This caused a lot of turmoil, with close to 60,000 vulnerable Citrix ADC servers being affected, because
the vulnerability was out and Citrix did not have a patch ready. The vulnerability became public at the
end of 2019, while Citrix had an expected timeframe of patches being available at the end of January 2020

This vulnerability also affected four major versions of the ADC platform, which also meant
that the patch needed to be backported to earlier versions, which affected the timeline of when the
patch could be ready.

While Citrix provided a workaround to mitigate the vulnerability, this did not work for all software
editions because of licensing issues, with features that were not available.
Eventually, the patch was released and the vulnerability was closed, but many ADC instances were
compromised. Many got infected with simple bitcoin mining scripts and others were used to deploy
web shells.
One group, which was later referred to as Iran Network Team, created a web shell on each of the ADC
appliances that they compromised. The group was pretty successful in deploying a backdoor to a
significant number of ADC appliances. Many of these appliances were already patched but were still
vulnerable due to the password-less backdoor left open on their devices by the attackers. This web
shell could easily be accessed using a simple HTTP POST command.

In addition, another threat actor created a new backdoor named NOTROBIN. Instead of deploying
a web shell or bitcoin mining, they would add their own shell with a predefined infection key. In
addition, they would attempt to identify and remove any existing backdoors, as well as attempt to
block further exploitation of the affected appliances. They did this by deleting new XML files or scripts
that did not contain a per-infection secret key. This meant that a compromised ADC appliance was
only accessible through the backdoor with the infection key.

Some overall pointers in regards to vulnerabilities

  • The time between when a vulnerability is discovered and an attacker starts exploiting it is
    becoming shorter and shorter.
  • You should always apply security patches as soon as possible because in many cases, you might
    not realize the impact of a vulnerability until it is too late.
  • After a vulnerability is known, if it takes too much time to install the patch to remediate it,
    chances are that someone might have already exploited the vulnerability.
  • Also, in many cases, an attacker might have already been able to exploit the vulnerability to
    create a backdoor that might still be utilized even after the patch is installed.
  • Many vulnerabilities evolve after the initial publication. This means that after a vulnerability becomes
    known, many security researchers or attackers can find new ways to use the vulnerability or find
    vulnerabilities within the same product/feature/service, as was the case with PrintNightmare.
  • Organizations on average take between 30 – 60 days to install the patch or update (when it might then already be to late)
  • High-severity vulnerabilities are not limited to Windows. This also affects other core components, including firewalls and virtualization platforms such as VMware, Cisco, Fortinet and so on. (the list is long!)
  • Many access brokers and ransomware groups use vulnerabilities either as part of getting initial access to an enviroment or to do lateral movement inside an organization.

Monitoring vulnerabilities

as I’ve mentioned earlier there will always be vulnerabilities, so it is important to pay attention to updates that might
impact your environment.
An average business today might have somewhere between 50 and 150 different pieces of software installed within their environment. This might also include software from the same number of vendors.
Consider using the following software if you are a small company running an on-premises environment:

• VMware: Virtualization
• Fortinet: Firewall
• HP: Hardware and server infrastructure
• Citrix: Virtual apps and desktop
• Microsoft Exchange: Email
• Microsoft SQL: Database
• Windows: Clients and servers
• Chrome: Browser
• Microsoft Office: Productivity
• Cisco: Core networking, wireless
• Adobe: PDF viewer/creator
• Apache HTTP: Web server

In addition to this, end users have their own applications that they need and there may be other line
of-business applications that you might need as part of your organization. Here, we have already listed
over 10 different vendors and many applications/products that need to be patched. How do we maintain
control and monitor for vulnerabilities?

This falls into a category called vulnerability management, which is the practice of identifying and
remediating software vulnerabilities. Remediating software vulnerabilities is done either through
configuration changes or, in most cases, by applying software patches from the vendors. We will go
into using tooling to patch infrastructure a bit later, but one thing I want to cover is how to monitor vulnerabilities.
While many commercial products can be used, I also tend to use other online data sources.

For example, you can use a centralized RSS feed to monitor security advisories from different vendors.

This is the most common tool that I use to monitor vulnerabilities from vendors. Most websites have
an RSS feed that I can collect into an RSS reader such as Feedly. Some of the RSS feeds that I use are
the following:
• VMware Security Advisories RSS feed: https://www.vmware.com/security/
advisories.xml.

• Cisco security RSS feed: https://tools.cisco.com/security/center/rss.x?i=44.
• CISA – Has a list of known exploited vulnerabilities Known Exploited Vulnerabilities Catalog | CISA
• Microsoft doesn’t use RSS anymore and instead uses email notifications, which you can sign up
for here: Vulnerabilities – Security Update Guide – Microsoft). However, I do monitor the Microsoft Security Response Center
(MSRC) blog, which highlights some of the higher severity vulnerabilities: Microsoft Security Response Center.

If you are using tools like Feedly, it also has a vulnerability monitoring option as well, but this requires a paid subscription to get access.

It should be noted that, depending on the different vendors you use, monitoring all these RSS feeds can
be a time-consuming and repetitive process. In many cases, you should limit the amount of RSS feeds
to a minimum so that it gets manageable.

Some vendors also have good filtering capabilities so that you do not get information
about vulnerabilities related to products you do not have. Going through the information from these
feeds is something that should be turned into a routine. In larger IT teams, this task should be rotated
between multiple people – for instance, you should have someone responsible for going through the
information and presenting relevant information on Monday mornings.

In the second post I will focus on how to detect vulnerabilities in your enviroment and how you should structure the work to handle updates.

Leave a Reply

Scroll to Top