Confidentiality and authentication flaws uncovered by researchers

Emma Woollacott 04 October 2022 at 14:49 UTC  
Updated: 04 October 2022 at 16:00 UTC

Confidentiality and authentication flaws uncovered by researchers

Matrix has patched five serious vulnerabilities in its end-to-end encryption that break the confidentiality and authentication of messages.

The flaws would allow a malicious server to read user messages and impersonate devices.

Matrix currently has 69 million accounts in total, spread over around 100,000 servers. The technology provides a federated communication protocol, allowing clients with accounts on different Matrix servers – their homeservers – to exchange messages across the entire ecosystem.

The platform enables end-to-end encryption by default.

However, four researchers – Martin Albrecht of the Royal Holloway, University of London, Sofía Celi of Brave Software, Benjamin Dowling of the University of Sheffield, and Daniel Jones of the University of London – have demonstrated (PDF) five practically-exploitable flaws.

**Fairly straightforward**

The vulnerabilities, two of which are rated critical, undermine assurances of authentication and confidentiality normally offered by the Matrix platform.

"All our attacks require a malicious homeserver – the server where users create accounts – i.e., no external party could mount them because all Matrix communication between clients and servers and between servers for federation are protected by TLS," Albrecht told The Daily Swig.

Catch up with the latest encryption-related news and analysis

"Now, for a malicious homeserver, carrying out these attacks would have been easy. We have implemented proof-of-concept attacks for the vulnerabilities we reported, and these \[are\] usually fairly straightforward."

The first critical vulnerability, CVE-2022-39250, is key/device identifier confusion in SAS verification, a bug in matrix-js-sdk that confuses device IDs and cross-signing keys. “This could be exploited by a malicious server admin to break emoji-based verification when cross-signing is in use, authenticating themselves rather than the target user,” according to a security notice by the developers of Matrix.

The other critically-rate flaw, CVE-2022-39251, is a protocol-confusion bug that incorrectly accepts to-device messages encrypted by Megolm rather than Olm, attributing them to the Megolm sender rather than the actual sender. The vulnerability potentially allows an attacker to send fake keys in order to spoof historical messages from other users.

In addition, the flaw creates a means to add a malicious key backup to a user’s account in order to exfiltrate message keys. Matrix’s developers said this attack scenario, which would require certain unusual preconditions, has not been detected in the wild.

**Impersonation attack**

Meanwhile, a semi-trusted impersonation attack exploits a lack of verification in Element in order to send attacker-controlled Megolm sessions to a target device, falsely posing as a session of the device they wish to impersonate.

Another vulnerability allows a malicious homeserver to add users under their control to end-to-end encrypted rooms – where they can then decrypt future messages sent in the room. This happens because room management messages aren’t authenticated in the Matrix specification, meaning they can be faked by a rogue homeserver.

Lastly Matrix’s use of AES-CTR to encrypt attachments, secrets, and symmetric key backups was faulted for lacking cryptographical rigour. Not good but, as the researchers acknowledge, this IND-CCA break falls short of anything that would result in a practical attack.

The researchers conclude that some of the vulnerabilities reside in the Matrix protocol itself, saying that they highlight the need for a systematic and formal analysis of the cryptography in the Matrix standard.

**Enter the Matrix**

However, the developers of Matrix dispute this.

"We consider the protocol itself to be sound and our security processes to be robust," Matthew Hodgson, co-founder and project lead for Matrix and CEO/CTO at Element, told The Daily Swig.

"For instance, we’re currently in the middle of a series of public, independent audits of our next-gen SDKs \[software development kits\] from Least Authority, and it’s worth noting that our next-gen implementations are not vulnerable to the implementation bugs in question here."

Albrecht responded: "The Matrix developers have shared with us their plans for addressing the issues we argued about, so we are hopeful that eventually the right outcome – Matrix achieving the security guarantees that it promises – will be achieved."

Element offers the flagship client and prototype implementation of Matrix.

RELATED Let’s Encrypt builds infrastructure to support browser-based certificate revocation revival

Matrix address flaws that break message encryption assurances

Affected firms alerted to bug whose potential impact is heightened by vm2’s use in production environments

Ben Dickson 04 October 2022 at 12:48 UTC

Affected firms alerted to bug whose potential impact is heightened by vm2’s use in production environments

