Posted in Penetration Testing, web app testing

XSS (Reflected) DVWA Med/High

In the last post I ‘tried’ to give an overview of how I understood Cross Site Scripting (XSS). There is still a lot more to learn, however, with the help of Damn Vulnerable Web App and being able to review the source PHP code, you can take bigger steps to understanding how to launch an attack and protect against it.

So for this post I’m going to tackle both medium and high security settings.

DVWA Security: Medium

Figure 1 – Default operation of the Web app

It’s always a good idea to test the default state of any web application. The more you understand how something behaves, the more you can spot it’s weaknesses. Much like people. The more you get to know someone… you know the rest.

Anyway! In the medium setting the operation is still the same. You enter a name and it returns it. Only this time when we try our previous malicious payload the web application returns a different output.

Figure 2 – Web application strips out the script tags

On review of the source PHP code it seems there is some sanitation going on.

Figure 3 – PHP code removes script tags from submitted data

From the outset it looks like the web developer has prepared well for the next attack. Changing the script tags to a space will prevent the site from executing the javascript code if we use the previously successful malicious URL.

The funny thing about computers is that they will do exactly what you tell them to do. The sanitisation is looking for the script tags in lowercase letters. Browsers aren’t too fussed about upper and lower case to we might get away with using uppercase?

Figure 4 – Use of uppercase letters for the script tags

On execution the alert box does indeed pop up, bypassing the strict sanitation that was implemented.

Figure 5 – Successful execution of XSS on Medium security

In the real world it’s unlikely you’ll get to review the server side source code of a web application, however it’s worth trying this simple change out if your initial attempt is unsuccessful.

DVWA Security: High

The source PHP code suggests the web developer has taken extra measures to prevent us from running any script tagged malicious javascript code.

Figure 1 – Further sanitation of submitted inputs in PHP code

*Spent some time looking up regular expressions

And we’re back…

From the code and from testing this out first (remember testing!) Anytime we enter the full word ‘script’ surrounded by <> it gets replaced with just ‘>’. If we put spaces inbetween the letters like this, ‘s c r i p t’ it is also replaced by ‘>’ No matter what  we try, it always gets sanitised (even uppercase).

After playing around with a few things I landed on a method that doesn’t use the ‘script’ tags.

IMG SRC=’#’ onmouseover=”alert(‘xxs’)” (removing the <> so WordPress doesn’t sanitise my inputs)

Figure 2 – Our broken IMG tag that is likely to force the user to try and click on.

This creates a HTML anchor IMG Source point and whenever the mouse is hovered over it, it pops the alert box with the word ‘XSS’ in it. A successful execution of Reflected XSS on the High security setting, despite the strict sanitation of submitted inputs.

Personally I love the ‘onmouseover’ function, and try to use it where needed.

Figure 3 – Successful XSS execution using ‘onmouseover’ 

Completing the low, medium and high security settings on DVWA does teach you a lot. You need to step beyond just googling “XSS quick wins” and running them against a given security level or sanitisation (if you even get to that part). You really should check what is happening if your script is being sanitised. How can you change it and still execute the code?

Also, what works for one web application might not work everywhere.

Posted in Penetration Testing, web app testing

XSS (Reflected) DVWA

I was in two minds on whether to write this up as Cross Site Scripting (XSS) is such a massive subject and this really just touches the foundations, however, I’ll give it a go.

What is Reflected Cross Site Scripting (XSS)? (From the OWASP website)

Reflected Crosssite Scripting (XSS) occur when an attacker injects browser executable code within a single HTTP response. The injected attack is not stored within the application itself; it is non-persistent and only impacts users who open a maliciously crafted link or third-party web page.

Put simply, the attacker is able to send malicious javascript code to a victim via a crafted  link and on opening the the victim is met with whatever the javascript code was designed to do reflected to the screen. That, it seems, is in its simplest form. I will hopefully explain further below.

Damn Vulnerable Web App

An excellent resource for any new person training in web application security. On clicking the “XSS (Reflected)” link you will see this screen.

Figure 1 – Default state of the XSS app

A simple question. What is your name? When a name is entered it will be displayed back to you on the web page.

Figure 2 – Any data entered is displayed on the webpage

During testing, it seems that any data we enter is displayed back to us, and is contained in the core HTML code of the site.

Figure 3 – Entered data forms part of the web apps html code

If we look at the source PHP code for the app

Figure 3 – Source PHP code

The PHP code just uses the GET function to pull the entered ‘data’ and then display it back to the user. This could prove to be dangerous if there is no checking of the submitted data.

Executing XSS

The most common way to test for Cross Site Scripting is to try and pop an alert box to the screen by getting the browser to run your malicious javascript code. This can be done with a simple addition to the URL.


*Wordpress removes the script tags from the above code. See real URL below

Figure 4 – URL with malicious script added

When the link is executed by the victim, the screen should show a pop up alert with the number zero in it.

Figure 5 – A successful XSS attack

If the attacker sends the above link to anyone it would execute the javascript code unless something was done to prevent this attack. Looking at the PHP source code available to use, there doesn’t seem to be any checking of any kind and because the site is designed to display the entered data into the website again, the javascript code is executed.

Figure 6 – Confirmation that the alert box script is a part of the sites code

The browser will execute the code it is given which results in the alert box pop up. There are many uses for this kind of attack. A more common attack is to steal a users session cookie while they are still logged in meaning the attacker can be logged in as that user simultaneously.

How can we protect against this?

DVWA has some added security settings (Medium & High) to show how to protect against this type of attack, however, you will see that this too can be circumvented to still display the pop up alert box. The alert box simply shows that the site is vulnerable to XSS. It shows the site managers that it is possible to run any javascript code in one HTTP request and have it reflect back to the user who is sent the link. This can be very damaging to end users.

The next post will delve a little deeper into how the Medium and High settings try to prevent this attack but we can still get around the measures put in place to stop the attack.

Posted in Penetration Testing, web app testing

DVWA – OS Command Injection low|med|high

I had a recent spell with OS Command Injection that left me feeling raw. Wish I could explain but sadly I can’t. I was glad to see there was some light relief in the form of Damn Vulnerable Web App. OS Command Injection all set up ready and waiting to play with.

I do remember about 6 months ago looking at DVWA Command Injection and embarrassingly not being able to do it. To be fair, I didn’t make any effort to look it up or review the source code. I hadn’t come across it. This industry has a funny way of showing you things you sidelined.

Security Level: Low

DVWA comes out of the box set to ‘Impossible’ security. Yeah ok, let’s get it changed.

Figure 1 – Low security setting in DVWA

On entering the Command Injection link on DVWA you are given the option to ping a device. For this purposes of speed, I just pinged localhost.

Figure 2 – Ping a network device

Entering the localhost IP into the box returns what you might expect.

Figure 3 – Result from pinging localhost

In the bottom right of the screen you have the option reviewing the source PHP code of the web application.

Figure 4 – Source PHP code of the web app on ‘low’

On reviewing the code the web app on the ‘low’ setting;

  • Takes in the requesting IP and passes it to the variable ‘$target’
  • Determines the OS type
  • Executes a direct command on the Operating System using PHP Shell_Exec

There is no sanitisation of any inputs given to the web application. It performs a direct command to the OS via shell_exec.

Given that in any environment you can chain commands together using certain operators it’s worth a try in this instance.

Figure 5 – Chaining of commands using the ‘AND’ operator in Linux

Chaining commands works as it would in a linux terminal. A successful output of /etc/passwd to the web page.

How did this happen?

The web developer didn’t write any protection measures in place to prevent users from chaining commands together. Due to the direct nature of the way this web app passes commands to the OS, the OS will run anything it is given. The web app is designed to display what is displayed back in the terminal so to speak.

Security Level: Medium

Remember to set the security to ‘Medium’ before trying the next part.

Figure 1 – Security set to Medium

There’s an assumption that the security of the web application will be tighter so it’s worth reviewing the source code before running a previously successful command.

Figure 2 – Medium setting PHP source code

Right away there is some differences to the code. Essentially the same as the ‘low’ setting in the way it handles the variables and passes them to the OS.

  • Takes a variable and passes it to ‘$target’
  • Creates an array of blacklisted characters for checking in a ‘$substitutions’ variable
  • Passes the command to the OS using shell_exec removing any blacklisted characters.

The developer has only blacklisted 2 operators. Both ‘&&’ and ‘;’ do similar things. You can read about operators and their functions here

There are several other operators you can use to chain commands together in Linux.

The web application only looks for 2. You can pipe commands together too, as I have done here.

Figure 3 – The use of a pipe to chain commands together

Why did this work?

The web developer did not fully sanitise all possible operators. The OS did not ping ‘’ but instead ran our command ‘cat /etc/passwd’ instead. I’ll no doubt investigate why it did this, but for now it’s good that it returned what I needed.

Security Level: High

This is where it gets interesting. First off, let’s set the security level to High.

Figure 1 – Security level set to High

On reviewing the source PHP code the developer has taken our advice about tightening the security and has placed all known operators in their blacklist. This could prove difficult.

Figure 2 – All available operators have been added to the blacklist variable

For now it seems that there is no way of chaining commands under these new rules.

On the bottom line the developer has blacklisted the double pipe operator ‘||’ the OR statement. In linux this character is called a metacharacter. It is not constrained by spaces on either side. The web application is strictly looking for ‘||’ with no spaces. Once this condition is true the operator will be blacklisted.

In my example inserting spaces between the pipes escapes any checks from the source code.|  |cat /etc/passwd

Figure 3 – Successful command execution on High

How did this work?

Technically this should not work as it errors on a linux terminal, however, when playing around on the web app it worked everytime. I’m not happy with the discrepancies here so further investigation is needed I think, however, for the purposes of running OS Command Injection on High within DVWA it was a good exercise.

I think I’ve learned a good number of things I do wish I knew before. Working through the problem, reviewing the source code and following the code is really useful. If you can explain to yourself how the simple web app works, then you can bypass it’s security more easily.

Impossible setting?

Erm, I have reviewed the source code. This is what I know so far

  • Splits up the IP address into octets
  • Checks that it’s been passed an integer (a number)
  • Merges the IP address before running the command.

I’m sure I’ll get to that one day. There’s a ton of other things to learn 🙂

Thanks for reading…

Posted in Thoughts, Uncategorized

What I would do differently – PWK


Giving back to the InfoSec community is something I’ve always strived towards. Other professionals have always had time for me and it’s only right that if I can, I would relay my experiences to other people.

Penetration Testing with Kali Linux

Some may know that I took up this monumental challenge around 200 days ago. I say monumental because I was a lost lamb with limited knowledge of Pen Testing before I enrolled in PWK.

Like many, I had such a fear of the course. I read so many stories, reviews and some scare mongering from various online resources. I’m a “into the deep end” type of guy and I needed something to focus on. PWK was that focus. It wasn’t plain sailing at the start so to help ease the stress or preconceived ideas about PWK that would otherwise put you off, I’ve put together a few things to help you out.

I’ll break it down into parts.

  • Kali Tips
  • Lab Tips
  • Reporting
  • If you get stuck

This is based on my own experience of what I would do differently, having been on the course for 200 days ( I know, I’m a slow burner at times). Your experience may differ.

Kali Tips

  • Create directories for each target. Dump all exploit scripts, enumeration files and anything related to that target in that directory.
  • Use symbolic names for your exploit code or document it in your notes. For example, 3456.c doesn’t mean anything at a glance. Months later you’ll come across it in your file system and if you didn’t document it’s use or change its name it is useless to you.
  • Create a directory for your ‘fixed’ exploits. Find your own way of doing this. You could use CVE numbers, exploit name or anything that you can call on later. Remember to document any change made to the code and name of the file.
  • Work on your speed of execution and how you can utilise your hardware to execute a task faster. For example, using more threads while using Dirbuster.
  • Don’t be foolish and neglect the use of Metasploit. It’s an amazing tool, and can build confidence.

Lab Tips

  • Don’t jump into the labs instantly if you are new. Read the course materials and watch the videos. The information is extremely useful.
  • Revert each machine before you enumerate it.
  • If a machine was reverted in the last few hours, someone may be working on it. Be kind, and move on.
  • Check the forums for the machine in question to see if it requires frequent reverts.
  • Run the fullest enumeration scan possible, full TCP scan, and UDP scan
  • DO NOT shy away from anything in the labs. Despite any rumours you may have heard about certain targets, try your hand at everything to have a better shot at the challenge.


  • Read G0tmilks tutorial on Alpha on the forums. It gives a great insight on how to report. Also this can give a great entry point and feel for how it’s done.
  • Read through the Offsec dummy report –>
  • Use the Reporting template from Offsec. It’s a good baseline. No point in reinventing the wheel.
  • I will add that using something like Keepnote is essential. Even more important to that step is keeping good notes. If you don’t, you will have nothing to report. Remember, you will need to explain these steps to someone who can follow them exactly as you did.

If you get stuck

  • Offsec Forums are fantastic for tips
  • Offsec chat function has been really helpful for me at times. Cleverly delivered tips that sometimes show you an answer without even giving you a hint. Great resource.
  • There’s the IRC channel too. Personally I never used it.
  • Refer to the course materials, and videos.


I could likely add more into this post as time goes on. No matter what stage you are at, you are always learning. Despite me failing the exam challenge twice and rooting 30 of the lab machines, I still have a lot to learn from PWK. The learning never stops. Enjoy the time you have in the labs. It’s an amazing experience.

Posted in Penetration Testing, Thoughts

Good enough?


Writing gives me space to offload things that could be swirling around in my mind. Almost like a program caught in RAM, this blog serves as a Task Manager to clean out any unwanted processes in my head.

