Expired Certificate Causes German Payment Meltdown

For most Hackaday readers the process of buying groceries this weekend has been a relatively painless one, however we’re guessing some of our German friends will have found their cards unexpectedly declined. The reason? A popular model of payment card terminal, the Verifone H5000, has suffered what has been described as a “software malfunction”. So exactly what has happened? The answer is as simple as it is unfortunate: a security certificate for German transaction processing stored on the device has expired.

The full story exposes the flaws in assuming that a payment terminal is an appliance rather than a computer and its associated software that needs updating like any other. The H5000 is an old terminal that ceased production back in the last decade and has reached end-of-life, however it has remained in use and perhaps more seriously, remained in the supply chain to merchants buying a terminal. With updates requiring a site visit rather than an over-the-air upgrade, it’s likely that the effects of this mess could last a while.

In case the hardware for this type of equipment interests you, we’ve had a teardown on another Verifone terminal in the past.

A modified Ghostbusters Proton Pack

Track Down Ghosts In Your WiFi With The Pwnton Pack

If there’s something weird in your Network Neighborhood, who you gonna call? If you want your WiFi troubles diagnosed in style, try calling [Travis Kaun] — he might just show up wearing the amazing Pwnton Pack. Built from a replica Proton Pack similar to those used in the 1984 classic Ghostbusters, it’s a portable wireless security diagnostics kit that should be able to pinpoint any weaknesses in your wireless network.

Inside, it’s got a Mark VII WiFi Pineapple, which is a portable device designed for security testing purposes, as well as a Raspberry Pi running Pwnagotchi: a deep learning-based WiFi sniffer that aims to capture those network packets that help maximize your chances of brute-forcing the WPA key. These two devices are connected to an array of antennas, including a cool rotating 5 GHz panel antenna to scan the surrounding area.

Naturally, the Pwnton Pack also includes a Neutrona Wand, which in this case contains a 2.4 GHz Yagi antenna hooked up to an ESP32 programmed to perform deauthentication attacks. An Arduino Nano drives an LED matrix that shows scrolling Pac-Man ghosts, while a dedicated sound board provides movie sound effects. The whole system is powered by three LiPo battery packs, and can even be remotely operated if desired.

Sadly, it doesn’t come with one of those ghost traps to suck up wayward WiFi networks, but the range of tools available should help to catch any kind of weird phantoms hiding in your system. We’ve spotted a few Proton Packs before, but never one with such advanced functionality. Security testing systems tend to be a bit less conspicuous, after all. Continue reading “Track Down Ghosts In Your WiFi With The Pwnton Pack”

This Week In Security: Good Faith, Easy Forgery, And I18N

There’s a danger in security research that we’ve discussed a few times before. If you discover a security vulnerability on a production system, and there’s no bug bounty, you’ve likely broken a handful of computer laws. Turn over the flaw you’ve found, and you’re most likely to get a “thank you”, but there’s a tiny chance that you’ll get charged for a computer crime instead. Security research in the US is just a little safer now, as the US Department of Justice has issued a new policy stating that “good-faith security research should not be charged.”

While this is a welcome infection of good sense, it would be even better for such a protection to be codified into law. The other caveat is that this policy only applies to federal cases in the US. Other nations, or even individual states, are free to bring charges. So while this is good news, continue to be careful. There are also some caveats about what counts as good-faith — If a researcher uses a flaw discovery to extort, it’s not good-faith.
Continue reading “This Week In Security: Good Faith, Easy Forgery, And I18N”

TurtleAuth DIY Security Token Gets (Re)designed For Durable, Everyday Use

[Samuel]’s first foray into making DIY hardware authentication tokens was a great success, but he soon realized that a device intended for everyday carry and use has a few different problems to solve, compared to a PCB that lives and works on a workbench. This led to TurtleAuth 2.1, redesigned for everyday use and lucky for us all, he goes into detail on all the challenges and solutions he faced.

When we covered the original TurtleAuth DIY security token, everything worked fantastically. However, the PCB layout had a few issues that became apparent after a year or so of daily use. Rather than 3D print an enclosure and call it done, [Samuel] decided to try a different idea and craft an enclosure from the PCB layers themselves.

The three-layered PCB sandwich keeps components sealed away and protected, while also providing a nice big touch-sensitive pad on the top, flanked by status LEDs. Space was a real constraint, and required a PCB redesign as well as moving to 0402 sized components, but in the end he made it work. As for being able to see the LEDs while not having any component exposed? No problem there; [Samuel] simply filled in the holes over the status LEDs with some hot glue, creating a cheap, effective, and highly durable diffuser that also sealed away the internals.

Making enclosures from PCB material can really hit the spot, and there’s no need to re-invent the wheel when it comes to doing so. Our own [Voja Antonic] laid out everything one needs to know about how to build functional and beautiful enclosures in this way.

This Week In Security: IPhone Unpowered, Python Unsandboxed, And Wizard Spider Unmasked

As conspiracy theories go, one of the more plausible is that a cell phone could be running malicious firmware on its baseband processor, and be listening and transmitting data even when powered off. Nowadays, this sort of behavior is called a feature, at least if your phone is made by Apple, with their Find My functionality. Even with the phone off, the Bluetooth chip runs happily in a low-power state, making these features work. The problem is that this chip doesn’t do signed firmware. All it takes is root-level access to the phone’s primary OS to load a potentially malicious firmware image to the Bluetooth chip.

Researchers at TU Darmstadt in Germany demonstrated the approach, writing up a great paper on their work (PDF). There are a few really interesting possibilities this research suggests. The simplest is hijacking Apple’s Find My system to track someone with a powered down phone. The greater danger is that this could be used to keep surveillance malware on a device even through power cycles. Devices tend to be secured reasonably well against attacks from the outside network, and hardly at all from attacks originating on the chips themselves. Unfortunately, since unsigned firmware is a hardware limitation, a security update can’t do much to mitigate this, other than the normal efforts to prevent attackers compromising the OS.
Continue reading “This Week In Security: IPhone Unpowered, Python Unsandboxed, And Wizard Spider Unmasked”

This Week In Security: F5 Twitter PoC, Certifried, And Cloudflare Pages Pwned

F5’s BIG-IP platform has a Remote Code Execution (RCE) vulnerability: CVE-2022-1388. This one is interesting, because a Proof of Concept (PoC) was quickly reverse engineered from the patch and released on Twitter, among other places.

HORIZON3.ai researcher [James Horseman] wrote an explainer that sums up the issue nicely. User authentication is handled by multiple layers, one being a Pluggable Authentication Modules (PAM) module, and the other internally in a Java class. In practice this means that if the PAM module sees an X-F5-Auth-Token, it passes the request on to the Java code, which then validates the token to confirm it as authentic. If a request arrives at the Java service without this header, and instead the X-Forwarded-Host header is set to localhost, the request is accepted without authentication. The F5 authentication scheme isn’t naive, and a request without the X-F5-Auth-Token header gets checked by PAM, and dropped if the authentication doesn’t check out.

So where is the wiggle room that allows for a bypass? Yet another HTTP header, the Connection header. Normally this one only comes in two varieties, Connection: close and Connection: keep-alive. Really, this header is a hint describing the connection between the client and the edge proxy, and the contents of the Connection header is the list of other headers to be removed by a proxy. It’s essentially the list of headers that only apply to the connection over the internet. Continue reading “This Week In Security: F5 Twitter PoC, Certifried, And Cloudflare Pages Pwned”

This Week In Security: UClibc And DNS Poisoning, Encryption Is Hard, And The Goat

DNS spoofing/poisoning is the attack discovered by [Dan Kaminski] back in 2008 that simply refuses to go away. This week a vulnerability was announced in the uClibc and uClibc-ng standard libraries, making a DNS poisoning attack practical once again.

So for a quick refresher, DNS lookups generally happen over unencrypted UDP connections, and UDP is a stateless connection, making it easier to spoof. DNS originally just used a 16-bit transaction ID (TXID) to validate DNS responses, but [Kaminski] realized that wasn’t sufficient when combined with a technique that generated massive amounts of DNS traffic. That attack could poison the DNS records cached by public DNS servers, greatly amplifying the effect. The solution was to randomize the UDP source port used when sending UDP requests, making it much harder to “win the lottery” with a spoofed packet, because both the TXID and source port would have to match for the spoof to work.

uClibc and uClibc-ng are miniature implementations of the C standard library, intended for embedded systems. One of the things this standard library provides is a DNS lookup function, and this function has some odd behavior. When generating DNS requests, the TXID is incremental — it’s predictable and not randomized. Additionally, the TXID will periodically reset back to it’s initial value, so not even the entire 16-bit key space is exercised. Not great. Continue reading “This Week In Security: UClibc And DNS Poisoning, Encryption Is Hard, And The Goat”