Denim Group. Build, integrate and secure web-based applications. This blog reflects the principals' thoughts on application security and development news and hot topics.

February 16, 2014

It’s that time of year. Your inbox is probably filling up with “Are you going to RSA?” e-mails from vendors and buyers alike and getting ready for the grueling yet exhilarating week that is the RSA Security Conference at the sprawling Moscone Center

So are we…in fact, Denim Group will be exhibiting at RSA for the first time. Now, I’ve been to a ton of RSA conferences, spoken at a bunch too, but we’ve never exhibited, so this is big news for us. In fact, this is just a big show that is a whole new experience for us…. To maximize our investment and avoid any unforeseen pitfalls of large-scale conference exhibiting, we read the “Rules and Regulations for Exhibitors and Sponsors” several times through, including the fine print. This 12-page document contains a bunch of logistical information every exhibitor should know before they arrive at the Moscone. What was really fascinating were all the extremely detailed restrictions that cover virtually every scenario that one might encounter as a booth exhibitor at a large conference.

Then I started thinking, what really caused so many of these bizarre restrictions to be included in this document? For example, what kind of madness preceded RSA 2014 that made the organizers include specific restrictions on smells and blimps? Was the “mime nuisance” so bad in past shows that a restriction needed to be included by name in this years rules? So, what follows are our ruminations of what might have happened to lead up to this year, and how these rules might have come to be.

So, We Can’t Bring Our Own Llama?

RSA’s rule stipulates, “With the exception of working service dogs, animals are not allowed in the Moscone Convention Center without written approval of Show Management.” OK, this makes sense. We surely don’t want to step in animal poo at RSA. We have enough trouble dodging the attendees walking aimlessly throughout the show floor and the aggressive exhibitors hawking their wares. Dodging animal-created land mines would simply be too much to bear. But I have to confess, I now fantasize about hiring a falconer complete with live bird to fly around and drop care packages on our competitors. This will not be an option apparently…

So I Guess We All Have to Shower This Year?

One of my favorite restrictions is the “Noise and Odors” section. So, how bad did someone have to stink one year to make this a mandatory rule for all RSA shows going forward? RSA’s rule states, “Noisily operated displays and exhibits producing objectionable sound or odors are not allowed.” The conference organizers are kind enough to volunteer themselves as the smell referees - (“Show Management may mitigate as a last resort, with their opinion being accepted by all parties as the resolution.”) I can just picture an RSA organizer, like a fine wine taster, trying to capture the “bouquet” of booth #1245 to make the hard call. Of course, will some clever company get penalized if they set up a Cinnabon oven like they do in airports or malls, wafting wonderful smells up and down the trade show floor? Doubtful because everyone knows that Cinnabons in the oven are the furthest thing from “objectionable.”

How Many Security Guys Does it Take To Unscrew A Lightbulb?

The answer is “none.” According to the section titled “Light Bulb Removal” you may “…request the removal of Moscone House Lighting that interferes with your booth display.” Makes sense, but first you have to let the show management know, and then any costs are the responsibility of the exhibitor. At that point some nice, burly fellow will remove the offending light bulb for you at Union rates!

I Swear! They Are “Models!”

Every year, several companies invite “booth talent” to lure unwitting show attendees into their booth. You know the typical Booth Babe drill – beautiful women, short skirts, and the guys who fall for it. However, in case you are wondering, RSA does define the limits of good taste in its booth regulations: “Show Management reserves the right to enter any portion of the booth premises and to eject from the Moscone Center any unbadged, improperly badged, unprofessionally or objectionably dressed, or other persons deemed objectionable.” But let’s be honest, how does one define objectionably dressed? Who’s the referee, and I want to know where is the waiting list to be that referee? How about the army of the objectionably “underdressed dudes at RSA?” Who lets them know that cut-off shorts and a t-shirt at the largest international security conference of the year just might not cut it?

But Are Dirigibles OK?

