Breach 2.1

This is another VM I had to put down for a while, but after some much needed time away, I was finally able to get past that wall.  Let’s get started!

Let’s get those nmap scans out of the way:


We’ve got rpc, more rpc, and SSH.  Hooookay.  Well, let’s see what lies beneath!



It took me a while to get this for a couple of reasons.  I got that the user was peter, and I added him to the list, but I was stuck on the “password is in the source” part.  WHAT SOURCE!?  THERE’S NO WEBSITE!!  Thanks to ch3rn0byl for hinting at what was right in front of me, I finally figured out that the sentence was supposed to be read “the password = in the source”.

I tried every combination of that only to have the connection close on me abruptly on a specific combination.  So I set ssh to verbose mode and lo and behold, the password “inthesource” was correct, it was just killing the session on login:breach2


Ok, so now what?  On a whim, I decided to scan the box again to see if anything had changed.


*sigh* Well, there’s the webserver.  It took me a few times to figure out that logging into the SSH server is what brought the webserver online.  Well, now that we’ve got a webserver, let’s go take a look at it!


Ok, nothing immediately obvious.  Someone really likes beef. Got it.  Looking at the source gave us:


Darn.  Ok, let’s let dirb do the dirty work for us then:


So we’ve got some directories and some files:

  • /blog/
  • /blog/smilies/
  • /blog/wysiwyg/
  • /blog/README
  • /images/
  • index.html

The most interesting thing here (though it took me a bit to realize it) is that README, let’s see what it says:


So there may be a config.php, an install.php, and a datechange.php hiding in here.  Checking reveals that all of these files exist, and that install.php does exactly what it says it does.  This is a pretty easy (if not extremely apparent 😉 ) way to get admin rights on this blog, so let’s do it!






After becoming the admin I look around and find…nothing! Literally nothing.  The entire admin panel is missing. Well, that was a waste.  I guess let’s peruse the site and see if I can find any XSS insertion points.


Ah! You can enter script into the username field on the registration page and it gets executed by the members page.  Cool.  Now at this point I’ve been thinking about that big BEEF picture on the top level website, and began to think it may be referring to beef-xss framework.  The only problem is that most of these VM’s don’t let you leverage XSS in any meaningful way.  Maybe this author had built a bot!?  Let’s look!



That looks like a bot!  Awwwwww yissssssssssss… and since I hadn’t set up metasploit integration in beef on this install yet, I followed this website:

Integrating Metasploit with Browser Exploitation Framework

After loading up beef, I grabbed the hook and made a new user with the following as the usename:


And now we wait…

I hook my own browser to make sure that it’s working and watch wireshark some more. After a little bit of this I decide that it’s probably that alert box I created messing with the bot.  Well crap.  So I reinstall the VM and go through the motions again (without bothering with admin this time).

And after what feels like an eternity, the victim browser is finally hooked! I run the msf_firefox_proto_crmfrequest exploit and wait patiently for shell…



Which after several attempts, finally works:



XSS is, after all, a waiting game.  Anywho! Let’s get to investigating.  After spawning a shell, it looks like we’re logged into peter’s account.  With that we also found the other users on this server: bill and milton.  Peter’s got sudo access to apache2, but that’s not super useful right now. Checking out netstat, however, reveals that MySQL and a service on port 2323 are both running on the loopback interface:



I’m interested in what’s inside the MySQL database, so let’s see if we can find a config.php file with some credentials:


So they’re running MySQL with a root user and no password.  Wonderful.  We also find another directory named “html2” here that contains a folder called oscommerce.  After investigating the MySQL server, we find an “oscommerce” database with a table called “osc_administrators”.  And as I’m sure we all hoped, it has username and password entries:



Cool, so we’ve got admin credentials.  After decrytping the hash, we end up with admin:32admin. So now to investigate what port 2323 is:


Coordinates and a login prompt… Well, Ok. Let’s find out what those coordinates are.  They take us to the dead center of Houston.  Looking into it some more, the google earth specific point is an odd geometric structure.  Not really sure what to make of this.  Back to that login prompt, though.  I tried a few combinations of bill to no avail, but milton:Office-Space-Milton


The password “Houston” worked for him. It then takes you to a countdown and prompts “Who’s stapler is it?”, which, if you’re a fan of Office Space knows Milton’s love for his stapler.  So after a few different attempts: miltons, milton’s, my stapler, mystapler, the password “mine” finally worked:



Ok, we’re in!  Milton’s love for his stapler was his downfall here.  Kinda running through everything I did with peter’s account, I noticed a new port opened up: 8888.  And this time it opened up on all interfaces (As indicated by the address). Let’s nmap scan that and see what shows up:


An nginx server, so this may be where that oscommerce site is.  And sure enough, here it is:



Uh, crap, where do I log in?  So I hop back over to the shell and find the admin login page is located at: “”.  And we now have an admin login prompt.  Let’s try those admin credentials we grabbed from the MySQL db.  After a few attempts, we discover the actual usename and password combo is “admin:admin”.  Not really sure why that 32 got added there.  Salt added to the hash maybe?  Anywho, now that we’ve got admin access, let’s login and snoop around a bit.



After some tooling around the interface, I find a File Manager that lets you upload anything you want.  The only problem is that I don’t have write access to the directory that we’re currently staring at.  So after checking most of the directories and their sub-dirs, I finally found one that let me upload to it: “./includes/work”.  So let’s upload a php reverse shell and see what user is actually running this nginx server:



It uploads successfully and also gives us another morsel of information: it appears that we’re running as blumbergh.  Let’s navigate to “” and see if we can catch a shell.



Awesome, it looks like we are running as blumbergh and we have a more permanent means of getting back into the system.  running sudo -l reveals that blumbergh can run tcpdump as root.  Tcpdump has a pretty cool privilege escalation vulnerability in this specific situation.  You can read more about it here:

So we’re essentially going to copy that article word for word except we’re going to create a reverse shell:


And since our listener was already set up and waiting, we got a shell!breach22


WOO! We’ve got root!  So lets navigate to the root dir and check out what we’ve got:



We found the flag!  It was even animated!  Thanks to mrb3n for the awesome VM, and for making that bot to finally let me leverage some XSS.

Au revoir, skiddies.