Blog

  • 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. 

  • Pizza. Check. Violet Crumble. Check. Biggest Loser. Check! All systems go!

    I don’t know why I do it, but I invariably wobble on diets on Tuesdays. So I’m doing the only thing I can – I watched the Biggest Loser with a few slices of Hawaiian pizza, a diet Pepsi, and a Violet Crumble to wash things down to get a bit of a sugar rush later.

    I’m down from 155.1 (last Tuesday) to 153.5 (last Saturday). Which is 1.6 kg. Which is 1% of my body weight. Sweet.

    Been a good boy except for tonight, so with some luck, I will not bounce back too much this coming Saturday from the pig out session.

    The folks on Biggest Loser are doing much better than I am – one guy made 100 lbs tonight, which is 45.5 kg in either 9 or 12 weeks (it’s not clear from the program as they wobble themselves on timelines). That really can’t be healthy, so I prefer my 1% body fat loss. If I keep that up, I’ll be truly svelte in 2009 or thereabouts.

  • No more excuses – weight loss starts now

    I’m home for the foreseeable future, so it’s time to stop blaming being on the road for getting the right food down my neck, and not exercising.

    It is difficult to get high quality, low sugar, low GI foods in the USA. There is a myth that everything is high fat here, but it’s a myth. Sure, there are heart attacks on a plate, but you have to go find them or make them yourself. I think the bigger problem is serving sizes and high sugar content, rather than the fat content.

    A good example is butter. Butter is the devil here – it’s practically impossible to get real butter at a sandwich bar. You can get butter at the supermarket if you look hard, but the stuff put out at restaurants is rarely butter. A customer I visit regularly has a cafeteria at which it’s hard to eat badly at … except it is easy to get lots of mayo, ranch dressing and other tasty condiments slathered on your sandwich which are far, far worse than butter. Tuna salad is not precisely “salad”, but full fat mayo and tuna. Most sandwich stuffings have a creamy, high fat texture.

    We were at the supermarket earlier tonight, doing the first weekly shop for my new food choices. It took a long time, and cost a lot of money. I was a bit shocked at the check out. Sure we bought a LOT of things you don’t need if you buy pizza every night. I now have the hugest collection of spices and seasonings I’ve ever owned at any time in my adult life. Our shop came to $320. That’s close enough to $AUD 350. I hope that future weeks will not be so expensive as we will not be buying 20 or so spices.

    Shopping took nearly as twice as long as our normal shop. A typical example is searching the nutrition panels on about 20 different margarines, I found the lightest, least sodium enriched margarine with no sugar (hard!). You have to be careful to avoid buying things with unnatural sugar additives content – “normal” US butter is churned with sugar (to create “whipped” butter), and pretty much all the bread is sickly sweet with sugar. That row in the supermarket literally stinks to my Australian nose, even after nearly a year of being exposed to funny tasting bread. Tanya threw up there tonight – the first time she’s puked in the supermarket.

    The margarine folks don’t use “margarine” – they use “spread”, but it’s margarine. I found a “lite” version of ICBINB, which had 85 mg sodium and 50 calories per tbsp. I then compared that to the full strength butter we normally use, and it has 85 calories and 85 mg sodium per serve. That actually puts our full fat butter in the lower end of the various margarines, and only a bit worse than the probably less than pleasing “lite” spread I nearly bought. For the amount of butter I use in a week (about 2 tbsp), it’s just not worth it to take the hit in taste. I took the same view with milk (4% fat is “light” for most foods) until I started having breakfast every day. Now, I am on 2%, and there’s only a minor taste difference.

    I think cost and serving size is the reason why US folks are a bit chubbier overall than most countries. It costs a lot more to eat healthy here than it does to buy a “Man sized” frozen dinner, or to go out and buy a massive serve at the local diner or chain restaurant. Despite this, most US folks are not that fat, despite the constant bleating in the media and the impression we get back in Australia. I think there is one other person in my company of a comparable size to me. The rest are skinny and lead active lifestyles.

    Serving sizes are killer here. You can easily buy a meal, cut it in half and take half home with you. Most restaurants have an ample supply of boxes to do exactly that. Considering how litigious the US is, I’m surprised the lawyers don’t step in and stop places from doggy bagging stuff so as to prevent lawsuits from customers who take food home in a white foam box with no reheating instructions and subsequently get sick.

    My problem has always been serving sizes. I don’t have an “off” switch. I will eat until I am physically incapable of eating any more – I feel awful for hours afterwards. I ordered a 12 oz steak tonight. I have no idea how big that is in real measuring sizes. So I’ve bought a set of precision Salter scales, good for +/- 0.1 g to 3 kg. That will help immeasurably as I work in metric and all the stuff I buy are in legacy units and my recipe books (and my brain) are in metric.

    Talking about scales, I nearly bought a set of Weight Watchers digital scales at Bed Bath and Beyond. I’m still thinking about it. This scale is a lot more accurate (+/- 0.1 kg calibrated to 180 kg) than my current scales, which only go to 150 kg and +/- 0.5 kg after 100 kg. I think I’m heavier than 150 kg as my barometer pants no longer fit. But my scales read 150-152 kg all the time. There are scales at the gym, but I don’t know if they reach my current weight (probably) or if they are calibrated (probably). Worst of all, I’d have to convert back from the legacy “customary” units they use here to metric. The last is the most likely reason to buy scales. But whilst I am so heavy, I think weighing myself is a moot point unless I start eating well and exercising.

    Last week, we bought more shorts and t-shirts for me, so I can go to the gym the entire week without having an excuse not to go. I walked 25 minutes yesterday, and we were doing shopping for nearly three hours today. It’s my plan to go to the gym initially three times a week for an hour (which equates to about 40-45 minutes on the equipment), and walk 20-30 minutes two more days. I’ll bump it up when I feel I’m no longer feeling out of breath.

    So, there you go. I have a week’s worth of expensive, healthy food. Two days of exercise down, and two days of following the eating plan with only one minor blow out (too much meat tonight). Let’s see how I go next week. As weight loss is not the current focus of this blog, if you want to follow my travails, use the “Weight loss” page tab above.

  • Ajax Security by Billy Hoffman and Bryan Sullivan

    I’ve had the manuscript of this book for about two weeks now. I approached this review from the point of view of having had a contract to write an Ajax security book myself, with No Starch Press. I actually approached Billy to see if he wanted to help write my book at Black Hat in 2006, but I never followed through… on either the book or chasing Billy down and getting on with the job. For those who wait, are those who do. Congrats to Billy in chasing down a publisher and getting a good co-author, and most of all – getting it done! Writing books is a hell on the social life, and I can’t imagine how many all-nighters they pulled to get this out the door.

    So onto my mini-review.

    The Good

    Is it just a re-hash of old presentations? No. The book breaks some new ground, and fills in a lot of the blanks in all of our presentations and demos. I hadn’t heard of some of these attacks in book form before. The examples improved my knowledge of DOM and other injections considerably, so there’s something there for the advanced folks as well as the newbies.

    I really liked the easy, laid back writing style. Must come from the laid back Atlanta-based authors (ps. I love it there). I don’t like it when authors write as if they are better than you by using big long words. Big long words just make my head hurt. Luckily, Billy and Bryan’s text is straightforward and easy to understand. They get across the concepts in a relatively new area of our field, coining at least a few terms (cross-site flashing, for example).

    The structure flows pretty well, building upon what you’ve already learnt. They bring you up a little bit at a time. That’s not to say that there’s nothing here if you’re a Jeff Williams or a Jeremiah Grossman or RSnake – there is advanced stuff, but the authors have to bring the newbie audience along for the ride. I think they do this in a way that helps the newbie more than it helps the experienced folks – but that’s fine: the experienced folks are already au fait with much of the discussed techniques.

    The bad

    Well, there’s not much wrong with the book. I would have preferred more real live examples rather than “cheating” with Firebug, but that’s a small quibble. If you can do it with Firebug, you code will be pwned sooner or later.

    Billy and Bryan spend a bit of time repeating the old hoary “no new attacks in Ajax” meme which is big with the popular kids (mainly because their products can’t detect or scan Ajax code yet and still want money from you), and then spend the rest of the book debunking their own propaganda with a wonderful panache that beats the meme into a bloody pulp and buries it for all time. Yes, there is a lot of old stuff that has crept back in, but honestly, Ajax is *different* in some areas, and it creates new attack surface by definition. There’s nothing really wrong with saying “hey, here’s JSON injection which is new” or “hey, here’s a hybrid Ajax CSRF attack worm, and that’s new”, “hey, you’re adding 25,000 lines to run in the untrusted browser, I reckon the attack surface is going to be bigger and more easily exploited”.

    The book also fails to deal with framework authors in any major way. There are so many (bad) Ajax frameworks out there right now. You can accidentally create one if you scratch some code the wrong way. In my view, web application security can only be improved by targeting the frameworks (in the hundreds) rather than targeting the huddled millions who code for a living. However, the book will only sell in the tens of thousands if you target the poor bunnies cutting code. In my view, I would have liked it if the book had covered what *frameworks* should do. Maybe this could be fixed in the second edition.

    The Ugly

    The book concentrates far too much on attacks, and not enough on building and architecting secure Ajax applications. This is typical of the usual penetration tester mindset, which gets you the hot girls and invites to the swankest parties. However, it leaves a lot to be desired from the software engineering front. We have to stop treating security like a black art – it has to move to being the very way we code, so much so that it hurts if we do it the bad old way. However, penetration testing is far sexier that software engineering, and I’m sure this will not hamper sales in any way (c.f. Hacking Exposed, etc).

    Conclusion

    If you are writing or reviewing Ajax code, you need this book. Billy and Bryan have done a stellar job in a nascent area of our field, and deserve success. Go buy this book. I can’t wait for it to come out.

  • OWASP / WASC AppSec 2007

    It’s that time of the year again! Time to register for the OWASP / WASC AppSec 2007 Conference.

    This is the conference track I dream about when I cry to myself re: lack of web application security in other security conferences. Awesome speakers, the Breach cocktail party (register now! Breach’s OWASP / WASC party at Blackhat’s was awesome).

    I believe we are still looking for sponsors, so if you have a lead there, mail conferences ‘at’ owasp.org.

    I really appreciate the WASC folks for taking a chance on collaborating with us at OWASP. With their help on the ground and on the papers committee, I think this will be one of the best appsec conferences ever! I hope to be there, but as my wife is nearly due, I may not get a leave pass from the Minister of War and Finance.

  • Why does forum software has more security features than “enterprise” tool chains?

    I am constantly amazed by the sheer lack of security in the average “enterprise” tool. I’ve looked at many over the years, and most are designed to the “soft squishy center” anti-security model. Typically:

    • They do not implement any form of strong authentication, nor any facility to integrate with known strong authentication solutions
    • They do not implement any form of strong identity handling, so when someone is logged into component A, it’s nearly impossible at component D to determine who is doing a particular action (see accountability below)
    • They do not make it easy to implement end-to-end access control (fine, medium, and course grained), so most of the time, authZ is equivalent to “do what the hell you want to do”, allowing the golden apples to fall very easily
    • Often they do client-side stupid tricks and can be trivially tickled into doing something really dumb
    • Accountability is simply missing. Yes, many systems have logs, but they are business irrelevant. My personal view is that if a business person doesn’t care about a log entry, it’s not worth collecting. Accountability is the key here, not 1 GB of logs per day
    • Data validation misses the business rules allowing tweaking of the golden apples, particularly on the way out. That old mainframe or ancient database is no more trustworthy than a slightly dodgy user
    • Modern business scenarios (business / trading partners, extranets, etc) are very poorly done
    • Encryption, if it is done at all, is of the crypto toy variety or the folks leave the keys in the door. But 95%+ of the time, it’s not even there, and yet here is all the value of the business, just lying there waiting to rustled under the covers

    A counterpoint to this is forum software. Admittedly, I help write forum software in my copious spare time (read: none at all), but considering that in most cases, the value of the asset being protected is precisely zero dollars, it’s amazing just how many security controls are relevant (and useful). They do what they do well, and yet they have to implement – through repeated and automated attacks – pretty much all of the OWASP Guide’s suggestions.

    I honestly wonder why folks think that “enterprise” software is somehow magically safe or scalable.

  • Fucktard drivers

    What is it with “sporty” coupes and their drivers? We were nearly killed coming home from the hospital by 8CR J60, a Black Infinity of some description. There’s a complete fucktard behind the wheel, who will hopefully get a nice moving violation from the police tomorrow.  I hope with all my heart that this is the last few points on his license so they are off the road for a few months. Honestly, why drive if you’re going out there to kill yourself and others?  

  • Cultural Learnings from the Great United States Of America

    Well, I was watching this new show called “The Big Bang Theory” last night (on Tivo-To-Go at the hospital, but that’s for another blog entry another time). It’s written by Chuck Lorre who has done a lot of great comedy, including Two and a Half Men. I quite liked it, as what’s not to love?

    • Cosmologically-correct lyrics in the opening titles – sure to annoy literal evangelicals YAY!
    • String theory jokes, using the actual differences between the various string theory camps as the punchline
    • Actual WoW game as a come-on … as in, let’s play WoW together … in different rooms … so I can get in your pants … somehow

    I never thought I’d hear jokes like this ever on prime time TV sitcoms – let alone from the country that watches Britney Spears’ every move as if it’s actually important (hint: it’s not important).What I didn’t like. The stereotypes are really old. The guy with the 60’s hair – never met him. The two guys who play Klingon Boggle. I’ve been geeky since whenever and I’ve never seen this, but maybe I’m not l33t enough in the Trekkie circles. One dimensional geeks. Sure there’s some folks who are Aspergers or borderline so, but most geeks are into a very wide variety of things, and not just intellectual pursuits and Babylon Five. I give it thirteen episodes before it’s canned. This show is far too cerebral and cliquey for the show biz types to go “I haven’t understood a single joke”. It’ll be a shame, as it’s the first US sitcom I’ve ever seen that doesn’t talk down to its audience. For that, you need to see Beauty and the Geek. I’m scared, very scared when I watch that show.  

  • Security Engineering

    One of the really cool things my job allows me to do is go teach developers and managers about application security.

    In the past, I’ve half jokingly said “when the revolution comes, X will be first against the wall”, where X is a product or company who has no clue about security and worse, they pissed me off. Well, I felt the wall and the hood with these students – they wanted to revolt!

    My crime? For daring to suggest that they do not belong in production.

    READ MY LIPS! DEVELOPERS DO NOT BELONG IN PRODUCTION! END OF RANT

    We have to end the developer cult where they believe they are a black magi sending code from on high. Those days never really existed. It was only because any old oxygen bandit* could get paid (and paid well) to write crap. Guess what? Crap may be the state of the art of today, but you’ll have to do better, and soon. 

    Real engineers are fallible, but they know this and design around it. Coders seem to think they are magically immune from engineering problems, and do not code in any defense in depth. One of the key ingredients for software security is production management. And part of that is that developers do not have logins for production systems. They do not have access to promote code by themselves. They do not need special features just because they are developers. 

    Developers need to learn basic production hygiene. I help teach it, but they have to accept it and live the life. If you are a developer, and you have access to development, it’s time to lose those credentials. If your code has backdoors that let you do more than anyone else, that’s a sackable offense at many financial institutions and government shops.

    Let’s start being engineers instead of cowboys. 

    * Oxygen bandit. adj. Someone who breathes air they don’t deserve, is able to dress themselves in less than 30 minutes, and who is able to drag a few controls onto code someone else developed. For more details, see one of my favorite sites.

  • InfoSec Sellout Pwned

    It’s sort of ironic funny when a blogger who is against FUD in the security industry get pwned by sploggers.

    Seriously not safe for work:

    picture-1.png