java

Ivanti’s RCE Nightmare Started with a Library You Might Be Using Too

viviandufour, , , Leave a comment
2–3 minutes

In May 2025, cybersecurity headlines were dominated by Ivanti Endpoint Manager Mobile (EPMM) facing active exploitation through chained remote code execution (RCE) vulnerabilities—CVE‑2025‑4427 and CVE‑2025‑4428. 

These flaws enabled unauthenticated attackers to execute malicious code on affected systems, affecting enterprises globally. Ivanti’s vulnerabilities were notably tied to outdated open-source Java components, highlighting the critical importance of managing open-source security dependencies.

In this blog, we explore the Ivanti incidents, understand the role vulnerable Java libraries played, and demonstrate how proactive software composition analysis (SCA), continuous monitoring, and automated remediation through Meterian-X could have prevented or swiftly mitigated these attacks.

Ivanti’s Open Source Vulnerability: Java Libraries at Fault

The Ivanti vulnerabilities were rooted in the software’s reliance on outdated versions of Java libraries, specifically including “hibernate-validator.” These libraries were susceptible to chained exploits:

  • CVE‑2025‑4427: Allowed authentication bypass.
  • CVE‑2025‑4428: Enabled subsequent remote code execution (RCE).

These vulnerabilities underscore a significant risk: even trusted enterprise products can expose businesses if they incorporate insecure or outdated open-source components.

Understanding the Attack Surface

Ivanti’s attack scenario reveals common industry oversights:

  • Outdated dependency versions not promptly updated.
  • Inadequate visibility into the software bill of materials (SBOM).
  • Insufficient integration of security checks in the continuous integration and continuous delivery (CI/CD) pipeline.

Given the rise in nation-state actors targeting supply chains, companies must ensure software dependencies are continuously scrutinized.

Continuous Monitoring & Detection with Meterian Sentinel

Meterian Sentinel actively monitors dependencies, aggregating real-time vulnerability intelligence from authoritative sources, such as the National Vulnerability Database and GitHub Security Advisories. 

Sentinel would have identified Ivanti’s outdated “hibernate-validator” dependency, alerting development and security teams of the urgent update required.

BOSS: Immediate Alerting & Automated Remediation

Meterian’s BOSS system provides:

  • Real-time notifications of critical vulnerabilities.
  • Actionable, prioritized remediation steps directly within development workflows.

In Ivanti’s case, BOSS would have immediately alerted to the risky dependency version, detailing the vulnerability and auto-generating a recommended fix within the CI/CD process.

Proactive Prevention: CI/CD Integration Workflow with Meterian-X

Integrating Meterian-X into CI/CD pipelines ensures software vulnerabilities are detected and addressed at the earliest stage, automatically:

  • Scanning: Meterian-X conducts real-time vulnerability scanning, flagging outdated dependencies like “hibernate-validator.”
  • Alerting: Via BOSS, teams receive instant alerts embedded within their existing development tools.
  • Remediation: Meterian-X auto-suggests safe library versions, ensuring secure deployment without manual intervention.
  • Verification: Automatically generates comprehensive SBOM reports (in CycloneDX format), streamlining compliance and software traceability.

This integration transforms vulnerability management from reactive firefighting into proactive security.

The Critical Role of SBOM

The Ivanti incident emphasizes why SBOMs are critical:

  • Manufacturers and enterprises gain transparent, real-time views into their software components.
  • Teams rapidly identify vulnerabilities within third-party dependencies.
  • Regulatory compliance becomes streamlined (e.g., SOC 2, EU CRA, EU DORA).

Meterian-X’s CycloneDX-based SBOM generation and ingestion is integral to maintaining visibility, security, and compliance.

Strengthening Your Software Supply Chain

Ivanti’s vulnerability illustrates a fundamental truth: security must extend beyond internal code to encompass all open-source dependencies. Meterian empowers security leaders, developers, and compliance teams to proactively detect and auto-remediate risks like those affecting Ivanti.

Adopting Meterian’s comprehensive security integration ensures continuous monitoring. It provides a rapid response and reliable protection of your software supply chain. This safeguards your business from the increasing threat of supply-chain-based cyber attacks.

Ivanti’s RCE Nightmare Started with a Library You Might Be Using Too

The Java Clone Hack That Happened in 20 Minutes — Could It Happen to You?

viviandufour, , , , Leave a comment
2–3 minutes
A smartphone displaying icons for a 'Clone App' with error messages and a shield symbol, highlighting cybersecurity themes.

