mostly useless crap from me

In today’s Age, there’s an article on how Australian taxpayer money is being used to bribe FIFA and other national soccer body officials to garner support for Australia’s World Cup Bid in 2022.

Item 1. It’s is actually illegal to spend Australian government money on bribes, gifts, holidays, and so on. This is contrary to the Bribery Act.

Item 2. Bribery is most likely illegal in all other FIFA playing countries, such that asking for or receving kick backs and gifts such as pearl necklaces and holidays is illegal.

The Federal Police should go in an investigate these claims, and prosecute them to the maximum extent that the law allows. We send folks who hold up a 7-11 for a measly $250 to jail for a couple of months to a few years depending on how stupid the crooks are. In this case, the “crooks” (in my opinion) are running double books and stealing Australian tax payer money to the tune of several millions of dollars per year. Bribery is theft pure and simple and is dealt with that way under Australian law.

Why is bribery and fraud so insidious? It is an opportunity cost. If the bribe did not need to be paid (and it NEVER does), then you can use that money for other things, such as health care, education, social programs, roads, and infrastructure. The more fraud you accept, the higher our taxes and the less you receive for it. In Australia’s case, $20m per year is nothing and the consultants and FFA are busy laughing it off. Wrong. For a third world country where the bribes are most likely to be accepted, this is actually death – actually no roads – actually no infrastructure. It’s evil and that’s why we and many countries have laws against it.

FIFA must immediately sack those who received or asked for gifts and change their processes to be bribe / fraud resistant and with huge sanctions on those who breach them – such as a 20 year disqualification from holding the World Cup for the countries involved, and immediate life bans from FIFA level competitions for those who seek to profit from their position.

FFA must immediately sack these “consultants”, and anyone in FFA who thinks running double books is a good idea. They must change their processes so that when they spend Australian tax payer funds, they adhere to all our laws, including the Bribery Act.

The AFP must look into these allegations and prosecute. This is like a thousand 7/11’s being held up, except Australian tax payer funds were in the till.

My guess? Nothing at all will happen. Welcome to your corrupt World Cup, a poisoned chalice for all those who covet it.

A key component in deciding a risk is WHO is going to be doing the attack. The above image is from the excellent OWASP Top 10 2010, and I will be referencing this diagram a great deal.

We’re talking about the attackers (threat agents) on the left today. So you’re busy doing a secure code review or a penetration test (how I loathe that term – so sophomoric) and found a weakness. You’ve written up a fantastic finding and need to rate it so that your client (whether internal or external, for money or for free) can do something about it. It’s vital that you don’t under or over cook the risk. Under cooking the risk looks really really bad when you get it wrong and the wrong business decision is made to go live with a bad problem. Overcooking the risk erodes trust, and often leads to the wrong fixes being made or none at all, which is worse. You can tell if you’re overcooking a risk if your clients are constantly arguing with you about risk ratings. Let’s get to a more realistic risk rating first time every time.

Risk Management 103 – Establishing the correct actor

I am more likely to be successful than a script kiddy who is more likely to be successful than my mum. Unfortunately, there’s just one of me, but there’s a million script kiddies out there. That doesn’t mean you should use them. Script kiddies are simply unlikely to find business logic flaws and access control flaws, such as direct object references. So you should reflect this in your thinking about risk – even though it might be simpler to go with what everyone already knows:

• Skill level – what sort of skill does the threat agent bring to the table? 1 = My mum. 5 = script kiddy (generous), 9 = webappsec master
• Discovery – how likely is it that this group of attackers will discover this issue?
• Ease of exploitation – how likely will this group of attackers exploit this issue?
• Size of attacker pool – 0 – system admins or similar, 9 – The Entire Internet (==script kiddies)

So you need to do the calculation for the weakness you found for these various groups to determine the maximum likelihood. This often leads into impact. Let’s go with an indirect object reference, such as the AT&T attack

Likelihood – AJV

• Skill level – 9 web app sec master
• Motive – 4 possible reward
• Opportunity – 7 Some access or resources required
• Size – 9 anonymous internet users (remember, this attack relied upon a User Agent header for authentication)
• Ease of Discovery – 7 easy
• Ease of exploit – 5 easy
• Awareness – 9 public knowledge
• IDS – Let’s go with Logged without review (8)

This brings us a total of 54 out of 72. I put this as a “HIGH” likelihood in my risk charts.

Likelihood – Script kiddy

• Skill level – 3 some technical skills (script kiddy)
• Motive – 4 possible reward
• Opportunity – 7 Some access or resources required
• Size – 9 anonymous internet users (remember, this attack relied upon a User Agent header for authentication)
• Ease of Discovery – 1 Practically impossible
• Ease of exploit – 1 theoretical
• Awareness – 1 Unknown
• IDS – Let’s go with Logged without review (8)

This brings us to 34. So we shouldn’t consider script kiddies when there might be a motivated web app sec master on the loose. But is that entirely realistic? Honestly, no.

Who is really going to attack this app?

Think about WHO is likely to attack the system:

• Foreign governments – check.
• Web app sec masters – Our careers are worth more than the kudos.
• Bored researchers trying to make a name for themselves – check even though quite dumb (see previous bullet)
• Script kiddies – check but fail. Realistically, unless someone else wrote the script, they wouldn’t be able to do this attack.
• Trojans – check but fail for the same reason as script kiddies.
• My mum doesn’t know what a direct object reference is. Not going to happen.
• Terrorists – check, but seriously, remember dying by winning lotto, buying a private plane with the lotto winnings, having the plane struck by lightning on its four leave clover encrusted hull eight times, parachuting out and then for the main and the secondary to both fail is more likely than a terrorist attack. Don’t use this unless you’re after Department of Homeland Security money as everyone else will just laugh at you. Especially if you use it more than once.

So let’s go with #1 as this is an attack that they would be interested in. They have resources and skilled web app sec masters, so this attack likelihood is a HIGH. So let’s work out the impact for this scenario:

Sample Impact Calculation

There’s a lot of subjectivity here. You can close that down significantly by talking it over with your client. This doesn’t mean you should go with LOW every time you have the conversation, but instead set out objective parameters that suits their business and this application. Yes, this takes a fair amount of work. You can either do it before you deliver the report, or you can do it after you deliver the report. If you choose the latter path too often, your reputation as a trusted advisor can be found in the client’s trash bin along with your reports and the client relationship.

Let’s do the calculations based upon the sketchy information I have from third hand, unreliable sources and vastly more reliable Tweets. i.e. I’m almost certainly making this up, but hopefully, you’ll get the picture.

• Loss of confidentiality. Check big time. All data disclosed (9)
• Loss of integrity. In this case, no data was harmed in the making of this exploit 0
• Loss of availability. If every government tried it at once, I’m sure there’d be a DoS but let’s be generous and say minimal primary services interrupted (5) as the system would have to be taken offline or disabled after it was discovered
• Loss of accountability. It’s already anonymous, so 9
• Financial damage. AT&T is big. Really really big. In the grand scheme of things, this probably didn’t hurt them that much. That said, it has to be in the millions. So let’s go with Minor effect on annual profit (3)
• Reputation damage. AT&T’s reputation is somewhat already tarnished, so let’s go with loss of major accounts (4) as I’m sure RIM will pick up all of those .mil and .gov accounts very soon now.
• Non-compliance. PII is about names and addresses, but AFAIK, e-mail addresses are not protected at the moment. Happy to hear otherwise – leave comments. Let’s go with “clear violation” 5
• Privacy violation. 114,000 is the minimum number, so let’s go with 7 and it could tip towards 9

This gives us 42 / 72, which is a MEDIUM impact (just shy of “HIGH at 46), giving an overall risk of HIGH. That is about right, and thus should have been caught by a secure code review and fixed before go live.

Next … Risk Management 104 – Learning to judge impacts

Like many technical writers, I am constantly looking for ways to improve my writing skills. I don’t think there will ever be a time when I think “Okay, that’s good enough” and stop criticizing my own work.

I am constantly in awe of other authors, particularly those that have published great works. I seek out author interviews on scholarly websites, and places like Galley Cat, in an effort to glean small insights into the life of an author.

I started out by reading author interviews for any morsels on how they organized their day and their writing space. This accelerated once I started working from home. This is a futile project – each author, if they mention it at all, has a completely different day structure and writing space than the author before. Some write early in the morning (impractical for me), some write late in the night (I’d love to, but I have a 2.5 year old who says “close eyes” and means it); some write in glorious writing palaces redolent in over stuffed furniture and old books others write in long hand at the local coffee shop or library. No two are the same. Sigh.

