Tag: webapp

boot2root, hacking, web application security

@Vulnhub – Solving #Cofveve

thefluffy007

Another day, another challenge.

In this post we’re going to solve the Cofveve virtual machine.

Let’s get started

After downloading the virtual machine and starting it we see the following:

Using the netdiscover command we can find the IP that the virtual machine is using

Going back to our attacking machine (I’m using the parrot virtual machine).

Doing an nmap scan with the command – nmap -sV <IP address from netdiscover command>, we see the following

There are three ports that are open – ssh, and two http ports.

When http ports are opened the next step is to try to do a recursive brute force attacks to find hidden directories.

We’re going to use two programs – dirb and gobuster.

Doing the dirb of port 80, we get:

Using gobuster we see:

We see that both of the programs did not return anything.

Let’s try to the following programs with the 31337 port, let’s start

We see five files – a robots.txt, and four hidden files (start with .)

The robots.txt gives information about sites that should not be crawled by the internet. This is useful as it will give us files or directories (folders) to review to get more information.

Going to the robots.txt we see:

Hmm, there are three directories that are disallowed. Let’s try to go to them.

Let’s start with taxes. When navigating there we see:

We found the first flag!

Going to the second directory .bashrc we see

Hmm, it’s a file, let’s save it.

Going to the last directory of .profile we see

Another file to save.

Going back to either dirb or gobuster results we have one more directory, .ssh.

This is strange. The .ssh which is hidden should not be exposed on the internet. This folder has information about how to login into the system. Such information is a private key (which only the user should know) public key (which everyone knows), as well as other things.

Going to this folder we see:

We see three items, which look like additional files.

Let’s see if we can navigate to these files.

Navigating to the first item, id_rsa we see:

Another file, so let’s save it.

Let’s try the second file – authorized_keys. Going there we see:

Another file, let’s save it.

Finally, let’s go to the third item – id_rsa.pub

Now that we saved everything let’s go back to our virtual machine and open the files.

First, let’s open the id_rsa.pub file. This file is the public key that is part of a pair. The other pair is the private key. As the name suggests only the user should know their private key and not expose it to anyone else. The public key can be exposed to everyone.

Opening the file we see:

We see a ssh-rsa. RSA is a cryptographic algorithm. Looking at the end of the file we see a valid user – simon@covfefe. We need to save this user as we will need it later.

Opening the id_rsa file we see:

This file is the private key to log into the SSH server as Simon! This is bad, as I said before this file should NOT be exposed as Simon private key should only be known by him only.

Opening the authorized_keys file it has the same content as the id_pub

How can we use this information?

We know a user (simon@covfefe) and a private key.

Well we can log into the ssh server.

Let’s start.

We can use the command ssh -i id_rsa simon@covfefe

Let’s break this down.

We’re logging into the SSH server, specifying a file id_rsa (Simon’s private key) and the user of Simon

We get the following output:

Uh oh – we received an error:

The private key is too open. We need to change the make it less accessible. To do this we’re going to change the permissions from 644 to 600. What this will do is give access to the owner in this case parrot (which is us).

To do this we will use the command chmod 600 id_rsa

Trying to log in again we have the following:

We need a passphrase… which we don’t have. How do we get this?

Doing a good ol’ Google search of cracking passphrase for id_rsa we see the following link

We see there’s a command ssh2john which can be used to crack the passphrase. Let’s do it!

First, we located where the ssh2john command lives in the file system. Next, we’re going to create a hash using ssh2john. We’re going to use this for the next step.

Next, we’re going to send our hash to john which will be used to crack it. We’re going to use the wordlist rockyou.txt which is a common wordlist used to crack passwords. Doing so, we found our passphrase – starwars.

Running our SSH command again, we enter the passphrase of starwars and we’re in the system!

Doing a long listing and showing all of the files (ls -la) we see the files we found before when brute forcing the directories. Let’s look at the .bash_history. This file is good to review as it will let you know commands that were executed on the machine.

Opening this file we see a read_message and then exit. What is read_message? Is this a program?

Executing the read_message we get a prompt. Let’s enter the name Simon. We received a message stating this is is a private messaging system and the source code is in the root directory.

Navigating to the root directory and doing a long listing with all the files (ls -la) we see there’s a read_message.c file, and flag.txt!

Opening the flag.txt file we see a permission denied :-(. Looking at the long listing again this file (flag.txt) can only be accessed the owner, which in this case is root (column 4). I am the user Simon, so I can’t view the file.

Opening the read_message.c file, we see source code, and… the second flag!

And it’s giving us a hint – we need to review the source code.

Looking at the source code we have a buffer (buf) that is holding 20 characters and is executing another file program which is pointing to /usr/local/sbin/message. Whenever we see buf we need to think of buffer overflows.

Buffer overflows are a vulnerability where you overflow the input to access other parts of the computer system. In this case, since we have a holding space of 20 characters – we’re going to overload the buffer with characters OVER 20 characters. Also we’re going to try to change the shell to /bin/sh <— bourne shell. We’re going to change the shell to escalate the user. Changing from Simon to root. We need to be root to open the flag.txt file.

Let’s try it.

Running the commands id and whoami we see we’re root!

Now let’s open the flag.txt and see what’s in the file.

We solved the challenge!

hacking, owasp, web application security

OverTheWire: Natas Level 9 – #appsec #webapp #websecurity #wargames

Another day, another hacking challenge…

Today’s challenge is to find the password for level 9.

To view level 8, please go HERE.

After entering the username/password we see the following screen:

level9_beginning

On the right side there’s a link that says, “view sourcecode”.

Clicking this link we see the following:

level9_source_code

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…

level9_test

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:

level9_all_words

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 “.”).

level9_listing_directories

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;.

level9_ending

We have received the password! Which is: $1$p1kwO0uc$UgW30vjmwt4x31BP1pWsV.

hacking, owasp, web application security

My Experience with SANS SEC542 – Web App Penetration Testing and Ethical Hacking Course #infosec #webapp #sans542 #ethicalhacking #gwapt

thefluffy007

Another day, another hacking post.

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:

  1. This class was on my bucket list for the last year, so I was VERY ecstatic when I was able to enroll
  2. 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.

temp

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.

Until next time!

hacking, owasp, web application security

The BodgeIT Store Series #6, Access Someone Else’s Basket – #bodgeit #infosec #pentest #appsec #webapp

thefluffy007

Happy Hacking!

Today’s post is #6 in the BodgeIt Store series.

To view post #5 in the BodgeIt Store series click HERE.

The topic for today is to access someone else’s basket.

First, let’s go to the admin page, and notice the different basket ids:

bodgeit_new_admin

We see that for each user – there’s a corresponding basket id.

Let’s go to the Your Basket page. Going there we see the following:
bodgeit_new_your_basket

Let’s open Burp and see if our traffic will reveal anything to us.

After opening Burp, and clicking on the “Update Basket” button we see:

bodgeit_basketid_initial

Hmm.. we see there’s a cookie value of b_id. Could this possibly be basket id?

Let’s try changing the value from 8 to 0 (which is the admin basket).

bodgeit_basketid_admin_not_working

bodgeit_basketid_admin_not_working_basket

OK… we see that the basket has been updated and we received a system error. This let’s me know that admin basket didn’t work too good.

Let’s go back and try another basket id of 1 which is the user1 account.

bodgeit_basketid_initial

bodgeit_basketid_changed_value

bodgeit_basketid_final

OK, changing the basket from 8 to 1 (user1 account) we see that our basket has been updated to show the user1 basket.

Let’s go back to the scoring page and see if we have successfully solved the challenge.

bodgeit_scoring_8

We solved the challenge successfully!

hacking, owasp, web application security

The BodgeIT Store Series #5, Login as a Different User?! – #bodgeit #infosec #sqli #pentest #appsec #webapp

thefluffy007

Happy hacking!

Today’s blog post is #5 in the BodgeIt Store series.

To view blog post #4, click HERE.

The challenges we’re going to solve are the following:

  1. Log into the application as test@bodgeitstore.com
  2. Log into the application as user1@bodgeitstore.com
  3. Log into the application as admin@bodgeitstore.com

Let’s begin.

Going to the application let’s go to the login page – screenshot:

bodgeit_login1

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 –> test@bodgeitstore.com’ OR ‘1’=’1

Password is going to be blank.

So the above line will be:

SELECT valid_login FROM customers WHERE username=’test@bodgeitstore.com’ OR ‘1’=’1 AND password=<blank>;

The password is going to be blank.

Let’s break down the above statement

We’re closing the test@bodgeitstore.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 test@bodgeitstore.com’ OR ‘1’=’1′, with no password, and press the Login button.

See screenshots:

bodgeit_login1

burp_login_test

burp_login_test_successful

We’ve successfully logged in without a valid password!

Let’s see if we can do this with the second username: user1@bodgeitstore.com

bodgeit_login2

burp_login_user1

burp_login_user1_successful

We were able to log into the application as user1, without supplying a valid password!

Let’s try username: admin@thebodgeitstore.com

Going back to the login page, let’s enter the username as admin@thebodgeitstore.com without supplying a password.

bodgeit_login3

burp_login_admin

burp_login_admin_successful

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:

bodgeit_scoring_6

All of the login challenges are now complete (green)!

hacking, owasp, web application security

The BodgeIT Store Series #4, Find Diagnostic Data – #bodgeit #infosec #pentest #appsec #webapp

thefluffy007

Happy hacking!

Today’s blog post is #4 in the BodgeIt Store series.

If you want to view post #3 click HERE.

In today’s post we’re going to find diagnostic data.

So exactly what is diagnostic data?

In this case, we’re looking for a webpage inside the store that will reveal debugging data.

What exactly is debugging data?

Debugging data is used by developers who want to make sure their application is working correctly.

The problem is that the developers do not turn off the debugging feature before moving their application to production (live).

Let’s get started.

So how are we going to find the debug data? We’re going to add the following in the URL address bar: ?debug=true

Let’s start with the home page:

debug_true_1

We added the debug command, and it the page rendered the same. No debugging code on this page.

Let’s try the about us page.

Adding the debug command, the page rendered the same. No debugging code on this page.

debug_true_2

 

Let’s try the contact us page.

Adding the debug command, the page rendered the same. No debugging code on this page.

debug_true_3

Let’s try the login page.

Adding the debug command… the page rendered:

debug_true_4_yess

If you view the top of the page, you will see the new line – DEBUG: Clear.

This is an example of debugged code!

We were able to find diagnostic code in the application.

Let’s try the Your Basket page, and see what we get:

debug_true_5_yes

We found another page that has diagnostic data! In this case the debugged line says – DEBUG basketid = 5.

Let’s try search page, and see what we get:

debug_true_6

No diagnostic data here.

Let’s see what the scoreboard says:

bodgeit_scoring_5

We have successfully completed the find diagnostic data challenge (it’s green)!

hacking, owasp, web application security

The BodgeIT Store Series #3, Get the Store to Owe You Money – #bodgeit #infosec #pentest #appsec #webapp

thefluffy007

Happy hacking!

Today’s post is #3 in a series of solving the BodgeIt Store.

If you want to check post #2, click HERE.

In today’s challenge we will make the store owe us money.

Before continuing on, you will need an interception proxy.

Two of the most popular interception proxies are ZAP and Burp.

I am going to use the free version of Burp (Community Edition) which can be downloaded HERE.

After downloading and installing Burp we need to set our proxy to have Burp intercept the traffic.

Note: I am using Chrome, but the steps are VERY similar between browsers (IE, Chrome, and Firefox)

When opening Burp, and clicking on the Proxy –> Options tab we see that the Proxy Listener is listening on 127.0.0.1, port 8080.

burp_settings

Going to your browser, go to Options.

In Chrome, click the three dots, and select Settings

You should see the following screen:

chrome_settings

In the search settings type in “proxy” which will show the following:

chrome_proxy_settings

Clicking on the last option – Open proxy setting we see:

internet_properties_1

Clicking on the Connections tab, we see:

internet_properties_2

Clicking the LAN settings button, make the settings look like the following screenshot and press “OK”.

internet_LAN_properties

To summarize: We’re setting the proxy in Chrome (or IE, Firefox, depending on the browser) to send traffic through our Burp proxy which is listening on 127.0.0.1:8080.

Going back to Burp, make sure that the intercept is on –  see screenshot:burp_intercept

Refreshing the BodgeIt page, we see:

burp_bodgeit

Yay! our traffic is being trapped properly through Burp.

Click Forward until the Raw tab is blank, and turn the intercept off.  Click the intercept is on box once and it will turn off the interception.

OK… now let’s earn some $$$!!!

Navigating to the home page, click on any of the items on the left side. I am going to click on Doodah’s (first item), and I see the following:

Doodah_1

I am going to click on the most expensive item which in this case is Doo dah day, and I see:

Doodah_2

OK, let’s turn on the interception back on. Click the intercept is off button once to turn the interception back on.

After the interception is on, click on the basket button. I see:

burp_price

Changing the quantity to -10 (which is a negative value, and should not be permitted as you can’t purchase a NEGATIVE item) we see:

burp_updated_price

Going back to BodgeIt…

We have successfully made the store owe us money!!!

burp_updated_price_final

Going back to the scoreboard…

bodgeit_scoring_4

we see this challenge is now complete (green)!

hacking, owasp, web application security

The BodgeIT Store Series #2, Find Hidden Content as a Non-Admin User – #bodgeit #infosec #pentest #appsec #webapp

thefluffy007

Happy Hacking!

Today’s post is #2 in a series of solving the BodgeIt Store vulnerability.

If you want to read the initial post, click HERE.

As the title says, we’re going to solve the vulnerability of finding hidden content as a non-admin user.

Let’s begin.

Going back to the Scoring Page (About Us –> Scoring Page Link) we see the following. Pay attention to our username, right now we’re logged in as a guest user.

bodgeit_scoring_2

Going to the home page we see the following:

bodgeit_home_1

What would happen if we view the HTML source of the page? Let’s try it.

Right clicking the page, and select View Page Source we see:

bodgeit_home_page_source_1

Hmm… we see a commented code on line 41 (green line) that shows a link to an admin page. What will happen if we navigated to this page?

Navigating to this page we see the following:
bodgeit_admin_1

We found a hidden page! This page lists the different user, and their role. Along with their BasketId, ProductId, and Quantity.

Let’s bookmark this page because I am sure we will need this page later for the other vulnerabilities.

Going back to the scoring page we see:
bodgeit_scoring_3

The hidden content as a non admin user is now complete (green)!

 

hacking, owasp, web application security

The BodgeIT Store Series #1, Level 1 XSS – #bodgeit #infosec #pentest #appsec #webapp #XSS

thefluffy007

First post of 2018!

This post will be a first in a series to solve the BodgeIt Store.

I am running the BodgeIt store from an ISO (disk image) on a virtual machine (I am using VM Workstation Player 12 which is free). I have a previous post that describes how to install ISO’s in virtual machines (VMs). Link here.

Now on to the hacking!

After installing the ISO, and powering on the VM, you will be presented with the login page:

owaspbwa_login

Navigating to the IP you will see OWASP BWA (Broken Web Application) homepage:

owaspbwa_homepage

Clicking on the BodgeIt link we’re presented with this homepage:

owaspbwa_bodgeit_homepage

Going to the “About Us” we see there’s a scoring page.

Clicking on the scoring page, we see:

bodgeit_scoring_1

By the end of the series, these challenges will be green (completed).

Let’s get started!

I’m going to start with “Level 1: Display a popup using: alert(“XSS”)”

Note: I am using Google Chrome which has XSS auditor pre-installed in the application.

If you’re using Chrome you will need to temporarily disable this for the XSS vulnerability.  Make sure to close ALL instances of Chrome before entering the below command.

To disable xss auditor, open a command prompt (run –> cmd.exe), and enter (or copy) the following: “C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” –disable-xss-auditor

Once you press Enter, a new instance of Chrome will open.

OK, now a new instance of Chrome has opened, and we’ve navigated to the BodgeIt store.

Going to the Search link we see the following:

owaspbwa_bodgeit_level1_XSS

Entering the following line in the search input: alert(“XSS”)

owaspbwa_bodgeit_level1_XSS_search_1

And pressing the “Search” button we see:

owaspbwa_bodgeit_level1_XSS_search_2

We have successfully simulated a XSS attack!

Navigating back to the scoring page (About Us –> Scoring Page) we see:

bodgeit_scoring_2

Level 1 is complete (green)!!!