Tech News

Part seven of the series detailing the OWASP top 10 web application vulnerabilities with a focus on password hashing. (See intro)

"Insecure cryptographic storage" relates to a number of aspects, but I think that it can be broken down to two main areas: Encryption and Hashing.

As these are similar in some respects and are often both used together, there's a bit of confusion around what they are.

Firstly, encryption uses a mathematical formula to transform human readable data into an unreadable form by means of a key. Often encryption is a symmetric process. That is, the same (or trivial) key is used to lock (encrypt) the data as to unlock the data. This differs from asymmetric (or public-key) encryption where there are two different keys employed - One for locking and the other for unlocking. One constant in encryption is that there is a key which must be kept safe. This key is employed by means of a sequence of data and may be stored in a file on the server if needed continuously by a computer program. This obviously implies that anyone who can break into the server and get access to the key can unlock all the data.

Hashing is similar to encryption in that it transforms data from a human readable form into an unreadable form via a mathematical function. The primary difference between the two is that hashing is only a one way function. In other words, given the hash (or resultant) code, nobody should be able to work out the original data. An example of a hash value for the entered phrase "test" using the Md5 hash algorithm is: 098f6bcd4621d373cade4e832627b4f6

If you can't ever retrieve the original data what use is this? One of the common uses is for securing passwords. The way in which it works can be explained by means of an account registration and login example. Upon account creation, the password is hashed, thus giving a block of unreadable data. This is then stored in the database as the "password". When the user enters their password during the login process, the entered password is once again hashed and then the two hashed values are compared. If they are the same, the user entered a valid password. Note how the password in human readable form is never needed to determine if the user has entered the correct password. So, even if a hacker got access to the system's source code and the hashed passwords, due to the fact that a hashed password can't be reversed, it is theoretically impossible to crack someone's password. Not quite...

There are a number of techniques employed in cracking passwords. Firstly dictionary attacks take a dictionary of words and try each one sequentially until a match is found. They would also try combinations of words, or words with prefixed and/or appended numbers. As it is much simpler to remember a name or word, people invariably choose simple passwords and therefore the dictionary attack is amazingly effective. This highlights the importance of having a minimum strength password policy in place, forcing a user to select a password with a combination of uppercase letters, punctuation and both alpha and numeric values therein.      

The other widely used approach is the use of rainbow tables. Basically, a hacker has a stored table of data which in essence contains two things; passwords and the hashed value for each password. Additionally, these hashed values are indexed in the database which makes it very quick to simply look up a given hash value and determine the corresponding password. This approach uses the time/memory trade-off as these tables are very large but allow much quicker cracking of hash values.

As an example of how easy this can be, using the hash example above, the hash value 098f6bcd4621d373cade4e832627b4f6 can be "broken" in seconds using online web based tool at:  http://www.md5rainbow.com/

The way to defeat the rainbow tables is to add a salt to the hash value. A salt is a random set of data that is appended to the given password which makes the cracking of the password unlikely by means of lookup tables. 

As an example, a 3 letter password containing only letters could have 17576 different possibilities(26x26x26). If another 3 letters were added before hashing, such that the final string = salt + password, there would be 308915776 permutations. The resultant space that would be required to calculate all the possibilities for all salts becomes exponentially greater as a longer salt is used. This renders generating a pre-compiled table infeasible.

Once the concatenated string has been hashed, both the salt and the hash are stored in the data store. The salt will be used later again to validate that an entered password is correct by using the same salt, hashing the resultant string and comparing it to the stored value. The storage of the salt with the password may sound counter intuitive, but it's sole purpose is to eliminate the possibility of using a pre-compiled table to crack passwords.

One more point about a salt, is that every salt must be unique. If all your records are hashed with the same salt then a determined hacker would only need to regenerate a single rainbow table for the given salt and then lookup any password. If every salt is unique, then the hacker would have to regenerate the table for every hashed password, making it much more difficult.  

Finally, there are a number of different hashing algorithms and some are better suited to particular jobs than others.

Some of the more common ones include: SHA256, MD5  and WHIRLPOOL. The SHA family of hash algorithms are probably one of the better general purpose algorithms to use, but check that any hash algorithm that you choose to use is secure.

Part four of the series detailing the OWASP top 10 web application vulnerabilities. (See intro)


On the surface of it, this might seem to have something to do with class type objects, but actually, it doesn't... So what are we talking about?

Well, the sort of objects we're talking about here are files, directories, database records or primary keys.

I find that using a specific example is the easiest way to explain these concepts, so consider the following URL:

http://myserver/index.jsp?getfile=myreport.doc
or
http://myserver/index.aspx?getfile=myreport.doc
The idea here, is that the parameter is used to specify the file to download. This could quite easily be exploited to return a unintended file by a hacker modifying the parameter.

What would happen if a hacker modified the URL to:

http://myserver/index.aspx?getfile=/../web.configor
http://myserver/index.jsp?getfile=../../../tomcat/conf/tomcat-users.xml

In the second JSP/Java/Tomcat example, they could get hold of the config file used to store user names and passwords - instant admin access!

This isn't limited to files - records identified by their primary keys are also vulnerable.

Once again, a hacker could easily modify the unique key in the following URL to return data that they might not be suppose to access:

http://myserver/viewAccountBalance.jsp?accountNr=1234
So what do we do to avoid this situation?
Firstly, validate all input. If you're returning files, ensure that a hacker can't escape the input. This isn't always as easy as it sounds though - I recall some time ago in 2001 that IIS had a bug in it allowing directory traversals by using the overlong Unicode representations for / and . - %c0%af and %c1%9c. Using a combination of these basically bypassed all security checks and allowed executing commands on the server by inputting commands to the command shell. Basically, a hacker had complete access to the server. So be careful!

Probably most importantly, use a reference map to refer indirectly to objects, so that they're never shown publicly. If a hashtable of valid key/file names are stored server side and are referenced through the use of their keys from the browser, a hacker can't enter a file name/ record key that they're not supposed to have access to.

eg. instead of the first example above, a better approach would be:

http://myserver/index.jsp?getfileByID=2

Obviously, you only store those files in the hashtable that they're supposed to have access to, otherwise they would simply change the file id and once again access secure data.


So... Beware of your parameters and what they could be exposing.

This is part five in a list of articles in which I'm detailing the OWASP Top 10 vulnerabilities. (see intro)

What is Cross-Site Request Forgery? Cross-Site Request Forgery, one-click attack, session riding or XSRF is an attack whereby unauthorised commands are transmitted from a user that exploits the trust that a site has in a user's browser. This is also known as a confused deputy attack against a browser. The "deputy" is the user's Web browser which is confused into misusing a user's authority at an attacker's direction.

Basically, a malicious script executes on a page not related to the actual compromised site and executes a transaction on the attacked site. This could take place on sites with URLs which have side effects. For example, while logged into Facebook, a user browses to a forum with an embedded script. When this script executes, it sends a request to another site to perform some action. This could be anything from changing passwords and details, transferring money, purchasing an item etc. This vulnerability could be executed even if not currently logged into a particular site, by making use of authentication cookies. An example of a possibly vulnerable bank website is one which could execute a similar request without authorisation: http://www.myBank.com?action=transfer,fromAccount=12345,toAccount=09876,amount=$1000

The main points in order for an XSRF attack to occur are:

• The site has a URL that has side effects (e.g. changes passwords or details, transfers money, purchasing an item etc.)
• There are no secret authentication values or ID's that the attacker can't guess.
• The site doesn't check the referrer header.
• The attacker must get a victim to browse to a site with the attack script in order to execute it.

• A web application should check the http referrer header.
• Require secondary authorisation steps which cannot be forged. I've seen in certain banks, that secondary authorisation steps are required in order to transfer money by including a unique ID SMS'ed to the owner. This is because an XSRF attack is blind. That is, once a request has been made, the response is not sent back to the attacker and therefore can't authorise the transaction. Note that it is possible to simulate multiple requests by executing time delayed requests.
• For security sensitive requests, ensure that authentication details are provided within the same http request.
• In URLs that have side effects, ensure that there is a unique user token required.
• Limit the lifetime of session cookies.

This is part one of the series detailing the OWASP top 10 web application vulnerabilities. (See intro)

http://xkcd.com/327


An SQL Injection attack is a type of code injection attack where an attacker exploits a vulnerability in the database layer of an application. This can occur when user input is incorrectly filtered for escape characters. Serious system damage can be suffered such as lost data or entire databases, compromised systems etc.

A classic example of this is in login screens. A user could enter a valid username in the "username" field and a specially constructed string in the password field. If this input is not filtered correctly, the database layer could build up a SQL query which returns incorrect results. Eg, an attacker enters "Administrator" in the username field and "anything' or 1=1 --" in the password field. If the user input isn't filtered correctly, the following SQL query could be built up:

select * from user_table where user_name = 'Administrator' and password = 'anything' or 1=1 --'

Now, because (1=1) is always true, the SQL should return all users where username = 'Administrator'. Another important part is the comment characters "--". This causes the database to ignore the rest of the statement, without which the last quote at the end of the string would render the query invalid. This effectively, bypasses the password check and could allow an attacker to log into the system with any valid username. Remember that most SQL syntaxes differ slightly, so there may be many different variants of the above attack depending on the database used.

This is only a simple example, but the possibilities are endless - consider what would happen if the following statement was executed:

SELECT * FROM someTable WHERE someField = 'x'; DROP TABLE user_table; --';

This shows that it is possible to not only construct a query which returns incorrect data, but also to modify databases. It therefore doesn't take too much imagination to extend this to inserting a totally new user into the database or modifying an existing password.

Now, the question is how does an attacker learn the names of the tables or fields that some attacks rely on? Firstly, tables are normally named fairly logically, so a bit of guesswork goes a long way, but incorrect error handling is a dead give-away. A string which deliberately creates an incorrectly formatted SQL statement, will throw an exception from the database. If the entire stacktrace and message is displayed on the page, instead of an error page with a generic message, the select statement may be displayed indicating the table and field names used in the statement. This is the only opening a hacker needs...

So, Lesson 1 - As with CSS attacks, sanitise all input data.

And lesson 2 - Make sure that all exceptions are caught and make sure you handle all exceptions properly. Set up a default error page which shows a generic message.