Dominic White's .tHE pRODUCT

My Pwnie Nomination was Accepted!

nospam@example.com (Dominic White) — Tue, 22 Jul 2008 17:18:46 +0200

Yeah! If you were wondering why I wanted to know who discovered SQL injections, it was to nominate a "Pwnie for Mass 0wnage". And it was accepted:

SQL injection in more than 500,000 web sites

Discovered by: Rain Forest Puppy back in 1998

SQL injection attacks are not new, but this year we saw an upsurge in the number of automated attacks against vulnerable websites. Reportedly more than half a million websites were compromised.

Although I see they went all conservative on the numbers (500k, *psccht*). ShadowServer has nearly 500k from the nihaorr1.com injection alone. Anyone with contacts please correct them.

Vulnerability Life Cycle

nospam@example.com (Dominic White) — Sat, 19 Jul 2008 11:51:33 +0200

Schneier once proposed a vulnerability life cycle in a Crypto-Gram newsletter. He was wrong. During the time of writing my thesis, there were several important pieces of research no-one had put together to come up with a 'more correct' vulnerability life cycle. Given some recent discussions between Symantec and Verizon, I thought I would provide this is a more accessible format that a previous presentation I did on the subject, so that I could refer to it later.

The benefits of having an understanding of the life cycle, is that it provides a model to 'predict' the behaviour of various role players (e.g. bad guys, vendors and administrators) and understand how that behaviour impact on important parts of the risk management equations such as vulnerability, threat and impact. This is an important building block of any threat model.

The detail after the jump.

Let's get into it. Schneier's (and others) theorised model looks like this:

This life-cycle has the following stages:

The creation of the vulnerability. This is when the vulnerability is created during the implementation of the vulnerable product.
The discovery of a vulnerability. The vulnerability in the product is found. Several people could discover the vulnerability at different times. Little is ever publicly known about this step.
The discovered vulnerability is disclosed. The disclosure could come from a variety of sources, in a variety of ways. It could be announced by the vendor or an independent researcher, or secreted away in a product’s Change Log.
The vulnerability is corrected. This is usually done by the vendor releasing a patch or workaround. This should lead to an overall reduction in successful intrusions.
The vulnerability is publicised. This can happen in a variety of ways; for example news reporting, publishing an advisory, worm activity; but the end effect is that many people know about the vulnerability.
The exploit is scripted. This can mean that workable exploit code was released, or instructions on how to produce one are released. In either case, the result is that the number of attackers is greatly increased as those with less skill (script kiddies) can now perform the attack.
The vulnerability becomes passé. Attackers become disinterested in exploiting this vulnerability. This is not guaranteed to happen with every vulnerability, and some vulnerabilities (and exploits) are shown to have cyclical popularity.
The vulnerability dies. This happens when the number of possible targets vulnerable to exploitation drops to an insignificant level.

Now, if we take into account a bunch of research, available on page 30 of my thesis, we get the following corrected life-cycle:

The notable differences are:

The scripting of an exploit leads to a surge in the number of attempted intrusions.
The spike in exploitations will level off and tend towards a constant over time (e.g. SQL slammer intrusions are still floating around the internet at a fairly constant level).
The number of vulnerable machines have a half-life.
Most exploits are scripted before the end of the first half life.
Vulnerabilities rarely die, but some do become passé and attacks stop trying to exploit them. If anything, the exploits re-spike several times.

Interesting OpenSSH & SELinux Flaw

nospam@example.com (Dominic White) — Fri, 18 Jul 2008 06:55:27 +0200

Some older versions of SELinux and OpenSSH compiled to support it allow you to log in with an arbitrarily chosen SELinux role. You'll need a valid account, and some fairly undefined conditions, but the attack is:

ssh --l<username>:/<chosen role> <host>

Haven't seen a (potential) stuff up like that since the MIT Kerberos telnet daemon flaw (which was significantly worse). I'd like to think that people who've gone to the effort of setting up SELinux also patch regularly. Source, milw0rm.

I am interested in this because it is dreadfully simple, has some weird implications for how SSH and SELinux interact, and there is scant information about this. Maybe a few more eyes can uncover something.

Disclaimer: I haven't tested this. The author only tested it on a limited subset and it didn't work on up-to-date distros.

