Re: Possibility to cheat integrity checking?
From: Kurt Seifried (bugtraq@seifried.org)Date: 03/16/02
- Previous message: Xiaoyong Wu: "Re: Statistical Anomaly Analysis? "Was [more specific] Signature vs. Protocol Analysis ""
- In reply to: Stephen P. Berry: "Re: Possibility to cheat integrity checking?"
- Next in thread: robert_david_graham: "RE: Possibility to cheat integrity checking?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Kurt Seifried" <bugtraq@seifried.org> To: <focus-ids@securityfocus.com> Date: Fri, 15 Mar 2002 16:39:13 -0700
Yes integrity checking can be cheated. However in the grand scale of things
it is much cheaper and effective to attack the process rather then the
crypto used. This includes but is not limited to:
Kernel modifiations - exec different file then the one called (so the
integrity check works ok), or passing different files, etc, etc, the sky's
the limit. But this is usually overkill.
Attack the update process, that is to say when you install a new software
package/etc you typically add files or change their checksums in the
integrity database. Several products do this really poorly and make it very
easy for an attacker to modify a file while the update is in progress. The
way it should work is packages are signed (like RPM's) and interface to the
integrity software, so the integrity software isn't really rebuilding the db
based on filesystem files, but is getting the config information it needs
from a trusted source. This is a pipe dream of mine though and I doubt it
will be implemented anytime soon (why do things right when you can do them
easy?).
Attack the messaging process. For exmaple redhat ships tripwire, it sends
alerts via sendmail, Ibreak in and modify your sendmail, or the tripwire
binary, anyways I have it send happy happy reports that everything is ok.
Tripwire commercial can be configured to send alerts via an smtp server,
this leads to dns poisoning and other attacks.
Reinstall the message checking software, depending on what it is this may
not be noticed. When is the last time you accessed tripwire and fed it a bad
password to make sure it hadn't been replaced with a binary that accepted
any password (in other words was totally subverted?). When was the last time
you modified a file to ensure tripwire caught it?
There are many easy attacks on integrity checking software, granted most
require admin access, but the point is you can't really trust your tripwire
results unless you boot from trusted media, use a trusted binary and a
trusted database (i.e. all stuff not stored on the system broken into).
As far as speed goes, on a 1 gig AMD, 230,855 files (total of about 12 gigs)
ranging from a copy of packetstorm to redhat install files and so on (in
other words a reasonably good real world example of files people keep) these
were my results:
[root@vomit ftp]# time find ./ -type f -exec md5sum '{}' ';' > /root/md5
real 27m15.656s
user 9m23.250s
sys 5m55.370s
[root@vomit ftp]# time find ./ -type f -exec sha1sum '{}' ';' > /root/sha1
real 35m57.824s
user 14m4.150s
sys 5m43.730s
That is a large difference. The CPU was doing nothing else during these
tests, load average at 1.00 to 1.05 for the entire time.
My two cents anyways.
Kurt Seifried, kurt@seifried.org
A15B BEE5 B391 B9AD B0EF
AEB0 AD63 0B4E AD56 E574
http://seifried.org/security/
http://www.idefense.com/digest.html
- Previous message: Xiaoyong Wu: "Re: Statistical Anomaly Analysis? "Was [more specific] Signature vs. Protocol Analysis ""
- In reply to: Stephen P. Berry: "Re: Possibility to cheat integrity checking?"
- Next in thread: robert_david_graham: "RE: Possibility to cheat integrity checking?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|