Advisories

WhatsApp for Android Retains Deleted Contacts Locally

nightwatchcyber Advisories, Research ,

Summary

WhatApp for Android retains contact info locally after contacts get deleted. This would allow an attacker with physical access to the device to check if the WhatsApp user had interactions with specific contacts, even though they have been deleted.

Vulnerability Details

When a contact is deleted on WhatsApp, their information about security code changes is retained (while the chat content is not). The only way to get rid of that is to select “Clear Chat” for the contact before deleting it. Even deleting the chat itself doesn’t do it unless the “Clear Chat” operation is done first. The “security code change notifications” option must be enabled in order for this to work.

Someone getting access to the user’s device can figure out whether they ever chatted with specific contacts, even if those contacts and their chats are no longer on the device. This is a privacy issue – especially for people like journalists and those living in dangerous countries.

Since WhatsApp uses Android’s contact app for contact information but supports chats with numbers that aren’t contacts, our theory is that the application retains information about security code changes even for contacts no longer on the device. There seems to be a discrepancy between how the “Clear chat” option and “Delete Chat” options are implemented in the application, with the first option deleting security notification data.

To reproduce:

  1. Delete a chat with a contact that had security code changes before.
  2. Delete the contact from the device via the Android Contacts app.
  3. Re-add contact to the device via the Android Contacts app.
  4. Start a new chat in WhatsApp with that contact but do not send any messages.
  5. Observe that security code changes are listed with dates in the chat.
  6. Select “Clear Chat” to remove the security code changes, and repeat sterps 1-4. Observe that the security code changes no longer appear.

Tested on WhatsApp for Android, app version 2.21.20.20, running on Android 12.

Vendor Response

We haven’t retested on a more recent version but our recommendation to users is to use the “Clear Chat” option in order to prevent this.

The vendor will not be fixing this issue, here is their response:

As part of the attack scenario you describe getting access to a person’s WhatsApp account to obtain private data, as you mention yourself, people do have a way to remove these messages from their account, if a bad actor gets access to their WhatsApp account prior to that person deleting that information then they will be able to view this information. As such, we are closing this report.

References

CWE: CWE-212 – Improper Removal of Sensitive Information Before Storage or Transfer

Facebook # 10102482597361835

Timeline

2021-10-24: Initial report sent to the vendor, report ID assigned
2021-10-27: Vendor asks for more info, additional info and screenshots sent
2021-11-03: Vendor sent interim status report, still investigating
2021-11-09: Vendor rejects the vulnerability and closes the report
2021-12-30: Public disclosure

Open Redirect Vulnerability in Substack

nightwatchcyber Advisories

Summary

Substack had a open redirect vulnerability in their login flow which would have allowed an attacker to facilitate phishing attacks. The vendor has deployed a fix for this issue.

Vulnerability Details

Substack is an online platform that allows users to create and operate free and paid subscription newsletters. This platform had an open redirect vulnerability in its login flow which would redirect users to any sites after login completed. This could have been used by an attacker to facilitate phishing attacks targeting Substack users and steal their credentials.

The vulnerability was due to the fact that the “redirect parameter” in the login flow wasn’t been validated to make sure that the redirect only goes to a specific set of URLs. The attacker could specify their own redirect URL as follows:

https://substack.com/sign-in?redirect=https://www.google.com

See screenshots below:

Vendor Response

Once a correct reporting channel was established, the issue was reported to the vendor and a fix was deployed limited the redirect parameter to Substack-specific URLs.

References

CWE: CWE-601: URL Redirection to Untrusted Site (‘Open Redirect’)

OWASP: Unvalidated Redirects and Forwards Cheat Sheet

Timeline

2021-07-08: Initial contact with the vendor, asking for a correct reporting channel
2021-07-09: Initial reply received, confirming communication channe again – no response from the vendor
2021-07-13: Pinged again – no response; pinged company co-founders on Twitter
2021-07-13: Communication with the vendor re-established, technical details sent
2021-07-23: Pinged for status, no response
2021-07-29: Vendor responded that a fix has been implemented
2021-07-29: Fix confirmed, vendor pinged for disclosure coordination – no response
2021-08-22: Public disclosure

Supply Chain Attacks via GitHub.com Releases

nightwatchcyber Advisories, Research ,

Summary

Release functionality on GitHub.com allows modification of assets within a release by any project collaborator. This can occur after the release is published, and without notification or audit logging accessible in the UI to either the project owners or the public. However, some audit information may be available via the GitHub APIs. An attacker can compromise a collaborator’s account and use it to modify releases without the knowledge of project owners or the public, thus resulting in supply chain attacks against the users of the project.

This issue was reported to the vendor – their response is that this is intended behavior and is an intentional design decision. While the vendor is planning improvements in this area, they are not able to provide additional details. GitHub.com paid plans and the GitHub enterprise server were not tested.

As a mitigation measure, project owners using GitHub.com are encouraged to use other methods for securing releases such as digitally signing releases with PGP. Users are encouraged to check digital signatures and use the GitHub.com release APIs to extract and verify release assets data.

Background

GitHub.com is a widely used tool for software development offering source code management (SCM) and other tools. It is used for hosting and distribution by many open source projects (OSS). The release functionality within GitHub.com offers a way to publish packaged software iterations as releases. These include a compressed snapshot of the source within the project as a .ZIP and .TAR.GZ file, as well as as additional binary assets. This functionality is a common way for open source projects to distribute their releases.

Vulnerability Details

The release functionality on GitHub.com allows modification of assets within a release by any project collaborator, after the initial release is published. An attacker can use this gap to modify releases without the knowledge of project owners by compromising an account of any project collaborator, thus resulting in supply chain attacks against those using the project. The following specific issues facilitate this:

  • Release assets can be modified after initial publication – except for the source code snapshots
  • Any project collaborator can modify a release – there are no fine-grained controls to allow code access and not release access.
  • There is no notification or indication within the UI that a release was modified – to either the project owners or other collaborators, or the public. However, some data is exposed via API.
  • A “verified” flag is displayed if the Git commit was verified – but this only applies to the source code snapshot and not the other release assets

The releases API provided by GitHub does expose additional information about release assets, which could potentially be used to see if a release was modified. This information includes the username of the uploader and the timestamp when the upload took place. This can be compared to the main release metadata. An example of using APIs for checking releases can be found at our release_auditor project.

NOTE: Paid GitHub.com plans and the GitHub enterprise server were not tested.

Example of a release (see here):

Example of API response exposing asset data:

Steps to Replicate

The following steps can be used to replicate this issue:

  1. Alice creates a public repository on GitHub.com, and adds some code including a shell script “test.sh”.
  2. Alice invites Bob as a collaborator on this repository.
  3. Alice publishes a release including the shell script “test.sh” as a separate asset.
  4. Bob accesses the release, and modifies the “test.sh” script within the release.
  5. When viewing the release via GitHub.com UI, there is no indication the script was modified. Downloading the script shows that it is different from what Alice published.

NOTE: Paid GitHub.com plans and the GitHub enterprise server were not tested.

Vendor Response and Mitigation

The issue was reported to the vendor via their bounty program. Their response is that this is intended behavior and is an intentional design decision. While the vendor is planning improvements in this area, they are not able to provide additional details.

GitHub.com paid plans and the GitHub enterprise server were not tested.

As a mitigation measure, project owners using GitHub.com are encouraged to use other methods for securing releases such as digitally signing releases with PGP. Users are encouraged to check digital signatures and use the GitHub.com release APIs to extract and verify release assets data.

An example of using APIs to check releases can be found in our release_auditor project.

References

Example repository: https://github.com/nightwatchcyber/gh_release_test
GitHub.com docs: here, here and here
HackerOne report # 1167780
release_auditor: see here

Credits

Advisory written by Y. Shafranovich

Timeline

2021-04-18: Initial report submitted to the vendor
2021-04-20: Automated response received
2021-04-21: Vendor response received, intended behavior
2021-04-21: Request to disclose sent
2021-04-23: Vendor ok with disclosure
2021-04-25: Public disclosure – added a link to the OSS project

Local Denial of Service in Nissan Leaf EV (2018) Head Unit Display (CVE-2021-1000008)

nightwatchcyber Advisories, Research ,

Summary

