The product behaves differently or sends different responses in a way that exposes security-relevant information about the state of the product, such as whether a particular operation was successful or not.
An attacker can gain access to sensitive information about the system,
including authentication information that may allow an attacker to gain
access to the system.
Demonstrative Examples
Example 1
The following code checks validity of the supplied username and
password and notifies the user of a successful or failed login.
(Bad Code)
Example
Language: Perl
my $username=param('username');
my $password=param('password');
if (IsValidUsername($username) == 1)
{
if (IsValidPassword($username, $password) == 1)
{
print "Login Successful";
}
else
{
print "Login Failed - incorrect password";
}
}
else
{
print "Login Failed - unknown username";
}
In the above code, there are different messages for when an incorrect
username is supplied, versus when the username is correct but the
password is wrong. This difference enables a potential attacker to
understand the state of the login function, and could allow an attacker
to discover a valid username by trying different values until the
incorrect password message is returned. In essence, this makes it easier
for an attacker to obtain half of the necessary authentication
credentials.
While this type of information may be helpful to a user, it is also
useful to a potential attacker. In the above example, the message for
both failed cases should be the same, such as:
Bulletin Board displays different error messages
when a user exists or not, which makes it easier for remote attackers to
identify valid users and conduct a brute force password guessing attack.
Operating System, when direct remote login is
disabled, displays a different message if the password is correct, which
allows remote attackers to guess the password via brute force methods.
Product sets a different TTL when a port is being
filtered than when it is not being filtered, which allows remote attackers
to identify filtered ports by comparing TTLs.
Version control system allows remote attackers to
determine the existence of arbitrary files and directories via the -X
command for an alternate history file, which causes different error messages
to be returned.
FTP server generates an error message if the user
name does not exist instead of prompting for a password, which allows remote
attackers to determine valid usernames.
SSL implementation does not perform a MAC
computation if an incorrect block cipher padding is used, which causes an
information leak (timing discrepancy) that may make it easier to launch
cryptographic attacks that rely on distinguishing between padding and MAC
verification errors, possibly leading to extraction of the original
plaintext, aka the "Vaudenay timing attack."
Virtual machine allows malicious web site
operators to determine the existence of files on the client by measuring
delays in the execution of the getSystemResource method.
Product uses a shorter timeout for a non-existent
user than a valid user, which makes it easier for remote attackers to guess
usernames and conduct brute force password guessing.
FTP server responds in a different amount of time
when a given username exists, which allows remote attackers to identify
valid usernames by timing the server response.
Browser allows remote attackers to determine the
existence of arbitrary files by setting the src property to the target
filename and using Javascript to determine if the web page immediately stops
loading, which indicates whether the file exists or not.
Potential Mitigations
Phase: Architecture and Design
Strategy: Separation of Privilege
Compartmentalize the system to have "safe" areas where trust
boundaries can be unambiguously drawn. Do not allow sensitive data to go
outside of the trust boundary and always be careful when interfacing
with a compartment outside of the safe area.
Ensure that appropriate compartmentalization is built into the system
design and that the compartmentalization serves to allow for and further
reinforce privilege separation functionality. Architects and designers
should rely on the principle of least privilege to decide when it is
appropriate to use and to drop system privileges.
Phase: Implementation
Ensure that error messages only contain minimal details that are
useful to the intended audience, and nobody else. The messages need to
strike the balance between being too cryptic and not being cryptic
enough. They should not necessarily reveal the methods that were used to
determine the error. Such detailed information can be used to refine the
original attack to increase the chances of success.
If errors must be tracked in some detail, capture them in log messages
- but consider what could occur if the log messages can be viewed by
attackers. Avoid recording highly sensitive information such as
passwords in any form. Avoid inconsistent messaging that might
accidentally tip off an attacker about internal state, such as whether a
username is valid or not.
Description
