Apr 10, 2024NewsroomSoftware Security / Vulnerability

A critical security flaw in the Rust standard library could be exploited to target Windows users and stage command injection attacks.

The vulnerability, tracked as CVE-2024-24576, has a CVSS score of 10.0, indicating maximum severity. That said, it only impacts scenarios where batch files are invoked on Windows with untrusted arguments.

“The Rust standard library did not properly escape arguments when invoking batch files (with the bat and cmd extensions) on Windows using the Command API,” the Rust Security Response working group said in an advisory released on April 9, 2024.

“An attacker able to control the arguments passed to the spawned process could execute arbitrary shell commands by bypassing the escaping.”

The flaw impacts all versions of Rust before 1.77.2. Security researcher RyotaK has been credited with discovering and reporting the bug to the CERT Coordination Center (CERT/CC).

RyotaK said the vulnerability – codenamed BatBadBut – impacts several programming languages and that it arises when the “programming language wraps the CreateProcess function [in Windows] and adds the escaping mechanism for the command arguments.”

But in light of the fact that not every programming language has addressed the problem, developers are being recommended to exercise caution when executing commands on Windows.

“To prevent the unexpected execution of batch files, you should consider moving the batch files to a directory that is not included in the PATH environment variable,” RyotaK said in a word of advice to users.

“In this case, the batch files won’t be executed unless the full path is specified, so the unexpected execution of batch files can be prevented.”

Apr 04, 2024NewsroomVulnerability / Internet Protocol

New research has found that the CONTINUATION frame in the HTTP/2 protocol can be exploited to conduct denial-of-service (DoS) attacks.

The technique has been codenamed HTTP/2 CONTINUATION Flood by security researcher Bartek Nowotarski, who reported the issue to the CERT Coordination Center (CERT/CC) on January 25, 2024.

“Many HTTP/2 implementations do not properly limit or sanitize the amount of CONTINUATION frames sent within a single stream,” CERT/CC said in an advisory on April 3, 2024.

“An attacker that can send packets to a target server can send a stream of CONTINUATION frames that will not be appended to the header list in memory but will still be processed and decoded by the server or will be appended to the header list, causing an out of memory (OOM) crash.”

Like in HTTP/1, HTTP/2 uses header fields within requests and responses. These header fields can comprise header lists, which in turn, are serialized and broken into header blocks. The header blocks are then divided into block fragments and transmitted within HEADER or what’s called CONTINUATION frames.

“The CONTINUATION frame (type=0x9) is used to continue a sequence of header block fragments,” the documentation for RFC 7540 reads.

“Any number of CONTINUATION frames can be sent, as long as the preceding frame is on the same stream and is a HEADERS, PUSH_PROMISE, or CONTINUATION frame without the END_HEADERS flag set.”

The last frame containing headers will have the END_HEADERS flag set, which signals the remote endpoint that it’s the end of the header block.

According to Nowotarski, CONTINUATION Flood is a class of vulnerabilities within several HTTP/2 protocol implementations that pose a more severe threat compared to the Rapid Reset attack that came to light in October 2023.

“A single machine (and in certain instances, a mere single TCP connection or a handful of frames) has the potential to disrupt server availability, with consequences ranging from server crashes to substantial performance degradation,” the researcher said. “Remarkably, requests that constitute an attack are not visible in HTTP access logs.”

The vulnerability, at its core, has to do with incorrect handling of HEADERS and multiple CONTINUATION frames that pave the way for a DoS condition.

In other words, an attacker can initiate a new HTTP/2 stream against a target server using a vulnerable implementation and send HEADERS and CONTINUATION frames with no set END_HEADERS flag, creating a never-ending stream of headers that the HTTP/2 server would need to parse and store in memory.

While the exact outcome varies depending on the implementation, impacts range from instant crash after sending a couple of HTTP/2 frames and out of memory crash to CPU exhaustion, thereby affecting server availability.

“RFC 9113 […] mentions multiple security issues that may arise if CONTINUATION frames are not handled correctly,” Nowotarski said.

“At the same time, it does not mention a specific case in which CONTINUATION frames are sent without the final END_HEADERS flag which can have repercussions on affected servers.”

The issue impacts several projects such as amphp/http (CVE-2024-2653), Apache HTTP Server (CVE-2024-27316), Apache Tomcat (CVE-2024-24549), Apache Traffic Server (CVE-2024-31309), Envoy proxy (CVE-2024-27919 and CVE-2024-30255), Golang (CVE-2023-45288), h2 Rust crate, nghttp2 (CVE-2024-28182), Node.js (CVE-2024-27983), and Tempesta FW (CVE-2024-2758).

Users are recommended to upgrade affected software to the latest version to mitigate potential threats. In the absence of a fix, it’s advised to consider temporarily disabling HTTP/2 on the server.

Feb 27, 2024NewsroomSupply Chain Attack / Data Security

Cybersecurity researchers have found that it’s possible to compromise the Hugging Face Safetensors conversion service to ultimately hijack the models submitted by users and result in supply chain attacks.

“It’s possible to send malicious pull requests with attacker-controlled data from the Hugging Face service to any repository on the platform, as well as hijack any models that are submitted through the conversion service,” HiddenLayer said in a report published last week.

This, in turn, can be accomplished using a hijacked model that’s meant to be converted by the service, thereby allowing malicious actors to request changes to any repository on the platform by masquerading as the conversion bot.

Hugging Face is a popular collaboration platform that helps users host pre-trained machine learning models and datasets, as well as build, deploy, and train them.

Safetensors is a format devised by the company to store tensors keeping security in mind, as opposed to pickles, which has been likely weaponized by threat actors to execute arbitrary code and deploy Cobalt Strike, Mythic, and Metasploit stagers.

It also comes with a conversion service that enables users to convert any PyTorch model (i.e., pickle) to its Safetensor equivalent via a pull request.

HiddenLayer’s analysis of this module found that it’s hypothetically possible for an attacker to hijack the hosted conversion service using a malicious PyTorch binary and compromise the system hosting it.

What’s more, the token associated with SFConvertbot – an official bot designed to generate the pull request – could be exfiltrated to send a malicious pull request to any repository on the site, leading to a scenario where a threat actor could tamper with the model and implant neural backdoors.

“An attacker could run any arbitrary code any time someone attempted to convert their model,” researchers Eoin Wickens and Kasimir Schulz noted. “Without any indication to the user themselves, their models could be hijacked upon conversion.”

Should a user attempt to convert their own private repository, the attack could pave the way for the theft of their Hugging Face token, access otherwise internal models and datasets, and even poison them.

Complicating matters further, an adversary could take advantage of the fact that any user can submit a conversion request for a public repository to hijack or alter a widely used model, potentially resulting in a considerable supply chain risk.

“Despite the best intentions to secure machine learning models in the Hugging Face ecosystem, the conversion service has proven to be vulnerable and has had the potential to cause a widespread supply chain attack via the Hugging Face official service,” the researchers said.

“An attacker could gain a foothold into the container running the service and compromise any model converted by the service.”

The development comes a little over a month after Trail of Bits disclosed LeftoverLocals (CVE-2023-4969, CVSS score: 6.5), a vulnerability that allows recovery of data from Apple, Qualcomm, AMD, and Imagination general-purpose graphics processing units (GPGPUs).

The memory leak flaw, which stems from a failure to adequately isolate process memory, enables a local attacker to read memory from other processes, including another user’s interactive session with a large language model (LLM).

“This data leaking can have severe security consequences, especially given the rise of ML systems, where local memory is used to store model inputs, outputs, and weights,” security researchers Tyler Sorensen and Heidy Khlaaf said.

Feb 15, 2024The Hacker NewsSaaS Security / Risk Management

With many of the highly publicized 2023 cyber attacks revolving around one or more SaaS applications, SaaS has become a cause for genuine concern in many boardroom discussions. More so than ever, considering that GenAI applications are, in fact, SaaS applications.

