Careful What You Search For

Search results and malicious websites

Among the many excuses I’ve heard from people who take computer security too lightly, or who brush off the likelihood of being targeted by Web attacks, are comments such as “I don’t search for a…

Search results and malicious websites

Among the many excuses I’ve heard from people who take computer security too lightly, or who brush off the likelihood of being targeted by Web attacks, are comments such as “I don’t search for anything bad,” or “I only visit sites I know.” I find this sort of attitude very frustrating, if not amusing, and I like coming across bits of information that I can use to educate these people. So, I was especially interested in the results of some related data analysis that I worked on for on the recently released Symantec Report on Attack Kits and Malicious Websites.

One of the metrics we use in the report examines Web search terms and the number of times the use of each search term resulted in a user visiting a malicious website. The range of search terms was unrestricted and consisted of both “good” and “bad”’ things—anything that any one might search the Web for, in other words. The top 100 terms were chosen for closer inspection based on the volume of malicious website hits associated with them.

Malicious websites by search term type

One of the resulting data points that came from the analysis was particularly interesting, although not surprising. Of the top 100 search terms, 74 were specific to legitimate domain names. That means that someone was searching for a legitimate website by name and ended up visiting a malicious website instead. How does that happen? One of the main ways is this: When Uncle Bob wants to visit some website, perhaps his favorite social network, he types the website name in the search bar rather than entering the full URL. Uncle Bob’s browser searches for the matching domain name and returns a list of results. Uncle Bob, absent-mindedly clicks on one of the results without verifying its integrity and ends up opening a malicious website.

This scenario may sound a bit contrived, but I think alternate scenarios are likely similar. Moreover, the numbers speak volumes: attackers are getting more hits on their malicious sites when targeting searches for reputable (i.e., good) websites than they are for targeting, say, less-than-savory sites, reinforcing just how important caution is when browsing the Web, even for people who think they’re practicing safe searching.

For a complete analysis of malicious websites by search term—as well discussion on other aspects attack kits and malicious sites—please download the Symantec Report on Attack Toolkits and Malicious Websites.

Did a U.S. Government Lab Help Israel Develop Stuxnet?

Questions are being raised about the involvement of U.S. government researchers in the creation of a digital weapon that experts believe may have sabotaged centrifuges at a uranium-enrichment plant in Iran.
Researchers at the Idaho National Laboratory, which is overseen by the U.S. Department of Energy, may have passed critical information to Israel about vulnerabilities in […]

Questions are being raised about the involvement of U.S. government researchers in the creation of a digital weapon that experts believe may have sabotaged centrifuges at a uranium-enrichment plant in Iran.

Researchers at the Idaho National Laboratory, which is overseen by the U.S. Department of Energy, may have passed critical information to Israel about vulnerabilities in a system that controls Iran’s enrichment plant at Natanz. That information was then used to create and test the so-called Stuxnet worm that was unleashed in a joint cyberattack on Natanz, according to The New York Times.

The report, based on anonymous sources, is sparse on detail but asserts that in 2008, INL worked with the German firm Siemens to uncover vulnerabilities in its industrial-control system. Stuxnet was then created to exploit those vulnerabilities and was lab-tested at Israel’s nuclear facility in Dimona. The Dimona facility, according to the Times, has been involved in a joint U.S.-Israel operation for the last two years to thwart Iran’s production of enriched uranium and forestall its development of a nuclear weapon.

Researchers at Dimona set up a test bed composed of the Siemens system and the same IR-1 nuclear centrifuges (also known as P-1 centrifuges) used at Natanz to gauge Stuxnet’s effect on them. The malware was discovered in the wild last June infecting systems in Iran and elsewhere, and last November, Iran acknowledged that malicious software had sabotaged centrifuges at Natanz.

Threat Level has already reported extensively on how Stuxnet worked and on clues that were previously uncovered that suggested Israel was behind the attack. Although it’s long been suspected that the United States played a key role, if not the lead role, in creating the malware, there’s been no definitive evidence.

The Times story falls short of delivering that evidence, but Threat Level has been tracking the same story for months, and it’s worth fleshing out the report with additional details.

Exploiting Jnanabot for Fun and Profit

Lest we forget, malware is a software application, albeit a malicious one. And, like any other software application, it can have vulnerabilities that can be exploited.

Our analysis of Trojan.J…

Lest we forget, malware is a software application, albeit a malicious one. And, like any other software application, it can have vulnerabilities that can be exploited.

Our analysis of Trojan.Jnanabot has revealed several serious vulnerabilities. One of the more interesting features of Jnanabot is its custom peer-to-peer (P2P) networking protocol. In other words, its bots are designed to be a part of a P2P network and use a custom-designed protocol for communicating with each other. This ensures that there is no single point of failure and that it is harder to trace the source of the infection and to take the botnet down. While the protocol was designed to provide some degree of robustness to the botnet, it has some flaws that allow anyone (provided they have the right know-how) to exploit them for fun and/or profit. At the very least, these flaws can be used to collect information about the infected hosts. At worst, they can be leveraged to create a fully functional parallel botnet or effect the complete takeover of the existing one.

In this blog I will document these flaws and illustrate how they can be exploited. Taking a page from the black hat handbook, we know that a successful exploit involves the following steps:

1.    Identifying a target
2.    Information gathering
3.    Exploiting a vulnerability in a network service running on the target
4.    Launching further attacks

Our research has shown that Jnanabot protocol vulnerabilities make the above steps trivial.

Identifying a target

The port for Jnanabot P2P communication is determined from the IP address of the peer, using a hashing algorithm. This means that given an IP address, it is possible to determine the port on which the Jnanabot P2P service might be running—if the host is in fact infected. Moreover, if a badly formatted P2P message is sent to an infected host, Jnanabot responds with an error message. Hence, given a range of IP addresses, it is possible to scan and identify infected hosts in that range.

Information gathering

The Jnanabot P2P protocol has an information-disclosure vulnerability that can be exploited to determine the current version of the bot and the operating system of the infected host on which it is running. In fact, the bot provides access to any file to which the currently logged-in user has access. It is easy to determine the current operating system and its version from artifacts of the file system. For example, the following chart shows Jnanabot’s OS distribution, mapped in the early part of December 2010:

In addition, on Windows hosts the malware installs a keylogger that records keystrokes in a plaintext flat file on the system before uploading the file to a remote FTP server. These files are accessible via the P2P service and can reveal private and confidential details such as usernames and passwords to a remote unauthenticated attacker.

Exploiting a vulnerability

The Jnanabot P2P protocol has a vulnerability that allows the user to upload any file to any location of the host’s file system. This can be easily exploited to run a simple backdoor on the infected host. For example, a file created in the startup directory in Windows will run every time Windows restarts. An attacker may also install a rootkit to cover his or her tracks and/or hide the backdoor.

Launching further attacks

Each Jnanabot agent maintains a list of peers. The P2P protocol provides a way of updating this list and also obtaining this list from a host. In addition, this list is present in encrypted form in the root directory where Jnanabot is installed. Hence, if even a single peer in a network is known, its peer list can be used to identify further targets whose peer lists can in turn be used; in this way, a large list of exploitable hosts can be obtained. A single peer can be used as a springboard to dive ever deeper into the Jnanabot network. Note that each list can have a maximum of 100 peers—making it highly probable that at least some of those peers will be accessible and available for exploitation.

Conclusion

It is not possible to determine if the existence of these vulnerabilities is known to Jnanabot’s creator(s), who either have a callous disregard for them or are simply unaware. We also do not know if there are others in the black hat community who know of these issues and are exploiting them. In any case, a host infected with Jnanabot has its doors wide open with a big “Welcome” sign inviting further exploitation. As such, the presence of Jnanabot on a host poses a threat much more grave than previously thought. Put that together with the fact that Jnanabot can infect multiple platforms, and we have a recipe for disaster.

Note that Jnanabot is written in a secure language, using advanced cryptographic techniques with strong algorithms. Yet, it allows for a complete compromise of the host on which it runs. This goes to show that depending solely upon secure platforms cannot ensure application security. Logic bugs are platform independent and can affect any application, including malware. It also demonstrates how a single malware infection can open the door to further infections and compromise the overall security of systems and networks.

Tweeting Tyrants Out of Tunisia: Global Internet at Its Best

Even yesterday, it would have been too much to say that blogger, tweeters, Facebook users, Anonymous and Wikileaks had “brought down” the Tunisian government, but with today’s news that the country’s president Zine El Abidine Ben Ali has fled the country, it becomes a more plausible claim to make.
Of course there was more to such […]


Even yesterday, it would have been too much to say that blogger, tweeters, Facebook users, Anonymous and Wikileaks had “brought down” the Tunisian government, but with today’s news that the country’s president Zine El Abidine Ben Ali has fled the country, it becomes a more plausible claim to make.

Of course there was more to such demonstrations than some new technology. An individual act of desperation set off the last month of rioting, as a college-educated young man set himself on fire after police confiscated his unlicensed fruit and vegetable cart. Tunisia’s high unemployment rate, rampant corruption and rising food prices added to the anger at Ben Ali’s 20-plus-year rule.

People risked their lives in the street, with some getting a bullet for their troubles, but the internet played a significant role in organizing these protests and in disseminating news and pictures of them to the world.

After the worst unrest in his reign, Ben Ali this week promised not to run for “election” again and to give the country a free press and the right to assemble. He fired his cabinet. It wasn’t enough. Protestors sensed weakness, and today they forced Ben Ali from Tunisia. He fled ignominiously with his family for any state that would have him.

Here’s a guide to the part of this battle fought in cyberspace over the last month.

Web blocking: Soon after the protests began, Tunisia ramped up its attempts at controlling the internet. These started simply enough, with straight-up site blocking. In an open letter to the Tunisian government, the Committee to Protect Journalists outlined the online repression:

We are troubled to learn that your government’s practice of blocking websites — including CPJ Web pages on Tunisia — has recently intensified. Local journalists told CPJ that additional news websites, as well as numerous Facebook pages carrying critical content, blogs, and journalists’ e-mail accounts have been blocked by the state-run Tunisian Internet Agency since protests erupted on December 17. Regional and international media have reported that numerous local and international news websites covering the street protests were blocked in Tunisia. One report placed your country, along with Saudi Arabia, as the worst in the region regarding Internet censorship. A 2009 CPJ study found Tunisia to be one of the 10 worst countries worldwide to be a blogger, in part for the same reasons.

We’ll take that Facebook password, please: It soon got much worse. The Committee to Protect Journalists said its own research found that “the [state-run] Tunisian Internet Agency is harvesting passwords and usernames of bloggers, reporters, political activists and protesters by injecting hidden JavaScript” into many popular site login pages.

This extended to sites like Facebook, where the main login page mysteriously had 10 additional lines of code inserted when it arrived at Tunisian computers. (Such code injection is technically simple using various pieces of deep-packet inspection gear, and it was made easier by the fact that the Tunisian government would periodically block secure HTTPS connections.)

That code grabbed the username and password, embedded them into a bogus Facebook URL, and then attempted to load the nonexistent page. It’s unclear why this was done, though speculation is that the hack was a simple way to grab passwords. The Tunisian Internet Agency could simply log all attempts to hit the bogus Facebook link without the liability of listing one of its servers in the code itself.

CPJ noted in a separate report that “unknown parties have subsequently logged onto these sites using these stolen credentials, and used them to delete Facebook groups, pages and accounts, including Facebook pages administrated by Sofiene Chourabi, a reporter with Al-Tariq al-Jadid, and the account of local online video journalist Haythem El Mekki. Local bloggers have told CPJ that their accounts and pictures of recent protests have been deleted or otherwise compromised.”

Al-Jazeera interviewed an anonymous source who had crafted a Greasemonkey script that could strip this additional code from login pages. On January 6, it had already been installed over 1,500 times.

On January 11, the Electronic Frontier Foundation publicized the Greasemonkey script but also asked Facebook in particular to consider a few technical changes:

Make Facebook logins default to HTTPS, if only in Tunisia, where accounts are especially vulnerable at this time. Google and Yahoo logins already default to HTTPS.

Consider allowing pseudonymous accounts for users in authoritarian regimes, where political speech under your real name is dangerous and potentially deadly. Many Tunisian activists are unable to reinstate Facebook accounts that have been erased by the Tunisian government because they were not using their real names.

Finding bloggers, pirates: The Tunisian government, not content to simply grab account information and delete the offending material, also began hauling bloggers into police custody.

On January 7, Reporters Without Borders had at least five confirmed cases of bloggers and online activists being arrested. Here’s one:

Four or five police plainclothes officers arrested the blogger and activist Hamadi Kaloutcha at his home at around 6 am, seizing a computer and a central processing unit. They told his wife they were taking him to the nearest police station and “just have a few questions for him,” and “that will only take a few hours.” There has been no news of him since.

Several of those arrested, including Kaloutcha, were members of the Pirate Party of Tunisia; the Pirate Party U.K. later issued several statements deploring the disappearances.

“Pirate Parties around the world condemn these acts against freedom of expression, human rights and democracy, and call upon governments take firm action against Tunisia for these recent events,” one said. A later note said that one detainee had been beaten, and it said that several of the bloggers were accused of “degradation of state property on account of anonymous DDoS attacks.”

And who specializes in anonymous distributed denial of service (DDoS) attacks against unfriendly websites? That’s right, it’s …