Unauthenticated RCE on a RIGOL oscilloscope

https://tortel.li/post/insecure-scope/

by jandeboevrie • 3 years ago

237 127 3 years ago

tortel.li

Towaway692• 3 years ago

Nice writeup and explanation how to get firmware outside of the hardware.

Bypassing strncmp was particularly insightful.

13of40• 3 years ago

Was I reading it wrong, or does the system actually store a clear text copy of the password instead of a hash?

Towaway692• 3 years ago

It would appear to be clear text with the assumption that no one can login onto the device. I assume the manufacturer makes this assumption.

meithecatte• 3 years ago

I don't think it's strncmp itself that's the problem. They fucked up and are only checking that the provided password matches a prefix of the stored password. And obviously an empty string is a matching prefix.

colonwqbang2• 3 years ago

The (decompiled) code looks very amateurish in general. Like, who writes something like system("echo >... or system("sync"). Looks like something written by a very green engineer/intern and not reviewed by anyone else.

dmvdoug• 3 years ago

I’m sorry, but your comment came right after the comment thread about a guy printing gay porn and I thought you were making a joke and I was giggling about the firmware and hardware thing and then I realized you were making a serious point.

veave• 3 years ago

I wonder who goes around thinking "I'm going to expose an oscilloscope to the WAN!". Something you have to do on purpose, taking lots of extra steps, because of CG-NAT. Kinda asking for it.

mschuster912• 3 years ago

Many universities give everyone on their network a fully routed IP address, at least this was the case ten-ish years ago for me in Germany. Was ideal if you were developing something and showing it off to someone at the other end of the campus while being on the phone or Teamspeak - just give the other person your IP address and spin up a server at 8080, that's it.

Besides, if I were on a red team, I'd enumerate all devices on the LAN as well. Simply to look for all that old cruft someone set up years ago and never updated... that's where you get persistence. No one goes and checks 'scopes, network gear or printers for indicators of compromise in their firmware, because no one thinks of them if the admin isn't looking for outgoing Internet traffic.

Aurornis• 3 years ago

Many universities give everyone on their network a fully routed IP address, at least this was the case ten-ish years ago for me in Germany

Times have changed a lot in the past decade. No reasonable network admin would be giving public IPs to everything that connects to the network any more.

IPv4 addresses are also scarce relative to a decade ago.

tetris11• 3 years ago

This is still the case I think, though admins now restrict the access for sensitive equipment. My work laptop's ethernet has a fully public ip4, for example.

retrac• 3 years ago

In the era of IPv6 you can't assume that your device is implicitly firewalled for incoming connections. My smartphone currently has a public IPv6 address from my relative's home wifi network.

tomrod• 3 years ago

Oh I didn't realize that. How can that be identified and locked down?

irdc• 3 years ago

But have you actually tested connecting to it from outside the network? Just because something has a public IPv6 address doesn't mean there isn't a firewall somewhere in between. It just means there's no NAT.

Roark66• 3 years ago

I wish we lived "in the era of ipv6". Unfortunately one of the biggest mobile providers in my country (and the only one available to me at reasonable speed) has no ipv6 setup. Also, they NAT their entire network.

So, to have any way to connect back to my home network I have to run a permanent vpn to a server in aws and connect to that.

sho_hn• 3 years ago

Probably quite a few people who want to remote-monitor a test setup? The web interface is one of the selling points.

dec0dedab0de• 3 years ago

All the people against NAT/PAT and hyping up v6 as a way to get rid of it.

NavinF2• 3 years ago

That's unrelated. Any firewall can block incoming connections without the massive performance penalty of NAT

starfallg• 3 years ago

NAT is and always was a massive band-aid for the lack of public IPv4 addressing.

1970-01-01• 3 years ago

Exactly! I don't see anything on shodan. (I didn't look very hard, however.)

remram• 3 years ago

I'm a bit confused about the timeline at the bottom, was the vulnerability patched?

Mathnerd314• 3 years ago

It looks like they never replied to him for months so he just published it. This would also fit with the HN title (conclusion in the post). I think if it was patched it would be "I found a bug".

SV_BubbleTime• 3 years ago

This sounds like Rigol and Siglent. Very impressive hardware for the price, questionable support and software.

pmontra• 3 years ago

From the timeline

