[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 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. 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 doesn’t handle large data coming back correctly and doesn’t 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 PIA’s 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 “/var/www/html/” (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 (“192.168.1.x”) 6. Connect the test device to the access point – 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 – 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 doesn’t consider this to be a security issue and doesn’t have immediate plans to fix it: "After talking to the product team, we’ve 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 attacker’s 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 – Uncontrolled Resource Consumption (‘Resource Exhaustion’) 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 _______________________________________________ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
