Category: Web App Security

30 Apr 2018

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

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

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.:)

14 Mar 2018

How self XSS got turned into an stored XSS ?

Hey everyone. Our company ENCIPHERS recently conducted a penetration test for a certain client XYZ and in this post, we will be sharing my XSS finding which was among the most critical vulnerabilities we found in the application.
The client here was a very reputed company which works in the field of video creation and animation. We can’t release the name of the client because the bug hasn’t been fixed yet as the test was done recently.

So our team started testing the application www.xyz.com. The first thing we did was to create 2 accounts one with the more features of a Paid account and the other was a Free Account and started cross-testing it for certain issues. But we soon found out, that there was an option to create our own videos and save it for future use. You can edit the videos or the text plus Export them or Upload to your google drive and several other features.

Now, what we did was to log in to our free account and created a video for ourselves. We saved the video with the payload

as name. But we got no popup and even checking in my videos list there was no success to be found because the name wasn’t getting reflected anywhere on the page.
Right beside it was an option for Collaboration. That means that we could share a copy of my video with other people who can work on them and can then again share it with us. As soon as we clicked the option for Collaboration, we got the popup as it was saying the video with “Video name” will be shared with these peoples and as a result, the name of the video was getting reflecting back. But the main thing was that till now, it was just a Self-XSS and it was not a high priority bug that could be used to attack others.

But there were two options which struck in our mind. The first was there was no X-Frame-Header or Click-jacking Protection present which could turn this into a Stored XSS. And the other method is what we actually did to turn it into a Stored XSS.

We went to the Collaboration option and gave our Paid account’s email id. We logged in to our Paid account and accepted the invitation to collaborate. As we think you must have guessed now, it had the same exact options as with the original one. So now if this user again goes to the Collaborate option to start sharing with some other person, the name gets reflected without any HTML sanitization and the user gets the popup. This was a simple method to get Stored XSS and in this case, it was a high priority issue because a user with an account for FREE features can get the session id and cookies of a PRO user and hijack the session. This is the POC screenshot.

Moreover, since it was STORED it can have as many victims as the attacker wants. Clickjacking in the whole application issue made the issue more CRITICAL because an attacker could use it to make the user accept the invitation for Collaboration.

This was all we did to get the above-stored XSS. The main thing to take out from this is there are always ways to convert any self-XSS to a General one. You just need to be on the lookout for that opportunity. Abusing Self-XSS using CSRF and Clickjacking are two of the well-known cases where any Self-XSS can be turned into a general one if the site is already vulnerable to attacks like CSRF and Clickjacking.

Meanwhile, keep hacking and we at ENCIPHERS will make sure to keep updating our blogs and tutorials so that you can learn different techniques with each post. Until then, Happy Hacking.:)

03 Mar 2018

Some quick checks to do in the password reset implementation during a pentest

Hello and welcome everyone to this new post from ENCIPHERS. Passwords are the first line of defense against any security attack. You must have already been told to use a hard and long password containing different kinds of characters. Password policies are also implemented so that the user is bound to follow these rules. But most of the times, the developers, and the testers miss one important thing to test thoroughly, and that is the Password Reset or Forgot Password functionality.

