Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Snyk] Security upgrade com.hazelcast:hazelcast-client from 3.2-RC2-SNAPSHOT to 3.12.11 #16

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

snyk-bot
Copy link

@snyk-bot snyk-bot commented Mar 3, 2022

Snyk has created this PR to fix one or more vulnerable packages in the `maven` dependencies of this project.

Changes included in this PR

  • Changes to the following files to upgrade the vulnerable dependencies to a fixed version:
    • hazelcast-hibernate/pom.xml

Vulnerabilities that will be fixed

With an upgrade:
Severity Priority Score (*) Issue Upgrade Breaking Change Exploit Maturity
medium severity 539/1000
Why? Has a fix available, CVSS 6.5
XML External Entity (XXE) Injection
SNYK-JAVA-COMHAZELCAST-1018909
com.hazelcast:hazelcast-client:
3.2-RC2-SNAPSHOT -> 3.12.11
No No Known Exploit
high severity 619/1000
Why? Has a fix available, CVSS 8.1
Deserialization of Untrusted Data
SNYK-JAVA-COMHAZELCAST-174771
com.hazelcast:hazelcast-client:
3.2-RC2-SNAPSHOT -> 3.12.11
No No Known Exploit
high severity 619/1000
Why? Has a fix available, CVSS 8.1
Deserialization of Untrusted Data
SNYK-JAVA-COMHAZELCAST-174772
com.hazelcast:hazelcast-client:
3.2-RC2-SNAPSHOT -> 3.12.11
No No Known Exploit
critical severity 704/1000
Why? Has a fix available, CVSS 9.8
Deserialization of Untrusted Data
SNYK-JAVA-COMHAZELCAST-1922239
com.hazelcast:hazelcast-client:
3.2-RC2-SNAPSHOT -> 3.12.11
No No Known Exploit

(*) Note that the real score may have changed since the PR was raised.

Check the changes in this PR to ensure they won't cause issues with your project.


Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information:
🧐 View latest project report

🛠 Adjust project settings

📚 Read more about Snyk's upgrade and patch logic


Learn how to fix vulnerabilities with free interactive lessons:

🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

@secureflag-knowledge-base
Copy link

XML Entity Expansion

Click here to find a XML Entity Expansion training lab

Description

XML External Entity Expansion (also referred to as XXE) attacks are used against applications that process XML input by exploiting XML external entity support. By supplying hostile XML input containing a specification of an external entity to a weakly configured XML parser, attackers may be able to view files on the application server filesystem, conduct denial-of-service attacks, and interact with any external or backend systems to which the application has access.

XXE vulnerabilities occur when the widely used XML format (a protocol typically used to transmit data between the browser and the server) contains various potentially dangerous features. Due to the potential severity of XXE attacks and their ongoing prevalence, these attacks make an appearance on the OWASP Top 10 list of web application security risks.

As with many of the vulnerabilities on this list, prevalence would markedly decrease with more comprehensive and continuously updated developer training.

Read more

Impact

XXE attacks can include conducting denial-of-service attacks and disclosing local files containing sensitive data such as passwords or private user data. As the attack occurs relative to the application processing the XML document, it can enable attackers to laterally traverse to other internal systems to potentially stage Server-Side Request Forgery (SSRF) attacks against unprotected internal services.

XML attacks have been understood for almost 20 years, and yet even in recent years, powerhouses like Google and Facebook are known to have faced issues with these types of attacks. This serves as a stark reminder that chaos can occur (and take the form of potentially massive fines) simply due to misconfiguration and poorly implemented code.

Scenarios

The main features of XML that are relevant to understanding XXE vulnerabilities are XML entities and Document Type Definition.

XML entities are a way of representing an item of data within an XML document instead of using the data itself. Entities, such as &lt; and &gt; that represent the characters < and > respectively, are already embedded in the XML language. New entities can be defined using Document Type Definition.

Document Type Definition (DTD) defines the structure of an XML document, and it is usually used for validation. It can be embedded at the start of an XML document by using the optional DOCTYPE element. External DTDs can be loaded from a remote URL.

Denial of Service Attacks

XML entities can be abused to cause denial-of-service attacks by embedding entities within entities within entities, causing the memory of the XML parser to overload. The so-called Billion Laughs attack shown below takes advantage of a Document Type Definition called foo, and an element called bar, replaced, in this case, with the name of a fine security training platform! Anytime &bar; is used, the XML parser replaces it with SecureFlag.

Request

POST http://www.vulnerableapp.com/xml HTTP/1.1

