Category Archives: Zero Day

Google fixes Chrome zero-day flaw exploited in the wild

Google has released Chrome 80 update that addresses three high-severity vulnerabilities, one of them has been exploited in the wild.

Google has released Chrome 80 update (version 80.0.3987.122) that addresses three high-severity vulnerabilities, including a zero-day issue (CVE-2020-6418) that has been exploited in the wild. The CVE-2020-6418 vulnerability is a type confusion issue that affects the V8 open source JavaScript engine used by the Chrome browser.

Google did not disclose details of the attack exploiting this zero-day flaw to avoid other threat actors will start to exploit it. The vulnerability was discovered by Clement Lecigne from the Google Threat Analysis Group.

The remaining flaws fixed by Google are an integer overflow in ICU and an out-of-bounds memory access issue in the streams component.

The integer overflow was reported by the security expert André Bargull, who was awarded $5,000 for its discovery.

The out-of-bounds vulnerability addressed with the release of Chrome 80 update (version 80.0.3987.122) was discovered by Sergei Glazunov of Google Project Zero.

This is the third Chrome zero-day that has been exploited by threat actors in the wild in the past year.

In February 2019, Clement Lecigne discovered a high severity zero-day flaw in Chrome that could be exploited by a remote attacker to execute arbitrary code and take full control of the target computer.

The vulnerability tracked as CVE-2019-5786 resides in the web browsing software and impact all major operating systems including Windows, Apple macOS, and Linux.

In November 2019, Google released security updates to address two high severity vulnerabilities in the Chrome browser, one of which is a zero-day flaw actively exploited in attacks in the wild to hijack computers.

One of the flaw, tracked as CVE-2019-13720, was exploited in a campaign that experts attribute to Korea-linked threat actors.

Pierluigi Paganini

(SecurityAffairs – hacking, Google Chrome)

The post Google fixes Chrome zero-day flaw exploited in the wild appeared first on Security Affairs.

Zyxel Fixes 0day in Network Storage Devices

Patch comes amid active exploitation by ransomware gangs

Networking hardware vendor Zyxel today released an update to fix a critical flaw in many of its network attached storage (NAS) devices that can be used to remotely commandeer them. The patch comes 12 days after KrebsOnSecurity alerted the company that precise instructions for exploiting the vulnerability were being sold for $20,000 in the cybercrime underground.

Based in Taiwan, Zyxel Communications Corp. (a.k.a “ZyXEL”) is a maker of networking devices, including Wi-Fi routers, NAS products and hardware firewalls. The company has roughly 1,500 employees and boasts some 100 million devices deployed worldwide. While in many respects the class of vulnerability addressed in this story is depressingly common among Internet of Things (IoT) devices, the flaw is notable because it has attracted the interest of groups specializing in deploying ransomware at scale.

KrebsOnSecurity first learned about the flaw on Feb. 12 from Alex Holden, founder of Milwaukee-based security firm Hold Security. Holden had obtained a copy of the exploit code, which allows an attacker to remotely compromise more than a dozen types of Zyxel NAS products remotely without any help from users.

A snippet from the documentation provided by 500mhz for the Zyxel 0day.

Holden said the seller of the exploit code — a ne’er-do-well who goes by the nickname “500mhz” –is known for being reliable and thorough in his sales of 0day exploits (a.k.a. “zero-days,” these are vulnerabilities in hardware or software products that vendors first learn about when exploit code and/or active exploitation shows up online).

For example, this and previous zero-days for sale by 500mhz came with exhaustive documentation detailing virtually everything about the flaw, including any preconditions needed to exploit it, step-by-step configuration instructions, tips on how to remove traces of exploitation, and example search links that could be used to readily locate thousands of vulnerable devices.

500mhz’s profile on one cybercrime forum states that he is constantly buying, selling and trading various 0day vulnerabilities.

“In some cases, it is possible to exchange your 0day with my existing 0day, or sell mine,” his Russian-language profile reads.

The profile page of 500mhz, translated from Russian to English via Google Chrome.

PARTIAL PATCH

