Super admins can, among other things, modify Jira connections, reset user accounts, and modify security settings

Adam Bannister 26 October 2022 at 16:00 UTC  
Updated: 27 October 2022 at 09:42 UTC

Super admins can, among other things, modify Jira connections, reset user accounts, and modify security settings

UPDATED A pair of vulnerabilities patched in Jira Align could have enabled low-privileged malicious users to elevate their privileges to super admin, a security researcher has found.

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.

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, the researcher said.

**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

Shafer also speculated that, while his testing “stopped at the edge of the Atlassian infrastructure”, leveraging the SSRF “under the right conditions” might theoretically enable attackers to move laterally or upward through Atlassian’s AWS infrastructure.

However, Atlassian disputed this assertion in response to queries from The Daily Swig, emphasizing “that Jira Align's SaaS and Atlassian's wider SaaS are not connected. The Jira Align AWS environment was locked down to a level that there was no accessible information that was not encrypted and other layers could not be reached, so this is a purely hypothetical and misleading statement”.

**No exploitation detected**

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

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 on June 9.

Bala Sathiamurthy, chief information security officer at Atlassian, told The Daily Swig: “These are both known and patched medium-severity vulnerabilities. Our Security Intelligence team has verified that no customers that use Jira Align on an Atlassian hosted cloud offering had either vulnerability exploited.”

He added: “As always, we recommend that our server and data center customers apply the latest security patches and mitigations as soon as they are available in order to receive the latest features and fixes. We also recommend that our customers move to the cloud versions of Atlassian products to ensure they automatically receive the upgrades and security patches.”

**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.

This article was updated on October 27 with the addition of comment from Atlassian.

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

Jira Align flaws enabled malicious users to gain super admin privileges

POP chain crafted to demonstrate exploitability

Adam Bannister 25 October 2022 at 15:20 UTC

POP chain crafted to demonstrate exploitability

Melis Platform, the open source e-commerce and content management system (CMS), was vulnerable to remote code execution (RCE) via a critical deserialization vulnerability.

Tracked as CVE-2022-39297 and with a CVSS score of 9.8, the object injection flaw has been patched along with a pair of high severity bugs by French vendor Melis Technology.

Melis Platform is based on Laminas, a popular PHP framework formally known as Zend, and counts Keyrus, Paco Rabanne, and La Banque Postale among its users.

Read more of the latest PHP security news

The vulnerabilities were discovered by researchers from Swiss security outfit Sonar.

“The main vulnerability we identified comes from the deserialization of user data, something that is known to be unsafe for quite some time now,” Sonar vulnerability researcher Thomas Chauchefoin told The Daily Swig.

“As modern applications are very loosely coupled, it was not immediately obvious, even to an educated eye, that attackers could reach this code. This is where automated code analysis can be very powerful,” they added.

**‘Puzzle pieces’**

Having established the potential for abuse of PHP’s function with Sonar’s static analysis tool, the researchers tested exploitability by crafting a Property Oriented Programming (POP) chain.

“The fun thing about deserialization vulnerabilities in PHP is that not so many gadget chains are available when you adventure \[move\] yourself out of the usual targets; they are like small puzzle pieces you have to assemble to obtain code execution,” said Chauchefoin.

“We had to come up with a new chain for the framework Laminas. We added it to PHPGGC, a public database of the most common gadget chains, so other researchers don't have to do this work again!”

**Targeting the cache layer**

In a blog post, Chauchefoin and Sonar software engineer Karim El Ouerghemmi documented how they targeted Laminas’ cache layer.

“Cache systems are often good targets ‘because they are\] designed in a way to be loosely coupled with the rest of the application (e.g. automatically trigger save at the end of the lifecycle of the request by using destructors) and support a broad range of storage backends, including filesystems,” they wrote. “It can also be assumed that gaining the ability to control what's stored in the cache can be abused later upon its retrieval, this data is always considered to be trusted.”

The other high severity issues caught by Sonar’s researchers include CVE-2022-39296, an arbitrary file read bug, and CVE-2022-3929, a DMA re-entrancy vulnerability in the NVM Express Controller (NVME) emulation in QEMU that could lead to denial of service (DoS) or code execution.

