RIPE NCC is building the largest Internet measurement network ever made. RIPE Atlas employs a global network of probes that measure Internet connectivity and reachability, providing an unprecedented understanding of the state of the Internet in real time. RIPE provide anyone who is interested with a probe that can be connected to a network and sends measurement information to the RIPE cloud. MDSec labs obtained several probes to assess the security of the device in order to determine if it could be compromised and leveraged to attack RIPE and/or customer infrastructure.

A standard methodology was followed to access the device, as shown below. The methodology should serve as a good guide to understanding how to systematically assess similar devices and what types of results can be expected:

Initial Hardware Communication to view the console output

Gaining Interactive Console access gain a root shell

Exploring the Device to determine weaknesses

Conclusions: How can device secrets, data, and trusts be used to compromise further targets?

Initial Hardware Assessment

On arrival the probe was determined to be a TP-LINK MR3020 device, branded with RIPE stickers. These units are a popular hardware choice for projects such as PORTAL as they are inexpensive, highly customizable and well supported with Linux. The device also shipped with a USB drive which when analyzed was determined to have the following file system layout.

[code lang=”bash”]Device Boot Start End Sectors Size Id Type

/dev/sde1 2048 2099199 2097152 1G b W95 FAT32

/dev/sde2 2099200 4196351 2097152 1G 83 Linux

/dev/sde3 4196352 6293503 2097152 1G 83 Linux[/code]

The USB file system of the probe was encrypted and it was not possible to mount the partitions. Port scanning revealed the probe had no real attack surface so instead we decided that a hardware attack would provide the best leverage. Opening the device and reviewing information on the TP-LINK MR3020 it was determined that a UART console was accessible on the board. A 10K ohm resistor had to be connected between pin’s 1 and 4 for access to the console output. Once connected with a FT-232R break out board it was possible to observe the Atlas probe POST and boot-up process. The image below shows connectivity to the RIPE Atlas probe with a FT-232R breakout board and resistor in place to provide a console connection.

Gaining Interactive Console Access

Interactive console access had been disabled in the Linux kernel and it was not possible to interrupt the loaded firmware to launch commands. The U-boot boot loader console however was still accessible by entering “tpl” during initial power on as can be seen here:

[code lang=”bash”]U-Boot 1.1.4 (Aug 17 2012 – 15:21:03)

AP121 (ar9330) U-boot

DRAM: 32 MB

led turning on for 1s…

id read 0x100000ff

flash size 4194304, sector count = 64

Flash: 4 MB

Using default environment

In: serial

Out: serial

Err: serial

Net: ag7240_enet_initialize…

No valid address in Flash. Using fixed address

No valid address in Flash. Using fixed address

: cfg1 0x5 cfg2 0x7114

eth0: 00:03:7f:09:0b:ad

ag7240_phy_setup

eth0 up

: cfg1 0xf cfg2 0x7214

eth1: 00:03:7f:09:0b:ad

athrs26_reg_init_lan

ATHRS26: resetting s26

ATHRS26: s26 reset done

ag7240_phy_setup

eth1 up

eth0, eth1

Autobooting in 1 seconds

hornet>

[/code]

Our initial attempt at compromising the device involved manipulating the environment variables of the booting firmware image, however we quickly found that this capability had been disabled. A cursory analysis of the device revealed that RIPE were using OpenWRT as a firmware base for the probe with packages written for the Atlas cloud. We downloaded the available firmware source code “ripe-atlas-fw-4610.tar.gz” from RIPE and began analyzing it for weaknesses. From the boot process we captured on the UART we knew that this was a 3.3.8 kernel. Through a process of trial and error, we created an identical kernel image using OpenWRT kernel source for a TP-LINK MR3020 and mirrored the kernel configuration in use by the RIPE firmware to generate a custom kernel image that instead of booting into the RIPE firmware would launch a “busybox” shell so we could further probe the device and its contents.

Our custom kernel image is then provided to the “tftpboot” command, U-boot attempts to download an image into RAM with the MAC address of the device and boot. This is shown in the image below:

[code lang=”bash”]c8f526f2ce89117e4009866b3383c1f6 6F01A8C0.img[/code]

Using our custom kernel image we then booted the device via “tftpboot” from the U-boot console, effectively allowing us to gain access to the FLASH firmware file system used by RIPE for the Atlas probe with root privileges to explore further into the OS. The screen shot below shows root access being obtained:

Exploring the OS

From this vantage point we are now able to continue manipulating the device and launch the RIPE Atlas cloud applications to determine more about the device and its operation. We found that we must call the following scripts to complete the initialization process to access the Atlas probe with root privileges and that the “preinit” script must be called to obtain the USB encryption keys and start the USB devices:

[code lang=”bash”]/etc/preinit

/etc/rc.d/S05defconfig start

/etc/rc.d/S10boot start

/etc/rc.d/S11ubus start

/etc/rc.d/S15lvm2 start

/etc/rc.d/S16setupcrypt start

/etc/rc.d/S19leds start

/etc/rc.d/S20fstab start

/etc/rc.d/S21mountatlas start

/etc/rc.d/S22network start

/etc/rc.d/S23startatlast start

/etc/rc.d/S39usb start

/etc/rc.d/S50cron start

/etc/rc.d/S60ntpd start

/etc/rc.d/S95done start

/etc/rc.d/S97watchdog start

/etc/rc.d/S98sysntpd start

/etc/rc.d/S99atlasusb start

/etc/rc.d/S99sysctl start[/code]

We could now extract information from the device to target the RIPE Atlas infrastructure. The device was discovered to use an unprotected SSH private key to connect to RIPE servers for the purposes of firmware updates. Discussion with RIPE has indicated that firmware updates are signed using RSA keys before being applied to devices. Additionally this level of access now allows an attacker to access the USB encryption key used for accessing the firmware filesystem. The output below shows that we now have the encryption keys for the USB device found to be using Linux DM-CRYPT.

[code lang=”bash”]/home/atlas/etc # ls -al sda*

-rw-r–r– 1 root root 512 Jan 1 00:01 sda2.key

-rw-r–r– 1 root root 512 Jan 1 00:01 sda3.key

/home/atlas/etc # ls -al probe_key

-rw——- 1 root root 1675 Jan 1 00:01 probe_key

/home/atlas/etc # cat probe_key

—–BEGIN RSA PRIVATE KEY—–

MIIEowIBAAKCAQEApvEP/UVPQOGsDgxymByyNv6dnMA7KxgqsT6UZQtPP5Zac+DY

JqoHTsSWlsWKpzMcWmObtRD52qxdgQJ8VxzbmuCIoOVFlBb8pvQtRBZz0WPpOFd0

0uiPc3tO6ZnZ3+4Eg34iNWwHAATibypmPGqgMH5QiiYm07CDX8PNR4pnOs9ESp4e

H/+IWUJvxoIjSFVy/xtz/KVFf4BATiblnM5ESPLA+2Ai1suCaArDkrHRfmwQ/Ifv

22ktMqH4LZtDQCh6m+B5WVPIUi3Xb/A7Fb2FB6alp4aDrKIK3aZ2LliR0VvAcFtT

QJCNL1pP/ES4bNDl+PWBQmTqMThUcDvVOFh3ewIDAQABAoIBADJy9O8H6/xidllE

f7jiKyUdasn8+aR7SCOKEtQ6R7eimzEbiJaemVi/ZfaoOc9vTakvItXkDG192z/q

XWMB8IdsRT3CK3WmQLG/ZpKF6ngjpk4Fd+Norjkq0V0cxk+6oRiPnIziWXczAq6v

dHfbjQ86jOJCx0b/t6PQCxAMjkeh8D3DT+qLuFC0vxb9llgs/SihcLkrbMj0tjMR

Q/mCmGniI87KM/uV+kyYYnVMnbG9S9l8p0AdLbMxE13I7kAZYNqmQklEgv6lkImb

AFN52G+/8lE2RQ5pR1Um0zNAL80Q4N81qxoA8cTBdPEQIDEVGqkmwffDgJBvWnSF

op2q5+ECgYEA0gfz7bmakyaJX7nLvROEuLR06zatqExb6jFpa2hhZr1/kiQrJXbj

dQUNSph+ChQsuTTNkx3eqeNvMjZI1mqCYZ6FuQWRXtQAZYjCcmciJvuKflNsQbQ/

/YJMxDx0HkLfhngewnBHxmuTKHJZTZoN5I9MuKpd8Rt7knFxNFfOECsCgYEAy3rO

7dHhBgxU8Lhpwak5DKKkp8mzcVmJ64bvNAhDN/6w9eBlsq2HG8qzImCGFD4k2Y9x

CUr/e6Oy3O/9NBAk1oK/6UUhOJrGjSYfI71hDybtMUeOhhuC+mOHz4THXf4hquCd

Hny0OHP7j3uv6lyZ4NKqOtB+tym417ZuMU8DPfECgYAUHcjiOwWwFF/R+FSoPmdW

3YnZQXpuhSnEi4kCTZQOqBXA5I/xXaq5eYtlWqevxXDnKESMU68Q7ISo9YQSbU8h

lHJQX1UmFP4Yu3mMRY6C11LTeKAExwPd/w3lObkRcOxBz916WBC303Pbyt/8y8WK

36LEiSTIRA6Y3x6tmb9V0wKBgQDIGTzlIj/ncrkVAET/7SntAwRo/DE6hpLayxbw

VC/GIPBk2wcnbv4ulmcSp1kzDumuCSFfwiD7tT9vhZG6YSXYzTtsak8BGzOmGpcE

zndkLyOSEoxV1Tg4gyhLKofkJsV1BO19zaRs36HCuB+GmQm5zXEZ5W63MJBVkVFL

rCfEAQKBgCslRgbcoGvtKTbM1xHhydV9+Lx2ARBALSRCbcllieyeuz9hCnU6whOT

4LU51cQ42T6etOoEQfiBrnnBFA6wH4UvaiKrYfUNP5HpyfAQdwNcn65ePvRQWsib

4AQm30G0sHYZss6YQwibpNuPnohGLWvo9u4i3ykw2CEi10QSYGJI

—–END RSA PRIVATE KEY—–[/code]

It was discovered that each device had a unique key and that although we had discovered sensitive information which could be used to access RIPE infrastructure it did not appear to be a shared secret across multiple devices. We were unable to assess the impact of obtaining the SSH private key as we did not have permission to assess the cloud infrastructure.

Conclusion and Next Steps

We have shown how an attacker can assess software devices to bypass security controls and extract sensitive information such as encryption keys and authorization tokens.

We have since submitted these findings to RIPE, in accordance with our responsible disclosure policy, to ensure that there is no impact on RIPE infrastructure or its customer base as a result of this research. Discussions have indicated that back-end mitigations are in place to prevent exploitation of the probe keys by malicious parties and that RIPE have accounted for this level of access within its security model. The probe used for the assessment (and hence the private key shown in this post) has since been blocked from accessing the RIPE infrastructure and is unable to function with the Atlas cloud.

Further, if a secure boot process had been used that validated booting kernel image as being signed by RIPE then this attack vector would not have been viable. MDSec contacted RIPE to share our findings with them before releasing this blog post.

If you’re interested in obtaining your own Atlas probe, then you can apply for one here.

This blog post was written by @hackerfantastic.