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:
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.
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
No valid address in Flash. Using fixed address
No valid address in Flash. Using fixed address
: cfg1 0x5 cfg2 0x7114
: cfg1 0xf cfg2 0x7214
ATHRS26: resetting s26
ATHRS26: s26 reset done
Autobooting in 1 seconds
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:
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:
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—–
—–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.
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.