Security Incidents mailing list archives

TsInternetUser priv. escalation; blank passwords; service passwords


From: Curt Wilson <netw3_security () hushmail com>
Date: 23 Dec 2002 08:05:32 -0000




What are the circumtances for many of the default accounts 
(TsInternetUser, IUSR_, IWAM_, krbtgt, Guest for instance) having blank 
passwords? I realize that all of the security checklists, etc. always 
recommend disabling the Guest account, etc. but a system I know of has 
recently been "hacked" by the attacker adding TsInternetUser into the 
administrators group and then using Term Services to login interactively 
using the TsInternetUser account. Currently, it appears that the 
TsInternetUser account has a blank password. I was under the impression 
that the TsInternetUser account was only needed when using TermSvc in 
application server mode, and in that case the password is changed 
frequently (daily if I recall correctly) by the system, as discussed in a 
MS knowledge base Q article. In any other instance the account can be 
deleted without breaking anything, based on my experiences so far.

What I don't understand is why some installs I've seen feature blank 
passwords and others dont, when the installation process was basically the 
same...win2k terminal services in remote administration mode. Installed 
from the same media, one system gets a blank password and the other gets a 
strong password. Why is this? 

I've not found any good docs on this phenomenon but if I've missed them 
please help point the way. I'm ruling out the obvious, because I know that 
the end user did NOT change any passwords after their installation and 
would not have assigned a password to these accounts manually.

On one of my personal lab installs, TsInternetUser is using a strong 
password; I've got the 2nd half of the password cracked by using LC4. What 
I don't understand is why my clients system featured (ha) a blank password 
for this account. I suppose that an audit of the actual processes taking 
place when these services are installed could be useful here. It would be 
useful for pen testing processes to know the method that the OS uses to 
create these passwords. Any tips on this?

I've also noticed blank passwords in various places for the IUSR and IWAM 
accounts, as well as a blank password for the krbtgt account on my test AD 
domain controller. When attempting to login via TermSvc with krbtgt and a 
blank password, a password change prompt comes up, but does not seem to 
allow interactive access, perhaps due to the blank password being 
the "old" password that the pw change GUI was not accepting? I've tried 
using krbtgt in net use commands to test the functionality of this account 
and to see what it's limits might be, but I'm still testing. Anyone out 
there beat me to this care to share your results?

On a slightly different but related note, is anyone aware of a canned 
exploit for IIS or SQL Server that adds the TsInternetUser into the 
Administrators group? I've been tasked with discovering the origin of a 
specific system attack in a non-hardended system (it does have all the 
current patches and hotfixes however, but we all know that's not enough). 
The attacker deleted their event viewer logs and cleaned up after 
themselves better than most that I've seen. Due to timing logistics I was 
unable to get a disk image or any type of memory dump, with the exception 
of some stack dumps from SQL Server that happened around the same time as 
the penetration. I'm currently analyzing these (and could use some help) 
to determine what happened. If anyone is good at analyzing these types of 
dumps, or can correlate these dumps with any of the SQL Server exploits, I 
would appreciate any assistance. 

Thanks
Curt Wilson
Netw3 Security
www.netw3.com

----------------------------------------------------------------------------
This list is provided by the SecurityFocus ARIS analyzer service.
For more information on this free incident handling, management 
and tracking system please see: http://aris.securityfocus.com


Current thread: