Show newer

> Why wait around begging the political machine to do your thuggery for you? If you're going to advocate widespread violent aggression against peaceful people, then don't be a coward or a hypocrite--skip the middle man and do it yourself!

youtube.com/watch?v=PKmiOz98Iw

hey friends,

on may 19, 2023 an unknown user registered the domain name fedirelay.xyz and setup a fake mostr (nostr) relay to listen for requests on the fediverse.

on may 20, 2023 at 20:52 (utc) a user uploaded the attached document to poast. it was originally an obfuscated javascript file (unobfuscated and attached it here, renamed to .txt so you can view it in any editor).

what this javascript file does is take the viewers oauth token, encode it to make it look like a nostr pubkey and then forced the clandestine mostr relay to look up that user locally giving that server the encoded token all while appearing to be a legitimate mostr (nostr) bridge

i have taken steps to completely limit access to the admin api and corrected any CSP or other issues that could possibly have contributed to this, however most of you are still vulnerable to it. the default pleroma install serves media files on your root domain as a local folder (i.e. yourdomain.xyz/media) and the default CSP for any site is to allow executing scripts via the root domain. in order to prevent this you should take steps to either move your media from yourdomain.xyz/media to media.yourdomain.xyz (or any subdomain outside of your root domain) or perhaps by limiting the CSP for that subdirectory via nginx configuration.

if you are an instance owner, the obfuscated file hash is `b2977f2d97f598d2ebd6dcf37afd9047b5da2b6dc95a7b2824fb111c906fb117` so you can search yourdomain.xyz/media/b2977f2d97f598d2ebd6dcf37afd9047b5da2b6dc95a7b2824fb111c906fb117.js and see if you have it on your server.

sorry to anybody i let down but i could never have foreseen this level of sophistication and i would not have ever expected it. now that we are aware of it, we will be more diligent in the future. thanks for being here with us still friends
@graf sorry you had to experience first before we found it, at least it should be fixed in the future.
Alright, we found a second exploit that is much worse than the first one I found, it involves a bug in our oembed parser. A new release is being prepared right now. Unless there's a third exploit, this can be mitigated by disabling rich media in the pleroma settings. Frontends other than pleroma-fe might also be not vulnerable.

What alex is recommending here will also fix the issue, so you can do that as well:

https://gleasonator.com/notice/AW3PsTi4WCWEUbN0uO

Pleroma / Akkoma / Rebased need to be patched, but here’s how you can secure your site without any code changes:

yoursite.com/media -> media.yoursite.com yoursite.com/proxy -> proxy.yoursite.com

To do this, add the following configuration to your site:

config :pleroma, Pleroma.Upload, base_url: "https://media.yoursite.com" config :pleroma, :media_proxy, base_url: "https://proxy.yoursite.com"

You will need to add DNS records for the subdomains. For media, it’s recommended to use an S3 bucket (or equivalent). For the proxy, you can simply point the DNS to the same server, and edit your Nginx file. A sample Nginx file is here: https://termbin.com/tj7q You’re on your own setting up letsencrypt, etc.

Here’s what does NOT work:

A CSP one-liner in Nginx. That’s not how CSP works. CSP affects the page it was loaded on, not other resources. This is straight up misinformation.
Disabling the media proxy on its own. The media proxy does appear to be vulnerable, but it cannot be the only action you take.

So my current evaluation of this is:

1. There's a bug in pleroma oembed parsing that allows html injection, this is probably the one used for the attack on poast. You need to have rich media (i.e. website previews) enable for that to be dangerous.

2. There's a second exploit that I found first, having to with the CSP settings for /proxy. The nginx snippet i posted fixes that, but it doesn't fix the first issue.

The used exploit might have been a different one altogether, but at least these two can absolutely be used to steal your oauth tokens.

So what you should do in my opinion is to deactivate rich media and add the nginx snippet i posted. If you can, you should also implement alex's suggestion of moving media and proxy to subdomains (see here: https://gleasonator.com/notice/AW3PsTi4WCWEUbN0uO), as this will fix these two issues plus potential additional ones that we don't know of yet.

you should also delete ALL oauth tokens, at least if you have used rich media or media proxy. you can do this by entering `delete from oauth_tokens` in psql.

@skells i never really thanked you for hitting me in the mouth! really perfect timing back then to save my sanity :blobcatheart:

@3T@annihilation.social
Elon said is guarantee of nothing.
Also non-free (as in freedom) cybernetics are torture.

location /api/pleroma/admin { return 403; }
location /api/v1/pleroma/admin { return 403; }

I bought two new guns today. The first one is a judge (pictures here with my target practice). The other gun is an Hk 9mm, picture and target i follow up thread.

Show older
CleverLibre Social

CleverLibre Social is an inclusive social instance for open discussion, learning, and community.
All cultures welcome.
Hate speech and harassment strictly forbidden.