This Week in Security

211 Articles

This Week In Security: Glibc, Ivanti, Jenkins, And Runc

February 2, 2024 by 4 Comments

There’s a fun buffer overflow problem in the Glibc __vsyslog_internal() function. This one’s a real rollercoaster, because logging vulnerabilities are always scary, but at a first look, it seems nearly impossible to exploit. The vulnerability relies on a very long program name, which can overflow an internal buffer. No binaries are going to have a name longer than 1024 bytes, so there’s no problem, right?

Let’s talk about argv. That’s the list of arguments that gets passed into the main() function of every Linux binary when it launches. The first string in that list is the binary name — except that’s a convention, and not particularly enforced anywhere. What really happens is that the execve() system call sets that list of strings. The first argument can be anything, making this an attacker-controlled value. And it doesn’t matter what the program is trying to write to the log, because the vulnerability triggers simply by writing the process name to a buffer.

There is a one-liner to test for a vulnerable Glibc:

exec -a "`printf '%0128000x' 1`" /usr/bin/su < /dev/null

and the Qualys write-up indicates that it can be used for an escalation of privilege attack. The good news is this seems to be a local-only attack. And on top of that, a pair of other lesser severity issues were found and fixed in glibc while fixing this one.
Continue reading “This Week In Security: Glibc, Ivanti, Jenkins, And Runc” →

This Week In Security: MOAB, Microsoft, And Printers

January 26, 2024 by 15 Comments

This week, news has broken of the Mother of All Breaches, MOAB. It’s 12 terabytes and 26 billion records, averaging about 500 bytes each. Now note that a record here is likely not a discrete email address, but simply a piece of data — a row on the database.

Now before we all lose our minds over this, there’s an important detail to take note of: These aren’t new leaks. This is a compilation of leaks, and as far as researchers have checked, there aren’t any new leaks disclosed here. This was someone’s database of accumulated leak data, accidentally re-leaked via an unsecured database. [Troy Hunt] goes so far as to speculate that it could be from a breach search service, which sounds pretty plausible.

There was yet another release of credentials late last week that hasn’t attracted as much attention, but seems to represent a much bigger issue. The Naz.api data set isn’t a breach where a company was hacked, and their entire user database was stolen. Instead, this one is combination of a credential stuffing list and stealer logs.

Credential stuffing is basically a smarter brute force attack, where the credentials from one breach are tried on multiple other sites. Such a list is just the results where guesses were successful. The really interesting bit is that this dataset seems to include stealer logs. Put simply, that’s the results of malware that scrapes victim machines for credentials.

Naz.api has over 70 million unique email addresses, and it looks like about a third of them are new, at least according to the Haveibeenpwned dataset. Now that’s significant, though not really worthy of the MOAB title, either. Continue reading “This Week In Security: MOAB, Microsoft, And Printers” →

This Week In Security: Gitlab, VMware, And PixeFAIL

January 19, 2024 by 3 Comments

There’s a Gitlab vulnerability that you should probably pay attention to. Tracked as CVE-2023-7028, this issue allows an attacker to specify a secondary email during a the password reset request. Only one email has to match the one on record, but the password reset link gets sent to both emails. Yikes!

What makes this worse is there is already a Proof of Concept (PoC) released, and it’s a trivial flaw. In an HTTP/S post containing the password reset request, just include two email addresses. Thankfully, a fix is already out. Versions 16.7.2, 16.6.4, and 16.5.6 contain this patch, as well as fixes for a flaw that allowed sneaking unauthorized changes into a previously approved merge request, and an issue with Slack and Mattermost where slash commands could be spoofed.

VMware

We don’t want to over-dramatise this vulnerability, but VMware is calling it an emergency. This one affects VMware vRealize and Aria Automation. According to the the CVSS calculator, it’s a low complexity network flaw, but does require at least some privileges. Hopefully more information will come out about this vulnerability, but for now that’s about all we know.

Continue reading “This Week In Security: Gitlab, VMware, And PixeFAIL” →

This Week In Security: AI Is Terrible, Ransomware Wrenches, And Airdrop

January 12, 2024 by 8 Comments

So first off, go take a look at this curl bug report. It’s a 8.6 severity security problem, a buffer overflow in websockets. Potentially a really bad one. But, it’s bogus. Yes, a strcpy call can be dangerous, if there aren’t proper length checks. This code has pretty robust length checks. There just doesn’t seem to be a vulnerability here.

OK, so let’s jump to the punch line. This is a bug report that was generated with one of the Large Language Models (LLMs) like Google Bard or ChatGPT. And it shouldn’t be a surprise. There are some big bug bounties that are paid out, so naturally people are trying to leverage AI to score those bounties. But as [Daniel Stenberg] point out, LLMs are not actually AI, and the I in LLM stands for intelligence.

There have always been vulnerability reports of dubious quality, sent by people that either don’t understand how vulnerability research works, or are willing to waste maintainer time by sending in raw vulnerability scanner output without putting in any real effort. What LLMs do is provide an illusion of competence that takes longer for a maintainer to wade through before realizing that the claim is bogus. [Daniel] is more charitable than I might be, suggesting that LLMs may help with communicating real issues through language barriers. But still, this suggests that the long term solution may be “simply” detecting LLM-generated reports, and marking them as spam. Continue reading “This Week In Security: AI Is Terrible, Ransomware Wrenches, And Airdrop” →

This Week In Security: Bitwarden, Reverse RDP, And Snake

January 5, 2024 by 10 Comments

This week, we finally get the inside scoops on some old stories, starting with the Bitwarden Windows Hello problem from last year. You may remember, Bitwarden has an option to use Windows Hello as a vault unlock option. Unfortunately, the Windows credential API doesn’t actually encrypt credentials in a way that requires an additional Windows Hello verification to unlock. So a derived key gets stored to the credential manager, and can be retrieved through a simple API call. No additional biometrics needed. Even with the Bitwarden vault locked and application closed.

There’s another danger, that doesn’t even require access to the the logged-in machine. On a machine that is joined to a domain, Windows backs up those encryption keys to the Domain Controller. The encrypted vault itself is available on a domain machine over SMB by default. A compromised domain controller could snag a bitwarden vault without ever even running code on the target machine. The good news is that this particular problem with Bitwarden and Windows Hello is now fixed, and has been since version 2023.10.1.

Reverse RDP Exploitation

We normally think about the Remote Desktop Protocol as dangerous to expose to the internet. And it is. Don’t put your RDP service online. But reverse RDP is the idea that it might also be dangerous to connect an RDP client to a malicious server. And of course, multiple RDP implementations have this problem. There’s rdesktop, FreeRDP, and Microsoft’s own mstsc that all have vulnerabilities relating to reverse RDP.

The technical details here aren’t terribly interesting. It’s all variations on the theme of not properly checking remote data from the server, and hence either reading or writing past internal buffers. This results in various forms of information leaks and code executions problems. What’s interesting is the different responses to the findings, and then [Eyal Itkin]’s takeaway about how security researchers should approach vulnerability disclosure.

So first up, Microsoft dismissed a vulnerability as unworthy of servicing. And then proceeded to research it internally, and present it as a novel attack without properly attributing [Eyal] for the original find. rdesktop contained quite a few of these issues, but were able to fix the problem in a handful of months. FreeRDP fixed some issues right away, in what could be described as a whack-a-mole style process, but a patch was cooked up that would actually address the problem at a deeper level: changing an API value from the unsigned size_t to a signed ssize_t. That change took a whopping 2 years to actually make it out to the world in a release. Why so long? Continue reading “This Week In Security: Bitwarden, Reverse RDP, And Snake” →

This Week In Security: Triangulation, ProxyCommand, And Barracuda

December 29, 2023 by 6 Comments

It’s not every day we get to take a good look inside a high-level exploit chain developed by an unnamed APT from the western world. But thanks to some particularly dedicated researchers at Kaspersky, which just happens to be headquartered in Moscow, that’s exactly what we have today. The name Operation Triangulation was picked, based off part of the device fingerprinting code that rendered a yellow triangle on an HTML canvas.

The entire talk is available, given this week at the 37th Chaos Communication Congress, 37c3. The exploit starts with an iMessage attachment, delivered silently, that exploits an undocumented TrueType font instruction. Looking at the source code implies that it was a copy-paste error where a programmer didn’t quite get the logic right for a pointer calculation. That vulnerability gives a memory write primitive that pivots into code execution. What’s particularly interesting is that Apple silently fixed this bug January 2023, and didn’t make any public statements. Presumably there were an uptick of crash logs that pointed to this problem, but didn’t conclusively show attempted exploitation.

The exploits then moves to using NSExpression as a next stage. NSExpression is an ugly way to write code, but it does allow the exploit chain to get to the next stage, running JavaScript as an application, without Just In Time compilation. The JS payload is quite a beast, weighing in at 11,000 lines of obfuscated code. It manages to call native APIs directly from JS, which then sets up a kernel exploit. This is multiple integer overflow flaws that result in essentially arbitrary system memory reads and writes. Continue reading “This Week In Security: Triangulation, ProxyCommand, And Barracuda” →

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

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