This is the journey detailing how my name was added to humans.txt for scoring my first bug bounty, a severity 2 one at that! Im writing this as i’ve always personally been interested in how people discover security vulnerabilities. Furthermore, vulnerability itself is incredibly easy to exploit, details can be found at the end of this article. (pls scroll slowly so I can rake in some partner program earnings)
Back story
I was originally going to write an article describing testing I conducted in an attempt to figure out how much of the $5 monthly fee is given to writers through the Medium partner program. I had planned to test out different interactions which I thought might affect a writer’s compensation. Such as reading the article for different amounts of time and seeing if interacting with the article (through means such as: highlighting text, clapping) would affect the writer’s compensation. Since I am on a shoestring budget I only wanted to pay for a single “control” account to do all my testing from. I originally had 20+ different scenarios I intended to test and could only test a single one per day as Medium Partner Program earnings are calculated daily, I was looking for ways to automate the process. Thus, I went exploring through the chrome developer tools to analyze how data is transmitted back to medium.com to see if it was possible to automate some of my tests.
I began by one by one blocking requests to certain url paths that I believed could be transmitting the metrics used to calculate my partner program earnings. After a lot of trial and error I discovered that it was requests to medium.com/_/batch that was transmitting all the data used to calculate my partner program earnings.
a screenshot of some of the data transmitted back to medium HQ through /_/batch endpoint
I didn’t have any way of figuring out what a lot of the data transmitted back to the medium.com/_/batch endpoint represents, I had at the time planned to perform a replay attack of the requests made to this endpoint only modifying timestamp data to make it relevant to the time the replay attack is launched (which could be days after I initially captured all the requests made to this endpoint).
Since I didn’t want to copy-paste all my cookies into the python script I was writing to preform my replay attack. I tried clearing my browser of all cookies after loading the webpage, Without any of the cookies present and being transmitted to medium.com/_/batch I was still able to generate partner program earnings. I then attempted to analyze the request JSON data to see if I could simply generate all the post request data required for a session of an arbitrary duration at once (essentially a whole bunch of page scroll events) and transmit it all in one go to your JSON endpoint medium.com/_/batch. (this would have allowed me to automate testing sessions of different lengths). That, unfortunately, did not work.
I originally believed that it was because the server was likely validating transmission time to stop someone from potentially creating partner program earnings for a writer for a period of time that they were not a member, say months in the future or past. But after some more experimentation (with requests sent at the correct timing and different payloads) I believe that the most probable explanation of why this didn’t work is that the eventID in the JSON payload is some sort of hash containing the UserID and the date of the page view as there does appear to be a pattern in EventIDs as the first 4 letters of the ID appear to be the same for requests from the same UserID and day. Due to code obfuscation, I was unable to figure out exactly how these userIDs are generated.
#bug-bounty #partner-program #web-development #hacking
