Month: January 2022

2022 is off to a great start for me – I recently passed my Advance Web Attacks and Exploitation (AWAE) exam and earned my Offensive Security Certified Expert (OSWE) Certification.

Background

I previously achieved my OSCP (Offensive Security Certified Professional) in 2018 and knew then that I wanted to ultimately earn my OSCE (Offensive Security Certified Expert). However, I had other commitments – I was enrolled in both Oregon State University Post-Bacc in Computer Science Program and the SANS Institute’s Graduate Certificate for Penetration Testing. I had other commitments and had to put my goal of earning OSCE on hold.

In August 2021, I had completed by SANS graduate certificate program and most of my courses for OSU (I’m currently completing my final class) and I had extra bandwidth to again pursue my OSCE.

The AWAE is one of three certifications needed from Offensive Security to achieve OSCE – the other two being OSEP (Offensive Security Experienced Pentester) and OSED (Offensive Security Exploit Developer).

Who is Offensive Security

If you’re not familiar with Offensive Security, they are the company responsible for creating the most popular Linux Distro in use for penetration testers and security practitioners – Kali.

They also provide training and certifications in the various field of penetration testing, e.g. windows/linux/Mac exploit development, black box penetration testing techniques and methodologies, web application penetration testing, etc.

Offensive Security certifications are arguable the most well-respected in the INFOSEC community – even by those who scorn certifications.

This is because you are required to demonstrate hands-on practical ability to launch a successful penetration test.

The AWAE exam is a proctored exam where you’re given access to a VPN with vulnerable web applications. You’re required to identify the vulnerabilities in those web applications and write your custom script to exploit them. There are no hints and you can’t phone a friend.

What is AWAE

Anyone who has take other penetration testing courses know that the field is very broad – there are different phases/aspect of a pen test engagement. AWAE is focused solely on exploiting Web Applications.

In the Penetration Testing With Kali Linux (PWK)/OSCP course, the approach was from a black box perspective – you had no prior knowledge about what services the VMs were running. You were taught the process of scanning, enumerating, then exploiting machines.

In AWAE is a course in white-box penetration testing. You know the vulnerable service is a web application and you’re given access to source code.

In the PWK/OSCP there were 40+ machines to exploit, in AWAE there 6+. The number of targets is smaller, but you’re digging through thousands of lines of code to discover vulnerabilities.

AWAE/OSWE differs from PWK/OSCP in that you write your own exploit – typically in python. The general strategy is exploit authentication then achieve a shell, i.e. remote code execution.

The instructor walks you through on processes and methodologies to identify vulnerabilities in the different web applications and how to exploit them.

If PWK/OSCP is a mile wide and one inch deep, then AWAE/OSWE is a mile deep and one inch wide.

Recommended Pre-requisites

AWAE is an advanced course, if you’re new to cybersecurity or penetration testing, this is not for you. I recommend you have a baseline level of knowledge and skills prior to taking the course:

• Scripting Language, recommend Python
  • Needed because you have to write your own exploits for the exam
  • Python recommend because this is what’s used in the course
• Understanding of routes/endpoints in web application
• Preferably familiar with one web application framework, e.g. nodejs express, django, php ruby on rails
  • If you know one, that should give you sufficient exposure to understanding how web applications are built,
• General understanding of vulnerabilities in Web applications e.g. sqli, xss, csrf, etc.
  • no need to be an expert, you’ll get tons more instruction during the course
• Understand how to read regular expressions e.g. “.*?var.*?sql.*?=.*?query.*?
• Be comfortable using IDE for debugging e.g. Visual Studio, or Eclipse. In the course you’ll be debugging in VS Code a lot
• Foundational understanding of programming:
  • Control Structures (if, while, for, etc)
  • Data Structures (dictionaries, lists, arrays, etc)
  • Data types (strings, ints, floats, booleans)

AWAE Exam

As stated before you have 48 hours to exploit a certain number of vulnerable web applications. You have another 24 hours to write a penetration testing report.

• The exam is proctored, you’ll be required to verify your ID and to perform a sweep of the room you’ll be taking the exam in.
• Take breaks regularly. Examining thousands of lines of code will wear you down quickly. During the first day I took an hour long break roughly every four hours. In the second day, I needed a 10-15 minute break every hour. I probably could’ve planed breaks a better
• Do plan to get one solid block of sleep. I did not execute this properly, learn from my mistake. I was in bad shape during the second day.
• You can’t have your phone with you in the same room.
• You’ll need to notify the proctor anytime you leave and return to your computer.
• Don’t get stuck going down a rabbit hole. If an avenue you’re going down an avenue that you thought might lead to an exploitation but doesn’t, don’t be afraid to take a step back and examine another route.
• Take down notes about your thoughts and methodology on the vulnerabilities you discovered.
• TAKE SCREENSHOTS REGULARLY! It’s easy to get caught up in the engagement. Don’t be that guy who get all the ‘proof.txt’ and ‘local.txt’ files but forgets to take screenshots showing how you got them. You will fail if report is lacking.

Conclusion

I was really happy with the course, I learned tons of new techniques and methodologies to exploit web applications. I absolutely feel that I came away from the course a more knowledgeable security practitioner – both in theory and in practical, hands-on application. I think it was money well spent.

I expect that I will be enrolling in the OSEP course in the near future and the OSED following that. God willing, I’d achieve those two certs and become an OSCE.

Thanks for visiting,

Cheers

Overview:

In this tutorial we’re going to cover the following topics:

• Creating Nodejs routes
• Creating a Handlebars templates
• Writing a webpage vulnerable to XSS exploit

Nodejs Router:

I’m going to introduce you to Routers, instead of explaining (probably in later post), I’ll just show you by example. To start we’ll need to add a new route in our ‘app.js’ file:

• ‘app.use’ :: this will bind a route – ‘/xss’ – the the middleware layer that we want to use, i.e. ‘xss.js’
• Easier explanation :: anytime a user visits the ‘/xss’ route in our web application, e.g. http://127.0.0.1/xss, it tells the server to execute the functions defined in the ‘./xss.js’
• We have to define a new file names ‘xss.js’ in the same directory as the app.js file. Note, if we instead defined the middleware as ‘./public/xss.js’, then we have the have folder named public in the same directory as the ‘app.js’ file, and within that ‘public’ folder, we would need to define ‘xss.js’

Define ‘xss.js’

Create and open a file named ‘xss.js’ in the same directory as ‘app.js’

touch xss.js 

If we listed all of the contents in the current directory (ls -al), it should like the following:

Open up the ‘xss.js’ in an text editor:

vim xss.js

Screenshot of the skeleton code:

I’m going to try and explain what’s going on here and hope this makes sense.

Recall in the ‘/wagmi’ route, anytime this endpoint is visited it executes a function that defined inline:

The ‘/xss’ route also needs a handler/function that is executed. In this instance we’re ‘importing’ – through the use of ‘require’ – the functions from the ‘xss.js’ file. Because we’re importing the function, then the ‘xss.js’ file must export a function, which it does. Notice the use of ‘module.exports’:

Hopefully, this explains what’s going. If not, just hit the “I believe button’ and copy the code. Moving on we have to define what handler will be doing when the ‘/xss’ route is visited.

We define that as so:

Note, do not get confused with ‘/’, root, endpoint. This is not defining the route for http://127.0.0.1/, it’s defining the handler for the http://127.0.01/xss/

Recall that in the ‘app.js’ file it’s redirecting all traffic to the ‘/xss’ endpoint to the ‘xss.js’ file. Using ‘/’ means we are using the root ‘/xss’ endpoint. In the ‘xss.js’ file, if we instead use ‘/subdirectory’, instead of ‘/’, we would be defining the route for http://127.0.0.1/xss/subdirectory.

Quick description of what’s going on inside the handler:

• we initialize variable ‘context’ which will be a dictionary
• we set dictionary key name ‘text’, i.e. context.text’ to value in query parameter ‘text’.
• we send a response back to the client that visited the ‘/xss’ endpoint.
  • we use our templating engine – ‘handlebars’ – to create the html page
  • we pass the context variable for ‘handlebars’ templating engine to use.

We have to tell our web app to use the handlebars templating engine. Let’s do that now.

Handlebars Template Engine

In the ‘app.js’ we have to configure our web app to use the handlebars templating engine:

• We are importing (i.e. require) the handlebars package
• We are telling handlebars the default html script to be included in all of our html pages
• We are setting the web app template engine to handlebars

Recall the directory structure in the first tutorial:

This is a standard layout when using the ‘handlebars’ template engine. It’s important specifically to have the ‘views’ and the ‘view/layouts’ directories.

In the ‘layouts’ directory, is where we define the ‘main.handlebars’ template, this will be included in every html page our web app responds with.

The ‘views’ directory will have the specific handlebars/html templates for our routes. We do this because, presumable, we’ll have different html for different endpoint, we don’t want the same html for all of our webpages, that would be boring.

Screenshot of my main.handlebars template:

html code inside ‘main.handlebars’

