Tag Archives: web application security

Posted on by

SSL Wars – Little New Hope

More of the Same

In 2010 I wrote a small series of blogs (A New Hope, The SSL Strikes Back, The Return of the SSLi and Web Application Security) regarding certain vulnerabilities in many of the SSL implementations that I have found while performing vulnerability assessments. Since this time I have not written much about the topic, so I thought it was time to write an update regarding the current state of websites that are using SSL/TLS to protect their web applications. Sadly, the current state of SSL/TLS is pretty pathetic. As of March 19, 2013 the SSL Pulse Project reported that many of the most popular sites on the Internet are still struggling with correctly implementing SSL!
Continue reading →

Comment on this post
Posted on by

Firebird SQL Stack Buffer Overflow (CVE-2013-2492)

Recently, the SecureState Research and Innovation team found a critical flaw in the latest, stable releases of Firebird SQL. Firebird SQL is an open source SQL server that can sometimes be found bundled with other software packages. The vulnerability SecureState found is a remotely exploitable stack buffer overflow which can be triggered by an unauthenticated user. The vulnerability occurs when the length of a group identifier field in the CNCT information of data sent by the client is not properly validated. This allows 32 bytes to be written to the stack when only 4 should be allowed. The result leads to overwriting a critical pointer which is later used to read a function pointer. Continue reading →

Comment on this post
Posted on by

Web Application Security

SecureState Auditor: What are you doing for web application security?

Web Development Project Lead: We use SSL.

The Setup: How You Protect Your Web Applications Says A Lot about the Maturity of Your Security Programs – In a meeting with a relatively well known third party web application development company, the question was asked as to what the company was doing for web application security. The company said they used SSL for their web application security. The answer to this question shows that some organizations may be confused when it comes to what SSL does and does not provide. These organizations may assume that just because they are using SSL, their web application is safe from all web application attacks. The problem with this logic is the fact that SSL protects web applications from only a small category of web application vulnerabilities. Unless the organization understands that their web application still could be vulnerable to a million other web application vulnerabilities, they could falsely assume SSL protects them from far more than it actually does.  Good auditors know this; and answers like “We use SSL” to protect our web applications should raise some red flags. The truth of the matter is that I have assessed many web applications which used SSL. Many of these web applications I have been able to run commands on the underlying web server or pull sensitive data out of the database the web application was using.

 

So What Does SSL Help To Protect the Web Application From?

Clear-Text Submission of Sensitive Information: SSL is used to encrypt sensitive information which is exchanged between a web browser and a web server. Suppose a user visits a website in order to purchase a new pair of shoes. This user selects a button which adds a new pair of shoes to the user’s cart. The user then selects the “Pay Now” button in order to check out. At this point the user is redirected to a checkout page where they are required to enter their credit card data and hit the “Submit” button. The credit card data then is sent from the user’s web browser to the website from which the shoes were purchased. If SSL is not used, this data will be sent over the Internet in clear text. This means that if an attacker is able to intercept the traffic flowing between the user’s browser and the web application server, the attacker would be able to see the user’s credit card data.

Malicious Site that Claims to be Your Site: SSL provides authentication by using something called certificates. The certificate is used to prove that the site the user is connecting to, is who they claim to be. When you pay your bills using online banking, how do you know you are really connecting to your online banking website and not an attacker’s website that only looks like your online banking site? What would happen if you were going to connect to your online banking site (onlinebanking.com), but an attacker was able to intercept and redirect your web traffic to a malicious site that looks like onlinebanking.com? How could you detect the presence of the malicious lookalike site as opposed to the actual onlinebanking.com site? Well, the answer to this question is…certificates. When SSL is implemented correctly, the user’s web browser should warn them that something is wrong with the web application’s certificate. Therefore, SSL can validate that the site you are connecting to, is actually the site it claims to be.

 

So What Does SSL NOT Protect You From?

