Defeating cipher padding attacks on individually encrypted inputs

The Lucky 13 attack exploits flaws in SSL/TLS implementations of CBC encryption. Classified as a “padding oracle” attack, Lucky 13 analyzes errors returned by the server (its “oracle”) after submitting incorrect “padding”—empty bytes that are added to plain text to make its length uniform before encryption is applied. Padding is required by all block ciphers. Once the attacker guesses the correct padding, the resulting encrypted messages have a similar pattern. Attackers can analyze many packets to find the pattern, and thereby decrypt the data for a Man in the Middle (MITM) attack.

This attack involves some brute force: the attacker must guess repeatedly until the server does not return an error, indicating that the correct padding has been discovered. As such, padding attacks may not have been feasible 10 years ago. However as broadband connections and powerful computers become pervasive, this kind of attack has become practical.

Not all web applications use HTTPS, however. Cryptography generally decreases performance. To improve performance while attempting to protect sensitive data, some web applications selectively encrypt above the application level. They encrypt only specific inputs and outputs, such as:

• session IDs
• cookies
• user profile URLs
• passwords

But if the custom functions to encrypt these inputs use the same principle as CBC, or are not well tested or promptly updated for security, they too are vulnerable to padding attacks.

For example, if only a user ID is encrypted, an attacker may want to decrypt it so that he or she can follow with a session hijacking attack. The attacker’s initial request might look like this:

GET /profile.jsp?UID=0000000000000001F851D6CC68FC9537...

The UID is a guess. Unless he or she is extremely lucky, the attacker did not use the correct key nor padding (e.g. 0x01). Therefore the application would reply with an error response such as:

500 Internal Server Error

But if the attacker increases or decreases the padding byte (e.g. 0x02), sends the request again, and repeats this process, the attacker would eventually guess the correct padding, resulting in a message from the server that indicates a correct padding byte:

200 OK

Repeating the above process with previous padding bytes would eventually yield the full, correct padding, and therefore also the length of the plain text. With that, the attacker would eventually be able to decrypt the entire UID. The attacker could then attempt to hijack the login.

To enable padding oracle protection

Before you can begin configuring to protect against padding oracle attacks, you have to enable it first.

1. Go to System > Config > Feature Visibility.
   To access this part of the web UI, your administrator's account access profile must have Read and Write permission to items in the System Configuration category. For details, see "Permissions" on page 1.
2. Locate Security Features.
3. Enable Padding Oracle Protection.
4. Click Apply.

To protect against padding oracle attacks

1. Consult with your application developer to find inputs that are individually encrypted.

Do not configure padding oracle attack prevention unless the URL, cookie or parameter is encrypted. Only encrypted inputs or URLs, especially those encrypted using CBC, ECB, or OAEP, are vulnerable. Unnecessary protection will decrease FortiWeb performance.

2. Go to Web Protection > Advanced Protection > Padding Oracle Protection.
3. Click Create New, then configure these settings:

Name	Type a unique name that can be referenced in other parts of the configuration. The maximum length is 63 characters.
Action	Select which action the FortiWeb appliance will take when it detects a violation of the rule: Alert—Accept the request and generate an alert email and/or log message. Alert & Deny—Block the request (or reset the connection) and generate an alert and/or log message. You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages). Deny (no log)—Block the request (or reset the connection). Period Block—Block subsequent requests from the client for a number of seconds. Also configure Block Period. You can customize the web page that FortiWeb returns to the client with the HTTP status code. For details, see Customizing error and authentication pages (replacement messages). Note: If FortiWeb is deployed behind a NAT load balancer, when using this option, you must also define an X-header that indicates the original client’s IP. Failure to do so may cause FortiWeb to block all connections when it detects a violation of this type. For details, see Defining your proxies, clients, & X-headers. The default value is Alert. Attack log messages contain Padding Oracle Attack when this feature detects a possible attack. Because this attack involves some repeated brute force, the attack log may not appear immediately, but should occur within 2 minutes, depending on your configured DoS alert interval. Caution: This setting will be ignored if Monitor Mode is enabled. Note: Logging and/or alert email will occur only if enabled and configured. For details, see Logging and Alert email.
Block Period	Type the number of seconds that you want to block subsequent requests from the client after the FortiWeb appliance detects that the client has violated the rule. This setting is available only if Action is set to Period Block. The valid range is from 1 to 3,600 seconds (1 hour). See also Monitoring currently blocked IPs.
Severity	When rule violations are recorded in the attack log, each log message contains a Severity Level (severity_level) field. Select which severity level the FortiWeb appliance will use when it logs a violation of the rule: Informative Low Medium High The default value is Medium.
Trigger Action	Select which trigger, if any, that the FortiWeb appliance will use when it logs and/or sends an alert email about a violation of the rule. For details, see Monitoring currently blocked IPs.

4. Click OK.
5. Click Create New.
6. Configure these settings:

Host Status	Enable to apply this rule only to HTTP requests for specific web hosts. Also configure Host. Disable to match the rule based upon the other criteria, such as the URL, but regardless of the Host: field.
Host	Select which protected host names entry (either a web host name or IP address) that the Host: field of the HTTP request must be in to match the rule. This option is available only if Host Status is enabled.
Type	Select whether the Protected URL field must contain a literal URL (Simple String), or a regular expression designed to match multiple URLs (Regular Expression).
Protected URL	Depending on your selection in Type, type either: The literal URL, such as /folder1/index.htm that the HTTP request must contain in order to match the rule, or use wildcards to match multiple URLs, such as /folder1/* or /folder1/*/index.htm. The URL must begin with a slash ( / ). A regular expression, such as ^/*\.jsp\?uid\=(.*), matching all and only the URLs to which the rule should apply. The pattern does not require a slash ( / ); however, it must at least match URLs that begin with a slash, such as /profile.cfm. Do not include the domain name, such as www.example.com, which is configured separately in the Host drop-down list. To create and test a regular expression, click the >> (test) icon. This opens the Regular Expression Validator window where you can fine-tune the expression. For details, see Regular expression syntax and Cookbook regular expressions.
Protected Target	Indicate which parts of the client’s requests should be examined for padding attack attempts: URL (e.g. parameters are embedded in the URL, such as /user/0000012FE03BC2) Parameter (e.g. parameters are appended in a traditional GET URL parameter, such as /index.php?user=0000012FE03BC2or POST body) Cookie

7. Click OK.
8. Repeat the previous 2 steps for each encrypted input in the web application.
9. Click OK.
10. To apply the rule, select it in an inline protection profile or an Offline Protection profile. For details, see Configuring a protection profile for inline topologies or Configuring a protection profile for an out-of-band topology or asynchronous mode of operation.

Malicious clients often send many HTTP requests while attempting to analyze the padding. This could flood your attack logs with repetitive messages. To adjust the interval at which FortiWeb will record identical log messages during an ongoing attack, see max-dos-alert-interval <seconds_int> in the FortiWeb CLI Reference: HTTPs://docs.fortinet.com/product/fortiweb/ See also Log rate limits.