Author: Blogger

I am the one who publishes all the blogs for ENCIPHERS :-)
29 Oct 2018

Workshop on DISCERNING HIGH IMPACT MOBILE APPS VULNERABILITIES at Bsidesdelhi on 25th Oct

About Conference
Bsidesdelhi is a event where professionals, experts, researchers, and InfoSec enthusiasts come together to discuss on information security.

 

Workshop highlights

This workshop was about High Impact Security Vulnerabilities in android and ios application.Workshop was focused on teaching how to test a mobile for some of the high impact security vulnerabilities and how to fix them.it was having good mix of presentations ,demos and hands on practicals on a VPS which was provided to attendees.

and some of the Vulnerability case studies were discussed why they exist, how to test such issues and fix them.

It was an awesome experience with attendees and Thanks for joining the workshop.
Hope to see you at Advance Level Web Hacking a part of “Art of Hacking” Series on 16 dec want to join the workshop check out the enciphers blog post about Advance Web Hacking.

01 Oct 2018

Web Application Hacking – Advanced Level

Right after the completion of our first training “Web Application Hacking – Basic Level”, we announced the advanced level training.

  • Training Name: Web Application Hacking – Advanced Hacking
  • Training Agenda: Find it here: Agenda For Web Application Hacking – Advanced Level
  • Training Date: 16th December 2018
  • Training Venue: Vivanta By Taj, Dwarka, New Delhi
  • Training Fee (Inclusive of lab access and taxes): 12,000 INR
  • Unique benefits of this training: 
    • One day training on advanced level attacks on web applications.
    • One month access to a specifically designed virtual private server. Attendees can use this server to perform bug bounties on targets and submit reports. The VPS (virtual private server) will also have detailed guides on how to start the testing, how to use specific tools on those servers and how to submit reports and earn money.
    • Invite to two Q&A sessions to ask doubts and take help.
    • Access to separate channel for asking questions and taking help.

 

How to enrol for this training:

Screenshot 2018-09-29 at 10.54.28 PM

Screenshot 2018-09-29 at 10.53.33 PM.png

 

01 Oct 2018

“THE ART OF HACKING” First Training

On 29th September, 2018 Enciphers conducted a training on WEB APPLICATION HACKING – BASIC LEVEL as a part of the training series “The Art Of Hacking”

20180914_143502_0001.png

It was a full day hands on training where everyone got to learn about web application Hacking , how to start with bug bounties , write good reports , things that should be avoided while doing bug-bounties and the most important thing different approach of finding vulnerabilities with higher impact.

The training agenda was designed in such a way so that people just starting their career in web application security can understand the basic concepts and improvise as we move ahead to advanced concepts. All the attendees did hands on practical of some of the concepts, in a customised virtual machine provided. 

During the workshop attendees learned about the basics of web application, about DNS stuff , burp suite and Recon, how to find “easy money bugs” Where to look for bugs like XSS , CSRF, Access Control & improper session management issues, Insecure subdomain & hidden insecure files. In one of the module high paying bugs were covered where attendees learned about IDOR , MFA bypass, password reset issues, session management issues etc. There were lots of interesting test cases were shared with attendees, which were found in penetration tests done by Penetration testing team of ENCIPHERS.

Some of the pictures from the training session are below. Are you in these pictures? If not, then you should 🙂 

 

You can find some of the content used in this training here.

13 Sep 2018

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.

10 Sep 2018

The Art Of Hacking

About:

A series of training focused on teaching practical penetration testing on Web and Mobile applications. These sessions are going to be hands on, classroom based, lab focused.

All the training are divided into Basic and Advance level. All the basic level will be free training and advance level will be paid.


How the first session will be organized?

  • The enrollment form for the first training will soon be launched together with the agenda of the training.

  • Interested attendees are required to fill the enrollment form after reading the description carefully.

  • From all the enrollments, we will confirm the enrollment according to the number of seats available. A confirmation email will be sent to those attendees with date and venue details.

  • Come and join us in the first training session 🙂


How the attendees will be selected?

Free Trainings:

  1. The first people to get access to the enrollment form will be from our Slack group (Join Here: Slack Group Invite).

  2. Next, the enrollment form will be made public and anyone can fill the form and enroll for the training.

  3. Once the time period for enrollment ends, we will get all the attendees details and send the confirmation one by one, on first come first serve basis.

  4. If, there are too many attendees left out after first training, we will make sure to schedule another training for those.

  5. The confirmation email will have all the details about venue and timing of the training.


Paid Trainings:

  1. A link will be shared to enroll for the training in the slack group first and then will be made public.

  2. Once the enrollment ends, we will share the confirmation mail with all the details.


Important Note:

If you have enrolled for free training and realize that you won’t be able to make it. Please send us an email at artofhacking@enciphers.com

If you fail to let us know and your seat goes empty in the training (because we won’t be able to give it to someone else), we will not be able to select you for any future training. Obviously, people with emergency or valid reason for not being able to attend the training, will be an exception.


Who will be the trainer?

Trainer Name: Abhinav Mishra

LinkedIn Profile: Link

Trainer’s bio: Abhinav has around 7+ years of experience in Information Security, penetration testing and hacking. You might have seen him giving trainings in several information security conferences and meet ups. Some of the recent training are: co-trainer in BlackHat USA 2018, BsidesDelhi 2017.

Abhinav is the founder and head of security operations at ENCIPHERS. He is also one of the Research Advisory Board member for Cobalt Core, where he also leads the penetration tests. One of the Synack Research team member, have won several accolades, bug-bounties and Hall of Fame. As much as he loves hacking, he loves giving training too.  You can find him on twitter @0ctac0der.

 

NOTE: Keep checking this page regularly, we will very soon publish the enrollment form for the first training.

 

02 Sep 2018

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

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

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

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

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