Mission : Get the root flag on `Pipe` which is a deliberately vulnerable virtual machine hosted at https://www.vulnhub.com/. The virtual machine can be downloaded at https://www.vulnhub.com/entry/hacklab-vulnix,48/. I quickly loaded up the virtual machine into my VMWare Player and i was good to go !
Detailed Steps for getting root:
A nmap scan of the box reveals a number of services running on the box such as ssh, smtp, finger, pop3, imap , rlogin , rexec, rshell and nfs.
Our attention is drawn to a number of services which we would typically not see exposed such as finger, rlogin services and nfs.NFS protocol allows a user on a client system to access a folder on the network as if it were present locally. Poorly configured NFS services are known be exploitable.[ If we remember there is a exercise in Metaspoitable that deals excursively on attacking the NFS protocol for getting root]. Hence we go for this service and enumerate if we can mount a share locally.
We see the the /home/vulnix directory can be mounted and we mount it on our attacking box. However we are unable to see the contents of the directory as we keep getting a permission error. We get this error because we are root on our attacking machine and we are trying to access a non root owned directory on the target system. We guess that this is because the NFS /etc/exports file (https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-nfs-server-config-exports.html) may have the root_squash permission turned on which squashes the permissions of the root client to the lowest user to prevent unauthorized alteration by a client on the nfs shared directory. In order to view the contents in the mounted directory we need to acess the nfs drive as a user with the same uid and guid as the vulnix user on the target box. Since we dont know the uid and guid of the vulnix user we do some further enumeration on the box.
We see that the smtp service is running of the box. There exisits a metasploit auxilliary module that helps us enumerate all the valid users accounts on the smtp server. We use this module as follows
The module has identified a number of user accounts on the box. The `user` account catches our attention. We guess that accounts maye be reused and use the finger service to determine if its possible to login to this box via the `user` account.
Clearly an account called `user` can be used to login to the box. With no other information available we attempt to bruteforce the ssh service with this user account. After a few minutes we are able to bruteforce successfully ! ! The credentials for this account are user:letmein . Now we can login to the box as `user`.
Once we login we see another user called vulnix. We take note of the uid and giud of this user (2008 in both case). We shall attempt to create a user with the same uid and guid on our client box. Hopefully this will solve out permissions problem and we will be able to elevate our priv to vulnix .
Now on the attacking box we create a testuser with the same uid and guid .
Now after we mount the /home/vulnix directory we no longer see the permission problem !
Detailed Steps for getting root:
A nmap scan of the box reveals a number of services running on the box such as ssh, smtp, finger, pop3, imap , rlogin , rexec, rshell and nfs.
Our attention is drawn to a number of services which we would typically not see exposed such as finger, rlogin services and nfs.NFS protocol allows a user on a client system to access a folder on the network as if it were present locally. Poorly configured NFS services are known be exploitable.[ If we remember there is a exercise in Metaspoitable that deals excursively on attacking the NFS protocol for getting root]. Hence we go for this service and enumerate if we can mount a share locally.
We see the the /home/vulnix directory can be mounted and we mount it on our attacking box. However we are unable to see the contents of the directory as we keep getting a permission error. We get this error because we are root on our attacking machine and we are trying to access a non root owned directory on the target system. We guess that this is because the NFS /etc/exports file (https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-nfs-server-config-exports.html) may have the root_squash permission turned on which squashes the permissions of the root client to the lowest user to prevent unauthorized alteration by a client on the nfs shared directory. In order to view the contents in the mounted directory we need to acess the nfs drive as a user with the same uid and guid as the vulnix user on the target box. Since we dont know the uid and guid of the vulnix user we do some further enumeration on the box.
We see that the smtp service is running of the box. There exisits a metasploit auxilliary module that helps us enumerate all the valid users accounts on the smtp server. We use this module as follows
The module has identified a number of user accounts on the box. The `user` account catches our attention. We guess that accounts maye be reused and use the finger service to determine if its possible to login to this box via the `user` account.
Clearly an account called `user` can be used to login to the box. With no other information available we attempt to bruteforce the ssh service with this user account. After a few minutes we are able to bruteforce successfully ! ! The credentials for this account are user:letmein . Now we can login to the box as `user`.
Once we login we see another user called vulnix. We take note of the uid and giud of this user (2008 in both case). We shall attempt to create a user with the same uid and guid on our client box. Hopefully this will solve out permissions problem and we will be able to elevate our priv to vulnix .
Now on the attacking box we create a testuser with the same uid and guid .
Now after we mount the /home/vulnix directory we no longer see the permission problem !
No comments:
Post a Comment