« June 2015 | Main | August 2015 »

3 posts from July 2015

Jul 23, 2015

PoisonIvy adapts to communicate through Authentication Proxies

Hi, it’s Shusei Tomonaga again from the Analysis Center.

PoisonIvy, a Remote Access Tool/Trojan (RAT) often used in targeted attacks, had been widely seen until around 2013.  Since then, the number of cases using PoisonIvy in such attacks decreased, and there was no special variant with expanded features seen in the wild.  However, recently, we have observed cases where PoisonIvy with expanded features in its communication function were used for attacks.

In this blog post, I will discuss PoisonIvy’s expanded features.

PoisonIvy’s Traditional Communication Function

Traditionally, PoisonIvy had used a proprietary protocol to communicate with C&C servers.  Within organizations using proxies, PoisonIvy attempted to send data to C&C servers via proxies by using CONNECT method or SOCKS (version 4).  This was achieved by pre-setting the proxy server information in PoisonIvy itself, or by enabling the configuration to obtain the proxy information from Internet Explorer.  Figure 1 shows an example of PoisonIvy’s communication using CONNECT method.

Figure 1: PoisonIvy's Communication using CONNECT Method
Fig_1

In the past, PoisonIvy was not able to communicate with external C&C servers when authentication was necessary for a proxy connection.

Transition to HTTP Communication

Recently, we found that PoisonIvy’s settings changed from its traditional proprietary protocol to HTTP for connecting to C&C servers.  This means that, as shown in Figure 2, the new variant now sends POST requests that include the data to send to C&C servers in the body field.

Figure 2: PoisonIvy's Communication (the Cookie tag "id=" is followed by a string with MAC address and host name)
Fig_2

Our analysis revealed that this new PoisonIvy variant has significant changes in its communication function compared to the traditional one (as shown in Figure 3).  The code used for its traditional proprietary communication was replaced with code for HTTP communication.

Figure 3: Change in PoisonIvy's Communication Code (Left: Traditional PoisonIvy / Right: PoisonIvy with expanded features)
Fig_3_2

Adaptability to Authentication Proxies

Furthermore, this PoisonIvy variant has adapted to communicate through authentication proxies.  When it attempts to connect to C&C servers via proxies, and an error is returned from the authentication proxy (HTTP status code 407), it sniffs the communication in promiscuous mode.  If this communication includes the string “Proxy-Authentication: Basic”, it writes this string to the following registry entry.

●HKEY_LOCAL_MACHINE\SOFTWARE\Classes\BJ\STATIC\MessageFile

Figure 4 shows an example of sniffed information that we actually observed in the registry.

Figure 4: Registry Entry with Basic Authentication Information Written Over
Fig_4

Later when connecting to C&C servers via proxies, PoisonIvy adds the string written in the registry entry to the HTTP header, and attempts to pass through the authentication proxy (as shown in Figure 5).   Note that PoisonIvy requires administrative privileges for the proxy authentication communications.  This is because, without administrative privileges, it cannot create the above registry entry, thus it fails to communicate the authentication information.

Figure 5: PoisonIvy's Communication with Authentication Information
Fig_5_2

In Summary

Attacks using PoisonIvy has hit a lull lately, but with the new variant introduced here, we never know it may be used actively again, so caution needs to be taken.

Furthermore, PoisonIvy is not the only case - there are many different types of malware that have adapted to communicate through authentication proxies.  PlugX, covered in an earlier blog entry , is no exception, and we believe that still more types of malware will adapt to communicate through authentication proxies in the future.

Thank you for reading and see you again soon.

- Shusei Tomonaga


Appendix

SHA-256 hash value of the PoisonIvy variant

●d1aa00b6b11fbefd2dda3b458d9fb5e975865b564bf1c289a6f464b14ad748cc

Jul 10, 2015

The 27th FIRST Annual Conference in Berlin

Hello, Taki here, and its currently rainy season in Japan.

Just recently, I attended the 27th FIRST Annual Conference, held on June 14-19 , 2015 in Berlin – a city that I visited for the first time.

Berlinpic1_2

(Photo by Hiroshi Kobayashi)

I would like to go over some activities that JPCERT/CC was involved in during the conference.

This year I attended together with 3 colleagues, Yurie Ito, Koichiro (Sparky) Komiyama and Hiroshi Kobayashi. The conference was themed “Unified Security: Improving the Future”, focusing attendees’ collective efforts on improving the future of security together. As usual, it was great to catch up with the various people that work in the industry and also getting to know some new people as well. Many discussions around work over the past year and prospective collaboration over the next year were had.

JPCERT/CC was involved in 3 different presentations at the conference and I would like to take the time to briefly introduce each of them.

First, Yurie's presentation was titled, "A Proposal for Cybersecurity Metrics Through Cyber Green". Cyber Green, currently led by JPCERT/CC, is a project that aims to measure the health of the Internet by aggregating data sets of key risk factors, enabling comparisons over time and around the world, in order to identify what can be improved to make the Internet a better place. The presentation centered around the overview of the project, along with some details on the methods as to how the data is collected, analyzed and shown.

I was a co-presenter in a talk titled, "VRDX-SIG: Global Vulnerability Identification" along with Mr. Art Manion of CERT Coordination Center (CERT/CC) and Dr. Masato Terada of the Hitachi Incident Response Team (HIRT). The FIRST VRDX-SIG (Vulnerability Reporting and Data eXchange Special Interest Group) was chartered in 2013 to study existing practices on how vulnerabilities are identified, tracked and exchanged, and to develop recommendations on how to better the existing practices across disparate vulnerability databases (including Vulnerability Notes Database by CERT/CC, Japan Vulnerability Notes (JVN) by JPCERT/CC and Information-technology Promotion Agency, Japan (IPA), Open Sourced Vulnerability Database (OSVDB) and other vendor security advisories). This talk presented results of the work of the VRDX-SIG, including the creation of a vulnerability database catalog and some findings about vulnerability identification and tracking.

The last presentation that JPCERT/CC was involved in was a presentation by Hiroshi titled, "Keeping Eyes on Malicious Websites - “ChkDeface” Against Fraudulent Sites". He first talked about some noteworthy features of defaced websites reported to JPCERT/CC, and then introduced a tool called "ChkDeface", developed and implemented at JPCERT/CC, to collect various information on the defaced websites through a secure and efficient monitoring method. JPCERT/CC is planning to share the source code of this tool with some CSIRTs in the FIRST community, and eventually to open source the tool so that it can be practically utilized to trigger deeper discussion among security experts about more precise detection methods ― so here's hoping for a follow-up blog entry when that happens.

JPCERT/CC was a part of a few working groups as well, including the Energy-SIG, Vulnerability Coordination-SIG and CVSS-BoF in addition to the aforementioned VRDX-SIG. While I am unable to provide any insight about what was actually discussed, I believe that the work being done is worthwhile and when there is any output provided, I hope to notify through this blog or some other forms of communication.

Lastly, Berlin was a wonderful city, a little colder than I had expected, and hope to create a chance to visit again.

That's all for today.

Thank you for reading.

Berlinpic2_3

(Photo by Hiroshi Kobayashi)

- Takayuki (Taki) Uchiyama

Jul 01, 2015

Protected Mode in Internet Explorer

Hello, this is Shusei Tomonaga again from the Analysis Center.

JPCERT/CC has been observing cases where vulnerability in Internet Explorer (“IE” hereafter) is leveraged in targeted attacks, etc., resulting in system takeover or configuration change by a third party. In fact, IE has several functions to prevent such exploits. In this article, I will introduce one of the functions called “Protected Mode” – its overview and effects.

OVERVIEW OF PROTECTED MODE

“Protected Mode” is a new feature of IE 7 and later, which is enabled by default. This function runs by using an access control mechanism called “Integrity Level” which has been introduced with Windows Vista. Resources (such as files and registry entries) and processes have their own integrity levels (currently High, Medium or Low, but extensible in the future). When accessing, this access control mechanism requires that the integrity level of the accessing process is the same or higher than the resource which will be accessed.

Figure 1: Integrity Level Concept Chart
Figure1

Ordinary processes started by Command Prompt has a “Medium” integrity level, while IE processes in Protected Mode has a “Low” integrity level. Child processes have the same integrity level or lower integrity levels than their parent processes. As a result, malware deriving from an IE vulnerability will be running as “Low” integrity level, whether it is running as an IE process or its child process. Consequently, malware will have limited access to resources, which is expected to limit its intended behaviour.

Figure 2: Integrity Level of Malware Run by Leveraging IE Vulnerability (Displayed by Process Explorer)
Figure2

VERIFYING MITIGATION EFFECT BY PROTECTED MODE

In order to verify how IE Protected Mode is effective in reducing damage by malware infection, we analysed how malware behaviour is limited in such environment. We took Poison Ivy as an example. Table 1 below describes the result of the analysis.

Table 1: Poison Ivy's Attack Vector and Behaviour under Protected Mode
ItemPoison Ivy's Attack VectorBehaviour under Protected Mode
1 Send information of infected computers (host name, IP address, etc.) Capable
2 Create/delete/download files/folders, execute programs Limited
(Only able to create/delete “Low” integrity level files/folders - e.g. “%TEMP%\Low” folder, etc.)
3 Create/modify/delete/view/search registry entries Limited
(Unable to create/modify/delete)
4 Obtain list of running processes, suspend processes Capable
5 Obtain list of installed applications Capable
6 Window-related commands
(Obtain information/image, key input, display, hide, maximise, minimise)
Incapable
7 Screen capture Capable
8 Execute arbitrary shell commands Limited
(Executable on “Low” integrity level)

As shown in Items 2 and 3 in the table, malware can neither create files in Startup folders nor create registry entries, therefore it cannot set up the necessary configuration for auto-run. Consequently, the process of malware disappears upon system shutdown, and will not persistently run on the computer. Other than that, however, other malware functions which could lead to information leakage (e.g. sending information of the infected computer, obtaining screen captures, etc.) cannot be blocked even under Protected Mode. This is because the operations restricted by integrity levels are configured for each resource as access policy, and it does not restrict all the operations (write/read/execute). Table 2 below shows items which can be configured as access policy.

Table 2: Configurable Items in Access Policy
ConfigurationContents
No-Write-Up Rejects writing from lower integrity level(s)
No-Read-Up Rejects reading from lower integrity level(s)
No-Execute-Up Rejects execution from lower integrity level(s)

For example, a text (.txt) file created by Notepad in a document folder has a “Medium” integrity level and only a “No-Write-Up” access policy by default. Therefore, if malware running with “Low” integrity level attempts to write on this file, it fails. However, since it does not have a “No-Read-Up” policy, it can read files – hence information leakage cannot be prevented.

Figure 3: File Access Policy (Displayed by AccessChk)
Figure3

IN SUMMARY

Protected Mode can save the risk of malware from persistently running even after reboot. However, the above analysis clearly indicates that this is not robust enough against information theft.

In fact, IE has a stronger security feature called “Enhanced Protected Mode”, which is expected to prevent further damage. In the coming entry, I will introduce this enhanced feature.

Thank you for reading and see you soon.

- Shusei Tomonaga


REFERENCE

[1] Understanding and Working in Protected Mode Internet Explorer

https://msdn.microsoft.com/en-us/library/bb250462%28v=vs.85%29.aspx