RIGOL says they would reply in 2-3 days, 1/28/23
Full disclosure, 2/8/23

Those should be January 28 2023 and February 8 2023, which is the date of the post. It's only 13 days after the last communication from RIGOL, not months.

By the way, could at least us developers use ISO dates instead of whatever our local conventions are?

StayTrue• 3 years ago

As a separate issue, it’s strange the firmware pkg is not encrypted.

mardifoufs• 3 years ago

Why is it an issue? Is it to make sure that the right firmware is loaded? I always thought encrypted firmwares were mostly a form of lock in.

m4rtink• 3 years ago

Yeah - if anything, you could sign it and/or checksums it. Encryption indeed sounds like lock-in.

luma2• 3 years ago

Rigol is pretty famous for not really caring a single bit about security. It's helpful in one particular area, in that they sell the device in the OP for anywhere between $900 and $2900 depending on which features are enabled, except all of those features are software locked with the same attention to security as they do everything else.

The result is that you can get a hell of a lot of scope for very little money, but don't expect it to offer things like "robust security".

amelius• 3 years ago

Also don't expose your Xerox printers to the internet (they will auto install user-hostile "upgrades")

ComputerGuru• 3 years ago

Not just that - they can ~all be bricked remotely unless running the latest updates!!

CVE-2022-23968: https://neosmart.net/blog/xerox-vulnerability-allows-unauthe...

fmx• 3 years ago

The timeline of this vulnerability might just be the best argument I've ever seen for full disclosure:

  2019-09-26 Reported to vendor with POC
  2020-01-14 Followed up with vendor
  2022-01-24 Publicly disclosed (still no fix over 2 years later!)
  2022-01-28 Fix released by vendor

I wonder if the same will happen with this RIGOL oscilloscope vulnerability.

chx4• 3 years ago

Here, I have a better, simpler , all encompassing rule: do not expose anything closed source to the Internet.

No, this is not Linux zealotry, I also advocate against using Linux as a daily driver on a modern laptop.

The right tool for the right job: OpenWRT on routers, Windows + WSL on laptops.

But, you are asking, how do you use your Windows laptop like this when away from home?

Easy: GL.iNet has tiny travel routers with OpenWRT supported out of the box.

KeplerBoy2• 3 years ago

Why would you advocate against Linux on Laptops?

If it works just as well and floats my boat, why change to windows?

chx4• 3 years ago

https://news.ycombinator.com/item?id=36678027

rfoo• 3 years ago

Easy: GL.iNet has tiny travel routers with OpenWRT supported out of the box.

It supports modified OpenWRT with proprietary drivers, which are closed source. Still better than completely black-box travel routers but /shrug.

From https://github.com/gl-inet/glbuilder:

Since the driver part uses the driver code maintained by many chip manufacturers, we have no right to open it to users. We have tried to provide it to users in the form of ko, but we will always encounter many strange problems.

matheusmoreira• 3 years ago

I also advocate against using Linux as a daily driver on a modern laptop.

Why would you do that?

chx4• 3 years ago

https://news.ycombinator.com/item?id=36678027

stavros3• 3 years ago

If you're as right about one as you are about the other recommendation, I might have to start exposing closed-source stuff to the internet.

chx4• 3 years ago

https://news.ycombinator.com/item?id=36678027

thefreeman• 3 years ago

Why would anyone who needs to program willingly choose windows + wsl over macbooks

_trampeltier2• 3 years ago

I think such devices anyway have anything lost in a companys LAN. Before such devices had a serial link to a PC. Now every device is in the office LAN. They can never be secure for the many years they are in service.

throwaway9870• 3 years ago

It has been like that since the 90s. At Stanford we had a sysadmin track down a warez site to our HP logic analyzer. Everything at Stanford in the 90s had a public IP address (at least in EE).

kjs32• 3 years ago

Probably an HP 16600/16700[1]. The control processor is basically a repackaged HP-PA workstation running a full version of HP/UX. Used X11 for remote access. The earlier 16500 had an optional, separate equivalent processor.

I have a 16702A, which includes a front panel LCD and keyboard console. It's a beast.

[1] https://www.keysight.com/us/en/product/16700A/logic-analysis...

montzark• 3 years ago

Maybe easy fix would be some certification requirement for routers that by default ports to device are closed even from same network? Some time ago there was issue with default passwords and it got solved with default passwords unique to device.

