tssci security

Collaborative systems and Ajax/RIA security

Office collaboration services look like 1985

Microsoft Outlook and Exchange server have been the staple for office collaboration for over 10 years, with a model that has been around since Novell and Lotus in the mid-80's. Collaboration services are clunky, bloaty, and every IT administrator and techie hates both of them with a serious passion. Outlook Web Access... -- never mind, I'm not even going to finish this sentence. When people say that Microsoft stifles innovation this is exactly what they are talking about. I don't mean to pick on Microsoft -- because Apple, IBM Lotus Notes, and the open-source community (no CTO is going to approve anything with `Squirrel' in the name) have not stepped up to provide anything equivalent.

SaaS makes collaboration worse

Everyone and every organization does their mail, address-books, calendaring, time management, conference-room reservations, and public folder sharing a little different. Some people like to download everything from the server and save it locally. Others keep all their mail on the server. Some do both. Email retention and anti-spam are a big deal for a lot of Enterprises, so much that people even outsource these or all collaboration services.

Organizations are also moving their data more online, to Google Analytics, Salesforce, NetSuite, et al. Do you trust your CRM or ERP to a SaaS solution, even if you are a small business? Even if you do trust them, how are you going to integrate these solutions, especially with your Exchange server?

Google's answer is their GApps, an integration of GPages, GMail, GTalk/Chat, GDocs, and all their GAPI's. Have you heard of an SMB or Enterprise that has moved their collaborative efforts to GApps? My guess is that not many have.

I've seen many businesses struggle with SaaS and outsourcing of collaboration services. When considering outsourcing, a normal strategy is to look at moving 20 to 40 percent of non-core business services to managed services. Groupware should be considered a core business service/need in a large majority of cases, as it really drives the day-to-day business and contains much of the documented and hidden processes that occur inside any organization.

It's almost 2008. Stop using Exchange server already

Enter Zimbra's Collaborative Suite (ZCS) -- a groupware server with Outlook compatibility that was recently purchased by Yahoo for $345M. Zimbra has been around for at least 2.5 years, so that fact that you haven't heard of them is strange. Even Mike Rothman daily debates switching over everything to Zimbra, but his worry about costs shouldn't scare you.

Zimbra's ZCS Server runs on Linux (or Mac OS X). Linux can handle all of your Windows clients, file sharing, and printing with Samba, can run LTSP to PXE boot your environment into FreeNX/Windows-TS, and can cluster it all for free. I've done so using Ubuntu LTSP inside Xen guests on CentOS along with keepalived. The architecture becomes lightweight if you have a 5U chassis (and cold, empty standby) with 24 spindles and 8 TB of hardware RAID-1 running CentOS and IET. Then you have two powerful 1U or 2U machines running CentOS with cman/fencing, clvmd, and iSCSI-initiators mounting filesystems as OCFS2. Xen guests are booted from the shared storage. For an example without shared storage, see clustering Zimbra from Ben Rockwood.

Compare the above reference architecture to Exchange. You'll need NLB for everything except Exchange clustering, which requires MCS because of MS SQL Server. To get anywhere near the equivalent of the above, you'll want VirtualIron or VMWare ESX Server. The enormous licensing costs are building in my head as I think it through. There is no way to do this with shared storage, and this is a heavyweight solution with lots of overhead.

The differences in clients are very similarly disparate -- Zimbra is lightweight and Exchange/Outlook is not. There are a few other solutions such as OpenGroupware+ZideLook or DeskNow that provide similar Outlook compatibility as Zimbra. They have support for the DAV's, iCalendar, and other good groupware features. Zimbra, however is especially unique in many ways.

Zimbra on Ajax security

The benefits and drawbacks to using Ajax are summarized very well in a ComputerWorld article by Paul Krill. Scott Dietzen, president and CTO of Zimbra, elaborated very well to both points in this excellent article. He says that he favors Ajax to Flash, and Ajax frameworks to Flex2. I would say that any RIA framework is capable of providing these sorts of services, but Ajax has been around the longest.

The interesting part is when Dietzen talks about Ajax security:

Dietzen did cite AJAX security issues such as cross-site scripting attacks, in which user data can get interpreted in the browser, creating a breach. Also noted as a security concern was use of source code in the browser.

[ ... ]

Blocking execution of user JavaScript inside of an application is important for combating server-side scripting attacks, according to Dietzen. Obfuscation and minimization technologies to remove white space can be used as security measures, he said. On the positive side, there is no caching of user data on the desktop with AJAX. Dietzen also advised that sensitive code not be put in a browser.

With the recent release of the book, Ajax Security, by Billy Hoffman and Bryan Sullivan -- hopefully Ajax developers and CTO's such as Dietzen will be able to be armed with the best resources for protecting their applications and userbase.

Collaborative systems need Web services support

Zimbra has support for SOAP, REST, and JSON, but certainly Web services will also need to be provided securely. I couldn't even imagine how great it would be to combine my collaborative Office tools with my collaborative personal research. If I could even import/export betwen my Google Reader RSS feeds and my Office feeds (using OPML), that would be extremely useful. Web services take this sort of technology to the next level.

It would be great to combine XMethods and mashups into your groupware system for a number of reasons. This level of customization is going to be a driver for innovation in groupware products. I'd like to see some of best mashups done with Enterprise data and shared as groupware. ChicagoCrime and HousingMaps are great, but we can do many more interesting things in the Enteprise.

The security of Web services and Ajax gateways/proxies for building mashups comes into question here. The commercial version of SOAPSonar only costs around seven-hundred dollars, and supports XSD-Mutation, and automated vulnerability assessment/detection. There are plenty of open-source tools for testing web services, such as those mentioned in my post on 2007 Security Testing tools in review. If well tested, Zimbra (and others like it) will be able to provide mashups along with Web services support, and do so securely. JSON is also vulnerable to API hijacking, and the Ajax Security book provides interesting solutions to its defense that you absolutely have to check out.

Collaborative systems need offline applications support

Exchange has beat out many open-source groupware services because of the requirement for supporting offline applications. Users cite issues such as travel and intermittent Internet connectivity, while others simply prefer working both offline and on. Zimbra has amazing offline application support, here are some quotes from the ComputerWorld article:

"The answer for occasionally connected apps is to provide a cache on the client side that allows the application to interact locally with a data set, and then synchronize over the network when the network is available," said Dietzen.

Offline AJAX systems can be developed by using a set of caching APIs in JavaScript that enable this. These are accessible via offerings such as Google Gears and the Dojo offline tool kit.

[ ... ]

But Zimbra used another approach. "What we did at Zimbra is we actually took Zimbra server code, which was written in Java, and we created a microserver that runs on my local client," said Dietzen.

Zimbra also has a great PDF presentation called Ajax Unplugged, where they compare their Zimbra Desktop offline technology, including Zimlets, to Adobe Apollo, Dojo.Offline, Joyent Slingshot, and Mozilla's Firefox 3 Offline support and XULRunner. The Ajax Security book dedicates an entire chapter, but only details Google Gears and Dojo.Offline, while minimally mentioning WHATWG (FF3 work), Joyent Slingshot, and Adobe Apollo. I'm also partially surprised that there was no mention of Zimbra, who has chosen to build their own solution.

However, Billy and Bryan's coverage of the attack surface for Ajax offline applications is no joke. Apparently, Billy Hoffman plans to release a new tool to take advantage of some of these attacks against Google Gears in a tool called GGHOOK. GGHOOK is based on another tool called HOOK (covered in an earlier chapter on Ajax function hijacking) -- both of which will be released on his website shortly. The biggest take from the book's chapter on offline applications is how client-side input validation has become relevant again. The sad part is that the Ajax frameworks aren't providing a lot in the way of client-side input validation for this purpose.

One of the largest problems for a system like Zimbra is XSS for the client-side data stores. We all know that XSS is capable of stealing cookies and controlling the browser, but imagine the damage it would be able to do in this scenario, especially as wormable. Thankfully, ZCS Server is a local solution and doesn't even have to be Internet accessible, which would minimize some of the damage from this theoretical attack. In the case of Google Gears, all of the data can be stolen using GGHOOK, which locates the Google Gears database object and queries the local SQLite tables. Ajax security testing will also be important to solve these sorts of issues.

Zimbra innovations

Besides providing Web services into the Zimbra/Zimlets API, providing a feed reader, and taking Zimbra offline -- they have also done some other notable things to increase collaboration.

Dietzen mentioned the AJAX technique of **`AJAX Linking and Embedding (ALE) <http://www.zimbra.com/blog/archives/2006/04/zimbra_ale-ajax_linking_and_embedding.html>`_*, in which one document can be embedded inside another. This expands content-sharing.* He also cited a technique called [ **`Lazy Loading <http://www.zimbra.com/blog/archives/2007/03/lazy_loading.html>`_* ] which cuts down loading time for Web pages. With lazy loading, the page loads but other parts of the application, such as calendaring, are loaded only as needed.*

Besides supporting various mail thick-clients, including Outlook and Apple Mail -- Zimbra has their ZCS web client aka "clientless mode". With the "lazy loading" support, this makes using Zimbra more powerful, faster, and cleaner than using a fat application client. However, it also exposes it to all of the web application and Ajax security problems.

Documents embedded in documents and HTML/JS embedded in HTML/JS are interesting concepts for web applications. The ALE specification provided by Zimbra is a good way of engineering this type of technology. Modern browsers have a concept known as "design mode" where the browser becomes the HTML editor.

Similarly, there's design mode in GMail, GDocs, and other web applications you may be familiar with. It has been argued between web application security scanner vendors that if scanning Ajax is difficult -- scanning "design mode" is nearly impossible. I'd like to see more specifications such as ALE come out, possibly as a standard. If so, testing Ajax-driven "design modes" could be much easier to automate.

Issues with Ajax security testing tools

Google has ways of automating their Ajax testing -- they use distributed Selenium (using grid technology) and WebDriver in order to accomplish these tasks. For commercial solutions, I like froglogic's Squish for Web more than PushToTest orHP Mercury Interactive's QTP -- but all of these are viable Ajax testing solutions. Combining security-driven fault-injection tests into these data-driven frameworks is currently the best way to test for Ajax security issues.

For theory, your best current bet is to read the Ajax Security book. The authors fail to mention tools that test Ajax. Well, they mention their own commercial scanner (nice, guys!) and one other open-source tool. I haven't mentioned it before, avoiding it as a topic for several reasons -- not even on my post about Why crawling doesn't matter. Billy and Bryan are quick to point out that the tool not only requires MS SQL Server, but also that the tool only tests the Microsoft ASP.NET AJAX framework (possible future support of GWT is mentioned). Here's a link to it anyways, as maybe the attacks in it are worth re-purposing -- the OWASP Sprajax Project.

The future of Ajax security testing tools is ripe for both the Technika Security Framework and the future-work in the w3af scanning tool, as each will be well-balanced browser-drivers. Until such a time, we are stuck with either quality testing tools (which lack the vulnerability and attack data), commercial web application security scanners (which lack critical testing capabilities), and less than a handful of open-source tools such as the Blueinfy tools, OWASP Interceptor tool, and w3af's DOM-based XSS module.

The largest issue that I see with Ajax security testing is the lack of secure static analysis techniques and tools. JSLint and DeHydra could be starting places for work in this area. The recently released commercial tool, Fortify SCA 5.0, just added some support for secure static analysis of Javascript/Ajax issues, but this is largely limited to XSS, Javascript function hijacking, and JSON API Hijacking (which was discovered by Fortify).

Ajax isn't the only security problem

The issues presented in this post are only scratching the surface of the overall problem. It appears that people who already place active attention into Ajax security issues are failing to follow-through with coverage of all the theories -- let alone running code. For example, Zimbra may understand XSS and Javascript obfuscation. HP SPI Dynamics and Fortify may support minimal Ajax testing for security issues. The real problems begin when we combine Web services, offline applications, and "design mode" HTML/JS editors. This becomes especially compounded with multiple Ajax and RIA frameworks.

Other logical security-related issues and design flaws will creep out. Using Firebug, it is incredibly easy to control the execution flow of Javascript-based applications. Ajax improves performance and speed, so surely timing and side-channel attacks will become relevant. Since Javascript is embedded in HTML/CSS content and browsers -- affecting the "presentation" of applications is a major attack vector that we will need to supply a lot of attention to.

Yesterday, I spent a little while playing with Dust-Me Selectors, a Firefox extension mentioned in the Ajax Security book for testing for unused CSS rules. It has a "Run automatically" mode that I tried out, which demonstrated the power of CSS data mining. Javascript on-demand hijacking (or framework hijacking) involve problems with leaking information about Javascript functions. In a similar way, CSS data mining involves problems with leakage of CSS content resources.

I've also mentioned Flash and other RIA frameworks in the past, but I don't want to go too much in-depth in this post. Hopefully, I've opened up your mind to a few of the problems with modern applications and testing them for security.

Posted by Dre on Thursday, December 13, 2007 in Defense, Hacking, Security and Work.

Building a security plan

An audit framework for evaluating structured security program frameworks

How many readers implemented a new security plan for 2006 or 2007? How many had clients that implemented a new security program? Which frameworks were involved?

Possible frameworks (Criteria)

Break down your plan

Even if you have no formal plan (e.g. buy SANS! buy Microsoft!), let's try and find out how the security program was implemented. A plan can be broken down into three major aspects, and several areas of specialty, however my list is not exhaustive:

Did you start from a top-down or bottom-up approach? Were you able to implement all three aspects? To what degree? Which area was most successful? Which areas were not successful?

Plan effectiveness and measurement

Did the framework you chose work for you in 2006/2007? Are you going to continue using it? How effective was it? How did you measure the effectiveness? Would you think about moving to a different framework in 2008? Which one? Why?

I read a book from Andrew Jaquith called Security Metrics: Replacing Fear, Uncertainty and Doubt on March 8th of 2007. Until the ISO 27004 standard is completed, this is above and beyond the best/only way of measuring the effectiveness of any security program. Rothman has some great ideas on his blog and in the P-CSO. As a reader of the TS/SCI blog -- I think you should feel obligated to check out securitymetrics -- add the blog to your RSS and get on the mailing-list if you haven't already.

Risk analysis

The ISO 27005 standard is also in progress. The ISO/IEC 27000-series FAQ answers the question of which information security risk analysis methods can be evaluated in the mean time. I have listed some of the obvious risk analysis frameworks listed from the FAQ, but I don't have any experience with a lot of these.

A comment on SecGuru introduced me to Practical Threat Analysis, a software suite (free to researchers/analysts) that aids in risk analysis and audits. It has modules for ISO 27001 and PCI-DSS 1.1, which include industry vertical customizations. There couldn't be an easier way to perform nearly-automated risk analysis, or just as a guide for self-assessment.

Risk analysis for software assurance has been a major interest of mine for the past two years, and here's my sorted list:

It's unsurprising to hear that the security measurement masters (Jaquith and Rothman) both have extremely unique views on risk analysis. Rothman seems to like "risk-adjusted expected loss models" in the P-CSO, but also calls them "black-magic" and "fear-mongering". His solution appears to revolve around ROSI/ROI methods he separates into best/worst/middle-road cases.

Jaquith's view: risk-modeling is incredibly important, but very hard to do. His primary point of his book, however, is that risk management is dead. The Deming Wheel (Plan-Do-Check-Act or PDCA) is Jaquith's Hamster Wheel of Pain, the antithesis of managing risk and measuring security. I found it interesting that Jaquith's Holy Grail is the Security Balanced Scorecard, which is based on a Six Sigma tool by the same name. Six Sigma's key methodology is based on the primary tool, DMAIC (Define-Measure-Analyze-Improve-Control), clearly inspired by Deming's PDCA. Adam Shostack has also referenced the military strategy OODA Loop (Observe-Orient-Decide-Act) as the basis of a security plan. Most interesting to me are "elements of a finding" from GAGAS 7.73 (US Government standards for performance audits) which lists Criteria-Condition-Effect-Cause.

Combining programs and putting risk assessment in its place

While Jaquith says that the program categories in his book are based on COBIT, he also mentions a gem entitled Aligning COBIT, ITIL and ISO 17799 for Business Benefit. His approach to risk analysis (i.e. assessing risk) is tied to effectiveness, is forward-looking, and denounces risk management and asset valuation (especially ALE). Instead, his view is similar to mine - risk assessment is primarily for software assurance and vulnerability management.

I have mentioned products such as Configuresoft and Lumension Security in the past few blog posts. These two vendors supply patch management solutions. I probably should have mentioned other possibilities such as BigFix, Opsware, and ThreatGuard (my bad). Recently, I came across the MITRE OVAL-Compatible program, which lists these and a few other vulnerability management solutions. OVAL support is great for managing risk from vulnerabilities, but I feel obligated to also mention Cassandra (an email service from CERIAS at Purdue), Advisory Check (advchk, which works via RSS), SIGVI (FOSS Enterprise vulnerability database), and OSVDB 2.0. Of course, this "vulnerability management" only applies to "known" vulnerabilities. Let's turn our attention back to unknown vulnerabilities, which are inherently weaknesses in software.

What is the problem we are trying to solve? (Cause)

I'm sure that you'll hate me for a few seconds here as I apparently go off-topic on an already overly long post. I would really like to address some issues with these modern-day security programs. Jaquith bought up some excellent points regarding security programs, risk management, and risk assessment. The root-cause of our problems come down to laws of vulnerabilities. Stop the vulnerabilities; stop the attacks; stop the threats.

Richard Bejtlich introduced some anti-audit sentiments while providing interesting ideas in a recent blog post, Controls Are Not the Solution to Our Problem. In it, he addresses hardened builds that are tested with vulnerability management, pen-tested, and shot into outer space (j/k on this last one). He also addresses topics of visibility and integrity. I can fully see his vision here, and it's quite good from an operational perspective.

For me, I come from a long line of intense operational background. I'm your 1997-2004 equivalent of a Green Beret Veteran from Vietnam, only a BGP Operator Veteran from Silicon Valley (although I prefer the term *Renegade Network Engineer*). My introduction to Unix/network security came on much earlier and it was then that I learned that all security problems are due to vulnerabilities and all vulnerabilities are due to bugs.

However, I often fail where it appears that I most succeed. I had a hard time trying to balance building things with breaking things, which made me avoid the security industry like the plague (plus all of the other obnoxious reasons). Sometimes I think that I don't have the security gene.

Yet I proselytize developers managing risk by producing significantly less vulnerabilities based on a process so simple in nature -- the CPSL I defined. Why do I think this will work? These developers are also lacking the security gene. Usually, only people with advanced knowledge and practice in finding vulnerabilities or writing exploits have the skills and genes necessary. These individuals are few and far between. Or are they?