There is a section on “Balloons/Blimps” which states “Helium balloons are permitted at Moscone Center, however, Freeman and/or Show Management will charge a fee directly to the exhibitor for retrieval of stray balloons.” OK, I get the balloons part, but “blimps?” And how about dirigibles – are they OK? Should we be worried that some nefarious exhibitor will bring a remote control Hindenburg and attempt to crash it into the SAP booth? If pigeons are outlawed, then maybe dirigibles can do the job of dropping love packages on competitors.

But Clowns Scare me Too!

OK, I get why exhibitors should not clog up the aisles to be bad neighbors. But how bad did it get in the past that this rule came to be: “The use of demonstrators, gimmicks, mimes, magicians, robots, vehicles, etc. in the aisles is prohibited at all times.” Wait a second here! Are clowns allowed in the aisles? Why pick on mimes and magicians? Heck, mimes and magicians are so obnoxious that you could make a case for banning them outright from RSA. And how about “demonstrators?” Are the organizers worried that Occupy Oakland! is going to travel across the Bay Bridge and park themselves in the South Hall of the Moscone Center?

So, we’re all prepped and ready with no clowns, no llamas and no dirigibles to exhibit at our first booth at RSA, but it’s been an interesting road to get there, for sure. Enjoy the show and come by booth #2332 in the South Hall and nominate your best addition for the 2015 “Rules and Regulations for Exhibitors and Sponsors!”

Add the ability to set up recurring Scan Agent jobs in ThreadFixIssue #139

For a complete list of items included in today's 2.0MS2 build, click here.

Please note that some of the REST API has been updated to fully use JSON so some previous calls may have changed. If you run into problems please post to the Google Group and we'll work to get you fixed up.

January 06, 2014

Regardless of what side of the Edward Snowden debate you fall upon – whether or not you think he’s a traitor or a patriot who helped shed light on an overreaching government agency – you no doubt understand that Edward Snowden has had a profound impact in Washington amongst policy makers, within the hallways of the intelligence community and most importantly perhaps, upon how business is conducted. In fact, long after Edward Snowden drifts from the headlines, many will point to him as a turning point in how big organizations handle sensitive data and interact with government agencies. For those in IT leadership roles who wonder what the consequences of the Snowden release are on corporate America, the following ideas represent what I think is likely to play out over the next several months. In the long term, these changes might actually have a more day–to–day impact in the way we conduct business and interact online. In the short term, you will at least be able to answer the question from your CEO or CFO about what might be the impact of Snowden on your organization.

For instance, some of the changes that are likely to play out in Fortune 500 and smaller companies include:

1. Companies will be more wary to cooperate with governments. I use the plural word “governments” because this is happening not only with the US Federal Government, but with government at all levels such as local law enforcement and state agencies. Where some companies strived to cooperate beyond the letter of the law, now the opposite will be the case. Instead, corporate counsels across the country are more likely to push back more vigorously against requests that appear to be too broad and overreaching and in its place, define these requests in the narrowest terms possible. That was mostly likely the case with Silicon Valley tech companies prior to the Snowden releases, but will now be more prevalent with the companies that traditionally cooperated more closely with the US government and law enforcement (e.g., telephone companies). For international companies that operate in multiple countries, this issue may be particularly thorny.

2. Tighter cooperation between security, privacy and corporate counsel will occur. In most large companies, departments exist that manage security, privacy, and legal matters within the organization. In certain instances, companies have formalized the roles of each including elevating the privacy function by hiring or promoting a “Chief Privacy Officer.” Most of these departments don’t typically work closely together on a day-to-day basis, but that is changing due to the Snowden revelations.Where these disparate corporate functions worked together on a case-by-case and event-driven basis, they will now be forced to coordinate more closely and will be more likely to regularly meet with each other. In the long-term, these relationships will maintain this close integration because the policy side of these discussions will remain the domain of the privacy and corporate counsel departments, and the means to implement the policies will remain with the security function, the other side of the equation.

