Case Study 30.1: TikTok Vulnerabilities and Starbucks Plaintext Credentials

Background

Mobile applications used by hundreds of millions of people are not immune to fundamental security vulnerabilities. Two high-profile cases — the series of vulnerabilities discovered in TikTok (the world's most downloaded app) and the plaintext credential storage in the Starbucks mobile application — demonstrate that even the most prominent organizations can fail at mobile security fundamentals. These cases are instructive because they illustrate different categories of mobile vulnerabilities, from server-side API flaws to basic client-side data protection failures.

TikTok: A Cascade of Vulnerabilities

The Discovery. In January 2020, Check Point Research published a detailed analysis of multiple vulnerabilities in the TikTok Android application and its associated infrastructure. The findings were significant not only for their severity but because TikTok had over 1.5 billion downloads globally, making any vulnerability in the app potentially catastrophic in terms of affected users.

Vulnerability 1: Account Takeover via SMS Link Spoofing. TikTok's "Send yourself a download link" feature sent SMS messages containing a link that, when clicked, opened the app and could execute actions on behalf of the user. Researchers found that they could spoof these SMS links to point to attacker-controlled servers while appearing to come from TikTok. When a user clicked the spoofed link, the attacker could: - Execute arbitrary JavaScript in the context of the TikTok WebView - Access the user's account data - Perform actions on behalf of the user (upload/delete videos, change privacy settings)

This exploited a combination of weaknesses: insufficient validation of deep link parameters, a WebView that allowed JavaScript execution with access to app functions, and inadequate origin verification for the SMS functionality.

Vulnerability 2: Cross-Site Scripting via Video Descriptions. Certain TikTok API endpoints returned user-supplied content (such as video descriptions) without proper sanitization. When this content was rendered in a WebView within the app, stored XSS payloads could execute, potentially stealing session tokens and user data.

Vulnerability 3: Insecure HTTP Connections. Despite the app's primary use of HTTPS, researchers found that certain API calls — including calls that transferred user data — were made over unencrypted HTTP connections. This allowed network-level attackers to intercept and modify the data in transit.

National Security Implications. Beyond the technical vulnerabilities, TikTok's data handling practices raised broader national security concerns. The U.S. government expressed concern that TikTok's parent company, ByteDance (headquartered in Beijing), could be compelled to share user data with the Chinese government under China's National Intelligence Law. This led to multiple executive orders attempting to ban or force the sale of TikTok's U.S. operations, Congressional hearings, and the eventual passage of legislation in 2024 requiring ByteDance to divest from TikTok or face a U.S. ban.

The TikTok case demonstrates how technical vulnerabilities in mobile applications can escalate to geopolitical issues when the application handles data for hundreds of millions of users across national boundaries.

Starbucks: Plaintext Credential Storage

The Discovery. In January 2014, security researcher Daniel Wood discovered that the Starbucks mobile application for iOS stored user credentials — including usernames, email addresses, and passwords — in plaintext in a local file on the device. The credentials were stored in a crash log file (Crashlytics log) that was written to the device's file system in an unencrypted format.

Technical Details. The vulnerability had several concerning aspects:

  1. Plaintext Storage. User credentials were stored without any encryption or hashing. Anyone with physical access to an unlocked device (or a device backup) could read the credentials directly.

  2. Crash Log Persistence. The credentials were written as part of crash reporting data. Crash logs are often persisted longer than regular application data and may be transmitted to analytics services, creating additional exposure points.

  3. Financial Impact. The Starbucks app included a stored-value card feature, meaning compromised credentials gave direct access to the user's Starbucks balance. Reports at the time indicated that some users had linked credit cards for auto-reload, expanding the financial impact.

  4. Reused Credentials. Because users commonly reuse passwords across services, plaintext credential storage in one app creates cascading risk across all services where the user employs the same password.

Starbucks' Response. When notified, Starbucks initially downplayed the vulnerability, stating that it required physical access to the device. After significant media coverage and public pressure, they released an update that removed the plaintext credential storage. However, the incident highlighted a troubling pattern: security vulnerabilities in high-profile consumer apps often require public pressure before they receive attention.

Technical Analysis: Why These Failures Occur

Development Pressure vs. Security. Both TikTok and Starbucks were under significant pressure to release features quickly. TikTok was in hypergrowth mode, adding features to compete with established social media platforms. Starbucks was racing to capture the mobile payment market. In both cases, security was subordinated to feature velocity.

WebView Complexity. TikTok's WebView-related vulnerabilities illustrate a common pattern. WebViews create a bridge between the relatively controlled native app environment and the wild west of web content. When apps register JavaScript interfaces, enable JavaScript execution, and load content from network sources in WebViews, they inherit all the vulnerability classes of web applications (XSS, CSRF, injection) within the mobile context.

The Android documentation explicitly warns about the risks of addJavascriptInterface(), which can allow JavaScript running in the WebView to invoke native Java methods. Prior to Android 4.2, any public method in the registered object was accessible, creating severe RCE risks.

Logging and Debugging Artifacts. The Starbucks credential exposure occurred through crash logging — a debugging feature. This pattern is surprisingly common: developers add logging statements during development that include sensitive data for troubleshooting, and these statements survive into production builds. The credentials were not intentionally stored in plaintext; they were leaked through a debugging mechanism that was never cleaned up.

Testing Methodology for These Vulnerability Classes

SMS Link/Deep Link Testing:

# Android: Test deep link handling
adb shell am start -a android.intent.action.VIEW \
  -d "medsecure://login?redirect=https://evil.com" \
  com.medsecure.provider

# Verify what parameters the deep link handler accepts
# Check if redirect URLs are validated against a whitelist
# Test for JavaScript execution in any WebView that opens

# iOS: Test URL scheme handling
# Open Safari and navigate to: medsecure://login?redirect=https://evil.com
# Or use Frida to invoke URL handling programmatically

WebView Security Testing:

// Frida script to audit WebView configuration
Java.perform(function() {
    var WebView = Java.use('android.webkit.WebView');

    WebView.loadUrl.overload('java.lang.String').implementation = function(url) {
        console.log('[WebView] Loading URL: ' + url);
        var settings = this.getSettings();
        console.log('  JavaScript enabled: ' + settings.getJavaScriptEnabled());
        console.log('  File access: ' + settings.getAllowFileAccess());
        console.log('  Universal access: ' + settings.getAllowUniversalAccessFromFileURLs());
        this.loadUrl(url);
    };

    WebView.addJavascriptInterface.implementation = function(obj, name) {
        console.log('[WebView] JavaScript interface added: ' + name);
        console.log('  Object class: ' + obj.getClass().getName());
        this.addJavascriptInterface(obj, name);
    };
});

Local Data Storage Audit:

# Check for plaintext credentials in all storage locations
# Android:
adb shell run-as com.medsecure.provider \
  find /data/data/com.medsecure.provider/ -type f -exec grep -l "password\|token\|secret" {} \;

# Check crash logs specifically
adb shell "logcat -d | grep -i 'password\|credential\|token'"

# iOS (jailbroken):
find /var/mobile/Containers/Data/Application/*/Documents/ -name "*.log" -exec grep -l "password" {} \;
find /var/mobile/Containers/Data/Application/*/Library/Caches/ -name "*.log" -exec grep -l "password" {} \;

Lessons for Ethical Hackers

  1. Always check local data storage comprehensively. Do not limit your check to databases and preferences — examine crash logs, analytics caches, temporary files, screenshots, and clipboard data. Sensitive data leaks into unexpected places.

  2. Test deep links and URL schemes thoroughly. Deep links are a growing attack vector as apps increasingly use them for inter-app communication, marketing links, and user onboarding. Test for parameter injection, redirect validation, and authentication bypass.

  3. Audit WebView configurations. Any app that uses WebViews should have JavaScript interfaces audited, content loading sources verified, and file access permissions reviewed. WebViews are a bridge between mobile and web security domains.

  4. Check for HTTP connections. Even apps that primarily use HTTPS may have specific API calls, analytics endpoints, or asset loading that falls back to HTTP. Use a proxy to capture all traffic and flag any unencrypted connections.

  5. Review logging in production builds. Production apps should have debug logging disabled. Search decompiled code for logging statements that include sensitive data — these are common findings even in major applications.

Discussion Questions

  1. TikTok's vulnerabilities were disclosed publicly by Check Point Research. Compare the effectiveness of public disclosure versus private disclosure for motivating security improvements in mobile applications. What factors should researchers consider?

  2. Starbucks initially downplayed the credential storage vulnerability because it required physical device access. Is this a reasonable security assessment? What threat models should be considered for mobile data storage?

  3. The TikTok national security debate centered on data handling by a foreign-owned company. How should security assessments account for geopolitical risks in mobile application supply chains?

  4. Both cases involved applications with hundreds of millions of users. How should the scale of an application's user base affect the prioritization and urgency of security testing?

  5. If you discovered a plaintext credential storage vulnerability in a healthcare mobile app like MedSecure's, what additional legal and regulatory considerations (HIPAA, state breach notification laws) would affect your reporting?

References

  • Check Point Research. "TikTok Flaw Could Have Allowed Hackers Access to User Accounts." January 2020.
  • Wood, Daniel. "Starbucks App Stores Usernames and Passwords in Plain Text." CNN, January 16, 2014.
  • OWASP. "Mobile Security Testing Guide (MSTG)." 2023 Edition.
  • U.S. House of Representatives. "Protecting Americans from Foreign Adversary Controlled Applications Act." 2024.
  • Android Developer Documentation. "WebView Security Best Practices."