“The US Cybersecurity and Infrastructure Security Agency has added a critical security bug in Linux to its list of vulnerabilities known to be actively exploited in the wild,” reported Ars Technica on Friday.

“The vulnerability, tracked as CVE-2024-1086 and carrying a severity rating of 7.8 out of a possible 10, allows people who have already gained a foothold inside an affected system to escalate their system privileges.”

It’s the result of a use-after-free error, a class of vulnerability that occurs in software written in the C and C++ languages when a process continues to access a memory location after it has been freed or deallocated. Use-after-free vulnerabilities can result in remote code or privilege escalation. The vulnerability, which affects Linux kernel versions 5.14 through 6.6, resides in the NF_tables, a kernel component enabling the Netfilter, which in turn facilitates a variety of network operations… It was patched in January, but as the CISA advisory indicates, some production systems have yet to install it. At the time this Ars post went live, there were no known details about the active exploitation.

A deep-dive write-up of the vulnerability reveals that these exploits provide “a very powerful double-free primitive when the correct code paths are hit.” Double-free vulnerabilities are a subclass of use-after-free errors…

Read more of this story at Slashdot.

The term “auth” is ambiguous, often meaning either authentication (authn) or authorization (authz), which leads to confusion and poor system design. Instead, Nicole Tietz-Sokolskaya, a software engineer at AI market research platform Remesh, argues that the industry adopt the terms “login” for authentication and “permissions” for authorization, as these are clearer and help maintain distinct, appropriate abstractions for each concept. From their blog post: We should always use the most clear terms we have. Sometimes there’s not a great option, but here, we have wonderfully clear terms. Those are “login” for authentication and “permissions” for authorization. Both are terms that will make sense with little explanation (in contrast to “authn” and “authz”, which are confusing on first encounter) since almost everyone has logged into a system and has run into permissions issues. There are two ways to use “login” here: the noun and the verb form. The noun form is “login”, which refers to the information you enter to gain access to the system. And the verb form is “log in”, which refers to the action of entering your login to use the system. “Permissions” is just the noun form. To use a verb, you would use “check permissions.” While this is long, it’s also just… fine? It hasn’t been an issue in my experience.

Both of these are abundantly clear even to our peers in disciplines outside software engineering. This to me makes it worth using them from a clarity perspective alone. But then we have the big benefit to abstractions, as well. When we call both by the same word, there’s often an urge to combine them into a single module just by dint of the terminology. This isn’t necessarily wrong — there is certainly some merit to put them together, since permissions typically require a login. But it’s not necessary, either, and our designs will be stronger if we don’t make that assumption and instead make a reasoned choice.

Read more of this story at Slashdot.

“Merged this Friday evening into the Linux 6.10 kernel is the new mseal() system call for memory sealing,” reports Phoronix:

The mseal system call was led by Jeff Xu of Google’s Chrome team. The goal with memory sealing is to also protect the memory mapping itself against modification. The new mseal Linux documentation explains:

“Modern CPUs support memory permissions such as RW and NX bits. The memory permission feature improves security stance on memory corruption bugs, i.e. the attacker can’t just write to arbitrary memory and point the code to it, the memory has to be marked with X bit, or else an exception will happen. Memory sealing additionally protects the mapping itself against modifications. This is useful to mitigate memory corruption issues where a corrupted pointer is passed to a memory management system… Memory sealing can automatically be applied by the runtime loader to seal .text and .rodata pages and applications can additionally seal security-critical data at runtime. A similar feature already exists in the XNU kernel with the VM_FLAGS_PERMANENT flag and on OpenBSD with the mimmutable syscall.”
The mseal system call is designed to be used by the likes of the GNU C Library “glibc” while loading ELF executables to seal non-writable memory segments or by the Google Chrome web browser and other browsers for protecting security sensitive data structures.

Read more of this story at Slashdot.

