Year: 2012

ADVISORIES | July 3, 2012

WellinTech KingView and KingHistorian Multiple Vulnerabilities

By Carlos Hollman

Independent researchers Carlos Hollmand and Dillon Beresford identified multiple vulnerabilities in WellinTech’s KingView and a single vulnerability in WellinTech’s KingHistorian applications. These vulnerabilities can be exploited remotely. WellinTech has created a patch, and the researchers have validated that the patch resolves these vulnerabilities in the KingView and KingHistorian applications. (more…)

WHITEPAPER | July 1, 2012

Reversal and Analysis of the Zeus and SpyEye Banking Trojans

By IOActive

Although the core functionality of SpyEye is similar to its main rival Zeus, SpyEye incorporates many advanced tricks to hide its presence on the local system. This document includes a deep technical analysis of the bot’s advanced hooking and injection mechanisms, as well as its core functionality used to hijack and steal user information.

Zeus is an advanced piece of malware, so getting it to a reversible state was not a trivial exercise since it incorporates multiple layers of custom, portable, executable encryption. IOActive reverse engineers stripped each encryption layer and rebuilt the executable to allow for proper disassembly. Once Zeus was in an unpacked state, consultants identified additional roadblocks including non-existent import address tables, obfuscated string tables, and relocated code. Zeus included many methods to hinder reverse engineering. (more…)

ADVISORIES |

Wonderware Archestra ConfigurationAccessComponent ActiveX stack overflow

By Richard van Eeden

The Wonderware Archestra ConfigurationAccessComponent ActiveX control that is marked “safe for scripting” is suffering from a stack-overflow vulnerability. The UnsubscribeData method of the IConfigurationAccess interface is using wcscpy() to copy its first parameter into a static-sized local buffer. Attackers can exploit this vulnerability to overwrite arbitrary stack data and gain code execution. (more…)

ADVISORIES |

XBMC File Traversal Vulnerability

By Lucas Lundgren

XBMC is an award-winning, free, and open source (GPL) software media player and entertainment hub for digital media. XBMC is available for Linux, OSX, and Windows. Created in 2003 by a group of like-minded programmers, XBMC is a nonprofit project run and was developed by volunteers located around the world. More than 50 software developers have contributed to XBMC, and 100-plus translators have worked to expand its reach, making it available in more than 30 languages. (more…)

ADVISORIES |

Multiple Vulnerabilities in Fwknop

By Fernando Arnaboldi

Fwknop stands for the “FireWall KNock OPerator” and implements an authorization scheme called Single Packet Authorization (SPA). This method of authorization is based on a default-drop packet filter and libpcap. A server might appear to have no open ports available, but it could still grant access to certain services if authorized fwknop packets are received. Companies commonly use this service on exposed systems and need to diminish the attack surface of this service.

wknop contains several vulnerabilities. The most critical of these might allow remote, authenticated attackers to leverage flaws to execute code and produce denial-of-service conditions. (more…)

ADVISORIES |

IBM Informix XML functions overflows

By Ariel Sanchez

Informix is one of the world’s most widely used database servers, with users ranging from the world’s largest corporations to startups. Informix incorporates design concepts that are significantly different from traditional relational platforms. This results in extremely high levels of performance and availability, distinctive capabilities in data replication and scalability, and minimal administrative overhead.

Informix contains two vulnerabilities affecting several versions. Attackers can exploit these vulnerabilities to execute arbitrary code or cause denial-of-service conditions. (more…)

ADVISORIES |

Windows Kernel Library Filename Parsing Vulnerability

By Lucas Apa

This vulnerability allows remote attackers to execute arbitrary code on vulnerable installations of Windows. User interaction is required to exploit this vulnerability in that the target must open or browse to a file or subfolder with a specially crafted name on a network SMB share, UNC share, or WebDAV web folder. (more…)

INSIGHTS | June 28, 2012

Inside Flame: You Say Shell32, I Say MSSECMGR

By Ruben Santamarta
When I was reading the CrySyS report on Flame (sKyWIper)[1], one paragraph, in particular, caught my attention:
 
In case of sKyWIper, the code injection mechanism is stealthier such that the presence of the code injection cannot be determined by conventional methods such as listing the modules of the corresponding system processes (winlogon, services, explorer). The only trace we found at the first sight is that certain memory regions are mapped with the suspicious READ, WRITE and EXECUTE protection flags, and they can only be grasped via the Virtual Address Descriptor (VAD) kernel data structure
 
