GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-10-13) - page 1 of 10
 
___________________________________________________________________
Someone Created a Tor Hidden Service to Phish My Tor Hidden Service
151 points by jstanley
http://incoherency.co.uk/blog/stories/hidden-service-phishing.html
shing.html
___________________________________________________________________
 
XR0CSWV3h3kZWg - 4 hours ago
0.002 BTC seems generous these days!Interesting post, I wonder how
common this is.
 
  krisives - 4 hours ago
  Very common look up rancid tomato proxy
 
    jstanley - 3 hours ago
    Google: No results found for "rancid tomato proxy".DuckDuckGo:
    this HN thread is the only result.Did you get the name slightly
    wrong?
 
      tyingq - 1 hours ago
      Try: rotten onions cloner
 
        XR0CSWV3h3kZWg - 1 hours ago
        If that doesn't work try:Putrid walnut skimmer
 
the_stc - 45 minutes ago
This is why we need SSL certs for .onions. DigiCert was doing this,
but they told me it is on hold. Maybe when V3 hidden services are
out?With an SSL cert, you get a cert for your .onion PLUS your
clearnet domain. Then users can access the .onion and see your real
enterprise's name.This should be doable even for
extrajurisdictional companies like mine. The key is that your
clearnet site should be a TCP-level proxy to the hidden service.
That way the SSL keys are never on an easily-discoverable system so
only IP addresses can be logged, not any contents. Slight plug:
Here's the tech design for our system: https://medium.com/@PinkApp
/pink-app-trading-latency-for-ano... (ignore the clickbait title).
This should work just fine for .onions too, even with the clearnet
entry point. For a DarkNet Market, most small buyers are probably
safe visiting over clearnet.
 
  jerheinze - 34 minutes ago
  SSL certs for .onions exist for years now, here are two examples:
  https://www.facebookcorewwwi.onion and
  https://protonirockerxow.onionAlso v3 onion services are
  available now with Tor 0.3.2.x-alpha.
 
    the_stc - 33 minutes ago
    But DigiCert says they are no longer issuing them. Probably
    because the .onion is an 80-bit truncation of a SHA1 hash so it
    doesn't meet baseline reqs?
 
      jerheinze - 28 minutes ago
      Ah, so yeah that's probably why they were waiting for v3
      onion services which are 56 characters long now (which are
      available now as mentioned above).
 
        schoen - 1 minutes ago
        I don't know what DigiCert's motivation was for suspending
        issuance of .onion certificates, but the CA/Browser Forum
        had given a special dispensation (by ballot) for issuance
        of EV certs despite the criticism about cryptographic
        strength mismatch. This dispensation didn't extend to DV,
        but it's never been revoked, so DigiCert would still
        apparently be able to continue its EV issuance if it wanted
        to! (But it looks like they've even let the
        facebookcorewwwi.onion certificate expire.)I've recently
        become an observer at the CA/Browser Forum and plan to
        bring up the subject of DV certificates for next-generation
        onion services imminently, just as soon as I'm done with my
        relaxing vacation!
 
Mizza - 1 hours ago
The guy who runs the phishing servers, "crimewave", (everything is
automated, all hidden services have these BTC phisher clones)
actually posts on r/onions sometimes. I had a good discussions
about possible counter-measures with him.
 
  devhead - 21 minutes ago
  do tell
 
    Mizza - 6 minutes ago
    Here's one of the threads from last year: https://www.reddit.co
    m/r/onions/comments/45k2ux/mitm_phishin...I appear to be
    suggesting a) sending BTC addresses as images and b) a 3rd
    party login visual verification service
 
campuscodi - 1 hours ago
The fake site was most likely created by the Rotten Onions crew.
 
PhisherPrice - 3 hours ago
Hit it offline with a denial of service attack.
 
  zethraeus - 3 hours ago
  Welcome to the dark web. It's terrible here.
 
  jstanley - 3 hours ago
  Note that since the phishing site proxies requests to the legit
  site, this also has a high risk of knocking the legit site
  offline.
 
    PhisherPrice - 3 hours ago
    Maybe with a layer 7 attack, but not with a layer 3 attack. The
    author also described the difference between the proxy request
    and a legit request, so he can just block the proxy requests.
    Try using slowhttptest. You don't even need a botnet.
 
      sp332 - 2 hours ago
      I think the article described a different response, but not a
      different request? Anyway they mentioned that some requests
      were cached, so you could request a cached object to avoid
      hitting the original host, if you wanted a level-7 attack.
 
  driverdan - 3 hours ago
  The seemingly easy way to DoS it would be to hit pages with
  Bitcoin addresses.You could even setup a hidden static page with
  hundreds or thousands of addresses and call it through that
  proxy. No load on the legit server but heavy load on the rogue
  proxy.
 
pbhjpbhj - 2 hours ago
If you can get js to execute on the server, can't you get info that
disambiguates the server?Is the a way to make the server run a
bitcoin miner, for fun really ...?
 
  jstanley - 2 hours ago
  The JavaScript I talked about ran in browsers when accessed via
  the phishing site, it didn't run on the server.
 
bflesch - 3 hours ago
I'm not a tor expert, but could this be solved by using something
like namecoin for DNS within tor? So there would be a "proper"
domain system for the .onion routes?The whole confusion comes from
the fact that tor domains have this random string added to the name
you actually want to take, right?
 
  jerheinze - 30 minutes ago
  This is properly solved by the switch to stronger encryption, the
  new v3 onion addresses protocol (available with Tor
  0.3.2.x-alpha) replaces SHA1/DH/RSA1024 with
  SHA3/ed25519/curve25519. Onion addresses are now 56  characters
  long, example: http://ffqggapqevcmylx6vtk5357i7bfjwbb6qchds3hloha
  ngshxrwvdd...Also something you may be interested in: OnionNS
  https://www.freehaven.net/anonbib/cache/onion-ns-pets2017.pd...
 
    the_stc - 28 minutes ago
    That does not solve anything. It just means the addresses are
    so long you are guaranteed no one is eyeball-comparing them.
    This makes phishing easier.
 
      jerheinze - 24 minutes ago
      Did you look into the OnionNS paper?
 
  koolba - 3 hours ago
  The string isn?t random. It?s a public key with the private key
  of the service able to decrypt content sent to it.Anyone can
  generate a key with a vanity prefix, it just takes computing
  power and the longer the match, the greater the computing power
  involved.
 
    flashmob - 32 minutes ago
    Facebook's hidden service address is particularly impressive:
    https://facebookcorewwwi.onion/It seems like everything except
    the 'i' is a prefix, a lot of computing must have went in to
    generating it.One tool to do it is called 'Shallot'
    https://github.com/katmagic/ShallotThe readme includes a table
    of estimated computing time required. A 15 char prefix like
    Facebook's is not even on the table, and a 14 char prefix is
    estimated to take 2.6 million years. There is also a GPU
    version which should be an order of magnitude faster:
    https://github.com/lachesis/scallion/blob/gpg/README.mdAlso,
    technically. the onion addresses not public keys, but derived
    from a public key. It's actually a hash of the public key.It
    appears that the hashing algorithm used is SHA1. Source: The
    last few lines of the easygen function
    https://github.com/katmagic/Shallot/blob/master/src/math.c
 
      the_stc - 26 minutes ago
      Facebook said they just looked for Facebook and got very
      lucky. corewww does not have a lot of meaning.We tried the
      same thing for PinkApp and got all sorts of much-longer
      matches that we could retcon into meaning something.
 
      tylersmith - 8 minutes ago
      FWIW I've struggled to get keys generated by Shallot to
      persist very long but haven't found the cause. We've had to
      fallback to a non-vanity address. If anybody knows what I'm
      doing wrong please let me know!
 
  djsumdog - 3 hours ago
  As explained in other comments, onion addresses are keys. However
  what you'd taking about does exist on zeronet, where people can
  buy .biz domains.
 
    ornitorrincos - 2 hours ago
    uh, out of curiosoty, how do they handle conflicts with already
    stablished domains on that tld?
 
      ReverseCold - 1 hours ago
      .bit not .biz
 
      warent - 2 hours ago
      To my understanding, there is no way to handle conflicts. If
      another person gets your private key, then they can collide
      their domain name with your domain name (and, speculatively,
      probably split traffic?)
 
      jstanley - 2 hours ago
      It's not a real TLD.
 
        koolba - 2 hours ago
        It's a real TLD, see [1] and [2]. It's just not controlled
        by a central registrar like a traditional TLD.[1]:
        https://tools.ietf.org/html/rfc7686[2]: http://www.ietf.org
        /mail-archive/web/ietf-announce/current/m...
 
          dsp1234 - 1 hours ago
          .bit is not an ICAAN or IETF recognized TLD, which is
          what djsumdog was speaking about
 
          atbentley - 26 minutes ago
          The original comment said .biz when they may have ment
          .bit
 