One particular annoyance lately, has been an echoing thought of meeting the grade. I have thrown myself into the lions den so to speak, or in a less aggressive manner, thrown myself into the deep end. Training in OSCP has been a challenge, and I feel that with 23 boxes rooted, it’s a modest number for someone who didn’t know anything about hacking only 12 months ago.

OSCP can have you living in a protected bubble. It can lure you into a false sense of security. It’s not a criticism of the course or certification, but merely an observation. You can become so captivated by the lab environment that you lose track of everything else around you. There are other aspects to Penetration Testing, however, your mind is focussed on the task of hacking lab machines. This is great for learning, however, when you speak to other professionals, it can leave you feeling distant if the conversation isn’t about OSCP.

Do you belong here?

I ask myself this question quite regularly. I see amazing things happen on a daily basis in the industry. That’s just from the people I follow on Twitter. Am I putting enough effort in to expand my knowledge past that of the OSCP? Where else should I turn for information?

OSCP hasn’t been a walk in the park for me. It’s often classed as an entry level certification in Penetration Testing. Entry level? Really? I’ll either need to put overtime in or readdress my goals. Don’t be fooled by the notion that this is an entry level certification if you are new to Penetration Testing. I can understand why they say it’s entry level, because it’s such a vast space, however, entry level doesn’t mean easy.

False sense of security

Finding your flow in OSCP can take some time. There is a lot of material to go through and when you start hacking the labs it can be a slow and frustrating process. Once you get more confident with identifying vulnerable services and exploits related to those services, you slowly and surely start believing in your ability. If for some reason you get ahead of yourself, there are some machines in the lab that can bring you back down to earth. This constant fluctuation in feelings can be unnerving at times. One day you’re full of confidence, and other days you just feel like a fake.  Training yourself to look past failure and turn it into success can take some time. The lab teaches you more about yourself than the vulnerabilities you uncover.

So what now?

I’ve broken past the point where training in Penetration Testing is a hobby for me. It’s not a matter of whether I’d like to do this as a career. It will be my career at some point. I love the art of enumeration and the craft of transparently learning everything about your target. There is always room for improvement. OSCP helps engineer your mind into learning. It’s not there to teach you how to hack. It’s function is to show people that you have the ability to learn and apply complex procedures in practice. How that translates to real world testing remains to be seen. Not everything in the world is vulnerable.

Ready, Set, GO!

I was fearful of moving away from my job in IT because of the job security. I knew my bubble and it was safe, but now I feel more confident that I can learn anything. That’s what OSCP teaches you. Work hard, learn, work harder, learn and apply in practice with confidence. It’s a genius concept once it sinks in.

You can do anything in life. Set goals, and if you want it bad enough it will fall into place.

Posted in Thoughts

OSCP // PWK – So far


30 days to go out of the 90 days of PWK lab time I purchased with Offensive Security.

Mixed emotions really, because due to (helping) to plan my wedding, having a really busy time in my work and other life things I’ve felt that I’ve hardly had great use out of my 60 days so far.

In the time I’ve been in the labs, I feel a sense of accelerated learning has been required. Your brain resists the input until one day it cracks and allows it all in. Normally after you smash your first box without using Metasploit. I had some serious issues with self doubt though.

I’ll never be able to do this. It looks really hard

I was utterly lost in the first 20 days. I’m big enough to admit my own failings and in hindsight I should have worked harder to get into the labs earlier, however, hindsight is what it is and I can’t really be too angry about it.

Personal battles

The task of hacking machines in a lab of varying difficulty might seem easy to some people, and hard to others. You won’t know how hard it is until you try. Here’s the kicker though, your success is based around a high level of confidence in your ability to enumerate a target. If you are lacking skills in this department, you will spend a long time starting at an nmap output not knowing where to go next. Hence why I wasted 20 days in the beginning.

PWK teaches you more about yourself than any other life experience.In the face of growing opposition what are you going to do? turn and run, or keep pushing through the barrier?

Try Harder

The OffSec moto that can either spur you on to greatness, or have you crumbling into a pile of your own disappointment (depending on how you feel that day). You will experience both emotions at some point, trust me.

There is, however, an air of disappointment to have gained shell or rooted a box based off a tip from someone. It’s almost tainted glory. Something you can’t really celebrate. True glory and elation comes from totally owning a box from nothing to root all by yourself. It’s one of the best feelings in PWK. For me the reward is equal to the effort put in. Only problem is, that, you can’t tell anyone how you did it, only that you did. The only proof that you have the determination, skill and mental ability is when you have that OSCP certification. Until then, it’s just hearsay.

What is the best way to approach PWK?

I’d say that the most important part of any engagement is to get your enumeration skills down to a fine art. Exhaust  every possibility, however, don’t waste time on tools not fit for the task at hand. I’ve seen people asking why enum4linux doesn’t work when it’s clear ports 139 & 445 are closed. Learn what the switches in the tools do. They can save time. Time is your enemy in PWK. You might think that 90 days is a long time, but it’s not. A lot of people advise new people about what to expect from PWK and it’s all pretty generic but I’d work on enumeration because the information you gather determines your next move.

  • Learn about Windows and Linux, and mostly where things live.
  • Learn how to get the most out of nmap and NSE scripts
  • When you think you’ve enumerated a box, you’ll have missed something.

More time

I’ll be adding more time to my labs for sure, as it’s taken me a while to get a fire going, but now the flame has started it’s easy enough to keep it alight.

My learning process can be annoying. I can’t just run an exploit, get root and be happy. I have to know why so I read the blurbs of exploits, and any associated information. Who knows, it may stick, and you never know when you’ll need to use it again.

A great course

I must admit. PWK is one of the best and worst courses I’ve ever done. It’s great because it’s freeroam to do as you wish to computers. You can learn a lot from failure, and you do fail a lot. That’s ok. This brings me to why it’s the worst. You’re on your own. There’s no two ways about it. There is some help, but it goes back to that tainted glory thing. They never talk about the human qualities needed for PWK

  • Natural curiosity
  • Stubbornness
  • Being able to think outside the box
  • Being inventive
  • Pre-visualisation
  • Willpower

All of which shine through in the labs as your mental dexterity is tested to the max.

I don’t have anything else to add without giving too much away, however, I would just say that enjoy your time in the labs. Don’t chase the exam or the cert. Do it in your own time. You’ll learn more that way.

Also Documentation is a must. Whatever method you chose it up to you, however, just make sure you document everything you’ve tried because you may have to leave boxes if you’re spending too much time on them. Mental exhaustion can kick in fast, so it’s best to move off to another box, and come back. Sometimes this is days or weeks, so your notes need to be on point.

Have Fun


Posted in Thoughts, web app testing

Where did that come from?


The scene above is one every person, new to InfoSec, should get used to. A vast empty road that rolls on for miles and miles with what looks like, no end.

I feel I’ve reached a pivotal point in my journey. I haven’t written anything in my blog for a few weeks, because I’ve been so immersed in learning. Attacking the Vulnhub VM’s was a great step in the ladder on my road to OSCP, however, I feel I was neglecting my real passion for Web Application Pen Testing so I switched up the format a little in the last few weeks.

The Journey is long

This industry will take you to your limit and beyond. It will test you until you break. Unfortunately I feel I’ve stalled a little in the last few days. When that happens I tend to write about it to iron out the creases.

In the next few days I start the OSCP journey. I would like to have entered into it with more confidence and ability, however, lately things haven’t been going to plan. I felt I was walking the road no problem until I stalled for no reason.

Web Application Pen Testing (WAPT)

On every CTF I gravitated to the Web App challenges. Excitement filled the air. The reality of WAPT is very different to CTF’s and I guess it was something I wasn’t really prepared for. Websites aren’t designed to be vulnerable. Sometimes they just are, sometimes they aren’t. The key is to find the vulnerabilities by way of utilising every skill you have at your disposal.

There lies the problem. A true test of what you think you know comes from entering the world of Bug Hunting on Bug Bounty websites. There is no introductory medium.

Vulnerable beginner Apps —————————–> Live site testing

There’s no medium. One minute your pushing the same XSS payloads to different Vuln Web Apps and likewise with SQLi . One day you just have to jump into the real world.

Sucking it up

You get down about failing. It’s human nature. You feel embarrassed. You want to crawl into a cupboard and let the storm blow over, however, get over it.

There’s teenagers that know more than I do about WAPT. It’s depressing to read disclosure reports and not know one thing about what’s in them. Your silly little XSS payloads that worked so well in your vulnerable web app won’t work here. You’re going to need to come up with something more special to fool decades of experience in web development.

I’ve been told I need a solid grounding in WAPT experience to get by in OSCP. Of course that was a kick in the groin. I had a difficult last few days trying out Bug Hunting getting my rear end handed to me on a plate. I’ve learned a lot in two days, and that’s important.

Moving On…

I expect a lot from myself. Sometimes it causes greater crashes, however, I don’t walk the road. I run it. I just need to train harder, give myself a slap and use my time more effectively.

Soon new roads won’t seem so daunting. You won’t fear the journey. You’ll get excited about what you’ll learn on the way. Writing about how you feel can make a massive difference. Even if no one reads it, it can help you clear the cobwebs and confusion.

Seize the Day!!

P.S. – This was me trying to kick my own ass today. I sat with my head in my hands wondering where the hell I was going and what I was doing. That won’t happen again.
Posted in Penetration Testing, web app testing

Sick OS 1.1 Vulnhub VM

Hosted by Vulnhub
Author: D4rk36

Thank you!


I do more in depth nmap scans than the usual I post here, however, the finished article is usually the one the yields the most straightforward results.

I’m using VMware Player 12 with NAT networking.

nmap -sS -A


I’ve highlighted the ports of interest here. A proxy setup I actually use in my job so it was a little odd to see it in a VM. In order for you to see any websites in this set up we need to point our browser to the IP address and port 3128.


Once we visit the web page of the Sick OS 1.1 server we get this.


Not very helpful. Viewing source is a waste of time as there’s nothing there. I ran a dirb scan and found a /robots.txt file.


Oh what do we have here? A /wolfcms directory? Don’t mind if I do.


I’ve used various content management systems in my time, however, navigating around the site always helps to get a feel for how it’s set up, how it operates and how the links change and to where. Both links don’t really offer much, however their URLs might.


No login page link, so I went out into the ether in search of an answer. I found this post on the WolfCMS forums. Company forums are a haven for excellent information. You can find out a lot about an application from a company forum. Even a fan forum can provide.

From that we find an admin page link and a few other tasty treats on the forum about a ‘config.php’ page in ‘/var/www/wolfcms’ that could be of use later.

We got to


I searched a few forum posts to see if I could find a default admin login. There’s always a default login for these things. I tried a few things, however, admin:admin was the correct credentials. We get in.


On login I received a quick pop-up telling me that Wolf CMS was out of date. Starting to see a theme here. My natural curiosity spots the version number ‘0.8.2’ and flies off to the interwebs for any vulnerabilities. I came across this.

Wolf CMS 0.8.2 – Arbitrary File Upload Exploit

A snippet from the site reads.

This exploit a file upload vulnerability found in Wolf CMS 0.8.2, and possibly prior. Attackers can abuse the
upload feature in order to upload a malicious PHP file into the application with authenticated user, which results in arbitrary remote code

I’m instantly thinking PHP Reverse Shell. Only because I’ve been able to use it so much recently. Why shouldn’t it work here? I navigate to the ‘Files’ tab of the CMS.


As you can see I’ve already got my shell ready to go. No need for Burp or Tamper Data here. we can just upload to the server. Logged in as admin helps with that.


From this point you’d be opening terminal and a netcat listener

nc -lnvp 1234

We uploaded our shell script to the /Public/ folder so visiting the link below should be enough.

Once we hit that, you’ll notice instantly that we have shell on the server. If only everything was as easy as this.


A quick python one liner to get us into a familiar bash shell.

python -c ‘import pty;pty.spawn(“bin/bash”)’

So what now?

As with anything, getting shell if you have that type of vulnerability is the easy part. The next part can vary depending on what the server set up is and the type of OS it is.

Again we’re logged in as ‘www-data’ and from earlier VM’s this has been a very limited account. I mentioned earlier that from the forums I obtained some information about a config.php file. To my surprise I was able to navigate to ‘/var/www/wolfcms’ and read the config.php file. In there I found this.


We have a root DB user with a password. Excellent. From the forum set up guides no one should be able to do this. One of the first things they get you to do is limit the www-data account. Not here obviously. Don’t always assume you have limited access.

I also found a user called ‘sickos’ with the ID of 1000. Probably a user account created after the server was made. I noted this down for later.


I tried various different methods of looking for things that would work here. I was maybe over complicating it. I tried loads of stuff.

  • Previous Priv Esc exploits.
  • Went rooting around in the DB with the credentials I found.Learned a lot about MySQL from that though.

I took a break and chatted with some others in Slack. They were asking how I got on and I explained where I was at. One guy pipes up “Oh yeah just switch user to root on that one” What? you’re kidding…

Off I went to educate myself on this. Surely it can’t be that easy?


Yes it was.


So we

  • Switched user to sickos
  • The sudo SU and got a root interactive terminal

I guess my limited time as a Linux user let that one slip. Being a Windows Admin and solely using Windows has me at a disadvantage when it comes to enumerating users, groups and permissions on Linux. Noted for the future.

What did I learn?

I think it would be silly to do these and not take anything away from them. I’d certainly say that it’s not always the most complicated of things that get you root. Look deeper and take note of everything you find, and learn why it is the way it is. I breezed by the sickos account. Probably shouldn’t, however, we learn.

Posted in Penetration Testing, web app testing

SecTalks: BNE0x03 Simple CTF

Hosted by: Vulnhub
Created by: @RobertWinkel (Bull)


