The Cheap Way To Glitch An STM8 Microcontroller

July 4, 2020 by Moritz v. Sivers 18 Comments

Reverse engineering or modifying a device often requires you to access the firmware stored on a microcontroller. Since companies are usually not fond of people who try to peek into their proprietary data, most commercial devices are readout protected. [rumpeltux] ran into this problem when he tried to dump the firmware on an HC-12 wireless serial communication module for yet undisclosed reasons. Hacking into the device was a challenge that he gladly accepted and in the end, he succeeded by building a low-cost setup for voltage glitching.

Voltage glitching is a form of fault injection that has, e.g., been successfully used to hack the Playstation Vita. It involves the injection of voltage spikes on the power line in order to force the bootloader to skip security checks. The hard thing is trying to find the right shape of the waveform and the best way to inject the signal.

While there are already open-source boards for fault injection like ChipWhisperer, [rumpeltux] chose to build his own setup around an FPGA. By using a cheap EPM240 board, some MOSFET, and a USB-to-Serial converter, the total costs of the glitching setup were under 20 Euros. [rumpeltux] then recorded a larger number of voltage traces on the VCC pin around the reset phase and analyzed the differences. This helped him to pinpoint the best time for injecting the signal and refine the search space. After some unsuccessful attempts to glitch the VCC and GND pins, he got lucky when using one of the voltage regulator pins instead.

Be sure not to miss Samy Kamkar’s talk at Supercon 2019 if you want to know more about hardware attacks or how to eavesdrop on people using a bag of potato chips.

This Week In Security: Palo Alto Scores A 10, Cursed Images, VM Escapes, And Malicious Music

July 3, 2020 by Jonathan Bennett 12 Comments

We’ve looked at many vulnerabilities over the years here on Hackaday, but it’s rather rare for a CVE to score a perfect 10 severity. This is reserved for the most severe and exploitable of problems. Palo Alto announced such a vulnerability, CVE-2020-2021, on the 29th. This vulnerability affects Palo Alto devices running PAN-OS that have SAML authentication enabled and a certain validation option disabled. The vulnerability is pre-authentication, but does require access to a service protected by SAML authentication. For example, a Palo Alto device providing a web-based VPN could be vulnerable. The good news is that the vulnerable settings aren’t default, but the bad news is that the official configuration guide recommends the vulnerable settings for certain scenarios, like using a third party authentication service.

The issue is in the Security Assertion Markup Language (SAML) implementation, which is an XML based open standard for authentication. One of the primary use cases for SAML is to provide a Single Sign On (SSO) scheme. The normal deployment of SAML SSO is that a central provider handles the authentication of users, and then asserts to individual services that the connecting user is actually who they claim to be.

The setting needed for this vulnerability to be exploitable is ‘Validate Identity Provider Certificate’ to be disabled. If this option is enabled, the SSO provider must use a CA signed SAML certificates. This doesn’t appear to mean that unsigned SSL certificates would be accepted, and only applies to certificates inside the SAML messages. It seems to be widely accepted that these certificates don’t need to be CA signed. In the official announcement, the vulnerability type is said to be “CWE-347 Improper Verification of Cryptographic Signature”. Continue reading “This Week In Security: Palo Alto Scores A 10, Cursed Images, VM Escapes, And Malicious Music” →

Easy, Secure HTTPS With An ESP8266

July 2, 2020 by Rich Hawkes 34 Comments

Security has always been an issue with IoT devices. Off the shelf devices often have terrible security while DIY solutions can be complicated, needing recompilation every time a website’s fingerprint changes. [Johannes] wrote in to let us know he’s been working on a way to make HTTPS requests easier to do on ESP devices.

The normal ways to do HTTPS with an ESP8266 is to either use Fingerprints, or to use client.setInsecure(). Fingerprints require the user to know exactly which pages the ESP will connect to and extract the Fingerprints from each of those websites. Since the fingerprints change yearly, this means the fingerprint will have to be re-extracted and the code recompiled each time a fingerprint changes. The use of client.setInsecure() is, obviously, insecure. This may not be an issue for your project, but it might be for others.

[Johannes’] solution is to extract the trusted root certificates and store them in PROGMEM. This allows access to any web page, but the root certificates do expire as well. As opposed to the fingerprints, though, they expire after 20 years, rather than every year, so the program can run for a long time before needing recompilation. This solution also doesn’t require any manual steps – the build process runs a script that grabs the certificates and stores them in files so that they can be ~~uploaded to the SPIFFS~~ written to PROGMEM to be used during HTTPS requests.

He’s come up with a fairly straightforward way to have your IoT device connect to whichever web page you want, without having to recompile every once in a while. Hopefully, this will lead to better security for your IoT devices. Take a look at some previous work in this area.

Pop Open Your Neighbor’s Front Door With 12 Volts

July 1, 2020 by Tom Nardi 57 Comments

Many in the community are skeptical about the security of commercial smart home devices, and for good reason. It’s not like you have to look far to find examples of poorly implemented systems, or products that are abandoned by their manufacturers and left without critical security updates. But the design flaw in this video doorbell really drives home how little thought some companies give to their customer’s security.

As explained by [Savvas], and demonstrated in the video after the break, all you need to do if you want to get into a home equipped with one of these vulnerable door bells is pop the unit off the wall and hit it with 12 volts DC.

Incredibly, the terminals that connect to the electronic lock inside the house are completely accessible on the back of the unit. They even labeled them, on the off-chance the robber forgets which wire is which. It’s not even as though the thing is held on with some kind of weird security screws, it’s just a garden variety Phillips.

In the video, [Savvas] even shows he used a little gadget attached to a QuickCharge USB battery bank to get a portable 12 VDC source suitable for tripping these locks. Which, interestingly enough, is based on a trick he read about in the Hackaday comments. Something to consider while penning your next comment on these storied pages.

[Savvas] says he’s reached out to the company to get their side of the story, but so far, hasn’t received a response. We aren’t surprised, this is a fundamental flaw in the product’s execution. Clearly they wanted to make an easy to install device that doesn’t require any additional electronics in the house, and this is the inevitable end result of that oversimplification. All the more reason to roll your own smart doorbell.

Continue reading “Pop Open Your Neighbor’s Front Door With 12 Volts” →

This Week In Security: Bitdefender, Ripple20, Starbucks, And Pwned Passwords

June 26, 2020 by Jonathan Bennett 13 Comments

[Wladimir Palant] seems to be on a one man crusade against security problems in security software. The name may not be immediately recognizable, but among his other infamies is originating Adblock Plus, which we have a love-hate relationship with. (Look, surf the net with an adblocker, but disable it for sites you trust and want to support, like HaD).

This week, he announced a rather serious flaw in the Bitdefender. The disclosure starts off with high praise for the Bitdefender: “security-wise Bitdefender Antivirus is one of the best antivirus products I’ve seen so far….” Even with that said, the vulnerability he found is a serious one. A malicious website can trigger the execution of arbitrary applications. The problem was fixed in an update released on the 22nd.

The vulnerability is interesting. First, Bitdefender uses an API that was added to web browsers specifically to enable security software to work without performing man-in-the-middle decryption of HTTPS connections. When a problem is detected, Bitdefender replaces the potentially malicious page with it’s own error message.

Because of the way this is implemented, the browser sees this error message as being the legitimate contents of the requested site. Were this a static page, it wouldn’t be a problem. However, Bitdefender provides an option to load the requested page anyway, and does this by embedding tokens in that error page. When a user pushes the button to load the page, Bitdefender sees the matching tokens in the outgoing request, and allows the page. Continue reading “This Week In Security: Bitdefender, Ripple20, Starbucks, And Pwned Passwords” →

Is Anything Really Private Anymore?

June 26, 2020 by Orlando Hoilett 53 Comments

In the connected age, every day it appears privacy is becoming more and more of an idealistic fantasy as opposed to a basic human right. In our latest privacy debate per [TechCrunch], apparently the FBI is taking some shots at Apple.

You may recall the unfortunate events, leading the FBI to ask Apple to unlock an iPhone belonging to a person of interest. Apple did not capitulate to the FBI’s request on the basis of their fundamental commitment to privacy. The FBI wasn’t really thrilled with Apple’s stance given the circumstances leading to the request. Nevertheless, eventually, the FBI was able to unlock the phone without Apple’s help.

You may find it somewhat interesting that the author of the news piece appears to be more upset with the FBI for cracking the phone than at Apple (and by extension other tech companies) for making phones that are crackable to begin with.

Maybe we should take solace in knowing that Apple stood their ground for the sake of honoring their privacy commitment. But as we saw, it didn’t really matter in the end as the FBI was able to hire a third party to help them unlock the phones and were later able to repeat the process in-house. The article also noted that there are other private companies capable of doing exactly what the FBI did. We understand that no encryption is 100% safe. So it begs the question, “Is anything really private anymore?” Share your thoughts in the comments below.

This Week In Security: HaveIBeenPwned And Facebook Attack Their Customers

June 19, 2020 by Jonathan Bennett 27 Comments

We’re fans of haveibeenpwned.com around here, but a weird story came across my proverbial desk this week — [Troy Hunt] wrote a malicious SQL injection into one of their emails! That attack string was a simple ';--

Wait, doesn’t that look familiar? You remember the header on the haveibeenpwned web page? Yeah, it’s ';--have i been pwned?. It’s a clever in-joke about SQL injection that’s part of the company’s brand. An automated announcement was sent out to a company that happened to use the GLPI service desk software. That company, which shall not be named for reasons that are about to become obvious, was running a slightly out-of-date install of GLPI. That email generated an automated support ticket, which started out with the magic collection of symbols. When a tech self-assigned the ticket, the SQL injection bug was triggered, and their entire ticket database was wiped out. The story ends happily, thanks to a good backup, and the company learned a valuable lesson. Continue reading “This Week In Security: HaveIBeenPwned And Facebook Attack Their Customers” →