EC 521 Group 3 - Raspberry Pi 3B Security Assessment

Background

High-level Description

This project is a security assessment on the Raspberry Pi Model 3B. We are group 3, and our group consists of four members: Joshua Bassin, Ashley Cui, Kaitlin Walsh, and Hang Xu.

We have looked at multiple areas of the Raspberry Pi to assess security faults and how they could be exploited. These areas include the hardware of the Raspberry Pi, the default Raspbian OS, and the Raspberry Pi's Bluetooth interface.

Device Usage

The Raspberry Pi is a popular single-board computer that is used for a wide variety of applications. It is affordable and portable, making it a popular choice when developing IoT devices and maker projects.

What inspired this assessment was a recent news story about how a Raspberry Pi left NASA open to a cyber attack.

References

Raspberry Pi's page listing common ways to secure a Raspberry Pi. This served as our starting point for assessing vulnerabilities.

Technical Content

Specifically, our group focused on different surfaces of the Raspberry Pi that could be vulnerable to attacks. We started by investigating the hardware of the Raspberry Pi, and determined vulnerabilities in the commercial hardware components that make up the Raspberry Pi. Environmental vulnerabilities were also briefly investigated. For the OS layer, we looked into the gaps between Raspbian and upstream Debian vulnerabilities. Finally, this assessment covers BlueTooth attacks that can be performed on the Raspberry Pi.

Limitations

The environmental hardware exploits are theoretically possible, but we do not want to do physical damage to our Raspberry Pi. Therefore, we cannot verify the attacks ourselves. The GPU side-channel attack has not been implemented on a Raspberry Pi yet, and our group did not have enough time to develop this attack.

Some attacks are supposed to be performed over a long period of time. In other words, given the limited time we have for this security assessment, we cannot verify these types of attacks.

A limitation about Fail2ban is that it does not support IPv6 networks in the default version installed through apt. If you want to use IPv6, you will need to install version v.10 or higher from the source. Please see here for more details.

Note: Fail2ban and apt are further explained in the later sections. Please read the Materials first.

Results

Our group accomplished what we believe to be a comprehensive security assessment of the Raspberry Pi for the time that was given.

Materials

Security Assessment

Our group performed a multi-level security assessment on the Raspberry Pi. This includes assessing the hardware, the default Raspberry Pi OS, and the Bluetooth protocol included on the Raspberry Pi 3B.

Hardware

Most hardware attacks on a Raspberry Pi rely on having physical access to the device. Mitigating many of these vulnerabilities could be as a simple as putting the device in a place where it could not be accessed by attackers. The hardware specifications of the Raspberry Pi 3B are listed here.

Environmental

Having physical access to a Raspberry Pi opens up many vulnerabilities with the hardware. While trivial, it is important to mention them in the context of a comprehensive security assessment. The first, and perhaps the most obvious, is that damaging the Pi can interrupt any services running on it. This brings us to a philosophical question: “Is smashing the Raspberry Pi with a hammer considered a DoS attack?”. Trivially, yes! The Pi is also vulnerable to short circuiting if it is exposed to water. These risks can be mitigated by using a strong, waterproof enclosure to encase the Pi.

The Raspberry Pi boots from an OS loaded onto the microSD card that is inserted into the Pi. With physical access, an attacker could swap the SD card with their own, malicious OS loaded onto the new SD card. Again, this vulnerability can be mitigated by limiting physical access to the Raspberry Pi.

The Raspberry Pi 3B is powered by a 5V, 2.5A power source connected to the Pi by microUSB. Interrupting power service to the Raspberry Pi could cause an improper shutdown during a write operation to the SD card, which would corrupt it. The SD card would need to be re-imaged after such an event. This opens up an exploit to attackers where they could cause a lengthened denial of service by cutting power to the Pi or the area in which it resides. Limiting writes to the SD cards lessens the chance of this corruption happening, but does not completely eliminate the chance it could happen. Some ways to limit SD writes are to disable swap memory and move logs to RAM. In addition to power loss, powering the Raspberry Pi with a source that emits more than 5V could damage or destroy the Raspberry Pi.

One of the more interesting trivial vulnerabilities is the Pi's operating temperature range. The Raspberry Pi 3B has a general operational temperature range of 0 degrees C to 50 degrees C (122 degrees F). The SoC has a slightly larger range, -40 degrees C to 85 degrees C(185 degrees F). When the operating temperature of the Pi closes in on this upper range, the Pi dynamically throttles the clock frequency and the power used by the processor and the GPU to reduce the amount of heat being produced. If the Pi continues to overheat even through all of these mitigation methods, then an emergency thermal shutdown is performed. According to the creators of the Raspberry Pi, since the device runs at a lower frequency for most processes, the device should not overheat for the typical user. However, the Raspberry Pi's clock frequency increases to 1.2GHz when performing heavyweight processes, such as AI applications. In these applications, this prolonged demand on the CPU can be enough to push the Pi outside of its operating temperature range.

