Friday, May 25, 2007

Skype worm leaps onto MSN

Skype worm leaps onto MSN
IM in peril
By John Leyden
Published Thursday 24th May 2007 17:51 GMT

Malware miscreants have created the first worm targeting Skype that's also capable over other instant messaging networks, such as MSN and ICQ.

The unnamed worm poses as a chat message linking to a website, as with other example of Skype-spreading malware before it. This malicious website contains a .pif file, that poses as "photos". Users tricked by this simple ruse will find themselves infected by the Stration worm, a mass mailer that also attempts to foil attempts to remove it by blocking access to security-related websites, and other items of malware.


Skype contacts of users infected by the worm get sent a message pointing to the hacker-controlled website. This is all fairly standard.

The twist comes via an attempt by VXers to hedge their bets. One of the files dropped onto infected PCs checks to see if a number of different instant messaging programs are installed.

Although the main vector for infection is Skype, the malware also attempts to spread by punting messages across MSN and ICQ, according to an analysis of the malware by researchers at IM security firm FaceTime Communications.

"The infection checks the registry for evidence of programs like AIM, Trillian, Yahoo Messenger, Miranda and ICQ - however, so far we've only seen it fire a message to an ICQ and an MSN Messenger Client," writes Chris Boyd, director of malware research at FaceTime. "The main target appears to be Skype with regards a delivery mechanism for the messages sent, but the potential for the infection to leap across various networks is obviously there."

FaceTime speculates that the cross-network IM worm is probably the work of the same VXers who created early Skype worm. The latest IM malware menace once again emphasises the importance for users to think before they click. ®

Labels:

Wednesday, May 23, 2007

First OpenOffice virus emerges - SB/Badbunny-A

First OpenOffice virus emerges
22nd May 2007 Dan Warne Linux, Mac, Windows

Oh what a sweet, sweet day it must be for Microsoft. The first worm specifically targeting the open-source office package OpenOffice has emerged.

It runs on Windows, Mac and Linux computers, but anti-malware vendor Sophos admits it poses a low threat, especially as it's only a proof-of-concept that hasn't actually been discovered 'in the wild'.

The OpenOffice worm uses the inbuilt StarBasic scripting language in the office suite to save scripts to disk in several other languages.

The worm attempts to download and display an indecent JPEG image of a man wearing a bunny suit performing a sexual act in woodland.

The SB/Badbunny-A worm first infects you when you open an OpenOffice Draw file called badbunny.odg. A macro included in the file performs different functions depending on whether you are running Windows, MacOS or Linux:
Windows: The worm drops a file called drop.bad which is then moved to system.ini in your mIRC folder (if you have one) and also drops and executes badbunny.js which is a JavaScript virus that replicates to other files in the folder.
MacOS: The worm drops one of two Ruby script viruses (in files called badbunny.rb or badbunnya.rb).
Linux: The worm drops badbunny.py as an XChat script and also drops badbunny.pl which is a tiny Perl virus infecting other Perl files.

The dropped XChat and mIRC scripts are used to replicate and distribute the virus, and they initiate DCC transfers to others of the original badbunny.odg OpenOffice file.

Sophos says the worm has not been found 'in the wild' but, in an odd move, was sent to their security labs for analysis directly by the makers. The worm, which has not been reported at any customer sites, also downloads and displays a pornographic picture of a scantily clad woman with a man dressed as a rabbit.

"The group responsible for writing the BadBunny malware don't seem to have much confidence in it spreading as they have sent it directly to our labs. The hackers have written plenty of StarBasic malware in the past, but the most 'in the wild' this one is likely to get is by displaying a picture of a furvert in the woods," said Graham Cluley, senior technology consultant for Sophos.

"This is old-school malware - seemingly written to show off a proof of concept rather than a serious attempt to spy on and steal from computer users. A financially motivated hacker would have targeted more widely used software and not incorporated such a bizarre image. This is not a piece of malware which we expect to see spreading in the wild, despite its use of a photograph of unusual wildlife."

Labels:

Thursday, May 17, 2007

Cisco IOS alleged backdoor

Cisco IOS Server Backdoor May Have Been Planted
By Lisa Vaas , eweek.com
May 15, 2007


A security vendor is questioning whether the IOS FTP Server vulnerabilities Cisco reported on May 9 may constitute an intentionally planted backdoor, as opposed to a series of programming errors that inadvertently led to a backdoor.

Chris Eng, director of security services at Veracode, is suggesting that possibility given that a remote attacker would need one of the flaws—improper authorization checking in IOS FTP—in order to exploit the second flaw—an IOS reload when transferring files via FTP.
ADVERTISEMENT

In essence, an attacker can bypass authentication and avoid giving credentials because of the first flaw. The attacker then has to overwrite the critical startup configuration file, then has to cause the router itself to reboot in order to execute the rewritten configuration file.

"Is it a coincidence that both flaws happen to be there at same time?" Eng asked in an interview with eWEEK. "Multiple things have to fall into place to really exercise the full extent of the attack. That seems a little bit odd. It kind of has the trademarks of what you'd expect from [an intentionally planted] backdoor."

Together, the flaws open the door for an attacker to retrieve or write any file from the device file system—including the device's saved configuration. "That configuration file may include passwords or other sensitive information," Cisco said in its advisory.

The origin of the flaws boils down to a question of intent, Eng said. Cisco essentially said in its advisory that the flaws can be used as a backdoor. That could mean that an attacker could exploit the vulnerabilities to gain access to a router.

The backdoor allows a remote attacker to log onto the FTP service on the router without credentials, get onto the router itself and read or write any file on the router's file system. The startup configuration is what the router reads when it reboots, to seed its initial configuration. If an attacker can control that by overwriting, he or she essentially has control of the entire router.

The attacker could take the router offline, for example, or, more ominously, could route traffic to another destination where the traffic can be intercepted.

In that definition, we're not looking at how the flaw got there in the first place, Eng said. "We're just taking it as a fact that yes, it's there and yes, people could do bad things with it."

The flaws could well be simple programming mistakes. "In most cases, when a vulnerability in a piece of software is discovered and made public, it's because of an implementation error on the part of the [developer not having] adhered to secure programming guidelines," Eng said. "It's just a mistake. Programmers do it all the time."

On the other hand, if the flaws are a backdoor, was it planted into the code base intentionally, by someone who gained access to the code base? Such could be the case with a disgruntled developer who had access to the code base, Eng said, or somebody who didn't already have access to the code base launched an attack on Cisco, gained access to the code base and surreptiously made changes. Then, once the code ships, such access to routers gets pushed out to all Cisco customers, he said.

If the flaws weren't intentionally planted, then they at least highlight the need for more frequent and better security reviews, Eng said, given the number of versions of IOS that harbor the flaws "This is an FTP interface and an authentication mechanism," he said. "Maybe they need better focusing of security reviews to look at these critical components, and look at these things that are liable to be exploited. With five versions of 12 [affected, etc.], they might need to do this more frequently to catch these things."

Use of the IOS FTP Server is an optional service that is disabled by default. Users can disable use of the server by executing this command in configuration mode:

no ftp-server enable

Cisco has supplied other mitigations here in Cisco's Applied Intelligence document, a companion to the advisory.

Cisco hadn't responded to a request to comment on the issue by the time this story was posted.

Labels:

Norton Personal Firewall ISAlertDataCOM ActiveX Control Buffer Overflow

Secunia Advisory: SA25290
Release Date: 2007-05-17


Critical: Highly critical
Impact: System access
Where: From remote
Solution Status: Vendor Patch


Software: Symantec Norton Internet Security 2004
Symantec Norton Internet Security 2004 Professional
Symantec Norton Personal Firewall 2004


CVE reference: CVE-2007-1689

Description:
Will Dorman has reported a vulnerability in Norton Personal Firewall, which can be exploited by malicious people to compromise a user's system.

The vulnerability is caused due to a boundary error in the ISAlertDataCOM ActiveX control (ISLAlert.dll) when handling the "Set()" and "Get()" methods. This can be exploited to cause a stack-based buffer overflow via an overly long argument.

Successful exploitation allows execution of arbitrary code.

Solution:
Product updates to correct the problem are available through LiveUpdate.

Provided and/or discovered by:
Will Dormann, CERT/CC.

Original Advisory:
Symantec: http://securityresponse.symantec.com/avcenter/security/Content/2007.05.16.html

US-CERT VU#983953: http://www.kb.cert.org/vuls/id/983953

Labels:

Monday, May 14, 2007

Bad Encryption

This is an article on how to break the security on fingerprint enabled 'secure' USB memory sticks. The sticks basic design is insecure.

To cut to the chase:
both sticks use something that's said to be very secure: fingerprint scanning. Then, why did they fail?

The answer is simple: the key to the encryption has to be stored on the stick in some way.

This is how it works: If you have a program doing encryption with a password as a key, the program doesn't have to know the password itself when not used. You run the program, enter the password, and the password is used to decrypt the info. Close the program and it will forget the password: it's stored nowhere on your computer. It's not needed: you yourself can enter the exact password when you want to have access to your data anymore. But you must enter exactly the password you've chosen: you can't make any mistake like using a capital-A instead of a lowercase one.

Fingerprints aren't that precise. If you scan your fingerprint two times, the scans will always be subtly different. Pressure differences, the way you slide your finger over the sensor, interference, loss of skin cells... they all contribute to a certain amount of noise to the picture. You can't encrypt something with that: you need something that never changes. As far as I know, it's not possible to distill from a fingerprint a certain piece of data that never changes, but still has variation enough to make it impervious to brute-force-attacks.

So, all systems have to take another route: encrypt the disk with a certain random key and hide that key somewhere together with the fingerprint of the user of the stick. As soon as the stick is inserted, the user is asked for his fingerprint and it is then compared to the stored copy. If they match, the disk is decrypted using the stored key.

The problem with that is simple: if the program handing out the key to the decryption routine can be hacked, the hacker can, one way or another, get the key. There's no way around that: the program can access the key and the hacker can access the program: that means the hacker can access the key.

There are two ways around this: The first one is not to allow the program access to the key. Truecrypt and other password-based programs do this, but as I explained, it's difficult for a fingerprint-based solution to do this. The other way is: don't allow the hacker access to the program. This would mean embedding a controller in the stick which should do all the fingerprint-comparing itself. While a really skilled hacker could still try and get into the microcontroller, it would be much, much more difficult to get to the data than with a software-based solution. Unfortunately, this solution is way more expensive than a PC-software-based solution.

Labels: , ,

Wednesday, May 9, 2007

Hackers control a British military communications satellite

A GROUP of computer hackers suspected of seizing control of a British military communications satellite using a home computer, triggering a "frenetic" security alert, has been traced to the south of England.

A security source said that, up to a month ago, the hackers found a "cute way" into the control system for one of the Ministry of Defence's Skynet satellites and "changed the characteristics of channels used to convey military communications, satellite television and telephone calls".

Contrary to reports in a Sunday newspaper, the group did not move the satellite, nor did it attempt to blackmail the MoD, and the Serious Fraud Office is not involved in investigations.

Instead, the hackers triggered a "frenetic rather than panic-stricken" response by MoD officials as the intrusion was characteristic of an information-warfare attack, when enemies attempt to destroy or disrupt military communications networks.

The hackers are being investigated by Scotland Yard's Computer Crimes Unit and the Communications Electronics Security Group at GCHQ, with assistance from the US Air Force.

American hackers passed on information that implicates hackers in southern England. Scotland Yard is assembling evidence and arrests are expected soon.

The hackers intercepted the link between the Skynet's control centre and the ground station. The source said the hackers "managed to reprogram a satellite control system. In many ways, the clever thing was not to lose the satellite."

Last week, Margaret Beckett, Leader of the Commons, warned of the growing risk of malicious electronic attacks on Britain's critical information infrastructure. "Hijacking a satellite is one of the first activities in an infowar attack," the source said. Defence staff examined several other classified points that would be expected to be attacked in the event of an information warfare assault. "Initially, the attack was thought to be an overt act of war. Now we think it was a mischievous act."

A spokesman for Scotland Yard said a computer hacker was being investigated. "The hacker is believed to be targeting several different international sites, some of which may include military installations," he said.

Britain has three satellites that form what is known as Skynet 4, the most modern generation of British military satellites. The first generation was launched in the 1960s and Skynet 4 went up in the late Eighties. The satellite that was infiltrated is believed to cover Scandinavia, the North Sea and northern England. Like all the MoD's satellites, and the two others Britain operates for Nato, it is controlled by the Royal Air Force.

The British hacking community was "astounded and envious" at the audacity of the attack, said one British hacker. "We guess that it is an unusual crew, probably a group of students with access to the control system," he said.

The hacker group is believed to have used a "recipe" describing how to attack satellite control command systems, published several years ago by a Briton who subsequently fled to Japan to avoid arrest for another hacking incident.

Several years ago, an American hacker called Capt Midnight grabbed control of an American television satellite. He replaced some of the channels with a test card that protested at the introduction of pay-television.

Geoff Bains, editor of What Satellite?, said: "It has always amazed me that more people have not done this. You just have to learn a few control codes and send up your own signal to play around with a satellite yourself."

Labels: ,

Friday, May 4, 2007

RFID Firewall

Feeling insecure about who might be trying to access your RFIDs? Here is a portable firewall from Melanie Rieback to provide a modicum of protection. The project web site is rfidguardian and the below article is from Ars Technica.

=====================================================================

The RFID Guardian: a firewall for your tags

By Nate Anderson | Published: May 01, 2007 - 11:53PM CT
Here, there, and everywhere
Don't carry RFID? You might be surprised; the short-range ID technology is currently found in everything from US passports to swipeless credit cards to public transit passes to World Cup tickets to car keys to the building access pass for your office building. A few of the digerati even elect to have RFID implants from VeriChip slipped beneath their skin in order to use them as cashless payment systems.

Much of the information on these chips can be read without exotic equipment, assuming an attacker can get within several feet with a concealed RFID reader. Unfortunately, most tags give users no control over when they respond to queries, and they offer no notification, which means that sensitive data could be at risk in public places.



The solution, for those concerned about such things, has so far been low-tech: smashing the chip with a hammer appears to be the preferred method for passports, but it is technically illegal and could lead to unpleasantness at customs.

A new tool from a graduate student at the Vrije Universiteit in Amsterdam offers the first real-time cloak of protection to users concerned about security, and no hammer blows are required. The RFID Guardian is essentially a firewall that can prevent or allow RFID queries, and can do so on a per-tag basis. Melanie Rieback, the Guardian's designer, describes it as a portable, battery-powered device for personal RFID privacy—but even if you aren't concerned about men in dark sunglasses snatching your passport data, the selective jamming tech in this diminutive device is fascinating stuff.

I had a chance to sit down with Rieback during her recent trip to the United States, and she explained how the device works, what's coming in version 3.0, and why she has no plans to profit from the technology.

"I'm definitely not anti-RFID," she explains. "I think there's a lot of great things you can do with it, but I just think that like any other technology, they need to take security and privacy into consideration."

Here's how the RFID Guardian gives that power to the people.
And I need this... why?

RFID got its start as an antitheft tool that soon became important for inventory management. Using RFID chips, it was suddenly simple for shippers to know how many pallets were in a trailer, and retailers could see how many razors were on a store shelf without keeping employees all night to do inventory. RFID received a massive boost when Wal-Mart required RFID tags to be used by all of its suppliers.

Because such commercial deployments emphasize cost over security, most tags still have no access controls, so grabbing a tag's information is relatively simple. Some specialized tags do employ basic cryptography, but this is not always robust. When researchers looked into the encryption found in the ExxonMobil SpeedPass, for instance, the algorithm turned out to use a 40-bit key and was cracked easily by a brute force attack. Tags with stronger cryptography tend to be prohibitively expensive, and thus are not often used.

As the tags showed up in increasingly sensitive applications, security became more of a concern—at least to researchers and privacy advocates. Rieback was one of those people. As a graduate student searching for a Ph.D. dissertation topic, she spent eight months reading computer science research papers and discovered that the number of published works on RFID security could be counted on both hands. "It became painfully obvious that there was a deficiency in the area of RFID, and there is so much work to be done," she says.

So Rieback turned herself into one of the foremost academic authorities on RFID security and went on to develop the first RFID virus as a proof of concept. That got the industry's attention. As Rieback tactfully puts it, there was a "mixed reaction" that even included some personal attacks. But other companies approached her team for consulting assistance within days of publishing the paper.

After doing her part to publicize these security shortcomings of many RFID implementations, Rieback moved on to the RFID Guardian project, which would give people a measure of control over their tags. It became her Ph.D. project, and when she finalizes the next version in the next eight months or so, she should earn her doctorate. Even when that happens, though, she has no plans to drop the project. "I think this is important enough that we should finish it," she says. "We should get it out there."

Eventual plans call for the Guardian to be incorporated into cell phones and PDAs, but the current model is a pocket-sized device that runs on its own battery and provides a circular 1m field of control over RFID tags, jamming any tags that the user does not want read. It sounds simple, but the technology behind it is surprisingly complex—complex enough that the current model uses what Rieback refers to as a "beast" of a CPU, an Intel XScale PXA270. Here's what all that power is for.

Guts and bolts

The Guardian has four basic components: an RFID reader, a radio transceiver, an XScale processor with flash memory, and a power source. Rieback has implemented two common RFID protocols in software (ISO 15693 and 14443), both of which operate at 13.56MHz. Passive tags using these protocols can be read from up to one meter away; higher-frequency tags and those with an active power source extend much further.

The Guardian polls all the tags in its vicinity, along with all queries that might come from other RFID readers. Whenever the Guardian detects a query, it looks up the requested tag's ID number in its internal Access Control List (ACL). The Guardian currently has no external interface for adjusting the ACL in the field, but it does have an RS-232 port for a connection to a PC, which can then be used to update the ACL.

Entries in the ACL can tell the Guardian to prohibit access to a specific tag, or to allow it, or to allow it only to specific readers. The Guardian needs to do this lookup quickly, since it must make a decision about whether or not to jam the tag's response within 320.9µs—the amount of time between the RFID reader's request and the beginning of the tag's transmission back to the reader.

Actually, the Guardian has even less time than this, since 23µs are needed to wake up the software thread that monitors the receiver and another 5µs are needed to to fire up the transmitter before sending a jamming signal. That leaves only 292.9µs for the Guardian to decide about jamming.

This is where the "beast" of a processor comes in handy. In tests, the 520MHz XScale processor looked up a tag's ID number in the ACL in far less time than this, even when the ACL contained hundreds of entries and the sort algorithm was unoptimized.

If the tag in question in supposed to be blocked, the Guardian then jams the tag's response. RFID tags use an anti-collision protocol (called "Slotted Aloha" in this case) so that their responses do not overlap with those from other tags in the area. The system recognized by the Guardian uses 16 timing slots to transmit responses; the tag chooses a slot after running a XOR function on the reader's anticollision mask and the tag's own ID number. The Guardian does the same calculation in order to know which time slot needs to be jammed.

When the time slot comes up, the Guardian generates a relatively massive burst of noise in the two sideband channels used by each tag for data transfer. This is easy to do, since most tags are inductively-powered and are therefore weak; the battery-powered Guardian simply swamps their response with noise. The anticollision system goes on to vary the time slot over the next few query rounds, hoping to find a clear channel to the tag—but the Guardian blocks them each time until the reader simply gives up.

Blocking only the time slots belonging to a specific tag can reveal the presence of that tag to a canny attacker, though, so the Guardian also creates a few collisions when the requested tag isn't actually firing. As Rieback puts it, this "throws in some chaff with the wheat."

Because all of this activity must take place in real-time, the Guardian uses the open-source e-Cos Real-Time Operating System to handle low-level tasks for the Guardian. The software that runs on top of the OS consists of device drivers for the RFID hardware, protocol stacks for various RFID flavors, and data storage libraries. The complete code is 12,694 lines long; for those who want to see it in operation, the project web site contains high- and low-resolution videos that illustrate how the jamming system works .

Of "kill queries" and DOS attacks

The Guardian provides real-time protection of RFID tags, limiting access only to trusted readers; it can also keep all tags blocked until the user switches it off. But there are a few things it can't do.

One of the most important limitations of the Guardian stems from the way it works. The device can't block queries, only responses. This normally is no big deal, but some RFID tags can respond to special "kill queries" that can permanently disable a tag. The Guardian cannot jam these queries.

The most likely active attack against a device like the Guardian would be a denial-of-service attack that attempts to overload some part of the device—likely its limited radio bandwidth or flash memory capacity. Simple tweaks to the code prevent the Guardian from locking up in most of these situations, though, and attacks against the radio bandwidth would also confuse the tags, which depend on precisely-timed signals.

So despite its limitations, the device looks like a powerful new privacy tool. But will the technology be used by black-hat hackers, especially since the libraries and protocol stacks will be open-sourced? "Of course," says Rieback, but notes that if she doesn't build such a device, others will. The hardware in question isn't even particularly complicated; she just happens to have put it together first.

"There aren't that many privacy-enhancing technologies out there for RFID right now," she says. The Guardian provides one of the first, but it also sends an important message to industry: these tags are not as secure as you think. Tag jamming and spoofing, both of which the Guardian does, are possible with off-the-shelf components. Security needs to be taken more seriously.

Guardians of the future

Version 3.0 of the device is already being drawn up in Rieback's Amsterdam lab. High on the list of priorities for the new design is a more modular design where the analog electronics would be contained on plug-in baby boards that could be easily removed and altered. That's because the v2.0 Guardian had everything soldered to a single board; when Rieback had a problem with impedance matching, "it was a pain in the butt to try and fix it."

The new version also features an upgraded interface that allows that Guardian to be controlled using Bluetooth and a custom Java applet designed to run on cell phones and PDAs.

Once the design is complete, the board will be professionally produced and then offered—at cost—to the public.

Getting the tech incorporated into cell phones and PDAs would be the next step, though Rieback notes that this would require the design and production of a custom chip, and that she has neither the time or facilities to do that at the moment. "We're taking it one step at a time," she says.

But for a grad student, she's already taken quite a few important steps and produced the only functioning RFID tag protection system. The project has now swollen to include 15 people, three of them full-time employees. Future versions of the Guardian will include more protocols and different frequency ranges, but the basic tech is already in place and working—putting it ahead of most similar projects.

So put away the hammers; if you're worried about the privacy implications of insecure RFID implementations, you'll soon be able to take back a measure of control.

Labels: , ,