Anonymous return addresses

Browsing through the 1995 IEEE Symposium on Security and Privacy
proceedings at the library, I found two articles of interest here.  The
first, "Preserving Privacy in a Network of Mobile Computers", is really a
method for anonymously receiving mail via reading it from a large
database such that no one knows which part you are reading.  This is a
topic which we discussed here at some length a year or two ago, but I
think this article has a new idea about it which I will discuss below.

The other one was "Holding Intruders Accountable on the Internet" and it
had one strange comment.  Basically it was about a way of trying to track
down cracker types who break into systems.  One strategy these people use
is to log into a whole series of insecure hosts, one after the other,
before attacking their target.  Then tracing back where they came from is
very difficult.  Cliff Stoll's "The Cuckoo's Egg" is the classic account
of how hard it is to trace these people.  Probably the new books about
Mitnick talk about the same thing.

The idea in this article is that you monitor the whole net and track
all the rlogin and telnet traffic between pairs of hosts.  Then they
describe a statistical technique for determining that two different
telnet sessions are chained together by recognizing the same patterns
of traffic on them.  Basically they count the frequency of spaces and
punctuation marks on minute-long time slices and try to correlate
them.  This way you can tell that the intruder attacking here is also
using these other hosts over there, and try to track him down that
way.

I don't think this is very practical, and I have mixed feelings about the
technology - I don't favor breakins, but the kinds of surveillance that
would be necessary to implement their technique seem very threatening.
Also they do mention the obvious countermeasure of using encryption at
each stage, which would be easy with such things as the secure remote
shell programs around now.

The interesting comment came when they were discussing an alternative
scheme, which would be to have all hosts keep track of their incoming and
outgoing connections:  "The difficulty with all such host-based tracing
systems is that, when an extended connection crosses a host which is not
running the system, accountability is altogether lost at that point....
Even if most hosts could be secured, the intruder community could easily
maintain a set of machines to launder connections, just as they maintain
anonymous remailers."

So apparently in the view of these authors anonymous remailers are
maintained by "the intruder community."  It is unfortunate that we have
this image among some member of the larger community.  BTW, there are
periodic suggestions here to run general-purpose connection redirectors,
but people should be aware of the problem that cracker types would seize
on these as another shield for their crimes.  These would have to be
limited to specific uses, such as port 80 which is the http port and
which hopefully can't easily be used for attacks.

In any case, let me describe the message-receipt idea from the other paper
I mentioned above, which is by David A. Cooper and Kenneth P. Birman of
Cornell.  They have a few ideas, among them exchanging message labels
for the next message in an ongoing conversation, so that later messages
don't have any identifying information on them, but just opaque message
labels which can be scanned for matches to those of interest.  This is a
concept we have discussed before.  However you still have the problem
at least for the first message to an anonymous recipient of getting it to
him anonymously even though the message says what pseudonym it is for.

A simple idea is to put all such messages into a database and to let
everyone scan the message headers to see whom they are for.  Then when
they see one for them they download, decrypt, and read it.  For more
security, let the database machine be trusted, and let the download
request and response be sent encrypted.  Now only the database machine
knows which person asked for which message.  This provides a level of
security analogous to sending through a single remailer.

(Another idea is to download all messages, but that is generally
infeasable if there are a lot of people using the system.)

The new idea is to use multiple databases to get security similar to
using multiple remailers.  I'll describe it using two machines.  Each
holds a database of messages, and the two databases are exactly alike.
Some mechanism keeps the two synchronized.  Furthermore, all the
messages need to be the same size.  There will need to be some padding
and fragmentation/assembly mechanism to arrange for this.

Someone who wants to receive some mail anonymously first downloads all
the message headers as before, and determines which messages are for
them.  Suppose just one is, and it is message number 20 out of a database
of, say, 50 messages.  Now what the reader does is to choose a random 50
bit number (where 50 is the total number of messages in the database).
He makes a copy of this number, and toggles bit 20 in one of them (20 is
the message he wants to receive).  Then he sends one number to one of the
database servers, and the other to the other server.  Each one receives a
random-looking 50 bit number.

What each server does is to take the messages from the database which
correspondo to 1 bits in the 50 bit number, and XOR all those messages
together, byte for byte.  The resulting output will be the same size as
a quantized message.  It is sent, encrypted, back to the requestor.

