As a hacker security professional, I'm more of a generalist than a specialist and while I'm ok at web application security, I wouldn't tout my prowess in that area. 

A few weeks ago, I took a class specific for web app security because that area is so vast, I felt like I wanted to move further up the line by hiring a professional to teach me some things I don't know.  Two areas that I've spent little time banging around on are Node and Mongo.  Both were discussed in class but briefly.  To continue my education, I've been playing around with vulnerable Node apps on Github.  

NodeGoat is a vulnerable application built for the specific purpose of education and while you could go the route of using the Docker image, I would suggest going the manual installation avenue.  At least for me, I find it helpful to see both the front and the back-end.  The installation is not complicated.

Read more: NodeGoat

Sometimes you're the windshield and sometimes your the bug.  This week, I'm feeling like the bug with respect to educational development.  I'm a little beat down from trying to understand an exploitation technique that I'm having a hard time grasping.  In need of a break, I went in search for something on the easier side to build my confidence.  Looking through some of the older machines on Vulnhub, I found Quaoar which claims to be easy.  I went beyond what was necessary to achieve victory but I think given its level of difficulty, I could take this further, explore it beyond root, and see what else I could uncover.

Kicking off with Nmap:

Read more: Vulnhub hackfest2016: Quaoar Walkthrough

According to the Interwebs, fuzzing involves sending random data to software until something happens or something reveals itself.  Fuzzing a web server is not much different really other than I wouldn't call it random data.  We're essentially taking lists of words, throwing them at the web server in different ways, and we're looking at the response.

In my opinion, fuzzing is an art form because it's a matter of using the right tool, with the right list, in the right way, to get the right response.

Read more: Pentesting 101: Web Fuzzing

The other day, I received an email from someone who asked me to write up a walk-through on SP: leopold which is part of a new series of boxes on Vulnhub.  Sometimes I really appreciate the Internet for what it truly is -- a remarkable instrument for communication.  It allows someone, from somewhere, to reach out and collaborate with another stranger with a common interest.  I was flattered actually and it made my day.

When I replied to my new found friend, I said that I would take a look at it over the weekend and I offered my quick thoughts.  I received a reply not long after with a bit more information which included a solid hint.  Prior to receiving that hint, I did what I normally do --

Read more: Vulnhub SP: leopold Walkthrough

We manage and monitor backups for our clients and as part of our process, we perform audits to ensure backups can be restored.  Going on a tangent for a moment, the purpose of a backup is not to capture the data, the purpose is to restore data when there's data loss.  You would be surprised when the backup software reports a successful run and yet you're unable, or you have difficulty, restoring that data.  Not to get into the weeds too far, point being, it's important to test the restore function to see if your expectations and reality align.  

Back on topic.  In the process of testing the restore capability, we occasionally come across files with "password" in the title or some other title that leads us to believe a document contains passwords.  In a few previous posts, I've discussed various methods for hunting for sensitive data and cracking of various file protections.  In this post, I'm putting a couple of those together.

Read more: Password Hunting

I worked with a guy who went onsite to install a router with information he was given from the local Internet Service Provider (ISP).  When he arrived onsite and he attempted to install the router, he was unable to connect to the Internet.  He and I went back and forth about the possible issues and after a few minutes, I asked him to text me the information he was given by the ISP.  When I looked at the message, it became immediately clear as to what was causing the problem. 

Not using the actual IP information, this will suffice:

IP Address:  255.255.255.0
Subnet:  192.168.168.10
Gateway:  192.168.168.1

You could look at this information and the problem might be completely obvious to you – or perhaps not.  The point being that to call this post a primer on pentesting would be to ignore the entire foundation where the majority of this work exists – the network. 

Read more: Pentesting 101: Nmap