here is the report prepared for law enforcement in regards to the happenings of may 20-23, 2023. we spent a lot of time meticulously gathering information over the weekend after I was certain everything was secure.
the attacker deactivated his account so in order to retrieve most of this I had to fetch and restore a backup of our database from the 23rd. reminder that if you run public services you should run multiple backups weekly and store them locally and off site in the event something like this happens.
im thankful for everyone involved from helping me track down the vulnerability, to those who are helping others patch it upstream and the entire community for coming together to resolve this for everyone in a timely manner
It seems to me that the embed injection could possibly still work (if it could inject inline code, it would run in the current window context and bypass the other safeguards)
(I am currently belt-suspenders-ducttape-scotchtape-superglue-elmersglue-… though, nobody with the real know-how has even acknowledged this configuration option)
I'm not worried about local users. Registration is by approval only, and I trust the guys here. That's why I was looking at the risk of remote injection.
Not sure if it’s cached at all, but from what I gather it’s a way the attacker can inject a script tag to execute some js, possibly inline, or definitely uploaded by a local user.
@Humpleupagus ours was uploaded locally but without using some kind of fix mitigating it, media proxy (remote media) is also vulnerable. if you don't run media proxy on your local domain (eveningzoo.club/proxy for example) you would have no issue. this particular exploit would have* worked because our CDN was in CSP
Does this exploit have to be uploaded from a local account? I note the section where you state the attacker created an account at poast and imply that the payload was uploaded locally.