Dropbox is a free web file synchronization tool, an online storage service operated by Dropbox Inc., which achieves file synchronization over the internet through cloud computing, allowing users to store and share files and folders. Dropbox offers both free and paid services, with paid services including Dropbox Pro and Dropbox for Business. There are client software available for different operating systems, as well as a web client.

Even such a perfect tool has experienced network security incidents. Back in 2012, over 60 million account details were stolen from Dropbox. For instance, in 2016, attackers used Dropbox to spread ransomware called Petya. Users clicked on files stored in shared Dropbox folders without realizing that clicking on them would install a virus on their computers.

We have been creating software images for the FriendlyArm NanoPi R1S single-board computer (SBC) to demonstrate some close-range attack techniques. I will detail the process of configuring the R1S by installing the Armbian distribution and P4wnP1 ALOA. We will also quickly look at how to configure USBProxy as a keylogger.

First, we will configure the R1S as a USB attack platform using P4wnP1 from MaMe82. Although it was initially created for the Raspberry Pi Zero W, there are essentially no restrictions. The Raspberry Pi Zero W, known as RPi Zero W in China, is a new generation darling of the Raspberry Pi family, using the same ARM11 core BCM2835 processor as its predecessor, but with about a 40% speed improvement. Compared to the Raspberry Pi Zero, I have added the same WiFi and Bluetooth as the 3rd gen B, making it adaptable to more scenarios. What we really need is an SBC with a USB Device Controller (UDC) and some way to communicate through it! The R1S fits this description perfectly, as it has two gigabit Ethernet ports that we can initially use during setup, but ultimately we will specialize in Ethernet attacks, which we will detail later. The R1S also has built-in WiFi, although it is not a particularly good chipset! However, we can use it as an access point to allow remote access to the configured Dropbox. We can also use the USB host port for LTE modems or other network interfaces for longer distances. But first, we will connect using the serial console provided on the USB port by default in Armbian.

We will base our setup on the current version of Armbian Buster (Armbian_20.02.1_Nanopi-r1_buster_current_5.4.20.7z). Download the file, extract the .img file, and then follow the instructions on the Armbian website to write it to the microSD card. Typically, I would perform the following steps, but make sure you are using the correct device!

Once done, insert the micro SD card into the R1S and connect the R1S to the computer using a microUSB cable. Ensure that the cable you choose is a data cable, not just a charging cable! A few minutes later, you should see a serial port on the host (this happens after the R1S boots and expands the filesystem to fill the SD card). If you do not see the new serial port, check the data cable!

dmesg -w shows the enumeration of the R1S

You should be able to connect to the serial port using your preferred terminal emulator. I like to use picocom, and I believe Putty on Windows works well too. You do not need to worry about the baud rate, but 115200 should work. Using a Linux host, the serial port is enumerated as a ttyACM device, such as /dev/ttyACM0. After establishing the connection, the initial Armbian login/setup screen will greet you. Log in as the “root” user with the password “1234”, then re-enter the password “1234” to start changing it to a new password. Remember your new root password! You may not need to create a non-privileged user, but you can do so if you wish!

Log in as root / 1234 and then change the root password

After interrupting or completing the creation of the “new user account”, log out and log back in as root or with sudo -s from a non-privileged user. During boot, we will connect an Ethernet cable from the local network to the WAN port of the R1S. After a few seconds, the R1S should be assigned an IP address.

Obtaining an IP address from the local DHCP server

Now we can SSH into our R1S. I also copied the ssh public key to make future connections easier.

Before running P4wnP1, we need to disable the USB serial console so that P4wnP1 can manage the USB device controller. First, stop systemd from starting the login prompt on the device:

Then, stop the automatic creation of serial devices by blocking the loading of the g_serial module. This will immediately unload it and prevent it from being loaded again in the future:

Now clone the P4wnP1 ALOA repository and copy the necessary (pre-built) parts to the correct locations. Ideally, we would build from scratch, but there are currently some bugs in the build process. Fortunately, the binaries built for the Raspberry Pi Zero W run well on the NanoPi R1S!

Now P4wnP1 is running, and you should be able to access the P4wnP1 web interface on port 8000 at the same IP as your SSH, i.e., http://nanopi-r1:8000. There is no authentication here, as it is assumed that the network exposed by P4wnP1 is a trusted network.

Now is a good time to test if the USB configuration is functioning properly; you should be able to select one or more USB classes to implement using the checkboxes on the right. I usually like to implement keyboard and mouse as well as custom HID devices. Then, ensure that USB is enabled at the top left, and click “Deploy”.

Configuring P4wnP1 USB configuration file

You should see the computer connected to the R1S detect a new USB device. For example, on the host using “dmesg”, you should see something like the following:

If you want to deploy this USB configuration at startup, you can click Store and enter “startup” as the profile name. Alternatively, you can deploy it manually as needed.

At this point, you should have a fully functional P4wnP1 device and can follow various tutorials online to actually use the USB functionality to attack connected devices.

Note: I found P4wnP1 to be very unstable when connecting to an existing access point during configuration (within P4wnP1). If this is your need, I would rather suggest using NetworkManager for this configuration. In this case, I recommend ignoring the next paragraph and disabling the WiFi configuration in P4wnP1, saving it as a startup configuration.

If you really want to utilize the hotspot feature of the built-in Wi-Fi interface for remote access, you may want P4wnP1 to manage it for you, simply because configuring it using NetworkManager seems not easy. If so, you will need to tell NetworkManager to ignore that interface to avoid ownership conflicts. You can do this by editing /etc/NetworkManager/NetworkManager.conf and adding the following two lines at the bottom:

Now, you can use the “WiFi Settings” tab in the web interface to configure P4wnP1 to run the Wi-Fi interface as an access point. Save it as part of the “startup” configuration to automatically configure it at boot.

When the device is deployed on-site and there is no familiar Wi-Fi network to connect to, this will be useful. Arguably, hiding the SSID helps to keep it hidden. Of course, once you start associating with it, any local Wireless IDS will quickly discover you! Alternatively, you could choose to connect using an LTE dongle or other less obvious communication mechanisms (such as Bluetooth or 802.15.4 radio). However, how to set it up will not be discussed here!

Additionally, I think I will try to set up a keylogger using USBProxy. Although it has been specially marked, it still works normally! The idea is to “mirror” the USB device plugged into the R1S via a USB-A connector by creating the same USB gadget descriptor and simply copying the packets from one side to the other. Studying the USB protocol might be the most interesting, but it can also serve as a keylogger out of the box.

Aside from ensuring that the libusb and libusb-dev packages are installed first, I will not cover all the details of the compilation. Similarly, by default, the keylogger functionality is bound to the ROT13 filter, so anything you type on the keyboard will be transposed by 13 characters. Therefore, before compiling, you may need to comment out line 153, where the PacketFilter_ROT13 plugin is added. While you are at it, you should also change line 143’s fopen call to append to the log file rather than open it just for reading by changing the “r+” parameter to “a+”. The main reason is that if the output file does not exist, the execution will fail; another workaround is to modify the output file before execution.

After compiling, you can run usb-mitm –k to start the keylogger. This will dump the observed keystroke information to stderr, which may not be very helpful. You can also pass an optional parameter to the -k switch specifying a file to write to: usb-mitm –kkeystrokes, which will log the observed keystrokes to the output file.

Captured Keystrokes

In summary, we have created a USB attack platform that can be used to inject keystrokes and mouse movements into connected victims, as well as execute various other USB attacks, such as using priority routing to launch a USB network interface. If there is an external USB keyboard readily available to plug into the R1S, we can also use it as a USB keyboard sniffer. Next, we will explore how to masquerade the R1S as an Ethernet person, plugging it between an authorized victim and their upstream switch. In this configuration, we can leverage the victim’s computer to pass any network authentication control mechanisms while “hijacking” its IP and MAC addresses so that any traffic generated by the R1S actually appears to come from the victim’s computer.

Next, I will focus on operating as an Ethernet attack tool in two scenarios. First, as a Dropbox that can connect to an unused Ethernet port and provide remote access to the target network; secondly, as an Ethernet Man in the Middle, which can be placed between a legitimate device and its internal device. In the upstream switch, using the IP and MAC addresses of the legitimate device to overlay its traffic. In the second case, we can also defeat network access control measures, as the legitimate device will handle all of this.

However, one thing to note is to avoid causing any anomalous network traffic, which could trigger alarms. An obvious example would be performing a DNS lookup on armbian.org during a scheduled apt update or trying to resolve 0.debian.pool.ntp.org. More complex might be certain DHCP options and parameters specific to Linux that do not apply to networks that only support Windows. It is best to familiarize yourself with all the processes running on your device and how they appear on the network before connecting your device to a potentially malicious network! Later, I will demonstrate a way to minimize this incidental traffic.

Preparing for an Attack

As mentioned above, I assume you will configure the built-in WiFi interface as a client to an access point you control or configure it as the AP itself, so we can connect to the R1S via WiFi without affecting P4wnP1. You can do this on the command line using nmtui when connecting to the serial console, or if you really know what you are doing, you can use nmcli! Set up the Ethernet interface.

The first suggestion is to rename the interfaces to correspond to the LAN and WAN names in the case, which helps avoid confusion between interfaces. You can do this using the following command, which can correctly configure systemd-network.

This will create two files in /etc/systemd/network/, named lan and wan interfaces, with the paths of the devices to be renamed. These should be the standard configuration for the NanoPi R1S, but may vary on other devices. You should also ensure that NetworkManager does not attempt to manage the following interfaces:

After creating these files, restart to activate the rules, rename the interfaces, and reload NetworkManager.

Renamed wan and lan interfaces

Let’s consider a scenario where you discover an unused Ethernet port and wish to connect your device. This is a potentially risky activity, as any network access control (NAC) system could detect your unauthorized activity and alert the operators. Nevertheless, it is likely to succeed, so it is worth a try.

The first thing you want to find out is whether the target port actually exists; fortunately, we can get immediate feedback using the three LEDs on the NanoPi R1S. Unfortunately, the LAN and WAN LEDs are hard to see, appearing green, while the red SYS LED is easier to see. The configuration I suggest is as follows, using the SYS LED to indicate CPU usage, and the WAN and LAN LEDs to indicate link status (when a link is detected) and detected RX traffic (flashing when only traffic is received).

To ensure this runs on every boot of the R1S, it is recommended to add the above to /etc/rc.local. Note that the link detection will not work without the IP link setup portion! If you want the red LED to indicate WAN link, swap LED1 and LED2 in the above script.

Now, if you power on the R1S and simply plug the Ethernet cable into the WAN or LAN port, it will tell you whether the data line is connected and whether there is activity on it. This helps avoid connecting the R1S to a disabled or disconnected port. That said, the R1S does indeed have indicator LEDs on the Ethernet port, so this is not entirely necessary!

Triggering hardware LEDs, the selected trigger is in brackets, currently [cpu]

Then, you can connect via WiFi and start monitoring network traffic before deciding how to proceed. For example, request a DHCP lease or simply hijack an unused IP address observed in the network range.

In the next article, we will discuss automated attack scenarios, network access control, network namespaces, and other possible attack vectors.

References and sources: https://sensepost.com/blog/2020/making-the-perfect-red-team-dropbox-part-1/ and https://sensepost.com/blog/2020/making-the-perfect-red-team-dropbox-part-2/