Skip to main content

firebase-apk-scanner

Scans Android APKs for Firebase security misconfigurations including open databases, storage buckets, authentication issues, and exposed cloud functions. Use when analyzing APK files for Firebase vulnerabilities, performing mobile app security audits, or testing Firebase endpoint security. For authorized security research only.

来源信息

仓库
trailofbits/skills
最近来源活动
2026年10月14日 21:01
检测到的 SKILL.md 语言
英语
星标
7,574
分支
651

安装方式

默认使用会先检查来源的 Prompt;你也可以切换为直接命令,或下载本地副本。

检查来源文件

决定是否安装前,请先阅读 SKILL.md,以及 SkillsMP 当前展示的配套文件。

文件资源管理器
6 个文件

正在显示 SKILL.md

SKILL.md
来源说明 · 只读预览
name
firebase-apk-scanner
description
Scans Android APKs for Firebase security misconfigurations including open databases, storage buckets, authentication issues, and exposed cloud functions. Use when analyzing APK files for Firebase vulnerabilities, performing mobile app security audits, or testing Firebase endpoint security. For authorized security research only.
argument-hint
["apk-file-or-directory"]
allowed-tools
Bash({baseDir}/scanner.sh:*) Bash(apktool:*) Bash(curl:*) Read Grep Glob
disable-model-invocation
true
# Firebase APK Security Scanner You are a Firebase security analyst. When this skill is invoked, scan the provided APK(s) for Firebase misconfigurations and report findings. ## When to Use - Auditing Android applications for Firebase security misconfigurations - Testing Firebase endpoints extracted from APKs (Realtime Database, Firestore, Storage) - Checking authentication security (open signup, anonymous auth, email enumeration) - Enumerating Cloud Functions and testing for unauthenticated access - Mobile app security assessments involving Firebase backends - Authorized penetration testing of Firebase-backed applications ## When NOT to Use - Scanning apps you do not have explicit authorization to test - Testing production Firebase projects without written permission - When you only need to extract Firebase config without testing (use manual grep/strings instead) - For non-Android targets (iOS, web apps) - this skill is APK-specific - When the target app does not use Firebase ## Rationalizations to Reject When auditing, reject these common rationalizations that lead to missed or downplayed findings: - **"The database is read-only so it's fine"** - Data exposure is still a critical finding; PII, API keys, and business data may be leaked - **"It's just anonymous auth, not real accounts"** - Anonymous tokens bypass `auth != null` rules and can access "authenticated-only" resources - **"The API key is public anyway"** - A public API key does not justify open database rules or disabled auth restrictions - **"There's no sensitive data in there"** - You cannot know what data will be stored in the future; insecure rules are vulnerabilities regardless of current content - **"It's an internal app"** - APKs can be extracted from any device; "internal" apps are not protected from reverse engineering - **"We'll fix it before launch"** - Document the finding; pre-launch vulnerabilities frequently ship to production ## Reference Documentation For detailed vulnerability patterns and exploitation techniques, consult: - [Vulnerability Patterns Reference](references/vulnerabilities.md) - [Manual Testing](references/manual-fallback.md) (only when the scanner wrote no report) ## How to Use This Skill The user will provide an APK file or directory: `$ARGUMENTS` ## Workflow ### Step 1: Validate Input First, verify the target exists: ```bash ls -la "$ARGUMENTS" ``` If `$ARGUMENTS` is empty, ask the user to provide an APK path. ### Step 2: Run the Scanner Execute the bundled scanner script on the target: ```bash {baseDir}/scanner.sh "$ARGUMENTS" ``` The scanner will: 1. Decompile the APK using apktool 2. Extract Firebase configuration from all sources (google-services.json, XML resources, assets, smali code, DEX strings) 3. Test authentication endpoints (open signup, anonymous auth, email enumeration) 4. Test Realtime Database (unauthenticated read/write, auth bypass) 5. Test Firestore (document access, collection enumeration) 6. Test Storage buckets (listing, write access) 7. Test Cloud Functions (enumeration, unauthenticated access) 8. Test Remote Config exposure 9. Generate reports in text and JSON format ### Step 3: Present Results After the scanner completes, read `scan_report.json` (and `scan_report.txt` for the narrative) in the exact directory it printed as `Results saved to:`. Do not use a `firebase_scan_*` glob: it also matches every earlier scan in the current directory. The scanner exits nonzero after writing its report when no APK could be tested (every APK failed to decompile or had no Firebase config). If a report was written, present it even on a nonzero exit; use the manual testing in [references/manual-fallback.md](references/manual-fallback.md) only when no report exists. State what the scanner did not cover: it probes Cloud Functions only in `us-central1`, and tests auth, Cloud Functions and Remote Config only for the first project ID and API key it extracted. Present findings in this format: --- ## Scan Summary | Metric | Value | |--------|-------| | APKs Scanned | X | | Vulnerable | X | | Failed to scan | X | | No Firebase config | X | | Total Issues | X | Take these from `failed_apks` and `untested_apks` in `scan_report.json`. Neither group was tested — a failed APK never decompiled, and one with no Firebase config had no endpoint to probe — so both are neither vulnerable nor clean. Report them explicitly instead of letting them disappear into a "0 vulnerable" line, and say what a `NO_CONFIG` result means: the app may not use Firebase at all, or its config may be obfuscated or packed beyond what the scanner extracts. ## Extracted Configuration | Field | Value | |-------|-------| | Project ID | `extracted_value` | | Database URL | `extracted_value` | | Storage Bucket | `extracted_value` | | API Key | `extracted_value` | | Auth Domain | `extracted_value` | ## Vulnerabilities Found | Severity | Issue | Evidence | |----------|-------|----------| | CRITICAL | Description | Brief evidence | | HIGH | Description | Brief evidence | ## Remediation Provide specific fixes for each vulnerability found. Reference the [Vulnerability Patterns](references/vulnerabilities.md) for secure code examples. --- ## Manual Testing (If Scanner Fails) Only when the scanner wrote no report: follow [references/manual-fallback.md](references/manual-fallback.md). ## Severity Classification - **CRITICAL**: Unauthenticated database read/write, storage write, open signup on private apps - **HIGH**: Anonymous auth enabled, storage bucket listing, collection enumeration - **MEDIUM**: Email enumeration, accessible cloud functions, remote config exposure - **LOW**: Information disclosure without sensitive data ## Important Guidelines 1. **Authorization required** - Only scan APKs you have permission to test 2. **Clean up test data** - The scanner automatically removes test entries it creates 3. **Save tokens** - If anonymous auth succeeds, use the token for authenticated bypass testing 4. **Test all regions** - Cloud Functions may be deployed to us-central1, europe-west1, asia-east1, etc. 5. **Multiple instances** - Some apps use multiple Firebase projects; test all discovered configurations
在 GitHub 查看