Category: Web App Security

  • Home
  • Web App Security
01 Feb 2019
Events, The Art Of Hacking, Training, Web App Security Blogger 0 comment

By Hackers, for Hackers

On 16th-DEC-2018, ENCIPHERS conducted a full day training on “Web Application Hacking – Advance Level” as a part of “The Art Of Hacking” training series. The seats in the training were kept limited, to ensure a good trainer to student ratio.

To enable the students understand the advance web hacking concept in the training, all the attendees and trainers were connected via a private slack group so that they can learn from the content shared, ask queries and sharpen the basics . In this class room training attendees were given access to our custom virtual private server, Bughunters VPS and were provided with multiple guides and Hackers mind map.

The full day training was filled with lots of advance hacking concepts and demonstrations. Post training, we received huge applause from the attendees on various social media platforms. Have a look at some of those tweets:

Following the same approach, but after several enhancements to the course content, Bughunters VPS and training duration. We are launching “Web Application Hacking – Advance Level 2.0”


24 Jan 2019
Events, The Art Of Hacking, Training, Web App Security Blogger 1 Comment

WEB APPLICATION HACKING – ADVANCE LEVEL 2.0

We Conducted the Web Application Hacking – Advance level training on 16th DEC 2018. Right after completing the training, we received amazing positive feedback: 

20190123_172738_0001

You can also read a post by one of the student, who won several bounties just hours after the training. MY EXPERIENCE OF THE ART OF HACKING TRAINING, AND THE STORY OF FIRST CRITICAL FINDING

We also received several inquiries regarding the next date of the training, from many who were not able to register last time. So keeping these things in mind, we worked more on improving several things:

  • Two day training agenda, comprising of several real world vulnerabilities and exploits instead of one day as it was in the last training. 
  • An improved version of Bughunters VPS, more tools, more secure, more powerful
  • A real world application like, lab environment, specifically created for this training.

So, now we present to you WEB APPLICATION HACKING – ADVANCE LEVEL 2.0, a two day classroom based training, focused on advance level exploitation of web application vulnerabilities.

Details about the training: 

Training name : Web Application Hacking – Advance level 2.0

Training Agenda : Agenda of Web Application Hacking-Advance level 2.0

Training date: 30th – 31st March 2019

Training Timing: 9:00 AM – 5 PM

Training Venue: New Delhi, India (Exact venue to be shared with registered students)

Training Fee: 

  • Classroom based training (Without VPS access): 15,000 INR + 18% GST [Final cost: 17,700 INR]
  • Classroom based training + One month access to Bughunters VPS: 20,000 INR + 18% GST [Final cost: 23,600 INR]

Only for students outside New Delhi – NCR, India region: [Only 10 seats available]

  • Online access to the training (virtual conferencing): 17,000 INR + 18% GST [Final cost: 20,060 INR] 
  • Online access to the training + One month access to Bughunters VPS: 22,000 INR + 18% GST [Final cost: 25,960 INR]

Unique benefits of this training:

2 days classroom based training on Advance level attacks on real world application specifically designed for training students.

Confirm enrollment to free Basic level training (online).

100% discount coupon for the online course: Web Application Penetration Testing Using Burp Suite.

One month access to completely customized VPS (Virtual Private Server). Attendees can use this server to do bug bounties or perform penetration testing. (Optional)

Detailed guides for all the tools on Bughunters VPS.

Hackers mind map: to help you understand what all things should be tested and how to proceed at each level.

Super cool training completion certificate by ENCIPHERS.

Access to private slack channel: ask doubts and questions. 

How to enroll for this training:

  1. Complete the payment:
    1. UPI: enciphers@icici
    2. IMPS/NEFT:
      1. Bank Name: ICICI Bank Ltd
      2. Acc No: 628205025182
      3. Account Name: ENCIPHERS
      4. IFSC: ICIC0006282
  2. Fill the google form here: Google Form
    1. Make sure to chose training mode you selected.
    2. Make sure to submit the transaction details (Transaction number etc)

Capture

For any inquiry contact us at: artofhacking[at]enciphers[dot]com

Join the Slack group of The Art Of Hacking:  Join us on Slack: Slack Invite Link

For corporate training and other inquiries: hello[at]enciphers[dot]com

02 Jan 2019
The Art Of Hacking, Training, Web App Security Blogger 1 Comment

My experience of The Art Of Hacking training, and the story of first critical finding

Hey folk,

I am Jayesh patel. Little bit of $whoami:  I am a bug hunter who is highly motivated towards the field of Web, Mobile application Security and I actively participate on various Bug Bounty Programs/Platforms like Bugcrowd, Hackerone, BugBounty.jp, openbugbounty.org.

 

Why am I writing this blog post ?

ENCIPHERS team asked me about my experience of basic and advanced level training in The Art Of Hacking series, and asked if I would be interested to share my experience through a post. 

So I said yes!!! and here i am writing blog about some of my findings, which I discovered after taking advance level training from ENCIPHERS.

Before the advance level training, I was only able to find the vulnerabilities which were of low-severity but after the training, I found my first critical vulnerability within hours. 

So the journey started on 29 September 2018, when ENCIPHERS team conducted a free training  “The Art Of Hacking: WEB APPLICATION HACKING – BASIC LEVEL“.  The training was awesome, I  learned lot of things to improvise in bug bounty hunting.  ENCIPHERS team also helped me in finding a vulnerability on a web application which I was trying to hack (under a responsible disclosure program).

 

After The Art Of Hacking – Basic Level training, ENCIPHERS team announced about The The Art Of Hacking: WEB APPLICATION HACKING – ADVANCE LEVEL and I Registered for the training. The advance level training was conducted on 16 December 2018, at Vivanta By Taj, New Delhi. This time, it was about advance and critical vulnerabilities like RCE, SQLI, SSRF, XXE  etc.

 

On the day of training, it started with setting up our access on a virtual private server,  Bughunter’s VPS and we were provided with multiple guides (PDFs). One of the other interesting thing was a Hacker Mind-Map designed by ENCIPHERS team.  The Hacker Mind-Map is a detailed flow of steps which one can follow while doing bugbounties or penetration testing. The Bughunter’s VPS was already setup with multiple bug bounty related tools, and a Tools and Usage guide  was also provided. This helped me a lot in finding bugs, just by recon only. The Mind-Map explained, how someone should start with testing a target, and what are the possible tests to do at each stage. 

In the training, we learned about many advance level vulnerabilities, and exploited them in a test application (by taking remote shells and dumping databases). 

Story of my first critical bug:

After the training, while I was returning back to my hometown, I had a few hours on the train station. So I thought of doing some bug hunting using the concepts from training.

So, I choose a target and first thing I learned in training was to understand the scope properly. This was a target with sub-domains included, so I started using my Bughunter’s VPS and discovered all the sub domains using Aqua-tone tool, which was already setup on the VPS. After that enumeration I started port scanning on all the sub-domains using Masscan tool on Bug Hunter VPS.

After scanning, I found that 5002 port was open on target site so I just opened that site www.xyz.com:5002 on chrome.

Yeah…….!!! 🙂 😉

port was open and control panel login page was visible now my second task was to bypass the access control page so I just tried the default credential admin:admin.

After entering username and password I got access of control panel and yeah!!! that was my first critical bug and all thanks to ENCIPHERS team for this amazing training.

 

 

If you are into bug bounties or penetration testing and want to enhance your security skills, I would highly recommend a training by ENCIPHERS.

Once I reported the vulnerability to the target company’s email address, within 24 hours I got a response:

unnamed (4)unnamed (5)

At the end of this blog, I just want to post a picture of me from the training 🙂 Looking forward to more training by ENCIPHERS.

 

DSCN5603

13 Sep 2018
The Art Of Hacking, Web App Security Blogger 2 Comments

The Art Of Hacking (Delhi Edition) : Web Application Hacking – Basic Level

We are excited to publicly announce the first session of “The Art Of Hacking”. Details are below:

Training Details:

Training Name: Web Application Hacking – Basic Level

Training Date | Time: 29th.September.2018 | 9:00 AM – 4:00 PM

Venue:  TO THE NEW, Tower B, 4th Floor, Logix Techno Park, Noida Express Way, Sector 127, Noida, Uttar Pradesh 201304.

Big thanks to “TO THE NEW” for helping us by providing the venue.

 

What’s so awesome in this training?

  • Free for all to attend.
  • Fully hands-on training, focusing on starting and succeeding in bug-bounties too.
  • It will be a live training with lab practice.
  • Attendees of Basic level will get discount for advance level training. 
  • Networking opportunity.

 

Prerequisites:

  • Working laptop with Kali Linux virtual machine.
  • Willingness to learn
  • (Optional) If you can get a personal wifi/internet connection, it would be better.

 

How to apply for this training?

  1. Fill the google form below (End of this page).
  2. As the seats are limited, we will chose majorly on who filled first criteria. So fill as soon as you can.
  3.  Wait for an acceptance email from our side with more details. Make sure to bring your ID and the invitation code we send in the acceptance email.

Timeline:

  • Enrolment start: 13th.September.2018
  • Enrolment ends: 19th.September.2018
  • Acceptance to be sent to attendees: 26th.September.2018

 

Agenda of the Training:

Module 1 – Basics of everything:

  • Basics of web applications
  • Vulnerability scanning
  • DNS and Domain level stuff
  • Intro to burp suite , Setting up & use cases

Module 2 – Recon:

  • What is recon? Best tools for recon.
  • Low severity issues and how to find them during recon.
  • Chaining low severity bugs to get higher impact.
  • Reporting low severity bugs the correct way.

Module 3 – Finding the “easy money bugs”:

  • Cross Site Scripting:
    • How to find? Where to look?
    • Using Burp suite for finding XSS
    • Interesting case studies of XSS
  • Cross site request forgery
  • Access control & Improper session management issues
  • Insecure subdomains & hidden insecure files

Module 4 – Finding high paying bugs:

  • Insecure Direct Object Reference
    • What are they?
    • Where do they exist?
    • Using burp suite to find IDORs
    • Case studies on interesting IDOR bugs
  • Authentication & Session related vulnerabilities:
    • MFA bypass
    • Password reset issues
    • Session management issues

Module 5 – How not to suck at bug bounties:

  • Reporting is the key to good money.
  • How to avoid duplicate issues?
  • Amazing resources from around the internet.
  • Where can you hunt other than Bugcrowd and Hackerone?

 

Want to know more about the whole series of trainings? Read here

Want to join the group? Have questions to ask? Join us on Slack: Slack Invite Link

Training Content/Hand-Outs:

  1. Presentation Used in the basic level training: (Presentation) The Art Of Hacking – Web App Basic Level
  2. Books/Resources:
    1. OWASP testing guide: OTGv4
    2. CORS POC sample: CORS_POC
    3. Web Application penetration Testing Checklist: Web Application Penetration Testing Checklist
    4. More resources to start in web app security:  Resources
  3. Virtual Machine (OVA file): OVA Link
  4. Virtual Machine Details VM Details
  5. Vulnerable App – WackoPicko Details
  6. Vulnerable App – OWASP Juice Shop: https://github.com/bkimminich/juice-shop

 

Hope you loved the training. Please give your feedback here.

02 Sep 2018
Web App Security Blogger 0 comment

Finding and exploiting Blind XSS

Hey guys. Welcome to this new post from ENCIPHERS. If you are here, we are already presuming that you know what XSS is and the major types of XSS(i.e Reflected and Stored). Plus there is DOM-based XSS too which is not that common as those other two. We have discussed in great depth about the different types of XSS and how to exploit them in different scenarios(like file uploading or markdown feature). You can always take a look at our blog section to go through them. But today, we have something special for you. If you are a beginner and you haven’t heard about Blind XSS, or you know about Blind XSS but do not understand how to exploit them, then this post will definitely help you as we will explain everything you need to know about Blind XSS.

Why “BLIND” XSS?

Blind XSS is a variant of the so-called “Stored XSS” but you cannot know by ordinary means that if your payload got executed like you can in case of Stored or Reflected XSS where the alert box popups immediately on the screen. Consider a simple scenario. You are putting XSS payloads in an input field, but nothing happens on screen. Now, what happens is that the admin of the application is getting the same input directly and your payload gets executed there(i.e on his account). But you have no way to know where does the payload get executed or even if it gets executed. That is why it is called Blind XSS because you can’t see that little alert box of yours because it may be getting executed somewhere else or on a completely different domain altogether.

Where to look for Blind XSS?

You should always put Blind XSS payloads in places, where you are certain that an admin or another user of higher privileges will definitely go through that. As for example, the Feedback page. Thinking logically, a normal user of the application won’t review your feedback but it will most probably be reviewed by an admin or a team member. So that’s a nice place for a little surprise. Another place where you could use Blind XSS payloads,

  1. Review forms
  2. Contact Us pages
  3. Passwords(You never know if the other side doesn’t properly handle input and if your password is in View mode)
  4. Address fields of e-commerce sites
  5. First or Last Name field while doing Credit Card Payments
  6. Set User-Agent to a Blind XSS payload. You can do that easily from a proxy such as Burpsuite.
    And there are many more cases, but we would encourage you to read some reports to get a perfect knowledge, where other hackers are already applying these techniques and how you can use them in your program.

How to find Blind XSS and what are the appropriate tools for this purpose?

Finding Blind XSS isn’t that hard as it sounds and sometimes putting your payloads everywhere can work like a charm. But let’s see how to approach this methodically.
There are awesome tools available for this purpose, but the most popular and the one which we regularly use in penetration tests and bug bounties is XssHunter. It’s specifically written for finding Blind XSS’s and it’s really easy to make it work.

    1. First of all, you need to signup for XSSHunter from this page.
    2. Now if you go to the Payloads section here you will see there are different payloads with the proper description on where you could use them.
    3. Next step is to just simply copy and paste these payloads and start inserting them in different fields as we already told you before(contact us, feedback, address etc).
    4. Once done, you can just sit down and check your XSS Fires tab at a later time. If the payload gets executed anywhere it will give the full details of the bug and will also mail you a report which is super helpful.

In case, it’s not working, you can also tweak with those payloads. Url encoding and double encoding are also some of the other options which can work like a charm.

There are other tools available also, like ezXSS or you can even write your own tool with your domain(but only when you become an advanced tester). For more exposure to Blind XSS, just use this Google Dork site:hackerone.com blind xss and you will get the full list of publically disclosed reports on Hackerone. Go through each of them to understand how you can make it work efficiently. Until then, you can start inserting these Blind XSS payloads from XSShunter and play around them in your future pentests or bug bounty programs and see for yourself how it works out for you.

All the best and Happy hacking.!!

22 Jun 2018
Web App Security Blogger 0 comment

Doing RECON the correct way

Hey guys, today we will discuss Information gathering aka Recon which is the foundation of every bug bounties or penetration tests which you will ever do. Many security researchers have found many CRITICAL and HIGH priority bugs just by doing proper information gathering which is the initial phase of a penetration test.

If I get 6 hours to chop a wood, I would spend the first 4 hours sharpening my ax.

This is exactly the case in this phase. Most of the researchers just start looking for vulnerabilities like XSS, CSRF, IDOR as soon as they get the target but with proper information gathering at the start people can know what the target is and the different technologies on which it is built and several other things. For now, we will keep this post general and simple and with time we will make sure to update it or write the 2nd part of it. So let’s get started on what you should do in the initial phase of knowing your target.

  1. Subdomain Enumeration:

    We have already published a post on Subdomain Enumeration in which we discussed several tools and techniques by which you could do subdomain enumeration. You can find the post here. In the time we last wrote that post, we came across some other cool tools which are much faster and bring better results when you have a target like *.target.com and you need to enumerate all the subdomains.

    Subfinder

    One of these tools is Subfinder. You can get the tool from here. It is faster than Subbrute or Sublist3r. It has been written in Go language so you will need to follow the instructions to install Go and setup this tool on your machine. Also, you will need to set up private API keys for some of the services like Virustotal to get results from them also. It has been mentioned in brief on that Github page. After installing the tool, there are several options which you can use. One of our favorites is:

    ./subdinder -d target.com

    This will make sure to get subdomains from 22 passive data sources. But if you have a text file like this all.txt and you want to brute force the subdomains, then you can use the option below

    ./subfinder -d target.com -b -w all.txt

    Subfinder is one of the fastest and mostly used subdomain enumeration tools out there recently. Make sure to use it to get juicy subdomains to gain more chances of getting a bug there.

    Amass:

    Amass is the second new tool which is there and we wanted to let you know in case you haven’t used it yet. It has also been written in Go and is super fast. Installation instructions and everything else which you will need can be found here.

    After installation, you can simply run the command:

    amass -d target.com

    to get different subdomains for that target. There are many other different flags mentioned there which can help you in finding a quality number of good subdomains. Now if you are thinking, why we are talking about subdomain enumeration tool once again, and Subbrute or Sublist3r would suffice this purpose. Then we would like to add something, as of now Sublist3r has really become depreciated as a tool and you will find a great difference when you compare the results from Subfinder and Subbrute or Sublist3r. Make sure to try these 2 tools to have better chances of finding a different domain and ultimately getting a valid bug on that.

  2. Censys:

    Now, this is one tool which many researchers have been focussing on in recent years. And this is one of the coolest tools for information gathering. Censys actually scan the IP addresses and gathers information from a set of different ports. Creativity is a way while doing Censys search. A simple search like this, “target.com” internal might lead to unexpected results. There are many tutorials online available on how to get more than the normal information usually shown and you should really check that out. You can access the tool from here. Just enter any website’s name in the Search Box and you will get a whole lot of results and many times subdomains data from there. Do take a look at it while doing information gathering.

  3. Shodan:

    Shodan is more or less the same as Censys except that it scans every IP addresses and generate a lot of data. The process is also almost the same and is really popular among bug bounty hunters. You can access the tool from here. There are many books like this and online tutorial plus videos which goes into a deep study on different shodan techniques to get better results. Again creativity is the key here, so do gather some information on Shodan before gathering info on the target application. So do check this one out.

  4. Github:

    Github is the world’s largest software development platform. It is one of the best places to look for various issues and knowledge about the technology stack the company is making it’s products on.
    While doing a Github Recon for a particular target, you could look for many things like:

      • Looking for secret keys labeled as API_key and AWS_Secret
      • Some internal credentials such as username, the password for Database or admin portals.
      • You could also get some different API endpoints and look for different domain patterns.
      • Not only this, there are many environments like dev, stage, and prod and you may find some interesting details or any interesting subdomain based on this.
      • Let’s suppose the testing application is target.com, then you could just make a search as
        “target.com” “dev” or “target.com” “prod” to look for the above details.
        For searching secrets like API_key, you can just make a search as “target.com” API_key and it might give you some unexpected results in many cases.
        Similarly, if you want to refine your searches for passwords, you should make a search for “target.com” password

    .

    There are many tools available for Github Recon like gitrob, git-all-secrets etc, but the best way will be to do it manually so you don’t miss anything important.

  5. Amazon Web Services(AWS):

    AWS s3 buckets are being used by a lot of companies to host their content nowadays. But many times unsecured methods leave them misconfigured which could then be an asset to a malicious hacker. In a CRITICAL scenario, this misconfigured s3 bucket may allow an attacker to read and write files on a bucket belonging to the company. Just as for finding any ‘juicy’ information on Github, it is also possible to get a good amount of information while doing AWS recon.

    Some of the ways can be like to use a Google Dork. Let’s say the target is abc.com then a google search like
    site:s3.amazonaws.com + abc.com
    may provide you with some interesting results.
    It is also possible to get s3 buckets on Github, so in this case, you may provide a search query in Github such as:
    “abc.com” + “s3”

