Plato Data Intelligence.
Vertical Search & Ai.

Cyber Security

ASUS warns router customers: Patch now, or block all inbound requests

Republished by Plato
Republished by Plato

Date:

Views: 10
by Paul Ducklin

ASUS is a well-known maker of popular electronics products, ranging from laptops and phones to home routers and graphics cards.

This week, the company published firmware updates for a wide range of its home routers, along with a strong warning that if you aren’t willing or able to update your firmware right now, then you need to:

[Disable] services accessible from the WAN side to avoid potential unwanted intrusions. These services include remote access from WAN, port forwarding, DDNS, VPN server, DMZ, port trigger.

We’re guessing that ASUS expects potential attackers to busy themselves probing exposed devices now that a lengthy list of bug-fixes has been published.

(Of course, well-informed attackers might have known about some, many, or all of these holes already, but we’re not aware of any zero-day exploits in the wild.)

As we’ve pointed out before on Naked Security, exploits are often much easier to figure out if you have signposts telling you where to look…

…in the same way that it’s much quicker and easier to find a needle in a haystack if someone tells you which bale it’s in before you start.

Do as we say, not as we do.

Annoyingly for ASUS customers, perhaps, two of the now-patched vulnerabilities have been around waiting to be patched for a long time.

Both of these have a 9.8/10 “danger score” and a CRITICAL rating in the US NVD, or National Vulnerability Database (reports paraphrased by us):

  • CVE-2022-26376. Memory corruption in the httpd unescape functionality. A specially-crafted HTTP request can lead to memory corruption. An attacker can send a network request to trigger this vulnerability. (Base score: 9.8 CRITICAL.)
  • CVE-2018-1160. Netatalk before 3.1.12 [released 2018-12-20] vulnerable to an out-of-bounds write. This is due to lack of bounds checking on attacker controlled data. A remote unauthenticated attacker can leverage this vulnerability to achieve arbitrary code execution. (Base score: 9.8 CRITICAL.)

To explain.

Netatalk is a software component that provides support for Apple-style networking, but this doesn’t mean an attacker would need to use a Macintosh computer or Apple software to trigger the bug.

In fact, given that a successful exploit would require deliberately malformed network data, legitimate Netatalk client software probably wouldn’t do the job anyway, so an attacker would use custom-created code and could theoretically mount an attack from any operating system on any computer with a network connection.

HTTP escaping and unescaping is needed whenever a URL includes a data character that can’t be directly represented in the text of the URL.

For example, URLs can’t include spaces (to ensure that they always form a single, contiguous chunk of printable text), so if you want to reference a username or a file that contains a space, you need to escape the space character by converting it to a percent sign followed by its ASCII code in hexadecimal (0x20, or 32 in decimal).

Similarly, because this gives a special meaning to the percent character itself, it too must be written as a percent sign (%) followed by its ASCII code (0x25 in hex, or 37 in decimal), as must other characters used distinctively in URLs, such as colon (:), slash (/), question mark (?) and ampersand (&).

Once received by a web server (the program referred to as httpd in the CVE information above), any escaped characters are unescaped by converting them back from their percent-encoded forms to the original text characters.

Why ASUS took so long to patch these particular bugs is not mentioned in the company’s official advisory, but handling HTTP “escape codes” is a fundamental part of any software that listens to and uses web URLs.

