In NoVA? Into WebAppSec? Mark your Calendars


owaspFor those of you in the Northern Virginia and surrounding area and who are into web application security, mark you calendars for April 8th, 2009!

Jeremiah Grossman of WhiteHat Security will be in town and presenting his “Top 10 Web Application Hacking Techniques of 2008″ at the OWASP NoVA chapter meeting. Following the presentation, Jeremiah, myself and some other industry representatives will hold a panel discussion on the evolution of pen testing.

I invite you all to join me and the OWASP NoVA chapter members on April 8th at 6PM.

Here are the particulars:
Location:

Booz Allen and Hamilton
13200 Woodland Park Road
Herndon, VA 20171

RSVP:

This event does require an RSVP, please join the OWASP NoVA chapter mailing list and confirm your attendance.

You can also keep an eye on the OWASP NoVA Chapter website and @OWASPNoVA on Twitter.

Tags: ,

Customer Care


were_listeningMaybe the title should have been caring for your customers, I’m not sure. Either way, when you’re involved in security, specifically for a product, or a company who builds products, you should be listening to your customers! Who are your customers? Well, that’s a grey area. Is it your employer, the development teams you collaborate with, or users of the product? If you answered all of the above, you’re correct.

Unfortunately, far too often, security folk forget that last one - the product users. All the quality assurance and security testing in the world won’t account for (hopefully) thousands of users and a few (hopefully) conscientious hackers who might be reporting issues.

So how would one go about accomplishing this task?

  • Establish a public, well documented process for bugs to be reported
    This process might be as simple as providing an email address for reporting issues or as complex as a form which creates a ticket in a tracking system. The point is, you MUST have a way for feedback to be provided
  • LISTEN AND RESPOND TO ALL FEEDBACK
    I can’t stress this enough! When you give users an avenue to report issues, you must accept and acknowledge all reports. When you ignore feedback, your customers get pissed. When you customers get pissed, they turn to any and all online avenues to bash the service and your lack of response. With services like Twitter, Facebook, and MySpace which thrive on user generated content, reputation can be affected within a matter of hours!
  • Be where the feedback is
    Big news: the internet is searchable!

    • Google is a great tool for searching. Furthermore, Google will provide results in RSS feeds which can be loaded into your favorite Feed reader.
    • Twitter is where the people are! Twitter is also searchable and with tools like Tweetdeck and tweetbeeps.com it’s easy to capture tweets which mention your product.

So why do I feel the need to be captain obvious with this post? Well, far too often, as with most security researchers, I’ve reported issues in various products. Some owners have been very responsive while others don’t even bother responding with a form/canned response. With copycat products being released everyday, if you don’t take care of your users, they’ll go somewhere else.

For a good place to start on reputation checkout SpinHunters.com

Tags: ,

Building the Security Team


hackers_aheadMubix recently had a blog post where he detailed an approach for building a team to defend the infrastructure in a hacking contest. This got me thinking about how I might recommend going about building an enterprise security team.

Know that you are the right person for the job - Building a team of security professionals requires a strong understanding of many different areas of specialization in the computer field. You must not only have the people and business skills typically required in any other leadership role, but you must also have a deep understanding of technologies (both security and other) and how they inter operate to ensure reasonable protections against disasters. I’m not saying that you must be able to configure the PIX firewall, but you should understand it’s purpose, differences in firewall technologies, their challenges and how they play into the overall security architecture.

Know your mission - the first item of business is to determine what the security team is going to provide in terms of services for the enterprise. What are the problems that you were asked to solve by creating a security team? Some examples might include PCI/SOX/HIPAA compliance. Perhaps a savvy CEO has asked you to build enterprise security guidance in the form of policies, standards and baselines. Maybe you’ve inherited the network firewall ACL management, penetration testing, enterprise authentication management and product security design services to better serve the company’s need for IT Security.

Know your infrastructure - now that you’ve determined all aspects of the enterprise that are going to be under your control, it’s time to audit them and determine whether any security controls are already in place. Remember, you’re going to need to build the team to support and enhance these controls, this exercise will help you determine a required skill set. This is also the point at which you’re going to audit the parts of the enterprise you’re being tasked to protect. It is important to involve all stakeholders so that a single set of requirements can be derived for each of the security services. For example, if one of your tasks is to evaluate and standardize security controls over all production hosts, it’s important to determine the operational needs of the system administrators who manage these hosts and the developers who write the applications running on these hosts.

Team leads - Here’s where the size of the enterprise you’ve been tasked with protecting comes in. If you’re a small company, your “leadership team” might be 3 really talented individuals with whom you plan on dividing the responsibilities. On the other end of the spectrum, your leadership team might be 5 managers with teams of engineers to accomplish the work in a large enterprise environment. The people in your leadership team (whether the enterprise is big or small) must be colleagues that you trust will not only be able to help you execute your vision, but will also be able to provide valuable input to the plan. The leadership team must all share the same general understanding of enterprise security architecture components while maintaining a strong subject matter expertise in the specific technology areas which they are directly responsible for. For example, I would expect that your network team leader could not only lead the engineers on the team, but also be able to step up to the keyboard and fill an engineer’s shoes.

The engineering teams - Provided you’ve been given enough budget and are looking to secure a large enterprise, you’ll be looking to fill at least a couple vacancies on each team. The interviews should be conducted such that the candidate is not only demonstrating knowledge in the areas directly associated with the position they’re applying for but also in the other areas of responsibility for the security team. In addition to the usual traits you look for in a good candidate (good resume, demonstrated technical knowledge, good writing/communication skills, overall fun person), you are also looking for candidates who are not only experts in their fields, but possess a broad knowledge of technology in general. Don’t be afraid to conduct several interviews with several different people and keep the interviews challenging by presenting a real life security concern and have the candidate and interviewers solve it as a team.

Solve the problem on paper - Now that you have your awesome security team in place, it’s time to get them all together and lay out the problems you’ve been tasked with solving. This is when your vision for solving the problems gets mulled over and revised by your trusted colleagues. This exercise should not only add specific technology solutions to the plan, but will also allow everyone the opportunity to apply their knowledge and be invested in the final solutions.

Measure it - In any enterprise, progress must be measured to ensure some form of Return on Investment (ROI). Costs associated with technology purchases, staff salaries, and other activities will have to be be justified by demonstrating that the cost provides a reasonable assurance of protection against threats. Additionally, in the security world, a lot of useful planning information can be derived from tracking security metrics. For example, if the security assurance team is noticing a high number of input based vulnerabilities during their application assessments, perhaps some investment in secure development training for the dev teams is in order. Knowing which metrics to track as the plan is being built will facilitate the collection and tracking of the numbers.

I do realize this is pretty high level and lacking in specifics, but I wanted to be sure I highlighted the importance of shared technical security knowledge as a key factor in the success of the security plan and subsequent implementation. Furthermore, I beleieve that the same planning and executing techniques can be applied from the executive goals to the engineers’ individual goals and when given the chance to build those goals together, the likelyhood of a good plan being build and implemented increases greatly.

Tags: ,

Security Questions don’t work!


We’ve all seen them, we’ve all used them…”What is your father’s middle name?”, “What is the name of your favorite pet?”, “Where did you go to high school?”. These questions are typically used in web applications when a user needs to reset their password or change their account email address. The intent is to provide a “secure” means through which a user’s identity can be asserted without email confirmation. The problem is that the answers to most security questions can easily be obtained with a little research.

One of the primary destinations on the internet in 2008 was for social networking applications…also known as places where you put all your information to share it with your friends. Whether it’s a Facebook profile, a Twitter post history, a blog, MySpace page, or Google most people have published all the information required for the target account to me stolen. Need more proof?

One of my motivations behind this post comes from when I checked my access logs and found that someone searching for “Wade Woolwine” birthday on Google and had ended up on my blog. Luckily, I don’t use my birthday for answers to security questions…but I now know that one of my accounts is being targeted.

