Security Hacks

1465 Articles

This Week In Security:Breaking CACs To Fix NTLM, The Biggest Leak Ever, And Fixing Firefox By Breaking It

July 8, 2022 by 16 Comments

To start with, Microsoft’s June Security Patch has a fix for CVE-2022-26925, a Man-In-The-Middle attack against NTLM. According to NIST, this attack is actively being exploited in the wild, so it landed on the KEV (Known Exploited Vulnerabilities) Catalog. That list tracks the most important vulnerabilities to address, and triggers a mandated patch install no later than July 22nd. The quirk here is that the Microsoft Patch that fixes CVE-2022-26925 also includes a fix for a couple certificate vulnerabilities including CVE-2022-2693, Certifried. That vulnerability was one where a machine certificate could be renamed to the same as a domain controller, leading to organization-wide compromise.

The fix that rolled out in June now requires that a “strong certificate mapping” be in place to tie a user to a certificate. Having the same common name is no longer sufficient, and a secure value like the Security IDentifier (SID) must be mapped from certificate to user in Active Directory. The patch puts AD in a compatibility mode, which accepts the insecure mapping, so long as the user account predates the security certificate. This has an unintended consequence of breaking how the US Government uses CACs (Common Access Cards) to authenticate their users. Government agencies typically start their onboarding by issuing a CAC, and then establishing an AD account for that user. That makes the certificate older, which means the newest patch rejects it. Thankfully there’s a registry key that can be set, allowing the older mapping to still work, though likely with a bit of a security weakness opened up as a result. Continue reading “This Week In Security:Breaking CACs To Fix NTLM, The Biggest Leak Ever, And Fixing Firefox By Breaking It” →

A Honda car behind a gate, with its turn signals shown blinking as it's being unlocked by a portable device implementing the hack in question. Text under the car says "Rolling Pwned".

Unlock Any (Honda) Car

July 8, 2022 by 76 Comments

Honda cars have been found to be severely  vulnerable to a newly published Rolling PWN attack, letting you remotely open the car doors or even start the engine. So far it’s only been proven on Hondas, but ten out of ten models that [kevin2600] tested were vulnerable, leading him to conclude that all Honda vehicles on the market can probably be opened in this way. We simply don’t know yet if it affects other vendors, but in principle it could. This vulnerability has been assigned the CVE-2021-46145.

[kevin2600] goes in depth on the implications of the attack but doesn’t publish many details. [Wesley Li], who discovered the same flaw independently, goes into more technical detail. The hack appears to replay a series of previously valid codes that resets the internal PRNG counter to an older state, allowing the attacker to reuse the known prior keys. Thus, it requires some eavesdropping on previous keyfob-car communication, but this should be easy to set up with a cheap SDR and an SBC of your choice.

If you have one of the models affected, that’s bad news, because Honda probably won’t respond anyway. The researcher contacted Honda customer support weeks ago, and hasn’t received a reply yet. Why customer support? Because Honda doesn’t have a security department to submit such an issue to. And even if they did, just a few months ago, Honda has said they will not be doing any kind of mitigation for “car unlock” vulnerabilities.

As it stands, all these Honda cars affected might just be out there for the taking. This is not the first time Honda is found botching a rolling code implementation – in fact, it’s the second time this year. Perhaps, this string of vulnerabilities is just karma for Honda striking down all those replacement part 3D models, but one thing is for sure – they had better create a proper department for handling security issues.

This Week In Security: Zimbra RCE, Routers Under Attack, And Old Tricks In WebAssembly

July 1, 2022 by 8 Comments

There’s a problem in the unrar utility, and as a result, the Zimbra mail server was vulnerable to Remote Code Execution by simply sending an email. So first, unrar is a source-available command-line application made by RarLab, the same folks behind WinRAR. CVE-2022-30333 is the vulnerability there, and it’s a classic path traversal on archive extraction. One of the ways this attack is normally pulled off is by extracting a symlink to the intended destination, which then points to a location that should be restricted. unrar has code hardening against this attack, but is sabotaged by its cross-platform support. On a Unix machine, the archive is checked for any symbolic links containing the ../ pattern. After this check is completed, a function runs to convert any Windows paths to Unix notation. As such, the simply bypass is to include symlinks using ..\ traversal, which don’t get caught by the check, and then are converted to working directories.

That was bad enough, but Zimbra made it worse by automatically extracting .rar attachments on incoming emails, in order to run a virus and spam check. That extraction isn’t sandboxed, so an attacker’s files are written anywhere on the filesystem the zimbra user can write. It’s not hard to imagine how this turns into a full RCE very quickly. If you have an unrar binary based on RarLab code, check for version 6.1.7 or 6.12 of their binary release. While Zimbra was the application specifically called out, there are likely to be other cases where this could be used for exploitation.
Continue reading “This Week In Security: Zimbra RCE, Routers Under Attack, And Old Tricks In WebAssembly” →

This Week In Security: IoT In The Hot Tub, App Double Fail, And FreeBSD BadBeacon

June 24, 2022 by 3 Comments

[Eaton Zveare] purchased a Jacuzzi hot tub, and splurged for the SmartTub add-on, which connects the whirlpool to the internet so you can control temperature, lights, etc from afar. He didn’t realize he was about to discover a nightmare of security problems. Because as we all know, in IoT, the S stands for security. In this case, the registration email came from smarttub.io, so it was natural to pull up that URL in a web browser to see what was there. The page presented a login prompt, so [Eaton] punched in the credentials he had just generated. “Unauthorized” Well that’s not surprising, but what was very odd was the flash of a dashboard that appeared just before the authorization complaint. Could that have been real data that was unintentionally sent? A screen recorder answered that question, revealing that there was indeed a table loaded up with valid-looking data.

Digging around in the page’s JavaScript comes up with the login flow. The page uses the Auth0 service to handle logins, and that service sends back an access token. The page sends that access token right back to the Auth0 service to get user privileges. If the logged in user isn’t an admin, the redirect happens. However, we already know that some real data gets loaded. It appears that the limitations to data is all implemented on the client side, and the backend only requires a valid access token for data requests. What would happen if the response from Auth0 were modified? There are a few approaches to accomplish this, but he opted to use Fiddler. Rewrite the response so the front-end believes you’re an admin, and you’re in.

This approach seems to gain admin access to all of the SmartTub admin controls, though [Eaton] didn’t try actually making changes to see if he had write access, too. This was enough to demonstrate the flaw, and making changes would be flirting with that dangerous line that separates research from computer crime. The real problem started when he tried to disclose the vulnerability. SmartTub didn’t have a security contact, but an email to their support email address did elicit a reply asking for details. And after details were supplied, complete radio silence. Exasperated, he finally turned to Auth0, asking them to intervene. Their solution was to pull the plug on one of the two URL endpoints. Finally, after six months of trying to inform Jacuzzi and SmartTub of their severe security issues, both admin portals were secured.

Continue reading “This Week In Security: IoT In The Hot Tub, App Double Fail, And FreeBSD BadBeacon” →

HDMI Is An Attack Surface, So Here’s An HDMI Firewall

June 22, 2022 by 13 Comments

Many years of using televisions, monitors, and projectors have conditioned us into treating them as simple peripherals whose cables carry only video. A VGA cable may have an i2c interface for monitor detection, but otherwise it presents little security risk. An HDMI interface on the other hand can carry an increasing number of far more capable ports, meaning that it has made the leap from merely a signal cable to being a connector stuffed with interesting attack vectors for a miscreant. Is it time for an HDMI firewall? [King Kévin] thinks so, because he’s made one.

It’s a surprisingly simple device, because the non-signal capabilities of HDMI rely on a set of conductors which are simply not connected. This of course also disconnects the on-board EEPROM in the device being connected, so there’s an EEPROM on the firewall board to replace it which must be programmed with the information for the device in question.

The premise of HDMI as an attack surface is a valid one, and we’re sure there will be attacks that can be performed on vulnerable displays which could potentially in turn do naughty things to anything which connects to them. The main value for most readers here probably lies though in the introduction it gives to some of what goes into an HDMI interface, and in accessing the i2c interface therein.

It comes as a surprise to realise that HDMI is nearing 20 years old, so it’s hardly surprising that its hacking has quite a history.

Build Your Own Two-Factor Authenticator With Good USB

June 18, 2022 by 19 Comments

Two-factor authentication is becoming the norm for many applications and services, and security concerns around phone porting hacks are leading to a phaseout of SMS-based systems. Amidst that backdrop, [Josh] developed his own authentication device by the name of Good USB.

The device can be built using a Arduino Leonardo, SS Micro, or even a BadUSB device. It’s the latter which [Josh] most liked, and since the nefarious device is being repurposed for good, it led to the name Good USB. Basically any Atmega32U4-based device will work, as the key functionality is the ability to emulate a USB keyboard to a host PC.

Using the device is just as simple. With the Good USB plugged in, one simply needs to click a button in the companion app to generate a code for the given account you’re logging in to. Pressing the button on the device then types in the code for you. Alternatively, if your device has no button, it can be set up to simply type the code two seconds after you select an account in the companion app.

The code is on Github for those wishing to make their own. Caveat for the cautious: it’s still a work in progress, and there may be security holes in the current implementation.

If you’re interested in the nuts and bolts of how 2FA works, we’ve looked into that in detail. Video after the break.

Continue reading “Build Your Own Two-Factor Authenticator With Good USB” →

Your Building’s RFID Access Tags Might Be Really Insecure

June 17, 2022 by 20 Comments

[Gabe Schuyler] had a frustrating problem when it came to getting into his building’s garage. The RFID access system meant he had to remove his gloves while sitting on his motorcycle to fish out the keytag for entry. He decided to whip up a better solution with less fuss.

His initial plan was to duplicate the keytag and to sew one into his gloves. Purchasing a 125 KHz RFID tag duplicator off eBay, he was able to quickly copy the tag, and create one that worked with his garage’s entry system. While the duplicate tags worked well, they were still too big to easily fit into a glove. Attempts to create a duplicate with a smaller tag failed, too. Eventually, [Gabe] turned up a ring complete with a compatible RFID chip, and was able to duplicate his entry tag onto that. Now, by wearing the ring, he can enter his garage and building with a simple wave of the hand, gloves on or off.

Of course, duplicating an RFID tag is no major hack. As per [Gabe]’s Shmoocon talk on the topic, however, it shows that many buildings are using completely insecure RFID access methods with little to no security whatsoever. Anyone that found an access tag lying on the ground could easily replicate as many as they wanted and enter the building unimpeded. It also bears noting that you can snoop RFID cards from further away than you might expect.