Injection Vulnerabilities: An organization may use SSL to help to protect their web application, but the application still may be vulnerable to injection vulnerabilities. One of the most common injection vulnerabilities is SQL Injection. SQL Injection allows an attacker to create their own SQL queries through injecting data into existing SQL queries. SQL Injection can be used to pull all of the data out of a database the web application is using or, in some cases, even run commands on the web application server. I have been on external attack and penetration assessments where we were able to fully compromise an organization’s internal network through a web application that was vulnerable to SQL Injection.

Tricking Users into Performing Unintended Actions: Cross Site Request Forgery is one of the most common vulnerabilities I have encountered while performing web application assessments. This attack is used in order to cause a user to perform some sort of action that they did not intend to perform. The attack works as follows:

Once a user logs in to a trusted web site, like a bank, a cookie can be stored in their browser. This cookie lets the web application know that the actions being performed are coming from the user that has just logged in. Every time an action occurs within this web browsing session the cookie is reused, so the user does’t have to keep logging in as they browse the web application.

Suppose that after the user logs in to the bank, they are able to transfer funds to another account using a form on the online banking site. This form requires that the user provide the account to which the funds will be transferred as well as the amount of money that is to be transferred to that account. When the user submits the payment, the information the user entered is passed to the underlying web application along with the cookie used to validate the user’s session. In our example, these parameters are passed to the underlying operating system in the following URL:

  • https://onlinebank.com/TransferFunds.aspx?AccountNumber=987654321&Amount=10.00

There are two parameters in this URL. The first is “AccountNumber”. This parameter is used to tell the banking web application the account number the funds should be transferred to. The second parameter is “Amount”. This parameter is used to tell the web application how much money should be transferred to “AccountNumber”. An attacker may be able to use cross site request forgery in order to have the user transfer funds into the attackers account, by causing the user to visit the following URL once they have logged in:

  • https://onlinebank.com/TransferFunds.aspx?AccountNumber=AttackersAccountNumber&Amount=1000.00

In this example the attacker caused the user to transfer 1000.00 into account “AttackersAccountNumber” by simply visiting the URL the attacker created. If the user has a valid session on onlinebanking.com, their cookie will be silently passed to the banking web application when they visit this URL and the funds will be transferred to the attacker’s account.

Many Other Web Application Vulnerabilities: Injection vulnerabilities and cross site request forgery are just a few vulnerabilities from which SSL does not protect a web application. Other common web application vulnerabilities SSL does not protect the web application against are cross-site scripting, privilege escalation, failure to restrict URL access, default credentials left on administrative interfaces, and default error handling. Although SSL provides authentication and confidentiality (as well as integrity and non-repudiation), it does not even begin to address all of the vulnerabilities to which web applications are exposed.

 

If I Remediate All SSL Vulnerabilities, Will I Pass My PCI ASV Scan?

Remediating ALL SSL Vulnerabilities Does not Mean You Will Pass Your ASV Scan: If an organization is required to comply with PCI regulations, they should be aware that implementing SSL on their web application does not mean they will pass their PCI ASV scans. A number of vulnerabilities exist which are specific to SSL and will cause a company to fail their PCI scans. Examples of these vulnerabilities include SSL version 2 being enabled, or SSL implementations which allow the use of weak ciphers. Other vulnerabilities like default credentials on administrative consoles, SQL Injection, and Cross Site Scripting also will cause a failure of the PCI ASV scan. The point is that you can remediate all of the SSL related vulnerabilities and still fail a PCI ASV scan.

The Verdict: If the Auditor Asks, Don’t Lead With SSL – When approaching web application security it is vital that any organization know the limit to any technology that they use to secure their web applications. If a site is using SSL it is important to know that you are not safe from vulnerabilities like privilege escalation, cross-site scripting, cross-site request forgery, or SQL injection. When it comes to web application security knowing your attack surfaces (i.e. The types of attacks you could be vulnerable to) and how to mitigate each class of vulnerability is important. When it comes to properly protecting your web applications an organization should be aware of the web application’s attack surface and how to mitigate the vulnerabilities to which these surfaces expose the web application. A proper Software Development Life Cycle (SDLC), Regular Web Application Assessments, Minimum Security Baselines (MSBs), having your developers attend annual web application security training, and the proper configuration of Web Application Firewalls and Intrusion Prevention Systems are just a few examples of what goes into properly protecting your web applications from attackers. You should never rely on one technology, like SSL, to protect your whole web application.

 

Comment on this post
Posted on by

Web Application Security Assessment

Why A Manual Web Application Security Assessment is Worth Every Penny Over An Automated Tool

Choosing the Assessment: As a Security Consultant for SecureState, I have performed my share of Web Application Security Assessments in the last couple of years, including both Assessments which relied heavily on Web Application Scanners to find vulnerabilities in the web application, as well as Assessments which relied primarily on manual techniques. There is a great difference between these two techniques for performing Web Application Assessments, and I believe that the Web Application Scanner based Assessments are of little value compared to Web Application Assessments that rely on manual techniques. Many times, when choosing a Web Application Assessment, a company will choose the cheapest Assessment available without truly understanding the Pros and Cons of each Web Application Security Assessment. It is important to realize the fact that the cheapest option is not always the best option.

Tool Based Web Application Assessments: The first Assessment I wanted to address is a Web Application Scanner based Assessment. This Assessment heavily relies on Web Application Scanners in order to identify vulnerabilities in the web application. During this Assessment, a Web Application Vulnerability Scanner is run against the web application. Once the scan has finished running, a Consultant will manually verify the results of the scan and remove any false positives. This Assessment is about 80% Web Application Scanner based and only 20% manual based (the consultant generally validates the vulnerability scanner findings). This Assessment is cheap because it requires little manual effort. The primary danger with this Web Application Assessment is the fact that many organizations do not realize the limitations of most Web Application Scanners. Once an organization has a Web Application Scanner based Assessment performed and only a few vulnerabilities are identified, the organization may falsely believe that their web application is secure.

Manual Web Application Assessments: The second Web Application Assessment I will be talking about primarily uses manual techniques in order to identify web application vulnerabilities. In most cases, the Consultant will use web application proxies which sit between the web application and the Consultant’s browser. This is done in order to bypass client-side constraints. The bypass of client-side constraints aids the Consultant in identifying vulnerabilities which would have been missed if client-side validation was used. Before the Web Application Assessment starts, the Consultant is normally given information about the business logic behind the web application. Most of the time, manual Assessments are performed using credentials of a privileged user. This is done in order to find vulnerabilities an authenticated user may be able to exploit (or fall victim to) that a non-authenticated user cannot. If the web application uses different privileged accounts, then the Consultant will try and use the lower privilege account to access functions the higher privilege account is able to access. The Consultant will also try to obtain information from accounts with the same privilege level. For example, if Account A is an administrator and Account B is a regular user, the Consultant will attempt to use Account B to access Account A’s data. Once manual testing of the web application is completed, the Consultant normally runs a Web Application Vulnerability Scanner as a sort of sanity check. This is performed in order to verify the Manual Assessment did not miss any vulnerabilities which could be considered low hanging fruit. Most of the time, Manual Web Application Security Assessments are about 80% manual and only 20% Web Application Scanner based.

Basic Logic Flaws: Web Application Scanners do not have the ability to think (unless we really are living in the “Matrix”) and are therefore limited in their ability to identify flaws in a web application’s logic. Let us look at a real life example of a logic flaw in a web application. Suppose a Website is created for a person to order expensive jewelry online. For the purposes of our example, the name of the site with the expensive jewelry for sale is https://BillionDollarJewelry.com. On this site, items are added to the user’s cart using a URL which accepts two parameters. The two parameters in our example are “Item”, which contains the value of the item being added to the cart, and the parameter “Cost”, which holds the cost of the item being added to the cart. In our example, the URL used to add items to a customer’s cart is as follows:

 https://BillionDollarJewelry.com/AddToCart.aspx?Item=BigDiamondRing&Cost= 1000000000

In this URL, the BigDiamondRing item is added to the cart with a cost of 1000000000 dollars. The problem occurs when an attacker is able to purchase the BigDiamondRing for the on sale price of just zero dollars by sending the following URL:

https://BillionDollarJewelry.com/AddToCart.aspx?Item=BigDiamondRing&Cost= 0

As far as I have seen, Web Application Scanners are not able to identify these sorts of vulnerabilities, yet I have found them numerous times while manually reviewing a web application.

Basic Privilege Escalation Flaws: I have never encountered a Web Application Scanner with the ability to identify privilege escalation vulnerabilities. In most Manual Web Application Assessments, the Consultant will attempt to escalate privileges using accounts with different levels of access, and privilege escalation vulnerabilities are common to find. For example, suppose User A is part of the web application’s administrator role. When User A logs into the web application, they are presented with a list of links which direct the user to web pages with powerful functions. In our example, we will call these functions X, Y, and Z. User B comes along and is only a part of the basic user role. Upon logging into the web application, he is presented with links which direct User B to web pages for functions A, B, and C. If the web pages which provide functions X, Y, and Z are not directly tied to the Administrator role, then User B may be able to access functions X, Y, and Z by directly visiting the function’s web page.

Other Common Vulnerabilities (XSS): It is also common to find high profile vulnerabilities which many Web Application Scanners miss while performing Manual Web Application Security Assessments. For example, I have seen a form of cross site scripting which requires a series of steps in order to get the malicious script to execute. If this series of steps is altered in any way, the script will not execute and the cross site scripting is not identified. Suppose a web application brings a person through a series of steps which require a customer’s personal information to be inserted into the web application. Once all data is placed in the web application, a summary of all data placed into the web application is shown to the customer. For our example, Web Page A requires the customer to submit their first and last name, Web Page B requires the customer to insert their address, Web Page C requires the customer to insert their phone number, and Page D shows the customer a summary of the information inserted into the web application. Now if the FirstName parameter on Page A is given a value of “Tom”><script>alert(‘xss’)</script>” the malicious script will not execute until Page D loads. Vulnerabilities like these are frequently found in the course of a Manual Web Application Assessment, but Web Application Scanners rarely find these sorts of vulnerabilities.

Other Common Vulnerabilities (SQL Injection): I have also encountered a number of SQL Injection vulnerabilities which many Web Application Vulnerability Scanners miss, but that manual review of the web application will identify. Many Web Application Scanners miss Blind SQL Injection in non-common databases. For example, I have found Blind SQL Injection in web applications using a DB2 database. The Web Application Scanner did not identify this vulnerability. I manually used DB2 string concatenation techniques in order to identify and exploit this vulnerability. A breakdown of this SQL Injection is as follows:

  • Original Query: https:DemoUserSite.com/LookUpCustomerID.aspx?UserId=Timmy (This page returns Timmy’s information) 
  • Modified Query 1: https:DemoUserSite.com/LookUpCustomerID.aspx?UserId=Tim’my (This page returns no individual’s information, or some default page)
  • Modified Query 2: https:DemoUserSite.com/LookUpCustomerID.aspx?UserId=Tim’ || ‘my (This page returns Timmy’s information)

Summary: Although Web Application Scanner based Assessments are cheaper than Manual Web Application Security Assessments, they can miss many vulnerabilities which a manual Assessment will identify. Many times Web Application Scanner based Assessments will miss flaws in a web application’s logic, role segmentation vulnerabilities, and other non-standard common vulnerabilities. Manual Web Application Assessments may be more expensive, but when it comes to protecting sensitive information they are much more effective than Assessments which primarily rely and on Web Application Scanners.

 

Comment on this post