Tuesday, December 20, 2016

IEC 104 Protocol Detection Rules

IEC 60870-5-104 Protocol Detection Rules


Cisco Talos has released 33 Snort rules which are used to analyze/inspect IEC 60870-5-104 network traffic. These rules will help Industrial Control Systems/Supervisory Control and Data Acquisition (ICS/SCADA) asset owners to allow the identification of both normal and abnormal traffic in their environments.

In order for these rules to be effective they should be selectively turned on/enabled. SIDS 41053-41077 will detect various TypeIDs, if that specific TypeID is not in use then the rule should be enabled. SIDS 41078-41079 will detect IEC 104 traffic entering/exiting the ICS network. If 104 traffic is not supposed to enter/exit the ICS network then these sids should be enabled.

The rules will require both Snort $EXTERNAL_NET and $HOME_NET variables to be correctly configured for some of the rules to be effective. If a network does not have IEC 104 traffic these rules should not be enabled as they are only intended to detect IEC 104 traffic and will likely result in false positives (FPs) on non-IEC 104 traffic.

What is IEC 104?


IEC 104 is a network protocol that is commonly used in ICS/SCADA environments. Various ICS/SCADA devices use IEC 104 to communicate with other ICS devices such as, but not limited to, Programmable Logic Controllers, Remote Terminal Unit, etc.

FirePower 6.1 enabling a SID
Read more on the snort blog here


Vulnerabiity Spotlight: Tarantool Denial of Service Vulnerabilities

Vulnerabilities discovered by Talos

Talos is disclosing two denial of service vulnerabilities (CVE-2016-9036 & CVE-2016-9037) in Tarantool. Tarantool is an open-source lua-based application server. While primarily functioning as an application server, it is also capable of providing database-like features and providing an in-memory database which can be queried using a protocol based around the MsgPack serialization format. Tarantool is used by various service providers such as Mail.RU, or Badoo.

Monday, December 19, 2016

In the Eye of the Hailstorm

This blog post was authored by Jakob Dohrmann, David Rodriguez, and Jaeson Schultz.

The Cisco Talos and Umbrella research teams are deploying a distributed hailstorm detection system which brings together machine learning, stream processing of DNS requests and the curated Talos email corpus.

Talos has discussed snowshoe spam before. Traditional snowshoe spam campaigns are sent from a large number of IP addresses, and a low volume of spam email per IP address. Using such techniques, snowshoe spammers intend to fly under the radar with respect to any reputation or volume-based metrics that could be applied by anti-spam systems. This post concerns "hailstorm" spam. Hailstorm spam is an evolution of snowshoe spam. Both snowshoe and hailstorm spam are sent using a large number of sender IP addresses, but unlike snowshoe spam, hailstorm campaigns are sent out in very high volume over a short timespan. In fact, some hailstorm spam attacks end just around the time the fastest traditional anti-spam defenses can update in response.

The images below, taken from Umbrella Investigate, nicely illustrate the difference between a typical snowshoe spam campaign versus a typical hailstorm spam campaign. The top image below illustrates what the DNS query volume looks like for a domain involved in a typical snowshoe attack. Note the maximum query rate is only 35 queries per hour for the snowshoe domain example. The bottom graph, in contrast, shows the DNS query volume for a domain involved in a typical hailstorm attack. In this graph, there is practically no query volume until suddenly when the DNS query volume spikes to over 75K queries per hour, then drops back down to nothing.

Typical DNS query volume patterns for traditional snowshoe spam (top) vs. hailstorm spam (bottom).

Wednesday, December 14, 2016

Vulnerability Spotlight: Local Denial of Service Bug in NVIDIA Windows Kernel Mode Drivers Fixed

Bugs are inevitable in complex systems and software. Operating systems and device drivers are prime examples where layers of abstraction help hide complexity and allow hardware and software to communicate. Thus, when bugs are identified that could compromise, disrupt, or bring systems to a halt, care must be taken to address them. Talos, in coordination with NVIDIA, is disclosing the existence of a local denial of service bug in the NVIDIA Windows Kernel Mode Driver: TALOS-2016-0217 (CVE-2016-8823).

TALOS-2016-0217 manifests as a deficiency in the handling of messages in the communication functionality of the NVIDIA Windows Kernel Mode Driver. Exploitation of this flaw could result in a denial of service condition where the system enters a bug check (blue screen crash). The execution of an application that sends a specifically crafted message to the driver could trigger this vulnerability.

Tuesday, December 13, 2016

Microsoft Patch Tuesday - December 2016

The final patch Tuesday of 2016 has arrived. Today, Microsoft has released their monthly set of security bulletins designed to address security vulnerabilities within their products. This month's release contains 12 bulletins addressing 48 vulnerabilities. Six bulletins are rated critical and address vulnerabilities in Internet Explorer, Edge, Microsoft Graphics Components, Microsoft Uniscribe, and Adobe Flash Player. The remaining seven bulletins are rated important and address vulnerabilities in various Windows components including kernel, crypto driver, and installer.

Vulnerability Spotlight: Joyent SmartOS

Vulnerability discovered by Tyler Bohan

Overview

Talos is disclosing a series of vulnerabilities in Joyent SmartOS, specifically in the Hyprlofs filesystem. SmartOS is an open source hypervisor that is based on a branch of Opensolaris. Hyperlofs is a SmartOS in-memory filesystem that allows users to map files from various different locations under a single namespace. Additionally, hyperlofs allows the creation of new virtual file systems quickly and easily. There are three core vulnerabilities that are being disclosed. However, since they are found in both the 32 and 64-bit versions there are a total of six CVE related to six Talos reports. For all of the vulnerabilities discussed an attacker would need the PRIV_HYPRLOFS_CONTROL privilege in order for them to be exploitable.

Wednesday, December 7, 2016

Floki Bot Strikes, Talos and Flashpoint Respond

This blog post was authored by Ben Baker, Edmund Brumaghin, Mariano Graziano, and Jonas Zaddach

Executive Summary

 

Floki Bot is a new malware variant that has recently been offered for sale on various darknet markets. It is based on the same codebase that was used by the infamous Zeus trojan, the source code of which was leaked in 2011. Rather than simply copying the features that were present within the Zeus trojan "as-is", Floki Bot claims to feature several new capabilities making it an attractive tool for criminals. As Talos is constantly monitoring changes across the threat landscape to ensure that our customers remain protected as threats continue to evolve, we took a deep dive into this malware variant to determine the technical capabilities and characteristics of Floki Bot.

During our analysis of Floki Bot, Talos identified modifications that had been made to the dropper mechanism present in the leaked Zeus source code in an attempt to make Floki Bot more difficult to detect. Talos also observed the introduction of new code that allows Floki Bot to make use of the Tor network. However, this functionality does not appear to be active for the time being. Finally, through the use of the FIRST framework during the analysis process, Talos was able to quickly identify code/function reuse between Zeus and Floki Bot. This made sample analysis more efficient and decreased the amount of time spent documenting various functions present within the Floki Bot samples we analyzed.

Talos worked in collaboration with Flashpoint during the analysis of Floki Bot. This collaborative effort allowed Talos and Flashpoint to quickly communicate intelligence data related to active campaigns distributing Floki Bot as well as data regarding the technical functionality present within the malware. Additionally, Talos is making scripts available to the open source community that will help malware analysts automate portions of the Floki Bot analysis process and make the process of analyzing Floki Bot easier to perform.

Tuesday, December 6, 2016

Vulnerability Spotlight: ImageMagick Convert Tiff Out of Bounds Write

Vulnerability discovered by Tyler Bohan 

Overview

Talos is disclosing TALOS-2016-0216 / CVE-2016-8707, an out of bounds write vulnerability in ImageMagick. ImageMagick is a photo editing software program that allows users to edit and manipulate various types of image files. This particular vulnerability lies in the convert utility that is bundled as part of ImageMagick. The utility is used to parse and convert images and other formats interchangeably. The vulnerability occurs when attempting to deflate an Adobe Deflate compressed Tiff image. The buffer that is created to hold decompressed data associated with the Tiff image is not large enough to hold the decompressed stream. This results in a controlled out of bounds write that under proper circumstances could be exploited into full remote code execution. The full details surrounding the vulnerability are available here.

Thursday, December 1, 2016

Project FIRST: Share Knowledge, Speed up Analysis


Project FIRST is lead by Angel M. Villegas. This post is authored by Holger Unterbrink.

Talos is pleased to announce the release of the Function Identification and Recovery Signature Tool (FIRST). It is an open-source framework that allows sharing of knowledge about similar functions used across file types that IDA Pro can analyze. The aim is to create a community for the infosec analysts and reverse engineers that promotes the sharing of information.

The main idea behind FIRST is to preserve an engineer’s analysis of certain functions (name, prototype, comment, etc) by using methods like opcode hashing, mnemonic hashing, locality sensitive hashing, etc. By collecting and storing these signatures centrally the framework can provide them later to the community via the API/Plugin. The goal is to provide quick lookups for similar functions (see Fig. A) to avoid losing time with analysing a function which was already analysed before in another sample or by another engineer.
Fig. A
For example, a researcher in Spain analyzed a sample. He annotated the analysed functions and uploaded the information to the server. Later, a researchers in California comes across a variant of the sample and he queries the FIRST server in order to find similarities with known binaries. He is lucky, someone has already analysed these functions and he does not need to reinvent the wheel, he can use the matches found in the framework and speed up his analysis.