<?xml version="1.0" encoding="ISO-8859-1"?> 
<!DOCTYPE foo [
  <!ELEMENT foo ANY>
  <!ENTITY bar "SecureFlag ">
  <!ENTITY t1 "&bar;&bar;">
  <!ENTITY t2 "&t1;&t1;&t1;&t1;">
  <!ENTITY t3 "&t2;&t2;&t2;&t2;&t2;">
]>
<foo>
  Join &t3;
</foo>

Response

HTTP/1.0 200 OK
 
Join SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlagSecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag SecureFlag

Server-Side Request Forgery Attacks

DTDs and XML external entities can also be leveraged to trick an application into retrieving files on the system.

Request

POST http://www.vulnerableapp.com/xml HTTP/1.1

<?xml version="1.0" encoding="ISO-8859-1"?> 
<!DOCTYPE foo [
  <!ELEMENT foo ANY>
  <!ENTITY xxe SYSTEM
  "file:///etc/passwd">
]>
<foo>
  &xxe;
</foo>

Response

HTTP/1.0 200 OK
 
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh 
bin:x:2:2:bin:/bin:/bin/sh
sys:x:3:3:sys:/dev:/bin/sh 
(...)

An attacker could perform a Server-Side Request Forgery attack, pointing the URI to an external resource, such as an HTTP location. This, in turn, can be used to pivot and interact with any external or backend systems to which the application has access.

Request

POST http://www.vulnerableapp.com/xml HTTP/1.1

<?xml version="1.0" encoding="ISO-8859-1"?> 
<!DOCTYPE foo [
  <!ELEMENT foo ANY>
  <!ENTITY xxe SYSTEM
  "http://internal.vulnerableapp.com:8443">
]>
<foo>
  &xxe;
</foo>

Response

HTTP/1.0 200 OK
 
(.. result of the request to http://internal.vulnerableapp.com:8443 ...)

Prevention

Disabling the Document Type Definitions (DTDs) function will effectively prevent most attacks.

When possible, handling data using simpler formats like JSON is recommended. For almost a decade, JSON has been seen as preferable to the use of XML due to its lightweight syntax and newer construction.

Of course, exceptions exist to prove rules, and in cases where it is absolutely not possible to switch off DTDs within the business parameters nor use another format, the following measures must be applied by developers.

When the entire XML document is transmitted from an untrusted client, it's not usually possible to selectively validate or escape tainted data within the system identifier in the DTD. Therefore, the XML processor should be configured to use a local static DTD and disallow any declared DTD included in the XML document.

Testing

Verify that the application correctly restricts XML parsers to only use the most restrictive configuration possible and to ensure that unsafe features, such as resolving external entities, are disabled to prevent XML External Entity (XXE) attacks.

View this in the SecureFlag Knowledge Base

@secure-code-warrior-for-github

Micro-Learning Topic: External entity injection (Detected by phrase)

Matched on "XXE"

What is this? (2min video)

An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, server-side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts.

Try this challenge in Secure Code Warrior

Micro-Learning Topic: Deserialization of untrusted data (Detected by phrase)

Matched on "Deserialization of Untrusted Data"

What is this? (2min video)

It is often convenient to serialize objects for communication or to save them for later use. However, serialized data or code can be modified. This malformed data or unexpected data could be used to abuse application logic, deny service, or execute arbitrary code when deserialized. This is usually done with "gadget chains

Try this challenge in Secure Code Warrior

@secure-code-warrior-for-github

Micro-Learning Topic: XML injection (Detected by phrase)

Matched on "XML Injection"

What is this? (2min video)

XML injection is a vulnerability affecting the handling of XML documents used by an application. If an application uses unsafe inputs as part of an XML document, it may result in corrupted XML that changes the behaviour of application components that use the modified document. Where XML documents are accepted by an application, it may allow information disclosure, denial of service or unauthorised file access if certain XML processing is permitted.

Try this challenge in Secure Code Warrior

Micro-Learning Topic: Denial of service (Detected by phrase)

Matched on "denial-of-service"

The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others. Source: https://www.owasp.org/index.php/Denial_of_Service

Try this challenge in Secure Code Warrior

Micro-Learning Topic: Server-side request forgery (Detected by phrase)

Matched on "Server-Side Request Forgery"

What is this? (2min video)

Server-Side Request Forgery (SSRF) vulnerabilities are caused when an attacker can supply or modify a URL that reads or sends data to the server. The attacker can create a malicious request with a manipulated URL, when this request reaches the server, the server-side code executes the exploit URL causing the attacker to be able to read data from services that shouldn't be exposed.

Try this challenge in Secure Code Warrior

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant