This Week In Security: Crash Your IPhone, Hack Your Site, And Bluetooth Woes

There have been some hilarious issues on mobile devices over the years. The HTC Dream had a hidden shell that was discovered when a phone rebooted after sending a text containing just the word “reboot”. iOS has gotten in on the fun from time to time, and this time it’s ""::. Type the double quotes, a colon, and any other character, and Apple’s Springboard service crashes.

Another hacker dug in a bit, and realized that Springboard is trying to jump execution to a null pointer, leading to a crash. It’s very odd that user input breaks the query parser badly enough to jump to null like that. There are a couple interesting questions that we have to ask. Given that the crash trigger is quite flexible, "anything goes":x, is it possible to manipulate that function pointer to be something other than null? And perhaps more importantly, why is the code crashing, instead of an invalid address error as one would expect from a Pointer Authentication Code (PAC) violation? Regardless, the bug seems to be fixed in the latest iOS 18 builds.

Continue reading “This Week In Security: Crash Your IPhone, Hack Your Site, And Bluetooth Woes”

This Week In Security: Three Billion SS Numbers, IPv6 RCE, And Ring -2

You may have heard about a very large data breach, exposing the Social Security numbers of three billion individuals. Now hang on. Social Security numbers are a particularly American data point, and last time we checked there were quite a few Americans shy of even a half of a billion’s worth. As [Troy Hunt] points out, there are several things about this story that seem just a bit odd.

First up, the claim is that this is data grabbed from National Public Data, and there’s even a vague notice on their website about it. NPD is a legitimate business, grabbing data on as many people as possible, and providing services like background checks and credit checks. It’s not impossible that this company has records on virtually every citizen of the US, UK, and Canada. And while that’s far less than 2.9 billion people, it could feasibly add up to 2.9 billion records as was originally claimed.

The story gets strange as we consider the bits of data that have been released publicly, like a pair of files shared with [Troy] that have names, birthdays, addresses, phone numbers, and social security numbers. Those had a total of 2.69 billion records, with an average of 3 records for each ID number. That math is still just a little weird, since the US has to date only generated 450 million SSNs and change.

So far all we have are partial datasets, and claims on the Internet. The story is that there’s a grand total of 4 TB of data once uncompressed. The rest of the details are unclear, and it’s likely to take some time for the rest of the story to come out. Continue reading “This Week In Security: Three Billion SS Numbers, IPv6 RCE, And Ring -2”

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

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

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

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

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

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”