Tor at heart of embassy passwords leak; "ToR isn’t the problem, just use it for what it’s made for."

[coderman <coderman@xxxxxxxxx>]

[std disclaimer: i am not speaking on behalf of the Tor project nor
any developers or employees of it.  i know Roger likes to avoid even
the appearance of such relationships with rogue third parties so i'll
void such notions up front *g* ]

---

Dan Egerstad published some more details about the source of his
embassy password list:
http://www.derangedsecurity.com/time-to-reveal%e2%80%a6/

anonymouse pointed this out back on sep. 1st and also seems to imply
that some kind of active MITM against SSL/TLS was used:
http://blog.wired.com/27bstroke6/2007/08/embassy-e-mail-.html#comment-81318789

(ok, mea culpa. if i'm going to use a pseudonym to post i should
really use Tor to do it *grin*.  the reason i claimed he was also
performing an active MITM is that i've seen this done from at least a
few exit nodes against encrypted mail protocols with forged
certificate CN and other elements.  i assumed at the time the list was
published it was Dan running these exits, but it may well be others
and he was solely sniffing plain-text credentials.  perhaps he will
clarify with a bit more detail :)  some additional comments at end of
this msg [0].

Dan correctly states in bold that "ToR (sic) isn't the problem, just
use it for what it's made for.".  this highlights the complexities and
subtleties of implementing Tor properly at both an application layer
and network layer; the details are complicated and carelessness will
get you into trouble, sometimes a lot of it...  (more to come on this
subject later this month)

---

one thing i don't agree with is the concern about some of the node
operators. "Criminals, hackers and Governments are running nodes,
why?"

there is really no reason you should trust an apparently honest
looking node more than one hosted by a government or a hacker group.
the strength of Tor's privacy comes from the decentralized nature of
node contributors; restricting the ability to contribute only
diminishes the scope of this decentralization, thus weakening your
privacy.  (not to mention suspicions fabricated against other nodes in
such an environment are useful methods to further weaken it against a
determined adversary.  recall the damage of just "some guy in IRC" as
Nick outlined so succinctly :)

expecting privacy of your traffic exiting a given node is an entirely
different matter however, and hopefully this incident and the others
like it that have occurred before (and no doubt will occur again) show
that private information (authentication credentials, personally
identifying details, etc) must never be sent in plain-text, no
exceptions.  public wireless networks are in a very similar situation
and the majority of users there are just as careless.  this will be a
painful lesson, again and again, for those who continue to ignore the
risks.

---

one last interesting tidbit posted on the 6th:
"""
Our site got shut down and we stood there not knowing why, couldn't
get any information from anyone. You aren't going to like the answer
we just dug up.

* American law enforcement officials requested DEranged Security to be
taken down *

Woho, we pissed the US of! But why? Millions of people have already
read the story and tens of thousands have those passwords.
"""

this is indeed interesting as Dan stated that the list of passwords,
even those not disclosed, did not involve any US Gov embassies or
state side facilities.  i don't remember where this comment was made,
perhaps in the comments now lost.  Dan, if you're reading this, please
correct me as needed :)

best regards,


0. more tangential commentary

0.a. the active MITM fun:

i won't say how exactly i was sure Tor was involved in the password
disclosures, but suffice it to say that just the destinations
themselves are indicative to someone paying attention, even without
watching exit traffic.  (and maybe origins too :)

