Can You Hack The RP2350? There’s $10,000 On The Line

August 12, 2024 by Lewin Day 63 Comments

The Raspberry Pi Foundation had their new RP2350 chip audited by Hextree.io, and now, both companies want to see if you can hack it. Just to prove that they’re serious, they’re putting out a $10,000 bounty. Can you get inside?

The challenge to hack the chip is simple enough. You need to dump a secret that is hidden at OTP ROW 0xc08. It’s 128 bits long, and it’s protected in two ways—by the RP2350’s secure boot and by OTP_DATA_PAGE48_LOCK1. Basically, the chip security features have been activated, and you need to get around them to score the prize.

The gauntlet was thrown down ahead of DEF CON, where the new chip was used in the event badges. Raspberry Pi and Hextree.io invited anyone finding a break to visit their booth in the Embedded Systems Village. It’s unclear at this stage if anyone claimed the bounty, so we can only assume the hunt remains open. It’s been stated that the challenge will run until 4 PM UK time on September 7th, 2024.

Hacking microcontrollers is a tough and exacting art. The GitHub repo provides full details on what you need to do, with the precise rules, terms, and conditions linked at the bottom. You can also watch the challenge video on Hextree.io.

This Week In Security: GhostWrite, Localhost, And More

August 9, 2024 by Jonathan Bennett 5 Comments

You may have heard some scary news about RISC-V CPUs. There’s good news, and bad news, and the whole thing is a bit of a cautionary tale. GhostWrite is a devastating vulnerability in a pair of T-Head XuanTie RISC-V CPUs. There are also unexploitable crashes in another T-Head CPU and the QEMU soft core implementation. These findings come courtesy of a group of researchers at the CISPA Helmholtz Center for Information Security in Germany. They took at look at RISC-V cores, and asked the question, do any of these instructions do anything unexpected? The answer, obviously, was “yes”.

Undocumented instructions have been around just about as long as we’ve had Van Neumann architecture processors. The RISC-V ISA put a lampshade on that reality, and calls them “vendor specific custom ISA extensions”. The problem is that vendors are in a hurry, have limited resources, and deadlines wait for no one. So sometimes things make it out the door with problems. To find those problems, CISPA researchers put together a test framework is called RISCVuzz, and it’s all about running each instruction on multiple chips, and watching for oddball behavior. They found a couple of “halt-and-catch-fire” problems, but the real winner (loser) is GhostWrite.

Now, this isn’t a speculative attack like Meltdown or Spectre. It’s more accurate to say that it’s a memory mapping problem. Memory mapping helps the OS keep programs independent of each other by giving them a simplified memory layout, doing the mapping from each program to physical memory in the background. There are instructions that operate using these virtual addresses, and one such is vs128.v. That instruction is intended to manipulate vectors, and use virtual addressing. The problem is that it actually operates directly on physical memory addresses, even bypassing cache. That’s not only memory, but also includes hardware with memory mapped addresses, entirely bypassing the OS. This instruction is the keys to the kingdom. Continue reading “This Week In Security: GhostWrite, Localhost, And More” →

This Week In Security: Echospoofing, Ransomware Records, And Github Attestations

August 2, 2024 by Jonathan Bennett 5 Comments

It’s a bit of bitter irony, when a security product gets used maliciously, to pull off the exact attack it was designed to prevent. Enter Proofpoint, and the EchoSpoofing attack. Proofpoint offers an email security product, filtering spam and malicious incoming emails, and also handling SPF, DKIM, and DMARC headers on outgoing email. How does an external service provide those email authentication headers?

One of the cardinal sins of running an email server is to allow open relaying. That’s when anyone can forward email though an SMTP server without authentication. What we have here is two nearly open relays, that wound up with spoofed emails getting authenticated just like the real thing. The first offender is Microsoft’s Office365, which seems to completely skip checking for email spoofing when using SMTP relaying from an allowed IP address. This means a valid Office365 account allows sending emails as any address. The other half relies on the way Proofpoint works normally, accepting SMTP traffic from certain IP addresses, and adding the authentication headers to those emails. There’s an option in Proofpoint to add the Microsoft Office 365 servers to that list, and apparently quite a few companies simply select that option.

The end result is that a clever spammer can send millions of completely legitimate looking emails every day, that look very convincing even to sophisticated users. At six months of activity, averaging three millions emails a day, this campaign managed just over half a billion malicious emails from multiple high-profile domains.

The good news here is that Proofpoint and Guardio discovered the scheme, and worked with Microsoft to develop the X-OriginatorOrg header that is now applied to every email sent from or through the Office365 servers. This header marks the account tenant the email belongs to, giving vendors like Proofpoint a simple way to determine email validity. Continue reading “This Week In Security: Echospoofing, Ransomware Records, And Github Attestations” →

This Week In Security: EvilVideo, Crowdstrike, And InSecure Boot

July 26, 2024 by Jonathan Bennett 12 Comments

First up this week is the story of EvilVideo, a clever telegram exploit that disguises an APK as a video file. The earliest record we have of this exploit is on June 6th when it was advertised on a hacking forum.

Researchers at ESET discovered a demo of the exploit, and were able to disclose it to Telegram on June 26th. It was finally patched on July 11. While it was advertised as a “one-click” exploit, that’s being a bit generous, as the ESET demo video shows. But it was a clever exploit. The central trick is that an APK file can be sent in a Telegram chat, and it displays what looks like a video preview. Tap the “video” file to watch it, and Telegram prompts you to play it with an external player. But it turns out the external player in this case is Android itself, which prompts the target to install the APK. Sneaky.

Continue reading “This Week In Security: EvilVideo, Crowdstrike, And InSecure Boot” →

Hacking An IoT Camera Reveals Hard-Coded Root Password

July 24, 2024 by Dan Maloney 24 Comments

Hacking — at least the kind where you’re breaking into stuff — is very much a learn-by-doing skill. There’s simply no substitute for getting your hands dirty and just trying something. But that doesn’t mean you can’t learn something by watching, with this root password exploit on a cheap IP video camera being a good look at the basics.

By way of background on this project, [Matt Brown] had previously torn into a VStarcam CB73 security camera, a more or less generic IP camera that he picked up on the cheap, and identified a flash memory chip from which he extracted the firmware. His initial goal was to see if the camera was contacting sketchy servers, and while searching the strings for the expected unsavory items, he found hard-coded IP addresses plus confirmation that the camera was running some Linux variant.

With evidence of sloppy coding practices, [Matt] set off on a search for a hard-coded root password. The second video covers this effort, which started with finding UART pins and getting a console session. Luckily, the bootloader wasn’t locked, which allowed [Matt] to force the camera to boot into a shell session and find the root password hash. With no luck brute-forcing the hash, he turned to Ghidra to understand the structure of a suspicious program in the firmware called encoder. After a little bit of poking and some endian twiddling, he was able to identify the hard-coded root password for every camera made by this outfit, and likely others as well.

Granted, the camera manufacturer made this a lot easier than it should have been, but with a lot of IoT stuff similarly afflicted by security as an afterthought, the skills on display here are probably broadly applicable. Kudos to [Matt] for the effort and the clear, concise presentation that makes us want to dig into the junk bin and get hacking.

Continue reading “Hacking An IoT Camera Reveals Hard-Coded Root Password” →

This Week In Security: Snowflake, The CVD Tension, And Kaspersky’s Exit — And Breaking BSOD

July 19, 2024 by Jonathan Bennett 37 Comments

In the past week, AT&T has announced an absolutely massive data breach. This is sort of a multi-layered story, but it gives me an opportunity to use my favorite piece of snarky IT commentary: The cloud is a fancy way to talk about someone else’s servers. And when that provider has a security problem, chances are, so do you.

The provider in question is Snowflake, who first made the news in the Ticketmaster breach. As far as anyone can tell, Snowflake has not actually been directly breached, though it seems that researchers at Hudson Rock briefly reported otherwise. That post has not only been taken down, but also scrubbed from the wayback machine, apparently in response to a legal threat from Snowflake. Ironically, Snowflake has confirmed that one of their former employees was compromised, but Snowflake is certain that nothing sensitive was available from the compromised account.

At this point, it seems that the twin problems are that big organizations aren’t properly enforcing security policy like Two Factor Authentication, and Snowflake just doesn’t provide the tools to set effective security policy. The Mandiant report indicates that all the breaches were the result of credential stealers and other credential-based techniques like credential stuffing. Continue reading “This Week In Security: Snowflake, The CVD Tension, And Kaspersky’s Exit — And Breaking BSOD” →

Linksys Velop Routers Caught Sending WiFi Creds In The Clear

July 15, 2024 by Tom Nardi 14 Comments

A troubling report from the Belgian consumer protection group Testaankoop: several models of Velop Pro routers from Linksys were found to be sending WiFi configuration data out to a remote server during the setup process. That would be bad enough, but not only are these routers reporting private information to the mothership, they are doing it in clear text for anyone to listen in on.

Testaankoop says that while testing out the Pro WiFi 6E and Pro 7 versions of Velop routers, they discovered that unencrypted packets were being sent to a server hosted by Amazon Web Services (AWS). In these packets, they discovered not only the SSID of the user’s wireless network, but the encryption key necessary to join it. There were also various tokens included that could be used to identify network and user.

While the report doesn’t go into too much detail, it seems this information is being sent as part of the configuration process when using the official Linksys mobile application. If you want to avoid having your information bounced around the Internet, you can still use the router’s built-in web configuration menus from a browser on the local network — just like in the good old days.

The real kicker here is the response from Linksys, or more accurately, the lack thereof. Testaankoop says they notified them of their discovery back in November of 2023, and got no response. There’s even been firmware updates for the affected routers since then, but the issue is still unresolved.

Testaankoop ends the review by strongly recommending users avoid these particular models of Linksys Velop routers, which given the facts, sounds like solid advice to us. They also express their disappointment in how the brand, a fixture in the consumer router space for decades, has handled the situation. If you ask us, things started going downhill once they stopped running Linux on their hardware.