This Week In Security: LastPass Shoe Drops, Keys Lost, And Train Whistles Attack

September 8, 2023 by Jonathan Bennett 8 Comments

There has been a rash of cryptocurrency thefts targeting some unexpected victims. Over $35 million has been drained from just over 150 individuals, and the list reads like a who’s-who of the least likely to fall for the normal crypto scams. There is a pattern that has been noticed, that almost all of them had a seed phrase stored in LastPass this past November when the entire LastPass database was breached.

The bulletproof security of the LastPass system depends in part on the rate limiting of authenticating with the LastPass web service. Additionally, accounts created before security improvements in 2018 may have had master passwords shorter than 12 characters, and the hash iterations on those accounts may have been set distressingly low. Since attackers have had unrestricted access to the database, they’ve been able to run offline attacks against accounts with very low iterations, and apparently that approach has been successful.

Microsoft’s Signing Key

You may remember a story from a couple months ago, where Microsoft found the Chinese threat group, Storm-0558, forging authentication tokens using a stolen signing key. There was a big open question at that point, as to how exactly an outside group managed to access such a signing key.

This week we finally get the answer. A crash log from 2021 unintentionally included the key, and Microsoft’s automated redaction system didn’t catch it. That crash dump was brought into development systems, and an engineer’s account was later accessed by Storm-0558. That key should not have worked for enterprise accounts, but a bug in a Microsoft key validation allowed the consumer systems key to work for enterprise accounts. Those issues have been fixed, but after quite a wild ride. Continue reading “This Week In Security: LastPass Shoe Drops, Keys Lost, And Train Whistles Attack” →

Bespoke Implants Are Real—if You Put In The Time

September 6, 2023 by Brian McEvoy 23 Comments

A subset of hackers have RFID implants, but there is a limited catalog. When [Miana] looked for a device that would open a secure door at her work, she did not find the implant she needed, even though the lock was susceptible to cloned-chip attacks. Since no one made the implant, she set herself to the task. [Miana] is no stranger to implants, with 26 at the time of her talk at DEFCON31, including a couple of custom glowing ones, but this was her first venture into electronic implants. Or electronics at all. The full video after the break describes the important terms.

The PCB antenna in an RFID circuit must be accurately tuned, which is this project’s crux. Simulators exist to design and test virtual antennas, but they are priced for corporations, not individuals. Even with simulators, you have to know the specifics of your chip, and [Miana] could not buy the bare chips or find a datasheet. She bought a pack of iCLASS cards from the manufacturer and dissolved the PVC with acetone to measure the chip’s capacitance. Later, she found the datasheet and confirmed her readings. There are calculators in lieu of a simulator, so there was enough information to design a PCB and place an order.

The first batch of units can only trigger the base station from one position. To make the second version, [Miana] bought a Vector Network Analyzer to see which frequency the chip and antenna resonated. The solution to making adjustments after printing is to add a capacitor to the circuit, and its size will tune the system. The updated design works so a populated board is coated and implanted, and you can see an animated loop of [Miana] opening the lock with her bare hand.

Biohacking can be anything from improving how we read our heart rate to implanting a Raspberry Pi.

Continue reading “Bespoke Implants Are Real—if You Put In The Time” →

This Week In Security: Not A Vulnerability, BGP Bug Propogation, And Press Enter To Hack

September 1, 2023 by Jonathan Bennett 6 Comments

Curl was recently notified of a CVE, CVE-2020-19909, rated at a hair-raising 9.8 on the CVSS scale. And PostgreSQL has CVE-2020-21469, clocking in with a 7.5 severity. You may notice something odd about those two vulnerabilities, but I promise the 2020 date is only the tip of the iceberg here.

Let’s start with PostgreSQL. That vulnerability was only present in version 12.2, which released in February of 2020, and was fixed with the 12.3 release in May of that same year. The problem is a stack buffer overflow, which doesn’t seem to enable code execution, but does cause a denial of service situation. To trigger the bug? Repeatedly send the PostgreSQL daemon the SIGHUP signal.

