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.

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?

• Sarah Palin Yahoo! account hacked
• Paris Hilton’s Sidekick hacked
• Fred Durst’s T-Mobile account hacked
• Google search results for: “security question” hacked

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.

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.

• IE: http://support.microsoft.com/kb/258063
  
• Firefox: In about:config, change the value in network.negotiate-auth.trusted-uris to https://the.url.for.your.app

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:

• Subversion (SVN)
• Mantis Bug Tracking Application (with Apache Basic Auth support)
• MediaWiki (with Apache Basic Auth support)

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.

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.

Per RFC 2109

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:

1. Victim logs into GMail using SSL*.
2. Victim uses the same browser to visit another web page (while keeping the GMail window open)
3. The SurfJacking tool detects step 3 and issues a fraudulent 302 HTTP Response code (Permanently Moved) pointing to http://mail.google.com
4. 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.
5. SurfJacking identifies the cleartext GMail session identifier and logs it for the tool operator.
6. 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.