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

181–190 of 241 posts

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

#181

Post by troad »

kepano wrote: post #180
troad wrote: post #177

Earlier quoted context omitted.

> multiple safety warnings in Obsidian Idk, I've always thought it was odd that the "community plugins" settings pane seemed more concerned with assuring the user that community plugins were fine than actually explaining the risk. There is literally a single sentence about the fact that plugins "may cause data integrity and security issues", and it is hedged with the mealy-mouthed modifier "like any other software yo…

To replicate this attack you have to also reject two more safety warnings. The user has to accept a shared vault (you have to click "trust author of this vault"), and you have to activate syncing remote plugins.

The first safety warning assures the user that "plugin security is important to [Obsidian]". That Obsidian plugins undergo initial code review by Obsidian themselves. That "many" plugins are open source and that Obsidian has a "large community of developers who watch out for each other". (At this point I'm not sure how this screen even qualifies as a safety warning. Seems more like a billboard for enabling plugins?)

Given that vaults are just Markdown documents, and plugins are so safe (or so Obsidian seems to claim), why should a person feel at all concerned clicking yes to these prompts? Is it still a social engineering attack when the app appears to encourage you along the way? Are these even safety warnings, or just (vaguely encouraging) confirmation dialogs?

I don't see how Obsidian should come off as completely blameless here. They've always tacitly encouraged this wild west plugin ecosystem, because it's an obvious generator of value. They don't get to absolve themselves of any responsibility by pointing at safety warnings, when those "safety warnings" spend (far!) more time explaining why the user might want to click "yes" than "no".

To be clear, I like and use (and pay for!) Obsidian. But the design of Obsidian plugins was clearly broken from the beginning, and the official messaging around them has always been more encouraging than wary. This sort of event is an absolutely inevitable consequence of those decisions.

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

#182

Post by soco »

jedimastert wrote: post #144
exceptione wrote: post #120

A long time ago I figured that "nasty Obsidian plugins" were not a matter of if, but when . So I did the (imho) only sensible thing, and run Obsidian in a sandbox (bwrap). By doing so, I also made sure it runs in a separate networking namespace. For now, I disallow any internet access. The amount of rage I see here is a bit strange, the whole attraction of Obsidian is that you can turn it into a Swiss army knife (tha…

> So I did the (imho) only sensible thing, and run Obsidian in a sandbox (bwrap). By doing so, I also made sure it runs in a separate networking namespace. For now, I disallow any internet access. > The amount of rage I see here is a bit strange Serious question: do you think it is actually obvious and technically accessable to everyday people to have the thought "I should run this in a sandbox" and do it? Like no th…

I haven't seen the term haxx0r since... ages! How are they called nowadays?

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

#183

Post by SamBam »

silon42 wrote: post #126
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.

For real security, operation should only be allowed after 24h of cooldown.

User should be required to explain the situation to an older and a younger family member, and get permission from both of them.

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

#185

Post by jpk2f2 »

kid64 wrote: post #9
pointlessone wrote: post #7

Earlier quoted context omitted.

It does give full access but Obsidian does tell you that. Community plugins are not enabled by default, you have to enable them manually. Same happens with a shared vault: once you get it you still have to manually enable plugins. So far no one managed to sneak in a plugin completely unnoticed.

That's horse hockey. Obsidian is not a usable system without community plugins. Folks will reply "but I use it every day without plugins". That position disregards software usability as a formal discipline, along with decades of UX research and standards.

Using it daily without plugins is, by definition, a "usable system".

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

#186

Post by sneilan1 »

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…

I've been using obsidian for years as a paying customer. Will continue to pay as price point is good and it just works. However, unless plugin security massively improves I will never install any plugins.

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

#188

Post by ImPostingOnHN »

Groxx wrote: post #62
ImPostingOnHN wrote: post #59

Earlier quoted context omitted.

> That covers probably literally a majority of all software on your computer If you're running GNU/Linux, chances are you'll have hundreds, if not thousands, of pieces of software that run totally unsandboxed. Yes, a very small minority of applications are unfortunately primarily distributed via flatpak or snap, and the distributors don't care about the user experience, so it's error-ridden and problem-ridden, but ch…

And tons won't be part of e.g. root, or dialout (to pick one I've had to deal with a lot lately), or many other more-privileged-than-default groups, yes. That's a permissions system working as intended. Besides. They said "all software on your machine". That is trivially false, to a significant degree.

I was pointing out that the claim that "literally a majority of all software on your computer" runs sandboxed is also trivially false, to a significant degree

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

#189

Post by kepano »

troad wrote: post #181
kepano wrote: post #180

Earlier quoted context omitted.

To replicate this attack you have to also reject two more safety warnings. The user has to accept a shared vault (you have to click "trust author of this vault"), and you have to activate syncing remote plugins.

The first safety warning assures the user that "plugin security is important to [Obsidian]". That Obsidian plugins undergo initial code review by Obsidian themselves. That "many" plugins are open source and that Obsidian has a "large community of developers who watch out for each other". (At this point I'm not sure how this screen even qualifies as a safety warning. Seems more like a billboard for enabling plugins?)…

You're looking at a different screen than the ones required to replicate this attack. To replicate this attack you have to agree three separate times to increasingly scary messages.

Yes it would be good to make it less easy to shoot yourself in the foot. However, I believe users should be in control. People should be able to do powerful things if they choose to. But that will always come with the risk of misuse or social engineering.

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

#190

Post by kepano »

sneilan1 wrote: post #186
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…

I've been using obsidian for years as a paying customer. Will continue to pay as price point is good and it just works. However, unless plugin security massively improves I will never install any plugins.

Obsidian is only seven people but we are working on this from all three angles:

1. Make community plugins less necessary over time as basic features become part of core

2. Improve the security of community plugins

3. Make it easy to create your own plugins that you can fully trust, e.g. with the recent release of Obsidian CLI

Post reply on HN