I had a lot of trouble trying to get this VM to get a DHCP lease. For some reason VirtualBox was broken so in trying this, I also managed to fix VB too.

After all the shenanigans I was able to get an IP for the Simple CTF box. Great! A quick nmap scan then.

nmap -sS -A


We see that port 80 is open. It’s running Apache on Ubuntu and with the http-title “Please login / CuteNews” Ok why not?


Not much to look at here. I created an account with the credentials test:test. Logged in to the portal and started looking around. I navigated to the ‘Help/About’ page where I was met with a pop up box alerting me to the fact that Cute News v2.0.3 was out of date and I had to upgrade due to security issues.


This is great news for a trainee Pen Tester. It actually tells me what I need to do next.
I instantly fire off to Google and search for ” CuteNews v2.0.3 exploit” Low and behold, a lovely exploit-db link for me to go into (after I clicked on a few others of course).

CuteNews 2.0.3 – Arbitrary File Upload Vulnerability

I read through every wee detail, however, it started to sound a lot like a reverse-php shell situation. I was very excited indeed.

Carving the exploit

The details of the exploit reveal that an account must be created, and you need to upload an evil.jpg as an avatar image, use Tamper Data to change evil.jpg to evil.php. I’ve used Tamper Data before, but I wanted to try Burpsuite for this.

Using the excellent PHP-Reverse-Shell from Pentest Monkey I edited the file to linkback to my Kali box IP and saved it as Evil.JPG. Didn’t need to use Evil, but it’s fitting.

After that, I opened Burpsuite and proxied the CuteNews site through Burpsuite. Details of that can be found all over the net. I set the stage so that I just had to hit ‘Save Changes’ on the Cute News Profile Page. Burp caught the request before it was sent to the web server.


As you can see it has the uploaded file in the request. Just take out the .jpg part and replace it with .php and hit ‘Forward’ on the menu bar. The Burpsuite part is done for now so close it all down as it causes problems later when we get shell. Trust me.

Where did the upload go?

At this point we have no way of calling our Evil.php file so we need to find a way to get to the URL. This is where DIRB comes in handy. CTRL+ALT+T for  a new terminal tab and type in.


This will use common wordlists to map a websites directories. It’s a lot quicker than DirBuster. We get some results.


I initially fired over to the /docs/ folder, however, the file wasn’t there. Funnily enough it was in the /uploads/ folder.


The webserver renamed the file to ‘avatar_test_evil.php’ Not a big deal. Before we click on the newly uploaded PHP-Shell we need to create a listener on our machine to create the connection from the CuteNews Server.

nc -lnvp 1234

Port 1234 was the port defined in the Evil.php shell script we uploaded. Within a few seconds of us clicking the ‘avatar_test_evil.php’ we have a remote shell to the server.


Excellent! I really do love this method a lot. I like to create a bash style shell so I type this into the prompt once I’m in.

python -c ‘import pty;pty.spawn(“bin/bash”)’

This just creates a bash shell for use to make it easier to identify where we are in the directory structure.

Privilege Escalation

We are shell on the server as www-data an Apache own limited user with limited functionality and options. No good. We need to gain higher privileges. This test was starting to go along the lines of a previous VM I did, Droopy. I checked the version if Ubuntu.

lsb_release -a

Wow it was the exact same version of Ubuntu ‘Ubuntu 14.04.2 LTS Z codename: trusty’
I just went along with it and went into gung-ho mode. I used an exploit for priv-esc on Droopy so I thought I’d give it a try again.

Linux Kernel 3.13.0 < 3.19 (Ubuntu 12.04/14.04/14.10/15.04) – overlayfs Local Root Shell

Navigating to the /tmp/ directory I ran this command in shell on the server


I also did the following after I downloaded 37292.

  • mv 37292 37292.c
  • gcc 37292.c -o rootMe
  • chmod +x rootMe
  • ./rootMe

4 command lines later and we have a root shell.


A quick ‘cd /root/’ and then a ‘cat flag.txt’ and we had the flag!!



After the initial VirtualBox trouble I had with this one I was really quite surprised when I popped Root on the box. Apart from going to Exploit-DB for the initial exploit I did this one all on my own and that’s a great feeling indeed.

It took me longer to write this post than it took to get Root on the server.

Thanks again to Vulnhub and Robert Winkel for this VM.

Posted in Penetration Testing, web app testing

Lord of the Root VM – Vulnhub

Lord of the Root VM – Vulnhub

After Droopy I was advised to try this one. Created by Kooksec – Thanks!

A lot of soul searching went on in this one. A lot of reading and doing it in between life tasks so it took me all weekend really.

