Static Application Vulnerability Testing: Binary Scanning vs Source Code Scanning
I had a meeting yesterday with a vendor who sells a SaaS solution for binary application vulnerability testing. They tell a very interesting story of a world where dynamic testing ("black box") takes place alongside static testing ("white box") to give you a full picture of your application security posture. They even combine the results with some e-Learning aspects so that developers can research the vulnerabilities in the same place they go to find them. In concept, this sounds fantastic, but I quickly turned into a skeptic and as I dug deeper into the details I'm not sure I like what I found.
I wanted to make sure I fully understood what was going on under the hood here so I started asking questions about the static testing and how it works. They've got a nice looking portal where you name your application, give it a version, assign it to a group of developers, and point it to your compiled code (WAR, EAR, JAR, etc). Once you upload your binaries, their system basically runs a disassembler on it to get it into assembly code. It's then at this level that they start looking for vulnerabilities. They said that this process takes about 3 days initially and then maybe 2 days after the first time because they are able to re-use some data about your application. Once complete, they say they are able to provide you a report detailing your vulnerabilities and how to fix them.
The thing that immediately struck me as worth noting here was the 2-3 day turnaround. This means that our developers would need to wait a fairly substantial amount of time before getting any feedback on the vulnerability status of their code. In a world full of Agile development, 2-3 days is a lifetime. Compare that to static source code testing where you get actionable results at compile time. The edge here definitely goes to source code testing as I believe most people would prefer the near-instant gratification.
The next thing worth noting was that they are taking binary files and disassembling them in order to find vulnerabilities. This lends itself to one major issue which is how can you determine with any accuracy the line number of a particular vulnerability written in let's say Java from assembly code generated by disassembling the binaries. By default, it's simply not possible. This vendor claimed that they can by adding in some debug strings at compile time, but even then I'd contend that you're not going to get much. I'm guessing they have some heuristics that are able to tell what function generated a set of assembly code, but I'm extremely skeptical that they can do anything with variable names, custom code functions, etc. I've seen some source code scanners, on the other hand, that not only tell you what line of code is affected, but are able to give you an entire list of parameters that have been consequently affected by that vulnerability. The edge here definitely goes to source code testing.
The main benefit that I can see with binary testing vs source code testing is that we can test code that we didn't write. Things like APIs, third-party applications, open source, etc are all things that we now have visibility into. The only problem here is that while we now can see the vulnerabilities in this software, they are unfortunately all things that we can't directly influence change in, unless we want to send our developers off to work on somebody else's software. I'd argue that scanning for vulnerabilities in that type of code is their responsibility, not ours. Granted, it'd be nice to have validation that there aren't vulnerabilities there that we're exposing ourselves to by uptaking it, but in all honesty are we really going to take the time to scan somebody else's work? Probably not. The edge here goes to binary testing with the caveat being that it's in something that I frankly don't care as much about.
This isn't the complete list of pros and cons by any means. It's just me voicing in writing some concerns that I had about the technology while talking to this particular vendor. In my opinion, the benefits of doing source code testing far outweigh any benefits that we could get from testing compiled binary files. What do you think about the benefits of one versus the other? I'd certainly love for someone to try to change my mind here and show me where the real value lies in binary testing.
Auditors Just Don’t Understand Security
Part of my new role as the Information Security Program Owner at NI is taking care of our regulatory compliance concerns which means I spend quite a bit of time dealing with auditors. Now auditors are nice people and I want to preface what I'll say next by saying that I think auditors do perform a great service to companies. I'm sure that most of them are hard-workers and understand compliance requirements probably better than I do, but they just don't understand security.
As a case in point, we're in the middle of our annual audit by one of those "Big Four" audit firms which I won't name here to protect the innocent. I sent an email checking in with our auditors to make sure that they had everything they needed before we went into our four-day holiday weekend. They said that they had received everything they needed except for documentation on "privileged users from the current OS and Database environments" as well as "evidence of current password settings from the application servers, OS, and Database". We go through a round of translation from Auditorese to Techie and figure out that they want exports of some specific user, profile, role, and privilege tables from the database and copies of /etc/passwd, /etc/shadow, and /etc group from the servers.
So we obtain the requested documentation and I shoot them back an email message to find out their proposed method for transferring the files. Secure FTP? No. PGP encryption? Nope. Their response back was astonishing:
How large do you think they'll be? Email should be fine.
Seriously? These are the guys that we're paying to verify that we're properly protecting our systems and they're suggesting that sending our usernames and password hashes via cleartext email is an appropriate method of file transfer. I respond back:
I'm not really concerned about the size of the files, but rather, the data that they contain. Sending files containing the users, groups, and password hashes for our financial systems via cleartext is probably not a good plan considering the point of this process is protecting that data.
And they respond with:
Whatever you'd like Josh. As long as you have the files as of today, we're good.
So now I'm convinced that auditors (or at least these auditors) view security as nothing more than a checklist. The people telling me what I need to do in order to protect my systems really have no clue about the fundamentals of security. If it's not on their checklist, then it must not be of importance. In this particular situation it may be easier or more convenient to send the documents via email, but any security professional worth their salt would tell you that's not secure nor appropriate for that data. Either our auditors hold themselves to a very different standard than the rest of us security professionals or they just don't understand security unless it's on a checklist.
Simplifying On-call Through Alert Aggregation
One of the coolest things about working on the Web Systems Team at National Instruments is that the company has invested in a wide variety of tools to assist us with our jobs. Since we are responsible for the availability of ni.com, we have the standard URL and content monitors (Sitescope and Nagios). We also have the ability to do real user monitoring with a tool called Coradiant TrueSight. We are also responsible for the website's performance so we have purchased tools like Panorama to diagnose code level issues. We have Splunk for log monitoring and Gomez for a third-party performance and availability monitor. We even have a SaaS provider that does application security scanning. Having all of these tools at our disposal is quite awesome and allows us to quickly find and fix issues with the site. The problem is that every single one of those tools has it's own alerting and reporting interface.
This isn't a new problem by any means. I've seen this issue at every job that I've ever had where the responsibilities included operational support. You rely on multiple tools to tell you when things aren't going quite right, but now you end up spending some non-zero portion of your time managing those tools. For example, lets say that your company has a small release that lasts a few hours once a month. You now have to log in to the control panel (GUI) for each one of those tools and disable your alerts for that time period so that your on-call device isn't going crazy. Assume that you have only four alerting tools and it takes you approximately 5 minutes to log in to each, set the maintenance window, and log back out. You just spent 20 minutes to disable alerts! Now you're getting to the end of the release and things didn't go as planned so the release is running longer than expected. Now you have to spend another 20 minutes to extend the maintenance window. How frustrating is that?
The issue gets even more complicated when you have multiple people providing support in either an on-call rotation or follow-the-sun type of scenario. At NI, we have an operations team that handles alerts during normal business hours, an on-call admin who handles alerts from 5 PM to 2 AM, and then a super-awesome Hungarian Web Admin who takes over responding to pages after 2 AM (9 AM in Hungary). Most of the alerting configurations that these tools provide aren't even able to handle this type of scenario, but let's suppose they did. You're still stuck logging into multiple systems every time there's a holiday, somebody goes on vacation, etc. And what happens if you don't have a dedicated on-call device to pass from person to person? Then you're stuck updating the alert configurations every time the on-call person changes in your rotation.
This really got me thinking that there has to be a better way to do things. I searched the internet looking for a solution, but when I couldn't find anything to do exactly what I wanted it to do, I ended up writing my own. It's now my pleasure to share with you iAlertYou. The idea is quite simple. You take all of those different tools that send alerts and you aggregate them in the same place. In this case, it's on ialertyou.com. By doing this, you gain the ability to control everything from a single, centralized, management platform. Have a maintenance window? No problem. Just log in, set it once, and it affects all of your alerts. Same thing for both alert scheduling (who should get pages and when) and contact groups (used for on-call rotations). Plus, by having all of your alerts going through a single aggregation point, it means that we can also do reporting on all of your alerts. Ever wondered how many of your alerts come from what tools? What times of the day you get the most alerts? It's all possible through alert aggregation.
Certainly there are drawbacks to this type of scenario. Most importantly, you're introducing another dependency in what is typically a mission critical activity. While I can't eliminate this concern completely, I built the system on top of internet cloud technologies for superior scalability. I've architected the application using best-practices in availability, performance, security, and usability. Currently, the only offering is a $30/month "everything" plan, but if you spend more than 10-20 minutes a month changing alert configurations, the ROI is realized very quickly. I will also be rolling out a "free" plan (thanks to Peco) with a limited subset of the functionality. I'd like to invite you to check out http://www.ialertyou.com and see if it can help your company simplify on-call through alert aggregation.
A XSS Vulnerability in Almost Every PHP Form I’ve Ever Written
I've spent a lot of time over the past few months writing an enterprise application in PHP. Despite what some people may say, I believe that PHP is as secure or insecure as the developer who is writing the code. Anyway, I'm at the point in my development lifecycle where I decided that it was ready to run an application vulnerability scanner against it. What I found was interesting and I think it's worth sharing with you all.
Let me preface this by saying that I'm the guy who gives the training to our developers on the OWASP Top 10, writing secure code, etc. I'd like to think that I have a pretty good handle on programming best practices, input validation, and HTML encoding. I built all kinds of validation into this application and thought that the vulnerability scan would come up empty. For the most part I was right, but there was one vulnerability, one flaw in particular, that found it's way into every form in my application. In fact, I realized that I've made this exact same mistake in almost every PHP form that I've ever written. Talk about a humbling experience.
So here's what happened. I created a simple page with a form where the results of that form are submitted back to the page itself for processing. Let's assume it looks something like this:
<html> <body> <?php if (isset($_REQUEST['submitted']) && $_REQUEST['submitted'] == '1') { echo "Form submitted!"; } ?> <form action="<?php echo $_SERVER['PHP_SELF']; ?>"> <input type="hidden" name="submitted" value="1" /> <input type="submit" value="Submit!" /> </form> </body> </html>
It looks fairly straightforward, right? The problem has to do with that $_SERVER['PHP_SELF'] variable. The intent here is that PHP will display the path and name of the current page so that the form knows to submit back to the same page. The problem is that $_SERVER['PHP_SELF'] can actually be manipulated by the user. Let's say as the user I change the URL from http://www.webadminblog.com/example.php to http://www.webadminblog.com/example.php"><script>alert('xss');</script>. This will end the form action part of the code and inject a javascript alert into the page. This is the very definition of cross site scripting. I can't believe that with as long as I've been writing in PHP and as long as I've been studying application security, I've never realized this. Fortunately, there are a couple of different ways to fix this. First, you could use the HTML entities or HTML special character functions to sanitize the user input like this:
htmlentities($_SERVER['PHP_SELF]);
htmlspecialchars($_SERVER['PHP_SELF]);
This fix would still allow the user to manipulate the URL, and thus, what is displayed on the page, but it would render the javascript invalid. The second way to fix this is to use the script name variable instead like this:
$_SERVER['SCRIPT_NAME'];
This fix would just echo the full path and filename of the current file. Yes, there are other ways to fix this. Yes, my code example above for the XSS exploit doesn't do anything other than display a javascript alert. I just wanted to draw attention to this issue because if it's found it's way into my code, then perhaps it's found it's way into yours as well. Happy coding!
Techniques in Attacking and Defending XML/Web Services
This presentation was by Jason Macy and Mamoon Yunus of Crosscheck Networks - Forum Systems. It wins the award (the one I just made up) for being the most vendor-oriented presentation at the conference. Not that it wasn't an interesting presentation, but their solution to defend against most of the attacks was "Use an XML Gateway" (guess what Forum Systems sells?) and the attacks were all presented using the CrossCheck SOAPSonar tool. I realize that being a vendor they probably have more knowledge than most in the field, but being an Open Source conference, you'd think they would have demonstrated using a free/open tool (SOAPUI?) and talked more about non-hardware solutions to fix the issues. My notes from the session are below:
Agenda
- Introduction to XML/Web Services Threats
- Techniques for Defending XML Threats
- XML Attack Examples and Classification
- Review sample attacks
Introduction to XML Threats
- Explicit Attacks
- Forced Disruption
- Information Theft
- Vendor Discovery
- Implicit Vulnerability
- Perimeter Breach (embeeded virus, malware)
- Infrastructure Malfunction (parser and data processing failures)
New Attack Vectors
- Protocol Firewalls are blind to XML
- Malware and virus delivered via SOAP attachments
- WSDL exposes schema and message structure
- Injection attacks exposed via XML parameters
- Data replay attacks
Security Testing - Base Requirements
- Security Framework
- Sign, ENcrypt, Decrypt, SSL
- Identity Framework
- Basic auth, SSL auth, WS-Security token auth
- Parameter Injection
- Database or file driven
- Permutations for security, identity, and SOAP/XML
- Concurrent Client Simultaneous Loading
- Denial of Service Testing
- SOAP with Attachments
- Malware and Virus testing
- Dynamic XSD Mutation
- Derive SOAP vulnerability profile from WSDL schema
The OWASP Security Spending Benchmarks Project
This presentation was by Boaz Belboard, the Executive Director of Information Security for Wireless Generation and the Project Leader for the OWASP Security Spending Benchmarks Project. My notes are below:
It does cost more to produce a secure product than an insecure product.
Most people will still shop somewhere, go to a hospital, or enroll in a university after they have had a data breach.
Why do we spend on security? How much should we be spending?
- Security imposes extra costs on organizations
- The "security tax" is relatively well knnown for network and IT security - 5 to 10% (years of Gartner, Forrester, and other studies)
- No comparable data for development or web apps
- Regualtions and contracts usually require "reasonable measures". What does that mean?
OWASP Security Spending Benchmarks Project
- 20 partner organizations, many contributors
- Open process and participation
- Raw data available to community
Reasons For Investing in Security
- Contractual and Regulatory Compliance
- Incident Prevention, Risk Mitigation
- Cost of Entry
- Competitive Advantage
Technical and Procedural Principles
- Managed and Documented Systems
- Business-need access
- Minimization of sensitive data use
- Security in Design and Development
- Auditing and Monitoring
- Defense in Depth
Specific Activities and Projects
- Security Policy and Training
- DLP-Type Systems
- Internal Configurations Management
- Credential Management
- Security in Development
- Locking down internal permissions
- Secure Data Exchange
- Network Security
- Application Security Programs
Building an In-House Application Security Assessment Team
This presentation was by Keith Turpin from The Boeing Company. About three years ago, all of Boeing's assessments were coming from outsourced service providers. They realized that they were unable to have control over the people and process and had difficulties integrating the controls into the SDLC and decided to bring these functions in house. The goal of this presentation is to show some of the issues they ran into and how they addressed those problems. My notes from the presentation are below:
Contraced Services Considerations
- Some Advantages:
- Highly skilled
- Established tools, processes, and standards
- Unbiased
- Available as needed
- Some Disadvantages:
- Expensive, especially for an extended engagement
- Less control and flexibility
- Not familiar with company processes and culture
- Rotating staff
Planning
- Considerations for establishing an internal team:
- Time to staff and train the team
- Overlap of external and internal teams
- Development of processes and standards
- Acquiring necessary tools
Service Model
- Define the services your team will provide. This will be greatly influenced by:
- The team's size and skills
- The number of applications you have to support
- The tools available
- The level of executive support
- The funding model
- Who pays for your services
- The team's role
- Development support, pre-deployment testing or post deployment auditing and pen testing
The 10 Least-Likely and Most Dangerous People on the Internet
This presentation was by Robert "RSnake" Hansen and was designed to be a fun conversation to have over drinks with security people. I feel privileged to have been one of those security people who he talked about this with beforehand. A very interesting topic about the non-obvious threats that may or may not exist. My notes are below:
Why?
- Because I use the Internet
- Because I'm a target
- Because most people don't know
- Because it's a fun conversation to have over drinks with security guys
- Maybe/hopefully you'll continue this conversation instead of just arguing!
Ground Rules
- Must be non-obvious and must be directly related to the Internet. Not:
- ...the President or any other gov'ernment official
- ...or someone involved with SCADA Systems/Brick and mortar
- Must be in control of some infrastructure or software, etc
- Must have the largest or widest negative impact possible for the least amount of work and least likelihood of being stopped
- No magic - must be real and dangerous
- They can't be "bad" people
- You can't take this list too seriously
How I Got Started
- Started thinking about core technologies that everything relies on
- Made a big list
- Shopped it around to dozens of security experts
- Assigned an arbitrary, unscientific, hand-wavy, risk-rating system of my own design
- Ranked them in order of how scared I am of them personally
#10
- John Doe at C|Net
- Job: Network Engineer
- Why: Controls com.com
- Impact: Largest collection point of typo traffic both for web adn email.
- Doesn't require anything overt or even indefensible
#9
- Giorgio Maone of NoScript
- Job: Consultant
- Why: Controls NoScript
- Impact: Nearly every security researcher on the planet - complete compromise. In general the most paranoid people on earth would be compromised.
- Builds arbitrary whitelists (ebay.com)
- Has changed functionality to subvert Adblock Plus
OWASP Top 10 – 2010
This presentation was by Dave WIchers, COO of Aspect Security and an OWASP Board Member. My notes are below:
What's Changed?
- It's about Risks, not just vulnerabilities
- New title is: "The Top 10 Most Critical Web Application Security Risks"
- OWASP Top 10 Risk Rating Methodology
- Based on the OWASP Risk Rating Methodology, used to prioritize Top 10
- 2 Risks Added, 2 Dropped
- Added: A6 - Security Misconfiguration
- Was A10 in 2004 Top 10: Insecure Configuration Management
- Added: A8 - Unvalidated Redirects and Forwards
- Relatively common and VERY dangerous flaw that is not well know
- Removed: A3 - Malicious File Execution
- Primarily a PHP flaw that is dropping in prevalence
- Removed: A6 - Information Leakage and Improper Error Handling
- A very prevalent flaw, that does not introduce much risk (normally)
- Added: A6 - Security Misconfiguration
- A1- Injection: Tricking an application into including unintended commands in the data sent to an interpreter. (http://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet)
- A2 - Cross Site Scripting (XSS): Raw data from attacker is sent to an innocent user's browser. For large chunks of user supplied HTML, use OWASP's AntiSamy to sanitize this HTML to make it safe. (http://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet)
- A3 - Broken Authentication and Session Management: Means credentials have to go with every request. Should use SSL for everything requiring authentication.
- A4 - Insecure Direct Object Reference: This is part of enforcing proper "Authorization", along with A7 - Failure to Restrict URL Access.
- A5 - Cross Site Request Forgery (CSRF): An attack where the victim's browser is tricked into issuing a command to a vulnerable web application. Vulnerability is caused by browsers automatically including user authentication data with each request. (Check out OWASP CSRFGuard, OWASP CSRFTester, http://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet)
- A6 - Security Misconfiguration: All through the network and platform. Don't forget the development environment. Think of all the places your source code goes. All credentials should change in production.
- A7 - Failure to Restrict URL Access: This is part of enforcing proper "authorization", along with A4 - Insecure Direct Object References.
- A8 - Unvalidated Redirects and Forwards: Web application redirects are very common and frequently include user supplied parameters in the destination URL. If they aren't validated, attacker can send victim to a site of their choice.
- A9 - Insecure Cryptographic Storage: Storing sensitive data insecurely. Failure to identify all sensitive data. Failure to identify all the places that this sensitive data gets stored. Failure to properly protect this data in every location.
- A10 - Insufficient Transport Layer Protection
OWASP Top 10 Risk Rating Methodology
- Attack Vector (How hard for an attacker to use this flaw - 1 (Easy), 2 (Average), 3 (Difficult))
- Weakness Prevalence (How often is it found - 1 (Widespread), 2 (Common), 3 (Uncommon))
- Weakness Detectability (How hard is it for an attacker to find the flaw - 1 (Easy), 2 (Average), 3 (Difficult))
- Technical Impact (1 (Severe), 2 (Moderate), 3 (Minor))
This is generic across the internet, not specific to any organization.
Started a new "Prevention Cheatsheet Series" that the Top 10 references (XSS, SQL Injection, Transport Layer Security, CSRF, Direct Object Reference).
What is actually being released is RC1 of the Top 10 and they are encouraging people to provide comments through the end of the year and then use that feedback to post the final Top 10 in January 2010.