In May 2025, a clone of the secure messaging app Signal — known as TM SGNL by TeleMessage — was compromised in under 20 minutes. The breach wasn’t due to zero-day exploits or state-sponsored threat actors. Instead, it was a plain, preventable Java server misconfiguration that exposed plaintext credentials, archived messages, and encryption keys.

This incident is a stark reminder for security and development teams – modern applications, especially Java-based clone apps, are riddled with hidden vulnerabilities that standard controls often miss.

This is exactly the class of threats Meterian’s continuous monitoring and AI-powered vulnerability intelligence is built to catch early and fix fast.


The TM SGNL Hack: Anatomy of a Misconfiguration

At the heart of the breach was a forgotten and publicly accessible Spring Boot Actuator endpoint. The exposed heap dump included:

  • Admin usernames and passwords in plaintext
  • Encryption keys
  • Archived private messages

TM SGNL had promised end-to-end encryption. Yet archived content was stored insecurely, and passwords were hashed using client-side MD5 — a deprecated and insecure method. The application also ran on an outdated JSP stack, compounding the risk.

The breach showed how vulnerable legacy Java frameworks and poor server hygiene can create systemic risk, even in apps that claim security by design.


Where Continuous Scanning Could Have Helped

This type of vulnerability isn’t exotic. It’s configuration-level, but critically dangerous. Meterian’s platform continuously scans Java applications for:

  • Misconfigured Actuator endpoints
  • Insecure or outdated hashing algorithms (like MD5)
  • Use of legacy Java stacks with unpatched CVEs
  • Exposure of credentials in memory dumps or logs

By aggregating insights from over 15 trusted vulnerability feeds, including the National Vulnerability Database and GitHub Advisories, Meterian flags risks with both high fidelity and low noise.


BOSS & Sentinel: Detect, Alert, Remediate

Meterian’s Sentinel engine would have flagged the publicly exposed /heapdump endpoint immediately as a misconfiguration with known exploit patterns. Combined with BOSS, our automated alerting system, security engineers would receive:

  • A prioritized, actionable report
  • A breakdown of the exposed endpoint’s risk level
  • Suggested auto-remediation steps (e.g., disable public access, require auth tokens)

These insights are delivered directly into existing CI/CD pipelines or DevSecOps dashboards, accelerating mitigation.


Why Java Clone Apps Are Especially Vulnerable

Clone apps often inherit:

  • Outdated codebases
  • Legacy dependencies
  • Minimal refactoring

In many cases, these applications rebrand functionality but retain insecure implementations. TM SGNL reused insecure design patterns while branding itself as a secure communications tool. This mismatch is where attackers thrive.

Meterian’s dependency graph analysis would have:

  • Mapped all third-party Java libraries in use
  • Flagged outdated dependencies
  • Identified insecure hashing libraries

What This Means for Security Leaders

Security isn’t just about patching CVEs. It’s about maintaining visibility and control across all components — including infrastructure, third-party libraries, and code hygiene.

Meterian helps CISOs, developers, and risk managers:

  • Maintain an up-to-date SBOM (using CycloneDX)
  • Integrate continuous monitoring into CI/CD
  • Detect vulnerabilities before they become breaches
  • Proactively secure clone apps before release


Prevention Is Achievable

The TM SGNL breach should not have happened. With continuous scanning, real-time intelligence, and automation-first remediation, it could have been prevented.

Meterian empowers software teams to spot and fix vulnerabilities like these — not weeks after deployment, but during development.

In 2025, security isn’t just a feature. It’s a process. And with Meterian, that process is invisible, continuous, and resilient by design.

The Java Clone Hack That Happened in 20 Minutes — Could It Happen to You?

URGENT AND CRITICAL: REMOTE CODE EXECUTION IN VARIOUS SPRING COMPONENTS NEEDS IMMEDIATE ATTENTION

bbossola, , Leave a comment

Red alert! All enterprise software maintainers of software using Java libraries need to check if their systems are affected by the newly discovered vulnerabilities “Spring4Shell” since its announcement, between 29th and 30th March, 2022, affecting various Spring components.

CVE-2022-22963

Vulnerability Score: 9.5 (CVSS: 3.0 / AV:N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:H)
Platform: Java
Components: org.springframework.cloud:spring-cloud-function-core, org.springframework.cloud:spring-cloud-function-context
Affected versions: 3.1.6, 3.2.2 and older unsupported versions
Fixed in version: 3.1.7, 3.2.3

CVE-2022-22965

Vulnerability Score: 9.5 (CVSS:3.0 / AV: N / AC:L / PR:N / UI:N / S:U / C:H / I:H / A:H)
Platform: Java
Components: org.springframework:spring-beans
Affected versions: all versions before 5.2.20, all versions before 5.3.18 
Fixed in version: 5.2.20, 5.3.18