The following picture is a thermal image of the Raspberry Pi taken by Gareth Halfacree, author of the Raspberry Pi User Guide. Here we can see the CPU reaching a temperature of 97.3 degrees C, well outside of the operating temperature range of the Raspberry Pi. This image was taken during a CPU benchmark test that verifies prime numbers through division.

A benchmark test is hardly considered a typical use case for the Raspberry Pi, but Microsoft AI researchers observed a similar phenomenon when running a compute-intensive AI process on their device. These researchers came up with a few cooling solutions to solve the overheating problem, which involved installing a heatsink and a cooling fan on the Raspberry Pi. The results are summarized by the graph below, which can also be viewed in the resources folder.

In summary, the Raspberry Pi 3B is prone to overheating when performing compute-intensive processes for an extended period of time. Potential risks of overheating the Pi to this degree are singeing the microSD card, causing a corruption of data, melting the Raspberry Pi, and potentially causing a fire. Mitigating these risks requires installing both a heatsink and a cooling fan on the Raspberry Pi.

Components

Since the Raspberry Pi is a system built from commercial components, non-trivial hardware vulnerabilities of the Raspberry Pi 3B arise from the vulnerabilities in the specific hardware components that make up the system. Attacks using these vulnerabilities tend to be more involved than the attacks mentioned above, so there is already an upfront skill barrier required to utilize these vulnerabilities.

The Raspberry Pi 3B has multiple hardware components on board. The System on Chip (SoC) is a Broadcom BCM2387 chipset, with a quad-core ARM A-53 processor. It has 1GB of LPDDR2 SDRAM for memory. The GPU on the Raspberry Pi 3B is a Broadcom VideoCore IV.

The main non-trivial hardware vulnerability in the Raspberry Pi is a side-channel RowHammer attack. RowHammer attack vulnerabilities are caused by the density of DRAM cells in memory. Because of this increased memory density, memory cells can leak their charge to adjacent memory cells, adversely affecting them. Therefore, through repeated and targeted memory accesses, an attacker can change the value of certain memory cells without directly accessing them. Due to their nature of execution, RowHammer attacks require direct access to physical memory, either through DMA infrastructure or by using cache-flushing operations. Researchers from Google Project Zero have show that RowHammer attacks can lead to privilege escalation, allowing user-level programs to attain kernel-level privileges. For a more in-depth look at RowHammer attacks, feel free to read this white paper.

Normally, memory managed by an ARM processor is not vulnerable to RowHammer attacks because cache-flushing operations are privileged by default. However, the GPU on the Raspberry Pi has DMA infrastructure, which allows it to bypass the cache and directly access memory. This, combined with high precision timers from the WebGL JavaScript library, allows an attacker to theoretically perform a RowHammer attack on a Raspberry Pi. One way to guard against RowHammer attacks is to increase the memory refresh rate, but this also increases the power consumption of the device. This is not an ideal solution for the Raspberry Pi, since it is often used in IoT applications, where power conservation and low power operation are important. However, the side channel attack mentioned above hasn't been tested specifically on a Raspberry Pi. ARM has also looked into this vulnerability, and have said that it would be difficult, if not impossible, to implement in a way that would cause meaningful damage.

In the interest of thoroughness, it is also important to briefly mention potential attacks that the Raspberry Pi is not vulnerable to.

For vulnerabilities in processors, Spectre and Meltdown come to mind. These vulnerabilities exploit the speculative execution on processors to either “melt” security boundaries to get access to protected areas of memory, or to make a program reveal some of its own data that was meant to be kept secret. Fortunately, the Raspberry Pi has an ARM A-53 processor, which is not listed as one of the processors that is affected by Meltdown and Spectre.

The Broadcom chipset is listed here as having a vulnerability that would allow a user to execute arbitrary code over WiFi. It is unclear whether or not this affects the Raspberry Pi since the specific chipset that the Pi uses is not listed. However, this vulnerability has been patched.

OS

The default operating system on Raspberry Pi is Raspbian, which is downstream from Debian. Thus, Raspbian is vulnerable to Debian-based attacks. It also means that patches in Debian are delayed in getting vendored into Raspbian, which means Raspian may be vulnerable to old attacks.

