3 Ransomware Precursors Laid Bare in a Cyber Truth or Dare

Table of Contents

How to prevent a ransomware attack from bringing down your business often boils down to not exposing actively exploited vulnerabilities to the Internet.

Recently, with my vulnerability researcher hat on, I was thrilled to get confirmation that three serious security vulnerabilities had been used as initial access vectors in ransomware attacks. Of course I was not gleeful or happy that this had happened to the victims, far from it, but what excited me was that I happened to know an antidote for these particular attacks and many like them.

Neither was my elation due to the fact that each of the vulnerabilities is on the CISA Known Exploited Vulnerabilities Catalog (KEV), which Jussi Eronen brought up in his earlier post on exposure assessment. What pushed my buttons, was that post mortem analyses of three ransomware attacks had revealed the root cause for each incident to be the exploitation of a publicly exposed known vulnerability.

In other words, the incident responders had discovered the smoking guns, plural.

To put it bluntly, each incident could have been avoided had the service not been directly exposed to the Internet in the first place. Please note that I used the words had the service not been directly exposed to the Internet in the first place on purpose – instead of patch and forget. The last couple of years have proven that even if you patch now, it will only be a temporary solution. To add defense in depth, you must place these particular services behind a reverse proxy or a (web application) firewall, period.

It may even be worthwhile to consider exchanging a given service for a more suitable one, should you approach the problem from a pragmatic risk management perspective.

The Exploited Vulnerabilities #

The vulnerabilities discovered in the post mortem analyses are not new and are definitely way past their news hype cycle. In other words, the eye of Sauron had passed over and has had its gaze fixed elsewhere. That of course hadn’t deterred the attackers, since they had simply exploited whatever worked and gotten on with their extortionate business practices.

In this case the three distinct vulnerabilities I’m talking about were the following (in chronological order):

CITRIX ADC CVE-2019-19782
Microsoft Exchange Server CVE-2020-0688
Atlassian Confluence CVE-2021-26084

Below, I will briefly go over the vulnerabilities, but I recommend that you use the links above for a deeper dive into the technical details for each vulnerability.

Deep AI's idea of smoking cyber guns. — Deep AI’s idea of smoking cyber guns.

Citrix ADC (CVE-2019-19782) #

Citrix Application Delivery Controller and Citrix Gateway suffer from a remote code execution vulnerability that features a vulnerable PERL script and some path traversal fairy dust sprinkled on top. You only have to glance at the exploit code to understand that this service is probably not something you should expose directly to the Internet.

Microsoft Exchange Server (CVE-2020-0688) #

The failure to deploy unique cryptographic keys at installation time for the Exchange Control Panel, ECP, lies at the heart of this vulnerability. Even if the exploitation requires a valid user account on the server, it will not deter the attackers who will just purchase initial access from the dark web or phish for the credentials themselves.

Atlassian Confluence (CVE-2021-26084) #

Java/Jakarta servlet servers present another class of exposure. This exposure stems from the fact that servlet servers ship with a lot of hidden functionality that is there even if the developer has not had any use for it – or even known about it. Consequently, the problem with servlet servers is that the hidden functionality can often be invoked and exploited, for which the Confluence Server OGNL Injection is a great case in point (as was log4j).

Deep AI's second take on what smoking cyber guns might look like. — Deep AI’s second take on what smoking cyber guns might look like.

Vulnerabilities as Ransomware Precursors #

When I talked about an antidote above, it sounds simple and from a detection point of view it actually is.

After all, we can:

identify the problematic service
explain what the scope of the problem is
and help validate whether a given finding affects your service.

What to actually do thereafter is a more complex question. At minimum, your goal should be trying to avoid a ransomware attack on your organization by not exposing a service to the Internet which has one or more critical vulnerabilities in it.

Even worse is a situation where the service has a flawed design or poor vulnerability track record to begin with. To make matters worse, it is being actively exploited by threat actors in order to deploy ransomware.