The head unit display in the Nissan Leaf electric vehicle (EV) has a local denial of service vulnerability that can be used to lock up the screen. Once locked, the car remains drivable but the display can no longer be used (even if the car is turned off and on). The only way to unlock the screen is by removing and re-inserting the SD card containing the mapping data.

This was tested on the 2018 SV model of the Nissan Leaf, other Leaf models/trims and other Nissan models with similar SOS functionality may also be affected.

This issue has been reported to the vendor (Nissan), NHTSA and ICS-CERT. Since the vulnerability is low risk there is minimal impact on end users. The vendor has confirmed the issue, but no patch is currently available.

Details

The Nissan Leaf is an electric car which contains a head unit with a touch screen interface in the middle of the dashboard. This panel is used for entertainment and navigation functions such as playing music/radio, navigation and interface with cell phone operating systems such as Android Auto and Apple Play. This panel (#3) is separate from the meters and gauges screen (#2) used to display information regarding the operation of the vehicle itself (as seen below – from the owner’s manual):

panel

Additionally, the Nissan Leaf just like many other Nissan models includes an SOS button located on the roof of the car above the passenger seat and is intended to summon help in case of an emergency. This button is paired with the Nissan app and can be seen below (screenshots from Nissan’s video and manual):

Screen Shot 2020-02-11 at 11.44.23 PMScreen Shot 2020-02-11 at 11.45.58 PM

The display has a denial of service vulnerability that can be used to lock up the screen. Once locked, the car remains drivable but the display can no longer be used (even if the car is turned off and on). The only way to unlock the screen is by removing and re-inserting the SD card containing the mapping data. The vulnerability seems to be the result of interaction between the SOS functionality and the rest of the software operating the head unit.

To replicate:

  1. The car being tested needs to be paired with the Nissan mobile app, and have the NissanConnect subscription enabled.
  2. Turn on the car, verify that NissanConnect with SOS functionality is enabled by checking that the little light on the SOS button is lit.
  3. Press the SOS button to trigger an emergency call.
  4. Immediately, press and hold the SOS button to cancel the call while turning off the car.
  5. The SOS call will lock the head unit, and will stay that way until the SD card is removed and re-inserted which reboots the display panel.

This was tested on the 2018 SV model of the Nissan Leaf, other Leaf models/trims and other Nissan models with similar SOS functionality may also be affected. If a NissanConnect subscription is not enabled on a particular vehicle, then it is probably not vulnerable because the SOS functionality is disabled.

Vendor Response and Mitigation

This issue has been reported to the vendor (Nissan), NHTSA and ICS-CERT. Once the report was routed to the correct team, the vendor responded quickly and confirmed the issue. Since the vulnerability is low risk there is minimal impact on end users. No patch is currently available.

A CVE will not be issued for this vulnerability by MITRE since MITRE doesn’t “assign CVE IDs for Local Denial of Service”. A CVE was issued by the Distributed Weakness Filing (DWF) project instead.

References

CVE (DWF): CVE-2021-1000008

ICS-CERT ticket # ICS-VU-984522
NHTSA case # 11308645
Nissan Information Security (IS) Case # 233758
Nissan Leaf (2018) manual: see here

Credits

The original discoverer of this issue is a minor and their full name cannot be disclosed for privacy reasons.

Timeline

2019-09-24: Initial report to the vendor
2020-01-01: Second report to the vendor, automated reply received
2020-01-27: Follow-up email sent to the vendor, no response
2020-01-28: Initial report to ICS-CERT
2020-02-08: Follow-up communication with ICS-CERT
2020-02-11: Draft advisory sent to both the vendor and ICS-CERT
2020-02-12: Reported to NHTSA
2020-02-12: CVE requested from MITRE
2020-02-16: CVE response received from MITRE
2020-02-16: Response from the vendor received (initial reports were misrouted)
2020-02 through 2021-03: Multiple phone and email communications with the vendor
2021-03-14: Public disclosure

2021-04-08: CVE assigned via DWF

CORS Misconfiguration in Verizon’s Residential Account Portal [2020]

nightwatchcyber Advisories

Summary

The residential billing section of Verizon’s account portal for residential customers had a CORS misconfiguration issue which would have allowed another site in the same browser to download copies of bills in PDF format. The vendor has deployed a fix for this issue.

Because the vendor stopped responding, the issue is fixed and a year has passed, we are now disclosing this publicly.

Vulnerability Details

Normal browser security mechanisms prohibit calls between websites not hosted on the same domain. An override mechanism exists for use cases where such functionality is desired called Cross Original Resource Sharing (CORS). This mechanism employs several headers to allows clients and server to signal each other when such functionality is desired. One of those headers is the “Access-Control-Allow-Origin” header sent by the server indicating which domains are allowed to access a given endpoint or API.

The billing download endpoint (“https://www.verizon.com/digitalservices/billing/billdownload/v1/downloadpaperpdf“) in Verizon’s residential control panel had a CORS misconfiguration. The “Acess-Control-Allow-Origin” header was not restricted to the sites operated by Verizon, but instead simply mirror the domain provided in the client’s request (via the “Origin” header). This could potentially allow other sites to access this endpoint and download the user’s bills in PDF format if they were logged in to the Verizon website at the same time.

This issue was tested on Firefox and it is not known if other browsers were also vulnerable.

Code To Replicate

The following code was used to replicate the issue originally:

Screen Shot 2020-02-17 at 4.46.59 PM

Vendor Response

This issue was reported to the vendor and a fix has been deployed.

References

MDN Reference for CORS: see here
OWASP HTML5 Security Cheet Sheet: see here

Credits

Text of the advisory written by Y. Shafranovich.

Timeline

2019-10-09: Initial report to the vendor
2019-10-08: Vendor requests POC, POC sent
2019-10-24: Pinged for status
2019-10-29: Issue still being investigated
2019-11-30: Pinged for status, issue still being investigated
2019-12-14: Pinged for status, issue still being investigated
2020-01-30: Vendor pinged for disclosure coordination
2020-01-31: Issue fixed, vendor asks for confirmation
2020-02-02: Fix confirmed, asked for disclosure coordination
2020-02-13: Vendor requests a copy of proposed advisory for review
2020-02-17: Draft advisory provided for review; vendor asks to remove their name from the advisory, request is denied; vendor stops responding
2021-03-03: Public disclosure

Content Injection (RCE) in Yandex Browser for Android [2018]

nightwatchcyber Advisories ,

Summary

The Yandex Browser Android application provided by Yandex can be injected with malicious content by an MITM attacker. Because this application is a web browser, this can lead directly to remote code execution (RCE) within the app. The root cause is lack of SSL being used in the help section of the app as well as some other links in the about section, homepage and search engines. Because these links are likely to be clicked on by users and may be considered by users to be “more trusted”, they should be protected.

The recommended fix is to change all of these to use HTTPS instead of HTTP.  The vendor has been notified but has not fixed the issue since they do not consider it to be a security problem. No CVE has been assigned. Version tested is v17.11.1.628, it is not known if other versions are affected.

Since vendor stopped responding in 2019, this is now publicly disclosed.

Vulnerability Details

Yandex Browser is a web browser application based on Google’s Chromium and made by Yandex. While monitoring network traffic of a test device running Android, we observed that the help section of the application makes an initial HTTP call is made to a non-HTTPS site, which then redirects to an HTTPS version. There are also additional hyperlinks within the about section and the homepage which do not use HTTPS, as well as some search engines as set in the settings. Because these links are likely to be clicked on by users and may be considered by users to be “more trusted”, they should be protected.

Because the initial call is done without HTTPS, it is possible for an MITM attacker to intercept this traffic and inject their own content.  Since this is a web browser, this can result in remote code execution within the application since all the content is web based.

Screenshots of the captured traffic:

Screenshot_20180225-163514 Screenshot_20180225-163523

Steps To Replicate (on Ubuntu 17.10)

1. Install the application on the Android device but do not start it.

2a. Install dnsmasq and NGINX on the Linux host:

sudo apt-get install dnsmasq nginx

2b, Configure NGINX by changing the following in /etc/nginx/nginx.conf:

default_type text/html;
charset utf-8;

3. Modify the /etc/hosts file to add the following entry to map the domain name to the Linux host:

192.168.1.x help.yandex.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. Add a file with malicious content (you may need to use sudo):

cd /var/www/html
echo powned >mbrowser

6. Modify the settings on the Android test phone to static, set DNS to point to “192.168.1.x”. AT THIS POINT – Android will resolve DNS against the Linux computer and serve the large servers file

7. Open the app on the Android device, tap on the three vertical dots to the right of the URL bar, and select “Settings” to open the settings menu. Scroll to the bottom and tap “Help”.

We also checked the HSTS preload list maintained by Chrome and did not find the “help.yandex.com” domain on that list. Therefore, Chromium on which this application is build would not force HTTPs for these URLs by default.

All testing was done on v17.11.1.628  of the Android application using a Linux host running Ubuntu v17.10 and Android test device running Android v7.

Additional Vectors – “About” Links

There are also several links within the about section that do not use SSL and lead to the same result. To get that section, tap the “Settings” menu, scroll to the bottom and select “About”:

Screenshot_20180225-163626

These include the following links:

  • “Build xxx” credits – uses domain “storage.ape.yandex.net”
  • “Blink” – uses domain “chromium.org”
  • “Chromium” – uses domain “www.chromium.org”
  • “Opera Turbo” – uses domain “www.opera.com”
  • “License Agreement” – uses domain “m.legal.yandex.ru”

Screenshots of captured traffic below:

Screenshot_20180225-163816 Screenshot_20180225-163732 Screenshot_20180225-163708 Screenshot_20180225-163743 Screenshot_20180225-163826

Additional Vectors – Homepage

There are also several links within the homepage of the application that do not use SSL and lead to the same result. To get that section, open the app and drag the screen down to display all of them. They also show up as a banner in the top of the Android screen in other apps as well – to see, go anywhere in the OS and drag down the top of the screen. Screenshots:

Screenshot_20180225-184156 Screenshot_20180225-184205

Of these, the following do not use SSL / HTTPS:

  • YouTube – uses domain “m.youtube.com”
  • Booking – uses domain “www.booking.com”

Screenshots of traffic attached:

Screenshot_20180225-184258 Screenshot_20180225-184312

Additional Vectors – Search Engines

Some of the search engines that the browser supports are also not configured to use SSL, thus allowing for injection. To reach the search engine settings, tap the right side of the URL bar with the vertical “three dots” icon to show the settings menu, then scroll down to “Search Engine”. Screenshots attached:

Screenshot_20180225-184941 Screenshot_20180225-184945

In particular, the following search engines are affected:

  • Bing (which is used by default) – uses domains “m.trovi.com”, “m.bing.com” and “www.bing.com”

Screenshots of captured traffic attached:

Screenshot_20180225-184645 Screenshot_20180225-184652 Screenshot_20180225-184658

Recommended Mitigation and Vendor Response

The recommended fix is to change all of these links to use HTTPS instead of HTTP. The vendor doesn’t consider these to be a security issue and has no plans to fix these issues at this time.

Users should consider using a different browser.

References

Google Play Link: https://play.google.com/store/apps/details?id=com.yandex.browser

Credits

Text of the advisory written by Y. Shafranovich.

Timeline

2017-12-17: Initial report to the vendor via their bounty page
2017-12-25: Initial vendor reply rejecting the bug, and our follow-up
2018-01-14: Reminder email sent to the vendor
2018-01-15: Vendor unable to replicate the issue
2018-01-23: Reply to vendor sent
2018-01-25: Follow-up communications with the vendor
2018-01-26: Vendor asks for video
2018-02-10: Videos and payloads sent to the vendor
2018-02-14: Reminder email to vendor sent
2018-02-22: Vendor rejecting the report, and a follow-up communication
2018-02-25: Draft advisory sent to the vendor for review, along with another video
2021-03-03: Vendor stopped responding in 2019; public disclosure

Network Vulnerability in Oracle Database – CVE-2021-2018

nightwatchcyber Advisories, Research

Summary

Vulnerability in the Advanced Networking Option component of Oracle Database Server can lead to an MITM attack. Supported versions that are affected are 18c and 19c (Windows platform only).

Details

Difficult to exploit vulnerability allows unauthenticated attacker with network access via Oracle Net to compromise Advanced Networking Option. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Advanced Networking Option, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Advanced Networking Option.

CVSS 3.1 Base Score 8.3 (Confidentiality, Integrity and Availability impacts)

CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H)

References

CVE Database: CVE-2021-2018

Vendor advisory: see here

Two vulnerabilities in Oracle’s iPlanet Web Server (CVE-2020-9315 and CVE-2020-9314)

nightwatchcyber Advisories ,

SUMMARY

Two vulnerabilities were discovered in the web administration console of Oracle’s iPlanet Web Server which allow for sensitive data exposure and limited injection. The first issue allows read-only access to any page within the administration console without authentication, resulting in sensitive data exposure. The second issue allows for injection of external images which can be used for phishing and social engineering.

These vulnerabilities have been reported to the vendor (Oracle) but the vendor will not be issuing security patches because the affected product is no longer supported. Users are encouraged to implement other controls to mitigate these vulnerabilities such as restricting network access to the administration console from the Internet or switching to a supported platform.

Version 7 has been tested and found to be vulnerable, however, it is unknown whether earlier versions are affected. Latest versions of Oracle Glassfish and Eclipse Glassfish application server (v5) share common code with the affected product, have been tested and do not seem to be vulnerable. MITRE has assigned CVE-2020-9315 to track the sensitive data exposure issue and CVE-2020-9314 to track the injection issue.

ISSUE #1 – SENSITIVE DATA EXPOSURE / ADMIN GUI BYPASS (CVE-2020-9315)

A vulnerability exists in the web administration console of Oracle’s iPlanet Web Server which makes it possible to read information from any page within the console without authentication. This can result in sensitive data exposure of configuration information about the server including encryption keys, JVM configuration and other data. We did not perform testing to see whether this vulnerability allows for changes to be made within the console.

This is accomplished by replacing any URL for any page within the administration console as follows:

with:

To replicate, try the following URLs:

ISSUE #2 – IMAGE INJECTION IN THE ADMIN GUI (CVE-2020-9314)

The “productNameSrc” parameter in the administration console allows for injection of external images. When used in combination with the “productNameHeight” and “productNameWidth” parameters, this can be used to inject an external image into a site to facilitate phishing. This is due to an incomplete fix for CVE-2012-0516. The earlier fix added validation against XSS issues but didn’t add validation to make sure an external image is not loaded.

To replicate, try the following URLs:

VENDOR RESPONSE

Both vulnerabilities have been reported to the vendor (Oracle), however the vendor doesn’t plan to issue security patches since the product is no longer supported, as per the following responses:

Oracle iPlanet Web Server 7.0.x is no longer supported. Please see the life time support document.

And:

Thank you for your report regarding Oracle iPlanet Web Server 7.0.x, which is no longer supported by Oracle. Since Oracle no longer supports Oracle iPlanet Web Server 7.0.x, the policy is that there is no coordinated disclosure involving Oracle. Reporters who discover security vulnerabilities in products that Oracle no longer supports are free to disclose vulnerability details without Oracle participation. Oracle does not assign CVEs for products that are no longer supported. That means, if you want a CVE assigned you will need to contact Mitre.

CERT/CC concurred with the vendor’s assessment.

MITRE has assigned CVE-2020-9315 to track the sensitivity data exposure issue, and CVE-2020-9314 to track the injection issue.

AFFECTED VERSIONS AND MITIGATIONS

Version 7 has been tested and found to be vulnerable, however, it is unknown whether earlier versions are affected. Latest versions of Oracle Glassfish and Eclipse Glassfish application server (v5) share common code with the affected product but have been tested and do not seem to be vulnerable.

Users are encouraged to implement other controls to mitigate these vulnerabilities such as restricting network access to the administration console from the Internet or switching to a supported platform.

REFERENCES

CERT/CC ID: VU#343851
CVEs: CVE-2020-9315 and CVE-2020-9314
Oracle lifetime support documentation: see here
Related vulnerability regarding XSS: CVE-2012-0516 and advisory

CREDITS

We would like to thank Synack for assistance with the disclosure process. Text of the advisory was written by Y. Shafranovich.

TIMELINE

2020-01-19: Initial discovery
2020-01-24: Initial disclosure sent to vendor; rejected since product is not supported
2020-01-24: Clarification questions sent to the vendor
2020-01-27: Report again rejected by vendor; referred to MITRE for CVE assignment
2020-01-29: CVEs requested from MITRE
2020-02-07: Initial report sent to CERT/CC
2020-02-17: CVE request rejected by MITRE, resubmitted with more data
2020-02-18: Response received from CERT/CC
2020-02-20: CVE assignments received from MITRE
2020-02-20: CVEs and disclosure plans communicated to the vendor
2020-05-10: Public disclosure

Interesting two-factor (2FA) behavior in Facebook

nightwatchcyber Advisories

We recently ran across an interesting behavior with two-factor authentication in Facebook. There are two methods supported: SMS to a phone and OTP via an app such as Google Authenticator. What is interesting is that when OTP is added as an 2FA method and SMS remains as backup, every login to Facebook still sends an SMS code (even though that method is supposed to be a “backup method” only if the OTP method fails). This is in contrast with other vendors such as Google where only one 2FA method is used at any given time.

The only way to get around this, is to setup OTP as the primary 2FA method and backup codes or a security key as the backup one. If you try to setup SMS as the backup method, it reverts to the behavior described above.

This was reported to Facebook on April 27th, 2020 and rejected as a security issue. The original report # is 554696145470552.

Screen Shot 2020-04-30 at 9.42.37 PM

Google Authenticator for Android Allows Screen Capture

nightwatchcyber Advisories ,

Google offers an application for Android called “Google Authenticator” which is used to setup two-factor authentication (2FA). This application is used to generate standard OTP codes usually used for 2FA.

It appears that Google Authenticator allows screenshots to be taken of OTP codes. The implication is that if a user’s device ends up running a rogue app, that app can capture all generated OTP codes as they are shown by the app, and thus break two factor authentication.

[EDITED: 2020-03-23: This is only true for rogue apps with screenshot permissions (MediaProjection) BUT not those using accessibility (a11y) permissions. This is especially true since many such rogue apps use Android accessibility to scrape screenshots from running apps. However, using FLAG_SECURE may prevent that behavior even via accessibility permissions, although more research is needed to confirm that.]

UPDATE (2020-03-03): Disclosed publicly because of recent media reports

UPDATE #2 (2020-03-04): Multiple people noted that Microsoft Authenticator has the same issue. We blogged about that back in 2018 and the issue remains unfixed.

UPDATE #3 (2020-03-23): Although FLAG_SECURE may protect against malicious apps using the MediaProjection APIs, HOWEVER, as per the comment below from Yanick Fratantonio and his blog post, FLAG_SECURE doesn’t protect against attacks using accessibility services. See our follow-up post here.

Steps to Replicate

To replicate, try the following:

  1. Open the application.
  2. Add an account.
  3. Press Power + Volume Down at any sensitive screen and observe a screenshot being taken.

The underlying reason is because the app is not using “FLAG_SECURE” for such screens (more information on FLAG_SECURE can be found in our earlier blog post). By contrast, many Android apps with higher security requirements use it.

Vendor Response

We filed a bug report with the vendor (Google) and the vendor filed an internal bug. The vendor never informed us whether the bug was fixed. Testing on the most recent version reveals that the bug is still present.

Screen Shot 2020-03-03 at 10.00.33 PM

References

  • GitHub issue filed by someone else – see here
  • Google Play link to the app – see here
  • Google Security Case # 8-2193000017345
  • Our earlier blog post about FLAG_SECURE on Android – see here
  • ZDNet report regarding Cerberus malware attacking this app – see here

Timeline

  • 2014-10-10: GitHub issue filed by someone else
  • 2017-05-10: Issue filed with the vendor, triaged and bug filed
  • 2017-05-11: Follow-up discussion regarding other vendor apps
  • 2017-05-12: Response regarding bounty received
  • 2020-02-27: Media story regarding malware targeting this app
  • 2020-03-03: Public disclosure
  • 2020-03-04: Added comment regarding Microsoft Authenticator
  • 2020-03-23: Added clarification regarding screenshot permissions and accessibility permissions