Entries Tagged "hacking"

Page 73 of 79

Misplacing the Blame in Personal Identity Thefts

Really good article:

In a recent dissection of the connection between gaming and violence, the term “folk devil” was used to describe something that can be labeled dangerous in order to assign blame in a case where the causes are complex and unclear. The new paper suggests that hackers have become the folk devils of computer security, stating that “even though the campaign against hackers has successfully cast them as the primary culprits to blame for insecurity in cyberspace, it is not clear that constructing this target for blame has improved the security of personal digital records.”

Part of this argument is based on the contention that many of the criminal groups that engage in illicit access to records are culturally distinct from the hacker community and that the hacker community proper is composed of a number of subcultures, some of which may access personal data without distributing it.

But, even if a more liberal definition of hacker is allowed, they still account for far less than half of the data losses. The report states that “60 percent of the incidents involve missing or stolen hardware, insider abuse or theft, administrative error, or accidentally exposing data online.”

Those figures come from analyzing the data while eliminating a single event, the compromise of 1.6 billion records at Axciom. The Axciom data loss is informative, as it reveals how what could be categorized as a hack involves institutional negligence. The records stolen from the company were taken by an employee that had access to Axciom servers in order to upload data. That employee gained download access because Axciom set the same passwords for both types of access.

Posted on March 23, 2007 at 10:29 AMView Comments

Interview with Sandia Whistleblower

Interesting interview with Shawn Carpenter, the Sandia National Labs whistleblower who just won a $4.3 million lawsuit for wrongful termination.

What prompted you to conduct that independent investigation into the Sandia intrusion in the first place? As a network intrusion detection analyst, I regularly used similar “back-hacking” techniques in the past to recover stolen Sandia password files and retrieve evidence to assist in system and network compromise investigations.

We were able to better defend our networks as a direct result of the intelligence we gained. I authored in-depth analyses of these intrusions that were sent for reporting and educational purposes to the Department of Energy’s (DOE) Computer Incident Advisory Capability (CIAC), investigators at the DOE Inspector General (IG), Sandia Counterintelligence, DOE Cyber Counterintelligence, Sandia IT management and my entire department. Even to a novice, it was obvious after reading the analyses how intelligence was gleaned on the adversaries.

For example, phrases substantially similar to this were used in my reports: “I used their credentials to access the systems in Brazil and China, identify their hacking tool caches, and [pulling] down all of their tools, e-mails and other information to aid in their identification.” Numerous exhibits of these activities were presented at trial for the jurors. In a meeting with them after the verdict was rendered, even the less cyber-savvy folks understood what the e-mails represented.

What were you hoping to achieve through this investigation? My objective started out with a purpose similar to the other investigations I engaged in while at Sandia. The difference in this instance was that the rabbit hole went much deeper than I imagined.

In late May of 2004, one of my investigations turned up a large cache of stolen sensitive documents hidden on a server in South Korea. In addition to U.S. military information, there were hundreds of pages of detailed schematics and project information marked “Lockheed Martin Proprietary Information ­ Export Controlled” that were associated with the Mars Reconnaissance Orbiter. Ironically, Sandia Corp., the private company that manages Sandia National Laboratories, is a subsidiary of Lockheed Martin Corp. It was this discovery that prompted my meeting with [supervisors] and when I was told that “it was not my concern.” Later, I turned it over to the U.S. Army and the FBI and helped investigate how it was taken and where the path led.

Posted on March 12, 2007 at 6:56 AMView Comments

Drive-By Pharming

Sid Stamm, Zulfikar Ramzan, and Markus Jakobsson have developed a clever, and potentially devastating, attack against home routers.

First, the attacker creates a web page containing a simple piece of malicious JavaScript code. When the page is viewed, the code makes a login attempt into the user’s home broadband router, and then attempts to change its DNS server settings to point to an attacker-controlled DNS server. Once the user’s machine receives the updated DNS settings from the router (after the machine is rebooted) future DNS requests are made to and resolved by the attacker’s DNS server.

And then the attacker basically owns the victim’s web connection.

The main condition for the attack to be successful is that the attacker can guess the router password. This is surprisingly easy, since home routers come with a default password that is uniform and often never changed.

They’ve written proof of concept code that can successfully carry out the steps of the attack on Linksys, D-Link, and NETGEAR home routers. If users change their home broadband router passwords to something difficult to guess, they are safe from this attack.

Additional details (as well as a nifty flash animation illustrating it) can be found here. There’s also a paper on the attack. And there’s a Slashdot thread.

Cisco says that 77 of its routers are vulnerable.

Note that the attack does not require the user to download any malicious software; simply viewing a web page with the malicious JavaScript code is enough.

Posted on February 22, 2007 at 12:40 PMView Comments

Debating Full Disclosure

Full disclosure—the practice of making the details of security vulnerabilities public—is a damned good idea. Public scrutiny is the only reliable way to improve security, while secrecy only makes us less secure.

Unfortunately, secrecy sounds like a good idea. Keeping software vulnerabilities secret, the argument goes, keeps them out of the hands of the hackers (See The Vulnerability Disclosure Game: Are We More Secure?). The problem, according to this position, is less the vulnerability itself and more the information about the vulnerability.

But that assumes that hackers can’t discover vulnerabilities on their own, and that software companies will spend time and money fixing secret vulnerabilities. Both of those assumptions are false. Hackers have proven to be quite adept at discovering secret vulnerabilities, and full disclosure is the only reason vendors routinely patch their systems.

To understand why the second assumption isn’t true, you need to understand the underlying economics. To a software company, vulnerabilities are largely an externality. That is, they affect you—the user—much more than they affect it. A smart vendor treats vulnerabilities less as a software problem, and more as a PR problem. So if we, the user community, want software vendors to patch vulnerabilities, we need to make the PR problem more acute.

Full disclosure does this. Before full disclosure was the norm, researchers would discover vulnerabilities in software and send details to the software companies—who would ignore them, trusting in the security of secrecy. Some would go so far as to threaten the researchers with legal action if they disclosed the vulnerabilities.

Later on, researchers announced that particular vulnerabilities existed, but did not publish details. Software companies would then call the vulnerabilities “theoretical” and deny that they actually existed. Of course, they would still ignore the problems, and occasionally threaten the researcher with legal action. Then, of course, some hacker would create an exploit using the vulnerability—and the company would release a really quick patch, apologize profusely, and then go on to explain that the whole thing was entirely the fault of the evil, vile hackers.

It wasn’t until researchers published complete details of the vulnerabilities that the software companies started fixing them.

Of course, the software companies hated this. They received bad PR every time a vulnerability was made public, and the only way to get some good PR was to quickly release a patch. For a large company like Microsoft, this was very expensive.

So a bunch of software companies, and some security researchers, banded together and invented “responsible disclosure” (See “The Chilling Effect”). The basic idea was that the threat of publishing the vulnerability is almost as good as actually publishing it. A responsible researcher would quietly give the software vendor a head start on patching its software, before releasing the vulnerability to the public.

This was a good idea—and these days it’s normal procedure—but one that was possible only because full disclosure was the norm. And it remains a good idea only as long as full disclosure is the threat.

The moral here doesn’t just apply to software; it’s very general. Public scrutiny is how security improves, whether we’re talking about software or airport security or government counterterrorism measures. Yes, there are trade-offs. Full disclosure means that the bad guys learn about the vulnerability at the same time as the rest of us—unless, of course, they knew about it beforehand—but most of the time the benefits far outweigh the disadvantages.

Secrecy prevents people from accurately assessing their own risk. Secrecy precludes public debate about security, and inhibits security education that leads to improvements. Secrecy doesn’t improve security; it stifles it.

I’d rather have as much information as I can to make an informed decision about security, whether it’s a buying decision about a software product or an election decision about two political parties. I’d rather have the information I need to pressure vendors to improve security.

I don’t want to live in a world where companies can sell me software they know is full of holes or where the government can implement security measures without accountability. I much prefer a world where I have all the information I need to assess and protect my own security.

This essay originally appeared on CSOOnline, as part of a series of essay on the topic. Marcus Ranum wrote against the practice of disclosing vulnerabilities, and Mark Miller of Microsoft wrote in favor of responsible disclosure. These are on-line-only sidebars to a very interesting article in CSO Magazine, “The Chilling Effect,” about the confluence of forces that are making it harder to research and disclose vulnerabilities in web-based software:

“Laws say you can’t access computers without permission,” she [attorney Jennifer Granick] explains. “Permission on a website is implied. So far, we’ve relied on that. The Internet couldn’t work if you had to get permission every time you wanted to access something. But what if you’re using a website in a way that’s possible but that the owner didn’t intend? The question is whether the law prohibits you from exploring all the ways a website works,” including through vulnerabilities.

All the links are worth reading in full.

A Simplified Chinese translation by Xin LI is available on Delphij’s Chaos.

Posted on January 23, 2007 at 6:45 AMView Comments

The Problem with "Hiring Hackers"

The Communications Director for Montana’s Congressman Denny Rehberg solicited “hackers” to break into the computer system at Texas Christian University and change his grades (so they would look better when he eventually ran for office, I presume). The hackers posted the email exchange instead. Very funny:

First, let’s be clear. You are soliciting me to break the law and hack into a computer across state lines. That is a federal offense and multiple felonies. Obviously I can’t trust anyone and everyone that mails such a request, you might be an FBI agent, right?

So, I need three things to make this happen:

1. A picture of a squirrel or pigeon on your campus. One close-up, one with background that shows buildings, a sign, or something to indicate you are standing on the campus.

2. The information I mentioned so I can find the records once I get into the database.

3. Some idea of what I get for all my trouble.

Posted on December 27, 2006 at 1:40 PMView Comments

Major Privacy Breach at UCLA

Hackers have gained access to a database containing personal information on 800,000 current and former UCLA students.

This is barely worth writing about: yet another database attack exposing personal information. My guess is that everyone in the U.S. has been the victim of at least one of these already. But there was a particular section of the article that caught my eye:

Jim Davis, UCLA’s associate vice chancellor for information technology, described the attack as sophisticated, saying it used a program designed to exploit a flaw in a single software application among the many hundreds used throughout the Westwood campus.

“An attacker found one small vulnerability and was able to exploit it, and then cover their tracks,” Davis said.

It worries me that the associate vice chancellor for information technology doesn’t understand that all attacks work like that.

Posted on December 13, 2006 at 6:43 AMView Comments

1 71 72 73 74 75 79

Sidebar photo of Bruce Schneier by Joe MacInnis.