So I decided to take a look and see what kind of methods Flame was using.
Flame is conceived to gather as much information as possible within heterogeneous environments that can be protected by different solutions, isolated at certain levels, and operated upon by different profiles. Which means that, from the developers point of view, you can’t assume anything and should be prepared for everything.
Some of the tricks implemented in Flame seem to focus on bypass just as much AV products, specifically in terms of heuristics. A distributed “setup” functionality through three different processes (winlogon, explorer, and services ) is way more confusing than letting a unique, trusted process do the job; i.e. it’s less suspicious to detect Internet Explorer coming from explorer.exe than winlogon.
In essence, the injection method seems to pivot around the following three key features:
·         Disguise the malicious module as a legitimate one; Shell32.dll in this case.
·         Bypass common registration methods supplied by the operating system, such as LoadLibrary, to avoid being detected as an active module.
·         Achieve the same functionality as a correctly-registered module.
 
So, let’s see how Flame implements it.
During the initial infection when DDEnumCallback is called, Flame injects a blob and creates a remote thread in Services.exe. The blob has the following structure:
 
The loader stub is a function that performs the functionality previously described: basically a custom PE loader that’s similar to the CryptoPP dllloader.cpp[2] with some additional tricks.
 

The injection context is a defined structure that contains all the information the loader stub may need including API addresses or names, DLL names, and files—in fact, the overall idea reminded me of Didier Stevens’ approach to generating shellcodes directly from a C compiler[3]

 Injection Context: Blob + 0x710

 
 
 

API Addresses:

esi             OpenMutexW
esi+4        VirtualAlloc
esi+8        VirtualFree
esi+0Ch   VirtualProtect
esi+10h    LoadLibraryA
esi+14h    LoadLibraryW
esi+18h    GetModuleHandleA
esi+1Ch   GetProcAddress
esi+20h    memcpy
esi+24h    memset
esi+28h    CreateFileMappingW
esi+2Ch   OpenFileMappingW
esi+30h    MapViewOfFile
esi+34h    UnmapViewOfFile
esi+38h    ReleaseMutex
esi+3Ch   NtQueryInformationProcess
esi+40h    GetLastError
esi+44h    CreateMutexW
esi+48h    WaitForSingleObject
esi+4Ch   CloseHandle
esi+50h    CreateFileW
esi+54h    FreeLibrary
esi+58h    Sleep
esi+5Ch   LocalFree
The loader stub also contains some interesting tricks.

 

Shell32.dll:  A matter of VAD

To conceal its own module, Flame hides itself behind Shell32.dll, which is one of the largest DLLs you can find on any Windows system, meaning it’s large enough to hold Flame across different versions.
 
 
 
Once shell32.dll has been mapped, a VAD node is created that contains a reference to the FILE_OBJECT, which points to Shell32.dll. Flame then zeroes that memory and loads its malicious module through the custom PE loader, copying sections, adjusting permissions, and fixing relocations.
 
 
 
As a result, those forensics/AntiMalware/AV engines walking the VAD tree to discover hidden DLLs (and not checking images) would be bypassed since they assume that memory belongs to Shell32.dll, a trusted module, when it’s actually mssecmgr.ocx.
The stub then calls to DllEntryPoint, passing in DLL_PROCESS_ATTACH to initialize the DLL.
 
 
 
The malicious DLL currently has been initialized, but remember it isn’t registered properly, so cannot receive remaining events such as DLL_THREAD_ATTACH, DLL_THREAD_DETACH, and DLL_PROCESS_DETACH.
And here comes  the final trick:
 
 
 
The msvcrt.dll is loaded up to five times, which is a little bit weird, no?
Then the PEB InLoadOrder structure is traversed to find the entry that corresponds to msvcrt.dll by comparing the DLL base addresses:
 
 
 
Once found, Flame hooks this entry point:
 
 
 