Please note that this affects also the spring-framework package and the spring-boot package, that both use the offending libraries. New versions of such packages have been made available. You can upgrade spring-framework to version 5.2.20 or 5.3.18, and you can upgrade spring-boot to version 2.5.12 or 2.6.6 (note that spring-boot itself includes spring-framework, no other upgrades necessary).

Which systems does these affect?

CVE-2022-22963 affects any project built using a vulnerable version of Spring Cloud, a framework that provides tools for developers to quickly build some of the common patterns in distributed systems. The “functions” part is a subsystem used to implement serverless functions like AWS lambda or Google Cloud Functions: if you are using such subsystem you are potentially affected.

CVE-2022-22965 affects any project built using a vulnerable version of Spring Framework, Spring Boot or the library spring-beans. A successful attack, however, can only be conducted undere these conditions:

  • JDK 9 or higher is used as the runtime environment
  • Apache Tomcat is used as the Servlet container
  • The application is packaged as a traditional WAR (in contrast to a Spring Boot executable jar)
  • There is a dependency with spring-webmvc or spring-webflux, or an endpoint is used with DataBinder enabled

Please note however that analysis are undergoing and the nature of the vulnerability is quite general: we suggest you keep monitoring this page for further updates.


Why do these threats demand an urgent patch?

Both vulnerabilities allows the attacker to remotely execute code on your system, with the ability to gain complete control of the underlying servers. It’s a simple exploit, as it requires only to send a crafted HTTP header in a request in order to execute code on the remote host. These vulnerabilities are actively exploited in the wild.


How can I check if my system is affected?

If you maintain any software using Java libraries, check if you are using any Spring Cloud Function library. The  Meterian BOSS scanner can be used to scan your codebase to identify all dependent software libraries.  If it is using the offending package, it will find the affected vulnerable versions and provide more information on how to mitigate this risk.

If you are a developer and you have access to the code, you can simply execute this command from your terminal:

CVE-2022-22963:

$ mvn dependency:tree | grep spring-cloud-function | grep compile
[INFO] +- org.springframework.cloud:spring-cloud-function-core:jar:3.1.2:compile

If you see any response lines, check the version: if it’s below 3.1.7 (as in the above example) or, if using 3.2.x, below 3.2.3, you may be affected.

CVE-2022-22965:

$ mvn dependency:tree | grep spring-beans | grep compile
[INFO] +- org.springframework:spring-beans:jar:5.3.11:compile

If you see any response lines, check the version: if it’s below 5.3.18 (as in the above example) or, if using 5.2.x, below 5.2.20, you may be affected.


My system has the vulnerable spring cloud function library — how can I mitigate the risk?

There are now patched versions of the affected components that resolve the issues, they are available via the standard Maven repositories. Upgrade the offending packages using the patched versions, as described in this article.

If the library is coming from a transitive dependency (it’s not one of your direct dependencies, but a dependency of them) you can just include an override in your root pom.xml (or where applicable) and retest that it’s not there anymore with the command shown before.

CVE-2022-22963:

    <dependency>
        <groupId>org.springframework.cloud</groupId>
        <artifactId>spring-cloud-function-core</artifactId>
        <version>3.1.7</version>
    </dependency>

Please be aware that there are multiple packages rooted in "spring-cloud-function": you will need to upgrade all of them, in particular "spring-cloud-function-context" which is also directly affected.

CVE-2022-22965:

    <dependency>
        <groupId>org.springframework</groupId>
        <artifactId>spring-beans</artifactId>
        <version>5.3.18</version>
    </dependency>

Please be aware that you may need / may be better to upgrade the parent pom of the project using an unaffected version of spring boot / spring framework (see at the start of the article).


What can I do to proactively protect from such vulnerabilities?

We always suggest you regularly scan your software code bases. 

  • To do a scan from the command line using the Meterian CLI scanner
  • To include this as part of your continuous improvement efforts to build resilience into your software development lifecycle, see our documentation on the various integrations we support with GitHub Actions, Azure DevOps Pipelines, and others.


Are Meterian applications affected by the spring vulnerability?

We have verified our applications and none are using the offending packages in a vulnerable configuration. We maintain a continuous monitoring system to ensure our development operations are up to date with the latest known vulnerabilities in software components. Given the nature of this vulnerability we will be running a specific monitoring for the following days, while more details are unfolded in regards to those vulnerabilities.   

Related references

CVE-2022-22963

CVE-2022-22965

