There are always people who want to piggy-back on the achievements of others. After ESET warned the public against ACAD/Medre.A in two blogs here and here and issued a free standalone cleaner for remediation, there was always the possibility that drawing attention to the issue would result in the topic being misused for other purposes. While  ACAD/Medre.A had impact on one industry in one geographical location, and the threat has already effectively been neutralized, ESET researchers found a puzzling website that claims to help in removing this threat.

If we review the claims made on the website about ACAD/Medre.A, we read first that:

While these are common symptoms of malicious software that hijacks a computer and misuses it for nefarious purposes, ACAD/Medre.A causes none of these symptoms!

Again, while this is a description of many forms of malware, ACAD/Medre.A does not perform any of the actions described above.

Are we getting down to the bottom line here?

Ah yes… Download… We will get back to this later.

First, what should we do to manually remove ACAD/Medre.A? In fact, apart from removing some registry keys (although even those will not hurt the system if they are left behind), removing the “acad.fas” files is enough. They are fastload AutoLISP compiled files, not locked by the system, not loaded as a process, and not installed as software on the system.

The advice from the website:

Needless to say there is no ACAD/Medre.A process to stop, there is no ACAD/Medre.A program to uninstall, and there are no real ACAD/Medre.A registry files, so the only “sensible” advice is to search for the ACAD/Medre.A files on your system and delete these.

So far for the advice, oh no… wait, there is more…. There is the advice to download “SPYWARE Doctor” to do all this automatically. You are given comprehensive information on the actions necessary to install “SPYWARE Doctor”, complete with accompanying screenshots:

A small detail here is that Spyware Doctor, a genuine utility published by PC Tools, a Symantec company, is not what gets downloaded or installed at all. What actually gets downloaded (and installed if you choose) are three different “tools”.

The “FixNCR.reg” file is a registry editing file that clears a large set of registry entries commonly used by malicious code, but none of them is used by ACAD/Medre.A. Medre. A only uses the following Registry entries to store its internal data, such as timestamps:

[HKCU\Software\Microsoft\Windows\Windows Error Reporting]
“FILE”
“FILE-G”
“FILE-H”
“Time”

Note that as mentioned in Robert Liposvsky’s Technical Analysis blog, the [HKCU\Software\Microsoft\Windows\Windows Error Reporting] Registry key is a legitimate one, only the four above-mentioned entries are used by the malware. None of these four entries are cleaned by this registry fix. As they are just used as storage for internal data by the malware, there is no harm in not removing them, but of course, given the way in which the cleaner is advertised , as mentioned above, any user would expect these entries to be fixed, too!

The second tool downloaded –  “SpyHunter-Installer.exe” –  installs SpyHunter4 from a company named Enigma Software Group (ESG), located in Clearwater, Florida. This anti-malware program had just one small problem in this context: in our tests, it did not detect ACAD/Medre.A on an infected system.

Now there is no anti-malware solution that will always detect all threats all the time, though we try our best at ESET to accomplish that. However, if the program is advertised specifically as suitable for the removal of ACAD/Medre.A then in this case, that claim is dubious at best. Note that the dubious claim here is made by Clean Guide PC, and not Enigma Software Group.

The third program downloaded is “SpeedyPC Pro Installer.exe”, and this utility found a mere sixty-three (63) problems that required my attention. Not bad for a clean – fully patched – disk image of a PC running Microsoft Windows with a sole ACAD/Medre.A infection.  What is bad is that this program, also advertised as part of the Medre.A removal process, does not detect the malware either, as shown in the picture below.

Funnily enough, the Junk Files section lists the install and processing logs of SpyHunter4. You would expect that – if offered together as a solution – these programs would interact with each other cooperatively, rather than the one calling the other “Junk”.

Of course, if you want to fix any of the problems with either SpyHunter4 or SpeedyPC Pro, then you first need to register (and thus pay) for the programs. As neither of the two tools will actually clean ACAD/Medre.A from my system, I will not be doing that. But since I want to have a clean system, and since the CleanPC Guide also takes every opportunity to suggest that I chat to a Live Expert 24/7, why not try that?

Oops… Clicking on any of the images that tell me to click to chat informs me that they currently are not available for a chat! So far it seems that  “Live Help 24/7” is not actually open for business at the weekend.

But when they were finally open for business I “tried” them and found myself chatting to “James” who wanted me to pay $119 to remove all kinds of malware for an entire year. This might be money-well-spend if one had to deal with some really nasty infections (if it was truly effective ,  but then again, your ESET product will also do this for real without any additional charge. Tellingly, they did not really know the page I was looking at. If you see the video you will notice the long pause after I ask if the website is theirs… They obviously had to look at it first! And of course it distracted them by forcing them away from their script.

And, of course it really got interesting when I asked them how they got their technical analysis data as “James” replied that they do not have ANY details “as they are just supporting customers via chat”. Now how can anyone support me without having technical analysis data readily available?

He kept wanting to know if I wanted to purchase their service. Eventually I told him I didn’t, then introduced myself and told them all the information was bogus!  I was graciously thanked for the information and told he would forward the information to his superior. I informed him that removing ACAD/Medre.A is not really rocket-science and all what is needed is to remove the infected “*.fas” files (there is somewhat more to clean up, in the registry but not that much) and  I got another universal “Okay!”

I don’t know if the chat service is genuine or not but it seems they are clueless.

While the ongoing floods of leaked account credentials from Formspring, LinkedIn et al. are potentially disastrous for the owners of those accounts, analysis of those data doesn't only provide a way of seeing whether our own accounts are at risk. It also provides an incentive for us all to re-examine our own password (and passcode) selection strategies by the insight they give us into whether we are using the same far-from-unique passwords as so many of the victims of these breaches.

My colleague Anders Nilsson's Eurosecure blog  looks at the data from the Yahoo! breach reported by Dan Goodin and refers to some detailed statistics. Rather than reproduce all those data here, I'd recommend that you read his blog, but as I've previously referred here and elsewhere to 'Top Umpteen' lists of insecure, over-used, easily guessed passwords, I can't resist reproducing the top ten he extracted here, as it comes from a more recent source than the Mark Burnett analysis I quoted in my previous post on the subject.

1. 123456 = 1666 (0.38%)
2. password = 780 (0.18%)
3. welcome = 436 (0.1%)
4. ninja = 333 (0.08%)
5. abc123 = 250 (0.06%)
6. 123456789 = 222 (0.05%)
7. 12345678 = 208 (0.05%)
8. sunshine = 205 (0.05%)
9. princess = 202 (0.05%)
10. qwerty = 172 (0.04%)

The TrustedSec blog suggests that the Yahoo! service from which the credentials were dumped is Yahoo! Voice, and if you have an account there, this would be a good time to change your password, however good it is. But if you're using any of the passwords above anywhere - or if it comes to that, any of the 25 below, as compiled by Burnett – it's a good time to start thinking about using better choices, or maybe looking for a good password manager program.

1. password
2. 123456
3. 12345678
4. 1234
5. qwerty
6. 12345
7. dragon
8. pussy
9. baseball
10. football
11. letmein
12. monkey
13. 696969
14. abc123
15. mustang
16. michael
17. shadow
18. master
19. jennifer
20. 111111
21. 2000
22. jordan
23. superman
24. harley
25. 1234567

No, number 24 doesn't mean I've flooded online services with logins where I use my own name. As I remarked the last time I published this list: "I've included the top 25 because it amused me to see my own name at number 24. I suspect, though, that has more to do with motorcycles than my own superstar status. "

If credentials are leaked for a service you use, there isn't much you can do except:

• Change your password ASAP
• Pressure the service provider into enhancing its security
• Consider whether there might be a safer service you can use.

But changing all your passwords to something harder to guess/break is never a bad idea.

* http://en.wikipedia.org/wiki/Pastures_of_Plenty

David Harley CITP FBCS CISSP
ESET Senior Research Fellow

We have been tracking the activity of the Rovnix bootkit family since April 2011. Rovnix was the first bookit family to use VBR (Volume Boot Record) infection (NTFS bootstrap code) for loading unsigned kernel-mode drivers on x64 (64 bit) platforms. The reason for exploring further is the desire of the Rovnix developers to bypass antivirus detection. The payload of the first samples in the wild blocked internet connection for Russian users and forced them to send an SMS to a premium number in order to get their connection unblocked (Hasta La Vista, Bootkit: Exploiting the VBR).

These variants with the internet blocking payload stopped using the bootkit component during the summer of 2011. At that time the Rovnix framework was sold to Carberp developers responsible for the botnet “Hodprot/Origami” (Evolution of Win32Carberp: going deeper). The Carberp developers used droppers incorporating bootkit framework only up to the end of 2011. We don’t have information about other sales of the Rovnix bootkit framework. But we only have information relating to a really small percentage of infections with Rovnix based bootkit code. A few days ago we got some interesting samples and quick analysis revealed similar VBR modifications to the Rovnix.B family. After unpacking the dropper we found a typical component for providing the next steps for  installation of the Rovnix bootkit’s BkSetup.dll module. The compilation timestamp of BkSetup.dll module looks fresh and is dated 24/06/2012: certainly it’s possible to fake a timestamp, but up to now developers had not changed the date on BkSetup.dll).

There is also a version information structure to be found in the resource section of BkSetup.dll filled as follows:

The file version has been changed to 2.4: previously, Carberp used version 2.1 of BkSetup.dll and stored the information in the debug string sent to the C&C as debugging information.

The base functionality of BkSetup.dll is centred on the process of infection and setting up the hidden storage partition. A call graph of the main BkSetup.dll routines looks like this:

A new sample with a new version of the Rovnix bootkit framework is indirect evidence of renewed sales activity and in the near future we may possible be able to disclose details of the relationship between Rovnix and other malware families. And now we will go deeper into the technical details of the Rovnix.D modification.

Polymorphic bootstrap code

Since Rovnix.B the modified bootstrap code has used polymorphic code in order to bypass static antivirus signature detection. Originally, polymorphic decryption code was detected in Carberp samples incorporating bootkit code. The following figure shows the basic workings of the polymorphic decryption code.

A simple trick of polymorphism based on permutations of the basic code blocks always results in the malware’s getting control of the decrypted malicious VBR code. The basic code blocks look like this:

[polymorphic code from Rovnix.B]

The reason for using polymorphic code is to bypass static signature detections by antivirus engines: this code can only be detected generically using emulation. Emulation is a technique closely related to sandboxing where the code is executed in a safe virtual environment in order to analyse it dynamically.  The differences between the Rovnix.D and Rovnix.B versions are presented in this flow graph:

[Rovnix.D variant (left) and Rovnix.B variant (right)]

The place where the encrypted malicious VBR is stored has been changed too, and after execution of the polymorphic code, control is transferred to the decrypted malicious VBR code. The different placement of the encrypted malicious VBR looks like this:

We also found changes to the function for decrypting and reading the malicious unsigned driver from raw sectors in the hard drive. These sectors are not used for general hidden storage, but only as a location for storing the malicious driver, which injects the payload into specified user-mode processes on the infected machine. Differences can be seen in the following figure:

[Rovnix.D variant (left) and Rovnix.B variant (right)]

All these changes are directed towards bypassing antivirus detections and do not represent fundamental changes in the general Rovnix bootkit framework structure.

Changes in hidden file storage

The structure of the hidden file system looks similar to the previous Rovnix modification and has already been described in previous blog posts (Rovnix Reloaded: new step of evolution). However insignificant changes were found in the file system initialization code. A strange function call was detected with the ability to read the file INJECTS.SYS from hidden storage.

This curious function extracts one or two paths from the file INJECTS.SYS to files on the standard file system. The function code is presented in the figure below:

Control flow never gets to execution of this code because the condition always receives NULL and control is never transferred to this code. In my opinion this modification in Rovnix.D is used for tests, and we aren’t seeing many detections in the wild. Rovnix.D seems to be a transitional version in preparation for something else, but at this moment we don’t have a clear understanding of what that might be.

Payload

The payload module includes functionality for downloading and executing additional modules from the C&C server. This module does not provide hooks and other malicious modifications to system memory, and is not generally detected by most common antivirus engines.

The C&C domain is rtttt-windows.com

The payload module works in multithreading mode and can communicate with the malicious driver. For synchronization reasons the payload generates the mutex:  Global\\<Generated_string>. The call graph for the main thread looks like this:

The payload module can also send an encrypted buffer to the malicious driver to be written to hidden storage and injection into processes. Before this Rovnix has not used any functionality for multiple injects, and provided only one payload module. Rovnix.D can use multiple payloads and can be used to provide a botnet for rent, and at the end of the rental period the payload will be changed.

Conclusion

At this moment changes can be seen in the landscape of complex threats for the x64 platform. The Sirefef (ZeroAccess) family has been migrated to user-mode in its latest modifications (ZeroAccess: code injection chronicles). Olmarik/Olmasco (TDL4 and MaxSS modification) does not account for a large percentage of infections in the wild and has stopped evolving (The Evolution of TDL: Conquering x64). Why are rootkits/bootkits for the 64 bit platform dying? In my opinion the ways in which x64 systems can be infected are severely limited, and the search for something new requires ample time and considerable experience on the part of the developer. Most bootkit infections have used MBR-modification, but this method is pretty old and by this time most common antivirus engines provide checks for a modified MBR. The Rovnix family used other ways to infect with modification of the VBR, but a constant stream of new modifications necessitates the provision of a great deal of debugging information to the C&C. The complexity of development and debugging on multiple platforms is one reason for the high price of the Rovnix bootkit framework. For example the fully-featured builder costs $60.000 including basic support for half a year. This price is only for the bootkit package and excludes the cost of exploits for escalating privilege in order to get access allowing modifications deep into the system.

In future, complex stealth technologies will mostly be used in targeted attacks, because the cost of buying and using them is not commensurate with the anticipated profit for typical cybercriminals. We now have less than ten families of x64 bootkits and their activity in the wild is also decreasing.

SHA1 hashes for the Rovnix.D droppers mentioned are:

• C1C0CC056D31222D3735E6801ACBA763AC024C5B
• 764B4F0202097F2B41A2821D30A7424490BF3A42

Special thanks to my colleagues Pawel Smierciak and Maxim Grigoryev.

Aleksandr Matrosov, Security Intelligence Team Lead

Changing the passwords on your online accounts might not sound like a fun weekend activity, but that’s what I did last weekend. Why? Because on Sunday I found out that one of my email addresses was in the list of Yahoo! logins whose passwords were exposed by sloppy handling of a credential file (an incident on which David Harley commented in a recent blog post). Here’s what I saw on Sunday, on a special web page created by the kind folks at Sucuri Labs:

Note that the “scobb at something dot com” email address was not a Yahoo! Mail address but one that I created and managed myself, associated with a domain that I owned for many years (somewhat obfuscated in the image). The fact that the “Yahoo! password breach” exposed non-Yahoo! email addresses and their corresponding passwords is an aspect of this particular breach which was not immediately apparent because the initial headlines for this story read “Hackers expose 453,000 credentials allegedly taken from Yahoo service.” I’m not criticizing Dan Goodin’s breaking story in arstechnica, it’s just natural for media attention to remain be focused on the biggest name involved, even as the story develops.

So how did I find out that my address was among those exposed? Obviously I used the Sucuri Labs web page that queried the list of leaked addresses (the list was published on the Internet by the folks that stole it from the server at Yahoo which they penetrated with a SQI injection attack). But why did I even bother to look at that web page? Because back in 2006 or so I was considering posting some articles on a website called Associated Content and I created an account there. If you go to www.associatedcontent.com today you will see that it is now Yahoo! Voices. I just happened to notice the Associated Content connection in my security news feed.

Just for kicks I searched my email archive and came up with this gem, the welcome message I received after signed up with Associated Content. This message suggests that Associated Content did not have the right approach to security back then (the original email displays the password in plain text).

The fact that this attitude could persist through the acquisition by a much larger and, one would hope, more diligent company, is disconcerting to say the least. That’s why I decided to do some serious password changing last weekend, just to be on the safe side. After all, millions of passwords have been exposed in the last 45 days, that we know off, including sites such as LinkedIn, Nvidia, and Phandroid. That makes now a good time to get the whole family to change up their digital credentials. The ESET blog has advice on how to go about improving your passwords, starting with a good collection of password-related articles here.

If you have some time left over after you have changed your passwords, you might want to email the CEOs of some of the companies that have let passwords leak out. Tell them to do a better job of protecting those who trust them to protect their information. Frankly, the standard of programming on too many big name websites fails to meet basic security standards. The technique used to get the password file from the Yahoo server, SQL injection, is widely known (consider this Search Security article on the subject from four years ago–plenty of time to put defenses in place, one would think).

Now would also be a good time for your company to review the way its websites are configured with respect to password handling, particularly if you have a support forum. The targets of the two latest credential exposing hacks to hit the news are forums. While two events do not make a trend, the news of these two events may attract copy-cat attacks. The very first thing you want to make sure of is that no passwords are being stored in clear text on web-facing servers. If you are a large company you might want to review all your sub-domains for old files that are lying around on servers from past acquisitions.

The Flame worm (detected by ESET as Win32/Flamer) is one of the most interesting targeted threats of this year. Although several articles about it have been published, many of the facts about the internal structure of its main module (mssecmgr.ocx) have not been disclosed yet. In this blog post we want to shed light on some of the implementation details of this component.

We first became acquainted with complex targeted threats through our analyses of Stuxnet (“Stuxnet Under the Microscope”), continued with Duqu (“Win32/Duqu: It’s A Date”), and now it’s Flame’s turn. Analysis of the Stuxnet code required quite an effort in order to comprehend the complete functionality of the worm. In the case of Duqu we found the architecture and implementation quite similar to those of Stuxnet, which made the process of analysing Duqu much easier. Flame is quite another story; there are lots of interconnected modules as well as internal storage for configuration information, and a payload with a format as yet unknown. Despite these difficulties we are going to reveal some interesting details about the main module mssecmgr.ocx.

Interconnection with Stuxnet & Duqu

It is clear that Flame is malware of the same kind as Stuxnet and Duqu. These malicious programs implement quite complex logic, with elaborate architecture and implementation details. They are intended to maintain a persistent presence on the attacked system. The object-oriented style of Flame programming in C++ makes code analysis more complex, because the process of analysis necessitates the reconstruction not only of Flame workflow logic, but compiler logic too. For example, a reconstruction of call method Rc4_GetBufferSize looks like this:

In static analysis, one problem  commonly encountered is that of ascertaining the single-valued relationship with an exact value in VTABLE, which will be called by the VPTR pointer. In the process of static analysis we use a method involving defining structures for the emulation of C++ objects. This method has been well described in the article: “Reversing C++ programs with IDA pro and Hex-rays”.

In the blog post “Win32/Duqu: It’s a Date” it is mentioned that Duqu is based on the same source code as Stuxnet. Based on the binary analysis of the main module of Flame (henceforth in this article this term will referr to mssecmgr.ocx) it may be concluded that the developers of the malware used different source code to that of Stuxnet or Duqu. Although mssecmgr.ocx makes heavy use of object oriented code this is quite different to how object oriented programming is used in both Stuxnet and Duqu.

If we look at the implementation details for certain objects we see that they are signficantly different. Consider, for instance, objects representing strings, which are almost the most frequently used type of object in all the malware considered here. In the figure below we present structures describing string objects in Stuxnet and in Flame and they are clearly quite different. The same applies to the methods implementation of these objects.

Figure 1 – Structures describing string types in Stuxnet and Flame

Such types are responsible for working with files, file mappings, synchronization objects, memory buffers, memory streams and so on, and are different from those implemented in Stuxnet.

Another distinguishing feature of Flame code is the frequent use of smart pointers like objects in order to handle pointers to objects of different types. Apart from the convenience of this approach (from the point of view of the developers) using smart pointers bulks up the code and makes it more difficult to analyze.

Main module analysis

