|
楼主 |
发表于 2008-10-9 23:08:38
|
显示全部楼层
|阅读模式
来自 山东省青岛市
针对2003服务器,只要对方的WS启用,都可从GUEST权限提升至SYSTEM权限。
已测试。
估计也马上会修补了,要用的抓紧时间 嘿嘿。
附件我就不传了- - 呵呵...去我bolg里有下~ 做个广告不介意吧bolg地址 www.visonc.cn
这0day最新的~
Who am I?
• Argeniss Founder and CEO
• I have been working on security for 7 years
• I have found and helped to fix hundreds of
vulnerabilities in software such as MS Windows,
MS SQL Server, Oracle Database Server, IBM
DB2, and many more...
• I have researched and created novel attacks and
exploitation techniques
• I have spoken around the world at most
important security conferences
• I have never written a book
Agenda
• Introduction
• What is impersonation and what are tokens?
• Windows XP and 2003 services security
• Windows XP and 2003 services security
weaknesses
• Windows Vista and 2008 services security
• Windows Vista and 2008 services security
weaknesses
• Token Kidnapping in action
• Conclusions
Introduction
• In the beginning all Windows services ran as Local
SYSTEM account
– Compromise of a service==full system compromise
• Then MS introduced NETWORK SERVICE and
LOCAL SERVICE accounts
– Compromise of a service!=full system compromise
• Then with Windows Vista and 2008 new
protections were introduced and some previous
weaknesses were corrected
• But as we are going to see Windows is still not
perfect...
What is impersonation and
what are tokens?
• Impersonation is the ability of a thread to
execute using different security information than
the process that owns the thread
– Threads impersonate to run code under another user
account, ACL checks are done against the
impersonated users
– Impersonation can only be done by processes
with the following privilege:
• “Impersonate a client after authentication”
(SeImpersonatePrivilege)
–When a thread impersonates it has an associated
impersonation token
What is impersonation and
what are tokens?
• An access token is an object that describes the
security context of a process or thread
– It includes the identity and privileges of the user
account associated with the process or thread
– They can be Primary or Impersonation tokens
• Primary ones are those that are assigned to
processes
• Impersonation ones are those that can be get
when impersonation occurs
– Four impersonation levels: SecurityAnonymous,
SecurityIdentity, SecurityImpersonation,
SecurityDelegation
Windows XP and 2003 services
security
• Services run under
– LOCAL SYSTEM, NETWORK SERVICE, LOCAL
SERVICE and user accounts
• Services seemed to be armoured
– Processes are created with “special” permissions
• A service running under “X” account can't directly
access another service running under the same
account
• Gentle Security found that services were
improperly protected and that service account has
WRITE_DAC permissions on service
Windows XP and 2003 services
security
• All services can impersonate
– If a service can get a SYSTEM impersonation
token the game is over
• This doesn't happen always in all services
– Impersonation takes place mostly during Inter
Process Communication (IPC) using Local
Procedure Call (LPC), Named Pipes, etc.
– Impersonation can be limited by clients by setting
proper options in the used functions
Windows XP and 2003 services
security weaknesses
• While service processes are not well protected,
threads aren't either*
– Service threads have default account permissions
– A service running under X account can access
threads of another services running under the
same account
• Service X can run arbitrary code on service Y
• Service X can get impersonation tokens from
service Y
*Brett Moore from Insomnia Security (www.insomniasec.com)
independently found the services thread permissions issue
Windows XP and 2003 services
security weaknesses
• While service processes are not well protected,
threads aren't either
– Threads from RpcSs service process (runs under
NetworkService) can be accessed
• This process always has impersonation tokens from
many different accounts including SYSTEM
• Services will need first to get NetworkService
impersonation token and then use it to access RpCSs
threads
Windows XP and 2003 services
security weaknesses
• Calling APIs that interacts with a service ends
up getting the service account impersonation
token
– Calling process only needs to be able to
“impersonate”
– If impersonation tokens have higher privileges
then calling process can elevate privileges
– Problem present in MSDTC (runs under
NetworkService)
• Call DtcGetTransactionManagerEx() to get
NetworkService impersonation token
– The function starts MSDTC if not running
Windows XP and 2003 services
security weaknesses
• Both weaknesses combined lead to full system
compromise just having Impersonation rights
– Any service can run code as SYSTEM
– Any ASP web page, CGI, etc. on IIS can run code
as SYSTEM
– Any SQL Server administrator can run code as
SYSTEM
– Etc.
Windows Vista and 2008
services security
• Huge improvements in latest Windows versions
(at least in theory)
• Session 0 isolation
– Not big deal, mostly protect against Shatter
attacks
• Least privilege
– Not big deal, most Windows services requires
Impersonation privileges
• Per service SID
– Nice feature, now the service process it's really
protected and its resources can be armoured
Windows Vista and 2008
services security
• Per service SID
– Service running under X account can't access
other service resources no matter the service is
running under same account
– Threads are now properly protected
• Write restricted token
– Nice feature, service can have write access to
resources only if explicitly granted to the service
SID, logon SID, Everyone SID or write-restricted
SID
Windows Vista and 2008
services security
• Restricted network access
– Nice feature
– Services can only accept connections on specified
ports and protocols
– Services can only make connections to specified
ports and protocols
– Services can be restricted to have no network
access
– Implemented as firewall rules
• Can't be disabled after service starts
Windows Vista and 2008
services security weaknesses
• Per service SID weaknesses
–While regular threads are properly protected,
threads from thread pools are not
• Service running under X account can submit work to
thread pools on other services running under same
account
• This means arbitrary code execution bypassing per
service SID protection
Windows Vista and 2008
services security weaknesses
• Per service SID weaknesses
–While service processes are protected some
regular processes running under LOCAL SERVICE
and NETWORK SERVICE are not
• Service process running under X account can access
regular processes running under same account
– Services can execute arbitrary code on other
processes
– WMI processes have this problem
|
|