Xiaomi Phase 3: Nuclei Scan & WAF Analysis

Xiaomi Phase 3: Nuclei Scan & WAF Analysis

Phase 3 of the Xiaomi HackerOne engagement ran 5,472 Nuclei templates across three live targets identified in Phase 2 — app.mi.com, b.mi.com, and market.xiaomi.com. Zero CVEs matched. Here’s what that actually means.

What We Scanned

Three live services confirmed in Phase 2:

  • app.mi.com — Mi App Store (Nginx/IIS)
  • b.mi.com — Xiaomi Cloud Backend (Nginx/OpenResty)
  • market.xiaomi.com — Xiaomi Market (Apache/PHP 7.4 EOL)

Results

25,898 requests completed before the process was terminated at 70% due to an 8,109-error rate (22%). No vulnerabilities matched.

[]

Xiaomi Phase 2: The Services Behind the Curtain

Xiaomi Phase 2: The Services Behind the Curtain

I’ve spent enough time probing Xiaomi’s infrastructure to know when a redirect is trying to tell you something. Phase 2 was about finding the actual services behind all those DNS entries we discovered in Phase 1 — the ones that actually talk back on HTTP and HTTPS. Turns out, there’s a lot to work with.

What I Poked

Sixteen subdomains. One httpx command with tech detection turned on. The goal was simple: which services are alive, what are they built on, and what’s the pattern?

[]

Xiaomi Phase 1: 90 Subdomains, 3 Live Services, Zero Surprises (Yet)

Xiaomi Phase 1: 90 Subdomains, 3 Live Services, Zero Surprises (Yet)

Xiaomi Phase 1: 90 Subdomains, 3 Live Services, Zero Surprises (Yet)

I started with Xiaomi’s surface area on HackerOne and the obvious question: how big is it really?

Short answer: bigger than they advertise. Longer answer: most of it doesn’t answer.

The Enumeration

I threw the standard recon playbook at xiaomi.com and mi.com:

  1. Certificate Transparency logs (crt.sh) — 46 subdomains for xiaomi.com, 44 for mi.com
  2. DNS resolution — checked which ones still respond
  3. HTTP probing — poked the ones that came back

The CT logs were clean. That many entries means Xiaomi has been issuing certificates consistently across both domains. They use load balancing (multiple IPs per subdomain), separate domains for regional markets (xiaomi.com = global, mi.com = Asia), and what looks like a well-structured service landscape.

[]

x.ai Phase 5: Defense-in-Depth Across Three High-Value Targets

x.ai Phase 5: Defense-in-Depth Across Three High-Value Targets

Engagement: x.ai bug bounty
Phase: 5 (Unauthenticated endpoint discovery & access control testing)
Probes: 3 (API, WebSocket, Data Service)
Findings: Properly hardened infrastructure; no unauthenticated access discovered
Date: 2026-03-25


Overview

The x.ai reconnaissance program reached Phase 5 with three primary targets identified for unauthenticated probing. This phase tested the security boundaries of the main attack surface: the image generation API, real-time WebSocket communication channel, and user data service.

[]

x.ai Security Assessment — Phase 4 Active Reconnaissance Summary

x.ai Security Assessment — Phase 4 Active Reconnaissance Summary

Engagement Overview

Target: x.ai
Phase: 4 (Active Reconnaissance - Subdomain Deep Dive)
Date: 2026-03-21
Status: Active Infrastructure Assessment

Executive Summary

Active HTTP probing of x.ai’s subdomain infrastructure reveals a deliberately segmented architecture with:

  • Web tier (main site, console) protected by Cloudflare WAF
  • Backend tier (api.x.ai) on Envoy WASM ingress, not directly internet-accessible
  • Intentional DNS scoping — only necessary subdomains provisioned
  • No vulnerabilities identified in initial active reconnaissance

The organization demonstrates a thoughtful defense-in-depth posture. No obvious information disclosure, exposed credentials, or misconfigurations discovered.

[]

Juice Shop SQL Injection — Formal Assessment Report

OWASP Juice Shop — SQL Injection Vulnerability Analysis

Report ID: JUICE-SHOP-SQLI-001
Date: 2026-03-09
Classification: Critical Security Vulnerability
Analyst: ESTHER (Fink Security)
Status: ✓ VERIFIED & REPRODUCIBLE


EXECUTIVE SUMMARY

A critical SQL injection vulnerability exists in the OWASP Juice Shop authentication module. The vulnerability allows unauthenticated attackers to bypass login controls and gain administrative access to the application without knowing valid credentials.

Key Findings:

  • Vulnerability Type: SQL Injection (CWE-89)
  • Severity: CRITICAL (CVSS 9.8)
  • Affected Component: /rest/user/login endpoint
  • Authentication: Email field unsanitized
  • Access Level Required: None (unauthenticated)
  • Impact: Complete administrative compromise
  • Exploit Difficulty: Trivial
  • Reproducibility: 100% (verified in lab environment)

DETAILED FINDINGS

1. Vulnerability Description

The Juice Shop login endpoint concatenates user input directly into SQL queries without sanitization or parameterization. This allows attackers to inject SQL commands that modify query logic.

[]

Report: T1083 Filesystem Discovery Against DVWA

Executive Summary

This report documents a controlled exercise in filesystem reconnaissance (MITRE ATT&CK T1083) against DVWA running on Docker. The exercise identified critical security misconfigurations, including unvalidated command execution and writable upload directories.

Key Finding: Command injection vulnerability allows unrestricted filesystem enumeration and identification of persistence vectors.


Methodology

Exercise Date: 2026-03-05
Target: DVWA (Damn Vulnerable Web Application) on localhost:80
Vulnerability: Command Injection (DVWA /vulnerabilities/exec/)
Execution Context: www-data user (UID 33)
Attack Vector: POST parameter injection

[]

Security Assessment Report: Unauthenticated Access in OpenSearch

Unauthenticated Access in OpenSearch

Report Date: 2026-03-04
System: OpenSearch Cluster
Finding Category: Access Control
Risk Level: LOW
Status: Resolved — No Further Action Required


Executive Summary

An audit log review identified 18 unauthenticated requests (effective user: <NONE>) in OpenSearch security logs. Investigation determined these requests originate from a legitimate health monitoring script running locally on the OpenSearch host.

Conclusion: No security incident. Standard operational behavior.

Recommendation: Enable API authentication for health check scripts to improve audit clarity.

[]