Remediation compared to ‘changing the tires on a car while in motion’

Remediation compared to ‘changing the tires on a car while in motion’

  

A high-risk bug in the Gatsby Cloud Image CDN service allowed attackers to stage server-side request forgery (SSRF) and cross-site scripting (XSS) attacks against some cloud-hosted Gatsby websites.

Gatsby is a React-based JavaScript and open source framework for creating static websites, while Gatsby Cloud is an online platform for building and serving Gatsby websites. The Image CDN is Gatsby Cloud’s content delivery network service that enables websites to run faster by loading resources from edge servers.

**Great Gatsby find**

The bug was discovered and reported by Shubham Shah, security researcher and CTO of Assetnote, and Sam Curry, security engineer at Yuga Labs.

The researchers initially discovered a security bug in Next.js, another React-based site generator, and decided to investigate other, similar frameworks, which led them to the Gatsby vulnerability. The pair have also unearthed similar bugs in static site generators in recent months, including an SSRF and XSS bug in Netlify.

The CDN Image functionality for fetching resources was implemented in a way that did not validate the URLs provided by the client, they found.

Two routes were affected by the bug, one for images and the other for any file. Attackers could exploit this flaw to send arbitrary URLs to the server and have them rendered by the website. According to an advisory by Gatsby, the vulnerability could be exploited by SSRF or XSS attacks.

“The full read SSRF allows attackers to read the contents of arbitrary URLs including the metadata IP address if they are on a cloud environment,” Shah told The Daily Swig. “Any IP on the local network is accessible through the SSRF. On cloud environments, this bug could be escalated to steal secret keys or sensitive information from the metadata IP address.”

In a blog post, Shah detailed how the bug could be exploited.

**Caveats to exploitability**

Mike Gualtieri, security engineer at Gatsby, told The Daily Swig that the vulnerability only affected customers who were using the Gastby Cloud and had enabled the optional Image CDN service. The bug has been patched in the latest release, and when enabling the Image CDN, web admins are warned if their sites are vulnerable.

Gualtieri also said that the SSRF vector did not present much exploitable risk to customers.

“Typically an SSRF vulnerability would be used by an adversary to access internal resources that are not publicly exposed to the internet. In this case, the SSRF executed within the environment hosted by our Image CDN partner that stores images for a site,” Gualtieri said. “This environment is completely decoupled from the Gatsby Cloud, so there would be no risk of data exposure or deeper system access.”

Read more of the latest news about web security vulnerabilities

However, the XSS bug was more serious and could have been used for phishing or an authentication bypass.

“If a site included authentication functionality, and did not set secure cookie headers and/or a Content Security Policy, the XSS vector combined with phishing could have led to cookie or local-storage theft, which could have allowed an adversary the ability to authenticate to the site in the context of the stolen authentication token,” Gualtieri said.

**Changing tires on a moving car**

Patching the vulnerability was a tricky engineering effort that Gualtieri compared to “changing the tires on a car while in motion”.

The developers had to make sure that the fix would not break customer websites. Moreover, the team had to contact affected customers before public disclosure.

The patched version encrypts CDN URLs with a unique private key to ensure that only parameters included in a site build will be interpreted as valid routes.

Shah recommended that developers perform thorough code reviews, review logic, and confirm that sources and sinks have been audited for security issues.

“Audit exposed application routes that are accessible pre-authentication for any dangerous behaviors, even if the framework states it is a static site generator,” Shah warned. “Do not assume cloud platforms for static site generators have no dynamic or vulnerable routes.”

YOU MAY ALSO LIKE Malicious proof-of-concepts are exposing GitHub users to malware and more

Gatsby patches SSRF, XSS bugs in Cloud Image CDN

New research suggests thousands of PoCs could be dangerous

New research suggests thousands of PoCs could be dangerous

Malicious proof-of-concepts (PoCs) are potentially exposing GitHub users to malware and other malfeasance, researchers have found.

In a paper titled ‘How security professionals are being attacked: A study of malicious CVE proof of concept exploits in GitHub’, researchers from Leiden University in the Netherlands recently detailed how thousands of PoCs for known vulnerabilities contain dangerous elements that do more than billed.

Instead of performing an innocuous operation, these exploits could open the door to potential attack.

**Qualitative and quantitative**

The team – Soufian El Yadmani, Robin The, and Olga Gadyatskaya – collected publicly available PoCs shared on GitHub for CVEs discovered between 2017 and 2021.

In total they studied 47,313 repositories that contained PoCs for at least one CVE from the target period, in what they called “the first large-scale qualitative and quantitative investigation of malicious PoCs”.

They found that of the 47,313 GitHub repositories they had downloaded and checked, 4,893 (10.3%) were malicious.

Read more of the latest web security research

“The purpose of our research was to investigate how big the problem of fake and malicious PoCs for CVE exploits is, since it is our understanding that this is a problem that hasn’t been tackled by anyone before,” El Yadmani told The Daily Swig.

“As a researcher and senior security researcher at Darktrace myself, we rely on sources like GitHub and Exploit-DB for these kinds of PoCs since the knowledge shared by other researchers speaks the same language as we do, which is programming.

“About a year ago I noticed that the topic of malicious PoCs was increasingly spoken about on Twitter, but it was only about specific cases, and it was not clear how large the problem actually was.

“Since there was no clear indication of how many PoCs were malicious, we chose to investigate the issue ourselves.”

**Impressive variety**

El Yadmani told The Daily Swig that the most interesting finding was the variation in fake and malicious PoCs that the team encountered.

“In some the attackers were trying to plant malware on users’ machines, while in others, they tried to open backdoors using CobaltStrike, for example,” he said.

“What’s surprising is that in some cases we found fake and harmless PoCs that included memes; the most interesting finding was that some of these people invested a lot of time in their PoCs, while their only purpose was to educate the community about how they should not blindly trust PoCs from other people.”

**Impact radius**

The research paper (PDF) also goes on to lay out recommendations for detecting malicious PoCs by analysing source code for malicious calls to servers as well as extracting hexadecimal payloads and Base64-encoded scripts that contains malicious instructions, “which could be exfiltrating information, downloading malicious files from the internet or containing a backdoor”.

“Ignoring this problem can cause damage that ranges from infecting yourself as \[a\] user, to infecting your company and likely your customers as well if it’s a more sophisticated attack,” El Yadmani warned.

“Pen testers and developers should always read the code before running it, but in CVE PoCs it can be tricky and challenging in some cases.

“That’s why we wanted to introduce an approach that helps \[with\] detecting suspicious behaviors in PoCs, automatically. We also want to invest more time in suggesting automated solutions that can help flagging malicious PoCs.

“Our research is also an invitation to other researchers, either in academia or \[the\] industry, to invest more time in producing solutions for this problem.”

YOU MAY ALSO LIKE Hyped OpenSSL vulnerability downgraded to ‘high’ severity

Malicious proof-of-concepts are exposing GitHub users to malware and more

Public listings have made sensitive data searchable due to misconfigured third-party services

Charlie Osborne 02 November 2022 at 14:38 UTC  
Updated: 02 November 2022 at 17:11 UTC

Public listings have made sensitive data searchable due to misconfigured third-party services

Researchers have warned of enterprise software misconfigurations leading to the leak of sensitive records on urlscan.io.

Urlscan.io is a website scan and analysis engine. The system accepts URL submissions and generates a wealth of data, including domains, IPs, DOM information, and cookies, alongside screenshots.

The developers say the engine’s purpose is to allow “anyone to easily and confidently analyze unknown and potentially malicious websites”. Urlscan.io supports many enterprise customers and open source projects, and an API is provided to integrate these checks into third-party products.

**GitHub warning**

In a blog post published today (November 2), Positive Security said the urlscan API came to its attention due to an email sent by GitHub in February, warning customers that GitHub Pages URLs had been accidentally leaked via a third party during metadata analysis.

“With the type of integration of this API (for example via a security tool that scans every incoming email and performs a urlscan on all links), and the amount of data in the database, there is a wide variety of sensitive data that can be searched for and retrieved by an anonymous user,” the researchers say.

RECOMMENDED GitHub patches bug that could allow access to another user’s repo

Upon further investigation, Positive Security found that this could include urlscan.io dorks, password reset links, setup pages, Telegram bots, DocuSign signing requests, meeting invitations, package tracking links, and PayPal invoices.

Pingbacks to leaked email addresses appeared to show that misconfigured security tools that submitted links received via email as public scans to urlscan.io were the culprits.

For example, many API integrations utilized generic python-requests/2.X.Y user agents that ignored account visibility settings, thus allowing scans to be wrongfully submitted as public.

**SOAR misconfiguration**

Positive Security reached out to numerous leaked email addresses and there was only one response – from an organization that sent an employee a DocuSign link to their work contract and subsequently launched an investigation.

The employer found that a misconfiguration of their Security Orchestration, Automation, and Response (SOAR) playbook, which was integrated with urlscan.io, was at fault.

Positive Security examined historic urlscan.io information and uncovered misconfigured clients that could be abused by scraping the system for email addresses and sending them unique links to see if they would appear on urlscan.

For users of such misconfigured clients, password resets for many web services can be triggered, and the leaked link used to set a new password and take over the accounts.

Speaking to The Daily Swig, Fabian Bräunlein, co-founder of Positive Security said that this attack vector could be triggered “for personal services like banking or social media or company services such as for popular SaaS or custom applications.

“For many SaaS providers, access to an email address with a certain domain is already sufficient to gain access to internal company data (e.g. chats or code repositories),” Bräunlein added. “In such a case, an attacker does not even need to take over existing accounts but can just create new accounts at interesting services.”

**Urlscan overhaul**

Once the impact of the issue’s assessment was completed in July, Positive Security reported its findings to urlscan.io. As a result, the cybersecurity firm and urlscan.io developers worked together to address the problems uncovered, leading to the release of a new engine version later in the month.

The improved software includes an enhanced scan visibility interface and team-wide visibility settings.

Urlscan.io subsequently also published Scan Visibility Best Practices, which explain the security benefits and risks posed by three visibility settings users choose between when submitting a URL: ‘Public’, ‘Unlisted’, and ‘Private’.

Read more of the latest cybersecurity research news

Urlscan.io has also contacted customers who have submitted vast amounts of public scans and begun reviewing third-party SOAR tool integrations. Finally, the developers have added deletion rules, highlighted visibility settings in the user interface, and implemented a report button to deactivate problematic search results.

“Security teams that run a SOAR platform must make sure that no sensitive data is leaked to the public via integrations of third-party services,” Bräunlein commented.

Urlscan GmbH CEO Johannes Gilger told The Daily Swig: “We welcome the research performed by Positive Security and appreciate their professional conduct while working with us to identify the scope and source of these inadvertent information leaks.

“We have improved the visibility of the relevant settings on our platform, we have educated our users about the issue through a dedicated blog post and we continue to work with third party automation providers to ensure adherence to safe default behaviors.

“A platform like urlscan will always carry the risk of unintended information disclosure due to the nature of its operation, so we take every available measure to minimize the likelihood of these things happening.”

DON’T FORGET TO READ OpenSSL vulnerability downgraded to ‘high’ severity

Urlscan.io API unwittingly leaks sensitive URLs, data

Punycode-related flaw fails the logo test

Punycode-related flaw fails the logo test

  

A much-anticipated security update from OpenSSL landed today (November 1) but its impact appears to be considerably less than developers initially feared.

OpenSSL 3.0.7 tackles two vulnerabilities in the cryptographic library (tracked as CVE-2022-3786 and CVE-2022-3602, respectively) and both involve X.509 email address buffer overflows.

OpenSSL versions between 3.0.0 and 3.0.6 are affected by the flaws – both of which were anticipated as “critical”, but were eventually classified as “high” risk.

“The bugs were introduced as part of punycode decoding functionality (currently only used for processing email address name constraints in X.509 certificates),” an FAQ by the developers of OpenSSL explains.

Catch up on the latest encryption-related news and analysis

Last week developers of OpenSSL took the unusual steps of warning of the looming “critical” vulnerability, the first issue to reach this level of severity since the infamous Heartbleed vulnerability (CVE-2014-0160) eight years ago.

Heartbleed was a memory handling bug that created a means for attackers to steal secret keys, passwords, and sensitive personal information from vulnerable systems.

**No Heartbleed?**

The latest flaws initially appeared to present a remote code execution (RCE) risk comparable to Heartbleed, but subsequent testing work has shown that stack overflow protections on modern platforms mitigate against potential malfeasance.

And, for some Linux distros, the stack overflow only leads to a currently unused portion of memory – useless from an attacker’s perspective.

BACKGROUND Upcoming ‘critical’ OpenSSL update prompts feverish speculation

Other as-yet-unidentified platforms might turn out to be at risk of greater exposure, but for now the impact of systems that rely on the almost ubiquitous cryptographic library would appear to be limited to denial of service (i.e. crashed programs).

Both updates only affect OpenSSL 3.0.x, a release line that debuted in 2021 – another factor that limits the scope of the whole problem.

**No logo**

There’s no indication that either of the flaws have been abused but even so it makes sense to audit systems for potential exposure to vulnerable versions of OpenSSL 3.0.x and, of course, to update software stacks. Users operating TLS servers may consider disabling TLS client authentication, as a workaround short of patching.

It could also be time to stand down from any heightened alert state due to concern about the effect of another Heartbleed-style vulnerability.

This vulnerability hasn’t even been branded in any way – perhaps, to some, the ultimate diss. “The OpenSSL project has not named or created logos for either CVE,” the developers said.

RECOMMENDED SQLite patches 22-year-old code execution, denial of service vulnerability

OpenSSL vulnerability downgraded to ‘high’ severity

New web targets for the discerning hacker

New web targets for the discerning hacker

Last month two Italian security researchers revealed they had netted more than $46,000 in bug bounties after discovering a misconfiguration vulnerability in Akamai – despite receiving nothing from Akamai itself.

The exploit, which leveraged HTTP smuggling and hop-by-hop header abuse techniques, instead achieved payouts from several of the company’s customers. These included $25,200 from PayPal and rewards from Airbnb, Hyatt Hotels, Valve, Zomato, and Goldman Sachs.

In other payout news, researcher Saajan Bhujel bagged a $10,000 bounty from GitHub after finding a way to spoof the platform’s login interface. Bypassing HTML filtering in the MathJax display engine allowed him to inject form elements and change the website’s CSS, potentially fooling users into entering credentials into a fake login page.

Apple, meanwhile, has invited researchers to apply for the Apple Security Research Device Program, with applications open until the end of November.

Successful applications will receive a Security Research Device (SRD) – a specially-fused iPhone that allows iOS security research to be carried out without having to bypass its security features. Shell access is available, and researchers can run any tools, choose their own entitlements, and customize the kernel.

Apple has also revamped its ‘Apple Security Research’ website, with researchers now able to track bug reports via real-time status updates. The program has paid out nearly $20 million in bounties since launching 2.5 years ago.

Meanwhile, the Swiss National Cyber Security Centre (NCSC) has launched a private bug bounty program that involves probing the federal government’s web applications, APIs, and critical infrastructure.

Amazon’s new hardware-focused program, managed by HackerOne, is offering rewards ranging up to $25,00 for bugs in Fire, Echo, FireTV, Halo, Luna Controller, and Kindle devices, along with corresponding applications and firmware.

And finally, the US Department of Defense said it paid out a total of $75,000 in bounties for 648 bug reports submitted by 267 researchers during a hackathon that took place in July.

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

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

**Apple Security Research Device Program**

**Program provider:  
**Independent

**Program type:  
**Private

**Max reward:  
**$1 million

**Outline:  
**Apple will send selected security researchers a Security Research Device (SRD), a specially fused iPhone that allows shell access, kernel customization, and iOS security research without the need to bypass security features.

**Notes:  
**Applications can be submitted until November 30, 2022, with successful candidates receiving an SRD for 12-month renewable periods, and reports potentially eligible for rewards through the upgraded Apple Security Bounty.

Check out the Apple SRD bug bounty page for more details

**Amazon**

**Program provider:  
**HackerOne

**Program type:  
**Public

**Max reward:  
**$25,000

**Outline:  
**Fire, Echo, FireTV, Halo, Luna Controller, and Kindle devices, along with corresponding applications and firmware, make up the 36 assets in scope under the Amazon Vulnerability Research Program.

**Notes:  
**Rewards for bugs in services and apps range up to $20,000, while bounties for devices rise higher still to $25,000.

Check out the Amazon bug bounty page for more details

**Beanstalk**

**Program provider:  
**Immunefi

**Program type:  
**Public

**Max reward:  
**$1.1 million

**Outline:  
**The bug bounty program for Beanstalk – a permissionless fiat stablecoin protocol built on Ethereum – centers on smart contracts and preventing the loss of user funds.

**Notes:  
**Beanstalk describes itself as forming “the monetary basis of an Ethereum-native, rent-free economy facilitated by the positive carry of its native fiat currency, a stablecoin called Bean”.

Check out the Beanstalk bug bounty page for more details

**BigCommerce**

**Program provider:  
**Bugcrowd

**Program type:  
**Public

**Max reward:  
**$2,500

**Outline:  
**A NASDAQ-listed provider of Software-as-a-Service (SaaS) ecommerce services to retailers.

**Notes:  
**Valid targets include bigcommerce.net, bigcommerce.com, and related iOS and Android apps.

Check out the BigCommerce bug bounty page for more details

**Blend Labs**

**Program provider:  
**HackerOne

**Program type:  
**Public

**Max reward:  
**$5,000

**Outline:  
**Blend Labs is a provider of cloud-based software for financial services firms in the US.

**Notes:  
**Just one target is in scope – knox.beta.blendlabs.com – with blend.com not a viable target.

Check out the Blend Labs bug bounty page for more details

**Deribit**

**Program provider:  
**HackerOne

**Program type:  
**Public

**Max reward:  
**$6,000

**Outline:  
**The Amsterdam-based cryptocurrency option exchange is offering between $2,500 and $6,000 for critical vulnerabilities.

**Notes:  
**Testing is only allowed within Deribit’s test environment.

Check out the Deribit bug bounty page for more details

**Jungle Smart Contract**

**Program provider:  
**HackenProof

**Program type:  
**Private

**Max reward:  
**$1 million

**Outline:  
**A peer-to-peer NFT marketplace for digital goods, art, collectibles, and other virtual assets backed by the blockchain.

**Notes:  
**Some 14 protocols are in scope.

Check out the Jungle Smart Contract bug bounty page for more details

**Lido on Polkadot and Kusama**

**Program provider:  
**Immunefi

**Program type:  
**Public

**Max reward:  
**$2 million

**Outline:  
**Lido, a liquid staking solution for Ethereum, has launched bug bounty programs focused on DOT (Polkadot) and KSM (Kusama).

**Notes:  
**Smart contract bugs could command rewards of up to $2 million, while flaws in websites and applications max out at $40,000.