Flame stores its components in various files within the Windows file system. It uses three distinct naming schemes in order to store the files. The malware chooses a specific scheme in each case, based on configuration information and the environment in which it is run. The following table contains information on these naming schemes.

Table 1 – Flame naming schemes

Flame Startup

When the malware is installed in the system it is registered as an LSA authentication package in the system registry. This results in loading mssecmmgr.ocx as part of the lsass.exe system process during system startup. Interestingly, LSA authentication packages are required to expose a specific set of routines as interface for LSA. None of these interface routines are implemented by the main module of Flame.

Flame OS supported versions

When the main module of the malware is launched it performs some checks as to whether the Operating System version is supported by the malware and whether the machine was loaded in safe mode:

Figure 2 – Flame initialization checks on startup

The malware doesn’t run on 64-bit operating systems, but runs on all versions of Windows starting from Windows 2000 up to but not including Windows 8).

Detecting antivirus software

When the main Flame module is loaded it performs checks as to what security software is installed on the machine to be infected. The list of the programs whose presence on the system should be checked is stored in configuration information which is discussed later. In the samples we analyzed there are approximately 320 different names which correspond to security software of different kinds: personal firewalls, antivirus software, parental control and so on. Depending on several conditions – as defined by configuration information – the malware may stop execution if specific security software is spotted in the system. All the detected products are split into groups depending on their functionality:

• Personal firewalls;
• HIPS;
• Antivirus software;
• Network packet analyzers;
• Parental control systems;
• System monitors;
• DLP systems etc.

Injecting into processes

Let’s look at how the malware propagates among processes within the infected system. Before going any further it is worth mentioning a nice publication on Flame’s injection technique (Inside Flame: You Say Shell32, I Say MSSECMGR).  To be able to inject code into the address space of other processes the malware carefully uses such standard API routines as:

• VirtualAllocEx – to allocate memory for the module injected into the target process;
• WriteProcessMemory\ReadProcessMemory – to inject the code;
• CreateRemoteThread\RtlCreateUserThread – to transfer control to the injected module.

As a result, at some point the address space of the target process will look like this:

Figure 3 – Target process address space layout during injection

What makes Flame difficult to detect is an interesting trick with the shell32.dll library. To map the image of the injected module, Flame allocates memory by mapping system library shell32.dll. The code responsible for doing this looks like this when it is decompiled:

Figure 4 – Reusing memory region of shell32.dll

This results in the creation of all the necessary system structures for the injected module and as a result it looks like a legitimately-loaded module.

When all the data and code are written into target address space, Flame creates a remote thread, by executing either the CreateRemoteThread or RtlCreateUserThread API calls and specifying the address of Stub 2 as entry point and the injected data as a parameter.

Stub 2 contains loader code, the purpose of which is to map the injected module into the address space of the process as follows:

• Allocate memory for the image;
• Apply base relocations;
• Initialize import address table;
• Call entry point.

It uses injected data as a helper structure containing the address of all the necessary routines and supplemental string constants. Here is a piece of the code responsible for initialization of this structure:

Figure 5 – Initialization of supplemental structures

Another thing that Stub_2 does is to hook the msvcrt.dll entry point with Stub_1 code. Later it will be shown why and how this hooking is implemented. The main functionality of Stub_1 code is to call the entry point of the injected module whenever the entry point of msvcrt.dll is called. As a result the injected module is able to receive all the events msvcrt.dll receives. It allows the malware to partially recreate the same execution environment as the legitimately loaded module creates. Flame hooks the msvcrt.dll entry point in quite an unusual way. Instead of splicing the code it overwrites the corresponding field of the PEB_LDR_DATA structure in InLoadOrderModuleList found in the PEB (Process Environment Block). After injection is completed the malware cleans up traces of penetration into process address space.

Flame configuration information

Flame’s configuration information storage is quite complicated and differs significantly at the implementation level from that of Stuxnet or Duqu. When the malware penetrates initially into the system, all the configuration data are contained inside resources belonging to the main module. Looking at Flame’s main module we notice a resource with the ID 146 in the resource directory. This is the place where all the configuration data are stored. Depending on the version of the malware the size of the resource may differ, ranging from 37 Kb up to 3 Mb. Unlike Stuxnet and Duqu, which store configuration data in a simple binary file, Flame employs a more sophisticated kind of storage which isn’t straightforward to parse.

To be able to get access to the configuration information one needs to decrypt the resource and decompress the decrypted data. The encryption algorithm is rather simple, as presented in Figure 6.

Figure 6 – Flame resource decryption algorithm

When decrypted the data are de-compressed with the inflate mode of the data compression algorithm. Thus the malware proceeds to decompress the data in small data portions (less than a kilobyte each). To bypass sandboxes the malware calls the Sleep API routine to wait for 10 milliseconds. between portions. This makes the process of decompression quite resilient:

Figure 7 – Inserting delays in resource decompression algorithm

Finally, after decompressing the decrypted resource, Flame applies a permutation to it as defined by the following byte array:

Figure 8 – Configuration data decryption permutation

 All the Flame’s configuration data are split into specially formatted blocks of the following natural structure:

Figure 9 – Flame configuration data storage basic block layout

Here, the block byte describes the type of the information contained inside the block. There are two types of blocks:

• blocks containing supplemental information about configuration information items;
• blocks containing the values for configuration information items.

The data field is structured as follows for blocks containing supplemental information:

Figure 10 – Flame configuration data storage basic block layout with supplemental information

Namely, it specifies the offset of the block with item data, the offset of the block containing supplemental information on the next configuration data item, and the name of the item. The root block is located at offset 0x1A from the beginning of the configuration data. In the next figure you can see a sample block describing configuration item RTS.MEDIA_SETUP.FILES_TO_DELETE:

Figure 11 – Flame configuration data storage basic block

Unlike Stuxnet and Duqu, where configuration information items were nameless, in the case of Flame malware researchers were able to take advantage of item naming to make understanding Flame functionality easier.

The type of data of configuration information items may be determined by the value of the block byte. Here are some block byte values corresponding to different types of items:

• 0×08 – DWORD (4-byte integer);
• 0×06 – WORD (2-byte integer);
• 0×09 – QWORD (8-byte integer)
• 0×05 – NULL-terminated Unicode string;
• 0×04 – raw binary data;
• 0×03 – item description block (see Figure 10)
• 0×02 – root block.

Depending on several conditions, when the malware infects the system it stores configuration information in a file with the name mscrypt.da0 or wpgfilter.da0 (see corresponding entry in Table 1)

We continue our in-depth code analysis of Win32/Flamer and will shortly return to you with new information.

Related ESET comment:

• The negative impact on GDP of state-sponsored malware like Stuxnet and Flame
• Stuxnet, Flamer, Flame, Whatever Name: There’s just no good malware
•  Win32/Flamer: the 21st Century Whale

Eugene Rodionov, Malware Researcher
Aleksandr Matrosov, Security Intelligence Team Lead

I received a sad report on the subject of PC support scams.

Yes, those same old scams where the perpetrator tells you that you have malware infections or system problems and tries to scare you into letting him or her connect to your PC so that he can install some software and fix it. For a price, of course, though that may not be immediately clear.

One of our readers described how he took a call from one of these guys on behalf of an elderly relative: having worked in tech support himself, he went out of his way to make the scammer’s life easier by giving him access to the relative’s system so that it could be fixed.

However, when he was told he needed to pay $310 in order to register his CLID file (from the context, I assume this is a variation on the CLSID ploy described here) he told the scammer he wanted to do a little more research on the problem first. And this is where it turned really nasty. The scammer told him that if his victim did not register the file, the computer would be shut down so that it couldn’t be used any more, as he claimed that the PC was only running a trial version of Windows That’s a ploy I haven’t come across before, and I can’t say I’ve ever heard of a trial version of Windows, apart from beta versions.

At first, our correspondent thought the scammer was just removing the files he’d installed during the remote session, but then realized that he was removing everything in the Windows/System32 folder. Although he shut down the remote connection window and rebooted the machine, enough damage had been done to prevent the system from starting up. (Hopefully, he was able to restore the system from CD without losing data.)

Scamming a Scammer

However, a somewhat related story had a much more entertaining finish. Chris Hamer, who has been quoted by US TV on the topic here and here, spent about 45 minutes stringing along a scammer who called him out of the blue. Fortunately, he already had a virtual machine set up for research purposes, so he was able to allow the scammer access in order to diagnose and ‘fix’ it. (Don’t try this at home unless you know exactly what you’re doing, which means you don’t want to give the scammer access to a machine you can’t fully or easily restore!)

Incidentally, Virus Bulletin’s Martijn Grooten did much the same thing with another tech support scammer, and he’ll be referring to that sting as part of our joint presentation (with Steve Burn and Craig Johnston) for the Virus Bulletin conference in Dallas in September.

But back to Chris Hamer’s story… He did a fine job of playing the dumb victim and gathered a great deal of information about the way this particular scammer operated. When, at the end, he told the scammer that he had no money to pay for the service and would probably ask his son to clean up his system, the scammer tried hard to persuade him that his credit card would not be charged immediately (this claim is characteristic of many phone scams, by the way), and then proceeded to make further changes to Chris’s system. When asked what he was doing, he claimed that he was installing free protection. However, he then told Chris that his PC was going to crash in 5-4-3-2-1 seconds. And it did. The scammer had gone to some lengths to make the system unusable. Fortunately, Chris is no dumb victim, and knew what was going on. He told me:

“He disabled all services, added a shortcut to startup that executed a little program he pushed from the remote admin app to kill services.exe, and then used msconfig to disable everything else. He also tried to add a startup shortcut that was a Weblink, but I hit escape when I saw him creating the shortcut and ended it.”

Imagine the scammer’s surprise, then, when Chris told him the system was rebooting normally and thanked him for his help. In fact, Mr. Helpful insisted that it could not be rebooting. But eventually he wished Chris luck with the system and rang off, no doubt to take a couple of aspirin and try to work out what the heck had gone wrong (from his point of view…).

In fact, the system hadn’t rebooted altogether normally, as you’d expect, given the nature of the damage: Chris had restored it from a virtual snapshot.

