Twenty Year Anniversary

Facebook For Android Crash

Facebook For Android Crash
Posted Jul 10, 2018
Authored by Yakov Shafranovich | Site wwws.nightwatchcybersecurity.com

Facebook Messenger for Android can be crashed via the application's status check. This can be exploited by an MITM attacker via intercepting that call and returning a large amount of data. This happens because this status check is not done over SSL and the application did not contain logic for checking if the returned data is very large.

tags | advisory, denial of service
MD5 | 3045573e4f0dc2fe7e1d4354cec82c67

Facebook For Android Crash

Change Mirror Download
[Original post here:
https://wwws.nightwatchcybersecurity.com/2018/07/09/advisory-crashing-facebook-messenger-for-android-with-an-mitm-attack/]

SUMMARY

Facebook Messenger for Android can be crashed via the applicationas
status check. This can be exploited by an MITM attacker via
intercepting that call and returning a large amount of data. This
happens because this status check is not done over SSL and the
application did not contain logic for checking if the returned data is
very large.

The vendor has no immediate plans to fix this issue.

VULNERABILITY DETAILS

Facebook Messenger for Android is a messaging application provided by
Facebook. While monitoring network traffic of a test device running
Android, we observed that the application made network calls for
checking server status. This call was done over HTTP without the use
of SSL / TLS. Example URL:

http://portal.fb.com/mobile/status.php

We were successful in crashing the application by injecting a large
packet because the application doesnat handle large data coming back
correctly and doesnat use SSL for this call.

It is also important to note this would allow someone to block
Messenger from being used but without the users realizing they are
being blocked, since they will attribute the app crashing to a bug
rather than a block.

STEPS TO REPLICATE (on Ubuntu 18.04)

1. Install the application on the Android device.
2. Install dnsmasq and NGINX on the Linux host:
sudo apt-get install dnsmasq nginx

3. Modify the /etc/hosts file to add the following entry to map PIAas
domain name to the Linux host:
192.168.1.x portal.fb.com

4. Configure /etc/dnsmasq.conf file to listen on the IP and restart DNSMASQ
listen-address=192.168.1.x
sudo /etc/init.d/dnsmasq restart

5. Use mkdir and fallocate to create a large server file in
a/var/www/html/a (you may need to use sudo):
cd /var/www/html
mkdir mobile
cd mobile
fallocate -l 2.5G status.php

6. Setup a WiFi access point and set the DNS server setting on the
access point to the Linux computer (a192.168.1.xa)

6. Connect the test device to the access point a Android will resolve
now DNS against the Linux computer.

7. Re-open the app and try to activate with a phone number. Observe
the crash a note that the application and launcher crashes but not the
device itself

All testing was done on v169.0.0.27.76 of the Android application
using a Linux host running Ubuntu v18.04 and Android test devices
running Android v7 and v8.1.

VENDOR RESPONSE

The vendor doesnat consider this to be a security issue and doesnat
have immediate plans to fix it:

"After talking to the product team, weave determined that the crash is
due to OOM and the security risk here is not significant enough to
qualify for a bounty. The impact here is a denial of service on very
specific users on the attackeras wifi network, which arguably can be
done via other local network attacks which we ultimately cannot
control. While we agree that this is a software bug and we may
consider making changes in the future to prevent this behavior, this
issue does not qualify as a part of our bounty program."

REFERENCES

CVE-ID: no CVE assigned
CWE: CWE-400 a Uncontrolled Resource Consumption (aResource Exhaustiona)

CREDITS

Text of the advisory written by Yakov Shafranovich.

TIMELINE

2018-06-05: Initial email to the vendor as part of another issue; POC sent
2018-06-12: Initial report triaged by vendor and sent to product team
2018-06-20: Vendor response received
2018-06-25: Draft advisory provided to vendor for review
2018-07-09: Public disclosure


Comments

RSS Feed Subscribe to this comment feed

No comments yet, be the first!

Login or Register to post a comment

File Archive:

December 2018

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Dec 1st
    11 Files
  • 2
    Dec 2nd
    1 Files
  • 3
    Dec 3rd
    18 Files
  • 4
    Dec 4th
    40 Files
  • 5
    Dec 5th
    16 Files
  • 6
    Dec 6th
    50 Files
  • 7
    Dec 7th
    12 Files
  • 8
    Dec 8th
    1 Files
  • 9
    Dec 9th
    1 Files
  • 10
    Dec 10th
    15 Files
  • 11
    Dec 11th
    30 Files
  • 12
    Dec 12th
    25 Files
  • 13
    Dec 13th
    0 Files
  • 14
    Dec 14th
    0 Files
  • 15
    Dec 15th
    0 Files
  • 16
    Dec 16th
    0 Files
  • 17
    Dec 17th
    0 Files
  • 18
    Dec 18th
    0 Files
  • 19
    Dec 19th
    0 Files
  • 20
    Dec 20th
    0 Files
  • 21
    Dec 21st
    0 Files
  • 22
    Dec 22nd
    0 Files
  • 23
    Dec 23rd
    0 Files
  • 24
    Dec 24th
    0 Files
  • 25
    Dec 25th
    0 Files
  • 26
    Dec 26th
    0 Files
  • 27
    Dec 27th
    0 Files
  • 28
    Dec 28th
    0 Files
  • 29
    Dec 29th
    0 Files
  • 30
    Dec 30th
    0 Files
  • 31
    Dec 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2018 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close