No abstract

Encrypted key transport with RSA-PKCS#1 v1.5 is the most commonly deployed key exchange method in all current versions of the Transport Layer Security (TLS) protocol, including the most recent version 1.2. However, it has several well-known issues, most importantly that it does not provide forward secrecy, and that it is prone to side channel attacks that may enable an attacker to learn the session key used for a TLS session. A long history of attacks shows that RSA-PKCS#1 v1.5 is extremely difficult to implement securely. The current draft of TLS version 1.3 dispenses with this encrypted key transport method. But is this sufficient to protect against weaknesses in RSA-PKCS#1 v1.5? We describe attacks which transfer the potential weakness of prior TLS versions to two recently proposed protocols that do not even support PKCS#1 v1.5 encryption, namely Google's QUIC protocol and TLS 1.3. These attacks enable an attacker to impersonate a server by using a vulnerable TLS-RSA server implementation as a "signing oracle" to compute valid signatures for messages chosen by the attacker. The first attack (on TLS 1.3) requires a very fast "Bleichenbacheroracle" to create the TLS CertificateVerify message before the client drops the connection. Even though this limits the practical impact of this attack, it demonstrates that simply removing a legacy algorithm from a standard is not necessarily sufficient to protect against its weaknesses. The second attack on Google's QUIC protocol is much more practical. It can also be applied in settings where forging a signature with the help of a "Bleichenbacher-oracle" may take an extremely long time. This is because signed values in QUIC are independent of the client's connection request. Therefore the attacker is able to pre-compute the signature long before the client starts a connection. This makes the attack practical. Moreover, the impact on QUIC is much more dramatic, because creating a single forged signature is essentially equivalent to retrieving the long-term secret key of the server.

No abstract

XML-based SOAP Web Services are a widely used technology, which allows the users to execute remote operations and transport arbitrary data. It is currently adapted in Service Oriented Architectures, cloud interfaces, management of federated identities, eGovernment, or millitary services. The wide adoption of this technology has resulted in an emergence of numerous-mostly complex-extension specifications. Naturally, this has been followed by a rise in large number of Web Services attacks. They range from specific Denial of Service attacks to attacks breaking interfaces of cloud providers [1], [2] or confidentiality of encrypted messages [3]. By implementing common web applications, the developers evaluate the security of their systems by applying different penetration testing tools. However, in comparison to the wellknown attacks as SQL injection or Cross Site Scripting, there exist no penetration testing tools for Web Services specific attacks. This was the motivation for developing the first automated penetration testing tool for Web Services called WS-Attacker. In this paper we give an overview of our design decisions and provide evaluation of four Web Services frameworks and their resistance against WS-Addressing spoofing and SOAPAction spoofing attacks.

No abstract

SOAP-based Web services is a middleware technology marketed as the solution to easy data exchange between heterogeneous IT architectures. The large number of scenarios, in which this technology is used, has introduced demands for new extensions raising its complexity. However, this has also introduced a large variety of new attacks. In this paper, we investigate an automatic evaluation of Web service specific Denial of Service (DoS) attacks. We present a new fully automated plugin for the WS-Attacker penetration testing tool implementing major DoS attacks. Our tool determines the attack success without having physical access to the target machine, using a novel blackbox approach. We give an overview of our design decisions and present the evaluation results using common Web service frameworks and systems.

XML Encryption was standardized by W3C in 2002, and is implemented in XML frameworks of major commercial and open-source organizations like Apache, redhat, IBM, and Microsoft. It is employed in a large number of major webbased applications, ranging from business communications, e-commerce, and financial services over healthcare applications to governmental and military infrastructures.In this work we describe a practical attack on XML Encryption, which allows to decrypt a ciphertext by sending related ciphertexts to a Web Service and evaluating the server response. We show that an adversary can decrypt a ciphertext by performing only 14 requests per plaintext byte on average. This poses a serious and truly practical security threat on all currently used implementations of XML Encryption.In a sense the attack can be seen as a generalization of padding oracle attacks (Vaudenay, Eurocrypt 2002). It exploits a subtle correlation between the block cipher mode of operation, the character encoding of encrypted text, and the response behaviour of a Web Service if an XML message cannot be parsed correctly.

No abstract