Broken Access Control

Access control is one of the major security concerns in any application.  Elevated access to a system may result in disaster ranging from lost data to bringing the system down for some time. It is possible to overlook the access control scenarios that are horizontal in nature. Most developers effectively check for administrator privileges within the escalated code blocks.

In this case, I, as an attacker, will try to look at my profile or any previous order.  When I check my profile I would not be logged on to the system with my used id and password but I will break in without an authentication token.

If we look at the application, there is a major problem in the ‘Forgot Your Password’ option. The screen does not ask for any information from the user except the username. In a real-time application it might not be a problem because the password may be sent using a different channel such as e-mail, but in this case the problem is that the attacker comes to know that database interaction is taking place just with one reference to the user name.  This has the ability to cause a serious security issue.

Sometimes the developers might leave comments in HTML code that is in JSP. Often the confusion is mistaking HTML for JSP comments. To start this attack we need some additional information.  We will need to have a couple of user accounts on the system and will need to complete a couple of purchases.  This will generate the seed data for the underlying attack.

The accounts must be created on the system so it is obvious that we will create bogus accounts, here I am going to create two accounts named test and hacker.
First I will logon with the test account, we have not made any purchase using this account, so if we click on view orders we will see the screen with message that explains that this user has never purchased anything.

Browse Orders Screen for user ‘Test’

Now we will try to see the records for the other user name that we created, because nothing has been purchased by the ‘test’user, we’ll try getting information for the other user ‘hacker’. To do this we just go ahead and modify the contents of the address bar to point the other user we want to see the orders for.

Insecure Direct Object Reference

The url to view the previous orders of user with user name ‘hacker’ would be:

http://localhost:8080/HacmeBooks/browseOrders.html?userId=hacker this will display all the previous orders by the user ‘hacker’. So the theory was correct and we were able to bypass the access token needed to view the previous orders placed by a user. If we have a look at the result, the screen contains the credit card numbers as well that can be misused.

Retrieving the other User Data  

This attack scenario highlighted two major problems during working with this application.  The first was that developer left comments in source code that provided the attacker with the clues necessary to launch the attack.  In fact, that was the platform to launch the attack.

Second, there is no horizontal privilege check.  So instead of the user who made purchases, the attacker was able to view the data by sending a manipulated http request in URL of the application page.  This is a classic example of the OWASP Insecure Direct Object Reference web vulnerability.

Cross Site Scripting Attacks

A Cross Site Scripting attack is most commonly used for luring attacks (i.e. to take the user to another site or page by using an injected script tag in the HTML). Cross Site Scripting, or, XSS, works by entering <script> alert() </script>. The most common use of this vulnerability is to steal the sensitive information from the user system, this can be the cookies from the site written on the user system to provide personalized contents and/or auto login features. A typical XSS attack is regularly part of Social Engineering techniques used by hackers.

Use of <Script> </Script> Tags in XSS attacks

In the above picture I have used the <Script></Script> tags to write a small script which when executed will prompt the user with a small message box. There is not specific function being performed by the script generated Message Box, but if an attacker wants he/she can run the OS level commands with privilege of the user working on at that time. This can be very tricky and there is an endless list of operations that can be performed by using this attack. For example, the user can be redirected to another site, the hacker could delete, add or modify some information on the user’s system, even the sensitive login information can be sent to a different website than it is intended for.  You have now inserted a “persistent” or “stored” XSS into the server in the location of user feedback data.  Now whenever someone views the page for that book, your user XSS “feedback” will be run in the browser of the person viewing it.  Generically, it will look like this:

Though this is just a message box that does nothing more the asking the user to push the ‘OK’ button and as soon as user does that, the box will go away and the user will return to normal screen. This can be used when we need some user interaction to perform a malicious activity on the user system. Most of the remote code execution vulnerabilities found in the browsers make use of XSS to do that.

Cryptographic Attacks: “Crypto Wannabe”

Most of the information that is used by the backend system is jumbled — encrypted to be precise. In this application, which is an online book store, there is a discount of 15% to 25% on all the books purchased during a given time which means the discount on purchase is a limited time offer.

So an attacker goes to website like any other user to buy a book. The limited period discount offer was not there when the site was created for the first time, so the developers must apply some code to provide the discount on purchase for a given period. The amount of discount depends on various factors which may vary from one user to another, but we are not concerned with that scheme at this time. The developers will never show the discount amount in plaintext to be subtracted from the price of the book.

There has to be some way for the application to understand what amount of discount has to be given on any given item.  Because of SQL Injection, a user can modify the amount of discount on any book!  For example if a book is offered on 15% discount the attacker can manipulate the data in such a way that system would end up giving 25% discount on the book which was eligible for only 15 %. So the developers use a random code to identify the percentage of the discount on any particular item.

For example

• • 15% -
• o AEODBOBOOE
• • 25 % -
• o BEAAABBOOE
• o BEOABDBOOE

If we stack the codes one on top of the other, we will get some interesting information that will be very helpful to manipulate the discounts. We are looking for the method used to jumble the discounts to make a distinct value for 15% and 25%.

A careful look on the codes below reveals some interesting information.

AEODBOBOOE

            BEAAABBOOE

            BEOABDBOOE

The last four letters in every value are the same. In two values, the first two letters are again the same. Two out of the three values are for 25% and one is for 15 %. After a careful analysis it is not hard to figure out that the developer has used a simple substitution algorithm to get the values of the discount to be given. Now, let’s start to understand the algorithm ,we will start with last four digits. The last four digits are the same in all, a Year also has four digits and they will remain same throughout the year so let’s try ‘2005’ instead of the BOOE in all the codes and see what we get.

