Teach devs security fundamentals to bolster supply chain resilience, argues Wheeler Addressing a decades-old deficiency in coding curriculums could have a profound effect on the security of the softwa

Adam Bannister 14 October 2022 at 14:15 UTC  
Updated: 14 October 2022 at 15:00 UTC

Teach devs security fundamentals to bolster supply chain resilience, argues Wheeler

Addressing a decades-old deficiency in coding curriculums could have a profound effect on the security of the software supply chain, a leading expert on the subject tells The Daily Swig.

In particular, David A Wheeler, director of open source supply chain security at the Linux Foundation, draws a link between a failure to incorporate security into entry-level developer courses and the vast majority of vulnerabilities belonging to a small number of common bug classes.

The IT PhD and Certified Information Systems Security Professional (CISSP) also moonlights as adjunct professor of computer science at Virginia’s George Mason University, and in 2020 concluded a 33-year spell at the US Institute for Defense Analyses.

Daily Swig: David, can you summarize your background and what your current roles involve?

David A Wheeler: I’ve loved computers since junior high school and paid my way through school doing computer consulting. I also briefly maintained the world’s first commercial, entirely text-based multiplayer roleplaying game, Scepter of Goth.

Now I teach at George Mason University on how to develop secure software – which I’ve studied over many decades.

Most of my work is with the Open Source Security Foundation, OpenSSF \[whose members include AWS, Google, and Microsoft\]. I view my role as being a kind of catalyst or accelerant. I can run around as a subject matter expert to help organizations improve the security of their software.

David A Wheeler has studied the secure development of software for decades

DS: And what are the biggest barriers to improving application security?

DAW: The fundamental problem is that we do not teach software developers how to write secure software.

I don't care if it’s a separate course or embedded \[in other coding courses\] – that's not the question. The question is: when software developers are learning the basics of their craft, do they learn the basics of developing secure software? And the answer is mostly “no”.

A 2019 Forrester study found that none of the top US coding schools and none of the top five non-US computer science schools were teaching this. Another study found that only one school did – at UC, San Diego. So good for them, shame on the rest.

DS: Let’s imagine all coding schools immediately revamped their courses to incorporate security fundamentals. Would we see a steady fall in vulnerabilities as a new wave of security-savvy developers emerge?

DAW: It’s generally estimated that somewhere between 90% to 95% of all vulnerabilities are in a relatively small set of common ones \[classes\].

So, if you educate developers to prevent them systemically, and then use tools to find the stragglers, we can dramatically reduce by at least one order of magnitude – and maybe two – the number of vulnerabilities that actually slip out.

They can also find and fix the problems created in the past.

Right now, detection, response, and recovery is overwhelmed by the sheer number of vulnerabilities going into deployed systems, so it will be much easier to counter the attackers when vulnerabilities are much rarer. And that's really the argument of ‘shift left’ in general: the sooner you can get rid of the problems, the better.

DS: Why is security neglected in the coding curriculum given the potentially severe consequences of software vulnerabilities?

DAW: Our educational system does not always respond to societal needs. There was an open letter written by Oracle and some other folks 10, 15 years ago or so, where they basically begged universities \[to educate them properly\].

But sometimes they \[universities\] want to teach what they want to teach, and it doesn’t matter what society’s needs are.

DS: Could this partially reflect the fact that many educators learned their craft when cyber threats were less numerous and severe?

DAW: On the \[early\] internet people were mostly connected to folks they felt they could trust. But once you saw this growth of the internet and the worldwide web running on top of it in the 90s, then very quickly \[they realized\] no, you can’t just trust arbitrary computers you connect to.

But educational conservatism isn’t all bad. It’s actually sensible to teach things that have stood the test of time, which security has. The fundamental \[computing\] design principles have been known \[about\] since the 1970s.

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

DS: Might there be a commercial incentive at work that favours coding quickly over coding securely?

DAW: Maybe to some extent for the for-profits, but I think the bigger for-profit issue is that if you know how to do \[secure development\], you can probably earn double or triple in industry \[compared to teaching\]. You’re not gonna teach.

I teach, but that’s my side hustle. I enjoy teaching. George Mason University is 20 minutes from me and more connected to industry than some other universities.

DS: How do we persuade or incentivize education providers to embed security into coding courses?

DAW: I think this is a solvable problem – basically, society needs to scream more loudly.

The US spends a tremendous amount of money financing degrees, including computer science. If we’re gonna pay, maybe we could have some criteria?

DS: Could the impetus behind ‘shifting left’ or DevSecOps help persuade education providers to change emphasis?

DAW: I would like to think so, but I think it’s much more societal and industry pressure continuing over a period of time \[that will make the difference\].

Right now DevSecOps \[is practised properly by\] a minority, and we need to make sure that \[secure development is practised\] not just the majority, but is \[a baseline\] expectation \[of all developers\].

Developers are not being taught general security principles – let alone how to apply them, says Wheeler

Years ago, I pushed really hard to get security added to a course on software engineering and after a lot of pressure and debate \[the provider\] finally added the word ‘security’ – no content, just that security might be important!

The ACM software engineering curriculum guidance at least does talk about knowing how to develop secure software, but lacks key specifics.

But I'm willing to believe that with continued emphasis we can get academia and many other organizations on board with making sure that software developers know the fundamentals.

DS: What fundamentals should newbie developers be taught?

DAW: What are the common problems? How do we prevent them in general? How do you design software so it’s less likely to be attacked? And what kind of tools can help developers to deal with that?

These general principles and the ability to apply them are important \[skills\] but lacking today.

Read more secure software development news

The first thing I did when I joined the Linux Foundation in 2020 as an employee was develop a course on developing secure software fundamentals. Thousands of people have now signed up.

George Mason University initially agreed to do my course every other semester, and very quickly, it's in every semester – it’s in demand.

But it’s an optional graduate course. We do need, in society, people who drill in deeper and \[become experts\], but we also need every developer to know the basics.

DS: How important is it that developers understand how to use security tools?

DAW: If you’re doing DevOps, you pretty much need a CI pipeline, and this is an obvious place to insert security tools. But if the developer doesn't know what they’re doing, they won’t know what the tool is telling them and what to do about it.

A fool with a tool is still a fool. They’re not stupid – it's just that no one has told them. Education and tooling go hand in hand.

The tools are going to miss things or report things that are not actually problems in context. Computer programs don’t – can’t – know the full context.

But as long as developers know which tools to use and how, then they can do \[some\] amazing things.

DS: Finally, anything to say on OpenSSF’s various initiatives aimed at bolstering software supply chain security?

DAW: Whether it’s industry, academia or governments, we’re all using open source software, so my first pitch would be: get involved with the OpenSSF. We would love to see more people involved.

I was deeply involved in the concise guides for developing secure software and evaluating open source software. And earlier, the OpenSSF published guides for open source projects and security researchers on \[handling\] coordinated \[vulnerability\] disclosure.

The Alpha-Omega Project has funded the Python Software Foundation and is funding Eclipse, Node... They’re announced a new partnership with Rust. They've released some tools for finding vulnerabilities – again, trying to shift left.

There’s also some funding for SBOM work, a tool for a Python library for SPDX \[Software Package Data Exchange\], and an \[enterprise\] end users working group kicking off.

RELATED Developers still struggling with security issues during code reviews, study finds

‘We don’t teach developers how to write secure software’ – Linux Foundation’s David A Wheeler on reversing the CVE surge

E-commerce platform admins should update ASAP

Adam Bannister 14 October 2022 at 11:11 UTC

E-commerce platform admins should update ASAP

A super-critical vulnerability in Adobe Magento could allow attackers to fully compromise e-commerce platforms, according to the security researcher who unearthed the bug.

Adobe has urged users to update their systems to protect their websites from abuse of the flaw, which has been assigned the maximum possible severity (CVSS) score of 10.

Tracked as CVE-2022-35698, the stored cross-site scripting (XSS) bug can lead to arbitrary code execution, according to an Adobe security advisory published on October 11.

Read more e-commerce security news

The flaw affects versions 2.4.4-p1 and earlier, as well as 2.4.5 and earlier, of Adobe Commerce and Magento Open Source. The issue has been patched in versions 2.4.5-p1 and 2.4.4-p2.

It’s estimated that around 267,000 active e-commerce websites are built with Magento.

The software update also addresses a medium severity, improper access control vulnerability that might be abused to bypass of a security feature (CVE-2022-35689).

**‘Easy to exploit’**

