tl;dr: Trango devices all have a built-in, hidden root account, with a default password that is the same across many devices and software revisions. This account is accessible via ssh and grants access to the underlying embedded unix OS on the device, allowing full control over it. Recent software updates for some models have changed this password, but have not removed this backdoor.
Around a year ago, I extracted a software update package for a Trango GigaPlus radio and found that it simply contained an ext2 filesystem image. After mounting that, I checked /etc/shadow and found a hashed root password, which I immediately put into Cain & Abel, but since I had no idea what length the password was, or what sort of characters it contained, I didn’t end up making any progress bruteforcing it.
More recently, I took another look at the filesystem image. I ended up finding some login credentials, but not for the root account. Instead, it was for Trango’s FTP server, which hosts many of their software update packages.
I downloaded many old packages for their legacy devices, figuring that they were probably much worse at securing their devices 5 years ago than they are now, so looking at those may reveal more than looking at recent packages would.
One of the packages I downloaded contained the root password I was looking for in plaintext. After verifying that it worked on our devices, I immediately reported the find to Trango, who removed the package containing the plaintext password from their FTP server. They said they’d get back to me within a week about next steps.
That same day, I also spoke to a Trango rep on the phone. He said that while this root password worked on some older devices, the password had been changed to something longer in newer device/software versions. This means that the vulnerability still exists in all software revisions of their devices, but with a different password than the one I found.
Three weeks later, I still hadn’t heard back, so I emailed them again asking for an update. I also asked if it would be safe to go ahead and change the root passwords ourselves on our devices, so that we didn’t have to wait for an update to be released. The rep said that it was safe to change the password ourselves, and that there “is no known vulnerability with our product or the software,” which I take to mean that they don’t consider this root backdoor a vulnerability.
While I was going through the filesystem, I also made an interesting discovery with regard to how ssh works on some of their devices. When you connect to a GigaPlus, for example, via ssh, the shell (/bin/sh) immediately spawns a telnet connection to 127.0.0.1, which is what gives you the proprietary configuration CLI. If you end the telnet session without ending the ssh session, either by pressing Ctrl+d or Ctrl+], then it drops you back into the ssh connection, which is just a unix shell.
Obviously having full root access to this unix shell gives you a lot more control over these devices than just having access to the device configuration CLI, making this vulnerability even more serious. Devices compromised in this way can easily be added to botnets, such as the massive one recently aimed at Dyn.
While I was waiting for a response from Trango, I also took the liberty of going through the software packages I had access to via their FTP server and determining what versions of each product use the shorter password I found:
Affected (the short password):
Apex <= 2.1.1 (latest)
ApexLynx < 2.0
ApexOrion < 2.0
ApexPlus <= 3.2.0 (latest)
Giga <= 2.6.1 (latest)
GigaLynx < 2.0
GigaOrion < 2.0
GigaPlus <= 3.2.3 (latest)
GigaPro <= 1.4.1 (latest)
StrataLink < 3.0
StrataPro - all versions?
I couldn’t test the SpartaElite software because the packages are encrypted. The StrataPro was the device that contained the root password in plaintext, and all of its packages were removed from the FTP server, so I wasn’t able to test those either.
Also, it’s important to keep in mind that just because one of Trango’s devices isn’t listed above, doesn’t mean it isn’t vulnerable to this root backdoor; it just means that the one password I found isn’t working. All of their devices still appear to have a root account accessible via ssh using other passwords, and passwords are all stored as a salted MD5 hash, so it’s only a matter of time…
Timeline:
2015 – backdoor first discovered
2016/10/07 – password found
2016/10/07 – reported to trango via email
2016/10/07 – spoke to trango rep on the phone
2016/10/07 – trango said they’d get back to me next week with next steps
2016/11/03 – Emailed trango again asking for an update, as I hadn’t heard anything back from them
2016/11/07 – trango responded, said it’d be okay for us to change the root passwords manually, implied that they don’t consider this a vulnerability and they won’t be fixing it
Demonstration:
ianl@ianl-laptop:~$ ssh root@1.2.3.4
root@1.2.3.4 password:
Trango System: TrangoLINK GigaPlus Command Line Interface v3.2.3
(CLI-view)#
<press Ctrl+d to kill telnet connection>
#
# id
uid=0(root) gid=0(root) groups=0(root),10(wheel)
CVE ID’s:
CVE-2016-10305
CVE-2016-10306
CVE-2016-10307
edit (2016/12/23): I found another password, this one goes to the Trango Altum AC600′s: “abcd1234″. Yeah.