Category: Web App Security

  • Home
  • Web App Security
13 Sep 2018
The Art Of Hacking, Web App Security Blogger 1 Comment

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

30 Apr 2018
Web App Security Blogger 0 comment

IDOR to change the email notifications of user

Hey guys. Welcome to this new post from ENCIPHERS. Recently we have been writing a lot about bypass of different access controls and in the recent pentest conducted by our team, we again got some medium priority vulnerabilities regarding horizontal access bypass. And we will be discussing what was the vulnerability and how we proceeded to get that.

So what was the vulnerability?

As you can see in the title itself, the vulnerability was that any user can unsubscribe any other random user from the email notifications. Now on the first look, you will think that it’s not a very cool type of vulnerability but let’s say, there is going to be a sale of Redmi Note 6 Pro on Amazon from today. The item is already OUT OF STOCK, so Amazon says that you will get an email notification when the sale resumes again. We believe that you must be getting where we are going with this. So now, what if the user was unsubscribed from his/her email services and wasn’t getting email notifications for the above item when it was out? He/she won’t know when the item is again in stock. This will lead to the decline of the business of the company which is a great problem in itself. Now the site we pen-tested had the similar kind of vulnerability present.

How we proceeded to get the vulnerability?

The application was a European e-commerce website.

  • We simply logged in to our user account.
  • For every item present there, there was an option to get email notifications for any upcoming information on that item.
  • If we turned on this notification, each time a mail will be sent to us.The link in the mail looked something like this:http://www.xyz.com/ticker/management/771255762/admin
  • As you can see, there is an identifier and we have already discussed in our IDOR posts earlier, how to check when there are simple identifiers like this one, no alphabets or special characters included.
    So we created another account and tried to open this same link in that user account.

Result of doing this?

We could see the items to which the user has subscribed to. Not only this, the user’s email id was also in open there with an option to check and uncheck the different subscriptions.
Now, we simply unchecked the different subscriptions and then when we checked it from the first account, there were no subscriptions present in the Subscription tab.

So this was a simple horizontal access bypass in which if we could somehow guess the identifier or we could see the person’s mail and which can definitely help for a larger attack. Now the most dangerous thing in this case, can be using the Burp INTRUDER. In cases like this, the one thing which you need is to see that what part of the identifier is varying and put your payload in that style.
It can give you a whole list of valid user id’s which can then be used for phishing or different high-level attacks apart from the IDOR we have seen here.

Main Points to take out from here:

We have written many posts on this kind of issues and the motivation to write this is access control measures not taken like putting a filter at a place. It needs to be executed for each request and for each action. There were no identifiers present in the application itself. But the identifier was present in the mail which led to getting this medium priority vulnerability. So keep a look for any place be it URL or mail for any kind of id. For any kind of reference on IDOR, you can always read this post of ours. Hope you will get to know another technique if you get something similar to this while testing or bug hunting. Happy hacking..!!!!

30 Apr 2018
Web App Security Blogger 1 Comment

Doing Subdomain Enumeration the right way

Hey guys. Welcome to this new post from ENCIPHERS. For the last few months, we have been continuously writing about different Findings and the approach our team took to find those. But there was one thing, which we wanted to share and that was the very first step itself. Be it bug bounties or Penetration tests, one thing that is commonly important is the subdomain enumeration of the targets.

We think we have talked about one or two subdomain enumeration tools in the post of subdomain takeover. But in this post, we will be discussing a whole lot more while providing you the required resources and how to use these tools accordingly. Not only this, but we will also tell you how our team was able to find a CRITICAL vulnerability during a client’s penetration test. So let’s start.

So what really is Subdomain Enumeration?

This is something which you will simply get to know from a simple Google search in much details. In a simple sense, it is the process of finding valid (resolvable) subdomains for a domain. Now, what does it mean practically?
Suppose you have to do a penetration test for a client, and the target in-scope is *.target.com. Here, the main domain is target.com but due to that “*”, all the subdomains are also in scope. In this case, the subdomains can be blogs.target.com, sales.target.com, cdn.target.com and many more. It becomes all the more important in bug bounties to find as many subdomains as possible to find vulnerabilities in areas where no one else has started testing.

Let’s see the practical side and tools which will help you in Subdomain enumeration:

There are a whole lot of tools present today for subdomain enumeration. Many security researchers maintain their own scripts to find manually valid subdomains so that they don’t need to deal with many false-positives. But if you are starting new, it will be the best to use the most popular tools for this purpose which have got good support from a large number of users. Some of these are:

  • Sublist3r:It is one of the most popular open source subdomain enumeration tools. This is the Github link from where you can see how to install and start using Sublist3r.
    Sublist3r enumerates subdomains using many search engines such as Google, Yahoo, Bing, Baidu, and Ask. Sublist3r also enumerates subdomains using Netcraft, Virustotal, ThreatCrowd, DNSdumpster, and ReverseDNS. So you get a lot of subdomains from a simple scan using Sublist3r. The problem sometimes is that Sublist3r relies mainly on passive data and so it doesn’t validate if the subdomains do exist in reality or not. So after a simple scan, you will need to check one by one for the valid subdomains.
    Example: If Sublist3r has been installed correctly and the target is google.com, then,python sublist3r.py -d yahoo.com

    will give you all the subdomains of Google. See the below screenshot.

  • Subbrute:Coming back, this was our first and favorite subdomain enumeration tool for a little while earlier. You can download and install Subbrute from here. Moreover, Sublist3r has also been integrated with Subbrute just for the purpose of finding more accurate subdomains using brute force with an improved word list.Example:
    python subbrute.py google.com

  • Google Dorks:Now this one is the most famous and the best tool for subdomain enumeration. Actually, it is not a tool, it is just the way of using Google in an advanced way which can unlock many hidden doors. We have already written a post on Google Dorks here. One of the easiest ways to get different valid subdomains is by using a simple technique mentioned in the example.Example:
    In the search box just type

    site:google.com
    It will start with www subdomain and then all the subdomains after that. Suppose, the page only contains cloud.google.com with different paths. Now what you will do, is

    site:google.com -www -cloud

    This search query will remove both the www and cloud subdomains of google from the results. The results will get less and less and you can add each unique result to your subdomain list. It is a manual task, but this gives the valid subdomains in all cases, and many times you may find a page or application just open to hacking into. There are many more applicable cases in this. Read the link we provided earlier to get more of it.

There are other tools like Knock and Masscan. Read more and download Knock from here. You can download Masscan from here.
I will be doing a separate writeup or will add them here in the near future after properly using them. Still the abovee 3 will work fine for you.

How Subdomain Enumeration helped our ENCIPHERS team to get a critical bug which could lead to the total hijacking of the application?

If you have read H1 reports for some time, then you must have seen many Subdomain Takeover reports which were found just by doing Subdomain Enumeration and then taking over that subdomain by hosting some simple content there. But in the last penetration test, our team found one of the easiest and most Critical bugs that could be found there. Let’s suppose the application to be tested was xyz.com.

A simple subdomain enumeration scan through Subbrute gave our team member Rahul the following subdomains:

./subbrute.py xyz.com

……
Now it was time to manually validate each subdomain and of course, there were many more subdomains we got but we didn’t add them here. The thing which he did by mistake was to only search for the exact subdomain without testing for the https:// one. What it means is:

When he searched for jenkins.xyz.com, it showed him nothing on the page and he just left it there that this subdomain is invalid or so. But then the other team member Abhinav told me to look for
https://jenkins.xyz.com
and to my utter surprise this page could authorize us to there Jenkins server account and after that, even a newbie hacker will know what to do.:) So this was his personal experience, where he came to know across one fact that always check subdomains for both HTTP and HTTPS and then make sure if they are valid or not.

Important Advice:

One thing you will learn in the white-hat hacking community is that to always abide by the scope of the target and not to test on out of scope items. But from our personal view, always do a complete subdomain enumeration of the target at hand and see if there are any vulnerable to subdomain takeover or if things like Jenkins or important private git files are just in the open for the public. The companies won’t mention it implicitly but you can always send these reports and if it is a bug bounty, then stay ready for being rewarded. But do not manually test on the subdomains if they are not in scope. Just test for subdomain takeovers and private files in open and that’s it.

So this was all for this post. If you already knew about Subdomain enumeration tools and if you have one of your favorite please write about them in the comment section and we will make sure that we update this post to add yours. Meanwhile, if you are not yet aware go read about different tools which we mentioned and play with them and see which one works best for you. Happy hacking till then.:)

14 Mar 2018
Web App Security Blogger 0 comment

Bypassing Access Control to see the private videos of an user

Hello security professionals. In the last post, we talked about the XSS finding in the recent penetration test conducted by our company ENCIPHERS. Here is a link to that post. In the same penetration test, we found another vulnerability which was really an interesting one.
But first thing’s first, if you are not sure about access control issues, we have already posted a tutorial for it. Go to this link to read the post.

Now, let’s see what we did and go through step by step. If you know, to test any access control issues, the best way is to create two accounts. You can make 2 accounts which have the same access level or if you can, you should always create 2 accounts 1 with normal features and other with the more features of a Paid account. This is the first thing which we did. Created 2 accounts, one of a Free User and the other of a Pro user and started cross-testing them.

We logged in with both of these accounts in different browsers. Then we opened the account with Pro features. As we already told you in the previous post, there was an option to create self-videos and edit the different details as necessary.

So we created a video and opened the Edit options which led me to a new page. The link to that looked something like this:

https://www.xyz.com/html5-studio/#/edit/fwyFsxFfB8Z

The identifier here was not random i.e it wouldn’t change if we made any edits in the video. So this was a plus point and a hint to test for access control because the identifier won’t be unique every time.

The request in Burpsuite looked something like this:

And the response was the one giving out all the details of that video and stuffs inside it like text.

So we went back to our free account and in that browser opened the above link by pasting it there. It worked.We could see the whole video and even play it with what else has been written or added as animation or text. There were no access control measures in place until this point. To see this in Burpsuite, we just needed to change that identifier fwyFsxFfB8Z to the one from the other account to see all the details.
But right after this point, the system prevented me to Edit or Save the file but we had full read control over the video.This vulnerability was critical in its own sense. Because of:

  1. All the URL’s were getting saved in the browser’s history. It means anyone gaining an access can then open the link or share it with him to check the video in make.
  2. The most important issue was the attacker will always see the updated thing. That means if the user has made any changes in the video or animation by adding any text or scenes, the attacker will see the same thing as that user.
  3. The issue was for both private and public videos.
  4. This could lead to important information disclosure because the attacker could see the same video. Just think for a second, if it is a reputed company or so, preparing their videos or any stuff and it is in a draft state and if the attacker by any chance get the link, he will see that stuff himself/herself and meanwhile can find any other way to download that thing before the video gets public.

So this was a simple case of access control. You will think that Write access was not granted but gaining access to things which you are not meant to have is what is access control. We had full READ access to that video which is pretty much a problem in itself.

We will be back again with lots of cool stuff which ENCIPHERS findings pentests or Bug Bounties. Hope you will like it and learn a lot from these practical cases. Happy hacking until then.:)

© Enciphers. All Right Reserved 2018.