#penetesting

So -after scratching my head over 0x08 for several days- I’ve decided to call it quits with SmashTheTux; I completed every challenge apart from the last (see my blog for earlier walkthroughs.)

Nonetheless, I really think SmashTheTux is a valuable experience for those interested in exploring virus and exploit development in the future (I say virus dev as the challenges force you to think more low-level.)

I’d also say -to a degree- it’s ideal for OSCP buffer overflow prep: not only is the first challenge a simple B/O similar to what you’ll encounter in the exam, but the experience of completing the 8 challenges (or 9; from the brief research I did, no one has managed to exploit 0x08) is also useful for building your confidence with using GDB and interacting with programs at a lower level.

Additionally, I found some of the challenges interesting as they required you to think independently of ways you  could change the control flow of the program to achieve the desired reuslt- for example, I completed 0x04 (integer overflow) in a way different to hinted at (this is why I don’t look at hints- encourage that creative thinking, man!) and I feel there would have been a few interesting ways to exploit 0x05 (will be below somewhere.)

All in all, I definitely recommend this machine to anyone intrigued by low-level exploit development or to those who want to build their confidence in the use of GDB.

Anyway, enough rambling, time for my last 3 exploits.

0x05

Well, it’s lucky I don’t look at hints! 0x05 was a very basic program- a call is made to system which executes the passed parameter as a terminal command, displaying the contents of /home/tux and then exiting.

The only input we have control over here is the files that appear within /home/tux; as the output of the command is not being placed in any sort of limited buffer or printf call, there’s little we can expect to achieve here.

So... What we need to do is hijack the call to ls which is actually pretty simple:

These are the commands I used to redirect the call to ls- first I created /tmp/ls and inserted the directory of /bin/sh before changing the permissions on /tmp/ls.

Finally, I added /tmp to the PATH environment variable- that’s it. Very simple but very effective.

When ls executes, the shell will look for a program file called ‘ls’ within the shell’s environment (aka: it will check each directory specified in the PATH environment variable for an executable file named ‘ls’)

Since /tmp is now the first directory within the variable, it will look there first and execute our modified /ls file as a result. It kind of acts like a symbolic link- when /tmp/ls is executed, the shell will execute the line ‘/bin/sh’.

This challenge could have potentially be completed by creating an alias for ‘ls’ also, to be honest there’s probably a few little tricks that could have been done here!

Although not directly related to C vulnerabilities, it does demonstrate the danger of loose access rights and permissions: it was my ability to change critical environment variables that made this possible.

0x06

Ah another hintless one, and here’s me feeling clever for not looking at the hints. xD

Here we have another format string vulnerability within sprintf (the same as printf but content is placed into the specified string as apposed to STDOUT); this time we are limited to input (not including the null) of 64 bytes.

Obviously this means EIP overwrite must occur within the first 64 bytes of input.

With some trial and error, I discovered that popping 10 addresses from the stack got us to the point of EBP/EIP overwrite- now to simply place our shellcode and jump to it.

I simply placed my shellcode at the end of the payload and -using GDB- found the rough location of the code.

From here I just played with the found address until I had execution outside of GDB.

0x07

0x07 was very interesting for me as it was my first encounter with malloc and heap overflow.

We have 3 declared pointers to member structs- m1, m2 and m3. M3 is never interacted with further from it’s declaration.

M1 and m2, however, are allocated a memory size of 8 bytes, given their own id values and a further 8 bytes allocation for their name properties.

The first two commandline arguments passed to the program are finally copied into the name properties of m1 and m2 respectively with no length checks on the provided arguments.

It took me a while to analyze my exploit for this- I understand everything so well at the time but then I find I’ve forgotten why it actually worked. (Note to self: work on organization!)

After looking into it again, however, I understand the logic behind this attack:

With the input provided to argv[1], we overwrite the value of m2 with the address of exit, occurring just 4 lines below the second strcpy- if our buffer is on the heap, any changes to the stack shouldn’t effect the value copied to exit. This is followed by basic shellcode starting at 0x804a030.

In the strcpy call to m2->name, we provide the start of our heap stored shellcode.

It’s been a while with life stuff getting it the way and whatnot; over last night and today I have rooted Stapler 1

