Masked Passwords Should Stay... Probably

The WebAppSec world has been awash with conflict following Bruce Schneier's discussion/comments that the masking of password entries on computers (and smartphones) should be done away with.

The discussion itself has morphed to some degree (well, quite a bit really), but essentially the argument is that the masking of passwords as they're entered in to a computer as part of an authentication sequence shouldn't be masked because of usability issues.

Now first off, I'm not a great fan of masked password entry myself, and I'm guaranteed to screw up a password several times each day, but I still think its a useful and relevant security technology. True, it's not much better than the password it's trying to protect - and it offers as much protection as the padding on a cars steering wheel does in a head-on collision - but it serves a purpose.

But I also split my answer. I think that password masking is less relevant to smartphones and could more easily be done away with. At least with a smartphone you can pull it close to your chest and obscure the password you're typing - it's damned near impossible to do the same with the LCD screen on your desk without looking like you're trying to theive it.

As with any security technology, theres a time and a place. Masked password use belongs as part of desktop protection of Web applications - but less so for smartphones (and fat fingers).

ATM Jackpot Talk Blocked from Blackhat

One of the few talks I was actually looking forward to seeing at Blackhat this year has just been canned due to corporate pressures.

Barnaby Jack was meant to be delivering his new talk "Jackpotting Automated Teller Machines" in Las Vegas but has had to cancel it due to the affected vendor(s) not getting things fixed in time and subsequent pressure being applied to his employer to drop the talk.

The abstract for Barns talk was the following (now removed from the Blackhat site):

I've always liked the scene in Terminator 2 where John Connor walks up to an ATM, interfaces his Atari to the card reader and retrieves cash from the machine.

I think I've got that kid beat.

The most prevalent attacks on Automated Teller Machines typically involve the use of card skimmers, or the physical theft of the machines themselves. Rarely do we see any targeted attacks on the underlying software. This presentation will retrace the steps I took to interface with, analyze, and find a vulnerability in a line of popular new model ATM's.

The presentation will explore both local and remote attack vectors, and finish with a live demonstration of an attack on an unmodified, stock ATM.

This isn't the first time a scheduled high-profile talk has had its rug pulled out from under it at Blackhat. Unfortunately this kind of thing is becoming a more regular occurrence at large technical security conferences - which is a shame.

Interestingly enough I had proposed a talk for Blackhat Las Vegas this year along with Stefan Frei which would have discussed how to stop this kind of thing from happening in the future. Pity it wasn't accepted this time round (would have been prime fodder for the ATM media circus) - but it gives us a bit more time to build and test things out. For those that are interested, the talk was going to be about "Guaranteed Disclosure" - abstract as follows...

Vulnerability disclosure – it’s close to all our hearts. For the last decade the disclosure debate has swung from Full Disclosure through to Responsible Disclosure, and every faction in-between. Let’s step up the pace and throw in a new disclosure paradigm – Guaranteed Disclosure.

What would the vulnerability disclosure landscape look like if you could disclose a vulnerability to a security vendor and etch in stone when it’ll become public? No sidestepping by the vendor – they’ve got 90 days to fix the vulnerability because that’s when the vulnerability will be public – and you can honestly say “it’s out of my hands, the timer has already begun!”

In this session we cover a new option for vulnerability researchers to independently and securely disclose their findings to vendors – and guarantee that they’ll be publicly disclosed on a date in advance, despite any future pressure from the Vendor or Government. Guaranteed Disclosure will ensure that hard limits are placed upon the time for vendors to fix a vulnerability and make it public – without the researcher being pressured to halt.

Barns -- looking forward to your talk whenever you get the corporate nod to finally give it.

TrendLabs JS_VIRTOOL Adaptations

The TrendLabs blog has an interesting take on a new variant of JS_VIRTOOL they've spotted in the wild. This variant is designed to make it difficult/impossible to analyze shared samples or dissect if the site context is lost.

How does this deobfuscator thwart security researchers? From Trends blog...

1. It retrieves the URL where the malicious script is located.
2. It retrieves its own function and adds the string of the URL.
3. It computes the CRC of the function plus the URL.
4. It decrypts an encrypted code in the script body using the CRC that was computed.
5. It executes the decrypted code using the eval() function.

It's not precisely rocket science, but it's more that sufficient to bypass static analysis investigation and network-based detection systems.

The particular technique of tying the decryption key to the URL of the source has been discussed for several years - and has been tried in the past (legitimately) by various Web sites that endeavor to protect their content from plagiarism. It's neither elegant nor a robust protection mechanism against host-based manipulation. - but from a network perspective it's "good enough".

Threat Naming
One point to note. Trend's the only folks using the name "JS_VIRTOOL" for this vector - so don't be worried if your preferred security vendor has no idea what you're talking about if you're wanting to check to see if you already have protection against this particular threat. Just ask them about obfuscated malicious JavaScript and JavaScript payload protection.

Something else to note... While it's a difficult threat to counter at the network level (and to not false-positive on legitimate sites that use similar techniques to protect their site's content) - there are a number of interesting in-the-browser technologies that will protect your host from anything malicious within the JavaScript payload - and they don't care about the obfuscation (since that's not the 'dangerous' part).

Making Money with Your Own Stealthy Botnet - Part II

Continuing on from yesterdays discussion of making money from botnets the stealthy way using a customer advertiser approach, lets look at another "if I had a big botnet I'd..." vector for making real money.

2. Pay-per-Installs
Pay-per-installs are a more recent permutation of click-based advertising payment schemes, except in this case the affiliate payment model is premised on getting others to install a piece of software.

As the owner of a Web site you get paid a small amount for each time a visitor to your site downloads a software package and installs it on their computer. Sounds dubious to you? Well, yeah, it's an odd business model, but there are quite a few service providers in this realm - so it looks like someones making money from the system somewhere. (note: there's a more detailed discussion on how the pay-per-install business operates at the end of this blog).

Exploiting this payment system with a botnet appears to be pretty obvious. With 50k victim computers under your control you simply remotely install the software packages on each of them and collect the cash at the end of the day. It's so obvious in fact that there are quite a few botnet operators out there already doing this. Early last year I was alerted to an enterprise-level victim that had several thousand infected hosts worldwide and was trying to figure out why these hosts were routinely installing and installing software - unaware that they had been compromised and were under the control of a bot master conducting a pay-per-install fraud.

But, even though this particular scam is already in operation, it looks to me to be an interesting way of making money from a botnet. And, based upon what I've seen and heard, there is still quite a bit of room for "improvement".

If I owned a botnet of 50,000 victims, I'd aim to make it more stealthy than whats out there today. Some obvious advancements would include:

1. Stealthy installation. With the bot agents already operating with administrator or system-level permissions, I'd make sure that an package installations are done without any user visible prompts and confirmations. In some cases this may be quite difficult because several of the more popular (and higher paying) pay-per-click affiliate systems attempt to thwart "illegal" installation of their software and have hard-coded clickable popup boxes or prompts for user supplied information. That said, most bot agents today have access to scripting languages and I'm certain I could automate the clicking and filling in of any forms - so that's not going to be a problem.
2. Log management. From what I've observed so far, it's going to be important to manage the application and security logs on the host. I'm going to have to either prevent my software installations from being logged and audited, or to erase any entries that crop up. This would be pretty easy for home PC's, but may be more difficult for enterprise victims that report their logs centrally. In which case, going with the former method (preventing the logs from being updated) is going to be preferable. Again, this is straight forward as long as my bot agent is operating with system permissions.
3. Timed uninstall. I'm going to want to have a mechanism for automatically uninstalling any software packages that I've installed. Ideally I'd set that up in advance and ensure that there's some kind of scheduling ability in my bot so I don't have to remember to uninstall it myself (or if I temporarily loose C&C over the host at any stage).
4. Fatal Error Simulator. It'll be helpful to have a component that'll generate a "fatal error" kind of message to the user of the computer. Ideally I'd aim to install any pay-per-install software packages stealthily and when the user is not currently interacting with the computer (e.g. monitor if the screen is locked, a screen-saver is running, or whether the mouse and keyboard haven't been tuched for 10+ minutes) - I might even monitor the local hosts time and do my installations in the wee hours of the morning. Regardless of the scheduling aspect, throwing up a fake fatal error message either instructing the user to reboot (or timing down to a forced reboot) or just blue-screening the host, will be handy if any of the packages require a reboot to function (e.g. some packages require a reboot before they phone-home and the pay-per-install vendor ponies up the money).
5. Hide the popups. It seems that many of the better paying pay-per-install packages are effectively spyware with ad popup capabilities. I'd definitely want to make sure that those popups never appear on the screen and bother my poor victim user (I'm trying to be stealthy remember) - and I'll probably want to "click" on a few of the ads just in case someones monitoring whether the software was actually installed legitimately and is being used.
   

Counting the Money
Given the investment necessary for configuring my botnet to conduct this pay-per-install fraud, how much money could I be expected to make?

If I was to go with one of the affiliate providers, here's what I'd be looking at on a per package install basis (assuming the majority of my botnet is in the US)...

• Zangocash - upto $1.45
• CPALead - at least $1
• WaveRevenue - $0.60
• ExeRevenue - $0.13
• IframeCash - $0.14
• VombaCash - $0.45

Actually the selection process isn't quite as obvious as it may seem. There's all sorts of "hidden" criteria for payment with the pay-per-install organizations that appear to offer the most. Regardless, lets knock off the first two and see what $0.13 to $0.60 could earn me...

Based upon a botnet of 50,000, lets assume that I can roll out the pay-per-install packages to 90% of them - that'll yield between $5,850 and $27,000. Not too shabby. With a bit of luck I can install a new package at least once per week, and uninstall older packages after I've been paid for their installation (allow 4-6 weeks). That means I could potentially be earning something like $20k-100k per month!

I suspect however that I'd have to split my pay-per-install affiliation amongst multiple providers as they'd soon get wise to the fraud if they had to hand over that amount of cash on a monthly basis - so I'd probably have to throttle things back a little if I'm to remain under their detection radar. I'd probably aim to earn about $10k per month through this botnet money-making scheme without too much fear of being spotted. That said, some of these pay-per-install vendors appear to have really open minds - and aren't shy of doing business with known botnet operators.

That's a reasonable return on my investment in setting up the delivery mechanics of the fraud. And there's no reason why I can't continue to use the botnet simultaneously for other fraud schemes. It's not going to make me rich, but it'll be handy to cover the costs of growing my botnet further.

The Pay-per-Install Business
When I first encountered pay-per-install vendors, it was back in the mid-1990's and shareware was all the craze. Some software vendors cottoned on to the fact that they could make more money if their new application was widely available and people installed it - thereby eventually registering the software or purchasing the subscription. Given how competitive (and crowded) the shareware distribution system was back then, paying a BBS operator or Web master to promote their software above other products made a lot of sense. Payments of up to $20 per successful installation and user registration weren't uncommon.

Since that time, the model has been refined and business permutations compete against each other. There are even some pay-per-install companies that have turned this model in to a successful affiliate marketing model.

The software being distributed by many of these pay-per-install vendors today isn't precisely something most computer users would want running on their computers. If it's not an actual virus (or bot), then it's going to be spyware or adware. More than likely, it'll be the latter - as this is how many of the pay-per-install operators make their money.

Getting started in this business as an affiliate is simple. There are plenty of sites and forums providing advice and tactics for making money installing this unwanted software. A quick google for "pay per install forums" will take you to over 12,000,000 sites/pages of information and advice.

Then there are several review sites - complete with star ratings of the pay-per-install vendors.



Finally, here's the FAQ from one such pay-per-install vendor (which I don't really believe in their non-virus claims - but you get the picture).

What we pay for?

We pay for our promotional software installation with your affiliate ID.

Are you making traffic quality checks?

We are making the analysis of each affiliate traffic. If in two weeks we do not leave on a recoupment point, we keep the right to suspend work with an affiliate, we pay to him for the poor-quality traffic ( exactly so much how many we earn) and leave him.

Is your software a virus?

Emphatically - no ! Our program does not inflict harm the computer of user and steal no personal information. The primary purpose of our software is advertising (such as popup advertisements or hijackin search result) and nothing anymore.

Do you allow SPAM traffic?

NO, exposed affiliates will be blocked and won't paid.

Do you have active referral program?

Up to know we don't have referral program for our affiliates, but we are working on such program implementation.

What is your actual install rates?

Basic rates are listed here, but after week of stable installs flow you rates may be reconsidered by contacting support.

What is your minimum payout?

The minimum payout for everybody is $10.

What payment methods are available?

Webmoney (0.8% payment commision)
WIRE transfer ($50 payment commision)
ePassporte (1.8% + $2 payment commision)
PayPal (3.5% payment commision)

It's interesting to note that the grammar and spelling doesn't appear to have come from a native English speaker, and that this particular site is hiding it's registrant details via PrivacyProtect.org.

Making Money with Your Own Stealthy Botnet - Part I

Over the last month or so I've had quite a few conversations with friends and former colleagues concerning what are the "cool" things you could do with your very own private botnet. Most of these conversations stem from them wanting to learn more about what I'm now doing - having joined Damballa a little while ago - and some of the nasty things criminals are doing with their botnets... which often deteriorates in to a "if I had a big botnet I'd..." type of discussion.

So, several ideas have been thrown around and I figured it would make an interesting series of blogs.

If I had a botnet...
"If I had a botnet..." is an interesting way of thinking about how criminal use of botnet may evolve over the next few years. While the news is full of stories and stats about monster botnets being built up and the volume of spam they're capable of pumping out, those are actually the boring ones (from a threat perspective) - and probably the least efficient use of a botnet. If your intent is to make money from a botnet, then using it for spam is effectively chump-change.

So, "if I had a botnet... how would I make real money from it?" - that's the killer question, and the one I'm going to explore.

1. The Custom Advertiser
Lets assume that I have a medium-sized botnet of some 50,000 victim hosts - most of which are home PC's on local DSL networks. Since acquiring (or reacquiring) those victims is a raw cost to me, anything I do with my botnet needs to be subtle and go undetected for as long as possible.

The users of the bot-infected computer, like most of the Internet-browsing planet, are constantly surfing sites plastered with advertising. Since my bot-agent is running on their host and is capable of both hooking the TCP/IP stack (i.e. man-in-the-middle) and operating within the browser (i.e. man-in-the-browser), I can intercept, view and edit any Web content before it gets rendered within the browser.

Since advertising seems to be a profitable route, why not replace those ads with ads of my own choosing? It's simple to do - in fact it's damned-near trivial. It's not even a new idea - some major ISP's around the world have toyed with doing similar things in the past (if not actually doing it today).

Armed with this capability to replace advertising (such as anything from ad.doubleclick.net etc.) a handful of business opportunities suddenly appear:

1. Strike up a deal with a particular organization and offer to plaster their ads on to every page 50,000 people view for an entire day.
2. Modify the code surrounding the legitimate advertisement such that if the user click on it they'll be taken to a different site. This could even be keyword based - for example, any legitimate ads for drugs and health care products get redirected to Canada Online Pharmacy. Think in terms of Phorm for ad replacement.
   
3. Replace the advertising with my own ads that are actually just redirects/proxies to ads being served from sites I already control. That way I'm serving legitimate ads, but any click-throughs are being associated with my Web site rather than the site the user was actually on.
4. Screw around with a company I don't like. Since most managed online advertising campaigns are supposed to be targeted against a specific audience - and they pay through the nose for each click-through. I could plaster their advertising everywhere such that they exhaust their daily online budget really fast and miss their target audience.
   

I'm sure the list of opportunities could go on and on, but lets look at the feasibility of these replacement scams for making money.

1. I think it would be a struggle to entice a legitimate/mainstream company to use my advertising services, so I'd be stuck selling to some company comfortable operating in the gray areas of the Internet. This means I'm not going to be able to attract top dollar for the advertising - so maybe I can only charge $2-5k per day. I'm also going to have to be careful of serving up too much of the same advertising to the same people and having them suspect something isn't quite right with their PC and asking questions that could reveal what I'm up to.
2. I'd likely have to deal with the same kinds of gray companies as for (1), but I could probably make more money. I'd be expecting the same daily rate of return on the advertisement placements (e.g. $2-5k), but I could probably also get a cut of any subsequent sales (e.g. like the way pharma-scam franchises currently work).
3. This could potentially yield me the most money. It'll be a little unpredictable, and I'd have to be careful not to be detected by the real advertising company (e.g. Google has some pretty sophisticated means for spotting click-fraud, and might catch this vector - but I could do some other magic such as modifying the victims REFERER fields to fake the source of their click). The advantage with this is that I could set it up all online and never actually have to speak with anyone... and I'd get cheques in the mail each month.
4. I don't think I'd actually make any money out of this unless I approached a competitor to the business being targeted. I might be able to get a few hundred dollars a day, but I'd end up having to explain how the scam works to them - which would shorten the viable life of the scam.
   

What do you think? Are there some better money-making business opportunities focused around replacing advertising inside the Web browser?

Look out for the next installment of Making Money with Your Own Stealthy Botnet...

New Bot-powered Pharmaceutical Scam Network

The other day we staggered across a strange botnet. It was only small as far as IP addresses were concerned, but gigantic as far as domains under management (greater than 25,000 currently in use). The cost of registering that number of domains is a significant investment by the botnet operators - at $20 each to register, you're looking at $500k in setup costs alone).

But the strangeness doesn't end there. The botnet is being used for pharmaceutical scams (i.e. Canada Drugs), but the DNS lookup process is messed up. Somehow the botnet operators have figured out how to manipulate the .com root servers in to doing some weirdness - and having them act as the authoritative resolvers for the 3LDs.

I'm not sure how this situation arose, but the criminals behind this are making good use of the flaw/exploit/manipulation. What they now effectively have is a system that prevents the good-guys from shutting down the resolution of where their scam Web sites are. Not good.

I'm still looking in to how this arose and what the real (longer-term) ramifications of this are. But its new to me and definitely in the strange/weird department.

I've posed a full blog about this botnet over on the Damballa site - Strange Bot-powered Scam Network. Take a look at whats going on.

Hacker Halted USA 2009

Next week, in the run up to this years Hacker Halted USA 2009 conference, I'll be delivering a EC-Council webinar covering DIY Malware Construction. The presentation covered the dynamics of building custom malware and making it undetectable to anti-virus - regardless of signature, heuristic or behavioral detection engines (but eventually protectable one the good-guy AV folks finally get a sample and develop a dedicated signature).

If you've got the time, please join the webinar. You can see a line up of past and future presentations here.



With regards to main conference event, well thats not until September 23-25 down in Miami. I'll be presenting on the topic of Factoring Malware into Web Application Design - which will of course be very cool :-)

The Dynamics of Pharmaceutical Botnets

The other day I was looking in to pharmaceutical spam - well, actually the botnets that power their spam portals - and threw up a new blog concerning the topic over on the Damballa site.

The blog - Takedown-resistant Double-fluxing Pharma-bots - takes a peak at some metrics governing one of the double-flux enabled botnets. It's interesting to note the persistence of the botnet even after 50,000+ shutdowns etc.

URL Shortening Equals Short-cut to Drive-by-download

URL shorting has always been a convenient vector for obfuscating a malicious URL. They've been used in phishing URL's for nearly a decade now, and in drive-by-download's for almost as long. Now it seems that another flaw in shorten URL services have been exploited by the bad guys - exploiting the hosting provider and getting ALL shortened URL's to point to a malicious drive-by-download URL.

That's what happened to Cligs Sunday/Monday this week.

Apparently, according to their blog, some 2.2 million shortened URL's were affected - redirecting victims to malicious content over at freedomblogging.com. Not pretty - but hardly unexpected.

From their blog...

"... I’m restoring the URLs back to their original destination states. However, the most recent backup is from early May, and so we may have lost all URLs created since then. My daily backups with my host were turned off for some reason, which is another story.

The restoration will take a long time - it’s millions of URLs that have to be individually restored - and so you may not see your proper links till tomorrow."

I suspect that this won't be the last time a shortened URL service provider will be compromised. Theres good money to be made by the bad guys if they exploit these kinds of services - so there's motivation and skills in abundence to do so. Frankly, the providers of shortened URL services aren't known for their security ambitions.

Blacklisted Security Researchers

As a security researcher you often encounter strange and unexpected behaviors visiting known-bad sites. In most cases you're actually hoping something will happen to your unpatched and disposable Web browser as you navigate a suspicious site that was reported to you by a customer or managed service provider.

You arm your system with numerous monitoring agents and wait for the unseen explosion of activity as your VM gets infected from some drive-by-download site. Or maybe not.

In the past I've talked about advancements to the X-morphic Attack Engines used by drive-by-download operators and how they often "blacklist" IP addresses of known security research institutions - such that the "good guys" don't get served the malicious goodies, and can't then discet the code and develop new protection signatures/algorithms.

Until recently I'd never actually seen one of those blacklists of security researchers that the bad guys don't want to serve their crimeware to up close - until now. Yuval Ben-Itzhak over at Finjan managed to uncover one such list from a crimeware toolkit and posted a nice blog about what they found - "Security vendors watch out, your IP address might be blacklisted by cybercriminals".

I guess the question now is whether I can get my home DSL netblock added to the blacklist for safer browsing by the family? Probably not.

Understanding Botnet Communication Topologies

Not all botnets communicate the same way. It's disappointing, but true. Yet many of the organizations I deal with struggle to understand the significance of a botnet's communication topology and the tools/services botnet operators typically use to make their botnets resilient to blocking or shutdown.

By understanding how bot agents communicate with their CnC infrastructure, security teams can better adapt and tune their existing protection systems to combat.

This new whitepaper I wrote - "Botnet Communication Topologies" - is a plain language analysis of the CnC topologies commonly seen in the wild. It covers the topologies used today by botnet masters as well as describing the fluxing technologies typically deployed in conjunction - making them more robust to takedown and blocking.

The papers objective is education as to the nature of the threat, and seeks to explain the relative strengths and weaknesses of the botnet topologies - with a view of enabling organizations to make better decisions pertaining to their proposed blocking strategies.

Exploring the Botnet vs. Malware Relationship

There are many misconceptions when it comes to understanding botnets. One of the most significant is the fallacy that a single "new" malware-type (or family) constitutes a single botnet.

For example, Zeus is a very popular family of bot malware. It's created using a commercially available DIY malware creator kit. However, it's not as if it's only purchased by a sole entity and that every infection of Zeus around the world is under the CnC of that individual. Nothing could be further from the truth. Just because the bot agent or piece of malware is of the same family, does not mean that compromised assets belong to the same botnet.

Similar arguments hold true for Conficker. It's amazing to me that so many people are blinkered in to their thinking that there's just one criminal entity behind all the Conficker installations around the work.

In an effort to educate security professionals as to the nature of the real threat, I've written a brand new whitepaper - The Botnet vs. Malware Relationship - covering the mechanics of botnet building based upon the use of popular DIY Malware creator kits. The paper discusses how CnC channels are affected and why botnets don't have a one-to-one relationship with malware.

The paper is designed to be vendor neutral and I've tried to use as plain as language as possible in an effort to explain the dynamics behind botnet building. Feel free to pass the paper along and provide feedback here. There are more educational papers on their way...

Corrupted Files for Sale

I stumbled across an interesting site earlier today - ideal for all those folks needing a little extra time beyond a hard-deadline for submission. The premise is an improvement over the "my dog ate my homework", in that you submit a corrupted file on the submission date - it takes the receiver some time to figure out something was wrong - and you gain a few extra days as the recipient asks you to "resend" the submission file. Corrupted-Files.com offers these corrupted files for a small fee.

How it works:

1. After purchasing a file, rename the file e.g. Mike_Final-Paper.
2. Email the file to your professor along with your "here's my assignment" email.
3. It will take your professor several hours if not days to notice your file is "unfortunately" corrupted. Use the time this website just bought you wisely and finish that paper!!!
   

So, for a fee of $3.95 you can purchase a corrupted file (DOC, XLS, PPT). But, in the words of the sites author...

"Please Note: I had deadlines with professors too, but I still got my sh*t done on time - its called Red Bull. If you need an extension, just be honest and ask your professor before you use a corrupted file."

Bonet SQL Injection & Conficker

Nowadays most organizations are familiar with SQL Injection - even if only as a "critical" vulnerability that happens to get the techies hot under the collar. Most CxO's I encounter understand the significance of the threat, even if they have no idea as to it's nature.

That said, even amongst most techies, the general perception is that SQL Injection is difficult and noisy - i.e. you need to understand the database/table structures to successfully hack it, and the repeated attempts to hack/enumerate the database would quickly be detected. Which, to my mind, is a rather strange (and sorry) state of affairs if that's their argument counterpoint to investing in more advanced protection.

Regardless, the real situation concerning the threat is that both arguments (or "defenses") are flawed - particularly so when you understand how botnet-based SQL Injection attacks occur.

Many people are unfamiliar with the current state of botnet-based attacks and just how advanced they've become over the last couple of years. So, with that in mind, I wanted to chat about the state of SQL Injection attacks launched from botnets.

Older SQL Injection Bots
Mid-2008 saw a number of press alerts and media stories covering the Asprox botnet (at the time estimated to be between 200k-600k bot agents) getting updated with a new module called "msscntr32.exe" which contained a automated SQL Injection attack kit. The Asprox botnet had gained notoriety the previous year due to its robust fast-flux command and control (C&C) structure that made it an incredibly reliable spam source.

At the time, the Asprox botnet was using the SQL Injection module mainly for injecting new drive-by-download iframes into vulnerable websites - thereby helping to build a bigger botnet.

The general process for Asprox (and several subsequent copy-cat botnet engines) was:

1. Armed with a "seed" SQL vulnerability (e.g. a known page type or URL parameter structure), the attack engine queries Google for other pages that contain the key words/structures.
2. A list of potentially vulnerable pages are identified within the returned search findings.
3. A preformatted SQL Injection string is constructed, and the attack engine iterates through each search finding - sending the SQL Injection exploit to each page/host.
4. Part of the exploit string contains the content that the attacker wants to inject in to the vulnerable application database - typically an iframe containing a URL that would direct potential drive-by-download victims to a host that botnet operator has prepared specially to serve Web browser exploit material and install bot agents.
   

In general, the attacks were unsophisticated. Each bot agent was largely left to its own devices to locate and attack vulnerable Web applications, and there was no intelligent load-balancing between bot agents via the C&C - so many vulnerable sites fell victim multiple times. While unsophisticated, they were quite successful - with some botnets successfully compromising hundreds-of-thousands of vulnerable Web applications.

Botnets agents like Conficker have been regularly updated with modules capable of operating in this fashion and have been observed launching these kinds of unimaginative SQL Injection attacks. Check your HTTP Web logs for User-Agent strings such as "NV32ts" to see if someone's pointed the botnet at your Web application.

Newer SQL Injection Bots
As is so typical in botnet development, "cool" features mature and morph really quickly. While the first Asprox botnets (and their clones) operated more akin to Zombie agents than bot agents, their botnet operators quickly added better centralized control of the SQL Injection mass attacks.

The SQL Injection attacks conducted by the more advanced bot agents (or downloaded malware) make better use of scripting engines and consequently are much more versatile attack platforms. A limitation of early generation bot SQL Injection resulted in the same vulnerable Web applications being hit multiple times by the same botnet - better scripting language use and more coordinated CnC overcomes this.

Consider the newer twist on the attack...

1. The bot master conducts a Google search for Web applications/sites potentially vulnerable to a new SQL Injection vulnerability. Typically this would be done via an open proxy or sacrificial bot agent so that the CnC doesn't give away it's position.
2. The bot master divides the list of potentially vulnerable sites in to batches (of the order 10-20 hosts) and allocates the sub-list to a particular bot agent along with the specific attack string.
3. The bot agent itterates its way through the batch it was given and reports its status/success to the CnC server - whereupon it is given a new batch to attack.

In this model, there is no duplication of effort and the botnet operator can change the dynamics of the attack (and iframe details) at anystage.

Blind SQL Injection
Given the pace of evolution its probable that the threat is already evolving to include blind SQL Injection tooling as well. With blind SQLi, the resultant enumeration or alteration of the backend database are not visible directly from the page's content - and the attack must effectively "brute force" it's way through an enumeration process.

The tools to conduct this class of attack have been available for a couple of years within the pentesting community - however, beyond proof-of-concept, they've never really amounted to much because it's a time consuming attack. However, given the capability to batch attack processes to distributed bot agents and improvements in CnC management systems it's now become much more feasible for criminals to launch blind SQL Injection attacks against vulnerable sites.

I haven't been asked to investigate any notable database hacks for a while now so I've not seen evidence of botnets bening used in this way to date - but from following discussions on various underground boards, the potential for attack hasn't been lost on the bad guys, so it's only a matter of time (if not already happening).

