Message-ID: <53D79FD8.6080002@fundacionsadosky.org.ar>
Date: Tue, 29 Jul 2014 10:21:28 -0300
From: Programa STIC <stic@...dacionsadosky.org.ar>
To: fulldisclosure@...lists.org
Subject: [FD] Vulnerabilities in Facebook and Facebook Messenger for Android
	[STIC-2014-0529]

Security advisory of Programa STIC at Fundación Dr. Manuel Sadosky
                    www.fundacionsadosky.org.ar

Vulnerabilities in Facebook and Facebook Messenger for Android

1. *Advisory Information*

Title: Vulnerabilities in Facebook and Facebook Messenger for Android
Advisory ID: STIC-2014-0529
Advisory URL: http://www.fundacionsadosky.org.ar/publicaciones
Date published: 2014-07-28
Date of last update: 2014-07-28
Vendors contacted: Facebook Inc. (NASDAQ:FB)
Release mode: Coordinated release


2. *Vulnerability Information*

Class: Information Exposure Through Sent Data [CWE-201], Information
Exposure Through Sent Data [CWE-201], Unintended Proxy or Intermediary
[CWE-441]
Impact: Denial of service, Data loss
Remotely Exploitable: Yes
Locally Exploitable: Yes
CVE Name: CVE-2014-NNNNY, CVE-2014-NNNNX, CVE-2014-NNNNZ

3. *Open proxy in Facebook application for Android*

  [CVE-2014-NNNNZ]

  According to Facebook's published financial results for the second
quarter of 2014, as of June 30th the company had 1.07 billion mobile
active users and an average of 654 million mobile daily active users[1].
The Facebook application for Android is among the top 10 most installed
Android applications worldwide with 500 to 1,000 million installations
as of June 24th, 2014[3].

  The application embeds a generic HTTP server component that is used as
a caching proxy for playing video recordings. This server is
misconfigured and accepts requests from any client, local or remote,
allowing attackers to connect to it and use a victim's device as an open
proxy. As a results, among other things, an attacker could carry out
various forms of denial of service attacks such as filling up the
device's storage or running up the subscriber's data transfer limit over
3G or LTE networks.

4. *Disclosure of private video content in Facebook application for Android*

  [CVE-2014-NNNNX]

  The application allows users to upload video to Facebook and configure
who should be able to play it back (publicly accessible, friends only,
oneself, custom list). The application also allows users to playback
video on the Android device. Viewing video content marked by the user as
private is prevented by Facebook in accordance to the company's privacy
policy [2] if the connecting client is a web browser. However, if the
user connects to Facebook using the Android application the
confidentiality of private video and audio content is not enforced.

  The application retrieves video content for playback in an insecure
manner, allowing anyone with access to the same network where the
Android device is connected or to any network in the path between the
device and Facebook's Content Delivery Network to capture or retrieve
video content disregarding the user's configured access policy and
bypassing Facebook's privacy policy.

5. *Disclosure of audio recordings in chat messages in Facebook and
Facebook Messenger for Android*

  [CVE-2014-NNNNY]

  The Facebook Messenger application is also among the top 10 most
installed Android applications worldwide with 500 to 1000 million
installs [4] . Both Facebook and Facebook Messenger applications allow
users to send and playback audio recordings as messages within a chat
session. Transmission of the audio content is done using an insecure
network protocol, allowing anyone with access to the same network where
the Android device is connected or to any network in the path between
the device and Facebook's Content Delivery Network to capture or
retrieve chat audio recordings bypassing Facebook's privacy policy.

6. *Video Cache Server vulnerability: Vulnerable packages*

  . Facebook Android application older than version 13.0.0.13.14

7. *Video vulnerability: Vulnerable packages*

  . Facebook Android application older than version 10.0.0.28.27 up
until June 11th, 2014.

8. *Audio vulnerability: Vulnerable packages*

  . Facebook Android application older than version 10.0.0.28.27

  . Facebook Messenger Android application older than version 5.0.0.25.1

9. *Vendor Information, Solutions and Workarounds*

    Facebook acknowledged and corrected all three vulnerabilities.
According to the company, the audio recording issue was already known
and a fix was being beta tested at the time the bug was originally
reported. The company released new application updates that fix both
audio and video vulnerabilities.
    The fix to the disclosure of audio recordings required a new
