Google has released Chrome 80 update that addresses three high-severity vulnerabilities, one of them has been exploited in the wild.
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
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.
(SecurityAffairs – hacking, Google Chrome)
The post Google fixes Chrome zero-day flaw exploited in the wild appeared first on Security Affairs.
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.
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.
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.”
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 firstname.lastname@example.org.
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.
Microsoft has warned Windows users that there is an unpatched zero-day vulnerability in Internet Explorer that is being exploited in targeted attacks.
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.
On Feb. 13, FireEye identified a zero-day Adobe Flash exploit that affects the latest version of the Flash Player (220.127.116.11 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.
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.
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.
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.
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:
Sample callback traffic was as follows:
POST /D28419029043311C6F8BF9F5 HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; InfoPath.2; .NET CLR 2.0.50727; SV1)
Both java.ns1[.]name and adservice.no-ip[.]org resolved to 18.104.22.168 on Feb. 18, 2014. Passive DNS analysis reveals that the domain wmi.ns01.us previously resolved to 22.214.171.124 between July 4, 2013 and July 15, 2013 and 126.96.36.199 on Feb. 17, 2014. java.ns1[.]name also resolved to 188.8.131.52 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||184.108.40.206 220.127.116.11|
|java.ns1[.]name java.ns1[.]name||2014-02-18 2014-02-18||2014-02-19 2014-02-19||18.104.22.168 22.214.171.124|
|java.ns1[.]name java.ns1[.]name||2014-02-18 2014-02-18||2014-02-18 2014-02-18||126.96.36.199 188.8.131.52|
|wmi.ns01[.]us wmi.ns01[.]us||2014-02-17 2014-02-17||2014-02-17 2014-02-17||184.108.40.206 220.127.116.11|
|proxy.ddns[.]info proxy.ddns[.]info||2013-05-02 2013-05-02||2014-02-18 2014-02-18||18.104.22.168 22.214.171.124|
|updatedns.ns02[.]us updatedns.ns02[.]us||2013-09-06 2013-09-06||2013-09-06 2013-09-06||126.96.36.199 188.8.131.52|
|updatedns.ns01[.]us updatedns.ns01[.]us||2013-09-06 2013-09-06||2013-09-06 2013-09-06||184.108.40.206 220.127.116.11|
|wmi.ns01[.]us wmi.ns01[.]us||2013-07-04 2013-07-04||2013-07-15 2013-07-15||18.104.22.168 22.214.171.124|
|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||126.96.36.199 188.8.131.52|
|microsafes.no-ip[.]org microsafes.no-ip[.]org||2014-02-12 2014-02-12||2014-02-12 2014-02-12||184.108.40.206 220.127.116.11|
|microsafes.no-ip[.]org microsafes.no-ip[.]org||2013-12-04 2013-12-04||2013-12-04 2013-12-04||18.104.22.168 22.214.171.124|
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 126.96.36.199.
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 188.8.131.52 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||184.108.40.206 220.127.116.11|
|windows.ddns.us windows.ddns.us||2012-05-23 2012-05-23||2012-06-10 2012-06-10||18.104.22.168 22.214.171.124|
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 126.96.36.199.
|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||188.8.131.52 184.108.40.206|
|ids.ns01[.]us ids.ns01[.]us||2012-04-23 2012-04-23||2012-05-18 2012-05-18||220.127.116.11 18.104.22.168|
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.
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.