Entries Tagged "browsers"

Page 2 of 7

Adware Vendors Buy and Abuse Chrome Extensions

This is not a good development:

To make matters worse, ownership of a Chrome extension can be transferred to another party, and users are never informed when an ownership change happens. Malware and adware vendors have caught wind of this and have started showing up at the doors of extension authors, looking to buy their extensions. Once the deal is done and the ownership of the extension is transferred, the new owners can issue an ad-filled update over Chrome’s update service, which sends the adware out to every user of that extension.

[…]

When malicious apps don’t follow Google’s disclosure policy, diagnosing something like this is extremely difficult. When Tweet This Page started spewing ads and malware into my browser, the only initial sign was that ads on the Internet had suddenly become much more intrusive, and many auto-played sound. The extension only started injecting ads a few days after it was installed in an attempt to make it more difficult to detect. After a while, Google search became useless, because every link would redirect to some other webpage. My initial thought was to take an inventory of every program I had installed recently — I never suspected an update would bring in malware. I ran a ton of malware/virus scanners, and they all found nothing. I was only clued into the fact that Chrome was the culprit because the same thing started happening on my Chromebook — if I didn’t notice that, the next step would have probably been a full wipe of my computer.

Posted on January 21, 2014 at 6:33 AMView Comments

The Onion on Browser Security

Wise advice:

At Chase Bank, we recognize the value of online banking­ — it’s quick, convenient, and available any time you need it. Unfortunately, though, the threats posed by malware and identity theft are very real and all too common nowadays. That’s why, when you’re finished with your online banking session, we recommend three simple steps to protect your personal information: log out of your account, close your web browser, and then charter a seafaring vessel to take you 30 miles out into the open ocean and throw your computer overboard.

And while we’re talking about the Onion, they were recently hacked by Syria (either the government or someone on their side). They responded in their own way.

EDITED TO ADD (5/11): How The Onion got hacked.

Posted on May 10, 2013 at 1:49 PMView Comments

Man-in-the-Middle Attacks Against Browser Encryption

Last week, a story broke about how Nokia mounts man-in-the-middle attacks against secure browser sessions.

The Finnish phone giant has since admitted that it decrypts secure data that passes through HTTPS connections — including social networking accounts, online banking, email and other secure sessions — in order to compress the data and speed up the loading of Web pages.

The basic problem is that https sessions are opaque as they travel through the network. That’s the point — it’s more secure — but it also means that the network can’t do anything about them. They can’t be compressed, cached, or otherwise optimized. They can’t be rendered remotely. They can’t be inspected for security vulnerabilities. All the network can do is transmit the data back and forth.

But in our cloud-centric world, it makes more and more sense to process web data in the cloud. Nokia isn’t alone here. Opera’s mobile browser performs all sorts of optimizations on web pages before they are sent over the air to your smart phone. Amazon does the same thing with browsing on the Kindle. MobileScope, a really good smart-phone security application, performs the same sort of man-in-the-middle attack against https sessions to detect and prevent data leakage. I think Umbrella does as well. Nokia’s mistake was that they did it without telling anyone. With appropriate consent, it’s perfectly reasonable for most people and organizations to give both performance and security companies that ability to decrypt and re-encrypt https sessions — at least most of the time.

This is an area where security concerns are butting up against other issues. Nokia’s answer, which is basically “trust us, we’re not looking at your data,” is going to increasingly be the norm.

Posted on January 17, 2013 at 9:50 AMView Comments

Insecure Chrome Extensions

An analysis of extensions to the Chrome browser shows that 25% of them are insecure:

We reviewed 100 Chrome extensions and found that 27 of the 100 extensions leak all of their privileges to a web or WiFi attacker. Bugs in extensions put users at risk by leaking private information (like passwords and history) to web and WiFi attackers. Web sites may be evil or contain malicious content from users or advertisers. Attackers on public WiFi networks (like in coffee shops and airports) can change all HTTP content.

Posted on September 29, 2011 at 7:07 AMView Comments

Man-in-the-Middle Attack Against SSL 3.0/TLS 1.0

It’s the Browser Exploit Against SSL/TLS Tool, or BEAST:

The tool is based on a blockwise-adaptive chosen-plaintext attack, a man-in-the-middle approach that injects segments of plain text sent by the target’s browser into the encrypted request stream to determine the shared key. The code can be injected into the user’s browser through JavaScript associated with a malicious advertisement distributed through a Web ad service or an IFRAME in a linkjacked site, ad, or other scripted elements on a webpage.

Using the known text blocks, BEAST can then use information collected to decrypt the target’s AES-encrypted requests, including encrypted cookies, and then hijack the no-longer secure connection. That decryption happens slowly, however; BEAST currently needs sessions of at least a half-hour to break cookies using keys over 1,000 characters long.

The attack, according to Duong, is capable of intercepting sessions with PayPal and other services that still use TLS 1.0­which would be most secure sites, since follow-on versions of TLS aren’t yet supported in most browsers or Web server implementations.

While Rizzo and Duong believe BEAST is the first attack against SSL 3.0 that decrypts HTTPS requests, the vulnerability that BEAST exploits is well-known; BT chief security technology officer Bruce Schneier and UC Berkeley’s David Wagner pointed out in a 1999 analysis of SSL 3.0 that “SSL will provide a lot of known plain-text to the eavesdropper, but there seems to be no better alternative.” And TLS’s vulnerability to man-in-the middle attacks was made public in 2009. The IETF’s TLS Working Group published a fix for the problem, but the fix is unsupported by SSL.

Another article.

EDITED TO ADD: Good analysis.

Posted on September 23, 2011 at 1:37 PMView Comments

Sidebar photo of Bruce Schneier by Joe MacInnis.