Question

I am developing a program in Java that will allow teachers and administrators to control student permissions and access. I have a server and a client, but my problem is that students can simply close the restricting program via taskmanager. I have blocked cmd and powershell, so those are not accessible. I could block taskmanager, but I believe this resource is more beneficial than not.

I know a rootkit can hide a process, but it's invasive. Does anyone know of an approach I might take to solve this problem. Perhaps create a "task manager" in java that hides essential processes?

Any help or direction is greatly appreciated. Thanks.

Was it helpful?

Solution

Summary

If you can make your students run with limited privileges (non-admin account) and run your guard under the system (admin) account, they won't be able to kill the guard. The rest is then easy. As correctly mentioned by Ravi Thapliyal, this should be your first and only line of defense. If that is not an option for whatever reason...

If you can't prevent the installation of arbitrary software, the best you can easily do is to create two processes that watch each other's existence and terminate the process that spawned them. When one dies, the other should spawn a new copy of both and then terminate itself. Name them Tuck and Hood (or any two seemingly unrelated and unsuspicious names that are far from each other alphabetically). Especially when combined with a proffesional-looking error message ("an attempt to ... has been detected"), this should deter most students.

If you can prevent installation of arbitrary software, you can block shift-clicks and ctrl-clicks and other goodies to perform a multiple selection in the task managers that are already installed. If you can use some other, more direct and straightforward, kind of tampering, you should. Or just block all other task managers and write your own, like you suggest.

Robin Hood and Friar Tuck

You can take inspiration in the story of Robin Hood and Friar Tuck, a pair of processes that was, among others, very difficult to terminate.

The list of pranks done by this virus is a very interesting read, but the interesting part is here:

... When Robin Hood was X'ed, the following sequence of events took place:

!X id1

id1:   Friar Tuck... I am under attack!  Pray save me!  (Robin Hood)
id1: Off (aborted)

id2: Fear not, friend Robin!  I shall rout the Sheriff of Nottingham's men!

id3: Thank you, my good fellow! (Robin)

Each ghost-job would detect the fact that the other had been killed, and would start a new copy of the recently-slain program within a few milliseconds. The only way to kill both ghosts was to kill them simultaneously (very difficult) or to deliberately crash the system.

...

The basic idea (have two processes that revive each other) is still viable, but there is a major hurdle in the form of task managers that can, in fact, kill two processes at once. However, at this point, you've got yourself a pretty good defense, especially if those two processes don't occur next to each other in the process list. And, of course, you don't have to stop at two. Unless the user finds all of them, they all survive.

Do not get killed simultaneously

The fact that users can select multiple processes and kill them at once is unfortunate, however. Disabling Shift-clicks and Ctrl-clicks globally causes too much collateral damage. Also, a custom-built task-manager (or a suitable console-based one) can easily bypass that one. Blacklisting every task manager in the world to prevent multiple selects in -- well, have you played whack-a-mole?

However, if you can prevent installation and execution of arbitrary software (this is almost definitely neccessary to be able to prevent all attacks), you can target and tamper with only the task managers that are already present in the system. If you tamper them enough, you won't even need there to be two processes to guard each other. However, if you have two processes, it suffices to kill the task managers' multiselect abilities. Also, be aware of their "kill the process tree" functionality.

A process can spend arbitrarily much time before reacting to a quit signal. You can toy with the idea of using a TCP loopback between the two processes to synchronise their termination so as to avoid them being killed at once. However, this doesn't work when the processes are terminated, not told to quit.

Another potential issue is that the student might decide to delete the guard program executable, and then kill it. This should be handled by proper file locking. However, If your operating system allows this, you need to prevent it yourself. However, if your operating system allows deletion of arbitrary files even if they are currently running executables, all bets are off.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top