How I got sensitive details of a company via misconfigured endpoints?
Hey guys,
The title seems somewhat catchy, but let me tell you the story how I got different sensitive details of a company via "Forced Browsing" on endpoints and how you can try to find the same kind of issues in Bug bounties or penetration testing.
So last week I was performing a penetration test for a certain company. Let's say the main application was www.xyz.com. The application was an organization basically and I was provided with all level of access. It had 5 layers of different access controls of which an Account-Admin had the highest privileges whereas a Normal user of the organization had the lowest privileges. Between these two there were 3 other privileged users such as Manager, Team Leader etc.
Now when you come across this kind of applications where there is a different kind of privileges, the first thing that comes in my mind is can I somehow READ or EDIT the details of a higher privileged user. XSS also comes in handy in this kind of situations(and I did get one to XSS the Account-Admin from user's account, the tale of which is in another blog post ;)).
So the first thing what I did was to log in with the highest privileges i.e. Account-Admin in one browser, whereas logging in with the lowest privileges i.e User in another browser. I went through all the functionalities one by one in both of them.
Let me tell you more about the application so you can feel how the testing looked like. We were provided with Account-Admin credentials from the client. The Account-Admin could then invite different people on the team via email address and assign Roles(like user or Team Leader) to them.
Now the one thing which caught my eye was there were certain things that were not present in the user account but were present in the Admin account(and of course, that's normal). The admin will always have access to extra functionalities. The first thing was the Settings. The Admin account had a Settings page, via which they can handle the different settings for the organization. This included the details of all the accounts in the organization such as users, Managers, team leaders with their mail addresses an option to edit their privileges or delete their accounts and so on. But the user account didn't have access to such kind of settings. Why the hell would a company want a normal user to see the details of the higher privileged users? Also, this application had an option to set up meetings on different dates, set the terms and conditions of the meetings and also to set the location of the meetings which was accessible to highest privileged users only. These all features were available to the Account-Admin only so he can see or edit them.
So here starts the main part(interesting part),
1. The Account-Admin could get the different details of the users via just browsing to the page, www.xyz.com/settings/users
The endpoint being '/users'. Now, this is something which should not have been visible to the lower priority members. But when I logged in as a normal user and went to the exact same endpoint,
www.xyz.com/settings/users
I was able to view all the details i.e the email address, the name of Admins, their username etc. since the endpoint was not properly configured. Again, this was valid for every access control level i.e managers and team leaders.
2. Moreover, there were other endpoints such as to see the different scheduled meetings & other details related to the meeting, such as the terms and conditions, details of the meeting, the date, and the location, each of these was visible through the following page,
www.xyz.com/settings/meetings
So, as you might have guessed, I did the same thing as I did in the previous one, and browsed to the following page, via a lower priority member and I could see all the details of the different meetings
After some testing, I concluded that every feature inside the "/settings" page was not properly tested and was vulnerable to Broken Access Control.
The only downfall of this bug was I couldn't get WRITE privileges to those settings.
As a normal user, I could see the different users, their roles, and even the option to 'Delete' the different users, but it just didn't work out at the end.
The Response showed '403' Forbidden and that was it. After a lot of trying, I didn't get WRITE access and submitted the report as it is.
It was marked as 'High" after proper discussion within the team as a lot of details were being revealed. Though it would have been an altogether different case if one could get "WRITE" privileges there.
So, I think you must have got better knowing that only XSS & CSRF aren't everything. In applications like these, where you are provided with different kind of access level accounts, always try to look for these kinds of issues and if it's a BB, be ready for big $$$s (depending on impact) of course.
So, that's it. Hope you guys liked this post. I will keep posting about the different techniques I use during my testing, as we all know, # Sharing is Caring
Hit me up on Twitter(@Hackers_Guild) or in the comments section, if you have got any questions, regarding the post.
ARIGATO GOZAIMASU !!
The title seems somewhat catchy, but let me tell you the story how I got different sensitive details of a company via "Forced Browsing" on endpoints and how you can try to find the same kind of issues in Bug bounties or penetration testing.
So last week I was performing a penetration test for a certain company. Let's say the main application was www.xyz.com. The application was an organization basically and I was provided with all level of access. It had 5 layers of different access controls of which an Account-Admin had the highest privileges whereas a Normal user of the organization had the lowest privileges. Between these two there were 3 other privileged users such as Manager, Team Leader etc.
Now when you come across this kind of applications where there is a different kind of privileges, the first thing that comes in my mind is can I somehow READ or EDIT the details of a higher privileged user. XSS also comes in handy in this kind of situations(and I did get one to XSS the Account-Admin from user's account, the tale of which is in another blog post ;)).
So the first thing what I did was to log in with the highest privileges i.e. Account-Admin in one browser, whereas logging in with the lowest privileges i.e User in another browser. I went through all the functionalities one by one in both of them.
Let me tell you more about the application so you can feel how the testing looked like. We were provided with Account-Admin credentials from the client. The Account-Admin could then invite different people on the team via email address and assign Roles(like user or Team Leader) to them.
Now the one thing which caught my eye was there were certain things that were not present in the user account but were present in the Admin account(and of course, that's normal). The admin will always have access to extra functionalities. The first thing was the Settings. The Admin account had a Settings page, via which they can handle the different settings for the organization. This included the details of all the accounts in the organization such as users, Managers, team leaders with their mail addresses an option to edit their privileges or delete their accounts and so on. But the user account didn't have access to such kind of settings. Why the hell would a company want a normal user to see the details of the higher privileged users? Also, this application had an option to set up meetings on different dates, set the terms and conditions of the meetings and also to set the location of the meetings which was accessible to highest privileged users only. These all features were available to the Account-Admin only so he can see or edit them.
So here starts the main part(interesting part),
1. The Account-Admin could get the different details of the users via just browsing to the page, www.xyz.com/settings/users
The endpoint being '/users'. Now, this is something which should not have been visible to the lower priority members. But when I logged in as a normal user and went to the exact same endpoint,
www.xyz.com/settings/users
I was able to view all the details i.e the email address, the name of Admins, their username etc. since the endpoint was not properly configured. Again, this was valid for every access control level i.e managers and team leaders.
2. Moreover, there were other endpoints such as to see the different scheduled meetings & other details related to the meeting, such as the terms and conditions, details of the meeting, the date, and the location, each of these was visible through the following page,
www.xyz.com/settings/meetings
So, as you might have guessed, I did the same thing as I did in the previous one, and browsed to the following page, via a lower priority member and I could see all the details of the different meetings
After some testing, I concluded that every feature inside the "/settings" page was not properly tested and was vulnerable to Broken Access Control.
The only downfall of this bug was I couldn't get WRITE privileges to those settings.
As a normal user, I could see the different users, their roles, and even the option to 'Delete' the different users, but it just didn't work out at the end.
The Response showed '403' Forbidden and that was it. After a lot of trying, I didn't get WRITE access and submitted the report as it is.
It was marked as 'High" after proper discussion within the team as a lot of details were being revealed. Though it would have been an altogether different case if one could get "WRITE" privileges there.
So, I think you must have got better knowing that only XSS & CSRF aren't everything. In applications like these, where you are provided with different kind of access level accounts, always try to look for these kinds of issues and if it's a BB, be ready for big $$$s (depending on impact) of course.
So, that's it. Hope you guys liked this post. I will keep posting about the different techniques I use during my testing, as we all know, # Sharing is Caring
Hit me up on Twitter(@Hackers_Guild) or in the comments section, if you have got any questions, regarding the post.
ARIGATO GOZAIMASU !!
Comments
Post a Comment