SecureState Has A New Blog - Come See What You're Missing!

Don't forget to check out SecureState's new blog site - we recently released a new tool update, take a look here and while you’re at it, visit SecureState's Company Website and see what's going on in our Media Center and browse through our recently released Tools!

Read more!

SecureState Releases New Tool for Footprinting 802.1x Wireless Networks

Today, SecureState is releasing a new tool for footprinting 802.1x wireless networks called EAPeak. EAPeak is a Python powered script that is meant to parse useful pieces of information for a Security Assessment of wireless networks that use the Enterprise Authentication Protocol. It relies on the Scapy libraries to parse both PCap files and live network captures.

Read more on our new blog site here http://blog.securestate.com/post/2011/06/03/SecureState-Releases-New-Tool-for-Footprinting-8021x-Wireless-Networks.aspx

Read more!

But My Web Application Uses SSL...Of Course I’m Secure

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

Read more!

Quit Hoarding

Evaluate your security program’s maturity before dropping money on a quick-fix “hot” product.

Evidently, there is an increasing fascination within the American psyche with hoarding, the excessive collection of items, along with the inability to discard them. This is evident in the popularity of television shows such as “Buried Alive” and “Hoarders”.

Read more of this post on our new blog site http://blog.securestate.com/post/2011/05/05/Quit-Hoarding.aspx

Read more!

Information Policies & Procedures, Part 7

This is part of an ongoing series on documentation development.


Do words matter? Of course they do. There are few places where this statement is as true as in documentation. When developing policies and procedures, we must be very clear about the rules. Must and shall mean, as the name implies, that the action is not optional. May means that the action is allowed, but not required. This is an essential difference. Take for instance: sharing passwords. A policy statement should be in place saying something like “users shall not disclose passwords to others.” This clearly dictates that passwords must not be disclosed. May, on the other hand, allows a bit more flexibility. For example, take the statement “users may bring in their own monitors.” In this case, users are allowed, but not required, to use their own monitors.

Read the rest of this post at our new blog site: http://blog.securestate.com/post/2011/05/02/Information-Security-Policies-and-Procedures-Part-7.aspx

Read more!

“We Have a Vulnerability Management Program…It’s in Our Data Center”

From Running Scans to Building a Vulnerability Management Program

I perform the Vulnerability Assessments and Payment Card Industry Approved Scanning Vendor (PCI ASV) Scans at our information security firm. I have been running scans for over 100 different companies for the last year, and I see the same recurring vulnerabilities again and again. What I have also seen is that people do not understand what it means to manage vulnerabilities.

Learn more on our new blog site
http://blog.securestate.com/post/2011/04/21/e2809cWe-Have-a-Vulnerability-Management-Programe280a6Ite28099s-in-Our-Data-Centere2809d.aspx

Read more!

Spring into a New Career!

SecureState will be holding on-site open interviews on Thursday, April 21 from noon to 6:30 p.m.

at the SecureState Headquarters: 23340 Miles Road, Bedford Heights, OH 44128


http://blog.securestate.com/post/2011/04/19/Spring-into-a-New-Career!.aspx

Read more!