_trampeltier2• 3 years ago

Such devices can also be attacked in a second stage from a compromised PC or so. Such devices have nothing lost in a production LAN at all.

ChrisMarshallNY• 3 years ago

Awesome detective work!

That's the kind of thing that makes this site special.

hadrien01• 3 years ago

I was very confused by the date format, so here's the timeline with ISO dates:

Vulnerability found, 2022-11-08

Sent detailed PoC, 2022-11-09

RIGOL says they would have contacted me with updates from R&D, 2022-11-09

Follow-up on the vulnerability, 2023-01-25

RIGOL says they would reply in 2-3 days, 2023-01-28

Full disclosure, 2023-02-08

stavros3• 3 years ago

Does this mean they never patched this, then?

psychphysic2• 3 years ago

So odd to list a timeline but not enough detail to work out what happened.

jjoonathan• 3 years ago

This is RIGOL we are talking about. In a year, they will release a firmware that solves the RCE but opens two more and also breaks cursors (or some other very basic thing). A year after that, they will release a second firmware that fixes the cursors but breaks the calibration and still has the two new RCEs.

mensi• 3 years ago

I actually reported the same pair of bugs to them 2021-03-01, so I don't think they're interested in fixing it...

DominoTree• 3 years ago

https://pbs.twimg.com/media/EkUjA7rVoAA6FF6?format=jpg&name=...

cesaref• 3 years ago

Instruments like this normally boot from a read only image, so even if you have root access to the box you can't do anything bad to it, well, nothing that won't disappear on reboot.

On my Siglent scope (an SDS2104X plus) you can easily hack it to enable telnet access. This requires physical access to the device to add a USB stick with a file on it to achieve this, but it's then very open (described here https://www.eevblog.com/forum/testgear/siglent-sds2000x-plus...)

It was actually one of the things that attracted me to this scope, that it was to some extent hackable. Compared to other scopes like the old Tektronix ones running VxWorks it's nice to have something familiar behind the scenes.

LeifCarrotson• 3 years ago

Exactly! A curl 1-liner to get root access to the Linux shell running on my Rigol scope (an older 1074Z-S...do I even have a webserver?)

Think of all the awesome things I could do!

This security vulnerability does not make me worried, it makes me happy. Rigols have always been somewhat hackable, this is an even easier way to do it.

c7DJTLrn2• 3 years ago

How are developers still screwing this up? Is it negligence or stupidity? They shouldn't be allowed to work in industry writing bad code like this.

Security vulns happen, but come on, this is the basics.

epcoa2• 3 years ago

You know how much embedded dev pays? It’s shit. People that are good are usually good enough to go write some Java crud apps and make 3x as much.

Unlike the games industry there isn’t nearly as many people drawn to writing the shitware on a consumer router or cut rate oscilloscope.

c7DJTLrn2• 3 years ago

I have no qualms with "acting your wage." This goes below the minimum bar in my opinion. Real engineers don't get away with fuckups with real consequences because of their salary.

sidewndr46• 3 years ago

As others have mentioned, the pay and the incentives for producing quality embedded software is non existent.

Just last year I casually inspected and found an RCE in a decade old consumer product just sitting there in plain sight:

http://www.hydrogen18.com/blog/hacking-zyxel-ip-cameras-pt-1...

userbinator• 3 years ago

    sprintf(&CMD_BUF,"echo admin:%s > %s",pass1,path);
    system(&CMD_BUF);

You've probably heard of useless use of cat, but this is a useless use of echo. Given that the code even opens the file in question several lines above, I'm surprised that the author didn't know about fprintf.

Const-me• 3 years ago

It seems the device embeds a conventional ARM Linux. If I were developing embedded software for a device like that, I would have used asp.net core runtime.

It’s much easier to create secure web apps using C#, compared to cgi-bin written in C for lighthttpd web server.

qwezxcrty2• 3 years ago

Most test equipments, ancient or recent, are not expecting their programming interfaces, let it be an analog voltage, GPIB, RS232, USB or LAN, exposed to the public internet and it would be a extremely stupid thing to do so. The maker of them assume that if one is able to operate them, one should know where they should plug the cables in.

These equipments are simply assuming that anyone can access the interface is not hostile. This is a pretty good assumption in most lab settings that I know, unless the operator is so ignorant. This assumption certainly have made my life much easier in the lab, of course, where every LXI test equipments are connected to a isolated LAN. I would say a lot more f*k in the lab if I have to authenticate myself before sending a SCPI command. I'm happy that most test equipment makers do agree with me.

For example, modern Rohde&Schwartz gears running Windows or Linux (FSV, FSW, FSVA, FSUP, SMA, SMC, ZNL, etc.) have VNC or Windows RDP enabled by default, and have a weak default password shared among the series. Keysight ones too (E5071C, DSOX3000T, maybe not on by default but with a supported way). A hostile user can even screw up a LAN connected, damn simple VxWorks based multimeter like Agilent 34410A badly by sending the calibration commands at the wrong time or some backdoor commands (DIAG:xxxx, haven't tried but looks possible).

Slightly off topic, some Chinese test equipment makers are making hackability as a feature, look at Siglent or Rigol scopes. They can (and they are competent enough to) lock down the system with secure boot like some Tektronix ones. However they don't, so that people with less budget can buy a cheaper model and hack for the bandwidth.

TheRealPomax2• 3 years ago

Then maybe RIGOL should not make assumptions and not release a device with near-trivially insecure firmware.

jfim• 3 years ago

People don't buy Rigol because they want a secure device, they just want a low cost oscilloscope.

technion• 3 years ago

My issue with these "they don't need to worry about security" issues is that this issue is at its core still an obvious bug. If your password generator puts a ; in your password your attempt to set it will break.

I went through a similar argument with an intranet product that "didn't need to worry about SQL because it's on a trusted network" crashed when Bob O'Reilly tried to make an account.

myself248• 3 years ago

Then it simply should not have a password. If everyone who can access it is benign by definition, simply remove the access control.

Having a password implies that it provides some meaningful security. A bad lock is worse than no lock, because it will lead people to put the instrument in inappropriate places.

Suzuran• 3 years ago

Having a password makes it less likely that the script that your co-worker got in their email and ran behind your firewall will destroy your stuff as a side effect of scanning your network for things it can destroy.

qwezxcrty2• 3 years ago

I agree to some extent, that's why no one put a password to the telnet based LXI SCPI command interface.

But a weak password maybe useful sometimes, to prevent your coworker accidentally connect to the wrong equipment and mess up one's experiment.

Here it's never meant to deter a hostile coworker, in that case one reports to one's superior rather than rely on the password which is always stickered to the scope itself (in my lab).

nimish2• 3 years ago

Lots of these tools have truly awful software engineering. Even companies that are top, premium brands have some really questionable decisions like embedding backdoor passwords in the firmware.

Never connect these things to the internet or any untrusted network. Last thing you need is a 10k instrument bricking itself.

oliv3r• 3 years ago

As most have already written here, this is no suprise. These devices are made to do one job. The whole IoT thing is just cause it something that was hyped. They did try to lock down the scope _a little_. E.g. they removed the incoming RX resistor so you couldn't use the console. They disabled SSH etc. But the scope is very hackable, both in terms of the mentioned unlock ability, but also in terms of accessling Linux. The fact that this is about a RCE, is 'troublesome' but also 'meh'.

I'm mostly disappointment that the author didn't do any research. While I get the cool-factor of trying to hack the firmware from scratch, a simple search would have found the author the EEVblog [0] for starters. But i admit, it is 104 pages atm. And the biggest dissapointment, an obviously shameless plug, is that this 'reversing' of the firmware, was done more then 5 years ago [1] where I wrote scripts to extract the whole firmware automatically.

There's even rumor that the entire source code has leaked onto the internet already.

I would expect some research would have made this 'discovery' less of an 'omg there's an RCE!'

[0] https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso... [1]: https://gitlab.com/riglol/rigolee/firmware/

kriive2• 3 years ago

Hey! Congrats on the reverse engineering work and all the time you put in your research. As you and many other people have already said, RIGOL scopes are not exactly a security fortress, so this exploit I've found isn't impressive at all.

After finding the vuln, I checked online if someone else had already found the vuln, and I admit I have come across the EEVblog, but I didn't find the exact vuln I found (I also must admit I didn't read all the posts there).

I am sorry if I have in some way disrespected your work, but it wasn't my intention at all!

Unauthenticated RCE on a RIGOL oscilloscope

Related Stories