Post AWYLStlcKnZlptiO2q by blue1337blood@social.netz.org
(DIR) More posts by blue1337blood@social.netz.org
(DIR) Post #AVJsO9oHhv73l8kWno by admin@friendica.utzer.de
2023-05-03T18:16:56Z
1 likes, 0 repeats
New troll domain with many subdomains. This is a strongly recommended block for all #Fediverse services for *.mastotroll.netz.org.Please share this post!#Friendica !adminscc @utzer
(DIR) Post #AVJtIqKinJ15rKx3E8 by blue1337blood@social.netz.org
2023-05-03T18:26:43Z
0 likes, 0 repeats
@admin @admins it's actually more proof of concept of troll domain than troll domain. There is no new mastotroll attack going on, it is only about one research instance hosted by @mephisto and me as a part of my bachelor's thesis. So feel free to block it, if you want to, just wanted to clarify :)
(DIR) Post #AVJtIr8LomiQLGAgaG by hypolite@friendica.mrpetovan.com
2023-05-03T21:47:44Z
0 likes, 0 repeats
@blue1337blood @mephisto @admin The fact that you wrote "only about one research instance" shows to me that you had no prior understanding of how the troll works before deploying it publicly. This was reckless and absolutely not good research.Requests to your domain will continue long after you've pulled the DNS record because Fediverse servers assume good faith from remote hosts, and you've carelessly betrayed this trust. Next time please ask someone, anyone who's already running a server before doing any kind of research involving the Fediverse.
(DIR) Post #AVJtIrmlOX2eMb4xZg by blue1337blood@social.netz.org
2023-05-04T09:33:38Z
0 likes, 0 repeats
@hypolite @admin @mephisto Sorry for the problems I caused, I didn't intended too. The description of the vulnerability is about accounts of a victim instance, controlled by an attacker, following bot accounts on an attacker server. Anyway, is it okay, if I ask you a question about the requests by other instances, even by removing DNS entries?
(DIR) Post #AVJtIsPl3YEYJXK6M4 by hypolite@friendica.mrpetovan.com
2023-05-04T11:57:46Z
0 likes, 0 repeats
@blue1337blood Thanks, I appreciate the apology, and it’s definitely okay, even if a little late, to ask questions!
(DIR) Post #AVJtIt6IVOGGRTE4f2 by blue1337blood@social.netz.org
2023-05-04T15:50:49Z
0 likes, 0 repeats
@hypolite thank you very much for your kindness. I think the point where it started to become a problem for "main Fediverse" (as distinction to my playground) was when I accidentally created a federation between my test instance and the main Fediverse? And therefore indexing started by other instances? Because the CVE description I found was about an attack server and victim instance where accounts from the victim instance follow the accounts from the attack server
(DIR) Post #AVJtItxTJgnP6O6XXk by blue1337blood@social.netz.org
2023-05-04T15:54:12Z
0 likes, 0 repeats
@hypolite it wasn't clear (at least to me) that it would affect account not following the ones of the attack server. And when this issue persists even with removed DNS entries, does this mean the indexing process isn't checking for valid DNS entries, so every instance ever federated with another one can be malicious when at some point in time it was recognized as valid participant speaking ActivityPub? Sorry if that sounds confused and thanks for reading and your time!
(DIR) Post #AVJtIuZP2f8Z01qpfM by hypolite@friendica.mrpetovan.com
2023-05-04T16:17:44Z
0 likes, 0 repeats
@blue1337blood It's okay, let's take it in chronological order: As soon as you interact from a newly created Fediverse server with an existing server, there's a chain of events that happens in the background: The remote server probes your new server for a .well-known/node-info path. If successful, your server will be added as a "known server" Its domain can and will be shared with all the other servers the first contact server knows about. For example my own single-user server running since 2016 knows about 23,000 other Fediverse servers. These twice-removed servers will also probe your domain for fresh data, and if successful, propagate the newly known servers further through the Fediverse. Even if you pulled the DNS at that point, the Fediverse is generally forgiving for remote server availability. We may be an extreme example, but at Friendica we retry probing domains with increased delay for up to 18 months. So after you pull the DNS at that point in time, you will keep receiving probe request retries from the first and second generations of servers that have successfully probed your domain at least once, and from the third generation of servers that receive the list of known servers from the second generation and perform the initial probe. Thanks to the known servers mechanisms, most Fediverse servers know each other so there isn't a slow-start exponential increase in affected servers with your new server record from the first contact, you can be quickly known by several thousands of servers in a very short amount of time before you hit a local maxima.Now this is valid for a single domain. But I believe the "troll" you deployed also generates arbitrary domains based on a wildcard DNS record, so the damage is compounded by how many different domains were randomly generated and recorded as valid Fediverse server throughout the network.
(DIR) Post #AVJtIv8UwBD4ksGrMu by blue1337blood@social.netz.org
2023-05-04T18:04:43Z
0 likes, 0 repeats
@hypolite Thank you very much for your answer! This makes it more clear for me to trace down where federating accidentially happened. So it is very important to keep a testing environment and the main Fediverse apart (and this is where I was too unmindful, because I anticipated that it would require to follow the attack server accounts)I understand the idea with host availability: Lots of decentralized instances, run by volunteers, might not be that resourceful to have 100% availability
(DIR) Post #AVJtIvgssKiQTWMJxw by blue1337blood@social.netz.org
2023-05-04T18:05:07Z
0 likes, 0 repeats
@hypolite So then there is a certain amount of trust among Fediverse instances that none of them has interacted with a malicious server, even by accident and this is what you were describing before. And I see why this issue is normally not a problem in the wild: Around 13000 instances in the wild won't go offline all at once, so this workload is only happening during a troll attack (and yes, wildcard DNS)
(DIR) Post #AVJtIwN4LUSYaM60ie by blue1337blood@social.netz.org
2023-05-04T18:05:30Z
0 likes, 0 repeats
@hypolite Do I see it correctly that for a bigger instance to be affected by this attack it would need more troll domains, since they can overall handle more workload or do I miss something here?
(DIR) Post #AVJtIx2BsbLwdtKqoa by hypolite@friendica.mrpetovan.com
2023-05-04T18:20:16Z
0 likes, 0 repeats
@blue1337blood Yes, you're right, the effect is more severe for smaller servers without enough resource margin to handle even tens of thousands of bogus extra background tasks. In the original attack, some servers reported having stored millions of bogus server records that slowed their server to a crawl while trying to update them.
(DIR) Post #AVJtIxrEooBbCDDcNk by schmaker@schmaker.eu
2023-05-04T18:36:30Z
0 likes, 0 repeats
@hypolite If i remember correctly, then *.activitypub-troll.cf attack had same tactic - flooding workers with tasks from subdomains.I can imagine someone runs more Fedi instances at single domain, but no more than 5-10. Shouldn't attacked server itself check for this and actively defend itself? Something like "if server got requests from 10 subdomains of same domain, then suspend tasks for this domain and notify administrator if he wants to block it or allow" could save some headaches
(DIR) Post #AVJwqUw99SWxCxCEDI by blue1337blood@social.netz.org
2023-05-04T18:55:16Z
1 likes, 0 repeats
@schmaker @hypolite This attack is the source for the CVE, yes and I wanted to see exactly one server with issues, my own one. And yes, I am looking for such defenses: (double) checking for valid servers (and yes, one can mimic valid servers since the element for compatibility is ActivityPub), DNS lookups, limits for n instances per subdomain... If I see it correctly, the attack is mainly annoying/nasty and makes extra work by the need to intercept manually
(DIR) Post #AVJxKCOUeq5yNzcMUa by utzer@social.yl.ms
2023-05-04T18:46:00Z
1 likes, 0 repeats
@schmaker @hypolite yes or throttle them, make them all lowest priority or so.
(DIR) Post #AWYLSrXibVGmwDCG6S by utzer@social.yl.ms
2023-05-03T18:30:42Z
0 likes, 0 repeats
@blue1337blood @mephisto @admin yes I blocked it, it is clogging up my queue with a few hubdred sub domains to be indexed or so, so looking up all server profiles. Also the servers response takes very long, which causes the queue jobs to run into a timeout, which causes the tasks to take longer.So yes, a block is necessary.
(DIR) Post #AWYLSsYSqDSc4oYMu8 by utzer@social.yl.ms
2023-05-03T18:33:48Z
0 likes, 0 repeats
@admin @blue1337blood @mephisto maybe even a few thousand tasks in the queue, 7000 task were cleared after adding it to the blocklist, but there is still tasks for this domain in the list.Also suggestion. Never use a nice domain like that for such a test, I think some people will block *.netz.org
(DIR) Post #AWYLSt8yeSfRu3dWoi by utzer@social.yl.ms
2023-05-03T18:35:21Z
0 likes, 0 repeats
@blue1337blood @mephisto is https://daystorm.netz.org a valid Mastodon server or do I have to block that too?
(DIR) Post #AWYLStlcKnZlptiO2q by blue1337blood@social.netz.org
2023-05-03T18:39:48Z
0 likes, 0 repeats
@utzer @mephisto it's only for research purpose, so you can block it