14 posts categorized "#Vulnerabilities" Feed

Aug 29, 2016

AppContainer’s Protecting Effects on Vulnerability-Exploited Web Browsers

Our previous article “Enhanced Protected Mode in Internet Explorer” (published in August 2015) introduced that running the browser with Enhanced Protected Mode in 64-bit mode is effective in the protection against attacks exploiting vulnerabilities. This entry will verify the effect of “AppContainer” against attacks, which is another function related to Enhanced Protected Mode for Windows 8 and later.

AppContainer and Web Browser

AppContainer is a sandbox which runs applications in an isolated environment. Access from AppContainer to an external environment is strictly limited. The biggest difference from Protected Mode (not Enhanced; access control based on Integrity Level) is that even reading is basically prohibited in addition to writing. [1]

The following Web browsers run within AppContainer:

  • Edge for Windows 10
  • Internet Explorer 11 in Modern UI (Metro) for Windows 8.1 (Immersive browser)

Flash Player which is integrated in Windows 8.1 and Windows 10 is also compatible with AppContainer.

Internet Explorer 11 for Windows 8.1 Desktop and Windows 10 do not run in AppContainer by default. They can run in AppContainer by selecting “Enable Enhanced Protected Mode” in Internet Options. Internet Explorer 11 on Windows 64-bit mode has an option to “Enable 64-bit processes for Enhanced Protected Mode”, however, this alone does not enable Enhanced Protected Mode. The browser will run in 64-bit mode outside AppContainer unless you enable Enhanced Protected Mode in Internet Options. When Enhanced Protected Mode or 64-bit mode is enabled, add-ons that are not compatible with AppContainer or 64-bit mode will not run. Also, even if Enhanced Protected Mode is enabled, it gets disabled when Protected Mode is disabled, for instance in Trusted Sites Zone.

Tests with Malware Samples Used in Actual Attacks

We conducted some tests to see the effect of AppContainer by using malware samples used in actual attacks exploiting Flash Player vulnerability. We used two kinds of samples. For one of them, we also tested by making modifications to the sample to see potentially derived methods. So, we conducted tests for the following three cases:

  • Test 1: See if the sample, which creates and launches executable files by exploiting the vulnerability APSB15-18, runs
  • Test 2: Modify the sample in Test 1 so that it launches executable files via DLL, and see if it runs
  • Test 3: See if the sample, which executes Windows commands and scripts by exploiting the vulnerability APSB16-15, runs

The tests were conducted using Internet Explorer 11 for Windows 10, and we observed the difference in behaviour depending on the configuration of Enhanced Protected Mode. We have confirmed that the same results were obtained for Windows 8.1 and 10.

Test 1 – Creating and Launching Executable Files

First, as a simple case, we tested AppContainer’s effect by checking if malware is successful in creating and launching executable files with different Enhanced Protected Mode configuration. Table 1 describes the behaviour of the sample after successfully exploiting the vulnerability APSB15-18.

Table 1: Creating and Launching Executable Files
Internet OptionsCreating Malware’s Executable FilesLaunching the Created Executable Files
Default (Enhanced Protected Mode disabled) Successful Successful
Enhanced Protected Mode enabled (AppContainer) Successful Failed
Enhanced Protected Mode enabled + Trusted Websites (Protected Mode disabled) Successful Successful

Whether or not Enhanced Protected Mode is enabled, executable files were successfully created. However, when Enhanced Protected Mode is enabled, it fails to launch the file due to an API error. This means that infection will not occur under Enhanced Protected Mode. However, even if Enhanced Protected Mode is enabled, it is disabled in Trusted Sites Zone, and thus infection cannot be prevented.

Test 2 – Launching Executable Files via DLL

The sample used in Test 1 was a simple one which creates and launches executable files. There could be other kinds of malware using more sophisticated methods. As an example, we took advantage of the fact that DLL can also be loaded in AppContainer, and modified the malware to launch executable files indirectly via DLL. We tested to see if executable files could launch this way (shown in Table 2).

