Arris RCE: "Bypassing Validation Using Validation"?

Arris RCE: "Bypassing Validation Using Validation"

Yet another commonly used device in the Caribbean and Latin America has been found to suffer from a remote code execution vulnerability (RCE), which invites us to question the poor choices made by providers in selecting consumer products in these countries. CVE-2022-45701 is a critical vulnerability that affects Arris routers, which allows an attacker to completely takeover the device. This article aims to describe the vulnerability in detail.

This is More Common Than we Would Like

Arris firmware 9.1.103, like many of the other router firmware that has been tested, suffers from Authenticated RCE via the improper neutralization of special elements used in an OS Command (CWE-78) commonly known as OS command injection. From the large number of routers that have been examined, this issue seems to occur more commonly in router firmware that tries to implement a ping or traceroute function in their management service, which almost always results in passing data to the underlying OS's command line interface and proves to be a nice juicy target for any penetration test.


Finding the Vulnerability

We start off by identifying a way to possibly send the payload and check what is allowed by the firmware. By looking closely at the web requests, we determined that the firmware uses SNMP to change the parameters to the command and stores the command input as an object with an identifier which allows us to send requests to /snmpSet to set the value, and /snmpGet to confirm that the value was actually set.

No alt text provided for this image
Setting the value to localhost with snmpSet
No alt text provided for this image
Confirming the value with snmpGet


For shell script command injection, we typically want to to be able to include one or more of the following special elements in our payload:

  • |
  • &
  • $()
  • <
  • >
  • `
  • ;
  • ${}

The logical thing to do here is to send each character separately and see what characters are neutralized.


Bypassing Validation

In almost every encounter with this type of router vulnerability, there has always been some amount of mitigation/validation done by the firmware which we were eventually able to bypass. As in the case of CVE-2022-37661, the payload was limited to 12 characters but just enough to open a netcat connection and send our shellcode over the connection. In the case of Arris firmware 9.1, the validation done was pretty interesting as we were able to gain RCE by "using the validation against itself" in a sense.

Here we see that only `$` is accepted which is promising but when paired with `$(` it is neutralized. This implies that the developer was intentionally trying to prevent command injection this way; however, there still exists a huge flaw in the validation. If any of these bad characters or `$(` is in the object, the object is not set and keeps its previous value however, in the case of `\` it is simply removed from the payload subsequent to validation. This allows us to set `$()` by inputting `$\()`. This could have easily been prevented by also neutralizing `$` or `(` individually ????


No alt text provided for this image
Here we bypass validation by placing \ in between $(


No alt text provided for this image
Confirming $( was actually set


From here we simply add netcat reverse tcp shellcode and voila we get a shell.

No alt text provided for this image
Using the python POC exploit to spawn a netcat shell

We now have access to the root user which allows us to dig deeper into the device and it's firmware, which is very helpful for identifying unauthenticated RCE.

The proof of concept exploit is available on github.

Mitigation

The simplest form of mitigation for this vulnerability is to use a strong password for the web service's management portal. A more extreme form of mitigation would be replacing the default arris firmware with DD-WRT or another custom firmware. This is easier for providers like Xfinity, who ships devices with their own firmware. For us end users, to install a CFW we would most likely have to exploit this vulnerability to gain root shell access and patch or in a more extreme case, reprogram hardware flash directly.


Conclusion

On contact with Arris (Now CommScope), they claimed that the devices running this firmware are in EOL and are no longer supported by the company (even though the SBG10 is actively listed on the web). This essentially translated to finger pointing at the providers using outdated products from the vendors with no plan to upgrade. In 2023 where people update their iphones every few months, why are we using decade old routers? This is just evidence that companies lack the security awareness and proper security protocols to keep consumers secured, in addition to wanting to go with the cheapest products to save a few dollars. Even just updating the vendor's default password to a more secure provider default, maybe even based on the provider's supplied default network security key would have been a very strong security control.

This is worrying as it makes vulnerable consumer routers in the Caribbean and Latin America easy targets for attackers to set up botnets, launch other network attacks, not to mention these devices are at the center of our network and handle the day to day traffic in many SOHO networks, which makes it ideal for eavesdropping and packet manipulation.

Given that almost everyone in the CALA regions are using the same device due to the monopolization of ICT companies, millions of people are left open to cyber-attacks at the mercy of other nation states and criminals who are way ahead in detecting and exploiting these vulnerabilities.


要查看或添加评论,请登录

Yerodin Richards的更多文章

  • RCE Exfiltration Framework?

    RCE Exfiltration Framework?

    So I got tired of running into boxes finding RCE vulnerabilities, but not being able to establish a shell. But wait.

    3 条评论

社区洞察

其他会员也浏览了