Page 2 of 14
Click on the “Establishing secure connection” link at the top of this page. It’s a Wells Fargo page that displays a progress bar with a bunch of security phrases—”Establishing Secure Connection,” “Sending credentials,” “Building Secure Environment,” and so on—and closes after a few seconds. It’s complete security theater; it doesn’t actually do anything but make account holders feel better.
Ever since the launch of Kim Dotcom’s file-sharing service, I have been asked about the unorthodox encryption and security system.
I have not reviewed it, and don’t have an opinion. All I know is what I read: this, this, this, this, and this.
Please add other links in the comments.
EDITED TO ADD (1/24): Also this.
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.
There’s a rise in QR codes that point to fraudulent sites. One of the warning signs seems to be a sticker with the code, rather than a code embedded in an advertising poster.
This brings up another question: does anyone actually use these things?
This sort of attack will become more common as banks require two-factor authentication:
Tatanga checks the user account details including the number of accounts, supported currency, balance/limit details. It then chooses the account from which it could steal the highest amount.
Next, it initiates a transfer.
At this point Tatanga uses a Web Inject to trick the user into believing that the bank is performing a chipTAN test. The fake instructions request that the user generate a TAN for the purpose of this “test” and enter the TAN.
Note that the attack relies on tricking the user, which isn’t very hard.
Good post, not because it picks on Tesco but because it’s filled with good advice on how not to do it wrong.
I’m late writing about this one. Cryptocat is a web-based encrypted chat application. After Wired published a pretty fluffy profile on the program and its author, security researcher Chris Soghoian wrote an essay criticizing the unskeptical coverage. Ryan Singel, the editor (not the writer) of the Wired piece, responded by defending the original article and attacking Soghoian.
At this point, I would have considered writing a long essay explaining what’s wrong with the whole concept behind Cryptocat, and echoing my complaints about the dangers of uncritically accepting the security claims of people and companies that write security software, but Patrick Ball did a great job:
CryptoCat is one of a whole class of applications that rely on what’s called “host-based security”. The most famous tool in this group is Hushmail, an encrypted e-mail service that takes the same approach. Unfortunately, these tools are subject to a well-known attack. I’ll detail it below, but the short version is if you use one of these applications, your security depends entirely the security of the host. This means that in practice, CryptoCat is no more secure than Yahoo chat, and Hushmail is no more secure than Gmail. More generally, your security in a host-based encryption system is no better than having no crypto at all.
Sometimes it’s nice to come in late.
EDITED TO ADD (8/14): As a result of this, CryptoCat is moving to a browser plug-in model.
Interesting discussion of trust in this article on web hoaxes.
Kelly’s students, like all good con artists, built their stories out of small, compelling details to give them a veneer of veracity. Ultimately, though, they aimed to succeed less by assembling convincing stories than by exploiting the trust of their marks, inducing them to lower their guard. Most of us assess arguments, at least initially, by assessing those who make them. Kelly’s students built blogs with strong first-person voices, and hit back hard at skeptics. Those inclined to doubt the stories were forced to doubt their authors. They inserted articles into Wikipedia, trading on the credibility of that site. And they aimed at very specific communities: the “beer lovers of Baltimore” and Reddit.
That was where things went awry. If the beer lovers of Baltimore form a cohesive community, the class failed to reach it. And although most communities treat their members with gentle regard, Reddit prides itself on winnowing the wheat from the chaff. It relies on the collective judgment of its members, who click on arrows next to contributions, elevating insightful or interesting content, and demoting less worthy contributions. Even Mills says he was impressed by the way in which redditors “marshaled their collective bits of expert knowledge to arrive at a conclusion that was largely correct.” It’s tough to con Reddit.
[…]
If there’s a simple lesson in all of this, it’s that hoaxes tend to thrive in communities which exhibit high levels of trust. But on the Internet, where identities are malleable and uncertain, we all might be well advised to err on the side of skepticism.
Details are in the article, but here’s the general idea:
Let’s follow the flow of the users:
- Scammer buys user traffic from PornoXo.com and sends it to HQTubeVideos.
- HQTubeVideos loads, in invisible iframes, some parked domains with innocent-sounding names (relaxhealth.com, etc).
- In the parked domains, ad networks serve display and PPC ads.
- The click-fraud sites click on the ads that appear within the parked domains.
- The legitimate publishers gets invisible/fraudulent traffic through the (fraudulently) clicked ads from parked domains.
- Brand advertisers place their ad on the websites of the legitimate publishers, which in reality appear within the (invisible) iframe of HQTubeVideos.
- AdSafe detects the attempted placement within the porn website, and prevents the ads of the brand publisher from appearing in the legitimate website, which is hosted within the invisible frame of the porn site.
Notice how nicely orchestrated is the whole scheme: The parked domains “launder” the porn traffic. The ad networks place the ads in some legitimately-sounding parked domains, not in a porn site. The publishers get traffic from innocent domains such as RelaxHealth, not from porn sites. The porn site loads a variety of publishers, distributing the fraud across many publishers and many advertisers.
The most clever part of this is that it makes use of the natural externalities of the Internet.
And now let’s see who has the incentives to fight this. It is fraud, right? But I think it is well-executed type of fraud. It targets and defrauds the player that has the least incentives to fight the scam.
Who is affected? Let’s follow the money:
- The big brand advertisers (Continental, Coca Cola, Verizon, Vonage,…) pay the publishers and the ad networks for running their campaigns.
- The publishers pay the ad network and the scammer for the fraudulent clicks.
- The scammer pays PornoXo and TrafficHolder for the traffic.
The ad networks see clicks on their ads, they get paid, so not much to worry about. They would worry if their advertisers were not happy. But here we have a piece of genius:
The scammer did not target sites that would measure conversions or cost-per-acquisition. Instead, the scammer was targeting mainly sites that sell pay-per-impression ads and video ads. If the publishers display CPM ads paid by impression, any traffic is good, all impressions count. It is not an accident that the scammer targets publishers with video content, and plenty of pay-per-impression video ads. The publishers have no reason to worry if they get traffic and the cost-per-visit is low.
Effectively, the only one hurt in this chain are the big brand advertisers, who feed the rest of the advertising chain.
Do the big brands care about this type of fraud? Yes and no, but not really deeply. Yes, they pay for some “invisible impressions”. But this is a marketing campaign. In any case, not all marketing attempts are successful. Do all readers of Economist look at the printed ads? Hardly. Do all web users pay attention to the banner ads? I do not think so. Invisible ads are just one of the things that make advertising a little bit more expensive and harder. Consider it part of the cost of doing business. In any case, compared to the overall marketing budget of these behemoths, the cost of such fraud is peanuts.
The big brands do not want their brand to be hurt. If the ads do not appear in places inappropriate for the brand, things are fine. Fighting the fraud publicly? This will just associate the brand with fraud. No marketing department wants that.
Here’s something good:
We have implemented sophisticated brute force protection for Linode Manager user accounts that combines a time delay on failed attempts, forced single threading of log in attempts from a given remote address, and automatic tarpitting of requests from attackers.
And this:
Some of you may have noticed a few changes to the Linode Manger over the past few weeks, most notably that accessing your “My Profile” and the “Account -> Users & Permissions” subtab now require password re-authentication.
The re-authentication is meant to protect your contact settings, password changes, and other preferences. The re-auth lasts for about 10 minutes, after which you’ll be asked to provide your password again on those sections of the Linode Manager.
It’s nice to see some companies implementing these sorts of security measures.
Sidebar photo of Bruce Schneier by Joe MacInnis.