Category: Uncategorized

So I haven’t been posting too many tutorials on this blog. I’m taking a different direction with the tutorial. For capstone project, my teammate and I are working on building an intentionally secure web application that incorporates the OWASP TOP 10.

We’re designing the website as walkthrough/tutorial. I think that form factor will be much more easily digestible than just posting a long instructions.

In the meantime, checkout this capstone poster we created.

Whew.. the past few weeks for me have been pretty hectic – it’s mostly work. Posting here on my blog has slowed to a crawl. The tutorials take up a quite a bit of time to write up.

If you’ve been keeping up, you’ll know that I have my Offensive Security Certified Professional Certification and recently earned my OSWE (Offensive Security Web Expert) certification in January. My ultimate goal to achieve OSCE status over the next 18 months.

An Offensive Security Certified Expert (OSCE) requires three certifications to achieve – OSWE, Offensive Security Exploit Developer (OSED), and Offensive Security Expert Penetration Tester (OSEP). I have one of the three.

I decided to enroll earlier this week in OSED. The course work primarily deals with binary exploitation (Stack, Return Oriented Programming, etc) of Windows Executable. It doesn’t really get into heap exploitation, but I’ve been studying up on that through open source materials.

I’m pretty excited about starting the new class and I’ll keep everyone updated on my progress as well trying to post new tutorials.

Cheers.

In my previous post I discussed how to setup a mysql server with AWS RDS services. In this post I’ll cover how to create a web application that vulnerable to SQL Injection.

I’m going do this tutorial a little differently than the previous tutorial. I’m going provide you my code:

git clone https://github.com/dailigf/cs467_Vulnerability_POCs.git
git checkout sqli_poc

The above command will clone my repository into your working directory and will checkout the “sqli_poc” branch.

You’ll need to create main working directory of the web app, you’ll need to create a folder named “database” and inside the “database” folder, a file named “db_connector.js”.

mkdir database
touch database/db_connector.js

Contents of “db_connector.js”:

You’ll need to enter the contents of your username and credentials.

Vulnerable Piece of Code

The vulnerable piece of code is located in the “sqli.js” file:

In this code we are creating an sql query by concatenating user input directly. This is always a bade idea.

Testing out the Vulnerability

We’re going to run the web application:

node app.js

Then open up a browser and browse to “http://127.0.0.1/sqli/test”:

The web application requires a name, in this case I’ll provide the name of “francis” because that name is currently in the user table in my capstone database. The website will return the following page:

The query return my full name.

Proof of Concept

If we enter the following into the text area:

'UNION ALL SELECT 1,2,3;#

Explanation of the POC:

• ‘ (single quote) :: the single quote in the beginning “closed off” the single quote in our sql query
  • Essentially the query became:
  • SELECT users.userId, users.first_name, users.last_name FROM users WHERE users.first_name = ”
  • it’s a valid query, but it’s an empty record

• UNION ALL SELECT 1,2,3
  • This will join the previous query with the “SELECT 1,2,3” query.
  • In the initial query there are three attributes it’s pulling from the DB – userId, first_name, and last_name
  • SELECT 1,2,3 must match the number attributes pulled, otherwise the union/join will be an error. In SQL Unions between two tables have to have the same number of attributes/columns, hence why we perform SELECT 1,2,3
  • If the previous query only pulled to records from db, our UNION Select statement would be “UNION ALL SELECT 1,2”
• ; (semi-colon) :: this signifies the end of an sql statement
• #(hashtag) :: everything after this is commented out, it’s not treated as query.

Pulling data from another table in the database

A “UNION” is interesting but not all that useful, however, what it does provide is an indication that the server is vulnerable. With this in mind, it’s possible pull information from other parts of the database.

Recall that our web application was only pulling information from the “users” table. With an sqli vulnerability, we can grab information that we were not meant to see. Example:

'UNION ALL SELECT 1,(SELECT password from credentials where userID=1), 3;#

Here we were able to pull the password attribute from a completely different table – “credentials”.

Anyway I hope this post proved enlightening. I’ll probably revisit this to provide some more detail. I’ve been pretty busy with work lately.

Until next time, cheers.

In the next series of posts I’m going to provide a tutorial on how to write and exploit and SQL Injection vulnerability on a web applications. However, before we can get there we need to setup our database.

We could set it up on our local machine, but that would be too easy, instead we’ll use Amazon’s RDS (relation database service) to setup our database.

I’m not going to walk you through creating an AWS account, it’s pretty straightforward. I’m going to assume you have an account.

1 Navigate to the RDS Service Dashboard

If you don’t know how to get to the RDS Service, you can search for it:

• 

You’ll be presented with following dashboard:

II. Create Database

In the Create Database page, we’ll select the following features:

• Database Creation Method – “Standard Create”

• Database Engine – “MySQL”

• Version – 8.0.27

• Template – “Free Tier”

• DB Settings – Username/Password

• Instance Class – Leave Default

• Storage – Leave Default

• Connectivity – Leave Default

• Database Authentication – “Password”

• Create Database

You’ll be re-directed to the following screen:

It will take a few minutes for the server to get created on AWS’ servers. The server is technically created/built at this point, however, we now have to make it accessible from the Internet, i.e. your home computer.

• Click on the “database-1” hyperlink to configure

III. Make the DB “Publicly Accessible

• Click on “Modify”

• In the “Connectivity Section”, Click on “Additional Cofiguration”:

• Select “Publicly Accessible” option:

• Click on “Continue” at the bottom of the page
• Click on “Modify DB Instance” on the next page

We are not yet complete with our configuration. You’re RDS or EC2 instances inside your VPC (Virtual Private Cloud) have NACLS (Network Access Control Lists) and Security Groups (SGs) applied to them:

IV. Quick Lesson on SG and NACLS

• Security Groups

Think of Security Groups as Host Level Firewalls. All of your instances running in your VPC must have a Security Group applied to them.

With Security Groups, you set the allowable ports/protocols/services and source addresses.

• Network Access Control Lists

NACLs are applied to the subnets in your VPC. Every subnet in your VPC must have NACL associated with it.

All of your instances will belong to a Subnet.

All of your Subnets will have a NACL applied to them.

With NACLS, you can configure based on IP address(es) and Ports

• Quirks

If you have NACLs set to allow “All traffic” through, but your Security Group is “Deny All”, you won’t be able to reach your instance

If you have your NACL set to “Deny All”, but your SG to “Allow All”, you won’t be able to reach your instance

A good strategy with managing NACLs and SG is:

• NACLs: Filter only by IP and allow all ports/protocols
• Security Groups: Filter by Ports/Protocols

V. Configuring the Security Group

• From RDS Dashboard, click on your DB Instances

• Select your DB Instance

• Under the “Connectivity and Security” menu, select the default security group
  • Recall that this was left to default when first created the DB
  • This Dashboard shows which SGs are applied to our RDS instance and we can just follow the links to edit it.

• Select “Edit inbound rules”

• Add rule to allow “MYSQL/Aurora” traffic type from the drop down
• Select “Save Rules”

VI. Configuring the NACL

• From RDS Dashboard, select “DB Instances”, then select your running RDS instance

• Click on the VPC hyperlink under “VPC”

• Click on the hyperlink under “Main network ACL”
  • mine is “acl-f483728f”
  • your’s will be different

• Click on the “Inbound Rules” tab, then “Edit Inbound Rules”

• Add a rule to allow all ports and traffic (0.0.0.0/0)

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,