ASUSwrt Password Sent in Cleartext

[arsenull]

First off, I really like asuswrt and greatly appreciate the work by the devs.

I noticed that when logging into the router via web browser (locally) the authentication is done using HTTP Basic Auth, which sends the username: password information with only base64 encoding (versus HTTP Digest which sends hashes).

Although unlikely, this is a big security hole for anyone sniffing on the network. Assuming it is the same when logging in via WAN (if enabled), then that security hole is even bigger.

Also, when changing the password the new password is sent to the router in cleartext using HTTP POST params.

My question is, is this deeply integrated into the ASUS firmware? Or would it be possible to use hashes for authentication rather than the password, which is a best-practice for security reasons.

Or is there an option I am overlooking to change this?

Thanks

 

[netware5]

Just don't use HTTP! Use HTTPS instead:

Menu>Administration>Authentication Method

 

[arsenull]

Just don't use HTTP! Use HTTPS instead:

Menu>Administration>Authentication Method

Yes, that is a good recommendation. However, I don't think it solves the underlying problem. Security should be in-depth (layers), and the router is only using a self-signed cert for HTTPS.
Another thing, if the client is sending the actual password (only base64 encoded) to the router, I can only assume the router is storing the actual password for comparison (rather than a hash), which is another best practice no-no.

HTTPS is great, but it isn't bullet proof. There are several MITM attacks for compromising HTTPS sessions. That is why security in-depth is so important, layers of security greatly increase overall security.

 

[Nullity]

...
Security should be in-depth (layers), and the router is only using a self-signed cert for HTTPS.
...

How could the router use anything but a self-signed cert for the initial connection? What alternative do you recommend for local domains?

The practice of CAs giving out certs for local domains is deprecated and all certs issued to local domains will be revoked by October, 2016. https://cabforum.org/internal-names/

 

[arsenull]

How could the router use anything but a self-signed cert for the initial connection? What alternative do you recommend for local domains?

The practice of CAs giving out certs for local domains is deprecated and all certs issued to local domains will be revoked by October, 2016. https://cabforum.org/internal-names/

An internal CA system is what you would generally see in an enterprise environment. But that's irrelevant, and honestly it was just a side-comment that in retrospect is obvious and unrelated.

The point of that response though was that HTTPS isn't a solution to the actual problem I originally asked about.

 

[RMerlin]

Yes, that is a good recommendation. However, I don't think it solves the underlying problem. Security should be in-depth (layers), and the router is only using a self-signed cert for HTTPS.
Another thing, if the client is sending the actual password (only base64 encoded) to the router, I can only assume the router is storing the actual password for comparison (rather than a hash), which is another best practice no-no.

HTTPS is great, but it isn't bullet proof. There are several MITM attacks for compromising HTTPS sessions. That is why security in-depth is so important, layers of security greatly increase overall security.

HTTPS is more than sufficient for a home network, which is the market targeted by these home gateways. If you need business-class security, you should probably be buying such a product. There's a reason why these are far more expensive.

 

[arsenull]

HTTPS is more than sufficient for a home network, which is the market targeted by these home gateways. If you need business-class security, you should probably be buying such a product. There's a reason why these are far more expensive.

Definitely understandable! I am a home network user, but just a paranoid one

Out of curiosity though, how deeply integrated is the use of the actual password in authentication vs. the use of a hash? I'm assuming it's deeply in the original ASUSwrt firmware?

Thanks for all the replies!

 

[Nullity]

The point of that response though was that HTTPS isn't a solution to the actual problem I originally asked about.

Yeah? Well, you know, that's just like, your opinion, man. You can always ditch the consumer router and setup OpenBSD as your router.

Just use HTTPS. HTTP digest is not a secure choice and is also vulnerable to MITM attacks.

If you are seriously concerned with security, create your own signed cert and transfer it to the router via USB flash drive.

 

[arsenull]

Yeah? Well, you know, that's just like, your opinion, man. You can always ditch the consumer router and setup OpenBSD as your router.

Just use HTTPS. HTTP digest is not a secure choice and is also vulnerable to MITM attacks.

If you are seriously concerned with security, create your own signed cert and transfer it to the router via USB flash drive.

It is in fact not a solution to the problem. The problem is that the actual password is being sent, not a hash. Solutions to that problem may have their own potential attack surfaces (such as HTTP digest, as you suggested), but such solutions could still increase security from a "security in-depth" perspective. This problem is irrelevant to HTTPS being used or not.

The thread was just a query into the potential for increasing this firmwares security in one aspect. Nothing more.

 

[Nullity]

