Slashdot Mirror
Backdoor In RuggedOS Systems: Infrastructure, Military Systems Vulnerable
FhnuZoag writes "A backdoor has been found in Canadian based RuggedCom's 'Rugged Operating System', providing easy access to anyone with the devices's MAC address — something often publically displayed. Rugged OS is being used in a wide range of applications, including traffic control, power generation, and even U.S. Navy bases. The backdoor was first found over a year ago, and RuggedCom have so far refused to patch out the exploit."
The exploit is trivial: each device has a permanent "factory" user, and an automatically generated password derived from the MAC.
Nothing. At. All.
Occasionally living proof of the Ballmer peak.
Unchangeable default password = MEGAFAIL
"When information is power, privacy is freedom" - Jah-Wren Ryel
Or could it be those evil Chinese?
What's this JC CREW organization that supposedly discovered this backdoor? Is it a corporation? group of hackers? single individual? in the US? International?
i went to their site at www.jccrew.org and it's just a picture of a burned out car. I don't get it. This is huge, but I can't find anything about the research person or organization.
Using this device would mean you would fail PCI-DSS and probably a few other widely used standards (ISO-27001 for example). One of the first requirements in these standards is that default vendor passwords be changed. You can't change it or even disable it.
Oolite: Elite-like game. For Mac, Linux and Windows
This whole post sounds like a setup for a classic GNNA troll. Rugged military backdoors? Are you kidding me?
RuggedCom have so far refused to patch out the exploit.
Perhaps when Siemens moves in new management, the problem will be fixed. After having the egg of Stuxnet on their face, they might be a bit more proactive about these sorts of things.
Have gnu, will travel.
Its a feature...not an exploit.
Looks like to exploit this, you need the MAC addrs.
1) One way is to be on the same LAN segment and watch a sniffer. This means you're already dead because you've lost physical security.
2) Another way is to telnet (FREAKING telnet in 2012?) into the device and the MAC is in the MOTD. This means you're already dead because you've lost all network security. What kind of madman allows telnet traffic thru a firewall in 2012? What kind of a madman allows unrestricted internet access to an embedded control device?
3) If you manage to somehow own a plain ole PC on a scada network, now you can own embedded control devices. But having an owned PC on your network means you're dead anyway.
I'm still struggling to figure out how a live, well run network could be in danger. What I mean is to implement this exploit takes a system that is already more screwed up than anything you could do with the exploit.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Does this mean that there will now be another set of noise with script kiddies trying to create automated scanners to locate these devices, thus adding more junk for me to look through in the logs?
--
Time is on my side
[Slow_Clap()]{2}
Good. The SC function works.
So we have that.
Nothing is 100% secure. Nothing. At. All.
Especially those things with a factory supplied backdoor. Regardless of the complexity of the password, regardless of how the marketing guys try to spin it as a "maintenance portal" or whatever they are calling it (assuming of course customers knew it was there), such a thing is essentially a backdoor.
Hopefully this was something that customers were aware of and something that customers could disable. Or more optimistically a debugging feature customers would have to enable for a session while in direct communication with the factory. Even so a hypothetically generate-able password is troubling.
I do not think it means what you think it means.
It is a device for industrial manufacturing. In the past the terminals and switches were accessible to anybody allowed into that area. It is an access problem. The network in a manufacturing plant should be inaccessible from outside. Why is that even news?
hfoo
I think they sell clothing - JCrew has lots on their website. :-)
We'll already be fully aware who our biggest enemy is: big business.
I'm certain the inevitable legislation to come from this will fairly and accurately reflect that fact...
An enigma, wrapped in a riddle, shrouded in bacon and cheese
The obvious correct hardware design was a simple switch (on the device) that allows usage of a default password. That way, you ensure both that you can put maintenance to the device in the future, whilst maintaining daily security.
Now we know what exploit Trinity used to shut down the power plant.
It was supposed to be RiggedOS.
My other car is a 1984 Nark Avenger.
Finally! An excuse to declare war on Canada.
Captcha: ambushed
4) brute force the password, knowing that only 3 bytes are unique to the device.
You don't have to guess. The password is computable from the MAC address using this short Perl program.
The factory password is, literally, "factory". It cannot be disabled and its password cannot be changed.
Someone should go to jail for this. It may fall under criminal negligence, sabotage, or even providing material aid to terrorists.
Any sane deployment is not vulnerable as it will not allow telnet or rsh (both insecure). As the release notes said, telnet can be set to allow 0, and rsh can be disabled (which is our stock deployment as we have sane SOPs). I have verified that this does affect the latest ROS v3.10.0 release from Oct 6, 2011 for telnet. It does not work via SSH or HTTPS services.
Administration - Configure IP Services - Telnet Sessions Allowed - 0; RSH Server - Disabled.
Any sane deployment is not vulnerable as it will not allow telnet or rsh (both insecure protocols). As the US-CERT work-around notes said: ROS users can disable the rsh service and set the number of allowed telnet connections to 0. Disabling the RSH service and setting telnet to 0 effectively disables this remote exploit. I have verified that this exploit works on the latest ROS v3.10.0 release from Oct 6, 2011 for telnet. In my testing, the same "factory" username and password which worked for telnet does not work via SSH or HTTPS services. There may be some other built-in username/password for SSH and HTTPS. Having said that, the ROS switches support multiple VLANs and the management of the switch can be assigned to an isolated management VLAN and restricted from all other access which will further restrict any management access to these devices.
I had a job interview with Ruggedcom a couple years ago, terrible experience even got the full facilities tour. This was just before Christmas too, the interviewer kept interrupting with phone calls from his team working on a wi-fi project under a bridge somewhere in the states and told them they couldn't stop working until the project was done even if it they were stuck there over Christmas. I eventually asked to leave after it the interview continued on for over 3 hours...that and it turned to money and I discovered this company pays it's people *half* of the competitive market industry rate and works them to death! They really are a small shop for what they do.
Of course, the fact that you can only use the password via. telnet/serial/rsh (as per the article), which already guarantees you HAVE NO SECURITY is clearly criminal. </sarcasm>
The vendor has posted a workaround on CERT (http://www.kb.cert.org/vuls/id/889195) which says 'disable telnet and rsh'.
This is not quite the same, since you CAN change the passwords on an iLo/riLo or DRAC... the problem is that most people forget or don't. So you thought remote root was unavailable until that dictionary attack is remotely performed against a local console.