RPC server might leak basic auth credentials in plaintext

[jsdanielh]

Link: https://hackerone.com/reports/2491451
Date: 2024-05-06 07:36:47 UTC
By: ryanrb
Weakness: Cleartext Transmission of Sensitive Information

Details:

Summary

The RPC server does not appear to mandate that TLS is required for connections. Given that basic auth can optionally be enabled via config, it may be possible for the credentials to be leaked in plaintext under some circumstances.

Project: core-rs-albatross
File reference: lib/src/extras/rpc_server.rs
Line: 67

// Configure RPC server
let basic_auth = config.credentials.map(|credentials| Credentials {
    username: credentials.username,
    password: credentials.password,
});

// ...

Ok(Server::new(
    Config {
        bind_to: (config.bind_to.unwrap_or_else(default_bind), config.port).into(),
        enable_websocket: false,
        ip_whitelist: None,
        basic_auth,
    },
    AllowListDispatcher::new(dispatcher, allowed_methods),
))

Recommendation

If basic auth credentials are being used, it is reasonable to assume that the individual configuring the server desires a secure setup. In order to prevent the basic auth credentials from being leaked or intercepted, the server should not be allowed to start using basic auth unless TLS is enabled.

Alternatively, a more secure mechanism for handling authentication and authorization could be used.

References:

• CWE-319

Impact

Basic auth credentials are notorious for the weakness that the username and password are transmitted in plaintext base64 format over the wire. As mentioned above, a user which is taking the time to enable basic auth likely wants the security guarantees of being protected with credentials. If the user configuring the server has unintentionally run the server in an insecure way, the basic auth credentials could be intercepted, compromising the RPC server and all of the capabilities it provides.

[hrxi]

Not sure if we should do something about this. You usually shouldn't expose this to the internet, and if you do, it should probably go behind a reverse proxy like nginx that will handle the HTTPS part. Maybe we should add some warnings to the documentation?