URGENT AND CRITICAL: REMOTE CODE EXECUTION IN VARIOUS SPRING COMPONENTS NEEDS IMMEDIATE ATTENTION

Urgent and Critical: Remote Code Execution in Apache Log4j needs immediate upgrade

viviandufour, , , , 1 Comment

Updated: 31 Dec 2021

5 minute read

This is a call to arms. All enterprise software maintainers of software using Java libraries need to check if their systems are affected by the newly discovered Apache Log4j vulnerability since its announcement on Dec 9, 2021. Since then several security vulnerabilities in the wild have been discovered.

CVE-2021-44832

Vulnerability Score: 6.6 (CVSS: 3.0 / AV: N / AC: L / PR: N / UI: N / S: C / C: H / I: H / A: H)
Platform: Java
Component: org.apache.logging.log4j:log4j-core
Affected versions: 2.0-alpha7 to 2.17.0 inclusive, except 2.3.2 and 2.12.4.
Fixed in version: 2.17.1

CVE-2021-44228

Vulnerability Score: 10.0 (CVSS: 3.0 / AV: N / AC: L / PR: N / UI: N / S: C / C: H / I: H / A: H)
Platform: Java
Component: org.apache.logging.log4j:log4j-core
Affected versions: all versions before 2.14.1, inclusive
Fixed in version: 2.15.0 but upgrade to 2.17.0 is required because of CVE-2021-45105

CVE-2021-45046

Vulnerability Score: 9.0 (AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H) (updated 18/12/2021)
Platform: Java
Component: org.apache.logging.log4j:log4j-core
Affected versions: all versions up to 2.15.0, excluding 2.12.2
Fixed in version: 2.16.0 but upgrade to 2.17.0 is required because of CVE-2021-45105

CVE-2021-45105