So this is all for this first post on Information Gathering. There are many other methods like dig command and archive.org which can be also helpful for getting various types of information. Information gathering is just what the name says. Gathering information from anywhere. Even though if you don’t find any sensitive file during Recon, knowing the technology stack, subdomains will definitely give you an upper hand in the latter half of pentesting. In the upcoming months, we will make sure to make a part 2 for Information Gathering where we will talk about some of these topics in depth or add new updated tools and methodologies to help you in your penetration testing career.

Until then, keep practicing and Happy hacking. !!

21 Jun 2018
Web App Security Blogger 0 comment

A User can change the personal details of any other user

Hi everyone. Welcome to this new post from ENCIPHERS. So recently, our team at ENCIPHERS conducted a penetration test for a certain company. The company is a very reputed one in the field of Money Investment and Real State business and it has a lot of day to day users. The client asked us for a penetration test on a limited scope of www.xyz.com only i.e the main application of the client without interfering with any other subdomains.

As it stood, the application was more or less quite secured to find vulnerabilities like XSS and CSRF. The next thing, that will come to any penetration tester at that time is to check for any broken access control related issues, and the same happened to us. So it was then that we started testing rigorously to find any critical bugs and yes we did find some of them.

Here are the different steps. Let’s see them one by one.

As we have already told you in lots of our posts earlier, you always need to make 2 accounts to test for cross-testing. So we started with that and logged into both the accounts in 2 different browsers.

Next, we started looking in the application URL and also in the Requests tab in Burpsuite, for anything where there will be something like a Identifier or a random number that could be used to differentiate between 2 different profiles.

We told you before that it was a Real estate business company. So in there, was an option to see the different profiles created by the user. These profiles contained different confidential information about the user like the Contact Information, the Ownership Type, and Legal Title. The Request looked like this:

And the Response to this particular request showed various details of the user.

Now what we simply did was to change the profile id with that of the other user account, to see if it shows Access Denied. But no, it doesn’t. Instead, it gave us the full details of that profile of the other user.
The JSON request part looked something like this:

As you can see, the profile_id was changed.

Not only Read but we also got Write Access to change the profile name of the other user’s account.
Actually, the link to edit the details of a profile, looked like this:

https://www.xyz.com/settings/investor-profiles/3342499135144669

So we just changed the id with the second one and the link became this:

https://www.xyz.com/settings/investor-profiles/3312999599807157

And to our utter surprise, the option to Edit the Info was still working and we successfully changed the profile name of the other user and saved it.

Not only this, a user can also see the various Investment details of any other user plus the Earnings of that user also. Here is how.
The Request to see the Investment details of a certain profile of a user looked something like this:

As you can see, the profile_id is in the JSON request and as a penetration tester, you won’t be missing to check what happens if you put any valid id of any other user there.
So we simply replaced the id with our other account’s id. And yes, it was ‘200 OK’ with the other account details there.

The Earnings tab was similarly vulnerable to Access Control issues where it was possible to get the whole details of any other user by giving that id.

The Request, in this case, looked like this:

As you can guess, what happens after this. We simply replaced the id and yes, that was it.
Now for certain curious readers, who must be thinking that how will someone guess the profile id of any other user because it seems to be a long random number. So for you, the sole purpose of a penetration test is to look for vulnerabilities present in any condition. The companies should always take the first step to make their site secure by taking the proper measures against access control issues instead of thinking that a hacker will not be able to guess such a long random number. If there was proper access control, then when we sent the request by replacing the id, it would have directly shown me Forbidden or Access Denied. Not only this, the profile id’s are also getting saved in the browser’s history and what if someone gets their hands on it. So proper access control measures should be applied in the first place so that even if someone finds a way or an algorithm to guess the number, it won’t help them with accessing the other user’s account.