BOOE – The alphabet ‘B’ is the second alphabet so let’s take it as a representation of the number 2 (we get this by placing 2005 on top of BOOE and then comparing corresponding digits and letters). The letter E is taken for number 5. O represents Zero in actual number. The other letters can be replaced by their corresponding numbers derived from the above rule. When we do this let’s see what we get?

AEODBOBOOE – 1504202005 is the decoded form. Let’s see what this means, there are couple of things hidden in this code, one is the date (time bound offer), percentage discount. So the value we get would look like:

Discount      Month    Day    Year

15                 04          20      2005  — this is how the developer implemented the discount algorithm that takes care of the date as well because it is a time bound offer and beyond the specified date, no discount should be given to any person buying any books. Now that we have the method, it is possible to get as much discount as we want and whatever we use would be validated because we know how it works and we can put in the values straight in a custom HTTP request. For example if I want to get 95% discount I will make the code –

95                 04          20      2007 – IEODBOBOOG — so by using this value I would get a discount of 95% on whatever book I want.

I will use the coupon created by breaking the algorithm used to buy a book on 95% discount. All I need to do is that go to the site and add the books I want to my shopping cart. Proceed to checkout and enter the discount code I created in the discount coupon box to avail 95% discount.

Used 95% discount code in the check-out screen

Total Amount payable is just $ 5.41 (95% discount)

Join us next Monday for the last in the series on Hacme Books.

Denial Of Service Attack

Security should provide CIA (Confidentiality, Integrity and Availability). When an attacker attacks the system he/she will compromise one or more of these attributes. In here I will be discussing the Denial of Service attack.  I will be using SQL Injection as the basic attack techniques.

The attacker had the information on how to attack the Hypersonic SQL prior to starting the attack (Google is the best tool available to hackers) by using extensive searches on the target system. For example an attacker can search on Google about how to shut down Hypersonic SQL server.
Most of the SQL Injection vulnerabilities are a result of concatenating the SQL statements including the user input taken using the application interface. Let’s see what a normal SQL statement looks like where we will use a value that is to be input by user at run time:

String Query = “Select * From PRODUCTS  Where Criteria = (USER INPUT Keyword)

The above code takes input from the user and processes the keywords into an SQL criteria via some method that iterates over the tokenized input. So the attacker can maliciously insert extra SQL statements.

In this case since we are creating a DoS attack, we will insert the SHUTDOWN command. A correct SQL statement code generated by the application would be like:

select * from products where title like ‘%USER KEY WORD%’ and like ‘%USER INPUTTED KEYWORDS%’
Planning the Attack  The attacker know knows how the SQL statements works, the attacker can now start manipulating the user inputs in SQL statement. Now to make it an effective shutdown statement should be like:

select * from products where title like ‘%’; SHUTDOWN; –% and like ‘%USER INPUTTED KEYWORDS%’

In SQL the symbol ‘-‘ is used to mark comments so the statement after – will be ignored by the SQL interpreter and the result of the query would be a system shutdown. Here is how I used this to shutdown the system and achieved a DoS attack.

DoS Attack using SQL Injection

To start with, just type in user input parameter in the search box, but this will not work because it does not cause a DoS, to get around this problem we used the search engine properties, the search engines generally tokenize input into separate pieces for methods like createCriteria(), Since we know that using a ‘+’ symbol in a search engine make the engine treat the input as one keyword so to tweak the attack we just put a + symbol in the search box.  As a result, the SQL attack that works is:  ‘;+SHUTDOWN; –

You should see output that indicates the database has been shut down:

Database Shutdown

Data Tempering with SQL Injection

Note: For this section you will need a valid user account to continue.  Use the Signup link on the main page to create a new user.

The Second type of attack I am going to work with is also a variant of SQL injection. This time we will not force the system shutdown but just modify the data; or Data Tempering. I will try to add a book title on the website (the book actually does not exist). This will cause a rather embarrassing situation for the website and online book store.

To modify the data within a database table the attacker must know the database schema which means that structure of the database table and organization of the data within the tables.

To add a new title in the database when there is no such title available, here again I used the SQL injection but I had more detailed information about the database schema.

Modify Data Using SQL Injection

I will search for a title that I know is there for sure for example I searched for a book with title “HACKING EXPOSED” and I get the above screen.

Now we have to add a new title. Look at the feedback section, a user can leave the feedback for the title there; I used the Feedback input box to enter a SQL query to add a new title to the products table. It a typical insert query used in SQL, all we need is the name of fields and data type so that we can add the information without causing any errors during the query execution.

Here is the command to use:

my feedback’, 735); insert into products (title, description, popularity,

price, vendor, category, publisher, isbn, author, imgurl, quantity)

