SSLv3/TLS Renegotiation Stream Injection</h1> <article> <h1>SSLv3/TLS Renegotiation Stream Injection</h1> <p>matt wood — Mon, 16 Nov 2009 11:00:00 GMT</p> Recently, Thursday 11/5/09, a few folks over on the IETF mailing list went public with a limited Man-in-the-Middle attack on SSLv3 and TLS. There has been quite a bit of press coverage on this issue's severity. However, the way this attack can be used is proving to be more dangerous in specific contexts than at first thought. This vulnerability affects almost every SSL/TLS implementation: IIS (5|6|7), Apache mod_ssl < 2.2.14, OpenSSL < 0.9.8l, GnuTLS < 2.8.5, Mozilla NSS < 3.12.4...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/11/16/ssl-tls-renegotiation-content-injection.aspx">read more</a>) </article> <article> <h1>Top Five Web Application Vulnerabilities 10/27/09 - 11/8/09</h1> <p>mark.painter — Mon, 09 Nov 2009 20:29:00 GMT</p> 1) HP Power Manager Management Web Server Login Remote Code Execution Vulnerability HP Power Manager is susceptible to a remote code execution vulnerability via the login form of the web based management web server due to improper bounds-checking of user-supplied data. Exploitation of this vulnerability can give an attacker the means to enact SYSTEM level commands and possibly lead to a complete compromise of the affected system. Even failed attempts will likely cause a denial-of-service condition...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/11/09/top-five-web-application-vulnerabilities-10-27-09-11-8-09.aspx">read more</a>) </article> <article> <h1>Now Hiring: HP Security Center Pen Tester</h1> <p>mark.painter — Thu, 05 Nov 2009 18:40:00 GMT</p> HP is looking for a qualified Sr. Application Security Consultant that has deep Application Security experience. Consultant should have experience with performing Web Application Assessments, Network Penetration Testing, and be capable of manually exploiting/validating any vulnerabilities identified. In addition to being able to perform security testing the consultant must have strong technical writing skills, so that exploits can be properly documented. Job will also involve implementing HP Application...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/11/05/hp-security-center-penetration-testing-job-posting.aspx">read more</a>) </article> <article> <h1>Take your %00 and shove it</h1> <p>matt wood — Wed, 04 Nov 2009 11:05:00 GMT</p> We've recently been optimizing our Local File Inclusion (LFI) audit engine. Part of that effort has included poking around in different frameworks (php, .NET, java, ruby/rails, python, perl... etc) and seeing how many ways a developer might fall prey to this vulnerability. One of the common ways to leverage this vulnerability is by appending a null byte (%00, 0x00, ASCIIZ), c-style string terminator, to the end of a parameter that might be susceptible to an LFI vulnerability. Sadly, this type...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/11/04/take-your-00-and-shove-it.aspx">read more</a>) </article> <article> <h1>HP Application Security Center at OWASP DC 11/11-13</h1> <p>mark.painter — Tue, 03 Nov 2009 21:26:00 GMT</p> The HP Application Security Center has several presentations at the upcoming OWASP Global Summit In Washington, DC. Ryan English, Rafal Los, Dennis Hurst and Kim Dinerman will all be there. More information about the summit can be found here: OWASP Global Summit . Details concerning each of our presentations follow here: Dennis Hurst at OWASP “ Understanding the Implications of Cloud Computing on Application Security” ( 11/12, 10:30-11:30) Understanding the Implications of Cloud Computing...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/11/03/hp-application-security-center-at-owasp-dc-11-11-13.aspx">read more</a>) </article> <article> <h1>WebInspect Tips: Changing settings to improve scans</h1> <p>todd.densmore — Wed, 28 Oct 2009 19:41:00 GMT</p> Although running WebInspect with ‘out of the box’ scans settings might be the easiest way to start a scan, it is almost sure to produce unexpected results. Configuring any web application scanner is tricky, but by following these simple steps to fine tune the scan more accurate results will be generated. Know your website Performing a manual assessment of your website (before using any tools) will help you quickly spot mis-configured scans, tweak scan configuration parameters, and ensure...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/10/28/webinspect-tips-changing-settings-to-improve-scans.aspx">read more</a>) </article> <article> <h1>Top Five Web Application Vulnerabilities 10/12/09 - 10/25/09</h1> <p>mark.painter — Mon, 26 Oct 2009 21:11:00 GMT</p> 1) TYPO3 Core Multiple Vulnerabilities TYPO3 is susceptible to multiple remote vulnerabilities including SQL-injection, Cross-Site Scripting, information disclosure, frame and session hijacking, and shell-command-execution issues. Each of these issues is exploitable via a browser, although some might require a valid backend login. If exploited, these vulnerabilities could lead to a complete compromise of the application, the theft of confidential information and authentication credentials, hijacked...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/10/26/top-five-web-application-vulnerabilities-10-12-09-10-25-09.aspx">read more</a>) </article> <article> <h1>Organizations are not adequately protecting E-health records</h1> <p>mark.painter — Fri, 23 Oct 2009 20:09:00 GMT</p> The American Recovery and Reinvestment Act of 2009 (aka the stimulus package) included funds to both implement electronic health records and rules to specifically improve personal health information breach notification rules. It’s ironic, then, that the rush to digitize personal health information didn’t include implementing security. A recent survey of IT managers involved in healthcare revealed that 80% had suffered at least one incident or more of lost or stolen health information...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/10/23/organizations-are-not-adequately-protecting-e-health-records.aspx">read more</a>) </article> <article> <h1>Automated Security Testing - Can't I Just Point-n-Click? (Part 3)</h1> <p>RafalLos — Fri, 16 Oct 2009 21:49:00 GMT</p> <p> So now that you've got the background from my other 2 posts in this series, you know the options and you have some background. Let's talk about the limitations of technology and why your brain is still required to do your job. Many folks continue to try and push the boundaries of technology, and while I applaud this effort greatly, I for one can't see <em>us security analysts</em> ever being replaced entirely by technology as some would have you believe. The analytical mind still trumps technology ... although I think there are some limitations based on levels of experience, etc. Read on for more ...</p> <ul> <li><strong>Technology & Automation's Limitations</strong></li> </ul> <p style="padding-left:30px;">Let's face it, there are some very serious limitations to technology today, even in the product-filled world of web app security. I think you will probably agree that there are many products that solve non-existant problems ... or what I would refer to as "brilliant solutions without purpose"... but we'll save that conversation for another time. Right now if we look at automation logically we can simply state that automation ,more specifically software, has its limitations at pattern-matching, for the most part (more in a minute). Immediately we can say that pattern-matching is a severe limitation to any technology, just look at the failed anti-virus installation on your computer. Does it protect you from every strain of every virus? what about new malware? Of course not ... that's why everyone pretty much agrees anti-virus in present form is a dead concept. Moving this into the web app sec world we can easily say that pattern matching is next to impossible when you look at static analysis (analysis of source-code) because thanks to the brilliance of the human mind we all do things just a little bit differently. To prove the point, ask 10 developers to write the same piece of code, even a simple function, you <em>may</em> find 2 that are the same ... maybe.</p> <p style="padding-left:30px;">Static analysis is particularly difficult from the perspective of automation, although there are great attempts out there I will acknowledge, because you're dealing with code. As I've written previously static code analysis has enough of a hard time with dealing with producing theoretical vulnerabilities, much less trying to understand every developer's code. This is why there is no such thing as an "out of the box" tool that works on static code analysis. Let's be logical about it ... your "sanitization" function can't possibly be anticipated by the tool you just bought to analyze your code ... and while the tools available can make attempts to "learn" the way your developers code, and what functions are safe, which are scrubbers, etc in the end it's just hours and hours of "tuning" that require ... ta-da ... human intervention!</p> <p style="padding-left:30px;">Taking the case to dynamic analysis doesn't make it any more pretty. Again, here we're pattern-matching against expected outcomes to "negative testing". We push javascript (such as the ever-popular pop-up) into a form field and expect it to come back to the browser in the same way that it was sent and execute a pop-up. Then we can determine that it's a vulnerability... right? It's not that simple though - because when you look at code coming into the browser you have to analyze the <em>context</em> it's being piped into! If you're pushing code you have to make sure it will actually execute first ... which is the challenge. Next, for your consideration think about how we test for database manipulation (SQL Injection). We send database command syntax appended or injected into the regular application fields to try and elicit a database response. Of course ... if the developers suppress databse responses to the end-user this makes it very difficult to detect injection when it's "incorrect"... Concepts like Blind SQL Injection are even more tricky because you're injecting database commands and not expecting a direct response but a change in page-state, or a positive/negative response which is also extremely difficult to script and contextualize. You'll notice that a lot of this comes back to context and while software can do catagorization pretty efficiently a la pattern matching, it's impossible to account for all possible states, responses and configurations. Yikes! This is all enough to make your head spin!</p> <p style="padding-left:30px;">I certainly don't envy those developers who are writing security analysis tools, and I can tell you first-hand that the folks that work in our HP Web Security Research Group are absolute geniuses. Scripting and pattern-matching gray-area responses is like walking a tightrope between false-positives and false-negatives ... and remember that no matter what you do people will attempt to discount the tools you build because they're either too noisy, or miss too much. This is especially why I am so big on human interaction in the process! </p> <ul> <li><strong>Your Brain Required</strong></li> </ul> <p style="padding-left:30px;">Now we get to it ... your brain will continue to be required for the forseeable future in security, more specifically the analytical part of web app security. While technology and innovation will continue to drive better and "smarter" engines for analyzing and attacking web applications, my crystal ball tells me that people will always be necessary. Actually, not just people. People with a clue will always be necessary - there is a huge distinction! Let's venture into why [intelligent] humans are necessary, and why anyone selling "a point-n-click" security tool should be laughed out of the building. You see, people build software. Even the smartest people make mistakes. Therefore, even the best software will have mistakes which often manifest themselves as security vulnerabilities. Given that, why would you trust the analysis of this <em>potentially</em> vulnerable software with more<em> potentially buggy</em> software? Make sense yet?</p> <p style="padding-left:30px;">Software-based testing, even software-driven testing is fine as long as there is someone who is schooled and reasonably accomplished in the art and science of interpreting results and analyzing them. What is required here is a 2-step method we like to refer to as "validation" of findings. You see, automated tools continue to get better at finding more and more complex defects yet the analysis of findings will always be the trickiest part of a security testing strategy. Looking at what an program/script/tool has uncovered and being able to critically deduce whether this is a positive vulnerability, a false-positive, or whether it simply requires more attention is critical to a security analyst's position and job description. The power of the human mind often kicks in where software leaves off, and can trigger a multitude of findings that would otherwise go undiscovered.</p> <p style="padding-left:30px;">A great example of this type of need for a human analyst is from a penetration test I was a part of a while back. The automated tool uncovered a treasure trove of low-hanging vulnerabilities including some cool SQL Injection and Cross-Site Scripting issues, as well as a crossdomain.xml issue that was pertinent to our attack. On their own these attacks could do some damage but it wasn't until the analyst actually dug into these attacks and noticed that they could be chained together to produce an incredible attack vector that there was (at the time) no solution for! You see, we could test for XSS, and SQLi, and even the crossdomain.xml vulnerability ... but the software couldn't string those together and notice a gaping flaw in the <em>design of the application</em> that allowed for a complete compromise of the online application.</p> <p>So the bottom line here is that I want you to walk away from this series being able to not only understand but intelligently speak about why a "point-n-click" security testing tool will never suffice, and why you have to have the human intellect to back it. That being said, there are a number of offerings such as HP's Web App SaaS offering which mix the automation and tools approach with an augmentation of the human factor for when you find yourself in a situation where you just don't have the in-house expertise! What I'm saying is don't trust your web application security to a tool, or even a collection of them - because alone they aren't telling you the whole picture. Throw away the notion that you can just point and click your way to being secure ... it's never going to happen that way.</p> <p>The answer then? Education, first and foremost, is key. Make sure you either educate or hire smart & intelligent security analysts. Make sure that you have people who understand how attacks work, why they work, and how to detect them manually. Your analysts should be able to spot basic attacks like SQLi and XSS in a site by hand, and execute (or know where to get cheat-sheets for) the more complex attacks. You don't have to hire the uber-hax0r, just know enough to call one when you need one. The next thing is to ensure you've got the best tools in your toolbox... often this means mixing open-source and closed-source apps together into something that works best for you. Know your applications and which attacks apply ... PHP-style attacks certainly won't work against IIS-based ASP.Net apps ... usually. Be ready to raise your hand when you're in over your head. There's no shame in asking or acknowledging when you don't know ... I do it all the time and it's quite liberating.</p> <p>I hope I've managed to convince you that point-n-click security is a failed prospect. What do you think? If you're interested in a further conversation please feel free to email me (via this blog) or get a hold of me through your HP sales rep (you probably already have one!)</p><div style="clear:both;"></div> </article> <article> <h1>Automated Security Testing - Can't I Just Point-n-Click? (Part 2)</h1> <p>RafalLos — Fri, 16 Oct 2009 17:06:00 GMT</p> <div> <div> <div>In the previous post - I tackled the question of automation, full automation, in web application security testing. We discussed the problem in great detail and underlined some of the issues that we will need to address and understand. In this post, I'm going to talk through the options and technological limitations that we face today and will continue to face deep into the future.</div> <div></div> <div> <ul> <li><strong>The Options</strong></li> </ul> <p style="padding-left:30px;">If you're going to attempt to test web applications with some measure of automation there are a few options you have available. There are full and partial automation opportunities, and application separation as well as multiple tools. Addressing them in order here...</p> <p style="padding-left:30px;">Full automation is what most people still think of when it comes to security testing their web applications. Full automation involves simply putting a URL into a field and clicking GO and standing back to watch the action. There are times when this is practical but there aren't many of those times, unfortunately. I've spoke with many folks recently who feel that web application security testing should be done like vulnerability scanning was when it first kicked off. Point, click, and receive results. This isn't practical because of the fact that there are many possible ways that this option can fail. Sadly, the less people understand the more they want to push into full automation. Let's think about full automation for a minute. In order for a tool to be able to perform a fully automated scan you have to assume that the tool can analyze site structure and compute an attack strategy on the site without human intervention. Forget that you're asking a whole lot from a computer program ... think about what that actually <i>means</i>. You'll be asking the tool you're using to be able to understand every part of the application ... fully. Can you say you can understand every part of the applications you test fully? Remember software is only as good as the people who write it, and unfortunately the people who write testing software can only make it as good as the examples they have to work with. Herein starts to peek a problem we'll address later ... mounting complexity. Full-on automation requires that the tool analyze every AJAX call, every FLASH object, every piece of JavaScript, every nook and cranny and every workflow through the application. If you're heard me talk about the failure of automation on the frontier of workflows you already know why this is such a losing proposition without human automation - but it gets more complex than that. You're hoping that the automation component can do all the work in a pre-defined amount of time, right? Let's be realistic, most automated tools, if not properly tuned will run for days, hours or weeks before running themselves out of memory of stack space - hopefully completing the scan. The reasons this happens I will address later on in the technical limitations but you're asking an awful lot of software that's testing software. Say you do get a complete scan. Say for the sake of argument that the tool you're using manages to completely cover the web application attack surface and finds a whole mother-lode of vulnerabilities. What you're saying now is that you want that same piece of automation (or software) to be able to validate its own findings. Fail. You already know that automation isn't perfect at finding vulnerabilities ... and now you want validation for the same price? Consider that ask...</p> <p style="padding-left:30px;">Partially manual testing is the next logical choice. Involving the human being as little as possible but still allowing for some intervention to do the set up and validation makes logical sense. The problem here is that the human being here has to understand what he or she is doing otherwise this process fails. Integrating a human being into web application security testing is a scary thing ... because now you're asking a human being to complement the software you're using but it certainly has its advantages. In fact, I would argue that it's better to have a human involved than to attempt to do everything with automation as you'll get better results 4 out of every 5 times. The problem is in the human part of this equation. Knowing what you're doing ("I'm testing a web application's security") and actually <i>knowing what you're doing</i> are drastically different. You also have to be trained in the tool you're using otherwise you'll fail with even more vigor. But here's the deal, partial automation involves the human being (tester) interfacing with the tool in order to provide it not only analytical insight but also guidance on what to test, what variables to use, what to tweak and what to avoid ... then analyzing the results. This is what most knowledgeable penetration testers and web application security <i>experts</i> do today with varying degrees of success. Don't let anyone fool you, it's a lot tougher than you'd think to get results particularly when they have to be consistent! Tweaking a piece of software and using it like a sledgehammer to find the low-hanging fruit is fairly easy ... getting deeper and better results than the tool could do on its own is a little more tricky. Lots of testers simply never master this craft and either end up blaming the tool, or simply giving up. Partially automating a testing tool, particularly one that's built to do evil, is an art-form and must be well-understood or the results could not only be catastrophic, but also inconsistent and more dangerous than when the tool is run fully automated.</p> <p style="padding-left:30px;">Your other option, of course is do testing in a partially automated way. What you probably don't know is that tools like WebInspect can function in this capacity brilliantly. "Penetration tester assistance mode" is what the folks who do this all the time call it. As the penetration tester looks at different areas of the site a black-box scanning tool is used surgically, with a large amount of human guidance. This use-case really isn't a human being assisting an automated tool as much as an automated tool is used as a supplement to the human being's abilities to do the mundane and simple tasks. Furthermore, more advanced tasks can be performed such as advanced XSS or SQLi testing within the framework of the tool so the tester doesn't have to do it by hand. Using the tools as an extension of the tester is a great way for someone advanced in the art and science of breakage to function ...but that expertise has to be there first. You can't just jump feet-first into this type of usage model and expect to succeed.</p> <p style="padding-left:30px;">So there we have it, 3 possible ways to engage in "automated" testing tools, a la black box security testing. The thing you must think about is which one is right for the situation you find yourself in, your knowledge level and experience, and specific use-case. What works for one may not work for others, your mileage may vary, batteries not included and some assembly is required.</p> <p> </p> </div> </div> </div> <div></div><div style="clear:both;"></div> </article> <article> <h1>Automated Security Testing - Can't I Just Point-n-Click? (Part 1)</h1> <p>RafalLos — Fri, 16 Oct 2009 16:14:00 GMT</p> <p>I've been witness to an interesting phenomena. Several otherwise rational folks- customers, prospective customers, and pundits alike - have posed the question to me now over a the last several months. I've been thinking a lot about the topic and have some thoughts I think it's time I share.</p> <p>The question for discussion is this: "<i><strong>Shouldn't a security testing tool (Web App security, black-box specifically) be able to just accept a URL and credentials and test my site, providing results without me having to intervene?</strong></i>"</p> <p>The answer, quite simply is an unabashed "<strong>No</strong>"... but I think it needs more of an explanation than that. It's often all too simple to provide an answer without explanation; or worse with an explanation that not everyone can understand, so I'll both answer the question, explain it in detail and give some real-life examples of why I'm answering this way. Grab a cup of coffee, get comfortable and let's think this through rationally together. I'm going to do this as a multi-part blog entry ... I can already see this as taking a few hours to write much less to read and fully comprehend... </p> <p> </p> <ul> <li><strong>The Main Issue</strong></li> </ul> <p style="padding-left:30px;">The main issue in question here is not whether computers can replace humans entirely for security testing - which I hope we can all agree on is a solid <i>no</i> but whether computers and automation has come far enough to begin test automation to a point where a human can provide minimal input and have a test complete. The problem with this request is that we're asking automation to <i>make decisions</i> within the process of testing. Decision making, so far in evolution, is best left to the human analytical brain, rather than automation - and the primary rational is here is that humans possess the ability to reason rationally whereas computers ... cannot. At the core of the question is the ability to make decisions or <i>reason</i> which then either makes or breaks an automated test. Let's think about this in a different light... let's look at this from the viewpoint of a mechanic. What we're really asking here is for a computer to hook up to the vehicle, diagnose the entire system without human input and then provide a solution, testing the effectiveness without a human in the loop. Rationally we can already see where this would break down. A computer can hypothesize a problem, apply a solution successfully without actually solving the problem the driver had in the first place. Diagnosing a problem in a vehicle, as mechanics will tell you, is more than just something you can do from a text-book, or by taking a course. It takes years of experience to understand vehicular cause and effect, and why a rattle in the front of the car may actually be a bad bearing in your rear wheel... computers can't tell you these things, yet. The other issue here in the mechanical world is that not everything can be connected to a computer system for diagnostic yet - there are still limitations. The problem can be easily extended to the digital world for web applications. Not everything can be analyzed properly and we'll go into more detail in a minute for why that is.</p> <p style="padding-left:30px;">Bringing this back to the question at hand and whether automation can simply "do the job" of assessing a web application's security viability ... we have to break the issue down into its bare components to further analyze. First, there's the identification and site functional analysis ... typically we call this the "crawler phase" or "discovery phase" depending on which tool you're using. Crawling the site (or application) means clicking buttons, inputting data, and traversing the site all while building a <i>virtual map</i> of what the site looks like, what the option trees are, and how traversal through the site is done <i>legally</i> without attempts to subvert the site. The next major step is the pre-attack analysis - whereby the tool attempts to build the attack sequences and tree for how the site will be attacked. This type of phase generally involves a lot of heavy memory and processor usage and building incredibly large and complex data structures (generally in machine memory). Once this is done the attack sequence can begin. Once the tool is confident that all attack patterns and plans have been laid out, the attacks are launched and the tool starts to do the heavy lifting it was built for. Inevitably during the attack process something <i>new</i> is discovered. Whether at attack pattern triggers some new function, or something breaks in a beautiful way ... the system has to put that newly found functionality back into the control-stack of the application for re-analysis and another pass. The tool will continue making the <strong>start</strong> -> <strong>discover </strong>-> <strong>attack-build</strong> -> <strong>attack</strong> -> <strong><i>repeat</i></strong> loop over and over as long as new things are discovered... until there is nothing new left on the discovery stack. Once the tool reaches that state it can be understood that the attack and discovery phases are complete and the tool moves to a final attack-analysis phase. At this point it will have to correlate, verify and validate the findings from throughout the process to make sure that there aren't any issues with these findings. The last step is to present it to the requester via a report. Whether the report is a dashboard, a PDF, or exposted XML or CSV the reporting piece is usually pretty standard and well understood. Having this process completely self-contained and automated is what some people seem to want - and I'm here to tell you that's a dangerous thing to ask for.</p> <p style="padding-left:30px;">So now that we have the problem identified ... let's go talk about what options we have, why people are required and doing this completely in an automated fashion is a bad, bad idea.</p> <p style="padding-left:30px;">...</p> <p> <i>There you have it ... the problem is now identified, unmasked, and ready to be discussed in detail. The upcoming post will detail some of the options we have for solving this issue and what technological limitations we are faced with today, and into the future. The last post in this series will go deep into the reasoning for why I continue to say that your brain will always be required. Until next time!</i></p><div style="clear:both;"></div> </article> <article> <h1>Is Anybody Listening?</h1> <p>RafalLos — Thu, 15 Oct 2009 16:22:00 GMT</p> <p>Greetings, I am finally back home after an exhausting trip which had me speaking at 2 conferences back-to-back in separate countries and on opposite side of the coast! I did learn some valuable lessons from speaking at these two wildly different conferences thought, so I thought I would share them with you here for your benefit too.</p> <p>First off, the Information Security conference I attended on Tuesday in Toronto called "<a target="_blank" title="SecTor Presentations" href="http://www.sector.ca/presentations">SecTor</a>" was brilliantly run and targeted towards Canadian-based information security professionals and wanna-be security professionals. It's OK to say it, there are plenty of people that attend these conferences who are looking to break into the business and want to learn about information security enough to get a grounding of what the industry is about... so they attend these conferences. My talk "When Web 2.0 Attacks" was well-attended and I even had some big names in my audience (thanks to RSnake, Hoff and a few others that wandered in and out) and I think the overall impression was that the stuff I presented was relevant to people's daily lives in Information Security. That's kind of the problem though...</p> <p>You see, while I ordinarily wouldn't think twice about educating those in my field ... someone that's been doing this for a while longer than I reminded me a while back that this is what we would call "preaching to the choir". Sure, I tend to agree that even within Information Security not enough people understand Web App Sec well enough to build a program and actually reduce any real risks - but those folks have been hearing this talk for years upon years right? At some point I'm bound to hit the law of diminishing returns; and furthermore, people who didn't agree with me 6 months ago aren't likely to agree with me today. Great conference, great mind-share but it's definitely time to reach a broader audience.</p> <p>That's where the next conference I spoke at comes in. Wednesday morning, at 4:00am Central time (yea, AM) while some of my colleagues were stumbling into their hotel rooms in downtown Toronto I was hopping into a car and being driven to the airport to head out west. My destination was Anaheim, CA where I would speak at StarWest later that day. I'm still not sure how through the delayed flight, sickness, and almost-missed connection I made it out to the West Coast by 2pm, but I did... and Star West was awesome.</p> <p>StarWest (run by the SQE folks (<a target="_blank" title="SQE Homepage" href="http://www.sqe.com">www.SQE.com</a>) is nicely put together and serves an entirely new audience of people. Here at StarWest (although I did find it strange that we were in the heart of DisneyLand!) the audience was almost entirely composed of software test engineers, managers and those related to the field. This was a completely different set of ears than what I'm used to ... this was a good thing.</p> <p>The first thing I heard when I put my welcome slide up was "Hey, isn't security supposed to be done by the security people?" Love it. This is exactly the mentality and walls I was there to break down. I think as we went through the hour-long session on "Detective Work for Testers..." I managed to convince a few people in the audience that their jobs were closely tied to mine in Information Security. Maybe, maybe not. The bottom line is that there were many great folks who came up to me and talked afterwards and through the end of the conference about the absolutely missing component in their SDL that was security. I had one lady in the audience (although she fled before I could get more out of her, and had to track her down myself later on the show floor) tell me that her security team <strong>is</strong> the developers and that because they tell the bosses that they don't have security issues no one ever tests the code. I wish I could recall where she worked, hopefully no place important like a bank or anything ...</p> <p>The point is - this was the right audience. If you were there and came to my talk, awesome! If you missed it, slides are posted and we can talk about it whenever you have some time.</p> <p>Do you believe that Information Security and Software Quality testing is one and the same? Do you believe that a quality defect may as well be a security defect? Can you successfully explain the difference between a security and quality bug?</p> <p>... I'm fairly sure I have my target audience for the next foreseeable future. Listen up quality testers - I'm coming to a conference near you!</p> <p> </p><div style="clear:both;"></div> </article> <article> <h1>Top Five Web Application Vulnerabilities 9/28/09 - 10/11/09</h1> <p>mark.painter — Mon, 12 Oct 2009 20:12:00 GMT</p> 1) Juniper Networks JUNOS J-Web Multiple Cross-Site Scripting And HTML Injection Vulnerabilities Juniper Networks JUNOS is susceptible to multiple Cross-Site Scripting and HTML Injection vulnerabilities. Successful exploitation of these vulnerabilities could be used to alter how the site appears, steal authentication credentials, or execute malicious scripts in the browsers of unsuspecting users. A fix has not yet been released. Contact the vendor for additional information. http://www.securityfocus...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/10/12/top-five-web-application-vulnerabilities-9-28-09-10-11-09.aspx">read more</a>) </article> <article> <h1>85% of IT security decision makers think successful external attacks very unlikely</h1> <p>mark.painter — Fri, 09 Oct 2009 19:19:00 GMT</p> A new report this week from ITC reveals that eighty-five percent of IT security decision makers think that losing data via an external threat is "very unlikely." Wow. Once upon a time, anyone involved in application security had a need to educate potential customers on why application security was important. You remember. It's not the network layer anymore...the application layer is where the attacks are occurring. That hasn't changed. It's one thing to think that your internal...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/10/09/85-of-it-security-decision-makers-think-successful-external-attacks-very-unlikely.aspx">read more</a>) </article> <article> <h1>Budget pressures still leading to increased risks</h1> <p>mark.painter — Mon, 05 Oct 2009 19:21:00 GMT</p> The Independent Oracle Users Group (IOUG) just released a database security survey of their members. As we've recently seen a lot, budget pressures are once again leading to increased risks. Organizations know there is a problem, understand it's getting worse, yet don't have the budget or resources to fix it. For instance, database breaches grew by 50% from last year to this. That's not a slight increase by any standard. Yet, the demand to do more with less has kept pace with the...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/10/05/budget-pressures-still-leading-to-increased-risks.aspx">read more</a>) </article> <article> <h1>SecTor - Meet n' Greet</h1> <p>RafalLos — Tue, 29 Sep 2009 22:54:00 GMT</p> <p>Hey everyone ... I thought I'd consolidate all the thoughts around the SecTor Tweet-Up that have been floating around Twitter (via SecurityTwits and myself) into a single blog post... so here it is...</p> <p><strong><span style="font-size:medium;">When</span></strong>: Tuesday, October 6th at 10:00pm local time<br /><strong><span style="font-size:medium;">Where</span></strong>: The Loose Moose (Google it) - <span dir="ltr" id="adr" class="adr"><span class="street-address">146 Front Street West</span>, <span class="locality">Toronto</span>, <span class="region">ON</span> <span class="postal-code">M5J 1G2</span>, <span class="country-name">Canada</span></span>‎ - <span dir="ltr" class="nw"><span class="tel">(416) 977-8840</span></span>‎<br /><strong><span style="font-size:medium;">Who</span></strong>: Everyone who's attending SecTor (or not) that's involved in Web Application Information Security (or security in general)<br /><strong><span style="font-size:medium;">Why</span></strong>: Meet me, and possibly Dennis Hurst of Hewlett Packard's Application Security Center ... and meet other InfoSec people!</p> <p>There you have it. Nothing formal ... just come and meet... talk and have a good time!</p> <p>Also.... <strong><span style="font-size:large;">my talk is on Wednesday</span></strong> ... </p> <p><strong>Time</strong>: 10:45 - Noon<br /><strong>Room</strong>: 203-D<br /><strong>Title</strong>: <span><em><strong>“</strong>When <span class="yshortcuts">Web 2.0</span> Attacks: Understanding Security Implications of AJAX, Flash and ‘Highly Interactive’ Technologies”</em></span></p> <p> ... see you at <a target="_blank" href="http://sector.ca" title="SecTor Homepage">SecTor</a>!</p><div style="clear:both;"></div> </article> <article> <h1>Top Five Web Application Vulnerabilities 9/14/09 - 9/27/09</h1> <p>mark.painter — Mon, 28 Sep 2009 20:43:00 GMT</p> 1) Novell GroupWise WebAccess Cross-Site Scripting Vulnerability Novell GroupWise WebAccess is susceptible to a Cross-Site Scripting vulnerability. An attacker can leverage this vulnerability to execute script code in the browser of an unsuspecting user in context of the affected application, possibly leading to theft of authentication credentials and other attacks. Updates which resolve this issue have been released. Contact the vendor for additional information. http://www.securityfocus.com/bid...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/09/28/top-five-web-application-vulnerabilities-9-14-09-9-27-09.aspx">read more</a>) </article> <article> <h1>60% of Internet attacks now conducted against web applications</h1> <p>mark.painter — Fri, 25 Sep 2009 14:57:00 GMT</p> New studies have gone a long way in confirming that certain web application security trends are accelerating. The SANS Top Cyber Security Risks report reveals that a full 60% of Internet attacks are now conducted against web applications. It's no longer unpatched operating systems that provide attackers with their main point of entry. In fact, patches for known flaws in operating systems are installed twice as fast as those for web application security vulnerabilities. Apparently, there are so...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/09/25/60-of-internet-attacks-now-conducted-against-web-applications.aspx">read more</a>) </article> <article> <h1>Is your .svn showing (like 3300 other sites)?</h1> <p>Chris Sullo — Thu, 24 Sep 2009 15:13:00 GMT</p> TechCrunch has an article (pointing back to a Russian security company blog post (translated link)), detailing a scan of 2,253,388 web sites which yielded an amazing 3,320 Subversion's .svn directories. In case you're you're not familiar with Subversion, it is a version control system similar to CVS. It's .svn directory is likely to have a wealth of information for attackers--account names of developers, change histories, and the most importantly, full copies of source code which...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/09/24/is-your-svn-showing-like-3320-other-sites.aspx">read more</a>) </article> <article> <h1>%3c has always been a friend of mine</h1> <p>billyhoffman — Thu, 17 Sep 2009 15:59:00 GMT</p> Ask a developer what's the ASCII code of "A" and most should be able to tell you 65. The good ones will tell you 0x41. If you ask them they should be able to tell you some more off the top of their head. Space... 32, quote... 34, "a" ... 0x61 (I can never remember the base 10, hex was just easier for this). This isn't the coding equivalent of silly or pointless information like knowing all the Vice Presidents. Most developers have learned various ASCII codes over the course...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/09/17/3c-has-always-a-friend-of-mine.aspx">read more</a>) </article> <article> <h1>The Dangers of a Disaster-Driven Security Program</h1> <p>RafalLos — Thu, 17 Sep 2009 15:27:00 GMT</p> <p><span style="font-size:10pt;color:black;mso-ascii-theme-font:minor-latin;mso-hansi-theme-font:minor-latin;mso-bidi-font-family:Arial;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:small;"><span style="color:#000000;"><span style="font-size:x-small;"><span style="background-color:#ffffff;"><span style="font-size:small;"><span style="background-color:#808080;"><span style="color:#ffffff;"><span style="background-color:#333333;">Reality check... at least 30% of the customers I have worked with this year use a "disaster-driven" security program.</span></span></span></span></span></span></span></span></span></span></p> <p><span style="font-size:10pt;color:black;mso-ascii-theme-font:minor-latin;mso-hansi-theme-font:minor-latin;mso-bidi-font-family:Arial;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:small;"><span style="color:#000000;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:x-small;"><span style="color:#000000;"><span style="background-color:#ffffff;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:x-small;"><span style="background-color:#ffffff;"><span style="color:#000000;"><span style="font-size:small;"><span style="background-color:#808080;"><span style="color:#ffffff;"><span style="background-color:#333333;">Yes, it means exactly what you think. Nothing gets done, nothing gets approved until there is definitive proof that the $company has been hacked, stolen from, or otherwise compromised.</span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></p> <p><span style="font-size:10pt;color:black;mso-ascii-theme-font:minor-latin;mso-hansi-theme-font:minor-latin;mso-bidi-font-family:Arial;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:small;"><span style="color:#000000;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:x-small;"><span style="color:#000000;"><span style="background-color:#ffffff;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:x-small;"><span style="background-color:#ffffff;"><span style="color:#000000;"><span style="font-size:small;"><span style="background-color:#808080;"><span style="color:#ffffff;"><span style="background-color:#333333;">While we as security professionals often joke that this is the best way to make our point and get budgetary consideration - this is actually a very poor way to run things! Why you ask? Let's analyze this situation. There are many dangers to being reactionary and jumping on the emergency du-jour... not the least of which is money waste, catastrophic loss, and resource confusion and absolute loss of direction. I think it's best if we address each of those points individually to make everything nice and clear.</span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></p> <p><span style="font-size:10pt;color:black;mso-ascii-theme-font:minor-latin;mso-hansi-theme-font:minor-latin;mso-bidi-font-family:Arial;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:small;"><span style="color:#000000;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:x-small;"><span style="color:#000000;"><span style="background-color:#ffffff;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:x-small;"><span style="background-color:#ffffff;"><span style="color:#000000;"><span style="font-size:small;"><span style="background-color:#808080;"><span style="color:#ffffff;"><span style="background-color:#333333;">It would <em><span style="mso-ascii-theme-font:minor-latin;mso-hansi-theme-font:minor-latin;mso-bidi-font-family:Arial;">almost</span></em> seem logical to only spend money when things go wrong- that way you know where your weakness is and you can patch the things that are broken. After all, you don't buy new tires because you <em><span style="mso-ascii-theme-font:minor-latin;mso-hansi-theme-font:minor-latin;mso-bidi-font-family:Arial;">think</span></em> you'll be getting a flat, right? You buy a new tire when the old one blows out, or wears too thin. Same with the hot-water heater, your roof and pretty much anything else in real-life... There are serious logic flaws in that thought process. First off, we all know it costs many, many more pennies to "clean up" after a disaster than it would have taken to avoid the disaster in the first place... hrmm... or do we? You see, falling into this mental trap is easy... putting together the right logic to avoid it is quite difficult. </span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></span></p> <p class="MsoNormal"><span style="font-size:10pt;line-height:115%;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:small;"><span style="color:#000000;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:x-small;"><span style="background-color:#ffffff;"><span style="color:#000000;"><span style="font-size:small;"><span style="background-color:#808080;"><span style="color:#ffffff;"><span style="background-color:#333333;">Let’s first talk through how you would measure these options, in order to provide empirical evidence.<span style="mso-spacerun:yes;"> </span>The important thing is to measure events which would be relevant to your business and model.<span style="mso-spacerun:yes;"> </span>So if you’re an industrial company, with very little web presence trying to substantiate the need for site security… good luck.<span style="mso-spacerun:yes;"> </span>Measuring involves accumulating the costs, all of them, of a disaster-driven approach.<span style="mso-spacerun:yes;"> </span>Inclusive costs would be things such as data-breach notification, legal fees, productivity loss, projected consumer confidence loss and other things that are very <i style="mso-bidi-font-style:normal;">soft measurements</i> … again making the empirical approach difficult here.<span style="mso-spacerun:yes;"> </span>Whether you do your own research or trust industry models – you will likely come to the conclusion that fighting fires with band-aids is more costly than being proactive… guaranteed.</span></span></span></span></span></span></span></span></span></span></span></span></p> <p class="MsoNormal"><span style="font-size:10pt;line-height:115%;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:small;"><span style="color:#000000;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:x-small;"><span style="background-color:#ffffff;"><span style="color:#000000;"><span style="font-size:small;"><span style="background-color:#808080;"><span style="color:#ffffff;"><span style="background-color:#333333;">The next important point against disaster-driven security is that catastrophic loss.<span style="mso-spacerun:yes;"> </span>Since I often liken InfoSecurity to life insurance let’s take that approach.<span style="mso-spacerun:yes;"> </span>We all know you can’t buy life insurance after the patient has crossed that line… I think we can all agree on that.<span style="mso-spacerun:yes;"> </span>The same is for security… sure you can beef up your defenses after a major disaster in security – but the damage is done!<span style="mso-spacerun:yes;"> </span>Whether you’re now dealing with untrusting customers or partners… you’ve got a tough hill to climb to win over those people again.<span style="mso-spacerun:yes;"> </span>This of course is completely ignoring how brutal the media can be… and then there’s the “Social media” that is merciless as well… Giving a press interview saying “Yes, we did everything we could pro-actively and still got breached” is much different than “Well, we were defenseless, but at least we’ll be ready for the same attack next time!”… obviously.<span style="mso-spacerun:yes;"> </span>Catastrophic loss leads to internal turmoil, profit shrinkage, people losing their jobs… and all sorts of nasty things… trust me, I know first-hand.</span></span></span></span></span></span></span></span></span></span></span></span></p> <p class="MsoNormal"><span style="font-size:10pt;line-height:115%;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:small;"><span style="color:#000000;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:x-small;"><span style="background-color:#ffffff;"><span style="color:#000000;"><span style="font-size:small;"><span style="background-color:#808080;"><span style="color:#ffffff;"><span style="background-color:#333333;">If you’re ever been a part of a data-breach or worked for a company that’s been hacked you know how difficult it is to work in that environment.<span style="mso-spacerun:yes;"> </span>Having leadership which either “follow the trends” or are “disaster-driven” means you’ll never actually successfully complete a project start to finish.<span style="mso-spacerun:yes;"> </span>This is true because odds are you start to plan, maybe even get into implementation before something strikes and you’re forced to drop everything and go do something else.<span style="mso-spacerun:yes;"> </span>Without continuity in your work life it gets confusing and you start to lose your place, projects are forgotten, and there is a lot, and I mean a lot of wasted everything.</span></span></span></span></span></span></span></span></span></span></span></span></p> <p class="MsoNormal"><span style="font-size:10pt;line-height:115%;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:small;"><span style="color:#000000;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:x-small;"><span style="background-color:#ffffff;"><span style="color:#000000;"><span style="font-size:small;"><span style="background-color:#808080;"><span style="color:#ffffff;"><span style="background-color:#333333;">Lastly, we address “loss of direction”… which at this point should be a self-evident outcome.<span style="mso-spacerun:yes;"> </span>When you’re chasing fireflies it’s very simple to run off the pier, since you’re looking not at where you’re going long-term but at all the pretty shiny lights all around you lighting up and dying off. <span style="mso-spacerun:yes;"> </span>Imagine, just imagine, if you had to chase one emergency after another.<span style="mso-spacerun:yes;"> </span>Imagine what that would do for your ability to resource plan, budget, and get a clear sense of direction for your department or company.<span style="mso-spacerun:yes;"> </span>It’s the perfect analogy for what’s going on in companies that have disaster-driven security practices.</span></span></span></span></span></span></span></span></span></span></span></span></p> <p class="MsoNormal"><span style="font-size:10pt;line-height:115%;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:small;"><span style="color:#000000;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:x-small;"><span style="background-color:#ffffff;"><span style="color:#000000;"><span style="font-size:small;"><span style="background-color:#808080;"><span style="color:#ffffff;"><span style="background-color:#333333;">Like it or not, many of you work in a company that believes security should be driven by incidents not strategy.<span style="mso-spacerun:yes;"> </span>Whether you want to or not, you’re enslaved by “running around putting out fires” and have very little sense of direction.<span style="mso-spacerun:yes;"> </span>Maybe it’s time you do something about that?</span></span></span></span></span></span></span></span></span></span></span></span></p> <p class="MsoNormal"><span style="font-size:10pt;line-height:115%;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:small;"><span style="color:#000000;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:x-small;"><span style="background-color:#ffffff;"><span style="color:#000000;"><span style="font-size:small;"><span style="background-color:#808080;"><span style="color:#ffffff;"><span style="background-color:#333333;">You’re #1 weapon against disaster-driven security is foresight, and metrics.<span style="mso-spacerun:yes;"> </span>You’ve got to anticipate, and measure carefully to prove that there is more risk in waiting for a disaster to occur, than being pro-active.<span style="mso-spacerun:yes;"> </span>After all, that is what everyone in this industry should be doing.</span></span></span></span></span></span></span></span></span></span></span></span></p> <p class="MsoNormal"><span style="font-size:10pt;line-height:115%;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:small;"><span style="color:#000000;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:x-small;"><span style="background-color:#ffffff;"><span style="color:#000000;"><span style="font-size:small;"><span style="background-color:#808080;"><span style="color:#ffffff;"><span style="background-color:#333333;"> </span></span></span></span></span></span></span></span></span></span></span></span></p> <p class="MsoNormal"><span style="font-size:10pt;line-height:115%;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:small;"><span style="color:#000000;"><span style="font-family:arial,helvetica,sans-serif;"><span style="font-size:x-small;"><span style="background-color:#ffffff;"><span style="color:#000000;"><span style="font-size:small;"><span style="background-color:#808080;"><span style="color:#ffffff;"><span style="background-color:#333333;">Good luck!</span></span></span></span></span></span></span></span></span></span></span></span></p><div style="clear:both;"></div> </article> <article> <h1>HTML 5 Form Tags a Risk?</h1> <p>Chris Sullo — Thu, 17 Sep 2009 14:01:00 GMT</p> I've tried to keep up with new HTML 5 features, but Billy recently pointed out that INPUT tags have the ability to set regular expression patterns for validation directly in the markup. I think this is nifty and, at least in the demo I tried , a very user-friendly and pretty way to inform the user they've put in a bad value. There are also special types for numbers, dates, times, urls, email addresses and more . However, I think there's a significant risk that we'll see many developers...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/09/17/html-5-form-tags-a-risk.aspx">read more</a>) </article> <article> <h1>Top Five Web Application Vulnerabilities 8/31/09 - 9/13/09</h1> <p>mark.painter — Mon, 14 Sep 2009 19:54:00 GMT</p> 1) Ruby on Rails Form Helpers Unicode String Handling Cross-Site Scripting Vulnerability Ruby on Rails is susceptible to a Cross-Site Scripting vulnerability. An attacker can leverage Cross-Site Scripting to execute script code in the browsers of unsuspecting users in context of the affected application, possibly leading to theft of authentication credentials and other attacks. Updates which address this issue have been released. Contact the vendor for additional information. http://www.securityfocus...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/09/14/top-five-web-application-vulnerabilities-8-31-09-9-13-09.aspx">read more</a>) </article> <article> <h1>How to clean up a hacked WordPress installation</h1> <p>mark.painter — Wed, 09 Sep 2009 18:58:00 GMT</p> Older installations of WordPress have recently experienced a new wave of attacks as they have been increasingly targeted by hackers. These installations are highly susceptible to a variety of attacks. What to do, then, when your installation has been comprimised? Here's a good list from WordPress of the steps to take when your WordPress installation has suffered a successful attack. http://codex.wordpress.org/FAQ_My_site_was_hacked The HP Web Security Research Group's own Matt Wood recently...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/09/09/what-to-do-when-your-wordpress-is-hacked.aspx">read more</a>) </article> <article> <h1>24 Hour Live Hacking Challenge</h1> <p>mark.painter — Wed, 02 Sep 2009 20:29:00 GMT</p> Join us at the HP Application Security virtual booth for a 24 hour live web hacking challenge where you will have a chance to advance through more than 10 levels of increasing difficulty. Participants attempt to break the login protection mechanisms at each level and gain experience in conducting attacks as a hacker would. Learn how simple techniques can compromise web applications. All of the security defects in the application are based on real world mistakes web developers make. Register to attend...(<a href="http://www.communities.hp.com/securitysoftware/blogs/spilabs/archive/2009/09/02/24-hour-live-hacking-challenge.aspx">read more</a>) </article> </main></body></html>