I’ve spent the past 3.5 years working on a team where my primary responsibilities involved “application security”. Now that this era has come to an end, I’d like to share some of the initiatives and define their successes and shortcomings. This is part 3 of 5 so please be sure to read parts 1 and 2.
Threat modeling, architecture reviews, and security consulting
Our application security program always offered a design review service. Initially this service wasn’t very well defined and simply involved a security engineer performing a review of available documentation and interviews with the development team. The outcome of this engagement was a series of recommendation and requirements for the project to implement during the development phase. As you can imagine, this approach was very subjective and lacked documentation, but formalization of the offering was put on the back burner due to the successes with the penetration testing offering.
A little over a year and a half after the application security program was defined, we started focusing on assimilating some of the industry proven approaches to threat modeling and security architecture best practices into our existing design review service. We leveraged the opportunities presented by the local OWASP chapter and were able to obtain the training in formal threat modeling approaches that we were easily able to adapt and offer as a fully documented and repeatable process. Unfortunately, my time with the team was up before we could really determine the effectiveness of this service offering. My hope was that we could use this service to not only identify deficiencies in secure design early in the lifecycle, but also to setup a plan for providing training, code review / SCA services, and penetration testing at the appropriate times. This would effectively setup a consulting relationship between the individual security engineers and the project team where a single person / team could be leveraged for all aspects of application security.
In this time of shrinking budgets, reduced staff, and other various financial constraints, security departments world wide are looking for ways to justify the expense of a well rounded application security program. Jeremiah Grossman (WhiteHat Security / OWASP) and Jeff Williams (Aspect Security / OWASP) have collaborated on a fantastic article that is sure to get security engineers, developers, and managers alike lining up at their executives’ door armed with some great arguments in support of creating or expanding their application security programs.
While I fully support and endorse the content of the article, I can already see the responses from some executives:
“Wow, this is really great, and I fully buy into it, but as it stands, there is REALLY no money extra money in the budget.”
What now? Hopefully, there are employees in your company who are responsible for managing servers, the domain, the networks/firewalls/IDS/IPS, and development efforts; but most importantly, you, who is concerned about the state of application security. Why not use some of the best resources from those groups to form an application security working group? I’ve found that no matter what the company, there are ALWAYS people that are interested in being able to devote some time to learning about how those sneaky hackers are able to break into so many systems. Furthermore, what (good) technologist wouldn’t be interested in expanding their skills?
I’m sure that you’ll encounter some resistance from employees and management alike, after all, time is valuable, but remember, Jeremiah and Jeff have already given you all the ammo you need; use it wisely.
Now that you’ve identified folks who are willing to donate some of their valuable time to this effort, your first step will be educating them about the various activities and processes involved with a complete application security program. Here’s a quick reminder:
Design and architecture reviews and threat models where you work to identify flaws in the application design and architecture as well as imposing security requirements.
Secure coding standards where you work to ensure that developers implement features such as input validation, authentication, authorization, and avoid creating flaws in the business logic as they move through implementation.
Code reviews where through either automated or manual means, developers review their code with a focus on identifying any security issues.
Testing and validation where you ensure that all requirements have been implemented according to design specs.
Deployment and maintenance where you ensure that logs are being monitored, system patches are being kept up to date, and 3rd party libraries used in the application are kept up to date.
The chances are good that some of the folks that have chosen to join the security working group already have some valuable input to provide. For example, the sysadmins might have expertise in Apache, host configuration management, or IPTables. The network folks might have been exposed to web application firewall technology. The developers might have some great security specific libraries that they’ve used on past projects. All of this knowledge is valuable and already at your finger tips. For other topics, search around your social network, if you’re on Twitter, checkout @securitytwits, if you’re a member of OWASP, attend the meetings, talk to folks, try to get an idea of their expertise. Many of the seasoned security professionals who attend these meeting would be happy to come in and present at one of your groups meeting.
So, get out there, talk to people both within and outside of your company, not only will you expand your social network and improve your companies application security program, but you’ll also be giving new opportunities to those who join the security working group.
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.
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.
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.
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 exposedtime 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.
Most modern web applications built on web development frameworks (PHP, Java, .NET, etc) use the cookie to store session identifiers which track a visitor’s activity throughout the site. Moreover, these session identifiers are also used when determining the visitor’s identity and authorizing transactions throughout the web application. As such, this value, which is transmitted with every HTTP request as part of the cookie, becomes a very attractive target to attackers.
To minimize the risk of exposing the session identifier on the network in cleartext the data going between the visitor’s web browser and the web application server must be encrypted using SSL. Baring any other vulnerabilities in the code such as XSS, code injection or SQLi one would assume that the session identifier is well protected…Not if the Secure only cookie flag hasn’t been set.
The Secure attribute (with no value) directs the user agent to use only (unspecified) secure means to contact the origin server whenever it sends back this cookie.
The user agent (possibly under the user’s control) may determine what level of security it considers appropriate for “secure” cookies. The Secure attribute should be considered security advice from the server to the user agent, indicating that it is in the session’s interest to protect the cookie contents.
This excerpt of the RFC simply means that if a cookie has the “Secure” option enabled, the browser must only send the cookie when the HTTP request is performed over SSL. The importance of this option is highlighted by a recent attack by Sandro Gauci of Enable Security.
In his paper (and video), Sandro demonstrates how an attacker on the same network physical network can use his tool (SurfJacking) to hijack another user’s authenticated SSL session with GMail and successfully obtain the session identifier. His approach is so simple, I regret not having thought about this myself:
Victim uses the same browser to visit another web page (while keeping the GMail window open)
The SurfJacking tool detects step 3 and issues a fraudulent 302 HTTP Response code (Permanently Moved) pointing to http://mail.google.com
The victim browser accepts the redirect and initiates a connection with http://mail.google.com using the same session identifier as was used in the SSL connection.
SurfJacking identifies the cleartext GMail session identifier and logs it for the tool operator.
Attacker accessing the victim’s GMail account.
* The browser connection setting in GMail must be set to Don’t always use HTTPS (which is the default)
Sandro Gauci has written a paper and created a video demo to illustrate the attack. The video shows the SurfJacking tool in action as well as mitigating the attack by enabling SSL only cookies with the “browser connection” setting in GMail. Please be sure to check them out.
I’ve spent the past 3.5 years working on a team where my primary responsibilities involved “application security”. Now that this era has come to an end, I’d like to share some of the initiatives and define their successes and shortcomings. This is part 3 of 5 so please be sure to read parts 1 and 2.
In this time of shrinking budgets, reduced staff, and other various financial constraints, security departments world wide are looking for ways to justify the expense of a well rounded application security program. 
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.
I’ve posted a couple research papers that I’ve written recently.
As a web application security testing professional, you often encounter “snake oil” security implementations. A recent example would be the “
Most modern web applications built on web development frameworks (PHP, Java, .NET, etc) use the cookie to store session identifiers which track a visitor’s activity throughout the site. Moreover, these session identifiers are also used when determining the visitor’s identity and authorizing transactions throughout the web application. As such, this value, which is transmitted with every HTTP request as part of the cookie, becomes a very attractive target to attackers.
DandyID
Friendfeed
claimID
Disqus
Facebook
Twitter
myOpenID
Google Profiles
Linkedin