Wing Security (Wing), a SaaS security company, conducted an analysis of 493 SaaS-using companies in Q4 of 2023. Their study reveals how companies use SaaS today, and the wide variety of threats that result from that usage. This unique analysis provides rare and important insights into the breadth and depth of SaaS-related risks, but also provides practical tips to mitigate them and ensure SaaS can be widely used without compromising security posture.

The TL;DR Version Of SaaS Security

2023 brought some now infamous examples of malicious players leveraging or directly targeting SaaS, including the North Korean group UNC4899, 0ktapus ransomware group, and Russian Midnight Blizzard APT, which targeted well-known organizations such as JumpCloud, MGM Resorts, and Microsoft (respectively), and probably many others that often go unannounced.

The first insight from this research cements the concept that SaaS is the new supply chain, providing an almost intuitive framework to the importance of securing SaaS usage. These applications are clearly an integral part of the modern organization’s set of tools and vendors. That said, long gone are the days when every 3rd party with access to company data had to go through security or IT approval. Even in the most rigorous companies, when a diligent employee needs a quick and efficient solution, they’ll look it up and use it to get their jobs’ done faster and better. Again, think of the widespread use of GenAI, and the picture is clear.

As such, any organization concerned about the security of its supply chain must adopt SaaS security measures. According to the MITRE ATT&CK technique ‘Trusted Relationships’ (T1199), a supply chain attack occurs when an attacker targets a vendor to exploit it as a means to infiltrate a broader network of companies. By entrusting sensitive data to external SaaS vendors, organizations subject themselves to supply chain risks that reach beyond immediate security concerns.

Four Common SaaS Risks

There are various reasons and ways in which SaaS is being targeted. The good news is that most of the risks can be significantly mitigated when monitored and controlled. Basic SaaS security capabilities are even free, suited for organizations that are just beginning to develop their SaaS security posture or need to compare it to their current solution.

1) Shadow SaaS

The first problem with SaaS usage is the fact that it often goes completely unnoticed: The number of applications used by organizations is typically 250% larger than what a basic and often-used query of the workspace reveals.

Amongst the companies analyzed:

• 41% of applications were used by only one individual, resulting in a very long tail of unsanctioned applications.
• 1 out of 5 users were utilizing applications not used by anyone else within their organization, creating security and resource strains.
• 63% of single-user applications were not even accessed within a 3-month period, begging the question – why keep them connected to company data?
• 96.7% of organizations used at least one application that had a security incident in the previous year, solidifying the continuous risk and need for proper mitigation.

2) MFA Bypassing

Wing’s research indicates a trend where users opt to use a username/password to access the services they need, bypassing the security measures in place (see image 1).

Image 1: From Wing Security’s research, bypassing MFA.

3) Forgotten tokens

Users grant the applications they need tokens; this is necessary for the SaaS applications to serve their purpose. The problem is that these tokens are often forgotten about after a few or just one use. Wing’s research revealed a large presence of unused tokens over a period of 3 months, creating an unnecessarily large attack surface for many customers (Image 2).

4) The new risk of Shadow AI

In the beginning of 2023, security teams primarily concentrated on a select few renowned services offering access to AI-based models. However, as the year progressed, thousands of conventional SaaS applications adopted AI models. The research shows that 99.7% of companies were using applications with integrated AI capabilities.

Organizations were required to agree to updated terms and conditions permitting these applications to utilize and refine their models using the organizations’ most confidential data. Often, these revised terms and conditions slipped under the radar, along with the usage of AI itself.

There are different ways in which AI applications may use your data for their training models. This can come in the form of learning your data, storing your data and even having a human manually go over your data to improve the AI model. According to Wing, this capability is often configurable and totally avoidable, provided it is not overlooked.

Solving SaaS Security Challenges In 2024

The report ends on a positive note, listing 8 ways in which companies can mitigate the growing threat of the SaaS supply chain. Including:

1. Ongoing shadow IT discovery and management.
2. Prioritize the remediation of SaaS misconfigurations
3. Optimize anomaly detection with predefined frameworks, automate when possible.
4. Discover and monitor all AI-using SaaS applications, and constantly monitor your SaaS for updates in their T&C pertaining to AI usage.

For the full list of findings, tips on ensuring safe SaaS usage and a 2024 SaaS security forecast, download the full report here.

Feb 07, 2024NewsroomCybersecurity / Software Security

JetBrains is alerting customers of a critical security flaw in its TeamCity On-Premises continuous integration and continuous deployment (CI/CD) software that could be exploited by threat actors to take over susceptible instances.

The vulnerability, tracked as CVE-2024-23917, carries a CVSS rating of 9.8 out of 10, indicative of its severity.

“The vulnerability may enable an unauthenticated attacker with HTTP(S) access to a TeamCity server to bypass authentication checks and gain administrative control of that TeamCity server,” the company said.

The issue impacts all TeamCity On-Premises versions from 2017.1 through 2023.11.2. It has been addressed in version 2023.11.3. An unnamed external security researcher has been credited with discovering and reporting the flaw on January 19, 2024.

Users who are unable to update their servers to version 2023.11.3 can alternately download a security patch plugin to apply fixes for the flaw.

“If your server is publicly accessible over the internet and you are unable to take one of the above mitigation steps immediately, we recommend temporarily making it inaccessible until mitigation actions have been completed,” JetBrains advised.

While there is no evidence that the shortcoming has been abused in the wild, a similar flaw in the same product (CVE-2023-42793, CVSS score: 9.8) came under active exploitation last year within days of public disclosure by multiple threat actors, including ransomware gangs and state-sponsored groups affiliated with North Korea and Russia.

Jan 25, 2024NewsroomRemote Access Trojan

Cybersecurity researchers have shed light on the command-and-control (C2) server of a known malware family called SystemBC.

“SystemBC can be purchased on underground marketplaces and is supplied in an archive containing the implant, a command-and-control (C2) server, and a web administration portal written in PHP,” Kroll said in an analysis published last week.

The risk and financial advisory solutions provider said it has witnessed an increase in the use of malware throughout Q2 and Q3 2023.

SystemBC, first observed in the wild in 2018, allows threat actors to remote control a compromised host and deliver additional payloads, including trojans, Cobalt Strike, and ransomware. It also features support for launching ancillary modules on the fly to expand on its core functionality.

A standout aspect of the malware revolves around its use of SOCKS5 proxies to mask network traffic to and from C2 infrastructure, acting as a persistent access mechanism for post-exploitation.

Customers who end up purchasing SystemBC are provided with an installation package that includes the implant executable, Windows and Linux binaries for the C2 server, and a PHP file for rendering the C2 panel interface, alongside instructions in English and Russian that detail the steps and commands to run.

The C2 server executables — “server.exe” for Windows and “server.out” for Linux — are designed to open up no less than three TCP ports for facilitating C2 traffic, inter-process communication (IPC) between itself and the PHP-based panel interface (typically port 4000), and one for each active implant (aka bot).

The server component also makes use of three other files to record information regarding the interaction of the implant as a proxy and a loader, as well as details pertaining to the victims.

The PHP-based panel, on the other hand, is minimalist in nature and displays a list of active implants at any given point of time. Furthermore, it acts as a conduit to run shellcode and arbitrary files on a victim machine.

“The shellcode functionality is not only limited to a reverse shell, but also has full remote capabilities that can be injected into the implant at runtime, while being less obvious than spawning cmd.exe for a reverse shell,” Kroll researchers said.

The development comes as the company also shared an analysis of an updated version of DarkGate (version 5.2.3), a remote access trojan (RAT) that enables attackers to fully compromise victim systems, siphon sensitive data, and distribute more malware.

“The version of DarkGate that was analyzed shuffles the Base64 alphabet in use at the initialization of the program,” security researcher Sean Straw said. “DarkGate swaps the last character with a random character before it, moving from back to front in the alphabet.”

