Tuesday, September 30, 2014

Shellshock Exploits in the Wild

This post was authored by Joel Esler & Martin Lee.

The recently discovered Bash vulnerability (CVE-2014-6271) potentially allows attackers to execute code on vulnerable systems. We have already blogged about the issue and provided more technical detail in a further blog. The rapid release of IPS signatures for our platforms allowed us to follow very quickly, the attempts at exploitation of the vulnerability in the wild.

For further details of our response to the issue, please see the Event Response Page.

Friday, September 26, 2014

Shellshock - Update Bash Immediately!

Shellshock is a serious vulnerability. Bash, arguably the most widely distributed shell on Linux systems, fails to correctly parse environment variables with function declarations. Why the fuss over environment variables? Because these variables are often set by programs that handle network data. Examples include dhcpcd which, through this vulnerability, more or less gives you a remote shell through DHCP option 114 (and potentially others) and Apache using mod_cgi or mod_cgid when CGI scripts are either written in Bash, or otherwise spawn subshells with exported data acquired from untrusted sources -- to name a few.

The problem is located in variables.c

initialize_shell_variables (env, privmode)
     char **env;
     int privmode;

If an environment variable starts with the string "() {" then initialize_shell_variables() interprets it as a function definition:

if (privmode == 0 && read_but_dont_execute == 0 &&
    STREQN ("() {", string, 4))
 string_length = strlen (string);
 temp_string = (char *)xmalloc (3 + string_length + char_index);
 strcpy (temp_string, name);
 temp_string[char_index] = ' ';
 strcpy (temp_string + char_index + 1, string);

To define the bash function, the rest of the string is passed to the parse_and_execute() function.

 if (posixly_correct == 0 || legal_identifier (name))
 parse_and_execute (temp_string, name, SEVAL_NONINT|SEVAL_NOHIST);

The problem here is the rest of the string is assumed to hold only a function definition, and is passed without sanitation to parse_and_execute().


/* Parse and execute the commands in STRING.  Returns whatever
   execute_command () returns.  This frees STRING. 
parse_and_execute (string, from_file, flags)
     char *string;

However, parse_and_execute() does not stop processing when it reaches the end of the function definition. Bash ends up executing all the commands in the string, even after the function definition. In essence, if an attacker can control an environment variable in a program that will spawn a shell with an environment containing that variable, command injection is possible. Since the original discovery of the vulnerability (CVE-2014-6271), the first fix has been found to be incomplete (CVE-2014-7169). Detection for the vulnerability condition (including CVE-2014-6271 & CVE-2014-7169) can be found in SIDs 31975-31978 & SID 31985.

We have observed attacks attempting to load ELF binaries onto possibly vulnerable targets via wget. ClamAV offers protection from this threat under the name "Linux.Flooder.Agent".

The following ELF binaries have been observed in the wild so far:


We'll be writing more on this subject early next week as we collect more information about the attacks we are seeing in the wild.

Thursday, September 25, 2014

Another Major Vulnerability Bashes Systems

Vulnerabilities that permit remote network attacks against ubiquitous software components are the nightmares of security professionals. On 24 September the presence of a new vulnerability, CVE-2014-6271 in Bash shell allowing remote code execution was disclosed.

Monday, September 22, 2014

Threat Spotlight: “Kyle and Stan” Malvertising Network 9x Larger Than Expected

This post was authored by Armin Pelkmann.

On September 8th, Cisco's Talos Security Intelligence & Research Group unveiled the existence of the "Kyle and Stan" Malvertisement Network. The network was responsible for placing malicious advertisements on big websites like amazon.com, ads.yahoo.com, www.winrar.com, youtube.com and 70 other domains. As it turns out, this was just the tip of the iceberg. Ongoing research now reveals the real size of the attackers' network is 9 times larger than reported in our first blog. For more details, read the Kyle and Stan Blog.

The infographic below illustrates how much more of the malvertisement network was uncovered in comparison to our first assessment. We have now isolated 6491 domains sharing the same infrastructure. This is over 9 times the previously mentioned 703 domains.  We have observed and analyzed 31151 connections made to these domains. This equals over 3 times the amount of connections previously observed. The increase in connections is most likely not proportional to the domains due to the fact that a long time that has passed since the initial attacks.

The discovery difference from the previous blog to this one in raw numbers. With more than 3-times the now observed connections and over 9-times the revealed malicious domains, this malvertising network is of unusually massive proportions.

Wednesday, September 17, 2014

Help! My IP Address Has Been Hijacked!

This post is authored by Jaeson Schultz.

SpamCop is a free, community-based spam email reporting service provided by Cisco. SpamCop analyzes reported spam, and extracts details about the sending IP, the URLs contained in the spam, and the networks over which the spam message has transited. This information is used to create the SpamCop Block List (SCBL). The SCBL a list of IP addresses believed to be sending Unsolicited Bulk Email.

As part of its service, each week SpamCop sends millions of email messages to notify network administrators about malicious activity that is observed occurring on their networks. SpamCop receives all types of replies in response to our notification emails. Many times recipients of SpamCop’s notifications will reply to SpamCop and claim, “we did not send the spam”. The SpamCop Deputies responsible for following up on these replies have heard every excuse under the sun. For them, “we did not send the spam” is the spam block list equivalent of “the dog ate my homework.”

Thursday, September 11, 2014

Looking Glasses with Bacon

This is my first post on the VRT blog and I would like to introduce myself. I am Mariano Graziano, an Italian third-year Ph.D. student at the Software and Systems Security Group at Institut Eurecom in Sophia-Antipolis (France) under the supervision of professor Davide Balzarotti. My research interests are memory forensics and automated malware analysis and currently I am an intern at Cisco in the Talos Security Intelligence and Research Group under the guidance of Alain Zidouemba for the next three months. This post is not about my current project at Cisco but is about my DEF CON talk.

At DEF CON 22 last month, I presented with my former colleague Luca Bruno an offensive research about Looking Glass software security. At the time we contacted all the Autonomous Systems (ASes) involved, as well as all the maintainers of the affected open-source Looking Glass software, but unfortunately, responsible disclosure is not the panacea and as result either some issues have not been addressed by the software maintainers or the AS local sysadmins did not update their Looking Glass instances.

In this post I give a brief overview about the research, then I introduce the vulnerabilities and web misconfigurations we uncovered, and finally I show how the Talos Security Intelligence and Research Group covered  all the CVEs with Snort rules, so that users can protect their backbone infrastructure.


Let's start by defining what a looking-glass is. A looking-glass is a web-application that provides a restricted set of operations on AS routers and is commonly written in Perl or PHP. This web application is directly connected to the routers (via telnet or SSH), the commands go from the web form to the router console and the answer is printed back. The attack vector is obviously from the web, in this threat model we have two kind of problems: web misconfigurations and common web vulnerabilities in the web interface. Web misconfigurations might lead an attacker to the backbone router credentials with a simple Google Dork while a severe vulnerability might lead to a command injection from the web form to the router console. During our research we have found both issues and six CVE numbers have been assigned by the MITRE affecting 45 ASes all over the world.

For a detailed analysis please have a look at either the WOOT 2014 paper or our DEF CON 22 slides.


We have found six vulnerabilities on four open-source Looking Glass software (MRLG4PHP, Cougar LG, Cistron LG and MRLG). Two CVEs (CVE-2014-3927 and CVE-2014-3926) are common web vulnerabilities, three are simply web misconfigurations (CVE-2014-3928, CVE-2014-3929 and CVE-2014-3930) and the last one is a memory corruption in a third-party binary shipped in a Looking Glass installation package. Below you can find the list of these issues:

  • CVE-2014-3927: Remote command injection in router's console via "argument" parameter
  • CVE-2014-3926: XSS in <title> via "addr" parameter
  • CVE-2014-3928: Unsafe configuration file path/ACL
  • CVE-2014-3929: Unsafe SSH keypairs path in default config
  • CVE-2014-3930: Unsafe configuration file path/ACL
  • CVE-2014-3931: Remote memory corruption in fastping (SUID binary)

The Snort way

Talos wrote six Snort rules to address all the above issues. The rules for the web misconfigurations prevent the attacker to retrieve the configuration file or list the configuration directories (have a look at sid:31709, sid:31708 and sid:31727 for all the details). The memory corruption bug referenced by CVE-2014-3931 should be avoided by sid:31767, only the default ICMP Echo Reply payloads are allowed. The web vulnerabilities are addressed by sid:31741 and sid:31766, these rules provide the missing input sanitization and should avoid basic exploitation attempts.

We recommend that all Snort users running the affected Looking Glass software deploy the mentioned rules.

Tuesday, September 9, 2014

Microsoft Update Tuesday September 2014: another generally light month but with a significant IE bulletin

This month’s Microsoft Update Tuesday is pretty light save for the Internet Explorer bulletin. While there’s only a total of 4 bulletins, they cover a total of 42 CVEs. The IE bulletin, as is usual, has the most updates for bugs and is rated critical. It covers a total of 37 CVEs. The other three bulletins are rated as important and provide updates for the remaining five vulnerabilities.

MS14-052 is the IE bulletin and is rated critical. It covers a total of 37 CVEs. Of these 37 CVEs, 36 are remote code execution vulnerabilities, the other one is an information disclosure vulnerability (CVE-2013-7331). This last vulnerability is publicly known and under active exploitation. This vulnerability allows attackers to use Microsoft’s XMLDOM ActiveX object to gain information on local drive and network settings. The attack can be used to detect if files or folders are present on the machine due to different error messages being returned depending on if the files or folder exist or not. An attacker can similarly figure out internal IP addresses using this vulnerability. The remaining 36 vulnerabilities are mostly the result of use-after-free vulnerabilities.

The three remaining bulletins are all rated as important:

Bulletin MS14-053 deals with a single CVE (CVE-2014-4072) in .NET. The vulnerability results in a Denial of Service. This is due to a hash collision that can be exploited by an attacker, which will result in resource exhaustion.

CVE-2014-4074 is fixed by bulletin MS14-054, it deals with a vulnerability in the Windows Task Scheduler that could allow a logged on user to schedule a task that would run code at the system level.

The final bulletin is MS14-055 and fixes three vulnerabilities in Lync. Two of the vulnerabilities, CVE-2014-4068 and CVE-2014-4071, could result in Denial of Services. An attacker could create a legitimate meeting and then modify the SIP information, which would result in a DoS on the Lync server. The third vulnerability that is covered by this bulletin is CVE-2014-4070 and can result in information disclosure due to a Cross Site Scripting (XSS) vulnerability on the server.

To address these issues, Talos has the following SIDs:  29821-29822, 30110-30113, 31782-31797, 31799-31802, 31811-31812

Monday, September 8, 2014

Threat Spotlight: "Kyle and Stan" Malvertising Network Threatens Windows and Mac Users With Mutating Malware

This post was authored by Shaun Hurley, David McDaniel and Armin Pelkmann. Malware was discovered by Richard Harman.

Update 2014-09-22: Updates on this threat can be found here

Have you visited amazon.com, ads.yahoo.com, www.winrar.com, youtube.com, or any of the 74 domains listed below lately? If the answer is yes, then you may have been a victim to the "Kyle and Stan" Malvertising Network that distributes sophisticated, mutating malware for Windows and even Macs.

Table of contents

Attack in a Nutshell
Technical Breakdown
Reversing of the Mac Malware
Reversing of the Windows Malware
Protecting Users Against These Threats

Malvertising is a short form for "malicious advertising." The idea is very simple: use online advertising to spread malware.

Friday, September 5, 2014

Danger at the Retail Point of Sale

This blog post was authored by Martin Lee and Jaeson Schultz.

With the announcement that yet another major retailer has allegedly been breached, it is important to review how attackers compromise retail systems and how such intrusions can be prevented. In this latest case, retailers are working to determine if a large cache of credit card information offered for sale on an underground trading forum originated as a result of a systems breach.

The presence of large amounts of financial and personal information within retail systems means that these companies are likely to remain attractive targets to attackers. Illicit markets exist for such information so that attackers are able to easily monetize stolen data. Although we don’t know the details of this specific attack, it may follow the same pattern as other major breaches in the retail sector. Incidents involving Point of Sale (POS) malware have been on the rise, affecting many large organizations.

In addition to the risk of fraud to the individuals affected, the consequences for the breached organizations are severe. News of customer data theft not only damages the brand, but recovering from the breach can also cost into the millions of dollars as systems are investigated, cleaned, repaired, and new processes are implemented to prevent future similar attacks.

POS Attack

Thursday, September 4, 2014

Malware Using the Registry to Store a Zeus Configuration File

This blog was co-authored by Andrea Allievi. 

A few weeks ago I came across a sample that was reading from and writing a significant amount of data to the registry. Initially, it was thought that the file may be a binary, but after some analysis it was determined that the file is a configuration file for Zeus. Within this blog post we take a look at our analysis of the data I/O in the registry.

Initial Stages of Infection

The scope of this paper is the analysis of the registry write. This section is a brief overview of what happens when the malware is executed.
  1. Unpacks
  2. Creates a copy of itself in the tmp directory
  3. Injects itself into explorer.exe
  4. Starts a thread that executes the injected code

The code injected into Explorer.exe becomes the focus of our analysis. To get started, an infinite loop was added to the entry point of the injected code and Ollydebug was used to attached to Explorer.exe. Debugging injected code in this manner was previously covered here.


Registry Key Names
After attaching the debugger and prior to continuing execution, a breakpoint is set on Advapi32.RegSetValueExW() before the large data write is made. This breakpoint is tripped multiple times by multiple threads within Explorer.exe. Most of the time the threads are related to the injected ZBot code.

It turns out that the same thread is used consistently for writing to this registry key.  Several sub-keys are created to store data that the application uses at a later time.The names of the sub-keys are created using an index value that is combined with other data to appear random. For instance, the key “2f0e9h99” was created by combining a hash of the User SID with the index value 0x9A. Throughout this paper, the registry key will be referenced by either name or index.

A Series of Registry Writes

This section establishes a pattern to the registry activity that can be used to help figure out what the malware is accomplishing with the registry I/O. The registry activity centers around writing to the following key:
  • HKUSERS\<sid>\Software\Microsoft\Ujquuvs.

The “ujquuvs” is dynamically generated by the application and will change between executions.

zbot-regdata-prior to initial large data write.png
Ujquuvs Registry Key Prior to 

Prior to the first registry write of interest the Ujquuvs sub-key contains the values shown in the above graphic. Throughout this section we’ll see that new value names are generated and data is cycled between the keys.

One of the first chunks written to the registry value 2f0e9h99 is a binary string that is 475 bytes in length. The following graphic shows the call to the Windows Advapi32.RegSetValueExW() procedure made by the malware.

RegSetValueExW() Stack

First Registry Write to 2f0e9h99

The above graphic displays the binary string data that was written to the registry. Although 475 bytes is a significant chunk of data written to the registry it is not what caused an alarm. The registry write I am looking for is greater than 3000 bytes. 

Second Registry Write to 2f0e9h99
Another 475 byte write occurs, but the data is different than the first write. It is worth noting that although the data is different the first four bytes appear to be the same “5D BB 95 50” pattern. This may be a header used to distinguish the data.

The next call to RegSetDataExW will write 3800 bytes to the registry.  The binary data was replaced with alphanumeric data (possibly base64). Another assumption can be made. The original binary data is encoded and then stored back to the registry.

Alphanumeric Data Written to 2f0e9h99

This is one of the large data writes that was flagged by the sandbox. Continuing on we see several more data writes all of which are variations of the above. The data cycles between binary strings and alphanumeric strings, and the string lengths vary. One of the largest data writes was an 7200 byte alphanumeric string.

Registry Reads

Along with the registry writes there are usually corresponding registry reads. The data located in 2f0e9h99 is pulled into a buffer and manipulated by the application.

Once the data is read, decoded from alphanumeric encoding to a long list of 475 byte chunks of binary data. These chunks of data contain a hash to identify specific chunks within the list. Whenever a new chunk of data is received the data contained in 2f0e9h99 is decoded and the hash value of the received chunk of data is compared against each chunk that exists already within the registry. If these hash values match, then the that registry data chunk is replaced with the incoming data. Otherwise the data is appended to the bottom of the list.

Once the  input queue is empty the calls to read or write to the registry stop. The thread has not been killed, but it is (most likely) suspended until some event occurs.

The next section combines these findings with further analysis to track down the source of the registry writes.

ZBotThread_1 Procedure

Walking through the executable with a debugger led us to the source of the registry writes. A thread is created and starts executing the code at address 0x41F579. From here on out this code is going to be referred to as ZBotThread_1(). This procedure is the backbone for all activity related to this registry key.

Network Socket Loop

After  several instructions for initializing various data structures, ZBotThread_1() initializes a network socket to communicate with a remote server.  Once traffic is received the IP address is verified against an IP blacklist of network address ranges that exists within a data structure used throughout the application. These IP Address ranges appear to be owned by various AV vendors (indicated here). Here is the list of blacklisted address ranges with the corresponding netmasks:
Once the IP address is verified the payload is decrypted and the data is initialized into the following data structure (sub_41F9C6):


Throughout this post we will refer to this as ZBOT_SOCKET_DATA. Each datagram payload contains this data structure. The lpDataBuff points to a buffer that contains the data that will eventually be written to the registry.

In addition, the dataBuffHeader[0x2C]  contains the first 44 bytes of the decrypted received data. These bytes contain critical information about the entire data chunk.

After a few checks to verify the integrity of the data, ZBotThread_1 calls AnalyseSockDataAndUpdateZBot (sub_43D305). This function will take the 20 byte hash of the data contained within the data chunk header (first 44 bytes) and compares it against a list of other hashes. This list of hashes is built out of previously received datagrams.  If the hash is part of the list then the data is dropped. Otherwise, the hash is appended to the end of the list.

 Next, AnalyseAndFinalizeSockData (sub_41D006) is called to begin the process of adding the data to the registry. Once inside the function, the data type (dataBuffHeader+0x3) is checked. There are several different data types, but the one that is relevant for the purposes of this blog post is type 0x6. This signifies the end of the data stream and the malware can proceed to save the data to registry key 2f0e9h99

The type 0x6 code branch calls VerifyFinalSckDataAndWriteToReg (sub_436889). This function strips the 0x2C length header from the socket data before verifying the integrity using RSA1.

Finally, if the data integrity is good, the WriteSckDataToReg function is called.

Writing Socket Data to the Registry

The previously received socket data has already been written to registry key 2f0e9h99. At this point, the socket data needs to be merged with the data contained within the registry key. Before this can occur, the data is currently alphanumerically encoded (see the registry write section above). The decoded data is a series of 0x1D0 hex byte chunks. Each chunk is a ZBOT_SOCKET_DATA structure.

encoded data structure.png
Alphanumeric Encoded Data in Memory

The hash of the socket data is compared against the hash of each chunk contained within the list of chunks. If the hashes match, then that registry data chunk is replaced with the network socket data. Otherwise the network socket data is appended to the end of the list.

Once the update is completed the registry data is (once again) alphanumerically encoded and written back to the 2f0e9h99 registry key.
It’s worth noting that our sample dropper can encode the original data in several different ways: Base64, and 3 customized XOR algorithms (see function at VA 0x4339DE for all the details).


Using the registry as a way to store and update a configuration is a clever idea. The multiple writes and reads that come with constructing the file with a registry key will raise alarms. It’s what originally grabbed our interest.

This blog post covers a small percentage of the functionality of this malware sample. Some of the functionality that we uncovered denote a high level of sophistication by the author. We strongly encourage others to download a copy and crack open their debuggers.

Sample MD5 Hashes:
     Dropper: 15136D615297C16D1FED67F2A8C11C37
     Injected Code: B4A00F4C6F025C0BC12DE890A2C1742E