Windows logon.scr hack

This is a tip that was posted in this forum for recovering a win2k admin password.

Here try this>
If you can log in as an account and it is FAT, drop to DOS start -> run -> cmd, at the C: prompt type the following (assuming default install locations)

C:\> cd \winnt\system32
C:\winnt\system32> copy logon.scr logon.scr.old
C:\winnt\system32> del logon.scr
C:\winnt\system32> copy cmd.exe logon.scr

Now log off the machine, logon.scr is the screen saver that will kick in after 15 minutes of not touching the keyboard/mouse at the logon screen. Wait 15-20 minutes and a DOS prompt with FULL SYSTEM rights will pop up, then just to
C:\> net user administrator <newpassword>
and then log in with the new account.

Try this, might work, as long as he didn't change default permissions on C:\winnt and C:\winnt\system32 you should be golden.
Let me know if this works.
Heavy_Deisel


I tried this out on my work PC. The command prompt came up as advertised. Though I received an "access is denied" error when I tried to change the administrator password or add a new local user, I was able to run regedit.exe and had permissions to modify the registry! I was also able to launch both applications (lotus notes and word) and mmc programs like the group policy editor (gpedit.msc) and Computer management (compmgmt.msc). I haven't really explored what could be done with this hack but it would be pretty easy to install a keystroke logger or a trojan to exploit this weakness. Does anybody have any suggestions for closing this loophole? I know the most obvious is to use NTFS and enforce permissions on files like logon.scr but my bosses insisted that we use FAT32 in order to be able to easily recover data in case of system crashes. I would also be curious as to how someone might use this exploit to gain local administrator access (outside of using a keystroke logger.) Any thoughts? Props out to Mickey05 and Heavy_Diesel for turning me on to this hack. Thanks.

remove del rights from logon.scr and you should be safe again ..

our systems use fat32 not ntfs.

all of the systems i administrate at the air force base use ntfs. for a while, i always installed it as my choice, but it is now a requirment by the dod. fat file systems are pretty much obsolete and any system running 2000 pro or xp should be installed with ntfs to optimize all of the operating systems options and security controls. not that ms will ever be secure or stable, but ntfs is slightly better from what i can tell.

Well, you could always reboot the box with a DOS 6.22+ boot disk, then modify the files, that way Win2K isn't there at all to get in the way.

Quote:

---

we use FAT32 in order to be able to easily recover data in case of system crashes.

---

yer bosses are weenies... :D (they ever heard of backups???)

the whole point of security procedures is to make things harder...and yes..that sometimes means it's harder for everyone...i've got 30 people here i have to give out new 12 digit complex passwords for them to remember..that's not easy...for them or me...but it is secure-(er)...i could give everyone a pwd like.."password"...real easy to remember..but...

