flat assembler
Message board for the users of flat assembler.
Index
> Windows > problem Filtering TerminateProcess |
Author |
|
revolution 28 Apr 2008, 12:58
So you have solved your problem then? Or not?
|
|||
28 Apr 2008, 12:58 |
|
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.
|
|||
28 Apr 2008, 13:10 |
|
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 |
|||
28 Apr 2008, 13:35 |
|
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? |
|||
28 Apr 2008, 14:16 |
|
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. |
|||
28 Apr 2008, 17:40 |
|
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. |
|||
28 Apr 2008, 20:05 |
|
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 |
|||
29 Apr 2008, 05:48 |
|
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 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. |
|||
29 Apr 2008, 07:55 |
|
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. |
|||
29 Apr 2008, 11:58 |
|
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. |
|||
29 Apr 2008, 14:57 |
|
revolution 29 Apr 2008, 15:52
Goplat wrote:
|
|||
29 Apr 2008, 15:52 |
|
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) |
|||
29 Apr 2008, 17:30 |
|
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.
|
|||
29 Apr 2008, 18:05 |
|
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 |
|||
30 Apr 2008, 06:00 |
|
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:
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. |
|||
30 Apr 2008, 17:03 |
|
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. |
|||
01 May 2008, 00:23 |
|
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 |
|||
01 May 2008, 11:26 |
|
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. |
|||
01 May 2008, 19:49 |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2024, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.