<!doctype html>
<html>
<head>
<title>My Page</title>
        <!--bootstrap setup -->
        <meta charset="utf-8">
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js"></script>
        <link rel="stylesheet" href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" integrity="sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T" crossorigin="anonymous">
        <link rel="stylesheet" href="https://pro.fontawesome.com/releases/v5.10.0/css/all.css" integrity="sha384-AYmEC3Yw5cVb3ZcuHtOA93w35dYTsvhLPVnYs9eStHfGJvOvKxVfELGroGkvsg+p" crossorigin="anonymous"/>
        <script src="https://cdn.rawgit.com/mgalante/jquery.redirect/master/jquery.redirect.js"></script>

        <script src="https://unpkg.com/axios/dist/axios.min.js"></script>
        <script src="https://cdnjs.cloudflare.com/ajax/libs/popper.js/1.16.0/umd/popper.min.js"></script>

</head>
<body>
        {{{body}}}
</body>
</html>

In my main, I include the sources for bootstrap and jQuery. This is where you ideally put styling sources that you want rendered for all of your pages. This is a benefit of using templating engine – you minimize the amount of code that is repeated. You need this because I’m using bootstrap styling.

We now need to define the index.handlebars file, the file that is rendered when someone visits the ‘/xss’ route.

Creating an XSS vulnerable Webpage

In the ‘xss.handlebars’ file write the following code:

<h1>Cross Site Scripting Test</h1>
  <div class="container">
          <form action="/xss" method="get">
                  <div class="form-group">
                          <label for="text">Input Text Here:</label>
                          <textarea class="form-control" name="text"></textarea>
                  </div>

                  <button type="submit" class="btn btn-primary">Submit</button>
          </form>
          {{#if text}}
                  {{text}}
                  {{{text}}}
          {{/if}}
  </div>

The important parts:

• We creating a form element
  • The form element has a textarea/text box, where the user can provide input
  • The textarea/text box has a ‘name’ attribute of ‘text’, this is equivalent to a variable. When the types in input and submits, the user’s input is set to the ‘name’ variable
  • when submitted it performs a ‘GET’ request to our ‘/xss’ route
• Notice the Block of code defined between {{#if text}} … {{/if}}, handlebars supports if statements.
  • If the handlebars engine is passed a variable named ‘text’ it will generate that into the html
  • {{text}} (double brackets) will escape special characters
  • {{{text}}} (triple brackets) will not escape, it will generate the exact string that the user inputs into the form.

Save the file.

Testing the web application

At this point we should be ready start up our web applications.

Navigate out of your ‘views’ folder where you edited the ‘index.handlebars’ page and into the directory where your ‘app.js’ file is. The contents of your current directly should like so:

Startup the web application:

node app.js

Open up a Google Chrome browser and browse to http://127.0.0.1/xss:

Insert the following into the text box:

<script>alert('wagmi');</script>

Click ‘Submit’. You should’ve receive a text box popup stating “wagmi”:

Congratulations! You not only completed fully function web application, you wrote one that was vulnerable to XSS.

Vulnerable Piece of Code

unescaped user input

The culprit that results in an XSS vulnerability is the use of triple brackets in the handlebars templating engine. Handlebars will render the user input exactly as written, there is not escaping/sanitization of user input.

A quick fix would be to use the double brackets to render variable passed into the handlebars template, this would escape special characters.

Another option could be to perform user input sanitization in our middleware. I’ll leave this to you to research what node packages are available to sanitize user inputs.

Anyway, I hope you found this tutorial enlightening. In the next few tutorials, I want to go over how to connect your web application to a Database and introduce sql injections.

Cheers,

Francis

Greetings and welcome to my blog – Francis’s Microsdose.

My name is Francis (go figure) and I am cyber security engineer in the Defense Industry. I’ve been in this field for nine years and counting.

I hold B.S. in Mechanical Engineering, US Naval Academy, M.S. in Cyber Security Engineering, University of San Diego. I’m currently pursuing my B.S. Computer Science from Oregon State University (one class remaining) and M.S. Computer Science from Georgia Institute of Technology (eight classes remaining). I should be complete with my B.S. by spring of 2022.

I also hold numerous Cyber Security Certifications – CISSP, GCIH, GPEN, GWAPT, GXPN, and OSCP (I’m most proud of this one). I’m currently pursuing Offensive Security’s Advance Web Application and Exploitation Certification and hoping to ultimately my Offensive Security Certified Expert Certifications

I started out this blog to: share advice on how to make it in the Cybersecurity field; document and share tutorials of my past, present, and future penetration testing challenges; and just share my thoughts on anything cybersecurity related.

I hope your ass passionate about cybersecurity as I am and that this site proves to be a useful resource.

Cheers,