Lessons Learned

Good to see a scammer getting egg on his face, but what do we learn from these stories?

If someone rings you up to tell you that your computer is infected with viruses, the chances are overwhelmingly in favour of his being a scammer. Well, if you read this blog regularly, that won’t come as a surprise to you. But apart from not taking any such claims too seriously in the first place, you really want to be ultra-suspicious of anyone who wants remote access to your system. In Chris’s case, using ammyy.com, but other remote access services such as LogMeIn are also used or misused.

Getting remote access to your PC  is an essential part of the scam: not only does it help the scammer ‘confirm’ his ‘diagnosis’ of the problems with the computer, but it also gives him a way to ‘prove’ that he’s providing the so-called service that he is charging you for. But it has an even more sinister aspect: once he has that access, he can do pretty much what he likes within the limits of your own access privileges.

Trashing files and installing programs like the one Chris mentioned - though it wasn’t technically a virus, contrary to the TV station report - is just one possibility. Many of the scammers I’ve talked to have demonstrated little technical knowledge: after all, they’re mostly working from a script. However, they use social engineering ploys that do sometimes suggest a certain amount of technical knowledge. In the case of the scammer Chris talked to, the scammer has not only enough knowledge to run the remote diagnosis/installation session, but both the knowledge and intent to trash a victim’s system, possibly permanently. While I have yet to see verified reports of the installation of out-and-out malware such as fake AV,  it wouldn’t require astonishing technical sophistication to install something that would ensure that the tech support scammers would get another chance to dip their snouts into the trough.

There’s no gainsaying the malice displayed in these cases, though from the scammer’s point of view, I guess he considers himself entitled to be angry at having his time wasted. For myself, I have absolutely no problem in principle with seeing a scammer’s time wasted, and it appears that there are plenty of people actually prepared to do it. However, if you feel like a little scammer baiting yourself, you need to know exactly what you’re doing to ensure that you don’t expose yourself to malicious action.

And if you don’t want to waste your own time wasting a scammer’s time, I can’t think of any good reason to give remote access to your PC to someone who rings out of the blue and spins you a yarn about viruses.

David Harley CITP FBCS CISSP
ESET Senior Research Fellow

Gamigo learned a few months ago about a breach and alerted its users that they had been attacked. But now, we see an estimated 8+ million records just went public, no small amount for the attackers. What is interesting is that by one account, hash cracking was able to decrypt over 90% of the passwords, lending credence to what David Harley recently wrote about password complexity, or the lack thereof.

Also, while it seems Gamigo took pretty proactive steps to notify users, still 8+ million username/password combinations, even in encrypted form, is a huge haul, and can add significantly to the pool of passwords for scammers to attempt new breaches.

When scammers attempt to crack leaked hashed passwords, a common method is to use a program that references a word list to try different combinations. Word lists of this type are freely available online, and some scammers even bundle multiple lists and make them available, sometimes at a fee. While the original list in the Gamigo breach claimed to hold close to 12 million username/password combination, after de-duplicating the data, it seems the real number of unique combinations is closer to 8 million. But adding an additional 8 million password combinations to the already existing lists (some in the tens of millions), can give scammers quite a leg up on future exploits.

What to do? Well, if Mr. Harley’s blog is at all accurate, and the most common passwords he listed are indeed king, changing your password to something stronger seems to be the best first step, and a cheap piece of insurance. Also, there are sites online that allow you to check to see if your credentials are available on any of the wordlists. That might be worth your time as well.

The weak link here is that a person who uses a weak password, probably also re-uses it across multiple services, spreading the scope of their attackable surface substantially. Also, if scammers get into one account, then can get other personal information that would help them with the challenge questions on your other accounts, so the chain of nastiness may just be starting for unwary users.

Still, Gamigo did the right thing notifying users, and we’re sorry to see the whole list actually did make it into the public arena. So now might be a good time to revisit Mr. Harley’s advice, before it’s too late.

Hat tip to Forbes for their article on the subject.

Want to access the music tracks of YouTube.com videos on your iPod but don’t want to pay? You’re not alone. Recently, a crop of websites have popped up offering to convert the audio from videos to .mp3 files that you can then download at no charge. Sounds great, right? The catch: scammers are trying to capture the popular click traffic and redirect users to scam websites, where you might get more than you bargained for, in the form of free malware and other unpleasantness as a bonus.

Recently, we hosted a “cyber boot camp”, teaching high school students to attack and defend networks. One of our presenters, John Moffat, who often delivers security awareness seminars to teenagers and stresses the dangers of the “free” internet, referenced this scam in his presentation. While Mr. Moffat doesn’t claim to be a malware expert, he knows a scam when he sees one, and does his best to help others avoid falling prey.

So what happens if you fall for one of these types of scams? Below we follow the trail of one example, with screenshots of what you might see.

In this example, I clicked on a highly ranked Google search results link, which pointed to a YouTube video itself, purporting to give instructions on how to convert their videos to .mp3’s. When I did, it showed a non-video screenshot inside their video player, which directed me to visit a website directly. The video description came completely stuffed with keywords in the description to inflate rankings. Here’s a screenshot of what I was presented with:

When I typed the URL into a browser that the “video” recommended, I was taken to a site heavily laden with javascript (which my browser blocked with a plugin), third party content providers and Google Analytics, that said I had to complete a survey to get my “$500 Best Buy gift card”, which would also unlock the download of the free video-to-mp3 converter. Since I’d like a $500 gift card as much as the next guy, I clicked on that link.

and then a screen that showed the locked download file, which I would then have to unlock

I chose the Best Buy gift card offer. When I clicked on it, it took me to a page that shows that I could get a $1,000 gift card, even better!

I also noticed that the page wanted to use extensive javascript and third party content, triggering an ESET Smart Security warning that a website was blocked which was trying to send me tracking cookies. I also notice the site used significant bandwidth trying to load all its goodies, presumably to enable the successful completion of my 3 questions to get the $1,000 gift card right? But surprise, after I completed the last question, I then had to enter my email, presumably to get the gift card. When I entered a fake email, I was then taken to a screen where I had to enter much more personal information, including my physical address, age, sex, and phone number. I also had to consent to being called by third parties about magazine subscriptions, etc:

Once you click ‘continue’ you get the next screen:

At this point, I notice that the original password that was promised to unlock my video converter download never materialized. It seemed clear that this rabbit trail I was following would not likely end any time soon, so I exited the websites, and finished up this article, hoping this accounting of what happens if you take the bait would dissuade others from falling for similar scams.

What’s the payoff for scammers? For some time now they have continually adapted their scam platforms to match new potential streams of traffic, and this is no exception. By gaining high search rankings through BlackHat SEO (BHSEO), every time a user clicks, their search popularity rankings, and associated ad revenue, goes up. Even if the user doesn’t fall for installing a “free premium .mp3 player” (laden with malware) or some such because they’re the “lucky one thousandthviewer” of the website, the scam website still makes money by cashing in on the traffic.

And many users might be convinced to download a premium, java-based player, with free malware as a bonus.

But to recount, this scam (so far) has attempted to send things that were blocked by ESET Smart Security, wanted to silently run questionable javascript on multiple pages, harvest my email address, along with physical address, age, sex, phone number, and get me to signify that I was over 18 years of age, and consent to the whole process. That doesn’t sound very close to free, it sounds like the beginning of a long string of nastiness. At that point, I went to my favorite reputable .mp3 vendor and purchased a great blues track from yesteryear for 99 cents, and decided to forego the personal information harvest “for free.”

Today I received the following message in my inbox, claiming to be from the Asian Domain Registration Service and warning me that the “eset brand” was in danger of being registered by a third-party.  Here is the message I received, which I’ve included in its entirety, except for a few bits:

Received: from mail.umail168.cn4e.com (mail.umail168.cn4e.com [117.27.141.168]) by [...].eset.com (Postfix) with ESMTP id 83EB18000B0;    Mon, 23 Jul 2012 04:26:56 +0200 (CEST)
Received: from ?????? (localhost.localdomain [127.0.0.1]) by mail.umail168.cn4e.com (Postfix) with SMTP id 4B426A2804E; Mon, 23 Jul 2012 10:26:34 +0800 (CST)
Received: from ?????? (unknown [114.97.226.112]) by mail.umail168.cn4e.com (Postfix) with ESMTPA;    Mon, 23 Jul 2012 10:26:33 +0800 (CST)
Reply-To: <richard@dcidc.a***>
From: richard zhang <richard@dcidc.a***>
To:
Subject: URGENT eset Brand Registration Confirmation
Date: Mon, 23 Jul 2012 10:25:48 +0800
Message-ID: <DreamMail__102548_82822228707@mail.dcidc.a***>
MIME-Version: 1.0
Content-Type: multipart/related; boundary=”—- =_NextPart_12072310232006281362145_001″
X-Priority: 1
X-Mailer: DreamMail 4.4.1.0
Disposition-Notification-To: <richard@dcidc.a**>
Return-Path: richard@dcidc.a***

Dear Sir/Madam,

We are the department of Asian Domain Registration Service in China. Here I have something to confirm with you. We formally received an application on July 20,2012 that a company claimed YDai Investment Ltd were applying to register “eset” as their Net Brand and some domain names through our firm.

Now we are handling this registration, and after our initial checking, we found the name were similar to your company’s, so we need to check with you whether your company has authorized that company to register these names. If you authorized this, we would finish the registration at once. If you did not authorize, please let us know within 7 workdays, so that we could handle this issue better. After the deadline we will unconditionally finish the registration for YDai Investment Ltd.Looking forward to your prompt reply.

Best Regards,

Richard Zhang
Head of Registration Department
Tel:+86-551-3434624 || Fax:+86-551-3434924
Address:No.99 JiuHuaShan Road,Hefei,Anhui,China

If this sounds the least bit suspicious, well, there’s a reason for that.

There’s no scam like an old scam.

This is a repeat of the Asian ccTLD domain registration scam which we have discussed over the years and I last blogged about back in March 2010 as The Return of Jacques Tits—a scam which was, at least three years old when I wrote that article.

