Discussion on:

Crimeware: What I didn't know

I talked to Joe Stewart, malware researcher with SecureWorks about banking crimeware. On-line banking is not hopeless, but certain steps need to be taken to remain safe.

hmmm i need to go get me a trojan kit lol thats messed that you can buy malware kits.

That just about any sophisticated malware can be purchased. In fact there is a shift in direction by malware developers. They are really not the users any more. They build and sell. I suspect that makes it safer for them.

It would seam to me that the bank having and maintaining a dial-in banking service would work better. It is not like there is huge amounts of data (read graphics) that would seriously bog down the dial-up connection. How many machines don't have an on-board modem these days?

Is it not virtually impossible to highjack that kind of connection if there isn't another networking source? Short of eavesdropping on the phone line somehow, and encryption should take care of that easy enough.

Of coarse all other online services would need to be disabled. And there would probably need to be site specific software but, hey, if it is unspyable what is wrong with that?

I can guess at a few things needed:

- phone wire quality is still sketchy outside of larger towns. Even with a 56k modem, one may not be getting half that transfer rate if the lines are noisy. The trick here used to be telling the phone company that the line was going to be used with a fax machine and then they'd take the time to clean the line during install.

- uncontrolled networking may still be an issue as phone companies run more information over IP networks. Those who have a VOIP phone from there highspeed internet provider will also be transferring data over public networks although it's going over a wire. This puts one back into the issues with encryption.

- listening in to calls happened easily long before everyone got all Web 1.0 (couldn't resist). It's probably still easier to join a call loop than it is to MITM the public IP network.

The expense is probably more than the cost of covering what moneys are currently lost through these types of fraud and theft.

what if I setup linux and do my online banking on that?

Of my knowledge, Linux is not been involved yet. Remember though, the bad guys want to keep their secrets from us.

I would try to use a read-only OS as on a LiveCD, if a dedicated computer is not an option.

Remember the two hunters and the bear.

looks for both OS and browser vulnerabilities. So, if you're running Firefox on Linux, your system could still be vulnerable until a Firefox vulnerability that is known to LuckySploit is recognized and corrected.

However, according to the article about LuckySploit, it obfuscates its routines which it uses to find and exploit vulnerabilities, which makes it (reportedly) impossible to identify the vulnerabilities for which it is searching.

Edit: I don't know which other browsers run on Linux; there is a list of the ones that LuckySploit seeks in the MCRC blog post about URLZone. It doesn't include Opera or Chrome, but perhaps I overlooked something in the article about LuckySploit itself.

My bank requires a second user to log in, review and approve all outgoing transfers.

You CAN login as the second user on the same pc - I think that somewhat defeats the purpose.

This is a pain and may not be practical in some cases but I think it would catch transactions that had been tapmered with.

Think that approach is effective against keyloggers and screen capture applications.

Also URLZone is capable of mimicking the Web page, change the account number and amount and have you verify it, because as far as you know everything is correct.

Quote: ".... You CAN login as the second user on the same pc - I think that somewhat defeats the purpose."

At least with URLZone, IMHO, that could defeat the purpose, because the second user would be logging-on from an exploited machine, and the malware is able to alter numbers which are on the banking web page that the browser displays. Perhaps they would catch the first attempt, because the web page displayed for the confirmation by the second user could be different and not included in the URLZone configuration file. The bot herder is probably apprised of that page because screenshots are sent, so they could change the configuration in the future if it isn't already configured to alter the confirmation page.

What are the possibilities of making a code generative browser, where browser code/functions are employed differently for each installation? Fight fire with fire.

Key loggers and screen capture applications make any of those types of approaches invalid.

How would keyloggers and such get on the machine in the first place? Most likely through the browser.
Browsers are the most widely exploited software on most PCs so if you start with a clean box and get a "perfect" browser the odds against getting infected from a non-specific attack are pretty unlikely.
If anyone ever finds that perfect browser please let me know

But, the dropper program could attack any one of the known vulnerabilities. I suspect the bad guys know of some vulnerabilities that we aren't aware of yet.

With all the money and resources spent on anti-everything, wouldn?t it be less expensive to stop the source? If you can buy these programs across the internet, then why can't those transactions be detected and stopped? Block the source and they will have to use other methods to deliver product. Make it hard enough and they will go and pursue the "slower hunter" of opportunity elsewhere. Do the buyers use a credit card or a bank transfer to pay for it? Surly those mule accounts can be detected and tracked to the sellers. Stop the problem at the source or at least use their own technology to get the money back and diverted into crime prevention. Similar to the DEA seize and sell program.

They are trying to, but this malware is ever-changing as are the money mules. The people in charge usually are in countries that do not extradite as well. It's a tough problem with a a highly variable scope.

Yes, but we have borders and cables which internet traffic flows on cross them. We can pinch those points if we want to and open that can of worms in the process. Do we need to impede certain traffic in order to protect the masses? Do you think our military is not preparing to do so in event of a "cyber war"? Surely some sort of compromise can be achieved. Big task.

I am not sure where I stand on that issue. I am concerned about who decided what is considered good traffic and what is bad traffic.

That's the whole issue or can of worms I mentioned. With the results of the last national election, its palin to see we can't make proper choices at that level either. It would take some real backbone to set that filter up and do what we all know is right.
Certainly, there are obvious filters that can be used today but a secure method of transactions will still be required. Perhaps a software fix is not the total solution but includes a hardware fix that encrypts your secure traffic through a vpn of some sort.

would have no effect on the operation of either ZeuS or URLZone. A Virtual Private Network prevents someone from sniffing the traffic and from becoming a "man in the middle".

It does not stop "man in the browser", a description of ZeuS (also applicable to URLZone) that has been introduced by Laura Mather of Silver Tail Systems. An "webinar" video disclosing their discoveries about ZeuS is available at:

http://www.veeple.com/link/48wBrdiCKJg%253D

If you have the time, it is well worth it.

I've read your other comments on this thread and agree that much more could be done to diminish the ability of criminals to use the Internet to commit their crimes "at a distance". For a start, we should campaign to deny Internet access to any country which refuses to sign an extradition treaty that allows people who are found to be committing crimes to be arrested and brought to the victim's country for trial.

That said, International Law, such as we have, is still in the womb. Soon it may be time for it to be born.

Very interesting Silver Tail webinar! Some thoughts & assumptions:

Assumptions:

1. Zeus literally has the information put in the form, so RoboForm crypto is negated

2. For the same reason SnoopFree Privacy Shield cannot block screen capture, because data is already captured through form and snapshots are not needed.

Mitigation:?

Trend Micro used to include a privacy control that would prevent unencrypted data that was protected by the ID vault from being sent out on Port 80, IM traffic, and email. However what is the state of the data being sent over JabberIM? Is it still SSL encrypted? If so Zeus could defeat even this protection feature.(IS 2006)

Of course, I haven't tested PC-cilline or Trend's Internet Security product since 2007, so I have no idea what they have now.

Of course we all know keeping things updated is the greatest mitigating factor here, but it would be nice to know we could improve multi-factor authentication to defeat this.

This may be spam I found in a previous article, but interesting, if true:

http://www.sentry-com.net/Transaction.html

According to the following RSA report, a cybergang that uses URLZone adopted measures to conceal the accounts managed by their "money mules":

http://www.darkreading.com/security/vulnerabilities/showArticle.jhtml?articleID=220301299&cid=nl_DR_DAILY_H

The best way to beat this problem, as with any malware, is to not get infected in the first place. Does anyone know all the attack vectors for these trojans?

Zeus is using LuckySploit and browser vulnerabilities. But that could change tomorrow. The trojans could be wrapped in any kind of dropper program.

Michael,

Prevention can be achieved by eliminating (preventing) the means of transmission at web sites, or making systems that will not allow malware to execute if they violate a business operational rule. This applies to the business operations of the home user as well.

To think those premises will never be possible. Nice thought though.

It is what we do.

Michael,
By attack vectors, I mean the sources of infection, i.e., IM, email links, web links?, flash drives?, CDs/DVDs?, etc., and is the malware self-executing, or does it require user intervention? From what I've read, it seems that it only runs automatically from a flash drive (and probably CD/DVD) if autoruns is not completely disabled. My point is that if one knows how to guard against getting infected, online banking is safe...for those who keep their guard up. I think that perhaps we need to keep the perspective that the odds of any single individual getting targeted are pretty small. Unfortunately I can't walk 6,000-10,000 miles to some of my banks, and the traditional methods of transferring money are cumbersome, slow and even pose the risk of at least temporarily being out of funds.

I understand, I absolutely need to bank on-line as well. That is the whole reason for this article. To get people at least aware of the possibility. I feel that user knowledge/awareness is half of the battle.

A recently published report from Trusteer (Measuring the in-the-wild effectiveness of Antivirus against Zeus) showed that 55% of 10,000 machines infected with the trojan Zeus had antivirus that was up-to-date.

Even if the anti-virus is up to date, a zero-day attack is when a vulnerability is exploited before a patch is issued. But as I understand them, trojans don't have to take advantage of a vulnerability, they just have to be allowed to execute on the host computer. But I am not sure why there is not more self-executing malware. Perhaps because users get warned by DEP, HIPs UAC or other protection? No anti-malware program, e.g., antispyware, anti-virus, etc., is bullet proof. Take a look at the Comparatives report at www.av-comparatives.org to see how bad some of the AV programs are at detection. So it is not clear what Trusteer means by up-to-date, i.e., did the anti-virus programs have the capability to detect the trojans and didn't, or did they have the latest signature files which did not include the trojan signatures?

..."did they have the latest signature files which did not include the trojan signatures?"

I was just responding to Howie's point:

"if one knows how to guard against getting infected, online banking is safe...for those who keep their guard up".

You are correct though, that your odds are better if you are diligent. That is beyond the average home user though.

You are never completely safe, the best you can really do is risk mitigation by removing yourself from the list of low hanging fruit by your due diligence, so that attackers go after easier targets. If someone really wants into your system, they can buy a zero day attack or a custom trojan just to target you with.

is called that because no one except the black hat(s) knew that the vulnerability existed before their malware exploited it.

Quote: ".... But as I understand them, trojans don't have to take advantage of a vulnerability, they just have to be allowed to execute on the host computer. But I am not sure why there is not more self-executing malware."

First, I'm not sure what you mean by "self-executing malware" because I've never heard of any "self-executing" computer program that runs via a Windows or UNIX OS. That is a pretty broad subject, since there are many types of computers and methodologies for using them besides the ones that have been the most commonly adopted.

With MS Windows, programs are always loaded by the operating system, which then tells the CPU to execute the instructions that comprise the program. There are several methods to tell the operating system to do that. For example, a program which is already being executed can tell the OS to launch other programs and/or an executable component(s) (e.g. a .DLL). For another, while the command shell's "batch processor" is running, it can tell the OS to run a program when a command to do that is included in a batch file that it is processing.

Of course, the person who is using the computer can also command the OS to load and run a program. Malware is properly called a "trojan" when the user commands the OS to run it because they believe that the program does something beneficial, and has not been deliberately designed to seize control of the computer system, and/or to harm the computer system, and/or to serve as a tool in the commission of a crime.

One context in which that happens is when the recipient of an e-mail message "opens" an attachment which is either (1) executable, so the act of opening the attachment commands the OS to run it; or (2) contains an executable that exploits a vulnerability in software that is launched by opening the attachment because that software reads the attachment as input.

So, you are right that a "trojan" does not have to exploit a vulnerability in a browser or in an OS in order to run. But there is no way for a program to tell Windows to load and execute it unless it is already loaded and running.

However, a running program can create a Registry key that instructs Windows to load and run either itself or another program either as a service, or after the system boot. There are also other ways that a program can be automatically loaded during the boot process and enabled to run afterward.

That said, neither ZeuS nor URLZone has a specific method of distribution. The ZeuS software creates a unique executable each time that it is run. That executable is the malware which the "bot herder" distributes. At last report, researchers have estimated that there are several hundred ZeuS variants in existence so far. It is likely that the same "signature" can only identify a few, or even just one, of the variants.

A person who purchases ZeuS or URLZone from their developers must decide how to distribute the malware so that it will be installed on other people's computers. It can be distributed as a trojan, but both ZeuS and URLZone often have been found to use an auxiliary program called LuckySploit, which finds and uses vulnerabilities in both OSes and browsers to install the malware without the user being aware that it is occurring. These variants typically install their malware payload from a malicious website during a "drive-by download".

...how inherently insecure operating systems are.

An inherently secure system would be able to self-check for its own integrity and security with every process request in reference monitor fashion, to prevent unauthorized privilege escalation. That is a given for a system to be inherently secure at the OS LEVEL.

In order to qualify as inherently secure, more would be required. It would also be necessary to have make it so nothing in user-space (people, applications, code using systems interfaces, processes or libraries etc.) would be able to bypass behaviour enforcement at the OS kernel. The system would be able to use any and every parameter within the operating system to specify a rule within its ruleset.

It could not, however, just be limited to the OS parameters. It would also require the ability to query sub-applications and external values in order that there was virtually no limit to the kinds of rules that can be created for use with, and enforced, by the system. With these capabilities it becomes possible to make rules that easily map to the business operations and those rules have to be enforced at the kernel level as well.

With such a system it would be easy to compartmentalize(sandbox) any application and set limits to the system and network calls that they were able to execute. You could allow an application to bind to a network process only the initial instance for example, so that injected code trying to take advantage of an app level bug would be denied. Any behavior that violated the business operational rules would simply be denied. All that would be necessary to ensure this would be to have the proper rule in place.

The utilization of mandatory access controls and whitelisting control of system and network calls, data access etc. would allow the evolution of systems and networks to least privilege default-deny systems that would simply not allow crimeware to execute no matter what iteration it appeared in.

Walk to the bank and deal directly with the teller.

if either you never "set up" online banking for an account(s), or the bank is willing to remove any online banking capability for that account(s).

Of course, you would have to do that not just for your bank account(s), but for each and every other "financial account" that can be used in any way to transfer funds to another entity's account (e.g., PayPal). From what I've read in the articles to which Michael referred, both ZeuS and URLZone are perfectly capable of being used to steal money from any account that has some, even, I suppose, to effect a fraudulent credit-card transaction (e.g., a "cash advance").

I don't think that many here realize analog solutions to this.

Security? A 45 auto.

Dobermann Pinscher is easier to aim, and has reflexes faster than mine.

(I did not suggest the "analog solution", I was just replying to it.)

Just stroking you.

I'd recommend to either set it up, or if the option is there, to get it disabled, unless you reverse that decision in person at a later time.
Even if you NEVER intend to use online banking, please DO go on and set it up with at minimum a strong password.
Then you can at least have a bit of peace of mind.
Let me explain...
An acquaintance of mine had someone walk in their house while they were in the back yard, and they grabbed the wife's purse that was just sitting on the dining room table.
What happened next is that they used her bank card, and immediately checked if online banking was used, since it wasn't, they conveniently set it up for themselves and basically cleaned out their account.
All because it hadn't been setup yet.
What a wonderful world we live in eh?

to the account without having the woman's user name and/or her account password? Just having the "bank card" alone should not have allowed access to the account. That would be a robbery waiting to happen.

Some "bank cards" have a pseudorandom number generator in them; press a button and they display a number in a small narrow screen, like a calculator. They are used for two-factor authentication: something that you know (a password), and something that you have (the number proves that you have the card). Just having that card, and knowing how to use it, is not enough to gain access to the account.

Another example of two-factor authentication is the typical "ATM card" or "Debit Card". It can only be used at an ATM or a point-of-sale terminal, and in both cases, the person who accesses the account must know and enter the PIN (usually a four-digit number). So there is something they know (the PIN) and something that they have (the card, which contains data that the ATM or point-of-sale terminal sends to the bank).

Of course, there are banks that have rudimentary security, and banks that have "very tight" security. There are many ways that a bank can endeavor to discern whether someone who wants access to an account probably does not have authorization to do that. Often the problem is that once someone gains access to an account, there are no further safeguards for the actions that they are authorized to take, such as transferring money to other banks.

With regard to my own bank's online banking, there is no advantage to my "setting it up" (or not) because it is already "set up". Worse, it appears to me that entering the data (account number, amount of payment or transfer, etc.), then using the Submit button is all that is required. As far as I have been able to determine, once someone has gained access to the account, they can steal everything in it.

Aside from that: yes, the account is currently protected by a strong password, as well as by a user name which is nothing like my actual name.

The bank's marketing department views this as "convenient" for the customer, although it is quite convenient for the bank, too. If they cannot disable online banking for my account, I will be compelled to find another bank, perhaps a credit union, that is just as concerned about security as I am.

The Silver Tail link explains it; the browser logon prompts for SMS authentication, and the unwitting user enters it into the window, solving the problem for the crime cracker!

It could be any coded authentication like this though. Unless a better authentication system comes in play.

I really think it is high time to use voice prints, or finger print scanning to introduce a third factor. However it would have to be trojan proof also; the capture of data by the criminal is the problem.

I assume forms don't need keyboard hooks or video hooks to do this once the data is in the form, it is too late, if the cracker pwns the browser session.

I didnt realise that both these trojans reported screen capture information, good research work Michael. The screen capture data would be the most direct attack on the PassWindow authentication system allowing the attackers to begin analysing the key pattern but it still wouldnt crack the user key in a useful amount of time / interceptions as it is with the Electronic tokens in the single interception outlined above. If implemented properly on the new outgoing account authentication the predictable path of the analysis still wouldnt yield enough information to the attacker in less than a year (maybe more depending on usage) of the attacker waiting and analysing the victims machine.

I talked to Mr. Stewart about PassWindow and I will fill you in.

when you already own the form session. The browser is fully pwned with the Zues method. They even get the user to put in second factor data like that mentioned.

Please correct be if I'm wrong Michael, but that Silver Tail webinar suggested it.

At least that is my understanding. Some versions use real-time screen capture and key logging. Sending the information via Jabber to a person that then uses that information in a duplicate Web site.

would block this, of course you could do it manually with your router, blocking the four ports Jabber uses in this instant.

But like you said - it depends of variant.

Avast, Trend IS 2006, Comodo, and NOD32 should be able to block the outgoing IM communication, if it is done this way.

I've never seen Norton block an IM message for years, but I don't read the history that much either.

Are not the default ones. They are variable.Remember each instance of Zeus is a different binary.