values (‘Eat my shorts you pointy haired boss’,'A great

book’,4,29.95,’Amazon’,'Technical’,'Addison

Wesley’,’1234567890123′,’Disgruntled Employee’,'http://’,1); –

The above query when executed will insert a new book in the table Products with

TITLE – Eat my Shorts you pointy haired boss

Description – A Great Book

Popularity –   4

Price          – 29.95

Vendor      – Amazon

Category   – Technical

Publisher   – Addison Wesley

ISBN        – 1234567890102

In the SQL as I mentioned earlier the symbol ‘-‘is used to mark a comment, so everything after the – will be ignored by the SQL interpreter. Using the SQL injection I will search for the newly added title and find the entry for a book named “Eat My Shorts you Pointy Haired Boss”

Search Results for newly added Title

So the purpose of the attack was accomplished, we were able to add a title to the database of the book store. The newly added book does not even exist and has an embarrassing title.  This will sure make people think whether they want to purchase a book from this site or not, because the integrity is compromised.

Join us next Monday for the fourth in the series on Hacme Books.

Vulnerability Testing 

There are two approaches to Vulnerability Testing; White Box testing and Black Box testing. The White Box testing provides more accurate results because the source code is available, going through the code makes it easy to find the loopholes in the code and login flow.

On the other hand the Black Box testing is suitable for all non developers, because in this case the source code is not available but just the application interface is provided as it would be to a normal user after implementation. In the current scenario we will be using Black Box testing. 

However, if you want to try the White Box testing, the source code can be downloaded.  I have used some information from the White Box testing techniques. I will call out specifically whenever an important piece of information is extracted by studying the source code of the application.

During the testing of this application we will use two different attack scenarios:

1. 1) as a normal user using the application, and
2. 2) from the Internet using a web browser.

One thing worth remember is that there are different approaches to complete the job. I have tried to follow a generic approach to break in starting from collecting information to actually breaking into the web server. We will start checking the application for known vulnerabilities in the web applications, by checking the system if a particular vulnerability is present in the system that can be exploited and how a developer can make the system secure by eliminating the vulnerabilities.

To attack a system, the attacker must have the enough information about the target system. More is the information available to the attacker the more successful will be the attack. The easiest way to find the information about a system is by studying an error message returned by the application.

An error message is returned when a fault condition is encountered during the execution of an application module. The error message tells the user about the error description and what caused this fault condition.

To start with, an attacker can try to create a fault condition and study the error message for extracting the information. Most common method of creating a fault condition is to provide an invalid input to any of the parameter.

All the developer can do is to make sure the user is provided with the least amount of information as possible by the error message (the error message can be restricted to a more generic statement just telling the user that an error has occurred and what caused it). The developer will have to trap an error condition and return a custom error message instead of presenting the user with the complete message returned by the back-end system. Unfortunately though, this is not possible in all the cases.

To see what information we can get from the system is by creating a fault condition, usually this can be done by giving invalid or wrong input to any of parameters. I have used the search box in the home page of Hacme Books,

Invalid Input in Search Box

Just put a single apostrophe in the search box.  The developer did not expect such a condition, so the system was not prepared to display an error message caused because of inputting a special character in the search box.  The result is a complete description of error and block of code written to handle the search function. The error message is as :

Error Message Returned By the Application for Invalid Input to Search

After the attacker hits the Search button, a considerable amount of information is returned. We used one fault condition and the information available is very important, by exploiting this fault condition, we now have following information about the target system:

• • Database Type: – The database type is very important because, it will provide the attacker a platform to start from. Every technology/application has some known and unknown flaws that can be exploited in one way or the other. The type of database system used is Hypersonic SQL (whole lot of information can be found and known flaws and tools for hypersonic SQL by searching on Google.com).
• • Application Server:- The application server is the platform where the target application is running. The Application server in this case is Apache Tomcat.
• • Other filters that are running in the servlet stack.
• • The java name spaces mean that this is a J2EE application.

Now that we know enough about the system we can start launching the first attack on the target system. In almost all database dependent applications the most common type of attack is SQL Injection.

If we need to write or retrieve data to and from database tables we will use the SQL Injection (SQL Injection is more of trial and error approach). SQL injection is the process of inserting special SQL characters in the application input flow of an application. This is achieved via HTTP requests.

Since the attacker is aware of the type of target system, an attacker can analyze various SQL construct supported. The SQL Injection flaw causes different effects on the target system depending on the context used by the attacker, this means that there can be several variations in terms of the final state of the system.

Join us next Monday for the third in the series on Hacme Books.

Hacme Books

The Security of web applications is a big concern in today rapidly growing size of the Internet. The internet is no longer only used to send just e-mails and chat, the online shopping enable the seller to reach the remote user where there is no other way to reach them.

E-commerce applications involve financial transactions such as credit card numbers and bank account details, so the security of the application and application data is critical to make an online business successful.

Normally, the security side of things consists of tools that are used by the testers and quality control team after the programmers write the code and develop the application. It is usually difficult for the developers to figure out if the code they are writing is secure or not and normally this is discovered only when the application is ready to be deployed.

Hacme Books is designed to enable the programmers to write the secure code. This allows the developers to setup a standard procedure for writing source code in J2EE applications. Hacme Books is a fully functional application for an online book shop written using J2EE.

This application includes some well known vulnerabilities. Hacme Books follows an MVC architecture that leverages the inversion of control design patterns to drive factory configuration.

1. Installation

Hacme Books comes in three formats: Windows binary executable, J2EE WAR File, and Complete Source code. I used the Windows binary executable file available here: http://downloadcenter.mcafee.com/products/tools/foundstone/hacmebooks2_installer.zip  The downloaded file is in .zip format, the zip package contents contain the exe file for installation and user guide.

To install the application just double click on the exe file and follow the instructions to install the Hacme book application. Before starting the installation make sure that JDK is installed on the system.  If it is not the installation will be aborted and setup will take you to the Java download site, download it from there and then again run the installation package.
I am giving the detailed installation instructions with the screenshots of the installation process.

1. 1. The first screen that displays when the installation package is run is the License Agreement, to install the package we must click on I Agree, if we do not agree, the installation will abort.

1. 2. Next, a screen appears warning users that Hacme Books purposefully introduces vulnerabilities to your system for testing reasons and that Foundstone accepts no liability for system compromises.  Click Next.

1. 3. Leave the default option checked for install location. By default the install location is C:\Program Files\Foundstone Free Tools\Hacme Books 2.0

1. 4. The installation will begin copying files and the progress indicator will show the progress of the installation.
2. 5. Once the installation is finished we will go ahead and test the installed application. Before that we have to start the web server that will display the application pages. It can be started by double clicking the startup.bat file in the Start  All Programs  …  Hacme Books Server START or directly from the filesystem location at …\tomcat\bin\startup.bat.

The application can be verified that it has started by doing a ‘netstat –ano’ and looking at new listening ports:

1. 6. After successfully starting the tomcat server, open the web browser and go to http://localhost:8989/HacmeBooks , this will give the home page of the application. This is the starting point of everything we will be doing during this session.  If the page times out and does not load check your browser proxy settings!

HacmeBooks home page

Home Page

Join us next Monday for the second post on Hacme Books.

Cookie With SessionID Before Login

Generally, a cookie is encrypted so only the site that created that cookie can read and get information from that, but if the encryption method used is not secure the cookie can be read by another site or person using a simple Java script. The cookies for Buggy Bank contain account information and a PIN, so it can be used to log in to the account.

Cookie With Account Number and Pin

Another problem with WebMaven is that it can be used to run the system commands with the current user privilege, this is known that a command can be injected after the account cookie using the special characters (for example, Command Injection via special character in Account cookie). An operating system command can be run simply followed by a semicolon.  This command will be executed when the page with the script is loaded. In this version only ping and netstat commands are available to make sure the system running WebMaven is safe from any intentional or accidental loss of data because of this vulnerability. The command that I ran to verify this hole is ping (simple utility to check if a host is alive or not) in which a semicolon followed by an OS level command ends up with the web server running that command.

SQL INJECTION

SQL Injection is most widely used method to get hold of the information used by the application. SQL queries are used to fetch the data from the back-end database and provide it to the application to be presented to the user of the website at that time. The SQL queries are normally predefined in the application to prevent users from running custom queries.  This is not possible in all the cases which require the user input before running a query. In such a case a parameter is passed to the query.  The value of the parameter is entered by the user at run time.  In this case we need the account number to fetch the data for that particular account, but if this can be manipulated it is possible to display the data for all the accounts in system.

Blind SQLi

Another problem is the blind injection; in some cases the attacker does not have the information on what kind of system he/she is going to deal with, the best way to find is to get it from the system itself. Generally if there are any errors in running a query or command, the system returns an error message that tells a lot about the type of target system. While designing such applications, the developers try to maintain the error message limited to the basic information.  For example if the user entered a number instead of character in a query parameter the error message should be simple, such as, “Invalid Input: Numeric Values are not allowed”. But what if the error message that is returned tells the attacker everything he/she would like to know?

The Paros Web Proxy

The system we are studying here contains a serious flaw; if a special character is injected in the

Parameter value, the system will return a detailed error message telling the operating system, DBMS, Database name, tables names etc. I used the Paros proxy for intercepting the HTTP 1.1 requests from the web browser and HTTP response from the Web Server. Intercept the HTTP request and manually change the value of the hidden field to special characters. This will result in a detailed error message telling about the database server, database name, tables etc from here on the attacker can start making strategies to get hold of the sensitive account information.

Account Number Harvesting 

There are a few ways in which the valid Account Numbers can be harvested. In this part; which is generally the first part of an attack, we are doing it to study the system and workflow logic.  Without this information it is much more difficult to exploit the vulnerabilities present. To exploit the vulnerabilities we must know if they exist or not.  Then, if they do, we can figure out how we would do it. So the information we need must be gained first hand by getting to know the system and using it to find out all we can.

To login to the account an Account Number and a PIN are needed. If any of these two are incorrect, we will not be allowed to login. An Account Number and PIN combination if tried using brute force attack may take years and can be easily detected by the server admin. So to get a valid account number we must narrow the search for information. When I tried using an Account Number and PIN, I got different error messages on different occasions. I already had two valid test accounts so I used them as known real accounts and known real pin numbers and tried a right/wrong combination to see what happens. There can be a number of combinations of right and wrong. Following is the brief idea on how to get the information we need. Here, an account number is more critical but can be found easily as compared to the PIN. To get a PIN, we must have an account number. Here is how I went after it:

Valid Account Number and PIN, but locked account: – For security reasons, if we try logging in with a wrong account number and pin, only three attempts can be made. After three unsuccessful attempts the account would be locked. This means that if anyone tries to login using a manual trial and error or more automated brute force, he/she will get only three chances before the account is locked.  The number of letters in ID and PIN are pretty long and will require millions of possible combination to be tried to guess the correct combination.  With only three available attempts, the possibility to login to the accounts are extremely low.  After an account is locked, even the correct Account Number and PIN combination will not work until the account is reactivated by the Admin. The catch is the message that is returned when the correct combination is tried, “Account is locked”, is different from what is displayed if wrong combination is tried. So even if the account is locked, it is possible to find the correct Account Number and PIN.

How hackers use this flaw is that almost anyone can get the account locked because it just needs three invalid login attempts. Once the account is locked, it will not be unlocked even if the correct Account Number + Pin combination is used. So an attacker can lock the account and then use exhaustive brute force attack to guess the correct PIN and Account Number combination.  The correct combination can be found by logging the error messages returned by the system for a locked account.

Harvesting Valid Account Numbers

The attacker can harvest the valid account numbers by exploiting the error messages returned by the system so as to handle different scenarios. Consider an attacker trying to get hold of an account using the known numbers combination to figure out an account number. Here, the attacker will get different messages as well. Let’s take all possible scenarios of Account Number and PIN combinations.

Valid Account Number Bruting

• • Wrong Account Number and wrong PIN: This situation will result in generating the message ‘Login failed because User ID does not exist in database’. This message explains a lot.  The first input is Account Number and if it is not valid nothing else will be processed. So the attacker knows that this is not Account Number…

• • Correct Account Number but wrong PIN: In this case, the error message generated by the system would be ‘Login failed because of Incorrect PIN” so the attacker knows that the Account Number is valid, but the PIN is not. Following this procedure, the valid Account Numbers can be figured out

• • Correct Account Number and PIN: If the account is not locked the message will be success.  The user will be able to login to his/her account. But if the account is locked, the message returned will be specifying that the account is locked, and if the PIN is wrong the message would be ‘Login failed because of invalid PIN’ even if the account is locked. So the attacker can launch a brute force attack and get the correct PIN.

Join us next week where we will begin our run on Hacme Bank.

Account Summary Page

Funds Transfer

Once the task is finished the user will click on the logout button to get out of the account summary window and get back to the login screen again.

Now that we know how to work with accounts and funds transfer etc., we will go ahead and start looking for vulnerabilities that can be exploited to get unauthorized access or hack the server.

To hack a system we must know how it works.  That is, how the control flows in the program to accomplish the required objective and exploit any loopholes. First thing is to figure out the flow of logic in an application i.e. how particular conditions are handled and if there is a way we can exploit the logic flow.  To see how the program works or how a particular transaction is handled we look at the Source Code of the page. To get the source code of login page, right click on the page and click on ‘View Source’ this will open the source file for that page.

<!DOCTYPE html

PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”

“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”&gt;

<html xmlns=”http://www.w3.org/1999/xhtml&#8221; lang=”en-US” xml:lang=”en-US”>

<head>

<title>Welcome to Buggy Bank – Login</title>

<meta http-equiv=”Content-Type” content=”text/html; charset=iso-8859-1″ />

</head>

<body>

<BODY BGCOLOR=”#FFFFFF” LINK=”#000099″ VLINK=”#336699″ TEXT=”#000000″ TOPMARGIN=0 LEFTMARGIN=0 MARGINWIDTH=0 MARGINHEIGHT=0>

<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0 WIDTH=610>

<TR VALIGN=TOP ALIGN=LEFT>

<TD WIDTH=4 HEIGHT=11><IMG SRC=”../clearpixel.gif” WIDTH=4 HEIGHT=1 BORDER=0></TD>

<TD></TD>

<TD WIDTH=303><IMG SRC=”../clearpixel.gif” WIDTH=303 HEIGHT=1 BORDER=0></TD>

</TR>

<TR VALIGN=TOP ALIGN=LEFT>

<TD HEIGHT=36></TD>

<TD WIDTH=606 COLSPAN=2><IMG ID=”Banner1″ HEIGHT=36 WIDTH=606 SRC=”../wm-header_NProfessionalBanner.gif” BORDER=0 ALT=”Buggy Bank Account Access”></TD>

</TR>

<TR VALIGN=TOP ALIGN=LEFT>

<TD HEIGHT=18></TD>

<TD WIDTH=303>

<TABLE ID=”NavigationBar3″ BORDER=0 CELLSPACING=0 CELLPADDING=0 WIDTH=303>

<TR VALIGN=TOP ALIGN=LEFT>

<TD WIDTH=101><A HREF=”../index.html”><IMG ID=”NavigationButton7″ HEIGHT=18 WIDTH=101 SRC=”../webmaven_NProfessional_up.gif” BORDER=0 ALT=”WebMaven Home”></A></TD>

<TD WIDTH=101><A HREF=”../install_guide.html”><IMG ID=”NavigationButton8″ HEIGHT=18 WIDTH=101 SRC=”../Install_Guide_NProfessional_up.gif” BORDER=0 ALT=”Install Guide”></A></TD>

<TD WIDTH=101 HEIGHT=18><A HREF=”../user_guide.html”><IMG ID=”NavigationButton9″ HEIGHT=18 WIDTH=101 SRC=”../User_Guide_NProfessional_up.gif” BORDER=0 ALT=”User Guide”></A></TD>

</TR>

</TABLE>

</TD>

<TD></TD>

</TR>

</TABLE>

</BODY> <!– The source code for the old sign-on CGI is at /backup/login.cgi.bak –><img src=”/money_burning_md_wht.gif” /><h1>Please sign in.</h1><form method=”get” action=”/cgi-bin/wm.cgi” enctype=”multipart/form-data”>

Account Number <input type=”text” name=”userid” value=”1234567890123750″ /><p />PIN <input type=”password” name=”pin”  /><p /><input type=”hidden” name=”transaction” value=”login”  /><p /><input type=”submit” name=”.submit” /></form><p /><a href=”/cgi-bin/wm.cgi?transaction=reset”>Reset all accounts to beginning state.</a><hr /><BODY BGCOLOR=”#FFFFFF” LINK=”#000099″ VLINK=”#336699″ TEXT=”#000000″ TOPMARGIN=0 LEFTMARGIN=0 MARGINWIDTH=0 MARGINHEIGHT=0>

<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0>