It’s not likely that people will stop choosing bad security questions or publishing too much information about them on the internet. So how do we make this account management safeguard safer?

  • Better Security Questions
    Enter a 6-10 digit code.
    Enter a backup password.
    Enter the last 4 digits of your drivers license.
  • Photo security questions
    Allow the user to provide the security question by selecting an image or providing their own.
  • Confirmation code sent over SMS
    For sites who use SMS for other purposes, a verification code can be sent to the registered mobile number.
  • Delay email address change requests
    Impose a 24 hour delay for email address change requests. During that time, issue an email to both current and future email address explaining the email change request. The email to the current email address should include instructions on how to block the request should it be unauthorized.
  • Identity certificates
    If the provider is able to issue client certificates for their visitors, these certificates can be used as a form of 2nd factor authentication.
  • 2nd factor authentication service
    For banks and other financial institutions, leveraging a service such as Verisign VIP should be implemented. There would be an additional cost for the tokens to cover, but the added security becomes a marketing tool for the service.

I’m not sure if any of these options are truly viable as robust solutions for enhancements or replacements for security questions, but they would make targeting users’ accounts through social engineering more difficult.

Tags: ,

mod_auth_kerb and mod_authnz_ldap bring Apache web apps into the Enterprise


The majority of companies out there have implemented some sort of Windows Active Directory system that they use to connect and manage desktop systems, servers, printers, and other networked assets in a “secure” way. I use secure in quotes because the security largely depends on individual implementations. In any event, the Open Source community builds some pretty cool web apps on top of Apache that would be very useful for collaborating, code management, etc. One of the pain points for companies choosing Open Source web solutions has been the custom authentication and authorization implemented in the applications.

mod_auth_kerb extends Apache’s Basic Auth functionality to authenticate enterprise users against Windows Active Directory using Kerberos tickets supported by Windows. mod_authnz_ldap can use the Active Directory LDAP server to evaluate any available LDAP field against administrator defined ACL. For example, Company X decides to use an Open Source web application but want to restrict access to those in the Active Directory Administrators group; mod_authnz_ldap can use the LDAP server to pull the Active Directory group for the user it’s authenticating and determine whether they are part of the Administrators group.

Here’s a quick summary of how to get it working:

  1. Ensure that your Apache is build with –enable-ldap –enable-authnz-ldap –with-ldap.
  2. Configure Apache to use mod_kerb_auth/Kerberos as it’s AuthType:
    http://koo.fi/tech/2008/06/18/apache-http-authentication-to-active-directory-with-kerberos/
  3. Configure Apache to use mod_authnz_ldap to authorize access based on LDAP data:
    Global Apache configurations:
    LDAPTrustedMode SSL
    (optional) LDAPTrustedGlobalCert CA_DER /etc/apache2/ssl/AOL_Member_CA.der # If the SSL certificate on ldaps is not recognized
    LDAPVerifyServerCert off

    Directory Apache configurations:
    RequireSSL # because you don’t want Active Directory credentials in the clear
    AuthLDAPURL ldaps://directoryserver:port/dc=somewhere,dc=com?cn SSL # where CN is the unique username
    AuthLDAPRemoteUserIsDN off
    AuthLDAPBindDN DNUsername
    AuthLDAPBindPassword DNPassword
    require ldap-attribute ldapfieldname = “ldapfieldvalue”
    require ldap-attribute ldapfieldname = “ldapfieldvalue”

  4. Set Apache’s LogLevel to debug and start troubleshooting. Having an LDAP browser available to test will help you determine where the issues are when troubleshooting.

I ran into a small problem while getting this setup. I found that mod_auth_kerb was modifying the Apache Basic Auth “user” field from the username provided at login to username@realm. This might not be a problem in most cases, but for my implementation, username@realm was no where to be found in the Active Directory LDAP data. So, I did the following quick hacks to the mod_auth_kerb source code and recompiled:

  • Comment out user = apr_pstrcat(r->pool, user, “@”, realm, NULL);
  • Changed MK_USER = apr_pstrdup (r->pool, name); to MK_USER = apr_pstrdup (r->pool, sent_name);

This small change makes mod_auth_kerb return the username instead of username@realm. I’ve emailed the maintainers of mod_auth_kerb to see if they would consider adding an configuration flag to enable the stripping of @realm.

mod_auth_kerb supports SPNEGO (Windows Integrated Authentication support in IE and Firefox) which can provide Single Sign On for Windows users authenticated to the Active Directory.

Since mod_auth_kerb and mod_authnz_ldap simply hook the Apache Basic Auth functionality, applications can leverage the Apache server to provide a username to the underlying web application.

Here are a couple apps you might want to test your new authentication with:

Tags: , , , , , , ,

RE: Alignment of Interests in Web Security


In response to Jeremiah Grossman’s post on Alignment of Interests in Web Security.

While I think that Jeremiah Grossman is absolutely on to something with his theories of alignment of interests in Web Security, I would argue that attaining the goal would go against human nature. Since the dawn of time, human have been in competition with one another and the only thing that’s really changed is the prize for being “best”. In pre-historic times, it was food, fire, and a safe place to sleep. In the middle ages it was land, crops, and livestock. In modern economies, it’s all about the money. For those actively participating in society, money virtually defines who you are in society. Actors, sports professionals, and CEOs of fortune 500 companies rake in hundreds of thousands of dollars and their quality of life shows it with nice cars and lavish housing. While middle class and below are barely making ends meat and most are working very hard for every dollar they spend.

