So what is Clickjacking?   Clickjacking is an interesting exploit since it is not a bug or defect in the browser software, but rather,  a design flaw which will get clearer as we go on. Clickjacking, as it’s name alludes to, is about getting a user to click on something they didn’t intend to click on and are not even aware they are clicking on it.  This is accomplished by loading a web page that has a hidden page or multiple pages behind the web page you are actually seeing.  The way this is done is by placing a “click here” button that looks perfectly fine but “underneath” the button is where a malicious site would place something that might be harmful.  There is a great demo here on the topic of clickjacking where you can see the  hidden page behind the one with the buttons that say “click here”.  They say a picture is worth a thousand words – it’s one thing for me to explain it and another to actually see the hidden page appear.   

One of Robert and Jeremiah’s  examples to demonstrate Clickjacking used Adobe Flash player.  They showed how easy it was to have a user click on something benign that turned on your computers’ video camera (if you had one).  It is a real scary thing for a malicious site to be able to turn on your video camera without your knowledge!  Robert and Jeremiah postponed their talk and Adobe has since taken responsibility and fixed the Clickjacking issue only when Flash-player is the avenue of a Clickjacking attack.  Clickjacking is an issue for all browsers with or without Javascript enabled, since Clickjacking can be accomplished with CSS and DHTML alone.  This exploit, however,  must be viewed within the larger picture.  It isn’t a flaw or a browser software bug but, rather, a complex vulnerability that became real due to the way we’ve evolved with the Internet.   Our browsers have become  more and more complex, which creates an environment where sophisticated exploits can breed and grow and become a reality.  It turns out that the concept behind this exploit was documented as far back as 2002.  However, back in 2002 the internet was a much simpler place and the idea of clickjacking wasn’t much of a threat.  We live in a much different 2.0 Internet world now. 

Application security is a big deal and that is why it is at the heart of the Payment Card Industry (PCI) security standards and requirements.

Requirement 6.6 became mandatory in June and requires the validated security of web-based applications. Requirement 6.6 requires organizations that process credit card transactions to address the security of web applications, either via manual or automated source code reviews or vulnerability scans, or via the installation of a web application firewall between a client and application. In the US alone, there are a huge amount of merchants that not must deal with application security, something many of them have never thought of until PCI made them wake up from their slumber.

There is a plethora of information available on the web regarding 6.6, so it is not necessary to fully repeat that here. But in a nutshell, the application code review requirement mandates organizations to meet this requirement 6.6 via an application code review or automated vulnerability scanning tool to identify application security issues.

The requirement to have a web application firewalls in front of web applications are to ensure that attacks can be blocked before credit card data is compromised. A web application firewall can also mitigate the risk of an insure application, in that it can detect and block attacks before an attack can occur.

Its been known for decades that the basis of nearly every software vulnerability is insecure or poorly written code. Yet for decades, application security has been ignored. PCI 6.6 is the long-awaited wake-up call for application security. Go get your kicks.

Ben Rothke is a security consultant and author of Computer Security: 20 Things Every Employee Should Know.

]]> http://www.itsecpackets.com/blog/2008/10/29/get-your-kicks-with-pci-66/feed/ 0 http://www.itsecpackets.com/blog/2008/10/06/owasp-2008-and-fortify/ http://www.itsecpackets.com/blog/2008/10/06/owasp-2008-and-fortify/#comments Mon, 06 Oct 2008 13:26:17 +0000 Ron http://itsecpackets.com/blog/?p=59 I was fortunate to attend this year’s OWASP  Web Application Security conference in New York city.   It was a fantastic experience where  I networked with some really interesting and nice people, participated in intriguing talks about application security and was introduced to some security vendors who captured my attention.  I chatted with Jeremiah Grossman from Whitehat security.  Jeremiah has contributed greatly to the world of web application security and is well known in the community.  You can visit his blog here.  OWASP, which stands for Open Web Application Security Projects, is an outstanding organization whose mission is to educate organizations and individuals around the world about Web application security through various means including articles, methodologies and tools.  OWASP set an industry standard with their OWASP Top 10 Web application security vulnerabilities.  In a previous post I talked about WebGoat which is created and maintained by OWASP.   In that post I discussed SQL injection, which is one the of the OWASP top ten “vulns” (vulnerabilities).

Fortify was one of the vendors I met.  I had a nice talk with Erik about Fortify and the solutions they offer companies.  As it turns out, unbeknown to me, my company has an enterprise site license from Fortify.  The suite of products is called Fortify 360 and one of the features allows organizations to conduct static analysis of an application’s source code.  Later in the conference I met someone from my organization who also mentioned that we have a site license and told me how to go about getting the Fortify source code analyzer installed on my machine at work.  He also gave me a demo of the product.  I really appreciate his involvement in assisting me with Fortify.  Getting my security fix at work is a big milestone for me.

I wanted to share my initial experience with Fortify’s audit workbench (code scanning product).  My first code scan using this product was WebGoat application.  What better way to prove that a code analyzer is up to snuff than to use it on a web application replete with known vulnerabilities.  It turns out WebGoat is a demo application included with the Fortify product.  I pointed the Audit Workbench to the directory where the WebGoat source code resided on my PC and it started it’s thing.   Below is a screen shot as the scan is taking place:

Ok , here is the summary of issues that Fortify found after the scan completed.

Notice how the issues are broken down by Hot, Warning and Info.  The Hot issues are known vulnerabilities that are considered critical and can be exploited.  You can see the different classes in the left upper corner; Command Injection, Cross-Site Scripting etc.  We discussed SQL injection in the WebGoat application on a previous post so I thought it would be cool to show you what Fortify found for this class of vulnerablity.  I  drilled down into the SQL Injection section and whala! take a look at this!!

Remember that I wrote, “SQL injection vulnerabilities are remedied by sanitizing the user supplied input. “  Fortify found that exact problem in the code; sanitizing user  input was not occurring.  Just in case you can’t read it in the Details section,  it says, “On line 166 of Login.java, the method login_BACKUP() invokes a SQL query build using unvalidated input. This call could allow an attacker to modify the statement’s meaning or to execute  arbitrary SQL commands”.  Exactly what we demonstrated in the SQL Injection post was possible!

Here is another “Hot” issue that Fortify uncovered that I want to share.  Take a look at the  screen shot below:

This is more stupidity than an explicit vulnerability.  In the highlighted  line of code there is a Database connection being made and the username/password is hardcoded.   The reason why this isn’t smart is that usernames/passwords can change often and each time changed would necessitate a programming modification.   I know from experience as a Developer that where, applicable, one should always put config values like these username/passwords in config files.

So far, my experience with the Fortify product has been very positive.  I plan in the future to use the analyzer against my own code to ascertain the vulnerabilities in the code that I write.  As a developer, it is a challenge to meet deadlines and write securely by thinking like an attacker.  Fortify is a good tool to make this possible.

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.

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.

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.