Andy Greenberg reports via Wired: More than two months after the start of a ransomware debacle whose impact ranks among the worst in the history of cybersecurity, the medical firm Change Healthcare finally confirmed what cybercriminals, security researchers, and Bitcoin’s blockchain had already made all too clear: that it did indeed pay a ransom to the hackers who targeted the company in February. And yet, it still faces the risk of losing vast amounts of customers’ sensitive medical data. In a statement sent to WIRED and other news outlets on Monday evening, Change Healthcare wrote that it paid a ransom to a cybercriminal group extorting the company, a hacker gang known as AlphV or BlackCat. “A ransom was paid as part of the company’s commitment to do all it could to protect patient data from disclosure,” the statement reads. The company’s belated admission of that payment accompanied a new post on its website where it warns that the hackers may have stolen health-related data that would “cover a substantial proportion of people in America.”

Cybersecurity and cryptocurrency researchers told WIRED last month that Change Healthcare appeared to have paid that ransom on March 1, pointing to a transaction of 350 bitcoins or roughly $22 million sent into a crypto wallet associated with the AlphV hackers. That transaction was first highlighted in a message on a Russian cybercriminal forum known as RAMP, where one of AlphV’s allegedly jilted partners complained that they hadn’t received their cut of Change Healthcare’s payment. However, for weeks following that transaction, which was publicly visible on Bitcoin’s blockchain and which both security firm Recorded Future and blockchain analysis firm TRM Labs told WIRED had been received by AlphV, Change Healthcare repeatedly declined to confirm that it had paid the ransom.

Change Healthcare’s confirmation of that extortion payment puts new weight behind the cybersecurity industry’s fears that the attack — and the profit AlphV extracted from it — will lead ransomware gangs to further target health care companies. “It 100 percent encourages other actors to target health care organizations,” Jon DiMaggio, a researcher with cybersecurity firm Analyst1 who focuses on ransomware, told WIRED at the time the transaction was first spotted in March. “And it’s one of the industries we don’t want ransomware actors to target — especially when it affects hospitals.” Compounding the situation, a conflict between hackers in the ransomware ecosystem has led to a second ransomware group claiming to possess Change Healthcare’s stolen data and threatening to sell it to the highest bidder on the dark web. Earlier this month that second group, known as RansomHub, sent WIRED alleged samples of the stolen data that appeared to come from Change Healthcare’s network, including patient records and a contract with another health care company.

Read more of this story at Slashdot.

U.S. telecom provider Frontier Communications shut down its systems after a cybercrime group breached some of its IT systems in a recent cyberattack. BleepingComputer reports: Frontier is a leading U.S. communications provider that provides gigabit Internet speeds over a fiber-optic network to millions of consumers and businesses across 25 states. After discovering the incident, the company was forced to partially shut down some systems to prevent the threat actors from laterally moving through the network, which also led to some operational disruptions. Despite this, Frontier says the attackers could access some PII data, although it didn’t disclose if it belonged to customers, employees, or both.

“On April 14, 2024, Frontier Communications Parent, Inc. [..] detected that a third party had gained unauthorized access to portions of its information technology environment,” the company revealed in a filing with the U.S. Securities and Exchange Commission on Thursday. “Based on the Company’s investigation, it has determined that the third party was likely a cybercrime group, which gained access to, among other information, personally identifiable information.” Frontier now believes that it has contained the breach, has since restored its core IT systems affected during the incident, and is working on restoring normal business operations.

Read more of this story at Slashdot.

T-Mobile employees from around the country are reportedly receiving text messages offering them cash in exchange for swapping SIMs. SIM swapping is when cybercriminals trick a cellular service provider into switching a victim’s service to a SIM card that they control, essentially hijacking the victim’s phone number and gaining access to two-factor authentication codes. From the Mobile Report: The texts offer the employee $300 per SIM swap, and asks the worker to contact them on telegram. The texts all come from a variety of different numbers across multiple area codes, making it more difficult to block. The text also claims they acquired the employee’s number “from the T-Mo employee directory.” If true, it could mean T-Mobile’s employee directory, with contact numbers, has somehow been accessed. It’s also possible the bad actor has live/current access to this data, though we consider that less likely due to the fact that some impacted people are former employees who have not worked at the company in months.

Still, the biggest issue here is how this person (or multiple people) obtained the employee phone numbers. We’re not sure yet which employees are impacted, but based on comments online it seems at least a few third-party employees are affected, and we’ve independently confirmed current corporate employees have also received the message. Though we can’t say for certain, this likely means the information is not the same data as what was leaked during the Connectivity Source breach [from September]. We can’t, however, eliminate that possibility. As mentioned, there are reports that some of the contacted people are former employees, and haven’t been employed at T-Mobile for months, so the information being acted upon is likely a few months old at the very least. That being said, we’re pretty confident based on corporate employees being included that this is a different source of data being used.

Read more of this story at Slashdot.

Zack Whittaker and Carly Page report via TechCrunch: Microsoft has resolved a security lapse that exposed internal company files and credentials to the open internet. Security researchers Can Yoleri, Murat Ozfidan and Egemen Kochisarli with SOCRadar, a cybersecurity company that helps organizations find security weaknesses, discovered an open and public storage server hosted on Microsoft’s Azure cloud service that was storing internal information relating to Microsoft’s Bing search engine. The Azure storage server housed code, scripts and configuration files containing passwords, keys and credentials used by the Microsoft employees for accessing other internal databases and systems. But the storage server itself was not protected with a password and could be accessed by anyone on the internet.

Yoleri told TechCrunch that the exposed data could potentially help malicious actors identify or access other places where Microsoft stores its internal files. Identifying those storage locations “could result in more significant data leaks and possibly compromise the services in use,” Yoleri said. The researchers notified Microsoft of the security lapse on February 6, and Microsoft secured the spilling files on March 5. It’s not known for how long the cloud server was exposed to the internet, or if anyone other than SOCRadar discovered the exposed data inside.

Read more of this story at Slashdot.

Bill Toulas reports via BleepingComputer: Firmware security firm Binarly has released a free online scanner to detect Linux executables impacted by the XZ Utils supply chain attack, tracked as CVE-2024-3094. CVE-2024-3094 is a supply chain compromise in XZ Utils, a set of data compression tools and libraries used in many major Linux distributions. Late last month, Microsoft engineer Andres Freud discovered the backdoor in the latest version of the XZ Utils package while investigating unusually slow SSH logins on Debian Sid, a rolling release of the Linux distribution.

The backdoor was introduced by a pseudonymous contributor to XZ version 5.6.0, which remained present in 5.6.1. However, only a few Linux distributions and versions following a “bleeding edge” upgrading approach were impacted, with most using an earlier, safe library version. Following the discovery of the backdoor, a detection and remediation effort was started, with CISA proposing downgrading the XZ Utils 5.4.6 Stable and hunting for and reporting any malicious activity.

Binarly says the approach taken so far in the threat mitigation efforts relies on simple checks such as byte string matching, file hash blocklisting, and YARA rules, which could lead to false positives. This approach can trigger significant alert fatigue and doesn’t help detect similar backdoors on other projects. To address this problem, Binarly developed a dedicated scanner that would work for the particular library and any file carrying the same backdoor. […] Binarly’s scanner increases detection as it scans for various supply chain points beyond just the XZ Utils project, and the results are of much higher confidence. Binarly has made a free API available to accomodate bulk scans, too.

Read more of this story at Slashdot.

“There is a new side channel attack against Apple ‘M’ series CPUs that does not appear to be fixable without a major performance hit,” writes Slashdot reader EncryptedSoldier. SecurityWeek reports: A team of researchers representing several universities in the United States has disclosed the details of a new side-channel attack method that can be used to extract secret encryption keys from systems powered by Apple CPUs. The attack method, dubbed GoFetch, has been described as a microarchitectural side-channel attack that allows the extraction of secret keys from constant-time cryptographic implementations. These types of attacks require local access to the targeted system. The attack targets a hardware optimization named data memory-dependent prefetcher (DMP), which attempts to prefetch addresses found in the contents of program memory to improve performance.

