From Help Desk to the Desk Owner - Simple Techniques #2

Hello guys, it's me again, now for the second post of the Simple Techniques articles. Today, I'm here to talk about the history of a pentest where I identified a GLPI instance running on the customer environment and how some public vulnerabilities and a little documentation helped me gain access to an Office365 administrative account. Of course, I'm not going to provide any sensitive information or details about the customer or anything like that; everything you're gonna see here is made by me, there is no real information about the pentest right here. My goal in sharing this is just to tell some experiences that I encountered and maybe help someone learn something new =)

Starting from nothing, aiming for the moon.

For context, it's a web penetration test in one domain, and some applications are running on other ports like 8443, 10443, etc. There are no other subdomains to explore, so I had to focus on the main domain and scan for open ports that can be web applications. First of all, I ran Nmap with some flags and waited for the results; the command I used was:

nmap -p- -open -v --min-rate=5000 -T3 example.com        

The --min-rate flag and -T3 helped me to get some time, so after 5 minutes, I identified 8 open ports different from 80 and 443. I started accessing every application on my browser to understand what was running below each one. There are a bunch of .NET applications that I found some vulnerabilities in, but let's focus on the objective of this article.

In a specific port, a GLPI instance is running that only allows authentication based on the internal GLPI database. For you guys that don't know, GLPI is a PHP open-source help desk solution that allows the IT department to manage tickets, monitor computers, activities management, and many other things.

I already have found other GLPI instances in other web pentests. I know there are some vulnerabilities like RCE, SQLi, and Account Takeover... so I didn't waste more time and ran Nuclei with all GLPI templates and waited for the results, but... no happy hacking here, Nuclei just returned me some public information and nothing more.

I love credentials, do you love credentials?

In this specific GLPI instance, LDAP authentication is not activated, so I cannot collect all the employees' names and try for defaults like Company@2024, company2023, etc. However, through a search engine and data archive tool, I could find a valid credential of a normal user to log in to the GLPI instance. That's good! So, after logging in to the GLPI instance, I started looking for everything that could help me get sensitive information or identify a possible vulnerability; nevertheless, there's nothing special here, so I have two ways to choose:

1. Find a vulnerability in GLPI that affects the version installed
2. Search for vulnerabilities reported by other researchers

I decided to start with the first way since it's a good idea to improve my research skills, and I can learn something new. I focused for two entire days and found some SQL Injections and Information Exposure, but nothing that I could effectively exploit or help me escalate to other vulnerabilities. At another time, I will try to find something that could have helped me in this situation.

After a time, I remembered that there are some public vulnerabilities reported to GLPI on the huntr.com website, for you guys that don't know, huntr.com is a "bug bounty" platform that allows security researchers to find vulnerabilities in public projects and has an easy communication with the project maintainers. I used a Google Dork to filter for vulnerabilities reported to GLPI.

site:huntr.com intext:"GLPI"        

I read every report that I could find and selected the most interesting ones for my scenario. Two specific reports helped to get an Account Takeover that allowed me to escalate to Super Admin and another report helped me achieve remote code execution.

1. Improper Access Control That Leads to Privilege Escalation / Account Takeover by Abdulmohsen Alotaibi
2. SQL Injection in GLPI leads to Account takeover and RCE by Guilhem7

WINNER WINNER CHICKEN DINNER

First of all, I used the Privilege Escalation/Account Takeover exploit made by Abdulmohsen against my target, however, the exploit did not work on the first try because he could not understand the GLPI behavior since this instance was running in the Brazilian, so I adapted the condition to detect if the password was changed successfully and everything is fine.

-   if 'Reset password successful' in r.text: 
        print("[+] Sucessfully updated the password to: " + super_admin_pass_value)
    else:
        print("[-] There was an issue while updating the password, please ensure the provided script info is correct")
        sys.exit(-1)

+   if 'Senha alterada com sucesso' in r.text:
        print("[+] Sucessfully updated the password to: " + super_admin_pass_value)
    else:
        print("[-] There was an issue while updating the password, please ensure the provided script info is correct")
        sys.exit(-1)        

But why do we need to be Super Admin? As Guilhem7 explains in his report, we need Super Admin privilege to update the GLPI settings and allow to .php be uploaded to the application.

You are not going to find the original exploit on the report because the GLPI team asked the researcher to send the exploit by email, though you can find the exploit on Guilherm7's Github profile.

This definitely can make a man's day, when I saw the final URL I clicked so fast that I could hear my CPU make some noises, probably because I opened 5 tabs at the same time hahaha.

Yes! We have a web shell. Since I have permission to escalate to the infrastructure I started listening on port 446 on my VPS and used a payload to gain my reverse shell, moved to a TTY shell and now we can try to become root and search for sensitive information stored in files. This Linux machine is an updated CentOS so we cannot use PwnKit, OverlayFS, or other exploits to get an easy root on the machine. I started my enumeration and collected every possible way to escalate, but we didn't have luck in the process. It wasn't entirely bad, as I was able to find a shell script file that backed up the GLPI database and had the MySQL root credential in it.

Read, Learn, Explore!

When I analyzed the GLPI instance I noticed there is an account defined on the SMTP settings, but the password is not directly stored on the settings page. This stuck in my mind and I started to imagine how this could be stored... maybe in the database? Then, I accessed the GLPI project on GitHub and started reviewing the code to get more information about this. In a file called "glpi-0.80.0-empty.sql", I found something that caught my attention:

Ok, even if it's not the version of the instance we're on, why don't we check? So I logged in to the MySQL database with the root credential that I had found and connected to the GLPI database, accessed the glpi_configs table, and got the smtp_password value.

As you can see, we have the smtp_passwd value, but the password is encrypted. At first glance, we might imagine it's a Base64 encoded string. However, upon reading the GLPI source code, we find that the password is encrypted with SODIUM_CRYPTO_AEAD_XCHACHA20POLY1305_IETF_NPUBBYTES, which is a very strong encryption algorithm. Therefore, brute force is not possible here.

If we check out the GLPI source code to see how the decryption method works, we'll notice it takes the encoded value and a private key as arguments. So, all we need is the private key, right? Yes!

If we look a bit more at the source code, we can understand how this private key is generated. By default, in versions before 9.4.6 of GLPI, the key was stored in a file named glpi.key. Versions beyond that are stored in a file named glpicrypt.key. Since the GLPI service is running as the Apache user and we have read and write access to the directories, we have access to the glpicrypt.key file. So, I decided to create a PHP script file that will read the content of the glpicrypt.key file and use it as the private key. Then, I defined the string I wanted to decode as a variable. Our result is the plaintext key for the SMTP account!

Final thoughts

It's important to note that these vulnerabilities in GLPI have been completely patched, and the way the private key is stored isn't bad, considering that an attacker would need to compromise the target machine. It was also quite a gamble, as the account could have had 2FA enabled. However, that wasn't the case precisely because it was being used by a service. I'd like to thank the two researchers who contributed to the GLPI project by reporting these vulnerabilities. They helped me a lot, hahaha. I appreciate you for reading this article, and I hope you've learned something new.

References

• https://huntr.com/bounties/82443f1f-300b-4d5a-a1ab-73902263ea4b
• https://huntr.com/bounties/77c672dd-319f-4b48-a704-dcffb4d5689a
• https://github.com/Guilhem7/CVE_2023_41320
• https://github.com/glpi-project/glpi
• https://gist.github.com/oppsec/bf5573d3956ee97f4ac9ce62b9200831