# Leaky Error Messages There were several vulnerabilities in this attack, including insecure APIs, and error messages that leaked the very thing they were meant to guard! To delete files, I needed just the `userid` and `accountid`. Given then the `userid` is only 4 alphanumeric characters, it was easy to bruteforce it. Getting the `accountid` was much harder, and I only found a leak after fuzzing multiple API endpoints. I eventually found an API that would have never been called during the normal flow of the application, and it leaked the `accountid` when trying to access a `userid` that was not mine. Below is the redacted and modified report that was accepted as a high severity vulnerability. ### Summary: This attack is a combination of various weaknesses 1. Information leakage through error messages 2. Unauthorized file access 3. Unauthorized file deletion Working backwards: To delete a file, the attacker can delete any files through `https:///delete?fileid=xxx` To get a valid `fileid`, the attacker can access `https:///get?userid=xxx&accountid=yyy` To get a valid `userid`and `accountid` combination, the attacker send a `POST` request to `https:///accounts/showInfo`, which when given a `userid`that is not yours, leaks the `accountid`through an error message ### Steps To Reproduce: This attack requires you to create and login to an account created at `https://` 1. Generate all possible `partnerId` using crunch ``` $ crunch 3 4 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ -o possibleUserIds Crunch will now generate the following amount of data: 8398080 bytes 8 MB 0 GB 0 TB 0 PB Crunch will now generate the following number of lines: 1679616 ``` 1. Login to the application as a normal user 2. Enumerate `https:///accounts/showInfo` with the `userid`values 3. When passing in a `userid` that is not yours, the error message leaks the error message by saying `Insufficient permissions for accountid xxx` 4. Using that info, we now have a valid `userid` and `accountid` combination 5. Using this combination, we can access the files via `https:///get?userid=xxx&accountid=yyy`to get a valid `fileid` 6. Now that we have the `fileid`, we can delete the files via `https:///delete?fileid=xxx` ### Impact Given that we can access all possible `userid`, we can also pull out all their related `accountid`via the error message Using these two values, we can thus access all user uploaded files, and even worse, we can delete all user uploaded files. This is caused by unauthorized file access and file deletion of files that is not owned you. This violates Confidentiality when the files are leaked, and Availability, as the files that are uploaded can be deleted by the attacker. It does not violate Integrity because the files cannot be modified, nor can the attacker upload files to the victim namespace. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://sheepwall.gitbook.io/home/bug-bounties/leaky-error-messages.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.