The researchers have found a way to use specially crafted cryptographic operation inputs that allow them to infer secret keys, guessing them bits at a time by monitoring the behavior of the DMP. They managed to demonstrate end-to-end key extraction attacks against several crypto implementations, including OpenSSL Diffie-Hellman Key Exchange, Go RSA, and the post-quantum CRYSTALS-Kyber and CRYSTALS-Dilithium. The researchers have conducted successful GoFetch attacks against systems powered by Apple M1 processors, and they have found evidence that the attack could also work against M2 and M3 processors. They have also tested an Intel processor that uses DMP, but found that it’s ‘more robust’ against such attacks.

The experts said Apple is investigating the issue, but fully addressing it does not seem trivial. The researchers have proposed several countermeasures, but they involve hardware changes that are not easy to implement or mitigations that can have a significant impact on performance. Apple told SecurityWeek that it thanks the researchers for their collaboration as this work advances the company’s understanding of these types of threats. The tech giant also shared a link to a developer page that outlines one of the mitigations mentioned by the researchers. The researchers have published a paper (PDF) detailing their work.

Ars Technica’s Dan Goodin also reported on the vulnerability.

Read more of this story at Slashdot.

Researchers at Cado Security Labs received an alert about a honeypot using the Docker Engine API. “A Docker command was received…” they write, “that spawned a new container, based on Alpine Linux, and created a bind mount for the underlying honeypot server’s root directory…”
Typically, this is exploited to write out a job for the Cron scheduler to execute… In this particular campaign, the attacker exploits this exact method to write out an executable at the path /usr/bin/vurl, along with registering a Cron job to decode some base64-encoded shell commands and execute them on the fly by piping through bash.

The vurl executable consists solely of a simple shell script function, used to establish a TCP connection with the attacker’s Command and Control (C2) infrastructure via the /dev/tcp device file. The Cron jobs mentioned above then utilise the vurl executable to retrieve the first stage payload from the C2 server… To provide redundancy in the event that the vurl payload retrieval method fails, the attackers write out an additional Cron job that attempts to use Python and the urllib2 library to retrieve another payload named t.sh

“Multiple user mode rootkits are deployed to hide malicious processes,” they note. And one of the shell scripts “makes use of the shopt (shell options) built-in to prevent additional shell commands from the attacker’s session from being appended to the history file… Not only are additional commands prevented from being written to the history file, but the shopt command itself doesn’t appear in the shell history once a new session has been spawned.”

The same script also inserts “an attacker-controlled SSH key to maintain access to the compromised host,” according to the article, retrieves a miner for the Monero cryptocurrency and then “registers persistence in the form of systemd services” for both the miner and an open source Golang reverse shell utility named Platypus.

It also delivers “various utilities,” according to the blog Security Week, “including ‘masscan’ for host discovery.” Citing CADO’s researchers, they write that the shell script also “weakens the machine by disabling SELinux and other functions and by uninstalling monitoring agents.”
The Golang payloads deployed in these attacks allow attackers to search for Docker images from the Ubuntu or Alpine repositories and delete them, and identify and exploit misconfigured or vulnerable Hadoop, Confluence, Docker, and Redis instances exposed to the internet… [“For the Docker compromise, the attackers spawn a container and escape from it onto the underlying host,” the researchers writes.]

“This extensive attack demonstrates the variety in initial access techniques available to cloud and Linux malware developers,” Cado notes. “It’s clear that attackers are investing significant time into understanding the types of web-facing services deployed in cloud environments, keeping abreast of reported vulnerabilities in those services and using this knowledge to gain a foothold in target environments.”

Read more of this story at Slashdot.