Now all he does is to XOR the two messages he got back from the servers.
All of them will cancel out except for message 20, which is the one he
wants.  This can be generalized to more than two servers, by creating
multiple bit strings and arranging so that the XOR of all of them will
just leave the bit set for the message he wants.  If he wants more than
one message the protocol has to be repeated separately for each message.

There is no large amount of traffic needed, as each server only sends an
amount of data equal to one message.  The individual servers do not get
any information about which message the requestor wants (other than that
it is one of the 50).  Only by colluding and XOR'ing their bit strings
can they figure that out.  The same kind of collusion is needed to trace
a sent message using two remailers, so the security is similar to what we
get sending messages.

Messages would have a finite lifetime and would expire and be removed
from the database after a while.  The authors propose breaking the
database up into batches with a fixed number of messages, but I don't
fully follow the reasoning behind this.  I guess it reduces the load on
the server when it does its XOR's.

I'm not sure whether this particular scheme was proposed when we
discussed this concept in the past, but it does seem like an interesting
alternative way to receive messages.

Hal

At 16:29 -0700 6/8/96, Hal wrote:


>There is no large amount of traffic needed, as each server only sends an
>amount of data equal to one message.  The individual servers do not get
>any information about which message the requestor wants (other than that
>it is one of the 50).  Only by colluding and XOR'ing their bit strings
>can they figure that out.  The same kind of collusion is needed to trace
>a sent message using two remailers, so the security is similar to what we
>get sending messages.

If the message is split into more than one part (to meet the message size
requirement) there is some potential leakage to each server of what message
is being requested. If User a requested 3 messages, then they MAY be
requesting all three parts of a 3 part message (or 2+1). If a record is
kept of the number of requests over time, then there can be some regression
checking based on the ID (ie: If the number of new messages for ANx in the
DB matches the number that User Y requests in the current session). I may
be in error with this thought but it looks like a possible problem.

>Messages would have a finite lifetime and would expire and be removed
>from the database after a while.  The authors propose breaking the
>database up into batches with a fixed number of messages, but I don't
>fully follow the reasoning behind this.  I guess it reduces the load on
>the server when it does its XOR's.

This can also affect the "attack" I speculated on above since it can "leak"
more info. Multi-part messages (or multiple messages to the same recipient)
which are retrieved in one session can be correlated between the groups
(ie: User Y asked for 5 messages [Selected from Groups 1&5] and ANx is the
one AN? that has the requested number of messages in each of the Groups
[ie: 3 from G1 and 2 from G5]).

-----BEGIN PGP SIGNED MESSAGE-----

On Sat, 8 Jun 1996, Hal wrote:

> The other one was "Holding Intruders Accountable on the Internet" and it
> had one strange comment.  Basically it was about a way of trying to track
> down cracker types who break into systems.  One strategy these people use
> is to log into a whole series of insecure hosts, one after the other,
> before attacking their target.  Then tracing back where they came from is
> very difficult.  Cliff Stoll's "The Cuckoo's Egg" is the classic account
> of how hard it is to trace these people.  Probably the new books about
> Mitnick talk about the same thing.
> 
> The idea in this article is that you monitor the whole net and track
> all the rlogin and telnet traffic between pairs of hosts.  Then they
> describe a statistical technique for determining that two different
> telnet sessions are chained together by recognizing the same patterns
> of traffic on them.  Basically they count the frequency of spaces and
> punctuation marks on minute-long time slices and try to correlate
> them.  This way you can tell that the intruder attacking here is also
> using these other hosts over there, and try to track him down that
> way.
> 
> I don't think this is very practical, and I have mixed feelings about the
> technology - I don't favor breakins, but the kinds of surveillance that
> would be necessary to implement their technique seem very threatening.
> Also they do mention the obvious countermeasure of using encryption at
> each stage, which would be easy with such things as the secure remote
> shell programs around now.

I don't really understand how such a system would work.  It would either
require some kind of centralized system to receive information from each host
being monitored, or each host would have to contact another and relay the
connection information.  The former would require too much bandwidth and the
latter would open up hosts to easy eavesdropping attacks.  The only alternative
is for sysadmins to monitor syslog activity which is (hopefully) done already.

[...]
> 
> So apparently in the view of these authors anonymous remailers are
> maintained by "the intruder community."  It is unfortunate that we have
> this image among some member of the larger community.  BTW, there are
> periodic suggestions here to run general-purpose connection redirectors,
> but people should be aware of the problem that cracker types would seize
> on these as another shield for their crimes.  These would have to be
> limited to specific uses, such as port 80 which is the http port and
> which hopefully can't easily be used for attacks.

