Entries Tagged "hacking"

Page 44 of 78

History of Hacktivism

Nice article by Dorothy Denning.

Hacktivism emerged in the late 1980s at a time when hacking for fun and profit were becoming noticeable threats. Initially it took the form of computer viruses and worms that spread messages of protest. A good example of early hacktivism is “Worms Against Nuclear Killers (WANK),” a computer worm that anti-nuclear activists in Australia unleashed into the networks of the National Aeronautics and Space Administration and the US Department of Energy in 1989 to protest the launch of a shuttle which carried radioactive plutonium.

By the mid-1990s, denial of service (DoS) attacks had been added to the hacktivist’s toolbox, usually taking the form of message or traffic floods. In 1994, journalist Joshua Quittner lost access to his e-mail after thousands of messages slamming “capitalistic pig” corporations swamped his inbox, and a group called itself “The Zippies” flooded e-mail accounts in the United Kingdom with traffic to protest a bill that would have outlawed outdoor dance festivals. Then in 1995, an international group called Strano Network organized a one-hour “Net’strike” against French government websites to protest nuclear and social policies. At the designated time, participants visited the target websites and hit the “reload” button over and over in an attempt to tie up traffic to the sites.

Her conclusion comes as no surprise:

Hacktivism, including state-sponsored or conducted hacktivism, is likely to become an increasingly common method for voicing dissent and taking direct action against adversaries. It offers an easy and inexpensive means to make a statement and inflict harm without seriously risking prosecution under criminal law or a response under international law. Hacking gives non-state actors an attractive alternative to street protests and state actors an appealing substitute for armed attacks. It has become not only a popular means of activism, but also an instrument of national power that is challenging international relations and international law.

Posted on September 21, 2015 at 6:34 AMView Comments

Hacking Team, Computer Vulnerabilities, and the NSA

When the National Security Administration (NSA)—or any government agency—discovers a vulnerability in a popular computer system, should it disclose it or not? The debate exists because vulnerabilities have both offensive and defensive uses. Offensively, vulnerabilities can be exploited to penetrate others’ computers and networks, either for espionage or destructive purposes. Defensively, publicly revealing security flaws can be used to make our own systems less vulnerable to those same attacks. The two options are mutually exclusive: either we can help to secure both our own networks and the systems we might want to attack, or we can keep both networks vulnerable. Many, myself included, have long argued that defense is more important than offense, and that we should patch almost every vulnerability we find. Even the President’s Review Group on Intelligence and Communications Technologies recommended in 2013 that “U.S. policy should generally move to ensure that Zero Days are quickly blocked, so that the underlying vulnerabilities are patched on U.S. Government and other networks.”

Both the NSA and the White House have talked about a secret “vulnerability equities process” they go through when they find a security flaw. Both groups maintain the process is heavily weighted in favor or disclosing vulnerabilities to the vendors and having them patched.

An undated document—declassified last week with heavy redactions after a year-long Freedom of Information Act lawsuit—shines some light on the process but still leaves many questions unanswered. An important question is: which vulnerabilities go through the equities process, and which don’t?

A real-world example of the ambiguity surrounding the equities process emerged from the recent hacking of the cyber weapons arms manufacturer Hacking Team. The corporation sells Internet attack and espionage software to countries around the world, including many reprehensible governments to allow them to eavesdrop on their citizens, sometimes as a prelude to arrest and torture. The computer tools were used against U.S. journalists.

In July, unidentified hackers penetrated Hacking Team’s corporate network and stole almost everything of value, including corporate documents, e-mails, and source code. The hackers proceeded to post it all online.

The NSA was most likely able to penetrate Hacking Team’s network and steal the same data. The agency probably did it years ago. They would have learned the same things about Hacking Team’s network software that we did in July: how it worked, what vulnerabilities they were using, and which countries were using their cyber weapons. Armed with that knowledge, the NSA could have quietly neutralized many of the company’s products. The United States could have alerted software vendors about the zero-day exploits and had them patched. It could have told the antivirus companies how to detect and remove Hacking Team’s malware. It could have done a lot. Assuming that the NSA did infiltrate Hacking Team’s network, the fact that the United States chose not to reveal the vulnerabilities it uncovered is both revealing and interesting, and the decision provides a window into the vulnerability equities process.

The first question to ask is why? There are three possible reasons. One, the software was also being used by the United States, and the government did not want to lose its benefits. Two, NSA was able to eavesdrop on other entities using Hacking Team’s software, and they wanted to continue benefitting from the intelligence. And three, the agency did not want to expose their own hacking capabilities by demonstrating that they had compromised Hacking Team’s network. In reality, the decision may have been due to a combination of the three possibilities.

How was this decision made? More explicitly, did any vulnerabilities that Hacking Team exploited, and the NSA was aware of, go through the vulnerability equities process? It is unclear. The NSA plays fast and loose when deciding which security flaws go through the procedure. The process document states that it applies to vulnerabilities that are “newly discovered and not publicly known.” Does that refer only to vulnerabilities discovered by the NSA, or does the process also apply to zero-day vulnerabilities that the NSA discovers others are using? If vulnerabilities used in others’ cyber weapons are excluded, it is very difficult to talk about the process as it is currently formulated.

The U.S. government should close the vulnerabilities that foreign governments are using to attack people and networks. If taking action is as easy as plugging security vulnerabilities in products and making everyone in the world more secure, that should be standard procedure. The fact that the NSA—we assume—chose not to suggests that the United States has its priorities wrong.

Undoubtedly, there would be blowback from closing vulnerabilities utilized in others’ cyber weapons. Several companies sell information about vulnerabilities to different countries, and if they found that those security gaps were regularly closed soon after they started trying to sell them, they would quickly suspect espionage and take more defensive precautions. The new wariness of sellers and decrease in available security flaws would also raise the price of vulnerabilities worldwide. The United States is one of the biggest buyers, meaning that we benefit from greater availability and lower prices.

If we assume the NSA has penetrated these companies’ networks, we should also assume that the intelligence agencies of countries like Russia and China have done the same. Are those countries using Hacking Team’s vulnerabilities in their cyber weapons? We are all embroiled in a cyber arms race—finding, buying, stockpiling, using, and exposing vulnerabilities—and our actions will affect the actions of all the other players.

It seems foolish that we would not take every opportunity to neutralize the cyberweapons of those countries that would attack the United States or use them against their own people for totalitarian gain. Is it truly possible that when the NSA intercepts and reverse-engineers a cyberweapon used by one of our enemies—whether a Hacking Team customer or a country like China—we don’t close the vulnerabilities that that weapon uses? Does the NSA use knowledge of the weapon to defend the U.S. government networks whose security it maintains, at the expense of everyone else in the country and the world? That seems incredibly dangerous.

In my book Data and Goliath, I suggested breaking apart the NSA’s offensive and defensive components, in part to resolve the agency’s internal conflict between attack and defense. One part would be focused on foreign espionage, and another on cyberdefense. This Hacking Team discussion demonstrates that even separating the agency would not be enough. The espionage-focused organization that penetrates and analyzes the products of cyberweapons arms manufacturers would regularly learn about vulnerabilities used to attack systems and networks worldwide. Thus, that section of the agency would still have to transfer that knowledge to the defense-focused organization. That is not going to happen as long as the United States prioritizes surveillance over security and attack over defense. The norms governing actions in cyberspace need to be changed, a task far more difficult than any reform of the NSA.

This essay previously appeared in the Georgetown Journal of International Affairs.

EDITED TO ADD: Hacker News thread.

Posted on September 15, 2015 at 6:38 AMView Comments

Iranian Phishing

CitizenLab is reporting on Iranian hacking attempts against activists, which include a real-time man-in-the-middle attack against Google’s two-factor authentication.

This report describes an elaborate phishing campaign against targets in Iran’s diaspora, and at least one Western activist. The ongoing attacks attempt to circumvent the extra protections conferred by two-factor authentication in Gmail, and rely heavily on phone-call based phishing and “real time” login attempts by the attackers. Most of the attacks begin with a phone call from a UK phone number, with attackers speaking in either English or Farsi.