Vulnerability Score: 7.5 (CVSS: 3.0 (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)
Platform: Java
Component: org.apache.logging.log4j:log4j-core
Affected versions: all versions from 2.0-beta9 to 2.16.0, inclusive
Fixed in version: 2.17.0


Which systems does this affect?

Apache Log4j is probably the most common library used for logging in the Java ecosystem with over 400,000 downloads from its GitHub project. It is used in Java applications to log system and user activities, so there’s a serious possibility your Java software is using it. It is used, internally, by many other Apache frameworks such as Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Flink, Apache Kafka, Apache Dubbo. It is also actively used in many other open source projects, like Redis, ElasticSearch, Elastic Logstash, Ghidra and many others.

Among all these open source components, one needs a special mention: Apache Struts. Yes, it is actively using Log4j. There exists a potential to trigger high-impact attacks against a wide variety of apps and services, similar to the scale witnessed in 2017. At that time, due to the vulnerability exploited in the Equifax megahack, 140 million customers’ data in North America and UK were breached. The latest version of Apache Struts, 2.5.28, uses by default Log4j version 2.12.21, which is vulnerable to this attack. This time, however, the scope for damage could be even wider, as Apache Struts is one of many Apache frameworks that use Log4j. 

The Java ecosystem is in very broad use in enterprise systems and web apps and many mainstream services are likely to be vulnerable. Therefore, software maintainers and developers should pay close attention to this vulnerability. 

This has been preliminary filed as CVE-2021-44228, and a subsequent vulnerability was also flagged, now filed under CVE-2021-45046.


Why does this threat demand an urgent patch?

This vulnerability allows the attacker to remotely execute code on your system, with the ability to gain complete control of the underlying servers.

This is actively exploited on the internet now and there is already a simple POC (proof of concept) available on the internet that explains how to do it. 

From https://www.wired.com/story/log4j-flaw-hacking-internet/:

“All an attacker has to do to exploit the flaw is strategically send a malicious code string that eventually gets logged by Log4j version 2.0 or higher. The exploit lets an attacker load arbitrary Java code on a server, allowing them to take control.  […]Minecraft screenshots circulating on forums appear to show players exploiting the vulnerability from the Minecraft chat function. On Friday, some Twitter users began changing their display names to code strings that could trigger the exploit. Another user changed his iPhone name to do the same and submitted the finding to Apple. Researchers told WIRED that the approach could also potentially work using email.”

If you maintain an enterprise system using Java software, you would need to update all affected applications, whether they are maintained directly by your organisation or your supplier organisation.

Within 2 days of the 2017 vulnerability being announced, several systems around the world were breached by exploiting the software weakness.  We do not want more cyber breaches of such scale and all need to react quickly to patch vulnerable systems.


How can I check if my system is affected?

If you maintain any software using Java libraries, check if you are using Apache Log4j.  Meterian BOSS scanner can be used to scan your codebase to identify all dependent software libraries.  If it is using Log4j, it will find the affected vulnerable versions and provide more information on how to mitigate this risk.

If you are a developer and you have access to the code, you can simply execute this command from your terminal:

$ mvn dependency:tree | grep log4j-core | grep compile
[INFO] +- org.apache.logging.log4j:log4j-core:jar:2.12.1:compile

If you see any response lines, check the version: if it’s below 2.16.0 (as in the above example) you may be affected.


My system has the vulnerable log4j library — how can I mitigate the risk?

There is a patched version of the library that resolves the issue.  Released by Apache Software Foundation, the solution is to immediately upgrade log4j to the latest log4j version 2.16.0.  The fixed version is available via Maven. 

If the library is coming from a transitive dependency (it’s not one of your direct dependencies, but a dependency of them) you can just include an override in your root pom.xml (or where applicable) and retest that it’s not there anymore with the command shown before:

    <dependency>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>log4j-core</artifactId>
        <version>2.16.0</version>
    </dependency>

A set of mitigations, specific to the version you are using, are also available on the Apache Log4j website. The Apache Struts team provided specific advice on how to handle the issue.

If you are using an external product that runs with Java, you can also protect your systems by launching the JVM with this special parameter:

-Dlog4j2.formatMsgNoLookups=true

This is useful for tools like Jenkins, where you have control of the installation but you do not have control of the code, but please note that this does not protect against the latest CVE.


What can I do to proactively protect from such vulnerabilities?

We always suggest you regularly scan your software code bases. 


Are Meterian applications affected by the log4j vulnerability?

No. We have verified our applications and none are using log4j.  We maintain a continuous monitoring system to ensure our development operations are up to date with the latest known vulnerabilities in software components.   

Related references

Urgent and Critical: Remote Code Execution in Apache Log4j needs immediate upgrade

Data Protection Day!

viviandufour, , , , , , , , , , , Leave a comment
Image of a screen if the label 'Security' and a cursor hovering on it.
https://www.pexels.com/photo/internet-screen-security-protection-60504/

Yesterday, 28th January was an important day… The Council of Europe celebrated this year the 14th edition of Data Protection Day. 

This practice was to raise awareness about good practices in this field, informing users about their rights and how to exercise them.

This date is aligned to the anniversary of the opening for signature of the Council of Europe’s Convention 108 for the Protection of individuals in relation to automatic processing of personal data. For the past 30 years this has been a cornerstone of data protection, in Europe and around the world.

Why is Data Protection so important?

Data protection issues are very present throughout everyone’s lives. Not to mention in the work environment, in public relations, in the health sector, when buying goods and services, in travel or merely whilst using the internet.

However, not all people are informed on their rights. For this reason, the 28th January has been allocated to inform more users on their rights and so that data protection professionals address data subjects. It is important our digitally advanced society understands what personal data is collected from them and why, as well as what their rights are when their data is processed. This in turn, will help users be aware of the risks which comes with illegal mishandling and unfair processing of personal data.

Meterian can help!

Here are a list of our blogs which can help users be more cyber resilient and diligent when it comes to managing sensitive data.

Read also our past blog posts about vulnerabilities in:

to make sure your apps are not susceptible to such exploits that would risk data confidentiality.

Data Protection Day!

New Java Vulnerabilities!

viviandufour, , , , Leave a comment

4min read

Attention to all Java users! Yes, we are back with a brand new set of Java vulnerabilities that I know you would like to get some juicy info on. During September 2019, two Java vulnerabilities have been discovered within the Apereo CAS versions before 6.1.0-RC5 and the Apache Tapestry versions between 5.4.0 to 5.4.3. The former open source vulnerability has been given a score of 8.1 whilst the later a higher score of 9.8 in regards to severity. So hurry, read up and don’t waste any time. You could be affected!

  • CVE-2019-10754 Apereo CAS (org.apereo.cas:*) components could allow a remote authenticated malicious user to obtain sensitive information, caused by the use of weak RandomStringUtils PRNG algorithm. 
  • CVE-2019-0195 Manipulating classpath asset file URLs, an attacker could guess the path to a known file in the classpath and have it downloaded.

CVE-2019-10754 

Vulnerability Score: 8.1 / HIGH

Platform: Java

Component: org.apereo.cas (Apereo CAS) 

Affected Versions: versions before 6.1.0-RC5

That’s right folks! Java has another vulnerability. Due to multiple classes using Apereo CAS (before the release of 6.1.0-RC5) and making use of apache commons-lang3 RandomStringUtils for token and ID generation, this has made them predictable and resulted in a cryptography weakness.

Apereo CAS is an open well-documented protocol, as well as an open-source Java server component. It provides support for multiple protocols (CAS, SAML, OAuth, OpenID) and is a library for clients such as Java, .NET, PHP, Perl, Apache, uPortal and more! Apereo’s mission is to help educational organizations ‘collaborate to foster, develop, and sustain open technologies and innovation to support learning, teaching and research’.

For example, org.apereo.cas:cas-server-support-simple-mfa is a package that allows Apereo CAS to act as a multifactor authentication provider by itself. This generates tokens and allows them to be sent to end-users via pre-defined communication channels such as email or text message. Please also note that this vulnerability affects multiple components of the Apereo CAS framework. 

So what is the threat? Well, the affected versions of this package are vulnerable to Insecure Randomness, as it relies on apache commons-lang3 RandomStringUtil  which can produce predictable results. So, this could allow an attacker to generate their own unique Ticket ID due to insufficient randomness. In other words, the attacker could guess the encryptionSecret used within GenerateJwtCommand and allow them to impersonate a user. This also means the attacker will have access to sensitive information caused by the use of the weak RandomStringUtils PRNG algorithm. 

Image showing user communicating with the server, and the hacker impersonating the user.

But don’t fret. There is a solution. It has been recommended to upgrade org.apereo.cas to version 6.1.0-RC5 or higher.

Java users, don’t give cyber criminals the chance to access your data. Act fast and upgrade org.apereo.cas! 

CVE-2019-0195

Vulnerability Score: 9.8 / CRITICAL

Platform: Java

Component: org.apache.tapestry (Apache Tapestry)

Affected Versions: versions 5.4.0 to 5.4.3.

We are not done yet folks! We have one more Java vulnerability to inform you guys on. Within the Apache Tapestry versions 5.4.0 to 5.4.3, the manipulating classpath asset file URLs allow an attacker to guess the path of a known file in the classpath and, as a result, download it. This was discovered on the 16/09/19 by Thiago H. de Paula Figueiredo.

The Apache Tapestry is an open-source framework for creating web applications in Java or other JVM languages. It also complements and builds upon standard Java Servlet API and works in any application server. Apache Tapestry has a long history. It has the oldest code, dating all the way back to 2000. This has resulted in many releases; developers now concentrate on Tapestry 5 as opposed to 3 and 4. 

What is tapestry.hmac-passphrase you say? This symbol is used to configure hash-based message authentication of Tapestry data stored in forms, or in the URL. In other words, your application is less secure and therefore more vulnerable to denial-of-service attacks. Especially when this symbol is not configured.

With various techniques, an attacker could guess the path to a known file in the classpath and have it downloaded. If the attacker found the file with the value of the  tapestry.hmac-passphrase configuration symbol, then they could use it to craft a Java deserialization attack, thus running a malicious injected Java code. 

Image showing a hacker guessing a file location, downloading the pass phrase and a computer showing it is has been hacked.

The recommended mitigation for this vulnerability has been suggested to upgrade to Tapestry 5.4.5, which is a drop-in replacement for any 5.4.x version. 

That is it from us…for now! Make sure to spread the word on these critically-rated Java vulnerabilities in order to help the app sec community defend against unwanted exploits. But as you all know, open-source vulnerabilities are discovered daily, so we recommend you regularly scan your code repositories for new known vulnerabilities. Don’t get caught off guard!

Knowing is half the battle. The other half is doing. Let Meterian help your dev team stay in the know and on top of the latest updates to secure your apps continuously.  Sign up here to download the Meterian client today.  You’ll get an instant analysis of your first project for free.  See the risks immediately and know which components to remove or upgrade to secure your app.

New Java Vulnerabilities!

Vulnerability Focus: Command Injection

viviandufour, , , , Leave a comment

5min read

Image of thief climbing out of laptop shining flashlight on ruby, java icons with a syringe, titled Vulnerability Focus: Command Injection

At attention, app sec community! It has been an exciting past couple of weeks, and we have got some juicy vulnerabilities to dish on. From Apache commons to the extensively-used Nokogiri library,  we will shed light on two compelling command injection vulnerabilities that rank highly on the common vulnerability scoring system (CVSS). Read along and spread the word to help combat against open source vulnerabilities.

  • CVE-2019-10086 The SuppressPropertiesBeanIntrospector class in versions before 1.9.4 of BeanUtils in Apache commons was not enabled by default

  • CVE-2019-5477 An inherent flaw in the Ruby Rexical gem v.1.0.6 or earlier, due to improper neutralization of special elements, resulted in a command injection vulnerability in the Nokogiri gem

CVE-2019-10086

Vulnerability Score: High — 7.3 (CVSS v3.0)

Platform: Java

Component: commons-beanutils

Affected versions: 1.9.3 and earlier

Take heed, all you Java programmers: a vulnerability has been located within Apache commons,  a provider of reusable open source Java component. There lies an arbitrary code vulnerability in the BeanUtils component, a set of utilities used for manipulation of JavaBeans code.

Within the BeanUtils component, there are several class types, or PropertyUtils beans, that  support mechanisms for dynamically defining and accessing bean properties (i.e. Bean Introspection) – these sets of utilities that assist in getting and setting property values on Java classes utilise the BeanIntrospector interface for components that can perform introspection on bean classes. 

Class TypeDescription
DefaultBeanIntrospectorThe default BeanIntrospector implementation

FluentPropertyBeanIntrospector		An implementation which detects write methods for properties used in fluent API scenario
SuppressPropertiesBeanIntrospector**A specialized BeanIntrospector implementation which suppresses some properties.

Example of class types and their functions
** highlights affected component in this CVE incident

In the context of this security flaw, the vulnerability originates from the SuppressPropertiesBeanIntrospector class type. This BeanIntrospector class type  is a standard implementation within a BeanUtils component which suppresses the ability for malicious attackers  to circumvent class properties of Java objects to gain access to the classloader. However, this safeguard mechanism against third-party exploitations of Java objects, was not enabled by default for version 1.9.2 – 1.9.3 of BeanUtils. 

This thereby allows attackers to manipulate classloaders and remotely execute arbitrary commands via class parameter, which would be detrimental to application security. Cyber attackers could potentially take advantage of this command injection loophole to inject malignant code into an application system through cross-site scripting (XSS), cross-site request forgery (XSRF), or drive-by attacks – this would then result in security breaches and a whole slew of inconvenience for organizations using  compromised versions of this BeanUtils component.

Affected users would be relieved to know that the fix for this vulnerability, version 1.9.4 of BeanUtils, has since been published. The security patch for apache-commons-beanutils has fixed the security flaw by adding a special BeanIntrospector class; this class type comprehensively suppresses the ability for any third party to access the classloader through the outmanoeuvring of class properties available on all Java objects – we can declare with utmost confidence that the updated BeanUtils bean prohibits all class level property access by default.

At the risk of sounding like a broken record, application systems that are using versions before 1.9.4 of the BeanUtils component ought to migrate to the latest version at the soonest. Don’t say you haven’t been warned!

CVE-2019-5477

Vulnerability Score: Critical — 9.8 (CVSS v3.0)

Platform: Ruby

Components: Rexical, Nokogiri

Affected versions: Rexical: 1.0.6 and earlier, Nokogiri: 1.10.3 and earlier

Mayday. I repeat, Mayday. Ruby users – watch out! A critical open-source security flaw has been located in Nokogiri, an open-source software library used to parse HTML and XML in Ruby. To provide some contextual information about its popularity, Nokogiri is indisputably one of the most downloaded Ruby gems – it has been downloaded over 240 million times from the rubygems.org. This translates into a potentially vast network of compromised users – it would be prudent for affected parties to understand the type of security flaw they are dealing with.

In versions Nokogiri 1.10.3 or earlier, a command injection vulnerability allows attackers to alter dynamically generated content on a web page by inserting HTML code into input mechanisms that lack effective validation constraints. These commands are then executed in a subprocess via the kernel#open method, which renders an application vulnerable to remote code execution due to improper neutralization of special elements used in a command injection.

This is due to the core functionality of the kernel#open method. When instructed with a file path (defaulting with ‘r’) , it treats the script as the name of a file to open using the specified mode; but when the file path starts with a pipe character ‘I’, it interprets it as a shell command and returns an IO class linked to the subprocess.  In the context of this Nokogiri security flaw, these subprocesses are only exposed if the (undocumented) kernel#open method “Nokogiri::CSS:: Tokenizer#load_file” is executed with unvalidated user input in its filename.

This particular vulnerability exposure appears in the codework generated by Rexical gem versions 1.0.6 or earlier. The Rexical gem facilitates the Nokogiri library in generating a lexical scanner code that is used to parse CSS queries. In any case, the app sec community would be reassured to know that  a patch which addresses this key vulnerability has been released as Rexical v1.0.7. And on an equally heartening note, Nokogiri has also performed an upgrade (i.e. Nokogiri v.1.10.4) to implement the latest patch for the Rexical gem in their library.

Now that you are all caught up on these CVEs, we hope this little piece of enlightenment would have made you more aware of the rampantness of open source vulnerabilities!

Knowing is half the battle. The other half is doing. Let Meterian help your dev team stay in the know and on top of the latest updates to secure your apps continuously.  Sign up here to download the Meterian client today.  You’ll get an instant analysis of your first project for free.  See the risks immediately and know which components to remove or upgrade to secure your app.

Vulnerability Focus: Command Injection

Vulnerability Focus: Java

, , , 1 Comment

Attention, fellow AppSec comrades! This blog post shines a spotlight on open source vulnerabilities in the Java universe. In particular, it has come to our awareness that the jackson-databind serialisation library, which parses Java objects to JSON and vice versa, has taken big hits over the past few weeks. To better enlighten our readers, we took an in-depth look into the origins of its (de)serialisation flaws.

  • CVE-2019-12384 A flaw in the serialisation process of FasterXML jackson-databind 2.x before 2.9.9.1  could lead to remote code execution. Read why
  • CVE-2019-14379 Hackers could exploit an invalid object-class for pre-2.9.9.2 versions of jackson-databind to gain remote access and control. Read why

CVE-2019-12384

Vulnerability Score: 5.9

Platform: Java

Component: jackson-databind 

Affected versions: FasterXML jackson-databind 2.x before 2.9.9.1 

Here is an interesting one! An open source vulnerability has been found in Jackson, more specifically in jackson-databind. Jackson is a widely-used Java-based library that supports serialization of Java Objects to JSON to enable objects to travel across a network.

A little befuddled? Think of two machines that speak entirely different mother tongues, and decisively pick up another shared language to enable seamless communication between each other. In this context, the act of translating the additional language stands in for the serialization process, whereby the translation process parses the mother tongue (Java Objects) of first machine (X) to a common language (JSON) that is also understood by the second machine (Y).

The root of this vulnerability is that jackson-databind, under certain conditions, blindly deserializes everything in its path. This then gives rise to exploitation opportunities for malicious third-party attackers to substitute valid object-classes with unvalidated ones. As a result, this then enables these hackers  to send specifically crafted JSON messages which could then lead to privilege escalation issues and arbitrary code execution  (ACE) attacks.

Although patches for this security flaw have been published for various softwares (RedHat, Debian 8 ‘Jessie’),  these solutions are not sustainable fix-alls. The existing solution for this vulnerability is essentially manually blacklisting invalid object-classes that can easily be exploited by third-party attackers. Nonetheless, unvalidated object-classes are popping up like hotcakes, and the maintainers of said blacklist are playing a risky game of whack-a-mole, and it is just too time-consuming to continuously add exploitable classes to a list.

Nonetheless, until a more comprehensive solution has been discovered to effectively combat against these loopholes, you had better perform an update on your jackson-databind library to ensure you are well-protected against the blacklisted attack vectors and such known vulnerabilities!

To find out more about jackson-databind exploits, click here.

CVE-2019-14379

Vulnerability Score: TBD

Component: jackson-databind

Affected versions:  2.x versions before  2.9.9.2 

Here’s another testament to the inefficiency of the blacklist measure to protect users of jackson-databind against arbitrary code execution attacks – another invalid object-class, the SubTypeValidator.java, has yet again appeared on our radar.

As explained under the aforementioned Jackson vulnerability that affected FasterXML jackson-databind versions 2.x (all versions up to 2.9.9), this data-binding library has the potential to deserialize any object-classes in its path under certain conditions. This is a result of default-typing which allows jackson-databind users to  deserialize object-classes without specifying the full possible type hierarchy. And herein the default-typing feature lies the flaw of this open source vulnerability.

In this context, where the security flaw affects the more recent version FasterXML jackson-databind 2.9.9.2, remote code execution could be triggered if a hacker inputs the unsanitized SubTypeValidator.java object-class under the default-typing mechanism, when it is used in conjunction with Ecache (Java’s most widely-used cache).

This could potentially result in security breaches  where hackers are able to send specific and malicious JSON messages resulting in unauthorised root access and control. We strongly advise that you upgrade to version 2.9.9.2 or higher at the soonest!

With jackson-databind being a highly popular serialisation gadget in the DevOps community, such exposures should be effectively nipped in the bud to prevent further compromises to its library, as well as waste of resources rolling out patched updates on every vulnerable version. A frequent user of jackson-databind? What are you waiting for?

Sign up here to download the Meterian client today. You’ll get an instant analysis of your first project for free.  See the risks immediately and know which components to remove or upgrade to secure your app.

Vulnerability Focus: Java