Common use of Vulnerabilities Clause in Contracts

Vulnerabilities. Figure 6 shows an overview of the vulnerabilities and how often we encountered them among the 80 surveyed banks. Each vulnerability is discussed briefly. At the end of 2014, a successful attack was made against SSL 3.0 and TLS 1.0 when block ciphers are used. An adversary manipulates a user’s browser to send requests to a site using SSL/TLS where the user is logged in. Important information can be derived by observing the cipher text, such as session cookies that can be used to hijack sessions. This attack was named POODLE [Mo¨ller et al. 2014; Xxxxxxx 2014]*. Vulnerabilities to POODLE are only noted for 2015 since the attack was not yet known in 2013. For SSL 3.0, the only way to protect against POODLE is by disabling cipher suites that use block ciphers. POODLE also works with some web servers that implement padding in TLS 1.0 incorrectly, which updates to the web server software might be able to solve. Figure 6 shows the number of banks that are vulnerable to POODLE with either SSL 3.0 or TLS. Five banks overlap, and are vulnerable to POODLE attacks with both protocol versions. Therefore, 30 out of 80 banks in our survey are vulnerable to POODLE attacks. Within the SSL/TLS protocol suite (up to versions 3.0/1.0, respectively), one method to encrypt data is with block ciphers used in Cipher-Block Chaining (CBC) mode. The SSL/TLS standard mandates that chained Initialization Vectors (IVs) are used with CBC mode encryption. With chained initialization vectors, the last block of the previous ciphertext is used as an IV for the next message. This presents a vulnerability that can be exploited using a Blockwise Chosen-Boundary Attack (BCBA) [Xxxxx and Xxxxx 2011]*. A BCBA applied on a HTTPS session is known as a BEAST attack [National Institute of Standards and Technology 2011]*. BEAST can be mitigated by letting servers only allow connections exclusively using TLS 1.1 or 1.2. Figure 6 shows that between 2013 and 2015 the number of banks that are vulnerable to BEAST attacks has increased. An explanation for this is that banks that became vulnerable at one point in time stopped supporting RC4, the only streaming cipher supported by SSL/TLS, since it is vulnerable to attacks [AlFardan et al. 2013]. The only alternative without disabling support for the older SSL 3.0 and TLS 1.0 protocol versions were cipher suites that applied CBC, and by implementing those the relevant banks became vulnerable to BEAST. This is likely seen as the preferable alternative, since the BEAST attack ACM Computing Surveys, Vol. 49, No. 4, Article 61, Publication date: December 2016. A Survey of Authentication and Communications Security in Online Banking 61:23 − can be mitigated by browsers by implementing 1/n 1 record splitting as a workaround [Xxxxxxx 2012; Xxxxxx 2013]*. If an attacker can observe network traffic and manipulate a victim’s browser to sub- mit requests to a target site, it is possible to retrieve data from the TLS stream when DEFLATE compression is used. An attacker can steal session cookies with CRIME, which makes it possible to hijack a session [Ristic 2012]*. While this attack is easier to execute compared to BEAST, it is also easier to defend against by disabling TLS com- pression. This can be done server- or client-side. The vulnerability is only exploitable when both server and client support and use TLS compression when a session is es- tablished. In 2013 only seven banks supported TLS compression, which after 2 years was reduced to four banks. SSL/TLS renegotiation makes it possible to use the same data session over multiple connections. Originally, the SSL and TLS protocols did not consider that different parties can use the same data session due to renegotiation, where one party has control of the connection before renegotiation, and the other afterwards. This allows a man- in-the-middle to inject plain text in an established session with a web server before the web server is reconnected with the user’s browser through renegotiation [Ristic 2009]*. As a response, some sites disabled the renegotiation feature [Ristic 2010]*, while others implemented an extension which fixed the problem [Rescorla et al. 2010]*. Renegotiating is cryptographically protected when both the server and the browser support the extension, thereby preventing the same data session to be shared between an end-user and a man-in-the-middle. Half of the banks that were vulnerable in 2013 fixed the issue in the following 2 years. SSL/TLS supports a number of cipher suites with different key sizes to support the confidentiality and integrity of an established session. Some of these cipher suites are merely meant for testing and unlike regular cipher suites, they do not offer either authenticity of the server’s identity (such as with anonymous (Elliptic curve) Xxxxxx- Xxxxxxx) or encryption, due to the lack of required algorithms in the suite. To prevent this, insecure cipher suites should be disabled. Only two sites from our survey sup- ported insecure ciphers in 2013, which have since then fixed this issue. The SSL Server Test from Qualys designates all cipher suites that are less than 112 bits as “weak.” If the assumption is made that data has to stay confidential and its integrity safeguarded against eavesdroppers for the period “2031 and Beyond,” a minimum of 128 bits conforms with recommendations by NIST [Xxxxxx et al. 2012]*. This is why any applied cipher suite with a symmetrical key length of less than 128 bits is considered vulnerable. However, there are a large number of sites that deploy cipher suites of which the shortest key length is 112 bits. These sites are noted separately in Figure 6 to distinguish sites that slightly deviate from NIST recommendations (less than 128 bits but at least 112 bits) and those which deviate significantly (less than 112 bits, i.e., 40 or 56 bits). Not much has changed since 2013. The most significant change was a moderate reduction in banks that supported very weak ciphers (from 17 to 10 banks). These banks disabled the weaker cipher suites in their web server configurations, forcing clients to use the stronger alternatives. Support for SSL 2.0 (with cipher suites enabled) or SSL 3.0 is considered a vulner- ability. SSL 2.0 has a number of flaws that were already acknowledged by Xxxxxxxxx et al. [2002]. These are the use of the same cryptographic keys for message authenti- cation and for encryption (which makes the security of Message Authentication Codes (MACs) unnecessarily weak when encryption key size is limited due to export restric- tions), the sole dependence on MD5 as a vulnerable hash function to construct MACs, the lack of handshake protection, and the possibility to truncate a connection due to relying on the closure of the TCP connection. SSL 3.0 is also considered insecure since all available cipher suites for that protocol version are vulnerable. Cipher suites using ACM Computing Surveys, Vol. 49, No. 4, Article 61, Publication date: December 2016.