Vulnerability theory (Effect)

Some of my frustrations as an operator have finally come to pass in the security world as well. When my mentor Tom Jackiewicz handed me a dog-eared copy of DNS & BIND, 1st Edition, and said "this is a black art; learn this first", this instinctively pushed to me to learn everything about DNS. Weeks later, I found out about the darkest art at the time, BGP routing. My biggest take from both of these is that after learning them -- I realized that they weren't really dark arts and were very easy once you got the theory down.

On Tom's birthday this year (maybe a tribute?), MITRE released a document called Introduction to Vulnerability Theory. In the introduction to this "Introduction" it reads:

Despite the rapid growth of applied vulnerability research and secure software development, these communities have not made much progress in formalizing their techniques, and the "researcher's instinct" can be difficult to describe or teach to non-practitioners. The discipline is much more black magic than science. For example, terminology is woefully garbled and inadequate, and innovations can be missed because they are misdiagnosed as a common issue. MITRE has been developing Vulnerability Theory, which is a vocabulary and framework for discussing and analyzing vulnerabilities at an abstract level, but with more substance and precision than heavily-abused, vague concepts such as "input validation" and "denial of service." Our goal is to improve the research, modeling, and classification of software flaws, and to help bring the discipline out of the dark ages. Our hope is that this presentation will generate significant discussion with the most forward-thinking researchers, educate non-expert researchers, and make people think about vulnerabilities differently.

The document goes through rough definitions and examples. Many are based on artifact labels to identify code sections/locations. In order, these labels are given as Interaction-Crossover-Trigger-Activation. The document also tries to introduce concepts and seeks feedback constantly throughout.

My favorite part is the "Related Work" section. Some of these have already been mentioned in this post, including the RASQ / Measuring Relative Attack Surfaces work and the Trike model. I've also already mentioned The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities, which apparently is a must-read for at least chapters 1-3, in addition to their accompanying website. I'd also add generic vs. context-specific and design/code visibility as portrayed in Secure Programming with Static Analysis, which also mentions the OWASP Honeycomb Project.

The final reference, the infamous Matt Bishop (author of Introduction to Computer Security and Computer Security: Art and Science), alludes to his research on "Vulnerabilities Analysis":

This project treats vulnerabilities as a collection of conditions required for an attacker to violate the relevant security policy. We're developing a set of conditions that apply to multiple vulnerabilties, which will help us locate previously unknown vulnerabilities, and a language to express the conditions in, which will help us reason about vulnerabilities with respect to security policies.

Types of vulnerability testing

While reading Matt Bishop's research, I also uncovered an interesting presentation entitled Checking Program Security: From Proofs to Scanning via Testing. He talks about different types of security testing (see the comments discussion between Ariel and I in the previous post on Why pen-testing doesn't matter for more information). From my blog post on Formal Methods and Security, I will change these to read:

Today, most vulnerability testing is done as ad-hoc. There are multi-stage attacks such as those described in Building Computer Network Attacks and w3af - A framework to own the Web. This sort of research may bring penetration-testing into the world of science by using formal methods such as hierarchical task networks (HTN) and Markov decision processes (MDP). HTN and MDP enter the realm of AI -- the promised land for all of the scanner vendors (network, application, software, source-code, exploitation engine, et al).

Artificial Intelligence to the rescue

Godel and Turing would say that computers are not capable of producing formal proofs, including any automated theorem-prover (ATP). I recently read Another Look at Automated Theorem-proving, which demonstrates these principles remain the same -- ATP over-promises and under-delivers.

Take an example from that paper, Fermat's Last Theorem. The proof was completed some 357 years after the theory was proposed. It was argued by the media that the theory should have been solvable by a computer.

If an integer n is greater than 2, then the equation a*n* + b*n* = c*n* has no solutions in non-zero integers a, b, and c.

However, this problem can only be solved through a geometric or inductive proof, requiring a human. An ATP, given a^3 + b^3 = c^3 to solve a, b, and c -- will simply run forever. This is due to the Halting problem.

