A question about LUAs and Malware

Suppose I set up a LUA in Windows XP with the following 'enhancements' :

1) Limit it's write privileges to it's user directory

2) Disable the open autostart values using KAFU

3) Using the Security Tab, make sure ADMIN takes ownership of all objects in and below root directory

4) Use 'secedit' (secedit /configure /db %temp%\temp.sdb /cfg %systemroot%\inf\defltwk.inf /areas filestore AND secedit /configure /db %temp%\temp.sdb /cfg %systemroot%\inf\defltwk.inf /areas regkeys) to make sure nothing with user privileges has write permissions where it shouldn't

5) Use the following command to disable all autorun/play (REGEDIT4
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYSoesNotExist")

Now what's the worse that can happen? What types of viruses/trojans/malwares are still able to infect the LUA with the above setup?

EDITED to include more info

 

I understand your question to refer to malware that has intruded w/o your permission, since to install a program, you would grant Administrative privileges.

The question is hypothetical, since without testing actual exploits you cannot know what might happen. The sophistication of malware once installed has grown exponentially, and from my own perspective, I would not feel safe relying solely on LUA or UAC.

I'm not sure what your enhancement 4) is, but if Software Restriction Policies, I would feel safer. Another user with SRP has tested many sites with exploits and nothing has succeeded.

----
rich

 

Rmus for more info on step 4 see here toward the bottom of the post.

I guess what I'm trying to say is how much damage can things like Vundo (and it's variants) do with the above setup?

 

LUA is pretty restricted. The failure of LUA is as Rmus says, the necessity to elevate privelages to a state of admin. At this point, you are compromised if you don't explicity know what the executable is doing. Sure, the installation of adobe flash is probably trusted. As is Firefox, you know. It is the unsure thing that wants admin rights that the danger lies.

As you state, locking down the autostart keys, being sure the admin group owns everything is great.

I am curious on the secedit portion. That is using a security template, I think Default Workstation. Have you done this? Have you seen issues with existing User accounts being problematic? If not carefully implemented, those security templates can reset all ownerships and rights of users and power users. Admins are not usually affected but Users are often. From my experience anyway. Can you explain why (technically) you chose to use that particular template rather than security setup or compatws ? You are aware those templates change users rights around, but do you understand implicitly what each actually does? Really, I would love to know what you know, because I have studied those a lot and they can be quite tricky to fully comprehend thier ramifications.

Also, maybe this has been said, but if you create your User account from the User Accounts tool located in control panel, you are creating a Power User. If you create it from the Computer Management snap-in, you create a User or LUA, truly. I read that recently on msdn or technet. I was not aware of that.

And what is the worst that can happen? I myself believe that if you can successfully stay in Userland, and recover ownership the User might have had and give to admin, and also lock down all the autostarts, you are in pretty good shape. And follow Rmus's advice of knowing what you elevate to admin. My concern with your method above would be what is actually the defltwk template is doing. I don't have that on my XP Pro machines. What version do you have? Can you PM me the actual .inf file?

Very nice topic Zopzop.

Sul.

 

Oh, nice find on that defltwk.inf file you or Tlu or whoever. I had not seen that one. It is chock full of comments. The security templates I have tampered with were not commented like that. Wow. This opens some new ideas.

Thanks for the thread Zopzop.

Sul.

 

LOL Sully, I have no idea what secedit does, I just ran the commands because Tlu recommended it if you made a previously Admin account into a Limited account.

This is news to me I learn something new everyday

That's the thing, nothing will ever be elevated to admin....ever. This setup was a thought experiment to see how effective a LUA with the above mentioned enhancements would be vs malware.

 

For example, the above setup would allow me to install Google Chrome but (if I'm reading this correctly) would completely cripple vicious trojans/adware like Vundo.

Unless I'm understanding this wrong, a limited user can't :

1) affect HKLM registry keys at all
2) (with the above setup) create/delete/edit any files outside it's user directory
3) (with KAFU) create any autostart entries whatsoever

Now with those restrictions suppose someone accidentally downloaded a fake .mp3 file from Limewire (the .mp3 file is really trojan.vundo or one of it's many variants). He/she tries to play it and it executes. According to this info on Vundo. What's the worst that can happen with the following setup?

Vundo won't be able to :

1) create it's files in %WINDIR%
2) affect any HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ entries
3) affect any HKEY_LOCAL_MACHINE\ entries

