Oh no, you're thinking, yet another cookie pop-up. Well, sorry, it's the law. We measure how many people read us, and ensure you see relevant ads, by storing cookies on your device. If you're cool with that, hit “Accept all Cookies”. For more info and to customize your settings, hit “Customize Settings”.

Review and manage your consent

Here's an overview of our use of cookies, similar technologies and how to manage them. You can also change your choices at any time, by hitting the “Your Consent Options” link on the site's footer.

Manage Cookie Preferences
  • These cookies are strictly necessary so that you can navigate the site as normal and use all features. Without these cookies we cannot provide you with the service that you expect.

  • These cookies are used to make advertising messages more relevant to you. They perform functions like preventing the same ad from continuously reappearing, ensuring that ads are properly displayed for advertisers, and in some cases selecting advertisements that are based on your interests.

  • These cookies collect information in aggregate form to help us understand how our websites are being used. They allow us to count visits and traffic sources so that we can measure and improve the performance of our sites. If people say no to these cookies, we do not know how many people have visited and we cannot monitor performance.

See also our Cookie policy and Privacy policy.

This article is more than 1 year old

GoDaddy plugs account hijack XSS vulnerability

Forgotten payload borks support call

Domain registrar GoDaddy has patched a blind XSS vulnerability in its customer support that could have allowed access to GoDaddy accounts.

Uber security man Matthew Bryant (@IAmMandatory) reported in a personal capacity the bug he says was located in an internal support panel.

A payload he uploaded and then forgotten had fired during a legitimate support call he placed to GoDaddy, as the officer attempted to remediate his problem.

The payload was insecurely reflected onto a support page, breaking it.

"While using GoDaddy I noticed that my first and last name could be set to an XSS payload," Bryant says.

"It was then (during the call) my phone vibrated twice indicating … notifications that my previously planted XSS payloads had fired.

"... my XSS payload borked the JSON displayed in the webpage body and escaped the script type="text/javascript block [which] caused the XSS payload to fire but broke the webpage that the support agent was viewing."

Bryant says the vulnerability meant an attacker could run any action that a GoDaddy customer rep could in what could have caused mayhem for customer accounts.

It took GoDaddy about four months to fix the hole after it brought Bryant into its private bug bounty program, and then claimed the vulnerability was a duplicate.

To make a physical comparison, blind XSS payloads act more like mines which lie dormant until someone triggers them.

Bryant says the vulnerability class is missed often in security tests.

"This flavour of XSS is often missed by penetration testers due to the standard alert box approach being a limited methodology for finding these vulnerabilities," he says. "When your payloads are all script>alert(1)</script you’re making the assumption that the XSS will fire in your browser, when it’s likely it will fire in other places and in other browsers."

Bryant recommends preventing payloads from being stored which goes beyond typical XSS remediation and affords improved security.

"When you do proper output encoding, you have to do it on every system which pulls data from your data store. However, 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."

The bug is one of a series the hacker will post to his blog after respective vendors have applied fixes. ®

 

Similar topics

TIP US OFF

Send us news


Other stories you might like