The attacks point to extensive knowledge of the targets’ activities, and share infrastructure and tactics with campaigns previously linked to Iranian threat actors. We have documented a growing number of these attacks, and have received reports that we cannot confirm of targets and victims of highly similar attacks, including in Iran. The report includes extra detail to help potential targets recognize similar attacks. The report closes with some security suggestions, highlighting the importance of two-factor authentication.

The report quotes my previous writing on the vulnerabilities of two-factor authentication:

As researchers have observed for at least a decade, a range of attacks are available against 2FA. Bruce Schneier anticipated in 2005, for example, that attackers would develop real time attacks using both man-in-the-middle attacks, and attacks against devices. The”real time” phishing against 2FA that Schneier anticipated were reported at least 9 years ago.

Today, researchers regularly point out the rise of “real-time” 2FA phishing, much of it in the context of online fraud. A 2013 academic article provides a systematic overview of several of these vectors. These attacks can take the form of theft of 2FA credentials from devices (e.g. “Man in the Browser” attacks), or by using 2FA login pages. Some of the malware-based campaigns that target 2FA have been tracked for several years, are highly involved, and involve convincing targets to install separate Android apps to capture one-time passwords. Another category of these attacks works by exploiting phone number changes, SIM card registrations, and badly protected voicemail

Boing Boing article. Hacker News thread.

Posted on August 27, 2015 at 12:36 PMView Comments

Nasty Cisco Attack

This is serious:

Cisco Systems officials are warning customers of a series of attacks that completely hijack critical networking gear by swapping out the valid ROMMON firmware image with one that’s been maliciously altered.

The attackers use valid administrator credentials, an indication the attacks are being carried out either by insiders or people who have otherwise managed to get hold of the highly sensitive passwords required to update and make changes to the Cisco hardware. Short for ROM Monitor, ROMMON is the means for booting Cisco’s IOS operating system. Administrators use it to perform a variety of configuration tasks, including recovering lost passwords, downloading software, or in some cases running the router itself.

There’s no indication of who is doing these attacks, but it’s exactly the sort of thing you’d expect out of a government attacker. Regardless of which government initially discovered this, assume that they’re all exploiting it by now—and will continue to do so until it’s fixed.

Posted on August 19, 2015 at 12:34 PMView Comments

Comparing the Security Practices of Experts and Non-Experts

New paper: “‘…no one can hack my mind’: Comparing Expert and Non-Expert Security Practices,” by Iulia Ion, Rob Reeder, and Sunny Consolvo.

Abstract: The state of advice given to people today on how to stay safe online has plenty of room for improvement. Too many things are asked of them, which may be unrealistic, time consuming, or not really worth the effort. To improve the security advice, our community must find out what practices people use and what recommendations, if messaged well, are likely to bring the highest benefit while being realistic to ask of people. In this paper, we present the results of a study which aims to identify which practices people do that they consider most important at protecting their security on-line. We compare self-reported security practices of non-experts to those of security experts (i.e., participants who reported having five or more years of experience working in computer security). We report on the results of two online surveys—­one with 231 security experts and one with 294 MTurk participants­—on what the practices and attitudes of each group are. Our findings show a discrepancy between the security practices that experts and non-experts report taking. For instance, while experts most frequently report installing software updates, using two-factor authentication and using a password manager to stay safe online, non-experts report using antivirus software, visiting only known websites, and changing passwords frequently.

Posted on July 30, 2015 at 2:21 PMView Comments

Hacking Team's Purchasing of Zero-Day Vulnerabilities

This is an interesting article that looks at Hacking Team’s purchasing of zero-day (0day) vulnerabilities from a variety of sources:

Hacking Team’s relationships with 0day vendors date back to 2009 when they were still transitioning from their information security consultancy roots to becoming a surveillance business. They excitedly purchased exploit packs from D2Sec and VUPEN, but they didn’t find the high-quality client-side oriented exploits they were looking for. Their relationship with VUPEN continued to frustrate them for years. Towards the end of 2012, CitizenLab released their first report on Hacking Team’s software being used to repress activists in the United Arab Emirates. However, a continuing stream of negative reports about the use of Hacking Team’s software did not materially impact their relationships. In fact, by raising their profile these reports served to actually bring Hacking Team direct business. In 2013 Hacking Team’s CEO stated that they had a problem finding sources of new exploits and urgently needed to find new vendors and develop in-house talent. That same year they made multiple new contacts, including Netragard, Vitaliy Toropov, Vulnerabilities Brokerage International, and Rosario Valotta. Though Hacking Team’s internal capabilities did not significantly improve, they continued to develop fruitful new relationships. In 2014 they began a close partnership with Qavar Security.

Lots of details in the article. This was made possible by the organizational doxing of Hacking Team by some unknown individuals or group.

Posted on July 27, 2015 at 6:17 AMView Comments

Remotely Hacking a Car While It's Driving

This is a big deal. Hackers can remotely hack the Uconnect system in cars just by knowing the car’s IP address. They can disable the brakes, turn on the AC, blast music, and disable the transmission:

The attack tools Miller and Valasek developed can remotely trigger more than the dashboard and transmission tricks they used against me on the highway. They demonstrated as much on the same day as my traumatic experience on I-64; After narrowly averting death by semi-trailer, I managed to roll the lame Jeep down an exit ramp, re-engaged the transmission by turning the ignition off and on, and found an empty lot where I could safely continue the experiment.

Miller and Valasek’s full arsenal includes functions that at lower speeds fully kill the engine, abruptly engage the brakes, or disable them altogether. The most disturbing maneuver came when they cut the Jeep’s brakes, leaving me frantically pumping the pedal as the 2-ton SUV slid uncontrollably into a ditch. The researchers say they’re working on perfecting their steering control—for now they can only hijack the wheel when the Jeep is in reverse. Their hack enables surveillance too: They can track a targeted Jeep’s GPS coordinates, measure its speed, and even drop pins on a map to trace its route.

In related news, there’s a Senate bill to improve car security standards. Honestly, I’m not sure our security technology is enough to prevent this sort of thing if the car’s controls are attached to the Internet.

EDITED TO ADD (8/14): More articles.

Posted on July 23, 2015 at 6:17 AMView Comments

Organizational Doxing of Ashley Madison

The—depending on who is doing the reporting—cheating, affair, adultery, or infidelity site Ashley Madison has been hacked. The hackers are threatening to expose all of the company’s documents, including internal e-mails and details of its 37 million customers. Brian Krebs writes about the hackers’ demands.

According to the hackers, although the “full delete” feature that Ashley Madison advertises promises “removal of site usage history and personally identifiable information from the site,” users’ purchase details—including real name and address—aren’t actually scrubbed.

“Full Delete netted ALM $1.7mm in revenue in 2014. It’s also a complete lie,” the hacking group wrote. “Users almost always pay with credit card; their purchase details are not removed as promised, and include real name and address, which is of course the most important information the users want removed.”

Their demands continue:

“Avid Life Media has been instructed to take Ashley Madison and Established Men offline permanently in all forms, or we will release all customer records, including profiles with all the customers’ secret sexual fantasies and matching credit card transactions, real names and addresses, and employee documents and emails. The other websites may stay online.”

Established Men is another of the company’s sites; this one is designed to link wealthy men with young and pretty women.

This is yet another instance of organizational doxing:

Dumping an organization’s secret information is going to become increasingly common as individuals realize its effectiveness for whistleblowing and revenge. While some hackers will use journalists to separate the news stories from mere personal information, not all will.

EDITED TO ADD (7/22): I don’t believe they have 37 million users. This type of service will only appeal to a certain socio-economic demographic, and it’s not equivalent to 10% of the US population.

This page claims that 20% of the population of Ottawa is registered. Given that 25% of the population are children, that means it’s 30% of the adult population: 189,000 people. I just don’t believe it.

Posted on July 20, 2015 at 3:15 PMView Comments

1 42 43 44 45 46 78

Sidebar photo of Bruce Schneier by Joe MacInnis.