Root SSH


While I was scanning the target system with PEAS to search for potential privilege escalation vectors, I found something very interesting

daemon@lame:/$ ll /root/.ssh/
total 16K
4.0k drwxr-xr-x 13 root root 4.0k apr  4 22:10 ..
4.0K drwxr-xr-x  2 root root 4.0K May 20  2012 .
4.0K -rw-r--r--  1 root root  442 May 20  2012 known_hosts
4.0K -rw-r--r--  1 root root  405 May 17  2010 authorized_keys

The SSH directory of the root user is accessible by anyone with the READ permission bit set

daemon@lame:/$ cat /root/.ssh/authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEApmGJFZNl0ibMNALQx7M6sGGoi4KNmj6PVxpbpG70lShHQqldJkcteZZdPFSbW76IUiPR0Oh+WBV0x1c6iPL/0zUYFHyFKAz1e6/5teoweG1jr2qOffdomVhvXXvSjGaSFwwOYB8R0QxsOWWTQTYSeBa66X6e777GVkHCDLYgZSo8wWr5JXln/Tw7XotowHr8FEGvw2zW1krU3Zo9Bzp0e0ac2U+qUGIzIu/WwgztLZs5/D9IyhtRWocyQPE+kcP+Jz2mt4y1uA73KqoXfdw5oGUkxdFo9f1nu2OwkjOc+Wv8Vw7bwkf+1RgiOMgiJ5cCs4WocyVxsXovcNnbALTp3w== msfadmin@metasploitable
 
daemon@lame:/$ cat /root/.ssh/known_hosts
|1|gS7DWzAxRvtufzEYnaW40GOvYu0=|5afWvF6s4R5Yaog0mimuOyNfXiI= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAstqnuFMBOZvO3WTEjP4TUdjgWkIVNdTq6kboEDjteOfc65TlI7sRvQBwqAhQjeeyyIk8T55gMDkOD0akSlSXvLDcmcdYfxeIF0ZSuT+nkRhij7XSSA/Oc5QSk3sJ/SInfb78e3anbRHpmkJcVgETJ5WhKObUNf1AKZW++4Xlc63M4KI5cjvMMIPEVOyR3AKmI78Fo3HJjYucg87JjLeC66I7+dlEYX6zT8i1XYwa/L1vZ3qSJISGVu8kRPikMv/cNSvki4j+qDYyZ2E5497W87+Ed46/8P42LNGoOV8OcX/ro6pAcbEPUdUEfkJrqi2YXbhvwIJ0gFMb6wfe5cnQew==

I am also able to read both files inside as well. While being able to read public SSH keys alone doesn’t really get me anywhere, I see that the public key is assigned to msfadmin@metasploitable

metasploitable is an intentionally vulnerable Linux machine developed by Rapid7 for security research purpose, and msfadmin is one of the system users in it. Could this potentially mean that the target system had already been compromised? so that the attacker(msfadmin) from metasploitable had already overwritten the public SSH key to the SSH directory of the root user?

if that is the case, the public ssh key itself might be vulnerable as it must have been generated from the metasploitable machine, which uses an older debian linux that was vulnerable to [[lame_privilege_escalation_2#cve-2008-0166|CVE-2008-0166]]