On Tue, 17 Aug 1999, William Hugh Murray wrote:
> The problem of substitution of a later log is a solved problem. See
> www.surety.com
I wasn't speaking of _substituting_ a later log, just of generating false
log entries from a machine at a later time than compromise. It's a
non-repudiation issue, and I don't think it can be solved easily with
current general-purpose OSes. For instance, if I get Administrator on your NT
server and generate a transaction entry for your commerce solution from
Vin's Credit Card, while at the same time, a completely valid transaction is
coming in with Bennett's credit card, without going back to both
originators, you'll have a difficult time proving the "valid" transaction on
a compromised host. Even going back, "proof" isn't necessarily a
given, as Bennett could also deny his transaction. It's a different and
much more difficult problem than simple last-thing-before-compromise logging,
which is much more easily solved once the logs are off the host in question.
The same issue applies to any loggable transaction.
Moreover, if the logs are on the host itself, the secret and algorithm
used to hash them will be too, so going back and inventing prior transactions
is good for the time period that the logs are on the box. In the case of
network logging, that means that if you can stop the remote log host from
receiving logs for long enough to get on and get the Ethernet buffer of
the compromised host, you *can* generate false prior entries, the same is
true of disk buffers and filesystem buffers, but the window is a lot more
difficult to hit. (You can also ARP the log host's address and start to
MITM if the connection isn't cryptographicly sound, and perhaps buffer
then MITM if it is once you've gained the target host.)
Architecturally, this speaks well for log-only interfaces and networks,
synchronous file systems, and non-privileged services - probably for
static ARP entries as well, or passive log hosts that sniff the network.
You can do a great deal to make a "listen only" host if you have the OS
source code, or at least network driver source.
> While they cannot solve the problem of tampered time and date stamps
> they can demonstrate that message N was created after N-1 and before
> N+1. By publishing the last message of the week in the Sunday New York
> Times, they can demonstrate that message existed before that date.
Only after the messages are off the host, which if it's been compromised
doesn't necessarily mean a great deal, depending on where you're logging,
how and what vulnerabilities exist in that mechanism. I submit that
non-repudiation of log files after a compromise is much more difficult
than it would appear - *especially* if the attack vector doesn't generate
anything out-of-the-ordinary in log information, if the log transactions
are on a common in-the-clear network, or if the keys to the off-machine log
session have been broken or compromised.
Here's what I said, and since I obviously wasn't clear, I'll expound some
more (CYBERIA gets off scott-free because I'm not subscribed, everyone
else is a captive audience)...
> > Signatures require a secret on the same machine, which is normally a big
> > problem. I think you have to worry about how you refute false subsequent
> > logs with actual event-up-to-compromise logs.
and:
> > You could fake subsequent logs if the authentication is on-machine, and
> > the machine is given in o complete compromise.
The point being that either as a part of a complex scheme to discredit or
cause harm, subsequent log entries could be held to show the good guys
doing bad things, or an innocent 3rd party doing bad things. If you
submit that the logs are valid as evidence, you're hard-pressed to show
what is and isn't a valid log event post-compromise, and in some cases
pre-compromise as well (such as a first-compromise from another host just
before the current compromise in the logs). In a jury trial such as a
criminal case, it could be made to be more confusing than DNA evidence,
especially if you don't have an exact time of compromise to at least give
suspicion to subsequent log entries. Possibly the uncertainty could
extend to prior log entries too, unless you can show some sort of constant
stream of logging and give a window of vulnerability analysis for
(compromise_time - last_verifyable_log_time.)
We all know that photo manipulation is possible, and can be done quite
realisticly. Show a jury a photo of the defendant holding up the bank, and
it's a pretty clear-cut thing. Show another photo of the defendent holding up
the bank with Bill Clinton as his accomplice and it's a different matter
entirely to explain that one part of the photo is true and the other isn't.
Suddenly you've cast doubt on the veracity of the evidence, and in a criminal
case that's a lot more damaging than in a civil case (assuming you're the
prosecution.)
The service you pointed out assumes that the data it's getting is valid,
and that's not necessarily true of a compromised host. I'd agree to
"partially solved", as it's probably "good enough" for the 90th
percentile of cases, but I wouldn't call it a "solved problem." A lot
also depends on the architecture of the systems/networks in question.
Paul
-----------------------------------------------------------------------------
Paul D. Robertson "My statements in this message are personal opinions
[EMAIL PROTECTED] which may have no basis whatsoever in fact."
PSB#9280
begin:vcard
n:Murray;William Hugh
tel;fax:800-690-7952
tel;home:203-966-4769
tel;work:203-966-4769
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:[EMAIL PROTECTED]
fn:William Hugh Murray
end:vcard
