Website Security Topics–Jeremiah Grossman Blog 2008
Oh, I Like Surprises!Gary McGraw (CTO, Cigital) provides a must-read article this week, Software Security Top 10 Surprises. Gary, along with Brian Chess (Chief Scientist, Fortify) and Sammy Migues (Director, Knowledge Management, Cigital), interviewed nine executives running top software security programs and provided their analysis. I’m always curious to know what the more progressive organizations are doing regarding software security. Some organizations take up a leadership position and the rest will follow -- eventually. I’ve highlighted several snippets that were specifically interesting to me.
“All nine have an internal group devoted to software security that we choose to call the Software Security Group or SSG.”
“...an average percentage of SSG to development of just over 1%.”
Ladies and gentlemen, we have metrics! Many organization are searching for benchmarks offering guidance when budgeting resources for software security and finding limited information. Their work, along with the OWASP Security Spending Benchmarks project, plan to fill the void.
“We were surprised to find that only two of the nine organizations we interviewed used Web application firewalls at all.”
Wait for it!
“In our view, the best use of Web application firewalls is to buy some time to fix your security problems properly in the software itself by thwarting an active attack that you are already experiencing.”
Whoa! I am surprised as well, but ironically in the opposite direction. I would have estimated the number of WAF deployment lower than 22% (2 in 9). However, we are speaking progressive organizations in this case so perhaps it does make sense. Then Gary, Brian, and Sammy go on to confirm what I’ve been recommending for some time -- use WAFs to quickly reduce the immediate exposure (time-to-fix), then fix the root cause (the code) as time and budget allow.
“Involving QA in software security is non-trivial... Even the "simple" black box Web testing tools are too hard to use.”
“One sneaky trick to solving this problem is to encapsulate the attackers' perspective in automated tools that can be used by QA. What we learned is that even today's Web application testing tools (badness-ometers of the first order) remain too difficult to use for testers who spend most of their time verifying functional requirements.”
Exactly right. It’s one thing for a security pro to learn to use some security tools, run scanners, and hunt down all manner of esoteric Web application vulnerabilities. It’s quite another to expect a QA person to do the same. QA people are not security experts, they have a different skill set, much separate from what webappsec requires.
“Unless you understand how potential attacks really work and who really does them, it's impossible to build a secure system.“
Well said, nothing more to add.
“However, though attack information is critical for SSG members, the notion of teaching work-a-day developers how to "think like a bad guy" is not widespread.”
Precisely. Effort is better spent teaching developers how to play defense, a smaller domain of knowledge, and not offense. Leave the offense to the security guys.
“All nine programs we talked to have in-house training curricula, and training is considered the most important software security practice in the two most mature software security initiatives we interviewed.”
In-house security training support is a must have. An education process fueling what development security standards the organization keeps, the libraries available, and other helpful resources is essential. Much better bang for the buck than generic external courses offered.
Budgeting for Web Application Security“Budgeting” is a word I’ve been hearing a lot of questions about recently, which is another data point demonstrating that Web application security and software security are increasingly becoming a top of mind issue. The challenge that many security professionals face is justifying the line item expense for upper management. Upper management often asks, “How much do we need to spend?” well before “What do we need to spend it on?” I was talking with Boaz Gelbord (Executive Director of Information Security of Wireless Generation) and several others about this, and they provided keen insight on the subject. I have identified the following approaches to justifying security spending:
1) Risk Mitigation
"If we spend $X on Y, we’ll reduce of risk of loss of $A by B%."
2) Due Diligence
"We must spend $X on Y because it’s an industry best-practice."
3) Incident Response
"We must spend $X on Y so that Z never happens again."
4) Regulatory Compliance
"We must spend $X on Y because PCI-DSS says so."
5) Competitive Advantage
"We must spend $X on Y to make the customer happy."
Risk Mitigation
Risk mitigation is the efficient, forward thinking, and scientific approach to security. Many extremely bright people are pushing this methodology forward, especially through SecurityMetrics.org. I’ve had the pleasure of rubbing shoulders with many of them at Metricon events including Andrew Jaquith, author of Security Metrics: Replacing Fear, Uncertainty, and Doubt, who does a stellar job of walking the reader through this world. The fundamental idea is to find an acceptable balance between the amount of investment and the risk reduction that represents "good enough."
While measuring investment against risk makes sense, it is also extremely difficult to quantify in Web application and software security given our industry’s lack of data. We don’t yet have strong data tying loss to root cause and those compromised closely guard the details. Only recently, through WhiteHat Security and WASC Statistics projects are we getting a wide look at who is exposed to what. Also remember that just because a vulnerability exists, doesn’t mean it’ll get exploited. Possible != Probable. My hope is that this approach continues to mature and becomes a widely accepted reality.
Due Diligence
Due diligence is another approach to security budgeting that considers the ramifications of a data compromise if it occurs. Among other things, upper management will want to assure customers and business partners that they were investing resources into the security program in line with industry standards. At the same time, a budget executive may not approve a larger than average security budget in the event no security incident occurs during the fiscal year. This common scenario prompts the question as Boaz puts it, “What is industry standard for security spending in Web application security or software development?” For example, with regard to IT backend systems, there are studies that suggest 3-10% or higher for security spending out of the total budget. In this context, the "Security needs to be embedded into every part of software development" mantra isn’t helpful.
To the best of my knowledge there has been no formal study or survey on how much organizations are spending or should be spending regarding security in software development (or webappsec specifically). What most organizations typically do is outline the best-practices (architectural reviews, security QA, pen-testing, WAF, etc.) they should be implementing relative to peers. Next, they identify the appropriate solutions and obtain rates from the vendor.
Incident Response
Few things free up security dollars faster than a data compromise that is publicly attributed to the organization. That last part is really important. It is possible for an organization to ignore a general Web server compromise, which they may not even know about. For example, when the bad guys are only interested in using a company's resources to improve the Google Rank of some website (i.e. Al Gore’s Convenient Truth blog). Things get much different though when a revenue-generating website is SQL Injected and begins delivering malware to its visitors which has already affected millions of users. The result is the website gets blacklisted by the search engines and traffic sinks like a rock. Now we are talking real quantifiable losses that get people's attention.
At this point an organization is in triage mode. How do they best remove the malware, get off the blacklists (may take days or weeks), and continue business operations? This is also a good time for a security professional when they are given license to pursue projects that ensure a similar event never happens again. They’ll be given the necessary resources to be proactive. They then have the power to prioritize activities that may fall into the category of Risk Mitigation without having to justify “why.”
Regulatory Compliance
Regulatory compliance is a huge justification lever for security professionals. Compliance pressures enables them to do the things they want/need to and gives them the ammunition to justify their requests. For many security professionals, this is of course a very welcome development. And again as Boaz lays it out, “it is much easier for me to justify costs that are legally mandated instead of pointing to threats that in practice are not very likely to materialize. As a citizen/user it is also a positive development, since without legal requirements I think that the already poor state of software/application security would get even worse.” Still the challenge is that most regulations do not indicate how far organizations must take these measures so the mileage will certainly vary.
Competitive Advantage
Competitive advantages. Every organization needs them, and wants more of them. Security that can be demonstrated or made visible can be used as a competitive advantage. Sure, security adds cost to the goods, but that fact could be capitalized on if the customer assumes a level of risk. As Bruce Schneier says, “you can feel secure even though you're not, and you can be secure even though you don't feel it.” For example, the McAfee Hacker Safe or secured via SSL logos can be seen as one of those things that makes consumers “feel” safer when conducting e-commerce. A firm can also engage with a reputable security firm to get a security assessment that can be shared. Deciding which to go with is directly proportional to the customers level of understanding.
At the end of the day no one can say if any one way is the right way, and that was not my intention, but instead to document the approaches I’ve seen gain a better understanding of what works best for a given environment. In order for Web application security and software security to improve, more dollars need to be allocated, so we must assist the stakeholders in that process as best we can.
Browser Security – Bolt It On, Then Build It In
Originally published in (in)-secure magazine #18.
Whether improving ease-of-use, adding new developer APIs, or enhancing security – Web browser features are driven by market share. That’s all there is to it. Product managers perform a delicate balancing act of attracting new users while trying not to “break the Web” or negatively impact their experience. Some vendors attempt an über secure design - Opus Palladianum as an example, but few use it. Others opt for usability over security, such as Internet Explorer 6, which almost everyone used and was exploited as a result. Then, somewhere in the middle, is fan-favorite Firefox. The bottom line is that any highly necessary and desirable security feature that inhibits market adoption likely won’t go into a release candidate of a major vendor. Better to be insecure and adopted instead of secure and obscure.
Fortunately, the major browser vendors have had security on the brain lately, which is a welcome change. Their new attitude might reflect the realization that a more secure product could in fact increase market share. The online environment is clearly more hostile than ever, as attackers mercilessly target browsers with exploits requiring no user intervention. One need only to look at this year’s massive SQL Injection attacks that infected more than one million Web pages, including those belonging to DHS, U.N., Sony, and others. The drive-by-download malware had just one goal - compromise the browser - with no interest in looting the potentially valuable data on the sites. Of course, we still have the garden-variety phishing sites out there. This leads to questions regarding the benefits of end-user education. Users are fed up. So let’s analyze what the Mozilla and Microsoft camps have done in response.
Buffer overflows and other memory corruption issues in the most recent browsers are declining, plus the disclosure-to-patch timeline is trending properly. Firefox 3 and Internet Explorer 7 now offer URL blacklists that block phishing sites and other pages known to be delivering malware. These features are reportedly a little shaky, but it’s clearly better considering there was nothing in place before. Firefox 3 provides additional visibility into the owners of SSL certificates and make it more challenging to blindly accept those that are invalid or self-signed. IE 7 offers a nice red/green anti-phishing toolbar that works with EV-SSL to help users steer clear of dangerous websites. Overall, excellent progress has been made from where we were just a couple years ago, but before the vendors start patting themselves on the back, there’s also some bad news.
If you ask the average Web security expert if they think the typical user is able to protect themselves online and avoid getting hacked, the answer will be an unqualified “no”. While browser vendors are addressing a small slice of a long-standing problem, most people are not aware of the remaining risks of a default install of the latest version of Firefox or Internet Explorer. When visiting any Web page, the site owner is easily able to ascertain what websites you’ve visited (CSS color hacks) or places you’re logged-in (JavaScript errors / IMG loading behavior). They can also automatically exploit your online bank, social network, and webmail accounts (XSS). Additionally, the browser could be instructed to hack devices on the intranet, including DSL routers and printers. And, if that’s not enough, they could turn you into a felon by forcing requests to illegal content or hack other sites (CSRF). The list goes on, but DNS-rebinding attacks get a little scary even for me, and it’s not like we haven’t known of these issues for years.
The browser security oxymoron hasn’t escaped the watchful eyes of the media’s Dan Goodin (The Register) and Brian Krebs (Washington Post), who figured out that something isn’t quite right. Nor Robert “RSnake” Hansen (CEO, SecTheory), who is a little confused as to why organizations such as OWASP don’t pay closer attention to browser security (recent events have shows signs of change). According to sources, only about half of IE users are running the latest, most secure and stable version of the browser. And again, if you ask the experts how they protect themselves, you’ll receive a laundry list of security add-ons, including NoScript, Flashblock, SafeHistory, Adblock Plus, LocalRodeo and CustomizeGoogle. Even with these installed, which relatively few people do, openings still exist resulting in an increasing number of people virtualizing their browsers or running them in pairs. Talk about extreme measures, but this is what it takes to protect yourself online.
Today, my philosophy about browser security and the responsibility of the vendors has changed. In my opinion, the last security-mile won’t and can’t be solved efficiently by the browser vendors, nor should we expect it to. I fully appreciate that their interests in building market share conflicts with those security features experts request, which by the way never ship fast enough. To be fair, there really is no way for browser vendors to make the appropriate amount of security for you, me, or everyone in the world while at the same time defending against all of the known cutting-edge attack techniques. Everyone’s tolerance for risk is different. I need a high-level of browser security and I’m OK if that means limiting my online experience; but, for others that could be a non- starter. So, this leaves the door open for open source or commercial developers to fill in the gaps.
I was recently talking with RSnake about this and he said “I think the browser guys will kill any third party add-ons by implementing their own technology solution, but only when the problem becomes large enough.” I think he’s exactly right! In fact, this has already happened and will only continue. The anti-phishing toolbars were inspired directly from those previously offered by Netcraft and eBay. The much welcome XSSFilter built into the upcoming Internet Explorer 8 is strikingly reminiscent of the Firefox NoScript add-on. Mozilla is already adopting the model themselves by building their experimental Content Security Policy add-on, which may one day work itself into a release candidate.
At the end of the day, the bad guys are going to continue winning the Web browser war until things get so bad that adding security add-ons will be the norm rather than the exception. Frankly, Web browsers aren’t safe now, because they don’t need to be. So, until things change, they won’t be… secure.
Predictably several people did manage to uncovered much of what we had withheld on their own, whom thankfully kept it to themselves after verifying it with us privately. We really appreciated that they did because it gave Adobe more time. Today though much of the remaining undisclosed details we’re publicly revealed and Adobe issued an advisory in response. Let’s be clear though, the responsibility of solving clickjacking does not rest solely at the feet of Adobe as there is a ton of moving parts to consider. Everyone including browser vendors, Adobe (plus other plug-in vendors), website owners (framebusting code) and web users (NoScript) all need their own solutions to assist incase the other don’t do enough or anything at all.
The bad news is with clickjacking any computer with a microphone and/or a web camera attached can be invisibly coaxed in to being a remote surveillance device. That’s a lot of computers and single click is all it takes. Couple that with clickjacking the Flash Player Global Security Settings panel, something few people new even existed, and the attack becomes persistent. Consider what this potentially means for corporate espionage, government spying, celebrity stalking, etc. Email your target a link and there isn’t really anyone you can’t get to and snap a picture of. Not to mention bypassing the standard CSRF token-based defenses. I recorded a quick and dirty clickjacking video demo with my version having motion detection built-in.
Robert and I are currently scheduled to give more or less simultaneous presentations in Asia about clickjacking. For myself, I’ll be delivering a keynote at HiTB 2008 Malaysia (Oct 29) and RSnake will be speaking at OWASP AppSec Asia 2008 (Oct 28). The timing just happened to work out well. The next couple weeks will give us time to put our thoughts in order, explain the issues in a more cohesive fashion, and bring those up to speed who’ve gotten lost in all the press coverage. For those that have been following very closely, you’ll probably not find any meaningful technical nuggets of information that are not already published. Our job now is to make the subject easier to understand and help facilitate solutions to the problem. Unless the browser is secure, not much else is.
Prevention?
Put tape over your camera, disable your microphone, install NoScript, and/or disable your plugins. In the age of YouTube and Flash games, who’s really going to do the latter? For website owners their CSRF token-based defenses can be easily bypassed, unless they add JavaScript framebusting code to their pages, but the best practices are not yet fully vetted. Again, browser behavior is not at all consistent.
What a couple of a weeks this has been. Thank you to Adobe PSIRT for their diligence and hard work.
What’s Important, Palin’s Yahoo Mail Account Hacked
That’s right, Alaska Governor and republican Vice-presidential candidate Sarah Palin's quasi-personal Yahoo Mail (gov.palin@yahoo.com) account was hacked into by the infamous group called “Anonymous”. While there are conflicting news reports on the incident’s authenticity - emails, screen shots, and family photos have been posted to Wikileaks as proof. If we assume the incident is real, there are so many ways a free WebMail account could be compromised – some more likely than others:
1) Password guessing / brute force attacks
2) Password recovery system flaw or website vulnerability
3) Network sniffers
4) Phishing scams
5) Insider (rouge customer service representation or software backdoor)
6) Operating System Malware/Spyware
7) Stolen hardware
8) Lost backup tape (hah, as if free WebMail providers have backups!)
9) Use of a public computer
etc. maybe more I’m not thinking of.
For myself and the rest of the InfoSec industry the “how” is interesting, but its unimportant for everyday users like our friends, family, coworkers, politicians, etc. What they need to know is WebMail compromises could happen to anyone - even if they do everything “right” because security is largely out of their hands or impossible to behave perfectly all the time. Mistakes happen and the more high profile of a person you are the higher the likelihood you will be targeted.
Bottom line: DO NOT receive or store anything you don’t want read or made public on these “free” WebMail systems. They are NOT private. They are NOT secure. They are NOT safe. The same goes for Google Docs, social network private messages, online backup solutions, whatever. What they are is FREE and CONVEINIENT. The businesses that support them are not accountable for your privacy, security, or lack thereof. Read their EULA or ToS if you don’t want to take my word for it.
WASC Web Application Security Statistics 2007
For those hungry for more web application security vulnerability data, WASC has released its Web Application Security Statistics report for 2007. Under the leadership of Sergey Gordeychik and the broad participation by Booz Allen Hamilton, BT, Cenzic, dblogic.it, HP, Positive Technologies, Veracode, and WhiteHat Security – we’ve combined custom web application vulnerability data from roughly 32,000 websites totaling 70,000 vulnerabilities. Methodologies include white box and black box, automated and manual, all reported using the Web Security Threat Classification as a baseline. Excellent stuff.
Figure 1. Vulnerability frequency by types
Figure 2. The most prevalent vulnerabilities (BlackBox & WhiteBox)
Sergey did a masterful job coordinating all the vendors (whom we thank), compiling the data, and generating a report in a nicely readable format. I’d like to caution those who may read too deeply into the data and draw unfounded conclusions. It’s best to view reports such as these, where the true number and type of vulnerabilities is an unknown, as the best-case scenario. There are certainly inaccuracies, such as with CSRF, but at the very least this gives us something to go on. Future reports will certainly become more complete and representative of the whole as additional sources of vulnerability data come onboard.
Ultimate Scanner Accuracy Test
Imperva issued a press release and a pair of blog posts describing their new SecureSphere (WAF) API functionality (OpenSphere). Cool stuff. Clearly from the text they’re excited by the VA+WAF concept, which is the same technology integration path WhiteHat Security completed with F5’s ASM and Breach’s open source ModSecurity. We’ve been getting email asking when we plan to integrate Sentinel with Imperva (and we likely will) because we’re only VA scanning vendor not listed (Cenzic, HP, IBM, NTO) in their announcement, but I’ll get to that in a moment.
There is something else deep underneath that VA+WAF brings to the surface, something everyone finds important, and that is true scanner accuracy. For VA+WAF to work (block) in a production environment scanner results MUST be EXTREMELY accurate. We’re talking sub 1% false positive and duplicate rates or things will fail (badly). And even then you still want to test virtual patches in alert mode first. Scanners cannot fudge these results, use noncommittal “potential vulnerability” reporting, or use clever marketing spin. You got the good or you don’t and probably an interesting new way to review scanners.
For example Kavado (defunct) attempted the VA+WAF in 2002-2003; and other vendors tried again in 2003-2004 using AVDL. Ultimately, all VA+WAF attempts proved unsuccessful because the scanning products dumped hundreds or even thousands of false positives and duplicate vulnerabilities (still the case?) into the WAFs. Early implementations labored WAF performance or rendered the entire website inaccessible. We feel at WhiteHat Security we’ve overcome the accuracy challenge and statistically gathered enough proof points to feel comfortable bringing the solution to market.
As far as integration our plans go and why we’re not listed, WhiteHat Sentinel features are almost entirely customer demand driven and WAF integration is no different. Many enterprises are considering their options (Cisco, Citrix, WebDefend, etc.) and then let us know which product they liked best. Then we get the product in the lab, integrate the technology, test, test, test, and test again, then show it off to a several people. If feedback is positive, then we announce. Perhaps other scanning vendors do it differently and don’t mind marketing vapor-ware. We prefer offering solutions that work first and that might explain why we’re not on the list. :)
Once Sentinel pinpoints the location of a vulnerability (class, url, parameter), its verified by our operations team, and a dynamically generated ModSecurity rule becomes part of the web-based reporting (see screenshot). The custom rule is a blacklist meta-character match narrowly focused on the vulnerable URL, parameter value (multiple params are supported), and class of attack. A parameter known to be vulnerable to SQL Injection probably has no legitimate use-case for receiving quotes, semicolons, dashes, parens, etc. Similar can be said for XSS.
Sentinel users then copy/paste the custom rule into their Apache config. We recommend the rule be tested in “pass” mode ensuring no false positives exist that might block legitimate traffic. Once confidence in the rule is established, which may take an hour to a couple days, “deny” mode can then be used to block attacks. False positives are minimal because only identified attack traffic where a vulnerability of that type is specifically known to exist in that location is affected. Finally the re-test button can test the single issue and should everything work properly the vulnerability status would be automatically closed out.
Hopefully in the coming months I’ll get some good case studies going and statistics to measure how the time-to-fix windows are shrunken.
What You Need to Know About HTTP Verb Tampering
Recently Arshan Dabirsiaghi, Director of Research of Aspect Security, published a white paper entitled “Bypassing URL Authentication and Authorization with HTTP Verb Tampering”. Initially there was a lot of confusion about what exactly was being explained or claimed. Including, is it real? Is it novel? Is it dangerous? What is this? Most will get lost in the semantics of the debate and only care if it impacts them in some way. So I hope to get to the relevant bits, borrow from Arian Evan’s summaries, and make things a bit easier to understand.
1) No one is claiming the HTTP Verb (GET/POST/HEAD) manipulation is new. Manipulating what type of HTTP request a webapp is expecting to receive, such changing GET to POST and POST to GET, has been done for years. Our websites should only be using the types of requests we expect to receive and no more. What is interesting here is when it can be used and for what purpose.
2) HTTP Verb tampering is generally used in conjunction with syntactic (XSS, SQLi, etc.) and semantic (bypass authentication/authorization controls) attacks as way to bypass certain defense measures. Arshan’s work on implementation details focus on the semantic version.
3) In syntactic attacks you can use verb manipulation to get malicious data (‘ DROP TABLE …’) in a session object that might now have otherwise been allowed. i.e. Query string parameters were sanity checked, but the attacker used POST placing the data in the message body where it was overlooked by the application. This can lead to SQLi, XSS, and several other common technical vulnerabilities.
4) To protect yourself from syntactic HTTP verb manipulation attacks, make sure you only include user-supplied data from where it’s expected to be received (Query string or POST data), or sanity check them both the same if necessary. Also only include the parameter names in the session object you expect to receive. Don’t allow attackers to add arbitrary name/value pairs.
5) In semantic attacks verb manipulation can be used to bypass authorization/authentication protection for specific verbs and areas of the site. A config might say HTTP requests to the /admin/* directory using “GET” must have an “admin” session role. One would ASSUME any methods not listed (POST, HEAD, WHATEVER) in the config would automatically be placed in default-deny mode, but this is not necessarily the case. RFC’s say the HEAD verb is supposed to be treated exactly the same as GET, just don’t return any response data. So its possible for an attacker to send a request to /admin/delete_user.cgi?id=1 with a HEAD verb with no authentication/authorization. They just wouldn’t get a response to the action and certain frameworks are known to be vulnerable to similar attacks. Nasty stuff and commonly goes untested for.
6) There are several things one can do to protect themselves, the most direct is ensuring ALL HTTP verbs are placed in default-deny mode unless otherwise specified. What you are looking for in consistency of authentication/authorization controls across the various methods you expect to receive. Addition details are going to be implementation specific and can be found in the white paper or list chatter.
7) Scanning for syntactic issues is possible, but can easily double or triple the number of requests that need to be sent. Varying degrees of effectiveness are wide across the commercial vendor range. Scanning for semantic issues is going to be extremely hard and likely to be a manual process for quite some time. Its basically a business logic flaw even though the scanner can technically manipulate the verb, it just doesn’t know what the outcome of a test means.
Overall good paper, I learned some good stuff about the particulars of certain implementations. Plus it sparked a lot of good debate. Hope this helps clear some things up.
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 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!
It Pays to be a Hacker
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:
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.
Jeremiah Grossman is a world-renowned expert in Web security, co-founder of the Web Application Security Consortium, and recently named to InfoWorld's Top 25 CTOs for 2007. He has authored dozens of articles and white papers, is credited with the discovery of many cutting-edge attack and defensive techniques, and co-author of the recently published book, Cross-Site Scripting Attacks.Mr. Grossman is frequently quoted in business and technology publications such as InfoWorld, USA Today, PC World, Dark Reading, SC Magazine, SecurityFocus, CNET, CSO Magazine, and InformationWeek.
Figure 1. Vulnerability frequency by types
Figure 2. The most prevalent vulnerabilities (BlackBox & WhiteBox)