application update. The fix to the video disclosure vulnerability works
with current and prior versions of the application that support
retrieval of video from the CDN using HTTPS.

    Facebook's new update to version 13.0.0.13.14 fixed the open proxy
issue by configuring the video cache server to listen only to local
requests.

    To determine which version of the applications you have installed on
your Android device, go to "Settings|application settings|manage
application" then tap on the Facebook or Facebook Messenger app.

10. *Credits*

    This vulnerability was discovered and researched by Joaquín Manuel
Rinaudo.
    The publication of this advisory was coordinated by Programa
Seguridad en TIC.

11. *Technical Description*

    Facebook uses an HTTP server as caching proxy for media content. The
server is hosted in the mobile application's process space and listens
on a local non-fixed ephemeral TCP port. The constructor of the class
'com.facebook.video.server.VideoServerBase' embedded in the Facebook
application instantiates this GenericHttpServer object. The created
instance listens to requests from any client, local or remote, enabling
an attacker to perform requests to third party servers through it.

    The server accepts three types of GET requests: '/proxy',
'/cache-window' and '/cache-thru'. The parameters for these requests are
''remote-uri'' whose value is an URL and a ''vid'' identifier. Upon
receiving a request, the server performs a HEAD request to the
''remote-uri' ' URL to obtain the 'content-length' of the resource, it
then obtains the requested resource with a series of GET requests until
the previously declared content-length is reached. Any redirect response
to the HEAD request is followed by a GET request to the redirected location.

    While the 'proxy' request will simply forward the content to the
server's client, the 'cache-thru' and 'cache-window' requests indicate
the server to not only forward the content to the client but also to
store a copy on the phone internal memory under
'data/data/com.facebook.katana/files/video-cache'.

    An attacker could use a victim's mobile with the Facebook app
installed as an open proxy by querying the embedded HTTP server for
'/proxy' and passing as a parameter a shortened URL that points to any
arbitrarily selected target site. Since all redirects are followed, an
attacker could use a shortened URL, obtained from a site like 'goo.gl',
as the target site parameter so the proxy works on all sites. She can
also cause the phone to run out of internal storage by simply querying
'/cache-thru' with a ''remote-uri'' set to a site containing a large
file. The same can be done for running up the subscriber's data transfer
limit over 3G, LTE networks.

    To reproduce the vulnerability follow these steps:

    1) Connect with adb shell to a device running Facebook and run
netstat to find out the listening port

    2) From a device in the same network run 'telnet [Phone IP]
[listening port]' and enter the following request:

    'GET
/cache-thru?remote-uri=https%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3Dz9Uz1icjwrM&vid=a
HTTP/1.1'

    3) The phone queries the link with a HEAD request which youtube
servers will respond with a 302 redirect to 'm.youtube.com'. The victim
then queries m.youtube.com and downloads the video content to the
phone's internal memory cache and forwards it to the client that
requested it over the telnet connection.

    Videos hosted on the Facebook CDN network are obtained via HTTP.
When a user requests playback of a video hosted on Facebook an instance
of the VideoServerBase class performs a request to an instance of the
GenericHTTPServer class with a parameter of /caching-thru with its value
set to the URI of the video to retrieve from the CDN. Since the URI
scheme is HTTP, the caching proxy requests to download the content are
performed over an insecure transport.

    Anyone with access to the local network of the Android device or to
any network in the path between the device and Facebook's CDN can obtain
the URL and video content by capturing network packets or can retrieve
the video content directly from Facebook's CDN once the URL is known.

    Steps to reproduce the vulnerability:

    1) Download and install Facebook application.

    2) Login to Facebook using any account (we will call it "account A").

    3) Using a web browser login to Facebook using a separate account
("account B"), post a video and allow access to it just to accounts A
and B.

    4) Using the Facebook application for Android logged in using
account A let the video status load but do not yet play the video.

    5) Set a proxy for the Android phone. This will make all HTTPS
requests stop working but they are not needed to reproduce the
vulnerability.

    6) Click on the video and let it play.

    7) Copy the URL in the GET request obtained from the proxy (this
emulates an attacker sniffing the network) and paste it in a web browser
to watch the video without any authentication.

    The third vulnerability involves audio recordings sent from one