A bug in vm2, a popular JavaScript sandbox environment, could allow malicious actors to bypass sandbox protections and stage remote code execution (RCE) on the host device.

Vm2, which has more than four million downloads per week, creates a secure context in Node.js servers to run untrusted code without compromising the server.

The potential impact of the vulnerability, which was given a maximum possible CVSS score of 10, was elevated by the fact that vm2 is used in production as well as developer environments.

**‘Interesting technique’**

The security flaw was discovered by Oxeye Security researchers Gal Goldshtein and Yuval Ostrovsky. “Our usual approach when evaluating a given software’s security is first to analyze the previous security lapses discovered in the same software,” the Oxeye security team told The Daily Swig.

RECOMMENDED Patching common vulnerabilities at scale: project promises bulk pull requests

“This helps us better grasp the available attack surface and may also lead to low-hanging bugs stemming from incomplete fixes.

“While reviewing the previous bugs disclosed to the vm2 maintainers, we noticed an interesting technique: the bug reporter abused the error mechanism in Node.js to escape the sandbox.”

**Channels between sandbox and host**

Like several previous bugs found in vm2, the new bug relies on the channels the sandbox uses to communicate with the host machine. In this case, the bug was caused by improper exception handling.

“The bug we found relies on a technique that is quite common in the VM bypass world, which is to find elements within the sandbox that can cooperate with elements outside of it,” the researchers said.

“This connection, when found, gives the attacker the opportunity to interact with the hosting process.”

This channel allows the attacker to run arbitrary code on the Node.js server, including invoking functions that run system commands.

The team aims to release a technical review of the bug with more details soon. The only way to prevent exploits is to upgrade to the newest version of vm2.

**‘Meant to run untrusted code’**

“We weren’t surprised by the fact that this library is used in production environments, mainly due to the fact that it has over 16 million downloads per month,” the researchers said. “We are in the process of responsible disclosure with several companies where we found this vulnerability in.”

In a separate advisory, RedHat has released a list of its services that are affected by the vm2 flaw.

This is not the first time that vm2 has patched a sandbox bypass, which only highlights the difficulties of securing sandbox environments.

“Sandboxes in general are meant to run untrusted code within an application. This means that you shouldn’t automatically assume that they are safe,” the researchers said.

“If the use of a sandbox is unavoidable, we recommend separating the logical, sensitive part of the application from the microservice that runs the sandbox code so if a threat actor successfully breaks out from the sandbox, the attack surface is limited to the isolated microservice.”

DON’T FORGET TO READ Rancher stored sensitive values in plaintext, risked Kubernetes cluster takeover

JavaScript sandbox vm2 remediates remote code execution risk

A lesson in how to achieve maximum value for your discoveries

Emma Woollacott 04 October 2022 at 10:41 UTC  
Updated: 04 October 2022 at 10:48 UTC

A lesson in how to achieve maximum value for your discoveries

  

Two Italian security researchers have netted more than $46,000 in bounties for the discovery of an Akamai misconfiguration, despite receiving nothing from Akamai itself.

Akamai is one of the most widely used content delivery networks (CDNs) in the world, used by more than a thousand companies including Apple, Microsoft, Airbnb, and the US Department of Defense.

While hunting for bugs in a website using Akamai via bug bounty platform Whitejar, researchers Jacopo Tediosi and Francesco Mariani discovered a misconfiguration that allowed them to poison the cache with arbitrary content.

Read more of the latest bug bounty research

The vulnerability is a combination of common HTTP smuggling and hop-by-hop headers abuse techniques, the researchers said.

Special headers named ‘hop-by-hop’ are removed from proxies before forwarding requests to the next proxy or the destination.

However, specifying the header as ‘hop-by-hop’ led Akamai Edge Nodes to remove it. This caused a desynchronization with subsequent nodes, which interpreted part of the HTTP request as a separate, second new request.

This second response was queued and was subsequently sent in response to requests from other clients or users, causing a HTTP smuggling vulnerability.

“An attacker could have inserted malicious arbitrary content into any domain served by the Akamai network, affecting their major customers such as the US Department of Defense, PayPal, Airbnb, Mastercard, PlayStation, Microsoft, Apple, etc,” Tediosi told The Daily Swig.

“This means that they could alter the appearance and behaviour of those websites as they wish. They could also make users’ browsers perform unintended actions on the original sites, as if the users were doing them.”

**Fixes available**

