Microsoft Malware Protection Center

Hi, Ziv Mador again. This week I’m attending the FIRST conference in Kyoto, Japan along with four of my Microsoft colleagues: Steve Adegbite, Andrew Cushman, Jonathan Ness and Dan Wolff.

Today Jonathan, Steve and I gave a presentation about Microsoft's response to the attacks which exploited a 0-day vulnerability back in the fall of 2008. Microsoft released a security update MS08-067 that fixed that vulnerability. Given the wormable nature of that vulnerability, we had strongly encouraged customers to install the security update, for example in the following blog post.  In the days, weeks and months following the bulletin release, malware exploiting MS08-067 has been launched, including the widely known Conficker worm. In our presentation we described the evolution of those exploits and the steps that Microsoft has taken to mitigate the threats.

FIRST is a worldwide organization of response teams and the annual FIRST conference is an international event. Nearly 400 researchers from 52 countries are attending the event this year. It is a great example of collaboration and information sharing in the security industry. Microsoft is a member and returning sponsor of FIRST. We participate in FIRST in order to share our experience and best practices and to encourage collaboration and community based defense to meet current and future challenges. Microsoft also participates in other forums. For example, it participates in the Conficker Working Group which helps mitigate the Conficker worm.

Kyoto includes many different historical sites as it used to be the Imperial capital of Japan for about a thousand years. One of these sites is the Nijō Castle. The architects of this castle designed and created several defense systems. There are two rings of fortifications; each one of them uses a wall and a wide moat. That obviously made an attack on the castle more difficult. But another interesting security feature was used there:  the floors in the corridors were built in a way that they chirp like birds when people step on them. That’s why they are called uguisubari or nightingale floors. This feature helped the defenders of the castle immediately know when someone entered the castle, possibly with a malicious intent. It is probably one of the earliest security warning systems ever developed. This castle or the Red Fort in Agra which David described in an earlier blog post, represent some of the basic ideas in defense systems also for modern computers networks: in order to secure them there is a need for an effective warning system, multiple security defense layers, and plans for response and recovery. Conficker can be used as a good example here. The later variants of this worm, spread using multiple vectors: they exploit MS08-067 to infect other computers on the network but also spread through shares with weak passwords and through removable media and auto-run. That means that even if an organization fully deploys all the security updates as soon as they are released, they still haven’t mitigated the risk of infections. To minimize that risk, the organization must also ensure that shares use strong passwords, disable auto-run (or educate users to select only the legit options), use an up to date AV, enterprise firewall, IPS systems etc. That said, modern computer networks should be protected the same way as the Nijō castle: a multi-layered defense approach.

Keep safe,
Ziv Mador

On May 28, our colleagues at The Microsoft Security Response Center released advisory 971778 which elaborated on a new vulnerability in Microsoft DirectShow effecting Windows 2000, Windows XP and Windows Server 2003. You can obtain more details on how to protect your environment from this vulnerability from the Microsoft SRD blog.

We have been closely monitoring the malware landscape for threats related  to leveraging exploits against this new vulnerability. We subsequently developed and released a generic detection for malformed media files, Exploit:Win32/CVE-2009-1537, based on MAPP information provided to us. Also, we have developed detections for the known malicious web pages, as Exploit:JS/Mult.BM or Trojan:HTML/Redirector.I. Our security products, such as Windows Live OneCare, Microsoft Security Essentials, and Forefront Client Security can block access to these malformed media files with signature definition update version 1.59.798 or higher.

While we are aware of several distinct files containing these exploits, based on our telemetry, the number of affected customers is very low. For our fellow researchers in other security companies, here are some SHA1 hashes of malformed media files:

The known exploits are typical drive-by attack scenario as shown in the following diagram:

Users, upon visiting a specially constructed web page that invokes the vulnerable media plug-in, will encounter exploit shellcode, which further execute and download additional malware to the infected machines.  Intending to bypass antimalware protection, malware binaries are encrypted in the download data stream.

New dog, same old tricks. To wrap up the attack scene, under the cover of the new exploits are the old long-lived online-game password stealers:

PWS:Win32/Wowsteal.AP (drops PWS:Win32/Wowsteal.AP.dll)
TrojanDropper:Win32/Dozmot.C (drops PWS:Win32/Dozmot.C and VirTool:WinNT/Dozmot.A)
TrojanSpy:Win32/Lydra.AE

We recommend you revisit these security tips during your online and gaming adventures. As usual, be cautious when visiting web sites and opening movie files from untrusted sources, and make sure your antivirus software is up to date. Microsoft will release a security update for this issue and once that happens, install it immediately.

-- Lena Lin, Cristian Craioveanu, Josh Phillips & Patrick Nolan

Microsoft Security Essentials is a new, no-cost, anti-malware solution for genuine Windows PC consumers that provides real-time protection against  viruses, spyware and other malicious threats.  It is a lightweight, effective and modern anti-malware which runs on 32 bit and 64 bit Windows 7, Windows Vista and Windows XP SP2 and higher, and on modern consumer form-factors such as netbooks.

A beta version of Microsoft Security Essentials v1.0 is available today for up to 75,000 consumers in a limited number of countries. You can find more details about the beta at the Microsoft Security Essentials website.

-- Microsoft Security Essentials Team

Recently, Marian and Andrei presented a paper at the CARO Workshop about PDF vulnerabilities and exploits related to them.

As we presented in our latest Security Intelligence Report, there was an increase in the use of these exploits, and the trend keeps going on. Since the beginning of the year, we have received over five thousand different samples taking advantage of various PDF vulnerabilities. Even though updates for these vulnerabilities are available, some for more than a year, people remain vulnerable despite having the solution at hand. And what is more important, the malicious samples work and people still get infected because they have not protected their systems as they should. The chart below shows the evolution by month which shows how things keep trending up:

An example of how an attack takes place would be like this: a website hosts a specially crafted PDF document, which contains the exploit code. Someone visits the page and the browser opens the PDF document, executing the PDF application in order to show its content. If the version of the PDF application in the user’s system is vulnerable, the obfuscated exploit code (e.g. a variant of Win32/Pdfjsc) is executed and downloads an awful piece of malware. This downloaded malware can obviously change from a password stealer to any other specimen the bad guys want. Some of the cases we have seen include members of families like Win32/Vundo, Win32/Renos, etc...

Nowadays, most applications have the option to update automatically. Let’s take advantage of it and have a safer computer experience. For more information on how to update your Adobe software, visit the Adobe security bulletin page.

Andrei Saygo, Marian Radu & Enrique Gonzalez

No-one who knows what they're talking about would say that writing a debugger is easy.  It's certainly made harder when the platform offers so many opportunities for things to go wrong.  Here are two examples.

CreateToolhelp32Snapshot

This function was introduced to the Windows NT-line in Windows 2000, though it existed as far back as Windows 95 in a separate DLL. On Windows NT-based systems, it calls into the ntdll RtlQueryProcessDebugInformation() function, which performs the majority of the work. Depending on the information that is requested, that function might insert into the process a thread that is used to gather that information about the process.

This has the unintended consequence of resuming a suspended process. For example, calling CreateProcess(myfile.exe, CREATE_SUSPENDED) then CreateToolhelp32Snapshot(myfile.exe pid) will cause myfile.exe to wake up and start running.

If a debugger has attached to the process, then Windows will create another thread that executes a breakpoint on behalf of the debugger. The problem is that when the process wakes up, the debug breakpoint will execute before the debugger can call WaitForDebugEvent() to intercept it.

This will typically cause the process to crash (though there are ways to intercept this and continue to run, no longer under the control of the debugger). One debugger is known to misbehave as a result of this bug.

Windows XP and later attempt to read from the process memory first. This attempt fails for a suspended process because it has not been completely initialised at that time. As a result, Windows XP and later do not create a new thread, so they do not demonstrate the problem.

CREATE_PROCESS_DEBUG_EVENT

When a process is started, a debugger typically wants to place a breakpoint at the main entrypoint. There are two common ways to locate this address.

The first way is to query the EntryPoint field in the InMemoryOrderModuleList structure. Interestingly, we document this field as "unsupported", even though the PSAPI.DLL uses it.

The second way is to wait for the CREATE_PROCESS_DEBUG_EVENT event to occur, and then to query the lpStartAddress field in the CREATE_PROCESS_DEBUG_INFO structure.  However, there is a problem with this second way. Windows has supported the relocation of EXE files since Windows 2000, though this fact has never been documented officially. With the introduction of Windows Vista and Address Space Layout Randomisation (ASLR), this "feature" came to be supported officially.

As a result, a file can be loaded to an address other than the one that it requested. One case in particular is when the requested address is intentionally invalid, such as zero or above 2Gb. This causes Windows to load the file to 0x10000. So far, so good.

The problem is that for such files, the value in the lpStartAddress field in the CREATE_PROCESS_DEBUG_INFO structure contains the "expected" (and incorrect) entrypoint value, that is calculated by summing the values from two PE header fields: ImageBase and AddressOfEntryPoint.

A breakpoint that a debugger places there will not be hit. If the debugger then resumes the process, the process will run freely. One debugger is known to misbehave as a result of this bug.

Such seemingly simple things, yet such potentially disasterous effects.  That's why debugging malware is best left to the professionals. If you can't trust your debugger, whom can you trust?

- Peter Ferrie

So far, it seems that a number of known attacks on RFID devices can be generally sorted into  three broad categories, that is;

• cloning an RFID tag,
• unathorised modification of an RFID tag,
• using an RFID tag to mount an attack on an RFID back end application,
• attempting a blunt denial of service. 

Continuing the biological virus analogy, an RFID tag can act as a carrier affected by a dormant infection, and the RFID protocol and radio waves can act as a transmission medium (say, like a fine mist of water that carries an airborne biological virus). In turn, an RFID reader is the port of entry for the infection and a computer connected to an affected RFID reader is thus susceptible to system infection.

If the traffic between the RFID reader and the tag is not encrypted it appears that cloning a tag, in most cases, is a fairly straight forward procedure. An analogy can be made to a voice-activated security system where recording the genuine request - response exchange would generally allow imitating the response any time the request for such response is made. In the case of an RFID system, a device constructively similar to an RFID reader but more sensitive, with multiband capabilities and the ability to record and analyze recorded sessions, is placed close to an RFID tag during the exchange. The radio session is recorded, demodulated and stored for post processing. Once the response of an RFID tag is isolated, it can be played back to the reader, eventually retransmitting an exact copy of the response from a legitimate tag. The cloning is complete. Similarly interrogating a tag with a predominantly known original reader request recorded earlier could activate a tag and allow recording of the transmitted tag’s response away from the original reader. This allows cloning to occur simply by placing the session recording device in the operating proximity of the tag.

Would such a recording device be readily available to the general public? The answer is yes. The architecture of an RFID recorder would be generally based on a Software Defined Radio (SDR). This type of radio device was originally proposed for  use by the military in late 80’s and early 90’s and then made its way to the public sector for  use in cell phone, medical and measuring equipment. The SDR samples the RF signal directly into the digital domain allowing any post processing, including demodulation, decoding, and any signal transformations to be done by software. This configuration is extremely flexible and allows the use of different protocols, encoding, decoding and modulation schemes. This is possible because all the necessary processing is done in the supporting software, leaving hardware modules intact.

The advances in Very Large Scale Integrated (VLSI) chipsets and high frequency electronics have made  SDR solutions affordable. A number of designs have been created and made available for reproduction by anyone who is generally versed in electronics. One such device has been designed specifically for RFID security studies by Jonathan Westhues (http://cq.cx/proxmark3.pl) and is referred to by numerous RFID hacking communities. Another SDR implementation, which is not specifically tailored for RFID needs, but is extremely flexible since it has capabilities to cover beyond HF band of 13 MHz (possibly including 433Mhz, 865-956 MHz, and 2.45 GHz bands), is the collaborative work of several individuals and is currently being actively developed and supported. (http://hpsdr.org/).

Is it possible to modify an RFID tag with some arbitrary information? Yes it is. Acting as an RFID reader and following a defined protocol, an SDR device can relatively easily modify information stored on a tag. It is also possible that an SDR device acting as a tag could simply present desired information to an RFID reader. This last method even works for tags which cannot be written to - the tag is simulated by an SDR device and the actual tag is not even needed.  Several successful proofs of concept have already been reported. 

Some RFID system configurations can loosely be looked at as user-input web-based processing systems. An RFID reader could be compared to a web page which requires some user input, and the tag can be related to actual information provided by a user.  Such a system may be susceptible to vulnerabilities targeting various layers of back end software. For instance, an application responsible for acquiring a user’s input or processing it, or the database engine or the decision making application layer could be susceptible.  Most notoriously it seems that some database engine vulnerabilities found to affect web based input systems could be directly applied and exploited, thus affecting an RFID system as well.  It looks like most of the time the back end is similar, if not exactly the same, for both of these system configurations.

There’s the possibility of crafting an attack where an exploit would allow the execution of malicious code stored on a tag. This could lead to an attacker gaining control of the back end infrastructure and possibly lead to the retrieval, loss or modification of sensitive information and costly down time. It is also possible to have such an attack propagate itself either through previously unaffected tags or by any other conventional means (such as mass mailing, shared drives or any other removable media). Some basic proof of concepts have already been circulated through the web, and while they are still in their infancy and only work in a controlled lab environment, the development of such techniques might pose a real treat in the future.

Because of physical restrictions on the number of tags which can be placed in the proximity of an RFID reader, generally, most RFID systems are not robust enough to defend against input information overloads. Although certain algorithms exists which are used to process multiple tags placed in the proximity of the reader,  such as walking a tree of tags id’s or a randomized poll for a bounced tag request, there is still a number of ways to disrupt an RFID service through RF interference. Creating interference on the carrier frequency of a reader will generally disrupt a radio frequency communication affecting the quality of the modulated signal.  Such an effect can be observed on a conventional radio when trying to tune to a weaker station which happens to share a carrier frequency with a more powerful station. Also because of automatic gain control of radio receivers aimed at protecting their input circuits from signal overloads, the sensitivity of the receiver will be tuned down to accommodate the stronger signal thus masking the weaker signal out.

In the case of encrypted RFID tags most of the attacks are not as trivial and require cryptanalysis in order to retrieve the key and the session’s data. To make it somewhat viable could require  substantial computer power. Because of the cost restrictions associated with tags, which affects their computational abilities, the key length is kept low, usually in the vicinity of 40 bits, and the encryption algorithm is generally kept obscure in the hopes of thwarting cryptanalysis. But using obscure encryption algorithms unfortunately most of the time works to the advantage of an attacker. Unknown or specifically tailored encryption algorithms are unlikely to have been tested by the broader cryptanalyst community. Often, when these algorithms are later exposed, they are discovered to be weak or may contain flaws which can be exploited.

It appears that in most of these case scenarios the security aspect of RFID designs is still a tradeoff between the cost of implementation or replacement, and the probability of attacks carried out on any particular RFID solution. A practice which may be acceptable today might become very costly in terms of down time and data loss once RFID solutions become widely adopted by industries and economically lucrative to attackers.
 
There are certain steps which might be taken to fortify RFID security.

• Keep RFID tags RF shielded or disabled until actual use with the reader, essentially limiting exposure of the tag to the possibility of cloning or a cipher attack.
• Use proven encryption algorithms - It is viable in the long run, despite the cost, to have all access control tags encrypted using proven encryption algorithms with larger keys (DES, RSA and so forth). While it might keep you at a door for a bit longer during an authentication process it is definitely worth it, considering the potential toll of a security breach.
• Use a testing platform utilizing the SDR devices mentioned above to assess different configurations and possible security issues associated with an RFID solution - why wait until someone else uncovers and possibly uses a vulnerability in your design?
• Provide robust input validation. This is the first and very important line of defense against vulnerabilities.
• If security is paramount, combine RFID solutions with other means of access control, for instance biometric.
• Have an RF SDR scanner listening in on a tag reader exchange and validating the data and protocol according to its internal database. Having a database of known attacks against such a configuration can act as an RFID intrusion detection system, and possibly block off malicious tags.

While the technology may be relatively novel, its adoption by various industries should be considered with security in mind.
 
--Oleg Petrovsky

This month, MSRT takes on another prevalent rogue family. This one is called Win32/InternetAntivirus and, although it has dabbled with the names General Antivirus and Personal Antivirus*, it is usually easy to recognise by the moniker Internet Antivirus Pro.
 


Win32/InternetAntivirus follows the familiar path of fake online scanner leading to the rogue downloader, which in turn installs the rogue itself. The online scanner looks like this:
 

 
This rogue downloader that these pages want you to run also downloads a password stealer called TrojanSpy:Win32/Chadem. Win32/Chadem tries to grab FTP usernames and passwords that the rogue creators can then use to compromise servers in order to host more malware. They use new domain names every day, often registering multiple names at a time, like scanfan4.info, star4scan.info and scanstar4.info.
 
Win32/InternetAntivirus also installs a component to display messages in your browser, similar to the combination of Win32/FakeXPA and Win32/Yektel. And it displays a bogus Windows Security Center, which reports that Internet Antivirus Pro is "unable" (sic).
 

 
This is all pretty normal rogue behaviour these days. As always, only use security software that has been tested by a trusted third party. Read this or the latest Security Intelligence Report (SIR) for more details on what to look out for.
 
-- Hamish O'Dea
 
* Not to be confused with Win32/FakeXPA, which also currently (mis)uses the name Personal Antivirus.

An RFID system is based around a reader and a tag. A tag stores information, whereas an RFID reader retrieves or modifies information stored on the tag. To transmit this information through the air, both devices  use high frequency electric current oscillations (the frequency of such current oscillations is also known as radio frequency or RF) which when applied to a piece of wire (referred to as an antenna) have a tendency to extend themselves well beyond the actual antenna wire boundary in the form of electromagnetic waves.

Such waves consist of two parts; magnetic and electric. Each of these contributing parts has an area of influence which depends on the distance from the emitting antenna.  Another important feature of the waves is their ability to induce electric charge or current in a conductor placed in the path of such wave propagation. If a tag is placed in the path of an electromagnetic wave emitted by a reader, there will most certainly be electric current induced in the tag’s antenna. Also, the direction of propagation can be roughly controlled by the shape of the emitting antenna, although in reality waves tend to scatter among a multitude of directions.

Here’s an oversimplified but basically functional schema of an RFID system. (Fig.1)

Fig. 1

To pass information from the reader to the tag and back, the RF waves are controlled, or as it is custom to say, modulated, with a much lower frequency of actual data transmission. A variety of modulation schemes exist, but most commonly they are based on the control of electromagnetic waves properties; amplitude, frequency and phase. The modulation schemes employed in RFID are designed to be the most useful in digital transmissions, meaning that such modulations encode only two states, interpreted as ‘0’ and ‘1’.  These modulation schemes are called ASK (amplitude shift keying), FSK (frequency shift keying) and PSK (phase shift keying). A simplified overview can be seen in the following examples.

Imagine we need to encode 101010 (this number is chosen as a good illustration of modulation for the purposes of our example).

As can be seen from fig.2 a ‘1’ or a ‘0’ state are represented by intermittently changing one of the wave’s properties; the amplitude, frequency or phase. It is worth noting that the frequency of the electromagnetic wave, which is subjected to modulation, is normally called a base frequency. 

Modulation and demodulation of the carrier frequency normally adds to the computational load for a reader or a tag. Also with the advent of specialized hardware bases for RFIDs there’s also a tendency to shift RF functions away from the main processing unit within a tag or a reader and incorporate them as functionally complete modules within a specialized integrated circuit. Such higher circuit integration essentially frees CPU to conduct more computationally intensive encryption algorithms. To distinguish between varieties of RFID devices and to make sure they best suit their dedicated purposes there are a number of standard protocols defined for an RFID tag and a reader exchange. These protocols differ by occupied bandwidth, carrier frequency, proximity of operation, amount and type of data exchanged and the type of coupling between the reader’s and the tag’s antennas.

So far there are a number of carrier frequencies which are used for RFID protocols. The frequencies in the range of 125-135 KHz are often used for pet and human tag implants as well as for some security access systems, such as car immobilizers and secured perimeters. The range of a reader - tag interrogation is mostly limited to 0.5 meters (around 1.6 feet). The bit rate of communication is comparatively slow (less than 1kbps) and the bit traffic is normally not encrypted.  In most cases tags are passive, meaning that they feed off a magnetic field created by the reader. These passive tags are often quite simple in implementation and tend to use backscatter propagation, basically reflecting the signal emitted by the reader in a certain way based on a configuration of the tag’s reflective surface. Once received, a reader analyzes the signal’s waveform to make a decision about the validity of the tag. Such technology is not new; quite similar techniques are used in radar or sonar applications to identify basic target's shapes for instance.

There are also some carrier frequencies allocated around 13.56 MHz, 433 MHz, 865-956 MHz, 2.45 GHz. The carrier frequency, generally, affects the proximity of operation as well as the amount of information it can carry when modulated, hence the used bandwidth and the speed of data exchange. Of interest, 13.56 MHz is becoming increasingly popular.  Because this frequency is fairly low, it allows inexpensive RF designs for a reader and a tag, and at the same time provides  an increased bandwidth for communication when compared to lower base frequencies such as 125-135 KHz.

Peering inside a modern reader or a tag we can usually spot a number of basic blocks.

Data from a control application, formalized by the CPU (Central Processing Unit) according to an RFID protocol, is passed to a DSP (Digital Signal Processor) where it is functionally transformed following the modulation and encoding schema. The byte stream then follows to a DAC (Digital to Analogue Converter). The DAC converts digital information to its analogue representation (where for instance digits correspond to an analogue parameter, say voltage) and passes it to an RF amplifier. The commutator controls the signal flow in and out of the antenna.

The received signal follows the reverse path where it is digitized by the ADC (analogue to digital converter) and then demodulated and decoded by the DSP. Note that the schematic of the module shown in Fig.3 is greatly simplified, but even at its most basic it shows a modern approach to design and implementation of RFID transceiver modules which heavily rely on digital post processing - while it is somewhat more expensive for design and manufacture, it is extremely flexible.  This architecture can adapt to changes in modulation encoding and RFID protocol by utilizing different software or firmware. It avoids costly hardware redesigns and remanufacturing and leads to greater encapsulation of RFID protocols from the controlling application.

While it is desirable to follow the digital signal processing approach when designing RFID infrastructure, in the case of RFID tags it is not always possible or viable.  For successful adoption of RFID technology it is imperative that the price of RFID tags stay low. This factor limits computational power available to a microcontroller for the DSP implementation. Most of the time DSP is sacrificed in favor of hardwired analogue logic which cannot be changed to reflect adoptions of newer standards.

The basic blocks of a tag include a CPU, memory, RF transceiver, modulator (MOD), demodulator (DEM) and antenna.

There are many variations in RFID tag implementations. For instance, there are tags which use only the geometric properties of their piezoelectric surfaces to resonate in response to the signal transmitted by the RFID reader.  The geometric configuration of the resonating RFID tag membrane imprints a distinct signature on the reflected RF signal. While the cost of such tags is extremely attractive, the use is very limited and overall such a solution might not be as cost effective and as generally adopted as the rewritable tag pictured in Fig.4.

There’s no doubt that RFID solutions are convenient, viable and provide flexibility to access control, payments and tracking infrastructures.  There are a number of pilot programs run by some big retail chains where RFID tags replace UPC barcodes. There are toll payment systems in the US and elsewhere that have been utilizing RFID tags for some time. In recent years we’ve seen the introduction of RFID passports by some European and Asian countries. There also seems to be a wide application of RFID tags implanted in pets, helping to track a stray pet and return it to its owner.

The adoption of RFID tag technologies by industries is on the rise. According to IDTechEX, it is expected that the RFID market will grow from 5 billion measured in 2008 to an estimated 25 billion in 2018.  Where does it leave us in terms of the RFID security? Should we be more concerned and more prepared with all the facts currently at hand? You’ll have to read part 3 of this series on RFID security...

--Oleg Petrovsky

Most people would be aware that biological viruses can be airborne, and can spread in this manner. For instance a common flu virus is able to survive in a fine mist of water droplets suspended in mid air until it lands on the next host. Luckily, not all viruses are created the same - some can't "fly", some "fly" but can't "land", some land but can't reattach themselves to a host.

Interestingly enough the same analogy persists in the realm of computer viruses. Would my computer or a smart device get infected if I came close to an infected laptop or a PDA? Continuing the analogy from the biological world, it depends on the ability of an already-infected system to deploy viruses into the common medium for transmission (air in our case), the host’s defences against such an attack, and the ability of the virus to penetrate those defences. Technically speaking, if a virus broadcasts itself utilising a wireless data transfer protocol and another system accepts this transmission and transfers control to the received data, then we may have a case of an "airborne" infection.
 
The most plausible case scenario might include a virus that utilises a vulnerability in the driver of a wireless device or a service using either TCP/IP or Bluetooth protocols. However, despite the growing numbers of wireless devices, including smart phones, PDAs and 2G, 2.5G, 3G and GPRM network services, so far we've been fortunate to not have outbreaks of this nature. Perhaps this 'good fortune' can be ascribed to several factors, including the diversity of wireless platforms, drivers, and services which limit the possibility of replication as well as the prevalence of security measures aimed at plugging holes exposed by vulnerabilities.

The situation is a bit different with common Radio-Frequency Identification (RFID) devices. We use them every day - some of us without even realizing it. For instance books or DVDs in some libraries have RFID tags that are scanned when they go in and out of a library database. We are granted access to offices and restricted premises using RFID badges. Some supermarkets and warehouses have run pilot programs to track and scan goods using RFID tags. Many countries have started using RFID for admittance to public transport, toll roads and passport control. Since 1998 ExxonMobil has been using RFID for fast transactions at the pump. The use and demand of RFID technologies is increasing.

At a basic level we have two devices: an RFID tag and an RFID scanner. When an RFID tag comes within close proximity of the RFID scanner the scanner reads and processes information from the tag. A tag can be active or passive - that mostly means either the presence or absence of an internal power source. If there's no internal power source, RFIDs use a wire coil which picks up electromagnetic energy from a reader. The tag can be read or written to. The tag could store identification information, as well as arbitrary information acting as a portable storage device used by a service application in any way it finds useful. For instance, a tracking system can update a tag on a package when it passes certain check points.

At a hardware level an RFID tag normally consists of a receiver, a transmitter, and a micro-controller which facilitates the exchange. The RFID sensor or a reader/writer is pretty much the same except perhaps the transceiver is a bit more powerful and the micro-controller usually has more processing power than an RFID tag. Normally, information stored on the tag has to be authenticated to prevent counterfeiting but because tags are thought of most often as a disposable device with the cost of manufacturing kept low, generally RFID tag micro-controllers are not powerful enough to employ sophisticated means of a robust real time encryption and are susceptible to attacks.

Most of the time an RFID reader is connected to some sort of database software to process data received from the tag. Once the tag is compromised it further opens possibilites for various scenarios of security breaches. For instance using an SQL injection vulnerability technique one may be able to force the system to run a stored procedure or a malicious binary code inside a database engine, which in turn can write code back to each passing tag, hence aiding in the propagation of the attack. In a succession of several blogs I'd like to explore the features and various standards of RFID devices and their security - perhaps going under the hood of most common hardware and software configurations.
 
--Oleg Petrovsky

We’re seeing plenty of reports for a JavaScript redirector malware family that we call Gamburl; previous reports have called it Gumblar or Redir.

These attacks seem to be coming from legitimate Web sites with pages that have been modified to contain this malicious script. So even if you’re visiting a Web site that you trust, there’s still the possibility that you may be a victim of these so-called “drive-by attacks”.

When a user visits a site containing a Gamburl script, the browser will be redirected to a specific Web site that contains a slew of exploits and other malware. As of this writing, Gamburl is known to redirect to the following Web sites:

gumblar.cn
martuz .cn

Once connected to the above sites, Gamburl tries to download other malware into the system. From what we have observed, these malware are mostly backdoors, PDF and Shockwave exploits. However, some of the observed downloaded malware are variants of the Win32/Daonol family. Examples of MD5 of Daonol seen are 7de29e5e10adc5d90296785c89aeabce and 2131112053ed144c46277b9024bcf39f. Daonol trojans are capable of preventing access to security Web sites, and redirecting searches to sites hosting other malware. Daonol is also capable of stealing information, such as FTP credentials, and placing the information in a file in the Windows system folder called sqlsodbc.chm. Note that a file named sqlsodbc.chm exists by default when you install Windows, and so is overwritten if your system has been infected by Daonol. This may be a symptom of Gamburl/Daonol infection. In case you suspect infection, you might want to check the list of some the unique hashes and file size of a clean sqlsodbc.chm.

However, users should also note that whatever malware is being served can be changed by the malware authors at any time.

This is a screenshot of part of the Gamburl code. It attempts to determine the script engine version of the browser being used. Based on this information, the malicious site could serve a variety of targeted exploits.

As always, we recommend that you use antivirus software and make sure that you have the latest signatures. Microsoft Antivirus customers are currently protected against the Gamburl family with detections Trojan:JS/Gamburl.A and Trojan:JS/Gamburl.gen!A.

Because this threat also makes use of a lot of exploits for other applications we would also like to remind users to always update all their software to the latest versions.

Thanks to Jonathan Poon and Ian McMillan for providing us information regarding sqlsodbc.chm.

-Elda Dimakiling & Jireh Sanico

This month’s MSRT shows the following top ten most prevalent threat families as of May 19.  The newly added and blogged rogue family, Win32/Winwebsec, is ranked at #17 with 34,792 infected machines. 

A few key takeaways from this telemetry:

• Out of the top 10 threat families six moved higher in ranking compared to last month.  Some of these six threat families like Alureon and Vundo have been around for more than two years while other like Koobface (refer to the recent MMPC Koobface blog) have only been seen in the ecosystem for several months.  This indicates each threat has its own lifecycle and it appears that sometimes malware authors are willing to reinvest in their existing distributions instead of moving to somewhere else.
• Three of the top 10 are password stealer threats.  In fact there are five if you count those two worms, Taterf and Koobface, both of which have critical payload of stealing user data.  Or consider six - Alureon trojan goes for users’ password and credit information as well. Adding them together there are 859,842 machines infected by password stealer threats when we are only talking about the top 10 threats.  Note this is not a direct sum since some machines were infected by more than one of these threats.
• Renos continues to be high on the list and is a major distribution channel for fake Antivirus programs.
• Cutwail drops slightly but stays in the top 10.  This is a spambot that we’ve discussed in different venues including in the recent Waledac blog.

So, not much of a surprise but worth taking note - identity theft, rogues and spammer highly occupy the top 10.  Criminals are going after your wallet especially at this recession time. Be safe.  Make sure you have firewall and AV product installed on your system.

Scott Wu

Nowadays almost everyone is affected by the recession in one way or another. More and more people try to save money.

Instead of buying licensed songs in CD form or from reputable online services, some people prefer to download songs via P2P or do a direct download from untrusted sites. This is a popular way of getting music files for free.

Wimad is a malware family that is known for using music files as its medium for distribution. It is a detection for malicious Windows media files that encourage users to download and execute arbitrary files on an affected machine. When opened with Windows Media Player, Wimad files open a particular URL in a web browser and prompt the user to download a file.  The accessed URLs and the downloaded files vary according to the Wimad variant, but some of the known detections for the downloaded files are Adware:Win32/PlayMp3z, TrojanDownloader:Win32/Tracur.A and Trojan:Win32/Nebuler.gen!D. In the wild, Wimad files have been observed with the extensions .ASF, .ASX, .MP3, and .WMA.

Below is a graph of the top 10 family detections for the last twelve months.

As you can see in the following graph, Wimad is the 7th family with the most number of reported detections. 

Looking at Wimad’s monthly detection report from May 2008 to April 2009, we can see an increase in detection, with an average detection of about 1.5M per month and a peak observed last December and January exceeding more than 2M.

Based on the geographic distribution of Wimad for the last year, United States, Canada and United Kingdom are the most affected countries.

As blogged before by our fellow researchers, the cost for free software might be too high. Time and time again we encourage users to support and patronize licensed media and software.

--Francis Tan Seng & Elda Dimakiling

This month’s addition to the Malicious Software Removal Tool (MSRT) is a rogue security program called Trojan:Win32/Winwebsec. In most ways Winwebsec is virtually the same as most other rogues. It is often distributed through fake online scanner web pages that have a very familiar look to anyone who has spent any time looking at rogues:

This web page is virtually identical to those used by other rogues like Trojan:Win32/FakeXPA and Trojan:Win32/WinSpywareProtect. It can’t actually scan the machine; it’s entirely fake. At the end of the “scan”, or if you click anywhere on the page, it tries to load the trojan itself, which usually goes by the file name “install.exe”. If allowed to run, this installs the rogue, which generally looks like this:

Winwebsec goes by different names (“System Security” and “Winweb Security”), which is also typical of a rogue. One less common feature is that it has been known to download additional malware. For a short time it downloaded Worm:Win32/Koobface (which we added to MSRT in March). This brings us full circle: one of the ways we have seen people directed to Win32/Winwebsec’s fake online scanner is via Win32/Koobface. As Scott mentioned in his blog, Koobface can launch pop-ups which load fake online scanners. At one time it was FakeXPA, at another it was Win32/Winwebsec. Koobface doesn’t seem attached to a specific rogue.

Some variants of Winwebsec try to block execution of particular programs. Instead of containing a list of programs to block, however, they contain a list of programs to allow:

alg.exe
csrss.exe
ctfmon.exe
explorer.exe
services.exe
slsvc.exe
smss.exe
spoolsv.exe
svchost.exe
system
iexplore.exe
lsass.exe
lsm.exe
nvsvc.exe
wininit.exe
winlogon.exe
wscntfy.exe
wuauclt.exe

Anything not on the list won’t run. This is enough to enable the system to work (barely), but obviously stops you from running tools that might help you remove Winwebsec (even cmd.exe and taskmgr.exe are blocked, for example). This “feature” serves a dual purpose, however: it is also another way to convince you that you need to pay money for the rogue:

-- Hamish O’Dea

The Spambot

Whilst Win32/Waledac is probably best known for the ability to send spam, it can also download and execute arbitrary files. In addition to using this downloading mechanism to update itself, Waledac can also download other malware. The MMPC has observed the download of Trojan:Win32/FakeSpypro and TrojanDownloader:Win32/Rugzip variants.

Downloading and executing arbitrary files is not confined to malicious software. Waledac also attempts to download and install a version of the freely available packet capturing library "WinPcap". This spambot leverages the capability of the library to "sniff" network traffic, searching for credentials being transmitted as part of SMTP, POP, HTTP and FTP protocols.

In addition to what we mentioned in the previous blog that Waledac has been downloaded by variants of Win32/Bredolab, we have also seen Waledac being downloaded by Win32/Cutwail in the wild. Interestingly, the MMPC has recently identified Win32/Cutwail variants downloading the same rogue as Win32/Waledac, Win32/FakeSpypro (below it the skin for FakeSpypro rogue).

The Telemetry

Now let's take a look at the MSRT telemetry after Waledac was added to MSRT in April. Waledac is the #24 most prevalent threat family this month. More than 20,000 distinct machines were detected with Waledac infection worldwide. The criminals behind Waledac seem to enjoy having the deployment mostly on XP. Note this is not normalized. As of today MSRT install base on Vista is about 37% the size of that on XP.

Factoring with the installbase, we came up with the following table of infection rate, or computer cleaned per thousand MSRT executions (CCM) widely used in Microsoft Security Intelligence Report. This table presents the top 25 Waledac infected countries, then sorted by CCM. Turkey has the highest infection rate, followed by Hungary, Switzerland and Australia.

The Spam Data

The MMPC and the Forefront Online Service for Exchange (FOSE) conducted some research on Waledac related spam. In this study we included the following subset of Waledac owned domains and monitored the spam emails between 4/15 and 4/23.

• chinamoilesms.com
• coralarmor.com
• freeservesms.com
• miosmsclu.com
• smsclunet.com
• smspianeta.com

From these domains we identified the related IPs and counted the emails sent from those IPs. Over the course of the study, we observed a total 7,199 distinct IPs sending spam from Waledac. We observed 4,091,725 spam emails distributed by these IPs during the seven days. Non-Delivery Report (NDR) is not counted as spam email in this study. Note this is not even the peak of Waledac email campaign.

The location of the senders of this spam does not necessarily match the geo distribution chart of the MMPC waledac detection. The controllers of waledac can decide which zombies will be throttled or heavily loaded. Furthermore, they can rotate these IPs in and out and need not have them all active simultaneously.

We will continue to monitor the waledac threats and the spam activities.

Scott Wu - MMPC
Terry Zink - FOSE
Scott Molenkamp - MMPC

About four months ago some new colleagues in the security business arrived in our Dublin office. They are part of Microsoft Anti-spam team and it is our pleasure to have them here :)

