Bilingual

Leaking the phone number of any Google user
a day ago
- The username recovery form on Google still works without JavaScript, using two HTTP requests to check if a recovery email or phone number is associated with a display name.
- Brute-forcing phone numbers is possible by using IPv6 address rotation to bypass rate limits, but datacenter IPs still face captchas due to JS disabled form restrictions.
- Using BotGuard tokens from the JS-enabled form with the No-JS form bypasses request limits, allowing efficient brute-forcing of phone numbers.
- Google's display name leak via Looker Studio enables attackers to get the victim's name without interaction.
- The full attack chain involves leaking the display name, obtaining the masked phone from the forgot password flow, and brute-forcing the phone number with optimized tools.
- Brute-forcing times vary by country: 20 minutes for the US, 4 minutes for UK, 15 seconds for Netherlands, and 5 seconds for Singapore, with potential reduction using hints from other services.
Skills That Don't Exist: A Large-Scale Study of Hallucinated Skill
14 days ago
- LLM agents recommend and install skills from open registries, but frequently hallucinate skill names that do not exist.
- Skill name hallucination enables supply-chain attacks, where adversaries pre-register malicious skills under fake names for victims to install.
- A large-scale study evaluated 15,000 prompts across 12 configurations, revealing hallucination rates averaging 36.0% for standalone LLMs and 36.9% for agents.
- Hallucinated names are not random; agents repeat the same fake names, providing reliable targets for hijacking.
- Defenses like retrieval grounding reduce hallucination but severely impact usability, highlighting a security-usability conflict.
- Fixing this vulnerability requires structural ecosystem changes, such as registry-level name reservations and verified recommendation pipelines.
Microsoft's Secure Boot has been broken for a decade and no one noticed
14 days ago
- Microsoft's Secure Boot protection, designed to prevent firmware infections on Windows and Linux devices, has been easily bypassed for most of its existence due to unrevoked, vulnerable shim images.
- ESET researchers discovered 11 old firmware images, or shims, dating back to at least 2013, that remain signed by Microsoft despite known vulnerabilities, allowing attackers to circumvent UEFI Secure Boot.
- Attackers can use these shims to install malicious firmware (bootkits) that persist through OS reinstallation or hard drive replacement, affecting both Windows and Linux users.
- Secure Boot was introduced in 2012 to counter bootkits, but its bypass has been simple, requiring only an old, trusted shim binary and basic UEFI knowledge, undermining this critical security feature.
- Many Linux users disable Secure Boot due to its ineffectiveness on most hardware, citing requirements like proper UEFI defaults and a fully local, auditable chain of trust that are rarely met on consumer-grade devices.

Hasty Briefsbeta

security vulnerability

Leaking the phone number of any Google user

Skills That Don't Exist: A Large-Scale Study of Hallucinated Skill

Microsoft's Secure Boot has been broken for a decade and no one noticed