<TR VALIGN=TOP ALIGN=LEFT>

<TD WIDTH=131 HEIGHT=11><IMG SRC=”../clearpixel.gif” WIDTH=131 HEIGHT=1 BORDER=0></TD>

<TD></TD>

</TR>

<TR VALIGN=TOP ALIGN=LEFT>

<TD></TD>

<TD NOWRAP> [<A HREF="../index.html">WebMaven&nbsp;Home</A>]  [<A HREF="../install_guide.html">Install&nbsp;Guide</A>]  [<A HREF="../user_guide.html">User&nbsp;Guide</A>] </TD>

</TR>

</TABLE>

<TABLE BORDER=0 CELLSPACING=0 CELLPADDING=0 WIDTH=459>

<TR VALIGN=TOP ALIGN=LEFT>

<TD WIDTH=108 HEIGHT=11><IMG SRC=”../clearpixel.gif” WIDTH=108 HEIGHT=1 BORDER=0></TD>

<TD WIDTH=351><IMG SRC=”../clearpixel.gif” WIDTH=351 HEIGHT=1 BORDER=0></TD>

</TR>

<TR VALIGN=TOP ALIGN=LEFT>

<TD></TD>

<TD WIDTH=351><P ALIGN=CENTER><FONT SIZE=”-1″>Please contact our </FONT><A HREF=”mailto:webmaven@mavensecurity.com”><FONT SIZE=”-1″>Webmaster</FONT></A><FONT SIZE=”-1″> with questions or comments. <BR></FONT><FONT SIZE=”-2″>©

</FONT><FONT SIZE=”-1″> </FONT><FONT SIZE=”-2″>Copyright 2002 David Rhoades</FONT></TD>

</TR>

</TABLE>

</BODY>

</body>

</html>

The code seems to be ok, but if we look carefully the first flaw in this code is the method used to send the credential for authentication is GET.  This means the account number and password would be visible during the login. So the ID and Password can be stolen because the GET method will expose it and it is not encrypted while going from the client web browser to the Buggy Bank server.

The second problem is there are no anti-caching methods used on the pages where sensitive data is displayed. Normally in almost all the Banking sites there is a idle time limit after which the session will expire and we must log back in to get back into the account.  This is a very important property as normally a user might not sign out from the account and instead just click the Close button on top right hand side of the page.  The page will be closed but the session is still there, so the attacker can get into the system by using the previous session ID without being asked for a PIN.  Moreover, the cookie contains the encrypted account name and password that can be decoded easily.  If we login to the Buggy Bank with the first ID and password provided on the home page, we will get the account details like Balance, Total Amount etc.  Now, if we close the browser window and open it again it should ask for an Account Number and PIN again. It does ask for them, but we can bypass that. All we need to do is get the session ID from the previous successful login and we will be able to access the last session without knowing Account Number and PIN.

In all the sites, especially secure sites like online shopping and banking, the user ID or account number field has Auto Complete property disabled. This means that when we click in the Account Number box, the list of all account numbers that were used to login prior to that will not be there, so that no one gets an account number from that list.  In the current application, the Auto Complete is on in the Account Name field so the user trying to login will be able to see the account numbers that were used by other users to login to their accounts. This makes the job of an attacker easy because they don’t have to use their resources on finding the account numbers.

Attacks

Weak Authentication Cookie 

A cookie is used by the web server to show personalized content to the user every time they visit a web site. A cookie is created when a website is opened; it is nothing but a small text file containing user preferences and sometimes the login information and session ID.

1. WebMaven

WebMaven v.1.01 is an interactive web application that simulates several vulnerabilities at the application-level. WebMaven is useful for the following:

• • Training: practicing security assessment techniques
• • Benchmarking: ensure web security tools perform their tests correctly

This program helps in explaining the problems found in application. It is an Online banking application and session id hijacking and cookie tracking can be performed in real time, in our case we use the web server and client on the same machine, so we would be able to use the cookie in any way we need to.

1. Install Requirements

WebMaven v.1.01 must be installed on a system that has a web server that supports Perl CGI scripts. I used a Windows XP SP3 computer, with Internet Explorer 8 and Paros web proxy. The proxy is needed to intercept and modify the HTTP requests. The Web server I used is Apache 2.2.

1. Installing Perl

You will need to install Perl, go to http://www.perl.org and download the appropriate client for whichever operating system you are running.

1. Installing Web Server

The web server of choice for WebMaven is Apache since it is open source.

See http://httpd.apache.org/ for Apache installation instructions.

