This Week In Security: TunnelVision, Scarecrows, And Poutine

May 10, 2024 by 9 Comments

There’s a clever “new” attack against VPNs, called TunnelVision, done by researchers at Leviathan Security. To explain why we put “new” in quotation marks, I’ll just share my note-to-self on this one written before reading the write-up: “Doesn’t using a more specific DHCP route do this already?” And indeed, that’s the secret here: in routing, the more specific route wins. I could not have told you that DHCP option 121 is used to set extra static routes, so that part was new to me. So let’s break this down a bit, for those that haven’t spent the last 20 years thinking about DHCP, networking, and VPNs.

So up first, a route is a collection of values that instruct your computer how to reach a given IP address, and the set of routes on a computer is the routing table. On one of my machines, the (slightly simplified) routing table looks like:

# ip route
default via 10.0.1.1 dev eth0
10.0.1.0/24 dev eth0

The first line there is the default route, where “default” is a short-hand for 0.0.0.0/0. That indicate a network using the Classless Inter-Domain Routing (CIDR) notation. When the Internet was first developed, it was segmented into networks using network classes A, B, and C. The problem there was that the world was limited to just over 2.1 million networks on the Internet, which has since proven to be not nearly enough. CIDR came along, eliminated the classes, and gave us subnets instead.

In CIDR notation, the value after the slash is commonly called the netmask, and indicates the number of bits that are dedicated to the network identifier, and how many bits are dedicated to the address on the network. Put more simply, the bigger the number after the slash, the fewer usable IP addresses on the network. In the context of a route, the IP address here is going to refer to a network identifier, and the whole CIDR string identifies that network and its size.

Back to my routing table, the two routes are a bit different. The first one uses the “via” term to indicate we use a gateway to reach the indicated network. That doesn’t make any sense on its own, as the 10.0.1.1 address is on the 0.0.0.0/0 network. The second route saves the day, indicating that the 10.0.1.0/24 network is directly reachable out the eth0 device. This works because the more specific route — the one with the bigger netmask value, takes precedence.

The next piece to understand is DHCP, the Dynamic Host Configuration Protocol. That’s the way most machines get an IP address from the local network. DHCP not only assigns IP addresses, but it also sets additional information via numeric options. Option 1 is the subnet mask, option 6 advertises DNS servers, and option 3 sets the local router IP. That router is then generally used to construct the default route on the connecting machine — 0.0.0.0/0 via router_IP.

Remember the problem with the gateway IP address belonging to the default network? There’s a similar issue with VPNs. If you want all traffic to flow over the VPN device, tun0, how does the VPN traffic get routed across the Internet to the VPN server? And how does the VPN deal with the existence of the default route set by DHCP? By leaving those routes in place, and adding more specific routes. That’s usually 0.0.0.0/1 and 128.0.0.0/1, neatly slicing the entire Internet into two networks, and routing both through the VPN. These routes are more specific than the default route, but leave the router-provided routes in place to keep the VPN itself online.

And now enter TunnelVision. The key here is DHCP option 121, which sets additional CIDR notation routes. The very same trick a VPN uses to override the network’s default route can be used against it. Yep, DHCP can simply inform a client that networks 0.0.0.0/2, 64.0.0.0/2, 128.0.0.0/2, and 192.0.0.0/2 are routed through malicious_IP. You’d see it if you actually checked your routing table, but how often does anybody do that, when not working a problem?

There is a CVE assigned, CVE-2024-3661, but there’s an interesting question raised: Is this a vulnerability, and in which component? And what’s the right solution? To the first question, everything is basically working the way it is supposed to. The flaw is that some VPNs make the assumption that a /1 route is a bulletproof way to override the default route. The solution is a bit trickier. Continue reading “This Week In Security: TunnelVision, Scarecrows, And Poutine” →

Your Open-Source Client Options In The Non-Mastodon Fediverse

May 8, 2024 by 22 Comments

