Sylvan von Stuppe

A Non-Technical Rant

2009-11-19T02:20:00.000Z

First, if you're looking for a post that is exemplary in its technical merit, this isn't it.

Second, my apologies for the long silence. I've been working on exciting stuff, but that's no excuse for posting nothing for this long of a period.

Now for our regularly-scheduled complaint...

I received some news today that was very disturbing. The thing in the news that bothered me was not that the person who sent the news disagreed with me - I'm not bothered by that. I tend to embrace being a bit different.

But what bothered me was a statement in the end of the message. The end of the message said that the team I was working with needed to spend more time researching ways to make defensive coding completely invisible to developers. The people who made this statement were way smarter than me, so I must be completely in the dark here.

Defensive coding should be automatic, yes. Invisible? Never. Similarly to shielding your children from every bacteria and virus that might come their way, only to find they spend the remainder of their life sick, these people think that the way to have more defensive code is to make it totally invisible to developers. Developers should be trained less on defensive programming so that when new attack vectors come out, the only people who can rescue them are security professionals. (Security professionals - what's our track record so far when we do things our way?)

So the gist of the statement was this - developers are too stupid to write defensive code. Functional code is no problem, but defensive code is serious business that we need to leave to the security professionals.

You trust developers to handle your income tax returns, but don't trust them to use prepared statements on purpose?

You trust developers to navigate the space shuttle, but doing some proper input validation is too complex for them?

You trust developers with sensitive health care information, but think that they're too dull to properly obfuscate it when logging?

See, this is exactly what the problem is right now. We security people think that everybody else is too stupid to get it, and that we have to rescue them. We can't possibly hold people accountable for gaining new knowledge? Look - the security vulnerabilities we find today aren't new. People had to program defensively long before there was a security industry. But now that there's a security industry, the best thing we can do is make writing good code transparent? Pshaw! If the coders aren't doing things right, raise your standards. If you are or know a programmer, you know the way to motivate them - tell them it can't be done. That will show you who the real programmers are. (But I'm still convinced that a decent blacklist simply cannot be written.)

A previous group I worked with used a set of tools I had written as a benchmark for hiring people. This isn't to say that what I wrote was rocket science - it just took some time, reading, and mostly tinkering. Nobody we hired was able to crack the nut in a reasonable amount of time - but we weren't looking for the people who could figure it out in an hour - the people we hired were the ones who tried - who weren't scared of a challenge - who were convinced it could be done, and who were determined to find a way to do it.

There do exist people with that mindset. The real programmers are those people. And they're not so stupid that you have to make everything invisible to them. They're smart enough that once you make the need clear to them, they will do the right thing automatically - because it's the right thing. They're the ones who will program defensively when there aren't automated tools around making their code defensive without them knowing it.

EORant.

50 Ways to Inject Your SQL

2009-06-16T13:19:00.000Z

If I had to rate it, it'd be an A+ on musicianship (I mean - who can't get an A+ for a parody of a Paul Simon song?), an A+ on lyrics (that's not the easiest song in the world to write new lyrics to), and a B+ on technology - only because with a video that short, it's really difficult to demonstrate receiving the results out of band - like in PDF, images, or by forcing the database server to do DNS lookups and logging the DNS events. But it's still good fun.

Building Security In Maturity Model

2009-03-05T02:42:00.000Z

It's no secret I'm a big fan of the work that Gary McGraw, Brian Chess, and Sammy Migues have done on the Building Security In Maturity Model (BSIMM). The idea of any maturity model is to have a set of criteria in any process that demonstrate how maturely the process is being run. While it's not an exact science, it is a pretty good comparative model, and for any process that is not fully matured or innovating, it gives some idea what the "next steps" are to improving the process. The good news about the BSIMM is that they didn't just make up the criteria for the model - they dealt with ten companies from several industries to get a picture of what some of the mature practices are out there.

One of the great things about the results of their research is that they've released the results under the Creative Commons Attribution - Share Alike 3.0 License. But it's also good to know that the run-time testing is not limited to penetration testing by the software security group, but includes fuzzing and failure or abuse cases in QA.

Anyway, I can't provide any more valuable information that what's in the model itself. So go take a look.

Dealing with SQL Injection Part I

2009-02-22T22:24:00.000Z

It turns out the new cool way of spreading malware is by SQL Injection. SQL Injection is also my favorite way of getting almost every piece of data available in the application. But I'm a solutions guy, and this is a solutions blog, so let's learn how to deal with it.

As Jeremiah said in his excellent post on the subject, a way (not necessarily the best way) of finding injection points is by outside in penetration testing. Trying particular sets of metacharacters might yield a database error, and you can often tell if the application is giving the error or if the database is giving the error. There are a couple of flaws with this approach: 1) programmers know errors are bad, and often do what they can to hide those, so you might not get adequate enough information to formulate a good attack. 2) Black-box penetration testing will only find a subset of the problems. If a particular injection is only exploitable on Tuesday, for instance, if it's not exercised on a Tuesday, it's never found. (These are called "corner cases")

The best place to fix SQL Injection vulnerabilities is in the source code. And if you have access to the source code, the absolute best method of finding SQL Injection points is by source code analysis - preferably a combination using automated static analysis tools and manual analysis. The way static analysis tools work to find the injection points is by marking data that enters the application as tainted or untrusted. Expensive tools can trace the taint through the application, through API calls, assignments, etc. until the data goes into a function that's not trusted. SQL Injections happen when untrusted data is concatenated into a query to be used in a prepared statement or query. Some example API's include in .NET DbCommand.CommandText (and children), or JDBC Statement.execute* or Connection.prepareStatement.

Here's a quick example from a web application:

Connection conn = DBUtil.getConnection();
Statement stmt = conn.createStatement();
String sql = "SELECT id, surname, givenName FROM person WHERE surname = '"
  + request.getParameter("surname")
  + "'";
ResultSet rs = stmt.executeQuery(sql);

There are two things that need to be corrected in the code above:

Rather than using a concatenated query, we should use a prepared statement, parameterized query, bind variables statement, whatever you want to call it. This allows the database driver to properly escape and transmit data to the query. For repeated queries, it also substantially improves performance.
Some sort of input validation needs to take place on the request parameter "surname" to verify that it's a legal surname syntax according to our syntax.

Here's the improved code using the first item:

Connection conn = DBUtil.getConnection();
String sql = "SELECT id, surname, givenName FROM person WHERE surname = ?";
PreparedStatement stmt = conn.prepareStatement(sql);
stmt.setString(1, request.getParameter("surname"));
ResultSet rs = stmt.executeQuery();

It's important to note that using PreparedStatement doesn't immediately make the code immune. You have to use them properly by using bind variables. The syntax for using them differs from driver to driver and RDBMS to RDBMS, but question marks are pretty common. Some things can't be bound, however. Only constant values can be bound, so if you're depending on the user to provide table or column names, you need to make sure it is exactly one of the allowed values, or use a lookup method such as a map to map integers to the column names. Also, LIKE statements seem to cause people grief - you need to concatenate the percent signs to the bind variables like "WHERE foo LIKE '%' + ? '%'" or "WHERE foo LIKE CONCAT('%',?,'%')".

As above, the other thing that needs to happen is input validation. I picked surname on purpose because the most common SQL metacharacter first used for injection is the apostrophe. An apostrophe might also be allowable in a surname. So it becomes a perfect example of why prepared statements work so well - it doesn't mean that you don't have to use apostrophes. Here's an updated version that takes pretty complex US-ASCII surnames including apostrophes, but still gets those safely to the query later.

String search = request.getParameter("surname");
if (search == null || !search.matches("^([A-Za-z][a-z]*[' ])?[A-Z][a-z]+(-([A-Za-z][a-z]*[' ])?[A-Z][a-z]+)?$")) {
  rejectInput();
}
Connection conn = DBUtil.getConnection();
String sql = "SELECT id, surname, givenName FROM person WHERE surname = ?";
PreparedStatement stmt = conn.prepareStatement(sql);
stmt.setString(1, search);
ResultSet rs = stmt.executeQuery();

Also, it's worth noting that simply using stored procedures does not remove SQL Injection vulnerabilities. There are two ways that injection can still take place - either by the way the statement is called from the code (with an EXEC with user data concatenated into it), or if the stored procedure uses concatenation to build a dynamic query - all you've done is moved the injection attack into the stored procedure, effectively using the prepared statement to safely transport the attack there.

Mmmm...Springtime!

2009-02-13T03:29:00.022Z