It is in fact not a solution to the problem. The problem is that the actual password is being sent, not a hash. Solutions to that problem may have their own potential attack surfaces (such as HTTP digest, as you suggested), but such solutions could still increase security from a "security in-depth" perspective. This problem is irrelevant to HTTPS being used or not.

The thread was just a query into the potential for increasing this firmwares security in one aspect. Nothing more.

Yeah, I get your point, HTTPS is acting like a band-aid hiding the plain text "mistake". Though, plain text through HTTPS is still more secure than HTTP digest through HTTP.

I suppose implementing a more secure HTTP authentication method would possibly improve overall security but if you are using HTTP... you obviously do not care about security. HTTPS is still there for those with security concerns.

 

[tsunami2311]

intresting i never realized router login was sent via HTTP by defualt would thought it would defualt to HTTPs

 

[arsenull]

Yeah, I get your point, HTTPS is acting like a band-aid hiding the plain text "mistake". Though, plain text through HTTPS is still more secure than HTTP digest through HTTP.

I suppose implementing a more secure HTTP authentication method would possibly improve overall security but if you are using HTTP... you obviously do not care about security. HTTPS is still there for those with security concerns.

Yeah, that is what I was thinking. I am more curious than anything how deep it is integrated into the original firmware. HTTPS is definitely a big help in this case, although I didn't realize at first (naively) that HTTP was the default.

If the user isn't using WAN web access to their router and is using HTTPS I think the attack surface is extremely small.

 

[tsunami2311]

would know, though i would think HTTPS would be default in this day in age.

 

[RMerlin]

Definitely understandable! I am a home network user, but just a paranoid one

Out of curiosity though, how deeply integrated is the use of the actual password in authentication vs. the use of a hash? I'm assuming it's deeply in the original ASUSwrt firmware?

Thanks for all the replies!

The authentication code is in the httpd daemon. However the admin user account is reused in other places of the firmware, for instance as a default username for PPTP accounts, for AiCloud logins, etc... So just storing a hash would require all those other services that also support the same user acount to be adapted. In the case of AiCloud it's not possible since it's closed source.

 

[arsenull]

The authentication code is in the httpd daemon. However the admin user account is reused in other places of the firmware, for instance as a default username for PPTP accounts, for AiCloud logins, etc... So just storing a hash would require all those other services that also support the same user acount to be adapted. In the case of AiCloud it's not possible since it's closed source.

Thank you for the thorough answer, exactly what I was looking for!

Also, thanks again for your work

 

[aph]

The router doesn't have to use a self signed cert or rely on enterprise CA chain of trust, which still terminates with a self signed cert without public audit records.

An issuer will issue a cert for any valid domain name. Pick one and register it. Assign the router to identify itself as a host on that network. Set up an A record in DNS matching that host name to the router's public IP. Access the router through the new host name.

Importing the cert and associating it with incoming connections will serve it and not generate any security warnings if the connection has not been compromised.

 

[Nullity]

The router doesn't have to use a self signed cert or rely on enterprise CA chain of trust, which still terminates with a self signed cert without public audit records.

An issuer will issue a cert for any valid domain name. Pick one and register it. Assign the router to identify itself as a host on that network. Set up an A record in DNS matching that host name to the router's public IP. Access the router through the new host name.

Importing the cert and associating it with incoming connections will serve it and not generate any security warnings if the connection has not been compromised.

Browsers need to drop those stupid security warnings anyway. The whole CA thing needs to be evolved. When normal users become accustomed to seeing those warnings and dismissing them, that is bad.

Seems like major overkill to pay for a public domain and CA for your consumer router.

 

[aph]

Browsers need to drop those stupid security warnings anyway. The whole CA thing needs to be evolved. When normal users become accustomed to seeing those warnings and dismissing them, that is bad.

Seems like major overkill to pay for a public domain and CA for your consumer router.

Yes unless you already have both. I have a domain for other purposes, and a wildcard cert for that domain. So increasing security with this setup does not add any cost.

 

[arsenull]

Browsers need to drop those stupid security warnings anyway. The whole CA thing needs to be evolved. When normal users become accustomed to seeing those warnings and dismissing them, that is bad.

Seems like major overkill to pay for a public domain and CA for your consumer router.

I agree completely. That's part of the reason why I dismissed the HTTPS as only a "self-signed cert", given that users are unlikely to check if it is because it is self-signed that they have to click through the exception warnings, or because it is a MITM attack.

 

[Nullity]

Yes unless you already have both. I have a domain for other purposes, and a wildcard cert for that domain. So increasing security with this setup does not add any cost.

For a local network, how is a public CA more secure than if I sign the cert myself?