Linux Fu: Easy And Easier Virtual Networking

June 14, 2023 by Al Williams 15 Comments

One of the best things about Linux is that there are always multiple ways to do anything you want to do. However, some ways are easier than others. Take, for example, virtual networking. There are plenty of ways to make a bunch of Internet-connected computers appear to be on a single private network. That’s nothing new, of course. Linux and Unix have robust networking stacks. Since 2018, though, Wireguard has been the go-to solution; it has a modern architecture, secure cryptography, and good performance.

There’s only one problem: it is relatively difficult to set up. Not impossible, of course. But it is a bit difficult, depending on what you want to accomplish.

How Difficult?

You must set up a wireguard server and one or more clients. You’ll need to pick a range of IP addresses. You might need to turn on routing. You have to generate keys. You might need to configure DNS and other routing options. You’ll certainly need to modify firewall rules. You’ll also need to distribute keys.

None of these steps are terribly difficult, but it is a lot to keep straight. The wg program and wg-quick script do most of the work, but you have a lot of decisions and configuration management to keep straight.

Browse the official “quick start,” and you’ll see that it isn’t all that quick. The wg-quick script is better but only handles some use cases. If you want really limited use cases, there are third-party tools to do a lot of the rote work, but if you need to change anything, you’ll still need to figure it all out.

That being said, once you have it set up, it pretty much works without issue and works well. But that initial setup can be very frustrating. Continue reading “Linux Fu: Easy And Easier Virtual Networking” →

This Week In Security: NAME:WRECK, Signal Hacks Back, Updates, And More

April 23, 2021 by Jonathan Bennett 9 Comments

NAME:WRECK is a collection of vulnerabilities in DNS implementations, discovered by Forescout and JSOF Research. This body of research can be seen as a continuation of Ripple20 and AMNESIA:33, as it builds on a class of vulnerability discovered in other network stacks, problems with DNS message compression.

Their PDF Whitepaper contains a brief primer on the DNS message format, which is useful for understanding the class of problem. In such a message, a DNS name is encoded with a length-value scheme, with each full name ending in a null byte. So in a DNS Request, Hackaday.com would get represented as [0x08]Hackaday[0x03]com[0x00]. The dots get replaced by these length values, and it makes for an easily parsable format.

Very early on, it was decided that continually repeating the same host names in a DNS message was wasteful of space, so a compression scheme was devised. DNS compression takes advantage of the maximum host/domain length of 63 characters. This max size means that the binary representation of that length value will never contain “1”s in the first two digits. Since it can never be used, length values starting with a binary “11” are used to point to a previously occurring domain name. The 14 bits that follow this two bit flag are known as a compression pointer, and represent a byte offset from the beginning of the message. The DNS message parser pulls the intended value from that location, and then continues parsing.

The problems found were generally based around improper validation. For example, the NetX stack doesn’t check whether the compression pointer points at itself. This scenario leads to a tight infinite loop, a classic DoS attack. Other systems don’t properly validate the location being referenced, leading to data copy past the allocated buffer, leading to remote code execution (RCE). FreeBSD has this issue, but because it’s tied to DHCP packets, the vulnerability can only be exploited by a device on the local network. While looking for message compression issues, they also found a handful of vulnerabilities in DNS response parsing that aren’t directly related to compression. The most notable here being an RCE in Seimens’ Nucleus Net stack. Continue reading “This Week In Security: NAME:WRECK, Signal Hacks Back, Updates, And More” →

This Week In Security: OpenWrt, ZOOM, And Systemd

April 3, 2020 by Jonathan Bennett 21 Comments

OpenWrt announced a problem in opkg, their super-lightweight package manager. OpenWrt’s target hardware, routers, make for an interesting security challenge. A Linux install that fits in just 4 MB of flash memory is a minor miracle in itself, and many compromises had to be made. In this case, we’re interested in the lack of SSL: a 4 MB install just can’t include SSL support. As a result, the package manager can’t rely on HTTPS for secure downloads. Instead, opkg first downloads a pair of files: A list of packages, which contains a SHA256 of each package, and then a second file containing an Ed25519 signature. When an individual package is installed, the SHA256 hash of the downloaded package can be compared with the hash provided in the list of packages.

It’s a valid approach, but there was a bug, discovered by [Guido Vranken], in how opkg reads the hash values from the package list. The leading space triggers some questionable pointer arithmetic, and as a result, opkg believes the SHA256 hash is simply blank. Rather than fail the install, the hash verification is simply skipped. The result? Opkg is vulnerable to a rather simple man in the middle attack.

OpenWrt doesn’t do any automatic installs or automatic updates, so this vulnerability will likely not be widely abused, but it could be used for a targeted attack. An attacker would need to be in a position to MitM the router’s internet connection while software was being installed. Regardless, make sure you’re running the latest OpenWrt release to mitigate this issue. Via Ars Technica.

Wireguard V1.0

With the Linux Kernel version 5.6 being finally released, Wireguard has finally been christened as a stable release. An interesting aside, Google has enabled Wireguard in their Generic Kernel Image (GKI), which may signal more official support for Wireguard VPNs in Android. I’ve also heard reports that one of the larger Android ROM development communities is looking into better system-level Wireguard support as well.

Javascript in Disguise

Javascript makes the web work — and has been a constant thorn in the side of good security. For just an example, remember Samy, the worm that took over Myspace in ’05. That cross-site scripting (XSS) attack used a series of techniques to embed Javascript code in a user’s profile. Whenever that profile page was viewed, the embedded JS code would run, and then replicate itself on the page of whoever had the misfortune of falling into the trap.

Today we have much better protections against XSS attacks, and something like that could never happen again, right? Here’s the thing, for every mitigation like Content-Security-Policy, there is a guy like [theMiddle] who’s coming up with new ways to break it. In this case, he realized that a less-than-perfect CSP could be defeated by encoding Javascript inside a .png, and decoding it to deliver the payload.

Systemd

Ah, systemd. Nothing seems to bring passionate opinions out of the woodwork like a story about it. In this case, it’s a vulnerability found by [Tavis Ormandy] from Google Project Zero. The bug is a race condition, where a cached data structure can be called after it’s already been freed. It’s interesting, because this vulnerability is accessible using DBus, and could potentially be used to get root level access. It was fixed with systemd v220.

Mac Firmware

For those of you running MacOS on Apple hardware, you might want to check your firmware version. Not because there’s a particularly nasty vulnerability in there, but because firmware updates fail silently during OS updates. What’s worse, Apple isn’t publishing release notes, or even acknowledging the most recent firmware version. A crowd-sourced list of the latest firmware versions is available, and you can try to convince your machine to try again, and hope the firmware update works this time.

Anti-Rubber-Ducky

Google recently announced a new security tool, USB Keystroke Injection Protection. I assume the nickname, UKIP, isn’t an intentional reference to British politics. Regardless, this project is intended to help protect against the infamous USB Rubber Ducky attack, by trying to differentiate a real user’s typing cadence, as opposed to a malicious device that types implausibly quickly.

While the project is interesting, there are already examples of how to defeat it that amount to simply running the scripts with slight pauses between keystrokes. Time will tell if UKIP turns into a useful mitigation tool. (Get it?)

SMBGhost

Remember SMBGhost, the new wormable SMB flaw? Well, there is already a detailed explanation and PoC. This particular PoC is a local-only privilege escalation, but a remote code execution attack is like inevitable, so go make sure you’re patched!

This Week In Security: VPNs, Patch Tuesday, And Plundervault

December 13, 2019 by Jonathan Bennett 11 Comments

An issue in Unix virtual private networks was disclosed recently, where an attacker could potentially hijack a TCP stream, even though that stream is inside the VPN. This attack affects OpenVPN, Wireguard, and even IPSec VPNs. How was this possible? Unix systems support all manner of different network scenarios, and oftentimes a misconfiguration can lead to problems. Here, packets sent to the VPNs IP address are processed and responded to, even though they are coming in over a different interface.

The attack initially sounds implausible, as an attacker has to know the Virtual IP address of the VPN client, the remote IP address of an active TCP connection, and the sequence and ACK numbers of that connection. That’s a lot of information, but an attacker can figure it out one piece at a time, making it a plausible attack. Continue reading “This Week In Security: VPNs, Patch Tuesday, And Plundervault” →

Exploring The Dell N1108T-ON Ethernet Switch

June 17, 2019 by Tom Nardi 24 Comments

In an era where everything seems to be getting “smarter” every year, it will probably come as no surprise to find that even relatively middling networking hardware is now packing advanced features and considerable computational power. A case in point is the Dell N1108T-ON Ethernet switch. Despite only costing around $100 USD on the second hand market, [Ben Cox] discovered this particular switch was capable of a lot more than what was advertised by poking around its onboard operating system.

It all started by plugging into the serial port on the front of the switch, which [Ben] happily notes is an integrated FTDI USB serial adapter to make life easy. Booting into recovery mode gave him local shell access, and some poking around determines it’s the sort of BusyBox-powered Linux system that you’d expect on an embedded device. The biggest discoveries were that it was running a relatively recent kernel (3.8.1), and that it apparently had Python installed.

From there, [Ben] found out that these switches have a feature where the administrator can install and run Python “applications” by packaging them up as tarballs and copying them from a USB flash drive. So he wrote up a simple Python program that used the socket library to open up a reverse shell to his desktop computer, and to his surprise, it worked perfectly on the first try. Now with root access, the fun really started.

The next step was getting an SSH installed and running on the switch, so that he didn’t have to do the reverse shell trick every time. He then started installing the packages necessary to turn the switch into a secure VPN tunnel with Wireguard. This took a little fiddling as [Ben] didn’t have the option of installing the normal Wireguard kernel module, but he eventually got the necessary tools modified and cross-compiled to ARM. He believes this is just the start of what’s capable on devices like this, and we’re interested in seeing where the community goes from here.

We’ve seen hackers add management capability to a “dumb” unmanaged switch in the past, but software modifications like this promise to make the creation of custom, secure, networks far easier even on a hacker’s budget. A lot has certainly changed since the last time we saw somebody really dive into a professional Ethernet switch.