POODLE

(Padding Oracle On Downgraded Legacy Encryption)

Release Date  : 14^th October, 2014

CVE No.           : CVE-2014-3566

Attack on        : SSL v3.0

Type                : Protocol Flaw

Impact            : Can steal “secure” HTTP cookies or other bearer tokens such                                                as HTTP Authorization header contents.

SSL 3.0 is an obsolete and insecure protocol. SSL 3.0 has been replaced by its successors TLS 1.0, TLS 1.1, and TLS 1.2, but TLS implementations remain backwards compatible with SSL 3.0 to inter-operate with legacy systems in the interest of a smooth user experience. The SSL handshake method provides facilities for authenticated version negotiation, so normally the latest protocol version common to the client and the server will be used. However, even if a client and server both support a version of TLS, the security level offered by SSL 3.0 is still relevant since many clients implement a protocol downgrade dance to work around server-side inter-operability bugs.

The POODLE attack takes advantage of the protocol version negotiation feature built into SSL/TLS to force the use of SSL 3.0 and then leverages this new vulnerability to decrypt select content within the SSL session. The decryption is done byte by byte and will generate a large number of connections between the client and server.

To work with legacy servers, many TLS clients implement a downgrade dance: in a first handshake attempt, offer the highest protocol version supported by the client; if this handshake fails, retry (possibly repeatedly) with earlier protocol versions. Unlike proper protocol version negotiation (if the client offers TLS 1.2, the server may respond with, say, TLS 1.0), this downgrade can also be triggered by network glitches, or by active attackers. So if an attacker that controls the network between the client and the server interferes with any attempted handshake offering TLS 1.0 or later, such clients will readily confine themselves to SSL 3.0.

In the web setting, this SSL 3.0 weakness can be exploited by a man in the middle attacker to decrypt “secure” HTTP cookies, using techniques from the BEAST attack. To launch the POODLE attack, run a JavaScript agent on http://example.com (Evil site) to get the victim’s browser to send cookie bearing HTTPS requests to https://example.com, and intercept and modify the SSL records sent by the browser in such a way that there’s a non-negligible chance that example.com will accept the modified record. If the modified record is accepted, the attacker can decrypt one byte of the cookies.

The attacker controls both the request path and the request body, and thus can induce requests such that the following two conditions hold:

● The padding fills an entire block.

● The cookies’ first as of yet unknown byte appears as the final byte in an earlier block.

Recommendations:

• The attack described above requires an SSL 3.0 connection to be established, so disabling the SSL 3.0 protocol in the client or in the server (or both) will completely avoid it.
• Disabling SSL 3.0 entirely right away may not be practical if it is needed occasionally to work with legacy systems. So, it is advisable to implement TLS_FALLBACK_SCSV on browser and server, which will make downgrade attacks impossible.

A10 Unvalidated Redirects and Forwards

If a user is redirected or forwarded to a page defined by an unverified entry, the target URL can be manipulated by an attacker. This attack is used to redirect a user to a malicious website through a website with a trusted domain name or to access an unauthorized internal page.

Impact on Security:

• Attack on Confidentiality
• Attack on Integrity
• Attack on Availability

Detectability   : Easy

Exploitability  : Average

Impact           : Moderate

Possible Mitigation:

1. Avoid using redirects and forwards.
2. Don’t involve user parameters in calculating the destination.
3. If destination parameters can’t be avoided, ensure that the supplied value is valid, and authorized for the user. IT is recommended that any such destination parameters be a mapping value, rather than the actual URL or portion of the URL, and that server side code translate this mapping to the target URL.
4. Create a whitelist of allowed pages or external sites (blacklists should not be used).

A9 Using Components with Known Vulnerabilities

There are a lots of vulnerabilities discovered everyday and that is a major reason every software gives a patch/updates. Known software vulnerabilities are available to everyone on the Internet. If an attacker knows which components you use, he can retrieve these vulnerabilities and find a way to exploit them.

Impact on Security:

• Attack on Confidentiality
• Attack on Integrity
• Attack on Availability

Detectability    : Difficult

Exploitability   : Average

Impact            : Moderate

Possible Mitigation:

1. Identify all components and the version you are using including all dependencies.
2. Monitor the security of these components in public database, project mailing lists, and security mailing lists, and keep them up to date.
3. Where appropriate, consider adding security wrappers around components to disable unused functionality and/or secure weak or vulnerable aspects of the component.

A8 Cross-Site Request Forgery (CSRF)

CSRF exploits the trust that a site has in a user’s browser.  i.e. In CSRF, attacker creates a forged HTTP request and sends it to the victim’s browser by any means and force user to click on that link. If victim clicks that link, server considers it as a legitimate request and serves that request.

Impact on Security:

• Attack on Integrity

Detectability   : Easy

Exploitability  : Average

Impact           : Moderate

Possible Mitigation:

1. Include hte unique token in a hidden field. Prefer to include it in the body of HTTP request instead of including it in URL.
2. Use CSRF Guard or ESAPI.
3. Use CAPTCHA to prove they are user.

A7 Missing Function Level Access Control

In a web application with different user roles, authentication is not enough. Each request must be controlled against user's role to ensure the user is authorized to use the requested function or access the requested page.

Possible Attacks:

• Privilege Escalation
• Directory Browising

Impact on Security:

• Attack on Confidentiality
• Attack on Integrity
• Attack on Availability

Exploitability   : Easy

Detectability   : Average

Impact            : Moderate

Possible Mitigation:

1. Deny all access by default. Check if user has permission to access then allow.
2. If the function is invoked in a workflow, check to make sure the conditions are in the proper state to allow access.
3. The enforcement mechanism should deny all access by default, requiring explicit grants to specific roles for access to every function.