Archives

This Week In Security: WebP, Cavium, Gitlab, And Asahi Lina

September 22, 2023 by 15 Comments

Last week we covered the latest 0-day from NSO group, BLASTPASS. There’s more details about exactly how that works, and a bit of a worrying revelation for Android users. One of the vulnerabilities used was CVE-2023-41064, a buffer overflow in the ImageIO library. The details have not been confirmed, but the timing suggests that this is the same bug as CVE-2023-4863, a Webp 0-day flaw in Chrome that is known to be exploited in the wild.

The problem seems to be an Out Of Bounds write in the BuildHuffmanTable() function of libwebp. And to understand that, we have to understand libwebp does, and what a Huffman Table has to do with it. The first is easy. Webp is Google’s pet image format, potentially replacing JPEG, PNG, and GIF. It supports lossy and lossless compression, and the compression format for lossless images uses Huffman coding among other techniques. And hence, we have a Huffman table, a building block in the image compression and decompression.

What’s particularly fun about this compression technique is that the image includes not just Huffman compressed data, but also a table of statistical data needed for decompression. The table is rather large, so it gets Huffman compressed too. It turns out, there can be multiple layers of this compression format, which makes the vulnerability particularly challenging to reverse-engineer. The vulnerability is when the pre-allocated buffer isn’t big enough to hold one of these decompressed Huffman tables, and it turns out that the way to do that is to make maximum-size tables for the outer layers, and then malform the last one. In this configuration, it can write out of bounds before the final consistency check.

An interesting note is that as one of Google’s C libraries, this is an extensively fuzzed codebase. While fuzzing and code coverage are both great, neither is guaranteed to find vulnerabilities, particularly well hidden ones like this one. And on that note, this vulnerability is present in Android, and the fix is likely going to wait til the October security update. And who knows where else this bug is lurking. Continue reading “This Week In Security: WebP, Cavium, Gitlab, And Asahi Lina” →

This Week In Security: Blastpass, MGM Heist, And Killer Themes

September 15, 2023 by 7 Comments

There’s yet another 0-day exploit chain discovered as part of NSO Group’s Pegasus malware suite. This one is known as BLASTPASS, and it’s a nasty one. There’s no user interaction required, just receiving an iMessage containing a malicious PassKit attachment.

We have two CVEs issued so far. CVE-2023-41064 is a classic buffer overflow in ImageIO, the Apple framework for universal file format read and write. Then CVE-2023-41061 is a problem in the iOS Wallet implementation. Release 16.6.1 of the mobile OS addresses these issues, and updates have rolled out for macOS 11, 12, and 13.

It’s worth noting that Apple’s Lockdown mode does seem to block this particular exploit chain. Citizen Lab suggests that high-risk users of Apple hardware enable Lockdown Mode for that extra measure of security. Continue reading “This Week In Security: Blastpass, MGM Heist, And Killer Themes” →

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

September 8, 2023 by 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” →

This Week In Security: Zimbra, Lockbit 2, And Hacking NK

February 11, 2022 by 9 Comments

Unknown attackers have been exploiting a 0-day attack against the Zimbra e-mail suite. Researchers at Volexity first discovered the attack back in December of last year, detected by their monitoring infrastructure. It’s a cross-site scripting (XSS) exploit, such that when opening a malicious link, the JavaScript running on the malicious page can access a logged-in Zimbra instance. The attack campaign uses this exploit to grab emails and attachments and upload them to the attackers. Researchers haven’t been able to positively identify what group is behind the attacks, but a bit of circumstantial evidence points to a Chinese group. That evidence? Time zones. The attacker requests all use the Asia/Hong_Kong time zone, and the timing of all the phishing emails sent lines up nicely with a work-day in that time zone.

Zimbra has responded, confirming the vulnerability and publishing a hotfix for it. The campaign seems to have been targeted specifically against European governments, and various media outlets. If you’re running a Zimbra instance, make sure you’re running at least 8.8.15.1643980846.p30-1.

LockBit 2.0

Because security professionals needed something else to keep us occupied, the LockBit ransomware campaign is back for a round two. This is another ransomware campaign run in the as-a-Service pattern — RAAS. LockBit 2 has caught enough attention, that the FBI has published a FLASH message (PDF) about it. That’s the FBI Liaison Alert System, in the running for the worst acronym. (Help them figure out what the “H” stands for in the comments below!)

Like many other ransomware campaigns, LockBit has a list of language codes that trigger a bail on execution — the Eastern European languages you would expect. Ransomware operators have long tried not to poison their own wells by hitting targets in their own back yards. This one is being reported as also having a Linux module, but it appears that is limited to VMWare ESXi virtual machines. A series of IoCs have been published, and the FBI are requesting any logs, ransom notes, or other evidence possibly related to this campaign to be sent to them if possible. Continue reading “This Week In Security: Zimbra, Lockbit 2, And Hacking NK” →

This Week In Security: Use Emacs, Crash A Windows Server, And A Cryptocurrency Heist

June 14, 2019 by 5 Comments

It looks like Al was right, we should all be using Emacs. On the 4th of June, [Armin Razmjou] announced a flaw in Vim that allowed a malicious text file to trigger arbitrary code execution. It’s not every day we come across a malicious text file, and the proof of concept makes use of a clever technique — escape sequences hide the actual payload. Printing the file with cat returns “Nothing here.” Cat has a “-v” flag, and that flag spills the secrets of our malicious text file. For simplicity, we’ll look at the PoC that doesn’t include the control characters. The vulnerability is Vim’s modeline function. This is the ability to include editor options in a text file. If a text file only works with 80 character columns, a modeline might set “textwidth=80”. Modeline already makes use of a sandbox to prevent the most obvious exploits, but [Armin] realized that the “:source!” command could run the contents of a file outside that sandbox. “:source! %” runs the contents of the current file — the malicious text file.

:!uname -a||" vi:fen:fdm=expr:fde=assert_fails("source\!\ \%"):fdl=0:fdt="

Taking this apart one element at a time, the “:!” is the normal mode command to run something in the shell, so the rest of the line is what gets run. “uname -a” is the arbitrary command, benign in this case. Up next is the OR operator, “||” which fully evaluates the first term first, and only evaluates what comes after the operator if the first term returns false. In this case, it’s a simple way to get the payload to run even though the rest of the line is garbage, as far as bash is concerned. “vi:” informs Vim that we have a modeline string. “:fen” enables folding, and “:fdm=expr” sets the folding method to use an expression. This feature is usually used to automatically hide lines matching a regular expression. “:fde=” is the command to set the folding expression. Here’s the exploit, the folding expression can be a function like “execute()” or “assert_fails()”, which allows calling the :source! command. This pops execution out of the sandbox, and begins executing the text file inside vim, just as if a user were typing it in from the keyboard. Continue reading “This Week In Security: Use Emacs, Crash A Windows Server, And A Cryptocurrency Heist” →

This Week In Security: Nvidia, Ransomware Retirement, And A TOCTOU Bug In Docker

June 7, 2019 by 2 Comments

Nvidia’s GeForce Experience (GFE) is the companion application for the Nvidia drivers, keeping said drivers up to date, as well as adding features around live streaming and media capture. The application runs as two parts, a GUI, and a system service, using an HTTP API to communicate. [David Yesland] from Rhino Security Labs decided to look into this API, searching for interesting, undocumented behavior, and shared the results on Sunday the 2nd.

The first interesting finding was that the service was written in Javascript and run using Node.js. Javascript is a scripting language, not a compiled language — the source code of the service was open for studying. This led to the revelation that API requests would be accepted from any origin, so long as the request included the proper security token. The application includes an update mechanism, which allows an authorized API call to execute an arbitrary system command. So long as the authentication token isn’t leaked to an attacker, this still isn’t a problem, right? Continue reading “This Week In Security: Nvidia, Ransomware Retirement, And A TOCTOU Bug In Docker” →

This Week In Security: Baltimore, MacOS Zipfile Security, And App Store Monopolies

May 31, 2019 by 13 Comments

Baltimore. The city was breached, crippled and held for ransom. The ransomware attack was discovered on May 7th, shutting down a major portion of the city’s infrastructure. The latest news is that an NSA-written tool, EternalBlue, is responsible for the attack. Except maybe it isn’t? First off, digging back through the history of an attack is challenging. It’s often hard to determine the initial attack vector with certainty.

The “initial attack vector” is the patient zero of the attack — how the first machine was compromised. An organization generally has a firewall separating the outside internet from the internal network. Once an attacker has found a way to access a machine inside the network, the separation is not nearly so strict. This takes many forms, but the most common is phishing. Close contenders are RDP and SMB (Remote Desktop and Windows File Sharing). A report at Ars Technica indicates that the initial vector into the Baltimore network was a phishing email.

The second step to consider is what’s called “lateral movement”, which describes an attacker using the compromised machine to target other machines in the organization. Often an attacker will have an entire toolkit of exploits to attempt to compromise other machines. One of the exploits used in this case was the same exploit contained in the NSA tool, EternalBlue. A clever program called psexec is usually part of any lateral movement campaign. While the exploit associated with EternalBlue was probably used to compromise a few of the machines on the Baltimore network, placing all the blame on the shoulders of the NSA is missing the point. The tool is only a small part of this attack.

MacOS and NFS Shares Inside Zipfiles

MacOS has a sometimes irritating feature, Gatekeeper, that only allows running signed binaries by default. The point of Gatekeeper is to prevent a user from running a malicious binary that has been downloaded from the internet. While it is sometimes an annoyance, it is helpful for some users. [Filippo Cavallarin] announced an exploit that completely bypasses Gatekeeper on the 24th. This exploit takes advantage of the fact that Gatekeeper considers network shares to be trustworthy, and doesn’t run the normal check before executing a binary located there. While interesting, this isn’t useful unless there is a way for an attacker to mount a malicious location as a network share. Enter the Mac’s ability to automatically mount network locations through the use of the /net path. The last piece of this puzzle is the fact that zip files can contain symbolic links. A zip file can be built with a link to the /net location, automounting an arbitrary NFS location. If binary files are located in this location, the OS will happily allow the user to execute those binaries whether signed or not.

This exploit may not be the most serious of the year, but it’s still a problem that needs fixing. [Filippo] contacted Apple back in February and disclosed the problem, even getting an assurance that they would fix it within 90 days. 90 days have passed, and Apple has begun ignoring his emails, so he has made the announcement and published steps to reproduce on his website.

There has been discussion in the comments of this column about vulnerability disclosure and publishing proof of concept code. This is a perfect example of why researchers publish their work. As far as [Filippo] knows, Apple has no intention of fixing the issue he discovered. He also has no reason to believe that no one else has stumbled on this discovery before he did. We mentioned EternalBlue above. The NSA discovered the SMB vulnerability that exploit targeted and used it silently for up to five years before it was stolen and finally disclosed to Microsoft and fixed. Make no mistake, public disclosures and proof of concepts get vulnerabilities fixed. For any given vulnerability, there is no guarantee that someone else hasn’t already found it.

Just a Little Document Leak

OK, maybe not so little. A Fortune 500 company, First American, managed to host millions of private documents in an accessible format. Imagine you upload a document to a company, and get a confirmation link that looks like “test.com/documents.php?id=0252234”. If you’re like me, you’re very curious what is at id=0252233. [Ben Shoval] is a real estate developer who apparently also wanted to know the answer to that question. To his surprise, millions of uploaded documents were available for anyone to view. He tried reaching out to First American, and when there was no response to his emails, he forwarded his findings on to Krebs on Security. After what was likely years of exposure, the database was finally taken offline Friday the 24th.

Walled Garden Monopolies

Staying on the Apple train, the App Store is pretty obviously a monopoly. Someone has finally asked whether it’s an illegal monopoly. As most of these questions go, it’ll take a drawn out court battle to decide. How is this security news? If the court finds that Apple has been violating antitrust laws, one possible remediation is to allow alternative app stores. While there is always the potential for a high quality alternative store like F-droid, sketchy app stores and downloaded are a real possibility. On the other hand, it would be nice to have an iOS app store that is compatible with the GPL.