FWIW, rpm.org has the first (but insufficient) step to hardening forensics on a
compromised system.
E.g Here is rpm-4.13.90 output of "rpm -Vvv popt"
`
...
D: read h# 27079 Header V3 RSA/SHA256 Signature, key ID 81b46521: OK
D: Plugin: calling hook init in syslog plugin
D: Plugin: calling hook init in systemd_inhibit plugin
D: ========== +++ popt-1.16-7.fc24 x86_64/linux 0x2
D: read h# 34281 Header V3 RSA/SHA256 Signature, key ID fdb19c98: OK
...
`
Hood: DIZZYTACJOMETER is likely replacing/deleting package headers in an rpmdb,
not modifying headers.
Importing only "trusted" pubkeys (i.e. rpm's current conception of "trust")
with well known pubkey id's and verifying the rpm executable isn't compromised
(by using an offline copy of /usr/bin/rpm, or by checking the digest of
/usr/bin/rpm with offline forensic tools), is a start at manual forensic
procedures.
Verifying pubkey certification signatures could also be attempted (but its
non-trivial to alter pukey parameters without also altering the keyid
fingerprint). It may (very unlikely, but I've not checked rpm.org recently) be
possible to replace the signature on an package header with a different pubkey,
or replace the pubkey parameters in the keystore used by RPM.
(Disclaimer: I'm not suggesting that RPM is vulnerable/deficient here, merely
stating possible attacks that would make RPM's signature verification described
above untrustworthy.)
Some of the manual procedures (like forcing the rpm package to be verified
before proceeding with --verify) could be automated without too much difficulty.
A simpler/stricter mode of operation for rpm --verify with exit on failure in a
multistep procedure would also help forensic analysis. The current "best
effort" (i.e. continue in spite of failures) mode of operation in RPM is too
goose-loosey for useful forensics of a compromised system.
Protecting an rpmdb against package header replacement/deletion attacks (what
DIZZYTACHOMETER is likely doing to hide rootkits) is unsolved (and not easily
solvable).
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/196#issuecomment-293478974
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