Can you smell that? sssnnnnnnifffffff..... Aahhhh yes. It's that time of year. Yeah, regardless of what Punxsutawney Phil might have had to say, it's springtime! (You folks in the colder parts of the Northern Hemisphere that won't thaw until June will just have to bear with the analogy - sorry). Yeah - it's the time of year when we clean up and clean out. Black Hat is about to start their rounds, SchmooCon just wrapped up, and all the new sales pitches start.

But I think this spring is bound to be a much more delightful one. I've become somewhat disgruntled in the AppSec industry because for a couple of years, we've not been focused on app security, but app insecurity. I think we left short. I personally think that finding weaknesses is only good if you have one of two end goals in mind: either you intend to exploit the weakness for fun and profit (or friends), or you identify them so that you can fix them. For a couple of years, the industry has grown rapidly, but sadly, mostly to the end that we're getting really good at identifying weaknesses, but leaving developers with no indications whatsoever about what to do about their problem. With no solutions, we've left our developers with two options: give up and cross your fingers hoping the bad guys never find out, or second, give up and pull the plug on your project.

But there are lots of things going on in AppSec right now which are very promising for those of us who actually want things to get better:

Gartner is releasing a Magic Quadrant on Static Analysis tools. While static analysis tools identify weaknesses, they identify them in such a way that developers can actually do something about the problems. (Please don't read that the wrong way. I'm not arguing that static analysis is "better" than blackbox/greybox testing. Lots of other people have those fights. Not for me). This is great news because an industry researcher has put a lot of effort into finding out from the industry what the best tools are in particular areas.
WhiteHat Security is providing WAF integration as one of their many services. While WAF's are not a silver bullet, when you don't have the source code, or a lot of cycles to fix issues, WAF's are a good stand-up solution to many semantic types of flaws, and a few logical ones, too. It's a step in the right direction.
Gary McGraw, Brian Chess, and Sammy Migues spent a great deal of time working with businesses learning about how they're dealing with application security, and have put together a Software Security Maturity Model to help businesses identify where they are in terms of baking in security, and where they need to go next. My favorite surprise of their investigation? The one thing that all their subjects said was most important in their program was training. And not just training on identifying weaknesses, but developing solutions.
RSnake and others are working with browser vendors to work out solutions to the whole clickjacking thing. I hate to see the standards-compliant focus of the browsers over the past few years go to back to the browser wars, but the slow-movement of the standards have crippled the advancements of browsers that are helpful in protecting users.
I'm personally doing a little bit of research on developing securely, and might actually get some work done on the project at some point and have a paper to prove it. But right now, it's all just theoretical.

If you're new to the blog, I'm passionate about fixing issues. Certainly, the first step to recovery is admitting you have a problem, but at some point you have to move beyond admitting you have a problem, and working on overcoming the problem.

Twitter Continues to Be Caught With Their Pants Down

2009-01-07T22:24:00.000Z

flee over at Fortify has an excellent analysis of the recent incidents with Twitter where very high-popularity profiles have been hijacked. The analysis is exceptional, but I have one question:

Does anybody take Twitter seriously? I mean....really?

Yes, certain brands use it as a means to remind deliberate followers that the brand is indeed still alive. In fact, is there really a better way to receive notification of the daily woot? But on the other hand, do followers really trust that Twitter has validated the authenticity of the people sending them tweets?

I suppose that unfortunately, the answer is yes. Or to be more accurate, I suppose that users have not really thought about it. In fact, I suppose that a few security-savvy users depend on it as Bruce Schneier thought it necessary to clarify that @bruceschneier is not Bruce Schneier. (Or at least not the Bruce Schneier that runs schneier.com.) And by not thinking about whether Twitter truly authenticates the source of tweets, users implicitly trust the source.

Expect to see a GPG plugin for laconica soon. (And yes, I do realize how silly of a statement that is.)

And while you're here, be sure to subscribe to the Fortify Blog. Those are all folks who do development and security, and do them both pretty well.

New Year Rundown

2009-01-07T00:13:00.000Z

I've been away from the blog for a bit lately, mostly because of work on a couple of projects that have not necessarily taken all my free time, but they've not lent themselves cleanly to a bloggable idea.

For security experts, there's no real news here. For developers, some of these tidbits may be of interest.

There's a big debate about whether pen-testing is dead, dying, evolving, or thriving. If you really want my opinion on the matter, pen testing is no less important than it has ever been. However, I think that enterprises need to shift focus from picking their jaw up off the floor to seeing how they can actually correct the issues. Pen testing will always find flaws that no other form of testing can. And it can provide good "shock value". But pen testing doesn't solve problems. For those who have pen testers in the enterprise, they need to understand that the pen test is not the end game - more defensive applications are the goal. In fact, I don't think the focus-shift that's necessary reduces the need for pen-testing, but rather increases the need for good pen-testers with good documentation ability.
Gary McGraw and Brian Chess did a superb job culling metrics from nine different enterprises to develop a maturity model for where enterprises are in their application security programs. As you've seen me say before, it's time for us to get the information that's in the security experts' hands and properly translate it to developers who are responsible for fixing findings. See the report here.
Every so often I get to work on another scenario for clickjacking. It really, really scares me. Certainly, the victim audience would be somewhat smaller than the general XSRF audience, but to think that you can use clickjacking to work around XSRF protections (including CAPTCHA) is frightening. If you're in control of it, make sure your site has some framebusting code. And even that's not 100% effective. (Considering IE can force an iframe to load at a particular security zone).
Regarding the MD5-collision-fake-CA attack demonstrated at 25C3: It's a very cool attack. And it completely negates the purpose of CA's - to validate the authenticity of a site. But who are the victims in a successful attack? The victims would be the people who are susceptible to phishing scams or DNS poisoning, but actually verify the authenticity of certificates. Sure, the browser will be fooled, but even without properly faking a CA, how many people who fall for phishing attacks don't click "Yes, I really want to do this foolish thing" when the browser warns them?
Regarding twishing: nifty idea. I wish it were mine. You can actually see the day that people got twished by the sudden change in their posts that have URL's in them. So why is twishing more severe than making thousands of fake twitter accounts? There are two reasons: 1) Twitter promptly disables ID's it deems to be automated spam accounts. Normal user accounts that are suddenly used for sending spam will pass more heuristics for legitimate use, and 2) real people already follow (and trust) the real users who got twished.
Attackers are continuing to use open redirects in Flash for new phishing attacks. Yes, just like Java applets or ActiveX controls, your Flash movies need to be analyzed for potential security flaws. Although there are lots of nifty attacks involving Flash, the simplest are still the most effective.

And...oh yeah! Happy New Year! It's a delightful time to be in the security industry, and a very good time to be a developer who understands defensive programming.

CAPTCHA-Jacking

2008-11-21T17:07:00.001Z

RSnake and Jeremiah Grossman did a really good and thorough job of going over clickjacking and many different ways that it can take place. And until I sat up one night and made my own example, I didn't consider how easy and how serious it was.

Before reading on, please note two things: 1) I'm not claiming to have discovered something new, and 2) I'm not recommending a new name or anything. Rsnake and Jeremiah did all the work and listed a whole series of things that could happen that they admitted were not exhaustive.

However, the most common way to work clickjacking is by completely hiding the target site in a transparent (0.0 opacity) iframe over "the red candy-like button". A teammate and I worked through a proof of concept, though where the idea was to make the target site visible and then use div's above the iframe to hide all the parts you don't want. The most common example would be to have the user solve a CAPTCHA. There are plenty of sites that explain that using a CAPTCHA is a great way to eliminate XSRF and clickjacking all at once.

RSnake and Jeremiah were right - the best way to avoid clickjacking is by using framebusting code. That solves a couple of other problems (although because with IE you can specify a security zone for an iframe it's not bulleproof, but at least you could have noscript that warns the user they might be getting clickjacked) such as dealing with DNS binding attacks. And if users were better about using different passwords for different sites, you can always ask for their password for sensitive actions.

Favorites Scmavorites

2008-08-29T11:09:00.000Z

Okay, a hundred sites have posted information on the iPhone exploit where you can bypass the security code required to unlock the phone. I don't think as I was playing with it last night that I discovered anything that nobody else has discovered. But I'll give a run-down of all the nifty things I was able to do with it once I got to the favorites screen:

If a single favorite has a URL, you can tap that and get Safari - the full shebang, so go to a jailbreak site. Game over. I think the security code is stored on the SIM, however, so this wouldn't necessarily bypass that - but since the phone is jailbroken, you should be able to run a telnet or ssh service in the background (good luck following that IP address for long, though).
If the favorite has a physical address, tap that to get to maps. More on that later
From Maps, put in the name of a company you know has a website. When the pin comes up for it, follow the link - back in Safari. Game over - as above.
From Maps, you can also see the home address of every contact on the phone. Or overwrite the contact information for every contact on the phone.
If a Favorite has an email address, you can tap the email addy to get to a Mail compose window. Cancel the message, and you have *full* mail access. Also, if there are links...
Hit Text Message and you go to the SMS composer window. Cancel that SMS message, and you can read all their previous SMS messages.
If the victim's Home button is configured to go to iPod, then you get full iPod controls.

Now, before you think I've gone all gloom and doom on you, I haven't. That's a very targeted attack against a single person. The most common way this would happen would be as a social engineering attack. I often get asked if somebody can use my phone because their ride hasn't shown up at the bus stop yet. The Emergency Call feature is what that's for - press Emergency Call and tap the numbers you need, but you don't get access to all the other junk. So this is a one person at a time sort of attack. This isn't some freaky remote exploit (not that it couldn't be).

There are a couple of things I haven't experimented with on this. First, I've only got one iPhone and not a budget for doing research on the iPhone, so jailbreaking it while it was locked could brick my phone at my own personal expense. If somebody else wants to hit a jailbreak site with a "locked" phone, be my guest. Second, some websites are able to open Maps from Safari - this works just like opening Youtube. Can you also open Stocks? Notes? Arbitrary other app on the phone?

And of course, Apple will probably have this fixed in the next rev of firmware (putting off copy/paste yet again). And until that time, you can either make new favorites with just phone numbers, or you can remove all your favorites, or you can change the home button behavior to go to the home screen instead of favorites. Or you can avoid getting your iPhone into the hands of strangers.

On Source Code Review

2008-07-23T23:39:00.000Z

First of all, Jeremiah Grossman's periodic Web Application Professional's Survey is online - so go take it.

That being said, I've kept quite silent on the value of static source code analysis for awhile now because I'm pretty sure what the reaction will be, but one of the questions on the survey was regarding which measures to application security go first.

There have been several places where static analysis has gotten a dissed, where it might not be necessary. Most notably of which, I think Fortify Software did their own software a disservice at the Iron Chef Blackhat edition at Black Hat last year. The competition was between some of their source code analyzers and some of their dynamic analyzers. The application testers won hands down.

Before I begin, know that I believe that there is no silver bullet to application security. Nor do I think static source code analysis is the "best" method of finding vulnerabilities. Here are some of the valid or most important reasons that static analysis should not stand alone:

Static analysis is really best at finding semantic flaws - bad API use or failure to use certain API's, etc.
Static analysis doesn't give compelling pretty pictures and videos of your application giving up information. The results of a static analysis are only meaningful to developers, and then, only meaningful to developers who understand the real risk of the types of findings.
Static analysis almost always requires really expensive tools to do a really, really good job. There are grep types of analyzers, but they don't follow taint through an application.
Static analysis may analyze components of your code that don't get used. There are still prioritization decisions to be made.
Static analysis tools can't find logical flaws such as privilege escalation or XSRF.
Static analysis has different requirements than black box testing:

Developers who understand the code and can fix it
The source code
For many tools, the code needs to at least build (doesn't have to run)

However, there are some really, really good reasons static analysis should be a part of your security toolbelt:

Static analysis can find vulnerabilities that dynamic analysis can't - corner cases. "This cross-site scripting flaw only exists on Tuesdays" - if your application was tested in a running state on Monday, you won't know that the flaw exists. Thread safety issues are very bad for an application, but a black box test of an application might never cause one to come up, and if it does, it's nearly impossible to reproduce, and the results don't say to the oracle that it was that type of vulnerability. (For example, the application gave you access even though you used the wrong password.)
The results of static analysis are meaningful to developers. They get lines of code back where untrusted data enters the application, where it flows through the application, and when it exits the application. These are the exact lines that the developers need to fix, which a black box test alone can't give you.
Since the results of a static analysis are geared toward the developers, it provides "instant training" for developers. "What does it take to make this shut up?" (While I prefer developers understand why you want it to shut up, finding all the places is pretty good, too.)
Static analysis can happen much earlier in the development process, long before the application is functional. This gives black box testers more time to test the really cool stuff that static analysis can't find.
Static analysis can take place as part of a build process, automatically generating problem tickets and/or preventing the promotion of code with high-probability, high-risk findings. This can be done with automated black-box tools, but it requires a running environment - many more moving parts.

So I'm convinced that as long as Iron Chef Blackhat is run the same way as it was last year, static analysis will always lose simply because to a spectator, the results are just boring. However, that doesn't mean that it shouldn't be a very, very vital part of the development process.

Coding is a Science, not an Art

2008-07-02T22:44:00.000Z

This has more to do with coding than engineering - two different phases of development.

When I've done code reviews, when I very clearly see a flaw and point it out, the first response is denial. (See The Five Stages of Web Application Security Grief - the devs have the same initial phase.) Developers are so quick to point out the really old defenses (it's a hidden form field; we validate that the drop down list only contains the values we expect when we render it). When you clearly explain the failures of those defenses, they move on to pure denial ("you have to show me"). Then you show them.

It doesn't have to be this hard.

Coders, know that writing code is not an art. It is a science. If it's a science, a found failure is not a comment on your value as a human being. It's a comment on your tendency to make typos, not press the right key, or simply to not have adequate information to execute the problem at hand. If I were to say that your theory has a flaw - that hurts. You've really invested something of yourself into that. But if I simply point out that you failed to carry a 1 or to consider the null hypothesis, or to turn the knob before pressing the button, it hurts much less.

Engineering is different. But if coders (myself included) were far less defensive about their code and actually valued it enough to take recommendations on how to make it better, we could get to the making it better part much, much sooner. Value your skill enough to allow others to help you make that skill better. Even the most elite of ninjas need training.

Drive By Password Changing

2008-06-29T23:49:00.000Z

Just glancing at some sites that I use day to day, I've found yet another that not only doesn't require the old password to change the password, but also has no other evident controls to prevent XSRF. And this one is a pretty big one, too. I notified them, but I'm sure I'll get a canned help desk response "to change your password, click on the Change Password link and enter your new password twice".

While I don't totally disagree with Billy Hoffman's paranoia of all things Web 2.0, you would think that the more Web 2.0 sites would actually be more concerned about security. Password issues aren't specific to Web 2.0, nor is XSRF. But you would think the people working on implementing new methods would have already figured out how to do the old methods right.

Data Destruction

2008-06-12T00:03:00.002Z

And I thought I was doing the right thing with tools like DBAN (when I only have a little time) or shred so I can set my own paranoia level high. I suspect at temperatures this high, that there's little magnetic remnant of the data. But you have to do this in a secure place (or shred first, melt later).

XPFA in Hollywood

2008-05-28T02:44:00.003Z

Well, it turns out that Cross-Personality Framing Attacks (XPFA) aren't just fact, they make good fiction, too. While Bruce Schneier asks his readers to come up with movie plot threats, the writers for CBS (at the very least) are up to the same. I saw an episode of Without a Trace tonight (Season 4, Episode 5 - or 75 "Honor Bound") where an XPFA ends up being a very pivotal plot point in the show. Certainly, there are other fictional shows where similar things happen.

It's unfortunate, however, that it doesn't just make for good fiction. These types of image-destroying attacks take place all the time, and real peoples' lives are being impacted because of them. And there's simply no real defense against it. Sadly, the only real victims are the people being attacked, and it's rare that the people who "fall for it" are inconvenienced. So there's little incentive for people who read fake profiles and ads to disbelieve what they read. This one really depends on people to be responsible, and just don't believe everything you read.

Maintainable Code

2008-05-22T22:55:00.002Z

I watched a fairly old talk by Nicholas Zakas on Maintainable JavaScript today, and even though it's not new information by any stretch, it's certainly relevant. And you might think that maintainability has nothing to do with security, but maintainability has a substantial impact on security.

