1

its a very simple question but might not be too trivial. Imagine an attacker has access to your device and gained SYSTEM privilege. Your company has installed a logging agent on your device to capture all these malicious activities, is there any ways to prevent an attacker from stopping the logging agent and send "Green" traffic back to the logging server?

One way that I can think of is using something similar to cred guard in windows 10, you have a hypervisor and running the agent in a separate "god" mode memory region. So the agent can oversee all the malicious activities and attacker wouldn't be able to modify it. (This requires hypervisor mode to be enabled.)

Sandboxing might help here, but let's just assume the attacker gained OS level privilege.

Will using an external electronic device help here? (Touchbar in mac)

1

If the attacker is logging from a bot or an automated remote tool: Possibly - by discovering that node and having an ISP trace the connections on it (White Hat) or by sniffing it and establishing a connection and locking out the controls. (Kind of difficult to do if it's on an active system being human monitored without locking out the attacker from their own system and even then they would pull the plug.)

0

I don't know if this is the right answer, but after a bit of research, I came up with this 'solution'. First of all, ensure you have a secure boot chain, which can guarantee no firmware rootkit is installed on your device, up to kernel level. This ensure the integrity of the system is trusted when it is booted. So now we have to worry about a runtime malware happen after the boot chain. First of all, we need some application sandboxing to minimise the attack surface, and we know that if an attacker exploited another application that is running on the device, they will not be able to view / touch our application.

And let say, unfortunately, they were able to exploit the Operating System, we hope we can somehow detect some artifacts before they reach this point, and our server can treat this device as compromised / untrusted.

In MacOS, there is something called the SIP (https://en.wikipedia.org/wiki/System_Integrity_Protection), which should be able to protect the process even if they gain root access. Please correct me if this is not correct. I think the idea is we now move the trust to kernel, so unless the attacker gained kernel access, they should not be able to touch our logging process.

Well.. and let say they have a 0-day kernel exploitation, does it mean we have to surrender? This is another chance for us to catch them before they reach the kernel. They have to exploit some kernel API and run arbitrary code as kernel. There are some protection for kernel at runtime such as Linux Kernel Runtime Protection, Windows VMS, Android KNOX etc. What they do is basically keep track of another list of task list, and hook into the syscall. They do integrity check when they return from the syscall. I am not 100% sure how this is being done, but I guess this might be a good chance to catch them before our logging agent is compromised.

There are a lot of research going on in this topic, a group called trusted computing group is working on this problem. However, there are a lot of difficulties due to the design of the operating system. When they first came out, they are not designed with mandatory access control. A superuser is able to do anything on the system. They are slowly progressing from Windows Vista, integrity level on processes, selinux on linux etc...

I don't think my answer is perfect but thats my understanding after doing a bit of research. It will be great if someone can clarify the points that I have mentioned above

  • If the kernel runtime protection you are talking about is Solar's thing, then it's completely useless (it's not like Solar Designer to release something that bad) and is utterly trivial to bypass. – forest Dec 31 '18 at 3:22
  • @forest Yea, you are right, im aware of that and the creator himself said that in one of the recent talk as well. But he gives a good idea on how it is possible to approach the problem. youtube.com/watch?v=tOiPM692DOM – user50312 Dec 31 '18 at 3:24
  • @forest The problem he has is the platform problem? Since linux can be running on any devices, unlike Apple, they know what are they running and what hardware are they running on. – user50312 Dec 31 '18 at 3:26
  • Well the problem he has is that he's trying to have a ring 0 kernel module detect malicious code that's also in ring 0. It's just not going to work. Now, something like Knox's RKP is a bit better since it uses a hypervisor, or that new EPT-based feature for KVM coming out that allows locking pages. – forest Dec 31 '18 at 3:27
  • @forest yea, right, just keep pushing the trust to next level, until they reach TPM haha – user50312 Dec 31 '18 at 3:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy