Raspberry Pi boards (or any of the many similar boards) are handy to leave at odd places to talk to the network and collect data, control things, or do whatever other tasks you need a tiny fanless computer to do. Of course, any time you have a computer on a network, you are inviting hackers (and not our kind of hackers) to break in.
We recently looked at how to tunnel ssh using a reverse proxy via Pagekite so you can connect to a Pi even through firewalls and at dynamic IP addresses. How do you stop a bad guy from trying to log in repeatedly until they have access? This can work on any Linux machine, but for this tutorial I’ll use Raspberry Pi as the example device. In all cases, knowing how to set up adequate ssh security is paramount for anything you drop onto a network.
It used to be tedious to set up a cross compile environment. Sure you can compile on the Raspberry Pi itself, but sometimes you want to use your big computer — and you can use it when your Pi is not on hand like when on an airplane with a laptop. It can be tricky to set up a cross compiler for any build tools, but if you go through one simple step, it becomes super easy regardless of what your real computer looks like. That one step is to install Docker.
Docker is available for Linux, Windows, and Mac OS. It allows developers to build images that are essentially preconfigured Linux environments that run some service. Like a virtual machine, these images can run together without interfering with each other. Unlike a virtual machine, Docker containers (the running software) are lightweight because they share the same underlying kernel and hardware of the computer.
The reality is, setting up the Raspberry Pi build environment isn’t any easier. It is just that with Docker, someone else has already done the work for you and you can automatically grab their setup and keep it up to date. If you are already running Linux, your package manager probably makes the process pretty easy too (see [Rud Merriam’s] post on that process). However, the nice thing about the images is it is a complete isolated environment that can move from machine to machine and from platform to platform (the Windows and Mac platforms use a variety of techniques to run the Linux software, but it is done transparently).
A lot of us spend a lot of time switching between Windows and Linux. Now that platforms like the Raspberry Pi are popular, that number is probably increasing every day. While I run Linux on nearly everything I own (with the exception of a laptop), my work computers mostly run Windows. The laptop is on Windows, too, because I got tired of trying to get all the fancy rotation sensors and pen features working properly under Linux.
What I hate most about Windows is how hard is it to see what’s going on under the hood. My HP laptop works with a cheap Dell active stylus. Sort of. It is great except around the screen edges where it goes wild. Calibration never works. On Linux, I could drill down to the lowest levels of the OS if I were so inclined. With Windows, it is just tough.
War is Shell
One place where Linux always used to have an advantage over DOS and Windows was the shell. There are lots of variations available under Linux, but bash seems to be the current pick for most people. If you want more power, you can move to some alternatives, but even bash is pretty powerful if you learn how to use it and have the right external programs (if you don’t believe it, check out this web server).
Setting up a cluster of computers used to be a high-end trick used in big data centers and labs. After all, buying a bunch of, say, VAX computers runs into money pretty quickly (not even counting the operating expense). Today, though, most of us have a slew of Raspberry Pi computers.
Because the Pi runs Linux (or, at least, can run Linux), there are a wealth of tools out there for doing just about anything. The trick is figuring out how to install it. Clustering several Linux boxes isn’t necessarily difficult, but it does take a lot of work unless you use a special tool. One of those tools is Docker, particularly Docker Swarm Mode. [Alex Ellis] has a good video (see below) showing the details of a 28 CPU cluster.
According to reports from Android Police and ZDNet, you may soon have a new operating system from Google to run on your Raspberry Pi. Details are still extremely sparse, the only description on the GitHub page is “Pink + Purple == Fuchsia (a new Operating System)”. But, here’s what we do know:
The new OS, called Fuchsia, will be based on Magenta, which is in turn built on LittleKernel. That means that, surprisingly, Google will not be using a Linux kernel for the new OS but something more like an embedded RTOS. Although Google is targeting embedded systems, the possibility of being able to run it on a desktop has been mentioned, so it may not be too minimalistic.
Google’s Travis Geiselbrecht has named the Raspberry Pi 3 specifically as one system it will run on, and said that it’ll be available soon. But, it seems Google is aiming to make it run on a variety of ARM devices (both 32 bit and 64 bit), as well as 64 bit PCs. This is a direct effort to compete against other commercial embedded operating systems that are currently available, and especially on IoT devices.
If you’re eager to see what this is all about, you can follow Google’s quick start recipes and see what you can come up with, although details are still sketchy enough that we’re just going to wait a bit.
[Ncrmnt] had a busted tablet PC with an Allwinner A23 SoC inside. He combined two of our favorite past-times, Linux hacking and 3D printing, to make a rather sweet little single-board-computer out of it, giving the tablet a second life.
Step one was to make sure that the thing works. Normally, you’d hook up a wired serial terminal and start hacking. [Ncrmnt] took it one step further and wired in a HC-05 Bluetooth serial module, so he can pull up the debug terminal wirelessly. The rest of the hackery was just crafting a bootable SD card and poking around in the Android system that was still resident in the flash memory of the system.
Once the board was proven workable, [Ncrmnt] designed and printed a sweet custom case using Solvespace, a constraint-based 3D CAD modeler that was new to us until recently. The case (after three prints) was a perfect fit for the irregularly shaped system board, a 3.7 V LiIon battery, and a speaker. He then added some nice mounting tabs. All in all, this is a nice-looking and functional mini-computer made out of stuff that was destined for the trash. It’s fast, it’s open-source, and it’s powerful. Best of all, it’s not in the dumpster.
There are pictures and more details on his blog, as well as [Ncrmnt]’s TV-stick to computer conversion that we’ve covered before.
If you don’t have root, you don’t own a device, despite what hundreds of Internet of Things manufacturers would tell you. Being able to access and write to that embedded Linux system in your new flashy gadget is what you need to truly own a device, and unfortunately this is a relatively uncommon feature. At this year’s DEF CON, [Brad Dixon] unveiled a technique that pwns a device using only a sewing needle, multimeter probe, or a paperclip. No, it won’t work on every device, and the devices this technique will work with are poorly designed. That doesn’t mean it doesn’t work, and that doesn’t mean the Pin2Pwn technique isn’t useful, though.
The attack relies on how an embedded Linux device boots. All the software needed to load Linux and the rest of the peripheral magic is usually stored on a bit of Flash somewhere on the board. By using a pin, probe, or paperclip to short two data pins, or two of the latch pins on this memory chip, the bootloader will fail, and when that happens, it may fall back to a uboot prompt. This pwns the device.
There are a few qualifications for this Pwn using a pin. If the device has JTAG, it doesn’t matter – you can already own the device. If, however, a device has a locked-down JTAG, unresponsive serial ports, or even their own secure boot solution, this technique might work.
Two data pins on a TSSOP Flash shorted by a multimeter probe
This exploit works on the property of the bootloader. This bit of code first looks at a piece of Flash or other memory separate from the CPU and loads whatever is there. [Brad] found a few devices (mostly LTE routers) that would try to load Linux from the Flash, fail, try to load Linux again, fail, and finally drop to a uboot prompt.
As with any successful exploit, an equally effective mitigation strategy must be devised. There are two ways to go about this, and in this case, the software side is much better at getting rid of this attack than the hardware side.
Since this attack relies on the software falling back to uboot after an unsuccessful attempt at whatever it should be booting, the simplest and most effective mitigation technique is simply rebooting the device if the proper firmware can’t be found. Having a silent serial console is great, but if the attack relies on falling back to uboot, simply not doing that will effectively prevent this attack.
The hardware side is a little simpler than writing good firmware. Instead of using TSSOP and SOIC packages for storing the device firmware, use BGAs. Hide the pins and traces on an inner layer of the board. While this isn’t a foolproof way of preventing the attack – there will always be someone with a hot air gun, magnet wire, and a steadier hand than you – it’s hard to glitch a data line with a sewing needle if you can’t see the data line.