(NOTE: You will need to add CGI Script support to Apache to get the WebMaven CGI scripts to work correctly.  For instructions on how to do this, consult The Site Wizard’s Tutorial: http://www.thesitewizard.com/archive/addcgitoapache.shtml)

1. Install WebMaven Files

You can download WebMaven from this website: http://www.mavensecurity.com/WebMaven.php

Uncompress the WebMaven archive distribution file. The contents of the WebMaven1.1 folder would be directory “doc” and “src” and some files (Install, License and Readme).  Place the \wm directory outside server’s document root but within reach of CGI scripts. This would be C:\Program Files\Apache Group\Apache2\wm.  Place the WebMaven CGI script (wm.cgi) within the normal CGI directory for the web server. This would be C:\Program Files\Apache Group\Apache2\cgi-bin\wm.cgi.  Place the ./templates folder within the normal CGI directory for the web server, this would be C:\Program Files\Apache Group\Apache2\cgi-bin\templates.  Place all the files within the ./webmaven_html folder directly into the web server document root.

Begin!

The installation is complete and we are ready to start exploring the WebMaven1.1 interface and try to break in and find vulnerabilities that can be exploited. The aim here is to go through every aspect of a web application and figure out the weak points and bad logic flow that can be used to get what we want.

To start working make sure that web-server i.e. Apache is running, we can check for the Apache icon in task-bar or go to All programs and look for Apache folder and click on Start Server, this will start the server if it is not running.  Now open the Internet Explorer and in the address bar type:  http://localhost:8080/index.html(you might need to use port 80 if that is the port Apache is configured to run on).

Localhost (127.0.0.1) is the address of the loop-back adapter and 8080 is the port on which apache is running, if everything is setup right, we get the following page, this is the home page of WebMaven1.1  Another name for WebMaven1.1 is Buggy Bank.

Click on the login link on the left hand side to go to the bank account login.

1. Buggy Bank Login Page

We need an account number and a pin to login to the account. For starting we have two accounts that we will be using, there are other accounts as well but that is up to the hacker, how many accounts can he/she get.

Acct No: 1234567890123660 and Pin – 1234

Acct No: 1234567890123661 and pin – 4321

1. Login to Account screen

Use any one of the two accounts to login to the application and check the account balance, funds transfers etc.

Join us again next Monday for the send in the series on WebMaven.

Session Fixation

For this task you are the hacker named Joe and you are trying to steal a session from a user named Jane. You are instructed to send an email that has already been prepared to Jane which looks like an official bank email. You are told that you need to add the sessionID (SID) to the email which will be appended to the link in the fake email.

To append the SID to the link you will need to use this:

&SID=sessionID where sessionID is whatever you would like

So enter the appeneded statement to the link and click the Send Mail button.

Now you are acting as Jane looking at the email she received from the hacker Joe. Click on the link you see for Goat Hills Financial.

Now you, as Jane, are prompted to enter your name and password.

You can see that the SID is visible in the URL bar:

Now login as Jane with password tarzan:

Click the Login button to continue.

Now that Jane has logged in using her credentials we can hijack her session because we know the SID. You are told to follow the link to reach the login screen.

As you see the SID is not what we need it to be to hijack Jane’s session…yet. Let’s change the SID to 0wn3d to continue and go to that address with the updated SID.

After going to the address you can see that we have hijacked Jane’s session:

Web Services

Create a SOAP Request

The create a SOAP request lesson wants you to connect to the web service description language (WSDL). You are given a URL for the web service at:

http://localhost/WebGoat/services/SoapRequest

You are also told that you can view the WSDL by adding ?WSDL on the end of the web service request.

To complete the lesson you have to look at the WSDL and determine the number of operations that are defined in teh WSDL. Once you have this information enter it into the textbox and click the Submit button.

First enter the below address into your web browser and go to it.

http://127.0.0.1:8088/WebGoat/services/SoapRequest?WSDL

You should see the WSDL file, now just figure out how many operations this file has defined.

I see four in total.

Next up we are prompted to type in the id parameter in the getFirstNameRequest method.

The type for the getFirstNameRequest is int

Type int into the textbox and click the Submit button.

Next we are told to intercept the request and invoke any method by sending a valid SOAP request for a valid account. Press Generate an HTTP Request and go to WebScarab and take a look at the webservices. Make sure the WSDL is correct,a nd verify the operation, finally modify the value field with 101 and execute it.

WSDL Scanning

This lesson we are tasked with trying to get credit card number from a database through a web service.

We are told to reference a WSDL file to assist us with getting this information. Go ahead and open up the file that is linked and take a look around. You should see a parameter named getCreditCard:

On with the attack, first select any one of the elements in the listbox and make sure that 101 is in the id textbox. Start the Tamper Data service; click the Submit button followed by the Tamper button. Next change the field parameter to getCreditCard and click the OK button:

Web Service SAX Injection

This lesson we are going to use a SOAP request to execute a function defined in the WSDL file.

The goal of this lesson is to reset the password for a user who is different than the user who has user-ID 101.

When the password textbox has a value  in it and the Go button is pressed an XML request is created, submitted and parsed by the SAX server:

<?xml version=’1.0′ encoding=’UTF-8′?>

<wsns0:Envelope

? xmlns:xsi=’http://www.w3.org/2001/XMLSchema-instance&#8217;

? xmlns:xsd=’http://www.w3.org/2001/XMLSchema&#8217;

? xmlns:wsns0=’http://schemas.xmlsoap.org/soap/envelope/&#8217;

? xmlns:wsns1=’http://lessons.webgoat.owasp.org’&gt;

? <wsns0:Body>

??? <wsns1:changePassword>

????? <id xsi:type=’xsd:int’>101</id>

????? <password xsi:type=’xsd:string’>[password]</password>

??? </wsns1:changePassword>

? </wsns0:Body>

</wsns0:Envelope>

To complete this attack we need to ensure that the XML request that is sent to the server is this:

<?xml version=’1.0′ encoding=’UTF-8′?>

<wsns0:Envelope

? xmlns:xsi=’http://www.w3.org/2001/XMLSchema-instance&#8217;

? xmlns:xsd=’http://www.w3.org/2001/XMLSchema&#8217;

? xmlns:wsns0=’http://schemas.xmlsoap.org/soap/envelope/&#8217;

? xmlns:wsns1=’http://lessons.webgoat.owasp.org’&gt;

? <wsns0:Body>

??? <wsns1:changePassword>

????? <id xsi:type=’xsd:int’>101</id>

????? <password xsi:type=’xsd:string’>[password]</password>

??? </wsns1:changePassword>

??? <wsns1:changePassword>

????? <id xsi:type=’xsd:int’>102</id>

????? <password xsi:type=’xsd:string’>newpassword</password>

??? </wsns1:changePassword>

? </wsns0:Body>

</wsns0:Envelope>

In order to accomplish this we need to inject this statement:

ewpassword</password>

??? </wsns1:changePassword>

??? <wsns1:changePassword>

????? <id xsi:type=’xsd:int’>102</id>

????? <password xsi:type=’xsd:string’>newpassword

We cannot do this within the textbox form due to HTML field limitations. Open up the Tamer Data tool and start the service. Click the Go button and then the Tamper button. In the password field enter the injection code from above and click OK.

Join us again next Monday when we start the series on WebMaven.

Exploit Unchecked Email

This lesson has two steps: first you are to send a malicious script to the website admin and second you are to send a malicious script to a ‘friend’ from OWASP.

So the first thing you are going to do is put the input shown below into the Questions or Comments textbox and click send:

<script>alert(“XSS”)</script>

Next we need to send it to a ‘friend’ from OWASP.

Again put the script into the same textbox as before but before you click Send open up Tamer Data and start the tamper service. Intercept the request and change the to field to another email address.

You can see here that the email was going to webgoat.admin@owasp.org (40 is the ASCII for @, you need to put the % for URL encoding). So let’s send this to friend@owasp.org. You will need to enter this:

Friend%40owasp.org

Click the OK button and you should see this:

Bypass Client Side JavaScript Validation

For this lesson you are given seven JavaScript validation mechanisms, all of which must have valid values in to submit successfully. You are told that both client-side and server side validation occur on these mechanisms; break the client-side validation.

Open WebScarab and check off request intercepts make sure to have everything highlighted.  Now go the page and hit submit. Go to the WebScarab window and check the encoded url tabbed, and you will see the values. Simply modify them, in the screenshot below I simply added the @ to each field and then press accept.

Session Management Flaws

Hijack a Session

For this lesson you are attempting to gain access to a user’s session.

You will need the jhijack tool available at http://sourceforge.net/projects/jhijack/.  Go head and startup WebScarab and set your proxies. Turn on request intercepts, view hidden fields and finally launch the Jhijack.  Now reload the page and we will look at webscarab.

Let’s take a moment and configure out jHijack. We need put our Host, and port into it first.  In the example below we see the IP address of this particular VM and port number, yours maybe different. Now we need to find a success message of some kind. So far we have noticed in Webgoat, that every time we complete a mission we get a “Congratulations” so let’s use that in our Grep (it’s case sensitive).  The last part we need to fill in is the URL.  See below.

Now we need to go back to WebScarab and select the Session ID tab (if you don’t see it make sure you are using WebScarab in it’s full version. Select previous requests and choose the appropriate url (picture below).  Now select the cookie weakid and remove it.

Go to the bottom of the screen and hit test. You should receive this success message.

Now we need to collect some data. Set the fetch number to 50 and hit fetch. Go up to the Analysis tab and set the session ID and you should receive the list of cookies out there.  We want to look specifically at the Session ID numerical value. Not that it is incrementing by 1.  Now, there is a gap there, between 19400 and 19402. That’s an open session so let’s focus on that.

The second part of the values has a large gap between them so we need to “guess” at what that value is, but we have JjHijack to make this really simple. Copy out the one above and below the target and  paste them into a notepad. Doing this makes it easier to see and copy.  See the example below. Notice the [] is a range.

Now it’s simply filling in the missing information in jHijack. Go back to WebScarab and gather the JsessionID, parameters and  enter them in. Note we want to place a $ at the end of our WEAKID value. Finally, take the range and enter that in.  Then hit hijack. See below.

We refresh the page one last time and go back to the WebScarab intercept and swap out the weakid.

And hit accept and we have our congratulations message.

Spoof an Authentication Cookie

For this lesson you are told to login using either webgoat/webgoat or aspect/aspect as the username/password combination. Next you are told to edit the cookie to change your identity to alice.

So first off log in as webgoat and click the Login button.

On the top of the webgoat page you should see a link that says Show Cookies. Click on the Show Cookies option and you will see the cookie that was created when you logged in as webgoat.

The authorization cookie or the user webgoat is 65432ubphcfx as shown above.

Go ahead and click the Logout button and then login with aspec/aspect next:

Click on the Show Cookies link again (might have to click twice) and you should get your authorization cookie:

For this authorization cookie we see that aspect has a value of 65432udfqtb.

So the different between the two logins is the letters after 65432.

The key to this attack is that the username is a really basic cipher. Let’s take a look at these authorization cookies versus their usernames:

The first thing that I noticed was that both the aspect and webgoat ciphers both start with u as the first character. The second thing that I noticed is that both webgoat and aspect both end in t. Next you can see that the last character of the webgoat cipher is x and x is one letter ahead of w. Also u is one character ahead of t which explains why both ciphers tart with u. The cipher pattern is a reverse of the login name and all letters are shifted up one. Now that we know this we can begin editing the cookie to change our login name to alice.

To do this lets first do the cipher by hand:

Ok now open up Firebug and edit the cookie value so that it is 65432fdjmb

To do this right click on the AuthCookie value when the menu for it is expanded and click Edit:

You will see a popup window called Edit Cookie. Change the value to the one we determined for user alice:

Click the OK button and refresh the page.

Join us again next Monday for the last in the series on WebGoat.