In this post, we’re starting a new series the Advent of Cyber series that is hosted by TryHackMe. This is the third year of the Advent of Cyber where a challenge is released everyday leading to Christmas. In total there will be 25 challenges. In these challenges, we’re McSkidy an elf trying to save Christmas.
In our first challenge, we’re presented with a scenario where the Grinch is trying to destroy Christmas by possibly using an IDOR (Insecure Direct Object Reference) vulnerability. IDORs are a vulnerability where sensitive information can be accessed without the proper authorization. These types of vulnerabilities can be found in real world applications and are good test cases for bug bounties… *hint, hint*
Can we save Christmas by solving the first challenge by stopping the grinch?
On Friday February 5, 2021, I provided a training on teaching Application Security concepts using the OWASP Top 10.
The Open Web Application Security Project or OWASP is a non-profit organization whose mission is to make application security better. Members of OWASP meet every few years to create a top 10 list of the prevalent vulnerabilities in the industry. The last list was from 2017.
The structure of my training is the first part is to present the theoretical part – concepts and definitions. The last part of the training is a practical or application of the first part of the training (theoretical).
For the practical piece I used the website – BodgeIt Store. The BodgeIt Store is an insecure app, that should NOT be deployed in commercial servers. Many will say that the BodgeIt Store is a SUPER old insecure app (it’s close to 10 years old).
The app is close to 10 years old, but I find this app is good to teach application security as there’s a scoreboard and 12 challenges to complete.
Anyway, without further ado below are my slides from my training
I also provided documents that provide a walkthrough of the BodgeIt store as well as installing and using an interception proxy such as Burp Suite.
Finally, I included instructions on how to import the OWASP Broken Authentication VM which have a series of insecure apps.
After entering the username/password we see the following screen:
On the right side there’s a link that says, “view sourcecode”.
Clicking this link we see the following:
First, you should notice that there is weird syntax (language) of “<? and ?>” What is this? Well, this is PHP (Personal Home Page). Which is a server-side programming language.
What exactly is passthru? Passthru is a function that executes a command. To learn more about the passthru function click HERE. In this case we’re using the word in the first screenshot to look through a file named dictionary.txt.
Let’s try to enter the word “test” to see what we get…
The code returns all of the words that have test in it. OK. Let’s see if we can get ALL of the words in the dictionary.txt file.
Let’s try the word of “” instead of test. Doing that we get the following:
We have all the words in the dictionary.txt file. Why did I pick “” ? Well if you look in the passthru function the command was enclosed in quotes. I figured that if I entered quotes we would break out of the command which would produce all of the words in the file.
So now we have all of the words, what do we do now?
The challenge seems to be vulnerable to command injection. To learn more about command injection, go to the link HERE.
Let’s try to add another command to list all of the directories in the folder. The command to enter is: ls%20-la; (%20 is the URL encoding of space). This command is listing all of the files in the directory include hidden ones (in Linux hidden files start with the “.”).
We have listed all of the directories, and have a potential gem. There’s a file named .htpasswd. Let’s add on to the command sequence to open this file. To do that we add the following: cat%20.htpasswd;.
We have received the password! Which is: $1$p1kwO0uc$UgW30vjmwt4x31BP1pWsV.
Today’s blog post will discuss my experience with SANS 542 for the GWAPT certification. I completed the course through the OnDemand (online) version.
Let me preface with a few disclaimers:
This class was on my bucket list for the last year, so I was VERY ecstatic when I was able to enroll
My job paid for this course as it’s $6k+ which includes: practice test (2x) and certification attempt. This does not include travel arrangements (flight, hotel, and food).
As you can see the class is expensive, but it’s a good course to invest into if you want to become a penetration tester.
The course is broken into 6 parts. Let’s discuss each section.
Section 1: Introduction and Information Gathering
As the title states, this was a primer of web application testings with reviewing the HTTP and HTTPS protocols, discuss web infrastructure, and discuss reconnaissance using the following tools: WHOIS and DNS. Finally, I was introduced to a web application vulnerability such as Heartbleed.
I found the material to progress at a nice pace. I had a general knowledge of web application pentesting by tinkering with a home lab, but this introduction filled in some of the blanks that I had.
Section 2: Configuration, Identity, and Authentication Testing
This section heavily relies on mapping a web application target, and reconnaissance, which is arguably the most important part of testing. Some of the tools that was used were: nmap, cURL, and manual techniques using Burp Suite (such as Burp Intruder). In this section, I was introduced to another web application vulnerability – Shellshock, which surprisingly was vulnerable for 25 years!
I REALLY enjoyed this section as I am a hands-on learner, so tinkering and learning new techniques was great. Also, I had a rush whenever I was able to successfully exploit a vulnerability.
Section 3: Injection
In this section I learned about SQL, Blind SQL, Error based SQL injection, command injection, remote file include (RFI), local file include (LFI), session tracking, authentication bypass by using the vulnerable application Mutillidae. Mutillidae is a great application to use when honing your web application skills as I previously stated the application is vulnerable to A LOT of attacks!
Again, I really enjoyed this section, I learned some new skills (LFI, RFI, and command injection), I already knew about SQL injection before taking the course.
Section 4: XXE and XXS
In this section, I learned about the different flavors of Cross-Site Scripting (XSS) – reflected, stored, or DOM, XML External Entity (XXE), XML and JSON, as well as logic attacks to web applications.
Again, enjoyed this section, and I learned A LOT. I knew about Cross-Site Scripting and the different flavors but had NO clue about XXE or XML. It was interesting to see the techniques on how to launch an XSS attack using JSON. As well as how I can use the logic and data returned from an application to deduce certain aspects of the application and craft attacks to exploit said application.
Section 5: CSRF, Logic Flaws and Advanced Tools
In this section, I learned about Cross-Site Request Forgery (CSRF), and tools such as: Metasploit, WPScan, w3af. Also, I learned how to use Python to leverage attacks on web applications as well as how to pivot inside a web application. Also, a cool talking point was on when the tools fail, which is a real scenario.
I enjoyed this section. I am glad that the professor touched on when tools failed. There are some people who heavily rely on tools and get discouraged or miss vulnerabilities when said tools do not work.
Section 6: Capture The Flag
This by far was my favorite part of the course!!! Since my class was online, the capture the flag was online as well. Note, if this class is completed at a SANS location then the capture the flag is an all day event on the 6th day. The team (or person) who has the highest score receives a medal.
Anyway the capture the flag incorporated all of the concepts of the class into a realistic environment.
Things to say about the capture the flag – while it was fun, I made STUPID mistakes. Remember when I said that information mapping was important? I lost 4 points, due to not correctly map the web application. For instance, I completed IGNORED a server that had a TREASURE TROVE of vulnerabilities. <– Yes, I am still kicking myself for that mistake.
The capture the flag was super fun as it started with answering questions and then progressed into hands-on exploits. Also, the questions started to get harder as the game progressed (I am a gamer at heart!) Also there were some funny Aha moments, such as the classic music video. I also fell prey on trying to use to tools, which made answering some of the questions harder than it needed to be. The question could’ve been on a difficulty level of 3 and I made it into a 9 by customizing a fancy exploit that was not needed.
At the end of the 4 months, I finished #11 out of 40 people. Not too shabby. If I didn’t make the mistakes above, I would’ve finished in the top 10.
Final assessment of the course: I LOVED the course!!! Like I kept reiterating I learned a lot of about exploiting web applications, that I will take with me in my journey as a pentester. I liked that each book was built on top of each other. Meaning in book 1 I started off with a primer and learning about web application architecture(s). When I started book 2, I built on top of book 1’s knowledge to then learn about information gathering and reconnaissance, etc. By book 6 (capture the flag) I had a solid foundation on how to actual execute a web application penetration test.
The good thing about this course is that the exploits are not cookie cutter. There were times where I scratched my head and had to do an exploit two to three times to FULLY understand all of the moving parts. Also, another great thing about the course is that the student will receive books for each day (that you can keep) as well as a custom VM that has all of the labs, vulnerable applications, and tools that were used in the course just in case if you want to study or find more vulnerabilities once the class is over. As my instructor, Eric Conrad stated, “One of the differences between a good and great penetration tester is creativity.” I want to be a great pentester, and this class will help me get there.
One last thing… the GWAPT certification. I will not go into detail about test questions (as that is unethical), BUT I will say the test is open book. Make sure to fully utilize the practice test(s) by pretending it’s the REAL test. These practice tests will give you a baseline of how well you know the material. You then can go back and review said concepts and take the second test again to see if there’s improvement. I have taken 4 SANS courses (including this one), with 3 certs, and I can tell you that your index is the MOST important thing for when you take the real test. Your index will literally make or break you, so it’s important to spend a considerable amount of time to make sure your index matches your learning style. The test has a time limit of 3 hours, and you will need to answer 75 questions with a passing score of 71% and above. If you score 90% and above you will be placed in an elite group called the Advisory Board. You can learn more here.
If there are anymore questions, please do not hesitate to reach out to me on twitter at @DevSecOpsGrl007.
The challenges we’re going to solve are the following:
Log into the application as firstname.lastname@example.org
Log into the application as email@example.com
Log into the application as firstname.lastname@example.org
Going to the application let’s go to the login page – screenshot:
Reviewing the objectives we have the username (email), but we don’t have the password… Meaning we can’t log into the application… well let’s see.
We already know the application is buggy (our favorite!) so it will not be hard to deduce that the application is not sanitizing our input. Meaning we can append certain characters in the username box and bypass entering a password to log into the application.
What possibly are these characters?
We know that for a valid login there has to be an back-end database that is used to test the username and password. We have the username, but what if we trick the database with a true statement and allow us to log into the application without entering a password.
The topic that I am talking about is SQL Injection. Doing a Google search you will see there are plenty websites dedicated to this topic.
Let’s imagine that the back-end database is the following:
SELECT valid_login FROM customers WHERE username=uname AND password=passwd;
Note: valid_login will return a boolean (TRUE/FALSE)
The username is the email that we have plus the appended characters –> email@example.com’ OR ‘1’=’1
Password is going to be blank.
So the above line will be:
SELECT valid_login FROM customers WHERE username=’firstname.lastname@example.org’ OR ‘1’=’1 AND password=<blank>;
The password is going to be blank.
Let’s break down the above statement
We’re closing the email@example.com expression, and then we’re going to include a new expression using the OR statement. The next expression is 1=1 which will ALWAYS evaluate to true (1 does equal 1).
Try it in the application and see what happens.
First, let’s configure our browser to listen through our Burp proxy.
Going to the login page, let’s add the username of firstname.lastname@example.org’ OR ‘1’=’1′, with no password, and press the Login button.
We’ve successfully logged in without a valid password!
Let’s see if we can do this with the second username: email@example.com
We were able to log into the application as user1, without supplying a valid password!
Let’s try username: firstname.lastname@example.org
Going back to the login page, let’s enter the username as email@example.com without supplying a password.
We were able to log into the application as an admin without supplying a valid password.
Hmm… we see with the admin login we have a new link – Comments. We’ll come back to this in another post.
Going back to the scoreboard we see:
All of the login challenges are now complete (green)!