Hacking the Rigol MSO5000 series oscilloscopes

[nctnico]

If I wanted to make a product like this with good security, I'd include a random number stored in the device as part of the production process, with a factory database of this number versus serial number, and use that rather than the serial no. for authenticating/decrypting license keys, so the actual serial number bears no useable relationship to the license key.

But that wouldn't stop patching the binaries just like the older Agilent DSO6000 / DSO7000 scopes. I don't think the licensing system is very complicated because it just costs time with very little return.

[lukier]

Dave posted the boot output in another thread.

Code: [Select]

## Loading kernel from [b]FIT Image[/b] at 03000000 ...
   Using 'rootfs@1' configuration
   Trying 'kernel@1' kernel subimage
     Description:  Kerstrel Linux kernel
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x030000f8
     Data Size:    3302448 Bytes = 3.1 MiB
     Architecture: ARM
     OS:           Linux
     Load Address: 0x00100000
     Entry Point:  0x00100000
[b]     Hash algo:    sha1
     Hash value:   bece162e8cad943c68714d8eb8020d68e1db896b
   Verifying Hash Integrity ... sha1+ OK[/b]


Yup, looks like secure boot process, FIT images instead of straight kernel/initrd/dtb, SHA1 signatures. Smart.

[FireBird]

If I didn't miss something, I can see 128 hex characters, which should give only 512-bits. That should make it much easier. 

[mrpackethead]

If I wanted to make a product like this with good security, I'd include a random number stored in the device as part of the production process, with a factory database of this number versus serial number, and use that rather than the serial no. for authenticating/decrypting license keys, so the actual serial number bears no useable relationship to the license key.

That just becomes  obscurity rather than security.   The serial number is just a look up, so they know which public key to use to encrypt the data with.   If you were able to find the public key,  you can't do much useful with it.   I'm picking you want to target the Zync as it whats running linux.   Its certainly got secure boot

If implemented properlhy, this is hard.

[mikeselectricstuff]

If I wanted to make a product like this with good security, I'd include a random number stored in the device as part of the production process, with a factory database of this number versus serial number, and use that rather than the serial no. for authenticating/decrypting license keys, so the actual serial number bears no useable relationship to the license key.

That just becomes  obscurity rather than security.   The serial number is just a look up, so they know which public key to use to encrypt the data with.   If you were able to find the public key,  you can't do much useful with it.   I'm picking you want to target the Zync as it whats running linux.   Its certainly got secure boot

It would prevent a keygen - AIUI the previous riglol hack duplicates Rigol's process for generating a license from the serial number. If the scope's internal process used a key derived from Rigol's serial->key database, then it would not be possible to generate compatible license keys.
Of course there are plenty of other hack avenues, but with a more expensive scope, people will be less likely to want to do anything potentially warranty-voiding.

[iMo]

Hackers of all lands unite! 

[TNorthover]

That just becomes  obscurity rather than security.   The serial number is just a look up, so they know which public key to use to encrypt the data with.   If you were able to find the public key,  you can't do much useful with it.   I'm picking you want to target the Zync as it whats running linux.   Its certainly got secure boot

It would prevent a keygen - AIUI the previous riglol hack duplicates Rigol's process for generating a license from the serial number. If the scope's internal process used a key derived from Rigol's serial->key database, then it would not be possible to generate compatible license keys.

Except that the scope needs to know something about this super-secret key to verify they used the correct one at generation time. At best it's just another public/private layer which doesn't help.

And generating a secure license key is really not the hard part of this problem in the first place. There are a few pitfalls, but realistically just cryptographically signing the serial+feature with an off the shelf algorithm is likely impossible to duplicate. Rigol would hold the private key, and there'd be nothing we could do to replace or discover it.

The hard part is securing the entire boot chain to guarantee all running code has been signed by Rigol (to prevent people bypassing the license checks entirely). Mobile phones have been contending with that problem for the last decade, with limited success. I doubt Rigol will do any better, but on the other hand there are multiple orders of magnitude more people attacking phones so maybe they'll do just well enough.

[tv84]

Let's not be paranoid. The only thing that could stop (meaning: make it sufficiently difficult) an attack is activating secure boot. All other things are within reach.

@lukier, SHA1 is an hash algorithm, not a digital signing algo! The fact that the NAND blocks are hashed doesn't mean much.

I don't think we have reached the secure boot point but, if we did, this is an electronics community forum so, something like this:
How to Break Secure Boot on FPGA SoCs through Malicious Hardware would be possible with the right guys... 

[TheSteve]

Some fun info:
"How to Break Secure Boot on FPGA SoCs through Malicious Hardware"
https://eprint.iacr.org/2017/625.pdf

[lukier]

@lukier, SHA1 is an hash algorithm, not a digital signing algo! The fact that the NAND blocks are hashed doesn't mean much.

Sure, but if they bother to load via FIT then it is very likely that secure boot is enabled, this u-boot is signed and there is a chain of crypto there.

[mrpackethead]

I feel resonably confident that they would have used secure boot.

[tv84]

I feel resonably confident that they would have used secure boot.

I don't. If that was the case, we would be seeing something like the attached pic.

[glenenglish]

There are also a couple of fixed numbers in the system.
The ZYNQ and the Spartan 6 have a DNA number.

I use it to generate MAC addresses in my gear.

Bitstream reverse engineering is "Non trivial"...

If the JTAG pins are available, and the external clocks are stopped, that might be of use.

This is this MFRs 2nd go at this, so they probably have hardened it up.

The other thing is, they might be using  PARTIAL RECONFIGURATION in the FPGA. Would make sense for different bandwidths as the filter structures are quite different for really high bandwidths. Although if it were me, I'd probably leave the filter structures the same for all bandwidths and just change the taps, which could be loaded on the fly, or initialized at load time as initialized block rams. lots of options..

[brainstorm]

I got some firmware from some undisclosed "Address" in the interwebs, please don't ask for binaries and don't tell

I can brief you on some interesting snippets I found after mounting UBIFS mount points and whatnot from the firmware, please notice which binaries are stripped of symbols:

Code: [Select]

tools $ file *
axi:       ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
axi_GP0:   ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
beeper:    ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
cfger:     ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, stripped                 <——— !!!
checkAXI:  ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
checkboot: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
dpuTest:   ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
fram:      ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
socket:    ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, stripped                <——— !!!
spi2cpld:  ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
spi2dev:   ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
spi2k7:    ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
spi2pll:   ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
ssd2543:   ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped
touch:     ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.3, for GNU/Linux 2.6.16, not stripped

Our encrypted targets, which might eventually give access to custom firmware flashing are: fw4linux.sh and fw4boot.sh. You read right, they are encrypted shell scripts.

But how do we decrypt them? Seems like cfger does play a role early in the boot process (and also later on in "application selection"):

Code: [Select]

############################################
#fetch system information from bootloader
############################################
$TOOLS/cfger -i /tmp/sysinfo.txt

Also cfger gets fed by some NAND data, also early in the boot process we can see this:

Code: [Select]

#Read Nand Block 0 data
nanddump -s 0 -l 0x40000 -f /tmp/env.bin /dev/mtd0

So if someone can get such a dump (from the lucky ones having the real device already on their benches), it will inform my analysis. I know this information is rather fragmented and incomplete, but I'm still putting the pieces together and have more juicy bits for future posts.

The application side is fairly huge (21MB), so I'm currently dissecting it section by section, fishing out the interesting regions. It might take some time but we'll get there.

I had a ton of fun last weekend so far and I'll keep digging in the near future, stay tuned

[Agne]

Thank you to all that provided feedback on the press fit pin headers. As a result of your feedback I am looking at alternative connector solutions.

While waiting for my new JTAG programmer to arrive I have been looking at alternative ways of hacking the oscilloscope. I decided to perform a port scan using Nmap to see if Rigol have let any vulnerable ports open. Results of the scan are below

Code: [Select]

Starting Nmap 7.70 ( https://nmap.org ) at 2018-12-03 23:44 W. Europe Standard Time

NSE: Loaded 148 scripts for scanning.

NSE: Script Pre-scanning.

Initiating NSE at 23:44

Completed NSE at 23:44, 0.00s elapsed

Initiating NSE at 23:44

Completed NSE at 23:44, 0.00s elapsed

Initiating ARP Ping Scan at 23:44

Scanning 192.168.2.134 [1 port]

Completed ARP Ping Scan at 23:44, 0.66s elapsed (1 total hosts)

Initiating Parallel DNS resolution of 1 host. at 23:44

Completed Parallel DNS resolution of 1 host. at 23:44, 5.51s elapsed

Initiating SYN Stealth Scan at 23:44

Scanning RIGOL_MS5A********* (192.168.2.134) [1000 ports]

Discovered open port 80/tcp on 192.168.2.134

Discovered open port 111/tcp on 192.168.2.134

Discovered open port 22/tcp on 192.168.2.134

Discovered open port 21/tcp on 192.168.2.134

Discovered open port 5555/tcp on 192.168.2.134

Completed SYN Stealth Scan at 23:44, 0.59s elapsed (1000 total ports)

Initiating Service scan at 23:44

Scanning 5 services on RIGOL_MS5A********* (192.168.2.134)

Completed Service scan at 23:46, 151.31s elapsed (5 services on 1 host)

Initiating OS detection (try #1) against RIGOL_MS5A********* (192.168.2.134)

NSE: Script scanning 192.168.2.134.

Initiating NSE at 23:46

Completed NSE at 23:46, 0.58s elapsed

Initiating NSE at 23:46

Completed NSE at 23:46, 1.04s elapsed

Nmap scan report for RIGOL_MS5A********* (192.168.2.134)

Host is up (0.0025s latency).

Not shown: 995 closed ports

PORT     STATE SERVICE  VERSION

21/tcp   open  ftp      BusyBox ftpd (D-Link DCS-932L IP-Cam camera)

22/tcp   open  ssh      OpenSSH 6.0 (protocol 2.0)

| ssh-hostkey:

|   1024 dc:eb:8b:b2:55:43:48:10:0c:7b:49:70:74:**:**:** (DSA)

|   2048 e4:02:cd:a8:fd:c7:68:54:f4:26:49:0a:50:**:**:** (RSA)

|_  256 6f:c4:43:18:a3:95:f1:88:4f:f1:73:28:39:**:**:** (ECDSA)

80/tcp   open  http     lighttpd 1.4.33

| http-methods:

|_  Supported Methods: GET HEAD POST OPTIONS

|_http-server-header: lighttpd/1.4.33

|_http-title: 400 - Bad Request

111/tcp  open  rpcbind  2-4 (RPC #100000)

| rpcinfo:

|   program version   port/proto  service

|   100000  2,3,4        111/tcp  rpcbind

|   100000  2,3,4        111/udp  rpcbind

|   395183  1            873/udp 

|   395183  1            877/tcp 

|   395184  1            873/udp 

|   395184  1            877/tcp 

|   395185  1            873/udp 

|_  395185  1            877/tcp 

5555/tcp open  freeciv?

MAC Address: **:**:**:**:**:** (Rigol Technologies)

Device type: general purpose

Running: Linux 3.X|4.X

OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4

OS details: Linux 3.2 - 4.9

Uptime guess: 0.015 days (since Mon Dec 03 23:25:16 2018)

Network Distance: 1 hop

TCP Sequence Prediction: Difficulty=259 (Good luck!)

IP ID Sequence Generation: All zeros

Service Info: Device: webcam; CPE: cpe:/h:dlink:dcs-932l



TRACEROUTE

HOP RTT     ADDRESS

1   2.52 ms RIGOL_MS5A******** (192.168.2.134)



NSE: Script Post-scanning.

Initiating NSE at 23:46

Completed NSE at 23:46, 0.00s elapsed

Initiating NSE at 23:46

Completed NSE at 23:46, 0.00s elapsed

Read data files from: C:\Program Files (x86)\Nmap

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .

Nmap done: 1 IP address (1 host up) scanned in 164.92 seconds

           Raw packets sent: 1026 (46.790KB) | Rcvd: 1016 (41.042KB)



Rigol have left the SSH interface open. I can connect to it but unfortunately I do not yet have the root password. Does anyone know of any root passwords that Rigol have used on there scopes in the past?

[Agne]

I got some firmware from some undisclosed "Address" in the interwebs, please don't ask for binaries and don't tell

I can brief you on some interesting snippets I found after mounting UBIFS mount points and whatnot from the firmware, please notice which binaries are stripped of symbols:

Does the firmware file also contain the hashed root password in the /etc/password or /etc/shadow files? If the files are in the firmware could you post them?

[brainstorm]

Yep: root:$1$qC.CEbjC$SVJyqm.IG.gkElhaeM.FD0:0:0:root:/root:/bin/sh

[TheSteve]

Queue John the Ripper

btw, any other userid's in case they prevent direct root login(guess you could also check that if you have the filesystem).

[brainstorm]

Nope, there's only root under /etc/passwd and the sshd_config is all commented out except UsePrivilegeSeparation no directive. Shadow is empty.

Code: [Select]

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# The default requires explicit activation of protocol 1
#Protocol 2

# HostKey for protocol version 1
#HostKey /etc/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh_host_rsa_key
#HostKey /etc/ssh_host_dsa_key
#HostKey /etc/ssh_host_ecdsa_key

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 1024

# Logging
# obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#RSAAuthentication yes
#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

# For this to work you will also need host keys in /etc/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
#UsePAM no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
UsePrivilegeSeparation no
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no
#ChrootDirectory none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem sftp /usr/lib/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server

[0x00000000]> cat /root/etc/passwd
root:$1$qC.CEbjC$SVJyqm.IG.gkElhaeM.FD0:0:0:root:/root:/bin/sh

[0x00000000]> cat /root/etc/shadow
[0x00000000]> cat /root/etc/ssh_config
# $OpenBSD: ssh_config,v 1.26 2010/01/11 01:39:46 dtucker Exp $

# This is the ssh client system-wide configuration file.  See
# ssh_config(5) for more information.  This file provides defaults for
# users, and the values can be changed in per-user configuration files
# or on the command line.

# Configuration data is parsed as follows:
#  1. command line options
#  2. user-specific file
#  3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.

# Site-wide defaults for some commonly used options.  For a comprehensive
# list of available options, their meanings and defaults, please see the
# ssh_config(5) man page.

# Host *
#   ForwardAgent no
#   ForwardX11 no
#   RhostsRSAAuthentication no
#   RSAAuthentication yes
#   PasswordAuthentication yes
#   HostbasedAuthentication no
#   GSSAPIAuthentication no
#   GSSAPIDelegateCredentials no
#   BatchMode no
#   CheckHostIP yes
#   AddressFamily any
#   ConnectTimeout 0
#   StrictHostKeyChecking ask
#   IdentityFile ~/.ssh/identity
#   IdentityFile ~/.ssh/id_rsa
#   IdentityFile ~/.ssh/id_dsa
#   Port 22
#   Protocol 2,1
#   Cipher 3des
#   Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
#   MACs hmac-md5,hmac-sha1,[email protected],hmac-ripemd160
#   EscapeChar ~
#   Tunnel no
#   TunnelDevice any:any
#   PermitLocalCommand no
#   VisualHostKey no
#   ProxyCommand ssh -q -W %h:%p gateway.example.com


[mrpackethead]

I'm trying to work out who the 'newbie' accounts are.  Language comparisons are very interesting.   brainstorm started out well, but is quicky slipping back to their natural writing style.
All good and fun, untill you start selling pcbs

[Dwaine]

 

[glenenglish]

The TAP access on the FPGA is fairly extensive. once the processor is stopped (but DRAM refresh allowed to run) that will enable loading an alternative bitstream for the PL, (while maintaining PS coherence) ... which would permit access via AXI transfers into the memory space .....and  rather personal inspection of memory, trace, all sorts of things, useful if you know something about  linux internals. I guess that would start with trapping where you fail when entering the incorrect feature code.

-glen

[Fungus]

@lukier, SHA1 is an hash algorithm, not a digital signing algo! The fact that the NAND blocks are hashed doesn't mean much.

Yep. It's probably just checking for file corruption, nothing to do with security/secrecy.

[Fungus]

Yep: root:$1$qC.CEbjC$SVJyqm.IG.gkElhaeM.FD0:0:0:root:/root:/bin/sh

I searched google for that string and got many hits, including this page: http://xilinx.wikidot.com/zynq-rootfs

Could it be a default password? 

Queue John the Ripper

No need.

[lukier]

This all sounds so lame it must be intentional  Even pricing-wise the base 70 MHz model is more expensive than Keysight DSOX1000. Hackability as a marketing feature