ActiveX module in Microsoft Works opens up security hole

April 18, 2008 – 8:21 AM

A demonstration of a security hole in the Microsoft Works Image Server (WkImgSrv.dll) ActiveX module contained in the Microsoft Works office suite has appeared on the Bugtraq mailing list. The demo appears to only cause a system crash. McAfee, however, has already found fully functional exploits which allow attackers to inject vulnerable systems with malicious code via specially crafted web pages.

The ActiveX module is not marked as “Safe for Scripting”, so Internet Explorer issues a warning before executing the module. However, if a user does allow a crafted web page to execute the module, malicious code may be injected and executed on the system.

No update has been released so far. As a workaround, the kill bit can be set for ClassID 00E1DB59-6EFD-4CE7-8C0A-2DA3BCAAD9C6. The vulnerable WkImgSrv.dll version 7.03.0616.0 and possibly other versions will then not be integrated into Internet Explorer. An article in Microsoft’s knowledge base provides assistance.

Source: Heise Security

Whale Phishing

April 18, 2008 – 8:14 AM

One of the things I love about cutting-edge technology is the way we get to invent fun, new terminology. It seems to have been around before, but I just came across my first reference to “whale phishing.” It describes a phish where the target is a very important person, such as a CEO, i.e. a very big target.

An example of the phenomenon was written up in this Internet Storm Center writeup which describes a phony subpoena request sent to several CEOs, purportedly from the US Courts. It was further written up by McAfee, including a screen shot, in their blog. The recipient is give a link to click on; if they do so, they are asked to install a “browser plug-in” in order to view the document; the file is named Acrobat.exe. If they do so, they are served with malware which McAfee classifies as TROJ_AGENT.AMAL.

Of course, the US Courts don’t e-mail subpoena requests directly to CEOs.

Source: PC Magazine

A Case Study on Storm Worm

April 18, 2008 – 5:33 AM

A bot is a computer program installed on a compromised machine which offers an attacker a remote control mechanism. Botnets, i.e., networks of such bots under a common control infrastructure, pose a severe threat to today’s Internet: Botnets are commonly used for Distributed Denial-of-Service (DDoS) attacks, sending of spam, or other nefarious purposes [5, 24, 15].

The common control infrastructure of botnets in the past was based on Internet Relay Chat (IRC): The attacker sets up an IRC server and opens a specific channel in which he posts his commands. Bots connect to this channel and act upon the commands they observe. Today, the standard technique to mitigate IRCbased botnets is called botnet tracking [11, 15, 14] and includes three steps. The first step consists of acquiring and analyzing a copy of a bot. This can be achieved for example using honeypots [1] and special analysis software [4, 32]. In the second step, the botnet is infiltrated by connecting to the IRC channel with a specially crafted IRC client. Using the collected information, it is possible to analyze the means and techniques used within the botnet. More specifically, it is possible to identify the central IRC server which, in the third and final step, can be taken offline by law enforcement or other means [9]. An attacker can also use an HTTP server for distributing commands: in this setup, the bots periodically poll this server for new commands and act upon them. The botnet tracking methodology outlined above can also be applied in this scenario. Today we are encountering a new generation of botnets that use P2P style communication. These botnets do not have a central server that distributes commands and are therefore not directly affected by botnet tracking. Probably the most prominent P2P bot currently spreading in the wild is known as Peacomm, Nuwar, or Zhelatin. Because of its devastating success, this worm received major press coverage [13, 17, 22] in which — due to the circumstances of its spreading — it was given the name Storm Worm (or Storm for short) [30]. This malware is currently the most wide-spread P2P bot observed in the wild.

In this paper we study the question, whether the technique of botnet tracking can be extended to analyze and mitigate P2P based botnets. Roughly speaking, we adapt the three steps of botnet tracking in the following way using Storm Worm as a case study: In the first step, we must get hold of a copy of the bot binary. In the case of this botnet, we use spam traps to collect Storm Worm generated spam and client side honeypots to simulate the infection process. The second step, the infiltration of the botnet, is adopted since we need to use a P2P protocol instead of IRC, HTTP, or other client/server protocols. The third step, the actual mitigation, is the most difficult: In the case of Storm Worm we exploit weaknesses in the protocol used by the bot to inject our own content into the botnet, in an effort to disrupt the communication between the bots. We argue later that this method is effective against P2P botnets using content-based publish/subscribe-style communication.

Our measurements show that our strategy can be used as a way to disable the communication within the Storm botnet to a large extent. As a side effect, we are able to estimate the size of the Storm botnet, in general a hard task [25]. Our measurements are much more precise than previous measurements [12, 17]. This is because measurements previously were based on passive techniques, e.g., by observing visible network events like the number of spam mails supposedly sent via the bots. We are the first to introduce an active measurement technique to actually enumerate the number of infected machines: We crawl the P2P network, keep track of all peers, and distinguish an infected peer from a regular one based on characteristic behavior of the bots.

Read the full case study here…

Vulnerability in Windows Could Allow Elevation of Privilege

April 18, 2008 – 4:47 AM

Microsoft is investigating new public reports of a vulnerability which could allow elevation of privilege from authenticated user to LocalSystem, affecting Windows XP Professional Service Pack 2 and all supported versions and editions of Windows Server 2003, Windows Vista, and Windows Server 2008. Customers who allow user-provided code to run in an authenticated context, such as within Internet Information Services (IIS) and SQL Server, should review this advisory. Hosting providers may be at increased risk from this elevation of privilege vulnerability.

Currently, Microsoft is not aware of any attacks attempting to exploit the potential vulnerability. Upon completion of this investigation, Microsoft will take the appropriate action to protect our customers, which may include providing a solution through a service pack, our monthly security update release process, or an out-of-cycle security update, depending on customer needs.

Read the full story…

PayPal Plans to Ban Unsafe Browsers

April 17, 2008 – 5:43 PM

PayPal says allowing customers to make financial transactions on unsafe browsers “is equal to a car manufacturer allowing drivers to buy one of their vehicles without seat belts.”

PayPal, one of the brands most spoofed in phishing attacks, is working on a plan to block its users from making transactions from Web browsers that don’t provide anti-phishing protection.

The eBay-owned company, which runs a Web-based payment system that allows the transfer of funds between bank accounts and credit cards, said browsers that do not have support for blocking identity theft-related Web sites or for EV SSL (Extended Validation Secure Sockets Layer) certificates are considered “unsafe” for financial transactions.

“In our view, letting users view the PayPal site on one of these browsers is equal to a car manufacturer allowing drivers to buy one of their vehicles without seat belts,” said PayPal Chief Information Security Officer Michael Barrett.

In a white paper that outlines a five-pronged action plan aimed at slowing the phishing epidemic, Barrett said there’s a “significant set of [PayPal customers] who use very old and vulnerable browsers” and made it clear that any browser that falls into the “unsafe” category will be banned.

“At PayPal, we are in the process of reimplementing controls which will first warn our customers when logging in to PayPal of those browsers that we consider unsafe. Later, we plan on blocking customers from accessing the site from the most unsafe—usually the oldest—browsers,” he declared.

Read the rest of the story…