JE Messenger 1.2.2 Joomla Module by Harmis Technology.
What: Incorrect Access Control
Due to insufficient protection mechanisms, it is possible to perform specific actions in the context of another user.
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:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:N : 7.7 (High)
Each user who has the rights to send Message, can send them in the name of another user. In this example, we are logged in as user1 and send a message in the name of user2 to user3. First of all we look into the empty inbox of the user we want to send the message.
If you do not already know the user-id of the user in which name you want to send the message, we can use the following "trick" to get it. We simply start an interception-proxy and type in the the first few letters of his username in the "To" field of the "Compose" page. The response of the triggered ajax request sends us back some interesting information about the user including his user-id.
Now we have everything to send the crafted message to the user. We start the interception-proxy and send the message. It's enough to change the value of the parameter "mail_from" in the request to the user-id we received before and forward it to the application.
- 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