Update: Explained my motivations and authority (or lack there of) of the exploit thanks to foobar's comments.

SCP Transfer Resuming With Rsync

nospam@example.com (Dominic White) — Tue, 15 Jul 2008 13:55:19 +0200

I never remember how to do this, so for my own personal blog-memory:

rsync --partial --progress --rsh="ssh -p <remote ssh port>" <from file> <partially downloaded file>

The --rsh parameter can contain all of your normal ssh command line-fu such as keys, options, ports etc. (Who runs public ssh on port 22 these days anyway?)
The <from> and <to> follow the normal SCP format of <username>@<hostname>:<filename> or just <filename> for the local copy.

Which Vulnerability Researcher Discovered SQL injection?

nospam@example.com (Dominic White) — Tue, 15 Jul 2008 08:56:05 +0200

Rain Forest Puppy (rfp) in a merry Christmas of an article entitled "NT Web Technology Vulnerabilities", published in Phrack Magazine, Volume 8, Issue 54 on December 25th, 1998. He didn't actually call it SQL injection yet, that honour either goes to SANS or Chip Andrews in 2001. Source, Litchfield.

Here's the beginning of his summary, from the section entitled "ODBC and MS SQL server 6.5":

- WHAT'S THE PROBLEM? MS SQL server allows batch commands.
- WHAT'S THAT MEAN? I can do something like:
    SELECT * FROM table WHERE x=1 SELECT * FROM table WHERE y=5
Exactly like that, and it'll work. It will return two record sets, with each set containing the results of the individual SELECT.
- WHAT'S THAT REALLY MEAN? People can possibly piggyback SQL commands into your statements. Let's say you have:
    SELECT * FROM table WHERE x=%%criteria from webpage user%%
Now, what if %%criteria from webpage user%% was equal to:
    SELECT * FROM sysobjects
It would translate to:
    SELECT * FROM table WHERE x=1 SELECT * FROM sysobjects

Viva Las Vegas, BlackHat & Defcon USA 2008

nospam@example.com (Dominic White) — Mon, 14 Jul 2008 20:26:10 +0200

It's official, I'm going to Black Hat and Defcon this year. I'm very excited. A *huge* thank you to the SensePost guys who are sorting me out only proper. Make sure you go, to, their, training. We've also pulled together a fairly decent Deloitte contingent.

I'll be there from the 29th of July to the 11th of August if all goes off according to plan. Give me a shout if you want to meet up, or if you have invitations to sexy parties.

Make Better Coffee

nospam@example.com (Dominic White) — Mon, 14 Jul 2008 19:17:42 +0200

If you've decided you want to make better coffee, here are my tips for the changes that will yield the biggest results. These aren't comprehensive, just some quick tips for quickly making better coffee.

Don't use instant, use proper Arabica grounds.
Espresso is the best, then French press, then percolator. A Moka Express or Brikka are quick ways to get into espresso.
Use hot milk. This makes a big difference in taste, 30-40s in the microwave should do it. A French Press can be used with hot milk to make decent froth for cappuccino too.
Grind your own beans. A grinder is cheap, and freshly grinding your own beans just before you make a cup makes a subtle increase in flavour. Remember to store your beans in an airtight container in a cool dry place (not the fridge).

Blog Updates

nospam@example.com (Dominic White) — Mon, 14 Jul 2008 18:29:00 +0200

After 4 years I have finally decided to change my theme. It is very Mac OSX oriented, but I just like it so much. I've also removed a Gig of spam block logs from the DB, so it should be a bit snappier. Finally, I figured out why Google hates me, I somehow didn't run a DB upgrade script on the last blog upgrade, and a ton of links weren't working. They are now.

Dan broke the internet again!

nospam@example.com (Dominic White) — Tue, 08 Jul 2008 21:34:57 +0200

This will be fun to watch. Dan Kaminsky has sort-of published not-so-sekret ways to break DNS. Patches have been released to make things more random. "Full" disclosure at BlackHat.

From ISC:

"The method used makes it harder to spoof answers to a resolver by expanding the range of UDP ports from which queries are sent, thereby increasing the variability of parameters in outgoing queries."

I laughed with mirth and glee at the Emergent Chaos comment:

"DJBdns is in fact not affected as DJB had already implemented port randomness even though he didn't know it was an issue."

