The description of Typhoon 1.02 makes it very clear that this box is extremely vulnerable on multiple fronts.  I didn't set out to find every avenue and I'm sure I did not.  As I'm reading the description again, I clearly didn't even touch DNS.  That being said, I found more than a few low privilege entry points and multiple privilege escalations. 

Two things I really like about this box --

1.  I got to play with a few things that I'd not seen previously.
2.  This box, like the metasploitable series, is good to come back to from time to time after learning new tricks.  Clearly I need to learn some new DNS exploitation techniques.  

Read more: Vulnhub Typhoon 1.02 Walkthrough

Over the last couple of weeks, I’ve seen a few examples of passwords being rejected for failing to meet the complexity rules.  For example, the current password is “secret1234” and the new password attempted is “secret1235”.  There are similar variations where people attempt to use the year and month – “password201810” and “password201811”. 

My password manager shows that I have 516 accounts and passwords.  Trying to remember 516 passwords is impossible which is why you should use a password manager.  While a typical user might not have 516 accounts, they have quite a few and without a password manager, they try to create something memorable.  I completely understand their need to change one digit and move on -- I disagree but I understand.  Here’s the problem – let’s say I get wind of this type of pattern and the initial portion of the password is “testing” and the remaining portion is a four digit number.  Technically, it’s an eleven digit, alphanumeric, password.  In reality, it’s a four digit, numeric, password. 

Read more: Sequential Passwords

The scanner comes back with:  "Site appears vulnerable to the 'shellshock' vulnerability (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-6271)."

I realize I'm talking about a four year old vulnerability but it's one that still exists and it's a rabbit hole I wanted to jump into.  I've come across this vulnerability a few times in the past and I've either used Metasploit or 34900.py ("Apache mod_cgi - 'Shellshock' Remote Command Injection") to get my shell.  I seem to recall having an issue with one or both at some point and I moved on to another avenue because my search results yielded bits and pieces but nothing that I could wrap my hands around.

Stumbling upon this vulnerability recently, I paused to dig into it with the intention of getting a better understanding for manual exploitation.

Read more: Exploiting Shellshock Manually

Have I mentioned that I love WordPress?  I do, as long as I’m not maintaining it.  When I’m maintaining it, I hate it.  My kneejerk reaction is to call it junk.  It’s not junk but it’s what happens when designers cut out developers.  I get it – you’re a designer, you want to move quickly and here’s this product which is easier to learn than coding.  If you want a fancy slider, you install a plugin.  If you want to embed a YouTube video, you install a plugin.  From that point of view, it’s amazing.  From my point of view, every time you bolt on a new widget, there’s a potential for an opening.  Heck, without plugins, you can still get owned which is what we’re going to explore in a moment.

Read more: Hacking WordPress 4.7.4

Does anyone actually write their own shells?  At some point, a few people did but now we just search for the type of shell we want and we find what we need.  Kali has quite a few under /usr/share/webshells and pentestmonkey.net is another good resource. 

Why reinvent the wheel shell when there are so many at our disposal?   To better understand the code we’re reading and writing.

At best, I hack code.  I’ll never be fluent in Python because there are too many other things to learn but that doesn’t stop me from writing simple scripts.  The more baby scripts I write, the better I can understand what I’m reading when I’m looking at other code. 

Read more: Writing Shells

I ran into an issue while installing Google Authenticator on Ubuntu 18 and although the solution is simple, it's given me an opportunity to discuss three items.

First, the issue:

You attempt to install Google Authenticator using the following:

sudo apt install libpam-google-authenticator

And you're presented with the following error:

E: Unable to locate package libpam-google-authenticator

Read more: Ubuntu Server - Google Authenticator