Month: April 2017

hacking, owasp, web application security

OWASP Hackademic Challenge 8

thefluffy007

Another day, another challenge.

Today’s challenge is #8 from the OWASP Hackademic Challenge.

Below is the scenario:

You have managed, after several tries, to install a backdoor shell (Locus7Shell) to trytohack.gr

The problem is that, in order to execute the majority of the commands (on the machine running the backdoor) you must have super-user rights (root).

Your aim is to obtain root rights.

Clicking on the link we see the following:

challenge8intro

Doing a right click and “view page source” the following screen appears:

challenge8pagesource

Looking at the input box, it seems that we can use bash commands to query what’s on the file system.

Typing in “ls” (list) we see the following:

challenge8ls

the b64.txt file looks interesting… let’s open this file to see what’s inside…

challenge8base64encoding

Looking at the file there’s encoding. Taking a wild guess the encoding is base 64 (the file gave it away).

Going to Google and typing “base 64 decoder” we get the following link.

Putting the encoding from the base64.txt file into the decoder we get the following:

challenge8base64decoder

We found the username and password, yay!!!

Going back to the challenge and entering the command su (switch user) we’re prompted with the username and password.

Entering what we found in the last screen we get the following:

challenge8congrats

We’re now running the application as root (we can see that in the red text, and a congratulations at the bottom)

Lessons learned:

Once again we looked at the page source, and really didn’t find a lot of information. We did notice that we could enter bash commands and the application would interpret it.

Doing a “ls” we noticed a file on the file system. Going to said file we noticed that it was encoded. Doing a quick Google search we were able to decode the encoding and find the username and password.

A fix for this application would be to not include sensitive files on the file system for users to access. The encoding was trying to do security through obscurity – which doesn’t work. Another fix would be to not allow the user to elevate their privileges (going from a normal user to a admin root user).

 

hacking, owasp, web application security

OWASP Hackademic Challenge 7

thefluffy007

Another day, another challenge.

This post we will solve challenge 7 of the OWASP Hackademic Challenge.

Below is the scenario:

A good friend of mine studies at Acme University, in the Computer Science and Telecomms Department. Unfortunately, her grades are not that good. You are now thinking “This is big news!”… Hmmm, maybe not. What is big news, however, is this: The network administrator asked for 3,000 euros to change her marks into A’s. This is obviously a case of administrative authority abuse. Hence… a good chance for D-phase and public exposure…
I need to get into the site as admin and upload an index.htm file in the web-root directory, that will present all required evidence for the University’s latest “re-marking” practices!
I only need you to find the admin password for me…

Good Luck!

Clicking on the link we see the following:

challenge7intro

Right clicking on the page we see the following:

challenge7pagesource

We see that there is a folder named index_files. Let’s go this folder and see what’s there…

challenge7indexfiles

Well look what we have here… there’s a lastlogin.txt, clicking on that file we get the following:

challenge7lastlogin

We see that Irene is a valid user. Let’s go back to the beginning and add Irene to the text box (with TamperData on) and see what we get.

challenge7irene

challenge7tamperdata

Let’s press “OK”, and continue.

challenge7ireneclass

Reloading the page we now see the following in TamperData:

challenge7ireneuser

Well what do we have here? Inside the cookie we have the user of Irene and a userlevel of “user”. Lets try to change the userlevel to admin and see if this will solve our challenge.

challenge7ireneadmin

After pressing out we get the following screen:

challenge7congrats

Lessons learned:

Page source provided gems in this challenge. When doing the page source we noticed that there was a folder “index_files”. When accessing this folder we see that there was information that was disclosed incorrectly that showed the last login of the application. This is bad because another user (in this case us) can impersonate a valid user.

Once we checked the grade for our user of “Irene” and looked at the tamper data results we noticed there was a cookie header that showed that our user had a privilege level of user. We noticed that this value can be changed. After change the privilege from user to admin we completed the challenge successfully.

When creating an application make sure that information is not being disclosed improperly. Make sure that there are no open folders that can be accessed on the website.

hacking, owasp, web application security

OWASP Hackademic Challenge 5

thefluffy007

Another day, another challenge…

What’s the challenge today? Challenge 5 of 10 from OWASP Hackademic.

Scenario below:

You need to get access to the contents of this SITE. In order to achieve this, however, you must buy the “p0wnBrowser” web browser. Since it is too expensive, you will have to “fool” the system in some way, so that it let you read the site’s contents.

Walk through below:

Going to the website we get the following:

challenge5

Viewing page source we see the following:

challenge5pagesource

So… the page source is not helping us as there are no gems.

Let’s look at Tamper Data.
Reloading the page and press “Tamper” we get the following:

challenge5tamperdata

We don’t have any POST data to change, but we do have request headers that we can change. One field looks interesting User-Agent.

The user-agent describes the type of browser that you are using. More can be learned about user-agent HERE.

If we change the user-agent to p0wnBrowser (since we are trying to trick the user to view the contents). Changing the user-agent we get the following:

challenge5p0wnbrowser

challenge5congrats

Lesson learned:

In this case we did not have POST data (response) to change, but we did have GET data (request) to change. Looking at the different headers the user-agent jumps out as one to change. Once again, if you’re stuck, Google is the way to go!