Unfortunately, httpd is very insecure.  First of all, cgi scripts are very
difficult to make secure and can be exploited quite easily.  There may also
be buffer-overflow problems.  It's about as difficult to make connection
redirectors safe from cracker use as it is to make anonymous remailers safe
from child pornographers, terrorists, and other horsemen.

- -- Mark

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
markm@voicenet.com              | finger -l for PGP key 0xe3bf2169
http://www.voicenet.com/~markm/ | d61734f2800486ae6f79bfeb70f95348
"In Christianity neither morality nor religion come into contact with
reality at any point."
                -- Friedrich Nietzsche


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBMbo8bbZc+sv5siulAQFfJAP+K8Fl268+FFZ1NRkqQfndKpGvyhH0DYya
ADgQSTClURwL5zWss7esRIpPSvBybCp9JPh9O9v53sTcOToiDWfuAJmuqrugycQa
QyzZW0FI+eNOfZfnMSvNJBs/5LAv2qCLgHDUX4RbT2O9zpaBkp7xAIibc3mQC8ED
CmDACy3Kt24=
=b7Ug
-----END PGP SIGNATURE-----

Can anyone "give away the Ending" of Cliff Stoll's book - and describe 
the basic methodology used to track back to the German hacker?

I don't have time to read the book. I don't need to understand all the 
little nuanced details, I just want to know the "trick".

Yours in couch potato'dom,
{your humble servant}

-----BEGIN PGP SIGNED MESSAGE-----

On Tue, 11 Jun 1996, Alan Horowitz wrote:

> Can anyone "give away the Ending" of Cliff Stoll's book - and describe 
> the basic methodology used to track back to the German hacker?
> 
> I don't have time to read the book. I don't need to understand all the 
> little nuanced details, I just want to know the "trick".

Here's the story as best as I can remember from _Cyberpunk_:

Cliff Stoll worked at LBL where he found that the account of a former worker
was being abused by a cracker.  He set up a system that would log every
keystroke the cracker made and he would automatically get paged whenever there
was an intrusion.  The connection was apparently from a Tymnet node.  Stoll got
a search warrent and traced the Tymnet connection back to a modem pool at
Mitre in Virginia.  The people at Mitre found that the cracker was dialing into
the modem pool and exploiting a security hole to dial back out to a Tymnet
node.  With cooperation from the CIA, it was found that the calls were being
made from a network in Germany called Datex-P.  When the network discovered the
extremely high long-distance bills, they traced the call back to Pengo (Hans
Huebner).

- -- Mark

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
markm@voicenet.com              | finger -l for PGP key 0xe3bf2169
http://www.voicenet.com/~markm/ | d61734f2800486ae6f79bfeb70f95348
"In Christianity neither morality nor religion come into contact with
reality at any point."
                -- Friedrich Nietzsche


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3
Charset: noconv

iQCVAwUBMb4P3rZc+sv5siulAQE7UAP/QoDxTapE1GjxXdWBD7mXIv+p4aeo2s8Z
7MZV65Faqpa/iEUEO539TkTToDr8yIUC1Mdkx3QDaJ0k5Wfw8qT2956n6kGS6CkS
hi2CgrOIlzsdBBbvdhxMHoRlA7O15uc4nQ3ghJU/FjjdpOFsQh/pwLRcdrG78L3n
X33Gi7YUdxc=
=2NkX
-----END PGP SIGNATURE-----

> Can anyone "give away the Ending" of Cliff Stoll's book - and describe 
> the basic methodology used to track back to the German hacker?

	Can't remember the exact details (and I can't remember where
my copy is :), but basically they used the ACK/NAK times in the kermit
protocol to guess his distance.  After tracing him back to some firm
in Va, they worked out to Germany and then the Bundespost ran a phone
trace to find him.  (So all y'all malicious crackers that have the
TLAs trembling in their jackboots remember to tweak your kermit (or
rz) progs to randomize response times. :)

	I'd reccommend reading the book.  It's pretty interesting.  Or
Nova did an episode ~2 years back (whenever the book came out) that
was a quick 1hr version of the whole story.

---
Fletch                                                     __`'/|
fletch@ain.bls.com  "Lisa, in this house we obey the       \ o.O'    ______
404 713-0414(w)      Laws of Thermodynamics!" H. Simpson   =(___)= -| Ack. |
404 315-7264(h) PGP Print: 8D8736A8FC59B2E6 8E675B341E378E43  U      ------