SRP - basic user hacka-lacka

Hi Sul

I'd like to have a look, thanks, project sounds like it has been a good lesson for you.

 

Hi Sully

It's been interesting following your progression these past months as i know we both share in the same excitement and satisfaction of that special security utilizing the combo of LUA & SRP and SuRun is been of great help in that respect for me, but like you i found some of my programs not starting that even though they were added in SuRun, they demanded a RUN AS to get them going instead of coming out of the boot up process activated.

Interesting however making mention of running programs as services though. I have that program a very long time and just never used it, just kept it on hand waiting out another method to equip starting programs in the LUA/SRP w/BASIC USER settings in secpol.msc

Your project looks very enticing for me and i look forward to your end result with the added DMR included.

Keep us informed to any new progress you run across or discover (even if by accident) LoL, by all means please.

Thanks EASTER

 

It would seem this is not as foul a method as I was beginning to think it was. After much more playing with it, I think I have a good system for those who are pretty saavy with XP.

Currently, I am still debuggin a new tool to use with DropMyRights. Eventually I will try to code my own version in c to do my stuff, but for now this works.

It seems I have created an autostart tool, where you can in 4 values declare the path of the program to start, the parameters to start with if needed, the process name to monitor and a pause time or delay. More on this shortly.

My new tool, so aptly and origianlly named DMR_Shell.exe, is about finished. It can currently use DMR to start the shell (explorer.exe) as a Basic User. When it runs for the first time, it configures the SecondaryLogon service to start. It asks for an admin username & password, which is then encrypted into an .ini file that resides with the .exe. Then the shell is stopped and restarted as a basic user. When you are ready to go back to being an admin, the program stops the shell, and using the admin credentials provided, restarts the shell as the admin. All of this is done without creating a new profile, and indeed your existing profile must be an admin for it to work at all.

There are a few tricks that needed to be performed to make this work. First, it was needed to create an autostart program (mentioned above), because as you come from a user, and load back into admin, you are basically re-loading your admin profile again. I have looked high and low to find a way around this, but I can find none. What this means is that anything you have set to auto-start will try to start.. again. Many items already running will check to see if they are running and ignore the request to start up. Others don't do this, and you end with 2 instances of the same program running.

To make matters worse, some programs are loaded at bootup, and then when coming back into admin, refuse to work properly, even if they don't start 2 instances. My little autostart tool takes the data from it's .ini file, and simply runs the program if it does not find the process already running. That simple.

Another part of using this vs. SuRun is that SuRun has a handy way to start things as admin and remember it. I am not going to do that at all. I want this more quick and dirty. So you would have to right click on anything you wanted to run as admin and use the RunAs interface. Too slow. So I have another tool that will increase the speed of this greatly.

And after too many hours IMO, I have managed to let my DMR_Shell.exe tool block the 2 autostart folders and 5 autostart regkeys that a user would have access to, while still allowing the admin to access. You may say, what ?? Basically, there are 5 regkeys and 2 folders that a user has access to use. If you were to drop from admin to user shell, and you picked up a malware etc, it could easily write autostart information for the user, as a user is permitted to do so. It would have to write it's payload files to the My Docs folder and not c:\windows or c:\program files, but that is easy. Anyway, since you have one account with this method, and ADMIN account, and you are simply starting explorer.exe AS A USER, anything that would get written to autostart areas AS A USER, would immediately autostart when you switched BACK TO ADMIN. Not good at all.

So the fix? Simple enough. I change the registry permissions on 5 keys to deny users, and file permission on 2 directories to deny users. While you are running the shell as admin, you have full access to these areas, and while you are running the shell as user, they are locked. Simple enough. Interesting, I got the directory restrictions to work with simple file sharing, which I was understanding from Aaron Margosis website, should only be allowed if you are not using simple file sharing. But then, I might be cross-eyed by now lol.

Anyway, I will be creating a new thread hopefully in a few days, as I have more or less changed the scope of what this method/tool will be targeted for. Hoperully I can test it on a few more machines and be sure all is both working and can be removed. Not much to remove, but shooting for betaware not alphaware.

Sul.

 

I am on the same page with this method & you Sully with great enthusiasm and interest. Easter will be following it, you can count on it, a better way with less disruptions for better security equals lust a little patience and a lot of effort.

Thanks Sully

EASTER