I came across an interesting application today. Google has released an application named Jarlsberg that is full of security holes. The intent is to make developers learn how these holes work and put them in a position to combat the security vulnerabilities.

You can visit the app to learn more. Security flaws to be detected are classified under the following categories

• Black box. You dont know the code
• White box. Requires you to see the code to understand how to break it.
• Gray box. Some code will be made visible.

I also came across an instructor’s guide that has problems to be solved in the application, graded by their difficulty level.

What better way to learn an exploit than to perform it on a test system ? Some of the exploits involve

• XSS and related challenges
• Path traversal exploits
• DOS
• Buffer overflow
• SQL Injection

and so much more. Give it a try now

There are times when you work with SSL traffic. Your website might be protected with a certificate so that traffic between you and the client is secure. At times like this, being a developer is troublesome. Browser cache settings need to be analyzed by looking at the HTTP headers. Encoding / Content type may need to be analyzed to ensure that a particular page is displayed correctly. These things cannot be looked into if the traffic is secure. There are situations under which the environment is secure but you must still sniff the data. So how do you manage this ?

Tools like Charles (A debugging proxy) help you do this. Charles allows you to proxy to a secure connection over a protocol like HTTPS and still read the traffic. So how does it do this ? Lets have a look.

Your environment probably has a self signed certificate like the one issued below, using keytool.

keytool -genkey -keyalg RSA -keysize 1024 -alias example.com -keystore mystore.ks -validity 9999
 
keytool -list -keystore ./mystore.ks -v
 
Enter keystore password:  changeit
 
Keystore type: jks
Keystore provider: SUN
 
Your keystore contains 1 entry
 
Alias name: example.com
Creation date: Dec 21, 2009
Entry type: keyEntry
Certificate chain length: 1
Certificate[1]:
Owner: CN=www.org.com, OU=Org, O=SomeCompany, L=Somewhere, ST=Someplace, C=US
Issuer: CN=www.org.com, OU=Org, O=SomeCompany, L=Somewhere, ST=Someplace, C=US
Serial number: 4b2ef9e0
Valid from: Mon Dec 21 10:00:24 GMT+05:30 2009 until: Thu May 07 10:00:24 GMT+05:30 2037
Certificate fingerprints:
MD5:  XX:XX:XX...
SHA1: XX:XX:XX...
 
*******************************************
*******************************************

When a certificate like this one is presented to a web browser, it will look like so. Let’s extract the certificate and open it up.

keytool -export -keystore ./mystore.ks -file ./testtex.crt -alias example.com

Untrusted self signed certificate:

Our certificate is obviously not trusted since it is self signed. A certificate signed by a CA will not exhibit a security warning. Like the one presented by google for the gmail login page, which is shown below

Trusted certificate from google.com:

When you start a proxy that has HTTPS support, say charles for instance, it does the magic by inserting its own certificate into the certificate hierarchy. The Charles CA Certificate, now becomes the root certificate in this hierarchy, allowing it to decrypt the information that is sent between the client and server.

Modified certificate hierarchy:

Charles signs the certificate that google presents, so it will now be able to decrypt the information that is sent by the server. However the side effect is that your browser will no longer trust this certificate since the root CA is not in your trusted store.

Untrusted connection due to modified hierarchy:

You can get over the problem by importing the certificate or installing it into the MS trust store. This is one technique that proxies use to debug traffic. Know of another method / proxy software ?  Leave a comment. Happy debugging

Let me begin this post by saying that I am not writing this so that you can read this and become a haCkEr. I am writing this post so you can learn to identify a vulnerability and try to avoid an embarrassment.

Google is an amazing search engine. The problem is that it is too good at what it does sometimes Here are some ways that google can reveal vulnerabilities on your website by mistake.

You allowed google to index a critical file:

This happens more often than you think. WordPress for example houses important files under the wp-* folders and it is no one’s business except yours to look at these files. Other files like .htaccess htpasswd are critical to your site’s security (if you are using apache and ‘allow overrides’). Do not allow google to index them. You can prevent that by placing a robots.txt file on the root path of your website. More on that here.

The better option is to put in place a configuration that will not allow the sensitive file to be displayed in the first place. Not all robots will obey what you instruct using robots.txt. The FilesMatch directive on apache can help you protect your site.

You can double check that google can read your robots.txt using google analytics. You can check the files that google has indexed using the query‘site:yoursitename.com

Google indexed a service page that is being served on a non regular port:

Examples of this are login pages or services that do not require a password. Searching for such pages can be done using the “inurl” keyword in searches. Here is an example inurl:8080. There are ways to tweak that search string to reveal more information about services on other ports. When you complement inurl:something_unique_in_the_url with a search using quotes, like inurl:1234 intitle:”Administration blah”, it can yield some very interesting results. Pick your favorite admin tool and replace the port and title with the admin home page equivalent. The search works on many major application / web servers.

Remember that google indexes your page. Even if you correct the problem, the damage is done and is still being done. With cached pages, a service that does not ask for user name and passwords (yes there are important services that do not require a username/password) will be completely indexed. Yikes ! The data that your service exposes is cached and indexed for everyone to see. Not what we want.

To avoid this simply shutdown services you do not need. If you need a service but you want that service to be private, block the port with a firewall.

You can optionally tell google bot and other bots not to index the page in question. But that is not really a solution. Be proactive and secure the service. A cached page can end up earning you some DOS attacks.

Google cracks MD5:

I realized that google could be used to crack weak passwords from this post. If the encryption is done without salting, the password will result in the same hash every time. A weak password can be guessed easily using this technique.

The lesson here is to use a strong password that no one will guess. The other lesson is to ensure that the links on your site do not pass along sensitive information. Here is the google search in case it interests you

Cached directory pages:

Your web server is quite capable of displaying a directory listing. What this means is that besides displaying HTML, if I were to request for a directory name instead, your web server will reveal the contents of the directory to me. Why is this bad ? It helps find more vulnerable files that are housed inside those directories. You can ask apache not to serve directory content by configuring the same in httpd.conf. The line of configuration will look something like this



Options Indexes FollowSymLinks
# More stuff here

Remove the word Indexes.

The related search query in google is intitle:”index of /”. Tweaking it will provide better results.

Before you make any configuration changes, always make a backup. Read about the changes you are making and understand what you are doing before you do it. Try these tricks on your site and check if it is secure. Be creative. Think about other sensitive terms like jsessionid, username, passwd, password, id etc.