3. Companies will review and update their public privacy statements. As an outgrowth of the aforementioned tighter cooperation, companies are adjusting their privacy statements so they are more inline with their internal practices. The perception from Snowden – correct or incorrect – is that most corporate privacy statements didn’t accurately reflect a company’s true practices concerning complying with government requests. As a result, the public now thinks that many companies gushed publicly about how they guarded and protected customer data while ,in fact, they were handing over the keys to the kingdom to law enforcement and the NSA. However, I believe that there is a ton of misinformation and surface-level analysis that appeared in the press that is not based on true reality. In fact, my take is that most companies were NOT falling all over themselves to provide their customer data to NSA. The problem is that the perception is out there and a lot of damage has been done to the customer’s trust factor as a result. The end product is that I believe public privacy statements will now be more muted and more in-line with internal practices. I also believe that companies will go on the offensive when announcing their customer privacy protections as well in an attempt to repair these perceptions.

4. CEOs will question why companies keep certain sensitive customer data at all. I predict that more company leaders – CISOs, CIOs and executive management – will be asking, “Why do we even collect this information in the first place?” Be prepared! Up to this point, only the most sophisticated scrutinized corporate efforts to collect private customer data. The norm was truly “the more, the better” and almost always was driven by marketing departments. That has certainly changed post-Snowden. Going forward, collecting privacy information electronically will more likely infer that a company will provide some modicum of protection. I remember not too long ago getting asked for my driver's license number for a trial gym membership. Why? More leaders will ask the same question.

5. Legislation to cooperate with the US Federal Government on Information Sharing is likely dead. See observation #1 above. The conventional wisdom in D.C. was that in spite of a poisoned political environment, some type of information sharing legislation would be passed in 2013. That did not happen, and we can likely thank Mr. Snowden for sowing the seeds of distrust in corporate America that hastened the death of information sharing this past year. No doubt, everyone took a step back after Snowden and is now looking for a real business justification that makes it worth working with government in this manner. In the interim, industry cooperation within sectors will continue, via forums such as the Information Sharing and Analysis Centers (ISACs) which are trusted entities established by Critical Infrastructure Key Resource owners and operators that share this information within the sector, with other sectors, and with the government.

6. International clients will ask American IT companies tougher questions. Without a doubt, American IT companies have been on the defensive with non-US clients since the Snowden releases became public. For example, the RSA story about its alleged cooperation with NSA is potentially very damaging, from the perspective of RSA’s ability to compete internationally. In discussions with colleagues involved in the hosting industry, the questions are particularly blunt. If your company handles sensitive information from international clients, you need to be ready to answer questions about your organization’s cooperation with US law enforcement and government organizations and how that may affect their business, especially cloud providers. In fact, I’d suggest that you think through these issues now and reach out to your international clients prior to them asking the question. In addition, I recommend that whatever you communicate truly be in line with your disclosure practices because getting caught a la Snowden could deeply damage any international business for your company in the future.

No one knows how long the Snowden releases will continue to appear in the press. Aside from headlines that grab attention from time to time, corporate IT leaders would be well-served to look beyond the headlines to identify the long-term impact to their organization. The range of responses to these Snowden releases will vary from company to company and from industry to industry. Bottom line though is that your response will be greatly driven by your corporate culture and the risk appetite of your organization. Issues of international competition should not be taken lightly given the negative reactions American companies are already receiving. Whether we like it or not, Edward Snowden’s revelations have forever changed the world within which we live. We think these long-term impacts are likely to play out and one should be prepared to respond to some or all of them.

November 06, 2013

Have you ever wondered about your application’s attack surface? What URLs will respond to requests? And what HTTP methods will they respond to? And what parameters can be passed in? You probably think you know what is exposed but do you really?

Why is this something you should even care about? I’d suggest a couple of reasons:

Your attack surface is where bad guys can reach out and touch your application. More attack surface = more possible inputs to worry about. More attack surface means more input validation and probably more contextual encoding to avoid common problems like cross-site scripting (XSS) and SQL injection. Attack surface isn’t necessarily bad but it is something you need to be aware of.

Attack surface has a tendency to creep up on you. Things get added to solve a particular problem and then they are forgotten as developers move on to new user stories and new functionality. I once tested a web application where, if you passed in the parameter “d” to any page in the application, it would delete the order referenced by that parameter value. The “d” parameter never showed up in any HTML rendered by the (non-administrative) pages in the application, but the functionality had been cut and pasted into every single page regardless. So if a bad guy got lucky and tried to send in a “d” parameter…

Knowing where you are exposed lets you better understand what your application looks like to potential adversaries and is essential if you want to do thorough security testing. The question is – what can you do to enumerate potential attack points?

We are currently finishing up the first phase of some research funded by the US Department of Homeland Security (DHS) under their Small Business Innovation Research (SBIR) program to develop Hybrid Analysis Mapping (HAM) capabilities for software assurance. You can read more about the scope of this research and some of the coverage it has received so far. The object of the research is to map the results of static application scanners (like Fortify SCA) to the results of dynamic application scanners (like IBM Rational AppScan). We’ve been pretty successful at that and we’re including that in future versions of ThreadFix. In addition, an interesting – and unanticipated – result of this work is that we created a utility that can do a lightweight scan of an application’s source code and dump out an enumeration of the application’s attack surface.

The endpoint enumerator takes a look at the application base and tries to determine the language and framework that is in use. Once the framework has been determined, the tool develops an analysis model with the following information:

Relative URL in the application that should respond to requests

HTTP methods for each URL

Parameters each URL might access during page execution

It then dumps out a listing to STDOUT where you can review it, parse it, or do whatever you like. This can provide a great start for manual penetration testing activities by highlighting potentially interesting information.

So how does this work for Java applications using JSP? Calculating the relative URLs for JSP is pretty simple. Basically we just need to find the common code root and the relative URLs are extrapolated from there. JSP makes it pretty simple. (Spring and other frameworks make it far less simple and we will post more about that later.) To determine the HTTP methods we currently just assume that JSPs will respond to GET and POST methods. (Making this more comprehensive will require a bit more analysis which we currently do for the Spring framework) Finally, determining the parameters that a JSP page will use requires some simple static analysis where we track down calls to request.getParameter(key). If “key” is a String literal, then that is the parameter name. If “key” is a String variable then we do some data flow parsing to see if we can trace the variable back to its value. It isn’t perfect but it works reasonably well.

Let’s take a look at the output of the tool when it is run against the Bodgeit Store. Bodgeit is an intentionally-flawed application written in Java using JSPs that is intended as a training tool for penetration testers. Running the command:

java –jar endpoints.jar ~/git/bodgeit

results in the output:

[POST, GET],/about.jsp,[]

[POST, GET],/admin.jsp,[]

[POST, GET],/advanced.jsp,[q, debug]

[POST, GET],/basket.jsp,[update, productid, quantity, debug]

[POST, GET],/contact.jsp,[anticsrf, debug, comments]

[POST, GET],/footer.jsp,[]

[POST, GET],/header.jsp,[debug]

[POST, GET],/home.jsp,[debug]

[POST, GET],/init.jsp,[]

[POST, GET],/login.jsp,[username, debug, password]

[POST, GET],/logout.jsp,[]

[POST, GET],/password.jsp,[password1, password2]

[POST, GET],/product.jsp,[typeid, prodid, debug]

[POST, GET],/register.jsp,[password1, username, password2, debug]

[POST, GET],/score.jsp,[debug]

[POST, GET],/search.jsp,[q, debug]

Most of this is pretty basic and shouldn’t be terribly surprising. However, the “debug” parameter that appears in a number of pages is a cause for some further inspection. Also, that “admin.jsp” page might not be something that everyone should have access to. These are exactly the kinds of thing that get placed into applications, and then find their way into production to cause trouble down the road. Keeping an ongoing eye on your application’s attack surface can help you catch things like this early – before they make their way into production and before they result in problems.

So what’s missing? We’ve hit the major points, but there are some limitations:

The support is very language and framework dependent. Right now, we have support for Java/JSP and Java/Spring and we’re working on others. Also the code is all open source and we’re structuring it so that it is easy for folks to get involved and add support for their favorite languages and frameworks. If you’re interested in helping, just drop me a line on Twitter or via email.

The attack surface model is limited. In the future, we’re looking at adding support for cookies and other HTTP headers as well as other input points such as environment variables, command-line arguments, inbound (but non-HTTP) network traffic, and so on. For right now though, URLs and their GET and POST parameters provide a solid starting point.

This is an area where other folks have done work as well. For more information, check out:

So – take some time and think about your application’s attack surface. What might be lurking about that you haven’t thought about in a while? Run the endpoints.jar utility through its paces and feel free to post any bugs or feature requests to our issue tracker. Bad guys are undoubtedly thinking about your application’s attack surface. Shouldn’t you be thinking about it as well?

The ThreadFix development team has been hard at work since our last official product release (v1.1) in March. We are excited to announce that 1.2 official is available for download. Please download and test drive today! Again, we encourage any and all feedback. Please report any bugs you might find (or cool feature requests) into our Google Code Issue Tracker. Today's update includes a bunch of great updates (User Experience, System Enhancements, Improved Reporting Capabilities) and a ton of bug fixes, see below:

September 30, 2013

The ThreadFix product development team has been hard at work since our ThreadFix 1.2 RC2 released in late July and today we've made a 3rd 1.2 Release Candidate available for users and organizations to download and put it through its paces. This update includes some great new features like: file attachments, severity filtering, support for Dependency Check, and a ton of bug fixes and enhancements. This release is intended for users who want to try out the new version and help identify any remaining bugs prior to the 1.2 official release. We welcome any and all feedback. Please report any bugs you might find into our Google Code Issue Tracker.

It is good to see both the press and industry taking a greater interest in an organization's need to fix the vulnerabilities that various scanning tools are identifying in their software and we're thrilled to be helping move the state of the industry forward.

August 26, 2013

I just got back from OWASP AppSecEU in Hamburg, Germany and I have to say I had a great time. The conference was very well run, the talks were very interesting and I had the opportunity to both reconnect with and meet a lot of great folks.

While I was there, I gave a talk titled "Do You Have a Scanner or a Scanning Program?" Here is the video from the presentation:

By this point, most organizations have acquired at least one code or
application scanning technology to incorporate into their software
security program. Unfortunately, for many organizations the scanner
represents the entirety of that so-called “program” and often the
scanners are not used correctly or on a consistent basis.

This presentation looks at the components of a comprehensive
software security program, the role that automation plays in these
programs and tools and techniques that can be used to help increase the
value an organization receives from its application scanning activities.
It starts by examining common traps organizations fall into where they
fail to address coverage concerns – either breadth of scanning coverage
across the application portfolio or depth of coverage issues where
application scans do not provide sufficient insight into the security
state of target applications. After discussing approaches to address
these coverage issues, the presentation walks through metrics
organizations can use to keep tabs on their scanning progress to better
understand what is being scanned, how frequently and at what depth.

The presentation also contains a demonstration of how freely
available tools such as the open source ThreadFix application
vulnerability management platform and the OWASP Zed Attack Proxy (ZAP)
scanner can be combined to create a baseline scanning program for an
organization and how this approach can be generalized to use any
scanning technology.

I also spent an afternoon giving demos of ThreadFix and talking to a bunch of current - and hopefully future - ThreadFix users at the Open Source (Security) Showcase. I really enjoy events like the OS(S)S and the BlackHat Arsenal because of the opportunity to talk with both users and prospective users in-depth about their challenges and how ThreadFix can help them address those challenges.

Contact us for more information about how organizations are using ThreadFix to make the most of their investments in app and code scanners.

Also the full text of the release describing the ThreadFix/NTOSpider integration is below:

Denim Group, the leading secure software development company, and NT OBJECTives (NTO), a leading provider of automated, comprehensive and accurate web application security software and services, today announced their alliance to provide enterprise customers with a comprehensive dynamic vulnerability management solution for web and mobile applications. Denim Group’s ThreadFix application vulnerability management platform is now able to import the results from NTO’s application scanner, enabling organizations to compare and analyze the results of other testing efforts and have a more complete picture of the results of their application security testing program.

“NTO is doing some very interesting things with their scanning technology, particularly related to testing for thick client applications and web services,” saidDenim Group CTO Dan Cornell. “By building the connector with ThreadFix, NTOSpider users can now import the results of their scanning efforts and manage them alongside static analysis or manual testing results to get a deeper understanding of where their application vulnerabilities lie.”

NTOSpider’s dynamic application security testing (DAST) engine allows companies to test mobile and web applications built with the newest programming technologies like REST, AJAX, JSON and GWT. Prior to NTOSpider, this testing had to be done manually. NTOSpider offers a repeatable, rapid, and comprehensive automated application security testing solution that now frees up security analysts to spend more time on other activities that must be done to properly secure software. NTOSpider offers more comprehensive application coverage combined with sophisticated attack methodologies as well as high rates for eliminating false positive and false negative findings. This makes the scanner an important weapon in the security team’s arsenal for speeding up time to market.

“Application security teams can now use the efficiency of both ThreadFix and NTO Spider to analyze test results faster, creating a holistic view of the corporation’s security posture that reduces the risk of damage to the company’s intellectual property, data, and web applications,” said Dan Kuykendall, NT OBJECTives co-CEO. “ThreadFix users benefit from this integration and can now consolidate the results of other testing activities to provide a full view of these efforts.”

Typically, an organization’s security team uses a combination of dynamic and static scanners as well as manual testing to identify potentially thousands of vulnerabilities in applications. In the past, these disparate results were typically haphazardly managed with inefficient Excel spreadsheets to track the status of each of these vulnerabilities. ThreadFix simplifies this process by importing dynamic, static and manual testing results into a centralized console that removes duplicate findings across testing platforms resulting in a prioritized security vulnerability list for each application. Unlike infrastructure security problems inside an organization, application vulnerabilities can only be fixed by software development teams. To enable this cooperation, ThreadFix exports its prioritized security vulnerability list into the defect trackers already used by development teams, translating vulnerabilities into software defects and essentially injecting these security tasks into the developer’s regular work flow. By acting as a crucial link between the security and development teams, ThreadFix creates meaningful and productive two-way communications that dramatically streamline and accelerate the application vulnerability resolution process. The result is that with ThreadFix, applications vulnerabilities get fixed faster, reducing software risk and protecting corporate assets.

Andrew wrote up some notes for our internal blog about an experience he had on a recent Capture the Flag (CTF) event. I thought they were interesting so we talked and decided to republish them here.

<Andrew>

I came across an interesting twist on exploiting a PHP local file inclusion vulnerability while participating in a CTF. LFIs are the little sister vulnerability to remote file inclusion (RFI), which is when an attacker can tell an application to execute arbitrary code from another file. The distinction with an LFI is it will only read and execute from files that are already on the server.

Developers usually create these vulns by allowing input from the client to decide the destination of an include() function call, which among other things is useful in templating out code. An example would be:

$page = $_GET['page'];

include("app/schedule/" . $page . ".php");

The developer’s intention is to pull in schedule code into another page, perhaps onto a sidebar. An attacker who notices this can specify their own page parameter to point to whatever file they want to be included. If an attacker can manage to upload code to the server, they can use this flaw to execute that code and probably compromise the machine. If not, they can still try to include files they’re not supposed to, such as /etc/passwd, but if the web server's account is locked down, it might not have read-access to access all the interesting files an attacker might want.

If the system is locked down then it seems like the risk here is somewhat mitigated, but PHP 5 has a fun little feature that can keep LFI in the game. PHP offers a protocol for accessing streams called ‘php://’. This protocol can do such things as read from the standard out stream with ‘php://stdout’. Interestingly, it can also apply filters to the stream, such as a filter which compresses the data as it passes through the stream.

We can take advantage of PHP’s base64-encode converter to tell PHP to base64-encode the php file before including it. The input would appear as such:

PHP does not parse base64-encoded text, so the entire base64 blob gets outputted onto the page as text. At this point an attacker is one base64 decode away from having the PHP source code to the application.

While the machine hasn’t been rooted yet, having the PHP source code offers all sorts of new attack options. From personal experience, I’ve found PHP developers rapidly sober up at the prospect of their source code being leaked. Features such as these is the reason the optimal fix for LFIs in PHP is to avoid it entirely in design by never using client-controlled input inside of an include.