The scam has not changed much over the years.  The scammer reports that someone is attempting to register your domain name in a different part of the world using country- and region-specific top level domains.  For example, ESET.CN for China, ESET.CO.JP for Japan, ESET.ASIA for the Asia Pacific region and so forth.

In this case, the scammer has made a few small changes to the content of their warning message, using a new company name “Asian Domain Registration Service” for their organization, a fake  name for the company trying to register my domain name in Asia, and putting the address of their web site in a picture; techniques have been used by spammers for many years in order to slow detection of their messages by antispam engines. They also no longer include the actual domain names in the body of the message, perhaps realizing that many of them may now be in use, or perhaps because it creates additional work for them. The scammer’s actual web site, though, has remained largely unchanged over the years. This makes sense; aside from the image-based link included in the email, it it not referenced in detail until the time comes for the “payment” from the victim.

Scam Mechanics

How does the actual scam work?  By abusing the trust or the recipient.   If I were to reply to the above message, “Richard Zhang” of the “Asian Domain Registration Service” (or whomever in the organization behind the scam is monitoring the mailbox) would notify me that unless I register my domain names with them for a fee, they will be given to the other party.  I might even have to participate in a fake bidding war against the imaginary company trying to register my domain names.  If I ask for the contact information for the company trying to register my domains, I will be told it cannot be given out “for privacy reasons.”  And, of course, since it is a fictitious company name, I will not be able to find it by searching on it.

All in all, it’s a simple way for a scammer to take someone’s money:  They don’t have to write any malicious software, hack into any systems or have any technical expertise beyond running a real domain registration business.  They simply use social engineering techniques to trick you into registering domains with them that you do not need, do not use and no one else is buying, either.

Countering the Wily Domain Registration Scammer

The techniques to counter social engineering-based scams such as this fake Asian domain registration scam remain unchanged since I blogged about them in 2010 and reprinted, below.

1. If, despite all of the warning signs, you feel for some reason that the message might be legitimate, open a new instance of your web browser, visit your favorite search engine, and type in the same of the domain name registrar along with keywords such as hoax, scam and spam. For example, if the domain name registrar is named “Worldwide Network Services” then you should type in “Worldwide Network Services + spam” for your search terms.
2. The scammers behind these types of messages often make small changes to them in order to make it more difficult for anti-spam tools to detect them. If the messages did not get sent to the spam folder in your email client, be sure to flag them as spam to help better classify them in the future.
3. Review what email addresses are made available on your web site, including old press releases and downloadable documents. It may be those addresses no longer need to be displayed, could be obfuscated better or replaced by a contact form.
4. You should never reply to messages sent by scammers. By replying, you let them know that not only have they found a valid email address at your company but that they can also send you additional emails and share your email address with other scammers.<br >[Source:  ESET Threat Blog.  The Return of Jacques Tits,   March 30, 2010.]

By far, the most effective countermeasure against such scammy, scummy business is to educate yourself about how such scams work, and if you come across them in the future, to simply ignore them.  These scammers prey on the unwitting by making their sales pitches sound like a legitimate business communication.  As soon as you understand what their scam is, you can defend against them using the best means possible:  The delete button.

For more reading about domain registration scams, please see the following earlier ESET Threat Blog articles:

• The Tits Alternative [March 3, 2009]
• There’s more to Jacques Tits Than Meets the Eye [March 17, 2009]
• About the Domain Scam, etc. [March 17, 2009]
• The Return of Jacques Tits [March 18, 2010]

My colleague David Harley reports seeing this scam as far back as 2004, which makes this scam eight years old, at least. It also points out the difficulty in combating social engineering, which attacks people instead of computers.

Regards,

Aryeh Goretsky, MVP, ZCSE
Distinguished Researcher

Have you received a fake domain registration scam?  If so, who was it from, and how did you response?  Please let us know in the comments, below.

Blackhat keynote speaker Shawn Henry, the former executive assistant director of the FBI’s Criminal, Cyber, Response, and Service Branch, opened up the day after opening remarks from Jeff Moss, founder of Blackhat. Moss wondered if now was the time for the cyber-security sector to take a more aggressive/offensive approach. Jeff mentioned working for a former employer years back, a firewall manufacturer who had a product that would launch specially crafted code in response to an attacker, sort of an early offensive DoS attack. This was an early attempt by security professionals to cause pain by going on the offensive methods.

But since DoS attacks aren’t exactly a legal offensive tactic nowadays, what to do? He recommends civil action, a la recent Facebook actions where attackers were sued in civil court. But what happens when attackers are overseas? Mr. Moss is hopeful that responding in a civil manner would “encourage” other countries to implement legal protections in place to stop current and future attack attempts abroad.

What can we do besides sue? Mr. Henry proposes advancing technologies like deception, network decoys and other trickery, along with heavy network segmentation as a possibility to turn the tide. He also pushes for more legislation that would make tactics more effective at nabbing bad actors. But this sort of legislative pressure is famous for riling up privacy pundits, who are sure to respond with counterpoints to perceived privacy erosion. Still, he argues current laws are archaic and do not allow adequate response to the current threatscape.

In the meantime, Mr. Henry says today’s headlines reflect only seeing a tiny sliver of what is actually happening, attack-wise. Companies, he said, vastly under-report hacks, and in fact the FBI frequently has the dubious honor of notifying companies that they have been breached after their private data has been found in the public domain during other investigations.

To give an idea of the total size of attacks, Mr. Henry estimates close to 90% of the REAL attack activity is happening in the classified environment, sort of “below the water line” to use an iceberg analogy. This means we are only seeing a tiny slice of an even tinier slice of the real threat, to use his characterization.

He calls the Internet a great attack equalizer, allowing any of the billions of Internet users to plan and possibly launch an attack, and paints this threat theater as one of the top threats faced in the world today, aside from WMD. And Internet threats are far easier to carry out than deploying Weapons of Mass Destruction.

But all attacks aren’t created equal, the motivations vary. If, for example, a company you plan to do business with has conducted network exploits against you, they may already know what kind of financial position you are in, what intellectual property you really have, and would therefore be in a much stronger negotiation position, possibly tilting the tables heavily in their favor. Mr. Henry compares this to taking a test where you already know all the answers, and therefore are HEAVILY favored to win.

What does he recommend? First he tries to glean wisdom from more tradition physical attacks and adapt them to the attacker.

These include:
1. Denial and deception – Keeping the attackers out of your core network by sending them on wild goose chases using network tricks
2. Decoys – Serve up fake information, designed to foil attempts to gain intelligence, sort of poisoning their intel, and helping them along with same wild goose chase
3. Raise the network defense bar – cause them considerable pain (and the cost of buying more advanced tools), make them spend months of effort trying to get in
4. Heavy use of defense-in-depth tactics – don’t put all the “crown jewels” one level deep from the perimeter, but make attackers have to penetrate multiple levels
5. Log everything you can – This will help greatly when trying to find a “smoking gun” during an investigation. This means both inbound and outbound traffic, and especially watch for abnormal outbound traffic, a telltale sign something bad is happening.

Will it be enough? These steps will certainly raise the bar of difficulty for people attacking companies, and therefore raise the cost to the attacker, which is a major factors when an attacker picks a target. If the costs become too high, they may go elsewhere or give up. They may also pick an easier target to exploit, and your company would be out of harm’s way.

But tactics change, and so does the threatscape. And if the last several years are any indication of what’s yet to come, hang on for a wild ride. Also, the old boxing admonition to “protect yourself at all times” certainly still applies.

In one of my previous blog posts I described the bootkit functionality included in modifications found in new Rovnix.D samples (Rovnix bootkit framework updated). However, further detailed analysis uncovered some interesting updates to the code injection technique employed. During the Rovnix.D code analysis process we found algorithms for multiple code injections with a range of payloads. In previous versions Rovnix worked with a single payload, and the Rovnix developer concentrated on the sales framework for that specific payload. In the new version we see multiple code injections into user-mode processes launched from hidden storage, opening up more ways  in which the botnet can be leased. But right now we aren’t aware of large botnets based on Rovnix.D, and the C&C indicates that the number of currently active bots is 8,417.

This C&C really seems to be much the same as the test panel for Carberp versions with bootkit functionality (Evolution of Win32/Carberp: going deeper). The small numbers of active bots suggest that the botmaster is not currently using an effective scheme for distributing the new Rovnix.D modification, and may be searching for a buyer or testing the botnet for future leasing. The communication interface with infected machines has two options: one to update the configuration file, and one to send a new payload to an infected machine. In the control panel this functionality is displayed like this:

The control panel interface seems basic and even incomplete, because at this moment only minimum functionality for controlling bots has been implemented. In the next part of this blog I am going deeper into technical details with code injection process.

Code injection technique

The structure of _PAYLOAD_CONFIGURATION_BLOCK has already been described in one of our previous publications about the Rovnix bootkit (Rovnix Reloaded: new step of evolution). The payload configuration block is stored in the malicious driver module right after the section header. In Rovnix.D the marker for the beginning of payload configuration block was changed from “JFA” to “JF”.

[Rovnix.D variant (left)  and Rovnix.B variant (right)]

Before the injection of a new or additional payload, as the first step the malicious driver parses the payload configuration block. The code for this action looks like this:

The full call graph for extracting the payload routine from the malicious driver is presented here:

 The ExtractPayloads() routine extracts the payload after driver initialization stage, but itworks with an encrypted payload already stored in the malicious driver. Rovnix.D is able to downloading other payloads and install them into hidden storage for multiple injections into user-mode processes.

A list of payloads for injection is kept in the configuration file INJECTS.SYS, itself in the hidden storage partition. The current version of the malicious driver sees the release of support for a full cycle of operations using the hidden file system (FAT16 modification):

• Create file
• Read/Write file
• Request file information (size, time of creation and etc)
• Request file access information

At this moment functionality for working with directories is not supported and always returns the status STATUS_NOT_IMPLEMENTED.

The payload can send requests to the malicious driver using the DeviceIoControl() function with the following codes:

• 0x8E040 – request information about file system
• 0x8E0C0 – add new payload to hidden storage
• 0x8E100 – add/delete inject of payload to/from context of active user-mode process
• 0x8E080 – execute other malicious driver from hidden storage

The reconstructed double-linked list with payloads has a structure like this:

For payload injection, mechanisms are used based on a queue of asynchronous procedure calls and looking at the list of payloads when creating a new process (code injection technique based on PsSetCreateProcessNotifyRoutine() callback). A call graph of functions in the process injection workflow is presented in this flow graph:

The code of function QueueAPC()decompiled from the malicious driver looks like this:

So the malicious payload can communicate with kernel-mode components and send the buffers with new components to the hidden file storage for the following injection into user-mode processes or for loading a new unsigned driver.

Decompiled code for implementing code injection via themalicious driver using the buffer received from the user-mode payload looks like this:

The algorithm for injection can check names of processes for the injection to follow and uses different process names for the injection of different payloads.

Rovnix is a really interesting bootkit and this is not the end of the story. We continue to track new samples and to reverse-engineer Rovnix components. Eugene Rodionov and I will be disclosing more details in September, in our presentation “Defeating anti-forensics in contemporary complex threats” at the 2012 Virus Bulletin conference at Dallas.

Special thanks to my colleague Maxim Grigoryev.

Aleksandr Matrosov, Security Intelligence Team Lead

If your organization’s website runs on Apache, and many do, you might wonder if the webserver’s .htaccess controls are securely configured. If you believe the demo we saw yesterday at Blackhat by Matias Katz and Maximiliano Soler, the answer is a resounding ‘NO!’ What Katz and Soler described in their session is not some rare “corner case” hack that could only possibly occur in a lab with billions of automated attempts, this is easily testable in the real world, and the tools to exploit it are freely available.

It turns out that Apache, the most common web server in the world, has an arrangement where it hands off PHP-based requests within .htaccess to PHP itself, which has been working fine on millions and millions of websites for years. But with .htaccess, you can specify WHAT requests get sent to PHP to try to interpret. The usual methods are GET and POST, but if you feed the .htaccess process some non-standard input, PHP automatically (unless otherwise instructed) treats it as a GET request, and allows the utility to start saving the PHP files on a webserver to your local filesystem.

Then it gets worse. Once the process has identified links buried in the files it just saved, it goes hunting down those links, requesting to save them all. It also checks to see if it already saved the file that the link points to, and in this way, won’t download duplicates, keeping the fileset fresh.

But wait, there’s more. After it saves all THOSE linked files, it scours them as well, searching for files located wherever THEY link to, and so the process goes. With so many pages linking to other resources, it’s easy to see how a bad actor can pull down all the PHP files that run the site. These may well contain references to login credentials for databases, passwords, personally identifiable information, and a host of other goodies that be sold on the black market or used to enable further exploits.

Want to protect yourself? Turns out you can get very specific in your .htaccess file about why types of requests get handed to PHP by using the “LimitExcept” directive instead of the more commonly used “Limit”. You can also fix the issue within your PHP code as well.

So, now might be a good time to check your website configuration to make sure you’re protected, before the bad guys go scouring around trying to use this type of exploit. And if you’re not the person in charge of your website, you might want to point out this problem to the person who is, they may thank you, a lot.

After my colleague Stephen Cobb stood in a huge line at Defcon waiting to get into the Friday keynote by NSA chief General Alexander, plus a swarm of interest shown at the two-part “Meet the Fed” panel presentation the next day, it’s becoming clear that multiple agencies of the federal government are focused on hackers, and vice versa. But to what end?

There seems to be considerable effort underway to get aspiring hackers to take the straight and narrow path, maybe offering them a career path as a reward if they’re monetarily motivated (but not the kind of money that might land you in jail one day). That could be a good thing, helping hackers to one day move out of their mom’s basement and buy their own hacker cave/house to raise offspring. Yet there seem to be tensions in this Fed/Defcon connection.

Ever since the first “spot the Fed” contest at Defcon nearly two decades ago, there’s been a certain amount of unspoken intel work going on at this event; well, sometimes it’s spoken too, after all this IS Defcon, a haven for the hackerly unkempt celebrating hacker culture, which isn’t always sanitized for public consumption. Speaking of consumption, at Defcon it’s not considered socially unredeeming to feature beers on the podium as you present, and if people raise issues during your presentation, you can self-penalize by taking successive drinks. Some presentations gain more and more “flavor” in this way, especially as the day progresses. And more than one speaker has done presentations with voice hoarse from doing who-knows-what the night before, so the lubrication can be helpful. Liquid penalties were also assessed this year for the use of “cyber” too many times in a presentation.

So, are the folks who feel at home at Defcon really going to blend in if they get an office at a federal agency? After all, the same event that hosted the head of the NSA also hosted a seemingly credible panel on the large-scale, warrant-less wire-tapping that the agency is accused of carrying out, including the person widely-acknowledged as being the world’s leading expert on the NSA, James Bamford.  There’s always been a sort of pseudo-spy sensibility to Defcon, but also a keen interest in protecting privacy. Now the Fed is here recruiting, we’ll see how it goes.

In the meantime, I can report that NSA’s booth space was heavily frequented, so at least the dialog is out in the open. After all, if Shawn Henry’s talk at Blackhat was a foreshadowing of things to come, various federal entities, from the army to the FBI, are VERY interested in talking to hackers, with or without the neon spray-painted mohawk they got at Defcon at the MohawkCon booth (where you can design your own mohawk variation that they install on the spot – very hacker vogue). But in the spy vs. spy world, hackers – even with dubiously constructed mohawks – are taking center stage.

Not having been at Blackhat and Defcon, I probably wouldn’t have paid much attention to Jonathan Brossard’s paper Hardware backdooring is practical if Kevin Townsend hadn’t called it to my attention – his subsequent article for Infosecurity Magazine Rakshasa: Hindu demon – and permanent, undetectable backdoor includes some of my thoughts on the topic, but I might as well comment a little further. I don’t see why Stephen and Cameron should have all the fun.

There has been persistent conjecture regarding the possibility of ‘hardware backdooring’ for as long as I’ve been on the fringes of this industry, and certainly before I had any kind of reputation to risk by joining in.

Well, it isn’t news that you can do something unexpected by gimmicking the BIOS at source: I have particular reason to remember the ‘Welcome Datacomp’ “virus”. Those words appeared in documents created by Mac users without the user having typed them. That ‘joke’ was hard-coded into the ROM of a 3rd-party Mac-compatible keyboard – I believe the company involved was Sicon. (I don’t know how many of those keyboards were affected, but there were quite a few reports in the early 90s.) Trivial though that was – though if you found yourself obliged to go back and get a keyboard that hadn’t been trojanned, I’ve no doubt  it was extremely annoying – it made the point about ‘hardware backdooring’ quite effectively a long time ago.

Maybe the real point there is that if you’re feeling paranoid about hardware, you shouldn’t necessarily source it from other countries purely on the basis of how cheaply they can produce it. At any rate, not unless it’s a state you trust implicitly, and it doesn’t seem to me (as an outsider) that the U.S. trusts China that much, or is that sure about its closest allies, come to that. Well, international politics isn’t really my area: let’s stick to hardware backdooring.

If you control the early part of the supply chain, you may never need to mess about with after-sales infection: however, the wide range of manufacturers provides some defence against that: you can’t gimmick hardware if you don’t have any access to/control over its components at any point during the supply process. So what about post-supply infection/compromise?

Bootkit technology, as discussed in the paper as a possible source of compromise, is by no means completely irrelevant, but you can actually go back a lot earlier to CIH (later and irrelevantly known as Chernobyl) for an example of real malware with a payload that involved writing to a flash-able BIOS, though it didn’t attempt to cover all possible Flash ROM chips. It was claimed to have affected tens of millions of machines, and I guess it influenced the number of machines built subsequently with the BIOS protected by a hardware switch. It’s a long step from trashing a PC BIOS (as CIH did) to using multiple device/peripheral firmware to run a botnet, but never say never. I can see potential for mischief here, but it’s not as simple as the paper makes it sound. It wouldn’t surprise me to hear that covert agencies are looking at this sort of approach for highly targeted operations, but I don’t think it’s likely to emerge as a global epidemic. After all, the malware he’s describing may be ‘ultra-stealthy’ once installed – though I’m never convinced by words like undetectable and unremovable – but it still has to jump through the usual hoops before it gets to a clean system.

David Harley CITP FBCS CISSP
ESET Senior Research Fellow

From the very beginning of our analysis of Win32/Flamer it was clear that this was an extremely sophisticated piece of malware which we had never seen before. It implements extremely elaborate programming logic and has an intricate internal structure. At the heart of Flame’s modularity lies a carefully designed architecture allowing all its components interoperability without causing any incompatibilities. In this blog post we will concentrate mainly on the internal architecture of the mssecmgr.ocx module (Flame, Duqu and Stuxnet: in-depth code analysis of mssecmgr.ocx). In the course of our research we analysed several different versions of mssecmgr.ocx and found specific architectural similarities that allow us to reconstruct Flame’s framework.

Flame framework

Flame’s main module consists of objects that each implement specific functionality: gathering information on the compromised system; infecting other computers; communicating with C&C, and so on. These objects are split into certain groups according to functionality and are managed correspondingly. The objects belonging to specific classes are inserted into a vector – that’s a C++ STL (Standard Template Library) type, not an infection vector – as shown on the diagram below:

Figure 1 – Flame Framework diagram

 Here is the list of different types of objects implemented in mssecmgr.ocx:

• Command Executers – these objects expose an interface that allows the malware to dispatch commands received from C&C servers;
• Tasks – objects of this type represent tasks executed in separate threads that constitute the backbone of the main module;
• Consumers – objects which are triggered by specific events (creation of new modules, insertion of removable media and so on.);
• Delayed Tasks – these objects represent tasks which are executed periodically with a scheduled delay.

