 |
||
Total Website Security |
||
|
||
|
|
|
|
|
Jeremiah Grossman Blog :: CSRF DDoS, Skeleton in the Closet Before getting into the focus of this post I’d like to provide some background: CSRF, like XSS, is one of web application security industries skeletons in the closet. Over the years only a precious few industry insiders were aware of CSRF and appreciated its significance. The larger infosec industry discounted CSRF (and XSS) because it wasn’t “elite” enough for their taste as it didn’t enable “root” access. All attention was instead placed on various types of buffer overflows, which is important, but not exclusively so. Web security experts on the other hand tend not to care about getting root on boxes because all the value is now within the browser walls. Why hack someone’s machine when its easier to go after a Web bank/email/brokerage directly? Even today on this very blog are comments saying, “XSS is not hacking, get some real exploits”, and I’m sure most readers here have encountered similar attitudes elsewhere. It’s this type arrogance and closed mindedness that got us into this mess and why maybe 20% of infosec conference audiences have even heard of CSRF. Developer audiences it’s lesser still. As a result we’re faced with a situation where millions of websites are already built (and vulnerable) where developers never considered CSRF protection because they didn’t know it existed. Browser vendor are trying to figure out what to do and likely years off from meaningful results. And now the bad guys have recently caught on and beginning to cause real damage. It’s with this context in mind that I share my thoughts about DDoS attacks carried out by way of CSRF. Also, I take no credit for the novelty of this attack as its been rumored around in various circles for years. I’m merely drawing attention to the issue. Here’s the basic exploit code that a bad guy would need: <* IMG SRC=”http://victim/” > Simple enough? All the bad guy needs to do is post the HTML snippet to a large number of public websites where other users would come in contact with it. These websites could be message boards, guest books, WebMail, blog comments, social networks, chat rooms, and so on. All the types of websites quite popular, free to sign-up, and easy to automate (save for CAPTCHA). The code instructs a users browser to make an HTTP request to an arbitrary location (victim) invisibly and behind the scenes with connections originating from all over. This makes the attack difficult to stop and obviously the more frequented the websites are the more effective it is. Want increase the number of connections per user? Just multiply the number of injections per page, probably maxing out right around 10 or so per user. I’ve tested this across a dozen websites simultaneously reaching about 200 requests per second on the target web server. Something more automated and advanced could easily surpass what I was able to accomplish. Want to increase the per request CPU processing of the target? Target the search application using several keywords separated “AND” operators, like so: <* IMG SRC=”http://victim/search?q=TERM1+AND+TERM2+AND+TERM3 …” > Want suck up a lot more bandwidth? Try URLs that are 2K or so in size: <* IMG SRC=”http://victim/AAA…” > Want to scrub the referers from the requests? There are tricks for that to. Anyway, you get the idea. Anyone have any bright ideas on what a defense might be? VA + WAF, yes it really works! March 11, 2008 Over the last week I’ve been inundated with people interested in WhiteHat Security’s new partnership with F5, specially the integration between WhiteHat Sentinel and their web application firewall (ASM). This is where we identify vulnerabilities, send custom rules to their WAF, and customers mitigate issues with the push of a button. It was actually Arian Evans (WhiteHat Security, Director of Operations) who reminded me what this means for WhiteHat as a company when he recalled a conversation he had with Bill Pennington (WhiteHat Security, VP of Services) and myself upon first joining the team. The question on the table was, “What is the most compelling story WhiteHat could ever tell?” After a long conversation loaded with acronyms and buzzwords the consensus was simple, “find and fix.” That is, finding vulnerabilities on websites and fixing them on an INTERNET-WIDE scale. Only a year and a half ago few outside company walls believed we could pull off the first part, let alone second. Today we’re well on our way to accomplishing exactly that and even our staunchest critics have come around. Now partnered with F5, whose #1 is performance and load balancers, we’re ambitiously taking the next step. Imagine having the time to take care of vulnerabilities in the source code when and how you choose. Imagine being a security guy with control over the security of your website(s). Many are curious as to how we plan to succeed with the VA+WAF concept where others in the past failed. The answer is two fold. Today’s WAF products are way more technologically mature than in years past, but the most important part is we’re able to fill the biggest missing piece -- accurate vulnerability data. Commercial scanning vendors proved time and time again dumping hundreds or even thousands of unvalidated results loaded with false positives and duplicate vulnerabilities into a WAF just doesn’t work. By contrast, with people, process, and a lot of technology we’ve overcome that hurdle. WAFs can now become easy to set-up, manage, and best of all block attacks attempting to exploit vulnerabilities (a rarity). Bill had the same impression as I did when first seeing the technology work, in a word, “amazing”. The VA+WAF combination resonates with everyone we share it with -- media, analysts, experts, IT professionals, you name it. Can you tell I’m excited? ;) The integration will also mean volumes for PCI 6.6 as a way for organizations to meet their obligations quickly and effectively. In a few short weeks the RSA Conference will be the first place we’ll have a demo on public display. Everyone is welcome to stop by the booth and see it for themselves. I can’t wait! February 28, 2008 Update 02.19.2008: Maybe the title should have read, "It pays to be a Ukrainian hacker." Dan Goodin from The Register follows up by laying it out saying, "Prosecutors with the Justice Department are probably free to file criminal charges against Dorozhko for computer hacking. But given his status as a Ukrainian, it's doubtful they'd succeed. And even if they did, it's even less likely they'd recover the proceeds." According to the New York Times, some guy (Mr. Dorozhko) hacked his way into IMS Health and obtained prerelease earnings information. Soon after the hack, Mr. Dorozhko invests ~$42K in options betting the stock will dive, which it does when the information is publicly released, and he makes a cool ~$300K. The story gets REALY interesting After the SEC investigation begins. Mr. Dorozhko gets to keep this cash because according the judge, “"stealing and trading" or "hacking and trading" does not amount to a violation of securities laws”. Put another way, Mr. Dorozhko was not an “insider” so therefore can’t be charged with “inside trading.” Apparently the way the SEC laws work is that its legal to trade on information illegally obtained, but illegal to trade on information legally obtained. Wrap your mind around that. Careful all you would be hackers, this is not to say that Mr. Dorozhko won’t be prosecuted on computer crime charges. From the story it clearly sounds like what Mr. Dorozhko did was illegal, but what if the attack was more subtle in nature? Take Predictable Resource Location (Forced Browsing) a highly effective approach which exploits the behavior of negligent website owners who post files, but don’t necessarily link them in until a particular date/time has passed. A couple years ago something similar happened in another SEC investigation involving Estonian stock traders. With PRS there is no need to circumvent password prompts, agree to any terms of service, or bypass any security systems. You simply ask for a file on the web server, which may contain some juicy market moving data not yet publicly released. So is obtaining insider information in this way legal? If so, and IANA, then it would be seen to be both legal to obtain insider information this way (via PRS) and legal to trade upon it. Technology Helps, but People Matter MostFebruary 11, 2008 The other day a friend called me up asking what the best scanner (web application vulnerability) is these days because he hadn’t been following the field closely. He recently left a consulting role and signed on as an InfoSec manager at a large organization. His first action was to roll out a website security initiative. He knew of course that I would be highly biased towards Software-as-a-Service. Apparently he would have gone that route, but the company had a policy against outsourcing. No one could quite remembered why. Anyway, before answering his question, I wanted to know more about his environment. I asked if he had a website asset inventory prepared. He didn’t since he just landed although was diligently working on it, but estimated roughly 200 websites. Then I asked how many people were allocated towards managing whatever scanner he bought. 1 Full Time Employee (FTE). I stopped short and said, “That’s never going to work!” A little stunned he asked, “Why not?” I explained by asking from his experience as a consultant how much time they typically allocated for a vulnerability assessment per website, with or without the use of a commercial scanner. He said usually 2 weeks for something comprehensive (consistent with most firms). We figured then to perform just a scan using a commercial scanner (no business logic testing) would require about 1 week to set-up, fine tune, wait, and analyze the results (removing false positives, duplicates, and properly assigning priority) per website. That meant they’d need 4-5 FTEs, not 1! Remember that’s just to scan the websites, to say nothing of identifying business logic flaws, addressing ongoing application changes, or spending time working with developers on remediation. Is VA worth anything if you got no time to work on fixing the issues found? He didn’t want to think about how many FTE’s that would require. I then asked if his new employer had the open head count for the project ready. He coughed and then quickly laughed, but the answer was no, not even close. He started to see the writing on the wall, so I finished the conversation by candidly saying then it didn’t really matter what commercial scanner he bought. No one was going to be around to manage it and was destined for life as shelfware. He appreciated the frankness saying said he’d have a chat with upper management and get back to me. :) Let's Talk Web Application Firewalls (WAFs)January 21, 2008 Over the last month the level of chatter about Web Application Firewalls (WAFs) has increased significantly. At the end of last year I’d receive 1-2 emails per week with questions, but over the last month its up to 2 per day - not to mention all the mailing list chatter. I like to stay up-to-date on the WAF market, even though I’m not in that business, because the value proposition is complementary to mine (website vulnerability assessment). Just like network security with perimeter firewalls, patch management, and vulnerability scanning each is important and fills a unique niche. At first I thought the WAF interest up tick was mainly due to the looming PCI 6.6 deadline (June 30, 2008), not so much, the reasons are more fundamental. You see, the InfoSec people responsible for Web security were usually not on the job when their employers’ websites were developed (insecurely). They were later hired in after the fact to solve the problem, typically once identified by a VA solution or maybe an incident, when preventative software security measures required massive code rewrites. Most of them first attempt an awareness program, a noble pursuit with long-term benefits, but doesn’t solve the immediate problems. The problems are too many websites, with too many vulnerabilities, developers who don’t work for them, and probably don’t care about Web application security anyway. In that position WAFs sound like pretty darn good option since it provides them with direct control. Another interesting thing about WAF technology is that it’s been around for roughly 10 years, still their market really hasn’t taken off (roughly 1,000 deployments by my estimates), but it hasn’t gone away either. That’s probably because the idea of website security without having to fix the code is extremely compelling. Of course there are WAF detractors who say it’s because WAFs don’t do what they promise, are difficult to manage, and people shouldn’t use them anyway because their approach just serves as a band-aid. The fact is the WAF industry has a lot of baggage they must overcome originating from the early days, much of which does not hold true today. A lot has improved over the last several years and I’ve had the benefit of demo’ing these products personally. They have some serious power and flexibility. Here’s the deal, nothing in security is a silver bullet. Everyone knows and gets that. So when a WAF isn’t perfect at something, doesn’t block every attack all the time, and can’t be plugged in and forgotten. That’s to be expected! And that’s what its all about, properly setting expectations. We really need to know what they can and can’t do and how well. Because from where I sit, we NEED WAFs to work, if nothing else but to provide development groups at least a few days of breathing room. I mean, consider the thousands of issues posted on sla.ckers.org, or XSSed.com, or in the WhiteHat Sentinel database. Is anyone really under the impression these will get fixed one at a time or anytime soon? And we’re just talking about the XSS. What about the rest? I like WAFs because they provide Web security experts one more option to get their job done. Dozens of open source and commercial WAFs are available, the most prominent names being Breach, Citrix, F5, and Imperva. Each has its own strong points and better at doing something depending on the current situation. Navigating that environment is the tough part and the more VA solutions deployed like WhiteHat Sentinel, the more we’ll understand that remediation is going to be a huge issue to tackle in the years to come. Geeks.com compromised, but relax, its still "Hacker Safe"January 8, 2008 As reported by ComputerWorld, Geeks.com was hacked and consumer data was lost – the volume of which remains undisclosed. What we do know is the names, addresss, telephone numbers, email addresses, credit card numbers, expiration dates, and card verification numbers on the eCommerce website has the potential of being in unauthorized hands. And right now if you view their Web page it’s ironic to see that they’re still “Hacker Safe” (acquired by McAfee). Oh well, just the continuance of a trend. Anurag also posed a good question about the Geeks.com incident related to PCI, “Should ScanAlert be revoked of their PCI Scanning abilities?” A fair question and probably one we won’t know the answer to for some time – which in and of itself is an answer. We also don’t know if Geeks.com was “PCI Certified” at the time of the incident, who their auditor was, or anything like that. What we do know is they automatically become a Tier-1 merchant, which carries a certain cost impact with it. Once Geeks.com gets done with the incident response fire drill (expensive), PCI compliance is going to cost a lot more. Before it was just a quick quarterly scan and a questionnaire. Now their going to have to do a lot more and get it all signed off by a QSA. Incidents like these are going to bite more and more small to midsized merchants hard in the pocket book - especially since PCI compliance really doesn't make a website harder to hack. I don’t think anyone has really done an analysis on the PCI costs after the fact have they? New Flash XSS Technique (thousands of websites at risk)January 5, 2008 This week I spent a good amount of time studying the recent attack technique disclosed about XSS issues in common Shockwave Flash Files. At first I thought, “eh, looks cool, but probably just some theoretical edge case”. Then in working with white paper author Rich Cannings I came to understand that the details are more complex than I originally gave credit. Apparently the scope of the problem is easy to underestimate with potentially hundreds of thousands of websites at risk (right, as if we needed more XSS to deal with). The other thing is that reasonably workable fixes are going to be a long time coming. In many ways the issue is similar to that of Adobe’s Universal XSS problem from last year. At its simplest, this issue describes that vulnerable Flash files can be used to XSS the hosting domain. The URL would look something like this: http://example/ FLVPlayer_Progressive.swf?skinName=asfunction:getURL,javascript:alert(1)// The URL looks a little different than the XSS exploits we’re used to, but still straight forward enough to understand. So I went to test on www.whitehatsec.com since we use some Flash and try to get some of the paper’s PoC working, much of it researched by Flash hacking extraordinaire Stefano Di Paola. I wasn’t having any luck and couldn’t tell if I was doing something wrong or we weren’t vulnerable, so I asked Rich for some assistance. Turn out the latter was true, but I also learned that just because a website is hosting a Flash file doesn’t automatically mean its XSS’able or XSS’able in the same way as another. Vulnerable Flash files are primarily generated in one of two ways: 1) A Flash authoring tool inserts some generic ActionScript that’ll execute arbitrary JavaScript. 2) Commonly used Flash files design patterns also leave room for the same XSS problem. If you read the white paper, Flash developers need to perform the same input validation as web application developers. Solutions where things get tricky… - Patch the Flash authoring tools - a half dozen tool vendors have been notified with fixes available. The challenge is this requires all Flash developers not only patch, but also regenerate their files and update them on the server. Also website owner often to do not develop their own Flash and rely upon third-party marketing firms who must be contacted. As a result, this process will take significantly longer. - Users update their Flash player – Based on the nature of the issue, I’m not certain of how much benefit to this there is, but might as well patch anyway if there is one available. - Disable or block Flash content – I think most people reading this probably already do some form of Flash blocking, but for everyone else, there are simply not going to. - Remove Flash files from the Web – Sure this could work in some cases, in others it’s easier said than done. Some websites are completely reliant upon Flash and removal is out of the question. Others use Flash for simply advertising purposes, those are going to be difficult to just arbitrarily delete as well. - Move Flash files to a secondary domain – just as is recommended with all third-party / user generated / untrusted content. This solution has promise as it sets up some domain barriers in the event a vulnerable Flash file shows up linked from your website. Vulnerability identification is another area of significant interest… Because this issue is NOT a universal XSS as it is the case of the Adobe PDF bug, issues are going to be harder to track down. We’re going to have to figure out ways decompile/reverse engineer Flash files to determine what authoring tool was used and update our vulnerability scanners so that Flash files can be tested in much the same ways as a web application. This is going to be interesting. Welcome to 2008 everyone, Web 2.0 hacking abound.
|
2007 Archives ›››
|
|
||
|
||
|
||
|
||
