lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Mon, 9 Jul 2018 16:39:55 -0400
From: Nightwatch Cybersecurity Research <research@...htwatchcybersecurity.com>
To: fulldisclosure@...lists.org
Subject: [FD] Crashing Facebook Messenger for Android with an MITM attack

[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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux - Powered by OpenVZ