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

Our Copyfish extension was stolen and adware-infested

a9t9.com

Post reply on HN
Print view View original

111–120 of 217 posts

Re: Our Copyfish extension was stolen and adware-infested

#111

Post by twhb »

jeswin wrote: post #88

Chrome's security policy is surprisingly poor and is the reason why I stay away from most extensions. "Read data from all websites" is like root on the phone. It should be allowed only via deliberate, explicit user action. While this will be an interesting UX challenge, defaulting to domain-specific permissions is the sane thing to do in this age. Case in point, I don't care about a readability or bookmarking plugin…

I think more granular permissions, not domain-specific permissions, are the solution. Domain-specific permissions destroy the illusion that the extension is part of the browser, without restricting access as far as it should be.

For example, I made an extension that, upon a certain keyboard shortcut, saves the current page in a specific bookmarks folder. Currently Chrome's permissions model completely fails here, you need to request full access to all user data, everywhere, indefinitely.

Which would be better, (a) granting full indefinite access to the domain you're bookmarking most of the time you bookmark something, or (b) giving the extension permission only to see the current tab's URL and title, and to edit one specific bookmarks folder, and only during a keyboard shortcut's callback?

The granularity solution to your scenario would be to tie page-reading permissions to your triggering the extension, and have them removed with code execution end. So, now you don't need to worry about sensitive information that shows up on other domains, or your bank deciding to use a subdomain, or that one bank blog post that you actually do want it to see.

Re: Our Copyfish extension was stolen and adware-infested

#112

Post by krackers »

kyle-rb wrote: post #109
krackers wrote: post #108

Earlier quoted context omitted.

The odd post requests I noticed to uaswitcher.org in wireshark while I was trying to create a packet capture. I saw that it contained my browsing history urls in double encoded base64 format. Interestingly it appears the extension was infected ~4 years back, taken down, and somehow later re-added, only to be reinfested with malware within the last few months. Suffice to say, I am now paranoid and have audited all my…

> urls in double encoded base64 format I've seen that somewhere else; is it just for obfuscation? Or is there some other reason for it?

From what I've seen online a lot of these adware extensions do something similar. To me it doesn't make sense as an obfuscation method since anyone capable of capturing traces of network activity (or using chrome dev tools to do the equivalent) can probably recognize a base64 encoding and can just run the decoder a second time.

Maybe it might fool some automated analyzers though.

Re: Our Copyfish extension was stolen and adware-infested

#113

Post by microtonal »

giovannibajo1 wrote: post #4
sgroppino wrote: post #2

I'd have though that two-factor authentication could have prevented this type of attack?

Only with U2F, because the hardware dongle would refuse to provide the OTP to a different domain

For clarity: U2F does not use one-time passwords (OTP), but challenge-response authentication. This is why it provides better protection against phishing than hardware OTP tokens.

Re: Our Copyfish extension was stolen and adware-infested

#114

Post by Buge »

TeMPOraL wrote: post #100
Buge wrote: post #91

Earlier quoted context omitted.

SMS and TOTP (Google Authenticator) can both be phished. U2F cannot be phished.

Can't it? What if I control the user's computer and can let my own code interact with U2F? Or does the protocol somehow prevent that?

If you control the user's computer, that isn't phishing. That's keylogging/credential theft.

Re: Our Copyfish extension was stolen and adware-infested

#115

Post by jakobegger »

sillysaurus3 wrote: post #22
hartator wrote: post #18

Earlier quoted context omitted.

I don't think more policies will make a better place. One of the team member screw up and stuff like this happen. I am questioning his security education to have been phished so easily.

It's counter intuitive. I bet you $5 that if I target you, and you're not expecting it, I can phish you. I've seen this happen in the field, and it doesn't have much to do with education. Relax for an instant and I have you. The only real defense is to glance at the url bar every time you're about to enter your password. And even I find myself not doing that 100% of the time. It's a numbers game. A policy of popping…

I use iCloud keychain. Safari autofills passwords only if the URL matches. If the password doesn't autofill, I know something odd is going on. Makes it trivial to recognise phishing sites like the one from the linked blog post.

Re: Our Copyfish extension was stolen and adware-infested

#117

Post by logicallee »

Animats wrote: post #107
logicallee wrote: post #95

We should never have to read a title "disable immediately" by a developer. In a news article. That is not how this should be distributed, in case the original developer is the one distributing the news. Instead, Google should generate an emergency disable code that a developer can put into a simple web form from anywhere in the world, even if the developer has been locked out of every one of their accounts, which imm…

We should never have to read a title "disable immediately" by a developer. In a news article. If you want to change that, start contacting reporters from mainstream media. If this hits the New York Times or the Wall Street Journal, or at least Techdirt, Google might notice.

Google is staffed by geniuses who also read HN and I feel it is sufficient that I suggested one possible correct solution here on HN. I am sure they'll introduce some solution to this problems. (I mean some way for them to disable compromised extensions centrally.)

I am not personally an extension developer and don't run many.

Re: Our Copyfish extension was stolen and adware-infested

#118

Post by userbinator »

sillysaurus3 wrote: post #36
laurencei wrote: post #31

Earlier quoted context omitted.

> Every time you're about to paste your password, glance at the url bar. Actually - I disagree with this. You can no longer "glance" at the url bar to determine if you are on the right domain due to Unicode chars if you clicked a link. The only safe way is to type the url yourself into the browser. If it is a long link - then at least typing the base domain, and pasting the "rest" is probably safe?

This actually isn't true. A website like https://www.xn--80ak6aa92e.com/ won't show up as apple.com. Browsers don't allow Unicode rendering in the URL bar. Maybe IE is affected though. I haven't tested every browser. But it's a known security concern.

Disable IDN and you will be safe from those. If you're not going to use non-ASCII domain names, you won't miss much.

Re: Our Copyfish extension was stolen and adware-infested

#119

Post by [deleted] »

krackers wrote: post #103

I guess this is as good a place as any to post that I noticed something similar had happened to [User-Agent Switcher for Google Chrome]( https://chrome.google.com/webstore/detail/user-agent-switche... ) and [Block Site]( https://chrome.google.com/webstore/detail/block-site/eiimnmi... ). The "report abuse" link on the page is useless. The former is very insidious in that it actually hides the malware in a .jpg file th…

[deleted]

Re: Our Copyfish extension was stolen and adware-infested

#120

Post by Endy »

driverdan wrote: post #56
Endy wrote: post #37

While I understand how some people can take this as a cautionary tale in favor of 2FA, as someone who doesn't like it and won't use it, I guess my mindset is very simple. There's the old saw that over time, computing has evolved from smart people in front of dumb terminals into dumb people in front of "smart" terminals. This attack is proof of it; and while 2FA might have had an impact, the major issue here is that w…

> The lesson here is: never trust anyone or anything. Which is why you should use 2FA and why you shouldn't trust someone who says they don't use it.

I don't trust any of the 2FA providers. And I have neither the time nor the interest to try and learn to code it in binary.
Post reply on HN