From Security Weekly Wiki
Jump to navigationJump to search

Episode Media


Tech Segment: CSRF (Cross-Site Request Forgery)


I want to put some effort and focus on the show into web application vulnerabilities, because we don't talk about them enough. Furthermore, the last time we talked about them, we sucked, so here's my effort to *start* to redeem ourselves.


CSRF is probably one of the oldest vulnerabilities in our field. It all started with a paper in 1988, which I enjoyed reading so much as the tender age of 11. Just kidding, the orginal paper was titled "The Confused Deputy: (or why capabilities might have been invented)". In it Norman Hardy talks about the deputy, or the program that is taking action on behalf of the user. Wikipedia describes the passwd program, a user wishing to access its entry in /etc/passwd needs to access the entire file, not just the users record. A confused deputy is a program that can exploit this trust, and in the case of the passwd program, change another users password, not just your own. Its up to the passwd program itself to regulate and monitor this behavior, thus a bug in passwd could result in a security breach for the entire system.

Fast forward to the year 2000, and a CERT advisory touches upon this very same topic in the context of malicious code loaded from one web site abusing a trust relationship, "At the heart of this vulnerability is the violation of trust that results from the "injected" script or HTML running within the security context established". Later on, this attack gets a name, CSRF ("sea surf") by Peter Watkins in a posting to bugtraq. And in that, Peter brings us to the crux of the issue:

The problem is what I call CSRF (Cross-Site Request Forgeries, pronounced "sea surf"). Any time you can get a user to 
open an HTML document, you can use things like IMG tags to forge requests, with that user's credentials, to any Web 
site you want -- the one the HTML document is on, or any other.

The Attack

So, from a users perspective, you can be logged into your bank application, click a link which brings you to another web site, the other web site executes HTML/Javascript code, which interacts with the bank web application using the credentials you've already supplied. This means, in theory, someone getting you to click on a link while logged into your bank could transfer all of your money to an offshore account. This is a bit scary because it bypasses so many of those countermeasures we put in place and enstill on users, such as:

1) SSL - You can have a perfectly secure SSL connection to your bank, and this attack still works.

2) Strong Passwords/Authentication - Click on as many pictures of monkeys, fingerprint, secure tokens, 23 character random passwords with letters, upper case, lower case, numbers, and special characters, and this attack still works.

3) Anti-virus/Anti-Spyware - LOL, thats all I have to say about that, LOL.

4) Disable Javascript - I mean come, who does that anyway? Be CERTAIN to read Jeremiah Grossman's and rsnake's presentation from BH.


Now, there are a few ways in which you can prevent this attack if you are the owner of the web application:

1) AND BEST WAY - Anti-CSRF token - This means that you validate every form submission with a unique token, so you are certain that the user actually pushed the "submit" button.

2) NOT BEST WAY - Referrer Link Checking - You can configure an Apache re-write rule to check the referer field and make certain it only ever is the URL of you web application. This is a cat and mouse game inside of a rat hole. You have to carefully construct your re-write rule such that it can't be "http://www.evilbadguy.com/www.mybank.com/". Also, there are flash player and IE XMLHTTPRequest vulnerabilities that allow the referrer to be spoofed. Furthermore, some people who are paranoid about privacy actually disable the referrer functionality in the browser altogether. Are we out of the rathole yet? Nope, because what if the application in question is your webmail app? A user already in their mail could open another email, which could then perform a CSRF attack to delete all of your email and empty the trash. Wouldn't that suck? We're not done yet, if your app has an XSS hole, game is over because I can then execute script code as if it was on your server, bypassing the referrer checking.

User education goes a long way too, when you are working inside a web app, don't have other pages open and don't click on any link or load other pages. Not-so-easy in practice, but a good prevention. Some other items of note, the attacker needs a fair amount of understanding to execute the attack to know what commands to send to the web app to either modify or read data to/from it. So, they need an account with the bank for example.

Conclusion: Old attacks are never really old, just named slightly different and applied to today's technology. With functionality comes insecurity, so phear the Internet!


http://www.owasp.org/index.php/Top_10_2007-A5 - CSRF is #5 on the top ten web application vulnerabilities list from OWASP.









Stories For Discussion

Status Bar Spoofing in Firefox - [Paul] - Looks like someone posted a "URL Status Bar Spoofing" concept and called it an "exploit". Strange, my Javascript PoC for URL status bar spoofing still works in Firefox (partial), IE 6, IE 7 (partial). You can find the full-blow lame paper here. Partial means that the bubble hover contains the spoofed site, and status bar contains nothing.

Shady Viagra Marketing - [Larry] - So, not only is Pfizer in trouble for disclosing customer and employee data, it now appears that they have a few spam zombies spitting out spam for Viagra. How ironic! What can be donw in these situations? Defense in depth: patches, principle of least prvelege, lock down workstations, text email, attachment filtering, up to date AV, and yes, egress filtering.

More Browser Exploit Fun - Scanning With Flash - [Paul] - So, I tested it, and it works, now I feel dirty. Flash remains as the ultimate backdoor to browser/web hacking. "Oh, crap, I can't do that in Javascript... Wait, I'll just do my evil in Flash and people will think its You Tube!". YouTube enables the Flash hacking revolution, users just have to watch two British chicks shoot each other with a laser shock device.

A Twitchy web 2.0 rant - [Larry] Quickbooks online has a vulnerable ActiveX control. So, what's the deal with putting all of these apps online like this - especially financial information! I'd highly suggest reviewing corporate use of Web 2.0 apps, especially those that could contain sensitive data.

Still getting Slammed by Slammer? - [Paul] -

Shmoocon '08 Announced - [Larry] - I'm trying to convince the wife to let me go. February 15-17 at the Wardman Park Marriot, Washington DC.

Skype: Is it truly evil? - [Paul] - Users of AppArmor, and well, strace, figure out that Skype on Linux reads the password file, Firefox profile, and some other files in Linux. Look, if you trust Skype at this point you should not call yourself a security professional. Yea, I use it, but its on a Windows partition of my laptop that has a special purpose. I refuse to use Skype on my desktop anymore and prefer Gizmo, however, who can you trust anyway? I mean, you all tune in to listen to me every week, and to quote Bruce Potter, "Don't believe a word I say". Always question...

Metagoofil - [Larry] - A neat tool for evaluating metadata from specific documents found via google. Useful for social engineering, and for usernames to brute force. I'm working with Christian right now on some bugs, and expect a new version this weekend. Keep in mind, that this does not keep you anonymous, unless you use a proxy.

DIY Fishing Kits - A Great Gift Idea - [Paul] - Its sad, phishing has become as easy as filling in a few fields and clicking a button. The attackers are automating the crap out of everything, are the good guys doing the same? We, the good guys, seem to struggle with patch automation, automatically blocking attacks (IPS, SPAM filters). Seems its easier to automate the bad stuff, maybe we should all just throw in the towel and change the color of our hats.

Facebook is Now evil - [Larry] - Facebook was one of the last hold outs on making profile info private. Apparently, now they will be making profile info indexable by search engines. To reiterate a point, now that we have another social networking site to be mindful of, social networks are huge sinks of personal information - your (if you have an account) that can be used to socially engineer, harass, and or stalk individuals. Not to mention, some of the stuff that you put there may come back to hurt you later.

Got Bots? - [Paul] - Along the lines of automation, botnets are like systems management for evil bad guys. To take a look at some of their code see this link. I find it interesting that two of the sites hosting botnet code are in Germany, one link is broken and the other is not. This live link looks like it had many pop-ups, most likely trying to 0wn ppl. I thought that was illegal in Germany? Oh wait, eveil bad guys don't care about that law because they are already breaking it!!! WTF, so pass a law and make it harder for the security researchers like phenolit, THC, Steffan Esser and others to do their thing. Sounds like US laws on gun control, whoops, that was a bit politcal...

Bind 9 DNS Cache Poisoning - [Larry] - I'm sure we've talked about this before, but this might have a little different spin on it. Why do I always pick the stories that have math that I can't understand? In any case the attack boils down to a ton of BIND 9 versions are susceptible to transaction ID prediction. While over the years, there have been improvements in the transaction ID randomization, they still aren't enough. I think the author hits it on the spot with "It is saddening to realize that 10-15 years after the dangers of predictable DNS transaction ID were discovered, still the leading DNS cache server does not incorporate strong transaction ID generation, particularly such one that is based on industrial grade cryptographic algorithms". What possesses non-professional cryptographers to design "cryptography"? Use something tried and true! We see this time and time again - WEP, WPA...

Prying Eyes Are Watching You - Cisco Video Surveillance IP Gateway Authentication Flaw - [Paul] - Watching you, watching you.. Get this, "The Telnet server installed on Cisco Video Surveillance IP Gateway video encoders and decoders does not prompt for authentication. This may allow a remote user with network connectivity to gain interactive shell access with administrative privileges on vulnerable devices.". WHAAAAT! Cisco developer, "Has anyone seen that authentication code for the TELNET server, oh look, British chicks on YouTube....."

Rumor has it we got hacked by China - [Paul] - And it took them how long to figure this out? And does this come as a suprise? And talking to them will do what exactly? Maybe China will pass some of those anti-hacking laws, oh wait, they probably already have them. How come the great firewall of China hasn't blocked these attacks?

Vulnerability in iTunes = Bad - [Paul] - "The vulnerability is caused due to an unspecified boundary error when processing album cover art.", I got a great idea for the album art for this episode! :) [Larry] - I had this same story - here is my entry for posterity: All ur iTunes belong to us - [Larry] - A vulnerability exists in iTunes 4.x through 7.3 (fixed in 7.4, released today), that allows for specially crafted audio files are introduced to the program, in which the album art processing can care a buffer overflow, allowing arbitrary code to be executed. Hmm, who runs iTunes as an admin? I hope you all enjoyed last week's album art....

Other Stories Of Interest

Pornography Drives Technology - [Paul] - I need to get ipv6...

Hackin The SLUG - [Paul] - So, I have a SLUG, and I haven't hacked it yet, shame on me... [Larry] - What? you got a SLUG and didn't tell me? *reaches for leatherman*