lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Date: Fri, 21 Aug 2020 20:11:03 -0700
From: Benjamin Floyd <benjamin.floyd253@...il.com>
To: fulldisclosure@...lists.org
Subject: [FD] Google Chromecast Auth Bypass/RCE

Problem:  Most modern Google-based smart devices run some form of
Chromecast (and a version of the Chrome browser to play content).  All of
their Chromecast devices, Google Home, Nest, and basically any Google smart
device, as well as Android TVs with Chromecast built in run Chrome.  In
Google's Cast Developer Console, you can add arbitrary Chromecast devices
for development purposes via serial number (which is on the outside of
device boxes).  You could also find it on devices themselves, or could
socially engineer people to give you their serial number (because who would
care about something like that?).

Vuln:  Once added, you can push arbitrary code to these devices using the
Cast Developer Console (it is $10 to obtain access).  It requires 0 user
interaction.  They typically run a version of the Chrome browser that is
2-3 months+ out of date, which means there are DOZENS of existing sandbox
escape vulns WITH code.  There is no ASLR/DEP/Stack cookies/etc on most (if
not all) smart devices.  A sandbox escape would likely be all you needed,
as it seems the processes are running as root.  You could implant an
ephemeral payload on the device granting access to their internal network,
send yourself the user's session cookies, force payments (possibly, purely
speculative as of yet).

Responsible disclosure: I reached out to Google back in April 2020 to
address the issue.  They accepted the bug, did nothing with it, and
their own SLA period lapsed.  I re-submitted the bug 4 months later after
calling them out on Twitter (via my handle @pwna5aurus; stop by and say hi)
and they acknowledged it and asked me to submit another bug to their VRP.
They triaged it, decided it is not a security vuln (lol) and are still
debating whether to fix it or not, as of 8/21/2020.

Have fun!

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Powered by blists - more mailing lists