 |
 |
- Cryptographically weak pseudo-random number generator
- Broken or risky cryptographic algorithm
- Information Exposure [This vulnerability is one of the vulnerabilities of the BID, 95831. The CVE ID isCVE-2016-8217. The descritiopn of this vulnerability is, "A possible timing attack could be carried out by modifying a PKCS#12 file that has an integrity MAC for which the password is not known. An attacker could then feed the modified PKCS#12 file to the toolkit and guess the current MAC one byte at a time. This is possible because Crypto-J uses a non-constant-time method to compare the stored MAC with the calculated MAC."]
Use of cryptographically weak pseudo-random number generator
Description
If a pseudo-random number generator (PRNG) is used that is not designed for cryptography, the cryptography can be prone to attacks. Sometimes a mediocre source of randomness is sufficient or preferable for algorithms which use random numbers. Weak generators generally take less processing power and/or do not use the precious, finite, entropy sources on a system. While such PRNGs might have very useful features, these same features could be used to break the cryptography.
What you should not do
srand(time());
int randNum = rand();
The rand() function used in the above code is not considered cryptographically strong. An attacker may be able to predict the random numbers generated by these functions.
What you should do
Use functions or hardware which use a hardware-based random number generation for all crypto. Use CyptGenRandom on Windows, or hw_rand() on Linux.
Concept Map
The above vulnerability maps to 11 in the Concept Map.
This vulnerability is mentioned in Common Weakness Enumeration (CWE) list of security flaws. The ID is 388. The link to the details of this vulnerability is https://cwe.mitre.org/data/definitions/338.html .95831
Use of broken or risky cryptographic algorithm
Description
Well-known techniques may exist to break a non-standard cryptographic algorithm. Hence, the attacker will be able to compromise the protected data.
What you should not do
Using the Data Encryption Standard (DES). DES uses a 56-bit key which is considered too small. DES has been replaced by Advanced Encryption Standard (AES).
Using DES in C is shown below.
EVP_des_ecb();
What you should do
In order to protect sensitive data, strong up-to-date cryptographic algorithms should be used. An algorithm that is well tested and considered strong by experts in the field should be used. For example, the U.S. government requires a FIPS 140-2 certification. This is a computer security standard used by the U.S. government to approve cryptographic modules. Custom or private cryptographic algorithms should not be used since they are likely to be exposed to attacks that are well-understood by cryptographers. If an attacker can reverse engineer an algorithm ad find out how it works, that algorithm is considered a weak algorithm. Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong.
Concept Map
The above vulnerability maps to 10 in the Concept Map.
This vulnerability is mentioned in Common Weakness Enumeration (CWE) list of security flaws. The ID is 327. The link to the details of this vulnerability is https://cwe.mitre.org/data/definitions/327.html .
Information exposure through an error message
Description
The software message generates an error message that includes sensitive information about its environment, users or associated data.
What you should not do
The example is written in Java, shows the table name and the column names are exposed.
public BankAccount getUserBankAccount(String username, String accountNumber) {
BankAccount userAccount = null;
String query = null;
try {
if (isAuthorizedUser(username)) {
query = "SELECT * FROM accounts WHERE owner = "
+ username + " AND accountID = " + accountNumber;
DatabaseManager dbManager = new DatabaseManager();
Connection conn = dbManager.getConnection();
Statement stmt = conn.createStatement();
ResultSet queryResult = stmt.executeQuery(query);
userAccount = (BankAccount)queryResulError messages should be a balance between too cryptic and revealing
too much information.t.getObject(accountNumber);
}
}
catch (SQLException ex) {
String logMessage = "Unable to retrieve account information from database,\nquery: " + query;
Logger.getLogger(BankManager.class.getName()).log(Level.SEVERE, logMessage, ex);
}
return userAccount;
}
If error message reveals details about the database query and other sensitive information about the database attacks such as SQL injection attacks are simple to execute.
What you should do
Error messages should be a balance between too cryptic and revealing too much information. Avoid logging highly sensitive information like passwords in logs, since a log can be accessed by an attacker. Revealing methods to determine an error allows the chances of an attack being successful, since the original attack can be refined with the information obtained from the error.
public BankAccount getUserBankAccount(String username, String accountNumber) {
BankAccount userAccount = null;
String query = null;
try {
if (isAuthorizedUser(username)) {
query = "SELECT * FROM accounts WHERE owner = "
+ username + " AND accountID = " + accountNumber;
DatabaseManager dbManager = new DatabaseManager();
Connection conn = dbManager.getConnection();
Statement stmt = conn.createStatement();
ResultSet queryResult = stmt.executeQuery(query);
userAccount = (BankAccount)queryResulError messages should be a balance between too cryptic and revealing
too much information.t.getObject(accountNumber);
}
}
catch (SQLException ex) {
String logMessage = "Unable to retrieve account information from database,\nquery: " + query;
Logger.log(Level.SEVERE, "Exception occurred", ex);
}
return userAccount;
}
Concept Map
The above vulnerability maps to i in the Concept Map.
The Common Weakness Enumeration (CWE) ID is 209 which is a child of CWE 200. The link to the details of this vulnerability is https://cwe.mitre.org/data/definitions/338.html .95831
Intentional information exposure
Description
Information considered sensitive by an administrator should not be published. This may involve information about the product's design and/or configuration.
What you should not do
The following JSP code displays the user's credit card and social security information on the web page.
Social Security Number: <%= ssn %></br>Credit Card Number: <%= ccn %>
What you should do
Don't display sensitive information on a web page.
Concept Map
The above vulnerability maps to i in the Concept Map.
The Common Weakness Enumeration (CWE) ID is 213 which is a child of CWE 200. The link to the details of this vulnerability is https://cwe.mitre.org/data/definitions/338.html .95831
Information exposure through discrepancy
Description
Information or response given to a user by a product for a result of a particular operation should not be in a way that security-relevant information is exposed.
What you should not do
In the following code in Perl, when an incorrect username is given different message are printed to the user versus the messages given to the user when correct username and incorrect password are supplied. These differences in error messages can help the attacker understand the state of the logic function. This could allow an attacker to find a valid username by trying different values until incorrect password message is returned.
What you should do
Message such as "Login Failed - incorrect username or password", should be used. For all failed cases the message should be the same.
Concept Map
The above vulnerability maps to i in the Concept Map.
The Common Weakness Enumeration (CWE) ID is 203 which is a child of CWE 200. The link to the details of this vulnerability is https://cwe.mitre.org/data/definitions/338.html .95831
This program is sponsored by NSF award #1303211