When things started getting iffy over at Twitter, Mastodon rose as a popular alternative to the traditional microblogging platfrom. In contrast to the walled gardens of other social media channels, it uses an open protocol that runs on distributed servers that loosely join together, forming the “Fediverse”.

The beauty of the Fediverse isn’t just in its server structure, though. It’s also in the variety of clients available for accessing the network. Where Twitter is now super-strict about which apps can hook into the network, the Fediverse welcomes all comers to the platform! And although Mastodon is certainly the largest player, it’s absolutely not the only elephant in the room.

Today, we’ll look at a bunch of alternative clients for the platform, ranging from mobile apps to web clients. They offer unique features and interfaces that cater to different user preferences and needs. We’ll look at the most notable examples—each of which brings a different flavor to your Fediverse experience.

Continue reading “Your Open-Source Client Options In The Non-Mastodon Fediverse” →

Your Pi, From Anywhere

May 7, 2024 by 20 Comments

The Raspberry Pi finds a use in a huge variety of applications, and in almost any location you could imagine. Sadly those who use those machines might not be in the same place as the machines themselves, and thus there’s the question of providing a remote connection between the two. This may not be a huge challenge to those skilled with Linux and firewalls, but to many Pi users it’s a closed book. So the Pi folks have come up with a painless way to connect to your Pi wherever it is, and it’s called Raspberry Pi Connect.

To use the service all you need is a Pi running the latest 64-bit version of Raspberry Pi OS, so sadly that excludes base model Zeros and older models. Sign in to the Raspberry Pi Connect server, follow the instructions, and you’re on your way. Under the hood it’s the well-known VNC protocol at work, with the connection setup being managed via WebRTC. The Pi servers are intended to act simply as connection facilitators for peer-to-peer traffic, though they are capable of handling through traffic themselves. It’s a beta service with a single server in the UK at the time of writing, though we’d expect both the number of servers and the offering to evolve over time.

We think this is a useful addition to the Pi offering, and we expect to see it used in all manner of inventive ways. Meanwhile it’s a while since we had a look at connecting to a headless Pi, but much of the information is still relevant.

Bluepad32 Brings All The Controllers To Your MCU

May 7, 2024 by 13 Comments

As much as we enjoy spinning up our own solutions, there are times when you’ve got to look at what’s on the market and realize you might be out of your league. For example, take Bluetooth game controllers. Sure, you could make your own with a microcontroller, some buttons, and a couple joysticks. But between the major players like Microsoft, Nintendo, and Sony, as well as independent peripheral companies like 8BitDo, there’s some seriously impressive hardware out there that can be easily repurposed.

How, you ask? Well, Bluepad32 by [Ricardo Quesada] would be a great place to start. This Apache v2.0 licensed project allows you to easily interface with a wide array of commercially available BT controllers, and supports an impressive number of software and hardware platforms. Using the Arduino IDE on the ESP32? No problem. CircuitPython on Adafruit’s PyPortal? Supported. There’s even example code provided for using it on Linux and Mac OS. Sorry Windows fans — perhaps there’s a sassy paperclip or sentient dog built into your OS that can instruct you further.

A few of the controllers supported by Bluepad32.

The nature of the Bluetooth Human Interface Device (HID) protocol means that, at least in theory, pretty much all modern devices should be supported by Bluepad32 automatically. But even still, it’s hard not to be impressed by the official controller compatibility list. There’s also separate lists for Bluetooth mice and keyboards that are known to work with the project.

While it’s somewhat unlikely to be a problem in this particular community, there is an unusual quirk to this project which we think should at least be mentioned. Although Bluepad32 itself is free and open source software (FOSS), it depends on the BTstack library, which in turn uses a more ambiguous licensing scheme. BTstack is “open” in the sense that you can see the source code and implement it in your own projects, but its custom license precludes commercial use. If you want to use BTstack (and by extension, Bluepad32) in a commercial product, you need to contact the developers and discuss terms.

