CTF: FluxFingers4Future - Evil Corp Solution

For this years hack.lu CTF I felt like creating a challenge. Since I work a lot with TLS it was only natural for me to create a TLS challenge. I was informed that TLS challenges are quite uncommon but nevertheless I thought it would be nice to spice the competition up with something "unusual". The challenge mostly requires you to know a lot of details on how the TLS record layer and the key derivation works. The challenge was only solved by one team (0ops from China) during the CTF. Good job!

PDFex: Major Security Flaws in PDF Encryption

After investigating the security of PDF signatures, we had a deeper look at PDF encryption. In co­ope­ra­ti­on with our friends from Müns­ter Uni­ver­si­ty of Ap­p­lied Sci­en­ces, we discovered severe weaknesses in the PDF encryption standard which lead to full plaintext exfiltration in an active-attacker scenario.

To guarantee confidentiality, PDF files can be encrypted. This enables the secure transfer and storing of sensitive documents without any further protection mechanisms.

The key management between the sender and recipient may be password based (the recipient must know the password used by the sender, or it must be transferred to them through a secure channel) or public key based (i.e., the sender knows the X.509 certificate of the recipient).

In this research, we analyze the security of encrypted PDF files and show how an attacker can exfiltrate the content without having the corresponding keys.

Testing SAML Endpoints for XML Signature Wrapping Vulnerabilities

A lot can go wrong when validating SAML messages. When auditing SAML endpoints, it's important to look out for vulnerabilities in the signature validation logic. XML Signature Wrapping (XSW) against SAML is an attack where manipulated SAML message is submitted in an attempt to make the endpoint validate the signed parts of the message -- which were correctly validated -- while processing a different attacker-generated part of the message as a way to extract the authentication statements. Because the attacker can arbitrarily forge SAML assertions which are accepted as valid by the vulnerable endpoint, the impact can be severe. [1,2,3]

Testing for XSW vulnerabilities in SAML endpoints can be a tedious process, as the auditor needs to not only know the details of the various XSW techniques, but also must handle a multitude of repetitive copy-and-paste tasks and apply the appropriate encoding onto each message. The latest revision of the XSW-Attacker module in our BurpSuite extension EsPReSSo helps to make this testing process easier, and even comes with a semi-automated mode. Read on to learn more about the new release! 

Probing for XML Encryption Weaknesses in SAML with EsPReSSO

Security Assertion Markup Language (SAML) is an XML-based standard commonly used in Web Single Sign-On (SSO) [1]. In SAML, the confidentiality of transferred authentication statements against intermediaries can be provided using XML Encryption [2]. However, implementing XML Encryption in a secure way can be tricky and several attacks on XML Encryption have been identified in the past [3] [4]. Therefore, when auditing a SAML endpoint, one should always consider testing for vulnerabilities in the XML Encryption implementation.

This blog post introduces our latest addition to the SAML Attacker of our BurpSuite extension EsPReSSO: the Encryption Attack tab. The new tab allows for easy manipulation of the encrypted parts within intercepted SAML responses and can, therefore, be used to quickly assess whether the SAML endpoint is vulnerable against certain XML Encryption attacks.

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

Why Receipt Notifications increase Security in Signal

This blog post is aimed to express and explain my surprise about Signal being more secure than I thought (due to receipt acknowledgments). I hope you find it interesting, too.

Signal, and especially its state update protocol, the Double Ratchet algorithm, are widely known for significantly increasing security for instant messaging. While most users first see the end-to-end security induced by employing Signal in messaging apps, the properties achieved due to ratcheting go far beyond protecting communication against (active) attackers on the wire. Due to updating the local device secrets via the Double Ratchet algorithm, the protocol ensures that attackers, who temporarily obtain a device's local storage (on which Signal runs), only compromise confidentiality of parts of the communications with this device. Thus, the leakage of local secrets from a device only affects security of a short frame of communication. The exact duration of compromise depends on the messaging pattern among the communicating parties (i.e., who sends and receives when), as the state update is conducted during the sending and receiving of payload messages.

Scanning for Padding Oracles

As you might have heard, we recently got our paper on padding oracle attacks accepted to the USENIX Security Conference. In this paper, we describe and evaluate a scanning methodology with which we found several padding oracle vulnerabilities in devices from various vendors. In total, we found that 1.83% of the Alexa Top 1 Million have padding oracle vulnerabilities.

Playing with TLS-Attacker

In the last two years, we changed the TLS-Attacker Project quite a lot but kept silent about most changes we implemented. Since we do not have so much time to keep up with the documentation (we are researchers and not developers in the end), we thought about creating a small series on some of our recent changes to the project on this blog.

We hope this gives you an idea on how to use the most recent version (TLS-Attacker 2.8). If you feel like you found a bug, don't hesitate to contact me via GitHub/Mail/Twitter. This post assumes that you have some idea what this is all about. If you have no idea, checkout the original paper from Juraj or our project on GitHub.

TLDR: TLS-Attacker is a framework which allows you to send arbitrary protocol flows.

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, CVE-2018-18688, CVE-2018-18689.