The researcher credited with finding the critical flaw, ‘Blaklis’, told The Daily Swig: “The flaw basically allows \[an attacker\] to XSS the admin area in a very specific way, that makes it very easy for the victim to trigger it with normal, regular browsing. That leads to obviously nasty things, including full shop compromise. So... that explains the score I guess.”

They added: “As far as I know, there’s no specific prerequisite to exploit it, and no real mitigations except patching.

“The flaw is pretty easy to exploit and does not require authentication at all. I found the bug by looking at their code, as I \[have\] do\[ne\] for a couple of years now – I pretty much know their code by heart now.”

Blaklis’ previous notable Magento finds have included a privilege escalation vulnerability in the Azure IoT CLI extension in February and, as reported by The Daily Swig, a pair of critical bugs in 2020.

YOU MAY ALSO LIKE Hidden DNS resolver insecurity creates widespread website hijack risk

Adobe patches critical Magento XSS that puts sites at takeover risk

Data importation mechanism failed to sanitize imports

Ben Dickson 13 October 2022 at 14:27 UTC

Data importation mechanism failed to sanitize imports

A vulnerability in GitLab allowed attackers to stage various attacks against GitLab servers, including the cloud-hosted GitLab.com platform.

The bug, reported by security researcher ‘yvvdwf’, was caused by the way GitLab imports data from GitHub, which could be exploited to run commands on the host server.

**Unsafe imports**

GitLab uses Octokit, a library that provides an interface to import data from the GitHub API. To retrieve and present its results, Octokit uses the HTTP client library Sawyer.

However, GitLab directly used the Sawyer results returned by Octokit without sanitizing them, which provided opportunities to insert malicious commands.

Yvvdwf found that one of the parameters used in the import function was prone to command injections against GitLab’s Redis database.

**RCE, information theft, and more**

On standalone GitLab installations, an attacker could exploit the command injection bug to escalate from Redis to Bash and send commands to the operating system. Any potential attacker would have remote code execution (RCE) access to the host with the privileges of the host process.

While the RCE exploit did not work on GitLab.com, yvvdwf was able to use other Redis commands to replicate data from GitLab.com to a standalone server with a public IP. They were also able to poison GitLab projects through the same mechanism and make them inaccessible.

An attacker with a standalone GitLab installation and an API access token could use the exploit to steal information, inject malicious code, and perform other malicious actions against GitLab.com.

**Protecting GitLab servers**

The vulnerability was assigned CVE-2022-2884 with a critical base score of 9.9 in the Common Vulnerability Scoring System.

GitLab has already patched the issue in GitLab.com and published a critical security release for GitLab Community Edition and Enterprise Edition.

All users are advised to upgrade their GitLab installation. For organizations that can’t upgrade right away, GitLab advises them to secure their installation by disabling imports until they can patch their system.

While GitLab users will be safe by using the cloud or updated self-hosted version of the platform, other services that use Octakit to interact with GitHub should be wary and make sure that they perform the right checks around the data they pass on and receive through the library.

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

GitLab patches RCE bug in GitHub import function

WordPress installations exposed to spoofed password reset vis cache poisoning threat

WordPress installations exposed to spoofed password reset vis cache poisoning threat

Hidden DNS (domain name system) resolvers create a means for carrying out email redirection and account takeover attacks, security researchers warn.

In a technical blog post, SEC Consult explains how it’s possible to manipulate the DNS name resolution of these so-called closed DNS resolvers using a variant of cache poisoning attacks (PDF), which were first unveiled by celebrated network security researcher Dan Kaminsky way back in 2008.

**Cache from chaos**

Previous research by SEC Consult has shown how it’s possible for an attacker to take over user accounts of web applications by manipulating DNS name resolution.

Closed DNS resolvers are used by numerous hosting providers and other internet service providers (ISPs) to provision services to their clients. As the name suggests, closed DNS resolvers reside on closed networks or intranets.

However, ‘closed’ is a bit of a misnomer in the context of SEC Consult’s research because the researchers have shown how it might be possible for external actors to abuse the functionalities of web applications to readily attack closed resolvers.

They found that attack reconnaissance is possible by exploiting how closed DNS resolvers interact with spam protection mechanisms on the open internet.

This could help an attacker understand DNS security features like source port randomization, DNSSEC, IP fragmentation, and, more simply by exploiting registration, password-reset, as well as newsletter functionalities of web applications that rely on closed resolvers.

**Scouring the web**

SEC Consult used two open source tools – DNS Reset Checker and the DNS Analysis Server – to analyze DNS traffic from targeted systems in order to identify vulnerabilities.

In practical terms, this attack reconnaissance work involved sending emails to some well-known domains and specifying the analysis domain as the sending domain. This allowed the researchers to identify thousands of systems that used static source ports, a security oversight that left them vulnerable to Kaminsky-style attacks.

“After sending emails to roughly 50k domains, we’ve received and analyzed DNS data for approximately 7,000 of them,” SEC Consult explains. “Among those 7,000 domains, at least 25 were using static source ports. By going down the rabbit hole again, thousands of more domains using static source ports were discovered.”

None of a sample of 25 vulnerable resolvers were using or enforcing additional security features such as DNSSEC, SEC Consult discovered.

Affected services were running behind domains operated by both small and big businesses, and sites delivering governmental services and political campaigns.

Catch up with the latest DNS Security-related news and analysis

DNS cache poisoning insecurities can be abused to manipulate records and redirect emails – a security shortcoming that would allow an attacker to abuse the password reset functionalities of WordPress and Joomla installations, among others.

The attack technique can be used to hijack even a fully patched WordPress installation, SEC Consult was able to demonstrate.

The infosec firm has held back on publicly releasing the exploit code it developed to attack WordPress systems, because of concerns that awareness of the issue is low, which would leave many web-based systems accessible through closed DNS resolvers open to attack.

SEC consult spoke to ISPs, hosting providers, and computer emergency response teams (CERTs) about the issue in the months prior to going public with its findings last week.

**Cache out**

Independent DNS security experts said that the research highlighted a valid concern.

Cricket Liu, chief DNS architect at Infoblox, told The Daily Swig: “I don’t think this is particularly novel – we talked about this sort of thing back in the heyday of the Kaminsky vulnerability – but it’s relevant because there are still some DNS servers out there that don’t use source port randomization.”

**Containing exotic attacks**

Even though legacy Kaminsky attacks are definitely not the ‘next big thing’ it would be unwise to dismiss the issue as unfashionable, according to SEC Consult.

Timo Longin, a security consultant at SEC Consult, told The Daily Swig: “The DNS provides very exotic and unknown attack vectors that should be brought to the attention of the infosec community! For example, we found some hosting providers where it would potentially be possible to compromise all hosted servers by password-reset hijacking users via the providers’ control panel”.

To safeguard systems, vulnerable DNS resolvers must be patched and configured securely. Some best practices for securing your own DNS resolvers can be found at Google and at DNS flag day. Alternatively, large public DNS providers such as Google, Cloudflare, or Cisco can also be used.

Countermeasures for new DNS attacks are usually implemented quickly by these large providers, according to SEC Consult.

YOU MAY ALSO LIKE Policy-as-code approach counters ‘cloud native’ security risks

Hidden DNS resolver insecurity creates widespread website hijack risk

Mitigation guidance provided while a patch is being developed

Mitigation guidance provided while a patch is being developed

  

A zero-day remote code execution (RCE) vulnerability in Zimbra is being actively exploited in the wild.

The bug was assigned the tracker CVE-2022-41352 in late September. Issued a CVSS severity score of 9.8, the critical issue can be exploited to plant a shell in the software’s root directly, achieving RCE and enabling attackers to wreak havoc on a vulnerable system.

Zimbra, once known as the Zimbra Collaboration Suite (ZCS), is an open source email suite. The software is relied upon by millions of users and is designed for managing enterprise and SMB email and collaboration tools.

Read more of the latest news about web security vulnerabilities

According to Rapid7’s AttackerKB project, CVE-2022-41352 is an RCE that “arises from unsafe usage of the cpio utility, specifically from Zimbra’s antivirus engine’s (Amavis) use of the vulnerable cpio utility to scan inbound emails”.

To launch a successful attack, a threat actor would need to email a , , or file to a vulnerable server. Amavis would then scan the message for malware and use the cpio file utility to extract its content.

However a ‘loophole’ exists where attackers could leverage to write to a target folder, or as Rapid7 says, “write to any path on the filesystem that the Zimbra user can access”.

Once inside, for example, an attacker may be able to extract emails, tamper with user accounts, wipe information, or conduct Business Email Compromise (BEC) scams.

Oracle Linux 8, Red Hat Enterprise Linux 8, Rocky Linux 8, and CentOS 8 builds are vulnerable.

**‘Effectively identical’**

Rapid7 researchers noted that CVE-2022-41352 is “effectively identical” to CVE-2022-30333, a path traversal bug in RarLab’s unrar binary which also triggers an RCE in Zimbra. The only difference appears to be the file type (, instead of ).

According to Rapid7 researcher Ron Bowes, the vulnerability is an exploit path for CVE-2015-1194, a bug that was patched in 2019. However, it appears that some distributions unintentionally remove the fix.

A Zimbra forum post indicates that the vulnerability is being actively exploited in the wild. Proof of concept (PoC) exploit code has been released.

Zimbra has acknowledged the vulnerability and says that a fix is being developed. In the meantime, Zimbra is urging users to install the pax package immediately and restart Zimbra as a workaround.

Pax is used for reading or writing archived file content and is not vulnerable to this exploit – but, unfortunately, Pax is not included by default. If Pax has not been installed, Amavis will resort to using cpio, and Zimbra says the “poor implementation” of this process that created the vulnerability in the first place.

Zimbra intends to remove the cpio dependency and make Pax a requirement.

There’s better news for Ubuntu users – Pax is installed by default in Ubuntu 20.04, and in Ubuntu 18.04, a custom patch issued for cpio provides protection.

The Daily Swig has reached out to Zimbra with additional queries and will update this story if and when we hear back.

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

Zimbra remote code execution vulnerability actively exploited in the wild

Research suggests that automation can cut down on cloud control plane compromises

Stephen Pritchard 07 October 2022 at 15:24 UTC  
Updated: 07 October 2022 at 15:26 UTC

Research suggests that automation can cut down on cloud control plane compromises

So-called ‘cloud native’ IT architectures are creating new threats for organizations, just as they look to update their technology infrastructure, security researchers have warned.

Over half of developers and security professionals expect the risks to their organizations to increase over the next year, according to research from developer security tools vendor Snyk. The drivers include cloud-native threats and, especially, control plane compromises.

Other potential problems include misconfigured cloud resources, as well as compromised credentials.

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

Speaking at the recent International Cyber Expo in London, Ashish Rajan, principal cloud security advocate at Snyk, explained that security breaches are no longer only about data. Increasingly, criminal groups are also looking to steal or expose credentials, including cloud infrastructure credentials.

Rajan cited the recent breach at ride-hailing company Uber, which used social engineering as part of an attack that ultimately succeeded in gaining access to the company’s credentials for Amazon Web Services and Google Workspace.

“It’s not just a breach, a release of records, they also shared the AWS and Google Cloud credentials on the internet as well,” he said. “We are actually talking about data breaches creeping into our cloud environment or even broader production environments as well.”

**Credentials targeted**

Attackers are searching for credentials for cloud services by searching for ‘open S3 buckets’, blob storage or other open storage sites, as well as GitHub repositories, SSH \[Secure Shell\] and SSL vulnerabilities, and even posts by developers on sites such as Stack Overflow. “People are finding easier targets,” Rajan said.

This is forcing developers to pay more attention to both application security and cloud security, the speaker argued. Although organizations and their developers increasingly understand the need for application security, cloud security is too often treated separately rather than as part of the same problem, he asserted.

“In my previous company, we had a product security team and we had cloud people. But they weren’t on the same team. It didn't make sense. We were still protecting this one application,” said Rajan.

Developers often rely too heavily on the cloud provider’s security measures, says Snyk’s Ashish Rajan

**Cloudy with a chance of breaches**

And the situation is made more difficult still by the ‘shared responsibility’ model of cloud security. Too often, contended Rajan, developers and their managers rely on the cloud provider’s security measures, rather than ensuring that their infrastructure and code is secure.

According to Snyk’s 2022 State of Cloud Security Report, 80% of organizations experienced a “serious cloud sec incident” during the past year. Of those, 33% suffered a cloud data breach, and 26% a cloud data leak. A further 27% detected an intrusion into their environment.

Catch up on the latest DevSecOps-related news and analysis

The research also found that companies that use the cloud to host applications that had migrated from a data center were the most likely to report serious cloud security incidents: 89% did so during the past year.

That was higher than the total for organizations using the cloud to build and run in-house applications (73%) or those hosting third-party applications (78%).

**Infrastructure as code**

To counter this, Rajan suggests that developers should follow five fundamentals of cloud security. These are knowing the operating environment, focusing on prevention and secure design, empowering developers, using policy as code to align with security requirements and automate compliance, and ensuring security teams are “measuring what matters”.

To adhere to these fundamentals, organizations should be looking to ’shift left’ and build in security checks earlier in a project’s timeline. Firms should map out a cloud secure development lifecycle, using infrastructure as code (IaC) tools and CI/CD pipelines. And organizations can take this a step further by defining security policies within IaC.

This, Rajan said, removes, or at least reduces, one of the most common causes of cloud security failures: human error.

“What's the policy look like? Can I define the policy as IaC? That's where a lot of people have found that you can reduce credentials being leaked or over-privilege, or misconfiguration of resources, as well as having identity not in control,” he said. Policy as code allows organizations to apply their security rules, whether they use a single cloud platform, or two or even three, added Rajan.

RELATED Rancher stored sensitive values in plaintext, exposed Kubernetes clusters to takeover

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

Public disclosure, a talk, and a blog post later, the RCE exploit remains unresolved

Public disclosure, a talk, and a blog post later, the RCE exploit remains unresolved

Despite a researcher’s best efforts at disclosure, the maintainers of the WebPageTest project appear to be ignoring a severe remote code execution (RCE) vulnerability.

In a blog post dated September 23, ManoMano researcher Louka “Laluka” Jacques-Chevallier discussed his discovery of a pre-authentication RCE vulnerability in the open source project WebPageTest.

The research has also been the subject of a talk at DEFCON Paris.

Catch up with the latest security research and analysis

Developed by Catchpoint, WebPageTest is a tool dating back to the days of dial-up modems and the 1990s, which has evolved to become a utility to check the speed and performance of website code for optimization purposes.

According to the researcher, this software has been “prone” to security issues in the past, including a lack of updates to code and containers, outdated components which remained unpatched against known vulnerabilities, and the “intensive use of smelly PHP code”.

The latest stable release of WebPageTest, v22.01, was published in October 2021.

Server-side request forgery (SSRF) vulnerabilities, bugs that allow attackers to make successful requests via a server-side application to an unintended location or resource, have been found in WebPageTest in the past.

A newly discovered SSRF flaw was the focus of Laluka’s research.

After examining the software’s source code and carrying out both crawling and fuzzing tests, Laluka discovered an SSRF vulnerability in under 15 minutes. The SSRF was limited to an HTTP scheme, but the underlying code held more surprises for the cybersecurity researcher.

**Under the microscope**

Upon closer inspection Laluka uncovered a range of issues, including PHP code that could trigger a payload by including a slash in a path, file write bugs, and sanitization failures. Eventually, the researcher was able to push a command injection, create a reverse shell, exploit JSON file jobs, and achieve RCE.

It may also be possible to exploit the RCE if the Beanstalkd work queue engine is in use. While not present in default configurations, Laluka says that the SSRF and command injection issues could be exploited to inject a new, malicious job and force the worker to use the file.

The researcher found the first SSRF bug on April 15, and by May 25, verified the full RCE exploit chain. Laluka contacted the vendor on June 15, and although Catchpoint responded, the lines of communication were described as “pretty tedious”.

**‘Open bag’**

Despite providing the technical details of the issue and a video Proof-of-Concept (PoC), the vendor did not respond until July 28, when Catchpoint offered a $300 “big” bounty program reward.

Laluka offered to help with patch validation, but there has been radio silence since. Although he was paid, it’s been over 90 days, and there is still no news on a fix.

“I think that this software can be really helpful for devs and site reliability engineers, but that the codebase isn’t following good practices whatsoever,” Laluka told The Daily Swig. “It’s basically features in a bag – an open bag.”

Catchpoint has not responded to requests for comment from The Daily Swig.

RELATED PHP package manager component Packagist vulnerable to compromise

Critical flaw in open source WebPageTest remains unpatched

With 35.6 million downloads the OAuth 2.0 protocol provider has serious downstream attack surface

With 35.6 million downloads the OAuth 2.0 protocol provider has serious downstream attack surface

  

OpenID Connect (OIDC) identity service Dex has patched a critical vulnerability that would allow an attacker to fetch an ID token through an intercepted authorization code and potentially gain unauthorised access to client applications.