Facebook user to another user through chat on both Facebook and Facebook
Messenger applications. The sender's application uploads the audio
recording using an HTTPS POST request to 'graph.facebook.com' and then a
HTPPS GET request to 'api.facebook.com/method/messaging.getAttachment'
that is responded with a redirect to the actual content at
'attachment.fbsbx.com'. Although the initial POST and GET requests are
sent over HTTPS and authenticated using the user's OAuth access token,
the redirect response to retrieve the audio content is obtained over
HTTP. Likewise, the receiver's application downloads the audio recording
using an HTTPS GET request to 'api.facebook.com/method/getAttachment'
that is responded with a redirect with a URL to the actual audio content
on 'attachment.fbsbx.com' over HTTP. The uid parameter in both requests
indicate the Facebook IDs of sender and receiver, respectively.

    This vulnerability was found in the
'com.facebook.ui.media.fetch.MediaRedirectHandler' class in method
'getLocationURI' in packages previous to version 10.0.28.27 . This
method calls a private method that translates the URI scheme from HTTPS
to HTTP for any request redirected to domain 'attachment.fbsbx.com'.

    As a result of the above, an attacker access to the same network
where the Android device is connected or to any network in the path
between the device and the 'attachment.fbsbx.com' network can capture or
retrieve chat audio recordings bypassing Facebook's privacy policy.

    Steps to reproduce the disclosure of audio recordings vulnerability

    1) Login to Facebook using the Facebook application for Android.

    2) Capture network packets using any network sniffing tool (e.g.
wireshark).

    3) Within the Facebook app open a chat window and send a recording.

    4) Find the GET request to 'attachment.fbsbx.com' in the captured
traffic. Use any web browser to open the specified URL to obtain the
recording.

12. *Report Timeline*

. 2014-05-13:

  The researcher sent a technical description of the vulnerabilities to
the vendor.

. 2014-05-13:

  The vendor acknowledged the audio recording vulnerability and said it
was fixed a month ago,that the fixed app is only available to beta users
and that an app update will be released in the near future.

. 2014-05-19:

  The vendor acknowledged the video vulnerability and requested
information about the device used for the tests.

. 2014-05-19:

  The researcher sent the requested information to the vendor.

. 2014-05-29:

  The researcher requested an status update and informed the vendor that
the Programa Seguridad en TIC plan to release a security advisory to
notify affected users about the issues and provide guidance to apply
fixes. He asked the vendor to continue the communication over email
rather than using Facebook's vulnerability reporting system since the
latter requires researcher and coordinator to have a Facebook account.


. 2014-06-04:

  Facebook communicated with Programa Seguridad en TIC  via email.
Programa Seguridad en TIC set June 18th as publication date for the
security advisory and indicated that there is evidence of very similar
vulnerabilities being actively exploited by third parties to collect
media content deemed private by Facebook users.

. 2014-06-05:

  Facebook asked for evidence of active exploitation and assured that a
fix for the recording vulnerability was already being rolled out before
the report was sent.

. 2014-06-06:

  Programa Seguridad en TIC send a reference [5] to NSA presentation
slides 82-87 leaked by Glenn Greenwald about network traffic capture
activities to obtain Facebook images hosted in Akamai servers.

. 2014-06-12:

  A new update for the Facebook application was released. The researcher
analyzed the new application and found that vulnerabilities 2 and 3 were
fixed.

. 2014-06-14:

  Facebook informed the researcher that the video and audio
vulnerabilities had been patched and asked for the researcher's
confirmation.

. 2014-06-16:

  The researcher acknowledged that both vulnerabilities were fixed.
Programa Seguridad en TIC Asked about the open proxy pending issue.

. 2014-06-16:

  Facebook requests proof-of-concept code or steps to reproduce the open
proxy issue.

. 2014-06-16:

  Steps to reproduce sent to Facebook by Joaquín Manuel Rinaudo.

. 2014-06-16:

  Draft of the advisory sent to The MITRE Corporation requesting
assignment of CVE identifiers for the audio and video vulnerabilities.

. 2014-06-20:

  Response from Mitre saying none of the two vulnerabilities meet the
CVE inclusion criteria and therefore CVE identifiers will not be
assigned.

. 2014-06-22:

  Programa Seguridad en TIC asks for an update about the open proxy
issue.

. 2014-06-23:

  Reply from Facebook security saying its working with the team and will
