pavel's blog

Understanding DTLS Usage in VoIP Communications

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.

Client-side TLS Implementation Assessment with Qsslcaudit - The WPS Office Case

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.


CVE-2020-0601: theory and practice

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.

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.


qsslcaudit release v0.6.0

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

The single huge feature added: support of assessing DTLS clients.

qsslcaudit release v0.4.0

Our tool designed to assess TLS clients security (certificates validation, protocols and ciphers support) got several updates and achieved version v0.4.0.

TLS clients are now analyzed more precisely, summary table is now colored, few bugs were fixed.

Give it a try. Github's issue tracker is at your service.

qsslcaudit repository

Subscribe to RSS - pavel's blog