The vulnerable system is not bound to the network stack and the attacker’s path is via read/write/execute capabilities. Either: the attacker exploits the vulnerability by accessing the target system locally (e.g., keyboard, console), or through terminal emulation (e.g., SSH); or the attacker relies on User Interaction by another person to perform actions required to exploit the vulnerability (e.g., using social engineering techniques to trick a legitimate user into opening a malicious document).
Attack Complexity
Low
AC
The attacker must take no measurable action to exploit the vulnerability. The attack requires no target-specific circumvention to exploit the vulnerability. An attacker can expect repeatable success against the vulnerable system.
Privileges Required
Low
PR
The attacker requires privileges that provide basic capabilities that are typically limited to settings and resources owned by a single low-privileged user. Alternatively, an attacker with Low privileges has the ability to access only non-sensitive resources.
User Interaction
None
UI
The vulnerable system can be exploited without interaction from any human user, other than the attacker. Examples include: a remote attacker is able to send packets to a target system a locally authenticated attacker executes code to elevate privileges
Scope
S
An exploited vulnerability can affect resources beyond the security scope managed by the security authority that is managing the vulnerable component. This is often referred to as a 'privilege escalation,' where the attacker can use the exploited vulnerability to gain control of resources that were not intended or authorized.
Confidentiality
High
C
There is total information disclosure, resulting in all data on the system being revealed to the attacker, or there is a possibility of the attacker gaining control over confidential data.
Integrity
High
I
There is a total compromise of system integrity. There is a complete loss of system protection, resulting in the attacker being able to modify any file on the target system.
Availability
High
A
There is a total shutdown of the affected resource. The attacker can deny access to the system or data, potentially causing significant loss to the organization.
Google Chrome Cleanup Tool DLL HijackingHi @ll,
Google's software_removal_tool.exe alias Chrome Cleanup Tool loads
and executes several DLLs from its "application directory" during
runtime:
* Windows XP:
SetupAPI.dll, NTMarta.dll, ClbCatQ.dll, SRClient.dll, UXTheme.dll,
RASAPI32.dll, HNetCfg.dll, IPHlpAPI.dll, RASAdHlp.dll, XPSP2Res.dll,
RichEd20.dll, SENSAPI.dll
* Windows 7:
NTMarta.dll, SRClient.dll, DWMAPI.dll, UXTheme.dll, IPHlpAPI.dll,
DNSAPI.dll
Additionally the following DLLs are loaded from its "application
directory" during load-time:
WS2_32.dll, WS2HELP.dll, PSAPI.DLL, WINMM.dll, WINHTTP.dll,
ProfAPI.dll, Secur32.dll, Version.dll
For software downloaded with a web browser the application
directory is typically the user's "Downloads" directory: see
<https://insights.sei.cmu.edu/cert/2008/09/carpet-bombing-and-directory-poisoning.html>,
<http://blog.acrossecurity.com/2012/02/downloads-folder-binary-planting.html>
and <http://seclists.org/fulldisclosure/2012/Aug/134> for
"prior art" about this well-known and well-documented vulnerability.
If an attacker places the DLLs named above in the users "Downloads"
directory (for example per drive-by download or social engineering)
this vulnerability becomes a remote code execution.
See <http://seclists.org/fulldisclosure/2015/Nov/101>
and <http://seclists.org/fulldisclosure/2015/Dec/86>
plus <http://seclists.org/fulldisclosure/2015/Dec/121>
Proof of concept (verified on Windows XP and Windows 7 using
version 2.46 and 6.44.3.0 of software_removal_tool.exe):
1. visit <http://home.arcor.de/skanthak/sentinel.html>, download
<http://home.arcor.de/skanthak/download/SENTINEL.DLL> and save
it as UXTheme.dll in your "Downloads" directory, then copy it
as RichEd20.dll, ClbCatQ.dll, SetupAPI.dll, DWMAPI.dll etc.;
2. download software_removal_tool.exe and save it in your
"Downloads" directory;
3. run software_removal_tool.exe from the "Downloads" directory;
4. notice the message boxes displayed from the DLLs placed in
step 1.
PWNED!
5. create empty files WS2_32.dll, WS2HELP.dll, PSAPI.DLL, WINMM.dll,
WINHTTP.dll, ProfAPI.dll, Secur32.dll, Version.dll in your
"Downloads" directory;
6. run software_removal_tool.exe from the "Downloads" directory.
DOSSED!
This denial of service can easily turned into arbitrary code
execution too: just create a DLL with all the entries referenced
from software_removal_tool.exe.
For this well-known (trivial, easy to avoid, easy to detect and
easy to fix) beginner's error see
<https://capec.mitre.org/data/definitions/471.html>,
<https://technet.microsoft.com/en-us/library/2269637.aspx>,
<https://msdn.microsoft.com/en-us/library/ff919712.aspx> and
<https://msdn.microsoft.com/en-us/library/ms682586.aspx> plus
<http://blogs.technet.com/b/srd/archive/2014/05/13/load-library-safely.aspx>:
| To ensure secure loading of libraries
| * Use proper DLL search order.
| * Always specify the fully qualified path when the library location
~~~~~~
| is constant.
Additionally software_removal_tool.exe uses an UNSAFE temporary
directory %TEMP%scoped_dir<pid>_<random> to extract and run
%TEMP%scoped_dir<pid>_<random>ChromeRecovery.exe
For this well-known (trivial, easy to avoid, easy to detect and
easy to fix) beginner's error see
<https://cwe.mitre.org/data/definitions/377.html> and
<https://cwe.mitre.org/data/definitions/379.html> plus
<https://cwe.mitre.org/data/definitions/426.html> and
<https://cwe.mitre.org/data/definitions/427.html>
stay tuned
Stefan Kanthak
Timeline:
~~~~~~~~~
2016-01-28 sent vulnerability report to <[email protected]>
NO reply
2016-02-05 resent vulnerability report to <[email protected]>
2016-02-10 reply from Google security team:
"Chrome is not in scope for the Google VRP program, and has
a separate bug reporting process."
2016-02-10 resent vulnerability report to <[email protected]>
NO reply, not even an acknowledgement of receipt
2016-02-24 resent vulnerability report to <[email protected]>
and <[email protected]>
2016-02-24 reply from Google security team:
"This is working as intended."
Google want's to have your Windows pwned!
2016-02-24 completely clueless reply from Chromium telling that they
didn't read <http://seclists.org/fulldisclosure/2015/Nov/101>
and <http://seclists.org/fulldisclosure/2015/Dec/86>
plus <http://seclists.org/fulldisclosure/2015/Dec/121>:
"I'm also unsure what defenses you intended to propose here,
because the loader definitely pulls in many (all?) of those
imports prior to any application code running -- so things
like SetDefaultDllDirectories simply aren't a viable defense."
2016-02-24 OUCH!
The DLLs loaded during runtime (see steps 1 to 4) don't have
any exports, there is no import which can (or need to) be
pulled by the loader.
2016-02-26 another nonsense reply from Chromium
2016-02-26 report published
obviously neither Google nor Chromium seem to be interested
in fixing their vulnerable cleanup tool.
STAY AWAY FROM SUCH CRAPWARE!
This information is provided for TESTING and LEGAL RESEARCH purposes only. All trademarks used are properties of their respective owners. By visiting this website you agree to Terms of Use and Privacy Policy and Impressum