Almost four months after disclosing a blind cross-site scripting (XSS) vulnerability to GoDaddy, researcher Matthew Bryant has published details on the vulnerability – because GoDaddy has finally fixed it.
Blind XSS flaws are so called because the researcher, pentester, or attacker doesn’t know when or where they might take effect. “To make a physical comparison,” writes Bryant, “blind XSS payloads act more like mines which lie dormant until someone triggers them.” This is because the payload is triggered and has effect in a different location to its delivery.
In this particular example, Bryant had noticed that his first and last names could be set on GoDaddy to an XSS payload. He entered his standard payload to both – and then forgot about them.
At a later date he contacted GoDaddy support in order to transfer one of his domains to a different registrar. Two things happened simultaneously: the GoDaddy support “appeared to be having trouble looking up my account due to their systems ‘experiencing issues’.”
At the same time, his mobile phone vibrated to indicate two emails in quick succession. These were notifications from XSS Hunter that his XSS payloads had been triggered – obviously by the support staff trying to access his account details. Although the payload was set in his account details, it was triggered and took effect on the web page used by the support staff.
This is a big deal, notes Bryant. Had he been an attacker, he could have performed any action available to the support staff, including modifying accounts, transferring domains or deleting the account altogether. “In a real attack scenario, the next step for exploitation would be to inject a proper BeEF hook into the agent’s browser to ride their session (using XSS Hunter’s JavaScript chainload functionality) and use the support website as them.”
Blind XSS flaws are easier to prevent during coding than to detect during testing. This is because they depend upon two flaws in different locations: one to enter the payload and another to trigger it. Independent pentester Robin Wood (DigiNinja) explains that he can test for blind XSS only where he gets access to both front and backend systems, “and can test directly by bouncing between the two.” Where he doesn’t get complete access, he explains to the client “what XSS is, and tell them to look out for unusual things happening in the admin suite or other areas while they are using.”
Wood also notes that there are other ‘blind’ attacks, “for example when input is batch processed at the end of the day and remote command execution attack that has been entered earlier gets triggered; or where SQL injection happens in a third party application caused by data that was originally intended to test the primary app.”
Some of these can be difficult to find because of the scope of work and the time available to the tester. “Data entered on the 1st of the month may not be processed till the month after, well after the test window has closed and the tester moved on to the next job.”
Fixing the flaws, he suggests, is relatively easy; but the time required will depend “on the processes the developers or admins have to go through and can take between hours and weeks and sometimes never happens at all.”
It took GoDaddy at least four months. We don’t know exactly how long because when Bryant reported it, he was told that GoDaddy already knew about it. The timeline he provides in his post indicates that it may have taken much longer had he not felt obliged, eventually, to threaten to go public.
On 11 April, he wrote to GoDaddy, “I’m moving my domains off of GoDaddy this week (since they could all be stolen/accessed using this issue) but for other GoDaddy users this is still outstanding critical issue that affects them. I’ve waited over three months so far for a fix so I feel giving this one more month until public disclosure takes place is fair.” Two weeks later it was fixed.
