Web App Pentesting

Hacme Books Week 5

Posted on December 24, 2012 by Ma5t3rX

This is the last in a series five posts for the vulnerable web application Hacme Books.

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.

Posted in Access Control Flaws | Tagged Access Control | Leave a comment

Hacme Books Week 4

Posted on December 17, 2012 by Ma5t3rX

This is the fourth in a series of five posts for the vulnerable web application Hacme Books. New posts for Hacme Books will post every Monday.

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.

Hacme Books Week 3

Posted on December 10, 2012 by Ma5t3rX

This is the third in a series of five posts for the vulnerable web application Hacme Books. New posts for WebGoat will post every Monday.

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.

Posted in Denial of Service | Tagged Data Tempering, DoS | Leave a comment

Hacme Books Week 2

Posted on December 3, 2012 by Ma5t3rX

This is the second in a series of three posts for the vulnerable web application Hacme Books. New posts for Hacme Books will occur every Monday.

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) as a normal user using the application, and
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.

Posted in SQL Injection | Tagged sql injection | Leave a comment

Hacme Books Week 1

Posted on November 26, 2012 by Ma5t3rX

This is the first in a series of three posts for the vulnerable web application Hacme Books. New posts for Hacme Books will occur every Monday.

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.

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. 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.

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.

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

4. The installation will begin copying files and the progress indicator will show the progress of the installation.
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:

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.

Posted in Uncategorized | Leave a comment

WebMaven Week 3

Posted on October 15, 2012 by Ma5t3rX

This is the last in a series of three posts for the vulnerable web application WebMaven.

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.

Posted in Blind SQL Injection, Spoofing Cookies, SQL Injection | Tagged sql injection | Leave a comment

WebMaven Week 2

Posted on October 8, 2012 by Ma5t3rX

This is the second in a series of three posts for the vulnerable web application WebMaven. New posts for WebMaven will occur every Monday.

Account Option Screen After Valid Login

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”>

<head>

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

</head>

<body>

</TR>

</TR>

</TR>

</TABLE>

</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>

</TR>

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

</TR>

</TABLE>

</TR>

<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″>©

</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.

Joint us next Monday for the final week of WebMaven.

Posted in Spoofing Cookies, Weak Authentication | Tagged Spoofing Cookies, Weak Authentication | Leave a comment

Web App Pentesting

Hacme Books Week 5

Hacme Books Week 4

Hacme Books Week 3

Hacme Books Week 2

Hacme Books Week 1

WebMaven Week 3

WebMaven Week 2

Recent Posts

Recent Comments

Archives

Categories

Meta

Follow “Web App Pentesting”