- Related Stories
-
Another Bagle variant tries to spread
September 1, 2004 -
Four new Bagle worms added to Internet soup
March 18, 2004 -
Bagle latches on to antispam ploy
March 15, 2004
Bagle.BB, also known as W32/Bagle.bb@MM, was raised to a medium risk assessment by security company McAfee. The virus had triggered more than 100 reports to McAfee's antivirus and vulnerability emergency response team by early morning in Europe. Antivirus software makers have also identified two other variants of the Bagle virus that are successfully spreading.
Other security experts noted that there are specific challenges with the latest variant of Bagle.
Prevention and cure: Bagle.bb
Ribaudo added that the Bagle virus, which is also known as Bagel AX and W32.Beagle.AV, tries to disable antivirus software loaded on people's computers.
Increasingly, computer viruses are serving as a tool to surreptitiously use another person's computer to send out spam or collect personal financial information.
Security experts note that the profit that can be made from these activities is driving the rapid rise in virus and hacker attacks.
The most recent version of the Bagle virus is another in a long list of variants of the virus, which began infecting computers in January.
BitDefender Labs noted that the new Bagel variant creates copies of itself in varying lengths, in a move to make it harder to filter out of e-mails using antivirus software.
As a result, the recipient of Bagle.BB receives a bogus e-mail with a spoofed sender address, which, for example, may appear to come from a legitimate friend, business associate or family member.
The subject header from the spoofed sender will contain such greetings as "Hello," "Thank you!" and "Thanks :)."
As with a number of viruses, it spreads when the recipient opens the e-mail attachment. The executable name of the attachment is listed as "price," "Price" or "Joke," according to McAfee.
Once the virus in the attachment has been released, it will copy itself onto the Windows system directory. It will also open TCP port 81, as a means for remote access to a user's computer.






In the days before the public internet was a household convenience, there was a loose federation of computers running software called UUCP and various other networking software (FidoNet, among others) to exchange messages and files on a nightly basis (or more often in some cases).
The hackers would attack various systems on this network, infect the shareware software with viruses, etc. and try to infect each other. They would war and brag, etc.
Trojans have been the mainstay -- either true Trojans or infected and repackaged executables (for example, they infect Doom, then attach it to an e-mail or post it on a public files site) because social engineering is (relatively) easy.
The real problem here is with modern OSes and the single most prevelant security mechanism. User-Role-Permission, or User-Group-Permission, is inherently flawed for an OS level implementation.
An Application cannot be considered trusted by its location on the hard drive. An Application cannot be considered trusted by the user who is launching it.
For an application to have access to files outside of its own folder, you must explicitly grant it that access. For an application to have access to API calls, to be able to talk to other applications, etc. you should need to explicitly grant that permission.
Applications need to be digitally signed, and need to belong to "suites" and "catagories." Suites have common file locations and are identified by a common digital signature certificate as well as claiming in their metadata that they are a member of a suite. Categories are assigned by users, and allow more broader sharing of files.
For example, the "Word Document" category (file type, should not be based on extension but on Windows likely has to be; shouldn't be based on magic, either, but on *nix likely has to be) would say that the file may read and/or write Word Documents.
The "Intranet Access" category would say the program may access files or information on network shares, but not over internet, etc.
If you look a Trojan, when it entered your system, it wouldn't have a signature, and it wouldn't be able to modify itself easily (because it would have to re-sign itself afterwards). It wouldn't be in a suite (no common publisher), so it wouldn't be able to access files or resources that belong to a suite (including the OS).
It wouldn't be in a category, so it wouldn't be able to access anything that required it to be a member of a particular category to access.
And so -- are you ready for this?
The Trojan would be toothless. It would be like an old geezer who left their teeth on their nightstand. It could try to gum the system to death, but it wouldn't work.
Look, I've worked in banks heavily, I've worked in food processing plants, I've worked at telephone companies, and I've developed software since I was 7.
The Trojans have always been there, the problem is you have a lot more people today downloading a lot more software and accessing them a lot more often. The hackers have always warred with each other, and put end-users in the middle. It's just been how they operated.
What's desprately needed is a fundamental shift at the OS level. The hackers are at fault for trying to break in, but if you have a house where there's no glass in the windows, no doors in the frames, etc. would you expect the contents to be safe?
When you add protection to the house, it not only discourages people from trying to break in, but it also makes it harder -- it makes it take longer.
Right now, all the focus has been on fixing individual applications. We fix Outlook, we fix Internet Explorer, we fix Mozilla, we fix Apache, we fix IIS -- and each time we fix a hole, the hackers come in again.
Fundamentally, if you want to keep the hackers out, you have to follow a different approach.
You keep the hackers out by making it so that even if an individual application is broken, the operating environment is resilient enough to prevent the broken application from becoming an entry point to cause more damage.
Just as an example, Phishing...
How much harder would it be to phish if web pages were all XHTML 1.0 with digital signatures across their valid page?
You cannot use SSL for everything, because it slows the server. However, an XML digital signature can be precomputed against arbitrary markup, then validated in the browser.
Such a digital signature in e-mail, on web pages, etc. -- on all correspondance -- would all but end phishing.
For example, when you install Earthlink, it could install an "Earthlink e-Mail signature." Earthlink could sign all their mail with this certificate, and then most existing e-mail programs (close to all with 3rd party tools) could tell you if the message was really from Earthlink or not.
Having SMTP servers use SSL and mutual authentication, even from untrusted certificates, would eliminate the ability to forge paths and provide trackability to SPAM without requiring a single new standard.