Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Obsidian plugin was abused to deploy a remote access trojan

cyber.netsecops.io

Post reply on HN
Print view View original

191–200 of 241 posts

Re: Obsidian plugin was abused to deploy a remote access trojan

#191

Post by Daedren »

kevinmgranger wrote: post #157
Daedren wrote: post #93

Earlier quoted context omitted.

The pop-ups and "social engineering" in question are things that any users in HN likely already accepted, which is to enable community plugins. These community plugins are the backbone of Obsidian and where a lot of the meat is behind its fame come from. There's no protections beyond that, community plugins can do whatever they want. Thankfully, the vast majority of them are open-source.

I'm gonna push back against the "backbone of Obsidian" part. I'll argue that vanilla Obsidian is plenty powerful enough. I know many people swore / swear by the datatables plugin, but now that Bases in core, you can get pretty far without it, no?

I agree with you that vanilla Obsidian is plenty powerful, but it's exactly like Vim's case. It's good enough on its own, but there's always more.

There's countless articles and videos about various community plugins and even curated selections of them depending on your use case for Obsidian.

Re: Obsidian plugin was abused to deploy a remote access trojan

#192

Post by stevenkast »

hresvelgr wrote: post #23

Am I the only one who thinks Obsidian is perfect without plugins? Half the reason I switched to it from Anytype was that it was rather spartan in its offerings. If they announced tomorrow they would ban plugins, I would not care.

I found plugins more useful early on in Obsidian's lifespan. Now, its current native feature list is good enough for me.

Re: Obsidian plugin was abused to deploy a remote access trojan

#194

Post by zerkten »

embedding-shape wrote: post #147
jon-wood wrote: post #112

Earlier quoted context omitted.

On macOS at least those 99% of users are probably installing from the App Store, where apps are sandboxed by default and need to explicitly ask for access to paths outside that sandbox. Even when not installed from the App Store a permission dialogue is popped if an application tries to read from sensitive paths like your photo library.

Does that help in this case though? I think the worry is that a rogue Obsidian plugin does bad stuff with your Obsidian vault, not just do stuff to the rest of the computer. But that vault/those notes live in the same sandbox as the (rogue) 3rd party plugin, which doesn't help with that, they really need to be isolated away from the notes themselves.

Anything that reduces the blast radius helps. There should still be a focus on further hardening. Most value comes from exploits that enable pivots. Attackers will focus on other vectors that enable broader pivots because immediate high value notes only exist for a limited set of users.

Re: Obsidian plugin was abused to deploy a remote access trojan

#195

Post by kepano »

hackermanai wrote: post #72
kepano wrote: post #43

Obsidian CEO here. There is a major update coming soon for plugin security. I think it will address many of the concerns people have raised in this thread. It's a hard problem but we are working on it. That said, the headline is misleading. This article is about a social engineering attack that requires the user to actively reject multiple safety warnings in Obsidian. As far as I know this is a proof of concept, I ha…

> actively reject multiple safety warnings Is this like a popup? which most people actively accept without blinking I think plugin/extensions should be a bit harder to run by default. I get the user friction from extra hurdles before using their plugins etc., but I don't think there is an actually safe way to execute arbitrary code, unaudited, without sandboxing, or other restrictions.

It's not one pop-up. To fully replicate the concept you have to agree on three separate screens (and these are not in quick succession):

1. exit restricted mode to allow third-party plugins

2. trust the author of the vault that's being shared with you

3. trust the plugins being shared with you via sync

Re: Obsidian plugin was abused to deploy a remote access trojan

#196

Post by fooqux »

PurpleRamen wrote: post #148
ibash wrote: post #44

Earlier quoted context omitted.

lol we told you plugins were insecure years ago. I distinctly remember getting flamed in your discord because I said that they had full disk access. Too little too late.

The insecurity is part of the benefit. Obsidian being so open, allowing easy customizing is what makes it great. They should add some more bells, whistles and guards to prevent sneaky social attacks, but they can't close Obsidian all together, or it would kill the app.

There's open, and then there's "full disk access, even outside the vault" open.

Re: Obsidian plugin was abused to deploy a remote access trojan

#197

Post by ApolloFortyNine »

I don't know when Obsidian gathered the hate I'm seeing here, but 'bad plugins' is a failure mode of most everything that has plugins.

Personally it feels similar to being mad at Windows if you were to install an exe someone emailed you and it turned out to be a virus.

You can install bad chrome plugins, bad wow addons, basically anything that's purpose is to run user code can be used to run bad code.

Personally I'm glad the _note taking app_ prioritized allowing for custom plugins over pushing back features so they could spend an extra year locking down user plugins. They can put some additional effort in but running unknown code will always be a risk.

Re: Obsidian plugin was abused to deploy a remote access trojan

#198

Post by cachius »

mfro wrote: post #178
andersa wrote: post #121

Earlier quoted context omitted.

Sadly, Windows cannot do that. Every installed program has full disk access by default. It's very, very difficult to make it not so.

https://learn.microsoft.com/en-us/windows/security/applicati...

Windows Sandbox is not for persistent apps

Re: Obsidian plugin was abused to deploy a remote access trojan

#199

Post by Analemma_ »

_qib3 wrote: post #138

This is becoming a bit of an epidemic. Not every attack or exploit (and especially not a social engineering one) needs a name out of Metal Gear or a website.

When Heartbleed happened and they gave it a cool name and a fancy dedicated website, it was neat and probably necessary for that bug but I immediately had a sinking feeling that from then on every 2-bit security consultant trying to get free publicity would follow that playbook for nothingburger vulnerabilities, which is exactly what happened.

Re: Obsidian plugin was abused to deploy a remote access trojan

#200

Post by schaefer »

kepano wrote: post #43

Obsidian CEO here. There is a major update coming soon for plugin security. I think it will address many of the concerns people have raised in this thread. It's a hard problem but we are working on it. That said, the headline is misleading. This article is about a social engineering attack that requires the user to actively reject multiple safety warnings in Obsidian. As far as I know this is a proof of concept, I ha…

Obsidian stands beside the terminal and Firefox as one of the pieces of software I use the most every single day. Thank you for all you're doing.

-

I've read the article describing the attack, and my very first thought was utter surprise that the entire attack chain started with someone accepting a shared vault from a stranger via social media (linked in and similar). That seems really, really strange to me.

I've never shared a vault - but if I did, I'd probably do so as a git repo of markdown files.

It would be interesting to see a blog post from Obsidian about "good hygiene for sharing vaults".

Post reply on HN