The one common theme is that they write every day. Iain Banks, one of my favorite authors, writes for only part of the year and takes the rest off, but still manages a punishing schedule and daily word count to pump out beautiful works of art.

Another common theme is supportive family and friends. I can attest to that – my cats led a lonely life whilst I was tapping away at the OWASP Guide 2.0 for several months. I don’t think I could ever do that again – not least for family reasons.

Technical writing for web application security is far different from any form of fiction. It’s different from most non-fiction – and it’s dramatically different from sports writing. We’re expected to dumb down (“communicate”) with our peers in a way that nearly no other technical field would allow. In my field, respect is paid to those who can communicate highly technical, very advanced concepts in a way that could be understood if they were on the back of a “Fantale” wrapper.

I am not disparaging my field, for I love it, but I do object that our terms of art – our short hand – is so easily sacrificed. I need to learn how to write dumber, become one with my inner dumb writer, and make sense even when it makes no sense to write for the average tabloid reader. I think we underestimate our reader’s intelligence and insult them terribly every time we pump out a report in basic English (that is – using only the 500 most common words).

Viva la revolucione! Whoops, that wasn’t basic English. My bad. As for more author interviews – it’s like reading a good autobiography – hard to put down. I think I will continue to seek out author interviews, even though I think they will in the end not shape my writing style nor my work space to any great degree.

There’s a lot of consultants (and clients) who know little to nothing about proper risk management. This is not their fault – it was never taught at computer science or most similar courses. If you get good at it, you’re unlikely to be a developer or a security consultant. That’s a shame, because risk management has a lot to offer both consultancies and their clients if done properly.

The problem is that most consultants think technical risk, and will happily assign “Extreme” risks to things like server header info disclosures. Many clients actively campaign to reduce risk ratings for whatever reason, some for valid reasons, others not. And they will win if the risk ratings are wishful thinking or outright wrong. This could cost the organization billions of dollars if a HIGH risk becomes a LOW risk and is accepted, when really it’s a sort of a MEDIUM to HIGH risk depending on the situation.

We as consultants have a responsibility to THINK about the findings we put into reports. Don’t be a chicken little, but also don’t be bullied into reducing bad risks as you’ll be chosen for your outcomes rather than your honesty and integrity. Be open and honest about how you came to that risk decision, talk over the factors, and help the client understand and agree to the choices you’ve made. So don’t just stick “HIGH” in there, you need the entire enchilada. Lastly, be reasonable when you’ve made a mistake and ensure there’s as few as possible as that’s a huge reputation risk.

Clients have a responsibility to talk over the risk ratings so they fully understand the risk. All parties should agree that they document the original risk, the discussion about the risk, and any revisions to the rating and / or vulnerability. Maybe there’s a control that’s being missed, or may be there’s a misunderstanding of how easy it is to perform. Otherwise, there’s no accountability. In the end, consultants should never change a risk without documenting that change.

How to improve the situation

I like the OWASP Risk Rating methodology. The primary reason is that two different consultants can come up with the same result independently, removing a lot of the subjectivity and argument from the equation. I like to include the entire calculation as this allows clients to repeat my work and thus understand why it turned out the way it did.

There are issues with the OWASP Risk Rating methodology:

• It’s far too easy to generate “Extreme” risks. Extreme risks are really, really rare. They are company ending, life ending, project ending, shareholder value strippers, reputation destroyers. Think BP and the Gulf Coast. SQL injection at TJ Maxx is an extreme risk (despite them still being in business, it did cost a lot).
• It’s difficult to game the numbers to create “Low” risks when you know that it really should be a “Low”. I basically take nine off the top, as I’ve never gotten a value less than nine. This helps a bit, but even then.
• It’s hard to do it manually. I use Excel spreadsheets, but you may want to automate it more.
• You must talk to your customers first. Otherwise, you need to take out the business elements (financial, legal, compliance, privacy) as you will not be able to lock these in.
• Impact values are not the same for the entire review. They change as per the asset value/classification, and you will most likely have more than one asset value / classification in your review. There’s a difference between contexts, help files, PII, and credit cards. Document which one applied.

That said, the OWASP risk rating methodology is way better than pretty much everything else out there for web apps. CVSS is not suitable as it’s for ISVs who produce software. That doesn’t describe most enterprise, hobby, open source projects, and so on. If you need to do AS4360 risks, CVSS is not going to cut the mustard.

Risk Management 102.

We spend a lot of time arguing with some clients because we haven’t thought through our risk carefully enough, or worse, just used the one from the last report. No two clients and no two apps are ever the same. Therefore, the risk ratings for each of your reports MUST be different. Spend the time to do it right the first time, or you’ll spend a lot more time later when your client argues with you. And they may have a point.

• Try not. Do… or do not. There is no try. The likelihood rating is solely about the likelihood of the MOST SKILLED threat agent SUCCEEDING at the attack / weakness / vuln you’ve described.
• The impact rating is solely about the WORST impact of the attack / weakness / vuln using the threat agent you’ve described.

For example, you have a direct object reference in the URL and no other controls – my Mum could do this attack. The IMPACT is off the charts, and the likelihood too. Just because a n00b consultant with an automated tool is unlikely to do more than annoy the web server, doesn’t mean that’s the threat agent you should document.

If you came so, so close to exploitation and you just know that it could be bad, but you failed miserably after several hours, exploitability has to be set to 0. Seriously. The impact has to be low too, as there’s no impact that you’ve proven. To document anything else is wrong. I’m happy for folks to write up how close they came, and draw attention to it in the executive summary and in the read out, but to put a high likelihood says that you’re lame, and a high impact says you’re a chicken little. Don’t do it.

If you’re unsure, map out different attackers (n00b consultants with automated tools, script kiddies, organized crime, web app sec masters), work out how likely they are to succeed at the attack, and then work out what the impact is for each of these threat agents. Do the math and use the most likely choice with that most likely choice’s impact. Don’t under or over blow it – if a web app sec master could totally rip a copy of the database with both hands tied, the impact is likely to be low.

Lastly, don’t go the terrorist route. You are more likely to win lotto, fall out of your new private plane from 30,000 feet and then get killed by lightning than you are ever likely to be a victim of terrorism. Chicken little scenarios work once or twice, but you’re just wasting everyone’s time and scorching the earth for all those who follow you.

As security researchers, I think we’ve let down users in the quest to close down questionable and unlikely events. The problem is that even though unlikely, these events – such as MITM attacks – work nearly 100% of the time. They make great demos to scare folks who don’t understand what they’re seeing. It’s a shame that they just don’t occur in the real world all that often. So let’s move beyond “Expire it after 10 minutes”, and to a session manager that actually helps the business and makes users love you, and really close out some of these attacks.

The reasoning behind 10 minutes is a balance between the business (who’d prefer no time outs really and would love to have a magic “remember me” function that is somehow secure) and Tin Foil freaks like me who know how incredibly simple MITM, session fixation, and session hijacking can be. Many of the goals of our advice has been based on 1970’s standards and thinking, and 1990’s type of attacks that still work, primarily because we’ve been asking for the wrong solutions, like short time outs and don’t let users log on twice.

As Dr Phil says, “How’s that working out for you?”

So let’s think about ways to improve session managers to blunt the known attacks. We know that TLS has issues with MITM attacks, but we’re very lucky that this is a local attack (for now). Such attacks are also exceedingly unlikely outside of security conference wireless networks, and motivated attacks on behalf of organized crime (very rare but devastating – see TJ Maxx).

However, some of the other assumptions we’ve made when recommending bad ideas usually don’t think about the user of the application. My wife does all of our shopping online. The system is awful. It times out within a short period of time, and it usually takes 4 to 5 attempts to finish an order. I’m sure there’s some poor risk manager going “WTF? PCI is stupid – we have to implement 10 minute time outs for a process that lasts 30-40 minutes?” Let’s move beyond quick fire “gimme” penetration test results, and think about HOW the USER is impacted when we make recommendations with our consultancy hats on.

What goes wrong if it takes 40 minutes to assemble a shopping list? Do we have a financial loss? No. Do we have a reputation loss. Yes. Do we have a shareholder loss. No. Do we have a privacy impact? No. Do we have a regulatory impact? Only if you consider PCI DSS a regulation worthy of its name. What can we do to make it better?

With the online shopping example, losses start when we can order stuff. Easy! Keep everything intact (and allow items to be placed in and removed from the cart), but make the user re-authenticate to purchase or see their profile if it’s been more than 10 minutes. But with 100% of session managers today, that very act is impossible without significant customizations and we all know there’s some B List pen tester willing to ping you on long timeouts if you do write that secondary all singing all dancing session manager. THINK BEFORE YOU RECOMMEND RECEIVED WISDOM!

Realistically, we need to set some baseline parameters for every session manager.

• Strong. Session tokens should be random enough to resist being brute forced in a reasonable time frame. I still see this although it’s been solved on most platforms since 1996 or so.
• Controlled. Session managers should only accept their own session tokens.
• Session hijacking resistant. Session managers should rotate their tokens from time to time automatically. Every five minutes is fine, as is every request as long as there’s a sliding window of acceptable tokens to allow the most used button (Back) to work. All frameworks should possess a regenerate token API – it’s ridiculously hard in all frameworks but PHP today.
• Session hijacking resistant. Session managers should watch headers carefully and reject requests that don’t perfectly match up with previous requests. There is no reason for a user agent or a bunch of other headers (upto and including REMOTE_ADDR) to change within a session.
• CSRF proof. Session managers should tie themselves to requests, and check that the session and forms match up. OWASP CSRF Guard can do it, and realistically, this should be standard in every session manager.
• Cloudy Web Farm support. It’s very hard to do federated session state with most session managers, and yet the hackiest solutions I’ve seen for getting around this issue is due primarily to the isolated session manager mentality. There are good last writer wins replication mechanisms around, including “deliver at least once” – not everyone needs this functionality, but those who do really need it badly. This can be used as a pre-cursor to…
• Notifications. Most SSO products use work arounds so that the primary session manager times out before the SSO token does. This means that their are active SSO sessions you could reconnect to if you know what you’re doing. Let’s make it easy for folks like Ping to get notified when regenerate, idle, absolute and logout events occurs.
• Adaptive timeouts. Sessions that “expire” should be put into a slush pool, that comes alive again up to an absolute limit. But the instant that a user wants to perform a value transaction, the session manager should require re-authentication.
• Integration with common SSO protocols. SAML and WS-Federation are the two most popular SSO mechanisms out there. Realistically, all session managers should be aware of how these work, and tie into them strongly so that if folks use SAML/WS-Federation, this can be tied to the session token in use. How many times have we seen these two operate in completely separate worlds and then been a target for replay, session expiry and other attacks.
• Destroy means destroy. Make it easy for devs to do the right thing when the user clicks logout. Not only clear the session properly, but also all associated copies of that token – headers, cookies, DOM, etc, etc.

Notice that I didn’t put one of the lazy pen tester’s favorites in the above list – “Logging on more than once”. I REALLY don’t care about that. I care about what VALUE TRANSACTIONS you can do within the assigned sessions. If there’s a problem with value transactions, preventing two sessions at once isn’t going to save your bacon. Transaction signing / SMS authentication / re-authentication will help, or if it’s about resource consumption, then transaction governors like in ESAPI will help. THINK BEFORE YOU PUT STUPID THINGS IN YOUR REPORTS.

Many of these items are in ESAPI. That’s awesome, but it would be nice if all session managers dealt with sessions to support users and business uses, rather than obscure and unlikely attacks.

I thought recently about the ways in which folks who are looking for research projects in web app sec might make a useful contribution to the field. Part of that is the list of impossible tasks – those tasks that are so hard that it is unlikely to be solved in my lifetime. If you solve these, you’re a rocket scientist.

• Universal XSS Prophylactic – it seems simple enough – blow XSS out of the water. In all code for all time. We know how to do it well enough, but how do you solve it for all that crappy code still running? Think of a design pattern, injection, or mechanism that will blow XSS out of the water with minimal changes to existing code. Don’t say h().
• The No Injection Design Pattern. Almost all of our major commercially successful protocols are mixed data / program (i.e. not Harvard Architecture). Think about a design pattern, architecture, or API that allows ANY arbitrary protocol (SNMP through XML) to have no injections. This is not just about prepared statements, this is about taking an injectable grammar, and transforming it into a work of uninjectable beauty that is orthogonal and deep. There is previous work in this area (and you’ll be off to good start if you know who wrote it and include them in your research team).
• Common Off the Shelf Anti-Corruption Business Processes. Realistically, we’re here to support solutions, not enable security “features”. There’s no value to be had from security per se; we are the guardians against dumb luck and bad risk. There should be a open source business process library that is resistant to fraud, corruption, coercion and bribery, as well as just going from Step 1 to Step 10. Think of how a simple process of acquiring pens from the office supplies cupboard should be built compared to say acquiring a data center populated with 3843 servers. Or was that 3842 servers?
• Working with infected platforms. Financial institutions know that a certain percentage of their customers are infected with malware. At one institution I worked at, it was approximately 35% of a Certain Popular Operating System had at least one, and more often 10 or more different pieces of malware installed, ranging from hostile toolbars all the way through to Banking trojans. We knew absolutely that their computers would most likely steal their logins, and try to steal their funds. Think about ways you can perform “trusted” computing on a clearly untrustable platform. Booting a LiveCD is not going to cut it for my Mum. Think harder. This one will make you millions if not billions if you do it right.
• Creating a math or notation for access control that “proves” protection. This one is a big one. Many a time, we do code reviews and penetration tests and find insecure end points – client, presentation, controller, model, or data and we can exploit them. We shouldn’t be able to find these at all – your compiler and IDE should alert developers to leakage of secured data / functions. Come up with a notation or mechanism that can be easily parsed by compilers that helps prove that every piece of secured data and secured function is protected end to end. You must satisfy “principle of least privilege”, “default deny”, “fail safely”, and “complete mediation” principles.

Some of these items are dealt with by OWASP’s ESAPI, others by the judicious use of WAFs. But there is huge scope with billions of lines of legacy code hanging out there in any number of languages and frameworks. These are simply never going to be fixed, and yet we rely on them to keep the lights on, water flowing and sewerage flushing. Literally. These are the first five that I think are worthy of top class researchers. Go for it.

The Great Firewall of Australia is still being worked upon by the evil legal minions of Senator Conroy. At the time of writing, it’s not illegal to tell you how to bypass censorware. I’m hoping that the legislation has no retrospective provisions in it (which would be really evil).

Here’s how you get around censorship in case Australia decides to become a totalitarian state and block free and unfettered access to the Internet.

Free and pretty easy

• Tor. Install Tor into Firefox. Done.
• Anonymizing Proxies. This is the easiest path, especially if you don’t use Firefox. Find one that is hosted outside of Australia. There’s heaps available.
• P2P software helps transfer files around, but I only use this for downloading Ubuntu ISO’s. Seriously. Don’t breach copyright – it’s how I make a living. P2P is not particularly secure, and can be monitored and seeded by hostile entities.
• Most messenger programs allow file transfers. Again, don’t breach copyright. Most Messenger protocols are unencrypted and thus can be monitored, and realistically, how do you know the other party is not a dog? See Chat Roulette for proof of this principle.
• Most transparent ISP caches only work on port 80, and can’t work with SSL due to the way SSL works. Use SSL.
• Most transparent ISP caches only work on port 80. Go to sites on ports other than port 80, such as port 81, 8080 or similar.

Free, but might cost you your job

• Using head office’s proxy in another country. If you work at a large multi-national, use their proxy. Remember, most workplaces have anti-pr0n acceptable use policies, and they’re more likely to police them than Australia. Otherwise, Done.

Not free, but still fairly easy

• SSL reverse proxies. There’s a fair few of these services around. Done.
• VPN’s. Buy a Virtual Private Server (VPS) in another country, preferably the USA. Install OpenVPN, PPTP or IPsec on it. Done.
• Set up a local web proxy server that has child-parent caches. Set up a remote parent cache in another country, or subscribe to a remote cache service. Done.

There’s more ways to bypass this stupid proposal, but I’ll leave those off this list for now.

I seriously hope that there will be mass protests and heavy campaigning if there is any legislation tabled.

We need to show Senator Conroy that the government is truly misguided on this – voters unanimously don’t want to be censored. Parents don’t want it. ISPs and our entire IT industry doesn’t want it. The ALP support base hates it. Censoring Australia WILL lose the ALP power. It will allow all the tin pot failed nations on the planet to say, “We have the right to do this, Australia did it.”

We must resist this most evil proposal in any way possible. See you at the protests.