Highlights of CanSecWest Day 2: Hacks Both Common and Sublime

Another day has passed here at CanSecWest with a mixed bag of results. Overall the content was, again, quite good, PWN2OWN shows us the future, HallCon and BarCon were all kinds of awesome, and I had two distinct “a ha!” moments.

My first “a ha!” came during DongJoo Ha and KiChan Ahn’s “Is Your Gaming Console Safe?: Embedded Devices, an AntiVirus-free Safe Hideout for Malware.” You might ask “Marcus, what is so compelling here? They’re just gaming consoles,” and that’s true. You know what they also are? Embedded devices with distinctly powerful CPUs. With the growth of home-brew builds (customized operating systems) available for many gaming consoles, more and more these are being looked at as attack and attacker platforms.

One example I found particularly powerful was a Nintendo DS running metasploit to compromise Windows devices. Clearly, a gaming console is just like any other device on the network. The second demo (and the actual “a ha!” moment) was when the presenters actually injected code into the gaming files themselves. Yes, boys and girls, you read that right. It is possible to inject code into games just as you would inject code into any DLL or application. They showed this on both installed games and games downloading from the Internet. I was left a bit unclear as to the limitation on an unbroken gaming console, but the implications are far reaching–a networked device is a networked device. They can all be 0wned. When you combine this with the fact that there is no awareness that malware or attacks can happen on these types of embedded devices along with the fact that people will download and install almost anything without a second thought, the potential for abuse is clear.

The Adobe sessions at CanSecWest this year were one of the main reasons I attended. Adobe is a huge target for cybercriminals and malware writers lately as client-side exploits are quite the trend. While attending Haifei Li’s “Understanding and Exploiting Flash ActionScript Vulnerabilities,” I was very disappointed–mainly because I could not understand the speaker. Later in the day, however, I reviewed the slides and enjoyed my second “a ha!” moment.

The slides are remarkably clear in explaining the essence of ActionScript vulnerabilities. They are due, according to Li, to various program flow-calculating errors in the Verification/Generation Process, and that the Verification Flow and the Execution Flow are not the same. This is a very big deal because code can pass verification mode but during execution mode can still trigger a vulnerability. Byte-code blocks make it difficult for the verification process to recognize the correct flow, which can then result in many ActionScript vulnerabilities. Clearly, ActionScript vulnerabilities and exploits will be with us for quite some time.

The final session that struck home for me was “Welcome To Rootkit Country,” from Graeme Neilso. His targets were atypical of traditional rootkit targets as he focused on firewalls and routers. Neilso’s question “Can the integrity of the OS be trusted?” had many heads nodding in agreement. (I was one of them.) Even I was surprised by the amount of firmware that still uses hardcoded passwords and no integrity checking. Let’s be honest: You are just asking for trouble here. Neilso walked us through rolling your own rooted firmware as well as methods of installing both remotely and locally across a wide variety of firewalls. Again, I walked away believing this more firmly than ever–any device, any OS, any application can be broken or 0wned. At this point I was roped into hallway discussions on the future of embedded-device security, rootkits, and what PWN2OWN really means for the future of the security industry.

When you consider how much infrastructure runs on embedded devices and how enterprises are more and more rapidly adopting mobile technologies, these types of conferences are becoming more relevant than ever.

Although it was really no surprise, the iPhone 0wnage by Charlie Miller during PWN2OWN was a portent of the near future of iPhone exploits and attacks. Miller used a drive-by download attack to 0wn the phone. Like many attacks, the phone user is simply required to surf to a rigged website. This caused a browser crash, but once it was relaunched Miller was able to hijack the entire address book. Pay attention to this type of attack, as it has far-reaching implications. Far more impressive to me was the BlackBerry attack by Vincenzo Iozzo, Willem Pinckaers, and Ralf Philipp Weinmann. By using vulnerabilities in WebKit, an open-source browser recently added to Blackberry, they were able to steal the device’s contact list, image database, and even write a file into it by chaining together a series of bugs. What makes this so impressive? The fact that BlackBerry is an almost unknown system. The attackers had to rely on assumptions on Java Virtual Machine and browser functionality. RIM is said to be planning to add ASLR and DEP in the future; however, because there are established evasions for these defenses, we shall see where this goes.

