Hacking the Rigol MSO5000 series oscilloscopes

[borjam]

I think its pretty certain that the scope phones home everytime it can.

One thing it does in that phone call, i think, is to send a RSA encrypted pack that contains some relevant data from the /data dir. Personal data: keys, licenses,etc

If someone wants to put a wireshark to work we can verify this info.

Mabl, no pissing contest here, but i released the SCPI commands in the general Rigol all SCPI commands thread. I'll try and check with yours.

Curious. At least I haven't observed anything of the sort with a DS1000Z, SDS1202X-E nor a SVA1015X (and I keep a year worth of Netflow data for my home network).

Phoning home would be quite rude.

[tv84]

Phoning home would be quite rude.

I raised this question from the very beginning.

https://www.eevblog.com/forum/testgear/hacking-the-rigol-mso5000-series-oscilloscopes/msg2073469/#msg2073469

At the time few people had the scope so the matter went to sleep.

Then I just saw the email thing, later I saw the RSA package upload....

When people started reporting the "bug" of the delays in booting up when connected to the net, I immediately started thinking that it was a "feature" and not a "bug". I confess that I never investigated thoroughly... It was just a hunch until a few days ago.

I hate something like this and specially when it's done by the same guys who are able to create the SMTP vulnerabilities that we saw in the last few days...

Deeply worrisome!!

I've done plenty of assembly analysis on all those equipments and never saw this in any of them.

This is a thing that I think can be seen in the new Rigol line of equipments: MSO5000,7000 and for sure the 8000. I think it's also in the RSA3000/5000 (but this one I would need to recheck).

[borjam]

Phoning home would be quite rude.

I hate something like this and specially when it's done by the same guys who are able to create the SMTP vulnerabilities that we saw in the last few days...

Deeply worrisome!!

With all the paranoia about Chinese equipment with backdoors it's extraordinarily dumb to do something like that.

If they are deeply worried about hacking, well, it's not that hard ot make it much more difficult. I can even imagine that they somewhat tolerate some hacking activity in the lower end.

I recall that Siglent dropped an automatic firmware version check from the SDS1202X-E and I wouldn't be surprised if that was the reason.

So is it really just an RSA encrypted packet? If it connects using SSL/TLS it could be possible to try to intercept it. Maybe they won't actually check the certificate (or it's possible to replace certificate trust settings on a firmware file).

[delfinom]

With all the paranoia about Chinese equipment with backdoors it's extraordinarily dumb to do something like that.

If they are deeply worried about hacking, well, it's not that hard ot make it much more difficult. I can even imagine that they somewhat tolerate some hacking activity in the lower end.

Most of the backdoors I have seen even in examples of the "backdoored" Chinese equipment can be described by Hanlon's razor just like in Rigol's smtp case.

Never attribute to malice that which is adequately explained by stupidity

People get paranoid because of the "Chinese" boogeyman (not to say there isn't a threat), but I've seen as equivalent stupidity from American equipment vendors, even big names like Cisco are part of it like this, or this, or this, or this (suspicious they keep leaving these backdoors eh?)


Just reinforcing the point that you can't trust any piece of networked hardware from any vendor anywhere in the world.

So is it really just an RSA encrypted packet? If it connects using SSL/TLS it could be possible to try to intercept it. Maybe they won't actually check the certificate (or it's possible to replace certificate trust settings on a firmware file).

SSL/TLS 
No, they are posting it over http.

[tv84]

So is it really just an RSA encrypted packet? If it connects using SSL/TLS it could be possible to try to intercept it. Maybe they won't actually check the certificate (or it's possible to replace certificate trust settings on a firmware file).

The info seems to be packaged and then encrypted with the RSA pubkey. It's not a big deal since we can intercept the info buffer (in realtime) before the encryption and see what is being packaged.

It's mostly info from the /data dir. But this is from what I've seen. There could be other info exchanges that I didnt notice.

[borjam]

Most of the backdoors I have seen even in examples of the "backdoored" Chinese equipment can be described by Hanlon's razor just like in Rigol's smtp case.

Never attribute to malice that which is adequately explained by stupidity

I know, that's why I said "paranoia". That said, lousy security can be a very serious problem in some environments.

