RE: advice needed - secure transfer of client details

[<Glenn_Everhart () bankone com>]

The general problem sounds like this:
You have a server you trust, and want to have code run on some client
but you must establish trust for the client. In other words, you want to
be sure somehow that the client is running some code and sending its
results to the server unaltered. The details of the code are in principle known
to the server, as in principle the machine type of the client (at least
to the point the client machine type and OS are known).

This is not AFAIK a solved problem. 
That said, there are ways to approach an answer "as closely as you like"
by using more and more detailed knowledge about the client...

The scheme is based on the observation that truth is consistent, whereas
it is hard to lie consistently.

To implement it, though, you need to be able to have the server make a series
of queries to the client and get responses. The more questions you can ask,
the more types of spoofing you make difficult.

For example if the server may ask for an SHA1 hash of client memory between
address a1 and address a2, it can establish that a copy of the client code
that matches its knowledge exists at the client. If the server can demand
that code at certain places be executed and results passed back, and test
results and timings of this, it can make it hard to have some other code that
is acutally running escape detection. In principle every point in the client
code can be treated as an entry point (remember the trouble folks had cloning
Apple II roms?) and its address checked. Likewise other memory can be probed.
Funny debugging schemes may also tend to show up in timing anomalies or in
probes designed to see if any debug bits are set.

Mind though that building a verification system like this which does not at the
same moment create enormous security holes in the client code is, shall we say,
nontrivial. 8-) Also, this is obviously a potentially enormous amount of work.

Thus in the real world you need to settle on a set of tests you will have a
client system run to prove itself and implement those. In some circumstances
it can be far cheaper to just inspect the client machines directly now and then
than to run this kind of remote gauntlet testing. 

In the real world, too, you are somewhat dependent on what you know about the
client machine. A special purpose machine with hardware trace or debug facilities
that do not show up at code level is possible and could be hard to detect even
using timing tests. The faster the special hardware is than the ostensible
target, the easier this becomes. Thus the probe set to achieve near certainty
you can trust the client will keep growing.

I regret a more optimistic answer cannot be given. Code signing, for example,
makes some assumptions around trusting the checking code at a client. Most other
quick answers do likewise. This kind of questioning reminds me of the more
fundamental question: by what are we certified that another human being is
conscious as we are? Dig deeply enough and the only answer seems to be "faith".

such is our universe.

Glenn C. Everhart


-----Original Message-----
From: Scovetta, Michael V [mailto:Michael.Scovetta () ca com]
Sent: Monday, November 01, 2004 11:36 AM
To: Tim James; webappsec () securityfocus com
Subject: RE: advice needed - secure transfer of client details


Tim,
  This is pretty much *THE* problem in application security, so this is
somewhat of an unsolved problem.

However, here's my advice: [it may be a bit scattered, this is a
braindump]
1. What's the potential loss ($) of someone tampering and sending false
data?
2. What's the chance of someone actually doing it?
3. Take #1 and #2, that's your probably loss by doing nothing. If that's
negligible, then you probably don't want to do anything. (Are the CEO or
high-level managers the only ones running this? Then they can probably
falsify the data anyway by some other means, so what are you
protecting?)

I'll assume that it's a real danger, big losses, by people you do NOT
trust already.

The real question boils down to: "How can you have A trust that B runs
program X to get output Y?"

I think .NET allows for code signing. That might be one approach.

Another would be to ActiveX it up and install an .exe on the client's
box. (Java apps are trivial to decompile).

Here's a more realistic one:
Use something like:
<applet src="whatever">
  <param name="key" value="abc"/>
...

Have the applet read the data from the client's box and hash it with
"abc" as the salt. Make sure that "abc" is a random string that changes
each time the page is loaded. You can save the "abc" value on the server
(session variable).

Then, you return back to the server:
  DATA (ip, hostname, whatever)
  MD5(DATA + "abc")

And make sure you get a response within, say, 10 seconds.

You could do some fancy signing + timestamping on the client, but I
don't think that'll get you much.

You could dynamically rewrite the applet bytecode to include a "secret"
that the client would have to decompile to learn, and then re-encrypt.
You could then just set a timer (they won't likely be able to do that
very quickly).

Finally, you KNOW their (external) IP address. They can't fake that. Use
that as leverage. It's sometimes easier to audit after the fact.


Alright, sorry this was such a mess-- I'm sure I could come up with
something more legible if I had more time to go through it all. If
you're looking to *really* get into this, I'd suggest the Blackat
training course "Network Application Design & Secure Implementation"
(http://www.blackhat.com/html/bh-usa-04/train-bh-usa-04-dm.html) next
time it's given.


Hope that helps,

Mike

-----Original Message-----
From: Tim James [mailto:jimtames () yahoo com] 
Sent: Friday, October 29, 2004 6:18 AM
To: webappsec () securityfocus com
Subject: advice needed - secure transfer of client details

Hi all,

This is a brain teaser. I have an application to
review which supplies details from the client's
workstation (derived from files on disk, hostname, IP
address). It currently implements a Java applet whose
job is to obtain these details and send them up to the
server in an ordinary HTTP POST. 

This sends alarm bells ringing for me. I have
developed a simple attack whereby I can replace the
applet at will with my own code, which can send
different details for workstation ID, hostname, IP
address. This falsifies the audit trail from this
point on and the server is none the wiser.

So, the general problem is this :-

How can a client communicate details that are only
known to the client, up to a server, in a way that
cannot be tampered with ? Why should a server trust
the supplied values ? The data for the workstation
next to me is known by everyone - why can't I create
an applet to reproduce those details, and hence
impersonate that workstation ?

I have some ideas but none are totally satisfactory. 

1) Encrypt the data
This shifts the problem to one of key management.
2) Checksum the applet 
3) Keep the details on the server in the first place
and supply some token from the client which cannot be
impersonated

I would *really* appreciate a different perspective on
this problem because I'm kind of stalled.....

Thanks a lot

Tim

Send instant messages to your online friends
http://uk.messenger.yahoo.com 





**********************************************************************
This transmission may contain information that is privileged, confidential and/or exempt from disclosure under 
applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, 
distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If 
you received this transmission in error, please immediately contact the sender and destroy the material in its 
entirety, whether in electronic or hard copy format. Thank you
**********************************************************************