Other CVE-listed bugs patched

  • CVE-2022-35401. Authentication bypass. A specially-crafted HTTP request can lead to full administrative access to the device. An attacker would need to send a series of HTTP requests to exploit this vulnerability. (Base score: 8.1 HIGH.)
  • CVE-2022-38105. Information disclosure. Specially-crafted network packets can lead to a disclosure of sensitive information. An attacker can send a network request to trigger this vulnerability. (Base score: 7.5 HIGH.)
  • CVE-2022-38393. Denial-of-service (DoS). A specially-crafted network packet can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability. (Base score: 7.5 HIGH.)
  • CVE-2022-46871. Potentially exploitable bugs in the open-source libusrsctp library. SCTP stands for Stream Control Transmission Protocol. (Base score: 8.8 HIGH.)
  • CVE-2023-28702. Unfiltered special characters in URLs. A remote attacker with normal user privileges can exploit this vulnerability to perform command injection attacks to execute arbitrary system commands, disrupt the system or terminate service. (Base score: 8.8 HIGH.)
  • CVE-2023-28703. Buffer overflow. A remote attacker with administrator privileges can exploit this vulnerability to execute arbitrary system commands, disrupt the system or terminate service. (Base score: 7.2 HIGH.)
  • CVE-2023-31195. Session hijack. Sensitive cookies used without the Secure attribute set. An attacker could use a bogus HTTP (unencrypted) web link to hijack authentication tokens that shouldn’t be transmitted unencrypted. (NO SCORE.)

Perhaps the most notable bug in this list is CVE-2023-28702, a command injection attack that sounds similar to the MOVEit bugs that have been all over the news lately.

As we explained in the wake of the MOVEit bug,s a command parameter that’s sent in a web URL, for example a request asking the server to start logging you on as the user DUCK, can’t be handed off directly to a system-level command by blindly and trustingly copying raw text from the URL.

In other words, the request:

https://example.com/?user=DUCK

…can’t simply be converted via a direct “copy-and-paste” process into a system command such as:

checkuser --name=DUCK

Otherwise, an attacker could try to logon as:

https://example.com/?user=DUCK;halt

…and trick the system into running the command:

checkuser --name=DUCK;halt

…which is the same as issuing the two separate commands below, in sequence:

checkuser --name=DUCK
halt

…where the command on the second line shuts down the whole server.

(The semicolon acts as a command separator, not as part of the command-line arguments.)

Session hijacking

Another worrying bug is the session hijack issue caused by CVE-2023-31195.

As you probably know, servers often handle web-based logins by sending a so-called session cookie to your browser to denote that “whoever knows this cookie is assumed to be the same person who just logged in”.

As long as the server doesn’t give you one of these magic cookies until after you’ve identified yourself, for example by presenting a username, a matching password and a valid 2FA code, then an attacker would need to know your login credentials to get authenticated as you in the first place.

And as long as neither the server nor your browser ever accidentally sends the magic cookie over a non-TLS, unencrypted, plain old HTTP connection, then an attacker won’t easily be able to lure your browser to an imposter server that’s using HTTP instead of HTTPS, and thus to read out the cookie from the intercepted web request.

Remember that luring your browser to an imposter domain such as http://example.com/ is comparatively easy if a crook can temporarily trick your browser into using the wrong IP number for the example.com domain.

But luring you to https:/example.com/ means that the attacker also needs to come up with a convincingly forged web certificate, to provide fraudulent server validation, which is much harder to do.

To prevent this sort of attack, cookies that are non-public (either for privacy or access control reasons) should be labelled Secure in the HTTP header that’s transmitted when they’re set, like this:

Set-Cookie: AccessToken=ASC4JWLSMGUMV6TGMUCQQJYL; Secure

…instead of simply:

Set-Cookie: AccessToken=ASC4JWLSMGUMV6TGMUCQQJYL

What to do?

  • If you have an affected ASUS router (the list is here), patch as soon as you can. Just because ASUS left it for ages to get the patches to you doesn’t mean that you can take as long as you like to apply them, especially now that the bugs involved are a matter of public record.
  • If you can’t patch at once, block all inbound access to your router until you can apply the update. Note that just preventing HTTP or HTTPS connections (web-based traffic) is not enough. ASUS explicitly warns that any incoming network requests could be abused, so even port forwarding (e.g. for games) and VPN access need to be blocked outright.
  • If you’re a programmer, sanitise thine inputs (to avoid command injection bugs and memory overflows), don’t wait months or years to ship patches for high-scoring bugs to your customers, and review your HTTP headers to ensure that you’re using the most secure options possible when exchanging critical data such as authentication tokens.
spot_img

Latest Intelligence

spot_img

Copyright @ 2024 Plato Technologies Inc.

Chat with us

Hi there! How can I help you?