ntfs is far superior in many ways...including the fact that is quite a bit more fault tolerant (so your data is actually less likely to get fu-ed in the first place...you can also use EFS to encrypt sensitive data...of course that's really hard to get back if you don't have system in place...

soooo..

have systems in place...go ntfs...or be unsecure...know that you can get your data easily...but so can anyone else...

you could probably just rename cmd.exe to something else. Not many people have any need to use it, other then the admins. So if you renamed it to prompt.exe, and only let the admins know it, you will probably be safe. Most people who know about the hole are not going to take time to find what you renamed it. They will just be like "Oh wow, no cmd.exe, gotta find a different script." You could also move cmd.exe so it is in a location that is not in the users path. Only the Administrators path, or no path at all. So you will have to type c:\progs\cmd.exe to start it or something along those lines.

Quote:

---

Originally posted here by zigar



yer bosses are weenies... :D

---

that sums it up quite nicely.

I'd trade you to support only 30 users. My team supports over 4000 desktops in over 40 locations! My company likes to talk like security is important but when it comes down to it, we choose convinience over security every time.

Thanks for the idea Souleman. Moving CMD.EXE is the simple solution I was looking for...

but if you move the cmd.exe program another attempt at success that i can think of would be to run a system with NT already and just upload a cmd.exe and rename it to logon.scr
if thats an off the wall suggestion excuse me cause im not very familiar with NT....never liked it...this bug is an example why heh.

that's a good point bios. the problem here is not so much NT because using ntfs would greatly reduce the risk that this hack could be implemented.

oh.. is dis Win2000 Pro??

sonic: windows 2000 any version is the new NT distro. meaning its Windows NT 5.0. a basic system information request will tell you that.

sonic: yes I'm referring to Win2K pro but supposedly this same hack works on NT 4 though I have yet to try it.

hmm.. well don't know much about the debate going on here. I'm going to try out this hack
tommorow. Somtimes if you can visualize a problem you can find a better solution.

Nice vulnerability though

Quote:

---

Originally posted here by bios
sonic: windows 2000 any version is the new NT distro. meaning its Windows NT 5.0. a basic system information request will tell you that.

---

yes it is basically NT 5.0 in that it is the system built for a networked enviroment, but it is signifantly different from the previous NT systems in how it deals with security.

so... the best thing to do here - except converting to ntfs - is to rename your cmd.exe and copy an empty file (or some other harmless prog.) to cmd.exe
(it would be funny to create some small prog. that tells the hacker he's been logged... )

If a hacker attemps this hack this would at least have 'm wondering why it doesn''t work ..
It's very easy to solve though..

M$ should have created a way to disable the logon.scr ...

even tho ntfs reduces the risk of this happening would there be ne way to get around it to implement this????

cmd.exe is not the only executable that works with this trick. You can basicly use any executable. On NT4 you can use musrmgr.exe, on win2k it should work with msc.exe.

And what about putting in an executable I made myself? This exe could create a new local account and give it admin rights. Should be really easy to program. For some added stealth you could run the renamed logon.scr so noone will notice ;)

The ONLY way to prevent hacks like this is to switch to ntfs and put some solid ACLs on %windir% and everything underneath.

It's worth noting that:

1. This attack does not work if the permissions on the NTFS filesystem and the registry are correctly setup, as they will be if you do a fresh install of NT4 (+win2k, winxp pro etc)
2. An alternate method of performing this attack is to modify a key in the registry to change the logon screensaver to something else. Renaming cmd.exe is lame. Many things rely on cmd.exe being called that and hence will not work (probably including much of Microsoft's own stuff)
3. Anyone with console access who can boot off a floppy can easily bypass the permissions on the registry and do this hack.
4. That isn't really a problem, because with console access they can do anything anyway

Don't rename cmd.exe or you will have real problems.

FAT is an unsecured FS bottom line. You could use registry keys to deny acces to the control panel->display after turning off the screen saver,but some one with physical access could just as easily use a boot floppy to copy the .sam as replace the screen saver. Just comes down to risk management. Tell your boss to quit being a weenie and use NTFS (at least for the System drive). Depending on the security required I would personally delete all dangerous binaries such as cmd.exe tftp.exe net.exe finger.exe ,etc,etc. or move them to a seperate location and allow ONLY the admins execute rights. (System cannot take ownership so buffer overflow attacks will be much harder to achieve) Although I have not had problems with removing these files you may find Win2000 likes to put them back for you, this is because copies are stored in dllcache by Windows File Protection which can be disabled here:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\
CurrentVersion\Winlogon

You must set (or create) the SFCDisable to REG_DWORD 'ffffff9d'

good luck!


-Maestr0

Quote:

---

Originally posted here by Maestr0
(System cannot take ownership so buffer overflow attacks will be much harder to achieve)

---

This is BS. File ownership has absolutely nothing to do with the security context the file will be run under. SYSTEM would still be able to run the file and it would still contain an exploitable buffer overflow.

anyone tried running mmc from that command window? it seems to me that could give you a few choice options as far as security is concerned, I'm going to try it right now

SirDice,
I think you may have misunderstood my comment. I said to allow execute permissions on cmd.exe for admin ONLY(This means deny SYSTEM). That means SYSTEM cannot execute cmd.exe OR take ownership of cmd.exe, this way if someone has found a buffer overflow in a program running under a SYSTEM context then the code will not be able to execute cmd.exe


-Maestr0

EDIT: I see that the original statement was unclear, the statement should have read:
"(System cannot take ownership so buffer overflow attacks <which execute these binaries> will be much harder to achieve)"

im just interested if u tried this on service pack 3 or not, let me know

Quote:

---

Originally posted here by Maestr0
SirDice,
I think you may have misunderstood my comment. I said to allow execute permissions on cmd.exe for admin ONLY(This means deny SYSTEM). That means SYSTEM cannot execute cmd.exe OR take ownership of cmd.exe, this way if someone has found a buffer overflow in a program running under a SYSTEM context then the code will not be able to execute cmd.exe


-Maestr0

EDIT: I see that the original statement was unclear, the statement should have read:
"(System cannot take ownership so buffer overflow attacks <which execute these binaries> will be much harder to achieve)"

---

That's much clearer and correct ;) It's all a matter of payload. So I think this would only protect you from prebuild exploits (scriptkiddie tools?).

I'm not sure about not being able to take ownership. I think you can still take ownership and nuke the ACL in the process (mental note: must try this out).

Quote:

---

Originally posted here by kroltz
im just interested if u tried this on service pack 3 or not, let me know

---

Servicepack/hotfix level has nothing to do with it. The default screensaver (when noone is logged on) will run in the SYSTEM context (this is by design). So if you have no or bad ACLs on %windir% this would still work.