Insecure Bootstrap Process in Google’s Cloud SQL Proxy

Summary

The bootstrap process for Google’s cloud SQL Proxy CLI uses the “curl | bash” pattern and didn’t document a way to verify authenticity of the downloaded binaries. The vendor updated documentation with information on how to use checksums to verify the downloaded binaries.

Vulnerability Details

As part of our ongoing research into supply chain attacks, we have been analyzing bash installer scripts using the “curl | bash” pattern. Google provides such script used to install the Cloud SQL proxy. However, the documentation doesn’t indicate how to verify downloaded files prior to execution.

Vendor Response

The vendor updated their documentation with information on how to verify downloaded binaries via checksums.

References

Vendor issue tracker # 244384166

Timeline

2022-08-30: Initial report to the vendor
2022-08-30: Vendor acknowledged the report
2022-09-27: Vendor rejected the report as a security issue
2023-03-03: Vendor reported that a fix has been implemented
2023-03-19: Public disclosure

Firebase CLI Installer Making Calls to Google Analytics

Firebase is a mobile and web application development platform provided by Google. One of the tools available for the platform is the Firebase CLI tool (GitHub repo) which helps developers interact with the platform from command line. An automatic install script is offered among other options, which allows installation of the CLI tool via the “curl | bash” pattern as follows:

curl -sL https://firebase.tools | bash

As part of our ongoing research into supply chain attacks, we have been looking into bash installer scripts that make calls to external systems. First, there is no way to verify that the installer is legit, However, to our surprise, we also found that this script makes calls to Google Analytics as part of the installation process. There is no sensitive data being collected but Google may still be collecting IP addresses of users installing the CLI. The source code for the installer script can be found here:

https://firebase.tools/

While this can be disabled, the documentation to do so is hard to find and is embedded within the installer script itself. We hope that Google will make this documentation more clear in the future. In any case, here is the documentation:

The actual code that makes these calls can be found here:

And here are all the analytics events triggered within the script:

send_analytics_event start
...
send_analytics_event uninstall_npm
...
send_analytics_event uninstall
...
send_analytics_event already_installed
...
send_analytics_event upgrade
...
send_analytics_event "missing_platform_$UNAME"
...
send_analytics_event failure
...
send_analytics_event missing_path
...
send_analytics_event success

Google Authenticator for Android Allows Screen Capture

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

 

Brief Notes on Gmail for Android and Confidential Mode

Recently Google launched “Confidential Mode” for Gmail which seeks to protect sensitive information from unauthorized access – details here.

