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.
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
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:
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>
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:
c8f526f2ce89117e4009866b3383c1f6 6F01A8C0.img
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:
/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
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.
/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—–
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.
Source:https://www.mdsec.co.uk
He is a well-known expert in mobile security and malware analysis. He studied Computer Science at NYU and started working as a cyber security analyst in 2003. He is actively working as an anti-malware expert. He also worked for security companies like Kaspersky Lab. His everyday job includes researching about new malware and cyber security incidents. Also he has deep level of knowledge in mobile security and mobile vulnerabilities.