Kroll said it identified a weakness in this custom Base64 alphabet that makes it trivial to decode the on-disk configuration and keylogging outputs, which are encoded using the alphabet and stored within an exfiltration folder on the system.

“This analysis enables forensic analysts to decode the configuration and keylogger files without needing to first determine the hardware ID,” Straw said. “The keylogger output files contain keystrokes stolen by DarkGate, which can include typed passwords, composed emails and other sensitive information.”

Jan 25, 2024NewsroomVulnerability / Software Security

The maintainers of the open-source continuous integration/continuous delivery and deployment (CI/CD) automation software Jenkins have resolved nine security flaws, including a critical bug that, if successfully exploited, could result in remote code execution (RCE).

The issue, assigned the CVE identifier CVE-2024-23897, has been described as an arbitrary file read vulnerability through the built-in command line interface (CLI)

“Jenkins uses the args4j library to parse command arguments and options on the Jenkins controller when processing CLI commands,” the maintainers said in a Wednesday advisory.

“This command parser has a feature that replaces an @ character followed by a file path in an argument with the file’s contents (expandAtFiles). This feature is enabled by default and Jenkins 2.441 and earlier, LTS 2.426.2 and earlier does not disable it.”

A threat actor could exploit this quirk to read arbitrary files on the Jenkins controller file system using the default character encoding of the Jenkins controller process.

While attackers with “Overall/Read” permission can read entire files, those without it can read the first three lines of the files depending on the CLI commands.

Additionally, the shortcoming could be weaponized to read binary files containing cryptographic keys, albeit with certain restrictions. Provided the binary secrets can be extracted, Jenkins says it could open the door to various attacks –

• Remote code execution via Resource Root URLs
• Remote code execution via “Remember me” cookie
• Remote code execution via stored cross-site scripting (XSS) attacks through build logs
• Remote code execution via CSRF protection bypass
• Decrypt secrets stored in Jenkins
• Delete any item in Jenkins
• Download a Java heap dump

“While files containing binary data can be read, the affected feature attempts to read them as strings using the controller process’s default character encoding,” Jenkins said.

“This is likely to result in some bytes not being read successfully and being replaced with a placeholder value. Which bytes can or cannot be read depends on this character encoding.”

Security researcher Yaniv Nizry has been credited with discovering and reporting the flaw, which has been fixed in Jenkins 2.442, LTS 2.426.3 by disabling the command parser feature.

As a short-term workaround until the patch can be applied, it’s recommended to turn off access to the CLI.

The development comes nearly a year after Jenkins addressed a pair of severe security vulnerabilities dubbed CorePlague (CVE-2023-27898 and CVE-2023-27905) that could lead to code execution on targeted systems.

Jan 17, 2024NewsroomSpyware / Forensic Analysis

Cybersecurity researchers have identified a “lightweight method” called iShutdown for reliably identifying signs of spyware on Apple iOS devices, including notorious threats like NSO Group’s Pegasus, QuaDream’s Reign, and Intellexa’s Predator.

Kaspersky, which analyzed a set of iPhones that were compromised with Pegasus, said the infections left traces in a file named “Shutdown.log,” a text-based system log file available on all iOS devices and which records every reboot event alongside its environment characteristics.

“Compared to more time-consuming acquisition methods like forensic device imaging or a full iOS backup, retrieving the Shutdown.log file is rather straightforward,” security researcher Maher Yamout said. “The log file is stored in a sysdiagnose (sysdiag) archive.”

The Russian cybersecurity firm said it identified entries in the log file that recorded instances where “sticky” processes, such as those associated with the spyware, caused a reboot delay, in some cases observing Pegasus-related processes in over four reboot delay notices.

What’s more, the investigation revealed a the presence of a similar filesystem path that’s used by all the three spyware families – “/private/var/db/” for Pegasus and Reign, and “/private/var/tmp/” for Predator – thereby acting as an indicator of compromise.

That said, the success of this approach hinges on a caveat that the target user reboots their device as often as possible, the frequency for which varies according to their threat profile.

Kaspersky has also published a collection of Python scripts to extract, analyze, and parse the Shutdown.log in order to extract the reboot stats.

“The lightweight nature of this method makes it readily available and accessible,” Yamout said. “Moreover, this log file can store entries for several years, making it a valuable forensic artifact for analyzing and identifying anomalous log entries.”

The disclosure comes as SentinelOne revealed information stealers targeting macOS such as KeySteal, Atomic, and JaskaGo (aka CherryPie or Gary Stealer) are quickly adapting to circumvent Apple’s built-in antivirus technology called XProtect.

“Despite solid efforts by Apple to update its XProtect signature database, these rapidly evolving malware strains continue to evade,” security researcher Phil Stokes said. “Relying solely on signature-based detection is insufficient as threat actors have the means and motive to adapt at speed.”

Jan 17, 2024NewsroomVulnerability / Software Security

GitHub has revealed that it has rotated some keys in response to a security vulnerability that could be potentially exploited to gain access to credentials within a production container.

The Microsoft-owned subsidiary said it was made aware of the problem on December 26, 2023, and that it addressed the issue the same day, in addition to rotating all potentially exposed credentials out of an abundance of caution.

The rotated keys include the GitHub commit signing key as well as GitHub Actions, GitHub Codespaces, and Dependabot customer encryption keys, necessitating users who rely on these keys to import the new ones.

There is no evidence that the high-severity vulnerability tracked as CVE-2024-0200 (CVSS score: 7.2), has been previously found and exploited in the wild.

“This vulnerability is also present on GitHub Enterprise Server (GHES),” GitHub’s Jacob DePriest said. “However, exploitation requires an authenticated user with an organization owner role to be logged into an account on the GHES instance, which is a significant set of mitigating circumstances to potential exploitation.”

In a separate advisory, GitHub characterized the vulnerability as a case of “unsafe reflection” GHES that could lead to reflection injection and remote code execution. It has been patched in GHES versions 3.8.13, 3.9.8, 3.10.5, and 3.11.3.

Also addressed by GitHub is another high-severity bug tracked as CVE-2024-0507 (CVSS score: 6.5), which could permit an attacker with access to a Management Console user account with the editor role to escalate privileges via command injection.

The development comes nearly a year after the company took the step of replacing its RSA SSH host key used to secure Git operations “out of an abundance of caution” after it was briefly exposed in a public repository.

Dec 27, 2023NewsroomZero-Day / Vulnerability

A new zero-day security flaw has been discovered in the Apache OfBiz, an open-source Enterprise Resource Planning (ERP) system that could be exploited to bypass authentication protections.

The vulnerability, tracked as CVE-2023-51467, resides in the login functionality and is the result of an incomplete patch for another critical vulnerability (CVE-2023-49070, CVSS score: 9.8) that was released earlier this month.

“The security measures taken to patch CVE-2023-49070 left the root issue intact and therefore the authentication bypass was still present,” the SonicWall Capture Labs threat research team, which discovered the bug, said in a statement shared with The Hacker News.

CVE-2023-49070 refers to a pre-authenticated remote code execution flaw impacting versions prior to 18.12.10 that, when successfully exploited, could allow threat actors to gain full control over the server and siphon sensitive data. It is caused due to a deprecated XML-RPC component within Apache OFBiz.

According to SonicWall, CVE-2023-51467 could be triggered using empty and invalid USERNAME and PASSWORD parameters in an HTTP request to return an authentication success message, effectively circumventing the protection and enabling a threat actor to access otherwise unauthorized internal resources.

The attack hinges on the fact that the parameter “requirePasswordChange” is set to “Y” (i.e., yes) in the URL, causing the authentication to be trivially bypassed regardless of the values passed in the username and password fields.

“The vulnerability allows attackers to bypass authentication to achieve a simple Server-Side Request Forgery (SSRF),” according to a description of the flaw on the NIST National Vulnerability Database (NVD).

Users who rely on Apache OFbiz to update to version 18.12.11 or later as soon as possible to mitigate any potential threats.