hacking, owasp, web application security

OWASP Hackademic Challenge – Challenge 4

thefluffy007

Another day, another challenge. What’s the topic for today? We’re still in Cross-Site Scripting (XSS) land…

Scenario below –

A hacker informed us that this site suffers from an XSS-like type of vulnerability. Unfortunately, he lost the notes he had written regarding how exactly did he exploit the aforementioned vulnerability.
Your objective is to make an alert box appear, bearing the message “XSS!“. It should be noted, however, that this site has some protection against such attacks.

SOLUTION

Enter the site we have the following page

challengefourbeginning

Trying to use the same tactic from the third challenge (alert(“XSS!”);) we get the following

challengefourwrong

challengefourwrong2

We see this doesn’t work. Hmm – seems the developer has added some validation to the page.

Let’s see if we can do output encoding with XSS.  Our goal is still trying to display the alert box of XSS!

Using TamperData from FireFox we see that our words are being encoded.

tamperdatachallenge4

 

Going to Google and look for “XSS Filter Evasion Cheat Sheet” we come to the following page HERE

Scrolling down we see the following:

Chapter4FromCharCode

Let’s try to use the fromCharCode and see if that works.

Changing the XSS to the ASCII equivalent –  we get the following:

alert(String.fromCharCode(88,83,83,33))

Putting this into the text box we get inside ‘Tamper Data”:

chapter4puttinginanswer

Pressing “XSS Me!” we get the following:

chapter4tamperdata

We’re not going to tamper this data, and press OK.

The screen now returns:

challenge4xss

challenge4congrats

Lessons learned:

The application encoded certain characters “>”, “<“, “(“, “)” to try to mitigate against cross-site scripting attacks. Even with doing this we still found a way to evade the encoding by using the JavaScript function – fromCharCode from the String class. When in doubt, use Google!

hacking, owasp, web application security

OWASP Hackademic Challenge 6

thefluffy007

Another day, another challenge…

Today’s challenge will be Challenge 6 of 10 from the OWASP Hackademic Challenge.

Below is the scenario:

In this assignment you must prove your… knightly skills! Real knights have not disappeared.

They still exist, keeping their secrets well hidden.
Your mission is to infiltrate their SITE. There is a small problem, however… We don’t know the password!
Perhaps you could find it?
Let’s see!
g00d luck dudes!

Walkthrough:

Clicking the link we’re presenting with the following:

challenge6intro

Looking at the page source we see the following:

challenge6pagesource

The scripting tag tells us that the code is JavaScript. Looking inside of the tag we see the document.write function – meaning that the data is being written to the page. The next set of characters are encoding. We need to decode it to get the message.

After a quick search on Google we find a decoder here.

Putting the encoded characters in the decoder we get the following:

encoder1

Scrolling down we see the following:

encoder2

Hmm… there’s a password that is commented out inside the mystart function.

We also have another function GetPassInfo() that checks for the value of the form to see if it’s easy. If so – then the result is easy, otherwise it’s the wrong code.

Let’s see if we can find where these functions are being used…

Scrolling down some more we have encountered were the functions are used:

encoder3

We see that when clicking on the button the button invokes the mystart and checkinfo functions.

Let’s try putting in the first commented out password of: 01234567890123456, we get the following:

encoder4

encoder5

So that was not the correct password. Let’s try entering: easyyyyyyy!

encoder6

As you can see that was the correct password.

Lesson learned:

  1. Whenever in doubt: VIEW THE PAGE SOURCE. The page source gives the tester GEMS that can be used or lets you know what direction to go into
  2. You can find out a lot about the language being used by the HTML tags being used. The developers tried to do security through obscurity – meaning doing security through hiding. This was done by using encoding and JavaScript functions. We were able to deflect this attempt by decoding the encoding.
  3. Look through the code. I know this can be difficult for testers that do not have a lot of coding experience. This is where Google comes in. No one knows everything, and you need to know when to ask or seek help. From the scenario we know that we need to find the code to unlock the challenge. Looking through the code we see two possible codes. The first one did not work as the code was commented out. The second code worked as you can see from above.
hacking, owasp, web application security

OWASP Hackademic Challenges Project – Challenge 3

thefluffy007

Another day, another challenge… What’s the topic today? Cross-Site Scripting (XSS)!

Scenario below:

XSS permits a malevolent user to inject his own code in vulnerable web pages. According to the OWASP 2010 Top 10 Application Security Risks, XSS attacks rank 2nd in the “most dangerous” list.

Your objective is to make an alert box appear HERE bearing the message: “XSS!“.

Solution:

Entering the challenge we see the following –

xsschallenge3

Looking at the page source we noticed that there is a POST method

xsschallenge3pagesource

A POST method is used to send data to the server either to a database or to another file or API (Application Programming Interface).

Going to Google – I found a link from OWASP that describes the common ways to test for Cross-Site Scripting (XSS).

Trying one of the items in the web page – alert(“XSS!”); – I get the following:

challengethreebeginning

challengethreeend

We were successfully able to use XSS scripting on the webpage.
Lessons learned:

When having input fields – as the web developer we need to make sure there is input validation. The reason for this is that we can disallow invalid characters (in this case the script tags) so our website would not be susceptible to XSS.