Monday, October 16, 2006

More on Netflix's CSRF advisory

Security researcher Dave Ferguson posted a Netflix CSRF advisory to a few mailing lists. A nice find and responsibly disclosed. Included was the ability for attacker to add movies to your rental queue, change the name and address on your account, etc etc. As Rsnake said, “pretty scary”, and a vulnerability I’ve called the sleeping giant. C-Net’s Joris Evers covered the incident, Netflix fixes Web 2.0 bugs, and described the severity of the problem nicely. There are some parts of the story that require more context. I've met reporter Joris Evers, nice guy, but as sometimes happens, important technical aspects are left out.

“The problems were repaired before they became publicly known, Steve Swasey, a Netflix spokesman, said on Monday.”

It would be interesting to know how much time and effort it took to fix the issue.

“The problems were repaired before they became publicly known, Steve Swasey, a Netflix spokesman, said on Monday. "It is an extremely remote possibility that it would have affected any of Netflix's 5.2 million members," he said.”

For the moment I’d agree about the low percentage probability. The problem is it’s hard to be sure. CSRF is really hard to spot in the logs since the attack looks like normal web server traffic. In fact, even the logged-in user is the one sending the HTTP request, not the hacker. As the criminal element becomes increasingly familiar with CSRF, we can expect increased usage of the exploit.

"Design flaws in the Netflix Web site were the cause of the relatively new type of weakness in Web applications, …. said Dave Ferguson..."


If "relatively new" means, 6-8 years or more, then OK.

"This type of attack is only suitable for a certain type of Web site. It just happens to be that Netflix is the perfect example," he said. One key thing is when the majority of users keep themselves logged in.”

Not so much. Nearly every website I’ve ever seen has CSRF vulnerabilities. The only difference between one website and another is the features present, which dictate the severity of an exploit. If a website doesn’t do anything, CSRF is meaningless. If users can log-in, change passwords, post comments, etc. then we’re talking about something more damaging.

"Netflix is audited all the time for security," Swasey said. "There was some level of exposure, although not serious." At no point was customer data such as credit card numbers at risk, he stressed.”

With CSRF, credit card numbers are not necessarily the most important piece of data. Neither are usernames and password. When in control of a browser’s authenticated access, a malicious attacker wouldn’t need that data in order to transfer money out of a bank account. Or in this case hi-jack a users Netflix account.

"Cross Site Request Forgery, or XSRF, is seen as one of the security problems that affect feature-rich Web sites. These "Web 2.0" sites often offer an experience more like using a desktop application than like using the Web."

This part and the title of the story reference the ambiguous Web 2.0 moniker. The reality is CSRF affects all websites no matter what technology version they use. AJAX, Flash, its all the same in this respect. For the rest of us, if you think XSS is/was bad and clogs the mailing lists? Just wait till the CSRF issues hit the security scene en mass.

P.S. I’m a Netflix customers, great service and gets my best recommendation!

2 comments:

admin said...

Hi Jeremiah.

I have been seeing some sites regarding the csrf attack, and i get noticed that some sites can't be vulnerables because they have POST or GET requests such as:

-----
comment_content=my_comments%2C+another_comment.
&submit=sended+the+comment&process=newcomment&
randkey=434fcD67&link_id=50056&user_id=1986
-----

-----
https://mywebmail/imp/compose.php?
uniq=1vgyw0g863c0
-----

There are parameters as randkey and similar which only the authenticated user can know. Am i right?

Thanks for your readings :)

Jeremiah Grossman said...

Yes, your right. That's one of the standard methods of defense. However, if the website is vulnerable to XSS, its possible for the exploit to get that randkey and manufacture a valid request.