If you’re familiar with Linux signals, that might sound odd. See, the SIGHUP signal technically indicates the end of a user session, but most daemons use it to indicate a restart or reload request. And to send this signal, a user has to have elevated privileges — elevated enough to simply stop the daemon altogether. Put simply, it’s not a security vulnerability, just a minor bug.

And now on to curl — This one is just bizarre. The issue is a integer overflow in the --retry-delay argument, which specifies in seconds how often curl should retry a failing download. The value is multiplied by 1000 to convert to milliseconds, resulting in an overflow for very large values. The result of that overflow? A smaller value for the retry delay.

[Daniel Stenberg] makes the point that this tale is a wonderful demonstration of the brokenness of the CVE system and NVD’s handling of it. And in this case, it’s hard not to see this as negligence. We have to work really hard to construct a theoretical scenario where this bug could actually be exploited. The best I’ve been able to come up with is an online download tool, where the user can specify part of the target name and a timeout. If that tool had a check to ensure that the timeout was large enough to avoid excess traffic, this bug could bypass that check. Should we be assigning CVEs for that sort of convoluted, theoretical attack?

But here’s the thing, that attack scenario should rate something like a CVSS of 4.8 at absolute worst. NVD assigned this a 9.8. There’s no way you can squint at this bug hard enough to legitimately rank it that severe. At the time of writing, the NVD lists this as “UNDERGOING REANALYSIS”.
Continue reading “This Week In Security: Not A Vulnerability, BGP Bug Propogation, And Press Enter To Hack” →

Diving Into Starlink’s User Terminal Firmware

August 31, 2023 by Maya Posch 6 Comments

The average Starlink user probably doesn’t spend a lot of time thinking about their hardware after getting the dish aligned and wiring run. To security researchers, however, it’s another fascinating device to tinker with as they reverse-engineer the firmware and try to both find out what makes it tick, as well as how to break it. This is essentially the subject of [Carlo Ramponi]’s article over at Quarkslab as he digs into the firmware architecture and potential weaknesses in its internal communication.

The user terminal hardware itself is a quite standard AArch64 ARM-based SoC, along with the proprietary communication interface, all of which is controlled by the Linux-based firmware. Dumping the firmware itself was made easy thanks to existing work by researchers at the KU Leuven, involving dumping the contents of the onboard eMMC storage. After this the firmware architecture could be analyzed, which turned out to consist out of mostly C++-based binaries, but with a single big binary for the user front-end written in Go.

Communication between these processes is handled through a custom inter-process protocol called ‘Slate Sharing’, all of which is coordinated via the core User Terminal Control process. It are these Slate IPC messages which form the most likely attack surface for a fuzzing attack, with the SoftwareUpdateRequest command being an interesting target as it would seem to not require authentication since it doesn’t address a specific user. This work is part of [Carlo]’s master’s thesis, and should form the basis of further research on the Starlink User Terminal firmware.

GTA 6 Hacker Found To Be Teen With Amazon Fire Stick In Small Town Hotel Room

August 26, 2023 by Jenny List 115 Comments

International cybercrime, as portrayed by the movies and mass media, is a high-stakes game of shadowy government agencies and state-sponsored hacking groups. Hollywood casting will wheel out a character in a black hoodie and shades, probably carrying a metallic briefcase as they board an executive jet.

These things aren’t supposed to happen in a cheap hotel room in your insignificant hometown, but the story of a British teen being nabbed leaking the closely guarded details of Grand Theft Auto 6 in a Travelodge room in Bicester, Oxfordshire brings the action from the global into the local for a Hackaday scribe. Bicester is a small town best known for a tacky outlet mall and as a commuter dormitory stop on the line to London Marylebone, it’s not exactly Vice City.

The teen in question is one [Arion Kurtaj], breathlessly reported by the BBC as part of the Lapsus$ gang, which is a sensationalist way of talking up a group of kids expert at computer infiltration but seemingly inept at being criminals. After compromising British telcos he was exposed by another group and nabbed by the authorities, before being moved to the hotel for his own safety.

Here the story becomes more interesting for Hackaday readers, because though denied access to a computer he purchased an Amazon Fire stick presumably at the Argos in the Sainsburys next door, and plugged it into the Travelodge TV. Using this he was able to access cloud services, we’re guessing a virtual Linux environment or similar, before continuing to compromise further organisations including Rockstar Games to leak that GTA 6 footage. He’s yet to be sentenced, but we’re guessing that he’ll continue to spend some time at His Majesty’s pleasure.

The moment of excitement in one’s hometown and the sensationalist reporting aside, we can’t help feeling sad that a teen with that level of talent evidently wasn’t given the support and encouragement by Oxfordshire’s education system necessary to put it to better use. Let’s hope when he’s older and wiser the teenage conviction won’t prevent him from having a useful career in the field.

Bypassing Bitlocker With A Logic Analzyer

August 25, 2023 by Dave Rowntree 27 Comments

Security Engineer [Guillaume Quéré] spends the day penetration testing systems for their employer and has pointed out and successfully exploited a rather obvious weakness in the BitLocker full volume encryption system, which as the linked article says, allows one to simply sniff the traffic between the discrete TPM chip and CPU via an SPI bus. The way Bitlocker works is to use a private key stored in the TPM chip to encrypt the full volume key that in turn was used to encrypt the volume data. This is all done by low-level device drivers in the Windows kernel and is transparent to the user.

TPM chip pins too small? Just find something else on the bus!

The whole point of BitLocker was to prevent access to data on the secured volume in the event of a physical device theft or loss. Simply pulling the drive and dropping it into a non-secured machine or some other adaptor would not provide any data without the key stored by the TPM. However, since that key must pass as plaintext from the TPM to the CPU during the boot sequence, [Guillaume] shows that it is quite straightforward — with very low-cost tools and free software — to simply locate and sniff out this TPM-to-CPU transaction and decode the datastream and locate the key. Using little more than a cheapo logic analyser hooked up to some conveniently large pins on a nearby flash chip (because the SCK, MISO, and MOSI pins are shared with the TPM) the simple TIS was decoded enough to lock onto the bytes of the TPM frame. This could then be decoded with a TPM stream decoder web app, courtesy of the TPM2-software community group. The command to look for is the TPM_CC.Unseal which is the request from the CPU to the TPM to send over that key we’re interested in. After that just grabbing and decoding the TPM response frame will immediately reveal the goods.

Continue reading “Bypassing Bitlocker With A Logic Analzyer” →

This Week In Security: WinRAR, DNS Disco, And No Silver Bullets

August 25, 2023 by Jonathan Bennett 1 Comment

So what does WinRAR, day trading, and Visual Basic have in common? If you guessed “elaborate malware campaign aimed at investment brokers”, then you win the Internet for the day. This work comes from Group-IB, another cybersecurity company with a research team. They were researching a malware known as DarkMe, and found an attack on WinRAR being used in the wild, using malicious ZIP files being spread on a series of web forums for traders.

Among the interesting tidbits of the story, apparently at least one of those forums locked down the users spreading the malicious files, and they promptly broke into the forum’s back-end and unlocked their accounts. The vulnerability itself is interesting, too. A rigged zip file is created with identically named image file and folder containing a script. The user tries to open the image, but because the zip is malformed, the WinRAR function gets confused and opens the script instead.

Based on a user’s story from one of those forums, it appears that the end goal was to break into the brokers’ trading accounts, and funnel money into attacker accounts. The one documented case only lost $2 worth of dogecoin.

There was one more vulnerability found in WinRAR, an issue when processing malicious recovery volumes. This can lead to code execution due to a memory access error. Both issues were fixed with release 6.23, so if you still have a WinRAR install kicking around, make sure it’s up to date! Continue reading “This Week In Security: WinRAR, DNS Disco, And No Silver Bullets” →