Oct 11, 2024 12:58:14 PM | 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 beleveraged by an attacker through a 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 (https://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 operations, 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 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 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
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

Written By: Christopher Emerson