Things aren’t much different in the business world. Companies who perform well go public and have millions of investors, companies who perform poorly go out of business, and once again, the measure of success is money. The examples cited by Jeremiah (SSL for web traffic, data encryption, and getting rid of IFrames) just further illustrate my point. While these practices would do a great deal for protecting their customers, they cost money and affect the bottom line profits, and therefore are not implemented. Yes, I know that security incidents end up costing the company more money in damage control than it would have cost for the safeguards to be implemented in the first place. This is the line security professionals have been giving senior executives for years. Has it worked? It doesn’t seem like it: Ask any of the 60% of the top 100 most popular websites who’ve hosted malware in the first half of 2008. (Websense security Labs™ (State of internet security -Q1 – Q2, 2008)

At this moment, the greatest asset that has been given to security professionals are regulations. Whether they be industry (PCI-DSS, SOX, etc) or Government (FISMA, NIST standards, etc) these regulations on IT Security have proposed to fine/hold legally responsible companies who do not attempt to enforce a minimum level of safeguards to protect their customers. By no means am I saying that these standards are perfect, there is far too little enforcement, the rules are not always described clearly and there are many cases where auditors are coerced into giving a passing grade to infrastructures which do not meet the requirements. What I am saying is that the idea of fining companies for failing to protect consumer data is the right way to go when you’re dealing with executives who’s primary driver is making money for the company.

I propose the following to answer Jeremiah’s question “How do we get the owners of 187 million websites, 17 million developers, browser vendors, universities, governments, ISPs, compliance auditors, and security researchers all to pull in the same direction towards a more secure Web?”:

  • Establish more laws and industry regulations defining how companies should conduct themselves.
    Admittedly, this is a double edged sword. More checkboxes != more security, but it does give the professionals in the field some solid backing when presenting security concerns to executives.
  • Academics and researchers must collaborate to change the education system.
    Remember the old saying “work to make the world better for your children”? We have an army of little tech savvy kids coming through the education system. Lets teach them about information security and privacy issues so that as they move into consumerism, they will instinctively demand security from the products they consume.
  • Figure out a better way to demonstrate the value of IT Security services.
    This seems to be the Achilles heel of the IT Security world. How do you demonstrate the value of preventative counter measures? Yes, I know, another question VS. an answer.
  • Offer better security solutions and products.
    As stated in Jeremiah’s article, “Security vendors love strongly enforced compliance standards as it frees up budget for their solutions, which may not reduce risk, but have to be purchased to satisfy a checkbox”. We don’t need more checkbox solutions, we need tools that actually empower companies with the right information so that they can easily get a snap shot of the current security posture. White Hat Security has a great tool/service hybrid where vulnerability data collected during automated assessment is pre-vetted by WhiteHatSec security engineers before being presented to the customer. As a quick disclaimer, I don’t work for WhiteHatSec, but have had the opportunity to see their product in action.
  • Greater focus on outreach and communications.
    As the final, and perhaps most important solution, I propose a greater focus on outreach and communication. Security is still a field where only those who have the history and passion for computers truely understand what’s going on. This needs to change. The average web consumer must be educated to understand the personal ramifications of the “laiser faire” attitude that plagues the web application security world.

Please feel free to share you thoughts in the comments, I’m very interested to hear what my peers have to say on this subject.

Tags: , , ,

Enterprise Vulnerability Metrics, The Tool


In order to effectively implement my plan for tracking enterprise vulnerability metrics and their associated data points, it was clear that a custom application for data entry and report viewing would be required. As such, I wrote a PHP/MySQL web application with the following features and functionality.

Data Model - In order to structure the collected data in the database in a manner which facilitates data extraction from reports, I had to define the reporting needs early in the development process. By doing so, I was able to create a relational data model which makes reporting fast, accurate, and reliable.

Data Input - I’ve provided a series of HTML forms which provide the user with all the data points from my previous article. These forms have been designed with a heavy focus on ease of use and rapid data entry. To provide these features, the input for the required data points have been grouped logically and implement a feature for quick input where the user can select from a list of recent entries for the given data points (eg: recent contacts, recent CVE numbers, etc).

Reporting - I’m a big fan of keeping reporting as open as possible: it makes life much easier down the road. As such, I created a reporting framework which is capable of outputting a list of vulnerabilities based on a query for any data point stored in the database. For example, if you want to know which reports are associated with a given manager, business unit, vulnerability class, or keyword just select your preferences on the search page, and view the results.

Statistics - A data collection tool is worthless unless you have a way to quickly determine the characteristics of the data stored in the database. As such, I created a statistics page which provides the viewer with a snapshot of the vulnerability metrics based on similar characteristics. The following details the statistics and their intended purpose:

Vulnerabilities Created and Resolved

Simple count of vulnerabilities created and resolved (separate counts) in the system for the given time period.

Vulnerabilities Created and Resolved per Category

Simple count of vulnerabilities created and resolved (separate counts) in the system for the given time period per vulnerability category.

Vulnerabilities Created and Resolved per System Type

Simple count of vulnerabilities created and resolved (separate counts) in the system for the given time period per system type.

Vulnerabilities Created and Resolved per Source

Simple count of vulnerabilities created and resolved (separate counts) in the system for the given time period per vulnerability source.

Vulnerabilities Created and Resolved per Impact Rating

Simple count of vulnerabilities created and resolved (separate counts) in the system for the given time period per impact rating category and value.

Vulnerabilities Created and Resolved per Risk, Severity, and Probability

Simple count of vulnerabilities created and resolved (seperate counts) in the system for the given time period per risk, severity, and probability rating.

Vulnerabilities Created and Resolved per Domain

Simple count of vulnerabilities created and resolved (seperate counts) in the system for the given time period per domain name.

Top Report Owners

Simple count of vulnerabilites created and resolved with average time to resolve in the given time period per report owner (the security engineer assigned to the vulnerability).

Top Business Units

Simple count of vulnerabilites created and resolved in the given time period per business unit listed in the contact field.

Top Managers

Simple count of vulnerabilities created and resolved in the given time period manager listed in the contact field.

The tool also contains several usability features such as mass actioning of vulnerabilities (eg: resolve multiple reports at once), a data authorization model defined by report owner (owner can edit and view, others can only view), and a “my” page which displays reports relevant to the user.

In the future I hope to seperate the parts of the tool which are specific to my environment and open source the project so that others can gain visibility into their vulnerability posture.

Tags: , ,

Enterprise Vulnerability Metrics, The Plan and Data Points


Some time back I posted about designing and implementing the processes and tools which would enable me to track vulnerabilities affecting the enterprise throughout their security life cycle (identification to mitigation validation). In addition to providing a central repository for all enterprise vulnerabilities, I also wanted to make sure that we could use the metrics derived from this data to support investments in other areas of IT Security. My target was to have everything ready to start tracking vulnerabilities on the first day of business in 2009.

The data points I decided to track were primarily aimed at providing visibility into how vulnerabilities were identified, who was responsible for them, establishing an enterprise risk profile, and categorizing vulnerabilities according to risk factors. The following is a more detailed list of the metrics I’m tracking and their intended purpose.

The Data Points

Report Source - Tracking where the vulnerability reports are originating from. As options, I decided on direct report, findings from automated scanning, and all relevant existing security processes (security assurance, incident response investigation, etc) as sources.

System Type - Tracking the type of system affected by the vulnerability. As options, web applications, desktop applications, hosts/networks/operating systems, and web platforms seem to encompass all major system types.

Vulnerability Class - Being able to abstract individual vulnerabilities into something that is digestible by a non-technical audience is critical in this field. The National Vulnerability Database (NVD) has adopted a cross section of the Common Weakness Enumeration (CWE) hierarchy that is broad enough for the diversity of vulnerabilities most enterprises would encounter. For more information, checkout the CWE page on the NVD website, http://nvd.nist.gov/cwe.cfm.

Impact Ratings - Giving us a smart way to answer the “how bad is it?” question. The NVD has developed a framework (Common Vulnerability Scoring System - CVSS) where the characteristics of the vulnerability are supplied and the high, medium, low ratings for risk, severity, and impact are derived mathematically based on the supplied characteristics. The mathematical formula for the computation is available in the CVSS documentation, but I had a different idea for computing the h/m/l ratings. First, here are a few of the characteristics, their ratings, and descriptions:

Access Vector (AV)

Local - vulnerability can only be exploited from the local system.
LAN - vulnerability can only be exploited from the local area network.
Network - vulnerability can be exploited from the internet.

Authentication (AU)

User - User level authentication is required to exploit the vulnerability.
Admin/Root - Administrator/root level authentication is required to exploit the vulnerability.
None - No authentication is required to exploit the vulnerability.

Remediation Level (R)

Official Fix - The vulnerability has been fully remidiated and tested according to guidance given by security staff.
Temporary Fix - The vulnerability has been mitigated temporarily while a permanent solution is devised.
Workaround - A workaround exists to circumvent the vulnerability.
Unavailable - No remidiation is available for the vulnerability.
Not Defined - Remediation for the vulnerability is unknown.

Additional impact ratings include Access Complexity (AC), Confidentiality Impact (C), Integrity Impact (I), Availability Impact (A), Exploitability (E), and Report Confidence (RC). Each of the values associated with the impact ratings is assigned a whole integer from 1 - 3. For impact ratings where there are more then 3 options, I found that in each case, 2 of the options were close enough to be assigned the same value. For determining which value I would assign to each impact rating, I assumed the greater the value of the impact rating, the more serious the vulnerability for the given impact. For example, for Authentication, User is assigned a value of 2, Admin/Root a value of 1, and None a value of 3. I then weighted each impact rating based on the importance attributed to the impact. For example Access Vector (weight of 2) is much more of a factor when determning risk than Report Confidence (weight of 1). To further clarify the impact of a vulnerability, I wanted to produce ratings for risk, severity and probability which are determined with the following equations:

Risk: (2*(av) + 2*(ac) + 2*(au) + c + i + a + 2*(e) + 4*(r) + rc)/15.
Severity: (c + i + a + 2*(e) + rc)/6.
Probability: (2*(av) + 2*(ac) + 2*(au) + 4*(r))/10.

Once the risk, severity and probability have been determined, I use the following ranges to assign high, medium, and low:

High: >= 2.00.
Medium: >= 1.00 and <= 1.99.
Low: >= 0 and <= .99.

Contact Information - Tracking who is reporting the issues, and who is responsible for fixing them. For each contact entered into the system, I wanted to capture their name, contact information, business unit (only for enterprise contacts), and their manager (again, only for enterprise contacts). The purpose of the contact information data points is to be able to determine which group within the enterprise we can target for education regarding specific topics in security. For example if we find that product team X has an abnormally high number of input validation vulnerabilities, we could justify investing in some XSS and SQLi training and know that it will be beneficial.

URL - I wanted to be able to present the data by fully qualified domain name (FQDN) to easily present the data to site owners.

Other - In addition to the data points mentioned above, I’ve also provided inputs for tracking of CVE numbers and internal ticket tracking system numbers. While this isn’t particularly relevant to vulnerability tracking, it will give my management a tie in to existing processes.

Provided that the data entered into the vulnerability tracking system is reliable and up to date, answering the “What’s wrong?“, “How widespread?“, “Who’s responsible“, “What’s the exposure?“, “What if we don’t fix it?“, “Where should we invest resources?“, and “How’s the security?” questions should be no problem from here on out.

Tags: , , , , ,

New Research Papers Posted


I’ve posted a couple research papers that I’ve written recently.

Secure Authentication and Authorization
In this paper, I lay out the key components to planning, designing, and implementing a secure authentication and authorization model for web applications. I discuss topics like data classification, application functionality inventories, unique session ids, and login forms providing PHP code samples as examples.

Cross Site Request Forgeries (CSRF)
In this paper I describe CSRF vulnerabilities, how they occur, and different techniques that can be used to mitigate them. Some of the mitigating techniques discussed include nonce checking, server side business logic enforcement, CAPTCHA, and IP address based rate limiting.

Please take some time to check out the Research / Papers tab on the blog and feel free to leave some comments.

Tags: , , ,

Security Snake Oil: Encrypted Login Forms Don’t Ensure Confidentiality!


As a web application security testing professional, you often encounter “snake oil” security implementations. A recent example would be the “Hacker Safe” ruse which has been exposed time and time again by the security community. Today, I come to you with another: Partially encrypted web applications aren’t protecting you!! Let me explain the situation. Most web applications have implemented SSL/TLS encryption for you to login without exposing your username and password to the guy in the black trench coat also using the wifi at the coffee shop. This kind of protective measure inspires the trust of the user in the application, but does very little to actually protect your identity, data, or in the event of social applications, your reputation.

At the heart of the problem is the way that the web server maintains a unique session for each visitor: by setting and tracking a unique value in the cookie. Once a visitor logs in, the unique web server session is bound to the authenticated user making the session identifier equivalent to the username and password. To further compound the issue, the contents of the cookie are automatically transmitted over the network with each request that the browser issues to the webserver.

Once an attacker has sniffed the contents of the web application’s cookie from the network, they have obtained the key component for impersonating the victim on the target site:

  • Social Networks - an attacker can perform smear campaigns by posting items to the targeted profile for the victim’s contacts to see.
  • WebMail - an attacker can create a mail filter to read the victim’s email. This attack has already resulted in a blogger being victim to domain hijacking.
  • Administration Interfaces - an attacker can perform unauthorized changes to devices or services which utilize administrative interfaces to update settings.
  • Financial Applications - an attacker could steal money or financial information on vulnerable web applications. (Applications which accept credit card payments are subject to PCI-DSS compliance and lack of encryption would no comply. Sites who only accept PayPal or other online payment processors are not subject to PCI-DSS).

Application users must learn to recognize when they’re being misinformed about risk and demand more security from the vendors. Application designers and vendors must implement encryption for the entire application. If the additional server resources are of concern, a hardware appliances for SSL/TLS can be installed so that the web server does not suffer from the overhead resource consumption.

Tags: , ,

« Previous Entries