Friday, June 3, 2011

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

Saturday, May 14, 2011

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.

Thursday, May 5, 2011

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

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

Thursday, April 21, 2011

“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

Tuesday, April 19, 2011

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

Friday, April 15, 2011

Let’s Go with the Web Application Scan… It is cheaper

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.

Learn more at SecureState's new blog site http://blog.securestate.com/post/2011/04/15/Lete28099s-Go-with-the-Web-Application-Scane280a6-It-is-cheaper.aspx

Friday, April 8, 2011

PCI DSS Applicability To Closed Accounts

We recently ran into some questions from multiple organizations regarding PCI DSS applicability to closed or inactive credit card account numbers. For example, when someone passes away, the disposition of their debts and assets may go through probate. What may happen during this process is the collection of all of the deceased’s debt accounts, including credit cards, to determine how claims will be paid from the estate. Based on discussions with some of our clients, the credit card accounts are closed before they are handed over to the probate organization. That being said, these organizations will have credit card data in their systems, albeit inactive account numbers.

Read more on SecureState's new blog site http://blog.securestate.com/post/2011/04/08/PCI-DSS-Applicability-To-Closed-Accounts.aspx

Wednesday, April 6, 2011

Penalty Double Ups: PCI Intersects with State Privacy Laws

A lawsuit out of Massachusetts related to a breach of cardholder data by the Briar Group, LLC resulted in an $110,000 settlement by the company. This is some interesting news, as it shows that penalties for not protecting cardholder data can hit you from both the card brands and regional privacy lawsuits. Although the amount of the settlement is not extremely high, the other requirements coming out of the settlement can definitely push those costs up. Read more on SecureState's new blog site http://blog.securestate.com/post/2011/04/06/Penalty-Double-Ups-PCI-Intersects-with-State-Privacy-Laws.aspx

Tuesday, April 5, 2011

The Importance of System Logging

This blog is more of a success story than anything else. I want to bring to light a small business with less than six employees who properly implemented auditing. As you may or may not know, Windows allows a user to audit Logon and Logoff events. This is extremely important especially when you are trying to figure out who is using, or has attempted to use, your system.

Read the entire post on SecureState's new blog! http://blog.securestate.com/post/2011/04/05/The-Importance-of-Auditing.aspx

Friday, April 1, 2011

Ten Ways to Fail at Information Security: Part 1

Information Security is still an emerging discipline, with lots of loud voices expressing different opinions as to what is the absolute best way to secure your company. Rather than throw more noise into the echo chamber espousing “best practices”, in this series of blogs, I will be taking a different route. Every company does security differently, with varying degrees of success. No single approach works best for everyone; however, there are several approaches that are wrong for anyone. In this series of blogs, I will be outlining ten wrong approaches to security, in the hope that we can all get better at avoiding these mistakes.

Read more on SecureState's new blog site http://blog.securestate.com/post/2011/04/01/Ten-Ways-to-Fail-at-Information-Security-Part-1.aspx

Thursday, March 24, 2011

Taking Data Loss Prevention To Data Loss Acceleration

“OpenDLP is a free and open source, agent-based, centrally managed, massively distributable data loss prevention tool.” This is how creator Andrew Gavin defines OpenDLP. While this tool could be used to monitor sensitive data on hundreds of systems simultaneously, it could also be used to steal massive amounts of data very quickly.

Read more on SecureState's new blog site http://blog.securestate.com/post/2011/03/16/Taking-Data-Loss-Prevention-To-Data-Loss-Acceleration.aspx

Is Your e-file Tax Return Secure?

Find out how secure yours is by reading Ken Stasiak's post on our new blog site here http://blog.securestate.com/post/2011/03/14/Is-Your-e-file-Tax-Return-Secure.aspx

New Vulnerability Alert by SecureState Now Available!

Find the vulenrability reports each month on our new blog site

http://blog.securestate.com/post/2011/03/08/New-Vulnerability-Alert-by-SecureState-Now-Available!.aspx

Cleveland OWASP Chapter Meeting Announcement

SecureState is proud to sponsor the Cleveland chapter of OWASP and we are bringing back the quarterly meetings by bringing in some of the top speakers in the application security community. This quarter we have web application security ninja Kevin Johnson that will be speaking. The title of his talk is “Ninja Developers: Application Security Testing and Your SDLC”.

Read more on our new site http://blog.securestate.com/post/2011/03/04/Cleveland-OWASP-Chapter-Meeting-Announcement.aspx

HIPAA: Rx For End-User Device Risks

HITECH breach notification requirements apply to breaches of “unsecured” Protected Health Information (PHI). Basically, if electronic PHI data is encrypted, purged, or physically destroyed before it is inadvertently disclosed, then it doesn’t count as a breach.

Read more at SecureState's new blog site http://blog.securestate.com/post/2011/03/03/HIPAA-Rx-For-End-User-Device-Risks.aspx

Tuesday, March 1, 2011

Come Out; Come Out; Wherever You Are…

The title of this blog is typically heard amongst children while playing the game “Hide and Seek.” I use it now as a reference to companies hiding from Privacy Regulations or at the very least avoiding the application of the best practices available when it comes to Privacy Principles.

Why Do Companies Hide From Privacy Regulations?

Read more on SecureState's new blog http://blog.securestate.com/

Friday, February 25, 2011

But It Was Developed By A Third Party… Of Course It’s Secure!

Just as internally coded web applications should go through a standard Software Development Life Cycle {SDLC}, third party web applications should also be subjected to an SDLC. For example, an organization’s SDLC may dictate that all newly coded web applications must go through a grey box assessment before going live...