KrebsOnSecurity first contacted Zyxel on Feb. 12, sharing a copy of the exploit code and description of the vulnerability. When four days elapsed without any response from the vendor to notifications sent via multiple methods, this author shared the same information with vulnerability analysts at the U.S. Department of Homeland Security (DHS) and with the CERT Coordination Center (CERT/CC), a partnership between DHS and Carnegie Mellon University.

Less than 24 hours after contacting DHS and CERT/CC, KrebsOnSecurity heard back from Zyxel, which thanked KrebsOnSecurity for the alert without acknowledging its failure to respond until they were sent the same information by others.

“Thanks for flagging,” Zyxel’s team wrote on Feb. 17. “We’ve just received an alert of the same vulnerabilities from US-CERT over the weekend, and we’re now in the process of investigating. Still, we heartily appreciate you bringing it to our attention.”

Earlier today, Zyxel sent a message saying it had published a security advisory and patch for the zero-day exploit in some of its affected products. The vulnerable devices include NAS542, NAS540, NAS520, NAS326, NSA325 v2, NSA325, NSA320S, NSA320, NSA310S, NSA310, NSA221, NSA220+, NSA220, and NSA210. The flaw is designated as CVE-2020-9054.

However, many of these devices are no longer supported by Zyxel and will not be patched. Zyxel’s advice for those users is simply “do not leave the product directly exposed to the internet.”

“If possible, connect it to a security router or firewall for additional protection,” the advisory reads.

Holden said given the simplicity of the exploit — which allows an attacker to seize remote control over an affected device by injecting just two characters to the username field of the login panel for Zyxel NAS devices — it’s likely other Zyxel products may have related vulnerabilities.

“Considering how stupid this exploit is, I’m guessing this is not the only one of its class in their products,” he said.

CERT’s advisory on the flaw rates it at a “10” — its most severe. The advisory includes additional mitigation instructions, including a proof-of-concept exploit that has the ability to power down affected Zyxel devices.

EMOTET GOES IOT?

Holden said recent activity suggests that attackers known for deploying ransomware have been actively working to test the zero-day for use against targets. Specifically, Holden said the exploit is now being used by a group of bad guys who are seeking to fold the exploit into Emotet, a powerful malware tool typically disseminated via spam that is frequently used to seed a target with malcode which holds the victim’s files for ransom.

Holden said 500mhz was offering the Zyxel exploit for $20,000 on cybercrime forums, although it’s not clear whether the Emotet gang paid anywhere near that amount for access to the code. Still, he said, ransomware gangs could easily earn back their investment by successfully compromising a single target with this simple but highly reliable exploit.

“From the attacker’s standpoint simple is better,” he said. “The commercial value of this exploit was set at $20,000, but that’s not much when you consider a ransomware gang could easily make that money back and then some in a short period of time.”

Emotet’s nascent forays into IoT come amid other disturbing developments for the prolific exploitation platform. Earlier this month, security researchers noted that Emotet now has the capability to spread in a worm-like fashion via Wi-Fi networks.

“To me, a 0day exploit in Zyxel is not as scary as who bought it,” he said. “The Emotet guys have been historically targeting PCs, laptops and servers, but their venture now into IoT devices is very disturbing.”

DISCLOSURE DEBATE

This experience was a good reminder that vulnerability reporting and remediation often can be a frustrating process. Twelve days turnaround is fairly quick as these things go, although probably not quick enough for customers using products affected by zero-day vulnerabilities.

It can be tempting when one is not getting any response from a vendor to simply publish an alert detailing one’s findings, and the pressure to do so certainly increases when there is a zero-day flaw involved. KrebsOnSecurity ultimately opted not to do that for three reasons.

Firstly, at the time there was no evidence that the flaws were being actively exploited, and because the vendor had assured DHS and CERT-CC that it would soon have a patch available.

Perhaps most importantly, public disclosure of an unpatched flaw could well have made a bad situation worse, without offering affected users much in the way of information about how to protect their systems.