This means *all* DNS (except DJBdns) is vulnerable, many vendor patches to follow. Although, DNSSEC is the *right* answer.

SA Crime Stats 2008

nospam@example.com (Dominic White) — Mon, 30 Jun 2008 13:57:32 +0200

The South African Police Services have released the crime stats for the last financial year. I still need to wrap my head around the numbers, as many of the categories don't seem discreet, or intuitive. However, I think the executive summary contains some good insight into the 'threat landscape'. It also backs up several of my 'gut feel' assertions about crime in SA. However, as Russell points, there may be an independence issue, as the report is "written by the guys whose job is on the line", and I haven't found any information on how the stats were independently verified. I've culled some sections from the executive summary and given them my own headings, formatting and order. Whatever your take on crime in SA, these stats are a good read, and certainly more likely to be accurate, even with bias, than the eight year old drivel on Wikipedia.

Most crime in 'Megatownships' by drunks

Detailed docket, geographical and timeline analyses of the contact crimes confirm that at least two thirds of all contact crime [e.g. mugging, rape, murder] cases are strongly linked to specific social behaviour patterns which inter alia involve alcohol and other substance abuse and are mainly associated with informal settlements in megatownships.

Almost two thirds (66,0%) of all aggravated robberies are street/public robberies. These occur mainly in CBD areas and the black megatownships (e.g. Khayelitsha, KwaMashu, Umlazi and Nyanga) where ordinary people are robbed of their money, cellular telephones or other valuables at gun or knifepoint. The large majority of these incidents are therefore not high profile cases involving well-known people and are rarely reported in the media.

[I emigrated because all the poor people were getting mugged sounds less justified.]

If you're rich, don't live here

The carjackings and house robberies most frequently occur in the more affluent suburbs of Gauteng such as:

Sandton
Honeydew
Douglasdale
Brooklyn
Garsfontein

Anatomy of affluent crime

Extreme violence resulting in severe injuries or fatalities is only employed in a very small proportion of these carjacking and house robbery cases. However, extreme violence does occasionally occur because the crimes are usually committed at places where it is less likely for bystanders or eyewitnesses to intervene; firearms are more likely to be involved; the robbers want specific items (frequently the key to a safe or a car); and the perpetrators may be disposed to use threats or violence to obtain their aim. The victims may also react in ways that could trigger violence.

The rest of the world

South Africa compares quite favourably with the rest of the INTERPOL member countries with regard to the incidence of property-related and all the other remaining categories of serious crime. Most of the contact-related, property-related and other serious crimes indeed experienced decreases.

[It would be nice to know how we compare against INTERPOL member countries for non-property related and other serious crime.]

Stats are better than “the media”

Because the crimes frequently occur in more well-to-do areas, the chances of somebody well-known being targeted and even killed are much higher. Such incidents feature on the front pages and in the headlines of the media and reverberate around the world. Such focused and selective reporting on less than 5,0% of South Africa's contact crime, read together with the contact crime statistics, consequently creates an international image of South Africa as an extremely violent society.

Remember, correlation does not equate cause

Increases in the number of crimes heavily dependent on police action for detection are actually considered desirable. The 25,4% increase in the ratio of driving under the influence of alcohol or drugs is probably a result of much more stringent law enforcement by both Metro Police services and the SAPS during 2007/2008.

Microsoft (and HP)++ for SQL Injection Response

nospam@example.com (Dominic White) — Wed, 25 Jun 2008 06:28:19 +0200

Microsoft has released a security advisory detailing three ways to respond to the SQL injection attacks. This advisory doesn't covery a patch, just three tools:

HP Scrawlr is a light weight version of HP's WebInspect that will look for SQL injection flaws. I love that they used the Bobby Tables XKCD comic.
A new version of UrlScan (3.0 beta) the IIS version of mod_security.
A source code analyser which will identify SQL injection vulns, although it currently only works for ASP and not ASP.NET.

That's pretty awesome, although, as always, these should be used to aid clue, not replace it.

GeekDinner Johannesburg

nospam@example.com (Dominic White) — Sun, 22 Jun 2008 20:04:33 +0200

We had our second Johannesburg GeekDinner yesterday. We're keeping it small until we build a dedicated team/community, so it was more of a GeekLunch. Unfortunately, I missed Yusuf's talk, on why CSS is rubbish, due to a mistimed afternoon nap, but Tristan's on per-user app DBs for scalability was certainly an interesting challenge to the status quo, and his knowledge certainly carried him through his last minute volunteering. I did some live demoing of 0wning a browser with XSS Proxy. We got some serious geek all over the place, which was great, and I think this will grow into something good. Shehnaaz's hand made (from scratch) pizza's were amazing, and she was a gracious host along with Yusuf. The next one has been planned, but we're keeping it invite only until we have it more stable, thanks to nVent for volunteering.

Major SA websites hacked by China - nobody cares about the Web

nospam@example.com (Dominic White) — Fri, 06 Jun 2008 00:39:32 +0200

Over the last few weeks, we have seen a set of incredibly uncomplicated and simple attacks effectively compromise several hundred South African web pages, and several million internationally. Many of the South African sites compromised were important; including major media organisations, several government institutions, large mining houses and even one information security company, who still have not removed the pie from their face. The intention of the attacks was to use the compromised web pages to infect visitors with a variety of malware, but most commonly, a trojan which attempts to steal as many passwords as it can, including specific references to some internet banking sites.

The response to the incident from both consumers and the affected companies seems to indicate that when it comes to the web in South Africa, nobody cares.

The Attack

Let’s get the details out of the way so that we can wander over to the hand waving. The attacks involved a technique knows as SQL injection. For those of you that usually skip over tech details, fast-forward the next two paragraphs. SQL injection involves taking advantage of the way in which SQL statements are executed on the database by the web application, a more detailed breakdown is available after the article. A SQL injection usually means that an attacker can take near full control of the database, the machine hosting it and any applications using the database as a backend.

In this instance, the bad guys were using Google to search for vulnerable web sites, then injecting Microsoft SQL specific statements to insert a remote JavaScript include to the end of every table. This has a good chance of getting that JavaScript inserted into any web pages that are pulling their content from a database (i.e. most of them). When a user visits an infected page, the JavaScript would then try and break into it by using a variety of attacks against outdated versions of iTunes, AIM, RealPlayer, Acrobat Reader, Shockwave Flash among others. Once successful, some form of malicious software is installed to the user’s computer, most commonly a password stealer. Once an injection has occurred, the attacker can vary what it does to users. So, if your anti-virus program updates to detect the evilware, the bad guy can just change it and is more likely to be able to rapidly modify his app than the anti-virus guys are able to discover, analyse and block it. Although, we did not see too much of the latter stuff.

To summarise the attack:
Search Google -> SQL Injection on Web Site -> User Visits Website -> User’s Computer is Infected -> Bad Guys Steal User’s Passwords -> Bad Guys Steal User’s Money

In the security world this attack falls squarely into the category of ‘lame’. What I mean is, they did nothing complex for which there aren’t good, easy to implement solutions. Searching Google for potentially vulnerable sites is in this case not even targeting the low hanging fruit, closer to the old rotten fruit slowly dying around the base of the tree. Using SQL which only works against MS SQL, when SQL as a language is generic enough to craft something that works against Oracle, PostGres, Sybase and MySQL. Using the injection point to squirt in some JavaScript and ‘wasting’ the full power of SQL injection. Exploiting vulnerabilities in applications for which updates have already been released to fix them and a decent anti-virus program should pick up. Stealing something as simple as a password instead of doing something incredible like injecting an advanced rootkit that makes your Second Life character look like Michael Jackson. Finally, using single domains with no fast-flux survivability like those infuriating bot-herder, is all just boring. Then again, criminals do not need to be innovative when it is this easy.

The Outcome

These attacks have been wildly successful. Without using any of the advanced techniques we have seen botnet developers put together over the last year, or any decent ‘worm-like’ activity, they managed to hit 3.5 million web pages. In addition, they are not done yet. It seems tools are being distributed to do this stuff for you, and they only cost a few Yuan. It is more likely that we’ve seen so many successful attacks because the costs of running them are so low, and there are a few hundred people doing it. Whenever we see attacks that are successful and easy to do, they tend to continue for the next couple of months or years until they stop being successful. In short, expect more of these, and expect them to get more advanced.

The Response

The response has not been very varied from the South African online practitioners. Most of the time, when I contacted the developers, they knew about the problem and were working on it. This consisted of removing that instance of the infected web page, which was shortly re-infected. Worse still, often only the ‘known’ infected web pages were cleaned, so an organisation may have had 10 pages infected, but only cleaned 7 because they had not see the others.

However, the ‘real’ impact of something like this is not at a technical level, this has the potential to affect the business. There’s a real risk to the business’ reputation; most want to be known as safe, honest, well controlled companies; hosting viruses on behalf of Chinese bad guys does not reconcile well with that. There is a legal and compliance risk, whether it is industry mandated compliance such as Sarbanes Oxley and the Payment Card Industry’s Data Security Standard or legislative requirements such as the up-coming Protection of Personal Information Act, the risks of non-compliance in these cases, or worse, legal action arising from it, can be quite dire. Finally, there is a financial risk, especially from web sites that rely on their online presence. Some of the affected media organisations, where having Google mention that ‘this site may harm your computer’, could have their ad revenue seriously dented along with their readership. However, right now, this just sounds like fear mongering, as we have not seen any of this happen. Maybe it still will, but it doesn’t seem that many of the affected company’s IT management have got wind of this, or we wouldn’t have seen the fix-the-symptom patch-ups we have, and I am fairly certain there are no CFOs losing sleep over this.

The hand waving

The conclusion I draw from all of this is that, at least in the large corporate space, no one important in South Africa really cares about the Web. The companies are not too worried that this will amount to any sort of real risk to them, and users are mostly too clueless about security to realise, let alone protest, the fact that their favourite radio station’s website is trying to steal their passwords. Worse still, the new importance-making-push into Web 2.0 is going to exacerbate this security problem, as a new wave of more complex and poorly secured tech washes over the IT industry. In the meantime, watch this space and if you are lucky enough to have not been infected because you were not using Microsoft’s SQL server (make no mistake, it was luck), start getting your devs trained up in writing secure code.

Appendix

SQL injection involves taking advantage of the way in which SQL statements are executed on the database by the web application. If, for example, you have an input field asking me for my name, and slap my input into a piece of SQL such as:

INSERT INTO names VALUES ('Dominic');

Then, if I enter my name as: Dominic’); DROP TABLE names;– , the resulting SQL statements becomes:

INSERT INTO names VALUES ('Dominic'); DROP TABLE names; --');

The name will be inserted, but the database will also delete the entire table. This is a fairly tame example, and in reality, a SQL injection usually means that an attacker can take near full control of the database and the machine hosting it.

The ‘right’ way to defend against it is to use parameterised and pre-compiled SQL statements so that anything you input cannot ‘break out’ and run awry. It always pays to be safe, and so making sure the application account has minimum database privileges, the database has been securely configured and you have firewalled properly goes a long way to either stopping an attacker in their tracks or making it easier to spot them. Please note that ‘input validation’ is not the right way to stop this, and those expensive Intrusion Prevention Systems and Web Application Firewalls will not be able to either.

This was originally posted for TechLeader at the following URL.

Blogging on TechLeader

nospam@example.com (Dominic White) — Fri, 06 Jun 2008 00:35:00 +0200

The guys over at the Mail & Guardian invited me to write for their TechLeader group blog, it is available here. I will be reposting content here after it goes live there. The audience is more technical and less security and the writing will attempt to reflect that.

SABC Blacklisted by Google

nospam@example.com (Dominic White) — Mon, 02 Jun 2008 23:48:02 +0200

I've been ranting about the SQL injections for a while now. While infecting your visitors with malicious software semi-silently generally doesn't put the pressure on the right people (i.e. the externality lies on the infected user not the infecting business), having your organisation blacklisted by Google shifts that externality. Here are the screenshots of Google warning me that the South African Broadcasting Company (SABC) may harm my computer. Check it yourself by googling 'sabc'. At the time of writing, the SABC had fixed the page.

Strangly enough, of the almost 100 other infected SA domains, the only other two South African domains blacklisted were:

gowerpower.co.za
4hair.co.za and fourhair.co.za
saart.net

While we're at it, I've found the following *new* domains injected into SA sites:

nihaoel3.com - 21 700 (International), 2 (Local)
qiqigm.com - 80 500, 3
woai117.cn - 5, 1

Finally, as a last, unrelated, poke in the eye, it seems the 'International Housing Research Network' a .gov.za site has had it's forums defaced (they've been contacted):