Read the rest on SecureState's new blog site http://blog.securestate.com/post/2011/02/25/But-It-Was-Developed-By-A-Third-Partye280a6-Of-Course-Ite28099s-Secure!.aspx

Means, Opportunity, and Motive: Point Of Interaction Awareness

There have been numerous news stories about employees stealing credit card information before it is even entered into your information systems. These are usually occurring out on the sales floor. You can be fully compliant with the PCI DSS, but most of the offenses we are talking about occur outside the scope of what those requirements are designed to protect against. The following types of scenarios are happening every day at merchants worldwide...

Read more at SecureState's new blog http://blog.securestate.com/post/2011/02/24/Means-Opportunity-and-Motive-Point-Of-Interaction-Awareness.aspx

New Module for the Metasploit Framework Released by SecureState

SecureState released a new module for the Metasploit Framework that allows users to brute force credentials on Microsoft OWA servers. The module, written in Ruby, forges HTTP requests (both GET and POST) to simulate a user logging into the web service. By checking the responses, the module determines whether the authentication succeeded and reports the information to the user. This is often useful on penetration tests when the attacker has a list of Active Directory users but no services that are using domain authentication.

Check it out on our new blog! http://blog.securestate.com/post/2011/02/24/New-Module-for-the-Metasploit-Framework-Released-by-SecureState.aspx

Dispelling The Myths Of Facebook Privacy And Security

There are many misconceptions about the security of Facebook, Facebook applications, and the frequent scams that seem to plague the world’s largest social network. To help set the record straight, I would like to shed a bit of reality on the most common myths about Facebook security and privacy today. These are real examples of statements that I have encountered regarding Facebook and their privacy controls and security measures. Some have surprising truth to them and others are completely false and misleading. I’ve broken these myths into three areas: Facebook applications, privacy, and security myths.

Read more on our new blog http://blog.securestate.com/post/2011/02/21/Dispelling-The-Myths-Of-Facebook-Privacy-And-Security.aspx

Visa Introduces Technology Innovation Program (TIP) for Merchants

Visa announced on February 9, 2011 that as of March 31, 2011, Visa will allow qualifying merchants outside the U.S. to discontinue their annual Payment Card Industry (PCI) On-Site Assessment. Visa has introduced the Technology Innovation Program (TIP), which essentially will apply to those merchants that meet the following requirements...

Read more on SecureState's new blog http://blog.securestate.com/post/2011/02/10/Visa-Introduces-Technology-Innovation-Program-(TIP)-for-Merchants.aspx

FERPA, HIPAA’s Immature Cousin, Says ‘Happy Data Privacy Day!’

Today I thought it would be interesting to compare HIPAA and FERPA.

Learn more at our new blog site http://blog.securestate.com/post/2011/01/28/FERPA-HIPAAe28099s-Immature-Cousin-Says-e28098Happy-Data-Privacy-Day!e28099.aspx

Small Goals Lead to Bigger Results

Why are there shelves, sometimes figuratively, sometimes literally, full of projects that money was spent on with little end result? Projects left incomplete, never verified as meeting their intended reasons for purchase?

Find out more at SecureState's new blog http://blog.securestate.com/post/2011/01/27/Small-Goals-Lead-to-Bigger-Results.aspx

SiteScape Forums TCL Injection Exploit Released

SecureState released new details on a vulnerability regarding TCL code injection in SiteScape Enterprise Forums. This web application provides a large scale collaborative environment that many organizations use for communication and documentation. This vulnerability, originally released in 2007 as CVE 2007-6515, stated only that SiteScape could be exploited to execute Tool Command Language (TCL) commands.

Read more on our new blog http://blog.securestate.com/post/2011/01/12/SiteScape-Forums-TCL-Injection-Exploit-Released.aspx

Tuesday, January 11, 2011

Picking The Right Lock

This past weekend several of us attended an excellent two-day training session on lock security offered by Schuyler Towne of Open Locksport. Two full days of picking locks, impressioning keys, and opening handcuffs brought physical security to the forefront for me. It seemed like the perfect time to do an overview of some of the popular non-destructive lock bypass techniques, and the ways we can mitigate them.

Read the rest of this post on our new blog site http://blog.securestate.com/post/2010/12/23/Picking-The-Right-Lock.aspx!

Increasing Security With Chroot Jails

In the world of information security, you have to assume that hackers will get into your network. Whether using a zero-day exploit, sending malicious emails to your employees or taking advantage of poor coding in use on your webpage, attackers are coming for you. Your job as an administrator is to make it as difficult as possible for an attacker to gain access as well as being able to detect and mitigate an attack after it occurs. This is why practicing “defense in-depth” must be an essential part of your everyday thought process. When deploying new services, devices, or applications, you should think to yourself: “If this were compromised, how could I mitigate the risk of an attacker advancing further into my network?” In come chroot jails.

Read the rest on our new blog site:
http://blog.securestate.com/post/2011/01/03/Increasing-Security-With-Chroot-Jails.aspx

January 5th, The Most Stressful Day of the Year – But It Doesn’t Have To Be For You And Your Information Security Program!

Recently I read an article stating that January 5th is the most stressful day of the year. This is based on a number of factors including the holidays ending, work resuming, cold gloomy weather, etc. While I can’t attest to whether this is true, I can share a few thoughts if information security is adding to your stress level!

Read the rest on our new blog site - http://blog.securestate.com/

Friday, January 7, 2011

New SecureState Blog

Check out our new blog site here!

Subscribe to: Posts (Atom)