Some brief notes:

  • On the web version of Gmail, when replying to a confidential message, the reply is also sent as confidential. However, when using Gmail for Android that is not true – instead you get a warning that the message will not be sent with confidential mode.
  • When viewing confidential mode emails with Gmail for Android, FLAG_SECURE is not used (see our post here). That means other applications on the same device with the screen capture permissions can capture this content as well. This was reported to Google (issue # 112838515) and they do not consider it a security issue.

Another Download Protection Bypass in Google Chrome – BIN files in Mac OS

Summary

BIN files on Mac OS bypass the download protection mechanism offered by Google’s Chrome browser. This was reported and fixed by the vendor, then pushed via a component update to users in March 2019.

Background

The Chrome and Chromium browsers are an open-source based web browser offered by Google. Among it’s features it includes a safety feature that detects unsafe downloads to protect the user. This feature works in multiple ways but is controlled via a file in Chrome’s source code (“download_file_types.asciipb”). Additional background details can be found in our earlier post. We had previously reported multiple instances of download protection bypass in Chrome to the vendor – this post describes another one that was found more recently.

Details

The BIN file extension on Mac OS is opened by default via the Archive Mounter utility. That means that you can take a compressed file such as ZIP and rename it as a BIN file. When downloaded via Chrome, the browser will not do safety checks on this file yet the file can carry dangerous content. The root cause is the fact that the BIN file type is whitelisted as being not dangerous. This issue only affects users on Mac OS.

The vendor fixed the issue and pushed it via a component update. Users do not need to update the actual browser – as long as connectivity exists for component updates, this should be fixed automatically.

References

Chrome Bug Report: 933637

Bounty Information

This issue qualified for the Chrome Rewards security bounty program and a bounty has been paid.

Credits

Advisory written by Y. Shafranovich.

Timeline Summary

2019-02-19: Report submitted
2019-02-27: Vendor fix is committed
2019-03-25: Vendor fix is released to users
2019-07-02: Public disclosure

 

Sensitive Data Exposure via WiFi Broadcasts in Android OS [CVE-2018-9489]

[NOTE: This bug is part of a series of three related Android bugs with the same root cause: CVE-2018-9489, CVE-2018-9581 and CVE-2018-15835. A presentation covering all three bugs was given at BSides DE in the fall of 2018.]

Summary

System broadcasts by Android OS expose information about the user’s device to all applications running on the device. This includes the WiFi network name, BSSID, local IP addresses, DNS server information and the MAC address. Some of this information (MAC address) is no longer available via APIs on Android 6 and higher, and extra permissions are normally required to access the rest of this information. However, by listening to these broadcasts, any application on the device can capture this information thus bypassing any permission checks and existing mitigations.

Because MAC addresses do not change and are tied to hardware, this can be used to uniquely identify and track any Android device even when MAC address randomization is used. The network name and BSSID can be used to geolocate users via a lookup against a database of BSSID such as WiGLE or SkyHook. Other networking information can be used by rogue apps to further explore and attack the local WiFi network.

All versions of Android running on all devices are believed to be affected including forks (such as Amazon’s FireOS for the Kindle). The vendor (Google) fixed these issues in Android P / 9 but does not plan to fix older versions. Users are encouraged to upgrade to Android P / 9 or later. CVE-2018-9489 has been assigned by the vendor to track this issue. Further research is also recommended to determine whether this is being exploited in the wild.

Amazon plans to address this issue as their transition devices to a new version of FireOS.

Background

Android is an open source operating system developed by Google for mobile phones and tablets. It is estimated that over two billion devices exist worldwide running Android. Applications on Android are usually segregated by the OS from each other and the OS itself. However, interaction between processes and/or the OS is still possible via several mechanisms.

In particular, Android provides the use of “Intents” as one of the ways for inter-process communication. A broadcast using an “Intent” allows an application or the OS to send a message system-wide which can be listened to by other applications. While functionality exists to restrict who is allowed to read such messages, application developers often neglect to implement these restrictions properly or mask sensitive data. This leads to a common vulnerability within Android applications where a malicious application running on the same device can spy on and capture messages being broadcast by other applications.

Another security mechanism present in the Android is permissions. These are safeguards designed to protect the privacy of users. Applications must explicitly request access to certain information or features via a special “uses-permission” tag in the application manifest (“AndroidManifest.xml”). Depending on the type of permission (“normal”, “dangerous”, etc”) the OS may display the permission information to the user during installation, or may prompt again during run-time. Some permissions can only be used by system applications and cannot be used by regular developers.

Screenshots of application permissions in Google Play and at run-time:

pic3 pic4 pic6

Vulnerability Details

Android OS broadcasts information about the WiFi connection and the WiFi network interface on a regular basis using two intents: WifiManager’s NETWORK_STATE_CHANGED_ACTION and WifiP2pManager’s WIFI_P2P_THIS_DEVICE_CHANGED_ACTION. This information includes the MAC address of the device, the BSSID and network name of the WiFi access point, and various networking information such as the local IP range, gateway IP and DNS server addresses. This information is available to all applications running on the user’s device.

While applications can also access this information via the WifiManager, this normally requires the “ACCESS_WIFI_STATE” permission in the application manifest. Geolocation via WiFi normally requires the “ACCESS_FINE_LOCATION” or “ACCESS_COARSE_LOCATION” permissions. Also, on Android versions 6.0 and later, the real MAC address of the device is no longer available via APIs and will always return the address “02:00:00:00:00:00”. However, an application listening for system broadcasts does not need these permissions thus allowing this information to be captured without the knowledge of the user and the real MAC address being captured even on Android 6 or higher.

Screenshot of an app trying to obtain MAC address in Android 7.0:

pic7

We performed testing using a test farm of mobile device ranging across multiple types of hardware and Android versions. All devices and versions of Android tested confirmed this behavior, although some some devices do not display the real MAC address in the “NETWORK_STATE_CHANGED_ACTION” intent but they still do within the “WIFI_P2P_THIS_DEVICE_CHANGED_ACTION” intent. We also tested at least one fork (Amazon’s FireOS for the Kindle) and those devices displayed the same behavior.

Because MAC addresses do not change and are tied to hardware, this can be used to uniquely identify and track any Android device even when MAC address randomization is used. The network name and/or BSSID can be used to geolocate users via a lookup against a database like WiGLE or SkyHook. Other networking information can be used by rogue apps to further explore and attack the local WiFi network.

Steps to Replicate by Regular Users

For Android device users, you can replicate these issues as follows:

  1. Install the “Internal Broadcasts Monitor” application developed by Vilius Kraujutis from Google Play.
  2.  Open the application and tap “Start” to monitor broadcasts.
  3.  Observe system broadcasts, specifically “android.net.wifi.STATE_CHANGE” and “android.net.wifi.p2p.THIS_DEVICE_CHANGED”.

Screenshot examples:

pic1  pic2

Steps to Replicate by Developers via Code

To replicate this in code, create a Broadcast receiver and register it to receive these actions (“android.net.wifi.WifiManager.NETWORK_STATE_CHANGED_ACTION” and “android.net.wifi.WifiP2pManager.WIFI_P2P_THIS_DEVICE_CHANGED_ACTION”). Sample code appears below:

public class MainActivity extends Activity {
@Override
public void onCreate(Bundle state) {
    IntentFilter filter = new IntentFilter();        
    filter.addAction(
	android.net.wifi.WifiManager.NETWORK_STATE_CHANGED_ACTION);
    filter.addAction(
	android.net.wifi.WifiP2pManager.WIFI_P2P_THIS_DEVICE_CHANGED_ACTION);
    registerReceiver(receiver, filter);
}
    
BroadcastReceiver receiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
    Log.d(intent.toString());
    ….
}
};

