Weak passwords? Better call The Doctor.

Every network presents its own unique opportunity for a penetration tester. Often, hidden among the innumerable workstations, servers, printers and switches, a tester will stumble across a specialty system quietly fulfilling some obscure business requirement. These edge case systems can provide the tester with a chance to highlight the different, sometimes surprising, ways an attacker could impact the organization.

Below we describe a recent internal network and wireless network penetration test performed at a facility where a few simple, commonplace errors resulted in our comandeering robotic service carts used within the facility.

The overall internal penetration test was progressing in an acceptable fashion and a comfortable level of compromise had been achieved, with target data located and exfiltrated. It was time to move on to searching for alternate avenues of attack, looking to increase both the width and depth of the findings.

Network mapping had uncovered a number of systems listening on the common MySQL port 3306. These systems were checked for the default username of 'root' and a blank password. A single database was found to be using these credentials but, sometimes, one is all that is needed.

Naturally, weak database credentials were interest grabbers and warranted a closer look at this system. A number of other services were discovered: FTP, SSH, and web server on ports 80 and 443. By pointing the browser at the web server it was possible to determine what sort of system it was before poking around in the associated database.

Branding on the discovered web interface indicated that this system was associated with a manufacturer of robotic service carts. A number of these robots were noted dutifully trundling through the halls of the facility, delivering important supplies and assisting with janitorial activities. A quick bit of additional research revealed that these robots navigate the corridors along predetermined routes using a variety of built-in sensors and politely announcing their presence and intentions via a small internal speaker. Connecting to the wireless network, the robots are able to call and operate service elevators, communicate amongst themselves, and coordinate with base stations such as the one discovered. From the web interface the robots can be dispatched to a variety of predetermined locations and operators can check the equipment status and view near real-time images from onboard cameras.

The web interface also included an "Administration" tab. Clicking on that tab resulted in a prompt for a username and password. A bit of searching through the poorly protected MySQL database on this system uncovered a likely table named "ui_users" which contained a pair of usernames as well as the associated, encrypted passwords.

At this point, while it would have been possible to launch an intensive, offline attack against the encrypted passwords in an attempt to recover the plaintext, the initial attack considered was the (disturbingly effective) method known as "guessing a few really poor password choices". Using usernames as passwords for service accounts is a popular, if bad, decision. So we used the discovered username for the password.

This method proved to be successful on the first attempt and provided, what appeared to be, end-user administrator access to the web interface. This account enabled access to a few additional options as well as a handy bit of information in the form IP addresses for all of the other base stations at the facility as well as the IP addresses of the robots themselves.

A portscan of the other base stations indicated they were operating essentially the same as the one system already compromised, although the MySQL databases were not quite as welcoming in offering a default login with a weak password. The robots were all found to be running SSH as well as a web server on port 9000.

Connecting to the web interface for a robot resulted in a login screen prompting for a username, in the form of an email address, and a password.

The previously successful username and password combination was tested against the robot's SSH login and, slightly modified to fit an email format, against the web interface login. Both instances were met with rejection.

Temporarily stymied in the attempt to access the robot, attention returned to the compromised MySQL server. There were two accounts detailed in the "ui_interface" table and the "REDACTED2" account could possibly provide the access desired. Based on the recent experience with the "REDACTED" account, using the username as the password for the "REDACTED2" account was the starting point again.

Not only was the "REDACTED2" account using "REDACTED2" as a password but it appeared to provide an elevated 'developer' level access to both the web interface and SSH on the base station.

The same combination was then found to provide SSH access to a robot.

The "REDACTED2" account, as a member of the sudoers list, provided a comfortable level of access to the targeted robot. Still, the system had a web interface that likely would provide some interesting and easy-to-use features. A search through common file locations revealed the PHP file used to authenticate web users. After a making a backup and a quick modification to the PHP the web interface provided 'super' user access with any random username and password combination.

The web interface presented a wide variety of administrative options for the robot. A 'super' user could change or load new routes within the facility, or building floor plans, audio files, and modify key configuration settings. While the SSH access alone would have facilitated making these sort of changes, the web interface was specifically designed for this type of activity.

This degree of compromise leads to an old problem. What do you do to a system to show that you can do ANYTHING to a system? It was important to highlight the import of this finding in a way that would be memorable and informative for the client. Obviously, nothing destructive or disruptive, these robots were performing important work all across the facility and any real interference would be unacceptable. While it would have been possible to have all the robots form a massive robot flash mob in the office of the CEO it could be overkill and may have had considerable negative impact on client relations. Eventually, an idea was developed that would leave a lasting impression with the minimal amount of disturbance; a proof of concept that would resonate with the target audience.

First, a trip to the local hardware store was needed to pick up some special equipment.

Next, an available robot recharging in the docking bay was located. After logging into the robot via the web interface a pair of specially chosen audio files were uploaded and the robot was instructed to play the new sounds over its internal speaker when performing certain actions. The lucky robot was then equipped with it's new accessory and asked to 're-dock' which involved simply backing up a few feet and pulling forward again on to the charging plate.

You can view the results in the video below, having your speakers turned on is highly recommended.

In the end, the client was provided with the detailed report with all the penetration test findings including information on the danger of default installations, weak password choices and the greater potential impact of the above video Finally, the client was presented with a small souvenir from the penetration test: one plunger, gently used.