Weakness in Java TLS Host Verification

Unicode-related vulnerabilities have seen an increase in momentum in the past year. Last year, a Black Hat presentation by Jonathan Birch detailed how character normalization NFC/NFKC can lead to glitches in URL and host manipulation. Recently, two vulnerabilities were found in password reset functionality. The two affected applications were Django and Github. In the previous blog post, we have presented API transforming code points with potential side effects. In this post, we present one of our findings: a vulnerability affecting Oracle JDK and Open JDK host verification in the TLS communication. We are also including details from a similar weakness in Apache HTTP client.

ESI Injection Part 2: Abusing specific implementations

Last year, we published a blog post about the injection of ESI tags in pages to fool the web cache proxy, and in August 2018, our colleague Louis Dion-Marcil spoke at Defcon about the discovery of the ESI Injection uncovered by the GoSecure intrusion testing team. For those interested, the presentation has been released on the Defcon YouTube channel. Defcon and Black Hat gave us an opportunity to unveil how ESI implementations can lead to session leakage through the client web browser without any malicious JavaScript. ESI is a specification that defines statements in the form of XML tags that are interpreted by the caching server. Those statements describe the content assembly of web pages by composing various HTML fragments from external resources. An attacker can abuse this mechanism by injecting a malicious tag inside an intercepted web page.

Beware of the Magic SpEL(L) – Part 2 (CVE-2018-1260)

On Tuesday, we released the details of RCE vulnerability affecting Spring Data (CVE-2018-1273). We are now repeating the same exercise for a similar RCE vulnerability in Spring Security OAuth2 (CVE-2018-1260). We are going to present the attack vector, its discovery method and the conditions required for exploitation. This vulnerability also has similarities with another vulnerability disclosed in 2016. The resemblance will be discussed in the section where we review the fix.

Beware of the Magic SpEL(L) - Part 1 (CVE-2018-1273)

This February, we ran a Find Security Bugs scan on over at least one hundred components from the Spring Framework, including the core components (spring-core, spring-mvc) but also optional components (spring-data, spring-social, spring-oauth, etc.). From this exercise, we reported some vulnerabilities. In this blog post, we are going to give more details on a SpEL injection vulnerability. While some proof of concept code and exploitation details have already surfaced on Twitter, we will add a focus on how these vulnerabilities were found, followed by a thorough review of the proposed fix.

Detecting deserialization bugs with DNS exfiltration

At the moment, Java deserialization vulnerabilities are becoming well known by vendors and attackers. Nevertheless, pentesters will still encounter these types of vulnerabilities. The low-hanging fruits can be identified with the current tools. Most of the available tools rely on the command execution API. However, the command from the payload may fail because of Operating System specific conditions. Additionally, the command used might be missing or the arguments it requires may differ due to the version of the command or the flavor installed (ie: GNU netcat vs OpenBSD netcat for example).

Due to the above-mentioned limitations of executing commands, detecting these bugs requires some trial and error. Having to send multiple payloads per target makes automation harder. Crafting a universal payload would simplify large scale detection of deserialization bugs. Before introducing our scanning approach, let's define a set of objectives for a more reliable payload.

Deserialization Vulnerability : Automating the hunt

At the end of 2015, many Java applications were found vulnerable to a common deserialization bug. It all starts with a presentation at AppSecCali that demonstrate the danger of deserializing user input and having Apache Commons Collections in the classpath ^[1]. Stephen Breen from Foxglove later publish vulnerabilities with working exploits for WebLogic, WebSphere, JBoss and Jenkins.

This is obviously not the end of the story. While some big names where fixed, other applications open source and proprietary are likely to be vulnerable to the same bug pattern. In fact quickly after Foxglove publication, an advisory was release for ActiveMQ.

Stephen has already described in great detail the detection and exploitation in the context of penetration test. I wanted to provide a small method for scanning proprietary applications looking only at the jar files.

Object deserialisation ^(*)

crossdomain.xml : Beware of Wildcards

This blog entry will describe a wide spread Flash vulnerability that affected many big websites including paypal.com. The description will picture the state of the website paypal.com and ebay.com in 2013-2014. The vulnerabilities were completely fixed two weeks ago. Therefore, it is not possible to reproduce this vulnerability as-is.

TL;DR : See the video demonstration.

Identifying Xml eXternal Entity vulnerability (XXE)

Here is a small writeup on how a XXE was discover on the website RunKeeper.com. The website, as the name suggest, keep track of your trainings (running, cycling, skying, etc.) The vulnerabilities presented were fixed on June 10th 2014.

The website accept the upload of GPX file. The GPX file format is a XML document containing a list of positions with the instant speed, time and elevation.

Jira Path Traversal explained (CVE-2014-2314)

A new advisory has been published about a path traversal vulnerability affecting Jira 5.0.11 and 6.0.3. The vulnerability was corrected in July of last year and the fixes were deployed in the following months.

The attack is quite simple but, the potential impact is considerable. It could allow a attacker to upload a file that would serve as a webshell. I will explain how it was found by static analysis and why a little detail made it exploitable only on Windows operating system.

ESAPI : When authenticated encryption goes wrong (CVE-2013-5960 / CVE-2013-5979)

(Note: This post was revert to draft until 3rd september to avoid unnecessary pressure on the ESAPI developpers.)

ESAPI is a community project part of OWASP. The project scope is kind of wide. It include functionality for authentication, validation, encoding/escaping, cryptography, etc.
I had to analyze the use of ESAPI cryptography component for my organisation. This post will detail the discovery of a vulnerability in the symmetric encryption API. Keep in mind that the observations refer to the Java implementation specifically.