Download me—Saying “yes” to the Web’s most dangerous search terms

by Conor Myhrvold - Jun 25, 2013 1:00 pm UTC

There’s a saying—"there’s no such thing as a free lunch." On the Web, however, it sure seems like there is. In the time span of a lunch break, a few keywords in a search engine promise free entertainment, just several clicks away. We all know the catch, though. These freebies can come with freeloading adware, malware, and other unwanted programs and plugins. This was particularly true in the Internet’s early days, but in the past decade, tech giants such as Google, Microsoft, and Yahoo—the three major players in search today—have deployed significant resources to prevent adware and malware from compromising their Web browsers, e-mail services, and websites. It can't be that bad in 2013, right?

Answering this question required a little experiment, one inspired by the documentary Super-Size Me. That film chronicles Morgan Spurlock’s month-long fast food “diet” during which he limited his exercise and knowledge about healthy eating, had to order everything on the McDonald’s menu at least once, and never said no to an upgrade offer.

Allie Brosh, Hyperbole and a Half

The Web version of this is simpler and better for an individual's (physical) health. From a clean computer fresh off an OS install, enter some of the most popular, plausible generic free keyword searches on a popular Web browser. Next, open all of the links in the search results (ads and otherwise) and download the first thing on the landing pages, recording where it went and what it did. Like Spurlock, I would limit my knowledge about what was safe or risky and take no (Internet) precautions beyond the default settings. The same rules applied for installing the program afterward. And in the Web's version of "would you like to super-size that?" I had to say yes to whatever was offered. There would be no avoiding a Web culture of excess and extras.

More programs included with the installation? MOAR! After each keyword search and installation was complete, I’d run several (free) popular antivirus programs to detect unwanted programs and record the installed programs, browser plugins, and extensions. That way it's easy to check later for Internet notoriety.

After a little research, I decided to search for free games, music, e-cards, a wallpaper, and a screensaver for my new computer. This appears to cover a spectrum of entertainment options available on the Web, but several ground rules guided me in selecting these items:

The content had to be plausibly free (“free” had to be the leading keyword) and legal (no purposefully targeting torrents, P2P).To replicate the high bounce rates common for Internet browsing, I exited if I needed to create an account or provide an e-mail or login. I also exited if there was no immediate download option from the landing page, although I was happy to click through several pages or redirections if it promised a free download (though it couldn’t be an unrelated third-party ad).The searched-for content had to be entertainment-oriented (no malware/spyware/antivirus searches), but it could not come from adult sites (online gambling, porn, webcams). In other words, the idea was to look for fun, free stuff—not trouble directly.

To no one's surprise, the keywords I selected were popular. However, they were also really, really dangerous. Each search qualified for the "Top 50 Most Riskiest Search Terms in the US" list from McAfee's 2008 roundup, The Web’s Most Dangerous Search Terms report. This experiment even included a pair of No. 1 ill-advised searches:

"free e-cards," listed in the McAfee Top 50, US

"free game cheats," “game cheats” qualifies as a McAfee Top 50

"free games," noted as popular generic search query

"free lyrics," “lyrics," and “song lyrics” were among the McAfee Top 50

"free music downloads," the No. 1 term for Average Risk, McAfee Top 50

"free screensaver," noted as a popular generic search query

"free wallpaper," “wallpaper” is a McAfee Top 50

"free word unscrambler," the No. 1 term for Maximum Risk, McAfee Top 50

In the McAfee report, "free" had the highest category risk. When you run software from an untrusted source, it exposes information about your operating system to the installer, such as your computer model, your IP address, your programs, and what browser you have. And if you are installing software from an adware kingpin, revealing this information is not good. Your information is directly on its way to the adware server.

A computer security expert I consulted beforehand pointed out a potential foil to my experiment. Since I would be installing many adware programs in a short time period—some likely from the same source through different adware networks controlled by the same entity—there was a chance my IP address would be flagged as a particularly gullible user. Other devices using that same IP address later could be vulnerable to a targeted attack if I used a fixed IP address or a narrow range. This required a simple shift. To increase anonymity, free public Wi-Fi was used (and it's likely where you could typically expect some of the downloading behavior I was about to replicate). Combine this with a clean install containing no personal information, and the experiment was as safe as anything involving McAfee may get.

So were these search risks, like human gullibility and those looking to profit from it, timeless or just trends of 2008?

Since Windows is the dominant operating system today, I used a MacBook Pro with a Windows 7 64 bit OEM virtualization via Parallels 7. This functioned basically as a PC petri dish and a sandbox for the potentially dangerous software. I could revert to the original pre-search image after each query—back to default programs with only Mozilla Firefox (one of the three most widely used Internet browsers) and two free popular malware detection programs, Microsoft Security Essentials and Lavasoft’s Ad-Aware.

For each search, I opened a new browser window in Mozilla Firefox—in private browsing mode—and navigated to Google’s search homepage. I saved the image of the clean computer state to Parallels, allowing me to run each search term in a standardized fashion before reverting to the beginning again.

Let the games (and lyrics, and other downloads) begin.

Enlarge / Desktop before search No. 1...
Enlarge / Web browser before search No. 1...

Expand full story

Page: 1 2 3 Next ?

View the original article here

Adobe Flash exploit grabs video and audio, long after “fix”

Sign up for the Ars Technica Dispatch, which delivers links to the most popular articles, journals, and multimedia features via e-mail to your inbox every week.

I understand and agree that registration on or use of this site constitutes agreement to its User Agreement and Privacy Policy.

View the original article here

Android flaw allows hackers to surreptitiously modify apps

Enlarge / A screenshot of an Android device that's been hacked by modifying the device manufacturer's application. The hack gives access to all permissions on the device.

Researchers said they've uncovered a security vulnerability that could allow attackers to take full control of smartphones running Google's Android mobile operating system.

The weakness involves the way legitimate Android applications are cryptographically signed to ensure they haven't been modified by parties other than the trusted developer, according to a blog post published Wednesday by researchers from mobile security startup Bluebox. The flaw has existed since at least the release of Android 1.6 almost four years ago. Hackers who exploit the vulnerability can modify app code to include backdoors, keyloggers, or other malicious functionality without changing the verification signature.

Malicious apps that exploit the vulnerability would enjoy the same system privileges as the legitimate one. That access could be especially dangerous if the app that's modified originated with the handset manufacturer or third parties that partner with the manufacturer, Wednesday's blog post said. That's because such apps are typically granted elevated privileges within the Android OS.

"The application then not only has the ability to read arbitrary application data on the device (e-mail, SMS messages, documents, etc.), [and] retrieve all stored account & service passwords, it can essentially take over the normal functioning of the phone and control any function thereof (make arbitrary phone calls, send arbitrary SMS messages, turn on the camera, and record calls)," the blog post said. "Finally, and most unsettling, is the potential for a hacker to take advantage of the always-on, always-connected, and always-moving (therefore hard-to-detect) nature of these “zombie” mobile devices to create a botnet."

While it would be devastating if an attacker was able to get such a modified APK into the Google Play Store, or somehow use the technique to hijack the update mechanism of legitimate apps, there are probably safeguards already in place to prevent such attacks.

"I imagine that Google would move quickly to add some logic to look for such attacks," Dan Wallach, a professor specializing in Android security in the computer science department of Rice University, told Ars. "Without that available to an attacker, this is likely to only be relevant for Android users who use third-party app stores (which have lots of other problems). This bug could also be valuable for users trying to 'root' their phones."

Blue box researchers privately reported the vulnerability to Google in February.

View the original article here

Stanford, Mozilla, Opera team up to tackle cookie privacy issues

For the past few months, Firefox alphas have been heuristically blocking certain cookies in a bid to protect user privacy and reduce the amount of online tracking by advertisers. Mozilla has not moved this blocking into the stable builds of its browser, however, because of problems with its effectiveness. The heuristics aren't perfect, so sometimes it blocks cookies it shouldn't block and other times lets cookies through that it should block.

A new project from Stanford University could provide the solution. The Cookie Clearinghouse intends to provide lists of cookies that should be blocked or accepted. Still in the planning stages, it will be designed to work in concert with the heuristics found in Firefox in order to correct the errors that the algorithmic approach makes.

Firefox's algorithm is simple. Essentially, if you visit a domain directly, that domain will be able to set cookies (first-party cookies) and it will continue to be permitted to set cookies even when visited indirectly (third-party cookies). For example, if you visit facebook.com, it will be allowed to set cookies both for explicit visits and whenever other sites embed Facebook content such as like buttons.

Conversely, if you've never directly visited a domain, that domain won't be allowed to set cookies at all. If you've never once visited Facebook then the embedded Facebook content won't be able to set any cookies.

As a rule of thumb, this works reasonably well; Safari has used this same algorithm for some time. However, it's not perfect. Some sites use multiple domains. A visit to the site should treat these domains as first-party (as they're still owned, operated, and controlled by the same people who run the site), but under this heuristic it won't. The Cookie Clearinghouse gives a hypothetical example: stanford.edu could load its images from domain stanford-images.edu. This would fall foul of the algorithm.

There can also be problems in the other direction. An accidental click on an advertisement will elevate the advertiser's domain to being an explicitly visited first party, and that will allow the advertiser's third-party cookies to work. That's probably not what you want to do.

Apple's solution for the problem, such as it is, is to disable the cookie blocking entirely should it cause a problem. That works, but Mozilla isn't keen on it. Mozilla CTO Brendan Eich writes that users tend to just leave the setting off forever, attaining no privacy protection at all.

The Cookie Clearinghouse is the solution. It will produce lists enumerating both cookies that should be allowed but aren't, and cookies that shouldn't be allowed but are. Browsers can then use these lists to shore up the algorithmic approach. The plan is to also allow site owners to challenge inclusion on the block list and present an argument for why their cookies should be allowed.

As well as Stanford staff, the Cookie Clearinghouse's advisory board includes representatives from Mozilla and Opera. Mozilla is inviting feedback and promoting the Cookie Clearinghouse as a neat solution to cookie privacy issues.

Advertisers appear to be less keen. Speaking to The Washington Post, Randall Rothenberg, president of the Interactive Advertising Bureau (an organization of advertisers and media companies), said that "there are billions and billions of dollars and tens of thousands of jobs at stake in [the advertising] supply chain." He continued. "[Changes in browser behavior] should be done with stakeholders' input." (Condé Nast, parent company of Ars Technica, is a member of the IAB.)

The algorithmic approach, combined with the lists to patch up the algorithm, also sidesteps another Web privacy issue that has been rumbling for a couple of years: Do Not Track. The Do Not Track specification described a request that browsers can send to Web servers to indicate that their users don't want to have their Web activity tracked by servers.

Its development has been fraught with controversy. To be useful, Do Not Track requires advertisers to opt in and explicitly choose to support it. Naturally, they're reluctant to do so, as it limits their ability to target ads to users. Accordingly, the spec says that the Do Not Track request cannot be sent by a browser by default: it must require a user opt-in.

Microsoft, in the name of greater privacy, threw a cat among the pigeons and turned Do Not Track on by default. The company justified its decision by saying that it still forced users to click through settings screens when first using Internet Explorer 10 and hence still had user consent.

The specification has other issues, such as a definition of "tracking" that might not square well with user expectations (analytics and advertising companies are still allowed to perform some kinds of tracing of Do Not Track users). There's also an unrestricted right for first parties to track users, even if they don't want to be tracked.

The conflicting views and incompatible demands threatened to derail the standard but it may yet limp towards some sort of outcome. The group working on the spec is due to finish their work in July. Getting agreement among the various parties seems impossible, so the options are to give up entirely, to force through changes that not everyone agrees on (something that the group's co-chairs can do), or to weaken the language and terminology of the spec to make it so meaningless that everyone will agree to it.

The algorithmic approach with the Cookie Clearinghouse should prove to be a more robust privacy system and one that doesn't depend on the consent of advertisers. If the browser blocks a cookie then there's nothing an advertiser can do about it.

Listing image by Jeramey Jannene

View the original article here

Attackers sign malware using crypto certificate stolen from Opera Software

Hackers penetrated network servers belonging to Opera Software, stole at least one digital certificate, and then used it to distribute malware that incorrectly appeared to be published by the browser maker.

The attack was uncovered, halted, and contained on June 19, according to a short advisory that Opera published Wednesday morning. While administrators have cleaned the system and have yet to find any evidence of any user data being compromised, the breach still had some troubling consequences.

"The attackers were able to obtain at least one old and expired Opera code signing certificate, which they have used to sign some malware," Wednesday's advisory stated. "This has allowed them to distribute malicious software which incorrectly appears to have been published by Opera Software or appears to be the Opera browser. It is possible that a few thousand Windows users, who were using Opera between June 19 from 1.00 and 1.36 UTC, may automatically have received and installed the malicious software."

Opera's advisory leaves out key information that makes it hard to assess just how much damage was done. Missing details include when the attackers first gained access to the servers, precisely when the stolen digital certificate expired, and whether there's reason to believe other certificates may also have been obtained. It would also be useful to know how hackers got access to an official Opera digital certificate, which is supposed to cryptographically prove that the software that bears its seal could only have come from the company. As Ars reported last year, companies such as Symantec go to great lengths to secure such keys, although Opera is hardly alone in losing control of such a valuable certificate.

The advisory also provides few details about the malware that was signed with Opera's official digital imprimatur, other than to link to this VirusTotal analysis. The Opera post urged users to "update to the latest version of Opera as soon as it is available, keep computer software up to date, and to use a reputable antivirus product on their computer."

Opera representatives declined to provide additional details, citing a continuing investigation into the breach. At some point soon, though, officials should provide a more thorough account of what happened, who was affected, and what steps have been taken to prevent similar attacks from succeeding in the future.

View the original article here

How the US (probably) spied on European allies’ encrypted faxes

Enlarge / Part of a secret document published by The Guardian detailing "Dropmire," a program that reportedly spied on encrypted faxes sent to the European Union's Washington, DC, mission.

View all…

US intelligence services implanted bugging tools into cryptographic facsimile devices to intercept secret communications sent or received by the European Union's Washington, DC outpost, according to the latest leak from former National Security Agency staffer Edward Snowden. Technical details are scarce, but security experts reading between the lines say the program probably relies on an old-school style of espionage that parses electric currents, acoustic vibrations, and other subtle types of energy to reveal the contents of encrypted communications.

The bugging method was codenamed Dropmire, and it appears to rely on a device being "implanted on the Cryptofax at the EU embassy, DC," according to a 2007 document partially published Sunday by The Guardian. An image included in the document, presumably taken from a transmission traveling over a targeted device, showed highly distorted text that can just barely be read by the human eye as the letters "EC" followed by "NCN." The fax device was used to send cables between foreign affairs ministries and European capitals, according to Sunday's report.

The ability to approximate the plaintext message but not capture it as it appeared when fully decrypted likely means Dropmire didn't crack the precise algorithm or key used to encrypt the message. That—along with the detail about something being "implanted" in the fax device—has led to speculation that the program monitored electrical, mechanical, or acoustical energy emanating from the device to deduce clues about the plaintext messages being received. Such techniques fall under the umbrella term Tempest, which was coined more than three decades ago as an NSA tactic for reading sensitive communications relating to national security. More recently, Tempest has come to mean any investigation or analysis that uses so-called "compromising emanations" to reveal the contents of sensitive communications or lead to the decryption of encrypted data.

"Having done many experiments to eavesdrop on office equipment myself, the noisy image at the bottom third of the picture above looked instantly familiar," Markus Kuhn, a computer scientist and senior lecturer at Cambridge University, wrote in a blog post published Monday. "It is what you might get from listening with a radio receiver on the compromising emanations of a video signal of a page of text."

Three security experts Ars spoke with agreed with Kuhn's analysis. They said it makes a strong case that the attacks targeting the EU encrypted fax devices were relying on what's known as side-channel attacks, which target weaknesses in a specific cryptographic implementation rather than the underlying cipher or mathematics it's built on.

"It's breaking things that really have nothing to do with the cryptography itself," Justin Troutman, a cryptographer and independent security and privacy researcher, told Ars. He went on to say that the effort required on the part of US intelligence agents was likely justified when considering the intelligence value of the encrypted data. "I think the side-channel attacks are plausible, and I think the target warrants it. So even though it's speculation at this point, it's certainly a valid point within the realm of reason."

Side-channel attacks analyze subtle fluctuations in power drawn by a cryptographic device or slight differences in the amount of time it takes the device to complete certain tasks. The side data is then used to ferret out clues about the underlying plaintext or the key or algorithm that was used to encrypt it. In some cases, side-channel attacks can be used to recover the entire cleartext once enough clues are gathered. Other times, the technique reveals only partial contents of the message.

"One way I've seen other side-channel attacks work is once you convert a signal into a binary, you can hope that it's as easy as reading the data," Troutman explained. "There's going to be noise, so it may take other algorithms to parse through that noise and filter it out. But if you can get bits and pieces, a few letters here, a few letters there, over time you may be able to build a picture of what the conversation is about, or enough to at least identify what this communication channel is used for, or possibly even identify names attached to other projects."

Cryptographic device makers have known about side-channel attacks for decades and often work hard to prevent their wares from leaking clues that can compromise customers' encrypted messages. Hardened devices often use data "padding" to obscure the size of encrypted messages. Devices may also be programmed to ensure there's more uniformity in the amount of time it takes for different types of data to be encrypted or decrypted. They frequently encase cryptographic devices in protective shields that prevent them from leaking electric or other types of emanations that can be analyzed by an adversary. That being the case, how might US intelligence agents carry out a side-channel attack on an encrypted fax device belonging to the EU?

One possibility is to plant some sort of bug on or near a targeted device that captures compromising emanations and delivers them to intelligence agents for analysis. While the data intercepted by such a Tempest-style bug has clear disadvantages—namely, the crudeness of the data it intercepts—it might also be considerably easier to plant and harder for EU defenders to detect. By contrast, a more advanced bug secretly added to a fax device might be able to deliver a more reliable copy of the protected communication while being relatively easy for someone to spot. In some cases, the bug might not be anything that's added but, rather, something removed to permit leakage that wouldn't otherwise occur. The corruption in the image included with The Guardian article suggests the device was closer to the former.

"That the image is so distorted, and getting edges instead of content, indicates that it's something simple, such as adding a wire or removing wire, as the [Kuhn] article indicates," said Rob Graham, CEO of security consultancy Errata Security. "Adding a circuit board would be detectable, snipping a trace on a circuit board to enhance emanations wouldn't be."

It's also possible that the surveillance was conducted by using a bug to analyze radio frequency emissions only after the sensitive data had been decrypted and was in the process of being printed by the fax device. In 2009, for instance, researchers demonstrated two methods for eavesdropping on passwords and other sensitive data by exploiting vibrational patterns and electromagnetic pulses that emanate with every character entered into a computer.

"The laser printer of a fax machine certainly fits the profile and unless specific countermeasures are in place, it might be vulnerable to such eavesdropping techniques, which would not be mitigated by the encryption layer, as they target the end output of the printer," said Andrea Barisani, chief security engineer for Inverse Path and one of the researchers behind the 2009 demonstration. "Our company is often given the task to assess the interaction between physical electronics and software security of embedded devices such as printers and fax machines. In the vast majority of cases, all of the tested targets are vulnerable to software attacks, hardware attacks, or a combination of the two."

The lack of specific details in The Guardian article makes it impossible to know just how accurate speculation is that US intelligence services are launching Tempest-style attacks on its European allies. But based on the information available, it's not possible to rule out these James Bond-type of surveillance techniques either.

View the original article here

Rampant Apache website attack hits visitors with highly malicious software

A campaign that forces sites running the Apache Web server to install highly malicious software on visitor's PCs has compromised more than 40,000 Web addresses in the past nine months, 15,000 of them in the month of May alone.

The figures, published Tuesday by researchers from antivirus provider Eset, are the latest indication that an attack on websites running the Internet's most popular Web server continues to build steam. Known as Darkleech, the rogue Apache module gets installed on compromised servers and turns legitimate websites into online mine fields that expose unsuspecting visitors to a host of dangerous exploits. More than 40,000 domains and website IPs have been commandeered since October, 15,000 of which were active at the same time in May, 2013 alone. In just the last week, Eset has detected at least 270 different websites exposing users to attacks.

Sites that come under the spell of Darkleech redirect certain visitors to malicious websites that host attack code spawned by the notorious Blackhole exploit kit. The fee-based package available in underground forums makes it easy for novices to exploit vulnerabilities in browsers and browser plug-ins. Web visitors who haven't installed updates patching those flaws get silently infected with a variety of dangerous malware titles. Among the malware that Darkleech pushes is a "Nymaim" piece of ransomware that demands a $300 payment to unlock encrypted files from a victim's machine. Other malware titles that get installed include Pony Loader and Sirefef.

"This campaign has been going on for a very long time," Eset malware researcher Sébastien Duquette wrote in Tuesday's blog post. "Our data shows that the Blackhole instance has been active for more than two years, since at least February 2011."

Eset's research is consistent with April coverage from Ars reporting that an estimated 20,000 Apache websites were infected by Darkleech in just a few weeks' time. Sites operated by The Los Angeles Times, Seagate, and other reputable companies were among the casualties. Like Ars, Eset found the Web malware employs a detailed array of conditions to determine when to inject malicious links into the pages shown to end users. Among other things, Eset wrote that users will only be attacked when their browser reports they're using Microsoft's Internet Explorer browser or Oracle's Java plugin. Eset's findings are also consistent with recent figures from Google showing that the vast majority of malware attacks are spawned from legitimate sites that have been hacked.

Darkleech has also been known to pass over visitors using IP addresses belonging to security and hosting firms, people who have recently been attacked, and those who don't access the hacked pages from specific search queries. By being highly selective in targeting potential victims, Darkleech developers make it harder for security defenders to unravel the campaign and block infections. Visitors who are selected are served an HTML-based iframe tag in a Web page from the legitimate site that has been compromised. The iframe exploits code from a malicious site under the control of attackers.

Darkleech, which also goes by the name Linux/Charpoy, is able to tailor exploits to the geographic region of the infected victim as well. Ransomware that infects US-based visitors, for instance, purports to come from the FBI, while ransomware hitting people in other countries is adapted accordingly.

Enlarge / The Darkleech infection flow.

In October, Darkleech underwent a makeover that changed the format of the URL in the malicious iframe so it's harder to detect. It works by decrypting four different text strings and then calculating a cryptographic hash to determine if a visitor should be served an iframe. The randomly generated link that leads to the attack site is extremely hard to detect as malicious except for its telltale ending "q.php."

As has been the case with previous investigations, researchers still don't know how the Darkleech module takes initial hold of the sites it infects. Speculation has surfaced that the servers are compromised by exploiting undocumented vulnerabilities in the CPanel or Plesk tools administrators used to remotely manage sites, but there's no hard evidence to back up that theory. Researchers also reckon sites may be taken over by cracking administrative passwords or by exploiting security flaws in Linux, Apache, or another piece of commonly used software. Darkleech in part uses CPanel and Plesk servers to handle certain aspects of the iframe injection and payload delivery, but other parts rely on the Apache server itself, Pierre-Marc Bureau, Eset's security intelligence program manager, told Ars.

Because there are usually many websites hosted on a single server, there's often multiple domain names pointing to a single IP address, so Eset researchers are unable to determine just how many Apache-powered websites are infected by Darkleech. The total is "probably lower" than the 40,000 estimate, Bureau said.

The Eset report comes two weeks after researchers from security firm Sucuri unearthed a new malicious module infecting Apache servers. They're still not sure if the plug-in is a newer, stealthier version of Darkleech or a completely different tool developed by a rival crime group. Researchers in recent months have uncovered a third piece of malware that causes websites to expose visitors to attacks. Known as Linux/Cdorked, it targets sites running the Apache, nginx, and Lighttpd Web servers and, as of May, had exposed almost 100,000 end-users running Eset software alone to attack.

With so many threats successfully targeting mainstream Web servers, administrators should take care to lock down their systems by following good security hygiene. One step is to ensure all default passwords have been changed to a one that's long and randomly generated. Also key is to make sure all software components—including the operating system and all applications—are fully up to date. It's also not a bad idea to use a website security scanner from time to time and to occasionally check the cryptographic hash of the HTTP daemon of the Web server to make sure it hasn't been tampered with.

View the original article here