41–50 of 364 posts
I'm still not entirely convinced this wasn't an inside job (or entirely made up) and they just put a nice pot of money away somewhere. Wouldn't be without precedent in the wonderful world of crypto...
Earlier quoted context omitted.
You can easily embed arbitrary javascript into any PDF, and you can obfuscate it pretty well enough to get past most endpoint security tools on the market.
That JS would be sandboxed similar to in browsers, so you'd still need an exploit to break out of that.
The going price for Adobe PDF RCE zero-days is $80,000
How is Proof of Authority, mentioned in the article, any different than normal social trust and reputational risk associated with that? This seems like a cute way of wrapping up the status quo in crypto lingo.
Did he get the job? because i guess he was fired from the previous one.
Can someone explain to me how a pdf can execute code?
The Adobe tools in particular have been a bountiful source of exploits for decades, but it's a complicated spec and there are plenty of opportunities for bugs.
They say that a worker downloading (and presumably viewing) a PDF (fake job offer) allowed spyware in. Which PDF viewer was exploited?
You can easily embed arbitrary javascript into any PDF, and you can obfuscate it pretty well enough to get past most endpoint security tools on the market.
Curious if anyone has been able to find technical details of how this attack works/worked. I'm under the impression most PDF viewers would prevent this sort of attack (e.g. opening a PDF in your browser should sandbox it to the browsing context), but really keen to know what PDF viewer / OS was used by the dev.
Here's a demonstration of some example attacks using pdf: executing arbitrary js, and connecting to a samba server: https://www.sentinelone.com/blog/malicious-pdfs-revealing-te... I'm not sure about this attack specifically, though, and in Ronin's post mortem they aren't really talking about that: https://roninblockchain.substack.com/p/back-to-building-roni... . To some extent, the PDF viewer/OS doesn't matter. A ded…
I know I'm pushing a boulder uphill with that one but it really is the way to go, better for both the individual and the company.
Curious if anyone has been able to find technical details of how this attack works/worked. I'm under the impression most PDF viewers would prevent this sort of attack (e.g. opening a PDF in your browser should sandbox it to the browsing context), but really keen to know what PDF viewer / OS was used by the dev.
Here's a demonstration of some example attacks using pdf: executing arbitrary js, and connecting to a samba server: https://www.sentinelone.com/blog/malicious-pdfs-revealing-te... I'm not sure about this attack specifically, though, and in Ronin's post mortem they aren't really talking about that: https://roninblockchain.substack.com/p/back-to-building-roni... . To some extent, the PDF viewer/OS doesn't matter. A ded…
I dispute this: the web browser is one of the most defended pieces of software of all time, especially relative to its complexity. I would find it much safer to open a potentially malicious PDF in my browser's JS-based reader than using a desktop reader.
> The "right" move here would have been for the employee not to download the compromised pdf, and short of that, for the IT Security team at Ronin to quickly detect the weird traffic that resulted and isolate the validators to prevent a compromise of their critical assets.
It also probably would have been helpful if one employee didn't have access to almost half of the validators, especially on a system they're accessing email with.