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 protect against padding oracle attacks
- Consult with your application developer to find inputs that are individually encrypted.
- Go to Web Protection > Advanced Protection > Padding Oracle Protection.
- Click Create New, then configure these settings:
- 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.
- Informative
- Low
- Medium
- High
- Click OK.
- Click Create New.
- Configure these settings:
- The literal URL, such as
/profile.jsp, that the HTTP request must contain in order to match the rule. The URL must begin with a backslash ( / ). - 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. -
URL (e.g. parameters are embedded in the URL, such as
/user/0000012FE03BC2) -
Parameter (e.g. parameters are appended in a traditional
GETURL parameter, such as/index.php?user=0000012FE03BC2orPOSTbody) - Cookie
- Click OK.
- Repeat the previous 2 steps for each encrypted input in the web application.
- Click OK.
- 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.
|
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. |
| 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: The default value is Alert. Attack log messages contain 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 (1 hour). The default value is 1. See also Monitoring currently blocked IPs. |
| Severity |
When rule violations are recorded in the attack log, each log message contains a Severity Level ( 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. |
| 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 |
Select which protected host names entry (either a web host name or IP address) that the 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: Do not include the domain name, such as 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: |
|
|
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 http://docs.fortinet.com/fortiweb/reference See also Log rate limits. |