Scanning and SSH security

Note: Installation details are at the end of this report.

For assessing the Operating System, we started with a vulnerabilities scan via a tool called lynis. Its scanning is modular and opportunistic, which means lynis will only use and test the components that it can find. It is open source and free to use. We installed lynis on one of the Raspberry Pis we have and ran the audit. The audit results are attached here.
From the output, you can see it has 38 suggestions on different areas such as “Users, Groups, and Authentication”, “File System” and etc. Among all of these suggestions, we think the most important ones are on “SSH Configuration” since SSH is the most common and popular approach to login to a Raspberry Pi when using one as a server. One of our Raspberry Pis has a default OpenSSH6.7p1 sshd version. After checking the Openbsd Openssh : CVE security vulnerabilities, versions and detailed reports about OpenSSH_6.7p1, we have found it is a vulnerable version that has numerous flaws. The OpenSSH official website(OpenSSH: Security), has acknowledged that there are versions of OpenSSH (between OpenSSH 5.4 and 7.1) that are vulnerable to information disclosure. This information may allow a malicious server to retrieve information including, under some circumstances, a user’s privacy keys. The suggestion from lynis is to add the undocumented configuration option UseRoaming no to ssh_config. This bug has corrected in OpenSSH 7.1p2 and in OpenBSD’s stable branch. Here are the CVE details about these bugs: CVE -CVE-2016-0777, CVE -CVE-2016-0778.

Another way to improve the SSH security is to add AllowUsers alice bob into the /etc/ssh/sshd_config. Through allowing only specific users, it can strengthen the security of the SSH connection. In addition, using key-based authentication is better than the password-based. Since the public key and private key cryptographically linked to each other, it is almost impossible to reproduce the private key given the public key if the key is long enough (e.g. 4096 bits). The only change to make it key-based is to add PasswordAuthentication no in the sshd_config file.

Next, we used nmap to gather more information about the Raspberry Pi (results: link). From the scan output, we can see that by default, only TCP port 22 is opened for SSH. The scan also shows the MAC address of the Raspberry Pi. (Note: for the type of nmap scan we have run, please refer to the above attached result file)

We also used another audit tool called nessus. It is proprietary software, but it has an education program allows us to try using the service. We installed the software on a Kali machine that is under the same subnet as the Raspberry Pi, and we ran the software. The result is attached here.

Among all these scanning results, there are a few important changes that the owner of a Raspberry Pi should consider. First of all, all Raspberry Pi comes with default user as pi and default password as raspberry, which means it is very crucial vulnerability if the Raspberry Pi has exposed to the Internet. In addition, the pi user has the sudo privilege so it could be very damaging if it is compromised to an attacker.

Next vulnerability is the sudo does not require a password by default. To strengthen the security of a Raspberry Pi, it is recommended to set sudo to require a password. For example:

$sudo vim /etc/sudoers.d/010_pi-nopasswd
# and change the pi entry to:
pi ALL=(ALL) PASSWD: ALL

Installing a firewall is another effective approach to secure a Raspberry Pi since it can filter unwanted network packets. The iptable is installed by the default on Raspbian, but it is not setup. A simpler to use tool is called ufw which stands for “Uncomplicated Fire Wall”. It can be installed via apt. A good practice is to maintain a whitelist of IP addresses that is trustworthy and only allow the IP addresses from the list to send packets to the Raspberry.

If using the Raspberry Pi as a server, it is important to prevent someone from trying a brute-force attack to obtain login credentials. A useful tool is called Fail2ban, which is written in Python, and it is a scanner that examines the log files within the Raspberry Pi. It also checks the suspicious activity such as fail to login for plenty of time. Eventually, it catches the brute force attempts from a specific IP address or many addresses and reject any incoming traffic from these addresses in the future.

Pre-installed packages: APT

APT: Advanced package tool, is a pre-installed package manager that is developed by the Debian Project. Apt works by fetching packages over HTTP to a remote repository based on the current operating system. For raspberry pi, this repositiry is located at raspbian.raspberrypi.org and archive.raspberrypi.org.

Diagram of regular usage:

In order to set up this attack, you would have to start a man-in-the-middle server, and change /etc/hosts file so that raspbian.raspberrypi.org resolves to 127.0.0.1, where your local attack server lies. This server would pass most instructions to the real raspbian.raspberrypi.org repository, except for a few key operations where the data is manipulated for the attack.

Attack

If you were to issue a

sudo apt-get update
sudo apt-get install [package]

Apt would first update its current database of packags through the update command. It does this by pulling a release.gpg into /var/lib/apt/lists/ In this attack, apt will send the request to pull the release.gpg to the malicious server. The malicious server would forward this request to the real repository, and obtain the real release.gpg. Then, because the location of release.gpg is known, the malicious server can inject bad.deb before the pgp signature, because anything before the signature is ignored by apt

<bad.deb contents>
-----BEGIN PGP SIGNATURE-----
...
-----END PGP SIGNATURE-----

Apt-get install [package] will then request a package from a online repository with specifications, and fork a child process that will respond with the current HTTP status, hereafter referred to as the fetcher. If the status is a 103 redirect, then the parent process looks at the response to see which resource it needs next, possibly as a dependancy for the pacakge. However, this input of the 103 redirect is not sanitized correctly. This means that anything could be appended to this redirect, which is simple if there is a man-in-the-middle and parsed. For example, if the original redirect response is Location: /new-uri%0AFoo%3A%20Bar The fetcher process returns this to the parent:

103 Redirect
URI: http://raspbian.raspberrypi.org/curr-uri
New-URI: http://raspbian.raspberrypi.org/new-uri
Foo:Bar

This extraneous Foo:Bar can easily be returned to the processes through the man-in-the-middle.

If the HTTP server sent

Location: /bad%0A%0A201%20URI%20Done%0AURI%3A%20http%3A//raspbian.raspberrypi.org/bad%0AFilename%3A%20/var/lib/apt/lists/raspbian.raspberrypi.org_Release.gpg%0ASize%3A%20mysize%0ALast-Modified%3A%20modifytime%2000%3A29%3A01%20%2B0000%0AMD5-Hash%3A%20myhash%0AMD5Sum-Hash%3A%20mysum%0ASHA256-Hash%3A%20myhash%0AChecksum-FileSize-Hash%3A%20mychecksum%0A

The fetcher process would interpret it as two separate resources that the parent would need to fetch, and trusts the injected hashes that the injector provides:

103 Redirect
URI: http://deb.debian.org/curr-uri
New-URI: http://deb.debian.org/bad

201 URI Done
URI: http://raspbian.raspberrypi.org/bad
Filename: /var/lib/apt/lists/raspbianraspberry.org_Release.gpg
Size: mysize
Last-Modified: modifytime
MD5-Hash: myhash
MD5Sum-Hash: mysum
SHA256-Hash: myhash
Checksum-FileSize-Hash: mychecksum

This bad.deb code is the executed as root on the system, as apt would unpackage and run the .deb binary, asuming the user would be typing sudo apt-get

Diagram of attack:

One of our raspberry pi's has apt 1.0.9.8.4, which is vulnerable to this attack, but the other doesn't. It is dependent on when th raspbian operating system was flashed onto the sd card for the raspberry pi. Any version of APT and raspbian installed before Jan 18 2019 is vulnerable.

Bluetooth

The public GitHub repository for the official raspberry pi Linux kernel has a few issues on the topic of Bluetooth vulnerabilities. The following three exploits are listed in order from most difficult to least difficult to implement.

The first set of vulnerabilities is BlueBorne. BlueBorne is a collection of exploits for Bluetooth stack implementation on almost every major system — including BlueZ, the Raspbian default. These exploits may be used by an attacker to gain access to any raspberry pi with its Bluetooth enabled, even if it has discovery mode off. The two Linux specific exploits are CVE-2017-1000250, which is an information-leaking exploit, and CVE-2017-1000251, a stack overflow exploit that allows for arbitrary permission escalation. The information-leaking exploit takes advantage of a flaw in the implementation of the BlueZ Service Discovery Protocol. Specially crafted lookup requests to the SDP server will cause the BlueZ process to leak memory, which can be targeted at the encryption key for the Bluetooth connection. Once the attacker has gained access to the encryption key they can listen in on all radio communications from that device. The stack overflow exploit takes advantage of a vulnerability in the messaging protocol BlueZ is built on top of: L2CAP. An issue in the processing of an L2CAP configuration packet causes memory corruption that allows for the arbitrary execution of code in kernel space. While both of these exploits were patched in September 2017, the Raspberry Pi 3B released in late February of 2016. Since the raspberry pi does not auto-update by default, any device purchased or flashed in those 1.5 years is still vulnerable to either attack. While the original reporter of the exploits — Aramis — published a whitepaper on their discoveries and a video demonstrating an attack, they did not publish the source code used in the exploit. As such, an attacker would have to reimplement the exploit on their own, greatly increasing the barrier to use.

