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.
Attack Requirements
Present
AT
The successful attack depends on the presence of specific deployment and execution conditions of the vulnerable system that enable the attack. These include: A race condition must be won to successfully exploit the vulnerability. The successfulness of the attack is conditioned on execution conditions that are not under full control of the attacker. The attack may need to be launched multiple times against a single target before being successful. Network injection. The attacker must inject themselves into the logical network path between the target and the resource requested by the victim (e.g. vulnerabilities requiring an on-path attacker).
Privileges Required
High
PR
The attacker requires privileges that provide significant (e.g., administrative) control over the vulnerable system allowing full access to the vulnerable system’s settings and files.
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
Unchanged
S
An exploited vulnerability can only affect resources managed by the same security authority. In the case of a vulnerability in a virtualized environment, an exploited vulnerability in one guest instance would not affect neighboring guest instances.
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.
From the article:
"Access to the at command varies, on some installations of Windows,
even the Guest account can access it, on others it's limited to
Administrator accounts."
But it's limited to members of the Administrators group by default.
Anyone who is an administrator can make their system insecure by
degrading the permissions to make them less restrictive than the
vendor intended them to be. On any operating system, built on any
security model, ever.
On a system where the administrator either knows what he/she is doing,
or doesn't mess with things that he/she doesn't understand, this does
not appear to be exploitable. And no security model can combat an
incompetent administrator. Consequently, this does not appear to be a
real vulnerability--unless you are saying that there is a bug in
Windows that causes it to sometimes be installed, out of the box, with
the guest user able to use the at command? (That would certainly merit
an advisory, if true, but the paper focuses on how to use the at
command, i.e., on what to do *once* you have obtained SYSTEM access.
Can you give more detailed information about cases where
non-administrative users are able to use the at command?)
I also think that it is misleading to say that SYSTEM can do things
that an administrator can't, since any administrator can execute code
as SYSTEM by installing a service to run as SYSTEM. Even if the task
scheduler is disabled, someone with administrative privileges can
still install system services. All the behavior that the article
describes seems to be by design and none of it seems to constitute a
security threat. Am I wrong?
By the way, on a related note, if the goal is to obtain a SYSTEM
desktop for administrative purposes, a more elegant way to do it is to
install a service that runs cmd.exe as SYSETM (using Microsoft's
instsrv.exe and srvany.exe utilities, search MS Knowledge Base for
more info), and then quit explorer.exe and related applications and
launch explorer.exe from the command prompt. (Or if you are running
Server 2003, I think you can actually run programs as SYSTEM with
RunAs.) This is essentially the same as the method described in the
article, but it doesn't use the task scheduler for a purpose not
relating to the scheduling of tasks, and works even if the task
scheduler is disabled or run with reduced priviledges.
-Eliah
On 6/11/06, zipk0der wrote:
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=
> = Advisory: Windows XP Task Scheduler Local Privilege Escalation
> =
> = Author: Daniel Hckmann (zipk0der) zipk0der (at) pandora-security (dot) com [email concealed]
> =
> = Released at: http://www.pandora-security.com
> =
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=
>
> 1. Overview.
>
> In Windows XP, the task scheduler service runs as "SYSTEM" (local service);
> this is akin to running cron as root. Any processes spawned by the
> task scheduler
> inherit "SYSTEM" permissions. Using command line tools, we can kill the Windows
> desktop (explorer.exe) and restart it running under "SYSTEM". Once running under
> "SYSTEM" we have full control of the machine, and can do things even
> Administrators
> can't. Also included is a recommended fix. Read the full paper at the
> link below.
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=
>
> Direct link to the original paper discussing this issue in detail...
>
> http://www.pandora-security.com/forum/viewtopic.php?t=2093
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=
>
> Sincerely,
>
> Daniel Hckmann - R&D Director, Pandora Security
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