Yes, and in some of the recent pentests our team found a whole lot of vulnerabilities in the Password reset implementation of a web application. I will be discussing some of them in this post and the different steps and tools we used to find those issues. So let’s start then.

  • Broken Authentication in Reset password

    This was one of the most critical issues and was given a P1 priority. Through this vulnerability, an attacker could change any other user’s password without his/her knowledge through the Password Reset functionality. The attacker could use the “/passwordreset” API endpoint and change the password of any account with just the knowledge of email address.

    Steps:

    1. First, we raised a password reset request for our account say abc@gmail.com from forgot password link https://www.xyz.com/password.
    2. Capture this request in Burpsuite and just change the email to another valid email say xyz@gmail.com
    3. Hit the Go button and see the Response. The password of the other account was changed to your previous password successfully.

    This was the Request.
    Request

    POST /passwordreset HTTP/1.1
    Host: www.xyz.com
    User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
    Accept: application/json, text/javascript, */*; q=0.01
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Referer: https://www.xyz.com/recover/confirmEmail
    Content-Type: application/json
    X-Requested-With: true
    Content-Length: 63
    Cookie: session_guid=s%3As9hwB7YRvUuu0ZrtShtc1K994uINRPHW.mWdj5EBB5y%2BF8hZGQK52g5BrOkbuM0QujoT4HVlns8M
    Connection: close

    {“email”:”abc@gmail.com”,”password”:”aH6D=&@p3@”}

    This was the original Request. We just changed the email value to other valid email and we got the below Response. So we change the email in the above request to xyz@gmail.com and send the request. You are able to change the password of xyz user as shown in the Response below.
    Response

    HTTP/1.1 200 OK
    Server: nginx/1.11.8
    Date: Wed, 24 Jan 2018 21:27:52 GMT
    Content-Type: application/json; charset=utf-8
    Content-Length: 32
    Connection: close
    X-DNS-Prefetch-Control: off
    X-Frame-Options: DENY
    Strict-Transport-Security: max-age=7776000000; includeSubDomains
    X-Download-Options: noopen
    X-Content-Type-Options: nosniff
    X-XSS-Protection: 1; mode=block
    Vary: X-HTTP-Method-Override, Accept-Encoding
    ETag: W/"20-ji/kkxAvLqkafQZ/AmvRSPoi2nc"

    {“redirect”:”/?account=recover”}

  • Reset password list can be intruded to get a list of registered users

    This was a P3 priority issue but this issue along with the first issue could be used as a full fledged attack which will compromise the user account totally.
    The Forgot password url did not impose any restriction in number of requests being sent from a user. A hacker could make use of this and test for numerous email address which will result in sending reset password email to registered users.

    The Forgot password redirected to recover page if user was registered otherwise it redirected to login page with not registered message which can be used to guess which emails are registered.

    Sample Request and Response for a registered Email id:
    Request:

    GET /passwordreset/request?email=risabh%2enandwani@gmail%2ecom&g-recaptcha-response=03AA7ASh3zEWVCZjJiMIWFSs1zrSA-eiPoARwlgVFWGjZ0QgJMRVAZvV8ipx2q_lGnPN76E1jN6CzIa1pM05SQVc2zVXS21b_kqS0u4XhJW0grAWoujxQ7pArCXyaRbbapKNUD57dod793eKVcM1MRliiCMg16m3Rf8Hrc4q9G_bST5ynYQdjfLZdZs-oVhdA7WrPlmVJl8HTXSsAvjt4mQ5wR7brYch0i1U802ECRnDDpYC8Rcs1Hqfg3DZJ9cDv2BNRqRZ1gQMezvhhDhrBCx5r9SgD9NFCbZHWShKYygugGh76aiWWsZ1tSegFFmY0hP2ITV-t4hKmOUxo7GvXyMENaR-JFbsd22hz-UyHSauT5a5zETqy5e1-ZgG7QVETsDcnT6Nw7Pa8RVKOkSU8AQ90Ujg_Kv7cdIg&action= HTTP/1.1
    Host: www.xyz.com
    User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
    Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Referer: https://www.xyz.com/password
    Connection: close
    Upgrade-Insecure-Requests: 1

    Response:

    HTTP/1.1 302 Found
    Server: nginx/1.11.8
    Date: Mon, 22 Jan 2018 09:32:30 GMT
    Content-Type: text/html; charset=utf-8
    Content-Length: 62
    Connection: close
    X-DNS-Prefetch-Control: off
    X-Frame-Options: DENY
    Strict-Transport-Security: max-age=7776000000; includeSubDomains
    X-Download-Options: noopen
    X-Content-Type-Options: nosniff
    X-XSS-Protection: 1; mode=block
    Location: /?recover
    Vary: Accept, Accept-Encoding

    Found. Redirecting to /?recover

     

    Now just think for a moment. If the application isn’t using any restrictions on the number of attempts here, a hacker can simply use the Intruder in Burpsuite and do a brute force attack to know which users have registered email addresses. Now, this attack can then be further used for the attack we discussed in the first example to change the password of that account which will then totally compromise that account whether it be a user or an admin.

  • Denial of Service

    Now, this was kind of a vulnerability which will definitely create problems for the registered users.
    What it means is that if a password reset request is raised for any account, that account holder cannot login to his old account unless he resets his/her password through that link.
    It can be used to temporarily revoke the access of a user.
    Steps:

      1. Just raised a password reset request for another email id obtained through the Example 2.
      2. The reset link will be sent to the user but if the user doesn’t check the mail, he/she won’t be able to login to the application through previous details.
      3. If the user resets his password, the attacker can again send a password reset request and keep on sending them which will then totally deny access to the user.

    This was the Request and Response for a valid user.

    Request:

    POST /auth/local HTTP/1.1
    Host: www.xyz.com
    User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
    Accept: */*
    Accept-Language: en-US,en;q=0.5
    Accept-Encoding: gzip, deflate
    Referer: https://www.xyz.com/
    Content-Type: application/json
    X-Requested-With: true
    Content-Length: 55
    Cookie: session_guid=s%3Ag7MHq7gbCo-DYEcINT0ph5A7ZkDvbvFF.VV24NQNxr7Jls0qJQH91lH%2BHq25BTY5xE7JezupoeIQ
    Connection: close

    {“email”:”risabh.nandwani@gmail.com”,”password”:”aH6D=&@p@1234″}

    Response:

    HTTP/1.1 200 OK
    Server: nginx/1.11.8
    Date: Tue, 23 Jan 2018 11:04:40 GMT
    Content-Type: application/json; charset=utf-8
    Content-Length: 36
    Connection: close
    X-DNS-Prefetch-Control: off
    X-Frame-Options: DENY
    Strict-Transport-Security: max-age=7776000000; includeSubDomains
    X-Download-Options: noopen
    X-Content-Type-Options: nosniff
    X-XSS-Protection: 1; mode=block
    Vary: X-HTTP-Method-Override, Accept-Encoding
    ETag: W/"24-9CvwFGpkVCOkoBhIf3mK/SyHVEk"

    {“redirect”:”/?account=notverified”}

    See, after the password reset request was raised, the response we got was account not verified. And it will be like this unless we reset the password through that link.

    This was a P3 vulnerability but I think you can understand the relation between the 3 examples and how one can lead to getting the other.

  • Token used in Password Reset link

    Password reset test should be tested thoroughly else even one mistake may allow an attacker to take over the whole user account by changing his/her password.

    Steps:

    1. Let’s say the target is www.xyz.com. Send a password reset request for a normal user at www.xyz.com/password.
    2. Check your mail. In our case, the token was written in the link simply. Something like this:https://www.xyz.com/#/forgotpassword?token=7f72b80d-c323-48dc-bda0-cf49e6f574c2
    3. Now the things we need to check here, first of all, is the token expiration.
      Just suppose that this link doesn’t get expired after one use, then if the person could somehow get access to the user’s mail, he/she can then reset the password through this link again and take over the account.
    4. Many times, it may happen that the token used maybe is just an integer. In that case, you will need to send several different requests to check how the algorithm works and if the token is random all the times.

    So testing of tokens is an integral part of the testing for password reset functionality.

This was all we wanted to discuss in this post. This post will help you understand these things practically which will then allow you to use these methods for password reset testing. We hope you understood most of the things in this post. In any case, if you are a seasoned bug bounty hunter or penetration tester and you have other different methods to test for password reset testing, please comment below or write to us. We will make sure to add them in this post for our readers. Thanks and happy hacking everyone.:)

03 Mar 2018

How missing access control can make your application hacker-friendly?

Welcome back my hacker friends. If you have already gone through the OWASP TOP 10 for 2017, you will find that Broken Access Control is in the 5th position on the list. In the recent penetration tests, our team at ENCIPHERS found a whole lot of vulnerabilities regarding broken access control. So in this post, I will be discussing the different fields where we look and how we proceed accordingly to get these type of bugs in the web application.

So first thing, what actually is Access Control?

Access control defines the type of permissions which are allowed for different types of users of an application. These users can be a normal user of an application, a person having high privileges like having the Right permissions of an application or the Administrator of the application who can do anything with the application. Now say, for example, you have the access to only a normal user but somehow you get access to any other’s user account or the access to an administrator’s account, this is what is called missing or broken access control. All the privilege escalation kind of vulnerabilities come under this kind of attack. If the user can get access to any other user’s account, then it is called a Horizontal privilege escalation while if he/she gets the access to a user with higher privileges like an admin’s account it is called a vertical privilege escalation.

Practical Examples:

So now, let’s see some of the findings we got in the previous pentests so you can have a better picture of this kind of vulnerability.

  • Example 1. A user with only view rights could delete workspaces, libraries, and channels which should only be available to the admin.The target here was an Ad selling company for TV and media. The first thing which is required to get this kind of vulnerabilities is to have two accounts. It will be better to have two user accounts to test for horizontal privilege escalation and one admin account to test for vertical privilege escalation. We were provided with all of these already.These were the steps I followed:
    • Invited a user with the Admin’s account.
    • Signed up and logged in the account and this user was automatically added to the team.
    • With the Admin account, we only gave the user account the VIEW rights, i.e. this user can’t delete or change anything which has been added by the admin and provided to only the team members but can, of course, make his own workspaces, libraries and channels like any other normal user account.
      So the user can see the libraries, workspaces and channels and all the listings but can’t delete them because he doesn’t have any sufficient rights.
    • So what the user does is create his own library or workspace, delete it and capture the request in BurpSuite. This is how the request looks
      DELETE /mediamanage/group HTTP/1.1
      Host: www.xyz.com
      User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
      Accept: application/json, text/plain, */*
      Accept-Language: en-US,en;q=0.5
      Accept-Encoding: gzip, deflate
      Content-Type: application/json
      Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJlbWFpbCI6InJhaHVsc2luZ2hybHA4MTJAZ21haWwuY29tIiwidmlnb3JfaWQiOiIwMjc4YzViMi0xNjJjLTRmM2YtYjRmYi1jMGZmNTg3NzlkOWIiLCJpZCI6IjAyNzhjNWIyLTE2MmMtNGYzZi1iNGZiLWMwZmY1ODc3OWQ5YiIsInByb3ZpZGVyIjoibG9jYWwiLCJhY2NlcHRlZF9ldWxhIjoiVkVVTEFfMDcxMDIwMTUiLCJuYW1lIjoiam9objQwMDEiLCJpYXQiOjE1MTYzNDMxNDQsImV4cCI6MTUxNjQ3Mjc0NH0.JoxT32C5JPxirz3znvMIXUgFz-2i9mCNq1aX-RNv2oQ
      Content-Length: 120
      Cookie: session_guid=s%3A5glHGEGceeF8yiDx_zHyRHHAZZ0FGaH2.sTHMbPCLYoA4Wz0bHf1%2FQAAEQ3cdEuYakG5IVHX57cM
      DNT: 1
      Connection: close
      {“team_guid”:”d41344be-f986-4d09-9077-1a2af33b692c”,”service_guid”:”1002″,”guid”:”f6181612-3582-4262-b8b0-03b8ba01a801″}
    • Now, if you see the request carefully, you will notice that in the post body parameters there is a team_uid which will be same for everyone in the team. The service_guid represents which service we are performing in the application like Deleting a library in this case and the main thing is the “guid” which is the id for the library or workspace.
    • The user needs to get the “guid” value of this library or workspace of which he is a part of. So what the user can do now is to select the library or workspace created by the admin and see the request in BurpSuite where you may get the “guid” value of that media.
    • Now, just replace the guid value and the library or workspace or channel got deleted from both the user’s and the admin’s account.

    This was a critical issue of vertical privilege escalation which was marked as P1.

  • Example 2: Sensitive Information Leakage( A user with only View rights can see the details of the whole Team management system of the company which will reveal every detail that only the Admin should know)This was a pretty similar application like the previous one. Here the user with only view rights could see the whole team management system of the company along with their positions and email addresses.So to test for this:
    • We logged in with a normal user account in one browser and with an admin’s account in another browser.
    • This user was only provided VIEW rights. A user with VIEW rights can’t see the Admin Panel and yes it should be obvious.
    • So, we just pasted this link https://www.xyz.com/#/workspace/playbox/admin/teammanagement/ in the user’s account and BANZAI!! We were able to see the whole team management only available to Admin.

    Now the thing to notice here is when we just tried for https://www.xyz.com/#workspace/playbox or https://www.xyz.com/#workspace/playbox/admin, the application did nothing but as soon as I pasted that link we could see the same panel as an Admin.

    So, as a tester, you need to check each and every feature for broken access related vulnerabilities because most of the times, it’s not been tested completely.

  • Example 3: User with only VIEW Rights can send an invite to a new user who will then be automatically added to the Team with “EDIT” Rights.This was an extra step taken after the bug found in Example 2.Steps:
    • After doing all the steps as in Example 2, a user with only VIEW Rights can see the Admin panel of team management. Now there was also an option to Invite a User though it which should have been only available to the Admin.
    • Interestingly enough, when the invited user signed up for the account, he was automatically added to the team of which the user is a part of along with the “EDIT” rights which is a critical access flaw because not only the user added another user to the team created by Admin but that person was also given the EDIT rights.

So in this way you can find several access related flaws in an application. In bug bounties most probably you will be provided with a normal user account, so most of the times you will be testing if you can somehow get the account access of a different user. It’s always advisable to create two accounts and then cross-test them.
While capturing requests, you will come across many situations where there will something like an identifier or id. It can be in the post body parameters or in the URL itself. Changing of these identifier values can lead you to get account information which you should not have been given access in any case.

This is all for this post. We tried to give the most important practical findings in this post, s you could understand how this works in the real world instead of just testing on Webgoat or Mutillidae. Hope our findings will be somewhat useful to you in future penetration tests.Meanwhile, for further deep understanding, check out the OWASP guide on it and check out our video on Youtube here. If you will like to ask us anything or want us to add something more to this post, please comment below and help us make this post better. Until then, keep learning and Happy hacking.:)

03 Mar 2018

Our three favorite burp suite extensions and how to use them

Hey there. In this post, we will be talking about some of the most popular Burspuite extensions and the different features about them. If you have been doing penetration testing for some time you must be already knowing that Burpsuite is the best tool a web application penetration tester can have. There is already a blog post on Burpsuite extensions. You should read it from here. There are many extensions in the BApp Store, some of them are available for free version while there are many that are only available for the Pro version. We already know that the inbuilt features provided in Burpsuite serve most of the purpose but these extensions go one step further in identifying some critical issues. So let’s see our three favorite Burpsuite extensions and understand how to use them.

    • Active Scan++ (Available for Pro version)

      This is one of the most popular extensions in Burpsuite. If you have used the Pro version, you must be already knowing that Burp Pro comes with scanning(Both Active and Passive) scanning capabilities. Now, this extension further extends the capabilities of scanning and help identify some awkward behavior that can be of particular interest to testers.

      This extension is only applicable for users having Burpsuite’s Pro Version because it will just start running when you do a simple Active scan on the target.

      How to install Active Scan++:

      1. First, you need to install Jython 2.5 or higher standalone version. Download the standalone version from here. The latest version at the time of writing this is 2.7.0.
      2. Open Burpsuite. Go to Extender -> Options.
      3. In the Python Environment, select the file for the location of Jython standalone Jar file which you downloaded earlier. See the screenshot below,
      4. Now again go to the Active Scan++ option in BApp store, you will see that the Install option is now available. Just click Install and the extension will be installed on your Burpsuite.

      One thing to mention, you won’t see the Active Scan++ tab as you see for the other extensions because it will be automatically added to the Active scanning of Burpsuite. SO to run it, you just need to do a normal active scan and it will add the issues which it finds.

      Particular issues that it takes care of:

      Active Scan++ will notify you of issues like XML input handling. Or if the input you submitted is being treated as a code rather than a plain text, for example, if you submit 5*5 and it outputs 25 instead of 5*5, and also checks for potential host header injection attacks.

      There is also a manual way to install Active Scan++. See this official Github page for instructions on that.

    • JSON Beautifier: (Available for Free version)

      This is one of the extensions, we have been using pretty much lately. Ever thought how easy it could have been if you could somehow see the JSON content in a better way rather the crunched stuff you see when there is a JSON Response. Sometimes, it’s so difficult to understand the content that many people copy it into a text editor and then arrange it to understand the syntax properly.

      If you are one of those, and you think that there should be a way to see these JSON Responses in an arranged manner, then hey, this extension is perfect for you.

      How to install JSON Beautifier:

      JSON Beautifier is available for free version also so do give it a try.

      1. Go to Extender -> BApp Store. You will see the JSON Beautifier extension there.
      2. Just Hit Install. Nothing special to do like that in Active Scan++.

      See these two pictures of before and after. The response in the picture is small but many times you will see Responses which are 50-60 lines long. So just check the after use image and see for yourself that how good this will be if arranged because you will be able to properly see the JSON content and can look for what you want.


      The particular issue that it takes care of:

      Basically for beautifying and arranging JSON content.

Reflected Parameters: (Available for Pro users)

This is also one of the most popular extensions for BurpSuite.

How to install Reflected Parameters:

      1. You need to have Java version 7 or greater installed as a prerequisite of installing this extension. So, install Java at first.
      2. After that, Go to Extender -> BApp Store.
      3. Go to Reflected Parameters Extension and simply Install.

Particular issues that it takes care of:

As documented in the official page, this extension

      • Monitors traffic and looks for request parameter values (longer than 3 characters) that are reflected in the response.
      • The extension monitors in-scope requests made by the Proxy and Spider tools. When sending an item to the Scanner, you can choose to scan all reflected parameters or only one reflected parameter.

We haven’t used this extension too much but yeah it is definitely popular and worth trying. It can also help you to get XSS issues in a web application so try it once.

So this was all for this post. There are a whole lot of extensions available in the store and testers are adding more and more every day. If you want to add an extension yourself, you have the option to do so. Several people may have different opinions about the extensions they love. If you are one of those and want us to add any more awesome extensions, do comment below and we will be more than happy to include it in this list.

Until then, start using Burpsuite and Keep Hacking.:)

27 Jan 2018

Subdomain Takeover

Hello, everyone. We have talked a lot about the TOP 10 web application vulnerabilities by OWASP in the other posts. This time we are going to learn something new which is being quite a common submission in the recent bug bounty reports. The vulnerability which we will discuss is Subdomain Takeover and we will see the different methods and tools which will help you to know which subdomain is vulnerable to this kind of attack.

So what is Subdomain Takeover?

A subdomain takeover is exactly what it sounds like. When an attacker can claim a subdomain of a site, it is said to be subdomain takeover.

Simple Example:

  • Let’s say there is a company called xyz.com
  • This company opens a service called “blogs” and registers this on Amazon S3.
  • So the DNS entry of the subdomain blog.xyz.com now points to the Amazon S3 bucket.
  • After some time, the company decided to stop this service but by mistake forget to remove the DNS entry and the S3 bucket remains unclaimed.
  • Now what the attacker does is register this S3 bucket as their own and all the traffic of the blog.xyz.com will be directed to a malicious site owned by you.
  • So the attacker can now use it as a phishing site because everything will seem legitimate to the user. The attacker can simply put an HTML form asking the user to log in and the user will do so due to their trust in the company xyz.com.

This kind of subdomain takeover vulnerabilities generally happens due to unclaimed DNS entries for external services like Github, Amazon S3 buckets, Heroku, Shopify etc.

So let’s get to the practical side.

How to test for Subdomain takeover?

There are several tools available for testing this. Let’s go through each of them one by one.

    • HostileSubBruteForcer This is one of the best tools available for testing for subdomain takeover written by Nahamsec. Just download it from here.
      After downloading, just go the folder where you have downloaded it and type the command:ruby sub_brute.rbIt will open a tab like in the screenshot. Just enter the domain name for which you want to test which subdomains are not correctly configured. In case this tool finds something suspicious it will show them in a red color.It will show you where the subdomains are pointing to. In case it finds that the DNS entries for a certain subdomain are pointing to something suspicious or to a 3rd party service which is not being used it will notify you.
    • Knockpy Knockpy is one of the more popular tools. It is actually a subdomain enumeration tool. In case, it finds that a subdomain is pointing to an external service it will notify you of that.
      You can download Knockpy from here.
      Now in case, if Knockpy notifies you of external services, you need to visit that domain to check if it is vulnerable or not.
      Let’s say that the DNS entry was pointing to a service on Heroku. Now when you visit the domain, it shows you this picture.

      Now, this in almost most of the cases makes sure that the subdomain might be vulnerable to takeover. In case, to be fully assured of the vulnerability, you will need to register on that service, in this case, the Heroku one and just host some of your content there to fully demonstrate that you have claimed the subdomain and it is now a perfect place to get user’s credentials.
    • Sublist3r Sublist3r is actually a very popular subdomain enumeration tool. Actually, it enumerates subdomains using many search engines such as Google, Bing, Yahoo etc. Download it from here.After you have downloaded it, and done with all the Python settings, just use this command to get started.
      Go to the folder where sublist3r.py has been downloaded and type:
      python sublist3r.py -d xyz.com

      Now this will enumerate all the subdomains of the domain xyz.com. The motive of this is after we get all the subdomains we will need to check the CNAME or the Canonical Name of each subdomain. It can be found in the DNS information of a particular subdomain. Otherwise, there are online tools also to get the CNAME of a particular subdomain like this one(See the screenshot below). Now if you find that the CNAME is pointing to a 3rd party service like Amazon, Heroku, Shopify etc., you will need to go to that service and verify if it can really be claimed so that the service now points to our malicious site and the subdomain takeover is complete.

      Another method which is there is to use the host command in Linux to check where the subdomain is pointing to. Just type the command:

      host blogs.xyz.com

      and it will show where the subdomain is pointing to and now we can verify it from there by applying the steps from the previous methods.

      There is one other subdomain enumeration tool called Subbrute which increases the possibility of finding more subdomains which automatically increases your chances of getting any subdomain available for takeover. You can download the tool from here.

    • Aquatone Last but not the least, there is one other tool which has been there for less than a year but slowly gaining some name for this kind of testing known as Aquatone. Download the tool from here.
      After downloading and all the setup type this command to use the aquatone takeover tool.

      aquatone-takeover --domain xyz.com

      The best thing is that the result is a JSON file in which you will get the name of possible subdomains vulnerable to takeover along with their CNAMES. So now you can go the respective service and try to claim it for the attack to be successful.

So this was all for this post. In a summary, subdomain takeover is a critical security issue which commonly occurs when a company assigns a subdomain to a third-party service provider and then later discontinues use, but doesn’t remove the DNS configuration. This leaves the subdomain vulnerable to complete takeover by attackers by signing up to the same service provider and claiming the subdomain.
And while submitting for this kind of bugs, it’s always better to claim the subdomain and don’t just report as soon you see the error message. Hosting something simple to fully show that the subdomain has been claimed will always be considered a better valid report in this case.

Hope you enjoyed this one. There are lots of reports for this kind of issues, so do read them as it doesn’t require any fancy testing like for other OWASP TOP 10 vulnerabilities. In case you didn’t understand something, please comment below and ENCIPHERS will always be there for your help. Until then, KEEP HACKING.:)

25 Jan 2018

How to exploit XXE vulnerabilities?

Hi everyone. In this blog, we are going to discuss a critical web application vulnerability known as XML External Entity vulnerability also known as XXE. XXE is at the 4th position of the OWASP TOP 10 vulnerabilities in 2017.

What is XXE actually?

XXE vulnerabilities are used to exploit how an application parses the XML input or basically attacking the XML parser itself with the help of external entities. If you are not so sure about XML first, then please read about it and then continue this blog so that you understand the syntax.

A simple XML document will look something like this:

Here the first line declares the starting of XML. And all the tags are called elements. Here, employee is the root element.

Read more about DTD’s and attributes from here.

What are External Entities?

So, an XML entity is used to reference some information externally or internally. If the entity declaration and everything is done inside the same document and nothing needs to be fetched externally then this is called Internal Entity.Eg:

Now coming to the main point of the post, below is the syntax for External Entities.

Now, when the XML parser goes through this XML document, the file from the URI handler is downloaded and substituted in place of the external entity references. These are called External Entities.

Practical Example of XXE:

The best way to learn about XXE vulnerabilities would be to practice it. So open up WebGoat and go to Parameter Tampering exercise. You will find the mission for XXE vulnerability there. Make sure to start Burpsuite to capture requests. If you are having any problems, setting WebGoat with Burpsuite, please see the video here.

The problem is to find the vulnerability in the search form and list the root directory. You can also extend the attack to get the password files and do many more things.

Now, when you just enter a random thing and check the Request,

You can see that an XML parser is in place. And you can now start playing with different XML inputs to exploit any vulnerability in the XML parser.
So here, we can use External entities. External entities defined in the DTD will be replaced in the form element and that will do the trick.

So, capture this request in Burpsuite and change the XML code with

Here since we need to get the directory listing, we have used file:/ as the external URI and sname is the name of the external Entity. If you are familiar with the syntax of XML, it’s nothing fancy.

This is the Response we get.

Now, you can also leverage this attack to get password files or do a whole port scan of the internal system and DOS attacks too.

We just need to change the external URI to do the trick for us

We get the contents of the /etc/passwd file from the server as the response.

How dangerous is XXE?

XXE vulnerabilities can lead to different attacks. The first one as you saw above to read juicy configuration files which can contain sensitive information such as username and password from the server. Scanning of different ports of a remote host, Remote Code Execution and Denial of Service attacks are possible through XXE vulnerabilities.

Where to look for XXE vulnerabilities?

XML parsers are very common nowadays and many of them are still misconfigured. They can be found in the form of API endpoints and even in the file upload forms which process XML after getting uploaded. You need to see where XML parser is being used and how it is parsing different inputs to exploit any vulnerabilities present. Companies do give a cool amount of bounty for reporting these kinds of bugs in Bug Bounties. So better start reading it from OWASP and other resources.

This is all for this post. If you didn’t understand something or want any help, do comment below. Until then, keep learning and keep Hacking.:)

24 Jan 2018

Different tricks to get ‘XSS’

Hey guys. Welcome to the new post from ENCIPHERS. As we think, you must be knowing that Cross Site Scripting is the most prevalent vulnerability present in any web application even now. We have discussed the basics of XSS in this post. Take a look at that if you are a beginner, else continue with this one. Now there are many ways to exploit XSS. Now by the exploit, we don’t mean different payloads, that is one aspect of it, but we mean that you can find XSS at different places on a website. So let’s get started with it.

EXAMPLE 1: XSS in form input fields

Now, this is the place where we all start looking for XSS at the first sight. If we see any input field, we just try to put different payloads and see how the application responses to it.
Let’s see an example from Webgoat. If you see the problem for Stored XSS attack, there are two input fields, one for Title and other for the message.
We have put the payload

in both of them. That’s how we usually do, insert payloads in all the input fields. And we got the popup as in below screenshot.

This was the most basic payload which won’t work always. So make sure to check our other post here and also see this awesome page from OWASP for further details on how to use different payloads when different filters are in place. So this was the simplest example to find XSS in a normal form input field.

EXAMPLE 2: XSS via image upload

Nowadays, many web applications ask users to upload an image. It can be the profile picture, any banner or logo for your company or any cover pic. Just think of any input method which allows you to upload a pic either from your computer or from Cloud.

Now trick to get the XSS, use XSS payload as the filename. For example, change the filename of the image you are uploading to,

and you will get the XSS triggered.

Many times server even doesn’t check if the uploaded image is the correct extension like png or jpg. In this case, you can upload any file, just remember to give the XSS payload as the filename.

If you see that it isn’t working then URL encode the payload,

and try it.

Now, what should you do, if the server is checking the extension of the image and also checking the file? There is one way out of this by changing the content-type. We will look at that later in example 4.

EXAMPLE 3: XSS while importing Contacts or Tasks

If you come across situations, where you are getting a chance to import anything whether it be contacts, your files, your tasks or anything like that, try the same thing as in Example 2.


Just create a file and write anything inside it but give the XSS vector as the filename. If the server is checking the extension, like in the screenshot, it’s asking to only upload a CSV or vCard file, then upload the file with same extensions like .csv or .vcf.

It will work in many cases. If it says to Import from your Drive account or any account, just do the same thing i.e. save the filename as the XSS vector there and then import.
If it says that the file is not valid, then create a legal CSV or VCF file but give the XSS payload as the filename.

EXAMPLE 4: Triggering XSS by changing the Content-Type when the server isn’t checking the content

As we discussed in Example 2, there may be cases when just saving the filename as an XSS vector won’t trigger an XSS. In this case, you need to check another thing i.e changing the MIME Content-Type of a file.
For this, you will need a proxy interceptor such as BurpSuite. Let’s suppose there is an image upload functionality. The valid MIME’s for these should have been image/png or image/jpg. To check for this,
Create a normal HTML file with javascript’s alert function inside it. But give the filename with the proper extension of jpg or png like uploadPic.jpg.

Now intercept the request using Burpsuite, it will be something like this when you intercept the request:
HTTP request

Now change the filename to uploadPic.html and the content-type as text/html as shown below.

If the server isn’t checking the content of the file, XSS will be triggered.
This can also be used in Example 3 scenarios. You can also use it as a file upload vulnerability and try to upload a php file or so.

EXAMPLE 5: XSS via improperly implemented Markdown parsers

If you don’t know how Markdown works, see this page here. It is generally used in Forums or if you have reported any bugs via HackerOne you must have seen them. Now if the Markdown parser hasn’t been properly implemented, there might be several vulnerabilities which you can find.
Let’s take a specific example of creating a user-clickable link via Markdown. Its syntax is like this:
[text to show on the page](link to go)

As an example let’s take:
[Go to this page](https://enciphers.com). After parsing it converts to,
Go to this page.
Now if you get where it’s going, instead of the link, you can put an XSS payload there like:
[You have been hacked](javascript:alert(1);)
It will trigger the XSS.
As we said, if the Markdown parser hasn’t been properly implemented then only this will happen. So you can try this when you find that Markdown is being used. Now since Markdown is generally used in Forums, it can also lead to Stored XSS which will be much more severe than the Reflected one.

So this was all for this post. We have discussed several tricks of finding XSS. These examples are the compilation of different reports disclosed and different posts and books we have gone through and these will definitely come in handy while looking for XSS in a web application. You can also make appropriate changes according to your needs in the examples. Now, these methods will give you more places to look for XSS vulnerabilities.
If you think there are any better methods you would like u to add to this post, please comment below and after reviewing we will definitely add it to this post. As for now, Keep Learning and Happy Hacking.:)