License gotchas aside, Bluepad32 is definitely a project to keep in the back of your mind for the future. You can always build your own controller if you’re looking a challenge, but you’ll have a hell of a time beating the decades of testing and development Sony has put into theirs.

MUDLink Is Making UART Data Links More Reliable

May 3, 2024 by 20 Comments

Many of us have used UARTs to spit data from one system or chip to another. Normally, for quick and dirty maker projects, this is good enough. However, you’ll always get the odd dropped transmission or glitch that can throw a spanner in the works if you’re not careful. [Jake Read] decided to work on a system that could use UARTs while being far more reliable. Enter MUDLink.

MUDLink is a library that works with an Arduino’s UART port and stacks on a bit of protocol to clean things up. It uses a packetized method of sending data to ensure that transmissions are received reliably as intended by the sender. Packets are framed using a method called Consistent Overhead Byte Stuffing, which is a nice lightweight way of doing so. The system also uses CRC16-CCITT as an error checking mechanism. There’s also an ack-and-retransmit system for ensuring any dropped transmissions are repeated and received successfully.

If you need reliable UART transmissions without too much overhead, you might want to look at what Jake is doing. It’s a topic we’ve looked at before, too.

A Smart Power Distribution Unit For Home Automation

April 25, 2024 by 28 Comments

Power distribution units, as the name implies, are indispensable tools to have available in a server rack. They can handle a huge amount of power for demands of intensive computing and do it in a way that the wiring is managed fairly well. Plenty of off-the-shelf solutions have remote control or automation capabilities as well, but finding none that fit [fmarzocca]’s needs or price range, he ended up building his own essentially from scratch that powers his home automation system.

Because it is the power supply for a home automation system, each of the twelve outlets in this unit needed to be individually controllable. For that, three four-channel relay boards were used, each driven by an output on an ESP32. The ESP32 is running the Tasmota firmware to keep from having to reinvent the wheel, while MQTT was chosen as a protocol for controlling these outlets to allow for easy integration with the existing Node-RED-based home automation system. Not only is control built in to each channel, but the system can monitor the power consumption of each outlet individually as well. The entire system is housed in a custom-built sheet metal enclosure and painted to blend in well with any server rack.

Adding a system like this to a home automation system can simplify a lot of the design, and the scalable nature means that a system like this could easily be made much smaller or much larger without much additional effort. If you’d prefer to keep your hands away from mains voltage, though, we’ve seen similar builds based on USB power instead, with this one able to push around 2 kW.

Supercon 2023: Alex Lynd Explores MCUs In Infosec

April 24, 2024 by 9 Comments

The average Hackaday reader hardly needs to be reminded of the incredible potential of the modern microcontroller. While the Arduino was certainly transformative when it hit the scene, those early 8-bit MCUs were nothing compared to what’s on the market now. Multiple cores with clock speeds measured in the hundreds of megahertz, several MB of flash storage, and of course integrated WiFi capability mean today’s chips are much closer to being fully-fledged computers than their predecessors.

It’s not hard to see the impact this has had on the electronics hobby. In the early 2000s, getting your hardware project connected to the Internet was a major accomplishment that probably involved bringing some hacked home router along for the ride. But today, most would consider something like an Internet-connected remote environmental monitor to be a good starter project. Just plug in a couple I2C sensors, write a few lines of Python, and you’ve got live data pouring into a web interface that you can view on your mobile device — all for just a few bucks worth of hardware.

But just because we’re keenly aware of the benefits and capabilities of microcontrollers like the ESP32 or the Pi Pico, doesn’t mean they’ve made the same impact in other tech circles. In his talk Wireless Hacking on a $5 Budget, Alex Lynd goes over some examples of how he’s personally put these devices to work as part of his information security (infosec) research.

Continue reading “Supercon 2023: Alex Lynd Explores MCUs In Infosec” →