be in touch when there is information to share.

. 2014-06-24:

  Email to Mitre requesting a CVE identifier to be assigned for the
third bug (open proxy) and providing additional details and opinion
about how the other two meet the CVE inclusion criteria.

. 2014-07-01:

  Facebook sent a new confirmation of working on the fix for open proxy
issue.

. 2014-07-02:

  Programa Seguridad en TIC expressed to Facebook its concern about
elapsed time since the original report and asked why a simple fix is
taking so long.

. 2014-07-02:

  Facebook replied that it is actively working on addressing the issue.

. 2014-07-03:

  Email to Mitre asking if they have a decision on use of CVE
identifiers in light of the additional details about the vulnerabilities
provided in the previous email.

. 2014-07-08:

  The researcher reminded Facebook that the advisory was originally
scheduled for publication on June 18 and that no estimated date for the
fix to open proxy issue was provided, so a new publication date was set
for July 16, 2014 and should be considered final. Programa Seguridad en
TIC remains willing to move the date on basis of receiving concrete and
detailed information about plans to fix the open proxy issue.

. 2014-07-08:

  Email to Mitre asking again for a response to the request for CVE
identifiers.

. 2014-07-09:

  Facebook asked to hold off the publication a week further, assuring
that the fix would be up by then.

. 2014-07-11:

  Programa Seguridad en TIC moved the release date to July 23, 2014 as
the final date.

. 2014-07-11:

  Facebook informed that the patch was already released in the beta
version of Android.

. 2014-07-11:

  The researcher acknowledged that the open proxy vulnerability is fixed
in the beta version.

. 2014-07-16:

  Email to Mitre indicating no response was received to the prior email
asking for a decision regarding the assignment of CVE identifiers and
asking for a response within 48 hours  since all the bugs have been
fixed and the update is available to vulnerable users. Publication of
the security advisory is imminent.

. 2014-07-17:

  Email from Mitre stating that CVE assignment group does not have a
final conclusion about whether the reported vulnerabilities fit the
inclusion criteria and recommending public disclosure without CVE IDs.
The original bug descriptions and additional explanations were reviewed
by the staff several times but a final conclusion was not reached. CVE
assignment group feels that the "research observations occupy a boundary
between site-specific and customer-controlled software that can be the
subject of extensive debate".

. 2014-07-21:

  Facebook informed that an application update was available to 5 % of
the users.

. 2014-07-21:

  The vendor informed that the update was available to 50% of the users.

. 2014-07-21:

  The vendor informed that the update was available to 100 % of the users.

. 2014-07-22:

  Programa Seguridad en TIC asked if the figures provided by Facebook
correspond to availability or actual installations of the update.

. 2014-07-22:

  The vendor replied that percentage figures correspond to availability
not actual installations.

. 2014-07-28:

  The advisory was released.

13. *References*

[1] http://investor.fb.com/releasedetail.cfm?ReleaseID=861599
[2] https://www.facebook.com/note.php?note_id=%20322194465300
[3] https://play.google.com/store/apps/details?id=com.facebook.orca
[4] https://play.google.com/store/apps/details?id=com.facebook.katana
[5]
http://hbpub.vo.llnwd.net/o16/video/olmk/holt/greenwald/NoPlaceToHide-Documents-Compressed.pdf

14. *About Fundación Dr. Manuel Sadosky*

  The Dr. Manuel Sadosky Foundation is a mixed (public / private)
institution whose goal is to promote stronger and closer interaction
between industry and the scientific-technological system in all aspects
related to Information and Communications Technology (ICT). The
Foundation was formally created by a Presidential Decree in 2009. Its
Chairman is the Minister of Science, Technology, and Productive
Innovation of Argentina; and the Vice-chairmen are the chairmen of the
country’s most important ICT chambers: The Software and Computer
Services Chamber (CESSI) and the Argentine Computing and
Telecommunications Chamber (CICOMRA).

  For more information visit: http://www.fundacionsadosky.org.ar

15. *Copyright Notice*

  The contents of this advisory are copyright  (c) 2014 Fundación
Sadosky and are licensed under a Creative Commons Attribution
Non-Commercial Share-Alike 4.0 License:
  http://creativecommons.org/licenses/by-nc-sa/4.0/


_______________________________________________
Sent through the Full Disclosure mailing list
http://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists