Entries Tagged "web"

Page 4 of 14

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 AM • View 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 PM • View Comments

Domain-in-the-Middle Attacks

It’s an easy attack. Register a domain that’s like your target except for a typo. So it would be countrpane.com instead of counterpane.com, or mailcounterpane.com instead of mail.counterpane.com. Then, when someone mistypes an e-mail address to someone at that company and you receive it, just forward it on as if nothing happened.

These are called “doppelganger domains.”

To test the vulnerability, the researchers set up 30 doppelganger accounts for various firms and found that the accounts attracted 120,000 e-mails in the six-month testing period.

The e-mails they collected included one that listed the full configuration details for the external Cisco routers of a large IT consulting firm, along with passwords for accessing the devices. Another e-mail going to a company outside the U.S. that manages motorway toll systems provided information for obtaining full VPN access into the system that supports the road tollways. The e-mail included information about the VPN software, usernames, and passwords.

They’re already being used to spy on companies:

Some of the companies whose doppelganger domains have already been taken by entities in China included Cisco, Dell, HP, IBM, Intel, Yahoo and Manpower. For example, someone whose registration data suggests he’s in China registered kscisco.com, a doppelganger for ks.cisco.com. Another user who appeared to be in China registered nayahoo.com ­ a variant of the legitimate na.yahoo.com (a subdomain for Yahoo in Namibia).

Kim said that out of the 30 doppelganger domains they set up, only one company noticed when they registered the domain and came after them threatening a lawsuit unless they released ownership of it, which they did.

He also said that out of the 120,000 e-mails that people had mistakenly sent to their doppelganger domains, only two senders indicated they were aware of the mistake. One of the senders sent a follow-up e-mail with a question mark in it, perhaps to see if it would bounce back. The other user sent out an e-mail query to the same address with a question asking where the e-mail had landed.

Defenses are few:

Companies can mitigate the issue by buying up any doppelganger domains that are still available for their company. But in the case of domains that may already have been purchased by outsiders, Kim recommends that companies configure their networks to block DNS and internal e-mails sent by employees that might get incorrectly addressed to the doppelganger domains. This won’t prevent someone from intercepting e-mail that outsiders send to the doppelganger domains, but at least it will cut down on the amount of e-mail the intruders might grab.

I suppose you can buy up the most common typos, but there will always be ones you didn’t think about—especially if you use a lot of subdomains.

Posted on September 16, 2011 at 5:22 AM • View Comments

Search Redirection and the Illicit Online Prescription Drug Trade

Really interesting research.

Search-redirection attacks combine several well-worn tactics from black-hat SEO and web security. First, an attacker identifies high-visibility websites (e.g., at universities) that are vulnerable to code-injection attacks. The attacker injects code onto the server that intercepts all incoming HTTP requests to the compromised page and responds differently based on the type of request:
Requests from search-engine crawlers return a mix of the original content, along with links to websites promoted by the attacker and text that makes the website appealing to drug-related queries.

  • Requests from users arriving from search engines are checked for drug terms in the original search query. If a drug name is found in the search term, then the compromised server redirects the user to a pharmacy or another intermediary, which then redirects the user to a pharmacy.
  • All other requests, including typing the link directly into a browser, return the infected website’s original content.
  • The net effect is that web users are seamlessly delivered to illicit pharmacies via infected web servers, and the compromise is kept hidden from view of the affected host’s webmaster in nearly all circumstances.

Upon inspecting search results, we identified 7,000 websites that had been compromised in this manner between April 2010 and February 2011. One quarter of the top ten search results were observed to actively redirect to pharmacies, and another 15% of the top results were for sites that no longer redirected but had previously been compromised. We also found that legitimate health resources, including authorized pharmacies, were largely crowded out of the top results by search-redirection attacks and blog and forum spam promoting fake pharmacies.

And the paper.

Posted on August 16, 2011 at 10:47 AM • View Comments

New, Undeletable, Web Cookie

A couple of weeks ago Wired reported the discovery of a new, undeletable, web cookie:

Researchers at U.C. Berkeley have discovered that some of the net’s most popular sites are using a tracking service that can’t be evaded—even when users block cookies, turn off storage in Flash, or use browsers’ “incognito” functions.

The Wired article was very short on specifics, so I waited until one of the researchers—Ashkan Soltani—wrote up more details. He finally did, in a quite technical essay:

What differentiates KISSmetrics apart from Hulu with regards to respawning is, in addition to Flash and HTML5 LocalStorage, KISSmetrics was exploiting the browser cache to store persistent identifiers via stored Javascript and ETags. ETags are tokens presented by a user’s browser to a remote webserver in order to determine whether a given resource (such as an image) has changed since the last time it was fetched. Rather than simply using it for version control, we found KISSmetrics returning ETag values that reliably matched the unique values in their ‘km_ai’ user cookies.

Posted on August 15, 2011 at 4:48 AM • View Comments

New Bank-Fraud Trojan

Nasty:

The German Federal Criminal Police (the “Bundeskriminalamt” or BKA for short) recently warned consumers about a new Windows malware strain that waits until the victim logs in to his bank account. The malware then presents the customer with a message stating that a credit has been made to his account by mistake, and that the account has been frozen until the errant payment is transferred back.

When the unwitting user views his account balance, the malware modifies the amounts displayed in his browser; it appears that he has recently received a large transfer into his account. The victim is told to immediately make a transfer to return the funds and unlock his account. The malicious software presents an already filled-in online transfer form ­ with the account and routing numbers for a bank account the attacker controls.

Posted on August 8, 2011 at 12:47 PM • View Comments

ShareMeNot

ShareMeNot is a Firefox add-on for preventing tracking from third-party buttons (like the Facebook “Like” button or the Google “+1” button) until the user actually chooses to interact with them. That is, ShareMeNot doesn’t disable/remove these buttons completely. Rather, it allows them to render on the page, but prevents the cookies from being sent until the user actually clicks on them, at which point ShareMeNot releases the cookies and the user gets the desired behavior (i.e., they can Like or +1 the page).

Posted on July 28, 2011 at 2:02 PM • View Comments

Google Detects Malware in its Search Data

This is interesting:

As we work to protect our users and their information, we sometimes discover unusual patterns of activity. Recently, we found some unusual search traffic while performing routine maintenance on one of our data centers. After collaborating with security engineers at several companies that were sending this modified traffic, we determined that the computers exhibiting this behavior were infected with a particular strain of malicious software, or “malware.” As a result of this discovery, today some people will see a prominent notification at the top of their Google web search results….

There’s a lot that Google sees as a result of it’s unique and prominent position in the Internet. Some of it is going to be stuff they never considered. And while they use a lot of it to make money, it’s good of them to give this one back to the Internet users.

Posted on July 20, 2011 at 6:23 AM • View Comments

Telex Anti-Censorship System

This is really clever:

Many anticensorship systems work by making an encrypted connection (called a “tunnel”) from the user’s computer to a trusted proxy server located outside the censor’s network. This server relays requests to censored websites and returns the responses to the user over the encrypted tunnel. This approach leads to a cat-and-mouse game, where the censor attempts to discover and block the proxy servers. Users need to learn the address and login information for a proxy server somehow, and it’s very difficult to broadcast this information to a large number of users without the censor also learning it.

Telex turns this approach on its head to create what is essentially a proxy server without an IP address. In fact, users don’t need to know any secrets to connect. The user installs a Telex client app (perhaps by downloading it from an intermittently available website or by making a copy from a friend). When the user wants to visit a blacklisted site, the client establishes an encrypted HTTPS connection to a non-blacklisted web server outside the censor’s network, which could be a normal site that the user regularly visits. Since the connection looks normal, the censor allows it, but this connection is only a decoy.

The client secretly marks the connection as a Telex request by inserting a cryptographic tag into the headers. We construct this tag using a mechanism called public-key steganography. This means anyone can tag a connection using only publicly available information, but only the Telex service (using a private key) can recognize that a connection has been tagged.

As the connection travels over the Internet en route to the non-blacklisted site, it passes through routers at various ISPs in the core of the network. We envision that some of these ISPs would deploy equipment we call Telex stations. These devices hold a private key that lets them recognize tagged connections from Telex clients and decrypt these HTTPS connections. The stations then divert the connections to anti­censorship services, such as proxy servers or Tor entry points, which clients can use to access blocked sites. This creates an encrypted tunnel between the Telex user and Telex station at the ISP, redirecting connections to any site on the Internet.

EDITED TO ADD (8/1): Another article.

EDITED TO ADD (8/13): Another article.

Posted on July 19, 2011 at 9:59 AM • View Comments

1 2 3 4 5 6 … 14

Sidebar photo of Bruce Schneier by Joe MacInnis.