I came across the perfect hands on learning tool that teaches about the common web application vulnerabilities. It’s called WebGoat, an open source J2EE insecure web application created by OSWAP. The purpose of WebGoat is to educate people and organizations on the various risks that are, unfortunately, plaguing our websites. What better way to learn about website hacking than to hack an insecure website with different known exploits. WebGoat has different lessons and some hints that guide the student. It’s a great, fun way to learn web application security. You can be up and running with WebGoat in no time by downloading a zip file that contains the WebGoat code, the Java run time environment and a configured Tomcat 5.5 server. Tomcat is a free Servlet container that implements Java Servlets/Jsp specification. Tomcat also contains a Java webserver. I chose to download the war file and import it into my Java IDE, called Eclipse, so I can analyze the source code. I put my Mac to the challenge; running Eclipse and Tomcat. Using the Mac turned out to be such a pleasure since everything installed and ran smoothly. After installing and configuring everything, I was able to start the Tomcat server from Eclipse and then point my Firefox browser to http://localhost:8080/WebGoat/attack and run the WebGoat application.

Databases are typically used as the back end to web applications. SQL is a query language that is used to interact with the database. SQL Injection is a common web application “vulnerability” that allows an attacker to send data to the back end database. This “string” is then inserted into an SQL query within the application code and executed in the database. If an SQL injection vulnerability exists, then the application may be severely compromised. In some cases an SQL Injection flaw may even allow an attacker to bypass authentication schemes.  In the below WebGoat lesson the student, acting as the attacker, needs to craft some “string” that, when submitted as the “password”, allows access.

 In order to proceed with the hack we will need to alter the HTML or submit the form and intercept the request in order to modify the password field. We can alter the HTML file locally on our computer and then modify the HTML code. We will change the password field to type=’text’ in order for us to see what we type. We will also change the size of the input field (currently it’s only allows 8 characters). A quicker way I found to do this was to use an awesome “Plugin” to Firefox called Firebug that allowed me to modify the HTML on the fly. The other way to proceed with the hack would be to use a tool called WebScarab to manipulate the data passed back to the server. Notice in the screen shot below that you can now see what I typed in the password field instead of asterisks. Also, my password field now allows 30 characters. 

Here is the altered HTML in case you can’t see it :

<input type=”text” maxlength=”30” size=”30” name=”password”/>.

Why did the “password” I used admin or ‘1′=’1 allow me to logon and bypass the authentication? We need a little background first on basic authentication for websites. The “password” supplied by the user needs to be verified that. indeed, it is the correct password for this user and whoever is logging on is who they say they are. This is done by querying the database and passing the supplied “password” as a parameter to the query. Here is a simple SQL statement that might be constructed in a web application:

SELECT * FROM user_data WHERE password = ‘?’ and username=’admin’

If the query returns the record from the user_data table then we have a match on the user’s supplied password. If there is no match, then the authentication should fail and a message should be sent back to the user as “Login Failed”.

Now let’s substitute the “password” I supplied into the query:

SELECT * FROM user_data WHERE password = ‘admin’ or ‘1′=’1′ and username=’admin’

The or ‘1′ = ‘1′ makes the entire query true, which returns the user admin record and bypasses the logon scheme. With this crafty string we have successfully exploited the SQL injection vulnerability. SQL injection vulnerabilities are remedied by sanitizing the user supplied input. In the above example, if the server side code had some kind of logic to reject the single quote, our method of attack would have been foiled. In fact, there should be a series of validations for the characters that are white-listed versus those that are not allowed and in this way, an invalid character would be stripped out. The fundamental concept here is that only server side code can thwart attacks such as the SQL injection since, as we demonstrated, the client side code can be easily modified. That’s why it is essential that all input validation is performed on the server side. With some knowledge of these types of attacks and diligence at the development phase, SQL injection vulnerabilities can be avoided.

Today we’re going to continue our discussion on the Yubikey from Yubico. I received mine in the mail a few weeks ago and had the opportunity to play around with the device a bit. Many people were attracted to the Yubikey because of it’s cool, tiny keyboard - so they ordered them. When it arrived they plugged it into their computers and touched the green surface which then spits out a 44 character encrypted one time password. That’s all nice and very cool but now what? How can this very innovative security token that is a tiny USB keyboard be put to good use? I, therefore, devised a way to prove that this cool token can really deliver. My plan was to customize this blog’s “admin logon” and incorporate the Yubikey authentication as an added layer of security.

Good news, Yubikey authentication is open source! This means that developers are able write code both on the client side as well as the server side to leverage the Yubikey in their own environments. There are not too many options for do-it-yourself hardware authentication solutions! Yubico offers sample code in a variety of languages that can help you get going. You can also authenticate against Yubico’s authentication server, hosted by them. This would come in handy for companies that plan on implementing their own server authentication, however, are not there yet and would like to test their client side code. In my case I decided to authenticate against Yubico, since it’s simpler and quicker. There is a downside to this approach that is worth mentioning. If I wanted to log onto my blog’s “admin panel” and for some reason the Yubico authentication server was down, I would be locked out of my blog’s admin panel.

