T09 · Insecure Skill Coding Practices
- Location
SKILL.md:153- Finding
SSH Host Verification Disabled for Wildcard Hosts
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 153-158
Vulnerability Type:T09: Insecure Skill Coding Practices
Risk Level: HighVulnerable Code
text Host *.dev.example.com User developer IdentityFile ~/.ssh/dev_key StrictHostKeyChecking no UserKnownHostsFile /dev/nullTechnical Analysis
StrictHostKeyChecking nopermits SSH connections without requiring the user to validate an unknown host key. SettingUserKnownHostsFile /dev/nulladditionally prevents accepted host keys from being retained for future comparison.Together, these settings remove the persistent trust relationship that normally allows an SSH client to detect server impersonation or an unexpected host-key change. The configuration applies to every host matching
*.dev.example.com, increasing the affected scope beyond a single explicitly identified development system.Attack Path
- A user adopts the documented wildcard SSH configuration.
- An attacker gains a network interception position or redirects a matching hostname through DNS, routing, or local network manipulation.
- The attacker presents an arbitrary SSH host key while impersonating the intended server.
- Because strict host-key checking is disabled and no host keys are retained, the client connects without providing effective identity-change protection.
- The user authenticates to and exchanges data with the attacker-controlled SSH endpoint.
- The attacker can inspect data delivered to that endpoint, present a deceptive remote environment, and intercept traffic or files intentionally sent through the connection.
Impact Assessment
Successful exploitation compromises server authenticity and the confidentiality and integrity of the affected SSH session. Depending on how the connection is used, exposed assets may include passwords entered into the impersonated endpoint, commands, transferred files, remote service tra ...[truncated 394 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove both
StrictHostKeyChecking noandUserKnownHostsFile /dev/null. - Retain OpenSSH's normal
known_hostsverification and require explicit confirmation for previously unknown hosts. - Provision expected host keys through an authenticated administrative channel before the first connection.
- For managed environments, use SSH host certificates signed by a trusted host certificate authority.
- If
ssh-keyscanis used for provisioning, independently verify the resulting fingerprint; network retrieval alone does not establish authenticity. - Avoid applying weakened security controls to wildcard host patterns.
- If disposable test systems require special handling, isolate the exception to a specific host alias and document the residual impersonation risk.
- Remove both
