If you’ve ever seen an experienced radio operator pull a signal out of the noise, or talked to someone in a crowded noisy restaurant, you know the human brain is excellent at focusing on a particular sound. This is sometimes called the cocktail party effect and if you wear a hearing aid, this doesn’t work as well because the device amplifies everything the same. A German company, Fraunhofer, aims to change that. They’ve demonstrated a hearing aid that uses EEG sensors to determine what you are trying to hear. Then it uses that information to configure beamforming microphone arrays to focus in on the sound you want to hear.
In addition to electronically focusing sound, the device stimulates your brain using transcranial electrostimulation. A low-level electrical signal tied to the audio input directly stimulates the auditory cortex of your brain and reportedly improves intelligibility.
Given that we are living in what most of humanity would now call “the future”, we really ought to start acting like it. We’re doing okay on the electric cars, but sartorially we’ve got some ground to make up. Helping with this effort is [Amy Goodchild], who put together a fancy LED shirt for all occasions.
The basis of the shirt is an ESP8266 running the FastLED library, hooked up to strings of WS2812B LEDs. It’s a great combination for doing quick and simple colorful animations without a lot of fuss. The LED strips are then fastened to the shirt by sewing them on, with heatshrink added to the strips to give the thread something to attach to. Tulle fabric is used as a diffuser, hiding the strips when they’re off and providing a more pleasant glowing effect. Everything is controlled from a small box, fitted with an arcade button and 7-segment display.
It’s a fun piece that’s readily achievable for the novice maker, and a great way to learn about LEDs and sewing. We’ve seen other similar builds before, such as this glowing LED skirt. Video after the break.
Ready for more speculative execution news? Hope so, because both Intel and AMD are in the news this week.
The first story is Load Value Injection, a different approach to reading arbitrary memory. Rather than try to read protected memory, LVI turns that on its head by injecting data into a target’s data. The processor speculatively executes based on that bad data, eventually discovers the fault, and unwinds the execution. As per other similar attacks, the execution still changes the under-the-hood state of the processor in ways that an attacker can detect.
What’s the actual attack vector where LVI could be a problem? Imagine a scenario where a single server hosts multiple virtual machines, and uses Intel’s Secure Guard eXentensions enclave to keep the VMs secure. The low-level nature of the attack means that not even SGX is safe.
The upside here is that the attack is quite difficult to pull off, and isn’t considered much of a threat to home users. On the other hand, the performance penalty of the suggested fixes can be pretty severe. It’s still early in the lifetime of this particular vulnerability, so keep an eye out for further updates.
AMD’s Takeaway Bug
AMD also found itself on the receiving end of a speculative execution attack (PDF original paper here). Collide+Probe and Load+Reload are the two specific attacks discovered by an international team of academics. The attacks are based around the reverse-engineering of a hash function used to speed up cache access. While this doesn’t leak protected data quite like Spectre and Meltdown, it still reveals internal data from the CPU. Time will tell where exactly this technique will lead in the future.
To really understand what’s going on here, we have to start with the concept of a hash table. This idea is a useful code paradigm that shows up all over the place. Python dictionaries? Hash tables under the hood.
Imagine you have a set of a thousand values, and need to check whether a specific value is part of that set. Iterating over that entire set of values is a computationally expensive proposition. The alternative is to build a hash table. Create an array of a fixed length, let’s say 256. The trick is to use a hash function to sort the values into this array, using the first eight bits of the hash output to determine which array location each value is stored in.
When you need to check whether a value is present in your set, simply run that value through the hash function, and then check the array cell that corresponds to the hash output. You may be ahead of me on the math — yes, that works out to about four different values per array cell. These hash collisions are entirely normal for a hash table. The lookup function simply checks all the values held in the appropriate cell. It’s still far faster than searching the whole table.
AMD processors use a hash table function to check whether memory requests are present in L1 cache. The Takeaway researchers figured out that hash function, and can use hash collisions to leak information. When the hash values collide, the L1 cache has two separate chunks of memory that need to occupy the same cache line. It handles this by simply discarding the older data when loading the colliding memory. An attacker can abuse this by measuring the latency of memory lookups.checking
If an attacker knows the memory location of the target data, he can allocate memory in a different location that will be stored in the same cache line. Then by repeatedly loading his allocated memory, he knows whether the target location has been accessed since his last check. What real world attack does that enable? One of the interesting ones is mapping out the memory layout of ASLR/KASLR memory. It was also suggested that Takeaway could be combined with the Spectre attack.
There are two interesting wrinkles to this story. First, some have pointed out the presence of a thank-you to Intel in the paper’s acknowledgements. “Additional funding was provided by generous gifts from Intel.” This makes it sound like Intel has been funding security research into AMD processors, though it’s not clear what exactly this refers to.
Lastly, AMD’s response has been underwhelming. At the time of writing, their official statement is that “AMD believes these are not new speculation-based attacks.” Now that the paper has been publicly released, that statement will quickly be proven to be either accurate or misinformed.
Closed Source Privacy?
The Google play store and iOS app store is full of apps that offer privacy, whether it be a VPN, adblocker, or some other amazing sounding application. The vast majority of those apps, however, are closed source, meaning that you have little more than trust in the app publisher to ensure that your privacy is really being helped. In the case of Sensor Tower, it seems that faith is woefully misplaced.
A typical shell game is played, with paper companies appearing to provide apps like Luna VPN and Adblock Focus. While technically providing the services they claim to provide, the real aim of both apps is to send data back to Sensor Tower. When it’s possible, open source is the way to go, but even an open source app can’t protect you against a malicious VPN provider.
Does the word “#backdoor” seem frightening? That’s because it’s often used incorrectly – sometimes to deliberately create fear. Watch to learn the truth about backdoors and other types of network access. #cybersecuritypic.twitter.com/NEUXbZbcqw
[Robert Graham] thought the whole story was fishy, and decided to write about it. He makes two important points. First, the Wall Street Journal article cites anonymous US officials. In his opinion, this is a huge red flag, and means that the information is either entirely false, or an intentional spin, and is being fed to journalists in order to shape the news. His second point is that Huawei’s redefinition of government-mandated backdoors as “front doors” takes the line of the FBI, and the Chinese Communist Party, that governments should be able to listen in on your communications at their discretion.
Graham shares a story from a few years back, when his company was working on Huawei brand mobile telephony equipment in a given country. While they were working, there was an unspecified international incident, and Graham watched the logs as a Huawei service tech remoted into the cell tower nearest the site of the incident. After the information was gathered, the logs were scrubbed, and the tech logged out as if nothing had happened.
Did this tech also work for the Chinese government? The NSA? The world will never know, but the fact is that a government-mandated “front door” is still a back door from the users’ perspective: they are potentially being snooped on without their knowledge or consent. The capability for abuse is built-in, whether it’s mandated by law or done in secret. “Front doors” are back doors. Huawei’s gear may not be dirtier than anyone else’s in this respect, but that’s different from saying it’s clean.
Abusing Regex to Fool Google
[xdavidhu] was poking at Google’s Gmail API, and found a widget that caught him by surprise. A button embedded on the page automatically generated an API key. Diving into the Javascript running on that page, as well as an iframe that gets loaded, he arrived at an ugly regex string that was key to keeping the entire process secure. He gives us a tip, www.debuggex.com, a regex visualizer, which he uses to find a bug in Google’s JS code. The essence of the bug is that part of the URL location is interpreted as being the domain name. “www.example.com\.corp.google.com” is considered to be a valid URL, pointing at example.com, but Google’s JS code sees the whole string as a domain, and thinks it must be a Google domain.
For his work, [xdavidhu] was awarded $6,000 because this bit of ugly regex is actually used in quite a few places throughout Google’s infrastructure.
SMBv3 Wormable Flaw
Microsoft’s SMBv3 implementation in Windows 10 and Server 2019 has a vulnerability in how it handles on-the-fly compression, CVE-2020-0796. A malicious packet using compression is enough to trigger a buffer overflow and remote code execution. It’s important to note that this vulnerability doesn’t required an authenticated user. Any unpatched, Internet-accessible server can be compromised. The flaw exists in both server and client code, so an unpatched Windows 10 client can be compromised by connecting to a malicious server.
There seems to have been a planned coordinated announcement of this bug, corresponding with Microsoft’s normal Patch Tuesday, as both Fortinet and Cisco briefly had pages discussing it on their sites. Apparently the patch was planned for that day, and was pulled from the release at the last moment. Two days later, on Thursday the 12th, a fix was pushed via Windows update. If you have Windows 10 machines or a Server 2019 install you’re responsible for, go make sure it has this update, as proof-of-concept code is already being developed.
It could be said that there are a number of factors behind the explosion of creativity in our community of hardware hackers over the last couple of decades, but one in particular that is beyond doubt is the ease with which it has been possible to import small orders from China. See something on AliExpress and it can be yours for a few quid, somewhere in a warehouse on the other side of the world it’s put into a grey shipping bag, and three weeks later it’s on your doorstep. This bounty has in no small part been aided by a favourable postage and taxation environment in which both low postage costs and a lack of customs duties on packages under a certain value conspire to render getting the product in front of you a fraction of the cost of buying the thing in the first place. Continue reading “EU Duty Changes, A Whole VAT Of Trouble For Hackers?”→
The North Sea in a winter storm is a spectacular sight, one of foam-crested waves and squalls driven on the gale. It’s not a place to spend a lot of time if you are a land-lubber, so to cross it twice in a few weeks must mean there is something very much worth seeing on its other side.
More of that exotic cruise ship lifestyle.
But one of the best antidotes to February weather in the European hacker community was Hacker Hotel 2020. Around 350 people came from all the countries of the northwest of the continent to the comfort and hospitality of the Westcord Hotel de Veluwe in the eastern Netherlands, to experience a hacker camp with all the convenience and luxury of a resort hotel rather than a muddy field.
Three days in this environment results in a camp that’s just a bit special, and one that’s very much worth a visit if your range extends this far.
An Upscale Hotel Gets The Hacker Treatment
The Hacker Hotel badge 2020 has many hidden depths
Our small party of Brits arrived a day early, on a damp Thursday morning ready to lend a hand with the set-up. Slowly an upscale business conference centre was transformed into a hacker camp venue, with conference rooms turned into lecture halls, lighting and video equipment in place and 3-phase power cables snaking along the skirting boards. A large hardware hacking area was set up in one wing of the building, then the EventInfra people came in and laid out a hacker-camp-grade wireless and wired network that delivered connectivity everywhere. The contrast between the two worlds is significant, but together they make for a unique experience.
One by one, hackers arrived from all points of the compass, bearing crates of the usual cool stuff. An amateur TV satellite earth station, a brace of oversized delta 3D printers, a coin-pushing game that’s familiar from other camps. And smaller projects; little roving robots, indoor-sized multirotors, and several crates of outdated Chinese photo-frames that it’s said can be hacked to run a Linux distro.
This is the lifeblood of a hacker camp, but of course the signature piece of hardware for any hacker camp is its badge. In this Hacker Hotel 2020 didn’t disappoint, with a beautifully designed Ancient Egyptian-themed badge that concealed an array of puzzles across multiple levels. We’ll cover the badge in detail in a separate piece, but suffice to say that it is something of a tour de force. For now let’s jump into all of people and activities on offer at the con.
Let’s Encrypt recently celebrated their one billionth certificate. That’s over 190 million websites currently secured, and thirteen full-time staff. The annual budget for Lets Encrypt is an eye-watering $3.3+ million, covered by sponsors like Mozilla, Google, Facebook, and the EFF.
A cynic might ask if we need to rewind the counter by the three million certificates Let’s Encrypt recently announced they are revoking as a result of a temporary security bug. That bug was in the handling of the Certificate Authority Authorization (CAA) security extension. CAA is a recent addition to the X.509 standard. A domain owner opts in by setting a CAA field in their DNS records, specifying a particular CA that is authorized to issue certificates for their domain. It’s absolutely required that when a CA issues a new certificate, it checks for a CAA record, and must refuse to issue the certificate if a different authority is listed in the CAA record.
The CAA specification specifies eight hours as the maximum time to cache the CAA check. Let’s Encrypt uses a similar automated process to determine domain ownership, and considers those results to be valid for 30 days. There is a corner case where the Let’s Encrypt validation is still valid, but the CAA check needs to be re-performed. For certificates that cover multiple domains, that check would need to be performed for each domain before the certificate can be issued. Rather validating each domain’s CAA record, the Let’s Encrypt validation system was checking one of those domain names multiple times. The problem was caught and fixed on the 28th.
The original announcement gave administrators 36 hours to manually renew their affected certificates. While just over half of the three million target certificates have been revoked, an additional grace period has been extended for the over a million certs that are still in use. Just to be clear, there aren’t over a million bad certificates in the wild, and in fact, only 445 certificates were minted that should have been prevented by a proper CAA check.
Ghostcat
Apache Tomcat, the open source Java-based HTTP server, has had a vulnerability for something like 13 years. AJP, the Apache JServ Protocol, is a binary protocol designed for server-to-server communication. An example use case would be an Apache HTTP server running on the same host as Tomcat. Apache would serve static files, and use AJP to proxy dynamic requests to the Tomcat server.
Ghostcat, CVE-2020-1938, is essentially a default configuration issue. AJP was never designed to be exposed to untrusted clients, but the default Tomcat configuration enables the AJP connector and binds it to all interfaces. An attacker can craft an AJP request that allows them to read the raw contents of webapp files. This means database credentials, configuration files, and more. If the application is configured to allow file uploads, and that upload location is in the folder accessible to the attacker, the result is a full remote code execution exploit chain for any attacker.
The official recommendation is to disable AJP if you’re not using it, or bind it to localhost if you must use it. At this point, it’s negligence to leave ports exposed to the internet that aren’t being used.
Have I Been P0wned
You may remember our coverage of [Troy Hunt] over at haveibeenpwned.com. He had made the decision to sell HIBP, as a result of the strain of running the project solo for years. In a recent blog post, [Troy] reveals the one thing more exhausting that running HIBP: trying to sell it. After a potential buyer was chosen, and the deal was nearly sealed, the potential buyer went through a restructuring. At the end of the day, the purchase no longer made sense for either party, and they both walked away, leaving HIBP independent. It sounds like the process was stressful enough that HIBP will remain a independent entity for the foreseeable future.
We’ve seen an abundance of speculative execution vulnerabilities over the last couple of years. While these problems are technically interesting, there has been a bit of a shortage of real-world attacks that leverage those vulnerabilities. Well, thanks to a post over at Google’s Project Zero, that dearth has come to an end. This attack is a sandbox escape, meaning it requires a vulnerability in the Chrome JS engine to be able to pull it off.
To understand how Ridl plays into this picture, we have to talk about how the Chrome sandbox works. Each renderer thread runs with essentially zero system privileges, and sends requests through Mojo, an inter-process communication system. Mojo uses a 128 bit numbering system to both identify and secure those IPC endpoints.
Once an attacker has taken over the unprivileged sandbox process, the next step is to figure out the port name of an un-sandboxed Mojo port. The trick is to get that privileged process to access its Mojo port name repeatedly, and then capture an access using Ridl. Once the port is known, the attacker has essentially escaped the sandbox.
The whole read is interesting, and serves as a great example of the sorts of attacks enabled by speculative execution leaks.
An ideal application for mesh networking is off-grid communication; when there’s no cellular reception and WiFi won’t reach, wide-area technologies like LoRa can be used to create ad hoc wireless networks. Whether you’re enjoying the outdoors with friends or conducting a rescue operation, a cheap and small gadget that will allow you to create such a network and communicate over it would be a very welcome addition to your pack.
That’s exactly the goal of the Meshtastic project, which aims to take off-the-shelf ESP32 LoRa development boards and turn them into affordable mesh network communicators. All you need to do is buy one of the supported boards, install the firmware, and starting meshing. An Android application that will allow you to use the mesh network to send basic text messages is now available as an alpha release, and eventually you’ll be able to run Signal over the LoRa link.
Navigating to another node in the network.
Developer [Kevin Hester] tells us that these are still the very early days, and there’s plenty of work yet to be done. In fact, he’s actively looking to bring a few like-minded individuals onto the project. So if you have experience with the ESP32 or mobile application development, and conducting private communications over long-range wireless networks sounds like your kind of party, this might be your lucky day.
From a user’s perspective, this project is extremely approachable. You don’t need to put any custom hardware together, outside of perhaps 3D printing a case for your particular board. The first time around you’ll need to flash the firmware with esptool.py, but after that, [Kevin] says future updates can be handled by the smartphone application.
Incidentally, the primary difference between the two boards is that the larger and more expensive one includes GPS. The mesh networking side of things will work with either board, but if everyone in your group has the GPS-equipped version, each user will be able to see the position of everyone else in the network.