A standard nmap scan throws up nothing but port 22 open (SSH). I tried so many variations of nmap scans to get past “All ports are open|filtered” I probably should have just tried logging into SSH.


Funnily enough I had just tried a VM that involved port knocking. Simple CTF I think it was. All ports were filtered too. Thought I’d hit it hard on this one.

I had to do some digging around for a few hours on Port Knocking.I created a bash script to automate port knocking using Hping3

Knocked on ports 1,2 & 3 from the hint in the SSH banner “Easy as 1,2, 3” I did try 80, 8080 & 9090 as they are usual VM ports. Not this time.


Logging on to the webpage gives us this.


Nothing of note here.

Viewing the source of the page reveals an images folder.


Naturally we want to check that there’s a robots.txt file.


What’s this? Lets view source again to see what else we can find.


I’ve done a lot of lower level CTF’s and they always use base64 to fool people. Let’s convert it.

echo “THprM09ETTBOVEl4TUM5cGJtUmxlQzV3YUhBPSBDbG9zZXIh” | base64 –decode


Ok, lets do the same. Now we’re getting somewhere!!


Looks like a useful link


YAAY a login page!!

Basic SQLi injection didn’t work. Lets go to the trusty SQLmap and pull a request from Burpsuite like we did in a previous VM.

Using a saved request file from the url We can see what the DB type is.

I should note at this point that any SQLMap scan done on this site will be done under time based conditions. This means that it checks each character of the name of any DB or table and if it’s true it’ll wait a certain amount of time to try the next one. This varied in my tests. Most amount of time was 5 seconds. It took 10 mins to get this far.


The DB seems to be MySql and we’ve found the DB name, so lets dump the DB.


The resulting information from the command.


It looks like we’re flying along nicely.

I tried to SSH into the server using all those accounts and only the ‘smeagol’ account would allow me in. However, we’re running as a normal user. I tried running an earlier priv esc exploit from another VM, however, that was unsuccessful

I needed to find out how to get to a root account. In an earlier scan to find the name of the DB I came across another DB name ‘mysql’ I suspected a system DB default to the server. Lets see what’s in it.


Interested in the result here


Lets try and pull the details from the user table.

Of course everything we do is based on a time based attack so everything is working slowly.

I ran the command


This ran for a bit but seeing as I seen the results for columns User & Password I canceled the scan and tried to hit those directly.



Again this takes time to run on a time based attack. You can let SQLmap run it’s own polling interval. It’s worthwhile to let this do it to save on errors.


After a while things start to look good again. We’ve found the root user but with hashed passwords.

You get the option to crack the password hashes with SQLmap. I hit Yes to this. It ran pretty quick and found what I was after.


We’ve found the ROOT password. ‘darkshadow’

I tried logging in over SSH with this, however, I got ACCESS DENIED. Crikey!!! That would have been too easy. It then dawned on me that this was not going to be that easy.

I floated around the net for a bit looking for hints. I touched a few walkthroughs that to be honest didn’t make much sense. Probably because I came in from a different angle.


I logged into MySql with the ROOT user I found in the other DB. I got in. Now what? Loads of other people were using their own scripts in Python and C, to do things with the SQL DB while logged in as ROOT however, I didn’t really understand all that yet. Bit above my level.

A few people mentioned in their blogs that there was an exploit available for priv esc in MySQL if MySQL was running as ROOT. I Googled around for a bit and found the information below.

Gaining Root Shell using MySql User Defined Functions

I admit I didn’t understand it at first from the site above. I sat for most of the day trying to get my head around it. They gave you clear instructions on how to do it, however, I don’t blindly just follow things I read on the net. An old Sysadmin thing I’ve yet to shake off.

Needless to say I followed this exploit to the letter and I was able to get root and find the flag. This VM probably was above what I’m learning at the moment, but, I wanted to give it a try.

Flag found!


I think it’s important to understand what you are running. From what I can gather, MySql was running as root so we inserted a shared function into a new database. Run it as root and get shell on the server. (In essence)


I haven’t completed the whole write-up for this, purely because after I found the root accounts, I felt like it was done by way of following a tutorial that someone else made. Yes I learned a lot, however, in the last post I fought hard filling in the blanks to find the goal to the end. This one felt odd when I found the flag. I had to go over it a few times and It’s still a little hazy to say the least.

Maybe this one was a tad more than I know just now, and that’s ok. It happens. In fairness I really don’t like using automated tools like SQLMap and Metasploit. I feel very disconnected from the test. I think in this case it was helpful to use SQLMap for such a complex query to cut done on time taken.

Never mind, onto the next one!!

Thanks again to Vulnhub for hosting VM’s in such a great environment for learning.