Many hardware and software vendors include a link from their home pages to /security.txt, which is a proposed standard for allowing security researchers to quickly identify the points of contact at vendors when seeking to report security vulnerabilities. But even vendors who haven’t yet adopted this standard (Zyxel has not) usually will respond to reports at security@[vendordomainhere]; indeed, Zyxel encourages researchers to forward any such reports to security@zyxel.com.tw.

On the subject of full disclosure, I should note that while this author is listed by Hold Security’s site as an advisor, KrebsOnSecurity has never sought nor received remuneration of any kind in connection with this role.

Operation GreedyWonk: Multiple Economic and Foreign Policy Sites Compromised, Serving Up Flash Zero-Day Exploit

Less than a week after uncovering Operation SnowMan, the FireEye Dynamic Threat Intelligence cloud has identified another targeted attack campaign — this one exploiting a zero-day vulnerability in Flash. We are collaborating with Adobe security on this issue. Adobe has assigned the CVE identifier CVE-2014-0502 to this vulnerability and released a security bulletin.

As of this blog post, visitors to at least three nonprofit institutions — two of which focus on matters of national security and public policy — were redirected to an exploit server hosting the zero-day exploit. We’re dubbing this attack “Operation GreedyWonk.”

We believe GreedyWonk may be related to a May 2012 campaign outlined by ShadowServer, based on consistencies in tradecraft (particularly with the websites chosen for this strategic Web compromise), attack infrastructure, and malware configuration properties.

The group behind this campaign appears to have sufficient resources (such as access to zero-day exploits) and a determination to infect visitors to foreign and public policy websites. The threat actors likely sought to infect users to these sites for follow-on data theft, including information related to defense and public policy matters.

Discovery

On Feb. 13, FireEye identified a zero-day Adobe Flash exploit that affects the latest version of the Flash Player (12.0.0.4 and 11.7.700.261). Visitors to the Peter G. Peterson Institute for International Economics (www.piie[.]com) were redirected to an exploit server hosting this Flash zero-day through a hidden iframe.

We subsequently found that the American Research Center in Egypt (www.arce[.]org) and the Smith Richardson Foundation (www.srf[.]org) also redirected visitors the exploit server. All three organizations are nonprofit institutions; the Peterson Institute and Smith Richardson Foundation engage in national security and public policy issues.

Mitigation

To bypass Windows’ Address Space Layout Randomization (ASLR) protections, this exploit targets computers with any of the following configurations:

  • Windows XP
  • Windows 7 and Java 1.6
  • Windows 7 and an out-of-date version of Microsoft Office 2007 or 2010

Users can mitigate the threat by upgrading from Windows XP and updating Java and Office. If you have Java 1.6, update Java to the latest 1.7 version. If you are using an out-of-date Microsoft Office 2007 or 2010, update Microsoft Office to the latest version.

These mitigations do not patch the underlying vulnerability. But by breaking the exploit’s ASLR-bypass measures, they do prevent the current in-the-wild exploit from functioning.

Vulnerability analysis

GreedyWonk targets a previously unknown vulnerability in Adobe Flash. The vulnerability permits an attacker to overwrite the vftable pointer of a Flash object to redirect code execution.

ASLR bypass

The attack uses only known ASLR bypasses. Details of these techniques are available from our previous blog post on the subject (in the “Non-ASLR modules” section).

For Windows XP, the attackers build a return-oriented programming (ROP) chain of MSVCRT (Visual C runtime) gadgets with hard-coded base addresses for English (“en”) and Chinese (“zh-cn” and “zh-tw”).

On Windows 7, the attackers use a hard-coded ROP chain for MSVCR71.dll (Visual C++ runtime) if the user has Java 1.6, and a hard-coded ROP chain for HXDS.dll (Help Data Services Module) if the user has Microsoft Office 2007 or 2010.

Java 1.6 is no longer supported and does not receive security updates. In addition to the MSVCR71.dll ASLR bypass, a variety of widely exploited code-execution vulnerabilities exist in Java 1.6. That’s why FireEye strongly recommends upgrading to Java 1.7.

The Microsoft Office HXDS.dll ASLR bypass was patched at the end of 2013. More details about this bypass are addressed by Microsoft’s Security Bulletin MS13-106 and an accompanying blog entry. FireEye strongly recommends updating Microsoft Office 2007 and 2010 with the latest patches.

Shellcode analysis

The shellcode is downloaded in ActionScript as a GIF image. Once ROP marks the shellcode as executable using Windows’ VirtualProtect function, it downloads an executable via the InternetOpenURLA and InternetReadFile functions. Then it writes the file to disk with CreateFileA and WriteFile functions. Finally, it runs the file using the WinExec function.

PlugX/Kaba payload analysis

Once the exploit succeeds, a PlugX/Kaba remote access tool (RAT) payload with the MD5 hash 507aed81e3106da8c50efb3a045c5e2b is installed on the compromised endpoint. This PlugX sample was compiled on Feb. 12, one day before we first observed it, indicating that it was deployed specifically for this campaign.

This PlugX payload was configured with the following command-and-control (CnC) domains:

  • java.ns1[.]name
  • adservice.no-ip[.]org
  • wmi.ns01[.]us

Sample callback traffic was as follows:

POST /D28419029043311C6F8BF9F5 HTTP/1.1

Accept: */*

HHV1: 0

HHV2: 0

HHV3: 61456

HHV4: 1

User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; InfoPath.2; .NET CLR 2.0.50727; SV1)

Host: java.ns1.name

Content-Length: 0

Connection: Keep-Alive

Cache-Control: no-cache

Campaign analysis

Both java.ns1[.]name and adservice.no-ip[.]org resolved to 74.126.177.68 on Feb. 18, 2014. Passive DNS analysis reveals that the domain wmi.ns01.us previously resolved to 103.246.246.103 between July 4, 2013 and July 15, 2013 and 192.74.246.219 on Feb. 17, 2014.  java.ns1[.]name also resolved to 192.74.246.219 on February 18.

Domain First Seen Last Seen IP Address
adservice.no-ip[.]org adservice.no-ip[.]org 2014-02-18 2014-02-18 2014-02-19 2014-02-19 74.126.177.68 74.126.177.68
java.ns1[.]name java.ns1[.]name 2014-02-18 2014-02-18 2014-02-19 2014-02-19 74.126.177.68 74.126.177.68
java.ns1[.]name java.ns1[.]name 2014-02-18 2014-02-18 2014-02-18 2014-02-18 192.74.246.219 192.74.246.219
wmi.ns01[.]us wmi.ns01[.]us 2014-02-17 2014-02-17 2014-02-17 2014-02-17 192.74.246.219 192.74.246.219
proxy.ddns[.]info proxy.ddns[.]info 2013-05-02 2013-05-02 2014-02-18 2014-02-18 103.246.246.103 103.246.246.103
updatedns.ns02[.]us updatedns.ns02[.]us 2013-09-06 2013-09-06 2013-09-06 2013-09-06 103.246.246.103 103.246.246.103
updatedns.ns01[.]us updatedns.ns01[.]us 2013-09-06 2013-09-06 2013-09-06 2013-09-06 103.246.246.103 103.246.246.103
wmi.ns01[.]us wmi.ns01[.]us 2013-07-04 2013-07-04 2013-07-15 2013-07-15 103.246.246.103 103.246.246.103

 

MD5 Family Compile Time Alternate C2s
7995a9a6a889b914e208eb924e459ebc 7995a9a6a889b914e208eb924e459ebc PlugX PlugX 2012-06-09 2012-06-09 fuckchina.govnb[.]com fuckchina.govnb[.]com
bf60b8d26bc0c94dda2e3471de6ec977 bf60b8d26bc0c94dda2e3471de6ec977 PlugX PlugX 2010-03-15 2010-03-15 microsafes.no-ip[.]org microsafes.no-ip[.]org
fd69793bd63c44bbb22f9c4d46873252 fd69793bd63c44bbb22f9c4d46873252 Poison Ivy Poison Ivy 2013-03-07 2013-03-07 N/A N/A
88b375e3b5c50a3e6c881bc96c926928 88b375e3b5c50a3e6c881bc96c926928 Poison Ivy Poison Ivy 2012-06-11 2012-06-11 N/A N/A
cd07a9e49b1f909e1bd9e39a7a6e56b4 cd07a9e49b1f909e1bd9e39a7a6e56b4 Poison Ivy Poison Ivy 2012-06-11 2012-06-11 N/A N/A

The Poison Ivy variants that connected to the domain wmi.ns01[.]us had the following unique configuration properties:

Domain First Seen Last Seen IP Address
fuckchina.govnb[.]com fuckchina.govnb[.]com 2013-12-11 2013-12-11 2013-12-11 2013-12-11 204.200.222.136 204.200.222.136
microsafes.no-ip[.]org microsafes.no-ip[.]org 2014-02-12 2014-02-12 2014-02-12 2014-02-12 74.126.177.70 74.126.177.70
microsafes.no-ip[.]org microsafes.no-ip[.]org 2013-12-04 2013-12-04 2013-12-04 2013-12-04 74.126.177.241 74.126.177.241

We found a related Poison Ivy sample (MD5 8936c87a08ffa56d19fdb87588e35952) with the same “java7” password, which was dropped by an Adobe Flash exploit (CVE-2012-0779). In this previous incident, visitors to the Center for Defense Information website (www.cdi[.]org — also an organization involved in defense matters — were redirected to an exploit server at 159.54.62.92.

This exploit server hosted a Flash exploit file named BrightBalls.swf (MD5 1ec5141051776ec9092db92050192758). This exploit, in turn, dropped the Poison Ivy variant. In addition to using the same password “java7,” this variant was configured with the mutex with the similar pattern of “YFds*&^ff” and connected to a CnC server at windows.ddns[.]us.

Using passive DNS analysis, we see the domains windows.ddns[.]us and wmi.ns01[.]us both resolved to 76.73.80.188 in mid-2012.

Domain First Seen Last Seen IP Address
wmi.ns01.us wmi.ns01.us 2012-07-07 2012-07-07 2012-09-19 2012-09-19 76.73.80.188 76.73.80.188
windows.ddns.us windows.ddns.us 2012-05-23 2012-05-23 2012-06-10 2012-06-10 76.73.80.188 76.73.80.188

During another earlier compromise of the same www.cdi.org website, visitors were redirected to a Java exploit test.jar (MD5 7d810e3564c4eb95bcb3d11ce191208e). This jar file exploited CVE-2012-0507 and dropped a Poison Ivy payload with the hash (MD5 52aa791a524b61b129344f10b4712f52). This Poison Ivy variant connected to a CnC server at ids.ns01[.]us. The domain ids.ns01[.]us also overlaps with the domain wmi.ns01[.]us on the IP 194.183.224.75.

Domain First Seen Last Seen IP Address
wmi.ns01[.]us wmi.ns01[.]us 2012-07-03 2012-07-03 2012-07-04 2012-07-04 194.183.224.75 194.183.224.75
ids.ns01[.]us ids.ns01[.]us 2012-04-23 2012-04-23 2012-05-18 2012-05-18 194.183.224.75 194.183.224.75

The Poison Ivy sample referenced above (MD5 fd69793bd63c44bbb22f9c4d46873252) was delivered via an exploit chain that began with a redirect from the Center for European Policy Studies (www.ceps[.]be). In this case, visitors were redirected from www.ceps[.]be to a Java exploit hosted on shop.fujifilm[.]be.

In what is certainly not a coincidence, we also observed www.arce[.]org (one of the sites redirecting to the current Flash exploit) also redirect visitors to the Java exploit on shop.fujifilm[.]be in 2013.

greedywonk-campaign-v2

Conclusion

This threat actor clearly seeks out and compromises websites of organizations related to international security policy, defense topics, and other non-profit sociocultural issues. The actor either maintains persistence on these sites for extended periods of time or is able to re-compromise them periodically.

This actor also has early access to a number of zero-day exploits, including Flash and Java, and deploys a variety of malware families on compromised systems. Based on these and other observations, we conclude that this actor has the tradecraft abilities and resources to remain a credible threat in at least the mid-term.