(https://www.vulnhub.com/entry/stapler-1,150/) :)

I actually learned a few things from this- it was my first experience with enum4linux and SMB file shares; I’ve also identified my main areas of weakness with hacking (seems to be more web app based challenges and also lacking the needed organization and thoroughness.)

Enum4linux is now 1000000000% a part of my arsenal, actually think I’ll be going back to some machines I hit a roadblock on and running that against them.

Anyway, on with my solution.

Scans

I executed my custom enum script to begin, resulting in the feedback of a nice amount of open ports:

So, we have two web servers (NOTE: Must made amendments to my enum script to account for multi web servers!), VSFTPD, dnsmasq (DHCP and DNS server), Samba (a filesharing service), a listener on p666 that Nmap cannot identify and a MySQL server.

After running Nikto scans against the two websites, there were a few interesting points; I’ll confess- web apps are not my favorite thing. Thus I decided to look at the other running services before focusing my full attention on the web servers.

Enum4Linux

While researching Samba (after only noticing the open port a couple of hours after beginning the machine *frustrated sigh*), I read and saw the output for Enum4Linux and immediately knew it was a good idea to run this.

I will say: this script is great. It showed me existing users on the machine in addition to a considerable amount of information about the service of interest- SMB.

With the information discovered, I proceeded to harvest available files.

The share Kathy held some useful information about the in-use FTP server: the config file for the server was present which revealed the feature of anonymous login.

Obviously I then checked what was available to the anonymous user; there was merely a note instructing Elly to save ‘payload information’ to her FTP account.

There was also an SMB share named ‘tmp’ in which there was a file called ‘ls’ with the following output:

.: total 12.0K drwxrwxrwt  2 root root 4.0K Jun  5 16:32 . drwxr-xr-x 16 root root 4.0K Jun  3 22:06 .. -rw-r--r--  1 root root    0 Jun  5 16:32 ls drwx------  3 root root 4.0K Jun  5 15:32 systemd-private-df2bff9b90164a2eadc490c0b8f76087-systemd-timesyncd.service-vFKox

After this, I looked further at the output of the enum4linux script in order to identify users for brute force attacks against FTP, SSH and MySQL:

With users identified, I saved these names to a text file and utilized Nmap NSE scripts for the brute force of FTP and MySQL.

Results for FTP. :) logging on with either credentials reveals a whole list of files; in all honesty this is where my exploration of FTP ended as I tried the same credentials in SSH and found success.

So, now we have a stable connection to the system... Just one trick away from root privileges.

I ran my custom privesc script and -to my annoyance- this didn’t reveal the specific sh file; it did refer to cronjobs which gave me the idea to try that. I tried to exploit this without research and upon failure I moved on until hours after playing around with the use of exploits (goes without saying I’ve now amended my enum script to avoid that happening again!)

After several crashes from attempting Dirtyc0w, I began to get the feeling that I was approaching things wrong- I’d done it again, hadn’t I?

I’d jumped head first into the same rabbit hole I encountered when rooting Mr Robot... There’s usually ALWAYS a simpler way, Courtney... XD

I took a moment to look through my notes again and I focused on my first observation- the use of cron jobs to escalate privileges. In my defence I have never escalated privileges like this; in hindsight I gave up on that method far too quickly and I should have first researched privesc via cron jobs before moving onto researching exploits.

The echo command that failed shows what I added to the file cron-logrotate.sh. The file also initially has a note directed at a user that hints it could be used for malicious purposes (something like ‘something needs doing about this’)

This is why my initial attempt failed: I originally tried to append to logrotate and manually execute it before then creating a cronjob (thought this would be created under root but either I didn’t create the job correctly or I was wrong!)

As cron-logrotate is executed automatically depending on config and owned by root,  the script executes, changing the permissions and owner of our created file- it’s now owned by root and -when run- it will execute with root privileges due to the setting the uid bit.

Conclusion

Genuinely have learned alot from this machine-I have a few changes I’m going to make to my enum script (both to accomodate multi web servers and to point out running services) in addition to the amendments I’ve already made to my privesc script.

What frustrates me is that my slowness is more down to rushing ahead and being to eager to complete things rather than inability: I actually only noticed the presence of dnsmasq when writing this walkthrough (but this can be helped by amending my enum script.)

So, 0x04 was pretty easy- it was a simple integer overflow attack; in all honesty I solved this without analyzing the source code well and took the time to analyze it after.

I understand the flow of the C now since the analysis above. I may actually make it standard practice to do this before I look into exploitation as it might help my speed! But yeah... Bit of a silly one in my opinion: I don’t think you’d come across anything like this realistically.

The first two bytes of the given file are stored into bar.len.

If len+1 bitwise AND 0xff (255) is greater than 1024, “Bad dog.“ is returned- else the contents of the file is returned starting at offset 2...

What? Like was this challenge written at 2AM? :’)

Anyway, my approach was pretty clever in it’s simplicity- this is why I don’t look at hints, you find different ways to solve things!

My payload is pretty simple: <1034 padding/shellcode><4 bytes junk (originally I thought it was EBP since input here overflowed the EBP register; as the program exits normally after our shellcode without segfault I was wrong, probably because the file closes first and thus EBP is changed by this function)><4 byte EIP/NOP address><4 byte expected file pointer>

I found the file pointer address when providing 1043 bytes of input to the file and performing a backtrace via GDB: I could see that the offsets I’d provided were correct as EIP and EBP were populated, but without the correct file pointer the program was constantly segfaulting before the point of EIP execution.

The second address is the desired file pointer. I think this was needed as the execve call works by essentially replacing program memory with the memory of the new process, inheriting the relevant file descriptors to do this.

Our payload led to the file pointer’s (or ESI’s) LSB being overwritten by the terminating ‘0a‘ newline character, meaning it was invalid and attempts to close the file by execve before executing /bin/sh were unsuccessful.

Reflection

I don’t really think much of this challenge if I’m honest- I don’t think there’s any sort of scenario in which anyone would encounter code with logic as random as the above.

However, I did notice how much my understanding of stack attacks is developing at a low level: as I said, I basically constructed this payload myself from simple trial and error (and a bit of logic!)

The third challenge of the series hosted a vulnerability known as a race condition.

The ls shows public as a root file as this is where the file swapping finished execution, usually .readthis is the root file!

Here we see use of the stat system call to retrieve information on a given file (argv[1])

The st_uid and st_gid returned from struct are XORed with 1000 (this is what the UID and GID macros resolve to) before a bitwise AND is performed on the result of the two XOR operations.

If this returns 0 (false), then the requested file is opened and it’s contents printed, otherwise access is denied.

This likely isn’t a buffer overflow challenge: not only is contents passed correctly to fgets, our input is also not interacted with (other than argv[1] being passed to the stat call) prior to the comparison.

Due to this, I realized the aim is probably to change the values of st_uid/st_gid somehow in order to execute fopen... But how when all we have to play with prior to the check is the given filename?

So, to Google... After some research on C vulnerabilities I came across race conditions and what to look for- sure enough, the same vulnerability is present in this code.

At line 14, argv[1] is used in the stat system call and at line 20 in the call to fopen- this gives us a small window of opportunity to swap the value of the given file with another before the call to fopen...

Maybe we show swap the contents of .readthis with the contents of public?(literally just a file containing the string ‘PUBLIC’)

To do this, I used a very simple script from https://github.com/sroettger/35c3ctf_chals/blob/master/logrotate/exploit/rename.c-it simply executes the renameat2 system call in a while loop, replacing the contents of file A with file B.

While executing this, I also executed ./pwnme, passing .readthis as an argument in a while loop- if there’s a race condition, we should see output other than PUBLIC, Access Denied and Access Granted after a short period (output is the first image.)

Reflection

I found this challenge very interesting to work on and I understand why this works and -though I’m not 100%- I also may know why my first approach potentially didn’t (attempting to execute ln -sf ./public ./link ; ln -sf ./.readthis ./link in a while loop while also executing ./pwnme ./link)

My first approach may have taken too long to execute in the small window of time provided, or maybe fopen was attempting to directly access .readthis, thus causing an error (I did get a seg fault in a couple of the results from this attempt, perhaps the segfault was due to not having permission to access the file?)

The second challenge off SmashTheTux demonstrates improper use of the printf function.

If user input alone is provided to the function, printf will evaluate user input as both a command -to compensate for the lack of format specifier- and input to print.

For example, if our input is “a string %x”, printf(text) would ultimately resolve to printf(”a string %x”)- as an argument has not been supplied for the value of ‘%x’, printf will simply pop the first hexadecimal number from the stack in compensation (I hope this is a satisfactory explanation behind the vulnerability!)

Now, onto the actual exploit, I opted to overwrite the GOT entry of exit with the address of a malicious environment variable holding simple execve(”/bin/sh”) shellcode- this isn’t a completely foolproof exploit as it also relies on the user having the permissions to actually create environment variables; in the situation of a privileged user attempting to gain root privileges via an SUID binary or alike, it’s actually very effective.

This was what I came up with:

The first 8 bytes here shows the GOT entry of the binary’s exit function plus the address+2 (this is because $hn writes 2 bytes at a time, thus we need to perform 2 overwrites on the GOT entry- a 4 byte pointer. The lower 2 bytes start at 0x08049754-%4$hn, the upper 2 at 0x08049756-%5$hn.)

Next, I filled the stack with 49143 characters via the %<int>x specifier- this sends the current address at the top of the stack to stdout padded with whitespace to match the specified length. %5$hn will write the current amount of characters in the buffer to the fifth address on the stack (this is 0x08049756 the second address in the first section, the location discovered by leaking the stack with the %x format specifier.)

I then repeated this step for the lower two bytes at address 54.

You’re probably wondering what the Hell’s going on if you’ve never seen a format string exploit; it’s actually pretty simple once you grasp the logic:

The two large numbers above correspond to our desired address in hex- 49151=bfff while 65482=ffca. Since %n overwrites the specified value with the length of the buffer thus far, this is (one of) the only ways to achieve a value overwrite in the event of a format string vulnerability.

You can attempt to use %n to overwrite all four bytes at once; this can take a considerable amount of time to execute as stdout then has to display these characters (which can be well over a million, should be enough to make you understand!)

I discovered the location of my variable on stack via GDB:

Can you spot my code environment variable I’m too lazy to highlight? The difference in address is due to taking the screenshot at a different time (atleast I think- I definitely got 0xbfffffca from this command when executing the exploit!)

I also put an NOP sled at the beginning to change the length of the shellcode from 23 to 32 bytes (keeps the stack neatly aligned and reduces the chances of leftover stack values interfering with the shellcode execution.)

Not the best screenshot as the exploit produced a lot of whitespace but you can see by the need to close the process that it was successful.

The hint provided was this:

So yeah, I think I can consider this exploit a bit more of a success: I didn’t make any alarmingly obvious noob mistakes and I also learned a little more about the effect environment variables can have on a vulnerable application.

As exploit dev is something I want to explore in the future, I’ve decided to go back to basics to gain a real understanding of it.

SmashTheTux offers 9 C scripts hosting different variants of B/O vulnerability, I’m actually glad I started it as I’ve realized I still have alot I need to remember when doing these attacks...

So my exploit for 0x00 was this:

I was COMPLETELY on the wrong tracks really as I forgot one crucial point: the segfault is triggered when one byte of EBP is overwritten, not when all of them are. :’)

However, my exploit still works as I simply placed my shellcode into the buffer and then returned to it after the overflow is triggered (I originally thought 264 bytes overwrote the whole of EBP but yeah... Huge nope I’ve forgotten alot since I first looked at it! xD)

I believe this works as I didn’t place any return address after EBP, thus EBP was popped to the stack and executed; if I’m wrong on this I’d like to know as exploit dev is something I want to do in future.

But yeah it’s kinda a bittersweet win: I had the knowledge to just place the shellcode in the buffer and then jump to it, but my offsets were completely wrong and I would have never got the intended solution with them. :’)

Lessons:

A complete EBP (or RBP) overwrite will occur 4/8 bytes AFTER the initial segfault (which makes perfect sense as even a slight alteration of EBP could make it point to an invalid address -.-)

If the standard attack doesn’t work, you can always just use my method above- trigger the overflow and then place the start address of the malicious buffer on the stack.

After massively failing at Brainpan 2 for a few weeks, I thought I’d take a breather and collect the 3 possible keys from Mr. Robot. It’s frequently referred to as an ‘OSCP-like’ VM though it’s rating is only beginner-intermediate.

So, the usual: download the VM (https://www.vulnhub.com/entry/mr-robot-1,151/), import into Oracle VM VirtualBox and perform an nmap port scan of your network:

As .17 is the local IP of my Kali Linux instance, it’s obvious that our target is .19 (NOTE: if the VM does not appear, scan every port using ‘-p-’.)

Before commencing with further tests, I added .19 to /etc/hosts and executed a more thorough scan on Mr. Robot (nmap -sV -T5 mr-robot -p-); while this revealed the web servers listening on port 80 and 443 were Apache, there were no open ports beyond these.

Fair enough, time for some nikto and dirb!

Nikto has revealed that responses from the web servers indicate the presence of PHP 5.5.29 and WordPress, in addition to WordPress login portals. It has also flagged the presence of a directory named ‘admin’; upon attempting access, the request is simply looped and no useful data can be found.

I also took the opportunity to test out WPScan- a WordPress vulnerability scanner that comes preinstalled with Kali Linux. While this does show the presence of the XML-RPC API and confirms some of Nikto’s findings, it’s definitely not required.

Dirb continued to run and revealed the presence of robots.txt, in addition to various other pages leading to redirects or lacking any sort of data.

Upon visiting robots.txt, you receive indication of the presence of key 1 and a file of dic format.

For any person with experience in boot2root challenges, they’ll probably have already guessed the obvious path forward- head to the wp-login page found earlier and investigate fsocity.dic.

To remove duplicate lines, I piped the contents of fsocity.dic to sort -u and stored the results in a new file (cat fsocity.dic | sort -u > unique.txt)

I looked through the file briefly for anything resembling a username firstly and by trial and error I received confirmation of the existence of Elliot.

There we go, so now we just need a password; like I’m going to sit and manually try each possibility myself!

Here comes Bash to save the day (yes, I could have used this for users too but I wanted to see the change in error message for myself.)

Not the sexiest but who cares about appearance when  the result’s the same? We still know that the password is ER28-0652.

Surely enough, this password grants us access to the wp-admin dashboard. Although my first time infiltrating a system running WordPress on their web servers, it only took me a couple of minutes before I discovered the themes editor would allow me to alter PHP files… So, also my first experience with a PHP reverse shell!

I originally attempted to alter a php file on the active twentyfifteen theme but executing this in my browser yielded no reverse shell, thus I editted a PHP file of theme twentyfourteen (honestly any should work but I used 404.php)

Surely enough, we receive a stable connection from mr-robot through netcat from user Daemon; further investigation reveals the presence of /home/robot.

Hmm, I’ve never watched Mr Robot but for an alleged hacker- this is pretty laughable… He hashes his password with 1) a crackable hashing algorithm and 2) saves it into a file revealing the algorithm in use… Yeah if real companies are really this stupid then God help our data!

Anyway, let’s give it a run through Johnny with /usr/share/wordlists/rockyou.txt:

Wow, the alphabet… Isn’t he smart? Into Robot we go.

After making my usual mistake and jumping to the more complex methods of privilege escalation first (exploit delivery… ALWAYS run basic checks thoroughly first, https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/ is a really good checklist to follow and refer to if you’ve fell down a rabbit hole,) I discovered that the nmap binary was not only present on the machine; it’s permissions also meant that the program executed under the privileges of the owner, not the user responsible for execution.

From this point, you can simply execute ‘nmap –interactive’ and then ‘!sh’, giving you root access to the system- go ahead and grab key-3-of-3 from /root.

Points to take from Mr. Robot:

You should always look for the most simple forms of entry and test simple vulnerabilities first and thoroughly before looking further into a service (this is my main issue- I jump to investigating further too soon!)

Only give web servers a brief manual check until scans finish- if scans don’t reveal any interesting directories or vulnerabilities, this is the time to begin looking into the site’s content (and other services if present.)

If you’ve tried something with a script that you strongly believed was going to grant you access to a specific area of the web server, check your syntax before moving on: I pretty much wasted Saturday looking more in-depth into Mr. Robot just to discover my original brute force script was only executing grep in the event of curl failing (yeah I know, what a noob!)