Vendor Response and Mitigation

The vendor (Google) classified this issue as Moderate, and provided a fix in Android P / 9. Because this would be a breaking API change, the vendor does not plan to fix prior versions of Android. Users are encouraged to upgrade to Android P / 9 or later.

Amazon has responded regarding their Android fork (FireOS) as follows:

We are planning to address the issue as devices transition to the new version of Fire OS

References

Android ID # 77286245
CVE ID: CVE-2018-9489
Google Bug # 77236217
GitHub: Internal Broadcasts Monitor

Bounty Information

This bug qualified for a bounty under the terms of the Google’s Android Rewards bounty program, and a bounty payment has been received.

Credits

We want to thank Vilius Kraujutis for developing the Internal Broadcasts Monitor application and making the source code available in GitHub.

This advisory was written by Yakov Shafranovich.

Timeline

2018-03-28: Initial report submitted to the vendor
2018-03-29: Initial response from the vendor received – issue being investigated
2018-04-03: Follow-up communication with the vendor
2018-04-04: Follow-up communication with the vendor
2018-05-02: Checking on status, response from vendor – issue still under investigation
2018-06-05: Checking status, no response from the vendor
2018-07-01: Checking status, no response from the vendor
2018-07-10: Response from vendor – issue still under investigation; pinged for a timeline
2018-07-12: Pinged the vendor regarding CVE assignment and disclosure plans
2018-07-13: Information about the fix provided by the vendor; follow-up communication
2018-07-14: Additional information provided to the vendor
2018-07-17: Additional information provided to the vendor
2018-07-19: Additional information provided to the vendor, response received
2018-08-09: Fix confirmed
2018-08-16: Initial draft of the advisory provided to the vendor for review
2018-08-21: Follow-up communication with the vendor
2018-08-22: CVE assigned by the vendor, follow-up communication with the vendor
2018-08-23: Final version of the advisory provided to the vendor for review
2018-08-29: Public disclosure / advisory published; added information about Android forks
2018-09-05: Added Amazon’s response
2018-10-22: Added bounty information
2018-11-11: Added links to related bugs and presentation
2019-09-01: Fix listed as part of Android 10 fixes

Media Coverage

Gmail for Android Allows Screenshots in Confidential Mode

Google recently added confidential mode for Gmail that allows the sender to restrict how their email gets by the recipients including forbidding printing, etc. However, it looks like that Gmail for android still allows screenshots to be taken for such emails. To replicate, try the following:

  1. Send a confidential email to another Gmail user.
  2. Open the email, press Power + Volume Down. A screenshot will be taken.

The underlying reason is because the Gmail 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. For example, Chrome for Android prohibits screenshots when browsing in anonymous mode on Android.

We did file a bug report with Google and here is their response:

We can not prevent someone from taking a photograph of their phone, using a second camera for example. Preventing taking photos of the content is not part of the feature.

References:
Google bug report # 112838515

Android OS Didn’t use FLAG_SECURE for Sensitive Settings [CVE-2017-13243]

Summary

Android OS did not use the FLAG_SECURE flag for sensitive settings, potentially exposing sensitive data to other applications on the same device with the screen capture permissions. The vendor (Google) fixed this issue in 2018-02-01 Pixel security update. Google has assigned CVE-2017-13243 to track this issue.

Details

Android OS is a mobile operating systems for phones and tablets developed by Google. The OS has multiple screens where sensitive information maybe shown such as the device lock screen, passwords in the WiFi settings, pairing codes for Bluetooth, etc.

FLAG_SECURE is a special flag available to Android developers that prevents a particular screen within an application from being seen by other application with screen capture permissions, having screenshots taken by the user, or have the screen captured in the “Recent Apps” portion of Android OS. We have published an extensive post last year discussing this feature is and what it does.

During our testing of various Google mobile applications, we found that the lock screen, password entry screen for WiFi, and the screen for entering pairing codes for Bluetooth devices did not use FLAG_SECURE to prevent other applications for capturing that information. By contrast other Google applications like Android Pay and Google Wallet use this flag to prevent capture of sensitive information. Exploiting this bug requires user cooperation in installing a malicious app and activating the actual screen capture process, thus the likelihood of exploitation is low.

To reproduce:
1. Lock the device, OR go to WiFi settings and try to add a network, or try to pair a Bluetooth device.
2. Press Power and volume down to capture screenshot.
3. Confirm that a screenshot can be taken.

All testing was done on Android 7.1.2, security patch level of May 5th, 2017, on Nexus 6P. Vulnerable versions of Android include: 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2 and 8.0.

Vendor Response

This issue was responsibly reported to the vendor and was fixed in the 2018-02-01 Pixel bulletin. The vendor assigned CVE-2017-13243 to track this issue.

Bounty Information

This issue satisfied the requirements of the Android Security Rewards program and a bounty was paid.

References

Android ID # A-38258991
CVE ID: CVE-2017-13243
CVSS scores: 7.5 (CVSS v3.0) / 5.0 (CVSS v2.0)
Google Bug # 38254822
Google Pixel Bulletin: 2018-02-1

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-05-12: Initial report to the vendor
2017-06-15: Follow-up information sent to the vendor
2017-06-19: Follow-up communication with the vendor
2018-01-02: Vendor communicates plan to patch this issue
2018-01-29: Bounty reward issued
2018-02-01: Vendor publishes a patch for this issue
2018-05-24: Public disclosure / advisory published

Multiple Instances of Download Protection Bypass in Google’s Chrome

Summary

We have found several instances of files bypassing the download protection offered by Google’s Chrome browser. All of these have been reported to the vendor, and whichever were accepted by the vendor were fixed in Chrome M51 and M52.

Background

The Chrome and Chromium browsers are an open-source based web browser offered by Google. Among it’s features it includes a safety feature that detects unsafe downloads to protect the user. This feature works in multiple ways but is controlled via a file in Chrome’s source code (“download_file_types.asciipb”) which defines several options based on what the file extension of the downloaded files are:

  • Platform/OS
  • What kind of warning to show the user
  • Whether this file type is an archive
  • Whether the file can be opened automatically by clicking on it in the download area
  • Whether a ping get sent back to Google for every download of this type (FULL), some downloads (SAMPLED) or not sent at all. This checksum check is used to check against a server-side blacklist of known bad files.

The Chrome Rewards bug bounty program includes a separate section covering download bypass that was added in March of 2016. To be eligible, it needs to be on a supported platform (MacOS or Windows), be dangerous by being clicked and not send a full ping back to Google. In December of 2016, the scope of this was changed to only include file extensions already in the source code for Chrome.

As part of our testing in scope of this program, we tested all file extensions that are included in a default on MacOS v10.11 (El Capitan)  and Windows 2012 R2 / 7 Enterprise. This advisory lists all of the bypasses that we located, reported to the vendor, and the status of whether they were accepted and fixed, or rejected. Most of these were reported prior to the scope change in December 2016, and included patches whenever feasible.

Details

The following extensions were reported but were rejected as being out of scope and were not fixed:

  • ChromeOS: APK
  • Linux: AFM, PFA, TIF
  • MacOS: APP, CONFIGPROFILE, DFONT, ICC, INTERNETCONNECT, MOBILECONFIG, NETWORKCONNECT, OTF, PREFPANE, PROVISIONPROFILE, QTZ, SAFARIEXTZ, SAVER, TTF, WEBBOOKMARK, WEBLOC
  • Windows: CAMP, CDMP, DESKTHEMEPACK, DIAGCAB, DIAGPKG, GMMP, ICC, IMESX, MOV, MSU, OTF, PFB, PFM, PRF, RAT, QDS, QT, RDP, SEARCH-MS, THEMEPACK, THEMES, TTC, TTF, WCX

The following extensions were reported, confirmed to be dangerous and fixed, all on MacOS (the underlying issue has been described in a separate blog post here).

  • AS, CDR, CPGZ, DART, DC42, DISKCOPY42, DMGPART, DVDR, IMG, IMGPART, ISO, MPKG, NDIF, PAX, SMI, SPARSEBUNDLE, SPARSEIMAGE, TOAST, UDIF, XIP