So this was all for this post. See it is very simple and easy to find such kinds of bugs. The issue in the last post was also easy. You just have to be on the lookout for an identifier and then cross-test among them to find these issues. Hope you must have learned some new things from this post too. See you guys in the next post. So go apply these techniques now and Happy Hacking.!!!!

19 Jun 2018
Web App Security Blogger 0 comment

Knoxss vs Burpsuite(A practical Demonstration)

Hello guys. So this is going to be an interesting blog as we are going to watch a practical demonstration of two awesome tools in the penetration testing industry.

One is Burpsuite. If you are here, then we probably assume that you know what Burpsuite is and how it works. This post will give you some better insights into it. Also you can enrol yourself in a course on Udemy on ‘Web Application Penetration Testing Using Burp Suite‘, a full fledged course on being Zero to One in web application penetration testing using Burp Suite.

The other is Knoxss. If you don’t know then just know that Brute Logic develops it and if you know XSS, then we guess you must have used the Brutelogic Website at least once.

Burpsuite is a hacker’s toolbox as it contains tools for every purpose. Whereas Knoxss is only for finding XSS vulnerabilities so here we will only try to find XSS bugs in the application and compare both the results.
Now the thing is we will be comparing the Burpsuite Pro version against the Knoxss Pro version and give our conclusions so you will know more about them and how will they be useful.

Practical Demonstration

The first thing that you need to do is get Webgoat up and running.

Webgoat is an intentionally vulnerable web application and is basically used for training new security researchers. You can see the different steps involved to get it running from here.

If all is good, then upon opening the URL http://localhost:8080/WebGoat/, it will look like this:

Scanning with Burpsuite Active Scanner

Let’s start with Burpsuite first and then we will again check it with Knoxss.
One thing which you will need to do is to change your Burpsuite proxy listener to any value except 8080 because Webgoat is running on that. We have changed it to 8000 in our case to avoid problems. See the screenshot below.

Similarly, you need to change the browser’s proxy to 8000 also so that Burpsuite could act as the proxy.
See the screenshot.

If you are facing problems with this setting, watch this video on setting Burpsuite.

So all set and done, let’s start finding XSS with Burpsuite.

Stored XSS
So go to Cross Site Scripting -> Stored XSS challenge in Webgoat and write anything in the input boxes. Make sure the Intercept is on in Burpsuite. Capture the request and do an active scan on it. Remember, Active Scan is only available for Pro versions. Active scan sends multiple requests to see if a vulnerability is present, so in this case, we will look out for XSS vulnerabilities.

This is what we got by doing an active request in Burpsuite Pro for this request.

Though it was able to find some other vulnerabilities, it couldn’t find out that the input fields in this page are vulnerable to XSS. Burpsuite results can be false positives also sometimes.

Reflected XSS
Let’s see for Reflected XSS challenge now.
You can see that it worked in this case correctly.

It correctly found Reflected XSS vulnerability in that page for certain. So Burpsuite passes in this case.

Testing with Knoxss Pro Extension for Firefox

Let’s get back to Knoxss for this two cases.

As of this moment,  we are using Firefox Quantum and the Knoxss extension is not working for this latest version of Firefox. The deadline for this issue is still unsure so it will be wise to use the Firefox-ESR instead of an outdated Firefox version and install the extension there. We will make sure to update this post as soon as we get the new extension which will support Firefox Quantum.

For the extension to work, go to the page where you want to check for XSS, and then press the ‘K’ button which must be there if you installed the extension correctly. Then the extension will get ‘ON’ and you can then see if it found any XSS on the page or not.

Stored XSS
So let’s check for Stored XSS first. Go to the stored XSS challenge page and start the extension.
See the screenshot below.

If you see in the top-right corner, it says Knoxss wasn’t able to find any vulnerability in the form. The same as with Burpsuite. But we know that the page is vulnerable to stored XSS, so both of them couldn’t find it.

Reflected XSS:
Turn the extension off by clicking and once again start it after visiting this page and stay there for 10-30 seconds.

Knoxss wasn’t able to find the XSS vulnerability in this case also.

Final Conclusion:

Please don’t get us wrong. While you will see many posts on successful working of tools, this post was to show that even such popular scanners can fail.  This post tells that you can’t always rely on the findings of an automated tool. Sometimes the results can be false positives but many a time it’s possible that they won’t even catch the vulnerability. We knew about both cases that they are vulnerable but the scanners couldn’t get it. But if we had inserted a simple payload, checking for XSS it might have worked.

We would like to mention that these two have worked magnificently for many other users while live testing. This post was just for demonstration purpose. Where Burpsuite Pro requires 349$ per year license, a year license for Knoxss Pro is 107$. So, try out with the free versions and if you think you should buy the pro version go for it. As for us, we are trying both of them now and we will be updating this post again if we find something interesting to share with you all. So stay tuned for that.

Until then keep trying and if you get stuck, please comment and someone from ENCIPHERS will surely help you out.

18 Jun 2018
Web App Security Blogger 0 comment

How can Expired URL’s lead to an all new kind of vulnerability?

Hey guys. Actually, this is the 2nd part of the vulnerability which we discussed in the earlier post. You can read that post from here. Now if you read the post, you will get to know that we have discussed the IDOR which we got in the e-commerce application.

What is this 2nd part all about?

So let us explain it in an easy to understand manner. What are the normal steps when you try to change your password on Facebook?

  • You chose the option of ‘Forgot Password’.
  • A link is sent to your mail id.
  • You reset your password using that link.

Now did you ever try, again revisiting that link? Do you think that again revisiting that link will help you to reset your password?

Then the simple answer to this NO. It won’t help you to reset the password because the link gets expired after one use. The reason for that is if someone gets access to your emails anyhow, he/she can change the password if the link doesn’t get expired. That is why there is always a token in the links and if you check it, you will find that the token gets changed with each “Forgot Password” request.

But the vulnerability in our case was slightly different than that.

The way the application was working that it will send an email to the user for notifications when he subscribed anything.

The link in the mail would look something like this:
http://www.xyz.com/ticker/management/771255762/admin

Now when we unchecked all the subscriptions and again visited this link, it said that the link has expired or the URL contained an error which was the perfect way the application should work.

When we again subscribe any item, we got an email with a link something like this:

http://www.xyz.com/ticker/management/978975762/admin

As you can notice, the identifier got changed i.e the tokens we were talking about earlier.

Here lies the vulnerability. As we used the previously expired link again now, we can see the different subscriptions and that even the new ones. It was not that the link was showing us the cached page. We were able to see the latest subscription for the user and we can again uncheck some of his subscriptions and play around with it. This was quite an unusual bug for our team but it was a well-found bug.

The major and the most CRITICAL problem of this bug is if an attacker can guess an identifier for once, then the user is doomed. He can just save this identifier and whenever he tries to use this and finds the link is expired, it will mean that the user hasn’t subscribed to anything for now. But as soon as the user subscribes anything, the attacker will again be able to see the user’s subscription and has full WRITE access to it.

Final Points

So the IDOR mentioned in the previous post along with this case of the link not expiring even after another link is issued was a HIGH priority vulnerability for the e-commerce company.
If the application has been properly tested and verified, problems like this shouldn’t have existed in the start i.e. the issue of non-expiration of links for quite a number of days.

This was all for this two-part post which was quite related to each other. As we have already mentioned before, issues like this are very easy to find and just needs a keen sense of open eyes. So this was all for this time. Hope you all learned something out of this and learned to always check the link in the emails cautiously because that can open a whole new door of possibilities for vulnerability finding. Until then, Keep Learning and happy Hacking..!!!!

13 Jun 2018
Web App Security Blogger 0 comment

Bypassing Cloudflare WAF to get more vulnerabilities

Hey guys,

If you have been doing penetration testing or bug bounties for some time now, then you must have come across applications which uses Cloudflare as their Content Delivery Network(CDN). As a new bug bounty hunter or penetration tester, you must be feeling kind of frustrated when any XSS Payload you provide leads to a security page or you get blocked by Cloudflare’s Web Application Firewall in place there.

What exactly is Cloudflare and how can you detect which web application uses it?

CloudFlare is a useful tool to enhance site performance, accelerate the access speed and improve the visitors’ experience. It is a CDN, DNS, Security(Web Firewall), Optimer, Analytics etc. all in one package. In a simple way, you can say that Cloudflare makes the application loading time faster and saves it from attacks such as SQLi and XSS to save your users from being hacked. If you are unsure about how to check if a web application is using Cloudflare, you can simply use an extension such as Wappaylzer which shows the different technologies, Frameworks, CDN’s the application is using. You can download it from here if you don’t have this or any other extension like it.  Its usage is pretty simple. This is how it will look like when you browse an application which uses Cloudflare as CDN.

This is how it will look when you see the Extension for a particular app using Cloudflare. There are other ways too and we will get to that eventually. Now if you try to use your normal XSS payload, you are either going to get the Captcha Security Box every time or on doing it constantly you will be blocked from further interaction with the app on that IP. Not only this, scanning and spam messages or emails will also lead to problematic issues for as a penetration tester.

