flat assembler
Message board for the users of flat assembler.

Index > Windows > problem Filtering TerminateProcess

Author
Thread Post new topic Reply to topic
TheLord



Joined: 24 Oct 2006
Posts: 42
TheLord 28 Apr 2008, 12:13
Hi, I successfully hooked TerminateProcess(). It comes the time for me to filter the processes to prevent my executable and my service from being killed.

here is the problem :
I can't get the filename corresponding with the hProcess argument in TerminateProcess, I keep getting err 5. Access Denied Error.

I did grant SE_DEBUG_NAME to the current process but it does nothing ... As far as I remember, SE_DEBUG_NAME bypass DACL in process object right ? So why Can't I access the process to get its name ?

(PS : I tried to open a handle on winlogon successfully so I believe I have SE_DEBUG successfully granted)

thx Smile

EDIT : I see TaskMgr use OpenProcess with access "TERMINATE", it may be the cause ? checking it right now ...

EDIT1 : yes it was the access right on the opened process ...
Post 28 Apr 2008, 12:13
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20355
Location: In your JS exploiting you and your system
revolution 28 Apr 2008, 12:58
So you have solved your problem then? Or not?
Post 28 Apr 2008, 12:58
View user's profile Send private message Visit poster's website Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 509
Location: Czech republic, Slovak republic
Feryno 28 Apr 2008, 13:10
Don't forget to TerminateThread and 1 special termination used by asm coders - just ret instruction, nothing more... (this perhaps leads into TerminateProcess or TerminateThread too, I don't know). Test these possibilities too.
Post 28 Apr 2008, 13:10
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
TheLord



Joined: 24 Oct 2006
Posts: 42
TheLord 28 Apr 2008, 13:35
to be sure I can get the name of the file w/o access rights problem I did hook OpenProcessA (I may have to hook OpenprocessW and CreateprocessA/W too ... it solve the problem but putting PROCESS_ALL_ACCESS with all OpenProcessA's process is not very clean ... This way it works :/
Code:
proc MyOpenProcess dwDesiredAccess, bInheritHandle,dwProcessId

        push [dwProcessId]
        push [bInheritHandle]
        or   [dwDesiredAccess], PROCESS_ALL_ACCESS
        push [dwDesiredAccess]

        call old_OpenProcess

        ret

endp   
    


If any has another solution, I take it with ease ! I thought about modifying the process DACL but I dont think it's gonna change the current access on the opened handle... It will just change the access possibility for OpenProcess regarding the current user's token, it's not good.

Feryno : it's light security I want to bring, I wont bother to cover all the cases, I just want to make it harder, just to tell "hey I did'nt let the user terminate the process via taskmgr"

EDIT : I finally Hooked NtTerminateProcess and NtOpenProcess instead of the higher level API, I think I can't hook anything deeper w/o ring0.
Still this PROCESS_ALL_ACCESS is pissing me off
Post 28 Apr 2008, 13:35
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20355
Location: In your JS exploiting you and your system
revolution 28 Apr 2008, 14:16
You could keep you own mapping table of ProcessId<->ProgramNames.

But I thought you only needed to protect one process, so how come you can't just monitor for your own ProcessID and not worry about the file names?
Post 28 Apr 2008, 14:16
View user's profile Send private message Visit poster's website Reply with quote
TheLord



Joined: 24 Oct 2006
Posts: 42
TheLord 28 Apr 2008, 17:40
The whole thing is :
1. a classic executable
2. a service
3. the DLL
[4. an xml file with various config settings => inject exclusion list, reboot count, etc etc] => this will be v2

This is my plan :

1. I protect my exe/my service from being killed by hooking NtTerminateProcess which leads me to a OpenProcess hook
2. As I see that I cannot prevent point 1. to happen (check Advanced Process Termination from DiamondCS and its bloody 18 ways to kill a process) I'm gonna hide my service + my exe => its difficult to kill something that does not exist.
3. I also will protect my service from being stopped/desactivated
4. I'll block user/group creation/move => to avoid little trick as creating a user in admin mode , and put it in the local admin group to get an admin account in the hand.
5. I'll also protect the DLL from being unloaded from any process

I can't monitor my processID because there is more than one process. it would bloat the code (I think) it's simpler to use a prefix/or a signature in the process image, by the way, I dont know the processes IDs per advance. here is the launching stuff order:

1. The service is started with the boot
2. The service launch the executable
3. The executable wait for a user to be connected to do his job (start the timer in case of admin mode)
4. If admin mode the executable spread the DLL into all the processes.
5. The DLL hooks CreateProcessW to spread in all new processes.

Maybe someone has a better solution, I'm open.
Post 28 Apr 2008, 17:40
View user's profile Send private message Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22 28 Apr 2008, 20:05
I have a simpler solution

You're already injecting code why not use that code to check for your process rather than hooking system APIs.

Have your remotethreads check for your process and if it's not running, restart it.
Post 28 Apr 2008, 20:05
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
Feryno



Joined: 23 Mar 2005
Posts: 509
Location: Czech republic, Slovak republic
Feryno 29 Apr 2008, 05:48
process wanting to make a harm to your process may also just suspend it, or attach to it as a debugger etc...
There are some processes in the Task Manager list which can't be terminated. There is a documented way how to make them as an 'integral part of OS' so OS refuses to terminate them, but I can't remember where I found that article (just few APIs, it was about year ago).
I suggest you the same as r22, run several threads where each one watches the others - and restartes terminated or resumes suspended etc.

later edit: WOW, check this - 18 various methods how to terminate or damage a process......
http://www.diamondcs.com.au/advancedseries/processkilltechniques.php
http://www.diamondcs.com.au/processguard/attacks.php
Post 29 Apr 2008, 05:48
View user's profile Send private message Visit poster's website ICQ Number Reply with quote
TheLord



Joined: 24 Oct 2006
Posts: 42
TheLord 29 Apr 2008, 07:55
Quote:
2. As I see that I cannot prevent point 1. to happen (check Advanced Process Termination from DiamondCS and its bloody 18 ways to kill a process) I'm gonna hide my service + my exe => its difficult to kill something that does not exist.


I know Sad

Actually the app is a watch dog, each executable looks for the other and restart it if killed, whiwh is about the same as r22's solution.
The problems of this solution are :
1. I can't prevent the user from desactivate the service while he is in admin mode which would cause infinite priv escalation.
2. I can't prevent the user to create a user in the local admin group which result to an admin account disponible for the user (same as above)
3. I can't prevent the user to move his account in the admin group (same as above)
4. I can't prevent the user from using at.exe which execute all the tasks in system context (open door for point 1. 2. and 3.)
5. The user could use software like "unlocker" in order to delete the DLL to be injected.

etc etc

Believe me, I had a hard time about thinking of the best thing to do. The only way I found is by hooking thoses relatives APIS in order to forbid all easy priv escalations. I know, the user could use anti rootkit such as rootkit unhooker or other related software, but there is a difference of knowledge between knowing how to create an account and how to remove a hook when they dont even know what it is.
Post 29 Apr 2008, 07:55
View user's profile Send private message Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22 29 Apr 2008, 11:58
You're still over complicating it.
You're in USERLAND think more like a user.

Have your remote threads search for the admin console windows, if the user opens up the "Computer Management" window have it immediately close the window WM_CLOSE (or get as fancy as you want). Do the same for MSCONFIG window SERVICES window CMD window RUN window anything the user doesn't need to do their job.

Think about why your users need this temporary Admin privilege and lock it down based on that.
Post 29 Apr 2008, 11:58
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
Goplat



Joined: 15 Sep 2006
Posts: 181
Goplat 29 Apr 2008, 14:57
If you don't want your users to have administrator privileges... then don't make them administrators; make them limited. Simple as that. No need to waste time writing virus-like programs which are very unlikely to protect against everything anyway.

If there is a specific thing users need to be able to do but requires admin, then write a service that does that specific thing, and a program (accessible by limited users) to communicate with that service.
r22 wrote:
CMD window RUN window anything the user doesn't need to do their job.
I use these all the time, for ordinary, non-administrative tasks.
Post 29 Apr 2008, 14:57
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20355
Location: In your JS exploiting you and your system
revolution 29 Apr 2008, 15:52
Goplat wrote:
r22 wrote:
CMD window RUN window anything the user doesn't need to do their job.
I use these all the time, for ordinary, non-administrative tasks.
I use the CMD for running fasm, don't block my fasm!
Post 29 Apr 2008, 15:52
View user's profile Send private message Visit poster's website Reply with quote
TheLord



Joined: 24 Oct 2006
Posts: 42
TheLord 29 Apr 2008, 17:30
it can be an app install/uninstall/update
it can be a technician who has NOT access to the local admin account, for an incident resolution ...

that's why the app HAVE to provide admin rights I can't restrict , it's not what the clients want.
If it was that easy, I would not use asm, I would not use a service or a DLL, I would just use runas in a GUI ...

I'll post what I made, Goplat, so you wont tell me I code virus-like program anymore (btw, hooking has NOTHING to do with virus go and tell that to Eugene Kaspersky, he is gonna laugh on this one)
Post 29 Apr 2008, 17:30
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20355
Location: In your JS exploiting you and your system
revolution 29 Apr 2008, 18:05
I don't think you have properly modelled your usage. If you feel that the user must get admin rights then you are already dead there. They are admin, so your app is to be considered as good as dead. Most companies have designated users that have admin login rights and can do the special tasks. If you also don't trust your techs then you have a bigger problem than just your computer system access. Tell your boss that this task is a waste of time and suggest a better alternative. If your boss just says "do it anyway" then find another job, you don't want to be working under arrogant bosses that don't listen.
Post 29 Apr 2008, 18:05
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 4046
Location: vpcmpistri
bitRAKE 30 Apr 2008, 06:00
If a client wants to pay to code the impossible (when they have been warned) then have them pay up front, imho.

_________________
¯\(°_o)/¯ “languages are not safe - uses can be” Bjarne Stroustrup
Post 30 Apr 2008, 06:00
View user's profile Send private message Visit poster's website Reply with quote
TheLord



Joined: 24 Oct 2006
Posts: 42
TheLord 30 Apr 2008, 17:03
hehe bitRAKE, that's what I think too.

a friend gave me an alternative for the ALL_PROCESS_ACCESS stuff. I dont need to hook TerminateProcess, I can just hook NTOpenProcess and remove the right TERMINATE if it's one of my processes.

Btw, I got it working nice, just a few change to do on the service to handle the sessions events, and on the exe to monitor the reboot count, thx to you all, I had a little fun trying to hack the app with MS windows provided tools, no success, you can't bypass the restricted rights (no account creation, no group move, no kill etc).

I only left app which use WMI instead of the API. exemple :
tasklist
taskkill
probably pskill
...

After those few change, if a user want to bypass he has to use ring0 tools.

revolution, I'm partially agree with you. first of all, I give two projects, my chief decide which should be used so there is an "improved" watch dog with a service, an exe and a PIPE to monitor, and what I do now with the fasm DLL hooking some APIS.

Quote:

Most companies have designated users that have admin login rights and can do the special tasks. If you also don't trust your techs then you have a bigger problem than just your computer system access.


not agree on that one. almost all our clients does'nt give admin right to the user. it's an open security hole because most user would always work in admin mode and then provide SK open door to exploit the desktop. Just think about trojan, vx, worm and cie.
Secondly, I dont know how it is in other country, but in france, you can hire techs for specifics mission (interim/time determined contract => dont know if the translation is ok). Those techs will never have the local admin password, same for deployement techs and some other specifics tasks.
As an exemple, I coded a master based on a sysprep image, the admin password is encrypted. why ? because the deployement techs does not need it, simple.
Post 30 Apr 2008, 17:03
View user's profile Send private message Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22 01 May 2008, 00:23
Simple ways to bypass security software:

A - Did you try booting into "Safe Mode" as a way to get around your application?

B - Are the NTFS partitions encrypted? If not then loading a live linux CD and mounting the drive with your program installed, then deleting your application files would bypass any security.

C - Resetting the password on the "Other" local admin account.

D - Enabling the local "Administrator" account (usually security practice is to disable it, so re-enabling it isn't creating an account.

I could think of more, but those are the least clever.
Post 01 May 2008, 00:23
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
TheLord



Joined: 24 Oct 2006
Posts: 42
TheLord 01 May 2008, 11:26
hehe

A. B. I can't get around those, you're 100% right but this is the case whatever the solution I use, that's a risk I can't handle in such programs, again, the client want it, he pay for it, I do the max I can to provide the best solution with minimum risk which does not mean NO risk at all

C. this wont work : I already hook NetUserSetInfo() which deny the local password change.

D. The admin account (for the client who initiate the demand) is not disabled, so there is no issue there.

I still left WMI which bypass my methods, but I'll find a way around
Post 01 May 2008, 11:26
View user's profile Send private message Reply with quote
r22



Joined: 27 Dec 2004
Posts: 805
r22 01 May 2008, 19:49
If you could find a way to disable/beat "Safe Mode" I'd consider your app an extremely viable Admin remediation tool.

The booting with a live CD can be hindered with a physical lock on the CD rom drive and a bios password so it can't be set in the boot priority.

A few more hurdles and you might have something with the temporary admin idea.
Post 01 May 2008, 19:49
View user's profile Send private message AIM Address Yahoo Messenger Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.