Summary
A missing authentication check in goshs's SFTP server allows clients to access files without providing valid credentials when certain flags are used together.
Under specific startup options, both SFTP authentication handlers are left unset, effectively turning on anonymous SFTP access where authentication is expected.
A missing authentication check in goshs's SFTP server allows clients to access files without providing valid credentials when certain flags are used together.
Under specific startup options, both SFTP authentication handlers are left unset, effectively turning on anonymous SFTP access where authentication is expected.
Affected context
This vulnerability arises when goshs is run as an SFTP server with a specific combination of flags:
- SFTP mode enabled (e.g.,
-sftp) - A basic auth configuration specifying a username but an empty password (e.g.,
-b 'admin:') - No forced key file configured (no
-fkfflag)
In this configuration, the password handler logic fails to attach any SFTP authentication mechanism, so clients can connect and access files without supplying a username or password, despite an apparent configuration that suggests authentication should be required.
This vulnerability arises when goshs is run as an SFTP server with a specific combination of flags:
- SFTP mode enabled (e.g.,
-sftp) - A basic auth configuration specifying a username but an empty password (e.g.,
-b 'admin:') - No forced key file configured (no
-fkfflag)
In this configuration, the password handler logic fails to attach any SFTP authentication mechanism, so clients can connect and access files without supplying a username or password, despite an apparent configuration that suggests authentication should be required.
Exploit preconditions
- Attack surface: Network-exposed goshs SFTP endpoint.
- Required access: Ability to reach the SFTP port (e.g., from the same network or over the internet if exposed).
- Trigger point: goshs started with SFTP enabled, a non-empty username and empty password in basic auth, and no forced key file.
- Why exploitation is possible: The password handler validates only that the configured username and password are non-empty. When the password is empty, both SFTP authentication handlers remain unset, and the server effectively accepts unauthenticated SFTP sessions.
- Attack surface: Network-exposed goshs SFTP endpoint.
- Required access: Ability to reach the SFTP port (e.g., from the same network or over the internet if exposed).
- Trigger point: goshs started with SFTP enabled, a non-empty username and empty password in basic auth, and no forced key file.
- Why exploitation is possible: The password handler validates only that the configured username and password are non-empty. When the password is empty, both SFTP authentication handlers remain unset, and the server effectively accepts unauthenticated SFTP sessions.
Why this happens
The bug stems from relying on a simple non-empty check (Username != "" && Password != "") as the gate for enabling SFTP authentication handlers.
When administrators configure a username with an intentionally blank password, the logic concludes that authentication is not configured and skips attaching any SFTP authentication callbacks. This falls under CWE-306: Missing Authentication for Critical Function, because the server exposes a sensitive file-access interface without enforcing any verification of client identity.
Conceptually, the implementation conflates "no authentication configured" with "authentication configured but weakly defined," leading to the critical case where the security mechanism is silently disabled instead of failing closed.
The bug stems from relying on a simple non-empty check (Username != "" && Password != "") as the gate for enabling SFTP authentication handlers.
When administrators configure a username with an intentionally blank password, the logic concludes that authentication is not configured and skips attaching any SFTP authentication callbacks. This falls under CWE-306: Missing Authentication for Critical Function, because the server exposes a sensitive file-access interface without enforcing any verification of client identity.
Conceptually, the implementation conflates "no authentication configured" with "authentication configured but weakly defined," leading to the critical case where the security mechanism is silently disabled instead of failing closed.
Potential impact
- Unauthenticated users may read files exposed via the goshs SFTP server.
- Unauthenticated users may upload or modify files, depending on SFTP configuration and permissions.
- Attackers could exfiltrate sensitive data stored in the SFTP-served directory.
- Malicious uploads could be used to stage additional attacks or distribute malware.
- Logs and audit trails may incorrectly suggest authenticated use, complicating incident response.
- Unauthenticated users may read files exposed via the goshs SFTP server.
- Unauthenticated users may upload or modify files, depending on SFTP configuration and permissions.
- Attackers could exfiltrate sensitive data stored in the SFTP-served directory.
- Malicious uploads could be used to stage additional attacks or distribute malware.
- Logs and audit trails may incorrectly suggest authenticated use, complicating incident response.
General mitigation guidance
Mitigation focuses on ensuring SFTP interfaces always fail closed and never run without explicit, enforced authentication:
- Treat configuration states with empty or partial credentials as invalid and refuse to start the SFTP server in those cases.
- Require explicit, non-empty credentials or key-based authentication when enabling SFTP, and validate configuration at startup.
- Design authentication logic so that handlers are always attached, with a default "deny all" behavior if configuration is incomplete or ambiguous.
- Encourage use of key-based authentication for SFTP, combined with least-privilege file system permissions and isolation of served directories.
- Document clearly that "empty password" or placeholder credentials are not accepted as a secure configuration and will cause startup errors.
Mitigation focuses on ensuring SFTP interfaces always fail closed and never run without explicit, enforced authentication:
- Treat configuration states with empty or partial credentials as invalid and refuse to start the SFTP server in those cases.
- Require explicit, non-empty credentials or key-based authentication when enabling SFTP, and validate configuration at startup.
- Design authentication logic so that handlers are always attached, with a default "deny all" behavior if configuration is incomplete or ambiguous.
- Encourage use of key-based authentication for SFTP, combined with least-privilege file system permissions and isolation of served directories.
- Document clearly that "empty password" or placeholder credentials are not accepted as a secure configuration and will cause startup errors.
How teams detect issues like this
Several approaches can help identify this class of misconfiguration-driven missing authentication:
- Code-level review: Look for authentication setup guarded solely by non-empty string checks, especially around network listeners and file-transfer endpoints; ensure incomplete credentials cannot disable authentication logic.
- Static analysis: Define rules that flag critical services where authentication handlers are conditionally omitted based on configuration, or where default paths allow anonymous access.
- Runtime validation: Implement startup self-checks that verify authentication is active for all SFTP endpoints and log or abort when it is not; integrate these checks into deployment pipelines.
- Security testing: Use automated and manual penetration tests to attempt SFTP connections without credentials whenever a new configuration is deployed, and alert if access is granted.
Several approaches can help identify this class of misconfiguration-driven missing authentication:
- Code-level review: Look for authentication setup guarded solely by non-empty string checks, especially around network listeners and file-transfer endpoints; ensure incomplete credentials cannot disable authentication logic.
- Static analysis: Define rules that flag critical services where authentication handlers are conditionally omitted based on configuration, or where default paths allow anonymous access.
- Runtime validation: Implement startup self-checks that verify authentication is active for all SFTP endpoints and log or abort when it is not; integrate these checks into deployment pipelines.
- Security testing: Use automated and manual penetration tests to attempt SFTP connections without credentials whenever a new configuration is deployed, and alert if access is granted.