What’s actually happening behind the scenes?

When a company uses Cloudflare, what happens is that Cloudflare sits in between you and the web application original server. So any malicious payloads or files which you try to execute on the main app goes through Cloudflare and as a result it blocks you. Not only this, even if you get the IP address and try to access the app using this IP, it will show that “Direct Access is not allowed”. Below is the image of a target which uses Cloudflare. Use the below command to get the IP being used

ping target.com

This is where Cloudflare is hosting your application. Any time you insert your payload, it goes here. Now just try to directly access the app using this IP and you will get the following error:

So is there any way out of it?

Yes, of course, there is. Think of what will happen if you could just access the Origin Server directly without going through Cloudflare’s protection? Then the app will have no protection via Cloudflare’s firewall and we can now test for various vulnerabilities like XSS and SQLI.

Let’s see some of the tools and methods which can help us to access the Origin Server directly.

1.Crimeflare:

You can access the application here. This applications work is solely based to determine the Directly Accessible server for that application i.e the origin server. They have maintained a database and a zip file containing the name of all the services which use Cloudflare and who is sitting behind this Cloudflare’s service. You will be able to see a search box at the bottom of the page. Once you enter the website’s name and Crimeflare comes up with a Direct Connection IP, then you can be almost sure that it’s the Origin Server. We are using “almost” here because many times the results produced are that of the target’s subdomain instead of the main domain, so you have to further verify from the other methods we are going to talk about. On the other hand, if you didn’t get any information on the Origin Server from here move to the other methods.

A sample demonstration for Bugcrowd.com which uses Cloudflare and how you can get the Origin Server.

2.Censys:

The website itself says that it’s a tool to find and analyze every reachable server on the internet. This tool comes in very handy during the Recon process of a penetration test or Bug Bounties as we can get different types of information from here about the target. But this is also helpful in this case where we have to find the Origin Server for an application using Cloudflare.

If you just enter the target’s name in the search box, it will come up with the IP’s of that target and mostly the origin server is in those. Let’s say for example Bugcrowd here.

https://censys.io/ipv4?q=bugcrowd.com

This is what the URL looks like and it’s giving a lot of results because the application might be using multiple hosts so you need to work a little harder.

3.Security Trails:

It is actually a repository of historical DNS data and you can get the origin server’s IP by looking at this data. Just like before, enter the application name in the search box and it will give you a whole lot of information. On the left side, you will find 4 rows. Go to Historical Data in there and see the ‘A’ field which will reveal all the IP’s related to the target.

4.Netcraft:

This website contains the history of hosting records for different websites. It can also be used if the other previous methods are not working. There is an extension for Netcraft which you can install to keep a look at the target’s different info which you can get from here.

What to do after we got the Origin Server?

Now there are 3 things which you can do now.

  1. Directly access the app through the real IP.
  2. Add the entry in the /etc/hosts file. In Windows, you can access this file from c:\windows\system32\drivers\etc\ hosts. Add the entry in it. In Linux, you can just do cd /etc to go to the /etc directory and then do nano hosts or vi hosts, whichever you like and add the entry like this.

    The OriginServer one was our new entry. You can use the same format on both Linux and Windows. Now when you do this, if you now try to go to the target application, it won’t go through the Cloudflare’s servers and directly access the application.

  3. Instead of option 2, you can also choose to override the DNS resolver for this project if you are using Burpsuite while Testing. It will do the same thing but it’s probably better because you just want to do it for this pentesting project and not for every time.To do this, go to the Project Options -> Hostname Resolution. Add the entry there. Just see the below screenshot in which I have added the Hostname and the IP address and this will override our computer’s DNS resolution which always takes us to the Cloudflare’s server.

When to think of bypass?

These methods are not 100% full proof and there are many more methods to bypass Cloudflare’s protection. dig and ping are especially useful in this cases. But when should you start looking for a bypass. Don’t just start looking for a bypass just after seeing that the application is using a Cloudflare’s CDN. First know, if the firewall is blocking your payloads. Cloudflare won’t possibly block you for every testing. Like it won’t if you check for Access Control and IDOR’s. It is up to the applications internal code how it handles that. Cloudflare will mostly block you for XSS, SQli injections, DoS, and DDoS attacks primarily, spamming etc. And many times even if you find the real IP and you go there it may behave in a weird manner or they may have taken extra measures in advance, so don’t lose hope. But from the next time you find an application using Cloudflare, you can definitely follow the methods mentioned in the post and you can also find some other ways if you search the internet. Try this and let us know your success stories.

HAPPY HACKING until then. !!!

© Enciphers. All Right Reserved 2018.