This blog uses Wordpress, the popular open source PHP blogging software. Modifying the admin logic to include the Yubikey as a 2nd level of authentication was very easy. I utilized the code written for PHP. First, I dropped in the Yubico class on my server. I then added in some code to the wp-login.php file.

Here is the function that calls the Auth_Yubico class:

function verifyYubikey ($token) {
global $error;

$yubi = &new Auth_Yubico(’77′,’5dFRPaFvjBvwiiB023ZWu4Qb++U’);
$auth = $yubi->verify($token);
if (PEAR::isError($auth)) {
$yub_error = $auth->getMessage();
$error = __(’<strong>ERROR</strong>: ‘. $yub_error);
return false;
} else {
return true;
}

}

Here is where I modified the logic for logging on in the wp-login.php file.

if (verifyYubikey($user_yub) && wp_login($user_login, $user_pass, $using_cookie)) {

I verify the yubikey string prior to verifying my static password so people can try it out by putting in a password and see what errors are returned back from Yubico’s authentication server; more on that shortly…

So, how does the Yubikey work? We talked about asymmetric encryption in a prior post. Each Yubikey contains a unique private key that encrypts some data, turning it into the encrypted OTP (One Time Password). The Yubikey uses a conversion scheme to ASCII, which they call mod-hex. The 44 character blob is made up of 12 characters plus the 32 character OTP. The first 12 characters never change; they are your Yubikey’s unique id. So you have the 48 bits plus an AES encrypted 128 bits sent over to the authentication provider (in my case, the Yubico server). Yubico then does a lookup with my unique 12 characters and pulls the “public” key to do the decryption. Now, if the authentication side is able to decrypt this blog then you are successfully authenticated. After decryption you have 128 bits of cipher text. Besides containing your unique id, the cipher text also contains some additional useful information about how your Yubikey has just been used. For example, the time-stamp of when the OTP was generated is included, as well as a session “use counter” showing how many times you generated an OTP. This information can be used to thwart some sneaky phishing attacks. Another thing to note is that your secret AES key in the Yubikey is never able to be read out; nothing you can do to the device can force it to give you it’s secret key. All in all, this hardware solution is extremely secure.

Below are two Yubikey passcodes generated from my Yubikey that I used to authenticate myself when creating this post. I highlighted the first 12 characters, my unique serial number indentifying my Yubikey. You can copy and paste the string in the Yubikey field on my admin page and then type in anything for the static password (logic for verifying Yubikey is done prior to the static password as you can see in the PHP code above).

jdteklknnhcffbfgjebejhbbgnrtrevingnldlctiulj
jdteklknnhcfnfidtedkcelbrkvngurddrclghnidgfh

To make sure the responses come from Yubico, they offer you the ability to create an id with a shared key. When you authenticate, there is an extra field returned to which you can apply a signature algorithm. To apply this algorithm you use your shared key to validate that the response actually came from Yubico. In the code of the “verify method” above I included my id of 77 and the shared key that was assigned to me. I just tried changing the shared key by adding a “1″ to the end of that string and wasn’t alerted that my signature algorithm failed; which it should have done. Perhaps I’m doing something incorrectly; feel free to comment. I’d like to say thank you to Simon from Yubico who was responsive to the questions I posed. Yubico also set up a forum where you can learn more about Yubikey.

I’ve been reading and learning about web application security lately. As a programmer with experience in web redevelopment, I thought web application security would be the perfect place for me to get my security fix. I’m finding it very interesting. I decided that a good place to start learning was with my blog application; how can I better lock down this blog. My blog uses the very popular open-source blogging solution called Wordpress. Recently I found a posting on Matt Cutt’s blog on some things you can do to secure your Wordpress blog. Let’s discuss one his simple recommendations I implemented.The first thing I did was create a .hatches file in my “wp-admin” directory.

AuthName “Access Control”
AuthType Basic
order deny,allow deny from all
# whitelist home IP address
allow from 71.172.62.228

The .htaccess files are also called “distributed configuration files” which allow you to restrict access to a particular resource in a web application. If you have access to the main configuration files (usually httd.conf) on the server it is better to make theseconfiguration changes there, since modifying the .htaccess file may cause your application to take a performance hit. My blog is hosted in a shared environment and therefore, I don’t have access to the main configuration file. My .htaccess file essentially blocks everyone (all IP’s) from accessing the www.itsecpackets.com/blog/wp-admin directory unless the TCP connection is made from the IP specified, which is my home IP address. When I access the admin page as the admin, I will still need to enter my username/password. This solution gives me another layer of security. Now keep in mind, with security comes a loss of convenience. I will not be able to logon to my Wordpress admin panel from work (unless I add the IP address). The same applies if I’m at a friend’s house. There are always trade-offs when it comes to security - always.