The company has since fixed the issue by preventing the specification of the keyword within the header value, although an advisory has not yet been published.

Tediosi and Mariani contacted Akamai on March 24 and arranged to coordinate disclosure, with a silent fix deployed on April 2. Unfortunately, they were told at the start of the process that the company doesn’t offer bug bounties or other rewards.

However, while Akamai was working on the patch the pair decided to try and pursue bounties from some of the company’s customers.

“It was the only way to get our work rewarded, as Akamai didn’t have a bug bounty program. I honestly didn’t want to use this solution, but it worked anyway and allowed us to stay ethical,” says Tediosi.

“It worries me a little that difficulties like these may tempt researchers not to report vulnerabilities they find, leaving security holes around the web, or even worse, selling them in black markets.”

The pair immediately received $5,000 from Whitejar for the original research. And while a number of bug bounty platforms and organizations – including Bugcrowd, Microsoft, and Apple – were unable to replicate the vulnerability, others were happy to pay up.

The bounties included $25,200 from PayPal, $14,875 from Airbnb, $4,000 from Hyatt Hotels, $750 from Valve, $450 from Zomato, and $100 from Goldman Sachs.

Tediosi says he believes that the use of hop-by-hop headers for smuggling may affect other implementations besides Akamai and deserves further research. In addition, he suggests, it may be possible to bypass Akamai’s fix.

RECOMMENDED Browser-powered desync: A new class of HTTP request smuggling attacks

Researchers net $46k for Akamai misconfiguration vulnerability

‘ProxyNotShell’ abuse less severe than 2021 attack wave due to authentication requirement

‘ProxyNotShell’ abuse less severe than 2021 attack wave due to authentication requirement

Microsoft is developing a patch for two actively exploited zero-day vulnerabilities in Microsoft Exchange Server.

The flaws, tracked as CVE-2022-41040 and CVE-2022-41082, were discovered in Microsoft’s enterprise mail server by Vietnamese cybersecurity firm GTSC. Microsoft said it is aware of “a small number of targeted attacks” exploiting the flaws, which impact on-prem Microsoft Exchange Server versions 2013, 2016, and 2019.

The bugs appear to be less dangerous variants – on account of authentication to PowerShell being required – of the critical ProxyShell vulnerabilities that were widely abused in 2021.

**RCE chain**

In GTSC's original security advisory, researchers said they discovered an attack on “critical” infrastructure made through Exchange Server in August.

The first vulnerability, CVE-2022-41040 (CVSS 8.8), is a server-side request forgery (SSRF) issue. When triggered remotely to launch CVE-2022-41082 (CVSS 6.3), the bug could result in remote code execution (RCE).

Catch up of the latest enterprise security news

As the vulnerabilities are yet to be patched, the full technical details have not been released – but proof-of-concept (PoC) code is expected to appear soon.

GTSC informed Trend Micro’s Zero Day Initiative (ZDI) of its findings. After ZDI verified the flaws and reached out to the Microsoft Security Response Center (MSRC), the Redmond giant confirmed the report and published an analysis of attacks exploiting the flaws.

“Authenticated access to the vulnerable Exchange Server is necessary to successfully exploit either vulnerability, and they can be used separately,” Microsoft noted.

Unfortunately, the authentication required is nothing more than a standard user. As a result, cybercriminals could obtain these credentials via theft, credential stuffing, and brute-force attacks.

**State-sponsored attacks**

According to Microsoft, fewer than 10 organizations worldwide have been targeted by what is likely a “state-sponsored organization”.

GTSC researchers said there are indicators that a Chinese threat group is leveraging Antsword, a Chinese cross-platform website management suite with web shell functionality.

China Chopper, a web shell, has apparently been used to perform Active Directory reconnaissance and data exfiltration. If this sounds familiar, the same web shell was used in attacks exploiting Exchange Server zero-day vulnerabilities in 2021. These attacks were attributed to the state-sponsored Chinese threat group HAFNIUM.

BACKGROUND ‘A whole new attack surface’ – Researcher Orange Tsai documents ProxyLogon exploits against Microsoft Exchange Server

Security researcher Kevin Beaumont has noted similarities between the paths used by the new bugs, which he has dubbed ‘ProxyNotShell’, and the zero days from last year.

Devcore researcher Orange Tsai, who discovered the original, ProxyShell flaws, suggested in a talk at Black Hat USA (PDF) last year that fundamental path confusion issues could see further ProxyShell variants emerge – a prediction that has now come to pass.

