this post was submitted on 20 Jun 2023

24 points (92.9% liked)

Asklemmy

43989 readers

1486 users here now

A loosely moderated place to ask open-ended questions

Search asklemmy 🔍

If your post meets the following criteria, it's welcome here!

Open-ended question
Not offensive: at this point, we do not have the bandwidth to moderate overtly political discussions. Assume best intent and be excellent to each other.
Not regarding using or support for Lemmy: context, see the list of support communities and tools for finding communities below
Not ad nauseam inducing: please make sure it is a question that would be new to most members
An actual topic of discussion

Looking for support?

Looking for a community?

Lemmyverse: community search
sub.rehab: maps old subreddits to fediverse options, marks official as such
[email protected]: a community for finding communities

~Icon~ ~by~ ~@Double_[email protected]~

founded 5 years ago

MODERATORS

[email protected]

Can you steal a user's identity if you gain their old domain name? (self.asklemmy)

submitted 1 year ago by maggoats to c/[email protected]

28 comments fedilink hide all child comments

Just a random thought experiment. Let's say I have my account on a lemmy instance: [email protected]. One day I decide to stop paying for the domain and move to [email protected], and someone else gains it and also starts up a lemmy instance.

If they make their own [email protected], how do federated instances distinguish who's who?

Have I misunderstood the role of domain names in this?

top 23 comments

sorted by: hot top controversial new old

[–] [email protected] 4 points 1 year ago* (last edited 1 year ago)

I imagine it works exactly like email where it is possible to inherit someone else's expired domains.

Checking out the relevant specifications: ActivityPub and WebFinger

Both of them identify users by URL, there is no numeric ID, UUID, or public key.
Using IDs or UUIDs would not be secure since the imposter could just copy the ID from the previous user as well as the username and domain name.
Verifying identity would necessitate the user having a public key as their unique identifier, and federated servers performing a challenge-response that requires the user to have the corresponding private key for that public key.

In conclusion, it certainly seems like you could take over someone else's domain name, and I suspect that public key cryptography is the only way to avoid this.

(edited to add: expired domains aren't the only attack surface here, domain takeover is also a thing, either by transferring the domain or simply changing the DNS records.)

[–] Setarkus 4 points 1 year ago (1 children)

I don't think you have to worry about that since user's data should be stored on the instance they registered on, which means that data should only be stored on those servers (I don't think that kind of data would be federated, correct me if I'm wrong).
So unless someone were to restart those servers with the same domain name and the data intact, it shouldn't happen.

[–] fubo 16 points 1 year ago* (last edited 1 year ago) (4 children)

I've only read the ActivityPub spec; I haven't read the Lemmy code.

With that in mind, my impression is —

The new domain owner — if they set up an ActivityPub server instance (e.g. a Lemmy) and got a list of the old user's post URLs — might be able to delete or edit the old user's posts stored on other instances. That is a vulnerability, albeit a small one.

If the old user was still listed as a moderator of communities hosted on other instances, the new domain owner might be able to take over that moderator role.

One way to fix this would be for instances to issue a public-key cryptographic identity to each user, and distribute users' public keys to other instances. Then activities purporting to be from that user would need to be signed by that user's private key.

Users' private keys would stay local to their home instance, so users don't have to do any key management themselves.

This would mean that if an instance goes away (and its key material is destroyed) then nobody can ever act as any of those users again. A new user created with the same username and domain would be a distinct user for all other instances too.

[–] [email protected] 6 points 1 year ago (2 children)

That is a vulnerability, albeit a small one.

"Small one" is very wrong here. This is by far the largest gaping security hole in the whole specification.

[–] fubo 2 points 1 year ago

Depending on DNS for security is generally a bad idea.

[–] [email protected] -1 points 1 year ago (2 children)

Since when is stealing a domain name easy? If it would be then google.com would redirect to another scam site every five minutes.

The only way you're going to steal a domain is if the owner stops paying for it.

If you steal gmail.com you could impersonate anyone with a gmail email address. How is that an argument?

[–] [email protected] 1 points 1 year ago (1 children)

Since when is stealing a domain name easy?

You either social engineer the needed data or hack the domain owner and change the Admin-C or Tech-C and then either directly or by request change the IP for that domain. You could also bribe some one working there or someone who works for the registrar or somehow gain access to the mail account of Admin-C or Tech-C.

https://www.hackingloops.com/domain-hijacking-how-to-hijack-domain-names/

You could also try to poison the instance’s DNS cache so the domain in question is resolved to an IP where the server is under your control.

https://en.wikipedia.org/wiki/DNS_hijacking

You could also register domain names that are either unpaid for whatever reason and thus marked as in transit and if the transit period is over you just claim the address.

https://en.wikipedia.org/wiki/Domain_drop_catching

And since you mentioned google.com:

https://money.cnn.com/2016/01/29/technology/google-domain-purchase/index.html

To recite @[email protected]: Depending on DNS for security is generally a bad idea.

[–] [email protected] 0 points 1 year ago (1 children)

Sure, but if you lose your domain you already lost. That's it, game over.

I do agree it would make sense to issue every Lemmy instance and every user an asymmetric key pair they can sign against, just for extra security. But that might also break things because instances per domain are no longer unique. You can have lemmy.ml@publickey1 and then lemmy.ml@publickey2 and then lemmy.ml@publickey3 and so on. It would be an absolute mess.

This doesn't even have to be an attack. A new instance owner might decide to re-setup their instance and nuke everything or they simply lost the data. Or on a faulty Lemmy update things break and the private key gets regenerated or jumbled up. Especially right now in the early stages of this platform where things are bound to go wrong you don't want to accidentally nuke an entire instance.

What do you do then if a legitimate owner sets up the instance under the same domain again?

Besides that, if an instance really gets removed (which basically happens if someone takes over the domain, they don't have access to the instance data itself) other instances can simply defederate in an emergency. Though the only damage would be moderator accounts on other instances. The content is dead the moment the instance dies anyway (there just isn't a mechanism yet to clean it up if there is no delete events being sent, but that will probably come).

[–] [email protected] 0 points 1 year ago (1 children)

You can have lemmy.ml@publickey1 and then lemmy.ml@publickey2 and then lemmy.ml@publickey3 and so on.

The key should OF COURSE not be a part of the URL. It should also not be instance specific or specific to a certain federated server. It should be in the protocol itself. A field in the Actor object where a public key can be placed and then whenever an action is done, it gets signed. The private key stays with the user.

All of your other considerations would automatically become non-issues, since the key pair stays with the user and not on the instance. As long as the public key field is intact it can be verified that the action was performed by a specific actor. And if not, it can be seen as unverified.

You could also bind administrative activities to key-based authentication.

[–] [email protected] 0 points 1 year ago (1 children)

This was an example, not an identifier.

lemmy.ml is the domain. And the instance on that domain has a private and a public key.

If you nuke your first instance and recreate it the keys will be different, which means you suddenly have two different instances for lemmy.ml when the new instance starts to federate. Which basically is lemmy.ml-1, lemmy.ml-2, ..

So what should other servers do? Only accept the first public key they ever saw for a domain as an instance? Then block new instances from the same domain? Or is there a way to differentiate the instances? Or do you nuke all content of an old instance when a new one pops up with a different public key?

If someone creates a second instance for the same domain all hell breaks loose either way. Because the new instance can have [email protected] that already existed with the old public key. Should federation just crash at that point? Throw an error? Block this user because it existed in the past? Treat it as a new user, but with the same name (which would be horrible UI wise)?

[–] [email protected] 0 points 1 year ago (1 children)

I still don't get what you complain about.

In an alternative timeline the keys are in no way related to any instance or domain or whatever. Not even to identically named Person objects on a recreated instance. All Activity objects are signed with a specific key. The Actor is also signed with the specific key. The private key is not stored anywhere except on the machine the user using the actor from.

All activities performed by an actor and the actor are signed. If you copy over the activities to another instance the sign is still valid. If you rename the instance it is still valid. If you modify the action or the actor it becomes invalid. (Somewhat similar to how mail signing works.)

If you reuse a hacked/stolen/whatever actor, all actions you perform with this actor are unverified because the person misusing the actor cannot sign the actions. If you change the public key stored in the Actor object all previous actions cannot be verified to be done by the actor. This could be solved to make the public key store in the Actor a list. So you can add multiple keys with validity start and end date (all signed with the next key).

[–] [email protected] 1 points 1 year ago (1 children)

You still don't seem to grasp the issue I'm pointing to.

You have instance 1, lemmy.whatever, this instance federated content to lemmy.ml. So now lemmy.ml holds content from lemmy.whatever.

Instance 1 gets nuked. Either because someone stole the domain, or the admin simply lost the private keys and had no backup. Or they had a backup but it's old and half their users got lost. A new Lemmy instance gets set up on lemmy.whatever (with a new key obviously). This is Instance 2.

Now lemmy.whatever starts federating content to lemmy.ml, but from instance 2.

How do you differentiate content and users from instance 1 and instance 2? It's the same domain, but different instances as the keys don't match. Do you block instance 2? Do you delete everything from instance 1 and now instance 2 is the "true" instance for the domain lemmy.whatever? Do you mark all new content from instance 2 as "unverified"?

Sure, with private keys in place a user [email protected] from instance 2 can't modify content from the instance 1 user [email protected]. But the instance 2 user could create new content under the name of the old user. How is this federated? Do other instances show the guy as test(2)@lemmy.whatever because the keys don't match?

[–] [email protected] 1 points 1 year ago (1 children)

You have instance

Let's stop it here. Instances are completely irrelevant in my idea.

but different instances as the keys don’t match

*sigh* The keys are in the Actor objects and in the Action objects and not in the instance. You cannot validate any instance, you cannot validate if an action was performed on a specific instance. You cannot prevent actors of the same name after the previous instance was wiped.

All you can do is validating if an action was performed by an actor existing at the time the action was perfoed and that both were signed with a specific key.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

So the only things you secure are access to existing posts, comments and roles, but without any further checks if this is still the same user, correct?

So if [email protected] creates 10 posts, 100 comments and is the moderator of 5 communities (on other instances) then the public key would secure that only that user can interact with that data. Makes sense.

But now the domain gets stolen, a new Lemmy instance is set up, a new [email protected] is set up. This user is named [email protected], exactly the same as the original one. They just don't have the right key to interact with their old content.

Now that user wants to moderate one of those communities again, are they treated like a different user (because keys don't match)? Or just locked out (because you can't have two users with the same name as moderator for the community)? Your whole idea makes sense, but when it comes to enforcing those ideas you run into a dozen issues both for federation and when it comes to present the data in the UI.

And you get phishing issues on top. If they are treated as separate users by other instances, they could just write another legitimate moderator "Hey, it's me, [email protected]. I got accidentally kicked out of the community, can you re-invite me as moderator please?" so all the work you put in for security is for naught.

[–] [email protected] 1 points 1 year ago

So the only things you secure are access to existing posts,

The only thing I secure is that for a given Action by a given Actor it can be validated that those were signed with a given key.

So if [email protected] creates 10 posts, 100 comments and is the moderator of 5 communities (on other instances) then the public key would secure that only that user can interact with that data.

Everyone can interact with that data, but since those are signed with a specific key the sign would become invalidated.

Now that user wants to moderate one of those communities again, are they treated like a different user (because keys don’t match)?

Since the key and signature are just additional attributes of the Actor object they'll be the same user federation-wise. An instance admin needs to manually validate why the Actor uses a different key now. If the Actor is used to perform malicious things it can be verified that those things are done with a different key. What's done with this information is up to the instance admins.

If they are treated as separate users by other instances, they could just write another legitimate moderator

Exactly. Key signing does not prevent social engineering.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago) (1 children)

You would be surprised: https://money.cnn.com/2016/01/29/technology/google-domain-purchase/index.html

Google.com, one of the most valuable domains on the Internet, was mistakenly sold for $12 last fall.

Google paid $12,000 to get it back.

But you are right about email, it is about the same.

But with time we could be more careful in federation to keep track of domains expiration dates and owners.

Maybe just instances need to be verified with public/private keys and not all accounts on them.

[–] [email protected] 2 points 1 year ago (1 children)

It absolutely makes sense to secure content and especially moderator positions in other communities by public/private keys.

But look at my replies to /u/Dirk below. If someone actually takes over a domain, sets up a new Lemmy instance and creates the same user again (but without matching keys), how should other instances treat that user? Like a new one? Or block all federation? Do you get warnings interacting with that user (as they could just write another community moderator to invite them "again")?

[–] [email protected] 1 points 1 year ago

All valid arguments, code needs to be checked abou what is possible to implement. Even if we start with one way of dealing with those instances, it will be possible to chamge in the future.

Thank you for good discussion in this thread.

[–] trachemys 3 points 1 year ago (1 children)

But does ActivityPub actually have public keys? That would need to be in the protocol I think.

[–] fubo 2 points 1 year ago

It would need to be added, but the protocol is extensible ... and in less obnoxious ways than applying PGP to email.

[–] Setarkus 2 points 1 year ago

Oh that's interesting. Now I'd really like to try that out :))

[–] [email protected] 1 points 1 year ago

Maybe it would be enough for instances to have their keys and to be securely identifiable, and not all user accounts?

[–] [email protected] 1 points 1 year ago

Ohh interesting. I don't know, although I think that'd be rare because most people use big instances. Although maybe if a big instance goes down someone could reuse their domain name and remake all those accounts?

load more comments