Nitesh Dhanjani wrote an excellent piece on Illogical Arguments in the Name of Alan Turing recently. For those in the security industry claiming the Halting problem (or the undecidability problem, one of Turing's other laws) as the reason why we haven't improved any further, this should be mandatory reading.

See my previous blog post on Formal Methods and Security for some thoughts on how model-checkers and ATP's can come to our rescue. Also expect some future posts on this topic (although I could use some guidance on where to research next).

Chess and the vulnerability problem (Condition)

No, I'm not talking about Brian Chess from Fortify Software (although this may be a good place to start with your budgeting plans for 2008). I'm talking about the game, "chess".

AI may have the best tactics, but only humans can provide the strategy necessary to defeat their machine opponents. Except of course in the case of Deep Blue, a chess-playing computer developed by IBM that defeated world champion Garry Kasparov in 1997. Deep Blue cheated on strategy, by using an evaluation function that had previously analyzed 700k grandmaster games, which additionally required tuning between games. Deep Blue was also tuned specifically to Kasparov's prior games.

Many people who first start to play chess think that it's entirely a strategic game (based on the above and other various reasons), focusing very little effort on tactical maneuvers. Experienced chess players will tell you that chess is mostly tactics. Chess "currency" such as time, space, and material eventually become patterns of recognition to chess masters.

In the third section above, "Break down your plan", I list three aspects of a security plan: strategic, operational, and tactical. If your security plan is largely tactical, you'll begin to see patterns of vulnerabilities and software weaknesses. If it's too strategic/operational and not backed up with enough tactics, you may end up with some losses. Many security program frameworks do not include enough information on tactics, or they don't address the right tactics.

Criteria, Condition, Effect, Cause, (Recommendation)

Having said all of this, I would encourage people to evaluate their current security program against Gunnar Peterson's Security Architecture Blueprint. I feel his program covers a lot of the tactical, risk management, and measurement issues presented in this post in a very succinct manner. Don't take just my word for it; also see what Augusto Paes De Barros (he suggests combining the P-CSO with the Security Architecture Blueprint), Anton Chuvakin, Alex Hutton, Chris Hoff, and Mike Rothman (under Top Blog Postings, on the first one listed here and the third one listed here) have to say.

It would be interesting to turn Gunnar's security program framework into an ISMS usable by ISO27k. The combined framework could then be further combined with COBIT and ITIL in order to meet a variety of requirements. This would allow for ease of use when dealing with auditors, particularly under the auspices of governance and regulations.

In the Security Architecture Blueprint, I particularly like the inclusion of Assurance, and pointers to work such as Architectural Risk Analysis. His domain specific metrics and use of dashboards is above and beyond some of the material in Jaquith's Security Metrics.

I recently came across a presentation Gunnar gave at QCon, the InfoQ conference in San Francisco. While the talk was on SOA and Web Services Security, in the first section he addressed Network, Host, Application, and Data security spending in a way that I thought was truly unique. My take was that typical businesses are spending too much on network security and not enough on data or application security. It appeared as if he recommended to take half of the network security budget and allocate it to software assurance and data protections.

One of the most interesting takes from Gunnar is the unanswered question about asset valuation. On May 4, 2006, as a post to the securitymetrics mailing-list, he said:

"Customers and customer relationships, as opposed to a valuation of the amount of gigabytes in the database, have tangible, measurable value to businesses, and their value is much easier to communicate to those who fund the projects. So in an enterprise risk management scenario, their value informs the risk management process ... [For example, consider] a farmer deciding which crop to grow. A farmer interested in short-term profits may grow the same high-yield crop every year, but over time this would burn the fields out. The long-term-focused farmer would rotate the crops and invest in things that build the value of the farm and soil over time. Investing in security on behalf of your customers is like this. The investment made in securing your customer's data builds current and future value for them. Measuring the value of the customer and the relationship helps to target where to allocate security resources".

Gunnar's recommendations here are consistent with Balanced Scorecards, and the Security Architecture Blueprint is directly compatible with Jaquith's Security Metrics. This also allows easy integration with Six Sigma, including other 6S tools such as Voice of the Customer (VOC), KJ Analysis, and SIPOC.

Having a good security plan is critical to the success of your organization, your job, and extends value to your customers. Will you make the right decision on a security program for 2008? Will you be able to say whether your program was effective come 2009? Did you calculate risk correctly? Did you value your assets correctly? What regulations and other requirements do you need to satisfy or comply with? Will your security program allow you to fully meet all of these requirements? Based on these recommendations, this framework should guide you towards building the right security plan in no time.

Posted by Dre on Monday, December 10, 2007 in Defense, Hacking, Intelligence, Politics, Security, Tech and Work.

Simultaenous use of Firefox profiles to guard against CSRF attacks

Here's a quick post to decrease your exposure to attacks against web application vulnerabilities. A couple months ago, I posted an article that detailed 8 Firefox extensions for safer browsing. In addition to the extensions listed in that post, I use another precaution while browsing websites: I simultaneously run multiple Firefox profiles. There are a couple reasons for this, such as oh... I dunno. I always thought people would run one profile for day-to-day activities/regular browsing, and another for doing security testing and web assessments. But did you know running separate instances of Firefox guards against CSRF attacks? Yes, it does!

If you're not using multiple Firefox profiles already, start up Firefox with the -ProfileManager option. On Windows, you can edit the shortcut target and append -ProfileManager.

"C:\Program Files\Mozilla Firefox\firefox.exe" -ProfileManager

MOZ_NO_REMOTE=1

To run Firefox profiles simultaneously, you'll need to export MOZ_NO_REMOTE=1 user environment variable. You can enter new environment variables on Windows through System Properties > Advanced Tab > Environment Variables dialog. On Linux, you can do the same by running the following from the shell or in a startup script.

$ export MOZ_NO_REMOTE=1

An alternative to exporting the environment variable, you can append the -no-remote option to Firefox (through a shortcut icon, just add it to the target location). If you want to create icons to start specific Firefox profiles like I do, you can specify which profile by it's name using the -P option.

Here are some Windows examples you can set:

"C:\Mozilla Firefox\firefox.exe" -P profilename -no-remote

"C:\Mozilla Firefox\firefox.exe" -ProfileManager

and for Linux:

/usr/bin/firefox -ProfileManager

/usr/bin/firefox -P profilename -no-remote

You can also go ahead and do what Joanna Rutkowska does, and practice "almost-full" privilege separation on Windows Vista and run different browsers with limited privileges.

Posted by Marcin on Sunday, December 9, 2007 in Security.

Client-side attacks: protecting the most vulnerable

Chris Hoff published his 2008 Security Predictions, which offer a very dim future for the security industry.

His first attack vector is regarding the virtualization hypervisor attacks. Didn't Ptacek prove that this vector is useless? I'm starting to see new work in this area, but it's not focused on attacks - it's more on defense/analysis. Expect to see kernel debuggers that get into the hypervisor, ready for CanSecWest and BlackHat next year.

The second attack vector is listed as a major privacy breach of a social networking site, which has already happened over and over and over again. How much more major is it going to get?

His others I'm going to have to agree with, only that I'm a little more positive-thinking about the future for 2008. Many of these are bound to happen sooner or later, so preparing now really isn't a bad idea. Hoff has a lot of insight into this, citing specific technology that works / doesn't work.

All except his #8 prediction, "Expect to see compromise of the RF you hold so dear". RF has already been compromised before. What exactly is new about this sort of attack?

Hoff states, you fire up that Verizon EVDO card plugged into your laptop or tether to your mobile phone instead because it's "secure"

I wonder if he is saying that EVDO's use of CAVE (128-bit AES) isn't properly sophisticated in the same way that WEP or WPA-PSK are also insecure? Or maybe Hoff is more forwarding thinking than I am. Could it be that there will be even more advanced attacks on EVDO such as the forthcoming work by Josh Wright on PEAP?

Now, if Hoff had used the words "GPRS, EDGE, UMTS, or HSDPA", I would be more likely to believe about a viable RF attack. GSM has had numerous problems in the past. I am not saying EVDO is flawless, but of all of these RF-based technologies, I expect EVDO to hold out the longest and have the least severe vulnerabilities of the bunch. WiFi and EDGE are likely to continue to be the focus area of RF attacks, not only because of their popularity (read: iPhone), but because of the existing work already done to reverse engineer their protocols, scan their networks, and provide packet dumps in Wireshark.

I use EVDO to connect to the Internet whenever possible, with my built-in WiFi turned off. When I use WiFi, I'm unable to bring myself to login to anything sensitive unless I'm already using an SSL VPN (SSL-Explorer is an open-source SSL VPN server) for the rest of my traffic. With attack tools such as WiFiZoo available for platforms such as the Nokia N800, I'm afraid that even turning on wireless will immediately send "something" to later WiFi fingerprint me or provide a source of sensitive information leakage.

At Toorcon 9 there was a talk about the Caffe Latte Attack, and there will be more to come at Shmoocon, judging by the recently released speaker lineup. What I find interesting about the Caffe Latte Attack is that they recommend using a "wireless security agent" to protect yourself. This reminds me of the Shmoo Group's Hot Spot Defense Kit, which was released at DefCon 12.

Haven't we shown that agents are an insecure approach to the problem? If this had changed, then Cisco wouldn't be announcing a remote buffer overflow in their Cisco Security Agent product. This is a product which claims protection against zero-day attacks. Does anyone have a problem with this besides moi?

It's uncanny how wireless attacks and browser attacks are so similar in nature. Both are relatively new, almost everyone uses them everyday without thinking about the consequences, and both have gaping huge vulnerabilities that developers seemingly refuse to fix. When simple solutions are provided (e.g. WPA-PSK) to fix the problem, stupid users pick dictionary passwords that are cracked within seconds and developers don't salt the passwords on the server-side. Everyone chooses usability over security, especially when it comes to WiFi and Firefox/IE/Safari. Don't forget the backwards compatibility!

Instead of solving these problems at the root-cause of the issue, we rely on "agents" such as anti-virus, host intrusion-protection systems, or WiFi-HIPS to provide the protection against wireless and browser attacks. Millions of malware spreads everyday through web browsers, while some of the largest data breaches like TJX were due to wireless attacks. Yet nobody is willing to take the risk of slightly "changing" the browser or wireless technology, lest face the wrath of the masses that would be unwilling to "buy into / upgrade to" the more secure solutions.

At least for wireless, there exists a WVE, or a single place to go to learn about the latest in wireless attacks. There's no place to go for browser vulnerability information. Let me repeat that. There is no place to go for browser vulnerability information. One would have to enumerate all the plugins, add-ons, and extensions for all of the browsers that one uses. This would only cover some of the vulnerability management problems inherent with browser vulnerability information. Patch management systems such as Lumension Security and Configuresoft fail to provide vulnerability management for these sorts of applications as well.

I've always been especially interested in the cross-over between browser and wireless attacks, such as airpwn, Ettercap filters, and KARMA. Imagine the consolidation of attack tools such as W3AF, Metasploit, and Wicrawl. It is very likely that all of these attacks tools will make it into the upcoming beta release of BackTrack 3 on December 14th.

I dislike solving problems with architectural recommendations and fixes to operational process, as using development process such as my recommended CPSL will eventually increase security above and beyond the recommendations I give below. At the same time, people do need to know about ways to protect themselves without asking their favorite Anti-Virus vendor whether or not they support Web 2.0. If you know anything about Javascript or Flash security - and how this influences/changes signature-based defense - then you'll know it's easy to infect a web browser with only whitespace, completely randomized alphanumerics, or whatever the attacker chooses. Nobody can build a signature for this.

Who are you going to turn to next? Patch management vendors to make sure that browsers and browser plug-ins are updated? How about protection against zero-day attacks using anomaly detection? Let's just add more agents that have inherent security weaknesses because they weren't properly tested into the mix, why not? Add a DLP host agent as well! That'll do the trick!

Protecting against the latest in browser attacks will mean providing some sort of Browser Vulnerability Enumeration project (BVE). I recently read from a few sources that OWASP (because of RSnake's talk at AppSec 2007 in San Jose) is going to start up a new project to concentrate on browser-related vulnerabilities, a "browser security group".

Until such a platform and group exists, there are a few ways in Firefox to provide safer browsing. Usually these defenses aren't going to prevent a vulnerability in an outdated version of your browser or plugin. Detecting these is normally a job for vulnerability management, but since the OS and Patch Management vendors leave this job up to the user, it's the user that suffers when he/she doesn't know how/when to patch what. Operators or inline devices must be able to provide this vulnerability management themselves, usually by passive analysis (e.g. packet capture of browser information) or via transparent proxy logs.

Jay Beale gave an extremely exciting presentation at Toorcon 9 that I can't stop talking about. His defense strategies (and soon, running code) are available on his ClientVA website. The basic idea behind the concept is to inject a once-a-day HTML iframe that carries RSnake's Master Recon Tool to enumerate browser plugin versions. The iframe injection can be done with airpwn, Ettercap filters, and/or a transparent proxy such as Squid. He also alludes to using similar techniques just by sniffing, digging through log files, and concepts for non-browser clients such as mail clients, and office/productivity applications (although I would add entertainment/creativity applications to this list). For office applications, he suggests using file share scanning combined with Metagoofil, which will scan documents for metadata (which contains MS-Office and similar version numbers) along with MACE "last-modified" file times. Richard Bejtlich presents some great concepts for testing instead of using these as controls that would work well along with this concept.

I've always wondered why router, firewall, or proxy-server vendors haven't included such functionality in their products. Palo Alto Networks is taking on some of the client-side issues, but addressing them a bit differently. I have also heard of Trusteer.com, but do not know of anyone using their products. Some people claim to browse with multiple browser instances or run their browsers in virtualized environments. Microsoft says you'll be fine if you use IE7 under Vista in protected-mode. I think for 2008, we'll start to see protections for client-side attacks start to catch on - but which of these will emerge as the most viable (or money-making) solution is not quite as easily predicted.

Posted by Dre on Wednesday, December 5, 2007 in Defense, Hacking and Security.

Why crawling doesn't matter

This post isn't intended to be a retort to Jeremiah Grossman's post last month on Why crawling matters, but more of a follow-up post to my latest blog entry on Why pen-testing doesn't matter. Hint: both pen-testing and crawling are still important/matter, but my CPSL process described in my last post leans towards a new, idealistic approach on the vulnerability problem.

I've covered web crawling before, in Scraping the web for fun and profit as well as when I mentioned papers written by Shreeraj Shah in my longest-yet post on 2007 Security Testing tools in review. Ajax crawling was only partially covered, so we'll continue to expand on that topic (as well as other topics) in this blog entry. Another motivator for posting information about crawling is that I'm seeing some repeated information over at blogs such as securitytechscience.com/blog -- especially in their latest on Screen Scraping.

Securitytechscience is interesting, because they are trying to build a web application security scanner. In their "Screen Scraping" article, they mention a TBD release of sts-scanner, and the author hints at a future solution for crawling Web 2.0. It will be interesting to hear more about what their solution is, although judging by their language (Ruby), library (Mechanize with Hpricot and/or RubyfulSoup), and available resources (i.e. downloadable source code) -- we can make some assumptions.

Also in the "Screen Scraping" article, the author makes mention that Wapiti is using RubyfulSoup? Maybe I took this out of context, but he says, "Rubyfulsoup is also a very powerful Ruby screen scraping package, offering similar parsing structures like HTree but without the complex XPath query language. I noticed that Wapiti recently incorporated this into its package". I think maybe he means BeautifulSoup, since Wapiti is based on Python. I do fail to understand how XPath is complex, and it's also very rarely slow (notable exception: Selenium Core's XPath expressions in IE are incredibly slow because they are non-native, more detail on this below).

Casey, a tssci-security local, brought up a comment in my post on "Scraping the web for fun and profit" that pointed me to an article on issues with XPath in the Firequark section entitled XPath vs. CSS Selector. While Casey may be onto something using scrapi (even though it is limited to using CSS expressions), this Firequark article appears to be somewhat wrong when it comes to comparing XPath and CSS expressions. Dealing with broken markup is simply something that needs to be dealt with if you're using an application driver. However, it appears that Firequark is browser driven, so while not wrong -- it still fails forward thinking behavior. Firequark (having "fire" in the name, and being based on Firebug) is likely a Firefox add-on, so it will only work in Firefox. Of course, CSS selectors are much slower than the native DOM expressions built into Firefox version 3 (by a lot!) as we'll come to see later in this post.

People who have no formal background in development or quality testing usually refer to protocol drivers as Web 1.0 crawlers and application drivers as Web 2.0 crawlers. Often, Web 1.0 crawlers are "good enough". Assuming there is no Ajax or other active client-side logic, there really isn't a need to crawl with an application driver. Protocol drivers are much less overhead, and therefore can be much faster. Building a speedy Web 1.0 crawler can be best accomplished by using Perl's FEAR::API, which can be even further enhanced by using larbin to provide C++ parallel crawling. This would be nice functionality to include for any web application security scanner.

As mentioned earlier, Shreeraj Shah has some articles on crawling Ajax and Web 2.0. In one article, he uses RBNarcissus (an application driver) for a basic example, and then moves into an extended example using Watir. Watir is a browser driver, but only for Internet Explorer, and only using the Ruby language. Confusingly, I discovered at a Java Users Group meeting that Watij and WatiN both exist, to drive IE from Java and .NET respectively. Firefox functional testers felt left out, so some clever person wrote FireWatir (good name, too) to drive Firefox browsers, but only using Ruby. The thought crossed my mind that it would be better if somebody would write a browser driver that worked with multiple-browsers using multiple-languages, because learning four completely different tools that only drove one specific browser seemed like quite a bit of a learning curve, and wasted time. This doesn't appeal to lazy programmers, does it?

Watir is a part of the OpenQA project, refugee code that escaped ThoughtWorks' Agile and RoR mind-control. Strangely enough, a browser driver that works with all browsers, Selenium Core -- was also developed in a similar path until OpenQA became its home. Not only that, but the Selenium Remote Control project allows tests to be written in Java, .NET, Perl, Python, and Ruby. While XPath expressions would be nice to use, as they are typically faster and cross-language/cross-browser compatible -- XPath using Selenium Core with IE is incredibly slow and often interpreted incorrectly (because it has to rely on Javascript libraries for support) -- so if XPath expressions are used between, say, Firefox 1.5/2/3, Opera, Safari, Camino, etc -- then they must be re-written as DOM expressions for IE3/4/5/6/7. Selenium is additionally limited to support of XPath 1.0 only (no 2.0). Other limitations include the fact that while Selenium groks Javascript, HTML, XML, and text -- it has a problem with parsing other content, including Java applets.

Selenium was based on an older application driver called JWebUnit, which in turn was originally based on HttpUnit. JWebUnit and most other application drivers are now based on HtmlUnit, and all of the history and other detailed information can be read about on this wonderful blog entry entitled HtmlUnit vs. HttpUnit (a must read!). That article has excellent information regarding support of external Javascript libraries, and the author's blog also has updates on new HtmlUnit features.

After playing with RBNarcissus, Watir, and Selenium Core -- it's hard to pick up traction about where to go next (although Shreeraj and OpenQA both led me towards Sahi, I skipped it over as it appeared too similar in its approach to Selenium). HtmlUnit isn't exactly a functional testing tool or approachable as an Ajax crawling solution (at least not just yet). I really liked the Selenium IDE about a year ago, which is a great little Firefox extension. After checking out the NIST SAMATE Web Application Vulnerability Scanners project page, I noticed a link that I hadn't seen before under Free/OpenSource Tools: TestMaker by Pushtotest. After further exploration, I discovered that another tool, TestGen4Web (another Firefox extension, be sure to check out the picture on that page), was capable of translating between HttpUnit, SimpleTest (i.e. TestMaker), and Selenium test cases. Yet I was still looking for something better.

After reading the Jason Huggins' blog (the author of Selenium) one day, he pointed attention towards a new project, WebDriver -- which is basically like using HtmlUnit as a standalone application. The biggest draw to WebDriver is that it not only can act as a very powerful application driver, but also has drivers specifically for Firefox and IE. This provides all the benefits of both application drivers and browser drivers: full browser JSE and plugin support through the browser drivers, while the speed and extensibility of an application driver. After exploring WebDriver, I later learned that Jason Huggins moved from ThoughtWorks to Google, where he built a grid testing system using Selenium RC. Apparently Selenium RC Grid is both very buggy and very cool!

As we proceed through this blog post, I hope that you are following along with what I've learned about crawling the web. The answer is that there is no universal answer. Every web application and security test is different: different size, different code requirements, different tests require different and multiple crawls, etc. So using one method of crawling, or one tool is by definition a bad approach. Crawling is not a "one-size fits all" program that you build. Hence, web application security scanners are inherently flawed because they fail to take different scanning engines into account for different reasons. Note that at least one commercial web application security scanner will allow customization to change it from Depth-first search (DFS) mode to Breadth-first search (BFS) mode, but this is only scratching the surface.

Consider for a second that you are attempting to crawl the "Dark Web". You've been tasked as a security professional to scope out what the bad guys are doing. First of all, you're going to want to protect yourself, maybe get yourself your own hijacked IP and ASN from APNIC and announce them out randomly changing BGP-speaking routers. Unlike phishers, you probably won't need to bother with DNS, so you won't need fast-flux networks except for maybe use in your proxy infrastructure. Your enemy is likely to start figuring out that you are crawling his important terrorist websites and will put up protections. So what works best, DFS or BFS in this situation? Neither, the best answer is to crawl by making yourself look like a legitimate dark guest. A few years ago I attended the LayerOne conference in Pasadena, CA -- where I had the pleasure to meet Billy Hoffman and attend his talk on Covert Crawling.

Covert crawling may not be enough, and if an after-thought may be "too little; too late". Consider wily attackers such as Ronald, who would consider strike-back attacks such as Spidering the Spiders. One of my favorite web application security blogs, Palisade, did a two part article on Dodging the spiders and More on dodging spiders. They also include a lot of great links and resources; I especially like the PDF on Stopping automated attack tools. The legality of crawling (especially crawling with attacks) comes into play, especially during strike-back, but what if you are able to purposefully or accidentally delete an entire site's content? Can a spider enter into a binding contract? This case was debated in a Colorado federal district court in `Internet Archive v. Shell <http://blog.ericgoldman.org/archives/2007/03/can_a_spider_en.htm>`_. Be especially careful when crawling financial institutions, especially if you're verifying a vulnerability in a two-factor authentication system in use for 13 million banking customers i.e. the BofA PassMark/SiteKey service.

Many people I know cite the primary reason for crawling (outside of search engines, which is everyone's obvious first answer) is to simply get an idea of the size and layout of a website. David Kierznowski discusses the benefits and drawbacks of using Microsoft Visio to spider a website on his blog, while Daniel Cuthbert always points people towards Freemind, a mind-mapping tool. My personal answer to this is to just ask the developers to do a walkthrough of the application with you, as they usually have understanding and comprehension of their application in ways that diagrams and mind-maps may never elicit. I often use other tools, services, and Firefox add-ons, such as The Wayback Machine, Netcraft, AboutURL, The Scrutinizer, myIPNeighbors, SpiderZilla, Slogger, Goosweep, Paterva, Googlegath, and Fierce. Sometimes I go really deep and start digging through whois-servers.net, ARIN, RWhois, RADB, and trash cans. Of course this list would not be complete without Johnny Long's `Google Hacking for Penetration Testers <http://isbn.nu/9781597491761>`_, which is about to release a second volume/edition slated by the end of the year. I'm curious to find out if they cover any material on Using Google Analytics to Subvert Privacy or Google Analytics: Now with Stolen Search Queries -- and I also expect to follow up these posts with new material, regardless of how it's covered in the new book.

One of the most impressive spider related hacks I've seen is the Javascript-spider work that pdp put together on his blog. Strangely, John Resig (author of jQuery), thought this was a joke and laughable. Apparently, John Resig had not yet checked out pdp's jQuery extensions such as jQuery Include and jQuery JSON. John and pdp may even share a similar vision of the future, such as The Next Generation of Security Tools will Run from the Browser. For example, dk+pdp announced the Technika Security Framework and continued the Javascript-spider research until it turned into the Yahoo Site Explorer Spider. If only John knew that Javascript spiders could produce stealth XSS, he probably wouldn't have spent so much time Hacking Digg with Firebug and jQuery. Both are masters of this art, as pdp is spending time providing Javascript hacks for web servers in your browser, while John Resig is Bringing the Browser to the Server to provide server-side Javascript (including some screen scraping examples!).

pdp and John Resig have some advanced crawling techniques that are worth additional mention. pdp posted the Top 5 most popular Web2.0 services hackers cannot live without and followed up with another post on 5 generic Yahoo Pipes hackers cannot live without. John also posted information about Selector Speeds and followed up with a post detailing the getElementsByClassName Speed Comparison, leading to additional comparisons on the isobaric blog.

Outside of Javascript, Perl, Ruby, and the aforementioned RBNarcissus, Watir, Selenium, TestMaker, and WebDriver crawling techniques -- there are a few masters of the Python language that have put that language to great use in open-source web application security scanning projects. Romain Gaucher's Grabber project has presented a few innovations such as wwwCall and Website functionalities coverage (et tu, Larry Suto?). Romain also wrote a source code search engine for the NIST SAMATE Reference Datasheet (SRD) called the Python File Indexer, or pyIndex. Andres Riancho of the W3AF project has included one of the only automated Javascript crawlers to inject DOM-based XSS. The Confessions of a Penetration Tester blog has published two W3AF tutorials (Part 1, Part 2) that go over some of its unique crawling features. Andres is also currently working on new methods to execute and analyze Javascript/Ajax, and he is looking at the following three Python modules to accomplish this goal: zope.testbrowser.real (a browser driver), PyXPCOM, and PyKHTML. He also appears to be sold in the concepts of covert crawling and using multiple types of crawls in the W3AF toolchain. I'm very much looking forward to the new versions of both Grabber and W3AF!

This about covers the latest and greatest in web crawling technology. Before you pick a language, scraping module, and begin writing security checks -- let me point you towards one more resource. Courtenay of the Caboose blog released a Ruby-based spider fuzz plugin in February, along with three updates (April, August, and October). This work seems to go beyond that of what Romain Gaucher was working on with his coverage tool, so be sure to take a look and integrate these concepts into your own future crawlers.

I also have an interest in crawling/walking Flash and RIA apps, so if you have any pointers, please do let us know! I know how to extract links ("grep" with swfdump -D or similar), but any further information/ideas would be very useful. Something like the opposite of hxASM (for disassembling from memory) or at least something better than Flare (for decompiling) would be very interesting. The flashsec.org software list is great, but I still haven't found anything that works well for this (AMF logs from Charles, maybe?). Stefano Di Paola has also yet to release the JAMFProxy and SWFRTAnalyzer tools, but according to his OWASP AppSec presentation, the SWF Runtime Analyzer will be made available on the Minded Security website. Looking forward to this and any other innovations in web application crawling!

Posted by Dre on Sunday, December 2, 2007 in Security.

« Newer entries — 19 — Older entries »

blog comments powered by Disqus