In my last post, I did a walkthrough for the VulnHub box The Planets: Mercury. This box was conceived and implemented to be low hanging fruit for people who enjoy Capture the Flag (CTF) exercises. The advice for much of what we used to gain our initial foothold are pretty basic. The advice should be pretty familiar to anyone who takes security hygiene seriously and certainly anyone who is running a production web server. Additionally, Injection (SQL and otherwise) is on the OWASP Top 10 consistently. It should be one of the things that should be checked and remediated early, but often isn’t. Nevertheless, we weren’t splitting atoms to find it or to suggest how to fix it. Here are the basic “Don’ts” from the Mercury CTF:
- Don’t leave default error pages in place
- Don’t leave public “to do” lists
- Don’t construct SQL Queries using blind concatenation
- Don’t leave text files with passwords in plain text (or any encoding) on the server
But none of those are how we gained root on the box. We took advantage of a misconfiguration on the server that was intended to let the user read from a log file. The Mercury box wanted to allow the user to read records from the /var/log/syslog file. Normally, that file requires elevated permissions to read it. The Admins on this example box chose to create a script that reads the last 10 lines from the file and then gave the user permissions to run sudo on this script. Unfortunately, we were able to use symlinks to cause that script to allow us to ultimately open a root shell instead.
But what could the Admins have done differently? The best solution here is probably using Access Control Lists (acls). Linux file systems for a few generations have supported these by default. To work with them, we can just install a package and then configure the permissions.
Take a look at these simple commands that could have prevented this avenue of privesc on Mercury.
# Install the acl package # In Debian-based systems sudo apt-get install acl # In RedHat-based systems sudo yum install acl # See if your file systems supports ACLs grep acl /etc/mke2fs.conf # If they do, you will see acl in the default mount options default_mntopts = acl,user_xattr # If not, you should be able to run this command to set it up # This has not been tested by me, as every Linux box I could find already had the permissions sudo mount -o remount,acl / # Looking at the ACL on the file to start, we see that I (user) have read and write # the adm group has read, and everyone else has no permissions. getfacl /var/log/syslog # Output getfacl: Removing leading '/' from absolute path names # file: var/log/syslog # owner: syslog # group: adm user::rw- group::r-- other::--- # Now I'm going to configure a user to have read permissions using # setfacl which was added when we installed the acl package sudo setfacl -m u:exampleuser:r /var/log/syslog # Let's check again getfacl /var/log/syslog # Output getfacl: Removing leading '/' from absolute path names # file: var/log/syslog # owner: syslog # group: adm user::rw- user:exampleuser:r-- group::r-- mask::r-- other::--- # You notice that now we have another user row in the output, saying # that example user has read permissions on the file
That’s it! It took me a total of less than two minutes and this avenue of escalation could have been prevented. This is a good example of how thinking like an attacker can help you be a better Administrator if you think about how every change you make to a system could be exploited and then think about a better way. When in doubt, look for guidance, don’t get “creative”.