CVE-2022-35914 and how the GLPI ecosystem might be affected

No doubt we need to share some light on the CVE-2022-35914 htmLawedTest GLPI vulnerability. Last week I started gathering information to write this post. Only now, after the storm had passed (at least the initial wave), I had the time to finish. What first came to my mind was Oscar Wild’s famous quote: As translations usually are lousy, in Spanish, this phrase has evolved into something like:

Let them talk about you, even if it is bad

More on this later, but let’s start at the beginning.

What has happened

[box type=”warning”] Disclaimer: I’m no security expert, so don’t expect a thorough report, but rather a file with information for you to consider and some personal conclusion at the end.[/box] If you are reading this, you might at least have heard something, but just in case, let’s make it clear. A couple of critical vulnerabilities have been discovered on GLPI, and all previous versions are affected:

This is not our field of expertise, but roughly a GLPI had an issue with a 3rd-party library htmlLawed and an API-related vulnerability. A CVSS base score of 9.8 is pretty scary.

Was this the first significant vulnerability of GLPI

No, it wasn’t. During the summer, CVE-2022-31061 affected previous GLPI versions, patched by upgrading to 9.5.8 and 10.0.2, respectively. But, the htmLawed vulnerability ( CVE-2022-35914) was the one exploited intensively from the beginning of the month. The result was a massive amount of not correctly patched GLPI instances affected. Let’s review how the events occurred based on our information:

A timeline of events

2022-07-13 CVE is notified
2022-07-13 CVE is patched
2022-09-14 GLPI patched versions are released (9.5.9 & 10.0.3)
2022-09-19 TICGAL notifies his contacts on his newsletter
2022-09-19 TICGAL starts fixing our systems & contacts contract clients to schedule the patching
2022-09-20 Some concerned clients (like you?) opened a ticket to schedule interventions on their systems.
2022-10-01 The first PoC appears on Github
2022-10-03 The CVE is disclosed
2022-10-03 A CyberSec client notifies they are exploiting the vulnerability
2022-10-03 Started reviewing servers
2022-10-04 The nightmare begins
2022-10-07 Spanish INCIBE-CERT reports the vulnerabilities in its Early Warning Security Advisories (SIC)

New Gapp 2.6.1. An Important Update on Gapp Self-Service and Formcreator

Some signs of having been compromised

Some information about the attacks we have found. Probably as I write this down, there are several additional ones.

Access to the offending file

If you see similar access entries in your apache (or your web server of choice), your GLPI is most likely compromised.

CPU Spikes

Excessive consumption bandwidth / Bandwith exhaustion

We had some testing instances affected. This was the notification we got on October,4th:

Subscription:XXXXXXX- 1024 MB High Frequency – 208.76.222.133 (glpi10rc1): 149.8% used […] Please note: Your bandwidth usage cap will reset on the 1st of every month.

Automatic actions not working

Due to the cronjob being substituted for a malicious one, the needed cronjob to make GLPI automatic actions work has disappeared. So more of a side-effect than anything else.

Strange processes running

Accessing /etc/passwd

One of our clients detected this abnormal behaviour confirming a not thoroughly cleaned server. We had a hard time solving this one.

No data exfiltration detected

For the DPO to be at rest. No sign of date extraction has been detected. Said that it doesn’t mean it won’t happen in the future.

Searching for the real impact

Have you been affected? I know it doesn’t improve things, but you are not alone. Twitter is an excellent source of (dis)information. You know, handle it with care. Despite all this, I don’t know a better way to obtain almost real-time information on any random topic. Here you have an example: https://twitter.com/luminouw/status/1577069579637071882. After reading the thread, I searched around the net, landed at Vulmon.com and discovered that the CVE-2022-35914 GLPI vulnerability was trending worldwide! We are talking about a World Wide Attack here! Note the cyan line: GLPI is a niche tool, but there are more installations than we might have imagined.

Additionally, we have some off-the-record information pointing to some providers having most of their GLPI-hosted instances affected. Not yet convinced? OK, check out our production server blocked attack attempts by fail2ban till today:

EDR on a Server Linux server?

We were lucky to have BEST – Bitdefender Endpoint Security Tools – for Linux installed on our production server. It didn’t block the attack itself, but its suspicious actions. We have first-hand knowledge of Microsoft Defender for Endpoint on Linux (did you even know this tool existed?), not blocking any threads. However, it reported the /etc/passwd access. Did your EDR detect the attack? Please share in the comments.

TICGAL: Local Roots, Global Reach IT

Tu quoque, Gapp, mi filli?

You too, Gapp? 😉 Yes, Gapp too. Even the API-related dangerous bug (CVE-2022-35947) doesn’t apply here because It is related to token authentication, and Gapp uses user/password auth; we had to do something to stop this nightmare. One of our recent determinations was to force users somehow to update. We don’t have such power, but some leverage might be applied to our increasing Gapp community. How? We are only supporting 9.5.9 and 10.0.3 versions and above. Otherwise, you will see a message like this: Gapp Essentials (Free) and Gapp eXtended (White Label) are forcing the update to the most secure versions of GLPI.

Random thoughts

In my opinion, all this previous data means:

There is a more significant number of GLPI instances around the world than we knew. (This is good, isn’t it?)
A lot of them are not perfectly maintained. (Not that good)
GLPI will be a new targeted destination from now on. (We knew this day would come, and we finally witnessed it)

As writing it took so long, I decided to add some scary examples of my recent searches: In case you don’t know it, Shodan Search Engine is a tool you can use to search any exposed service, for instance, locating GLPI servers. Can you see how dangerous this automation might be? Another one. Can you spot GLPI vuln among some well-known software similar issues? Other relevant links:

Final words

So, GLPI has reached legal age. I know last year was its 18 anniversary, so I’ve started the post mentioning Mr Wilde. We have all learned a lesson the hard way. As a team, these are our conclusions:

Improve our/your processes. (Currently working on it)
Communication is a key player. We are not mail-bombing you with useless emails. An email a month (we’ve sent seven this year) is not too much to keep you in the loop regarding a critical tool in your IT department. Please read the relevant information. It won’t be more than 5 minutes.
GLPI is now a well-known product. And a possible attack target. PoC like this one proves that more indiscriminate attacks will come.

Thanks to the TICGAL Support Team for its hard work in sharing critical information to illustrate this article.