Direkt zum Hauptbereich

Scanning TLS Server Configurations with Burp Suite

In this post, we present our new Burp Suite extension "TLS-Attacker".
Using this extension penetration testers and security researchers can assess the security of TLS server configurations directly from within Burp Suite.
The extension is based on the TLS-Attacker framework and the TLS-Scanner, both of which are developed by the Chair for Network and Data Security.

You can find the latest release of our extension at: https://github.com/RUB-NDS/TLS-Attacker-BurpExtension/releases


Thanks to the seamless integration of the TLS-Scanner into the BurpSuite, the penetration tester only needs to configure a single parameter: the host to be scanned.  After clicking the Scan button, the extension runs the default checks and responds with a report that allows penetration testers to quickly determine potential issues in the server's TLS configuration.  Basic tests check the supported cipher suites and protocol versions.  In addition, several known attacks on TLS are automatically evaluated, including Bleichenbacher's attack, Padding Oracles, and Invalid Curve attacks.

Furthermore, the extension allows fine-tuning for the configuration of the underlying TLS-Scanner.  The two parameters parallelProbes and overallThreads can be used to improve the scan performance (at the cost of increased network load and resource usage).

It is also possible to configure the granularity of the scan using Scan Detail and Danger Level. The level of detail contained in the returned scan report can also be controlled using the Report Detail setting.

Please refer to the GitHub repositories linked above for further details on configuration and usage of TLS-Scanner.

Scan History 

If several hosts are scanned, the Scan History tab keeps track of the preformed scans and is a useful tool when comparing the results of subsequent scans.

Additional functions will follow in later versions

Currently, we are working on integrating an at-a-glance rating mechanism to allow for easily estimating the security of a scanned host's TLS configuration.

This is a combined work of Nurullah Erinola, Nils Engelbertz, David Herring, Juraj Somorovsky, Vladislav Mladenov, and Robert Merget.  The research was supported by the European Commission through the FutureTrust project (grant 700542-Future-Trust-H2020-DS-2015-1).

If you would like to learn more about TLS, Juraj and Robert will give a TLS Training at Ruhrsec on the 27th of May 2019. There are still a few seats left.

Beliebte Posts aus diesem Blog

How To Spoof PDF Signatures

One year ago, we received a contract as a PDF file. It was digitally signed. We looked at the document - ignoring the "certificate is not trusted" warning shown by the viewer - and asked ourselfs:

"How do PDF signatures exactly work?"

We are quite familiar with the security of message formats like XML and JSON. But nobody had an idea, how PDFs really work. So we started our research journey.

Today, we are happy to announce our results. In this blog post, we give an overview how PDF signatures work and on top, we reveal three novel attack classes for spoofing a digitally signed PDF document. We present our evaluation of 22 different PDF viewers and show 21 of them to be vulnerable. We additionally evaluated 8 online validation services and found 6 to be vulnerable.

In cooperation with the BSI-CERT, we contacted all vendors, provided proof-of-concept exploits, and helped them to fix the issues and three generic CVEs for each attack class were issued: CVE-2018-16042

DTD Cheat Sheet

When evaluating the security of XML based services, one should always consider DTD based attack vectors, such as XML External Entities (XXE) as,for example, our previous post XXE in SAML Interfaces demonstrates.

In this post we provide a comprehensive list of different DTD attacks.

The attacks are categorized as follows:
Denial-of-Service AttacksClassic XXEAdvanced XXEServer-Side Requst Forgery (SSRF)XIncludeXSLT

Practical Dictionary Attack on IPsec IKE

We found out that in contrast to public knowledge, the Pre-Shared Key (PSK) authentication method in main mode of IKEv1 is susceptible to offline dictionary attacks. This requires only a single active Man-in-the-Middle attack. Thus, if low entropy passwords are used as PSKs, this can easily be broken.