The set of objects described above constitute the Flame framework. The approach looks very similar to a “Command” object-oriented design pattern. It is worth mentioning that Stuxnet and Duqu made heavy use of lists (another C++ STL type) to manage objects. Flame, however, relies on vectors.

During our Flame analysis we found out that different versions of the malware’s main modules implement different framework objects in all vectors, as reflected in the two tables below.

Table 1– Command Executers Objects in different version of mssecmg.ocx

Table 2 – Tasks objects in different version of mssecmg.ocx

From the tables above it is evident that the malware has evolved over time and its functionality has been significantly extended. Some components that may have been implemented previously as separate modules are incorporated into the main module by later versions.

Flame tasks

Task objects implement the general functionality of the framework. There are two tasks (among others) that exist in every version of Flame main module,:

• IDLER task
• CommandExecuter task.

The purpose of the IDLER task is to handle delayed tasks. It runs periodically through the delayed tasks vector and executes its elements as shown in figure 1.

The CommandExecuter task is responsible for retrieving and executing commands from the malware’s configuration information using objects from the corresponding vector:

Figure 2 – Command Executer Routine

Flame consumers

Consumers constitute another set of objects implemented in the Flame framework. These objects are inserted into the corresponding vector during initialization and are triggered when a specific event happens. Thus, Flame designers employ an event–driven model that allows Flame to achieve certain goals. Since the malware is intended for gathering information from the infected system this architecture is very efficient. Consumers such as the following are implemented:

• process consumers – these are notified when an application is run;
• volume consumers – these are notified when a new volume appears in the system;
• removable media consumers – react to removable media events;
• mobile devices consumers – react to mobile device events;
• consumers for Bluetooth adapter etc.

When an event takes place on the system a specific trigger is created which fires the corresponding consumer, which in turn takes an appropriate action: infects media, copies files from removable media, activates a Bluetooth adapter, and so on.

Executing commands

Command executers are responsible for handling commands received from C&C servers. These are objects that implement a specific interface described below:

The CommandExecuter task is responsible for handling commands received from C&C server. The commands are stored in a special repository within the Flame configuration information under the key CMD_QUEUE:

Figure 3 – Executing commands

The commands are formatted as compressed binary data. While decoding the commands Flame decompresses the data and splits the commands into blocks. Each block is handled by a specific command executer object identified by its own ID number. The screenshot in the figure below presents the interface of a command executer object:

Figure 4 – Interface of command executer object

Once the command executer is identified the CmdExecuter_Dispatch method is called to handle command information. Different command dispatchers are able to accomplish different actions. For instance the DbQuery command dispatcher is used to execute SQL queries to the SQL Lite database maintained by the malware.

Finding commands

Commands may also be stored in files in specific directories for which the malware scans. There is a special task object CommandFileFinder whose purpose is to look for files in specific directories and load the contents of these files into the command data repository stored in configuration information. This helps the malware send commands to the machines that don’t have a direct connection with C&C servers.

SQL Lite database & Lua

As already pointed out Flame uses a SQL Lite relational database to store all the information (sKyWIper (a.k.a. Flame a.k.a. Flamer)) it gathers on the infected system as well as supplemental data which facilitate Flame’s propagation within a targeted system. In the figure below you can see the database schemas reconstructed in the course of research with a brief description:

Figure 5 – Flame database schema

Figure 6 – Flame database schema

Another interesting feature of the Flamer malware is the use of the LUA scripting engine to perform certain supplemental operations. The following table summarizes information about different scripts extracted from Flame configuration information.

 Special thanks to our colleague Maxim Grigoryev.

Eugene Rodionov, Malware Researcher
Aleksandr Matrosov, Security Intelligence Team Lead

For years scammers and hackers focused largely on Windows x86-based platforms, in many ways because that’s where the bulk of the users were. But times change, and new targets emerge. At Blackhat and Defcon last week we saw a flurry of talks on Mac OSX/iOS security, trying to illuminate possible chinks in the armor.

From proof-of-concept hacks on the boot loader sequence (EFI), where rogue drivers could potentially be hooked into and used to wreak havoc on OSX, to firmware flashing and other low level hacks, running the gamut to app security, and kernel heap as well, the spotlight squarely focused on Mac OSX and iOS. A few years ago Mac sessions were far more rare, so does this mean the age of Mac hacking has arrived?

Well, it depends. It seems Mac has done a better-than-average job of protecting it’s OS stacks, so it’s not going to be a piece of cake. In the talk on hacking the bootloader, it was clear that this isn’t just plug-and-play, there’s definitely some heavy-lifting. And Mac OSX is based on underlying BSD, which has a quite enviable history of minimal security problems, sometimes weeks or months pass between security updates. Not so with many other OS’es.

One hack proof-of-concept involved hacking firmware…which resulted in bricking the device in the presenters experiment, less than a happy ending to be sure.

But what about things that are added to the base OS for additional functionality? Java has been particularly problematic in the past few months due exploits, which we mentioned here and here. And if you use iOS or OS X, but download an app that has problems, does that mean the underlying OS is the culprit? Not really, but it represents a problem in the end user’s perception. This is simply a case of the add-ons adding more than a user bargained for (one reason why more Mac users are now running antivirus and antimalware to augment the defenses baked into the OS).

And don’t forget that phishing scams and a host of other web/email-based nastiness can still happen on a Mac/iOS platform, but that’s really user education. And the user continues to be the champion in the race of problem creation, regardless of the platform, Mac/iOS or otherwise, so that’s nothing new.

What may be new is that users may become aware that they should continue to keep their guard up against scams, regardless of the platform. In other words, you shouldn’t ignore security awareness in any computing environment, but blaming Mac/iOS feels too convenient, when there’s a very good chance the problems lie elsewhere.

Still there’s an awful lot more hacker focus on the Apple platforms, including toolsets, test suites, defenses and other coding energy. Will this turn into scams that exploit these operating systems? Stay tuned and we’ll see what happens in the next year.

Virus Bulletin’s Martijn Grooten has drawn my attention to a couple of interesting and highly relevant articles on the ongoing PC support scam issue, where someone calls you to tell you that you have a virus (or some other system issue) and offers to provide technical support (for a fee…) Martijn and I, along with Steve Burn and Craig Johnston, have been doing a lot of writing on this recently.

Firstly, Brian Krebs returns to the theme with his article Tech Support Phone Scams Surge: he summarizes a number of scam attempts that have been reported to him.

In one instance, an 11-year-old was persuaded to enter some numbers into the Run window. My guess is that the number in question is was probably a unique code to enable the scammer to get remote access through ammyy.com or something similar.

According to Krebs, his reader assumed the machine was compromised and would need to be reformatted. That is, I guess, a rational assumption, though in general the reports I’ve received suggest that scammers usually upload legitimate (but free and irrelevant) software rather than malware. On the other hand, as I reported in a recent blog, I have a reliable report of a scammer trying to install an (unknown) web link as a startup shortcut. Since it would be unusual for an 11-year-old to have a credit card or a PayPal account, it’s possible that the scammer intended to leave some kind of backdoor access in the hope of establishing a more profitable contact later. However, it also occurs to me that a scammer might also try to leave some kind of access available on the victim’s machine so that they can come back for another helping. However, I don’t have information (apart from my conversations with Chris Hamer) as to whether such a compromise may have taken place, or as to how it might be implemented.

Krebs also includes reports suggesting that old people are being targeted. I’m not sure to what extent this is a deliberate strategy, since it’s not clear how much information the scammers really have about their intended victims: quite a few of the many scammers who’ve called me are clearly using an outdated directory. However, it’s clear that many types of scam are perpetrated by people who regard older people as easy prey, and I’ve blogged elsewhere an experience of my own with a scammer who assumed that I was even older than I am, and that my presumed advanced age meant that I was both lacking in technical knowledge and easy to intimidate.

Kaspersky’s David Jacoby has also recently put up an article relating his own experiences. While there’s not much there that will be new to people who’ve been following this thread on ESET’s ThreatBlog,  it’s a good, comprehensive article that addresses two issues of particular interest to me. Firstly, he confirms that the Task Manager ploy I reported here a while ago was by no means a one-off. (That’s where they tell you that your CPU usage should be at 80-90%, and the fact that it’s only registering at 3% means that all your CPU cycles are taken up by the malware. It’s total rubbish, of course.) Secondly, he reports a new gambit (new to me at any rate) involving the misuse of a system utility (in this case, VERIFY). I thought it was worth expanding a little on that trick here.

As you can see from the minimal helpscreen shown in the screenshot, VERIFY is used (not very often, I suspect) as a check that files are being written to disk correctly. Unlike INF and PREFETCH, which will let you type any old rubbish – such as ‘INF number of virus infections’ – and simply ignore everything but their own names (see my article Support Scammers (mis)using INF and PREFETCH for more information on how those utilities are misused), VERIFY will put up an “incorrect parameters” message if you try to type in something like ‘VERIFY Microsoft Licence”. However, if you type it in with no parameter, it will simply tell you that ‘VERIFY is off.’  This just means that file-write verification is turned off (the default setting). According to Jacoby, however, the scammers tell their victims, however, that it means that your Windows licence (or something of the sort) isn’t verified, so that security patches can’t be applied. But of course, this and all your other problems can be fixed for a not-so-small fee.

VERIFY exists, as far as I know, in all current versions of MS-DOS and Windows. It may be worth knowing, though, that running just about any DOS command with the /? parameter will put up a helpscreen like this to tell you what the utility really does and how it works. It won’t work with the INF or PREFETCH utilities, though, which are not recognized at the command-line, but does work with ASSOC, which is often misrepresented as indicating a licensing problem. While EVENTVWR (Event Viewer) is recognized at the command line, the /? parameter is disregarded: it just runs the utility, which is also misused by claiming that it shows malware or critical system errors.

I don’t advise that you waste time on this kind of call: the circumstances under which Microsoft might contact you about a malware issue are very limited indeed. And I certainly don’t advise that you  let anyone connect remotely to your system unless you know exactly who they are and why they’re doing it.

Still, it might be useful to you to know which utilities are currently being misused by scammers, and how to use the command line or the Help and Support option on the Start button to check out what a utility really does, if only so that you can advise other people.

