TL;DR: The second of our short, IoT-related posts shares a simple trick we use in IoT pentests to temporarily change the contents of read-only files in Linux-based devices. Very useful when trying to proxy network traffic or temporary change the behavior of a device!
IoT field notes is a series of short stories about interesting (hopefully 🙂 ) observations, vulnerabilities and techniques, inspired directly from the IoT assessments we perform at NVISO and from our IoT R&D activities. Interested in the first part of this series, where we talked about Glitching Attacks? Read it here: https://blog.nviso.eu/2020/02/21/iot-hacking-field-notes-1-intro-to-glitching-attacks/)
Read only filesystems
IoT devices running Linux-based OSes often use the following partition configuration:
- The main filesystem partition, containing most of the OS files and application executables, is mounted as read-only;
- A secondary, smaller partition is mounted as read-write and used to hold configuration files and logs.
This is useful to protect the integrity of the OS and the application executables and prevent unwanted modifications.
However, during pentests, we often need to temporarily modify the contents of OS and application files. A typical use case is updating the hosts file, or some application-specific configuration file, to redirect a device’s traffic to an intercepting server. Bind mounts are an easy way to achieve that!
Example scenario
To demonstrate this technique, we configured one of our trusted Raspberry Pis, in order to mount the main partition as read-only and use a temporary in-memory filesystem for the logs and transient files. In the mount command output below, we highlighted the main partition carrying all the OS files in red and the temporary filesystem in green:
Now, suppose we want to modify the /etc/hosts files of the Pi, to redirect traffic to “google.com” towards an intercepting proxy on our local network, listening on 192.168.0.15. Predictably, trying to directly modify the /etc/hosts file is futile:
The obvious solution
In this case, the obvious solution would be to remount the main partition as read-write and then modify the hosts file. However, this approach has some disadvantages:
- We need to manually back-up the original hosts file and restore it after we are done;
- We need to be very careful about not causing unintended modifications to other files – we have no guarantees that some application on the device will not run rampart (because it was designed to operate in a read-only filesystem) and damage it;
- Sometimes, it might not be possible to remount the main partition as read-write, due to hardware constraints.
The easy solution: using bind mounts
In very simple terms, using a bind mount will allow us to mount a file to a different location inside the filesystem, creating a temporary view. The only prerequisite for using bind mounts is to have an area on the device where we can create files – in our scenario this is the temporarily filesystem holding the log files.
In the snippet below, we move into the /tmp folder of the temporary filesystem, create a copy of the read-only /etc/hosts file into etc.hosts.modded and finally modify etc.hosts.modded to force google.com to resolve to 192.168.0.15:
We are now ready to create a bind mount from the modified file to the original /etc/hosts file. The actual command is highlighted in red:
After bind mounting, the contents of /etc/hosts now reflect those of /tmp/etc.hosts.modded. Any modifications to the etc.hosts.modded file will immediately show in /etc/hosts as well.
Notice that in the output of traceroute (highlighted in green above), google.com now resolves to our intercepting proxy address: mission accomplished!
Last thoughts
Bind mounts are very useful because they allow us to temporarily modify the contents of read-only files, without risking permanent changes to them. Using “umount <mount_point>” or simply rebooting is enough to restore everything back to its original configuration.
We hope this trick will be useful in your IoT hacking adventures and hope to see you back for our next IoT fieldnotes post!
About the author
Théo Rigas is an IT Security Consultant at NVISO. He has researched the security of connected alarm systems and is currently working on more IoT and embedded device security projects. Outside of his Research work, he performs Web, Mobile and IoT security assessments for NVISO.