Dex uses OIDC , a simple identity layer on top of the OAuth 2.0 protocol, to power authentication for other apps. It acts as a portal to other identity providers through ‘connectors’, allowing it to defer authentication to LDAP servers, SAML providers, or identity providers such as GitHub, Google, and Active Directory.

Dex, an open source sandbox project from the Cloud Native Computing Foundation, has been downloaded 35.6 million times.

**Consent problem**

Security researchers discovered that an attacker who can dupe a victim into navigating to a malicious website can steal the OAuth authorization code, exchange it for a token, and then gain access to applications that accept that token. The exploit can be used multiple times, allowing the attacker to get a new token every time the old one expires.

“The cause of the bug is the implementation of the consent page,” Dex maintainer Maksim Nabokikh tells The Daily Swig.

“This page is supposed to protect users from sharing too much profile data with the application. Instead, it created a hole in Dex. If fraudsters can access this page before a user, they can steal not only all the user’s data but also impersonate it.”

**Reproduction steps**

When the victim navigates to the malicious website, Dex returns a 302 Redirect to the connector IDP, according to a GitHub security advisory. The exploit then involves recording the state parameter value , which later becomes the request ID.

The website subsequently redirects the victim’s browser to the connector IDP, to which the user authenticates. And if the user has authenticated before, authentication may be carried out without a challenge, with the connector IDP redirecting the browser to the Dex callback with a code.

Read more of the latest authentication security news

Dex then fetches the user claims from the connector IDP, persisting them and generating an OAuth code, before redirecting the browser to the approval endpoint. The reproduction steps conclude with Dex using the request ID to look up the OAuth code, and building a redirect to the original callback .

The flaw, which has a CVSS rating of 9.3, affects versions 2.34.0 and earlier, with users advised to update to version 2.35.0. Those using Google connector should upgrade to 2.35.1 instead.

The patch was created by Sigstore developers Hayden Blauzvern, Bob Callaway, and ‘joernchen’, the original reporter of the bug.

The fix involved introducing a hash-based message authentication (HMAC) code, which uses a randomly generated per-request secret that can’t be known to an attacker and is persisted between the initial login request and the approval request.

DON’T FORGET TO READ Matrix address flaws that break message encryption assurances

Dex patches authentication bug that enabled unauthorized access to client applications

‘SBOM turns on flashing lights on the dashboard; VEX helps you figure out which to turn off’

‘SBOM turns on flashing lights on the dashboard; VEX helps you figure out which to turn off’

A new twist on security advisories promises to optimize the triaging of vulnerabilities by highlighting whether flaws are not just present within software but practically exploitable, too.

Developed by the US government, the vulnerability exploitability exchange (VEX) enables “both suppliers and users to focus on vulnerabilities that pose the most immediate risk” and avoid wasting time on bugs with no impact, according to use cases (PDF) published by the US Cybersecurity & Infrastructure Security Agency (CISA) in April 2022.

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

As CISA vulnerability analyst Justin Murphy puts it: if a software bill of materials (SBOM) “turns on flashing lights on the dashboard, VEX helps you figure out which ones you have to turn off”.

Speaking at the recent Linux Security Summit in Dublin, Ireland, Murphy said this “negative security advisory” supplements the provision of a product’s ‘ingredients’ by SBOMs, which President Biden has decreed should be a precondition for the government purchase of software.

**Vulnerable\_code\_not\_in\_execute\_path**

VEX advisories, which emerged from a National Telecommunications and Information Administration (NTIA) project, advise whether a product is ‘affected’, ‘not affected’, ‘fixed’, or ‘under investigation’ in relation to a particular bug.

As detailed (PDF) by CISA, the ‘not affected’ designation could be accompanied by ‘status justifications’ such as:

*   Component\_not\_present
*   Vulnerable\_code\_not\_present
*   Vulnerable\_code\_cannot\_be\_controlled\_by\_adversary
*   Vulnerable\_code\_not\_in\_execute\_path
*   Inline\_mitigations\_already\_exist

Murphy suggested a specific scenario in which “you have a third-party dependency and it says the code is vulnerable, but since the compiler rips it out you’re not actually affected”. Alternatively, he continued, a product might use a vulnerable library but not its vulnerable functions, or contain protections around input validation.

In providing information about exploitability, suggested Murphy, VEX advisories usefully augment SBOMs and the Known Exploited Vulnerability Catalog, which CISA launched in the fall of 2021.

**Machine readability**

The proliferation of CVEs and therefore security advisories has made tackling known vulnerabilities a “data management problem”, said Murphy.

And the problem is complicated by the fact advisories come in various formats, hampering not just machine readability but also “human readability in some cases”.

Asking the maintainer about flaws – “will you even get a response?” – or conducting your own, time-consuming investigation are hardly superior alternatives, argued Murphy.

This context helps explain CISA’s focus on interoperability and the fact VEX advisories can be implemented in the machine-readable OASIS CSAF standard.

**Name confusion**

Aspirations to link SBOM and VEX data are complicated by the lack of a universally agreed upon system of common identifiers for software components, conceded Murphy.

As such, security teams are at risk of erroneously misunderstanding their stack’s exposure when, for example, separate SBOMs inadvertently use differing identifiers for the same component or the same identifier for different components.

A comprehensive component identification system probably needs to address this problem “through aliases or equivalency relationships”, suggested Murphy, perhaps using a combination of common platform enumeration (CPE), package URLs (purls), SWID tags, SWHIDS, and GitBOM.

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

The exploitability advisory: CISA’s VEX offers fresh take on tackling known vulnerabilities

Argument injection bug posed RCE risk

One of the important components of Composer, the main package manager for PHP applications, contained a vulnerability that could have been abused to attack coding repositories, researchers at SonarSource have found.

Packagist, the vulnerable component, enables Composer to determine and download software dependencies that software developers include in their projects. Composer serves approximately two billion software packages every month.

The vulnerability might potentially have been exploited to distribute malicious backdoored packages to servers, a technical blog post by SonarSource explains.

An estimated 3500,000 dependencies were threatened by the security flaw.

Fortunately, the vulnerability was resolved by project maintainers only hours after it was reported.

**Argument injection**

The new bug comes a year after SonarSource discovered and reported another supply chain attack vulnerability in Packagist. The previous bug was in the classes that interact with version control systems (VCS) like Git, Mercurial, and Subversion to resolve dependencies from code repositories.

While that vulnerability was patched by the maintainers of Packagist, SonarSource researchers found that other parts of the same class implementations were still prone to potential attack.

“Our previous research helped us navigate quickly to the juicy sections of the code base, but at the same time, we’ve missed this bug several times when reviewing code and patches related to our previous discovery,” Thomas Chauchefoin, a vulnerability researcher at SonarSource, told The Daily Swig.

To display information about packages, Packagist reads content from readme.md or a user-specified file in the code repository. Packagist contains separate implementations to retrieve file data from different VCS systems. Each of these implementations composes a shell command that includes content from the user-supplied file.

According SonarSource, if an attacker inserted malicious commands in the information file, they would be inserted as arguments in the shell command that ran on the system. And although Packagist uses escaping mechanisms to stop malicious code, it left some gaps open.

**Supply chain attack**

In a proof-of-concept video, the researchers show how the vulnerability can be exploited to run arbitrary commands on the server.

The attacker could abuse the bug to modify the definition of a package and point it to an unintended destination, tainting the software development pipeline in the process.

“Defending against argument injection bugs is very unusual compared to all the techniques we’ve been pushing to developers in the past decade, and I think that’s why we’ve been finding them a lot,” Chauchefoin commented.

“Third-party data can be encoded, escaped, and tightly validated, but that’s often not enough!”

**Protect yourself**

The bug was patched shortly after SonarSource reported it to Packagist. If you are using the default official Packagist instance or Private Packagist, you are already safe. If you have integrated Composer as a library and operate on untrusted repositories, you must upgrade to one of the patched versions of the library.

“Nothing changed in the year after our previous discovery, which is understandable as these are vital projects with years of work behind them,” Chauchefoin said.

“Enforcing features like the signing of any build artifact (i.e., packages) would likely introduce non-trivial changes to the workflows of millions of developers.”

Meanwhile, Chauchefoin expressed hope that more traction around new standards like sigstore might help mitigate the risks of supply chain attacks.

“Ideally, package managers should only be tubes between the maintainers and package users, and there should be no way to tamper with what's flowing inside. Signing everything is the key, and sigstore makes it much more affordable,” he said.

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

Source

PortSwigger