**Mitigation advice**

Microsoft has released customer guidance for mitigating the new bugs while it works on a patch.

The company is urging customers to disable remote PowerShell access for non-administrators immediately. If the Exchange Emergency Mitigation Service (EEMS) is enabled, further mitigations will be applied automatically.

According to the tech giant, Exchange Online customers do not need to take any action. However, Beaumont has queried the wisdom of this statement, given that Microsoft Exchange Online migration involves using hybrid, internet-facing Exchange servers.

“It is expected that similar threats and overall exploitation of these vulnerabilities will increase, as security researchers and cybercriminals adopt the published research into their toolkits and proof of concept code becomes available,” Microsoft commented.

CISA has added the two zero-days to the Known Exploited Vulnerabilities Catalog.

Microsoft told The Daily Swig that the company has nothing further to share beyond the published advisories.

YOU MIGHT ALSO LIKE #AttachMe Oracle cloud bug exposed volumes to data theft, hijack

Microsoft confirms zero-day exploits against Exchange Server in ‘limited’ attacks

Maintainer of Chinese project closes public issue apparently without issuing a fix

Charlie Osborne 03 October 2022 at 11:20 UTC

Maintainer of Chinese project closes public issue apparently without issuing a fix

An unpatched remote code execution (RCE) vulnerability in Nepxion Discovery, an open source project that provides functionality for the Spring Cloud framework, has been made public.

Security researchers from GitHub Security Lab (GHSL) disclosed the vulnerability, alongside an additional information disclosure flaw in Nepxion Discovery on September 9.

Nepxion, a China-based vendor, maintains several open source projects related to Spring Cloud.

Despite the Nepxion Discovery GitHub page having over 1,300 forks, the security policy page is disabled and the security advisories tab is empty.

**SpEL injection**

In a blog post, GHSL researcher Jorge Rosillo said the most severe vulnerability, tracked as GHSL-2022-033 (CVE-2022-23463), is a critical issue in the discovery-commons function that renders the software vulnerable to SpEL Injection.

SpEL Injection attacks occur when there is a lack of protection to stop user input from passing directly to a SpEL expression parser. In this case, two endpoints turn user input into expressions, pass them through, and input is then allowed to interact with Java classes – including java.lang.Runtime – leading to RCE.

Read more of the latest open source software security news

Due to the severity, this vulnerability was assigned a CVSS score of 9.8.

The second issue, tracked as GHSL-2022-033 (CVE-2022-23464) and issued a can GitHub score of 4.3 (NIST 7.5), is a server-side request forgery (SSRF) flaw that could result in information leaks.

According to the GHSL, no patch has been made available, and there are no known workarounds for either vulnerability. The issues impact Nepxion Discovery versions 6.16.2 and below.

The cybersecurity researchers privately disclosed their findings to Nepxion on May 22. In June, the team requested a security contact and, with no response forthcoming, a public issue was opened on June 20.

The maintainers closed the public issue on August 9.

By August 21, the standard vulnerability disclosure process deadline had expired, leading to the assignment of CVE-2022-23463 and CVE-2022-23464 and public disclosure.

When approached for comment, GitHub pointed us to the original disclosure.

Nepxion has yet to respond to queries submitted by The Daily Swig, but we will update this article if and when we hear back.

YOU MIGHT ALSO LIKE Rancher stored sensitive values in plaintext, exposed Kubernetes clusters to takeover

Nepxion Discovery software with Spring Cloud functionality fails to patch RCE, info leak bugs

New web targets for the discerning hacker

New web targets for the discerning hacker

This month’s big news was the Uber hack that saw the breach of the ride-sharing app firm’s internal networks, which appeared to have been carried out via a social engineering attack targeting an employee.

The attacker also gained access to an employee’s HackerOne account before commenting on multiple tickets, implying that they had accessed highly sensitive bug bounty reports that could reveal security vulnerabilities in Uber products and infrastructure.

A 17-year-old in the UK has been arrested in connection with the breach, the City of London Police confirmed.

This incident wasn’t Uber’s only embarrassment this month, as its former security head Joe Sullivan stood trial in the US.

Former Uber engineers testified about their concerns over Sullivan’s decision to treat a 2016 hack as a white hat bounty and pay the hackers $100,000 – thus avoiding scrutiny from the Federal Trade Commission.

In bug bounty news, Immunefi says it has paid out $60 million in bounties and helped to avoid $25 billion worth of losses from web3 hacks averted.

The company connects web3 projects that need their code checked and secured with whitehat hackers, offering rewards that can reach as much as $10 million.

Meanwhile, NFT marketplace OpenSea says it has paid out $200,000 to two ethical hackers for finding vulnerabilities, at least one of which was rated critical. The details of the flaws weren’t revealed, but the company says it has moved fast to fix them.

Finally, bounty hunter Sam Curry of Yuga Labs was baffled to receive a $250,000 bounty from Google this month. The only problem? He hadn't submitted any bug report.

According to a company spokesperson – and no doubt disappointingly for Curry – the payment was made in error, and Google planned to ask for it back.

And finally, a survey conducted by SANS Institute and cybersecurity firm Bishop Fox found that the typical ethical hacker can uncover a vulnerability that offers a route beyond the network perimeter in less than 10 hours.

Moreover, 58% can hack into an environment in under five hours once a security flaw has been identified.

**The latest bug bounty programs for October 2022**

The past month saw the arrival of several new bug bounty programs. Here’s a list of the latest entries:

**ALSCO**

**Program provider:  
**HackerOne

**Program type:  
**Public

**Max reward:  
**$1,500

**Outline:  
**Network security provider ALSCO is asking ethical hackers to look for vulnerabilities in its domain.

**Notes:  
**All rewards are based on the CVSS standard. However, ALSCO says that these are general guidelines and payouts are decided at its discretion.

Check out the ALSCO bug bounty page for more details

**Aptos Petra Wallet**

**Program provider:  
**Immunefi

**Program type:  
**Public

**Max reward:  
**$100,000

**Outline:  
**Aptos Petra Wallet is offering a bumper bounty of $100,000 for the most critical vulnerabilities in its websites and applications.

**Notes:  
**It’s worth checking out the list of top targets on the bug bounty page that could earn the hunter the top prize.

Check out the Aptos Petra Wallet’s bug bounty page for more details

**Bing Xchange**

**Program provider:  
**HackenProof

**Program type:  
**Public

**Max reward:  
**$4,000

**Outline:  
**Bing Xchange, a crypto social trading exchange that offers spot, derivatives, and copy trading services to more than 100 countries worldwide, is asking for vulnerability reports on two domains, two apps, and its web API.

**Notes:  
**There is an extensive list of out-of-scope targets, so these should be consulted before trying your hand at any targets.

Check out Bing Xchange’s bug bounty page for more details

**Caisse d'Epargne Normandie**

**Program provider:  
**YesWeHack

**Program type:  
**Public

**Max reward:  
**€2,000

**Outline:  
**The European bank has a number of web applications and APIs to target, and is offering up to €2,000 for the most critical bugs.

**Notes:  
**The bank has noted that any issue in Yousign or mangopay is not in scope, and therefore should not be targeted.

Check out the Caisse d'Epargne Normandie bug bounty page for more details

**LinkTree**

**Program provider:  
**HackerOne

**Program type:  
**Public

**Max reward:  
**$6,000

**Outline:  
**Social media link sharing tool LinkTree is opening multiple domains and two of its mobile apps to bug bounty hunters looking for security flaws.

**Notes:  
**There are 14 different domains to target and two mobile apps, offering plenty of chances to partake.

Check out the LinkTree bug bounty page for more details

**MongoDB**

**Program provider:  
**HackerOne

**Program type:  
**Public

**Max reward:  
**$5,000

**Outline:  
**MongoDB is asking for reports on security vulnerabilities in two of its domains and its GitHub repositories.

**Notes:  
**There are detailed instructions for bug bounty hunters on how to submit reports, so make sure to read these beforehand.

Check out the MongoDB bug bounty page for more details

**Poloniex**

**Program provider:  
**HackerOne

Program type: Public

**Max reward:  
**$5,000

**Outline:  
**Cryptocurrency exchange Poloniex is asking researchers to look for issues in five of its web domains.

**Notes:  
**The most critical bugs can potentially net bug bounty hunters £5,000.

Check out the Poloniex bug bounty page for more details

**Stader for NEAR**

**Program provider:  
**Immunefi

**Program type:  
**Public

**Max reward:  
**$1 million

**Outline:  
**Ethical hackers are being offered the chance to bag an eye-watering one million dollars for vulnerabilities in Stader, a “non-custodial smart contract-based staking platform that helps you conveniently discover and access staking solutions”.

**Notes:  
**Bug severities – and therefore payouts – are classified according to Immunefi’s own scoring system.

Check out the Stader for NEAR bug bounty page for more details

Curated by Jessica Haworth. Additional reporting by Emma Woollacott.

PREVIOUS EDITION Bug Bounty Radar // The latest bug bounty programs for September 2022

Bug Bounty Radar // The latest bug bounty programs for October 2022

Automating bulk pull request generation FTW

John Leyden 29 September 2022 at 13:46 UTC

Automating bulk pull request generation FTW

Researchers are trialing methods to scale up the ability to roll out security fixes for vulnerable components across the open source ecosphere.

Tools such as CodeQL (GitHub’s code query language) enable scans for vulnerabilities across hundreds of thousands of open source software projects.

These utilities can be used to systematically identify basic security flaws – common bugs with relatively simple fixes – in projects hosted on GitHub and similar platforms.

Catch up on the latest security research and analysis news

Such low-lying bugs are legion and straightforward to find and fix, so the real difficulty for those seeking to bolster security comes from the difficulties involved in triaging, reporting, and fixing.

Rather than automating the creation of bug reports, which might easily put an extra burden on the maintainers of an open source project, security researcher Jonathan Leitschuh is helping to define and test a methodology to partially automate pull requests at scale.

During a recent series of talks first delivered at BSides Las Vegas and then during DEF CON last month, Leitschuh outlined a methodology for automating bulk pull request generation. The talk was entitled ‘Scaling the Security Researcher to Eliminate OSS Vulnerabilities Once and For All’.

**The HUMAN factor**

Leitschuh, the inaugural Dan Kaminsky Fellow at HUMAN Security, has carried out a research project that involved creating tools and techniques to industrialize the development of security fixes for open source software.

If widely used, the approach would mean that if a component used by multiple projects is found to be vulnerable, then protect maintainers would be promptly offered a pull request that patches the problem.

Leitschuh and his colleagues started off using Python scripts to make a number of pull requests to open source projects found vulnerable to the so-called ‘Zip Slip’ vulnerability.

More recently they have refined this methodology to make use of OpenRewrite (a style-preserving refactoring tool created at Netflix and now developed by Moderne).

RECOMMENDED ‘Security teams often fight against developers taking control’ of AppSec: Tanya Janca on the drive to DevSecOps adoption

In total, Leitschuh has used the technique described in his talk to create 590 automated pull requests targeting Zip Slip (a vulnerability in the JVM ecosystem) and two other vulnerabilities (partial path traversal and temporary directory hijacking). These bring his career total of pull requests to 5,200.

Leitschuh told The Daily Swig that feedback from project maintainers about receiving automated pull requests had been mixed.

“The feedback I’ve gotten has been mixed. Lots of appreciative maintainers, and a few maintainers \[were\] upset,” the researcher explained.

“The Jenkins team has outright asked me not to issue \[pull requests\] against their organization.”

**‘Inspiring’ follow-up research**

The automated pull request approach omits unit tests that software developers like to see to verify that suggested amendments to their code base avoid breaking any functionality. In addition, the automated approach means that disclosures are made openly – an issue for eligibility under some, but not all, bug bounty programs.

Despite these potential drawbacks, feedback from security researchers about the automated pull request approach has largely been positive, according to Leitschuh.

The researcher concluded: “Responses from other security researchers \[have been\] generally quite positive. The value proposition is very easy to see when the idea is presented. I’ve inspired a few people to take on this research themselves for their own work, too.”

YOU MAY ALSO LIKE Vulnerability in Apache Pulsar allowed manipulator-in-the-middle attacks

Patching common vulnerabilities at scale: project promises bulk pull requests

Clients vulnerable due to improper certificate validation

Emma Woollacott 28 September 2022 at 15:30 UTC  
Updated: 28 September 2022 at 16:20 UTC

Clients vulnerable due to improper certificate validation

A newly-discovered vulnerability in Apache Pulsar allows a remote attacker to carry out a manipulator-in-the-middle (MitM) attack due to improper certificate validation.

Apache Pulsar is a distributed, open source solution for server-to-server messaging and queuing built on the publisher-subscribe pattern.

