cat slave diary

Category: Security

  • IE exploit spreading via SQL injection

    It’s no news that the latest 0day for IE is spreading via SQL injection attacks. What is news is why are we still suffering from SQL injection? We’ve known for over eight years how to utterly end SQL injection. I’m sick of writing about it. We should not be talking about SQL injection any more. 

    This is a call to arms – SQL injection is a done deal. It stops today!

    I call on:

    • Acquirers of software to inspect nvd.nist.gov and determine if the software your about to acquire has ever had SQL injection. If so, make sure it does not use dynamic queries today. If it does, do not acquire or use it. 
    • Managers of software libraries to investigate all software in their possession in the same way. If it has had SQL injection in the past, it’s likely that it still has dynamic queries today. Write to the project and demand a version that has no dynamic queries. Make transition plans to get off faulty software if they do not respond or cannot respond in a reasonable time frame. We did this for the Y2K effort, it’s not that hard
    • Open source project houses such as Google Code, Microsoft’s CodePlex and SourceForge should put projects on notice that have dynamic queries that their downloads page will be disabled by Dec 31, 2009 if they have any dynamic SQL queries in them. I know this is a lot of work, but I can’t think an easier way to provide outreach to so many projects simultaneously.
    • CISO and CIOs and lead architects to outlaw the use of dynamic and concatenated queries in your policies and coding standards and to mandate the use of un-injectable alternatives
    • Developers to stop using dynamic queries and concatenated strings in prepared statements. With all haste, migrate all your code to prepared statements, stored procedures (noting that these still may have issues), or an alternative data storage mechanism, such as Hibernate or Active Record 
    • Frameworks to deprecate and eliminate dynamic SQL query interfaces (Java’s Statement, PHP’s mysql interface, etc) with extreme urgency. Today, they should emit warnings in DEBUG mode, and in six months to a year, they should cease to exist
    • Frameworks should inspect prepared queries in DEBUG mode, and if there’s a WHERE clause without a placeholder, the query should raise a warning during compilation or runtime depending on how your language operates. Of course, there are SQL queries that have where clauses that are static, but these are the exception not the rule. We need to help developers pin point weak statements, so a pragma or comment mechanism to shut the warning down would be helpful too
    • If you audit or review source code, you should mark all dynamic SQL queries critical. Because they are critical risks. Without understatement or hyperbole, dynamic queries are an obvious clear and present danger to the world’s IT infrastructure and they simply do not need to exist.  

    SQL injection stops today! There’s an awful lot of code that needs fixing, so let’s get cracking.

  • WordPress 2.7 released with easter egg

    As I noted a few weeks ago, WordPress has had an obfuscated easter egg in it for some time.

    Despite reporting this security defect / software engineering malpractice to two different WordPress folks (the author of the excellent WP development blog, and the security team’s e-mail), 2.7 was released with the easter egg. 

    Hopefully, this will be resolved in a future release.

  • WebScarab For Eclipse

    This lunchtime, I did something I’ll probably later regret: creating a new project. As if I don’t have enough on my plate already.

    The idea has been rattling around my head for a while – I use Eclipse nearly all day, and I figured that Eclipse is a great toolchain hosting platform. It gets rid of some of the issues surrounding the re-platforming of WebScarab Classic features to NG, which seems to have been stalled for a long time, and adds more of its own issues, such as what will I do with other projects I have commitments such as ESAPI for PHP and the OWASP Guide.

    The biggest challenge is the initial muck work of porting software not designed for Eclipse to Eclipse in a reasonable way and not getting side tracked with all the great ideas I’ve got – all of which rely upon the engine and basic functionality to exist prior to even starting them.

    There’s a lot of ideas I want to get into a tool, and so if you’re interested in helping, please call by the Google Code site:

    http://code.google.com/p/owasp-webscarab-eclipse/

  • Black Hat 2008

    Well, I’m back from another year at Black Hat. This time, I taught one of my company’s 2D Web Application Security courses.

    I think I may have been one of the very few courses that concentrated on defense, which is Black Hat’s tongue in cheek slogan (“Digital Self Defense”). I taught the folks in there (about a 50/50 mix of devs and PMs/architects/designers etc) not only “this is a SQL injection” but hey, we have a complete solution for this, and this is how it works.

    The class was originally 15 – 20 in size, but ended up being more than double that. I’m pleased with the outcome and how many folks really liked the course. Hopefully, it will lead BH into more actual digital self defense rather than just claiming that territory whilst promoting offense, offense, offense.

    I met up with a fair number of folks, including Dinis, and all too briefly Jeremiah, RSnake, Arian Evans, the blokes from the NAB (Justin et al), my mate Justin Derry who is now at Fortify, and a bunch of others.

    I took in almost all of the appsec 1.0 / webappsec 2.0, except for the last session of the last day. It was a good conference and well worth the visit this year. There are always a couple of weak talks, including the one from the network pen testers who have cottoned on to 0days involving web apps which I found very amusing because they thought they were so hard core and l33t. Here’s a hint guys: if you can’t get 8-20 0days out of any web app, you’re not doing it right. It’s like whack a mole or stealing candy from a sleeping baby. And authorization attacks are automatable if you have the right tools. The only interesting thing from that talk was an extension of the old file format jumble, where some file formats have headers and some have trailers, and thus you can make a valid file that is both one thing and another. They had a GIF and a JAR. Past precedents include both ELF and Win32 binaries (from back in 2001) in the one binary, the 1×1 pixel image that is also a PHP exploit (my favorite). I’m sure there’s others prior to 2001.

    Anyway, enough ranting for me. I had a good time, and I can hardly complain as I was sponsored there by my employer and thus bore nothing of the real costs of this trip.

  • OWASP Guide 3.0 and Coding Guide 2009 Start

    I’ve been busy over the weekend.

    I met with Blake Turrentine at a diner near where I live. We had a good long discussion over breakfast on the future of the Guide 3.0.

    The Guide 3.0 will be about how to design apps and code securely. That’s it. Only positive controls will be discussed unless the negative controls rule right now. For example, the Services “Databases” section will contain only the following sub-sections: Best practices (use an extremely low privilege account unique to your app, use an encrypted connection, store the connection credential securely, etc), Active Record / ORM, prepared statements, stored procedures.

    The pattern in each sub-section will most likely be:

    • What to do right
    • Risk level of this control (All, Low, Medium or High risk apps)
    • Why this works (using ESAPI if it’s got something to say about this control)
    • Code snippets doing it right
    • What this prevents (links to the testing or code review guide and any publicly known attacks using this mechanism)

    There will be a “Worst Practices” sub-section containing Dynamic queries, and Stored Procedures Gotchas (discussing string concatenation, calling out to native features, and the use of exec, etc). The idea is that if there’s zero noise on bad controls, you’re more likely to do the right things, particularly if there’s supporting code.

    It should be nice and short, especially in comparison with the 2.0 version as there will be only links to testing or code review material. There’s no point in repeating that material.

    Although pen testing is considered sexy and a little bit naughty by the meejya (and thus “newsworthy” when plainly it is not), coupled those folks who consider themselves hard core l33t haxors get to go to all the nice parties with ladies of negotiable value, I think pen testing is not the best way to deal with crappy paradigms. If you’re still using dynamic queries, you have soooo much work to prove that you’re “safe”, and every few years when a new technique that exploits the root cause comes along, you’re hosed.

    However, if you had spent far less time and money to use one of the three “safe” methods above, you’ll be “safe” for most values of “safe”. We have seen zero mechanisms to attack prepared statements in the last eight years. That’s a very successful control. Therefore, testing for SQL injection is sort of pointless and we can move onto the real golden apples, like direct object references and business logic flaws.

    The Coding Top 10 will be a distilled version of the same material, but by necessity, it will concentrate only on ten items, instead of may be 200-300 items. Neil Smithline has agreed to take a shot at it, so I need to touch base with him this week.

    In both cases, I’m looking for a healthy dose of contributors as there’s no way I could do the amount of out of hours work I put into the OWASP Guide 2.0 again. Tanya would kill me for a start! If you think you can help out, please join the OWASP Guide and Top 10 mail lists, and shout out!

    Please don’t do it because you want to be invited to all the sexy parties and have ze ladies fall at your feet, or to get wealthy on the residuals. I will make this prediction right now: neither document will be feted by the press, and neither document will get much traction at the trendy conferences. Even though they will be the best things to help developers and businesses code properly ever written. Let’s make a start and see how things go.

  • Feelings of Rejection

    In other news, all my talks for OSCON were rejected again. Why did I bother? I should have paid attention my last year’s rant. Most likely, I will have to give up on submitting papers to certain open source developer’s conferences as honestly, why bother doing the work of doing the research, creating the paper and slides only to be rejected? Luckily, two of my submissions were from colleagues, so I didn’t squander a lot of resources on those talks, even though for example, I’m working on porting ESAPI to PHP, which is the subject of one of the rejected talks.

    I’ve identified the following security talks for those security folks still considering going to OSCON (although I’d recommend saving your money for OWASP USA as we already have a schedule of 45 web app sec talks in three tracks, and two full days of tutorials, including several two day courses where you’ve got an actual chance of learning something. Just saying.)

    So five talks and two three hour longer talks. Here it is in graphical format for you:

    microsoft-powerpointscreensnapz001.png

    A couple of the talks are likely to not offer that much in the way of solutions. Sadly, no Ruby, Python, administration, database, emerging topics, or people security talks. Worse, there are no Java security talks, which for an semi-incomplete track, I found sort of astounding, especially as I submitted two Java security talks and one PHP talk. The official “security” track has two three hour talks, both detailed above. Even if you look at it from the point of view of OSCON having 16 tracks, hopefully with equal time for all of the tracks assuming there was a lot of competition for speaking slots, there should be 215/16 = ~ 13.4 security talks, not 7.

    Although I am glad my friends are accepted whilst talking about security, I think OSCON needs a new program committee. This one is broken.

  • HttpOnly Update

    Jim asked a great question – what is the current state of the nation for HttpOnly? I’m glad he asked!

    Pass – read/write cookie protection

    • IE 7.0
    • Firefox >= 2.0.0.5
    • Firefox 3.0 beta
    • Camino 1.5.4

    Barely Pass – read only cookie protection

    • IE 6.0
    • Opera 9.50 beta

    Fail – no cookie protection

    • Safari 3.1
    • Firefox < 2.0.0.5
    • Opera 9.2.6 (currently shipping stable version)

    Coverage of HttpOnly Support

    According to my Google Analytics account, 93.6% of browsers support HttpOnly for preventing being read. The worst offender is Apple, with a marketshare of 5.3% on my heavily trafficked site. They have no support whatsoever. In fact, they’ve had a bug outstanding for some time that no one is assigned. BAD APPLE!

    Conclusion

    Most sites do not use cookies for anything other than the session ID. This is best practice. In these instances, there is NO REASON for them to read or write the cookie using JavaScript. Although there are ways around HttpOnly (some work better than others, depending on your browser), it is worthwhile for frameworks and app server vendors to send this tag automatically. Those very few folks who really need to be pwned should have the ability to turn this protection off.

  • ESAPI for PHP is go

    I’m working (slowly) on porting ESAPI to PHP. This will be great!

    So just in case I keep on having a life after hours, Jeff kindly created an ESAPI for PHP project. If you care about PHP security, come help us finish the port. It’s only 3900 lines of code, and I’ve ported like a 1000 of them already.  

    Why ESAPI? 

    Well, it’s a ready to use secure coding package. The ESAPI library is not about avoiding attacks, it’s about software engineering for web app security. ESAPI deliberately targets around 80% of security features of the average application (whatever your application is!) with the reference implementation, and for that 80% it does security 100% right so you don’t have to.

    ESAPI covers nearly the entire OWASP Top 10, and some other issues besides:

    • User object*
    • Authentication* membership management classes – we have coded createUser, and friends, login, logout (with safe session and cookie termination), disable account, generateStrongPassword, automatic password hashing including salts, etc. 
    • Access control*
    • Access Reference Maps* – direct to indirect object reference maps. No longer do you need to jump through hoops to protect primary keys, files and other things that people can trivially tamper. Instead of filename=report.pdf, you can now trivially turn this into filename=4fd8Xz
    • Encrypted configuration*. No more clear text passwords in config.php
    • Encrypted and integrity protected cookies*
    • Encrypted and integrity protected hidden fields*
    • Hard core encoding utilities*, such as HTML, JSON, XML and LDAP encodings that only do whitelisting
    • Easy to use Encryption support … with only access to SHA256 and AES other quality algorithms. No MD5 or DES here.
    • Easy to use strong random number support … no more weak random values
    • Executor* – safely call the operating system
    • Integrated intrusion detection* – security events are automatically generated and logged
    • Integrated Logging* – using log4php by default
    • CSRF token management* 
    • Thresholds* – automatically set rates for certain actions to help prevent brute forcing
    • Validation libraries* that help you do white listing by default 
    • Test suite to prove coverage and test all functionality 

    Things with a star (*) are simply missing from PHP today, which is surprising considering EVERY SINGLE web application MUST have them. This is despite 5698 functions being defined in PHP today.  

    If the PHP core folks want to talk about adopting these in PHP by default, OWASP would be more than happy to donate the code and re-license as appropriate. All PHP applications deserve this level of security.

    So, please feel free to join us.

  • Reaching for the high hanging fruit

    My current research is mainframe security as it applies to web applications. This is where the high hanging fruit (the golden apples) lie. If you can

    a) fake or bypass authentication
    b) fake or bypass authorization
    c) spoof logging or otherwise destroy accountability
    d) interact directly or indirectly with a deeply nested service of value
    e) manipulate data to violate integrity (creation, update or delete)
    f) view data (read)

    you are most likely to pwn the high hanging fruit. It’s actually amazing to me how LITTLE information is available on securing this stuff, and how often products which are marketed as “enterprise ready” and “secure” are actually not worth running a faulty bidet let alone left in charge of multi-trillion dollar a day roles.

    Then there’s the dumb architectures which often use clear text protocols, unauthenticated transfers (often using ftp or worse), batches with no integrity and no accountability controls, and so on. This field is amazing that no one has taken the time to really learn how to do it properly. It is not 1969 any more. The days when the data center was guarded and that’s how the punch cards arrived and the tapes left no longer apply.

    However, there’s a few protocols and common transports which need some help first. I’m going to blog on those in the near term future.

  • Let’s talk mainframes for a bit. Part 1: Background and AuthC

    In larger organizations, the back end of a web application is a mainframe. The mainframe is the final frontier of application security:

    1. Uses a platform few if any in the application security industry know about
    2. Those who do know mainframe security rarely interact with the outside
    3. IBM trains young devs in how to program COBOL, RPG, or PL/1 for its large institutional clients, but they rarely – if ever – get taught the fundamentals of security, risk management, or even the basic security features of their platform and language
    4. Most of the security features of the mainframe’s core languages simply don’t exist. For example, standard COBOL does not support SHA512. It has to call out to do that.

    This is a shame as the mainframe is actually a damn fine security platform:

    • One authC/authZ framework to rule them all. And it’s actually pretty good.
    • A transactional model which is inherently thread safe
    • Mandatory access control to data if you desire 
    • Logical partitioning of hardware and resources in water tight sandboxes that Dinis Cruz wishes was in .NET 🙂 (sorry, Dinis, couldn’t resist)
    • All modern IBM mainframes come with a hardware security module (HSM, a crypto card which can store keys and do safe crypto processing)
    • and on, and on, and on… 

    The problem is that most mainframe code does very little to protect itself. The original risk model is a 3270 green screen dumb terminal running in a locked down environment with fairly hardcore presentation layer access control (generally a menu system) being used by trusted staff members who liked their jobs. That same code is now not only well past the age of consent, it’s done the binge drinking thing, grown a goatee, moved out of home, shaved the goatee, and is thinking seriously about starting a family. And suddenly, it’s being hooked up on a blind date with code of negotiable value who likes to party by picking up all the keys in the bucket. Metaphorically speaking. You know where this is going. In a typical web application scenario, we have the following architecture:mainframe-security-architecture.pngThe usual problems we have here include:Authentication We talk to MQ via… one single connection. So does the database. So what’s the big deal? Well, in many systems, database queries are designed with this in mind. If you don’t, we have direct object reference attacks which result in loss of fine grained authorization. But let’s assume our data architect was clued in, and we see SQL like this:

    SELECT * FROM orders WHERE orderID = ... AND userID = ...

    or

    SELECT * FROM orders WHERE orderID = ... AND roleID in (SALES_ROLE, MANAGER_ROLE, ...)

    This prevents the attacker from seeing records which are not owned by the user, or in the latter case within the correct role. Mix and match to suit your requirements.Back the mainframe. We talk to the mainframe through something like MQ or SNA Server. The mainframe is running a piece of code written explicitly for a 3270 or 5250 terminal using menu level security or even better with a proper protection profile from RACF. Back in the day, each of these semi-smart terminals had their own logical address (LU) telling the sys prog who was logged in, where it was, and way more importantly… that a trusted staff member was doing stuff.When exposing mainframe transactions to the enterprise, the industry’s first shot at SOA was the Enterprise Message Bus, later renamed Enterprise Service Bus and lately seen down in the docks sporting the SOA name tag now that we’re doing exactly the same stuff as we were doing in the early 90s … using unreliable web protocols instead of reliable mechanisms like MQ, Biztalk or SNA Server.Next week, we start to see why it’s important to not only impersonate the correct user, but not to give the transaction more privileges than you need.