finnn - 4 hours ago
I wonder what the requests look like coming through the proxy. Is
there a distinct user agent? or some other header send with the
request
 
  jstanley - 4 hours ago
  It passes through the client User-Agent unchanged. I've not yet
  looked at anything else although I doubt it will do anything but
  pass through the client headers.It might be interesting to send
  confusing or contradictory request headers and see how it reacts.
 
    finnn - 4 hours ago
    yeah, i'd definitely try sending it all sorts of weird things.
    Can you setup a path that will respond with a ton of data?
    Maybe a bunch of things that it will try to parse? etc
 
      jstanley - 4 hours ago
      "GET /headers" will dump the request headers, but note this
      has gone through one layer of munging by nginx and another by
      Mojolicious, so don't draw any conclusions about what you see
      in the response without bearing that in mind!I'd be
      interested to hear if you spot anything surprising.EDIT: And
      in case you haven't seen it, "torsocks" is a tool that lets
      any (?) other program speak Tor, e.g. it works with both curl
      and nc.
 
        [deleted]
 
        finnn - 4 hours ago
        Cool! Looks like the Accept-Encoding header is being set to
        "gzip, deflate, sdch" regardless of what i send.
 
larkeith - 4 hours ago
Excellent writeup, and a good example of what types of attacks to
expect as we move forward towards a more decentralized web.
 
  ewams - 4 hours ago
  We are moving towards a more centralized web, not decentralized.
  The technology industry, and the Internet, is consolidating. Look
  at the news for all the companies being purchased by facebook,
  google, microsoft, amazon, apple, hpe and cisco. Also look at
  ISPs, Timewarner and spectrum, verizon, att, etc all are
  consolidating. It will continue to become harder to hide, or be
  anonymous, as we make this path because not only will data be
  held by just a few players, but so will the transmission lines
  only be held by a few.
 
    jstanley - 4 hours ago
    The more the "mainstream" web becomes centralised, the more
    technical people are being pushed towards working on tools for
    decentralisation and anonymity.It's happening, just not in the
    places that most people tend to look.
 
      cookiecaper - 3 hours ago
      It's not happening in a meaningful way. The technology for a
      decentralized web is already here -- it's just the normal
      web. Our artificial legal barriers are what keep it
      centralized, and those will be an issue regardless of
      technical innovation.Legalize scraping and fix copyright law
      so that users can truly assert ownership over the content
      they generate, and this will quickly become a non-issue.P2P
      technology is cool and it has its uses; I'm even developing a
      decentralized distribution thing as a side project. But it is
      more work, which means in the typical web browsing use case,
      it is slower and less convenient than a conventional 1:1
      conversation with a stable endpoint.Suggesting that everyone
      introduce four hops of latency or that we all participate in
      a multi-billion device DHT (which all just translate to "much
      slower" to the typical user) is just not a practical solution
      to these problems.The good and correct solution is to look to
      the root cause and fix it. That root cause is the incentive
      structure, including legal and financial arrangements, that
      heavily encourages the "AOLizaiton" of the web and allows the
      AOLizers to use the courts to clobber the hackers that try to
      re-liberate it.
 
    SEJeff - 2 hours ago
    And not just them, the Content Delivery Networks as well.Look
    how massive a problem cloud bleed was when that vuln was found
    in Cloud Flare.
 
ageisp0lis - 2 hours ago
Isn't this connected to crimewave's "Rotten Onions"? The author
doesn't seem to make the connection:
https://twitter.com/campuscodi/status/917231902033104896
 
  jstanley - 1 hours ago
  Thanks, I hadn't come across this. It could very well be the same
  thing.I didn't notice any XMR mining though, FWIW.