Hacker News new | ask | show | jobs
by mschwar99 3249 days ago
From what I remember poking around at Hansa that's not true. Each vendor / user had a public key associated with their account. All text communication through the website was supposed to be with GPG encrypted text secured by private keys unavailable to website.

So law enforcement has lots of encrypted text along with some clear text from users not informed enough to follow any kind of opsec.

4 comments

Law enforcement could have easily MITM'd the PGP. They replace the public key of a vendor with their own public key (on the vendors's page, without the vendor's/buyer's knowledge), then the buyer address gets encrypted with that public key. Then they decrypt and resend the message using the sellers original public key.

I really wonder if this happened at all

They almost certainly did. I do market research and a number of vendor keys changed on Hansa and Dream on June 23rd. Some had various comments in them claiming to be older, e.g. "EST June 2016".

Dutch Police released a statement claiming as much http://politiepcvh42eav.onion/hansafaq.html

I diffed a key I recently used on Hansa with one the same vendor on Grams and it appears that the key wasn't updated.

Maybe this was done on a case-by-case basis or Grams updated their keys to the new LE keys.

Interesting. What do you do with your market research?
I'm a developer on the OpenBazaar project which is a p2p Bitcoin market. Because DNMs are the most popular Bitcoin marketplaces I keep up with them and their features and trends. They're great sources for discovering security concerns.
Can you give an example of some of the security concerns you have discovered? Do you keep a formal list of threat vectors? I would have thought they are pretty much the same as regular web apps.

PS. OpenBazaar seems to have received $3M funding. Interesting about change for a project started by Amir Taaki given his very anarchist professions.

PPS. Desktop client seems a bad thing to develop first (in the true tradition of Bitcoin!). Perhaps you guys could have stuck with network client daemon + API for starters. Anyway, good luck.

The desktop client is just the GUI for the backend:

https://github.com/OpenBazaar/openbazaar-go

My first thought as well.

Furthermore, in order to lower the risk of anyone detecting this here's something the LEO could do:

1. They seize control of the servers.

2. They make note of who is an existing user and keep serving them the real PGP keys of other pre-existing users.

3. For anyone who registers after the point in time where LEO controls the servers, replace the PGP keys of sellers and also the keys of these new users with MITM key pairs.

Then when they run the site for a month as they did and they have the influx of users they got from AlphaBay, they will have plenty of evidence on all of the sellers that are active during that period of time due to there being so many new users all of whom you are MITMing, regardless of whether the sellers are new or old because the old sellers are also being MITMed in all exchanges they have with new users.

The sellers were the primary target of interest, so the LEO got what they wanted.

All of what I said is just something they could have done though. Not saying that it's what they actually did.

The impression that I get is that after they busted Alphabay, they nabbed a number of sellers and possibly some large buyers, who were held incommunicado. When there was a big migration from Alphabay to Hansa of both customers and sellers, there was an opportunity to set up many of those sellers' entire presence from scratch there. So it wasn't just the site that was compromised, but many of the largest individual sellers themselves, physically.

Of course, I know nothing and have just heard of either of those sites this morning.

While I doubt that many people check the vendor's public keys, it would just take one person to notice that a vendor has a different public key from another site (for example, AlphaBay, since there must have been lots of users moving to Hansa from there). If they questioned the vendor about it, they'd discover something was wrong. This would then blow the cover of the police, or at the very least be a big red flag showing that the site had been hacked.

In short, I doubt the police did this kind of thing because they risked blowing their cover for the sake of getting some buyers' addresses.

Also, these sites tend to have a big button labelled 'encrypt my message' - which ostensibly does all the PGP for you. I'd guess that most people are lazy and just press this instead of running PGP/GPG manually. It would be trivial for the police to capture the unencrypted messages just by subverting the auto-PGP.

Then users looking at their accounts from other logins would see the wrong public key and know something was wrong. Also wonder if that happened at all
The only reason I mention that this is at all probable is because of the length of a PGP key. How often is the average user of a site like this logging in to verify even the last few bytes of a PGP pub key compared to what is saved in their software? Plus how many users would chalk it up to "oh SellerX just changed their key pair" and continue on encrypting their message with the new key
I highly doubt anyone looked at it or cared. People were most likely on there to buy drugs. Do you think they turned to their friend and asked "hey do you mind looking into this website and comparing the PGP keys with me? I just want to be sure!"
This has me curious (as a complete crypto noob): how would one defend against such a MITM attack in general?

Only send messages to vendors with known "trusted" keys and don't trust new keys? So in general, use a trusted channel for key exchange separate from the communication channel so that a MITM needs to control both channels?

Correct. This is what the PGP "web of trust" is supposed to assist with: a trusted key is either one which you have verified, in person, as belonging to your correspondent, or one which has been signed by a number of other correspondents whom you trust to verify keys (and whose keys you have verified in person).
> So in general, use a trusted channel for key exchange separate from the communication channel so that a MITM needs to control both channels?

Yes, this is how PGP verification is supposed to take place.

Someone sends you their public key, and then you meet them in person to verify it.

Of course, nothing stops the government from sending an agent to meet you, but it does raise the effort required to MITM substantially.

Using a standard channel for public key exchange is half the battle. The other half is using a trusted channel to verify the public key does indeed match the public key you were originally sent. "Trusted channel" can be broadly interpreted (and is also often subject to tampering as well)
Wouldn't they just contact the vendors as new clients? Keep the service up to keep suspicions at bay, and to keep the communications systems up.
They can't MITM secure email from buyers to vendors (the direction with actual physical addresses) unless they subvert either the buyers or vendors email server. The actual email does not go through the site.
Eh? Messages are not sent as emails. They are messages kept within the site itself, a sort of private message system.
That's got to be bittersweet, busting a perp, only to open the door to his lair to find a grid of bank safes.
> unfathomably large grid of bank safes

The size of the grid makes encryption work.

No, he means each "bank safe" is a "user profile". I.e. controlling the site didn't automatically come with the users' history on the site.
This is true, but if they had taken over the site, they could decrypt anything that the site had 'encrypted' (some sites let you either encrypt stuff yourself, or let the site do it for you... which isn't a very sensible option)
They did exactly this on Hansa. They also used this same method to break the multisig transactions that hansa used to direction bitcoins directly to LE wallets (The dutch say 2million euros worth)