Sonar reported the vulnerabilities to Melis Technology back in June 2021 and patched updates were released on September 23, 2022.

The flaws affect versions spanning 2.2.0 and 5.0.0 inclusive, and were remediated in Melis 5.0.1.

DON’T MISS HyperSQL DataBase flaw leaves library vulnerable to RCE

Melis Platform CMS patched for critical RCE flaw

Chinese and Russian cyber-spies actively targeting security vulnerability

Chinese and Russian cyber-spies actively targeting security vulnerability

Fortinet is urging customers to patch a critical authentication bypass vulnerability that has already been exploited in the wild.

Earlier this month, the networking vendor patched the bug, CVE-2022-40684, found in its FortiOS network operating system, FortiProxy secure web proxy, and FortiSwitchManager management platform projects.

The vulnerability allows an unauthenticated attacker to add an SSH key to the admin user, enabling potential miscreants to hack the administrative interface using specially crafted HTTP or HTTPS requests.

The issue affects FortiOS versions from 7.0.0 to 7.0.6 and from 7.2.0 to 7.2.1, FortiProxy versions from 7.0.0 to 7.0.6 and 7.2.0, and FortiSwitchManager versions 7.0.0 and 7.2.0.

Catch up on the latest network security news and analysis

Customers were notified via email and advised to update vulnerable devices to FortiOS 7.0.7 or 7.2.2 and above, FortiProxy 7.0.7 or 7.2.1 and above, and FortiSwitchManager 7.2.1 or above earlier this month. Those that can’t, said Fortinet, should immediately disable internet-facing HTTPS Administration interfaces.

After the patch was released, Horizon3.ai published proof-of-concept code for exploiting the vulnerability.

“An attacker can use this vulnerability to do just about anything they want to the vulnerable system. This includes changing network configurations, adding new users, and initiating packet captures,” it warned.

“Note that this is not the only way to exploit this vulnerability and there may be other sets of conditions that work. For instance, a modified version of this exploit uses the User-Agent ‘Node.js’.”

**Axis of exploit**

Meanwhile, cybersecurity firm Cyfirma warned that attackers are scanning for and attempting to exploit the vulnerability in the wild.

“Our intelligence research community observed Iranian and Chinese threat actors abusing the vulnerabilities of Fortinet products,” it said. “The suspected threat actors are US17IRGCorp aka APT34, HAFNIUM, and its affiliates in the ongoing campaign.”

Cyfirma warned that Iranian cybercriminals appear to be colluding with Chinese groups and Russian cybercriminals as part of the campaign, with the aim of supporting Russia’s offensive in Ukraine.

Dark web forum discussions, according to Cyfirms, have focused on exploiting weakness in enterprise networks that rely of Fortinet’s technologies, manipulator-in-the-middle (MITM) attacks, potential ransomware attacks, and lateral movement to hack deeper in the network of compromised organizations.

**Patching advice reiterated**

In response to the detection of attacks in the wild, Fortinet issued a further advisory, stressing the increased seriousness of the situation.

“Fortinet is aware of instances where this vulnerability was exploited to download the config file from the targeted devices, and to add a malicious super\_admin account called ‘fortigate-tech-support’,” it said, before reiterating its advice for customers to update.

However, four days later, it appeared that many affected organizations had still failed to patch their systems, leading to yet another warning from Fortinet.

“After multiple notifications from Fortinet over the past week, there are still a significant number of devices that require mitigation, and following the publication by an outside party of PoC code, there is active exploitation of this vulnerability,” it said.

In a statement for The Daily Swig, the company adds: “As part of our commitment to the security of our customers, we continue to proactively reach out to strongly urge them to immediately follow the guidance provided in our October 10 PSIRT Advisory (FG-IR-22-377), as we continue monitoring the situation.”

RELATED Failed Cobalt Strike fix with buried RCE exploit now patched

Critical authentication bug in Fortinet products actively exploited in the wild