InjectedBlock1 (0x101C36A1) is a small piece of code that basically dispatches the events received to both the malicious DLL and the original module.
The system uses this entry point to dispatch events to all the DLLs loaded in the process; as a result, by hooking into it Flame’s main module achieves the goal of receiving all the events other DLLs receive. Therefore, it can complete synchronization tasks and behaves as any other DLL. Neat.
I assume that Flame loads msvcrt.dll several times to increase its reference count to prevent msvcrt.dll from being unloaded, since this hook would then become useless.
See you in the next post!
INSIGHTS |

Thoughts on FIRST Conference 2012

By Eireann Leverett

I recently had the opportunity to attend the FIRST Conference in Malta and meet Computer Emergency Response Teams from around the world. Some of these teams and I have been working together to reduce the internet exposure of Industrial Control Systems, and I met new teams who are interested in the data I share. For those of you who do not work with CERTs, FIRST is the glue that holds together the international collaborative efforts of these teams—they serve as both an organization that makes trusted introductions, and vets new teams or researchers (such as myself).

It was quite an honor to present a talk to this audience of 500 people from strong technical teams around the world. However, the purpose of this post is not my presentation, but rather to focus on all of the other great content that can be found in such forums. While it is impossible to mention all the presentations I saw in one blog post, I’d like to highlight a few.
A session from ENISA and RAND focused on the technical and legal barriers to international collaboration between National CERTS in Europe. I’m interested in this because during the process of sharing my research with various CERTs, I have come to understand they aren’t equal, they’re interested in different types of information, and they operate within different legal frameworks. For example, in some European countries an IP address is considered private information and will not be accepted in incident reports from other teams. Dr. Silvia Portesi and Neil Robinson covered a great wealth of this material type in their presentation and report, which can be found at the following location:
In the United Kingdom, this problem has been analyzed by Andrew Cormack, Chief Regulatory Advisor at Janet. If I recall correctly, our privacy model is far more usable in this respect  and Andrew explained it to me like this:
If an organization cannot handle private data to help protect privacy (which is part of its mission), then we are inhibiting the mission of the organization with our interpretation of the law.
This is relevant to any security researcher who works within incident response frameworks in Europe and who takes a global view of security problems.
Unfortunately, by attending this talk—which was directly relevant to my work—I had to miss a talk by Eldar Lillevik and Marie Moe of the NorCERT team. I had wanted to meet with them regarding some data I shared months ago while working in Norway. Luckily, I bumped into them later and they kindly shared the details I had missed; they also spent some of their valuable time helping me improve my own reporting capabilities for CERTs and correcting some of my misunderstandings. They are incredibly knowledgeable people, and I thank them for both their time and their patience with my questions.
Of course, I also met with the usual suspects in ICS/Smart Grid/SCADA security: ICS-CERT and Siemens. ICS-CERT was there to present on what has been an extraordinary year in ICS incident response. Of note, Siemens operates the only corporate incident response team in the ICS arena that’s devoted to their own products. We collectively shared information and renewed commitments to progress the ICS agenda in Incident Response by continuing international collaboration and research. I understand that GE-CIRT was there too, and apparently they presented on models of Incident Response.
Google Incident Response gave some excellent presentations on detecting and preventing data exfiltration, and network defense. This team impressed me greatly: they presented as technically-savvy, capable defenders who are actively pursuing new forensic techniques. They demonstrated clearly their operational maturity: no longer playing with “models,” they are committed to holistic operational security and aggressive defense.
Austrian CERT delivered a very good presentation on handling Critical Infrastructure Information Protection that focused on the Incident Response approach to critical infrastructure. This is a difficult area to work in because standard forensic approaches in some countries—such as seizing a server used in a crime—aren’t appropriate in control system environments. We met later to talk over dinner and I look forward to working with them again.
Finally, I performed a simple but important function of my own work, which comprises meeting people face-to-face and verifying their identities. This includes our mutually signing crypto-keys, which allows us to find and identify other trusted researchers in case of an emergency. Now that SCADA security is a global problem, I believe it’s incredibly important (and useful) to have contacts around the world with which IOActive already shares a secure channel
INSIGHTS | June 13, 2012

Old Tricks, New Targets

By Ruben Santamarta

Just a few days ago, Digitalbond announced that they had been victims of a spear phishing attack. An employee received an email linking to a malicious zip file, posing as a legitimate .pdf paper related to industrial control systems security. Therefore, the bait used by the attackers was supposedly attracting targets somehow involved with the ICS community. (more…)