There are a huge number of products available in the modern world that come with network connectivity now, when perhaps they might be better off with out it. Kitchen appliances like refrigerators are the classic example, but things like lightbulbs, toys, thermostats, and door locks can all be found with some sort of Internet connectivity. Perhaps for the worse, too, if the security of these devices isn’t taken seriously, as they can all be vectors for attacks. Even things like this Rigol oscilloscope and its companion web app can be targets.
The vulnerability for this oscilloscope starts with an analysis of the firmware, which includes the web control application. To prevent potentially bricking a real oscilloscope, this firmware was emulated using QEMU. The vulnerability exists in the part of the code which involves changing the password, where an attacker can bypass authentication by injecting commands into the password fields. In the end, the only thing that needs to be done to gain arbitrary code execution on the oscilloscope is to issue a curl command directed at the oscilloscope.
In the end, [Maunel] suggests not connecting this oscilloscope to the Internet at all. He has informed the producer about it but as of this writing there has not been a resolution. It does, however, demonstrate the vulnerabilities that can be present in network-connected devices where the developers of the software haven’t gone to the lengths required to properly secure them for use with the modern Internet. Even things not connected to a traditional Internet connection can be targets for attacks.
I thought this was really impressive when I read it the other day, and am looking around our lab. We have at least 20 different kinds of test instruments that are capable of remote operation by web access, as in they have a browser. We routinely bar all Windows machines older than 4 years from internet access, but some of our linux and vxworks scopes are over 15 years old and they’re still on the network, and now I’m thinking hmmmm how good an idea is this.
Well internet no, but being networked can allow for certain things like monitoring an experiment remotely.
Yeah, that’s how we use it, and getting scope shots, and to a lesser extent automated/remote testing, and that’s one reason we’ve been aggressively buying linux-based scopes over windows scopes, because we know that there’s going to be a time when a windows scope won’t be allowed on the network anymore. (The other reason is that we keep having windows scopes hiccup somehow and suddenly stop booting and we reinstall windows and get stuck on drivers and the scope never works again, while we have a half dozen vxworks based scopes from 1992 that are still happily chugging along.
With certain routers you should be able to block internet access to certain devices while allowing them to communicate over the network. You could look into open source options like dd-wrt and tomato, or commercial options like ubiquity. I don’t know much about networking but you could look into VLANs.
Do these scopes still pull OS updates? As if the Kernel and core library are staying updated from the FOSS community at large in some way and its only the actual scope software that may become abandoned there is probably no reason to ever take them off the network. The underlying Linux system has more than enough security features on the networking side (usually defaulting to moderately secure type levels) you can setup to make it a stupidly hard time for an attacker to do anything much even if the scope software hits EOL or just has major bugs they are not fixing – can’t exploit what you can’t access.
However obviously nothing is perfect, and I’d never put hardware like this directly on an internet facing network without really good reason. Does it really really need to be remote connected anyway? Or directly addressable when you probably already have a lab wide VPN for remote access to the local network already – Why have a bigger surface exposed to attack than you actually need?
I bet $5 that even if the companies DID provide OS updates, they don’t anymore, and even if they did, they wouldn’t get through the corporate firewall, meaning the only way these would get fixed up is if someone downloaded upgraded firmware and installed it.
Well it probably is just a basically stock Debian/Ubuntu/SuSe (etc) under the hood with a scope program set to autorun on boot, so the company doesn’t have to provide updates for their bits at all for a really really really long time. Most likely anyway as changes that break older stuff in Linux are relatively rare.
In which case the OS updates may well just happen checked for automatically when you turn it off, or prompt for user acceptance, or it might sit there waiting for the user to tell it to look (etc). But as that is the sort of connection you want getting through your firewall I’d suspect it would if they tried to update, or your corporation would already have their own internal mirror that hosts the updates.
Well l we’ve been hacking the rigol for years over at the eevlog [0]. Nobody probably really cared about the exploit in so far that enabling ssh etc is easy. This might be thought of as interesting because this opens a remote door.
While generally RCE’s are bad, these devices are usually so leaky, I just shrug. And in this particular cases, I’m happy we still have a chance to own our hardware …
See more firmware hacking my repo [1].
[0]: https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/
[1]: https://gitlab.com/riglol/rigolee/firmware/
Such attack vectors just always boggle my mind, Why would something like a password EVER end up on a promt from after being entered in a program?
Much more interesting would be the possibility to finally customize trace colors, in some cases the contrast is lacking (channel 4 and 3 and math), and that would really increase the usability.