Today I finally found the time to release the XAB Proof-of-Concept code. An apology to those of you who have been emailing us wondering when we would publish it. For the time being, it’s hosted at sourceforge and you can download the code from the XAB project page located at: http://sourceforge.net/projects/xab We’ve submitted talks to Black Hat and Defcon for the updates we’re working on, so hopefully we’ll have the chance to catch everyone up, solicit some more feedback, and grab a brew.
Back in November, I had the opportunity to take part in the Great American Teach In. This event takes place at schools around the Tampa, FL area and invites local volunteers to come into the classrooms to teach kids about their job. The objective is to familiarize kids with differing careers and hopefully get them excited so that they do well in school. For my experience, I spoke to a group of 4th graders regarding online safety and security.
Justin and I will be on the Security Weekly podcast tonight to discuss the latest developments with GuestStealer and the Smart Grid book. For more information, check out tonight’s episode guide and join the live discussion tonight. Also, GuestStealer v1.1 is now available for download. This is a bug fix release that improves the error handling and prevention of downloading the same vmdk file twice (when that vmdk self-references itself). Thanks to the efforts by Ron at Skull Security, the new version is available on the tools page.
In addition to the previously mentioned Nmap script, GuestStealer has now made its way into a Nessus plugin and a Metasploit module. Nessus Plugin 44646 was released by Tenable a few weeks ago and the Metasploit module was pushed up to the trunk last week. GuestStealer has been mentioned in several articles and blog posts recently, including DarkReading – Tech Insight: Securing The Virtualized Server Environment and The Hacker News Network.
All Your Public facing Web Apps Are Relevant To Us. I’m going to start off this post with the moral of the story: Good intentions often have bad, unintended consequences. The following is the ‘Testing Procedures’ text of requirement 6.6 from the new PCI DSS v1.2 (source: https://www.pcisecuritystandards.org/security_standards/pci_dss_download.html): For public-facing web applications, ensure that either one of the following methods are in place as follows: Verify that public-facing web applications are reviewed (using either manual or automated vulnerability security assessment tools or methods), as follows:
We’ll be hosting an informal reception at the Hofbräuhaus Las Vegas on Thursday, July 30 to celebrate Tony, Matt, and Jeff’s Black Hat and DEFCON presentations. Please RSVP to rsvp[shift+2]fyrmassociates.com or talk to one of the guys wearing the FYRM Associates shirts at Black Hat. The beer will start flowing at 6 PM and we’ll be around until at least 8 PM.
FYRM Associates is proud to announce our new AppTrust offering that enables organizations to produce secure applications in Agile environments, in a cost-cutting manner. The typical, flawed approach to application security is based on the network security model of “when we find a vulnerability, we patch it.” This forces your organization into a never-ending game of catch-up with attackers that is nothing more than a costly and time-consuming strategic failure.
My abstract for this year’s Black Hat DC was picked up. I’ll be presenting the XSS Anonymous Browser tool, or XAB for short. I’m currently hammering out some of the more technical aspects of the tool, but I’ll have a working proof of concept ready for the conference. Plus if there’s time (who am I kidding?), I’ll release a second tool that is a great defense against the attack vectors that XAB utilizes.
As an industry, we have failed. Miserably. Cyber security professionals have implemented a broken methodology and graduated from failing to properly identify the problem to failing to present an effective solution. The network security methodology of: 1. Find Vulnerabilities, and then 2. Apply Security Patch, simply does not work for the custom web application environment. This statement may seem obvious, but it’s exactly what the industry has tried to do.
I have had many discussions this year regarding the future of the application security industry and even more about its current state. It’s interesting how people of such varying backgrounds will have similarly varying views; this short article is designed to capture those views and hopefully drive some productive discussion as a result. Where are we now? Should be a simple question, right? Let me summarize in three main categories: