Possible rootkit found on my Fedora 24 template?

83 views
Skip to first unread message

slemmi...@gmail.com

unread,
Jun 20, 2017, 12:36:07 PM6/20/17
to qubes-users
Hello and thanks for reading.

I installed rkhunter, updated it and ran it. It gave me this:

[17:28:20] Checking running processes for suspicious files [ Warning ]
[17:28:20] Warning: The following processes are using suspicious files:
[17:28:20] Command: xl
[17:28:20] UID: 0 PID: 514
[17:28:20] Pathname: /usr/sbin/xl
[17:28:20] Possible Rootkit: Dica-Kit Rootkit
[17:28:20] Command: xl
[17:28:20] UID: 515 PID: 514
[17:28:21] Pathname: 432688
[17:28:21] Possible Rootkit: Dica-Kit Rootkit
[17:28:21]

Can't find anything about this -rootkit- and qubes on the net, no false positives and such. I uploaded the file, xl, to virustotal and all results where green, so no antivirus program found anything wrong with this file.

"The following processes are using suspicious files", is there a way to find these suspicious files?

The only file that I found that xl uses is xldevd.pid and there is a logfile /var/log/xen/xldevd.log but the log file is empty.

The rkhunter log gives me this:

[17:23:27] Scanning for string /var/run/...dica/clean [ OK ]
[17:23:27] Scanning for string /var/run/...dica/dxr [ OK ]
[17:23:27] Scanning for string /var/run/...dica/read [ OK ]
[17:23:27] Scanning for string /var/run/...dica/write [ OK ]
[17:23:27] Scanning for string /var/run/...dica/lf [ OK ]
[17:23:27] Scanning for string /var/run/...dica/xl [ OK ]
[17:23:27] Scanning for string /var/run/...dica/xdr [ OK ]
[17:23:28] Scanning for string /var/run/...dica/psg [ OK ]
[17:23:28] Scanning for string /var/run/...dica/secure [ OK ]
[17:23:28] Scanning for string /var/run/...dica/rdx [ OK ]
[17:23:28] Scanning for string /var/run/...dica/va [ OK ]
[17:23:28] Scanning for string /var/run/...dica/cl.sh [ OK ]
[17:23:28] Scanning for string /var/run/...dica/last.log [ OK ]

So, if anyone could install rkhunter on their fedora 24 template and see if you get the same results, that would be very helpful. :)

Has my qubes been compromised?

slemmi...@gmail.com

unread,
Jun 20, 2017, 1:06:36 PM6/20/17
to qubes-users, slemmi...@gmail.com
Or is this a false positive?

Unman

unread,
Jun 20, 2017, 6:09:19 PM6/20/17
to slemmi...@gmail.com, qubes-users
On Tue, Jun 20, 2017 at 10:06:36AM -0700, slemmi...@gmail.com wrote:
> Or is this a false positive?
>

It's almost certainly a false positive, triggered by the presence of xl,
and nothing more.


Chris Laprise

unread,
Jun 20, 2017, 7:17:24 PM6/20/17
to slemmi...@gmail.com, qubes-users
On 06/20/2017 01:06 PM, slemmi...@gmail.com wrote:
> Or is this a false positive?
>

If you 'man xl' you'll see its a Xen command (Qubes runs under Xen). Its
included in my Fedora template so I don't think there is a problem.

Also don't know how a root would have gotten into your /template/...
that seems extremely hard unless you've been installing
unsigned/untrusted software in there manually.

If you're really paranoid, you could attach the root.img of the template
to an appVM based on a different template, then do a SHA sum on 'xl' and
related xenlight libs. You should be able to find sums for (same
versions of) those files at fedora's site.

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

Chris Laprise

unread,
Jun 20, 2017, 7:42:22 PM6/20/17
to slemmi...@gmail.com, qubes-users
If you're worried about rootkits, the threat looks somewhat different
for Qubes templates and template-based VMs because the templates
themselves are so well protected (essentially read-only most of the time).

The potential threat lay with configuration files stored in /rw
(private.img) which includes /rw/config and /home/user. I am working on
a tool to help detect and prevent such rootkits:

https://github.com/tasket/Qubes-VM-hardening
https://github.com/tasket/Qubes-VM-hardening/tree/systemd

The first version merely sets all the bash/sh/GUI init scripts in /home
as 'immutable'. This has the benefit of preventing non-priv-escalation
malware from persisting at startup, and prevents alias shims from
stealing passwords, etc.

The next version can also compare file hashes and deactivate root-level
malware at startup before /rw is brought online.
Reply all
Reply to author
Forward
0 new messages