The "JAP Team" has admitted to installing spyware and tricking users into downloading it.
The purpose of the spyware is to compromise the mix servers so that there is a "backchannel"
of communication between the first and last mix, destroying all anonymity. This is done via an
embedded XML-RPC server in the Java client. Obviously any third party could also look for
such communications and piggyback on them to compromise anonymity themselves.
Effectively, JAP no longer exists as a privacy tool.
The two posts are here. This information is not reflected on the JAP webpage and the first
post may be a troll. However, the second post includes analysis of the source code available
at the Sourceforge CVS which can be verified or debunked by third parties.
---
From: jap@inf.tu-dresden.de (JAP Team)
Newsgroups: alt.test,alt.privacy,alt.privacy.anon-server,alt.fan.unabomber,sci.crypt
Subject: Re: JAP compromised, privacy community panics
Date: 14 Aug 2003 06:46:05 -0700
Organization: http://groups.google.com/
Message-ID: <26e1a3d6.0308140546.353b0413@posting.google.com >
References: <V1C1050J37830.7089699074@anonymous.poster> <9e58f7719195fe68cc183a1e50362972@remailer.frell.e u.org>
NNTP-Posting-Host: 141.76.1.122
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Trace: posting.google.com 1060868767 19080 127.0.0.1 (14 Aug 2003 13:46:07 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: 14 Aug 2003 13:46:07 GMT
Hello,
it is good to know there are people who read the source code. Yes,
your analysis of the backchannel is correct…
… but the most important thing: JAP still allows anonymous surfing,
still on the probably highest level world-wide. So there is no reason
to exaggerate a single case and read too much into things.
What has actually happened? The project operators of AN.ON received a
judicial instruction that said that the access to a particular IP
address had to be recorded for a limited time period. The background
is preliminary proceedings by the German Federal Bureau of Criminal
Investigation. Such a judicial instruction cannot be rejected without
risking severe sanctions. This applies even if you consider this
judicial instruction to be not correct. It's the same thing here: The
operators of AN.ON have taken measures against this instruction but
they have to adhere to it until a higher instance has made a decision.
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. No, in
contrast: AN.ON must be continued and made even more unassailable by
use of further mixes. If we chickened out just because of one single,
quite limited judicial decision that is still to be verified in the
next instance we obviously would not have much to contribute to the
struggle for anonymity in the Internet.
The JAP update of July did not have to do anything with this process;
it is rather a product of the suggestions for improvement by thousands
of JAP users.
However, since the judicial instruction landed on the desk at this
time, a server update (but not one of JAP) was necessary. As already
mentioned it is good to know that people actually read our source
code, but this time, it lead to the misunderstanding that the JAP was
generally opened for the sake of criminal prosecution.
Why the operators of AN.ON have not been addressing the public by
themselves, yet? In Germany, there are holidays, too, and a judicial
instruction of this kind was something perfectly new for all involved,
particularly the holiday crew.
Therefore: keep cool. AN.ON is and will remain *the* service when it
comes to anonymity. Only because one single judge has decided
(provisionally) that all access to a particular IP address are to be
recorded for a limited time period, there is no reason to throw the
baby out with the bathwater.
MfG
The JAP Team
---
Sender: Fritz Wuehler <fritz@rodent.frell.eu.org>
Comments: This message did not originate from the Sender address above.
It was remailed automatically by anonymizing remailer software.
Please report problems or inappropriate use to the
remailer administrator at <abuse@remailer.frell.eu.org>.
Newsgroups: alt.test,alt.privacy,alt.privacy.anon-server,alt.fan.unabomber,sci.crypt
Subject: Re: JAP compromised, privacy community panics
From: "Edison Carter" <edison.carter@network.23>
References: <V1C1050J37830.7089699074@anonymous.poster>
Message-ID: <9e58f7719195fe68cc183a1e50362972@remailer.frell.e u.org>
Precedence: anon
Date: Tue, 12 Aug 2003 02:08:43 +0200
Mail-To-News-Contact: postmaster@nym.alias.net
Organization: mail2news@nym.alias.net
"Captain FUD" <fud@fubar.org> wrote in
<V1C1050J37830.7089699074@anonymous.poster>
> The JAP page now has a very strange "update" on their site after the service
> was mysteriously down due to a "hardware failure.
>
> This is what it said.
>
> http://anon.inf.tu-dresden.de/index_en.html
>
>
> Mix service temporarily not available: Currently the Mixservice is Down
> due to a hardware
> failure. We try to replace the hardware as soon as possible but it might
> take some days. We are
> sorry for the inconvenience caused. (07/28/03).
>
> UPDATE! As soon as our servoce works again an obligatory Update (version
> 00.02.001) is needed
> by all users.
>
> --
>
> There is no indication of what this "upgrade" is, which is very bizarre.
> Even Microsoft explains
> "upgrades." So they mysteriously disappear and come back, ordering an
> "upgrade" with no
> apparent reason, as if they have been taken over and their hardware
> replaced, requiring
> this ham-handed segue into tricking users into installing some weird spyware.
>
> What does the new code contain but strange data like
> "CAMsg:rintMsg(LOG_INFO,"Loading Crime Detection Data....\n");"
> "CAMsg:
> \n%s\n",id,crimeBuff,payLen);"
>
> Additionally, there are other bizarre variable names that sound like
> something from a bad
> hacker movie.
>
> I would have to say that at this point, JAP is obviously compromised and
> should be avoided.
> Who got to them?
<FANFARE. A caption announces "Network 23"; although obviously produced on
tens of thousands of dollars-worth of graphics equipment, the crude overuse
of edge styles and drop shadows has conspired to give it the appearance of
cheap Letraset. Female announcer's voice over:>
This is Network 23. The network that means business now transmitting live to
the world the award-winning Edison Carter on the "What I Want To Know Show".
<Close up of reporter, sitting in the passenger's seat of the helicopter as
it flies through the gray and rain-laden skies of Dresden heading for the
site of the University. He has a tall, narrow face with intense, searching
eyes, and a shock of tousled blond hair; he is clearly holding his own
camcorder pointed directly at himself to shoot this scene.>
This is Edison Carter, reporting for Network 23, asking the questions that
*you* want answered. Tonight on the 'What I Want To Know Show', I'll be
investigating the mysterious disappearance of privacy surrounding the JAP
web mix-proxy. What I want to know is, who knows what about who's been
surfing where? And why aren't they telling us? And just how long has this
all been going on? Helping us get to the truth tonight is an anonymous
programmer and privacy advocate, and some of the things he has to say make
pretty disturbing listening.
<Cuts to prerecorded interview; anonymous programmer is visible only in
silhouette>
This is very interesting stuff. FYI, none of the crime-related stuff appears
in the two old versions of the proxytest.src.tar that I have lying around,
dated 24/02/2002 21:29 and 05/12/2002 22:19. It should be possible to tell
from the JAP Sourceforge CVS exactly when these code modifications were
introduced.
Looking at the source code, there's no ambiguity at all: the system has been
fatally compromised, intentionally and by design. There is a back-channel
from the last mix (at which point all the data is unencrypted, but the
source IP it arrived from is unknown) to the first mix (at which point the
data is encrypted, but the incoming IP address is known).
The entire security of mix-systems, whether remailers or JAP, rests on an
attacker being unable to link the encrypted activity at the entry point with
the unencrypted activity at the exit point. If a mechanism is built into the
system which breaches that condition, there is no real security in the
system.
<Cut back to Edison Carter>
But that wasn't enough for this investigative journalist. We presented the
new versions of the JAP software source code for a thorough lab analysis to
confirm the accusations made by the anonymous source known only as 'Captain
FUD'. Come with me as we go live and right now, to determine the terrifying
truth behind these allegations.
<Cut to boffin in lab; white-coated, white-haired, and obviously goes to the
same hairdresser as Einstein.>
Here's how it works. At startup time, the software in the last mix in the
chain calls CALastMix::init() (CALastMix.cpp line #82) which includes these
lines:
#ifdef LOG_CRIME
m_nCrimeRegExp=0;
m_pCrimeRegExps=options.getCrimeRegExps(&m_nCrimeR egExp);
#endif
The getCrimeRegExps function is part of the commandline option handling in
CACmdLnOptions.cpp; as an argument passed to the proxy software on the
command line, an XML file is specified, containing the XML specs for a set
of regular expressions that are loaded and precompiled by the modules in the
'tre' subdirectory.
Having set up the list of regexes and the rest of the mix's internal data,
the last mix software then enters CALastMix::loop(). This function receives
packets from the previous mix, decrypts them, and forwards them to the squid
cache that actually proxies the http requests from JAP clients to the
outside world. It contains the code (CALastMix.cpp, line #367)
#ifdef LOG_CRIME
if(payLen<=PAYLOAD_SIZE&&checkCrime(pMixPacket->payload.data,payLen))
{
UINT8 crimeBuff[PAYLOAD_SIZE+1];
memset(crimeBuff,0,PAYLOAD_SIZE+1);
memcpy(crimeBuff,pMixPacket->payload.data,payLen);
UINT32 id=m_pMuxIn->sigCrime(pMixPacket->channel,tmpBuff);
oqueueMixIn.add(tmpBuff,MIXPACKET_SIZE);
CAMsg:
Content: \n%s\n",id,crimeBuff,payLen);
}
#endif
The checkCrime function looks like this:
#ifdef LOG_CRIME
bool CALastMix::checkCrime(UINT8* payLoad,UINT32 payLen)
{ //Lots of TODO!!!!
//DNS Lookup may block if Host does not exists!!!!!
//so we use regexp....
UINT8* startOfUrl=(UINT8*)memchr(payLoad,32,payLen); //search for first
space...
if(startOfUrl==NULL)
return false;
startOfUrl++;
UINT8*
endOfUrl=(UINT8*)memchr(startOfUrl,32,payLen-(startOfUrl-payLoad));
//search for first space after start of URL
if(endOfUrl==NULL)
return false;
UINT32 strLen=endOfUrl-startOfUrl;
for(UINT32 i=0;i<m_nCrimeRegExp;i++)
{
if(regnexec(&m_pCrimeRegExps[i],(char*)startOfUrl,strLen,0,NULL,0)==0)
return true;
}
return false;
}
#endif
What this does is to separate the url from the "GET http://url/path
HTTP/1.x" request and test it against a set of regexes for matches. This
could be used to detect attempts to access specific sites or urls; also, it
could be used to detect various kinds of hacking attempts directed at
webservers, such as unicode exploits or xss. The processing here is very
simple: unless there are regexes covering all sorts of variations of a url,
you might be able to slip past the regex match by url-encoding some or all
of the url in question, or by referring to a site by IP address rather than
dns name.
It is interesting to note that the code that finds startOfUrl and endOfUrl
is buggy: it will be thrown off by putting an extra space in between "GET"
and "http://url", and will think the url has zero length. You can also fool
this code by using what is known as the HTTP/0.9 format, "GET url" without
any trailing HTTP/x.y version identifier, assuming that that format still
works anywhere. Perhaps by including PAYLOAD_LENGTH spaces in between the
http "GET" and the URL contained in the actual request, you might be able to
push the url into the second mixpacket; I haven't fully analysed the
situation, but if the last mix is only examining the first packet to come
down each virtual mix channel, and assuming the squid proxy isn't thrown off
by lots of spaces in the http request, then that would probably bypass the
detection as well. This is currently the crudest sort of NIDS there is: see
all the papers about bypassing NIDS for more ideas.
Assuming that a match is found, the line
UINT32 id=m_pMuxIn->sigCrime(pMixPacket->channel,tmpBuff);
is the next critical one: it allocates a random ID number to identify the
current packet, and sends a special packet back along the mix chain with the
CHANNEL_SIG_CRIME flag set in the mixpacket flags. It then logs the details
CAMsg:
--Content: \n%s\n",id,crimeBuff,payLen);
including the ID number and the content of the packet that triggered the
regex match. The return packet proceeds back along the mix chain until it is
received at the first mix. That mix is also running a packet-processing
loop, in CAFirstMix::loop(). At CAFirstMix.cpp line #784, we see this code:
#ifdef LOG_CRIME
if((pMixPacket->flags&CHANNEL_SIG_CRIME)==CHANNEL_SIG_CRIME)
{
UINT32 id=(pMixPacket->flags>>8)&0x000000FF;
CAMsg:
--In-IP is:
%u.%u.%u.%u\n",id,pEntry->pHead->peerIP[0],pEntry->pHead->peerIP[1],pEntry->
%pHead->peerIP[2],pEntry->pHead->peerIP[3]);
continue;
}
#endif
Here, very clearly, the ID code that was generated at the last mix and
logged along with the URL request that triggered the regex match is being
logged again, along with the incoming IP address from which the URL request
originally came.
<Cut back to Edison Carter in the helicopter, now touching down outside the
University of Dresden. In the background, a building explodes in a ball of
flame.>
BOOOOOOM!!!! What was that? It was JAP's anonymity going up in smoke.
<Edison leaps from the helicopter and sprints toward the scene of the
explosion. A number of Teutonic academics are fleeing the scene, lab-coats
in tatters, beards still smouldering. Edison scans the crowd of fleeing
professors and singles one out; he runs over and falls into step, jogging
alongside the fleeing man. The professor keeps his head down and covers his
face from the camera with his hands; Edison addresses questions to his
fleeing form.>
Dr. Federrath, I see you're quite keen on protecting your own privacy there,
but what do you say to the allegation that JAP users no longer can expect
any privacy from the mix operators?
Dr. Federrath, on the JAP project website, at
http://anon.inf.tu-dresden.de/Selbst...chtung_en.html, it quite clearly
says that "All mix providers for the JAP internet service declare in the
following official declaration, that they do not save connection log files
or exchange with other mix providers data which could be used to uncover JAP
users".
Dr. Federrath, what is this back-channel, if not an exchange of data between
mix providers for the specific purpose of uncovering JAP users?
Doctor, will you confirm that this new software places the entire JAP
project in breach of its own promise?
<The sinister doctor, having answered nothing, disappears behind a shield of
bodyguards into a limo with blacked-out windows that speed off rapidly into
the distance. Edison heads back into the helicopter which returns to the
skies, and does a to-camera shot to wrap up.>
The situation then is that the JAP system is completely compromised, as
compared to its original ideal to be a mix-mailer like system for the web.
Originally, tracking traffic through JAP would have been as hard as tracking
it through the remailers: an attacker would need to record ALL traffic at
ALL points throughout the mix-net to stand a good chance of identifying one
user's traffic. Now, the system includes a back channel, specially designed
to link the first and last mix, thereby eliminating the need to monitor all
the traffic, and making real time tracking simplicity itself. The URLs in
the http requests sent by JAP clients are compared against a list of
'criminal' URLs, and if a match is detected, the first and last mixes in the
mix-chain collaborate to record the IP address from which the request was
sent and the details of the request.
<Closing credits begin to roll over picture.>
Tune in again next week, when I'll be asking the questions you want to hear
answered, such as "Why does the JAP client software contain an XML-RPC
server?" and "Why, if the entire client is written in nice safe Java, is
there now code in there that wants to load a native dll, japdll.dll, when
there's no such dll distributed with the client package?" This is Edison
Carter, Network 23, signing off.
<Cut to black.>
Reply With Quote
