capture the flag, hacking, web application security

InfoSec Institute CTF Challenge 3

Another day, another challenge…

Today’s challenge will be #3 from the InfoSec Institute.

Going to the following link we’re presented with the following:


Looking at the screen we’re presented with a qr code.

Doing a right click, view source we see the following:


Doing a quick Google search of “QR code decoder” we go to the following site.

Entering the proper information and uploading our file we see the following:


Doing a Google search of our output the code is actually Morse code!

Another Google search to decode the code gives us the following site.

Putting our code inside of the decoder we get the following:


We found the flag!!!

Lesson learned:

Right click, view page source saves the day again. By doing this we found that there is a qrcode being displayed on the page. Doing a quick Google search we found a QR code decoder that gave us morse code. Another Google search yielded the flag.

When in doubt view page source and Google searches!

capture the flag, hacking, web application security

InfoSec Institute CTF Challenge #4

Another day, another challenge…

Today’s challenge is #4 from the InfoSec Institute CTF challenge.

Going to the following link we see the following:


Doing a right click view page source we see the following:


Looking at the page we see the following hint – “Hypertext Transmission Protocol”

Pressing F12 to view the developer tools and going to the “Network” tab we see the following:


Inside the set-cookie we see “fusrodah=vasbfrp_syntvf_jrybirpbbxvrf”. This is interesting…

Doing a quick Google search and putting in the second half of our value we get the following link for ROT-13.

ROT-13 is a rotation 13 cipher. This cipher rotates each character by 13 characters.

Using the following site, and putting in our value we get:


We retrieved the flag.

Lessons learned:

Use the hints provided. We our trust right click, view page source, but that didn’t help us. Going back to the page we noticed that the hint was HTTP. Using the development tools inside Chrome and going to the network tab we saw the files retrieved when accessing the site.

Clicking on the page, and viewing the headers we noticed that the cookie was being set. Using this information inside Google we were able to decode the message.

capture the flag, hacking, web application security

InfoSec Institute Capture The Flag #2

Another day, another challenge.

Today’s challenge will be on the second ctf challenge from the InfoSec Institute.

Below is the screen listed HERE when accessing the link:


Doing a right click view page source and scrolling down we see the following:


We see a img src that points to a leveltwo.jpeg. Clicking the file we get the following:


Going to the space bar and add the “view-source:” to the beginning of the address bar we get the following:


We got the flag!

Lesson learned:

Once again do the right click page source. In the beginning it didn’t reveal too much except that there was an image. Clicking on said image we’re brought to a page with a non-rendered image. Viewing the source of that image we see the flag. This is security through obscurity which never works.

hacking, owasp, web application security

OWASP Hackademic Challenge 10

Another day, another challenge…

Today’s challenge will conclude the Hackademic Challenge.

Below is the scenario:

Would you like to become an active hacker ?
How about becoming a member of the world’s largest hacker group:
The n1nJ4.n4x0rZ.CreW!

Before you can join though, you ‘ll have to prove yourself worthy by passing the test that can be found at:

If you succeed in completing the challenge, you will get a serial number, which you will use for obtaining the password that will enable you to join the group.

Your objective is to bypass the authentication mechanism, find the serial number and be supplied with your own username and password from the admin team of the site.

Clicking the link we see the following screen:


Doing a right click, page source we see the following:


Looking at the line above the password line we noticed that there is a hidden field called “LetMeIn” which is set to false. What if we set this to true?

Going back to the our original screen, and clicking on Tools –> Web Developer Extension –> Forms –> Display Form Fields we see the following screen:


Changing the field from “False” to “True” and pressing the “Login” button we see the following:


Hmm… there’s an alert box that has encoding in it. Could this encoding contain the serial number?

Copying the encoding and going to Google we search for “Decoder online”. We found a website HERE

Changing the encoding type from Base64 to URL encoding and pressing “Decode” we see the following:


We have the serial number!

Going back to the challenge and pressing Enter we’re presented with the following screen:


Entering our name and serial number, and pressing the send button we see the following screen:


Lesson learned:

Our trick of right clicking and viewing the page source helped us. We noticed that there is a hidden field titled, “LetMeIn”. Developers believe that just because a field is hidden a penetration tester could not exploit these fields. This is further from the truth.

After we have tampered with the hidden field we are next encountered with encoding. Doing a quick Google search we found an encoder/decoder online that we can use to decode the encoding.

Once that decoding is done we entered our name and serial number on the next screen and we have completed the challenge.

hacking, owasp, web application security

OWASP Hackademic Challenge 8

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

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:


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


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:


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


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:


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:


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

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:


Right clicking on the page we see the following:


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


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


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.



Let’s press “OK”, and continue.


Reloading the page we now see the following in TamperData:


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.


After pressing out we get the following screen:


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 – Challenge 4

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.


Enter the site we have the following page


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



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.



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

Scrolling down we see the following:


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

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


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


Pressing “XSS Me!” we get the following:


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

The screen now returns:



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!