Check out the Lido on Polkadot and Kusama bug bounty pages for more details

**Private Internet Access (PIA)**

**Program provider:  
**Bugcrowd

**Program type:  
**Public

**Max reward:  
**$1,250

**Outline:  
**PIA, which already had a vulnerability disclosure program, is now incentivizing researchers to probe its technologies with rewards ranging up to $1,250.

**Notes:  
**Priority bugs are those enabling remote code execution, unlicensed access to VPN servers, or third-party monitoring or leaking of user data.

Check out the PIA bug bounty page for more details

**Rec Room**

**Program provider:  
**Bugcrowd

**Program type:  
**Public

**Max reward:  
**$2,500

**Outline:  
**A video game and video game creation platform available on Windows, Xbox, PlayStation, Oculus Quest, Apple devices, and Android.

**Notes:  
**Rec Room web application and API are in scope, but the free, cross-platform Rec Room game is the “primary target”.

Check out the Rec Room bug bounty page for more details

**Redox**

**Program provider:  
**Bugcrowd

**Program type:  
**Public

**Max reward:  
**$5,000

**Outline:  
**Redox technology facilitates the transferring of electronic healthcare records between organizations.

**Notes:  
**Critical bugs ordinarily fetch rewards of between $3,000-$4500, but submissions that “reflect an understanding of the platform and can describe the vulnerability and its impact and how to resolve it clearly and concisely” could net bounties of $5,000.

Check out the Redox bug bounty page for more details

**Stravito**

**Program provider:  
**Intigriti

**Program type:  
**Public

**Max reward:  
**Undisclosed

**Outline:  
**The market research platform claims McDonalds, Electrolux, Comcast, and Carlsberg among its customers.

**Notes:  
**Said Stravito founder and CEO Thor Olof Philogène: “Partnering with Intigriti, the leaders in this space, allows us to add an additional layer of stress testing to ensure we continue delivering the most robust and secure platform in our space.”

Check out the Stravito bug bounty page for more details

**Swiss National Cybersecurity Centre**

**Program provider:  
**Bug Bounty Switzerland

**Program type:  
**Private

**Max reward:  
**Undisclosed

**Outline:  
**The Swiss National Cybersecurity Centre (NCSC) is seeking submissions for bugs in the federal government’s web applications, APIs, and critical infrastructure.

**Notes:  
**As previously reported by The Daily Swig, the program follows a pilot project conducted in 2021 where ethical hackers probed IT systems of the Swiss parliament and Federal Department of Foreign Affairs for security vulnerabilities.

Check out the Swiss NCSC bug bounty page for more details

**Other bug bounty and VDP news this month**

*   **HackerOne** is expanding numbers of its ‘Hacker Success Managers’ to assist bug hunters, and has launched a new attack surface management platform, HackerOne Assets
*   **Bugcrowd** is now a CVE numbering authority, and has also launched a program management platform to help customers coordinate pen test, bug bounty, VDP, and ASM assets
*   European platform **Intigriti** has launched Hybrid Pentesting, which purports to combine the ‘pay-for-impact’ bug bounty model with the dedicated resourcing strategy of penetration testing
*   **YesWeHack** has launched MyOpenVDP, a turnkey vulnerability disclosure program-hosting solution
*   **Open Bug Bounty** has surpassed the milestone of notching one million web security vulnerabilities (PDF) reported and patched eight years after the platform’s launch

Curated by Adam Bannister. Additional reporting by Emma Woollacott.

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

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

Dormant 32 bit-era coding flaw causes problems for 64-bit systems

Dormant 32 bit-era coding flaw causes problems for 64-bit systems

The maintainers of the SQLite database engine have patched a high severity vulnerability that attackers could exploit to crash or control programs that rely on the software.

Developers of the software have offered The Daily Swig a convincing argument that the flaw would be difficult to exploit in practice. Even so, they have revised the software with a patch to defend against the flaw – rather than dismissing the issue as something that can be safely ignored.

SQLite is a popular open source C-language library that underpins many enterprise apps and services. Notable users of SQLite include Apple, Adobe, Google, Facebook, and Microsoft. There are billions of copies of SQLite deployed worldwide.

The SQLite team is quick to fix emerging vulnerabilities in the software due to their potentially wide-reaching impact. However, a vulnerability disclosed this month by Trail of Bits was introduced 22 years ago and highlighted how initially secure functionality could have unintended consequences much further down the line.

Catch up with the latest database-related security news and analysis

In a blog post dated October 25, Trail of Bits researcher Andreas Kellas said the vulnerability was introduced in SQLite version 1.0.12, a 2000 release that landed when the software was primarily based on 32-bit architectures. According to Kellas, the bug “may not have seemed like an error” at the time.

The high severity vulnerability is tracked as CVE-2022-35737, scoring a CVSS severity score of 7.5.