First, a couple of statements about the talk. While most of the code samples are in Javascript, and some of the discussion is specific to JavaScript, it is certainly relevant to folks writing any type of code - er. except dead-end code that will never go to production, I suppose. (Unfortunately, you may think it's not going to production, but alas it will).

He mentions the following attributes as being fundamental to maintainable code:

Understandable
Intuitive
Adaptable
Extendable
Debuggable

These things certainly make it easier to add security to applications that don't have it. While some believe that web application scanning and a web application firewall can cure all that ails you, they're only part of a complete solution - fixing source code and writing good code from the beginning are critical to code defensiveness.

Another couple of attributes that Nicholas didn't mention specifically (but he certainly emphasized them) are consistency and testability.

Consistency is not only making a decision about code formatting (although cosmetic things like that make code review much easier), but consistency should apply to design patterns and library use. Consistency in design patterns helps code reviewers - once they've seen a pattern and how it's used once, they can begin to see "patterns in the patterns" - when particular algorithms are used and when they're not. A code reviewer can provide a much more valuable report when the developers use the same patterns. Consistency in libraries is critical to properly tuning static analysis tools as well as making recommended solutions that fit within the one scheme of frameworks in use.

Before I talk about testability, I'll talk about tests. Unit tests for code are very helpful during code review because they reveal how methods are supposed to behave. Not only should unit tests test for functionality, but also boundary cases and exceptions. If a function is supposed to take a number between 1 and 1,000, what happens when 0.999 is passed or 1,001 or 1000.001? Does the function fail gracefully? These types of tests help to reveal deficiencies in the functions themselves, and are helpful in revealing the desired functionality of those components. So if code is written in a way that it can't properly be tested (say, it's hard-wired to production data sources), there's a good guarantee that the tests are not being written or executed. And if they're not being written or executed, then you're missing two components - the guarantees that negative cases fail gracefully, and the external technical documentation about the desired functionality.

It was an excellent talk, however I don't totally agree with him on all points - most notably the use of closures. While I agree that closures don't solve everything, in many languages, they actually help the readability and understandability of the code. Simple is generally better, and closures properly applied can greatly simplify logic. (Yes, they can be mis-applied). And I'm undecided on extending objects you don't own. Javascript strings need a trim() function, and I've become pretty fond of Groovy - and it adds lots of functions I didn't know I needed (many of which take a closure as an argument).

So, go watch the video. And figure out where you can make things more maintainable. But like in all things - take small steps.

Somebody Changed My Password!

2008-05-13T23:39:00.002Z

Okay, not really.

On a very popular website the other day, I went to change my password. It had two of the three really common boxes required for changing a password: New Password, and Repeat New Password. Yes, they fail to prompt the user for their current password.

And this is on a site that not only allows, but encourages users to stay logged in. Their documentation is pretty sparse as it is, but I've not found anything on the site explaining to the ordinary user that they shouldn't stay logged in from a shared computer (where it's even more likely that just anybody could change my password).

So I sent in a support request. I understand there was a lot of talk in my support request about passwords and stuff, so any automated tool would probably think that I wanted to change my password and didn't know how. The only problem is, this "automated" tool took two days to reply to me - so I don't know if it's an automated response after all.

The response it took them two days to conjure started with:

Thanks for your email. To change your password:

So it took two days for a response, making me believe that a human being looked at my support request - and this is what they came up with?!

Now, most people probably already know the site in question. I won't say the site, but this makes it really easy to execute another good XPFA against somebody.

As a side note, I find it really interesting that there are evident XSRF guards in the change password form, but not the most basic of guards - the current password.

Combination Attacks and Metrics

2008-04-26T00:28:00.002Z

I think the most important benefit of blackbox and graybox application testing is the screenshots. It's actually not very helpful to a developer to just tell them "you had x number of XSS", but to show them the steps that were taken in order to do something really condemning to the application (steal credentials, money, install malware, start a worm, etc.) in order that those who receive it get a better picture of how it really impacts them.

However, at some point, metrics have to be made. Somebody has to know if site A is "better" than site B, or if site A is improved over last year.

But do combination attacks change the picture? When measured alone, 9.76% of websites were vulnerable to HTTP Response Splitting attacks, but only a trace had Insufficient Authentication, Authorization, or Session Expiration problems. I would assume Session Fixation would lie in one of those three. But how many sites actually had both? Where an attacker can send a URL to a victim with a known session iD, the client takes that ID because of a response splitting (actually, header injection in this case) problem, and the attacker waits for the victim to authenticate (not receiving a new session ID). Either of the problems alone is pretty bad. But in combination, that's very serious.

Another example would be cross-site scripting and key exposure. If a site has key exposure problems where an authenticated user can find the email address of all the users in the system by enumerating key numbers, there's an opportunity for spearphishing. But if you combine that with an anonymous, reflected Cross-site Scripting exploit, you can make a very compelling attack against users you know to be legitimate users.

How do folks roll those combinations into their metrics? I suppose that's where a consistent scoring algorithm such as CVSS (maybe not CVSS exactly) that takes multiple factors (combinations of vulnerabilities, for example) into account is helpful in keeping metrics that still show the weight of combined problems.

Simpson's paradox

2008-04-26T00:27:00.000Z

Evidently, it has other names, but Simpson's paradox is a statistical phenomenon such that the combination of success rates is the reverse of the individual success rates. For example, in each of 1995, 1996, and 1997, David Justice had a better batting average than Derek Jeter. But the combined batting average of Derek Jeter was better than that of David Justice.

It happens when one part of the sample is out of proportion to the remainder of the sample. For example, if the two had similar batting averages over the three year period, except one year, David Justice had three at bats and reached twice. His batting average for the year would be .667, but it basically gets "lost in the wash".

Now I truly understand why they say that you can make statistics say anything you want.

SANS Summit

2008-04-13T00:24:00.002Z

This week I'll be in Orlando at a SANS summit warmup before the training courses, which are next week.

I'm very excited about this one because we'll get to spend a lot of time talking, among other things, about how to roll defensive engineering and programming into the educational process for technology students.

Security is so easily exploited now because we never learned to program defensively (or never enforced it). So now, we're trying to go back and patch the dam. This is a great opportunity to discuss how we start to make brand new dams that don't need patching. And while I don't know if I would agree with IBM that the Security Business is out of business, I do agree that we need to make systems that are impervious to attack from the beginning.

Maybe I'll get Micky's autograph while I'm there...

Not a Failure

2008-03-21T21:18:00.002Z

I can't go into a whole lot of detail about the exam, but my results for the SANS GSSP-Java came in and I passed. The exam is still quite young, but some great minds are working on it - Ryan Berg and Andrew van der Stock, as well as having the backing of SANS.

My hope for the GSSP exams in the future is that they are actually affordable enough that a person without employment can actually get it. I know that accumulating, writing, and editing questions costs a lot of money, as well as securing an exam location, transmitting exams, scoring exams, communicating back to the people taking the exam, and managing the website. But for a corporation to pay for their people to take the exam in the first place does little for the corporation unless they're investing in the training of the employees as well. But it could serve as an excellent baseline for entry into a lot of shops, but for it to be effective as such, it needs to not cost a year's salary to study for and take the exam. I'm not certain at this point what SANS hopes to be the perfect place for the exam.

Take a look at SANS and see if you can schedule an exam date. The exam still needs some work, but testers can only help at this point because you have a chance to give input.

AntiSamy

2008-03-17T23:59:00.004Z

To be added to my list of ways to effectively allow HTML without allowing javascript, enter OWASP's AntiSamy library.

AntiSamy uses home-grown methods of being very specific about what is and is not allowed to come into the application. And what's very nice about it is that it already includes configuration for several profiles - online sites that allow HTML. These profiles somewhat match the profiles of those websites. For example, the slashdot profile is pretty restrictive, while the MySpace profile allows quite a bit more.

To be honest, I don't know how much better AntiSamy is than using a DTD, Schema, or RelaxNG to validate the HTML, *except* that there are additional rules that have to be validated with logical tests.

One thing that occurred to me while working on a mock-up of using XML validation to perform this validation is that <img tags (or anything with a remote URL) requires special consideration to deal with the possibility of XSRF against other sites. For example, if an attacker finds an XSRF vulnerability against some site, it's in their interest to get that URL injected in as many places as possible. One way to do this is with <img tags in sites that allow them to come from remote sites, or url() constructs in style attributes where a url is permissible. In order to deal with these, the best way I came up with is to have the server fetch the resource when the tag is entered, then when the page is rendered, to reference the URL locally. (This also gives the user the benefit of having a static version of an image, even when it expires off the original site).

Anyhow, cheers again to OWASP.

Password: Impossible

2008-02-11T00:00:00.000Z

Aviram had a post on how he thinks password complexity rules are a bad thing. To a degree, I agree with the post - the more complex you make password requirements, the more likely your users are to try to find some way to subvert that requirement (like Aviram did - change your password a bunch of times so that you can go back to the original).

Unfortunately, however, passwords are a core part of application security. Until two-factor systems become convenient for the user and cost-effective for the provider, password complexity rules are a fact of life. Right now, if a user wants to use two factor authentication, they're left carrying (or hooking up a webcam to) several RSA tokens, carrying a card in their wallet, and ensuring their cellphone is always on. Now, I like the idea of using SMS as a two factor verification as the odds of me losing my phone and my wallet (which has all my passwords) at the same time is pretty slim.

So, how I really feel about password requirements is that I do like them. For the time being, if all sites used really low-threshold password requirements, it allows users to reuse passwords. So what if an attacker can't brute force their way into your bank account? Do you use that password on some other system? If that site doesn't enforce a lockout or a change policy, then how likely is it that the attacker is going to be able to find out that you use that other system? Do you use the same identity on multiple systems?

So what is a user to do? For the typical user, I honestly don't know. I use a password safe with about a hundred entries in it. That password safe is on an SD/USB device I keep in my wallet. It's encrypted using AES, and a really long passphrase. I'm down to a very small number of passwords that I actually remember and know anymore. But it's a major inconvenience for anybody who's using passwords all day every day on different systems. To really protect your passwords, your safe needs to have a long passphrase and a short lock timeout. And that doesn't mean that attackers can't get the passwords from the clipboard or submitted forms. For an ordinary user, the first response is probably "why bother?"

Keychain is getting close to the level of system integration that makes it easy for users to use. However, not everything on Mac uses Keychain. 1Password adds quite a bit of functionality to extend the ease of use. But that's still mac only. On Windows, there's KeePass, which has some nice system integration and some additional features (like TAN's) that make it really nice. And since it's open source, there are alternatives for Mac, Linux, and mobile devices.

But I still don't think that gets the reach to all users the way it needs. Remembering to back up my password safe is a pain - I need to back it up at a few locations in the event that I lose my device, and I won't put it on the web where it becomes available for anybody else to download and bang on forever until they unlock it. I would have to protect the download with a really strong password, but then where am I going to keep that password?

And regarding the 90 day change policy - that is a good thing. Once an account is compromised, it could be months before it's actually used because, particularly with financial accounts (credit cards, online bank accounts, etc.), they tend to be sold in lots on the open market. The person who compromised the account is highly unlikely to be the one to ultimately gain from the account compromise - it's just an asset to be sold to the highest bidder.

Social Networking Threat: XPFA

2008-01-30T00:32:00.000Z

Okay - I didn't find a new kind of vulnerability or identify some brand new threat. We've seen lots and lots of cases like these:

A teacher fired for material they had on their MySpace page
People not getting a job because of information they put on their Facebook profile
People complaining that somebody close to them got their password and changed information on their social networking profile

What surprises me is that actually exploiting the non-existence of a profile isn't more prevalent. The idea that employers are looking at employees' or candidates' social networking profiles is no surprise. And if many people know that it's common, why don't we see more hijacking of a non-existent identity? If a person doesn't have a Facebook profile, but they have enemies, why aren't enemies falsifying profiles?

This has two benefits for attackers. The first is the revenge or get-even factor. If I can falsify somebody's private life and prevent them from getting a job, promotion, or even a date, is that of value to me? Depending on the job, promotion, or date at stake, the profile stalker could gain financially - think of all the domain squatting that took place in the early to mid 90's. Will we see a similar trend in individuals to protect their "personal brand"? Will we see indie rock bands have to change their band name when a disgruntled ticket buyer makes a fake version of their site on the social networking site du-jour?

The consequences of this to the victimized person are clear. Their name has been slandered by somebody who knew enough information about the victim to make a convincing (yet false) page. They will have to take time to build a new, true identity. They will have to take the time to explain to potential employers that there's a fake out there.

But companies are at risk as well. Companies who use this practice could potentially miss the best candidates, or be relying on false information. They could get rid of the best employees by relying on information they don't know to be real. This is the same story as small town teachers getting fired because parents found liquor bottles in the teacher's trash bin on Tuesday night (whether it was put there by the teacher or not). And I don't think we know for sure there won't be litigation in early termination or whatnot because of falsified social networking information. (Most states are "right to work" states, meaning you can be fired for no reason, so the potential for this is low).

All that being said, a couple of colleagues and I came up with a new name for the vulnerability: Cross-Personality Framing Attacks or XPFA. We'll find out if the name gets any traction.

So how do ordinary users protect themselves? For those who do use social networking sites, I recommend using a different password for that site than any other, and change it frequently. Of course, I recommend this anyway. And limit the visibility of the information on the site. And don't put anything on there you wouldn't want your mom to see.

For those who don't use social networking sites (or the most popular ones), I'm not sure how much protection there really is other than claim your spot early. The problem is that you'd have to keep your profile public and up-to-date with completely benign information in order to get it linked high in search engines. Which is sad - the way to protect yourself from a fake social networking profile is to use social networking?

Perhaps the best solution for users is not to make enemies. And the best solutions for companies is to make sure they know the site is for real before trusting it.

Incidentally, I neither condone nor condemn employers using this practice. I don't necessarily like it, but in general, it is information that people want for the public to be aware of. If I were hiring somebody who had written a book, I would probably at least skim the book before hiring them. Is this that much different?

Using Web 2.0 to Identify Phishing

2008-01-09T20:10:00.001Z

noam at SecuriTeam has started an experiment with searching for a sender of an email to possibly identify spam. I had had a couple of ideas with regards to phishing (not spam in general) to help combat it, but haven't spent a lot of cycles on it.

Currently, most phishing site detection is dependent on a RBL to identify a phishing site. But botnets are beginning to be the front door into those phishing networks, so you could actually have hundreds of thousands of users follow a phishing link before the same web server is used twice. Also, because of the famous security question with the same responses as expired/mismatched certificates, the user's natural response ("Click Yes if you want to do this dumb thing") is actually the wrong one.

I had come up with a couple of anti-phishing techniques, but it would require buy-in from frequently-phished companies who wanted to cut back on their own fraud.

The first idea centered around using heuristics to determine if a site is trying to look like the victim site. If XYZ.com is the real site we're trying to lure users from, XYZ.com knows what their look and feel is - the colors they use, the fonts, spacing, key phrases they use, logos, etc. Browsers actually have enough information when rendering a site to do a lot of these heuristics. Now, when a user visits a site, and the color scheme closely matches, and there's an XYZ.com logo, and some words similar to XYZ.com, and a login form, but the host is not in XYZ.com's address space, the user is warned. Only now, since we know that the phisher was trying to lure XYZ.com customers and not ABC.com customers, we can give the user three choices: 1) Click YES if you want to go to XYZ.com (the real correct answer), 2) Click NO to do nothing, or 3) Click this "I understand this is silly and I wish to go to ECKSYZ.com" box and click You've Been Warned to go to the phishing site. It's not perfect, attackers would change just enough to go below the threshold, but depending on how much they wanted to reduce fraud, XYZ.com can change either their heuristics or the threshold score. Or the user could change the confidence level.

Another idea I bounced around with a colleague centered around using the user community to make a determination about the legitimacy of a site. If you visit a site that has a login form, the browser does a check against del.icio.us or Alexa or even Google to determine if the target site has been bookmarked before, or is highly-ranked, or if it's been searched yet. The warnings on these, unfortunately, would tend to be a little less clear. "Nobody has ever bookmarked this site, are you silly enough to be the first?" or "Hmm...this site isn't very popular - sure you want to do this?" And of course, attackers can create lots of fake social bookmarking accounts and bookmark their own phishing site.

So for you plugin developers with gobs of time, go write those so we can see how ineffective they really are.

Mozilla Prism

2007-12-27T00:55:00.000Z

Mozilla Prism is another Experiment in the Mozilla labs right now. The idea is to make desktop launchers for web-based applications where you launch a prism application, and you're in a browser totally dedicated to that application, which will provide a little better interactivity with the desktop, making web applications feel more like desktop applications.

As a security tester, I love the idea. But the one benefit I would hope to get from it (each webapp being sandboxed, so you can have multiple logins to the same application) is still on the to-do list.

That being said, didn't Java Web Start die already?