Mishandling of untrusted input issue resolved by developers

John Leyden 24 October 2022 at 14:46 UTC

Mishandling of untrusted input issue resolved by developers

Security researchers have discovered a serious vulnerability in HyperSQL DataBase (HSQLDB) that poses a remote code execution (RCE) risk.

HSQLDB offers a Java\-based SQL relational database system. The technology – which is the second most popular embedded SQL database with 100 million downloads to date – is used for development, testing, and deployment of database applications.

HSQLDB is used by more than 3,120 Maven packages including LibreOffice, JBoss, Log4j, Hibernate, and Spring-Boot as well as various enterprise software packages.

**Parsing problem**

Security researchers from Code Intelligence discovered the RCE vulnerability (tracked as CVE-2022-41853 and rated with a near-maximum CVSS severity score of 9.8) after running a series of fuzzing tests.

More precisely, they found that the parsing procedure for binary and text format data in the java.sql.Statement and java.sql.PreparedStatement components of the technology were flawed.

All versions of the software up to and including HSQLDB version 2.7.0 are vulnerable. Code Intelligence contacted HSQL Development Group, the developers of HSQLDB, who responded promptly by putting together a fix and a workaround that helps safeguard previous versions.

Catch up on the latest secure development news and analysis

HSQLDB is yet to respond to a request for comment from The Daily Swig but security researchers from Code Intelligence have confirmed that a patch is in the pipeline.

“The issue is already fixed upstream and will be available in the next release,” Code Intelligence said. “From version 2.7.1. the property hsqldb.method\_class\_names must be defined with a list of class names or wild cards if any Java static method is used as an HSQLDB routine target.”

The previous implementations caused a problem because the use of Java static methods, except those in java.lang.Math, should not be allowed without defining the system property or else problems can arise.

**Root cause**

A technical write-up of the issue by Code Intelligence explains the root cause of the problem in more depth.

“By default, SQL statements can be used to call any static method from any Java class in the class path. HSQLDB (HyperSQL DataBase) allowed direct use of methods,” a post on Medium last week explains.

The vulnerability means that using java.sql.Statement or java.sql.PreparedStatement in pre-patch versions of HSQLDB along with untrusted input may leave applications vulnerable to an RCE attack.

In response to queries from The Daily Swig, Khaled Yakdan, co-founder of Code Intelligence, explained that an app does not have to be vulnerable to SQL injection for the issue to come into play.

“The current default configuration allows static methods of any class that is on the classpath to be used,” Yakdan said. “Moreover, direct use of methods is allowed for legacy compatibility.”

Yakden declined to speculate on which particular apps might be vulnerable, but he was able to explain the impact of the flaw in cases where it was activated.

“We only focus on finding bugs and don’t investigate which code bases are vulnerable,” Yakden told The Daily Swig. “The impact of this CVE is that if you use HyperSQL to process queries that include (untrusted) user input, attackers may be able to cause your app to execute arbitrary code.”

RELATED Apache Commons Text RCE: Resemblance to Log4Shell but exposure risk is ‘much lower’

HyperSQL DataBase flaw leaves library vulnerable to RCE

Platform pays high reward for bug reported as ‘low severity’

Jessica Haworth 21 October 2022 at 14:00 UTC  
Updated: 21 October 2022 at 14:29 UTC

Platform pays high reward for bug reported as ‘low severity’

  

A researcher netted a $10,000 bug bounty reward from GitHub after discovering a way to spoof the platform’s login interface.

Saajan Bhujel found a bypass that allowed him to change the CSS of the website, potentially tricking users into logging into the fake page.

GitHub uses MathJax, an open source JavaScript display engine for LaTeX, MathML, and AsciiMath notation.

Users can render or display mathematical expressions in Markdown through the MathJax library.

Read more of the latest web security vulnerability news

Bhujel found a way to bypass MathJax’s HTML filtering by injecting a malicious tag that is filtered and removed, which then allowed him to inject form elements that spoof the GitHub login interface.

He originally reported the issue to GitHub using a different technique, as described in a blog post.

When GitHub noted that his submission was a duplicate, Bhujel used a different technique to enable him to find the bypass.

The researcher told The Daily Swig that he is “so happy” with the reward of $10,000, despite originally reporting it as a low severity issue.

RECOMMENDED Failed Cobalt Strike fix with buried RCE exploit now patched

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

The fix was developed at a running pace as Cobalt Strike is essential to Red Team operations

The fix was developed at a running pace as Cobalt Strike is essential to Red Team operations

  

The team behind the Cobalt Strike penetration testing tool has responded to reports of a failed remote code execution (RCE) exploit patch with a new fix.

HelpSystems’ Cobalt Strike enables cybersecurity professionals to simulate attacks with post-exploit agents and is arguably the most popular threat emulation software of its type.

However, the source code of old versions of the licensed software is subject to leaks – the latest of which reportedly took place in 2020.

As a result, Cobalt Strike often surfaces within the arsenal of sophisticated threat actors who use the software to set up command and control (C2) beacons for illicit communication.

**Failed fix**

Given the importance of this tool and how red teams worldwide rely on Cobalt Strike for their research and cybersecurity audits, the details of the failed patch were kept private until a fix could be released.

On October 17, Rio Sherri, managing security consultant of IBM’s X-Force Red Adversary Simulation team, revealed in a blog post that a patch designed to resolve a known RCE vulnerability had failed.

The vulnerability, tracked as CVE-2022-39197 and issued a CVSS severity score of 6.1, is a cross-site scripting (XSS) issue that allowed remote attackers to execute code without permission on the Cobalt Strike teamserver.

It was possible to trigger the bug by inspecting a Cobalt Strike v.4.7 payload and modifying the username field. Alternatively, an intruder could create a new, malicious payload using the extracted information.

A researcher with the pseudonym ‘Beichendream’ privately reported the original security flaw.

HelpSystems published an out-of-band patch for the RCE on September 20. The Cobalt Strike 4.7.1 release added a new property to the teamserver file, which “specifies whether XSS validation is performed on selected Beacon metadata,” according to HelpSystems.

However, after IBM researchers Sherri and Ruben Boonen examined the patch, it transpired that the 4.7.1 update was “insufficient to mitigate the impact of the vulnerability”.

If an attacker created Java Swing components, the researchers found, it was possible to circumvent the fix and create arbitrary Java objects in class paths, as Java Swing will interpret any text as HTML content as long as it begins with an HTML tag. Object tags could then load a malicious payload from the server, which a Cobalt Strike client would subsequently deploy.

**Second patch**

IBM X-Force notified HelpSystems of its findings privately and requested a new CVE, CVE-2022-42948. The researchers also assisted Cobalt Strike developers in creating a bulletproof patch.

The vulnerability has been resolved in Cobalt Strike v. 4.7.2 via a second out-of-band patch. HelpSystems thanked IBM, noting that the circumvention was caused by the Cobalt Strike interface being built on the Java Swing framework.

While IBM requested a new CVE, HelpSystems did not, noting that the underlying issue is in Java Swing rather than Cobalt Strike as a standalone application.

“We felt that there were parallels between this and the recent log4j vulnerability – thousands of applications that used log4j were vulnerable and yet there aren’t CVEs to cover every single vulnerable application,” commented Greg Darwin, Cobalt Strike software development manager. “It is the same case here, although I appreciate that some people may disagree.”

The Daily Swig has reached out to IBM for clarity on the focus of the new CVE assignment and we will update if and when we hear back.

DON’T MISS Apache Commons Text RCE: Resemblance to Log4Shell but exposure risk is ‘much lower’

Failed Cobalt Strike fix with buried RCE exploit now patched

Behavior functioning as intended, Microsoft reportedly says, and offers mitigation advice instead

Ben Dickson 20 October 2022 at 15:46 UTC

Behavior functioning as intended, Microsoft reportedly says, and offers mitigation advice instead

Windows servers running Microsoft Office Online Server can be exploited to achieve server-side request forgery (SSRF) and thereafter remote code execution (RCE) on the host, according to security researchers.

Researchers from MDSec said they informed the Microsoft Security Response Center of their findings, but were told that the vulnerable behavior is not a bug but a feature of Office Online Server, and therefore will not be fixed.

Read more of the latest Microsoft security news

According to MDSec, Microsoft has instead advised administrators to “lock down ports and any accounts on that farm to have least privilege” to avoid attacks against internet-connected Office Online hosts.

Administrators can also set the service’s flag to false to prevent access to files through UNC paths, which is the feature used to attack the server.

**SSRF**

Office Online Server is an ASP.NET service that provides browser-based versions of Word, Excel, PowerPoint, and OneNote. Office Online provides access to Office files through SharePoint, Exchange Server, shared folders, and websites.

Office Online has a .aspx page for retrieving documents from remote resources. Attackers can use this endpoint to initiate connections to remote resources through the server and perform SSRF, according to a technical write-up from security firm MDSec.

For example, the researchers found that they could send unauthenticated requests to the page to fingerprint the devices of the server’s local network. Based on the timing of the response, they could identify active IP addresses in the server’s network.

**RCE**

Attackers could further exploit the bug if they controlled an SMB server that the Office Online Server could access.

Office Online Server uses its machine account to initiate connections to remote resources. When using the endpoint to retrieve a document on their SMB server, researchers could use the tool ntlmrelayx to force the server to relay the connection to the Active Directory Certificate Services (ACDS) and retrieve a client certificate for the Active Directory network.

Using this certificate, they were able to obtain a Ticket-Granting Ticket (TGT) – a logon session token – to the Office Online Server host. They used the TGT to send an S4U2Self request to forge a service ticket to the server. This allowed them to obtain local administrator access to the host.

According to the researchers’ findings, there was another pathway to obtain remote access to the server by relaying the endpoint connection to the LDAP service and performing a shadow credential attack.

The Daily Swig reached out to Microsoft for comments. We will update this post if we hear back.

YOU MIGHT ALSO LIKE Adobe patches critical Magento XSS that puts sites at takeover risk

Microsoft Office Online Server open to SSRF-to-RCE exploit

Former chair bemoans ‘coup by governance’

Former chair bemoans ‘coup by governance’

Security certification body (ISC)² is being accused of promoting a series of ‘undemocratic' changes to its bylaws.

(ISC)² – the International Information System Security Certification Consortium – is a non-profit organization providing training and certification for cybersecurity professionals.

Over the last two years, it has been carrying out a review of its practices around committees, nominations, and governance. The aim, it said, is to create a more inclusive organization that is better positioned to serve the needs of the security profession in future.

**Bylaw amendments**

The proposed bylaw amendments, announced earlier this month, include allowing the establishment of other non-voting membership classes, adding the chair as an officer of (ISC)², and updating the standing committees to include ones overseeing audit, compensation and CEO succession, nominations, and risk.

There is also a new mission statement, reading: “(ISC)² exists to strengthen the influence, diversity, and vitality of the cybersecurity profession through advocacy, expertise, and workforce empowerment that accelerates cyber safety and security in an interconnected world.”

However, some of the proposed changes have raised concern.

**Member engagement shortcomings**

According to Wim Remes, a former board member who spent three years as (ISC)² chair, the organization currently has a poor record on member engagement, with election turnout averaging only around 4%.

As things stand, 500 endorsements are required for members to raise a petition. However, the new proposals would see this figure raised to 1% of the 170,000-odd members.

“This effectively shuts down an important relief valve in corporate governance, in my opinion, and is not in the interest of the membership,” Remes told The Daily Swig.

“It’s already impossible to get up to 500. It’s unthinkable anybody would make it to 1,600, \[or\] to 2,000.”

**Membership slate**

Also in the pipeline is a significant change to the process for electing the board of directors. If approved, this would remove the option for a write-in candidate and witness the board submitting a slate of qualified candidates to the membership that would be equal to the number of open seats.

“Combined with making the petition process harder – if not impossible – this is as close to a coup by governance as one could get,” Remes argued. “They still call it an election, but it is officially a coronation.”