You should take the ransomware threat seriously, since just of late the UK government declared ransomware to be a tier 1 threat to national security on par with terrorism.

The hype cycle approach to the problem is to state that you patch the affected system and carry on. The sad fact, however, especially in the case of the three products mentioned above, is that the Internet has proven time and again that they are broken beyond repair and must not be directly exposed to the Internet. That is of course, unless you are equipped and resourced to do so and have built layered defenses around them.

Case Microsoft Exchange #

Take Microsoft Exchange Server for example. The plethora of severe vulnerabilities discovered in it have led to a situation where the only practical solution to avoid direct exploitation in the short to medium term is to place the web server components behind a firewall and only allow remote access through a VPN. Why I say this, is that it has proven extremely difficult for sysadmins to even know whether their Exchange Server has the correct set of patches applied. The root cause for this is complexity, since there is no simple mechanism to update the server to the latest version.

The pundits may retort that you can just use Office 365 and not worry about an on-premise deployment at all. That is correct and a much safer option, but the sad fact is that many organizations using Office 365 have still left their on-premise Exchange Server exposed to the Internet. This hybrid solution is most likely carryover from the migration, where they think they need their own server for autodiscovery for example.

This oversight of course led into another debacle at the end of 2022. You don’t have to take my word for it. Kevin Beaumont has written extensively on ransomware precursors and in the context of the ProxyNotShell vulnerability, he states:

If you don’t run Microsoft Exchange on premise, and don’t have Outlook Web App facing the internet, you are not impacted.

Case CITRIX ADC #

Application Delivery is a capability which probably makes things easier for many organizations needing to use productivity software, but do not want to deploy it on each workstation. To combine VPN functionality into the same package has proven to be a less than ideal solution from a layered security perspective.

The layered defense required in this case is probably better achieved by having a dedicated, robust VPN server sit in front of the ADC and not exposing the application server directly to the Internet. For example, wireguard is proving to be a much simpler and more robust solution than an SSL(sic) VPN is.

Using a separate VPN gateway ensures that your application delivery controller can work as intended, with less potential of becoming a ransomware delivery controller instead.

Case Atlassian Confluence #

Java was touted as a secure, memory safe programming language that will save the world from evil. OK, I embellish a bit, but having studied computer science in the mid 1990s this was the message the academia tried to instill into our susceptible minds.

It took some time for the world to realize that Java had only shifted the goal posts. What I mean by this is that at the latest log4j showed us that having a framework in place where code and data is happily interpreted in the same context is not a good idea.

Write once, execute everywhere indeed is a paradigm that has proven to be the Achilles heel of the Java Servlet frameworks. That is why putting a Web Application Firewall (WAF) in front of these servers would be an important improvement. I mean restricting the types of queries one can make to a servlet server simply is something you must do.

Otherwise, these problems will keep on giving and in the context of this write-up, it will just keep making ransomware gangs filthy rich and happy.

Lessons Learned #

At this point it should be evident that I am a strong proponent of the fact that ransomware is not the cause rather than the effect. Too much attention is paid to the bad thing that already happened, where the real focus should be on systematically eradicating problems which caused the bad thing to happen in the first place.

After all, the media hype cycle is much more likely to pay attention to a zero day vulnerability X or a ransomware attack on organization Y. Focusing on identifying and reducing your attack surface in time and over time and as a whole is not so popular, apart from the current External Attack Surface Management (EASM) hype cycle of course.

Moreover, attack surface reduction needs to be a continuous activity, since one-off assessments only help identify problems at the time the assessment is performed. Should the vulnerability or public exposure be revealed a day after, then waiting a year, six months or even a month to discover it will be a day late and a dollar short.

If you enjoyed this post or have thoughts you’d like to share, we’d love to hear from you! The best way to stay updated and never miss a post is by subscribing to our monthly newsletter. No spam, no sharing your details – just valuable insights delivered once a month straight to your inbox.

Subscribe Now