The Dublin Spam team recently told us that almost every week, Microsoft Forefront Online Security for Exchange is filtering a whopping 13 billion spam messages. Most of them (around 95%) are automatically blocked because they are sent from computers listed in blacklists.

From the remaining messages that are coming from computers not listed in a blacklist of known spammers, another 30% are flagged as spam by various filters and rules.

That’s a staggering amount– one in three messages that is sent to you from supposedly clean systems is spam, but thanks to the work done by the Anti-spam team, it doesn’t clog your inbox.

Now, probably you remember (or not) our blog entries about our honeypot (part1 and part2). We’ve also installed a fake open-relay mail server and today we’re going to show you some of the things that we’ve received.

In the past few months our honeypot received probes from more than 60 independent computers that are used by various automated systems to actively search for badly configured mail servers.

Spammers are always on the lookout for expanding their capabilities to send spam messages, maybe contracting bot-herders that control a number of infected machines capable of sending massive amount of spam for their campaign.

Now, a server won’t be added so easily to the spammer’s network. Probe e-mails are sent a couple of times to check the viability of the target mail server (for example, to ensure that the target mail server is active and has not been reconfigured). The probe e-mails we’ve received usually have the following format:

Sender:  <random e-mail address>
Receiver:  <e-mail address monitored by the spammer>

For easier verification, the subject usually contains a way to identify the scanned computer, for example:

Subject: BC_<IP address>

Or

Subject: Super webscan open relay check succeded, hostname = <IP address>

Another interesting thing is that spammers are also using various free web mail services in their probes.

After a short check of these IPs we found just a few of them listed in our database as known spam senders. Of course some of those that aren’t listed belong to various web mail services, but the others are probably part of a botnet/spam network and are used only for various scans (possibly for “reconnaissance” attempts) and not for sending spam.

Using an open relay mail server is an integral part of the spam campaign. A spam message can try to sell you an untrustworthy product, but more seriously it can lead to a phishing scam, or might contain links that point to malicious files.

To make sure that your Microsoft Exchange Server is not configured as an open mail relay, you can read Microsoft KB Article 895853.

With our efforts combined, Microsoft’s Anti-malware and Anti-spam teams are actively working on mitigating these attacks.

Special Thanks to Kai Yu from the Dublin Anti-spam Team, and Andrei Florin Saygo and Jireh Sanico from the Dublin Anti-malware Team!

- MMPC Dublin
- Dublin Anti-spam Team