as for the SSL/TLS MITM, i've seen this from some exits, and this is a
well known issue.  (even at defcon 13 one of the feds "spotted" was
exposed because his blackberry or other email client was not handling
forged certificates correctly and failed back to an insecure mode of
operation during an active MITM over the wireless there.  he was
assured by his tech staff that he would be safe because "SSL is being
used".  oops!)

refer to active protocol-version rollback attacks and social
engineering tricks used to break SSL/TLS privacy for more details.

so Dan, if this wasn't you after all, my apologies.


0.b. node reputation and automated detection of malicious activity:

it would be nice to extend torflow and/or snakes on a Tor to perform
SSL/TLS certificate checks for various protocols like https, imap-ssl,
etc.  these tools (and the scanner running on peertech) can detect
malicious DNS and web page hi jinx fairly quickly.  the remaining
protocols, however, are probably not getting looked at by anyone.

likewise, such tools once available would be a great fit for the
voting / node reputation proposals in the works.  marking these nodes
as bad exits quickly would help contain the impact of such rogue
nodes, even if strong privacy is implemented (since an active SSL/TLS
MITM would at least produce a denial of service in a good
implementation).


0.c. pissing off 'The Powers That Be' (tm) and "not winning any friends", etc

Dan writes: "Directly to the people in the security industry out there
to clarify some stuff. There is no exploit to publish, no vendor to
contact. This have been told about before with no reactions.
Publishing it yet one more time wouldn't have changed crap. Even after
publishing a full disclosure list like we did, it was first thought of
like BS and done nothing about."

you have to cede some credit to this argument, despite the fact that
such a method undoubtedly pisses people off in the process.  a
favorite comparison of security and dentistry is useful to put this
into context; it may be uncomfortable and painful, but just like those
vegetables mom makes you eat it's good for you in the long run:
http://securosis.com/2006/08/30/security-is-like-dentistry/

the proof-of-concept Tor attack this summer is a similar learning
experience, even if not the wisest idea to implement.  the Tor
developers had a patched version ready within HOURS (not days, and
certainly not weeks/months like many vendors) after it hit.

this highlights the ability of the Tor team to react swiftly and
effectively to counter even the most malicious 0day that drops out of
no where.  (hopefully a very rare event not to been seen again for a
long while :)

additionally, the nature of the flaw associated with this event was
known years ago (though we weren't aware of the research at the time
either :), and a question about the security of the Tor control port
specifically was posted to this list about a year ago without much
consideration.  full disclosure can be useful to "encourage" prompt
attention to weaknesses that expose clients/users to risks that may
otherwise be deemed insignificant, not exploitable, or simply "too
much trouble/cost/time/bad-pr to fix".


0.d. on security in general:

or, "it's the attackers who determine the effectiveness of security in a system"

Peter Gutmann made an excellent point about the nature of assessing
the effectiveness of security mechanisms implemented in a given system
in a thread about the economics of security:

http://www.mail-archive.com/cryptography@xxxxxxxxxxxx/msg07940.html
"""
Florian Weimer <[EMAIL PROTECTED]> writes:

>The tests I've seen are mostly worthless because they do not weigh their
>results based on the actual threats a typical user faces.
...
We already have really, really good metrics for this.  It's called the
commercial malware industry (blatant ad: see my Defcon talk from last week for
examples of exploit sales and pricing models).  To find out how secure
something is, look at how much exploits for it are selling for on the black
market.
... it could be argued that the best
real-world metric that we have for security comes from the attackers, not the
defenders.

(Incidentally, this powerful real-world metric is telling us that the
existing browser security model is indistinguishable from placebo :-).
"""

this is exactly the reason why the janusvm developers are always
trying to attack our own software and implementation to probe for
weaknesses that may have been overlooked and verify the assumptions of
our threat model and capability of attackers against it.  this is
called "red teaming" and the government and industry have found it
indispensable for decades.
(we're failing in some other important areas though, particularly
documentation to clearly define our threat model and implementation in
detailed specifications, as well as sources and processes related to
development of it. I promise Roger, this is being worked on, it is
just a lot of work and we're very distracted with day to day
responsibilities like onerous day jobs, meat-space drama, and the
various other time sinks that slow our progress toward this goal.
many thanks to those who have donated to janusvm; we appreciate it, it
has helped us directly, and will make good on getting it documented
and more transparently developed.)


0.FF.

"PS: Data and hard drive on each node is destroyed and I forgot
everything somehow"

lol !
... i understand this sentiment completely.  :P

best regards,