Riorey DDoS mitigation appliances suffer from a very poor design vulnerability where they have a hardcoded root login and password for automation. Fail!
29c26502b9e544b424841c7d7e3ccd28614e8629e9e6f9e8c76dac87a75fd345
Title: Riorey "RIOS" Hardcoded Password Vulnerability
Severity: High (Full root access to the device)
Date: 07 October 2009
Versions Affected: RIOS 4.6.6 , 4.7.0 possibly others
Discovered on: 25 July 2009
Vendor URL: www.riorey.com
Author: Marek Kroemeke
Overview:
Riorey DDoS mitigation appliences (www.riorey.com) are vulnerable to taking a full control
over affected devices via a hardcoded username and password used to create
a SSH tunnel between the RView application and the device itself.
Details:
Riorey devices running affected "RIOS" versions have a hardcoded username and password
that is then used by the RView software to connect on port 8022 in order to create
a SSH tunnel. This allows the attacker to login as user 'dbuser' using
the hardcoded password, and due to an old Linux kernel version used - escalate privilages
through several vulnerabilities and eventually take the full control over the device.
Additionally - the web interface advices the user to reset the admin password for security reasons,
but the RView application still uses the hardcoded password in order to create the SSH tunnel which
may result in a false sense of security.
Proof of Concept:
Open your favorite SSH client and use the following detials in order to login:
port: 8022
username: dbadmin
password: sq!us3r
-- cut --
root@rioreyXXXXXXX dbuser # id
uid=0(root) gid=0(root) groups=0(root)
root@rioreyXXXXXXX dbuser # uname -a
Linux rioreyXXXXXXX 2.6.16.6 #23 SMP Fri Oct 24 19:29:08 EDT 2008 x86_64
Dual-Core AMD Opteron(tm) Processor 1210 HE AuthenticAMD GNU/Linux
-- cut --
Mitigation:
Login to the device via SSH using the above details, and reset the password using the 'passwd' command.
Vendor Contact:
30 July 2009 - Initial vendor contact
31 July 2009 - Vendor replies advising to use a firewall in front of the device
01 August 2009 - Vendor replies that next software release will address this problem, work in progress
09 August 2009 - Vendor sends an email confirming that it's not ready yet but will be by the end of the month
16 August 2009 - Confirmation about realease day of a patched version - 05 October 2009
07 October 2009 - Releasing the vulnerability report.