Home page logo
/

bugtraq logo Bugtraq mailing list archives

Re: Popular Net anonymity service back-doored
From: "Thomas C. Greene " <thomas.greene () theregister co uk>
Date: Thu, 21 Aug 2003 05:05:19 -0700

I agree that the dirty work has to be done on the proxy, but it's reasonable 
to imagine that the client update was issued to maintain compatibility with 
whatever was done to the proxy software. Maybe the two are unrelated as the 
group says, but how can I trust them when they continue to soft-pedal the 
security implications of the back door?

Yes, the code sort of shouts at you, and this may well be a deliberate heads 
up.  However, the group is still in denial, insisting that their service is 
secure (see the press release linked in the Register story). It's not secure, 
and claiming that it is taints anything else they may be doing on behalf of 
users. They're *still* saying it's impossible for anyone to intercept users' 
traffic or identify them. That simply isn't true.  

It's likely were legally prevented from issuing a clear warning, which is why 
I say they should have taken the service down in protest.  I don't know 
German law, but I'd be surprised if the courts can force you to provide a 
communications service just so the Feds can use it.  

Leaving a hint in the source and waiting for someone to call them on it may be 
a legal strategem, but it's not a good way of maintaining user trust.  It 
took too long for this to become public.  A better way to maintain trust 
would be to stage a protest shutdown, or, if that's legally risky, a silent 
shutdown and a subsequent leak to the press.  No decent reporter would reveal 
their source in a case like this, and approaching a journo based in another 
country would add another layer of protection. 

chrz,
t.

On Thursday 21 August 2003 11:38, Florian Weimer wrote:
"Thomas C. Greene " <thomas.greene () theregister co uk> writes:
traffic might be going straight to Big Brother, right? Wrong. After
taking the service down for a few days with the explanation that the
interruption was "due to a hardware failure", the operators then required
users to install an "upgraded version" (ie. a back-doored version) of the
app to continue using the service.

This is technically incorrect.  As far as I know, the client update is
completely unrelated.

The logging functionality has been implemented in the mixes
themselves, otherwise you would be able to circumvent it by using a
different client.  The CVS commit occured on 2003-06-27.  Logging is
implemented this way: if the last mix in the cascade (which sees the
request in the clear) detects a suspicious request, it is logged
together with an ID.  The ID is transmitted (through the cascade) to
the first mix, which logs the ID and the IP address.  Combining the
two log files, it is possible to collapse the cascade and backtrack
the requests.  This exploits that TU Dresden operates both the first
and last mix in the Dresden--Dresden cascade (which is the only that
works reliably, AFAIK).

An employee of TU Dresden described this scheme in an interview with
Heise Online, a German online news site, back in October 2001.  He
announced an implementation within the next six months, but I don't
know at the moment if he was speaking for the JAP project as a whole,
or if he was just expressing his own ideas.

According to the news sources I have read, the court requested
surveillance based on the target IP address.  However, the source code
does not contain code to monitor specific (target) IP addresses, but
an elaborate URL screening facility, based on regular expressions.
Just by specifying ".*", it should be possible to log all requests
(and the corresponding IP addresses).  I don't know why the source
code doesn't implement the surveillance based on IP addresses, as the
court allegedly requested.

"What was the alternative? Shutting down the service? The security
apparatchiks would have appreciated that - anonymity in the Internet
and especially AN.ON are a thorn in their side anyway."

Note that this kind of target-based monitoring would be much harder on
the plain Internet unless the remote site is willing to cooperate.  A
broken anonymizer makes this type of surveillance quite easy.

But that's not the point. Disclosure is the point. The JAP Web site still
claims that anonymity is sacrosanct: "No one, not anyone from outside,
not any of the other users, not even the provider of the intermediary
service can determine which connection belongs to which user."

The official declaration ("Selbstverpflichtung") of the mixes, which
promises that neither logging will be enabled nor backdoors will be
implemented, hasn't been updated either.

However, perhaps the JAP team at TU Dresden hadn't much choice.  I
haven't seen the court order, but I could imagine that they weren't
allowed to inform the users because it would have harmed the criminal
investigation.  Following the order while fighting it within the legal
system is perhaps a wiser choice than just resisting it (and thus
breaking the law yourself).  But I agree that it takes them awfully
long to update their web site, now that some information is public.

Finally, they could have avoided all the hassle if they hadn't
published the source code.  Why did they publish?  I don't believe
it's an accident.

For BUGTRAQ readers: Symantec strips message headers.  The original
To: and Cc: are:

To: bugtraq () securityfocus com, full-disclosure () lists netsys com
Cc: "Thomas C. Greene " <thomas.greene () theregister co uk>


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]