Website Security Topics - Jeremiah Grossman Blog 2008
OpenSocial, Hacked in Under 45 MinutesFriday, November 9, 2007
Top blogger Michael Arrington posted about how a hacker was able to modify his personal Plaxo account profile as well as that of Plaxo’s VP Marketing John McCrea. The hacker, calling himself “theharmonyguy” and describes himself as “just an amateur”, appears to have spotted a handful of clever insufficient authorization issues which allowed him to perform horizontal privilege escalation on fellow users.
Fortunately what theharmonyguy did was only a harmless prank and sought only to bring attention to the flaw. It there’s people out there who are curious and looking for these types of issues. And if you read back to an earlier post, I directed people to a story in Insecure Magazine #13 called "Social engineering, social networking services: a LinkedIn example". According to the content, social network websites can be incredibly valuable targets for conducting personal reconnaissance and carrying out identity theft.
It’s also interesting to watch how people who ar not part of web application security world react. Michael Arrington in titling his post, “First OpenSocial Application Hacked Within 45 Minutes”, used outcome-based metrics to describe the incident without even knowing it. In the past I’ve referred to it as hackability and this is a perfect example of how I think website security and security solutions should be measured. The approach is simple, natural, and makes a lot of sense to everyone.
QVC Business Logic Flaw Nets Scammer $412,000Friday, November 2, 2007
$412,000 is what a business logic flaw in QVC’s website allowed North Carolina woman, Quantina Moore-Perry, to scam them out of. The scam was brain dead simple. 1) Place an order 2) Quickly cancel the order 3) Wait for the products to arrive in the mail anyway 4) Sell off the goods on eBay. 5) Profit. I guess the cancellation system needs a bit more attention.
My guess is Moore-Perry, who has since plead guilty to wire fraud, was no “hacker” and found the issue by mistake. She probably legitimately ordered something at first, then for whatever reason canceled it, and the products arrived in the mail anyway. Instead of calling customer support she probably saw an opportunity to make a little cash.
According to The Register article, QVC only learned of the incident when an eBay buyer tipped them off. They became suspicious because the QVC packaging wasn’t removed. Lazy crooks. The also incident begs the question, how many QVC customers (if any) have found the same issue and have just gone unnoticed? Out come the auditors. I’m sure this issue isn’t unique among eRetailers.
As I’ve been articulating over the last couple of months, business logic flaws like these can be incredibly damaging, are painfully common, and very difficult to identify. Obviously vulnerability scanners are not going to find these (unless they can check the mail too), IDS won’t spot them, and WAFs won’t block them. Basically this is because every part of the attack contains completely valid HTTP requests and responses. No crazy looking meta-characters like in XSS or SQLi and even the flow of the requests is natural.
At the same time, these types of issue can also be difficult for even a pen-tester to spot unless they know what to look for. Normally a pen-testers scope of work stops short of “ordering” something on the website. That’s also why I’ve been asking for and documenting as many of these real world examples as possible because it helps raise awareness. The more we have to go on the better everyone’s system design and vulnerability assessment processes will become.
Why Crawling MattersThursday, November 1, 2007
The first thing you do when pen-testing a …
… network: ping sweep
… host: port scan
… website: crawl
Each process begins by gathering intelligence and mapping out the attack surface as best as possible. Without a well-understood attack surface generating results from a scan/pen-test/assessment or whatever is extremely difficult. I bring this up because there’s been a lot of interesting discussion lately about evaluating web application vulnerability scanners though measuring code coverage and crawling capabilities. At WhiteHat Security we’ve spent years R&D’ing our particular crawling technology and have plenty of insights to share about the challenges in this particular area.
Crawl and code coverage capabilities are important metrics because automating as much of a website vulnerability assessment process as possible is a really good thing. Automation saves time and money and both are in short supply. The better a website crawl (even if manually assisted), the more thorough the vulnerability assessment. If you’ve ever experienced a scanner spinning out of control and not completing for hours or days (perpetually sitting at 5%), or the opposite when a report comes up clean 2 minutes later after clicking scan, there’s a good chance it’s the result of a bad crawl. The crawler of any good web application scanner has to be able to reach every nook and cranny of a website to map the attack surface, isolate the injection points, or run the risk of false negatives.
Whatever you do don’t assume crawling websites is simple and scanners are just mimicking old school search engine (Google, Yahoo, and MSN) technology. While much is similar, consider everything those guys do is pre-login and that’s just the start of where things become difficult. Many issues exist that routinely trip up crawling like login, maintaining login state, JavaScript links, malformed HTML, invalid HTTP messages, 200 OK’ing everything, CAPTCHA’s, Ajax, RIAs, Forms, non-standard URLs, and the list goes on. Search engines don’t really have to worry about this stuff and if they happen to miss portions of content they probably don’t care a whole lot anyway. For example they wouldn’t be interested in indexing a bank website beyond the login form.
While WhiteHat’s technology has become really good at JavaScript (Ajax) support and overcoming most of the challenges described, no one in the industry is able to guarantee that all links have been found or application logic flows exercised. Password resets or account activation are often not linked to from the website itself, instead they’re only visible in email. This means human assistance is often required to complete attack surface mapping. What we do with WhiteHat Sentinel is make available the crawl data to our customers for sanity checking. So if for some reason we’ve missed a link they can notify us and we’ll add it directly. Then we investigate why the link was missed and if necessary make a code update. Most often its because the accounts we were provided did not give us access to a certain section of the website and we had no idea it existed.
Then there is the matter of scale as some websites contain millions of links, some even growing and decaying faster than anything can keep up with. Without a database to hold the crawl data, scanners tend to slow or die at about 100,000 links due to memory exhaustion. However to use Amazon as an example, you don’t need to visit every book in the index in order to map all the functionality. But, a scanner has to be intelligent enough to know when it’s getting no more value from a particular branch and move on. Otherwise scans will go on forever when they don’t need to. Ever wonder why there are so many configuration settings for the commercial scanner products around crawling and forced browsing? Now you know. Like I said in an earlier post, each scanning feature should be an indication of the inability to overcome a technology obstacle and it needs human assistance.
Moving forward the one thing we’re going to have a keep an eye on is scanner performance over time. The effectiveness of scanners could actually diminish rather than improve as a result of developer adoption of Web 2.0ish technologies (Flash, JavaScript (Ajax), Java, Silverlight, etc.). Websites built with this technology have way more in common with a software application than an easy parse document. While its possible to get some degree of crawl support with Ajax and the rest its not going to come anywhere close to supporting a well known data format like HTML. As a result, attack surface mapping capabilities could in fact decline and by extension the results. Lots of innovation will be required in many areas to overcome this problem or simply keep up with the status quo.
SasS – An Idea Whose Time has ComeFriday, October 19, 2007
Software as a Service (SaaS) for Website Vulnerability Assessment (VA) – all the cool kids are doing it. WhiteHat Security has been the pioneer of the model for the last several years, but only very recently did industry activity demonstrate validation of the market. Huge companies are jumping in, making their moves with acquisitions, and retrofitting technology towards SaaS. Customer demand is growing extremely fast as they grow to understand webappsec’s importance. I’m hoping everyone is noticing the same great uptick in webappsec VA that we are. Anyway, all of this makes a sense because many information segments followed similar evolutionary paths:
1) Technology starts off as someone’s pet project
2) Several variations work their way into first generation tools
3) They mature into enterprise product offerings
4) SaaS manifests as manageability, scalability, and economics become issues
This evolution occurred with the IDS, firewall, A/V, and network vulnerability assessment (VA) industries. Think of the parallels in network VA with SATAN, Nessus, eEye, ISS, Qualys, and everything in between. Today we’re witnessing it happening with website VA. The late 90’s and early 00’s saw the rise of scanners, proxies, and various tools like Whisker, Nikto, Elza, Achilles, and many others. Then Watchfire, SPI Dynamics, Cenzic, Acunetix, and NTOBJECTives raised the bar with commercial products. Of course it was only a matter of time before enterprises demanded better manageability, scalability, and economic options as the tools weren’t getting the job done. Enter SaaS.
WhiteHat Security recognized this need and decided early on to go the SaaS-only route. There are millions of websites out there that need continuous VA and simply not enough web security experts to go around. This required us to build a technology platform capable of scanning the world’s largest websites (1MM+ links), lots of them all at the same time (thousands, tens of thousands, etc.), plus develop an efficient process to suppress false-positives, and most importantly leverage the technology to create a streamlined expert-driven methodology to complete comprehensive assessments. Clearly this is no small task and one that takes serious development time and expertise to achieve. So let’s get to the bottom of who’s got what and what they’re doing.
Network VA SaaS pioneer, Qualys, plans to offer web application scanning in Q1 of 08’ and hired a couple of bright people to build the technology. This places Qualys in a similar position to ScanAlert (HackerSafe) which also does SaaS network VA and at least some web application scanning. Then also IBM and HP completed acquisitions of Watchfire and SPI Dynamics respectively. Attacking from both sides, published reports and insiders say that both behemoths are setting their sights on website VA SaaS, while at the same time AppScan/WebInspect R&D will push the products towards developers and QA testers. Finally, Core Impact is adding web application penetration testing to their product as well.
All this points to market momentum and healthy competition, great for the consumer and practitioner. It’s all about capabilities though.
For those who don’t already know, scanning a network for vulnerabilities has very little to do technologically with websites or web application VA. This is a big reason why no one has successfully combined multiple VA solutions. Qualys has a nice infrastructure capable of scanning really big networks. However, they must start from scratch to build the technology capable of scanning websites for vulnerabilities. Plus, they enter an arena where others are entrenched with a several year technology head start. They’ll have some proving themselves to do. The same reasoning applies to Scan Alert and both companies are big players in the PCI ASV market.
IBM and HP have the opposite problem. They have the vulnerability scanning capability from the product acquisitions, but must build out big web application scanning and assessment infrastructures to go with it. Converting desktop products into a SaaS platform, which must be a little to like turning MS Outlook/Exchange into Gmail, takes time. Neither Qualys, IBM, nor HP possess the ability to scale the people and process portion to complete an assessment. That’ll mean huge false-positives and limited coverage for customers, at least initially. For IBM and HP at least, they’ll be able to compensate using a consultant behind the curtain with a scanner and call it SaaS. This will have to work long enough for them to nail a process down, just like all the scanner product guys have been doing for the last year or two.
Like I said, WhiteHat Security started early and built the three-piece trifecta: web application vulnerability technology, large scanning infrastructure, and an efficient expert-driven assessment process. What’s new is the mega corps surrounding us on all sides competing for the same dollars, but I really look forward the challenge as its good for the market. And on the industry outskirts are still other big names like Symantec, McAfee, VeriSign, PWC, etc. who have teams of webappsec VA consultants, but lay dormant on SaaS side. One thing I’ve learned over the years is that superior solutions don’t always ensure market share victory - these competitors could win deals based on name recognition alone. The next 12 to 18 months are going to be a lot of fun and highly interesting.
Malware as a Service Friday, October 12, 2007
Most of the time us Web App Sec people are a world’s apart from the traditional A/V and malware industry involved in reverse engineering rootkits, creating signatures, taking down botnets, tracking fraud, etc. We read the headline snippets sure, but don’t really have the time to keep up with what’s happening at ground level. So when Scott Berinato of CIO.com passed along his latest and VERY in depth thee-part article documenting the "Evolution Malware Industry through Infiltrating Fraud Rings", I was definitely interested. The text is definitely illuminating as it talks about groups such as the Russian Business Network, ShadowCrew, HangUp Team, 76service and others and how they’re turning the industry into “Malware as a Service” (MaaS). Web 2.0 models are for everyone I guess. I even saw that Hoff got into the action, saying something about how we was thirsty. :)
I pulled out some quotes I thought were particularly thought provoking.
"Jackson found a full-fledged e-commerce operation. It was slick and accessible, with comprehensive product offerings and a strong customer focus. Jackson, no one really, had ever seen anything like it. So business-like. So fully conceived. So professional.”
“Gozi represents the shift taking place in Internet crime, from software-based attacks to a service-based economy.”
“Electronic crime has evolved, from an episodic problem, like bank robberies carried out by small gangs, to a chronic one, like drug trafficking run by syndicates.”
“When Jackson logged in, the genius of 76service became immediately clear. 76service customers weren’t weren’t paying for already-stolen credentials. Instead, 76service sold subscriptions or “projects” to Gozi-infected machines.”
“Some of those account holders managed to make several cash transfers up to $49,000. “They’re playing with limits on fraud,” says Jackson. That is, they know the banks won’t flag 5 transfers under 50 grand, but will flag one $250,000 transfer.”
“There are two key tenets underscoring that success: Distributed pain with concentrated gain, and distributed risk.”
“The Internet criminals’ model perfectly mirrors the drug cartel model, which relies on a stratified market that spreads the risk out to pushers, distributors, mules, manufacturers, and all the money flows up, to the cartel.”
“Business is good. Internet criminals operate with de facto immunity. The pool of vulnerable computers to exploit remains massive. The target financial institutions still treat their crime as acceptable loss. Law enforcement is otherwise occupied. And technical defenses are mere market conditions to adapt to.”
The Big Picture
Friday, August 31, 2007
At SANS Ryan Barnett (Breach Security) and I talked a lot about the various suggested Website security “best practices” such as SDLC, black box testing, source code reviews, WAFs, scanners, etc - weighing their pros, cons, and costs. In the course of the conversation Ryan commented that I tend to look at the landscape from a scalability perspective. I hadn’t noticed this before, but he’s absolutely right. I try to look at strategies and solutions with an eye for the big picture with consideration for how many people/companies/websites the best-practices may benefit or not. If “best practice X” were rolled out on 1,000 or 10,000 or 100,000 websites…
- What problem(s) does it solve and cause?
- How much time and effort would be required for implementation?
- Are there enough skilled people available?
- What will it cost and who would be willing pay?
- How much more secure will it make a website?
Etc.
These data points help develop insights into the where the industry is headed, the challenges we’ll face, and where innovation is most helpful. Plus I find it fun. To illustrate what I mean, below are some speculative high-level numbers I’ve collected which are used calculate “best practice” costs. Hopefully my math is accurate.
Important Websites: 60,000
According to Netcraft there are roughly 128 million websites. Of course not all of these are “important” (containing sensitive data, brand sensitive, etc). Netcraft also says there are over 600 thousand SSL websites, which is another useful metric, since why buy a certificate if it isn’t at least somewhat important. There could still be important websites not using SSL and neither accounts for intranet or access restricted websites. But because the number is still so large, I decided to stay conservation and take only 10% of the SSL total and use that moving forward. Figuring out how to properly secure the top 60,000 websites would really be something.
Vulnerability Assessments
The standard one-time black box vulnerability assessment (with or without the aid of tools) conducted on a single website performed by a qualified Web security pen-tester.
Required man-hours per assessment: 40 hours
Bill rate: $250 (per hour)
Cost per website: $10,000 (40 * $250)
Max number of assessments per year per person: 40
* Estimates are based on the data collected from the Web Application Security Professionals Survey and sanity checked through other sources.
To perform a vulnerability assessment on 60,000 websites each year requires:
Total man-hours: 2,400,000
Qualified pen-testers: 1,500 (websites / 40)
Total cost: $600,000,000 (websites * $10,000)
*These numbers do not take into consideration that many website change rapidly and may require multiple assessment per year.
Source Code Reviews
The standard one-time source code review (with or without the aid of tools) conducted on a single website and performed by a qualified software security expert.
Required man-hours per source code review: 80 hours
Bill rate: $250 (per hour)
Cost per website: $20,000 (80 * $250)
Max number of Source code reviews per year per person: 20
*Estimates are based on data contained within the techtarget article entitled, “Inside Application Assessments: Pen Testing vs. Code Review”, and sanity checked through other sources.
To perform a source code review on all 60,000 websites each year requires:
Total man-hours: 4,800,000
Qualified source code reviewers: 3,000 (websites / 10)
Total cost: $1,200,000,000 (websites * $20,000)
*These numbers do not take into consideration that many website change rapidly and may require multiple source code reviews per year.
Web Application Developers: 300,000
It’s difficult finding a reference for the number of Web developers worldwide, so I figured I’d try JavaScript instead since most if not all of them know the language. According to a “JavaScript: The Definitive Guide Advertisement”, there “300,000 JavaScript programmers” took advantage of the book. There are probably more Web developers out there who don’t know JavaScript, but let’s try to stay conservative. Imagine all the Web application code their churning out daily, let alone annually.
Secure Programming Training (2-day course)
* Based relative to SANS pricing information
Per Person: $2,000
Qualified trainers: 375
* Assuming 1 trainer is capable of conducting 20 classes per year with 40 students in each class.
To train all web application developers once per year:
Total cost: $600,000,000 (300,000 * $2,000)
*Does not account for any travel costs
From these numbers many takeaways can be derived, but here’s one that stood out to me:
Clearly more code is being churned out than our ability to assess it. Which means vulnerabilities will be pushed no matter what because the business is not going to wait around for security’s backlog. And if the bad guys just need to find one vulnerability, then we’re going to lose the battle. In fact the only things holding things together is there isn’t a critical mass of bad guys with the skill set to full exploit the opportunity. However, this will only last a short while and the smart money says attacks will continue to increase.
Why aren’t more Website Hacked?Friday, August 17, 2007
I’ve given many presentations about website security statistics, most recently at SANS, stating somewhere between 70% and 90% have serious vulnerabilities. I dig into severity breakdowns, top ten lists, vertical industry comparisons, and more. After bearing witness to the data at hand, what the “bad guys” could do (or already have done), attendees emerge from the Denial stage of Web security grief and enter Anger. Others remain skeptical, completely understandable, and curious about something particularly relevant. They ask, “If these statistics are accurate and the Web so insecure, why aren’t websites hacked more often”? This is a darn good question!
Indeed....
Why aren’t the bad guys pillaging everything in sight?
First off, websites ARE getting hacked. A LOT! The Zone-H defacement archive clearly illustrates the size of the problem. Secondly, the public isn’t always made aware of every website hack and media doesn’t advertise every incident. Many profit-driven website hacks will never be made public because both the bad guy and victim keep the incident confidential. The various state disclosure laws only apply to customer personal and private data, not with incidents that compromise source code, trade secrets, brokerage account access, etc. The point is we only know the best-case scenario out there based upon the published information.
However, these explanations aren’t satisfying, probably because we can’t measure it. Perhaps there is another possibility. Consider that Netcraft says there are roughly 128 million websites and about 2 million more are added per month. Those in the industry know the challenge of finding, hiring, training, and retaining web security people. Could it be there simply isn’t enough bad guys with the necessary skills and motivation to monetize web hacks? Could there be more than 2,000 of such morally flexible people? I have no idea if this number is accurate or not, but it seemed reasonable. This could explain why Web banks aren’t yet getting compromised hourly or and why isn’t MySpace or Facebook suffering Web Worms daily.
Something to consider anyway.
How to Make a Website Harder to HackFriday, August 17, 2007
I mean, that’s what web application security is all about. We know websites will never be 100% secure just like software never be 100% bug free. We also know web application hacks are targeted. All we have to do is look at CardSystems, the U.N., MySpace, CNBC, UC Davis, Microsoft UK, Google, Dolphin Stadium, Circuit City, T-Mobile, and many other incidents to figure that out. Bad guys don’t hammer away at eComSiteA then mistakenly hack into WebBankB. It doesn’t work like that. The victim is the one they’re targeting in the browser URL bar. So instead we should approach website security in terms of time and difficulty just like they’ve done for decades in physical security--with burglary resistance, fire resistance, alarm systems, etc.
For example GSA approved and U.L. certified products such as a:
Class 5 vault door - “shall be resistant to 20 man-hours surreptitious entry, 30 man-minutes covert entry and 10 man-minutes forced entry.“
Class 150-4 hours container - “must maintain an interior temperature less than 150°F and an interior relative humidity less than 85% when exposed to fire as per the Standard Time Temperature Curve for 4 hours to 2000°F.”
These benchmarks make sense. The problem in web application security is everyone so blindly and exclusively talks about “best practices” like the SDLC, input validation, threat modeling, PCI compliance, source code reviews, scanners, developer education, WAFs, and other topics. They forget about the big picture. Do these “solutions”, or combination thereof, actually make a website harder to hack? Yes! Well, probably. Err, maybe. And if so, how much harder? If the answer is unknown then how do we justify their cost in time and money? Oh right, “compliance." Still, imagine telling the CIO you just spent the last 6 months, countless company man-hours, and hundreds of thousands of dollars implementing “best practices” only to raise the bar by maybe 30 minutes!?
Judging from WhiteHat Security’s vulnerability assessment statistics on hundreds of websites, this is exactly what’s happening. Vendors basically attempt to dazzle customers with the most blinky-red-lights, buzzword compliant banter, confusing diagrams, meaningless ROI calculations, and reams of FUD to distract people from their main objective. MAKE A WEBSITE HARDER TO HACK. Do yourself a favor the next time a vendor is hawking is their wares at you, ask them this simple question, “How much harder does your solution make my website to hack?” The answer might surprise you, if there is one.
Rather than continue ranting, I think its time the web application security industry began using this type of testing methodology so we may answer these questions in no uncertain terms. To do so we’d have to take into consideration the skill of the bad guys, the tools and techniques at their disposal, whether they would be internal or external, change rate of the website, and . . . anything else? The methodology probably wouldn’t need to be overly complicated. In fact, we might borrow ideas from physical security on how they set-up their testing processes. Imagine obtaining a measurable degree of security assurance.
How to Check if Your WebMail Account has been Hacked (Redux)
Friday, July 27, 2007 Erik Larkin from PC World posted a great tutorial on how to “Set a Hacker Alarm on Your Web Mail Box” in 5 easy steps. This is based upon a trick I blogged a while back. We improved upon the original concept by using a free hit counter, OneStatFree.com, instead of having to host a web server yourself, which many are not able to do. Also by including the “alarm” code as an HTML attachment, the trick will work even if your Web Mail account is set to “block all images” to prevent spam. This is trick is useful not only catch a hacker breaking into your Web Mail account, but perhaps rouge customer service representatives or someone with physical access to your machine. Have fun!
Attribute-Based Cross-Site Scripting
Monday, July 23, 2007
A couple of weeks ago I posted sections from one of our WhiteHat customer newsletters that focused HTTP Response Splitting. Newsletters are one way we keep customers informed of important industry trends and improvements to the Sentinel Service. Judging from the blog traffic and comments it was well received. So this time I’ll highlight Attribute-Based Cross-Site Scripting, which Arian Evans (WhiteHat’s Director of Operations) has been spending a lot of R&D time to get working properly. Enjoy.
New Vulnerability DetectionJuly 2007
Attribute-Based Cross-Site Scripting is one of the hardest types of Cross-Site Scripting to find in an automated fashion. Today, no desktop scanner does a good job at this; most don't even attempt it because false-positives skyrocket – except for the WhiteHat Sentinel Service. Naturally.
WhiteHat Sentinel implemented our second-generation attribute injections last week. Many of you have seen new XSS attack vectors being pushed on your sites, and for quite a few it is a result of these tests. The example we most often push is sourcing in JavaScript via an injected STYLE tag (attack vector for Internet Explorer).
Attribute injection is when user-controlled data lands inside of an HTML tag, or specifically a value inside of an HTML tag, where notorious characters like “<” and “>” may not be required for XSS exploitation. For example:
HTTP GET request (not actual Sentinel test - this is an example for exploitation):
http://www.domain.site/search/partner/index.cfm?sessionid=12345678901
&hid=%22+STYLE%3D%22background-image%3A+expression%28alert
%28%27Is_XSS_HERE%3F%29%29
Will result in this example tag in the HTTP Response:
<* td>
<* a href="/index.cfm?sessionid=12345678901&hid="" STYLE="background-image: expression(alert('Is_XSS_HERE?))">
<* img src="http://www.domain.site/images/topnav/logo.gif" width="274" height="83" border="0">
<* /a>
<* /td>
This is a perfect example of an XSS vulnerability in which the attacker wouldn't need HTML tags or meta characters like <>. All you need in this case is a double-quote, a colon, and some parenthetics to begin your attack. From here the exploit can be carried out in many ways (e.g.-malicious Javascript). The ability to detect these issues accurately will grow exponentially with the advanced conditional logic currently being implemented into the Sentinel Service.
WhiteHat Website Vulnerability Management Practice Tips
Q. How do I stop an XSS attack that lands in an HTML tag?
A. For most attribute-based attacks to work, the attacker needs at least single or double-quotes. Double-quotes are what is most often needed – from what we see at WhiteHat. You could try escaping, removing, or substituting single and double-quotes on input.
Alternately you could encode any user-supplied data safely on output. This is the safest approach. Barring international-language sites – there are a minimum of four alternate encoding types for all Latin-ASCII code page characters: being Unicode, Decimal, Hexadecimal, and Named. This can jump to 18 variants for something as simple as double-quote, if you factor in international-language code pages.
Q. How do I encode my output safely?
A. If you encode double-quotes as their named-entity references, you will remove most of your attribute XSS issues. If you encode single-quotes using Decimal (works across the most browsers) or named-entity reference, this should solve the problem, as well (by breaking the initial escape sequence the attacker needs to take over the tag and begin scripting).
A nice reference page for more on entity-encoding values can be found here:
http://www.crosswinds-cadre.net/?page=character_entities
Q. What is this Unicode craziness you speak of?
A. A great place to start is here:
http://www.joelonsoftware.com/articles/Unicode.html
Time to learn DNS-PinningTuesday, July 10, 2007
Per the typical web security M.O, attack techniques we’ve known and ignored for years have a way of coming back around as new ways of using them are discovered. It happened with XSS, recently with CSRF, and now new life is being breathed in Ant-DNS Pinning. Anti-DNS Pinning is a very important issue, especially as it related to intranet hacking, but its HIGHLY complicated and few people understand the nuances. In fact only a few months ago is the first time I’d seen the term mentioned in the mainstream media.
Fortunately learning about Ant-DNS pinning is getting easier as Christian Matthies and PortSwigger both posted freshly minted and extremely well-written white papers. The benefit of Christian’s is that he’s got a bit more data on anti-anti- and anti-anti-anti DNS Pinning, while PortSwigger’s explores web proxy implications which I had not seen anywhere else.
Also, if you are attending Black Hat USA 2007, make sure to catch David Byrne's Intranet Invasion With Anti-DNS Pinning.
7 Deadly Sins of Website Vulnerability Disclosure Thursday, July 5, 2007
Someone you don’t know, never met, and didn’t give permission to informs you of a vulnerability in your website. What should you do? Or often just as important, what should you NOT do? Having security issues pointed out, “for free,” happens to everyone eventually (some more than others). People unfamiliar with the process often make poor judgment calls causing themselves more harm than good. We witness these missteps regularly, even amongst security vendors who should know better. I figured that if we document some of these mistakes, maybe we’d start learning from them. Then again, the original seven deadly sins certainly haven’t vanished. :)
Note: The content below should not be considered a substitute for an incident response plan.
Pride :: It’s been said many times, all software has bugs. And as long as software has bugs it will contain vulnerabilities. It’s time we faced this fact. If you receive an email from a stranger declaring the discovery of a Cross-Site Scripting, SQL Injection, Cross-Site Request Forgery, Response Splitting, Content Spoofing, Information Disclosure, Predictable Resource Location, or some other esoterically named vulnerability in your website, there’s no need to get defensive. Even if you’ve never heard of or don't understand the type of attack, it doesn’t mean you’re dumb or your baby/code is ugly. It also doesn’t mean that it’s not a real issue with serious consequences undeserving of attention. Investigate each disclosure thoroughly, communicate openly, and fix issues promptly.
Wrath :: Depending on the nature of the disclosure, some are tempted to fight back against the person disclosing a vulnerability by informing law enforcement and/or their attorney. While it’s not a bad idea to seek their counsel, only in cases of fraud, extortion, or other malice is taking the next step typically warranted. Investigations are difficult to open unless the financial or data loss is substantial. And, nasty legal threats only lend credence to the fact that something major has taken place. Criminal and civil actions have been known to backfire when the news breaks. Negative PR due to a “security issue” is not something any business owner desires, especially headline news about an issue that could have been quietly resolved with little to no media attention.
Desertion :: A fresh security event is no time to start polishing the resume for Monster, CareerBuilder, or Craigslist. This is when your presence is critical and where you can end up learning the most. A vulnerability disclosure is not the end of the world (instead painfully common). Then again maybe a “free” vulnerability assessment reveals you’ve been severely negligent in your duties. It’s much more advantageous to take advantage of an outside vulnerability disclosure because it clearly demonstrates what might have happened “IF” exploited by someone with malicious intent. This should provide management with the motivation to prioritize initiatives previously suggested by the security team.
Blame :: Your website, your responsibility. That’s how customers see it and that’s how any respectable business owner should treat the security of their website. No one appreciates when people point the finger at others or saying it was only *cough* honeypot when an event takes place. These excuses are transparent, unbecoming and do nothing to build or rebuild customer confidence. When an organization acknowledges an issue (publicly or privately) and resolves the matter quickly, it says a lot about that their integrity. Try not to shoot he messenger. Despite how you might feel at the time, when someone privately discloses a vulnerability in your website, in their mind they’re doing you a favor. Next time you might not get the chance to handle the incident proactively.
Arrogance :: Dismissing or reprioritizing a vulnerability disclosure because a website uses SSL, is PCI compliant, or sports a HackerSafe logo is absurd. Compliance != Security. These credentials will not ward off the bad guys or prevent an incident from occurring. In fact, it might attract new attackers because it represents an interesting challenge. Compliance standards are typically a minimum baseline, and the skill of the average hacker (good, bad, or gray) easily outpaces the required security measures. Mandating security throughout the SDLC does not result in perfect code. Protecting a website is very difficult as you have to defend against all issues all the time. Someone on the outside only needs to find ONE issue to place the odds in their favor.
Sloth :: Ignoring or flat-out denying that a vulnerability exists will not cause a disclosure to go away. In fact, it is more likely that the discloser will become annoyed and post the issue publicly, thereby alerting the media, a competitor, and perhaps a bad guy or two. The guys on sla.ckers.org have no problem full disclosing a website vulnerability and making you the subject of ridicule. Make sure that when you fix a disclosed issue, you take the time to hunt for others just like it, because where there is one there is likely another. It’s embarrassing to have someone point out a flaw and have the same issue pop up again and again.
Uncommunicative :: When a "disclosee" fails to communicate adequately with the discloser, the media, or customers - one thing people do very well is assume the worst. The disclosure may believe they are being ignored and proper action is not taking place, which forces them to consider full-disclosure. A reporter receiving zero responses to press inquiries might assume they’ve uncovered the next TJX and raise a large FUD flag over the company/website. Should customers catch wind of the matter and not feel properly informed, panic and revolt could easily cross their mind. Striking the right balance between open communication and discretion is difficult, but also crucial.
6 Reasons Why Reviewing Development Code is Not the Same
as Assessing Production WebsitesMonday, June 25, 2007
Finding and fixing vulnerabilities during development, prior to production release, helps lower software development costs and decreases website security risk. Obviously vulnerabilities in development will make their way to production, but what many people miss is that not all vulnerabilities in production once existed in development. At first this might seem counter intuitive, but it happens all the time.
Frequently WhiteHat customers deploy our Sentinel Service earlier in the SDLC (via Satellite Appliance), right around QA time. I mention this because WhiteHat presently runs continuous assessments on a significant number of staging systems, side-by-side with the production “mirrors”. What’s interesting is that the vulnerabilities reported are rarely identical! This comes as quite a shock to many of our customers. Turns out there are a variety of reasons for differences between development/staging and production systems and here are just a few:
1) Code is enabled/disabled prior to release
Before staging code is released to production the push process says to disable debug == 1, admin == true, test credit card numbers, verbose error messages, test/QA accounts, etc. Then enabled extra security add-ons, transaction logging, performance enhancements, etc. This means production will never be a perfect mirror of staging and should any one step be overlooked, vulnerabilities could be introduced.
2) Lack of system configuration and patch level consistency
Even with centralized configuration and patch management, it’s extremely difficult to keep staging and production machines in perfect sync on rapidly changing websites. Non-standard-build web servers are quickly put into rotation, ASP.Net Request Validators are disabled on-the-fly because users need to upload active content, and not to mention random system failures.
3) Last minute feature requests demands
Management says a new feature needs to be pushed NOW! “Security be damned, the company will lose money if it isn’t released. Make the change on production and deal with any security issues later.” Developers rush out new, buggy, and insecure code.
4) Emergency vulnerability hot fixes
Security says a high-severity-easy-to-exploit vulnerability is discovered on the production website. “Developers need to implement a hot fix ASAP because its too risky waiting for the normal dev/QA process.” Developer pushes the fix, but forgets to back port the code. The next scheduled released overwrites the earlier security hot fix.
5) Backup and log files hidden in a public available location
System administrators are trained to make backups of files (*.bak) before they’re overwritten in case something goes wrong. If backup files remain next to the original indefinitely it may never become a problem. However, if the files are located in a Web directory it can be. "login.cgi” becomes “login.cgi.bak” and the source code would be made publicly available by simply requesting “/cgi-bin/login.cgi.bak”.
6) Infrastructure devices
When it comes to infrastructure devices such as proxies, load balancers, firewalls, network storage, databases, and web application firewalls - staging systems are rarely a perfect mirror of production. Often the reason for the difference is cost. These devices have the ability to impact a websites security posture either positively or negatively.
Try as we might, successfully maintaining identical staging and production systems is difficult (often impossible) to say the least. Sometimes the issues described above are under developer control, but certainly not always. "Push managers", system administrators, and security personnel at the direction of the "powers that be" all play a role in maintaining the website and everyone makes mistakes. This illustrates why measuring the security of the actual production website is so important.
Moving Forward: CSI Working Group on Web Security Research LawWednesday, June 13, 2007
The CSI Working Group on Web Security Research Law (web security researchers, computer crime law experts, and law enforcement officials) was formed in effort to advance our collective understanding of website security vulnerability discovery and disclosure. The inaugural report explores all aspects of the debate, complete with case studies, and provides a solid resource from bringing the industry up to speed. As part of the working group and having time contemplating what I’ve learned, the big question on my mind is "where to go from here?"
If our goal is to…
1) Protect the security researcher
If a software vendor or website owner is knowingly or unknowingly putting consumers (or their data) at risk, security researchers make it known. A security researchers act of vulnerability discovery/disclosure, which may cross ethical and legal lines, in a sense serves as an industry watchdog. While many argue over specifics, few say vulnerability security researchers do not overall help the greater good. If we wish to continue having security researchers play a role as more software becomes web-based we’ll need:
a) Clear guidance as to what actions are legal or illegal when looking for and disclosing website vulnerabilities.
Today’s climate of legal liability and criminal prosecution has already caused many experienced researchers to curtail website vulnerability discovery and disclosure (at least in the U.S.). Without guidance, those who will suffer the most unfortunately will be the new comers to the information security field who don't know any better. Careers or in some cases lives will seriously impacted before they’ve even begun. For the rest of the people looking for vulnerabilities on websites, the bad guys, it’s a free for all for them one way or the other.
b) Whistleblower protection
Even the most well intended laws sometimes prevent people from serving the great good. We’ve seen this happen in other areas and it’s reaching to the point where this may be required in the information security field as well. Especially with more and more of our most sensitive information under the protection of others. People in a position to know should be able to come forward with at least some expectation of legal protection. Right now there is none.
2) Motivate organizations to better secure their websites
By some estimates over 1 billion people are online with access to over 122 million websites (growing by nearly 4 million per month). The vast majority of these websites that are assessed for security have serious vulnerabilities. So its as no surprise that the most commonly attacked spot is the Web layer because it represents the path of least resistance. With so much commerce being conducted on the Web, it should be in the best interest of website owners to protect the security and privacy of the consumer. Question we all ask is how to do help that.
a) Industry’s self-regulation - the carrot
Industry’s may self-regulate and reward website owners with perks for maintaining a high level of security for consumers. With PCI we’re beginning to see this tend. While the results will not be immediate, over time they will be measurable. For industries who fail to self-regulate on-line security, they’ll continue to suffer massive incidents. If the problem gets bad enough, the risk is of government imposes regulations becomes a reality as has already happened in many other industries.
b) Legal liability - the stick
The government may also to decide consumers deserve to be compensated for breaches of their personal information. For myself I find this route preferable to legislated compliance standards for security. Let the organizations involved properly balance their need for security with the potential of legal liability.
However, maybe within the next 3-5 years as more incidents like TJX occur, we’ll have both remedies.
$1,000,000 CNBC Stock Trading Contest Hacked Monday, June 11, 2007
Described as the American Idol of stockpicking, CNBC's Million Dollar Portfolio Challenge (closed), is a chance for amateur traders to match their skills against the portfolios of the internet's best. 375,000 contestants compete in ten one-week challenges for a $10,000 prize and a spot in the final round to go for the cool million. To win all you have to do is make the most money. However, reports are surfacing that several of the finalists (with unbelievably good returns) may have gamed the system. According to BusinessWeek and SecurityFocus picking a sure winner required exploiting a surprisingly simple web application business logic flaw:
“A trader could go to the CNBC Web site and select a number of stocks to buy, but hold off on executing those trades. If you made the selection before the close of regular trading at 4 p.m. EST and left your Web browser open, you could execute those trades after hours and still receive the 4 p.m. closing price. For example, if a company whose stock closed at $20 a share rose to $25 in after-hours trading, you could buy the stock at $20, even though it was already worth 25% more.”
You can almost hear an army of web hackers smacking themselves for missing the opportunity to play – or maybe they didn't? :) Obviously this issue something you can’t scan, heck most humans misses it. And talk about difficult to detect. Certainly not the common IDS noise from XSS or SQL Injection. In the end it was seemingly just a bunch of every day stock people who spotted the abnormality. CNBC, with a reputation to protect announced that it had opened an investigation. With that amount of money on the line, they’d better.
This situation raises several interesting and timely questions with respect to the CSI website vulnerability discovery report.
1) Does CNBC or parent owner GE face potential lawsuits from disgruntled participants?
2) Do the people whom exploited the flaw in attempt to win the contest face any civil liability or potentially criminal charges? What about the people who felt cheated and decided to find the glitch on their own accord?
Civil maybe, criminal is hard to say because it seems they still technically “used” the system in the way it was intended. It could easily go the other way and both sides might have that scary discussion with a prosecutor.
CNBC Notice
We have an update on the CNBC Million Dollar Portfolio Challenge. As CNBC first reported on May 30, we were contacted by several contestants alleging unusual trading in violation of rules of the contest, which ended on May 25.
As CNBC said at the time, we immediately launched a thorough investigation of the contest and we are now focusing on three specific areas of concern.
We are investigating whether one or more finalists wrote and executed computer program scripts to bypass the contest's security measures.
Additionally, one or more contestants were able to change their trades after the markets closed at 4 PM ET, but before the trades were processed by CNBC. That way, a contestant could have executed trades after hours, and have the trades priced as of that day's market close.
CNBC has retained two leading consultants in the information security industry to investigate these two computer programming related issues.
In addition, there have been allegations that one or more contestants may have engaged in illegal market manipulation to affect actual prices of stocks represented in their contest portfolios.
We have engaged an independent securities expert to determine whether such activity took place.
As we said previously, the rules state that CNBC has until July 8, 2007 to declare a winner. Although CNBC hopes to announce a winner before that date, it is more important to ensure the individual awarded the Grand Prize is in compliance with the rules.
Integrity is paramount to CNBC. We are taking all allegations of improprieties very seriously. CNBC will provide updates on the air and on CNBC.com as they become available.
How to Rate the Value of Your Websites
(Road to Website Vulnerability Assessment - Part 2) Friday, June 8, 2007
This is the second installment in the Road to Website Assessment Series. Part 1 (How to Find Your Websites) describes a process for website discovery. This installment (Part 2 ) describes a methodology for rating the value of a website to the business that many of our customers have found helpful. Website asset valuation is a necessary step towards overall website security because not all websites are created equal. Some websites host highly sensitive information, others only contain marketing brochure-ware. Some websites transact million of dollars each day, others make no money or maybe a little with Google AdSense. The point is we all have limited security resources (time, money, people) so we need to prioritize and focus on the areas that offer the best risk reducing ROI.
For example, it might be more beneficial to first resolve a medium severity vulnerability on mission critical website rather than a high severity vulnerability on a website of marginal value to the business. Without the intelligence of website valuation and vulnerability severity, effective decision-making is impaired. Another piece of intelligence we’ll discuss later on is what we at WhiteHat call a vulnerability threat rating, or how difficult a particular vulnerability is to exploit. Not all vulnerabilities are created equal either, but we’re getting a little ahead of ourselves.
As a continuation of the end of part 1, visit each website in the asset inventory spreadsheet, then answer a series of questions about them. These answers assist in a subjective value rating process. I say subjective, rather than objective, because I’ve yet to see a generic value rating system for websites that was quantifiable. If you happen to have one specifically for your company, fantastic, use it. Heck if you can, post it so others can learn from it! If you don’t have one don’t worry, over time you should be able to tailor this methodology specifically for your company.
1) What does this website do and who is responsible for it?
Click around the website, exercise the functionality, fill out a few forms, register an account if you need to. Is it a shopping cart? Web bank? Brochure? Who manages the content and/or security?
2) What would the business impact be if the website were to be compromised or suffer more than 24 hours of downtime?
Sometimes unplugging the network cord (not recommended) on a website is the only way to tell if someone cares about it or if its important. Before you do that though, consider if the website were unreachable or suffered a publicly known data/system compromise. Sometimes organizations have downtime in quantifiable terms. If so, great, use it. If not, terms such will suffice such as:
* Major/moderate/low loss of revenue
* Major/moderate/low reputation impact and brand damage
3) What are the amount of registered users and/or level of visitor’s traffic?
* Hundreds/thousands/millions of registered users
* Thousands/millions/billions of page views / unique visitors per month
* Unknown
4) What's the most valuable type of data collected and/or distributed?
* Personal and private information (names, addresses, phone numbers, social security numbers, etc.)
* Regulated information (credit card numbers, bank account numbers, patient records, attorney privileged data, etc.)
* Intellectual property (source code, customer lists, business plans and objectives, etc.)
5) How often do the web applications change (not the content)?
a) 1 – 4 times per month
b) Quarterly
c) Annually
d) Never or as needed
Answering these questions takes time and a lot of research, but the spreadsheet you’re building will be of huge benefit to the company, especially those with a substantial Web footprint. Taking these answers into account with the appropriate weighting, assign a rating from 1 – 5 to each website with 5 being the most valuable. Share the document around internally for feedback. After you have completed the process, what you’ll have is something that most do not. A well defined and prioritized website asset inventory.
The spreadsheet will look something like this:
How to Find Your Websites
(Road to Website Vulnerability Assessment - Part 1)
Friday, June 8, 2007
I spend a lot of time with companies (mostly large and medium sized) who are interested in finding the vulnerabilities in their websites. Obviously the first step in the VA process is to first FIND the websites. Now this may come as a surprise to many, companies with more than 5 or 6 websites tend not to know what they are, what they do, or who's responsible for them. And if they don't know what websites they own, there is no hope of securing them.
Finding all of a company's websites isn't exactly a trivial process and doesn't end with scanning an IP ranges for port 80 and 443. Virtual hosts, redirects, vanity hostnames/domains, partnerships, and legacy are hurdles that must be overcome. Here is a process that should help:
1) Network Discovery
Find a starting point IP address. Most of the time the main website (i.e. www.company.com) works fine. Look up the IP address using dig or some other utility:
>dig www.company.com
Next plug in the IP address in the ARIN whois database to search for the registered netblock(s). Then have a chat with one of the network systems administrators, asking them if this is indeed your netblock and if they know of any more that might have been missed.
Last, nmap scan the netblock ranges on port 80 and 443 looking for web servers. Sure other web servers could be listening on non-standard ports, but those are likely out of “web application security” scope and can be addressed later.
> nmap -sT -p 80,443 x.x.x.0-255
Save all your results in a spreadsheet.
2) DNS and Zone Transfer
Search for web servers based upon domain names by interrogating the name servers. whois works great on the command line, but if not, any other website (godaddy, register.com, etc.) will do that provides the service.
> whois company.com
Name Server: nameserver1.com
Name Server: nameserver2.com
Next we'll attempt a DNS zone-transfer on the off chance that it's misconfigured. Digital Point Solutions provides a great online utility that does this for you, which loops through each name server attempting the zone-transfer. dig on the command line works fine as well, but I still prefer the Web in this instance.
> dig @ nameserver1.com company.com axfr
> dig @ nameserver2.com company.com axfr
Additionally it doesn't hurt to have a chat with the person in charge of or has access to the domain registrars account to see what other domain names are owned by the company. If you are lucky they might even save you a lot of work by providing the hostname list from the DNS name servers directly. If you have access to the web servers configuration or the person who does, you could also dump the virtual hostnames and get lists that way as well.
Match up the hostnames to the IP addresses in your spreadsheet and log the domain names.
3) Google and Netcraft
Google is a great resource to locate websites, especially if you know the right search options to use. First restrict search results by domain name:
site:company.com
This should provide a list of results, but also a lot of pages on the same hostnames that need to be widdled down. Once you find a hostname, log it, then restrict it from the search results and try again.
site:company.com -www.company.com
Rinse repeat.
site:company.com -www.company.com -store.company.com
and so on until no more results come up. Log all hostnames found.
Netcraft SearchDNS is also an excellent resource for locating hostnames. Perform a wildcard domain name search for each domain name you have logged:
*.company.com
Log each hostname listed. You'll probably get a lot of overlap between Google and Netcraft, but that's OK, better not to miss anything. You also might want to give Fierce (by Rsnake) a try… it locates targets both internal and externally, not just websites though.
4) The grunt work
Visit each website on the list with a web browser and start taking notes. See if the website is: up, active, functional, its purpose, redirects to or anything else informational. Click around the website. Take a look at the links and the sitemap to see if there are any other hostnames or domain names that are not on your list. Doing this with a logging HTTP proxy helps.
Depending on how much websites there are, this can be a painstaking process, but it's also vital.
How to Check if Your WebMail Account has been HackedThursday, May 3, 2007
WebMail accounts are a popular target for malicious hackers, law enforcement conducting investigations, and rouge insiders. WebMail security is very important, perhaps even more so than your online bank account. If your WebMail is hacked, every web-account associated to that address (using send-an-email-forgot-password-system) could be compromised, including your bank. Phishing scams, password brute-force attacks, cross-site scripting exploits, and insufficient authorization vulnerabilities are all commonplace. And for the most part these attempts are impossible for normal users to detect or do anything about. The problem is that unless your password changed without our knowledge, how can you tell if your account has been compromised? Fortunately there is a fairly simple way.
Normally when someone compromises a WebMail account they'll pilfer through all your messages and save anything they're interested in keeping. Unless the intruder is really dumb, and sometimes they are, they'll change all the messages back to unread (bold) so you won't notice their presence. What you can do ahead of time is set a kind of a virtual silent alarm on your account. Here's how:
1) Upload a tiny image somewhere online where you can see the logs of who accesses it. There are a lot of places that offer web space, could come with your DSL provider, or a friend that might have some to share. Once uploaded, NEVER share out the URL to the image. Hide is well because no one should ever find it online by accident.
2) Send your WebMail account an email, containing the silent alarm image, with a juicy sounding subject line like “Your new online Bank password”, “Re: employee personnel files”, or “That's it, we're through!!!”. Anything an intruder wouldn't be able to resist reading. Leave the email as unread in your inbox. This is your silent alarm email.
3) Hopefully this day will never come, but if an intruder were to ever break into your account and read your silent alarm email, they're browser will unknowingly request the embedded image. By periodically checking the image logs, if it ever has activity, you'll know something is up. The web server logs will contain the intruders IP address as well as the date/time of when they broken in and read the message.
Simple. This same process can also be used to protect your MySpace account through the messaging system. Enjoy!
Mainstream Media is Figuring out the Industry's New Disclosure DilemmaFriday, April 13, 2007
"Security holes in online applications may go unfixed because well-intended hackers are afraid to report bugs. Web applications pose a dilemma for bug hunters: how to test the security without going to jail? If hackers probe traditional software such as Windows or Word, they can do so on their own PCs. That isn't true for Web applications, which run on servers operated by others. Testing the security there is likely illegal and could lead to prosecution." Bug Hunters Face Online Apps Dilemma (via Joris Evers from CNET)
We've all debating the legal and ethical issues, but it doesn't change the fact that we're going to lose the canary-in-the coal-mine aspect of information security. Does that mean we're going to have to rely on compliance rather than community peer review? Eeesh!
I also just caught Alan Shimel's follow-up on the article, he comments on one of my quotes:
"Jeremiah Grossman of White Hat Security (and a past guest on our podcast) is quoted as saying that: "We're losing the Good Samaritan aspect of security". He uses the gun law analogy that if we make it illegal to find vulnerabilities in web sites, only bad guys will find them. Sort of like if it is illegal to own guns, than only bad guys will own guns. I disagree with the gun analogy and I disagree with Jeremiah on this one. I just think there is too much room for abuse to allow condone people hacking into web sites. Who really knows what their motives are."
Let me clarify because I still stand by the statement as what will inevitably happen should Good Samaritans be routinely prosecuted. But, I don't think Alan and I fundamentally disagree on the next step of the legal matters. Pen-testing websites without consent is and should be illegal (we can debate proper penalties later). There is just too much risk otherwise. What we do have is a catch-22 situation.
Vulnerability Assessment, When do We Stop Looking?Friday, April 6, 2007
This is a fair and increasingly common question in web application security. Especially considering that we never know how many bugs (or vulnerabilities) actually exist in a piece of code. This is also why I tend to approach security as an attempt to make a system as hard as possible (not impossible, because that's impossible) for the “bad guys” to break-in. Finding and fixing vulnerabilities, whether pre-deployment or post-production, makes the next vulnerability harder to identify. The idea is to require the bad guys to expend more resources (time, money, etc.) than it will be worth should they succeed. Realistically though given a long enough timeline, everyone gets hacked, if they haven't been so already. Which begs the question, when do we stop looking for vulnerabilities?
The answer varies depending on the importance of each website and the security needs of the organization. Beyond the everyday network noise, in my experience the average attacker targeting custom web applications uses a web browser, an HTTP proxy, Google, and perhaps some specially crafted scripts. I think the at this layer odds are the attackers aren't using vulnerability scanners of either the open source (because no decent ones exist) or commercial variety (it's faster for them to find the vulnerability or two they need by hand). The main variable in a bad guys success is their level of persistence and cognitive skill rather than the capability of the tools. This is an important benchmark to understand.
The way the logic works is the more thorough and frequent the VA process, the fewer attackers there are in the world possessing the time/ability to penetrate the system. Depth of testing needs to outpace what is perceived to be the skill of the vast majority of bad guys. Otherwise what's the point? There are the causal researcher types who just want see if they can find an XSS issue on domain X. Then there are the more dedicated and skilled attackers willing invest several weeks or months to defraud a system who are a level above. Frequency of VA should also match the change rate of the application. For example web applications that change every week doesn't match up well with an annual two-week engagement.
At some point VA reaches a level of diminishing returns and after thousands of assessments we have a good idea of best practices and what due diligence represents. We understand security can never be 100% and at some point mistakes will be made, bad guys get lucky, or they're talented and VERY persistent. I created the following diagrams to illustrate these concepts. The diagrams are not meant to be a literal measures but to visually describe the fundamental concepts.
Time/Difficulty vs. Total Vulnerability (%)
Now if we overlay the estimated effectiveness of certain solutions in the same vulnerability coverage zone of certain adversaries.
Effectiveness/Skill vs. Persistence
When do we stop looking?
As a biased VA vendor it'll sound self-serving (but so be it): On websites where the code changes more than a few times per year which require at least a modest degree of security, you never stop looking because the bad guys certainly won't. Applications are changing and the attack techniques are improving even if the applications aren't. You want to enlist those who are AT LEAST as skilled as the pool of attackers, have a thorough methodology, and a consistent process. To borrow a quote from Bruce:
“Security is a process, not a product.”
Automated Scanners vs. Low-Hanging Fruit Tuesday, February 20, 2007
Low-Hanging Fruit
(LHF) are vulnerabilities that are easy to find and exploit. We certainly don't want these types of issues in our websites, especially if
they can be quickly mitigated with a small amount of effort. In network security, scanning does the trick for LHF identification.
Unfortunately, in website security, though
scanning is absolutely vital, it's not that simple or sufficient.
That's because LHF may fall into either technical vulnerabilities, which
website vulnerability scanners can find, or
business logic flaws, which they can't find much
of any.
Technical vulnerabilities, including Cross-Site Scripting (XSS) and SQL Injection, can be
found in large supply by scanners and usually can
be classified as LHF. For instance, when a website
echoes user-supplied HTML, that's a dead
giveaway of an XSS vulnerability. The same with
SQL Injection and the notorious ODBC error
messages dumping database statements. These
instances are easy to spot and exploit. Though as
common as these issues are, they're not
always classifiable as LHF.
Input Validation or Output Filtering, which is Better?
Tuesday, January 30, 2007
This question is asked regularly with respect to
solutions for Cross-Site Scripting (XSS). The answer is
input validation and output filtering are two different
approaches that solve two different sets of problems,
including XSS. Both methods should be used whenever
possible. However, this answer deserves further
explanation.
Input Validation
(aka: sanity checking, input filtering, white listing,
etc.)
Input validation is one of those things ranted about
incessantly in website security, and for good
reason. If input validation was done properly and
religiously throughout all website code
we'd wipe out a huge percentage of
vulnerabilities, XSS and SQL Injection included.
I'm also a believer that developers
shouldn't have to be experts in all the crazy
attacks potentially thrown at a websites. There's
simply too much to learn and their primary job should
be writing new code, not to become website
hackers. Developer should only have to concern
themselves with the solutions required to mitigate any
attack no matter what it might be. This is where input
validation comes in play.
|
A Today, PC World, Dark Reading, SC Magazine, SecurityFocus, CNET, CSO Magazine, and InformationWeek.