David Harley CITP FBCS CISSP
ESET Senior Research Fellow

Part of my daily routine here at ESET is to inspect URLs for new trends and malware campaigns identified by our systems. A couple of weeks ago I noticed a group of URLs with a similar pattern. When I investigated further, I found out that the URLs pointed to copies of legitimate web sites with a malicious Java applet embedded in them.

As an example, the following screenshot compares the original web site—in this case, the home page for the popular game RuneScape—side-by-side with its copy. The large gray portion on the copied web site is due to the fact that the Java applet was disabled when the screen shot was taken.

When examining the HTML source code of the copied web sites, I found comments in them stating that the earliest ones had been copied with HTTrack, a popular open-source tool used to save web sites for offline reading. In later instances, the comment had been modified to read “FoxxySF Website Copier”. It was a bit surprising that the person behind this took the time to modify the comment as opposed to removing it altogether.

A malicious script and Java applet were added to the copied websites. This, in and of itself, is nothing new:  Self-signed Java applets have been used for a while now to install malware on computers. Using a copy of the RuneScape website, though, is actually a well-thought-out strategy as the game itself is a Java applet and so users may well be accustomed to seeing Java security dialogs and fall for the trick.

The malicious script was trivially obfuscated and contacted a hit counter hosted on a server at another domain to keep track of the number of visitors to copied web sites.

Upon execution, the Java applet would download a malicious executable hosted on various file hosting services and launch it. When decompiling the applet, I found out that the author used HelloESET  as the name of a function.

After successfully executing the downloaded file, the applet also performed a callback to the same domain as the script previously mentioned. That domain seemed like an interesting candidate to continue my analysis.

Introducing FoxxySoftware

When visiting the domain in a web browser, I was surprised to discover that it was hosting a website selling access to a malware-distribution service.

The website contained a comparative of the features in the different versions of the product, mentioning malicious features like “website cloner”, “auto spread”, use of packing and scanning with antivirus software to ensure files are not detected prior to distribution. The description even blatantly stated “FoxxyJava will allow you to quickly and effectively download an application onto a users computer without complication or frustration”.

The website even had a blog and in one of the articles the developer complained about detection by our product. The funny thing is that we were not tracking this malware before I started looking into it (which was after he posted his complaint) and we definitely never had an account there.

In addition to the pseudonym used on FoxxySoftware’s blog, I also had email addresses and other information gathered from the WHOIS entries for the domain names. My next step was to check and see what additional information I could find linked to these.  This is often complicated and time-consuming because malware authors and online miscreants typically take precautions to not leave too much information about themselves behind and to keep their personal life separated from their malevolent persona. Not this time.

Meet JHFIRE

The first things I found were posts on hacking forums where our new friend was advertising his product, which is quite common and not unexpected. I also found older posts using the same pseudonym and style of language where he boasted about using cheats in online games. This is possibly how JHFire started his hacking “career.” Looking around further, I discovered that he even had Twitter accounts where he advertised his product.

He also posted a question on the programming forum StackOverflow, asking for help with a piece of Javascript code.

He also complained on the Dropbox forums about their application programming interface (API) which he used to download the malware executables onto victims’ computers.  I would like to point out that Dropbox was unaware of this abuse of their system and responded promptly and professionally when we notified them.

On Web of Trust, a service that allows users to classify websites as safe or dangerous, he even complained that his website had been flagged as malicious.

He also commented on an article in Kaspersky’s blog complaining about their explanation of a “drive-by” download.

I also found a YouTube account. Amongst the videos he posted, there is one called “Hacking a Hacker” were you can see a name appear for a brief moment on the Windows Start menu. Oops.

Searching for one of the email addresses extracted from the WHOIS entries returns the same name on Skype.

Conclusion

While there is a humorous side to this case it illustrates a somewhat troubling trend which is the commoditization of malware services.  Services such as automated packing, scanning to verify evasion of current antivirus signatures, preconfigured exploiting servers, renting of botnets for spam distribution or denial of service attacks; pretty much everything cybercriminals need can be paid for and used with a few clicks. And while most of those services are advertised in “underground” forums, the fact that we are seeing more and more of them with public websites posing as legitimate businesses is a cause for concern.

It is also difficult to get these services closed, even in evident cases of abuse like this one. We contacted the registrars and webhosts used by FoxxySoftware with limited success—the website is still accessible at the time of publication[1].  We strongly caution you against going there as it is a perfect target for malicious content.

[1] We want to thank Dropbox and PublicDomainRegistry for quickly taking action after we contacted them.

Another day, another support scam call. It appears that one of my PCs has been sending out messages to India again about system problems. I don’t know why it would rather talk about its problems to a call centre in Uttar Pradesh rather than just pop up an error message to me. Does it feel I’m working it too hard?

‘Anna’ claimed to be from Global PC Helpline, and gave me a UK phone number 0800-0148910 which does indeed correspond to the Global PC Helpline page for the UK at http://globalpchelpline.com/uk/. She also told me that my PC was sending out messages about system errors, and tried to pull the CLSID gambit on me, then put the phone down when she realized I wasn’t buying it and tried to get her to tell me what she thought the ASSOC program really does.

While this was clearly a scam call, I can’t, of course, prove beyond all doubt that she was calling from Global PC Helpline, and in fact Caller ID was disabled.

However, after taking a quick look at the GPCHL website, if they’ll excuse the familiarity, it includes some interesting features. While the company is claimed to have been founded in Magnolia TX in January 2009, whois data are not entirely consistent with that claim:

Anna also told me she was in India, when she was still answering my questions.

The site claims, among other services, to offer support for a number of well-known antivirus products. I particularly liked the first sentence of a section on support for McAfee products:

Our certified technicians provide you immediate help and best possible solutions for Norton Antivirus.

I’m not sure whether that means that McAfee and Symantec are closer friends than anyone realized. Or does it mean that McAfee detects and removes Norton? Perhaps the AV industry is more competitive than I’d realized.

The site has a number of more serious problems:

• unfinished stub pages (I can’t wait to find out what Smart Phone Support is, unless it turns out to be Anna, in which case there may be a Trade Descriptions issue)
•  invalid security certificate messages
• a Facebook page that claims it was founded in Foley TX. Not exactly round the corner from Magnolia TX.

Any Texas Rangers reading this who can help this confused company sort out its real location?

David Harley CITP FBCS CISSP
ESET Senior Research Fellow

Sharing details of the hack that “wiped his life” has earned Mat Honan a place in the annals of information system security; the specific inter-dependence of flawed authentication systems that cost him so dearly–encompassing Apple, iCloud, Amazon.com, Gmail and more–would probably still exist if Mat had not gone public. Wired has the full story here for those who have not been watching it unfold on Twitter.

As news spread last weekend about how much of Mat’s data the hackers had wiped out–by social engineering Apple Support into wiping his iPhone, iPad and MacBook–the company quickly moved to suspend over-the-phone resetting of Apple ID passwords. Amazon also reacted and, according to a follow-up report in Wired: “handed down to its customer service department a policy change that no longer allows people to call in and change account settings, such as credit cards or email addresses associated with its user accounts.”

Problem solved? Not really

While it is now impossible to replicate the exact hack that wiped Mat’s life–which is some comfort, I suppose–it is entirely possible that there are other ways to exploit weak links in authentication methods currently used by separate but inter-twined information systems. Based on several decades spent observing patterns of system abuse, I would say it is extremely likely that a. more hacks like this are possible, b. more people than ever are looking for them right now, c. not all of those people have honorable intentions.

In technical terms the online world currently suffers from an atrocious conflation of identifiers with authenticators (your phone number, email address, and Social Security number are identifiers, not authenticators). This situation is compounded by a widespread failure to implement shared secrets effectively (the name of your first pet is not a shared secret and asking for all the digits of my pin number is profligate and inviting of interception). Underlying all of this mess is an excessive reliance on single-factor authentication and an alarmingly widespread misconception that multiple authenticators = multi-factor.

Multi-factor authentication refers to the three factors: A. Something you know, like a password; B. Something you have, like a physical key, C. Something you are, like your face or your fingerprints or the veins in the palm of your hand. Asking me for two or three or more pieces of information that I know is not multi-factor authentication. Why large companies with big research budgets get things like this wrong is hard to fathom and it strikes me as unfair to force consumers to become security experts just to safely navigate services for which someone is paying (either the consumer themselves or the people paying for ads on ad-supported sites or within ad-supported apps and services).

The challenges of restricting access to online data and services are compounded by the shift to email+password for authentication instead of username+password (a person’s email is easier to guess or discover than a non-public username). Then there is the apparent inability of some organizations to keep passwords from prying eyes. As previously reported, millions of passwords were disclosed in June alone, from LinkedIn, eHarmony and Last.fm. Last month more than 400,000 usernames and passwords were stolen from Yahoo, while the social networking site Formspring, clothing company Billabong, gaming site Gamigo, and forums at Phandroid and Nvidia, all suffered similar breaches.

I’m sure regular readers of this blog are getting weary of the advice to change passwords, choose hard-to-guess passwords, and use different passwords for different services. To that we may have to add: use different email addresses for key services that employ email addresses as account identifiers. We might also add: let you frustrations be known to the major online players. There are better ways to do authentication and we need to let companies know we expect better of them.

Aftershocks will likely continue

How much will this incident impede adoption of consumer cloud services in general and Apple’s iCloud in particular? Well, until authentication services improve, I don’t see many security experts recommending you trust your data backup to general purpose cloud services such as those offered by Google, Amazon, Dropbox, Microsoft, and Apple. The news for providers of dedicated online backup services such as Mozy and Carbonite may not be as dim. If your entire business model is backup you are likely to be paying close attention to how you manage it.

In the meantime, there is likely to be renewed interest in offline backup, things like USB hard drive (ironically an area in which Apple has excelled in the past–Time Machine in OS X is my personal backup of choice). Here at ESET we have definitely seen increased readership of the article Options for backing up your computer by fellow blogger Aryeh Gorestsky (11-page .pdf file).