Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
Privacy Security Upgrades

Tor Users Urged To Update After Security Breach 161

An anonymous reader writes "If you use Tor, you're cautioned to update now due to a security breach. In a message on the Tor mailing list dated Jan 20, 2010, Tor developer Roger Dingledine outlines the issue and why you should upgrade to Tor 0.2.1.22 or 0.2.2.7-alpha now: 'In early January we discovered that two of the seven directory authorities were compromised (moria1 and gabelmoo), along with metrics.torproject.org, a new server we'd recently set up to serve metrics data and graphs. The three servers have since been reinstalled with service migrated to other servers.' Tor users should visit the download page and update ASAP."
This discussion has been archived. No new comments can be posted.

Tor Users Urged To Update After Security Breach

Comments Filter:
  • by Anonymous Coward on Thursday January 21, 2010 @10:08PM (#30855820)

    Roger's entries to date on the subject (excluding first page linked within /. summary):

    (this is for those who are too lazy to page through mailing list threads, this post is
    missing other individuals replies as well as future replies from Roger and others)

    http://archives.seul.org/or/talk/Jan-2010/msg00165.html [seul.org]

    Here are some more technical details about the potential impacts, for
    those who want to know more about Tor's innards:

    ----- #1: Directory authority keys

    Owning two out of seven directory authorities isn't enough to make a new
    networkstatus consensus (you need four for that), but it means you've
    only got two more to go. We've generated new v3 long-term identity keys
    for these two authorities.

    The old v3 long-term identity keys probably aren't compromised, since
    they weren't stored on the affected machines, but they signed v3 signing
    keys that are valid until 2010-04-12 in the case of moria1 and until
    2010-05-04 in the case of gabelmoo. That's still a pretty big window,
    so it's best to upgrade clients away from trusting those keys.

    You should upgrade to 0.2.1.22 or 0.2.2.7-alpha, which uses the new v3
    long-term identity keys (with a new set of signing keys).

    ----- #2: Relay identity keys

    We already have a way to cleanly migrate to a new v3 long-term identity
    key, because we needed one for the Debian weak RNG bug:
    http://archives.seul.org/or/announce/May-2008/msg00000.html [seul.org]

    But we don't have a way to cleanly migrate relay identity keys. An
    attacker who knows moria1's relay identity key can craft a new descriptor
    for it with a new onion key (or even a new IP address), and then
    man-in-the-middle traffic coming to the relay. They wouldn't be able to
    spoof directory statements, or break the encryption for further relays
    in the path, but it still removes one layer of the defense-in-depth.

    Normally there's nothing special about the relay identity key (if you
    lose yours, just generate another one), but relay identity keys for
    directory authorities are hard-coded in the Tor bundle so the client
    can detect man-in-the-middle attacks on bootstrapping.

    So we abandoned the old relay identity keys too. That means abandoning
    the old IP:port the authorities were listening on, or older clients will
    produce warn messages whenever they connect to the new authority. Older
    Tor clients can now take longer to bootstrap if they try the abandoned
    addresses first. (You should upgrade.)

    ----- #3: Infrastructure services

    Moria also hosted our git repository and svn repository. I took the
    services offline as soon as we learned of the breach -- in theory a clever
    attacker could give out altered files to people who check out the source,
    or even tailor his answers based on who's doing the git update. We're
    in pretty good shape for git though: the git tree is a set of hashes
    all the way back to the root, so when you update your git tree, it will
    automatically notice any tampering.

    As explained in the last mail, it appears the attackers didn't realize
    what they broke into. We had already been slowly migrating Tor services
    off of moria (it runs too many services for too many different projects),
    so we took this opportunity to speed up that plan. A friendly anonymous
    sponsor has provided a pile of new servers, and git and svn are now up
    in their new locations. The only remaining Tor infrastructure services on
    moria are the directory authority, the mailing lists, and a DNS secondary.

    ----- #4: Bridge descriptors

    The metrics server had an archive of bridge descriptors from 2009.
    We used the descriptors to create summary graphs of bridge count and
    bridge usage by country, like the ones you can see at
    http://metrics.torproject.org/graphs.html [torproject.org]

    So it's conceivable that some bad guy now has a set of historical bridge
    data -- meaning he knows addresses and public keys of the bridges, and
    presumably some of the bridges are still running at those addresses and/or
    with those public keys. He could use this information to help governments
    or other censors prevent Tor clients from reaching the Tor network.

    I'm not actually so worried about this one though, because a) we didn't
    have that many bridges to begin with in 2009 (you should run a bridge!),
    b) there seems to be considerable churn in our bridges, so last year's
    list doesn't map so well to this year's list), and c) we haven't been
    doing a great job lately at keeping China from learning bridges as it is.

    Hope that helps to explain,
    --Roger

    http://archives.seul.org/or/talk/Jan-2010/msg00167.html [seul.org]

    On Wed, Jan 20, 2010 at 11:12:29PM -0500, Peter Thoenen wrote:
    > > In early January we discovered that two of the seven directory
    > > authorities were compromised (moria1 and gabelmoo), along with
    > > metrics.torproject.org, a new server we'd recently set up to serve
    > > metrics data and graphs. The three servers have since been reinstalled
    > > with service migrated to other servers.
    >
    > While the issue was resolved, could this of had an impact had they known
    >what they broke into between the time of breach and time of discovery?

    Yes, depending on how paranoid you want to get.

    I don't think they could have done anything particularly devious with
    the directory authority. We've got that pretty well sorted out with the
    distributed trust thing -- nothing moria1 does can rig the consensus
    by itself.

    So it's really a question of the services running.

    Moria was running a nameserver for torproject.org (still is), so they
    could send web requests elsewhere. If people check SSL certs, no problem
    (modulo the usual points about SSL not being perfect); if they don't
    check SSL certs, we hope they check package signatures. This risk isn't
    specific to our machines though -- your local ISP can lie to you about
    your DNS resolves, or some jerk could redirect our bgp record like how
    Pakistan stole Youtube for a few hours last year.

    It was also the mail host for @torproject.org, though most of the mails
    went off to other mail servers after that. So they could have read my
    mail. Most of my mail is public (and/or boring) anyway though.

    I could imagine that they might try to sneak in a commit to the git
    repository. We have a hook that mails all commits to the mailing list,
    and we watch that pretty well. But they could disable the hook during
    their commit. As I mentioned in the earlier mail, the git tree is made up
    of hashes, so they can't just modify it outright. I've looked over the
    'git log' output, and didn't find anything odd. It might be neat to do
    an automated comparison of "mails that made it to the mailing list" vs
    "commits to the git repository", if we wanted another layer of checking.

    Svn is less secure. It's just a database, and people can muck with it how
    they like. We've compared several of the svn repositories to backups, and
    nothing looked out of the ordinary. Good thing we moved Tor, Torbutton,
    BridgeDB, etc to git last year. The website wml files are still in svn
    and not git though, to make it easier for our volunteer translators;
    give us a holler if you find "Tor sucks" scribbled in some corner. :)

    If you want to scale up on the paranoid meter, you could imagine ssh
    client buffer overflows for the developers when we connected to it. That
    rabbit-hole goes as far as you like.

    Speaking of rabbit-holes, my gpg key is nearly a decade old and only
    1024 bits. Sometime in the next little while I'm going to switch to a
    bigger one.

    > Do we know how they broke in?

    As I understand it, we have a 450G disk image from one of the machines
    sitting somewhere in Canada, but not anywhere near any of the Tor people.

    The attacker(s) were sloppy, so we know some things like the name of the
    local-to-root exploit they used (which by its name works on a surprisingly
    wide spread of kernel versions... security is hard). I still don't know
    how they got in to moria originally, though. Too much was going on on
    that machine.

    --Roger

    http://archives.seul.org/or/talk/Jan-2010/msg00169.html [seul.org]

    On Thu, Jan 21, 2010 at 12:25:08AM -0500, grarpamp wrote:
    > It would be easier to just sign the git revision hashes at various intervals.
    > Such as explicitly including the revision hash that each release is
    > made from in the release docs itself. And then signing that release.
    > That way everyone... git repo maintainers, devels, mirrors, users...
    > can all verify the git repo via that signature. Of course the sig key material
    > needs to be handled in a sanitary way, but still, it's the idea that matters.
    > And git, not svn, would need to be the canonical repo committers commit
    > to, etc.
    >
    > Thanks for Tor.

    We do sign the git repository for each release (stable and development).

    Do a git clone of Tor, and then 'git tag -l'.

    Saying the git hash of the release in the release notes is not a crazy
    notion though.

    --Roger

  • Re:Tor weaknesses (Score:5, Informative)

    by v1 ( 525388 ) on Thursday January 21, 2010 @10:11PM (#30855866) Homepage Journal

    They don't even use encryption and

    Oh but they do, and that's the key to the problem. Everyone and their dog knows where the C&C servers are, and can monitor the commands sent out. Problem is, the commands are cryptographically signed, usually with a hideously large key (last one I saw was 2048 BYTES) so you can't subvert their network. Improperly signed commands are merely ignored.

    The bot herders get their anonymity from any of a hundred ways to anonymously sign into the IRC C&C channel. I'd speculate that most of them use TOR to do so.

  • Re:Sooo...... (Score:1, Informative)

    by Anonymous Coward on Thursday January 21, 2010 @10:33PM (#30855992)
    I love it when clueless people comment and show their ignorance, it's good for future reference.

    It still seems this breach is unrelated to Tor itself. To be clear, it doesn't seem that anyone specifically attacked our servers to get at Tor. It seems we were attacked for the cpu capacity and bandwidth of the servers, and the servers just happened to also carry out functions for Tor.

    * Does this mean someone could have matched users up to their destinations?
    No....

    * Does this mean someone could have learned more about Tor than an ordinary user?
    Since our software and specifications are open, everyone already has access to almost everything on these machines...

  • Re:Sooo...... (Score:3, Informative)

    by Anonymous Coward on Thursday January 21, 2010 @10:39PM (#30856026)

    I spent a bit over a year working with the FBI gathering information on a pedophile ring who was using one of our servers (to coordinate picture trading going on in Asian image board sites). Neither agents' opinions, the content gathered, nor the actual research I've seen, agree with your unsupported assertion that "they are one and the same". Though, two troll paratrooper points for accusing those who disagree with you of naivete. Good show, golf claps all around.

    I also don't know to what extent the "pedo" content in actual prepubescent kids, versus underage pubescent ("jailbait"). No, I don't really want to know either. Anyway, ephibophilia is illegal, but arguably medically normal, and ephibophiles and pedophiles make up separate populations.

  • Re:Sooo...... (Score:5, Informative)

    by clang_jangle ( 975789 ) on Thursday January 21, 2010 @11:33PM (#30856344) Journal

    But until it's as simple as hitting a button in Firefox to use Tor, of course it's only going to be the enthusiasts and scumbag fringes that'll put the time into researching and securing their privacy online.

    Duh! [mozilla.org]

  • Re:Sooo...... (Score:3, Informative)

    by trytoguess ( 875793 ) on Thursday January 21, 2010 @11:50PM (#30856432)

    This is somewhat tangential, but there is illustrated porn where just about any deviance can be catered to without harming a minor. Actually molesting a child is wrong of course.

  • Re:Sooo...... (Score:2, Informative)

    by larry bagina ( 561269 ) on Friday January 22, 2010 @12:32AM (#30856642) Journal
    tor also lets you run an (anonymous) file server.
  • by VortexCortex ( 1117377 ) <VortexCortex&project-retrograde,com> on Friday January 22, 2010 @12:33AM (#30856644)

    Wait... Anyone can be a TOR node [torproject.org] and it's still secure.

    TOR data is very encrypted.

    It doesn't matter if the hardware or software is compromised, it's still secure because a TOR node is just one node in a chain of encrypted nodes. You encrypt your data 5 times if you're sending it through 5 nodes.

    Each node takes off one layer of encryption and forwards the still encrypted data to the next node. If any intermediate nodes (2 3 4 in our 5 node example) are compromised (in software or hardware), they can not see the message in plain text, or determine the originating IP or destination IP of the traffic.

    If the first node is compromised it can see your source IP, but not the destination IP or any part of the message (it's still encrypted.)

    If the exit node is compromised it can see the destination IP, and clear text message, but not the source IP.

    These multiple layers of encryption mean that if any one node is compromised the system is still very secure.

    Taking off a layer of encryption at each router is like peeling an onion... hence, "The Onion Router".

    (this is an oversimplified explanaion -- if you're talking compromised code repositories, viruses and trojans are usually not delivered as source code, the tampering would be evident.)

Chairman of the Bored.

Working...