Table 2: Launching via DLL
Internet OptionsLaunching Malware’s Executable Files
Default (Enhanced Protected Mode disabled) Suspended (Launches if allowing the warning pop-up)
Enhanced Protected Mode enabled (AppContainer) Suspended (Launches if allowing the warning pop-up)
Enhanced Protected Mode enabled + Trusted Websites (Protected Mode disabled) Successful (No warning pop-up)

Except for the case where Protected Mode is disabled for Trusted Sites Zone, the warning pop-up in Figure 1 appears:

Figure 1: Warning Pop-up asking to allow File Execution

If you choose “Allow” on the pop-up, even under Enhanced Protected Mode, malware is executed without AppContainer’s operation restriction. Please be cautious not to casually allow this message.

Figure 2 to 4 show the Process Explorer screen when executable files were successfully launched. In Figure 3, the “Integrity” for processes running within AppContainer is shown as “AppContainer” instead of its actual Integrity Level. Although the parent-child relationship for processes shown in Figure 2 and 3 are different from that of Figure 4, the process calling for API which launches the malware’s executable file is “iexplorer.exe”, which is listed in the second row from the bottom (iexplorer.exe of child process) in all these figures. Therefore, unlike the case where the malware’s executable file was launched without a warning pop-up and infection occurred (Figure 4), the launched process (sample.exe) will not be a child process of the process calling for API (iexplorer.exe) when execution is allowed at the warning pop-up (Figure 2 and 3).

Figure 2: Screen when execution is allowed at the warning pop-up (Enhanced Protected Mode disabled)

Figure 3: Screen when execution is allowed at the warning pop-up (Enhanced Protected Mode enabled)

Figure 4: Screen when infected via trusted Websites (Protected Mode disabled)

Test 3 – Launching Windows Command

The last test used samples we recently observed in June 2016, Flash File (SWF) sample of Neutrino Exploit Kit. The sample attempts to create and execute scripts to download and launch malware by leveraging vulnerability APSB 16-15. cmd.exe (Windows command processor) is used to create the scripts, and WScript.exe (Windows Script Host) is used to execute the scripts for downloading and launching the malware. The test results are described in Table 3.

Table 3: Results for Launching Windows Command, Creating and Executing Scripts
Internet OptionsLaunching cmd.exeCreating ScriptsDownloading and Launching
Default (Enhanced Protected Mode disabled) Successful Successful Successful
Enhanced Protected Mode enabled (AppContainer) Successful Failed -
Enhanced Protected Mode enabled + Trusted Websites (Protected Mode disabled) Successful Successful Successful

In any case, cmd.exe is successfully launched. Process Explorer at this stage is illustrated in Figure 5. Unlike Test 1 or 2, programs are launched within AppContainer.

Figure 5: Launched Programs within AppContainer

As shown, launching programs within AppContainer does not necessarily fail, and Windows command and others can be launched. In this situation, a warning screen as in Figure 1 will not appear. However, functions of the command are limited, since it takes over the conditions within AppContainer. This sample is not compatible with the limited command functions, and so cannot create scripts. Therefore, infection will not occur under Enhanced Protected Mode.


Even if a vulnerability is leveraged, we have verified that further stage of attack can be prevented by running the Web browser within AppContainer. Through access restriction against malicious codes, you can expect to limit the range of affected area by an attack, or even reduce the risk of being infected by malware.

Yet there is something to note regarding this effect. Since AppContainer is just a system to run applications (e.g. Web browsers) in an isolated environment, it cannot prevent attacks targeting information that Web browsers handle. For example, it cannot prevent actions to steal information from memory, such as password hash of proxy servers with authentication. If such information is stolen, it could be used for other attacks. We can utilise AppContainer, but we recommend that users do not rely on it too much – and make sure that basic security measures are in place, such as to avoid using a single password for multiple Web services.

Thank you for reading.

- Kenichi Imamatsu

(Translated by Yukako Uchida)


[1] FFRI - Windows 8 Security (Japanese)

[2] Microsoft - AppContainer Isolation

[3] IBM - A Peek into IE's Enhanced Protected Mode Sandbox

[4] Black Hat - diving into ie 10's enhanced protected mode sandbox

Jul 08, 2016

Japan Vulnerability Notes (JVN) Site Update

Hello, Taki here. This is more of an update to my previous entry:

Some coordinated vulnerability disclosures in April 2016


Towards the end of the entry, I had mentioned that we were working on upgrading our systems to get more advisories out on our JVN English site. As of May 16th, the JVN site has been updated so that we can release advisories for vulnerability reports that are directly reported to us from various sources.

When you go to the JVN English site now, there are 2 new categories under the "List of Vulnerability Report" on the right. They are "VN_VU" and "TA". Details on these categories are provided on JVN site, but let me briefly explain here.

"VN_VU" is a section used for reports directly reported to JPCERT/CC, where JPCERT/CC is involved in the coordination process in some manner. Advisories will be published here for such reports and when there is no information source in English that we can find.

"TA" is a section that will be used to warn JVN readers on large scale issues, not just a specific vulnerability. As an example, on the JVN Japanese site, we recently published an alert on "WPAD Name Collision Vulnerability". This was a localization of a US-CERT Technical Alert, which is why it is not on the JVN English Site, but we would like to publish similar information here in the future.

We hope that we can provide more information through JVN that helps our readers.

If you have any questions, please contact us at vultures (at) jpcert (dot) or (dot) jp.

Until next time,

Takayuki (Taki) Uchiyama

May 06, 2016

Some coordinated vulnerability disclosures in April 2016

Hello, Taki here. It has been a long time since I have written here.

Today, I will be writing about some activities within our Vulnerability Coordination Group.

Over the past few years, we have received some coordination requests directly from overseas researchers and other sources, in addition to the reports through the " Information Security Early Warning Partnership".

I would like to introduce some recent cases that we have published on Japan Vulnerability Notes (JVN - https://jvn.jp/) but due to system limitations, are not in English at the moment.

The first case is,

JVNVU#92116866 – Published on 2016/4/26

Keitai Kit for Movable Type vulnerable to OS Command Injection.

An OS command injection vulnerability was reported to us in the Movable Type plugin, Keitai Kit. Leveraging this vulnerability may result in arbitrary OS commands being executed on the server.

Versions affected are 1.35 through 1.641.

Attacks in the wild leveraging this vulnerability have been confirmed.

The vendor has provided an updated version, 1.65 to address the vulnerability. For those that cannot update, emergency patches have been provided for affected versions.

This vulnerability has been assigned, CVE-2016-1204.

The second case is,

JVNVU#90405898 – Published on 2016/4/27

ManageEngine Password Manager Pro fails to restrict access permissions.

An access permission bypass vulnerability was reported to us in ManageEngine Password Manager Pro. Leveraging this vulnerability may result in unauthorized users being able to access password entry records for other users.

Versions affected are 8.3.0 (Build 8303) and 8.4.0 (Build 8400, 8401, 8402).

The vendor has provided an update version, 8.4.0 (Build 8403) to address the vulnerability.

And this vulnerability has been assigned, CVE-2016-1159.

Internally, we are working to upgrade our systems so that we can get this information onto JVN in an advisory format. For the time being, I hope to update through this blog periodically on some of our coordinated disclosures.

If you have a vulnerability report and are having difficulty reaching a vendor or are trying to reach a Japanese vendor and having a language issue, feel free to contact us. While we may not always be successful, we can at least give it our best try to contact and coordinate with a vendor.

For coordination assistance, please contact us at vultures (at) jpcert (dot) or (dot) jp.

- Takayuki (Taki) Uchiyama

Apr 08, 2016

PHP Files in CMS, Targeted for Alteration

JPCERT/CC has been continuously observing cases where websites in Japan created with Content Management Systems (hereafter “CMS”) are defaced in a similar way, and the same kind of cases are also observed overseas [1], [2]. In these cases, part of the PHP files composing the CMS are altered, and this results in defacement of the website contents [3].

Based on the analysis of several cases, this entry today describes the alteration of such files composing CMS.

Altered Files

JPCERT/CC confirmed that the targeted CMS contained partially altered PHP files as components. The CMS names and altered PHP files in each are listed in Table 1.

Table 1: CMS names and altered PHP files
CMS NameAltered PHP Files
WordPress /wp-includes/nav-menu.php
Joomla! /includes/defines.php
Drupal /includes/bootstrap.inc
MODX /manager/includes/protect.inc.php

Our study revealed that malicious codes were dynamically inserted into the response from the website for each access by the visitor, which was a result of the PHP file alteration.

How Altered PHP Files Insert Malicious Codes

Altered PHP files included malicious PHP codes in between “//istart” and “//iend” as in Figure 1 (we noted that malicious codes are obfuscated in some cases).

These malicious PHP codes have a function to insert codes obtained from outside. They receive malicious codes from a specific URL and insert them in a certain place.

Figure 1: Malicious PHP codes in between “//istart” and “//iend”

Malicious Codes to be Inserted

When a visitor accesses such websites, the malicious PHP codes in the altered PHP files obtain malicious codes composed of “div” tag and JavaScript, and insert them in the response to the website visitor. The places to insert the codes differ in each CMS: right after the “body” tag in WordPress, and at the beginning of the HTML in Joomla!, Drupal and MODX.

Figure 2: Example of malicious codes to be inserted

Malicious codes include obfuscated JavaScript, and if this is executed on the visitor’s browser, they generate tags such as iframe, etc., which redirect the visitor to the attacker’s site. Also, if the visitor’s web browser or its plug-in, etc., has certain vulnerability, their PC may be exposed to the risk of being infected with malware such as ransomware.


In such cases where malicious codes are dynamically inserted, it may be difficult for website administrators to realise that their websites are providing malicious contents. We recommend the administrators to confirm that there are no malicious PHP codes (as in Figure 1) in the PHP files described in Table 1 and others in their websites. We have not yet confirmed how these PHP files are altered, but vulnerabilities in the CMS or the plug-ins used by CMS may be leveraged for the alteration. We also recommend updating the CMS and plug-ins to the latest version.

Other than the instances introduced here, JPCERT/CC has been seeing cases where Japanese websites are defaced, and then leveraged as an entrance to the attacker’s website. We hope that each website administrator takes actions as updating the software and properly managing passwords, and be mindful that their website would not be abused for such attacks.

- Ayaka Funakoshi

(Translated by Yukako Uchida)


[1] Sucuri Inc
WordPress Malware Causes Psuedo-Darkleech Infection

DarkLeech: Finally Under Control?

JPCERT/CC Incident Handling Report (October 1 – December 31 2015) (English)

Sep 30, 2015

VPN Servers Altered by Attacker Leading to Scanbox, a Reconnaissance Framework

Hi, it’s Shusei Tomonaga again from the Analysis Center. JPCERT/CC has confirmed several attack cases around May 2015, which attempt to steal information of computers leveraging specific network devices featuring VPN server functions. The target of the reconnaissance varies from installed software to keylogs, and it is presumed that the attacker has aimed to steal such information from computers which attempt to login to VPN servers through altered login pages. In this post, I’d like to introduce the details of the attack and effective countermeasures you may take.


Through our analysis, we were able to reveal the mechanism of how VPN account information could be stolen, using a framework called Scanbox. The Scanbox consists of (1) JavaScript code to be sent to the browser, (2) the server to receive the collected information and (3) tools to analyze information collected in the server. The overall flow of attack is shown in Figure 1.

Figure 1: Overall Flow of Attack [Click to enlarge image]

In this attack, the attacker somehow alters VPN service login pages of such network devices and embeds scripts, which leads the user to access a different server in addition to its originally intended behaviour. The JavaScript code of Scanbox, which collects information of users’ computers, is placed in the accessed server, and computers accessing the altered login page are led to download and execute it. This JavaScript code steals information such as the computer’s IP address, installed software and information entered by the user in the VPN session, and keeps sending the information to the Scanbox information collection server until the browser is closed.


Through our analysis, we confirmed that login pages of specific network devices with VPN server functions were altered in several cases. As of now, we have not been able to specify the method of alteration, but there is possibility that a network device vulnerability was leveraged.

The altered login page was embedded with a script tag as shown in Figure 2. When the user accesses the Web SSL VPN login page via the browser, the user is unknowingly entrapped into the Scanbox due to this script.

Figure 2: A Script embedded Web Page redirecting to an Altered Website [Click to enlarge image]


The Scanbox, set up at the redirected site, is a framework to steal information, often used in targeted attacks. Attacks by Scanbox start by downloading and executing a JavaScript code. This JavaScript code collects the computer information such as installed applications and IP address, etc., and sends them to the Scanbox information collection server. (Note that the Scanbox JavaScript code can not only collect computer information, but can also add functions to infect the computer with malware by leveraging a vulnerability.)

Table 1 lists Scanbox’s information collection function which we confirmed in this attack.

Table 1: Information collected by Scanbox
ItemFunctionCollected Information
1 Software Scan Information of installed software (anti-virus software, Windows patch, etc.)
2 Flash Scan Adobe Flash Player versions
3 Office Scan Microsoft Office versions
4 Adobe reader scan Adobe Reader installation status
5 FireFox Extentions scan Firefox and plugin installation status
6 Java scan Java versions
7 IP scan IP address information (function for Chrome)
8 Keylogs Keystrokes within the browser (sent every 5 seconds)
9 Ip list IP address information HTTP_X_FORWARDED_FOR
10 Drives scan Drive information

As shown in Item 8 in the above table, Scanbox can also collect such information as entered in Web forms. As such, information entered in the login site may possibly leak. For keystrokes within the browser, the Scanbox JavaScript code sends the collected information to the server every 5 seconds until the browser (tab) reading the JavaScript code is closed. Other information in Table 1 is sent to the Scanbox information collection server upon respective functions’ startup. (For further information on Scanbox, please visit the AlienVault Blog (Reference [1]) for detailed explanation.)

Furthermore, Scanbox has a Web interface for the attacker to analyze the collected information. As shown in Figure 3, the collected information can be browsed on the Website. Information collected by Scanbox can also be customized from the Website as shown in Figure 4.

Figure 3: Screen for browsing information collected in Scanbox [Click to enlarge image]
Figure 4: Screen for customizing information collected in Scanbox [Click to enlarge image]


As of now, the method of the VPN server login page alteration is unknown. However, we presume that there is high possibility that a known vulnerability was leveraged, so we recommend users to apply patches and update firmware. We also recommend users to check if there are any scripts that are unintentionally embedded in the login pages.

Although attacks using Scanbox do not involve malware infection, it needs caution as it steals computer information and information entered in the browser. There is possibility that the attacker is planning for the next phase of attack based on the collected information, therefore, it is necessary to endeavor to detect the attack in an early stage, as well as to keep a close watch over the attacker’s next move and to strengthen protection against it.

Last but not least, an effective countermeasure against Scanbox is to avoid executing JavaScript in your browser downloaded from a Website which is not trusted on your browser.

Thank you for reading and see you again.

- Shusei Tomonaga


[1] AlienVault - Scanbox: A Reconnaissance Framework Used with Watering Hole Attacks


Aug 28, 2015

Enhanced Protected Mode in Internet Explorer

Hi, it’s Shusei Tomonaga again from the Analysis Center. My previous post discussed the mitigation effects against damages caused by malware infection by enabling Internet Explorer’s (hereafter “IE”’s) Protected Mode. In this article, I’d like to introduce an even stronger security function called “Enhanced Protected Mode”, which is a feature of IE 10 and 11 - its overview and preventive effects against damages caused by malware infection.


Unlike Protected Mode, Enhanced Protected Mode is turned off by default. To enable it, you must tick the “Enable Enhanced Protected Mode” option in the Security section of IE’s Tools > Internet Options > Advanced tab, and then restart IE.

Figure 1: Enhanced Protected Mode setting screen (IE 11 for Windows 8.1)

This feature is available in the following OS:

  • Windows 10 (32-bit/64-bit)
  • Windows 8.1 (32-bit/64-bit)
  • Windows 8 (32-bit/64-bit)
  • Windows 7 (64-bit) *Not available on 32-bit OS

When Enhanced Protected Mode is enabled, IE will run in the following mode:

  • 64-bit mode (only in a 64-bit mode Windows)
  • A sandbox environment called AppContainer (only on Windows 8, 8.1 and 10)

Even on a 64-bit Windows, IE will run in 32-bit mode if the Enhanced Protected Mode is turned off. On a 64-bit Windows, IE will run in 64-bit mode by enabling the Enhanced Protected Mode, plus in case of IE 11 for Windows 8 and later, by checking the “Enable 64-bit processes for Enhanced Protected Mode” in “Internet options”. Furthermore, IE that is launched from Window Store applications in Windows 8, etc., will run in 64-bit mode. Also, Microsoft “Edge”, the all new web browser introduced with Windows 10, will run in 64-bit mode by default.

AppContainer is a sandbox environment introduced in Windows 8, which limits process operations more strictly than does the Integrity Level (in Protected Mode). In a widely known case, the Windows Store applications runs in an AppContainer environment, and an Enhanced Protected Mode designated IE also runs in an AppContainer environment.

Figure 2: IE Integrity Level (confirmed with Process Explorer)


In order to validate how Enhanced Protected Mode is effective in reducing damage by malware infection through IE, we analysed using an exploit code that leverages CVE-2014-6332 (vulnerability in IE)which runs PowerShell to attempt to execute an unauthorized code. The verification was conducted on IE 11 for Windows 8.1.

As shown in Figure 3, the attack was successfully conducted in IE running in 32-bit with the Enhanced Protected Mode turned off; the PowerShell is running.

Figure 3: Behaviour of Unauthorized Code on IE 11 (32-bit) for Windows 8.1

Furthermore, Figure 4 shows the verification of IE running in 32-bit with the Enhanced Protected Mode enabled. It shows that the attack was successfully conducted under this condition as well, and the PowerShell is running.

Figure 4: Behaviour of Unauthorized Code on IE 11 (32-bit) for Windows 8.1 with Enhanced Protected Mode enabled

On the other hand, in IE running in 64-bit with the Enhanced Protected Mode enabled, the Powershell fails to run, and IE shut down unexpectedly, as shown in the following figure.

Figure 5: Behaviour of Unauthorized Code on IE 11 (64-bit) for Windows 8.1 with Enhanced Protected Mode enabled

The reason for IE’s unexpected shutdown in 64-bit mode is that the exploit code executed in the IE process was created exclusively for a 32-bit environment. All the exploit codes leveraging vulnerability in IE that JPCERT/CC has analyzed so far were created exclusively for 32-bit OS. Therefore, if IE is running in 64-bit mode, these exploit codes fail to execute as intended by the attacker.

Note that AppContainer is not supported in Windows 7; therefore IE just runs in 64-bit mode when Enhanced Protected Mode is enabled. In this case, the attack also fails, similarly to the test results in Windows 8, etc.


Running IE in 64-bit mode with Enhanced Protected Mode enabled is a strongly effective countermeasure against attacks targeting IE, until an exploit code for 64-bit emerges. Furthermore, I did not touch on the functions of AppContainer in this verification, but when AppContainer is enabled, it basically only allows access to limited resources such as files created in IE, favorites folders (%UserProfile%Favorites), etc. Therefore, even if malware infection occurs, we can expect a higher mitigation effect than that of the Protected Mode which I touched upon in the previous post.

Last but not least, please note that when you enable Enhanced Protected Mode, not only the malware but also incompatible browser extensions such as add-ons, ActiveX controls, etc., may not work correctly. So I would recommend users to check the compatibility before actually enabling the Enhanced Protected Mode.

Thank you for reading and see you again.

- Shusei Tomonaga


[1] Understanding Enhanced Protected Mode


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.


(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.


(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.


“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

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)


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)
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
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)


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


[1] Understanding and Working in Protected Mode Internet Explorer


May 28, 2015

Fiddler Core's insecure Default flag may lead to Open Proxy Issue

NOTE: This article, originally published on May 28, 2015, was updated as of June 8, 2015 (See below).

Just 2 days ago, we published an advisory (in Japanese) on an open proxy issue of a widely used, open source, web browser game utility app called KanColleViewer. The game, Kantai Collection, has explosive popularity. Its official Twitter account has over 1 million followers, and according to its Tweet, the game has 3 million registered players as of May 2015. The issue was due to the insecure configuration of a proxy server launched in the app, allowing any Internet user to access the proxy. Due to the large user base of the app and the nature of the issue, Internet-wide scan against 37564/TCP (the app's proxy port) has been observed.

In this article, I will elaborate a bit more on the technical aspect of the issue to provide secure coding tips for developers.

KanColleViewer is a Windows Desktop app written in C# WPF. The app uses IE shell for web browsing and Fiddler Core for capturing HTTPS traffic between the client and the game server. The app was designed to improve the UI experience of the game, thus acquiring larger user base (2 million downloads as of August 2014, says the developer).

Fiddler Core is a .Net class library for C# apps. By using this library, developers can launch a web proxy in their apps, capture and modify HTTP/HTTPS traffic just like using Fiddler, a well-known web debugging proxy tool.

Now, who is going to use the web proxy launched in the app?

Because the app only needs to capture its user's (game player’s) traffic, the proxy should be exclusively used by the user. However, the proxy was launched in a way that is accessible from remote users as well, serving as an "Open Proxy".

If you take a look at the source code of the vulnerable version 3.8.1, the proxy was launched by calling FiddlerApplication.Startup() in the following way:

63  public void Startup(int proxy = 37564)
64  {
65      FiddlerApplication.Startup(proxy, false, true);
66      FiddlerApplication.BeforeRequest += this.SetUpstreamProxyHandler;
68      SetIESettings("localhost:" + proxy);
70      this.compositeDisposable.Add(this.connectableSessionSource.Connect());
71      this.compositeDisposable.Add(this.apiSource.Connect());
72  }

FiddlerApplication.Startup() is an overloaded method. There are three implementations where two, three and four arguments are taken. Those that take three and four arguments are NOT RECOMMENDED to be used according to the FiddlerCore documentation (which you can download from http://www.telerik.com/fiddler/fiddlercore).

Now, the recommended way to start the proxy instance of FiddlerCore is by calling the following two-argument version of the Startup():

public static void Startup(
       int iListenPort,
       FiddlerCoreStartupFlags oFlags

The first argument is the port number of the proxy. The second argument is the flag options passed into the Startup method.

How should we specify the flag? According to the documentation, using the 'Default' is recommended as below:

The FiddlerCoreStartupFlags option you want to set;

FiddlerCoreStartupFlags.Default is recommended

Unfortunately, the 'Default' flag is NOT SAFE. It will open the door for 'Open Proxy'.

If you use FiddlerCoreStartupFlags.Default, your app will start listening at I used the FiddlerCoreAPI SampleApp (which comes with the free download of FiddlerCore) for testing purposes and got the following result:


The 'Default' flag will enable 'AllowRemoteClients' option which may not be what you exactly want.


Going back to KanColleViewer, the issue was fixed in version 3.8.2. The app now calls Startup() method in a safer way:

63  public void Startup(int proxy = 37564)
64  {
65      FiddlerApplication.Startup(proxy, FiddlerCoreStartupFlags.ChainToUpstreamGateway);

'ChainToUpstreamGateway' option will instruct FiddlerCore to use the system proxy as an upstream gateway proxy.

It seems that there are a number of websites that show the insecure call of the Startup(). I briefly searched stackoverflow.com with the keyword 'FiddlerApplication.Startup' to find enough examples that may lead to this issue.

So tips for developers:

  • Use the two-argument Startup() method
  • Don't use FiddlerCoreStartupFlags.Default
  • Instead, specify the options you really need

Lastly, I'd like to thank the developer Mr. Manato KAMEYA for coordinating with JPCERT/CC smoothly and disclosing the security issue in a responsible manner.

Masaki Kubo @ Vulnerability Analysis Team

Update on June 8, 2015

After a few discussions with the developer of FiddlerCore@Telerik, they've decided to exclude AllowRemoteClients from the Default flag in their next release:

... out of an abundance of caution we will be making a breaking change to the next build of FiddlerCore to require developers explicitly opt-in to Allowing Remote clients.(http://www.telerik.com/forums/fiddlercorestartupflags-default-enables-allowremoteclients#1xtYFqA1LUqoNGXx-h6aKw)

I appreciate Telerik for the decision to make developers and their users more secure.

Dec 25, 2014

Increase in Possible Scan Activity from NAS Devices

Happy holidays to all, this is Tetsuya from Watch and Warning Group. Today, I would like to share a recent, remarkable trend discovered through TSUBAME sensors.


In TSUBAME, we have observed a significant increase in packets destined to 8080/TCP since December 5th, 2014. When accessing source IP addresses using a web browser, the admin login screen for NAS devices provided by QNAP was seen in many cases for IP addresses from certain regions.


[Figure 1: Scan count per hour observed at 8080/TCP from December 2nd, 2014 onwards (Source: TSUBAME)]


Below are some characteristics that we noticed from TSUBAME data:

  - Increase in packets to Port 8080/TCP since December 5th, 2014

  - The TTL value for most of the packets were between 30 - 59

  - A scan attempt sends 1 - 2 packets (the second packet is a re-send)

  - A source IP does not continuously scan a particular destination IP (The majority scans only once)



Also we were able to verify the following after checking some of the source IP addresses:

  - When accessing Port 80/TCP of the source address, a redirect to Port 8080/TCP occurs and the admin login screen of QNAP NAS is shown

  - The QNAP firmware looks to be version 4.1.0 or earlier (Information taken from the screen that is shown. 4.1.0 and earlier are affected by Shellshock) (*1)


Using an environment separate from TSUBAME to check the packets sent by an infected QNAP device, we saw the following request (there are several types of requests).


[Figure 2: Sample request from infected device (Source: JPCERT/CC)]


When a QNAP NAS device using a vulnerable version of firmware receives this request, the Shellshock vulnerability is leveraged to download a malicious attack program over the Internet and be infected by malware (*2, *3). Once infected, it begins to search for other vulnerable NAS devices. As a result of this activity, a large number of NAS devices were infected and we believe this is the reason for the sudden increase in packets to 8080/TCP.


The vendor has released firmware to address the Shellshock vulnerability. If you have yet to apply the update, we recommend that you first check (*2) whether you have been infected or not.


  JVN#55667175 QNAP QTS vulnerable to OS command injection (*1)



  The Shellshock Aftershock for NAS Administrators (*2)



  Worm Backdoors and Secures QNAP Network Storage Devices (*3)



 An Urgent Fix on the Reported Infection of a Variant of GNU Bash Environment Variable Command Injection Vulnerability (*4)



Thank you for reading, and we wish you all the best for the coming year.


- Tetsuya Mizuno