AppSec Notes

Bizarre CAPTCHAs

noreply@blogger.com (Dave Ferguson) — Sat, 30 Mar 2013 17:21:00 +0000

We all understand the security benefits of using a CAPTCHA as it relates to anti-automation in a web application. The most common implementation of CAPTCHA functionality is reCaptcha, a technology that Google purchased in 2009. Most of the time it works great, but recently I ran across a site that was producing some bizarre images. I saved a few of these, and I'm pleased to present them here now for your enjoyment!

Hmm, I don't have some of these letters on my keyboard:

Users are expected know calculus now?

If a word is upside down, would you enter it left to right or right to left?

Absolutely no clue:

The Audacity of Your Flashlight App

noreply@blogger.com (Dave Ferguson) — Thu, 29 Nov 2012 04:55:00 +0000

I've been taking a closer look at my mobile apps lately, specifically the permissions they request when downloading and installing them. It has been quite an eye opener. It turns out that mobile apps are invading our privacy. It's as simple as this: any app that can read your contacts and access the Internet can slurp your data and send it off to some random server to be stored and/or used in a nefarious way.

The finding that surprised me the most was the audacity of my little old flashlight app. I was using "Tiny Flashlight + LED", which is allowed to read your phone identity and have full Internet access. A flashlight app that needs Internet access is nonsensical to me. I switched to use OI Flashlight, which requires only the permissions of camera control and preventing the device from sleeping. I discovered during my research that most flashlight apps want Internet access. The top 4 flashlight apps that appear when searching for "flashlight" on Google Play are:

All four require Internet connectivity! However, the winner of the most inappropriate and egregious permissions contest is "Brightest Flashlight Free" by Goldenshores Technologies, LLC. This popular app (over 10 million downloads) requires the following permissions:

full Internet access
your location (both coarse and fine)
modify your SD card contents
read your phone identity

Can you think of a reason a flashlight app needs to know your current location or modify the data on your SD card? I can't either.

Risky to Report Website Vulns

noreply@blogger.com (Dave Ferguson) — Tue, 20 Nov 2012 23:19:00 +0000

The main reason I stopped reporting vulnerabilities to website owners is the risk of being prosecuted. The Internet is more dangerous when well-meaning security researchers are treated this way. I was new to Application Security in 2006, so I didn't realize that I was actually taking a pretty big risk when I told Netflix about their CSRF vulnerabilities. In my mind I was doing them a favor. They got a free mini pen test. In fact as a Netflix subscriber, I was giving them money! It turns out they were nice and simply said "thank you", then went about fixing the issue.

Today I ran across Patrick Webster's story from Australia and he wasn't so lucky. He noticed that his bank's web application allowed for any customer to view another customer's account information, including very sensitive data that could allow for identity theft. This type of insecure direct object reference vulnerability is very simple to exploit. Mr. Webster just changed a numerical parameter in the URL to discover the problem. He reported it to his bank, who decided to report him to the police. It's not like this guy was a determined attacker with premeditation who spent weeks doing reconnaissance on the site. That said, he clearly went too far by running a script that "cycled through each ID number and pulled down the relevant report to his computer". That wasn't necessary to report the vulnerability.

Another example is Andrew Auernheimer who is potentially facing 5 years in prison due to his AT&T "account slurper" script. Again, he went too far with the script, but clearly he might've been prosecuted anyway. One of the comments on this story was humorous:

You seem to be implying that every exploit can be anticipated. The article points out that AT&T changed their code after discovery of the hack. There is no indication that they knew it was a problem before hand.

Web app vulns can and should be anticipated.

"Sorry, that password is already in use"

noreply@blogger.com (Dave Ferguson) — Wed, 10 Oct 2012 14:56:00 +0000

Here is a good example of the kind of insecure practices application developers are doing out there.

http://lists.webappsec.org/pipermail/websecurity_lists.webappsec.org/2012-October/008535.html

Thank you Jim Burton for being concerned and speaking out. I have to admit laughing out loud when first reading this. That may have been wrong of me.

Time to Update Your LinkedIn Password

noreply@blogger.com (Dave Ferguson) — Wed, 06 Jun 2012 23:55:00 +0000

Change your LinkedIn password! Also change it on any site where you use that same password. In case you missed it, about 6.5 million LinkedIn passwords were leaked today. The passwords were in the form of unsalted SHA-1 hashes. This leads you to believe that LinkedIn was not following secure best practices in terms of storage of user passwords. A blog post from LinkedIn indicates that hashing and salting of user passwords was "recently put in place". I wonder how recently? Probably today.

If you are curious about whether your password was compromised, head over to LeakedIn.org, a site just launched by PHP security guru Chris Shiflett. (Side note: Chris authors a very informative blog and I've learned a lot about AppSec from his posts over the years.) Once there, enter your LinkedIn password. Client-side JavaScript code will produce the corresponding SHA-1 hash, then send the hash value to the server. You will soon find out if your password was part of the 6.5 million that were leaked and whether or not the hash was cracked. If you don't feel comfortable entering your password, just run HashCalc locally to calculate the SHA-1 hash of your password and enter the hash value instead. I did this check today and my password was indeed among those that were leaked, but it hadn't been cracked yet.

Needless to say, I've changed my LinkedIn password. It's a perfect example of why you should be using different passwords for every site you use.

AppSec Shouldn't Be Something Special You Do

noreply@blogger.com (Dave Ferguson) — Tue, 22 May 2012 18:53:00 +0000

To really improve the security posture of applications, development shops must get to a place where security is simply part of their normal development process. In other words, designing secure software and writing hack-proof code shouldn't be a special side project or considered for the first time during the testing phase. This point was nicely explained in a short interview with Chris Wysopal.

Making application security an inherent part of your SDLC can be done on a gradual basis. You could start with instructor-led training of developers to teach them appsec concepts. I did this type of training for several years. A more scalable way to teach developers is computer based training (CBT), also known as eLearning. This may be your only option with hundreds or thousands of developers on staff and limited budget.

Another key piece to building security into your SDLC is regular static and dynamic testing of applications. The goal is to find vulnerabilities and fix them before going live. Static analysis looks at an application from the inside out. You may also hear this referred to as white-box testing or static application security testing (SAST). Static analysis can be done for any type of application (web, thick client, mobile, glue code, etc). Dynamic testing involves looking at a web application from the outside in and is also known as black-box testing or dynamic application security testing (DAST). Both static and dynamic testing should be done to have the best chance at finding all the vulnerabilities. They are complementary approaches, although there is some overlap in the issues they can find.

Latest OWASP Educational Video

noreply@blogger.com (Dave Ferguson) — Fri, 29 Jul 2011 03:29:00 +0000

The latest episode in the educational video series from Jerry Hoff and OWASP is out. This one is all about stored XSS, aka persistent XSS. Another outstanding resource to introduce concepts of web application security to developers!

Account Lockout Fail

noreply@blogger.com (Dave Ferguson) — Sat, 02 Jul 2011 02:17:00 +0000

A while back I was hunting for vulnerabilities in a web app's Forgot Password feature. On the first page you had to enter your username and email address. The second page asked a personal security question. That is quite weak. I recommend asking for at least 3 pieces of data on the first step. Asking for only two inputs, especially when they are username and email address, is not very secure. Username and email address are often related. If you know one, you might be able to guess the other. For example, the email address for user "jthomas" could be "jthomas@yahoo.com". I also recommend asking two personal security questions on the second page, not just one.

Anyway, one of the things I like to check is whether or not the account is locked after a certain number of failed attempts to answer the security question(s). This is an important defense against attackers who are trying to break in via the Forgot Password functionality. Sure enough, the message "account has been locked" appeared after I purposefully entered 3 wrong answers.

I was just about to make a note about this commendable practice, but something caught my eye. The input field was still there on the page. That's not something you normally see. Usually the application takes it away after a lockout occurs. So being a curious fellow, I proceeded to enter the correct answer to the question. Lo and behold the application sent me to the next page where I was allowed to reset the password on the account. Now that's an account lockout fail! I'm not sure why or how the developers created a lockout message without actually coding the lockout. Just another example of how difficult app security can be.

Blackhole Exploit Kit

noreply@blogger.com (Dave Ferguson) — Thu, 21 Apr 2011 05:38:00 +0000

Something I found surprising at first when learning about real-world SQL injection attacks on web applications is that hackers will strive to insert data into the database, not necessarily try to extract data from it. Why would they do this? They want to inject JavaScript code. Basically, the goal is to leverage SQL injection to create a stored XSS attack on application users. It really shows you how supremely dangerous stored XSS vulnerabilities are, huh?

If successful, the malicious JavaScript code will execute in users' browsers. This is bad. Think of it as executable code, chosen by an attacker, running on a victim's computer. One example of the nastiness that can result is the Blackhole Exploit Kit. This malware originated in Russia and is openly for sale. Blackhole is designed to compromise victim computers by exploiting known vulnerabilities in certain software products like Adobe Reader or Java. Symantec researchers have provided a nice writeup of how Blackhole works. Typically, the badness begins with an iframe (created by JavaScript of course) that points to a Blackhole server.

A U.S. Postal Service website was recently found to have been compromised with Blackhole. There is some question how it happened. Regardless, the thing to keep in mind is that a web application that allows for SQL injection might very well lead to stored XSS attacks.

Educational Videos about Web Application Security

noreply@blogger.com (Dave Ferguson) — Mon, 07 Mar 2011 04:25:00 +0000

A terrific and free resource for introducing developers to web application security concepts is a video tutorial series from OWASP. Jerry Hoff is the leader on this tutorial project. The first two episodes are complete - AppSec Basics and Injection Attacks. The videos are very well done, with nice graphics, sound, and animation.

Latest Forgot Password Best Practices Doc

noreply@blogger.com (Dave Ferguson) — Sat, 11 Sep 2010 17:23:00 +0000

A new version of my white paper entitled "Best Practices for a Secure Forgot Password Feature" is available. You can download the white paper here. No significant changes were made in terms of content, but it does have fewer pages and a more pleasing look now. The link I had given out previously is no longer valid.

Password Complexity Rules

noreply@blogger.com (Dave Ferguson) — Thu, 09 Sep 2010 02:43:00 +0000

A Consumer Reports blogger has been taking Facebook to task for allowing dictionary words to be used as passwords. I can't confirm that Facebook actually forbids the use of these words like the blogger claims. The signup page did not reject the word "animal" when I tried it, and their password strength FAQ does not state that dictionary words are banned.

The flak got me to thinking about password complexity rules in general. It needs to be evaluated when assessing the security posture of a web application. I see huge variety in the password rules that are being used. That's not the problem. It makes sense that highly sensitive applications, such as financial or governmental, should enforce stricter requirements. The problem I see is that the password rules simply aren't strong enough, ever. Identifying this weakness calls for a manual test or a code review. It is not something a web app scanner like WebInspect or AppScan would flag. Maybe that's part of the problem.

Below are the password rules I normally recommend for Internet-facing web applications.

Minimum password length of 7
Maximum password length of 20 or more
Require at least one uppercase letter
Require at least one lowercase letter
Require at least one number
Allow special characters
Do not allow any part of username to appear in the password
Do not allow the user's first or last name to appear in the password
Do not allow any form of the word “password”
Do not allow the same character three or more times in succession

Notice there is nothing about banning dictionary words (other than a number being required). Applications can mitigate that particular risk by using an account lockout mechanism to prevent automated password guessing. Also, it probably goes without saying, but passwords should be case sensitive.

Please let me know if you have any other suggestions on this subject!

Bug Editing Cookies in Web Developer Extension

noreply@blogger.com (Dave Ferguson) — Fri, 28 May 2010 23:26:00 +0000

Just a quick note I've been meaning to post about a small bug in Chris Pederick's Firefox Web Developer extension. It is a fantastic extension and I use it all the time, especially for working with cookies. Kudos to Mr. Pederick!

Unfortunately, what I noticed is that if you have "accept third-party cookies" unchecked in Firefox's privacy options, you can't edit cookies or add cookies. In fact it ends up deleting the cookies that you try to edit. D'oh!

This bug bit me a few times when I was trying to demonstrate session hijacking while teaching an application security class. This bug is a known issue and I'm hoping Chris can find a way to make it work in the next version. In the meantime, I will keep using the extension and trying to remember to enable third-party cookies whenever I teach the class.

A Case for HttpOnly

noreply@blogger.com (Dave Ferguson) — Mon, 17 May 2010 13:26:00 +0000

Last month the Apache Infrastructure Team fell victim to a common web application attack. Rather than keep the information secret, they were kind enough to explain how the attack occurred. The initial attack leveraged cross-site scripting to steal users' session IDs. This is something that could have been prevented if the web app's session cookie had been marked with the HttpOnly attribute. When a web app sets a cookie, the presence of HttpOnly instructs browsers to disallow client-side script from accessing the cookie.

You will sometimes hear or read that HttpOnly helps prevent XSS attacks. That is not quite true. It helps prevent session hijacking. Specifically, it helps guard against one attack vector, namely where session cookies are stolen via XSS. HttpOnly can be used for any sensitive cookie that you don't want falling into the hands of fraudsters. (I should use "fraudster" more often - it is a fun word)

There is one caveat to using HttpOnly. It might break your application if it was written in such a way that the functionality depends on JavaScript having access to the cookie. That is fairly uncommon however.

Dynamically-Generated PDFs

noreply@blogger.com (Dave Ferguson) — Wed, 12 May 2010 14:19:00 +0000

Many web applications will generate PDF files for users so they can view nicely-formatted statements, reports, etc. These dynamically-generated PDFs are typically accessed by users in two different ways.

1) The application creates an actual PDF file on the server and redirects the user's browser to the file (via 302 response code).

2) The application streams the bytes for the PDF directly to the user's browser as part of the HTTP response.

This second method is much more secure. The reason is that a PDF file sitting on a server can probably be accessed by anyone. The only information needed is the directory and the file name. That said, I have seen the first method implemented securely, but two important mitigating factors were employed. First, the application used randomized file names. A globally-unique identifier (GUID) is great for this. Second, the files were deleted within about 10 seconds of them being created. These two factors, when combined, made it almost impossible to gain access to another user's PDF file.

Testing for this vulnerability is simple. If you run across an application that allows you to download a dynamic PDF, make note of the URL when viewing the PDF. Is it a direct link to the PDF file? If so, copy the link, open a different browser (not another window of the same browser), and paste the URL. Is the PDF loaded? If so, then you have a problem, especially if the file name is guessable or follows a pattern. You might also check to see if the PDF is deleted from the server after a time.

This topic applies to other static files that your application might generate dynamically too, such as Excel files. PDFs just seem to be the most common.

Authentication Flaw

noreply@blogger.com (Dave Ferguson) — Tue, 20 Apr 2010 03:45:00 +0000

During an assessment of a financial web application, I found a serious flaw in authentication. The web security scanners at my disposal gave a "seal of approval" on the unauthenticated surface area of the application. Yet, in a matter of a few hours after getting the go-ahead to test the application, I had fully compromised a user's account. How? Basically, by using my brain as a hacker might. Screen shots proving my authenticated access were probably eye-opening to the customer as they had given me only the URL for the site, not any user credentials.

This was a case of flawed forgot password functionality. For users who had forgotten their password, the application worked as follows:

Step 1 - Enter username
Step 2 - Answer question to personal security question and enter email address
Step 3 - Receive email with a new, system-generated password

Can you find the flaws? First, the application asked for only one piece of data initially: the username. It is not hard to guess a valid username. I found that "jsmith" was a valid username. Second, the application asked the user to enter his email address on the second step. Um, shouldn't this be part of the user's profile and already known to the application? Why trust a value entered by the user? Third, which I didn't actually tell you, is that the application allowed an unlimited number of attempts to answer the personal security question.

It happened to be that jsmith's security question was "What was the name of your first pet?". I fired up Burp Intruder with the 100 most common dog and cat names. Very soon I received an email with jsmith's newly reset password. It turned out that his first pet was named "Rocky" (I'm assuming jsmith is a man here - would a girl naming her pet "Rocky"?).

This is an example where a scanner (and a web app firewall most likely) would not alert you to this security hole. All requests, data, and URLs were perfectly legitimate in my attack. The flaws were caused by poor design decisions.

Don't Need No Stinkin' Coupon Print Activator

noreply@blogger.com (Dave Ferguson) — Wed, 03 Mar 2010 07:38:00 +0000

This is a real-life example of exploiting a web application security flaw. I received an email from Discover Card offering some Lowe's coupons.
I was needing to buy some stuff there anyway, so I decided to grab them.
I was soon shocked and amazed. Turns out they expect you to download an executable (something called a"Coupon Print Activator") and run it just to print the coupons.
I am not in the habit of running strange .exe's.
But, I really wanted those coupons (and perhaps sensed my hacking skillz were being challenged). I looked at the requests being made to the server, and noticed that dsppreprint.cfm had some JavaScript pointing to interesting URLs, one to "print.cfm" and one to "print_noplugin_redirect.cfm". The query strings were radically different between the two, so I decided to append the query string from print.cfm onto the other .cfm file.
This hybrid URL ended up in a round-about way returning some HTML with an "embed" tag with a bunch of attributes. One of the attributes was very interesting to me.
A request to this URL returned some raw data that appeared to be meant for consumption by the Coupon Print Activator. It also led me to discover yet another URL.
A request to this URL returned the following jpeg image (numbers masked to protect something or other):
So I got a bar code. Wonder if I could print this bar code and use it at the self-checkout at Lowe's? This would not be unethical as I was entitled to the coupon anyway. I just didn't want ro run that Activator thingy! As a simple test, I jumped over to Lowes.com and added a ceiling fan to my shopping cart. There was an input field for "Promotional Code".
Proceeding to enter the number that appeared below my bar code, I was pleased to see my $10.00 discount applied.
To sum up, coupon obtained, Activator thingy bypassed. Sorry I do not have time get into how this site could have been written more securely. Suffice it to say that exposing data, URLs, and client side logic is not good.

Counting Lines of Code

noreply@blogger.com (Dave Ferguson) — Fri, 22 Jan 2010 05:36:00 +0000

Want some interesting metrics about your code? A nice little Windows utility called LOCmetrics could be just what you are looking for. When preparing for an application source code review, I usually need an estimate for the number of lines of code involved. I've found the numbers provided by development teams can vary significantly from what we actually see when we get the code. That is why I am going to start recommending they run LocMetrics.

LocMetrics has a simple GUI and works with C#, C++, Java, and SQL code. Run LocMetrics and it will dump out physical LOC, executable-physical LOC, and executable-logical LOC. Plus, you get bonus information like number of comment lines, blank lines, cyclomatic complexity (aka McCabe VG complexity) and LOC counts broken down by directory. The most important results are shown in the GUI itself and you get a HTML file containing more detail.

Here's a screen shot of the GUI:

I ran LocMetrics on a few Java libraries for comparison sake. Here are the results.

OWASP AntiSamy 1.3
Lines of Code = 4,576
Executable physical LOC = 1,972
Executable logical LOC = 1,444
Cyclomatic complexity = 259

OWASP ESAPI 1.4.2
Lines of Code = 21,263
Executable physical LOC = 8,926
Executable logical LOC = 6,172
Cyclomatic complexity = 1,547

JSE 1.6.0_17 (java.* package only)
Lines of Code = 556,018
Executable physical LOC = 200,567
Executable logical LOC = 136,076
Cyclomatic complexity = 38,106

Tomcat and HttpOnly Session Cookies

noreply@blogger.com (Dave Ferguson) — Thu, 26 Nov 2009 00:24:00 +0000

Just wanted to let you know that Apache Tomcat can now be configured to use HttpOnly session cookies. I had forgotten about Jim Manico's crusade to get HttpOnly support in Tomcat. It is a shame that it took so long to happen. Microsoft had introduced the concept of HttpOnly cookies primarily as a defense against session hijacking where a cross-site scripting attack is used to steal a session cookie. If a web application sets a cookie with the HttpOnly attribute, web browsers do not allow client-side script to access the cookie. The first browser to support HttpOnly was Internet Explorer 6 SP1 and for a long while IE was the only browser that supported it. That has changed as Firefox and Opera, for example, now support HttpOnly as well.

In Tomcat, enabling HttpOnly for the JSESSIONID is done at the context level, which means it can be controlled for each individual web application. You simply need need to add the following attribute to the <context> element:

useHttpOnly="true"

The default is "false", so you must explicitly add the line above to implement an HttpOnly session cookie. This capability first appeared in Tomcat 6.0.19 (current version = 6.0.20) as well as Tomcat 5.5.28, which is currently the latest version in the 5.5 branch.

OWASP Top Ten Changing for 2010

noreply@blogger.com (Dave Ferguson) — Thu, 19 Nov 2009 02:03:00 +0000

A new version of the OWASP Top Ten will be arriving in early 2010. At the AppSec DC conference, I attended a session by OWASP board member Dave Wichers that described the proposed changes. First, the emphasis will be on risk, whereas the 2007 version focused on the most prevalent vulnerabilities. The updated list considers not just prevalence, but also the damage level that could result from successful exploitation.

The biggest changes are that Malicious File Execution and Information Leakage/Improper Error Handling are dropping off the list for 2010. In their place, Security Misconfiguration and Unvalidated Redirects/Forwards are being added. Some other items are shifting around. The chart below sums up the changes very nicely.
The release candidate of the new Top Ten is now available for download as a PDF document. OWASP is requesting feedback on anything and everything until December 31, 2009. I've not yet read the document in detail. At first glance, I wonder about the naming conventions. For example, is "Injection" descriptive enough? Is "misconfiguration" a real word? Why is "Insecure Communications" changing to the more cryptic "Insufficient Transport Layer Security"? I guess now is the time to ask!

XSS via Cookie - How Severe?

noreply@blogger.com (Dave Ferguson) — Thu, 05 Nov 2009 21:16:00 +0000

Take a web application that sets a cookie. Now let's say the application takes the cookie value included in subsequent requests and outputs it into the HTML of the responses. Also assume this occurs with no authentication required and with no output encoding being done. Yes, this application is susceptible to reflected cross-site scripting.

I recently tested such an application. Interestingly, both HP WebInspect and Burp's active scanner reported the XSS vulnerability, but they were at opposite ends of the spectrum in terms of rating its severity. WebInspect rated it "critical" (the most severe rating), while Burp rated it as "information", which implies you don't even need to concern yourself about it.

So why the big disparity in these tools? Is it critically severe, or is it really no big deal? In my view, the answer is somewhere in between. This type of vulnerability is clearly very difficult to exploit. An attacker would somehow have to cause a victim's browser to send a script-injected cookie as part of a request to the vulnerable site. But regardless of the difficulty level, the application should properly encode the cookie value when it is written into the HTML page. Please let me know your opinion on how serious you think this type of vulnerability is.

Internet Safety for Parents

noreply@blogger.com (Dave Ferguson) — Sat, 17 Oct 2009 04:36:00 +0000

A friend asked me about Internet safety including how parents can protect children from the nasty stuff that's out there. I replied by describing what I do at home. It's probably not the perfect system, but it seems to work for me.

If you know nothing about Internet safety, start by visiting the resources listed here. Educate yourself about Internet dangers and the kinds of protection available.

In terms of filtering, I recommend using the Windows Vista built-in parental controls. You can select age-appropriate access level, define time restrictions, view logs of sites visited, etc. Each user must have their own login on Vista (no sharing accounts!). If you're not using Vista, please think seriously about upgrading. The parental controls feature alone is worth the money. However, at this point in time you should probably upgrade to Windows 7 since its release date is near. I assume it has the same or even better parental controls.

Defense in depth applies in protecting children too. So for better protection, I also recommend using BlueCoat's K9 Web Protection (available for free). It is not as flexible (all users have the same filter level), but it catches some stuff that Vista doesn't. If you are currently stuck on Windows XP, use K9 at least. Just remember it is not perfect.

Finally, if you don't want a hacker opening a reverse shell and taking over your computer, make sure you check for software updates at least weekly! Or, have it done automatically if possible. These updates should include not just Windows and Anti-Virus software, but also Internet Explorer, Adobe Reader, Flash Player, Firefox, Thunderbird, Java, iTunes, etc.

ColdFusion Session Fixation

noreply@blogger.com (Dave Ferguson) — Sat, 10 Oct 2009 01:27:00 +0000

I usually see session fixation vulnerabilities with Java web applications. Just recently I found a ColdFusion application vulnerable to session fixation. This nasty security hole greatly increases the risk that legitimate sessions will be hijacked. Both HP WebInspect and Burp Pro's active scanner failed to find this vulnerability. Testing for session fixation is quite easy to do, so I ran a quick test for it manually, and I'm very glad I did.

When testing for session fixation, I like to use two different browsers: IE and Firefox. If the login page for an application is https://someapp.com/login, my test for session fixation consists of the following steps:

https://someapp.com/login.jsp;jsessionid=[sessid]

https://someapp.com/login.cfm?cfid=[cfid]&cftoken=[cftoken]

The ColdFusion site I tested was handling the situation even more poorly than usual. It was not necessary to visit the site initially to obtain legitimate session IDs from the server, so steps 1-3 above weren't required. An attacker could make up *any* 6 digit value for "cfid" and *any* 8 digit value for "cftoken", embed the made-up values in the malicious URL, and the application happily accepted them. The server responded by assigning CFID and CFTOKEN cookies based on the made-up values as illustrated below.

The URL of the request was:
https://someapp.com/login.cfm?cfid=999555&cftoken=29292929

The HTTP response contained the following headers:
Set-Cookie: CFID=999555; path=/; Secure
Set-Cookie: CFTOKEN=29292929; path=/; Secure

Who Has the Answers to Your Security Questions?

noreply@blogger.com (Dave Ferguson) — Sat, 03 Oct 2009 06:31:00 +0000

I'm back after a summer that was crazy busy for me. Recently, I had two eye-opening occurrences where other people viewed the answers to my personal security questions - you know, those questions that web sites ask in case you forget your password. These incidents weren't security breaches, just normal business processes that appear to be more prevalent than I thought.

In the first incident, I got a new cell phone for my daughter at a retail store of one of the major providers. I gave the clerk my cell number so he could look up my account and he then asked for my "PIN". I didn't know it. I knew my password for their site, but that's not what he wanted (I wouldn't have told him anyway). Since I didn't know my PIN, the clerk followed up by asking me "What's the model of your first car?". Whoa. I proceeded to answer the question. He looked at his monitor and said "okay, good".

The other incident involved Vanguard again. I got locked out of their site (not just unrecognized like last time). The darn thing wouldn't even allow me to answer my security questions. Forced to call Vanguard customer service, I explained to the CSR that I was completely locked out. Wouldn't you know the CSR simply asked me to answer two of my security questions? I provided the correct answers, and he immediately unlocked my account allowing me to log in again.

Moral to the story: These answers are not simply being used programmatically or being treated as confidential data. Realize that the answers to your personal security questions could be viewed by other people in many cases.

Vanguard.com Doesn't "Recognize" Me

noreply@blogger.com (Dave Ferguson) — Wed, 24 Jun 2009 23:44:00 +0000

I upgraded the hard drive on my home computer. The first time I tried to log into my Vanguard account online, it asked me to answer a security question. No problem I thought to myself. The site just doesn't recognize me since I have a new drive. It wants extra information to be sure I'm me. This is part of PassMark "sitekey" functionality. I typed in the answer to the question and was promptly told "sorry, invalid answer". Weird. I tried again. same result. I was 95% sure I was entering the correct answer, but each time I tried, it didn't work. Eventually I got an email telling me I disabled my ability to log in from an unrecognized computer due to repeated wrong answers. Nice. The web site didn't inform me of this - only the email. The email also stated I could now only log in if I used a recognized computer. To log in from an unrecognized computer, I would have to reset my security questions or call Vanguard customer service. Great.

Luckily, I had logged into Vanguard from my work computer, meaning it was "recognized" and I wasn't asked a security question. Using my work computer, I logged in and reset my security questions and answers as required. Now back to my home computer. I was quite confident facing a security question this time. But again, failure! Why does it not accept my answer? I was 100% sure it was correct this time. I just reset them for cryin' out loud.

At this point I concluded that it was a bug in Vanguard's site. Do I call their customer support? Ugh. Instead I took the approach of trying to get the site to "recognize" my home computer. Long story short, I copied a single file from my work computer to my home computer and solved the problem. I knew the PassMark/sitekey solution uses a Flash local shared object to determine whether a computer is recognized. It does not use a persistent cookie as you might first guess. Anyway, I found the shared object file "PassMark.sol" in the following directory on my work computer:

C:\Documents and Settings\[user]\Application Data\Macromedia\Flash Player\#SharedObjects\xxxxxxxx\vanguard.com\passmark\flash\pmfso.swf

where "xxxxxxxx" changes for different users. I copied PassMark.sol over to the corresponding directory on my home computer and it worked like a charm! Vanguard's site suddenly recognized my home computer and I got logged in.

This episode was very frustrating and got me wondering how normal users feel. After all, I was only able to solve the problem with:

Luck - I had another computer that was recognized
Esoteric knowledge - Vanguard's site uses Flash shared objects to recognize a computer

The vast majority of users are not web application security experts. They must be going crazy, and on the phone with support a lot.