Today holds one more Adobe session for me, stale pointer theory, and some cool fuzzing.

Threats to AutoCAD

AutoCAD is one of the most popular CAD (Computer-Aided Design) software applications available. It is used extensively in various professions, such as architecture, engineering, construction, infrastructure, manufacturing, and more.

Back in December 2003, the first worm written in the AutoLISP scripting language for AutoCAD was discovered. The purpose of the worm, ALS.Bursted.A, was simply to replicate itself within the AutoCAD folder of the compromised computer. The script file was a simple text format, which allowed most antivirus vendors to analyze and detect the worm without much difficulty.

More than six years have passed since the emergence of that first worm, and in 2010 we realized that a new AutoCAD threat had evolved with Visual LISP technology. Moreover, we have observed that the worm has been spreading slowly, mainly in China.

Visual LISP is based on the AutoLISP scripting language, but has many new features, including encryption and protection of compilation. The LISP-scripted code is compiled into bytecode and its data is encrypted. Thus, the threat is now composed of a complex binary body.

As well as protection, the threat gets a lot of benefits from Visual LISP features, especially ActiveX support. The following list shows the functionality that we have observed in recent variants, illustrating how LISP-scripted threats have achieved a similar malicious capacity to general modern malware:

  • Enumerates all mount drives and creates copies of itself on the drives
  • Downloads and executes remote files
  • Updates itself
  • Opens a back door and allows a remote attacker to access the compromised computer
  • Searches for specific files and transfers them to a specified FTP server

The author of the threat has been actively updating it. We are seeing new functionality in it every time a new variant is released. What is the motivation behind this? One can only assume that the author intends to steal sensitive data created by AutoCAD. As previously mentioned, the software is used by professionals in various industries to create a broad range of products, including: office layouts, architectural designs, automobile conceptual designs, digital prototyping, etc. This type of data is highly sensitive and valuable to both the owner and the attacker.

Writing the threat with the LISP-scripting language might be bit of a challenge for the author since it is not a popular language for malware creation. The benefit is that the threat can easily find the data created by the AutoCAD program on a compromised computer because LISP-script threats inherently run with the program. Wherever a LISP threat exists, AutoCAD data also exists.

My colleagues, Dennis Tan, Jerry Jing, and Beannie Cai have written a robust generic detection for the threat and Symantec AntiVirus products have already been detecting it as ALS.Kenilfe or ALS.Kenilfe!inf. Please keep your virus definitions updated. Furthermore, Firewall and Intrusion Prevention Systems will also help you to prevent unauthorized remote access. Data Loss Prevention products will also help to protect your data from being breached.

Trojan.Koredos Comes with an Unwelcomed Surprise

Recent Distributed Denial of Service (DDoS) attacks on a number South Korean websites have been in news for the past week. The threat responsible for carrying out these attacks is Trojan.Koredos.

This attack is reminiscent of another attack, launched on July 4th, 2009 against the U.S. and South Korean governments, as well as financial and media websites. For now, the attack has subsided and the affected sites can be accessed without any issues. However, the computers have not been cleaned for the Trojan.Koredos infection will be greeted with a surprise well after the initial infection, which we will detail in this blog.

Attacks such as this usually involve a command and control (C&C) server that sends commands to the compromised computers, resulting in systematic and coordinated attacks. In this case, the commands do not come from a C&C—they are hidden inside the threat.

There are many components involved in the attack, and that alone indicates some level of sophistication. Of those files, the destructive behavior is carried out by the s[RANDOM LETTERS]svc.dll file. While we have seen several variants of this .dll, the end result is the same—the master boot record (MBR) of the compromised computer is destroyed.

Some variants scan the fixed drives of compromised computers for files with various extensions, which are used by software predominantly used in Korea (i.e. .alz, .gul, and .hwp). This strongly suggests the threat targets computers located in Korea.

Figure 1 –  Heatmap showing Trojan.Koredos infections.

Figure 2 – The threat searching for file extensions.

The threat overwrites the files with all zeros. Additionally, if the file size is larger than or equal to 10,485,760 bytes, the threat simply deletes the files. If a file does not meet the previous condition, the threat creates a .cab file using the original file name, and deletes the original file. In other cases deleted files can be restored using various methods, but since the threat overwrites the files with zeros, the original file cannot be restored.

The threat destroys the MBR of all drives if one of the following conditions is met:

  • The %System%\noise03.dat file is missing. The noise3.dat file is a part of Trojan.Koredos that contains a number 7 within it. This is the number of days the destruction functionality gets triggered. One interesting part is that the number can be overwritten, though the threat can only distinguish up to 10. (Any number over 10 will be interpreted as 7.) This means the maximum life of the compromised computer is 10 days.

    Figure 3 – Creating the noise03.dat file with the date and time of infection and days to attack.

  • A %System%\dnsec.dat file exists, and its first four bytes are all zero. The dnsec.dat file is also a component of W32.Koredos that works with other threat components.

    Figure 4 – Overwriting files with zeros and checking that the file size is greater than 10,485,760 bytes.

  • The current date and time is later than 7 days, or equal to the number in %SYSTEM%\noise03.dat at the time of first infection.
  • The current date and time is equal to or longer than 7 to 10 days after first infection. As explained previously, the number can manually overwritten in the %System%\noise03.dat file, but the operating system will be destroyed.

    Figure 5 – Checking that 7 to 10 days have passed.

In short, the infected computers can live up to 10 days if they are not cleaned. Symantec provides protection against the threat. Please make sure you keep virus definitions up-to-date to keep your valuable data safe from the destructive threat.

Thanks to Masaki Suenaga for his contributions to this blog.

Android.Bgserv Found on Fake Google Security Patch – Part II

Following our initial post on the discovery of Android.Bgserv, Symantec has found additional Trojanized samples in the wild. After analysis of these new samples, it appears that the applications contain multiple bugs. In the case of the Trojanized version of Google’s Security Tool, we have confirmed after testing (with no surprise) that it does not have the ability to clean a system infected with Android.Rootcager.

The Trojanized applications also contain code to change an infected device’s APN settings. The screenshot below belongs to the threat code responsible for changing them. However, in our research we have not been able to identify the code being called at any time.

Our research also shows that even if this APN change code was called, the application's permissions would not allow the requested changes to take place. This can be seen in the screenshot below, showing the Trojanized application's manifest:  

An application willing to change the APN settings is required to hold the “android.permission.WRITE_APN_SETTING” permission. We have also found some other pieces of interesting code within the threat that seem to be dormant. One example of this is seen in the screenshot below:

The purpose of this code seems to be to block incoming calls from specific telephone numbers. In this case, the telephone numbers in question seem to belong to a major Chinese telecom operator's customer care service.  

Below is an image showing the command-and-control (C&C) server that is being used by this threat and an example of the information that is posted to the C&C server. At the time of writing, the C&C server was live but not serving commands.

Our overall analysis of this threat has shown it to be a potentially worrying threat. However, the threat's perpetrators have failed to fully implement all of the functionality within the infected applications, thereby lessening its potential impact as a threat.    

Here are a few tips that may help to identify whether or not a device has been infected with Android.Bgserv. The legitimate Android Security tool was automatically pushed to infected users and did not require manual download.  Also, it does not show up within the application menu, as opposed to the malicious one:

We can see the malicious service that has been started by the Trojanized tool running in the background as “BgService”:

Finally, to avoid becoming a victim of such malicious Android applications, we recommend that you only use regulated Android marketplaces for downloading and installing Android applications. Also, in the Android OS application settings there is an option to stop the installation of non-market applications, which can help to prevent against this type of attack. Checking user comments on the marketplace can also assist in determining if the application is safe. Lastly, always check the access permissions being requested during the installation of any Android applications. If they seem excessive for what the application is designed to do, it would be wise to stop installing the application.

Note: Special thanks to Irfan Asrar for all his input into this blog.