The second vulnerability is internalblue. Internalblue isn't a bug but is instead a reverse-engineering of the Broadcom Bluetooth chip's firmware and firmware update process. Since the firmware update process is known, a framework for patching the lower layer of the Bluetooth stack to add monitoring tools can be created. With the firmware injection, one can arbitrarily establish connections, issue HCI commands, and read and write to any location in both the RAM and the ROM, which is normally read-only. Since this vulnerability is not an issue with Bluetooth itself but instead circumvents the security through obscurity of the radio chip's protocol, patching it will take a long time. Despite the release of the internalblue framework in July of 2018, it has not been fixed in a firmware update of any of the Raspberry Pis. While the production of the original internalblue suite took multiple years and many hours to develop, the up-to-date tool is still freely available on github along with instructions for its installation.

The final vulnerability is the Knob Attack. This attack, disclosed in late 2018, takes advantage of lax rules set by the Bluetooth protocol and as such affects all devices that fully and correctly implement the Bluetooth protocol. The specification allows for entropy bit size negotiation, down from the maximum 128 bits of entropy to just 8. With only a single byte of entropy on the encryption key, it is near trivial to brute force the key in real-time. Once successfully brute-forced, the attacker can listen in on any Bluetooth communications as well as perform man-in-the-middle attacks, intercepting and modifying the data being sent. The full process for performing a Knob attack is as follows:

Two (or more) targets form a bluetooth connection. They generate an encryption key with up to 128 bits of entropy.
The attacker contacts the master node in the connection and requests a renegotiation of the key. As the bluetooth protocol is parallel and does not authenticate requests for renegotiation, this is transparent to the end user.
The attacker reduces the entropy down to 8 bits. It can then brute-force the encryption key in real-time.
Once the encryption key has been found by the attacker, it can both listen in on the communication as well as use the key to sign its own messages and send commands to any other device on the network.

As of the time of writing, this exploit is still unpatched in Raspbian, as well as the upstream Debian. As fixing this loophole would require a deviation from the standards put forward by Bluetooth SIG (the governing body over bluetooth protocols), it is unlikely that a resolution will be implemented before a new protocol version is released.

Debugging

The Raspberry Pi contains hardware support for debugging the active process in its ARM core, using the built-in ARM CoreSight debugging modules. One thing of note is the ability of an ARM debugger to pause the execution of its target, even if the target has a higher privilege. When the target is paused, the debugger can read the entire contents of its memory, as well as modify that memory, before resuming execution. While this in itself is a security flaw, it normally requires hardware access, and as such has not received much scrutiny.

The Raspberry Pi 3B and its successors have a four-core system. Nailgun takes advantage of the interprocessor debugging capability of ARM cores to perform a variant of the above exploit entirely in software. One core can be used to debug another core internally, and since the debugger can access and override any other core regardless of privilege, it has access to anything on the Raspberry Pi. A proof of concept shows an abuse of this system to elevate from E1 (the ARM equivalent of Ring 3) to E3 (the ARM equivalent of the “negative rings” that hypervisors and Intel's Management Engine tend to have). With this privilege escalation, one can read out important data such as the contents of the SCM, which controls the privilege required to access different parts of the processor as well as the CPU's default behavior, as is demonstrated in the demo. That said, this is a general privilege escalation attack, the attacker gains access to anything on the device. This includes reading secure encyption keys and executing arbitrary payloads in a high-privilege mode. This vulnerability is an issue with how all ARM devices handle debugging and is unlikely to be patched in the near future.

An implementation of the nailgun attack (as well as instructions on how to use it) can be found in the nailgun folder.

Installation Guide

Lynis

$ apt-get install lynis

And it is recommended to upgrade lynis to the most recent version. More details please refer to here Nessus

First of all, Nessus is a large software required about 30GB disk space. For details please check here

This page shows how to install Nessus on a Linux machine. We used a Ubuntu 18.04 LTS machine for testing purpose. And make sure to install Nessus Essentials which is the free version of Nessus for educational purpose. More details can be found here

Signed Statement

(25%) Hang Xu: Scans using Nmap/Nessus/Lynis, Assessments on OS/User Group Permissions/SSHd/Fail2ban/Firewall.
(25%) Kaitlin Walsh: Hardware Assessment
(25%) Ashley Cui: Assessment of apt & HTTP Injection
(25%) Joshua Bassin: Bluetooth and Debugging Assessment

Source: EC 521 Group 3 – Raspberry Pi 3B Security Assessment

EC 521 Group 3 – Raspberry Pi 3B Security Assessment