A Journey from Automated Discovery to Manual Exploitation
Unveiling Vulnerabilities in an Appointment Booking System: A Journey from Automated Discovery to Manual Exploitation
Last updated
Unveiling Vulnerabilities in an Appointment Booking System: A Journey from Automated Discovery to Manual Exploitation
Last updated
Commencing the bug bounty journey, a list of potential targets was compiled. The selection of these targets was largely driven by their digital footprints archived in the Wayback Machine. Each target's historical data was funneled through the waybackurls tool, setting the stage for the next steps in this intriguing expedition.
Post target selection, the next stage was to automate the pattern identification process. The mechanism was set up to identify common patterns, track base64 encoded mails, and build specific tools to streamline the process further.
Find more details here : https://github.com/tomnomnom/gf
Or let's say I just used the following regex :
The initial payoff was the identification of a target leaking personally identifiable information (PII) through GET parameters. Upon extracting the URLs for these targets, a recurring pattern became evident. A specific URL containing a SessionID parameter surfaced repetitively, suggesting that a potential vulnerability may be lurking beneath.
The targeted system turned out to be an appointment booking platform. It had a feature allowing guests to schedule appointments with the site's users. Instead of implementing a standard session management protocol using cookies, the system was relying on GET parameters as session tokens to allow users to manage appointments.
The investigation went further manual. By creating a service to engage with the application from the appointment managers side, it was found that the application was constructed using PHP, a promising ground to test for SQL Injection and XSS attacks.
Simulating the appointment managers interaction brought to light some default fields like name, phone, and notes associated with the guests. While the XSS payload embedded in the notes field resulted in an XSS report marked as duplicate, an interesting anomaly was spotted. Injecting an XSS payload without any spaces, into the phone number field, resulted in a valid XSS report, indicating that the prior researcher had possibly overlooked this aspect.
XSS in a File upload Function
The next step was to enable additional input fields for the guests to test. Here, a file upload field came into view that enabled guests to transmit files to the appointment manager. This upload mechanism used a third-party(cloud storage) service to process the file and return its URL to guest and store it in a request parameter.
As a guest, an attempt to upload a file via the standard process led to an interesting discovery. The file's URL was reflected on the admin site, and upon embedding an XSS payload into this URL, another XSS vulnerability was unearthed. Unlike the prior XSS report, this was a more severe issue as it needed no elevated privileges to exploit, posing a significant security threat.
The url was being used in href attribute so the following payloads as url would work
To sum up,This experience underscores the importance of systematic analysis, persistent probing, and an open mind to anticipate the unexpected when delving into bug bounty hunting.
