This post details my analysis of a router that I purchased from an Australian second-hand retailer. The USR-G806AU 4G LTE industrial cellular VPN router by PUSR (Jinan USR IOT Technology Limited) had an undocumented uid=0 account named usr . I recovered the account’s credentials from a helper utility that ships on the device itself, and confirmed that it can be used to achieve remote SSH access. Mitre assigned CVE-2024-42682 to track this issue. While this research focuses on a single unit, the behaviour may not be isolated. Similar configurations could exist on other devices from the same manufacturer. Owners of USR-G806AU devices should note that if management interfaces such as HTTP, SSH or Telnet are exposed to untrustworthy networks (such as the Internet), undocumented uid=0 accounts with discoverable credentials could provide adversaries with a direct administrative access path. Owners should restrict access to remote management interfaces from untrustworthy networks. This post describes the process by which I discovered the undocumented uid=0 account and its password, but we are not publishing the password itself . Device owners should assume that a capable adversary may be able to independently discover the password of the undocumented uid=0 account. We first contacted PUSR to report this issue in 2024. We also provided details of this issue to the Australian Cyber Security Centre (ACSC). Details of these reports are included in the timeline at the end of this post. We confirmed that this issue affects our USR-G806AU device running firmware versions 1.0.41 and 2.0.13. Despite our repeated attempts to engage with PUSR, we have not heard from them since 2024. The issue may have been resolved in a subsequent version if one has been made available to customers, but Tanto Security cannot know whether this is the case. We only tested our own USR-G806AU device. We did not interact with any other devices. Due to this, we cannot know the full set of models, devices, or firmware versions that are affected by this issue. If you are a user of PUSR devices, the manufacturer or your retailer may be able to provide you with advice and information regarding undocumented accounts. An unlikely candidate “Is that a used 4G industrial router for sale online? I’ve never seen these before.” Those were my thoughts as I was searching for a device to hone my hardware hacking skills. I certainly wasn’t expecting to come across a 4G industrial router at an Australian second-hand retailer, but it fit my criteria. I could pick it up for cheap - under $100 - and it seemed to have lots of functionality that I could explore. I placed the order, and about a week later it arrived on my doorstep. The device is a USR-G806AU, with the AU suffix denoting it as the Australian version. It is made by PUSR (Jinan USR IOT Technology Limited), which describes itself as an “industry-leading IIoT software/hardware solution provider”. This is not the root account you are looking for First things first. I plugged the device in, powered it up, and connected it to something to make sure it worked. I decided to use the Raspberry Pi that had been sitting in the corner of my office. It had been looking at me longingly, much like the Flipper Zero we all have in our bottom desk drawer, each hoping for something to do. This meant I could connect the Raspberry Pi to my Wi-Fi while having the USR-G806AU connected directly to the Raspberry Pi via Ethernet. I could then SSH into the Pi from my laptop, allowing me to interact with the router while having it be somewhat separated from my own network. A few minutes later, once everything was all hooked up, I saw some flickering lights. It was alive! I soon found that someone had already discovered an account on firmware version 1.0.41 with the username root and the password root . As my device was running the same version, I confirmed that I could log in over SSH and Telnet, since both were listening on ports 2222 and 2233 respectively. After I logged in, I was met with some confusion. I was logged in to an account that looked like root, it was called “root”, but… It seemed somewhat locked down. Running id to see what was going on, I realised the root account wasn’t actually the superuser root account. It had a user identifier (UID) of 2, not 0. I took a look at /etc/passwd which showed the following: root:x:2:2:root:/root:/bin/ash root:x:2:2:admin:/admin:/bin/ash daemon:*:1:1:daemon:/var:/bin/false ftp:*:55:55:ftp:/home/ftp:/bin/false network:*:101:101:network:/var:/bin/false nobody:*:65534:65534:nobody:/var:/bin/false rpc:x:65533:65533:rpc:/var/empty:/bin/false sshd:x:22:22:sshd:/var/empty:/bin/false usr:x:0:0:Linux User,,,:/root:/bin/ash Each row in the passwd file is colon-separated and contains seven fields. Focusing on the first entry for the root account we see the values: The username: root The password hash, or the special value x to indicate that the user’s password hash is stored in /etc/shadow The u...