Response Manipulation to Account Takeover
Hello Everyone here is my another blog for Account Takeover which I Discovered back in November 2019 on a Hackerone Private Program.
I have already reported 3–4 bugs to this program but only 2 got rewarded and another one got Informative so I moved further to discover more and I always try to get any instance where I could get into someonelse’s account. For this I just focused on the Login Request and Response because most of the Vulnerabilities exist’s on the Login page itself like Oauth Misconfiguration, Open Redirect, SQL injection to Login Bypass and so on.
The main motto of this blog is pointed towards the Response part which can be manipulated by the BurpSuite using the do intercept the Response for a particular Request.
Getting started with it, I started my trial and error method to find all the possible Vulnerabilities which can be obtained by observing the results. The web application was having React framework for Javascript so it was pretty hard to pop an XSS on the web application. So I moved on to the web application to discover some logical bugs or Information Disclosure through IDOR since it was having GraphQL to query the requests. But after so many attempts I failed to discover any Vulnerability in the GraphQL endpoints may be it was much more secured. So I just Logged of for that day after so many tries.
The next day I started again from the beginning and just focused on all the Requests that was going through the Burp History, and hopefully I noticed the Login Request and Response which was having only some Numeric and one alphanumeric values. Later I just replayed the Login from the browser multiple times and analyzed each Response, the only thing which clicked in my mind was to try to Manipulate the Response and see if it takes me to the another users Account, for this I have created 2 Accounts and just copied the disimilar values and manipulated the Response and later when I Forwarded the manipulated response I was into the other User Account.
Simple Proof of Concept:-
The Login response was having 2 different parameters which was reflected when a valid credentials where provided to the web application. You can see the same in the given image.
Blue circle part: Publically Available (Static)
Green circle part: Only available when the user is Logged in, So it requires an XSS to be executed to get this value. (Static)
Red circle part: Vulnerable endpoint, it is generated by only when a valid credentials are provided. (Dynamic)
Here in the above image you are able to see one session parameter which is always static and the value in it is a combination of user_id(publically available) and a secret_id in the format user_id:secret_id. Next in the Json body you can see the oauth_accesstoken which includes 3 parts where it has one static value which can be obtained through an XSS and the other value which is Dynamic which can be generated by providing a valid credentials.
When an Attacker uses his own credentials and logs in he will intercept the Login Request and do intercept the response to the Login Request and edit the session and oauth_token value with the victims values by presumming that the attacker has successfully gained the green circle data from the victim by XSS or any other Social Engineering attacks. Thus the attacker gets logged in to the Victim Account through this way because there was no Validation of the Token generated by attacker on the server side. The server was only validating that the generated token is true or not.
For every successful login a random token was generated for that session which was dynamic on every Login, so here the attacker has created a true session by providing his own credentials and later he just manipulated the response with the static values! Thus the attacker is able to create a session on behalf of the Victim by just knowing the green circle values and takeover the whole Account.
I reported the same on Hackerone and the staff had replied with the need mode Information and asked me to provide a working exploit to support my Report, and after so many attempts I could not discover any exploit(XSS) to support the bug and after 2 months when I tried looking for the same I noticed that the whole Login workflow has been updated, thus the Program has patched this Misconfiguration.
Hope you may have Liked it!
Stay updated with me on Twitter for more interesting blogs.
Thank you for reading.