For the timebeing though, the bad guys will probably persist with single string SQL Injection attacks (i.e. send GET/POST a single string of SQL Injection commands to a server with an embedded iframe) rather than more sophisticated enumeration and data egress attacks - mainly because it's easier and there's still money to be had that way. However, I'd expect some of the more cutting edge botnet operators to up their game and pursue the data theft route in the later stages of the year - mainly because it's becoming more profitable and they've almost perfected their systems.

DIY Malware - Octopus Keylogger

As is so often the case, I'm trying to pull content together fresh content for a presentation at the last minute - this one about DIY malware creator kits.

So, with a quick browse and a few Google searches I come across a batch of new DIY kits - "new" in the context that I hadn't stumbled upon them before (neither for public download as a generator kit or circulating "in the wild" as malware).

I find it interesting that there is such a variety of region-specific DIY kits.

One of the regional DIY kits I came across has just made the transition from freeware to a commercial offering. This kit - called "Octopus Keylogger" - has been developed by a Spanish author and offers the usual assortment of keylogging goodies for the low price of €20 ($30)...

* Encrypted FTP and Email of captured key logs,
* UPX compression
* Local and remote keylogging
* Peer-to-peer infection vectors
* Bypassing of host system logging
* Downloader creator
* "100% undetectable" executable stub
* Scheduled uploading of captured key logs
* Disabling of Task Manager
* Add two autorun's (HKEY_LOCAL_MACHINE) and (HKEY_CURRENT_USER)
* Supports Windows XP SP2/SP3, Windows Vista and Windows 7

The author, SharkI, has been experimenting with the keylogging technology for quite some time and this latest commercial version appears to have been based off the the DigitalX.

SharkI has previously published the keyloggers and DIY creators kits called:
* Royal Stealer (now in to its second edition - source code for the first version is now public)
* Virus Maker (written in visual basic)
* Call of Duty WAW Stealer (game license key stealer)
* Call of Duty 4 Stealer



On the point of Royal Stealer, it's interesting to note which applications the tool is designed to steal passwords and obtain registration keys from...
* Internet Explorer
* Mozilla Firefox
* Windows Live Messenger
* Winzip
* PhotoShop 7.0
* Symantec Anti-virus
* No-Ip
* mIrc
* Norton Antivirus
* COD SAGA (Game)
* Burnout Paradise (Game)
* Crysis Wars (Game)
* Counter Strike (Game)
* BattleField2 (Game)
* RainbowSix (Game)
* The Gladiators (Game)

Obfuscated PDF Exploits

This year has seen a flurry of PDF related vulnerabilities and exploits circulating (several of them being zero-day). The specifics of the vulnerabilities vary marginally, but all-in-all I'd attribute the source to be Adobe trying to do too much with their portable document format without due consideration for the complexity they are introducing to the format. That complexity is coming back and biting both Adobe and everyone obliged to have Acrobat installed on their system.

I know that Adobe make reasonable investments in their security QA and even employ some of some of the best consulting bug-hunters out there today. However, the complexity of their product - in particular their rapidly evolving scripting language support - is turning in to a real pain in the arse.

Casting that pain-point aside, it's been interesting studying the exploit techniques being used by the bad guys leveraging the vulnerabilities within the Acrobat PDF format. As with most exploits, copy-paste is rife with (by my estimation) the majority of "new" attacks being tweaks to existing exploits or techniques - which is practically verbatim for all Web browser exploits.

Sticking with the decade of Web browser exploit evolution as a yard stick, we're only now just seeing some of what I'd call "advanced" script obfuscation techniques making their way to the PDF exploits. I think a lot of it has to do with the fact that most perimeter defence technologies have now incorporated good PDF document parsers and can see deeper in to the files (early on the PDF content was just "some kind of file" and it was simple strings matching).

The results are some interesting obfuscation techniques particular to PDF's rather than generic HTML-based JavaScript. For the time being these obfuscation techniques are specific to their authors (i.e. little copy-paste going on) so can serve as decent markers of their origination point. In the longer run, the copy-paste brigade will muddy those waters - and perhaps the best-of-the-best will become metamorphic creation tools by the end of the year.

If you're after a little more reading on the subject, the folks over at WebSense have posted a nice blog today titled Complex obfuscated PDF exploit.