Domain registrar GoDaddy fixed a vulnerability affecting systems used by its customer support agents that could have been abused to take over, modify or delete accounts.
Researcher Matthew Bryant said that a riff on a cross-site scripting attack called a blind XSS was to blame. A GoDaddy customer, Bryant wrote on Sunday on his blog that Name fields on a particular GoDaddy page accepted and stored a cross-site scripting payload. He left a generic payload behind, akin to leaving a mine that isn’t triggered until someone steps on it.
As it turns out, no one stepped on the mine until Bryant needed to make a legitimate support call to GoDaddy. The rep on the phone could not access his account, and at the same time Bryant was getting email alerts that his almost-forgotten payloads had fired.
Bryant dug into the issue, which he privately disclosed to GoDaddy in December, and found that his attack had fired outside of his browser. Pen-testers, he said, often miss these types of attacks because an attacker can drop these payloads throughout a site and wait for them to be triggered. If there aren’t proper notifications set up aside from the traditional dialogue box, a pen-tester will be left in the dark and often miss this class of XSS flaws.
“The more you test for blind XSS the more you realize the game is about ‘poisoning’ the data stores that applications read from. For example, a users database is likely read by more than just the main web application. There is likely log viewing apps, administrative panels, and data analytics services which all draw from the same end storage,” Bryant wrote. “All of these services are just as likely to be vulnerable to XSS if not more because they are often not as polished as the final web service that the end customer uses.”
In this case, GoDaddy’s internal support panel was vulnerable to the cross-site scripting attack, and Bryant’s payload had broken the page. The support application, he said, grabbed the payload from a shared database and reflected it into the page. Bryant said the main GoDaddy page where he dropped the payload “safely encoded the input,” but the shared data source allowed the vulnerability to traverse services, he said.
“I would say it’s pretty critical,” Bryant told Threatpost. “You can take over a support agent’s page and use that to access other accounts. If you use it maliciously, you can perform actions on any GoDaddy account, like making modifications to domain names. That’s why it’s pretty scary. If you’re a big company with GoDaddy, you can have your account modified and potentially cause outages.”
Bryant said he used a tool he built called XSS Hunter that sniffs out cross-site scripting flaws, including blind XSS. The tool injects payloads onto a vulnerable page and notifies when they fire.
Bryant said GoDaddy fixed the issue properly, but not necessarily in a timely fashion. A timeline published on his blog shows that he emailed a bug report Dec. 29 and a day later was invited to join GoDaddy’s private bug bounty. In February, GoDaddy informed him this was a duplicate issue, and that his finding was out of scope for the bounty. After three months had passed and the issue had likely been present far longer, Bryant requested public disclosure. GoDaddy, because of the severity of the bug, asked that Bryant not go public until a fix was made. Another exchange on April 13 resulted in GoDaddy escalating the issue before it was finally fixed April 25. Bryant confirmed the fix two days later and disclosed on Sunday.
Bryant said that output encoding is one way to fix this issue, but it’s much safer to prevent the storage of payloads.
“If you simply ensure that the stored data is clean you can prevent exploitation of many systems because the payload would never be able to be stored in the first place. Obviously, ideally you would have both, but for companies with many services drawing from the same data sources you can get a lot of win with just a little filtering,” Bryant said. “This is the approach that GoDaddy took for remediation, likely for the same reasons.”
