NLIGHTEN
Arun Ram
Behind
Kumar
Enemy Lines
To protect your client information, it is necessary to delve deeper into the hacker’s mind.
C
orporations open up to the online world in an effort to increase their customer base and they are dependent on technology to manage their data. With this comes the responsibility of protecting customer information. Ensuring that their physical premise and local network is secure, won’t suffice – the danger of a school kid retrieving customer information stored in the company’s website is very real and we hear such news very often. A London school student, in October 2010, published 27, 000 passwords that he got by hacking his school’s website. This was just a school, but there have even been cases of hacking which led to credit card numbers being stolen as well. The word ‘hacking’ piques curiosity in even a non-technologist. Hacking is regarded as belonging to an elite group of genius programmers who can take control of any system, destroy any data they wish, crack passwords for any email ID and even place their own content on websites belonging to corporations and governments. In simple words, hacking means to get unauthorised access to data and hackers generally take advantage of some flaw that is present in the software application. So how do hackers break into systems? There are numerous ways depending on the system being used and we’ll start with some basics on protecting data and loopholes in systems. And since it is websites that provide the public with
a means of entering corporate networks we’ll focus on them.
Storing passwords there In this highly networked world, everyone is a customer to someone. All data in the corporate world resides on databases - user names, customer address information, email IDs, mobile numbers, credit card numbers, bank account numbers and even passwords. And getting to the database is what a hacker would love to do. It is quite common for many people to use the same password for multiple websites and accounts. So how comfortable would you feel if your password is stored in a database - a database that can possibly be accessed by many employees in the company that runs the website, a database that if compromised would reveal your password that could be used to access your other online accounts. Till biometrics identification systems become cheaper and easy to implement, verifying users on websites will continue to be done using passwords. So how does the system verify that a particular user is the person they claim to be? The system asks the user for the login - ID (which could be known to the whole world – like an email id) and the password (which should be kept private by the user). The system then asks the database, “Do you have a record which has this userid and this password that the person has supplied?” If a record is found, then it al-
lows you to enter the system. So who all could potentially view your password? Any person who has access to the database can see it – possibly anyone from the technology department. This makes your password 'not so private' anymore. Till biometrics step in, passwords are like keys to your locker -- you don't want anybody else to get your key; not even the person who designed the website that you use.
Hashing passwords So what is the solution? Don’t store the actual password – instead convert the password and store the converted value in the database. So if your password were: thiscannotbecracked it might get stored internally as: asf980-09131#3414MAoWQ[]afa^& The process of converting the input password to a hash key using an algorithm is called hashing. Given the hash key you cannot find the original password; it is a non-reversible algorithm and there are many hashing algorithms available. Most websites employ hashing when storing passwords. So even if someone stumbles upon the hash key for a user id, they will not be able to guess the actual password. When the system needs to verify a user, the system would take the password entered by the
user, apply the hashing algorithm and compare the generated key with what is stored in the database for that login-ID. A match means the user has used the right credentials. Encryption is also a process for converting a given text to something unrecognizable. But encryption is a reversible process while hashing is not. Is it foolproof ? Not really; if someone happens to see the hash key in the database, the only way to find out the actual password is by trial and error – since hash algorithms are public algorithms, a hacker can keep trying a random set of inputs through the hash algorithm and compare the output produced with the hash key. If a match is found then the hacker knows what your password is. Obviously this cannot be done manually - what a hacker does is create a program that will keep trying different combinations through the hash algorithm and try to find the match - this method is called brute force! Though it is breakable, the key here is that the hashing algorithm needs to be strong – weak hashing algorithms like LM Hash take a brute force program only a few hours to find the password. Stronger algorithms are the SHA1 and SHA-2 (Secure Hash Algorithm). The stronger the algorithm, the longer it will take to find the password; and if it is going to take a couple of years to find the password, then that is not of much use for the hacker. The whole idea of hashing the password is to ensure that even if the database is compromised, the hacker does not get passwords which can be used elsewhere. How do you know whether a system employs hashing while storing passwords? Simple -- just go to the "forgot password" link and in case they email you your original password you can be sure that there is no hashing being done. Websites that use hashing will reset your account with an internally generated password because they do not know what the original password is.
your password or logging into a system, you are interacting with the database. For a hacker, this provides a small window of opportunity to test the database and if possible cause some damage.
the application is discovered. The hacker could insert SQL statements that even delete records or databases and wreak havoc! Some databases disallow execution of multiple SQL statements in one call but most databases do.
Any application performs database operations (reading and writing) using SQL (Structured Query Language). You can consider it as the language used to interact with databases. Whatever information we type into textboxes is used to build an SQL statement and then passed to the database for execution. So a login page might construct an SQL like this: Check if there is a record on the database where
And you might think that this only allows a hacker to gain access into a system -- but this can be modified further such that data from the database is returned. The hacker will try to form an SQL that he knows will fail and the resultant error message thrown by the system will give him the details of what he is looking for! Yes, there are a lot of applications out there that throw database errors back to the user instead of giving a customised error message that might say "Operation cannot be performed". Database errors when propagated back to the user can be used by a hacker to learn details about the database and this information will aid him in fine tuning his attempts at hacking the website.
Questions to ask your software development team: • Are any passwords being stored? • Is the strongest available hash algorithm being used? • Has the application been tested against SQL injection attacks? • Are customised errors sent to the user when system errors occur?
user = 'userid-textbox-value' and password = 'password-textbox-value'
Injecting code into databases
The values come in from what the user types and SQL injection/insertion is a technique where a hacker tries to insert his own SQL statement. For instance, if the user gave the password as: ‘dummypassword' OR 't' = 't’ the SQL constructed by the application would be: Check if there is a record on the database where user = 'user-textbox-value' and password = 'dummypassword' OR 't' = 't'
Keeping passwords safe is a priority. But this is not all -- there is a lot more that resides on the database than just passwords. Any mechanism that breaches the database of a system is a potential threat to client information. Do you know that every time you fill up textboxes on a website and hit the submit button, you are most likely interacting with the database on that system? Be it doing a registration, resetting
The new condition inserted is 't'='t' which is always going to hold true and so the database will say, "Yes, I do have a record for this SQL statement." Now the application thinks that this is a valid user because there is a record on the database and this enables our hacker to enter the system. There are more frightful things a hacker can do once this weakness in
The weakness is because of the way the application is coded – the application is permitting special SQL characters (like the double quote in the above example) to be passed to the database. Robust applications will perform strong validation on user entered values and there are techniques by which SQL injection can be prevented. The techniques are well documented. There have been SQL injection attacks for years and it still continues to be used by hackers even now. Protecting against this might seem to be something basic that every programmer should handle. But even this year there have been credit card identity thefts in Japan and China using this technique. It just goes to show that just because something is well documented doesn't mean that everyone knows about it! What we have seen is just a small pie of the data security threat that companies face. If you happen to be involved with anything concerning client data, the adage “Do unto others what you would have them do unto you” holds very true. A breach can ruin trust in your company. Protect before the damage is done.
Sethu Subramanian
10
11 The Business Enterprise | Feb 2011
Feb 2011 | The Business Enterprise