People get paranoid because of the "Chinese" boogeyman (not to say there isn't a threat), but I've seen as equivalent stupidity from American equipment vendors, even big names like Cisco are part of it

Of course. Getting it right in a big company is very hard. Especially when everything was just soooo coool, dude, in happiest times! Straightening poor practices inherited from the past is really difficult.

Just reinforcing the point that you can't trust any piece of networked hardware from any vendor period.

And indeed you are right. My commment deals with the trust problem that these new manufacturers can face. They are newcomers, they are beginning to sell somewhat mature products and nowadays people pays much more attention to this crap than 30 years ago.

[delfinom]

Of course. Getting it right in a big company is very hard. Especially when everything was just soooo coool, dude, in happiest times! Straightening poor practices inherited from the past is really difficult.

Well, I don't see it as an issue about getting it right at a big company. It's the year 2019. A "big company" not auditing it's releases and processes at this point is committing willful negligence at this point (or if I continue my rant about Cisco, increasing outsourcing their development to a patchwork of lowest bidders/it doesn't take "a change in company practices" to learn how to grep your update packages for ssh keys before release).


The optics are just against new/smaller manufacturers like you say.

[Sighound36]

Unfortunately a lot of large corporate entities are very much in big company mentality of the left hand is not knowing what the right hand is doing.

In this case Rigol should take a very seriouy look at the cyber security dept and kick a few backsides as this is a fundamental faux par of large proportions. The possibility of looking in on any of Rigol's personal and private files even for a brief period is pretty grim, as a customer it certainly does no favors for their brand image or credibility in the market place, which is a shame.

Looking to trade up to an MSO 8000 very soon, maybe not so sure now 

[tv84]

Loss of trust is infinitely more damaging than any "hack"... 

Definitely this is a top management matter.

[Martin72]

I didn´t see a reason to connect my scope to lan at home, at work I would be "killed" for if I connect anything else to lan as my authorized notebook.
So I don´t have problems with things who want to phoning home...they couldn´t.
Or:

Do anyone have a fire-tv stick from amazon ? Or a pc connected to lan ? Or alexa ? Or home automations ?
So why worrying about a scope….

[Shodge]

As a FYI, if you are using a somewhat modern router, it is pretty easy to set up a rule to prohibit the scopes nic from going through the router.  You can still access it on your lan, but it can no longer 'call home'.

DD-WRT (router firmware) calls this 'Access Restrictions -> Wan'.


-Stan

[PA0PBZ]

Or just set a fixed IP and leave the gateway out.

[Xtremexp]

Does this enable all features?

Thanks.

[tv84]

Here's a new bspatch that should disable two callbacks to rigol. But I could only test that it stopped storing the response in /tmp/firmware.xml right now.

delfinom, what about disabling email capabilities?

sub_273B50
sub_2745AC

[delfinom]

Here's a new bspatch that should disable two callbacks to rigol. But I could only test that it stopped storing the response in /tmp/firmware.xml right now.

delfinom, what about disabling email capabilities?

sub_273B50
sub_2745AC

May be better to just nuke the smtp client at  /rigol/mail/bin/msmtp
I like how in the invocation they are turning off tls.

273B50 creates the config file for it.
2745AC sends mail using it

[tv84]

My analysis (FW v00.01.01.04.08):

sub_273B50 - load_mail_config_vars
/rigol/mail/etc/Muttrc
/rigol/mail/etc/msmtprc

sub_2745AC - send_mail_test
/rigol/mail/bin/msmtp

sub_274B70 - send_mail
/rigol/shell/send_mail.sh (uses /rigol/mail/bin/mutt)

It seems they use it to send system logs and/or screen snapshots of the scope. Let's assume that with our previous authorization.

To stop mails from the MSO5000:

Option 1
Delete/rename files:
/rigol/mail/bin/msmtp
/rigol/mail/bin/mutt

Option 2
Patch appEntry (sub_275A08):
offset 0x26DA08 - patch: 00 48 2D E9 -> 1E FF 2F E1

[tv84]

I just got an email from someone (who is not anonymous) that claims to have cracked the scope and is seeing performance up to 1GHz after setting the front end chip to 4GHz bandwidth.

I will have a new look at this claim in the coming days. I have a "feeling"...   

Edit1: I'll start by recreating what is shown in this image. (And, yes, I believe it's a real image...) It should be pretty easy to do (although not by everyone).

These asiatic forum members are extremely volatile and that's why this line of thought has been kept buried somewhere! I'll try to dig it up in plain english... 


https://www.eevblog.com/forum/testgear/rigol-mso5000-upgrade-to-500m-bandwidth/msg2316924/#msg2316924

I will then need some external help to test the performance. But that should be easy for some of you guys!

Once we do this step, we step up the game...

Let's see where we'll end.

(Of course, let's hope all of this may be extendable to the 7000, 8000 series.)

PS: And, all in "feature" mode. No "patches" or "hacks".   

[luma]

That last thread left off with a suggestion that this was an April Fool's thing.  Do we have reason to think the front end on these devices can function past 500MHz?

[Noy]

Maybe. Same chip like mso8000 but IT will not be interesting because of the missing 50Ohm input. 500MHz is max what can be done with passive probe.

[tv84]

So, as promised, here is the replication of that accomplishment. And, I will not disappear in the myst...

The tests (done by another forum member) with the new FW version still continue.

But, at first sight, it seems that the BW limit of the MSO5000 is definitely near the 500MHz mark and doesnt go further:

To be continued...

[TK]

But, at first sight, it seems that the BW limit of the MSO5000 is definitely near the 500MHz mark and doesnt go further:

Maybe the lack of 50ohm input?

[NoisyBoy]

tv84,

That’s an excellent update, can’t wait to learn more. 

Even if we don’t use all 500MHz, just not having the -3dB drop at 350MHz is a welcomed enhancement.

I agree that not having the 50 Ohm input would limit how high we can go on the hardware without modification.

Have you had a chance to check if heat on the front end increases with the update and how well the existing cooling handles it?

[thm_w]

tv84,

That’s an excellent update, can’t wait to learn more. 
Even if we don’t use all 500MHz, just not having the -3dB drop at 350MHz is a welcomed enhancement.
I agree that not having the 50 Ohm input would limit how high we can go on the hardware without modification.
Have you had a chance to check if heat on the front end increases with the update and how well the existing cooling handles it?

Its already been measured at 450-500MHz prior to modifications tv84 is currently working on: https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/
What he could unlock is possibly  >500MHz or >8Gs/s, the second of which would increase power consumption.

[nimish]

tv84,

That’s an excellent update, can’t wait to learn more. 
Even if we don’t use all 500MHz, just not having the -3dB drop at 350MHz is a welcomed enhancement.
I agree that not having the 50 Ohm input would limit how high we can go on the hardware without modification.
Have you had a chance to check if heat on the front end increases with the update and how well the existing cooling handles it?

Its already been measured at 450-500MHz prior to modifications tv84 is currently working on: https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/
What he could unlock is possibly  >500MHz or >8Gs/s, the second of which would increase power consumption.

Is > 8GS/s needed at 500MHz max BW? It looks like the hard analog bw 3dB point is 500MHz, which is likely limited by the actual frontend. So with 4x oversampling that's 2GS/channel and that's enough for 500MHz I guess. But I am not an expert.

[NoisyBoy]

thm_w, thanks for pointing that post out. 

Do you happen to know what "correction of the measuring path" means in graph 4.1 for the MSO5000?  In the MSO4000, I believe they upgraded the heat sinks for the FPGA and ADC, I wonder if they perform the same hardware upgrade in the MSO5000 to get this "correction".

I ask because without this correction, it is -2.2dB at 350MHz, vs. -0.6dB with correction, that's a meaningful difference.  And without this correction, the -3dB point is about 450 MHz.

But if tv84 can perform his magic, I would gladly take the extra 100MHz bandwidth 

Its already been measured at 450-500MHz prior to modifications tv84 is currently working on: https://www.eevblog.com/forum/testgear/review-rigol-mso5000-tests-bugs-questions/
What he could unlock is possibly  >500MHz or >8Gs/s, the second of which would increase power consumption.