Vundo is effectively neutered no?

 

For the most part, yes. I haven't been able to infect myself with any of the variants yet, but I also employ SRP. There are places it writes to that a LUA will allow, but the consequences are far less obviously.

 

My understanding of LUA (and UAC) is that a piece of malware may execute but would be prevented from writing to various parts of the system.

Whereas, SRP (I assume this is one of your enhancements) would deny the malware from executing, as shown here:

​

The person who tested this exploit for me runs as Administrator. His rationale is that if the malware cannot execute, then nothing else is needed.

----
rich

 

Have you ever seen this?

Sul.

 

That's the thing, I purposely didn't want SRP to be part of the experiment. I was wondering out loud if a LUA with the above enhancements would survive various deadly malware (like vundo).

And here's some more questions if anyone can help me :

1) What does the syntax %XXXX% mean? For example what does %System%, %Temp% , and %SystemDrive% mean in regard to directories where some viruses try to copy themselves.

2) Some viruses "infect" executables or other file types on a drive, in a LUA setup as mentioned in the first post (ie the Admin owns every object in and under the root directory), what happens? Does the virus infect all executables/files types on the drive? Or Does it only infect executables/file types in the LUA user directory (meaning every other executable/file type is immune)?

PS Sully do you still want a copy of that defltwk.inf file?

 

The best way to answer your last post zopzop is to create a LUA on your own test box and (try to) infect it with all the latest junk out there. See where the malware writes to or tries to write to. That has got to be the best learning tool I've ever come across. That will also answer your question regarding the environment variable locations.

 

With you setup, zopzop, nothing bad can happen to your system:
- no driver nor rootkit can install
- no malware can survive upon reboot, provided all the autostart values are protected (and I am not sur about it).
- no program can be modified as it is protected by write access.

All this of course in absence of any vulnerability,permitting an priviledge escalation...

But the main problem doesn't reside in the protection of the OS, but in the protection of your data.
This setup will absolutely not protect you against data theft, data destruction...
As long as you don't store any sensitive data on this kind of setup, everything is OK.

 

Thank you Lucy, this is what I basically was trying to get at (the safety of the system). By the way Lucy, you said you weren't convinced that all autostart locations were covered. Do you know of any that spots in the registry that are missed by both the LUA and KAFU?

Yeah I don't care what happens to the data in the user account as long as the system is unfazed and the user's account itself isn't compromised.

 

Check on sysinternals autoruns: there are many more than the 6 locations given by tlu under HKCU. But basically, one can imagine to apply the same steps given by tlu to these other HKCU locations, or at least to check ownership and user rights.

This idea is only provided as is without any insurance it won't s***w anything!

 

Yes, I've been wondering if it might be possible to achieve a secure LU setup using only file permission restrictions, without SRP. The main problem has goto be the LU Docs n Settings folder - the classic place for progs like crome to run their exes. This is where SRP comes into its own, and is arguably the only place you really need it, if your file perms are otherwise tight.

I may be wrong, but I thought the idea with KAFU.EXE was to lock down the autorun locations available to LU. There may be more listed in "autoruns" but these would only be available to Admin.

 

Yeah, that was sorta my understanding too. But that damn registry is so huge and complex, what are the chances that we missed some startup keys?

 

You may have a point. Kafu is rather an obscure tool, and when last updated? I was just looking where I got it from. Here's the original ref by tlu, still active:

ftp://ftp.heise.de/pub/ct/listings/0523-112.zip

However, it shouldn't be *that* hard to look at the file perms in the registry. I think the SURUN thread has more on this. My understanding is LU should only have write access to HKCU anyway.

 

True. The whole point of it is though, as you probably are aware, is that you don't really want anything in HKCU that could bite you available to the user. There are more areas to look at, but not specifically all for autorun or autostart. There are vulnerabilities in the environment variables (ie. %windir%) as well as in .lnk files and .scf files. Seems .lnk files can do some wierd stuff I have been reading.

I also read that SRP does not actually know the difference between a directory or file. I have yet to experiment with that but plan to.

The point is, there are a finite number of autostart type locations. I read somewhere I think that there are a total of 52 or so in total. Maybe TLU wrote that. But there are other areas to show concern over that are not as well publicized. I am not sure poking through the registry would reveal those. My digging only shows me these things from peeps who are really into security, and usually in domain environments where they have to lock things down. Security blogs are where I find the most data.

Sul.