Meanwhile, the Ethics Committee is to be eliminated as a standing committee of the board.

“I don’t know what the plan here is, but our profession stands and falls by ethics,” Remes explained. “I can’t find a rationale that would explain how we, as members, would not want the board to ensure that professional ethics are maintained by members.”

**Case for the defense**

Clar Rosso, CEO of (ISC)², defended the changes, stating they are aimed at making the organization more inclusive and globally representative.

“The proposed bylaw changes, which members will vote on, reflect not only creating a more inclusive organization, for example, eliminating the English fluency requirement and introducing best practices in term limits and nominations processes, but also modernize the bylaws by using gender neutral references to board officer position and moving our ethics process from one that is majority board-run to a process that is adjudicated by a broader cross-section of members,” Rosso told The Daily Swig.

“Additionally, many of these bylaw changes are reflective of best practices of other similarly-sized associations, and some simply provide clarity and ensure legal compliance with applicable state and federal laws. The (ISC)² board of directors, comprised entirely of member volunteers, supports the proposed changes.”

Members can vote on the proposed bylaw amendments from now until November 19, with proxy votes applied to a final bylaw vote during the annual meeting on December 14.

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

Security certification body (ISC)² defends ‘undemocratic’ bylaw changes

Log4Shell-like bug is serious but less dangerous than notorious Log4j vulnerability

Adam Bannister 19 October 2022 at 10:35 UTC  
Updated: 19 October 2022 at 11:46 UTC

Log4Shell-like bug is serious but less dangerous than notorious Log4j vulnerability

A critical flaw patched in the Apache Commons Text library has sparked comparisons with the ‘Log4Shell’ bug that surfaced in the near-ubiquitous open source component Log4j last year.

However, the researcher who found and reported the Commons Text flaw in March has downplayed its comparative impact, while acknowledging a resemblance to the ‘Log4Shell’ vulnerability that is widely recognized as one of the most severe flaws of all time.

**Lookup link**

“The vulnerability is indeed very similar,” GitHub Security Lab principal researcher Alvaro Muñoz told The Daily Swig.

“The Apache Commons Text code appears to be based on the Log4j code, as both of them enable interpolation of multiple Lookup sources. Log4j enabled JNDI lookups \[while\] Apache Commons Text and Apache Commons Configuration allows script lookups – both could lead to RCE. The impact is, therefore, very high.

“However, it is worth keeping in mind that an issue's severity is calculated based on both the impact and the likelihood, and for the Apache Commons Text, the likelihood of untrusted data flowing to ACT's sink is much lower.”

RECOMMENDED ‘Endemic’ Log4j bug set to persist in the wild for at least a decade

  
Apache Commons Text performs text operations such as escaping, calculating string differences, and substituting placeholders in text with values looked up through interpolators. Fellow open source library Log4j is a Java-based logging utility.

Tracked as CVE-2022-42889, the Commons Text bug emerged on October 13 with an Apache Software Foundation (ASF) security advisory.

The vulnerability centers on an insecure implementation of the library’s variable interpolation functionality, namely that certain default lookup strings could potentially accept untrusted input from remote attackers, such as DNS requests, URLs, or inline scripts.

**‘Clearly documented’**

A technical analysis published yesterday by Rapid7 also attempted to tamp down hype over the bug, whose CVSS score of 9.8 is nevertheless close to Log4Shell’s perfect 10 on the severity front.

The vulnerable “ interpolator is considerably less widely used than the vulnerable string substitution in Log4j and the nature of such an interpolator means that getting crafted input to the vulnerable object is less likely than merely interacting with such a crafted string as in Log4Shell,” said Rapid7.

The ASF echoed these sentiments, telling The Daily Swig: “In Log4Shell, string interpolation was possible from the log message body, which commonly contains untrusted input. In the Apache Common Text issue, the relevant method is explicitly intended and clearly documented to perform string interpolation, so it is much less likely that applications would inadvertently pass in untrusted input without proper validation.”

**Remediation**

The flaw affects Apache Commons Text versions 1.5 through 1.9, and all JDK versions, and has been patched in version 1.10.

The ASF said: “When using the string substitution feature, some of the available interpolators can trigger network access or code execution. This is intended, but it also means an application that includes user input in the string passed to the substitution without properly sanitizing it would allow an attacker to trigger those interpolators.

Read more of the latest news about web security vulnerabilities

“For that reason the Apache Commons Text team have decided to update the configuration to be more ‘secure by default’, so that the impact of a failure to validate inputs is mitigated and will not give an attacker access to these interpolators.

“However, it is still recommended that users treat untrusted input with care. We’re not currently aware of any applications that pass untrusted input to the substitutor and thus would have been impacted by this problem prior to Apache Commons Text 1.10.0.”

Rapid7 recommends that developers and maintainers watch out for follow-on vendor advisories, install “patches as they become available, and prioritize anywhere the vendor indicates that their implementation may be remotely exploitable”.

RELATED Log4Shell legacy? Patching times plummet for most critical vulnerabilities – report

Apache Commons Text RCE: Resemblance to Log4Shell but exposure risk is ‘much lower’

Attack surge blamed on ‘avoidable’ bugs

Charlie Osborne 18 October 2022 at 15:21 UTC  
Updated: 18 October 2022 at 16:07 UTC

Attack surge blamed on ‘avoidable’ bugs

Researchers warn that there has been a 633% year-over-year increase in cyber-attacks launched against open source software repositories.

Open source components, frameworks, libraries, and whole platforms are relied upon by organizations during multiple stages of the software development lifecycle. These components provide the lynchpins for communication, software capabilities, security, and user interactions – and as they are developed and reviewed by communities, open source promotes innovation in the software space.

However, the other side of the coin is that open source contributors are volunteers; therefore, security issues can sometimes slip through the net. Furthermore, IT teams may not be aware of what open source software is in use and so they might easily miss patch alerts and upgrades that impact their business.

Catch up on the latest open source software news and analysis

New research suggests that cyber-attackers – well aware of organizational reliance on open source software – are increasing their attempts to compromise repositories year on year.

According to Sonatype’s 8th Annual State of the Software Supply Chain report, known attacks against open source repositories have increased by 633% year-over-year, and there has been an annual, overall increase of 742% since 2019.

After analyzing data from public and proprietary sources, the software supply chain security firm said that the popularity and growth of open source software continues to climb. The four main ecosystems – Java, JavaScript, Python, and .NET – tied to open source development are set to go beyond three trillion downloads in the near future.

However, this popularity has security ramifications.

**Technical debt**

“The amount of third-party code flowing through software supply chains occurs on a massive scale,” the researchers said. “Yet published code accrues technical debt over time, creating the potential for compounded security vulnerabilities, if not kept up-to-date.”

According to the researchers, 1.2 billion Java dependencies known to be vulnerable, for example, are downloaded each month while new, patched, or improved versions are ignored.

Sonatype said this is a prime example of “non-optimal consumption behaviors as the root of open source risk”.

“This is in contrast to public discussion, which often associates security risk with open source maintainers,” the report added.

**Risky business**

Risky behavior is not necessarily anyone’s fault. Developers tasked with managing dependencies face more complexity in their roles than ever, with the average Java application containing 148 dependencies – 20 more than 2021’s average – and going through an average ten updates a year.

Each dependency could contain vulnerabilities, so developers must track potentially thousands of changes per year, per app. Therefore, mistakes will be made.

Brian Fox, co-founder and CTO of Sonatype said that “the overwhelming tide of dependency intelligence that developers must interpret in their daily development process is at odds with prioritizing good software quality”.

It is, therefore, critical that education on the potential risk of outdated, vulnerable open source software is understood, and teams should consider adopting automation to lighten the load.

Fox added: “\[The\] sobering reality demonstrates the immediate need for organizations to prioritize software supply management so that they can better deal with security risk, increase developer efficiency, and enable faster innovation.”

YOU MAY ALSO LIKE Linux Foundation’s David A Wheeler on reversing the CVE surge

Source

PortSwigger