• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Insufficient Data Protection Working

Page history last edited by Robert Auger 12 years ago

 

Project: WASC Threat Classification

Threat Type: Weakness

Reference ID: WASC-50

Working State: Draft/Peer Review - Round one

 

Important Note: This page is in a working state, do not link to or reference this material.

 

Insufficient Data Protection

 

Insufficient Data Protection occurs when sensitive or potentially valuable data is not sufficiently handled to prevent disclosure, modification, or provide non-repudiation [3]. In order to understand Data Protection it's important to know the structure of the weakness and related topics. Using "logical thinking" it's useful identify:

  • Assets: what kind of data must be protected and where is handled?
  • Threats and Threat Agents: what, who, which insist on it?
  • Security Controls: what controls can be implemented to protect it?
  • Security Limitations: these controls can be not implemented, implemented partially or implemented in a bad way which can introduces new threats? 

 

Each data element used by an application should be evaluated for its Confidentiality, Integrity, and Availability.  Utilizing a well thought out data classification and outlining the encryption/signing/hashing requirements of each data element, can ensure consistency and prevent ambiguity when handling each type of data. Data classifications can also ensure that background decisions for handling various data types are documented, in particular to meet compliance standards such as ISO 27000 [4], PCI-DSS [5], SOX,, privacy laws [6], or other legal requirements. Common examples of data include:

 

  • Authentication/Identification Data
    • Passwords
    • Keys
    • PINs
    • Certificates  
    • Tokens
  • Personally Identifiable Information (PII)
    • Full name
    • Birth Date
    • Birthplace
    • Contact Information (e-mail addresses, phone numbers etc...)  
    • Official Documents (Driver's licence, ID Documents)
    • Biometric information 
    • National Identification Number (SSN) 
    • Health Information
    • Financial Data (Salary)
    • Race
    • Sexual orientation
    • Credit Cards (PAN, CVV2) 
  • Company and Business Data 
    • Client and Customer Names and Contacts
    • Financial Data  
    • Transactions and Payments
    • Other confidential documents and materials
  • Other
    • Confidential e-mail contents

 

 

Then the point is about where and how these data is handled. Handling can be splitted in two parts: Storage and Transport. Stored data can be located typically on Database Server, Content Addressed Storage, Mail Server, File (example a money-transfer XML file), and someone can access it. During transportation data pass through a channel - the transport layer - and destination must be sure data received is the same as sent, and someone can intercept it. 

 

On the low-level data is virtually stored in one or more disks, probably mapped into a file-system even if Database files, or in a Cloud Storage and is  transported over the network.

 

Threat Agents is someone can access to these location or intercept/modify/delete data. Special mention for Authentication/Identification data which can be also guessed.

 

Common threat agents include:

  • Employees (System Administrators, DBAs, Developers, OPS, Release Management, etc...) 
  • External Attackers who can access where data is stored exploiting some vulnerabilities.

 

In order to avoid data reading/modifying/deleting there are Controls can be applied:

  • Encryption Techniques to avoid agents to read data ensuring Confidentiality.
  • Integrity Checking for transported and stored data to avoid unwanted modifications. 
  • Complexity Requirements for Authentication/Identification Data to avoid brute-force and password guessing attacks.
  • Transport Layer Protection to avoid eavesdropping (see Insufficient Transport Layer Protection).
  • Password and Key Management practices to avoid Authentication/Identification Data compromise.
  • Backup / Disaster Recovery Planning to avoid data deletion ensuring availability.
  • Data Loss Prevention solutions to avoid bad destinations for data. 

 

This weakness occur for a missing control or if a control is applied but with limitations:

  • Lack of Encryption
  • Weak/Obsolete Cipher Usage
  • Wrong Encryption Type Usage
  • Homebrew Ciphers/Obfuscation Usage
  • Hashing without Salting
  • Hashing without Shared Salts 
  • Non Random Salts and Initialization Vectors
  • Lack of Integrity Checking
  • Lack of Key Derivation Function 
  • Insufficient Secret Complexity
  • Insufficient Entropy/Randomness 

 

Lack of Encryption

Lack of Encryption can occur when a requirement to encrypt data fails to exist and/or is failed to be applied during development. Common data elements that are often not encrypted or are improperly encrypted are credit cards.  Depending on the type of data you're handling, the country where your company practices business, and your user's country of origin, failure to secure sensitive data may be in violation regulations such as PCI-DSS, SOX, HIPPA, etc...

 

Example 1: Storing credit cards in cleartext

A common mistake is for credit card data to be stored by e-commerce sites in cleartext. In this example consider there are no triggers or other stuff which encrypts "on-the-fly" card data, even if there are the HMAC for whole record, with the Integrity Key only know by the application itself.

 

-- SQL Database Dump
 
--
-- Table structure for table 'shop_cards'
--
 
DROP TABLE IF EXISTS 'shop_cards';
CREATE TABLE 'shop_cards' (
        'card_holder' varchar(255) NOT NULL default '',
        'card_type' varchar(16) NOT NULL default '',
        'card_number' varchar(42) NOT NULL default '',
        'card_expire' varchar(4) NOT NULL default '',
        'card_cvv2' char(3) NOT NULL default '',
        'card_hmac' varchar(88) NOT NULL default '');
INSERT INTO 'shop_cards' VALUES 
        ('John Doe', 'visa','4319784677360536', '0612', '123', 'YzU4N2EzNjdmODcwNDc2OGM5ZDU4NzA3OWI3OGQzOTAwN2QwMGVmMjI4NjgxZTg3YWViNWMwY2M1OGU4YjNiNg=='),
        ('Joe Soap', 'visa','4024007113929037', '0211', '456', 'ZTRkM2RhYjYzZDJjNDgxZWU0ZjAwMmYwMzA0MjNhYTljMTU2MzA1NDg5NjM0NTk3NWE3MDIxMDUzODc3ODhmNw=='),
        ('Numerio Negidio', 'visa','4916775127629220', '1013', '789', 'YjEyZDk3MWJjN2RmYTkyNWY1ODEwOTY4NzhhNThmMjM3N2VlMGRkZDkwNTUxZDJiNzAzZmNmY2U5MDJkZGZhMQ=='),
        ('Joe Bloggs', 'visa','4556600738547014', '0613', '012', 'MDczMjk2NGUyMzc3YjBkZmU1NTBhODZkZDFkN2RhZTdlNTM4MmViMTliOTZkYzk2MDVkNzE1ZWE5NTg4ODY5OA==');  

 

By not properly encrypting a credit card you open yourself to some of the following threats:

  • A malicious employee stealing customer data
  • Card compromise due to SQL Injection, or SQL database related vulnerability
  • Violation of PCI-DSS

 

Weak/Obsolete Cipher Usage

Many ciphers have had vulnerabilities identified within them, or as hardware becomes faster and cheaper become less effective. The DES cipher has been found to contain many weaknesses and is not recommended for protection of data. DES uses 56-bit key lengths and can be trivially brute forced as demonstrated by the Electronic Frontier Foundation with "DES cracker" [20].   When encrypting potentially sensitive/sensitive data do not use weak ciphers such as DES, consider a stronger alternative such as AES. Similarly for hashing data, avoid weaker ciphers such as MD5/SHA1, and consider using SHA-256/384/512. For a more comprehensive list of ciphers be sure to check out the The OWASP Cryptography Guide [28].

 

Wrong Encryption Type Usage

The use case for your data should determine the approach for protecting it. In the case of storing passwords, a best practice is to use one way hashing algorithms [26] rather than two way encryption. For this use case when a password evaluation is needed it is best to hash the incoming password using a secure cipher and compare the two values.

 

Home-brew Encryption and Obfuscation Usage

It is usually never safe to use homegrown encryption or obfuscation methods as it is likely to be vulnerable to various forms of crypto attacks [32]. Against data that could be considered sensitive. A general rule is that such ciphers should be limited for didactic purposes, and should never be used in a production environment, in particular if it's required to adhere to compliance standards or regulations, it's also important to use only approved crypto-modules and functions in order to avoid problems in implementations. Also consider in this section "custom" and "secret" algorithms for a specific vendor [29]. 

 

Example 2:  Caesar Cipher

The Caesar Cipher is a famous Roman substitution/shift cipher, it operates by substituting one character for another and has been used in military communications [19]. 

 

Cleartext: WEB APPLICATION SECURITY CONSORTIUM
Shift 3 letters: ZHE DSSOLFDWLRQ VHFXULWB FRQVRUWLXP
Shift 4 letters: AIF ETTPMGEXMSR WIGYVMXC GSRWSVXMYQ
Shift 5 letters: BJG FUUQNHFYNTS XJHZWNYD HTSXTWYNZR

 

Due to the ease of use in breaking such ciphers, they should never be used to protect anything of potential value. ROT13 is a modern example of a substitution chipper. In some cases base64 - an encoding schema - is used wrongly for obfuscation.

 

Hashing without Salting

Salting is a technique used to increase the time needed to crack a hash. This is achieved by inserting a random value alongside with the data prior to hashing with a secure message digest algorithms. By salting the data, you are preventing attackers from using pre-computed hashes, e.g. a rainbow table [18].

 

Example 3: passwords being hashed without an appropriate salt

This example demonstrates a developer using the SHA-512 algorithm to hash a password without salting it.

 

<?php
/* some code... */
 
$statement = $dbh->prepare("INSERT INTO app_users_use (use_username, use_password) VALUES (:username, :password)");
$statement->bindParam(':user', $_POST['user']);
$statement->bindParam(':password', hash('sha512',$_POST['password']));
$statement->execute();

 

/* other code... */
?>
 

Hashing with Shared Salts 

It is a generally accepted practice to store a salt along with the hashed data. If you are using a shared salt to hash all data and the database + salt is compromised then an attacker can simply generate a new rainbow table with this salt. By using per user salting it would require the attacker to generate 1 rainbow table per user, adding considerable time, and likely reducing the chances of cracking the original data.

 

Non Random Salts and Initialization Vectors

 

An initialization vector is a fixed-size set of bits used to generate different ciphertext when the same key is used to encrypt the same data. As outlined under 'Hashing Without Salting', salts are random data used to ensure that the generated hash by a known hashing function returns a different result. If a salt or initialization vector is not random, encrypted/hashed data could be compromised.

 

Example 4: Non-random Initialization Vectors & CBC chaining

An online service encrypts a user’s 'stuff' but use a nonrandom static initialization vector.


<?php
/* encryptstuff.php page */
$stuff = $_POST['stuff'];
$key = $_POST['key'];
$iv = '12345678';
$encrypted = mcrypt_cbc(MCRYPT_TripleDES, $key, $stuff, MCRYPT_ENCRYPT, $iv);
/* some code... */
?>

 

A famous example of an attack exploiting non-random IV was demonstrated by the B.E.A.S.T. attack tool[31], which exploited older versions of TLS. In TLS versions prior to 1.1, the IV used for CBC encryption is the ciphertext of the last block of the last message, instead of a random IV. This allows an active attacker on the local network the capability to influence traffic, and ultimately steal data within an encrypted TLS stream.

Lack of Integrity Checking

Integrity is one of the three cornerstone's in Information Security's C.I.A. pyramid along with Confidentiality and Availability. There are situations where a high level of assurance exists that data hasn't been altered by an attacker in transit. Common approaches to implementing integrity checking involve the usage of Digital Signatures for Asymmetric encryption, or Message Authentication Codes (MACs) for symmetric encryption. Typically these signatures are appended to the end of the payload, and are used to verify if the data has been altered in any way. If the payload is altered in transit the digital signature or MAC will fail to validate indicating a modification has occurred.

Example 5: Lack of integrity checking for purchases

 

A typical example where a lack of Integrity exists involves placing orders on an e-commerce site. After the purchase order is placed, and payment verified, the order is passed to an external shipping company indicating the customer address and order reference. In the example below the request is sent to a Web Service over HTTPS.

 

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">

  <soap:Header>

  </soap:Header>

  <soap:Body>

    <order:ShipOrder xmlns:order="http://www.example.org/order">

       <order:To>Elwood Blues</order:to>

       <order:Address>1060 West Addison Street, Chicago, IL</order:address>

       <order:Telephone>1-555-368-7147</order:telephone>

       <order:OrderReference>1562</order:OrderReference>

    </order:ShipOrder>

  </soap:Body>

</soap:Envelope>

 

As can be seen there is no mechanism for the shipping company to determine that this order hasn't been altered.  An active attacker could modify the request and change the shipping address to their own unbeknownst to the shipping company.

 

An approach to implementing proper integrity checking would involve appending a MAC, or Digital Signature to the order that would be required to pass verification prior to processing the order. A good example is to add an HMAC for the bitwise concatenation of all fields (in italic):

 

<?xml version="1.0"?>

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope">

  <soap:Header>

  </soap:Header>

  <soap:Body>

    <order:ShipOrder xmlns:order="http://www.example.org/order">

       <order:To>Elwood Blues</order:to>

       <order:Address>1060 West Addison Street, Chicago, IL</order:address>

       <order:Telephone>1-555-368-7147</order:telephone>

       <order:OrderReference>1562</order:OrderReference>

       <order:HMAC>MTljNmY2ZWQ5MTZjMmRlZTY3YjAwZDQzODU2MzIzYjZjYjRjNTYwNWZkZDUzYzZiYWM5YjYwZDU1ZjNiYTQ3Zg==</order:HMAC> 

    </order:ShipOrder>

  </soap:Body>

</soap:Envelope>

 

Lack of  Key Derivation Functions

Key Derivation Functions [22] such as PBKDF2 [21] are used to cryptographically transform an original secret into one or more secrets. The resulting secret is then used to encrypt or hash data. A key use for using KDF's is to add computation time prior to encrypting or hashing data. An advantage of using a KDF is to extend the life of a secure cipher (one which has not been discovered to have any inherent weaknesses) as hardware speed increases by simply increasing the iteration counts.

 

The importance of Key Derivation Function is underlined in NIST Special Publication 800-108 [30], which explains in deep the recommendations using KDF. There is a lack of Key Derivation Function if it not used or implemented.

 


Insufficient Secret Complexity

Using a secret (a password/pass-phrase, or encryption key) which is both not guessable and difficult to brute force is just as important as using the appropriate encryption or hashing cipher/algorithm. With the wide availability of free tools such as John The Ripper [16], it is important to choose a secret that does not fall within one of the following conditions:

  • Short Secrets: Ensure that a reasonable minimum length is enforced in your application. 
  • Secrets with limited character ranges: Ensure that multiple characters ranges are required for your users when selecting a secret
  • Secrets susceptible to dictionary and brute force attacks

 

Example 6: poorly chosen passwords

Short passwords or passwords which can be found in a dictionary should not be used. Typical examples of weak passwords involve the name of the user, his/her favorite animal, color, city, or sport team. Below is a list of common weak passwords obtained from a hacked website [24], [25], [27]: 

 

12345

123456

1234567

12345678

123456789

letmein

jeremiah

password

Password

 

Insufficient Entropy/Randomness

Random values are often used in the process of protecting data, generating session ids, generating activation codes, or generating keys. If random values are predictable or repeat, data may be susceptible to Brute-Force attacks, guessing the random value and accessing to reserved data, or collisions.

 

Example 7: Usage of rand() in PHP on Windows

On Windows usage of the rand() function is not secure, as discovered by visual analysis [11]:

 

<?php

while(1) {

echo rand(0,1);

}

?>

 

<MORE DETAIL REQUESTED>

 

 

Public Incidents

 

Gawker Hack: passwords stored using DES

In December, 2010 Gawker server - an online media company - was hacked [12] and had its database stolen. The stolen database exposed the email addresses and passwords of over 1.3 million users. This occurred because Gawker's passwords were stored using the obsolete Data Encryption Standard (DES) which allowed the attackers to easily crack them. After obtaining the account details the attackers used them to launch spam campaigns on popular social network sites [17]. This is an example of Wrong Cipher Usage and Weak Cipher Usage.

 

RockYou Hack: cleartext password 

In January, 2010 RockYou server - a Facebook application provider - was hacked [13] via SQL Injection. Over 32 million user passwords were stolen because RockYou stored the passwords in cleartext. This is an example of Lack of Encryption.

 

phpBB Hack: passwords hashed using unsalted MD5

In February, 2009 phpBB.com the provider of a popular forum application was hacked [14] and lead to the exposure of 20,000 user hashes. Due to phpBB.com's lack of per user salting, attackers were easily able to crack the hashes and obtain the original user passwords. This is an example of Hashing without Salting.

 

Other examples of compromise due to poorly implemented cryptography can be found at the Web Hacking Incident Database [15] Project.

 

 

Additional Information

 

SANS Top 25 Most Dangerous Software Errors - Missing Encryption of Sensitive Data

http://cwe.mitre.org/top25/#CWE-311

 

OWASP Top 10 2010-A7-Insecure Cryptographic Storage

http://www.owasp.org/index.php/Top_10_2010-A7

 

References

 

[1] CWE-310: Cryptographic Issues

http://cwe.mitre.org/data/definitions/310.html

 

[2] OWASP - Guide to Cryptography

http://www.owasp.org/index.php/Guide_to_Cryptography

 

[3] Wikipedia - Information Security

http://en.wikipedia.org/wiki/Information_security

 

[4] ISO 27001 12.3, 15.1

http://www.27000.org/

 

[5] PCI-DSS v2 - Requirement 3 Missing Encryption of Sensitive Data

https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf

 

[6] Wikipedia - Privacy Law

http://en.wikipedia.org/wiki/Privacy_law

 

[7] Wikipedia - Business Continuity Planning

http://en.wikipedia.org/wiki/Business_continuity_planning

 

[8] Wikipedia - Disaster Recovery Planning

http://en.wikipedia.org/wiki/Disaster_recovery

 

[9] FIPS - PUB 199 “Standards for Security Categorization of Federal Information and Information System”

http://csrc.nist.gov/publications/fips/fips199/FIPS-PUB-199-final.pdf

 

[10] CNSS - Policy No. 15, Fact Sheet No. 1

“National Policy on the Use of the Advanced Encryption Standard (AES) to

Protect National Security Systems and National Security Information”

http://csrc.nist.gov/groups/STM/cmvp/documents/CNSS15FS.pdf

 

[11] Pseudo-Random vs. True Random: A Simple Visual Example

http://www.boallen.com/random-numbers.html

 

[12] Computer World - Gawker hack analysis reveals weak passwords

http://www.computerworld.com/s/article/9201139/Gawker_hack_analysis_reveals_weak_passwords 

 

[13] Computer World - RockYou hack exposes names, passwords of 30M accounts

http://www.computerworld.com/s/article/9142327/RockYou_hack_exposes_names_passwords_of_30M_accounts

 

[14] SecLists - phpbb hacked...

http://seclists.org/dailydave/2009/q1/97 

 

[15] The WASC Web Hacking Incidents Database Project

http://projects.webappsec.org/Web-Hacking-Incident-Database

 

[16] John The Ripper

http://www.openwall.com/john/

 

[17] Hack attack on Gawker spawns Twitter spam

http://www.bbc.co.uk/news/technology-11981816

 

[18] Rainbow Tables

http://en.wikipedia.org/wiki/Rainbow_table

 

[19] The Caesar Cipher

http://www.cs.trincoll.edu/~crypto/historical/caesar.html

 

[20] Frequently Asked Questions (FAQ)About the Electronic Frontier Foundation's"DES Cracker" Machine

http://w2.eff.org/Privacy/Crypto/Crypto_misc/DESCracker/HTML/19980716_eff_des_faq.html

 

[21] Password-Based Key Derivation Function

http://en.wikipedia.org/wiki/PBKDF2

 

[22] Key Derivation Function

http://en.wikipedia.org/wiki/Key_derivation_function

 

[23] CWE-331: Insufficient Entropy

http://cwe.mitre.org/data/definitions/331.html

 

[24] The Top 50 Gawker Media Passwords

http://blogs.wsj.com/digits/2010/12/13/the-top-50-gawker-media-passwords/

 

[25] rootkit.com cleartext passwords

http://dazzlepod.com/rootkit/password/

 

[26] Jeff Atwood - You're Probably Storing Passwords Incorrectly

http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html

 

[27] A brief analysis of 40,000 leaked MySpace passwords

http://www.the-interweb.com/serendipity/index.php?/archives/94-A-brief-analysis-of-40,000-leaked-MySpace-passwords.html

 

[28] OWASP Guide to Cryptography

http://www.owasp.org/index.php?title=Guide_to_Cryptography

 

[29] Snake Oil Warning Signs: Encryption Software to Avoid

http://www.interhack.net/people/cmcurtin/snake-oil-faq.html

 

[30] NIST Special Publication 800-108

"Recommendation for Key Derivation Using Pseudorandom Functions (Revised)"    

http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf

 

[31] B.E.A.S.T.

http://netifera.com/research/beast/

 

[32] Types of Cryptographic Attacks

http://www.giac.org/cissp-papers/57.pdf

MCRYPT_TripleDES

Comments (0)

You don't have permission to comment on this page.