Almost back…

It’s been a long time everybody…but we are back.

It’s been a crazy roller coaster, but now all of the pieces are finally in place and the rookies and I will begin posting content here regularly on the first of August.

In the meantime be sure to check out:

http://it-security-professionals.com

 

and of course:

http://strategicsec.com/blog

 

 

See you soon…

Posted in Uncategorized | Leave a comment

Hacme Books Week 5

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 | Leave a comment

Hacme Books Week 4

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.

Posted in Cross Site Scripting, Cryptographic Attacks | Tagged , | Leave a comment

Hacme Books Week 3

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://&#8217;,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 , | Leave a comment

Hacme Books Week 2

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

Posted in SQL Injection | Tagged | Leave a comment

Hacme Books Week 1

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.

 

    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.

 

Posted in Uncategorized | Leave a comment

WebMaven Week 3

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 | Leave a comment