It’s used by thousands of companies for high-performance data pipelines, microservices, instant messaging, data integrations, and more, managing hundreds of billions of events per day.

But a delay in the TLS hostname verification process in the Pulsar Java Client and the Pulsar Proxy, discovered by Michael Marshall of cloud database-as-a-service firm DataStax, makes each client vulnerable to a MitM middle attack.

Read more of the latest news about web security vulnerabilities

The vulnerability isn’t specific to the Pulsar protocol, but exists thanks to a fundamental weakness in TLS hostname verification that means that the protocol fails to enforce hostname verification.

The Pulsar Java Client sends its client certificate as part of its client authentication step, while the Pulsar Proxy sends its server certificate as part of its authentication step.

However, authentication data is sent before verifying that the server’s TLS certificate matches the hostname, meaning that authentication data could be exposed to an attacker.

**Attack method**

To take advantage of this vulnerability, an attacker would need to take control of a machine between the client and the server. They would then have to actively manipulate traffic to perform the attack by providing the client with a cryptographically valid certificate for an unrelated host.

And because the client sends authentication data before performing the hostname verification, it would be possible for the attacker to gain access to the client’s authentication data.

When the client verifies the hostname and establishes that the targeted hostname does not match a hostname on the certificate, the client eventually closes the connection.

This means that the value of the intercepted authentication data will depend on the authentication method used by the client, with token-based and username/password methods left vulnerable because the authentication data can be used to impersonate the client in a separate session.

The vulnerability, rated medium severity, affects Apache Pulsar Java Client versions 2.7.0 to 2.7.4; 2.8.0 to 2.8.3; 2.9.0 to 2.9.2; 2.10.0; and 2.6.4 and earlier.

Users are advised to upgrade to unaffected versions – 2.7.5, 2.8.4, 2.9.3, 2.10.1, or higher – and to rotate vulnerable authentication data, including tokens and passwords.

DataStax says it has alerted its customers to the flaw. “The Pulsar security issues have already been fixed for the DataStax Luna Streaming offering and will be in an update to our Astra Streaming service soon,” says a spokesperson.

RECOMMENDED Web security flaw in Sophos Firewall patched

Vulnerability in Apache Pulsar allowed manipulator-in-the-middle attacks

Maintainers patch vulnerability and offer mitigation advice over bug that affects all Kubernetes objects

Ben Dickson 28 September 2022 at 14:08 UTC  
Updated: 28 September 2022 at 14:15 UTC

Maintainers patch vulnerability and offer mitigation advice over bug that affects all Kubernetes objects

A now-patched version of Rancher, an open source Kubernetes management tool, stored secrets in plaintext, a security researcher has discovered.

The issue affected various Kubernetes objects and could enable attackers to take over entire clusters.

Rancher, which was acquired by German software provider SUSE in 2020, is popular among the DevOps and Kubernetes communities.

Catch up with the latest cloud security news

The platform allows developers to deploy and run Kubernetes container clusters from different providers. It also adds value by centralizing authentication and role-based access control to clusters, which allows admins to control cluster access from one location.

Linux system engineer Marco Stuurman, who made the recent discovery, stumbled on it while investigating Rancher’s service tokens. “I'm not a security researcher, but I keep my eyes open for things like this,” Stuurman told The Daily Swig.

“I fetched information from one of our Rancher set-ups and became suspicious of the token. I've looked into similar tokens before, so it caught my attention.”

**‘Problem lies in low privileges’**

According to Stuurman’s findings, Rancher stored sensitive fields like passwords, API keys, and account tokens in unencrypted plaintext directly on Kubernetes objects.

“Storing secrets in plaintext is indeed bad practice but sometimes needed. In this case, you can't choose to hash the secret as this is the access key to the cluster,” Stuurman said. “The problem lies in the low privileges needed to access this key.”

According to the bug report, the plaintext data would be available to anyone with read access to the Kubernetes objects through the API.

“The attacker only needed the least possible privileges to a cluster Rancher manages. For example, our monitoring robot user’s only privilege was to proxy HTTP requests from rancher to the monitoring instance running in the target cluster,” Stuurman said.

**Protecting your cluster**

All Kubernetes objects are affected.

The service account token used to provision clusters is particularly critical since it has the highest privileges. In this case, the exploit could allow attackers to escalate their privileges and completely take over the cluster if there weren’t any other advanced prevention measures.