Trail of Bits said the bug impacts any app that relies on the SQLite library API.

The vulnerability is exploitable on 64-bit systems when large string inputs contain %Q, %q, or %w format substitution types that – in this scenario – might cause programs to crash or worse.

In the most severe cases – when the ! special character exists in the format string – it may be “possible to achieve arbitrary code execution, in the worst case, or to cause the program to hang and loop (nearly) indefinitely,” according to the researchers.

**Root cause analysis**

Speaking to The Daily Swig, the creator of SQLite, D. Richard Hipp, said the root cause of the problem was the use of signed 32-bit integers as a byte index into the input string and to compute the size of the output string. When an input string was large enough, the integer would overflow, and “all kinds of problems” ensued.

However, the potential impact of the flaw appears to be limited.

Hipp told us that it is not possible to reach the vulnerability for malicious purposes via SQL inputs or by passing SQLite a malformed database file. Instead, an attacker would have to abuse the use the sqlite3\_mprintf() function – or “similar C-level interfaces with a format string that includes one of the non-standard \[;...\] conversion symbols, and then pass in a string that is over 2GB in size”.

The software developer added:

“Lots of applications use SQLite, but only a small percentage of those use the sqlite3\_mprintf() API, and an even smaller percentage make use of %Q, %q, or %w. Of those that do, most do not provide a way for an attacker to arrange for a 2GB+ string to be passed into the argument to %Q, %q, or %w.”

**Unearthing Fossil**

In addition, while the project uses the Fossil control system and this software uses printf, the team couldn’t find a way to inject a 2GB string.

CVE-2022-35737 was reported to the Computer Emergency Response Team (CERT) Coordination Center by Trail of Bits on July 14. CERT confirmed the issue, reached out to SQLite maintainers, and the team fixed the bug in the software’s source code only three days later – a task accomplished by converting to the use of 64-bit integers.

The patched SQLite version, v3.39.2, was released on July 21.

“We are grateful for the responsible disclosure from the researchers who found it,” Hipp said. “It doesn’t hurt to upgrade to a newer release of SQLite. But very few if any real-world applications should be affected by this.”

The Daily Swig has reached out to Trail of Bits with additional queries and we will update this story as and when we hear back.

RELATED HyperSQL DataBase flaw leaves library vulnerable to RCE

SQLite patches 22-year-old code execution, denial of service vulnerability

Is the new Heartbleed or just a bleeding distraction?

Is the new Heartbleed or just a bleeding distraction?

Developers of the OpenSSL cryptography library have taken the unusual step of pre-warning that an update due to land next Tuesday (November 1) will fix a critical vulnerability.

The looming OpenSSL 3.x patch represent the only the second time the project has addressed a flaw classified as ‘critical’. The only previous OpenSSL update of such elevated severity addressed the infamous Heartbleed vulnerability (CVE-2014-0160).

Heartbleed was a memory handling bug that opened the door for attackers to access secret keys, passwords, and sensitive personal information from vulnerable servers. At the time of its discovery eight years ago, experts from Netcraft estimated that the flaw affected 17% of SSL web servers or “half a million widely trusted websites”.

Little is known about the upcoming critical fix (OpenSSL 3.0.7), other than it is restricted to OpenSSL version 3.0, the latest release line of the software, and does not affect previous versions.

YOU MAY ALSO LIKE HyperSQL DataBase flaw leaves library vulnerable to RCE

OpenSSL 3.0.x only debuted in 2021, a factor that might limit the extent of the problems next week’s announcement will reveal. OpenSSL has been around since 1998 and most systems today are still built using earlier release lines.

No details of the upcoming patch or the critical flaw it tackles have been released. In the absence of any hard info, infosec Twitter has gone into overdrive with some speculating that the vulnerability might represent the “next Heartbleed”.

One security expert from Google, for example, has suggested on the basis of recent software commits and a blog post by the OpenSSL team that the update might relate to a denial-of-service (DoS) issue.

**Feel the DHEat**

This particular DoS bug – known as DHEat and previous confirmed to affect OpenVPN and SSH services – involves enforcing the Diffie-Hellman key exchange.

DHEat (AKA CVE-2002-20001) scores 7.5 on the CVSS 3.1 index, indicating high severity and falling somewhat short of critical.

On the face of it, an OpenSSL patch for DHEat would appear to be a poor candidate for a critical patch unless OpenSSL is particularly vulnerable. A recent OpenSSL blog post referencing DHEat makes it even more unlikely that the looming patch tackles this issue.

It seems more likely that a previously unknown vulnerability is at play, according to experts quizzed by The Daily Swig.

**Action stations**

Brian Fox, CTO of Sonatype, told us that organizations should audit their code base for exposure to any vulnerability in OpenSSL 3.0.x, leaving them prepared to either patch or isolate vulnerable systems next week.

“In the first instance, it’s critical to find out where 3.x is used,” Fox said. “More importantly, it’s vital to get tooling in place to avoid having to audit and identify components manually every time.”

Catch up on the latest encryption-related news and analysis

Fox went on to argue that speculation about the content of the upcoming fix were, at best, “unhelpful”. He said: “The speculation assumes that the fix is available in the publicly visible source and the advance notice gives attackers time to find it. This assumption may not be true. It is a best practice at some times to embargo the actual change until after the announcement for this exact reason.

“The team at OpenSSL consists of some of the foremost experts in handling high profile open source vulnerability disclosures and if they have determined this is the best course of action – to give advance notice – then I have faith in that decision.”

Professor Alan Woodward, a computer scientist at the University of Surrey, reasoned that the problem is unlikely to be related to the older vulnerability.

“If the OpenSSL vulnerability is truly critical as per their own definition, then it sounds dire,” Prof. Woodward told The Daily Swig. “If it’s the older vulnerability, I fear they may have cried wolf. It isn’t helpful to give so little information but as it is a tiny team I can see why.”

Prof. Woodward concluded: “I guess we’ll all have to wait until next week.”

YOU MAY ALSO LIKE GitHub patches bug that could allow access to another user’s repo

Upcoming ‘critical’ OpenSSL update prompts feverish speculation

Bug fixed despite product reaching end of life

Bug fixed despite product reaching end of life

  

VMWare has patched a critical vulnerability in the management service for NSX, its network virtualization and security platform.

The vulnerability, caused by an old deserialization bug in an outdated Java library, could be abused to achieve pre-authentication remote code execution (RCE) on the host computer.

Due to the bug’s criticality, VMWare issued a patch despite the product having reached end-of-life status. The vulnerability is a reminder of the security challenges of managing open source software dependencies.

**Deserialization bugs**

Discovered and documented by security researcher Sina Kheirkhah, the main culprit in the VMWare NSX Manager flaw was XStream, a library for converting Java objects to XML format and vice versa (aka marshalling/unmarshalling).

XStream supports the marshalling and unmarshalling of a wide range of Java objects, even those that don’t support the Serializable interface.

This has made XStream an attractive launchpad for various code injection attacks. Security researcher Alvaro Muñoz documented RCE attacks with XStream in 2013, research that greatly helped Kheirkhah in discovering the VMWare vulnerability.

To go from unmarshalling to code execution on the host machine, the attacker would have to hook several Java features including dynamic proxies, event handlers, and method closure. This allowed the attacker to instantiate the class and invoke the method that runs commands on the system.

**Exploit on VMWare NSX Manager**

Versions of XStream up to 1.4.18 are vulnerable to this kind of deserialization attack. Kheirkhah discovered that VMWare NSX Manager used v1.4.18. The next step was to find an endpoint that could allow him to exploit the vulnerability.

“Java is very wild and there are so many scenarios that something can go wrong and end up in RCE on a popular appliance/software,” Kheirkhah told The Daily Swig. “I spent weeks studying how this certain VMWare product works which, eventually after spending so much time, it led to me to the discovery of the vulnerability.”

Kheirkhah first found an endpoint through which he could exploit the bug on NSX Manager. However, this endpoint required authenticated access.

With the help of security researcher Steven Seeley, Kheirkhah was able to access XStream through the password reset endpoint, which led to pre-authentication RCE on the NSX Manager host.

“This vulnerability allowed unauthenticated remote code execution as the root user on the target VMWare product,” Kheirkhah said.

Kheirkhah posted a proof of concept that shows how an attacker could gain shell access to the NSX Manager server.

**Lessons learned**

Even though the product had reached its end of life, VMWare patched it because it evaluated the severity of the bug to be in the Critical severity range with a maximum CVSSv3 base score of 9.8.

“While VMware does not mention end-of-life products on VMware Security Advisories, due to the critical severity of NSX-V the product team has made a patch available,” VMWare stated in an advisory.

“Deserialization vulnerabilities have been around for many years and will never go away,” Kheirkhah said.

“Even today you can notice how many new serialization libraries are getting introduced every day and how talented researchers are analyzing the security of these libraries and how it’s possible to abuse the deserialization process.”

Kheirkhah also underlined the importance of carefully handling the dependency chain of open source software. “Keeping track of dependencies and making sure they’re up to date is vital for securing your software,” he stressed.

The Daily Swig has reached out to VMWare for comments. We will update this post if we hear back from them.

YOU MAY ALSO LIKE Jira Align flaws enabled malicious users to gain super admin privileges – and potentially worse

VMWare patches RCE exploit in NSX Manager

Renaming accounts opened the door to hijacking

Jessica Haworth 27 October 2022 at 14:15 UTC

Renaming accounts opened the door to hijacking

  

A flaw in GitHub’s namespace retirement feature could have allowed attackers to potentially access another user’s repository.

Coined ‘repojacking’ by researchers from Checkmarx, the technique could have enabled malicious actors to bypass protections against the takeover of “retired” GitHub namespaces.

GitHub repositories have a unique URL which is nested under the user account that created it. The linked URL and username together are called a ‘namespace’.

When a user chooses to rename their GitHub account, the platform will redirect their old URLs to the new URL.

However, this feature was found to be vulnerable to “a logical flaw that breaks the original redirect”.

Read more of the latest news about web security vulnerabilities

If a malicious actor created an account using the previous account name of another user, they were able to link the old repository URL to their account, gaining access to code and other content in the process.

In addition, and compounding the problem, the default redirect was disabled, so if an attack was successful then all existing traffic was immediately routed to the attackers malicious GitHub repository.

To protect against this, GitHub initially introduced the “popular repository namespace retirement” feature, meaning that any repository with more than 100 clones at the time its user account is renamed is considered “retired” and the namespace cannot be used by others.

**Timeline**

In a blog post, Checkmarx researchers explained that they found two bypasses that allowed them to exploit the feature, noting that a successful attack would enable the takeover of popular code packages in several popular package managers including Packagist, Go, Swift, and more.

The team discovered an initial bypass in November 2021 and reported this to GitHub, which “fixed” it In March 2022.

In May 2022, it was still deemed to be exploitable and was again patched later that month.

Then in June, Checkmarx researchers found a second bypass, which was patched in September and disclosed this week (October 26).

The researchers were awarded an undisclosed bug bounty reward for the discovery. Checkmarx warns that thousands of repos could be at risk if any further bypasses were found.

“We have identified over 10,000 packages in those package managers using renamed usernames and are at risk of being vulnerable to this technique in case a new bypass is found,” the researchers said in a blog post.

RECOMMENDED Login spoofing issue in GitHub nets researcher $10k bug bounty reward

GitHub patches bug that could allow access to another user’s repo

Lateral or upwards movement beyond the instance was theoretically possible, concludes researcher

Lateral or upwards movement beyond the instance was theoretically possible, concludes researcher

A pair of vulnerabilities patched in Jira Align could in the “worst-case scenario” be combined by low-privileged malicious users to target Atlassian’s cloud infrastructure, a security researcher warns.

Jira Align is a software-as-a-service (SaaS) platform through which enterprises can scale their deployments of Atlassian Jira, the hugely popular bug tracking and project management application, in the cloud.

A Bishop Fox security researcher found a high severity (CVSS 8.8) authorization controls flaw that allows users with the ‘people’ permission to elevate their privilege, or that of any other user, to ‘super admin’ via the MasterUserEdit API (CVE-2022-36803).

Subsequently, abuse of a medium severity (CVSS 4.9) server-side request forgery (SSRF) bug (CVE-2022-36802) could then see attackers retrieve AWS credentials of the Atlassian service account that deployed the Jira Align instance.

**MisAligned permissions**

Super admins can among other things modify Jira connections, reset user accounts, and modify security settings, said Jake Shafer, senior security consultant at Bishop Fox.

Attackers could also access “everything the client of the SaaS had in their Jira deployment (or just take the whole thing offline, but I would hope there’s some backups in that case)”, he told The Daily Swig.

“Going by my pen testing experience, that could be everything from credentials and client information to details on unpatched vulnerabilities in their own applications and software.

Catch up with the latest cloud security news

“While, for good reason, my testing stopped at the edge of the Atlassian infrastructure, under the right conditions \[leveraging the SSRF\] potentially means gaining access to other client data through lateral or upward movement through Atlassian’s AWS infrastructure.

“Since Atlassian’s providing cloud tenants to these clients, gaining access to the infrastructure of the SaaS provider itself is pretty much worst-case scenario.”

The flaws affect version 10.107.4 and were patched in 10.109.3, which was released on July 22, 2022.

**People permissions**

The role of ‘people’ permissions varies depending on an instance’s configuration. “In the sandbox environment that was provisioned for testing purposes, this permission was added to the ‘program manager’ role, but could be exploited by any role with the ‘people’ permission,” explained Shafer in a Bishop Fox security advisory.

This could either be done by “intercepting the role change request directly to the API and modifying the parameter to ”, or by performing an API call with a request containing their session cookies.

The SSRF resides in the Jira Align API, which manages external connections.

A user-supplied URL value called points to the relevant API location. Jira Align automatically appended /rest/api/2/ to the URL server side, but the further addition of ‘#’ “would allow an attacker to specify any URL”, warned Shafer.

The issues were unearthed on May 31, 2022, and reported to Atlassian on June 6, with the vendor initially addressing the SSRF with a hotfix version 10.108.3.5 on June 28.

The Daily Swig has invited Atlassian to comment. We will update the article if they do so.

RECOMMENDED Policy-as-code approach counters ‘cloud native’ security risks

Source

PortSwigger