SecureLayer7: Major Security Flaws in Mailcow: Inside the XSS and Path Traversal Exploits (CVE-2024-31204 and CVE-2024-30270)
Mailcow is an open source mail server software suite. CVE-2024-31204 (6.1 medium) XSS in the Admin Panel and CVE-2024-30270 (6.2 medium) arbitrary file overwrite were originally reported by SonarSource. SecureLayer7 performs patch diffing to provide a root cause analysis (proof of concept) for them.
#vulnerability #CVE_2024_31204 #CVE_2024_30270 #mailcow #proofofconcept #CVE
Wow, this guy setup fake free WiFi to harvest FB logins on a Plane! This is one of those always rumored, but never true attacks. Article doesn’t specify just how they figured out which guy on the plane was doing it.
https://www.infosecurity-magazine.com/news/australia-police-fake-wifi-airport/
OpenSSH CVE-2024-6387 mitigation (on Fedora):
echo 'OPTIONS=-e' | sudo tee -a /etc/sysconfig/sshd && sudo systemctl restart sshd
I have no idea why Qualys didn't mention this. The only non-async-safe function called by the vulnerable signal handler is syslog()
. So just turn off syslog and log to stderr. On systemd distros, this still ends up in the journal anyway, so you lose nothing.
I confirmed that the message at the root of the issue is logged to stderr and not syslog with this option:
[pid 638194] --- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---
[pid 638194] getpgid(0) = 638194
[pid 638194] getpid() = 638194
[pid 638194] rt_sigaction(SIGTERM, {sa_handler=SIG_IGN, sa_mask=~[RTMIN RT_1], sa_flags=SA_RESTART}, {sa_handler=SIG_DFL, sa_mask=~[KILL STOP RTMIN RT_1], sa_flags=SA_RESTART}, 8) = 0
[pid 638194] kill(0, SIGTERM) = 0
[pid 638194] getpid() = 638194
[pid 638194] write(2, "Timeout before authentication for 192.168.21.10 port 37734\r\n", 60) = 60
[pid 638194] exit_group(1) = ?
[pid 638194] +++ exited with 1 +++
Edit: The problem code still calls snprintf()
which on-paper is still unsafe. However, it does this a bunch of times anyway in multiple code paths, and Qualys didn't mention anything about it. A quick look through glibc code suggests that snprintf()
only does unsafe things (allocate memory) if you format floats, which obviously ssh does not.
Edit 2: Turns out there is another related issue, CVE-2024-6409, which is not mitigated by this trick. However, it only affects F35 through F37 and RHEL9, since it's caused by distro patches. The mitigation above works for current Fedora releases. If you're stuck on the vulnerable range for some reason, use the LoginGraceTime 0
mitigation and update your OS ASAP since those old versions won't get the patches at all.
Microsoft has told customers that the Russian criminals who compromised its systems earlier this year made off with even more emails than it first admitted. | @theregister
“the digital Russian break-in at the Windows maker saw Kremlin spies make off with source code, executive emails, and sensitive US government data. Reports last week revealed that the issue was even larger than initially believed and additional customers' data has been stolen.”
I have discovered 7 long lost #DEFCON 6 videos, but they are in Real Media format and I can't find any utilities that work on current technology to convert them.
Does anyone know of tools that work?
So i wrote this on the other site (the short messages wannabe porn site) and predictably got just a single response.
Perhaps here I would fare better?
Reading the Qualys writeup about the OpenSSH race condition RCE it occurred to me that there should be a book titled "Beautiful Exploits" in which a handful of beautiful exploits are explained and their philosophical and historical implications are discussed.
Which ones you'd pick?
Meta claims that the "ad-free subscription" (Pay-or-Consent) model has been "approved" by the Court of Justice of the European Union (indeed ot opined on the matter). It states that this model is compatible with the DMA. An interesting case developing. Very well.
When it comes to Qualys, in the context of the OpenSSH vuln, I'll just repeat what I said a while back:
"I'm impressed with the Qualys security research team. Not only because they are clearly talented and have an impressive portfolio of high-impact findings - but because in an era of vanity domains and logos for bugs, they're keeping the 1990s research aesthetics alive."
Truth to be told, Qualys might be the only group still regularly doing this kind of "basic stack" research. Almost all the vuln research has shifted elsewhere, largely in response to financial incentives.
Do you like Splunk? Do you like them enough to read 18* security advisories?
No mention of exploitation. h/t for @cR0w for the last 2 CVE IDs (I relied specifically on the RSS feed entries).
Notes on regreSSHion on musl — https://dustri.org/b/notes-on-regresshion-on-musl.html
Google Android security advisory: Android Security Bulletin—July 2024
29 security vulnerabilities, CVE-2024-31320 (EoP) is marked critical severity. Qualcomm vuln CVE-2024-21461 is also critical. 25 vulnerabilities of varying types are high severity. No mention of exploitation
Running Windows Server on Apple Silicon seems "fun"!
https://trimarcjake.github.io/blog/2024/06/24/Virtualizing-Windows-Server-2025-on-Apple-Silicon.html
just in time to celebrate infosec.exchange returning, Cisco zero day: Cisco NX-OS Software CLI Command Injection Vulnerability
CVE-2024-20399 (6.0 medium) A vulnerability in the CLI of Cisco NX-OS Software could allow an authenticated, local attacker to execute arbitrary commands as root on the underlying operating system of an affected device. This vulnerability is due to insufficient validation of arguments that are passed to specific configuration CLI commands. An attacker could exploit this vulnerability by including crafted input as the argument of an affected configuration CLI command. A successful exploit could allow the attacker to execute arbitrary commands on the underlying operating system with the privileges of root. Note: To successfully exploit this vulnerability on a Cisco NX-OS device, an attacker must have Administrator credentials.
In April 2024, the Cisco Product Security Incident Response Team (PSIRT) became aware of attempted exploitation of this vulnerability in the wild.
EDIT: Sygnia links attempted zero-day exploitation to Chinese state-sponsored threat actor it tracks as Velvet Ant (no article yet). See related Bleeping Computer reporting; Cisco warns of NX-OS zero-day exploited to deploy custom malware
cc: @campuscodi @briankrebs @cR0w @mttaggart
#CVE_2024_20399 #vulnerability #zeroday #cisco #cve #eitw #cyberespionage #velvetant #china
A new blog from ZDI Researcher Yulin Sung and shows how to combine 2 bugs to get unauth RCE on the #Logsign Unified SecOps Platform. These bugs were originally reported by
@mdisec
and were recently patched. Read the details (w/ PoC) at https://www.zerodayinitiative.com/blog/2024/7/1/getting-unauthenticated-remote-code-execution-on-the-logsign-unified-secops-platform
This is a really interesting vulnerability, but *the Internet is not on fire.* Please read the actual advisory before spreading FUD. If you can't understand the original advisory, please get someone to explain it to you.
In short, the exploit has only been proven against x86 versions - NOT x64. That's important because finding the right address to return to in x64 is exponentially harder in x64 than x86.
This is definitely a "don't delay patching" moment, but not a "OMG, get an outage window NOW" moment. Monitor for updates though, that could change (though highly unlikely IMO).
This is also a great time to talk about zero trust. The foundational principle here is "deny all, permit by exception." Most orgs don't need SSH open to the whole Internet. Yes, ACLs are a pain to use. But you're getting a lot back in security. That's true for times like these, but it's also makes credential compromises harder to meaningfully exploit.
As an aside, if you can't do IP ACLs for SSH (and everyone *can*, it's just a question of overhead to maintain), consider changing the default port for SSH. In some testing, that's dropped my failed login attempts by more than 95% (98%+ if you don't make it something obvious like 2200, 2222, or 2022).
Finally, let's talk monitoring. It took @qualys researchers about a week to get a root shell. And that's for the x86 version (which again, is infinitely easier to trigger than in x64). So even if you can't just allow list a few IP addresses, you can for sure block list IPs that are hammering your server with ~10,000 exploit attempts. And before someone says "but Jake, what if they use a distributed network" - okay, but still block the obviously malicious IPs?
Great work by the Qualys team. There aren't many that can turn something like this into RCE - even in controlled environments.
https://blog.qualys.com/vulnerabilities-threat-research/2024/07/01/regresshion-remote-unauthenticated-code-execution-vulnerability-in-openssh-server
The YouTube playlist for #OST2 “Exploitation 4011: Windows Kernel Exploitation: Race Condition + UAF in KTM” class by Cedric Halbronn @saidelike is now public for those who like to download videos: https://www.youtube.com/playlist?list=PLUFkSN0XLZ-nl4HEX4_LWG9H_d9vJKkYL
But the best way to learn the material is with the full class at https://ost2.fyi/Exp4011. This class assumes you've already taken "x86-64 OS Internals" https://ost2.fyi/Arch2001, "Windows Kernel Internals 2" https://ost2.fyi/Arch2821, and "Advanced WinDbg" https://ost2.fyi/Dbg3011
This is an advanced level class that teaches you how to exploit a race condition vulnerability leading to a use-after-free in the Kernel Transaction Manager (KTM) component of the Windows kernel. This class is meant to show the approach an exploit developer should take in attacking a previously unknown component in the Windows kernel.