The issue has been addressed in the latest version of Rancher. The maintainers of the project have provided a script to rotate Rancher service account tokens. They also advised admins to limit access to Rancher instances, to check their downstream clusters for potential signs of a breach, and to change credentials that might have leaked.

“The best way to protect your cluster is to limit your cluster management tool access to people you trust,” Stuurman said. “However, that doesn't mean it shouldn't be as secure as possible.”

The Daily Swig has invited the maintainers of Rancher to comment but we are yet to hear back. If we do, we will update this article accordingly.

DON’T MISS CI/CD servers readily breached by abusing SCM webhooks, researchers find

Rancher stored secrets in plaintext, exposed Kubernetes clusters to takeover

Maintainers patch vulnerability and offer mitigation advice over bug that affects Rancher-owned objects

Ben Dickson 28 September 2022 at 14:08 UTC  
Updated: 30 September 2022 at 12:12 UTC

Maintainers patch vulnerability and offer mitigation advice over bug that affects Rancher-owned objects

UPDATED A now-patched version of Rancher, an open source Kubernetes management tool, stored sensitive values in plaintext, a pair of software developers have discovered.

Exploitation could have enabled attackers to gain privileged access to various Rancher-owned objects.

Rancher, which was acquired by German software provider SUSE in 2020, is popular among the DevOps and Kubernetes communities.

Catch up with the latest cloud security news

The platform allows developers to deploy and run Kubernetes container clusters from different providers. It also adds value by centralizing authentication and role-based access control to clusters, which allows admins to control cluster access from one location.

The bug was reported by Linux system engineer Marco Stuurman and and developer Florian Struck. Stuurman stumbled on the flaw while investigating Rancher’s service tokens. “I'm not a security researcher, but I keep my eyes open for things like this,” Stuurman told The Daily Swig.

“I fetched information from one of our Rancher set-ups and became suspicious of the token. I've looked into similar tokens before, so it caught my attention.”

**‘Problem lies in low privileges’**

According to Stuurman’s findings, Rancher stored sensitive fields like passwords, API keys, and account tokens in unencrypted plaintext directly on Kubernetes objects.

“Storing secrets in plaintext is indeed bad practice but sometimes needed. In this case, you can't choose to hash the secret as this is the access key to the cluster,” Stuurman said. “The problem lies in the low privileges needed to access this key.”

According to the bug report, the plaintext data would be available to anyone who has access to the Rancher-owned Kubernetes objects.

“The attacker only needed the least possible privileges to a cluster Rancher manages. For example, our monitoring robot user’s only privilege was to proxy HTTP requests from rancher to the monitoring instance running in the target cluster,” Stuurman said.

**Protecting your cluster**

Several Rancher-owned Kubernetes objects are affected by the bug.

The service account token used to provision clusters is particularly critical since it has the highest privileges. In this case, the exploit could allow attackers to escalate their privileges and completely take over the cluster if there weren’t any other advanced prevention measures.

In comments made to The Daily Swig, the Rancher security team said that not storing that data as secrets objects in Kubernetes came from some initial architectural and scaling decisions made when Rancher was still under early development. It was reviewed and addressed in the latest version of the platform.

“The remediation of the issue is a direct result of improvements that we started to implement, like creating a security team composed of a security engineer and developers to focus on security related issues and improvements,” the security team said.

RECOMMENDED #AttachMe Oracle cloud bug exposed volumes to data theft, hijack

“We also changed our release process to have security architectural reviews and tests before releasing new features, as well as enabling more security focused tools in our development pipeline.”

The issue has been addressed in the latest version of Rancher. The maintainers of the project have provided a script to rotate Rancher service account tokens. They also advised admins to limit access to Rancher instances, to check their downstream clusters for potential signs of a breach, and to change credentials that might have leaked.

“The best way to protect your cluster is to limit your cluster management tool access to people you trust,” Stuurman said. “However, that doesn't mean it shouldn't be as secure as possible.”

The Daily Swig has invited the maintainers of Rancher to comment but we are yet to hear back. If we do, we will update this article accordingly.

This article was updated on September 30 with comments and corrections from Rancher, in particular to reflect the fact that sensitive values, rather than secrets, were exposed, and that exploitation could lead to attackers gaining privileged access to Rancher-owned objects.

DON’T MISS CI/CD servers readily breached by abusing SCM webhooks, researchers find

Source

PortSwigger