These issues were fixed in Chrome M51 and M52.

References

Chrome Bug Reports (rejected): 671382, 671385, 624224, 596342, 605386, 601255, 601250, 600910, 600615, 600609, 600606, 600601, 600597, 600592, 600590, 600587, 600581, 599880

Chrome Bug Reports (fixed): 596354, 600613, 600907, 600908

Bounty Information

The issues that were fixed qualified for the Chrome Rewards security bounty program and a bounty has been paid.

Credits

Advisory written by Yakov Shafranovich.

Timeline Summary

2016-03-20: First report submitted
2016-03 to 2016-12: multiple other reports submitted, and fixed applied
2016-12-06: Last report submitted
2018-02-26: Public disclosure

 

Content Injection in DuoLingo’s TinyCards App for Android [CVE-2017-16905]

[NOTE ADDED 04/29/2019: The term “RCE” – “Remote Code Execution” in this context is taken from the Google Play Security Reward Program (GPSRP) as per their policy here, even though it is not normally used that way. It specifically refers to the ability to inject and run JavaScript within a WebView-based app.

For now, the scope of this program is limited to RCE (remote-code-execution) vulnerabilities and corresponding POCs (Proof of concepts) that work on Android 4.4 devices and higher. This translates to any RCE vulnerability that allows an attacker to run code of their choosing on a user’s device without user knowledge or permission. Examples may include:

  •  Attacker gaining full control, meaning code can be downloaded from the network and executed (download and execute arbitrary code, native, Java code etc. Javascript)
  • UI Manipulation to commit a transaction. For example, causing a banking app to make money transfers on behalf of the user without their consent.
  •  Opening of webview that may lead to phishing attacks. Opening webview without user input or interaction.

]

Summary

The TinyCards Android application provided by DuoLingo can be injected with malicious content by an MITM attacker. Because this application is a web-app framed in an Android WebView, this can lead to JavaScript being executed within the app by running JavaScript [which Google calls remote code execution (RCE)]. The root cause is lack of SSL being used on app startup when the initial web content is loaded into the WebView.

The vendor has fixed this issue in v1.0 (version code 10) that was released via Google Play Store on November 20th, 2017 and users should install the latest version. MITRE has assigned # CVE-2017-16905 to track this issue.

Vulnerability Details

TinyCards is a flashcard application for preparing for tests and memorizing vocabulary. It is made by DuoLingo, which provides a platform for learning new languages. While monitoring network traffic of a test device running Android, we observed that during application startup an initial HTTP call is made to a non-HTTPS site, which then redirects to an HTTPS version. Further research into the application revealed that the application is essentially a thin browser wrapper using Android’s WebView around a web application loaded remotely.

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 app, this can result in code execution within the application since all the content is web based. This would be accomplished by injecting and running arbitrary JavaScript.

Screenshots of the captured traffic and relevant source code:

screenshot1screenshot2

Steps To Replicate (on Ubuntu 17.10)

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

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 the domain name to the Linux host:

192.168.1.x tinycards.duolingo.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 >index.html

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 and observe injected content.

All testing was done on v1.0 (version code 9)  of the Android application using a Linux host running Ubuntu v17.10 and Android test device running Android v7.

Vendor Response and Mitigation

To fix this issue, the vendor has changed the initial URL for web content being loaded within the app to use SSL. The vendor has fixed this issue in v1.0 (version code 10) that was released via Google Play Store on November 20th, 2017 and users should install the latest version.

Bounty Information

DuoLingo doesn’t currently offer bounties, however, this bug has fulfilled the requirements of Google Play Security Reward Program and a bounty has been paid from that program.

References

CVE-ID: CVE-2017-16905
HackerOne Reports: 281605 (DuoLingo) and 293444 (Google Play Rewards)

Credits

We would like to thank the vendor for the quick turnaround and fix for this  vulnerability. Text of the advisory written by Yakov Shafranovich.

Timeline

2017-10-21: Report opened with the vendor via HackerOne to clarify scope
2017-11-06: Technical details of vulnerability provided to the vendor via HackerOne
2017-11-07: Report triaged and being reviewed by the vendor
2017-11-20: Vendor patched the issue and asked for testing of the fix
2017-11-20: Fix confirmed, communication regarding disclosure
2017-11-28: Report submitted to Google’s Play Rewards program via HackerOne
2017-11-29: Rejection received due to scope, follow-up communication with Google regarding scope
2017-12-04: Follow-up conversation about disclosure with Google and the vendor
2017-12-05: Disclosure requested from DuoLingo via HackerOne
2018-01-04: Public disclosure on HackerOne, and publication of this advisory
2019-04-29: Added clarification for terminology