White Wolf Security

Shmoocon5: Hack or Halo

Shmoocon was a little over a week ago but I wanted to wait until we got all the materials together before I wrote up this post. This year, like last year, White Wolf provided some hardware and bandwidth for the Hack or Halo Competition. The competition went amazingly well for all involved, both in pre-game setup and execution thanks to the awesome HoH crew that never fail to deliver amazing results.

Registration

For those that may participate in next year's competition, registration went extremely fast this year. Last year we filled all our available slots an hour or two before the competition (which is at the end of the 2nd day of the con). This year we had all spots filled and were into the waiting list by the end of the 1st day, which is absolutely incredible.

The Halo tournament has a hard limit on number of spaces based on XBox space and the amount of time we want the competition to run. So there are 64 spaces total for Halo, which gives a first tier of 8 games with 8 players. The competition was run this year with the top half of each round moving on to the next tier (so in Round 1 the top 4 players from that game moved on). Chris, Kymberlee and Mike ran everything extremely efficiently. 5 minute rounds, 2 minutes in between to set up the next round (which helps account fo the strange round times given).

The Hack tournament had a somewhat arbitrary limit of 40 players set, based on what we originally thought were network switch space limitations. It turned out we had a lot more space than initially planned for, so after a quick network reconfiguration and some debugging (Remember: if you run NMap as an unprivileged user it defaults to a TCP 3-way handshake, instead of an ICMP ECHO request. Always run your NMap scans as root.) we opened up to the competition to anybody who wanted to play.

Since we hadn't planned to accomodate that many people originally, the Hack space got a little crowded (sorry, guys), and really became an insane hazard of jumbled chairs and network cables strewn wherever there was room.

Competition

The actual competitions went very smoothly. Prizes this year were a netbook for the Halo winner and an XBox360 for the Hack winner (with the logic being, if you win the Halo competition you probably already have an XBox, and if you win the Hack competition you probably already have a laptop. QED). But as a special addition this year the resident HoH artist (Mike Goffin) customized both the netbook and the XBox with a Hack or Halo logo (Mike is also the guy that designs the posters each year, as well as the Hack or Halo tshirt and the stickers), which turned out absolutely awesome.

The Hack competition had a number of new puzzles this year, hopefully offering a little something for everyone. Everything from physical security (lock picking, social engineering) to web app security (XSS, CSRF) to Reverse Engineering was included for a total of 16 puzzles to try and complete in the 2 hours of the competition (the winning team finished 15, but couldn't quite get the last reverse engineering puzzle before time ran out).

The social engineering task (use a VoIP phone to call a "secretary" and convince her to let you in the door) turned out to be a hilarious task, slightly evocative of a Family Guy scene... Something about having Heise (a 6' tall guy with a mohawk) speaking in falsetto to imitate a secretary is simultaneously hilarious and wrong.

Associated Links

Thanks to the entire Hack or Halo crew for helping put everything together (Chris, Kymberlee, Mike, Heise, Fotios, Jordan, Wes and Gentoo), and especially thanks to all the participants for making HoH incredibly successful and fun. We'll try and re-think how we handle seating for all the participants next year, but if you have any other comments or suggestions for improvement please head over to the Hack or Halo blog and leave comments (or email one of the HoH crew).

• Pictures from Shmoocon (from Carson, the official con photographer)
• All the files from Hack or Halo (the VM that was running the puzzles, the clues and answers to the puzzles, and the introduction and background letters)
• The official Hack or Halo Blog

CCDC `09 - Regional Qualifiers

We held the 2 rounds of regional qualifiers at our facility January 17th and 24th. Interest in the competition has been steadily increasing over the last few years, so we've had to break the competition down into two 1-day competitions to accommodate the additional participating universities. Each 1-day event pitted the teams of four universities against one another, with the top two teams advancing to the next round (the national qualifier held in March).

The rules of the competition are fairly simple. Each team of students inherits a network to defend. The students are given a list of the operating systems and services they'll have to administer and defend during the competition. The teams are scored based on 4 criteria:

1. the ability to defend themselves from the hackers (aka the Red Team)
2. the ability to complete business injects
3. the ability to gather information about, and respond to, known intrusions (incident response)
4. the ability to maintain the availability and integrity of their business services

These criteria are scored in various ways: some manual, some automated and some a combination of both. In the end, the two teams that do best across all 4 scoring categories are invited back to participate in the next round.

The Infrastructure

The team's infrastructure was kept very similar to the regional competition of last year. Each time (of up to 8 students) was tasked with administrating and defending:

• A Cisco firewall
• A network-enabled security camera
• An Asterisk PBX Server and 2 VoIP phones
• A server running Nagios, as their out-of-band test system
• 6 servers (3 Windows, 3 Linux) running various versions of the operating system, comprising the fictional business's core infrastructure. This includes an Active Directory server, mail server, primary and secondary DNS, a web server, database server and a Human Resource management server

The Blue Teams

Because of the short length of the exercise (the competition ran from around 9AM to around 5PM) the teams weren't given any lead time ahead of the Red Team. At 9AM the teams were allowed onto the systems and had to move quickly to identify systems and services and begin working the plans that they had come up with in the weeks leading up to the competition.

In some cases plans were executed and worked well, in other cases plans changed on the fly based on the environment that the students found, and in all cases the Red Team's hacking activities made plans obsolete quickly. It's difficult to keep up the intensity required to defend a network that is consistently under attack for 8 hours, especially when you're aware that your network has been penetrated and you're still trying to do all the other things being asked of you, but the participating teams always manage admirably.

The goal of the Mid-Atlantic CCDC is not to present a true-to-life realistic scenario for the students, but to drop them right into the middle of a worst-case scenario, and see which teams can organize under pressure and rise to the top. Given those constraints: 8 hours is a long, long day.

During the After Action Review (AAR) the teams discussed the strategies they began the day with, and which ones were effective or not. Many teams started the day with strategies of immediately applying OS patches to defend against known vulnerabilities. This strategy frequently didn't work due to shared bandwidth issues (4 teams attempting to pull hundreds of megabytes of updates through one shared Internet pipe), which meant that often teams were waiting 60 minutes or more to get patches in place, while their systems were under attack.

One team came to play with only 2 members and did extremely well. One was a Linux expert, one a Windows expert, so they split the systems in half by OS and focused only on their area of expertise. Their strategy was to completely ignore business injects (the tasks given to teams to simulate everyday business requests, such as password changes and new account creation) and focus only on keeping their required services up and running correctly. This team did amazingly well. Sadly, the weighted nature of the scoring means that abandoning one part of the competition completely makes it unlikely to move on to the next round. If they had just one more person to handle administrative tasks, though...

The Red Team

As the size and number of the blue teams increases the red team is always there to match. This year had our largest number of hackers so far (17 hackers showed up for the January 17th date). Our hackers included professional government penetration testers, university professors and students, security professionals as well as just plain hobbyists and enthusiasts. This year also had a few blue team members from previous years that have since graduated, but decided to come back and join in on the fun from the other side.

The Red Team's lair can always be identified by the low overhead lighting, disproportionate number of LCD screens to people, War Games (or Hackers) being played on an overhead projector and, of course, the periodic laughter when something goes incredibly right. There were the usual fun pranks: cancelling patch installs and system reboots and remotely initiating Windows Vista installs. But there were also some new pranks tried out, like replacing the logo on VoIP phones, and the accidental destruction of a VMWare config file (oops).

These 1-day exercises are always fast-paced and usually have a few surprises throughout them, but they're always a lot of fun. Pictures from the event can be found on our website, and further information about the competition can be found on the National CCDC homepage.

Hacking Your Own VMWare Single Sign-On (SSO)

One of our current projects involves using VMWare Infrastructure (specifically ESXi Server and VirtualCenter) to create a large number of VMs for users to log into and test out our educational environment without the hassle of traveling to our office just to see what we're talking about.

We put the entire infrastructure behind an SSL-VPN which made it simple to sync with our Windows Active Directory backend, so far so good. VMWare's VirtualCenter also makes it very simple to generate URLs to interface with a virtual machine through a web browser, but VMWare doesn't provide a method of interfacing with a VM from within the web browser, which means that after a user has logged in through the SSL-VPN they have to type in their (same) credentials again to gain access to the console of the virtual machine.

While this isn't really a problem, per se, it is very annoying. It's even more annoying when you're doing testing and have to keep typing the same username and password (in pairs) every time you change something and want to log in again. VMWare's recommendation is to use an SSO Broker service, such as Leostream, which will transparently handle all the Single Sign-On details for you. While an SSO Broker is definitely an option, it seems a bit of overkill for what I'm trying to do, and also adds cost to project which I'm trying to avoid.

So I decided to make my own Single Sign-On method using the VMWare Perl SDK, PHP and jQuery.

Background

I'll explain a little about the environment I was working in to make it easy to know if this kind of thing will work with your own VMWare project.

The entire VMWare environment is behind an SSL-VPN, which means that when users browse to the page they are presented with a username/password prompt and they must log in. Once the user is authenticated I capture and store their username and password in the PHP SESSION. I'm sure there are more secure ways to do this, but this was the most direct path to a solution so it's the way I chose.

After logging in users are transferred to a portal page. I'm actually using 2 pages for the users:

1. a page that lists the VMs currently assigned to them (using the VMWare Perl SDK)
2. a page with various pieces of educational information, that has the virtual machine embedded in an <iframe>

The users are first sent to a portal page, which generates the VirtualCenter URLs needed to access the console through a web browser. Once the user clicks on one of the virtual machines they're sent to the next page which has the console URL embedded in an iframe called embeddedVM.

Client-Side Code

Here's the main part of the necessary code:

	<script type="text/javascript">
		$(window).load(function() {
			$("#embeddedVM").contents().find("input[name^='userName']").val("<?php echo $username; ?>");
			$("#embeddedVM").contents().find("input[name^='userPassword']").val("<?php echo $password; ?>");
			$("#embeddedVM").contents().find("input[name^='btnSubmit']").click();
		});
	</script>

Most jQuery users are probably used to using the $(document).ready() line to start out your scripts. Since the embedded virtual machine is actually a Java applet, we have to wait until the entire window is finished loading to know that all the elements are in place. Attempting to run the next lines before everything is loaded doesn't work.

• embeddedVM is the id of my iframe, the quotes and # are necessary parts of the jQuery selector
• contents() returns the HTML inside embeddedVM
• find() allows us to search through the returned HTML for certain tags
• input[name^='userName'] is a regular expression, search for any input elements that contain the phrase "userName"
• .val() allows us to set the value of the selected field. In this case I use PHP to output the $username and $password variables extracted earlier
• .click() is used in the final statement to actually click the "submit" button to log in to the VM

The above code will cause the username and password entered initially to be filled in to the VMWare form and submitted, automatically logging the user in. Because it's all done dynamically, and client-side, users will notice a quick flash where their username will appear on the screen before the page reloads. This is fairly minor, but I didn't want our users to be confused if they started to fill in the form and then it automatically submits (especially if they're on a slower connection) with no feedback as to what's happening.

The final step I took is using a jQuery plugin called BlockUI to block input to the iframe for a set amount of time to give the user some idea of what's happening. BlockUI will create an overlay, with an optional message, over a page, or certain areas of a page. My embeddedVM is inside a div called vmContainer.

My final code looks like this:

	<script type="text/javascript">
		$(document).ready(function() {
			$("#vmContainer").block({
				message: '<h1>Please wait...</h1>'
			});
		});

		$(window).load(function() {
			$("#embeddedVM").contents().find("input[name^='userName']").val("<?php echo $username; ?>");
			$("#embeddedVM").contents().find("input[name^='userPassword']").val("<?php echo $password; ?>");
			$("#embeddedVM").contents().find("input[name^='btnSubmit']").click();
			setTimeout($("#vmContainer").unblock(), 5000);
		});
	</script>

This code blocks the vmContainer div with a message reading "Please wait..." as soon as all the page elements are in place. Once the window finishes loading, our script inputs the username and password, submits the form, then waits 5 seconds and removes the block. 5 seconds is an arbitrary number but, in testing with our setup, 5 seconds was more than enough time to allow the applet to appear and start loading, so the users had a good idea that something was happening.

I am not a VMWare or jQuery expert, so if you've done this in a simpler way (or know of a more efficient way to write that code), please feel free to leave a comment.

Desperately Seeking Secrecy

Privacy on the Internet has always been a hot topic, whether you're discussing political dissidents using Tor to talk freely about their governments or about Facebook users worried about invasive advertising. As more and more personal information is put online (or sent into the cloud) there are always discussions about the erosion of personal privacy rights or the dilution of personal space. Those metaphors imply slow and progressive change, but with new techniques and research technologies it may turn out that traditional privacy rights have instead undergone sublimation, and are already slowly drifting on the wind.

The New York Times published this article last week on a group called the MIT Media Lab and a project they call Reality Mining. Reality Mining is a more specific form of data mining that uses massive amounts of data points from real people to learn about behaviors and trends within groups of people. From the Media Lab's home page:

Reality Mining defines the collection of machine-sensed environmental data pertaining to human social behavior. This new paradigm of data mining makes possible the modeling of conversation context, proximity sensing, and temporospatial location throughout large communities of individuals. Mobile phones (and similarly innocuous devices) are used for data collection, opening social network analysis to new methods of empirical stochastic modeling.

Pulling Data From All Around Us

Reality Mining takes advantage of the, now ubiquitous, mobile phone to study human behavior. In their current project the Media Lab traded 100 MIT students a brand new smartphone in exchange for complete transparency in their life: who the students talk to, what music they listen to, what applications they use on the phone and how they use them. In short, everything. The students are all assured that the data collected will be anonymized to protect their identity before being released.

Many people are willing to trade their privacy for certain benefits, for example giving up details about your personal life on a site like Myspace or Facebook in order to better stay in contact with old friends. Many people are also willing to trade certain rights in the interests of science, that is to participate in a study, and this study is certainly audacious. From the Reality Mining page:

The Reality Mining project represents the largest mobile phone experiment ever attempted in academia. We are collecting an unprecedented amount of data on human behavior and group interactions that we plan on anonymizing and making available to the general academic community. By the end of the experiment, this dataset will contain over 500,000 hours (~60 years) of continuous data on daily human behavior. Already we have been approached by over a dozen of researchers in a wide range of fields (including epidemiology, sociology, physics, artificial intelligence, and organizational behavior) who are extremely eager to see how this unique data can answer questions from their own discipline.

500,000 hours of continuous data. But let's go back to that promise. All information is scrubbed before being passed on, so there's no way of determining an individual's actions based on their usage, and individual privacy is preserved. But that seems to be something of a catch-22. These experiments are meant to study a person's actions to see how predictable they are, if it turns out their actions are extremely predictable, then I'll be able to identify a person based solely on their habits, given reasonable data and reasonable resources.

How about a practical example? In late 2006 AOL, in an attempt to reach out to the academic community, released an anonymized set of searches made through their service. The goal was to give academic researchers the chance to crunch some numbers on some real search data. The data released covered 20 million searches from 658,000 users, or an average of 30.39 searches per user. And, as it turns out, you can identify individuals by name from anonymized searches.

Privacy Tradeoffs

Of course, this is only relevant if the benefits to society are less than the damage that could be done by a loss of personal privacy. Dr. Thomas Malone, director of MIT's Center for Collective Intelligence, comments at the end of the article:

"For most of human history, people have lived in small tribes where everything they did was known by everyone they knew,” Dr. Malone said. “In some sense we’re becoming a global village. Privacy may turn out to have become an anomaly."

I'm not an expert in sociology, so I hope this comment is in line, this seems like a textbook example of the naturalistic fallacy. Paraphrasing from the Wikipedia page on the naturalistic fallacy: "what is natural is inherently good or right, and that what is unnatural is bad or wrong". The implication from the statement seems to be that privacy is a very recent phenomenon, something that hasn't existed long and therefore shouldn't be expected.

For most of human history humanity, as we know it, hasn't existed, and it changes all the time. You could take that as a point for either side of the argument, but if we're truly becoming a global village, that is a single village with 6.4 billion people in it, that makes me desire my own personal privacy all the more. The idea of privacy is to give people their own space, a small piece of calm refuge from the outside world, whether that world is a village or a metropolis (or a modern-day superposition of both).

And while privacy is certainly a recent creation, the idea has certainly been around for some time. Stanford's Encyclopedia of Philosophy page on Privacy (and critiques of privacy) lists Aristotle's writings as the first major work on privacy, in which he separates the "public sphere of politics and political activity, the polis, and the private or domestic sphere of the family, the oikos, as two distinct spheres of life".

Societal Benefits

Dr. Alex Pentland, of MIT's Media Lab, leans more heavily on the benefit that can be taken from these large data mining projects, while still trying to protect a user's privacy:

DR. PENTLAND says there are ways to avoid surveillance-society pitfalls that lurk in the technology. For the commercial use of such information, he has proposed a set of principles derived from English common law to guarantee that people have ownership rights to data about their behavior. The idea revolves around three principles: that you have a right to possess your own data, that you control the data that is collected about you, and that you can destroy, remove or redeploy your data as you wish.

...

Citing the epidemic involving severe acute respiratory syndrome, or SARS, in recent years, he said technology would have helped health officials watch the movement of infected people as it happened, providing an opportunity to limit the spread of the disease.

“If I could have looked at the cellphone records, it could have been stopped that morning rather than a couple of weeks later,” he said. “I’m sorry, that trumps minute concerns about privacy.”

Infectious disease tracking seems to be one of the more immediate uses of tracking individual movements and actions within a population. Using search trends Google released a new tool several weeks ago called Google Flu Trends. It turns out that you can track the flu and, presumably, other diseases as well based on what people are searching for in a given area.

The only real concern is with the final quote. When we're talking about other people's cellphone records and other people's personal data, privacy concerns always seem minute. English Common Law principles don't apply to the massively digital world we've created today. The right to possess your own data and data that is collected about you relies on the implicit assumption that you know data is being collected about you.

Over the past several years surveillance, whether in the form of video cameras or online click-tracking, has increased considerably. Most people have no idea what information they're sending to remote webservers, and what databases that data gets entered into or where that data goes. To think of the amount of time it would take to try and track down companies that collect information online to request data about yourself is mind boggling. Every website you visit has pieces of information about you: IP address, operating system, browser, what other sites you've visited recently, etc.

In a world where massive data mining and statistical research work to peer into the seemingly inscrutable, a system of explicit opt-out doesn't seem like it would have any benefit for personal privacy whatsoever. Though, if the choice is between a person's privacy and a person's life, in the form of stopping the early spread of a disease, who's to say that privacy is worth the trade?

UK Hospital Operational After Virus Outbreak

Alright, yes, it was a computer virus outbreak that infected the hospital network. And yes, the hospital network was disconnected by the administrators to prevent further spreading of the problem. But this seemed like the perfect story for a sensationalist headline, and I decided to take it.

Three hospitals in London, St. Bartholomew's, the Royal London Hospital and the London Chest Hospital had their networks shut down earlier in the week after detection of a virus outbreak. Over the past few days the IT staff has been slowly bringing key systems and departments back online as they can be secured. Initially the staff thought they had it contained, but it turned out to be worse than they thought, crashing systems when doctors and staff tried to log on to systems, prompting to more drastic shutdown and disconnection.

The entire story, with many more details, is available here. Luckily for the hospital it looks like their disaster recovery planning has actually gone pretty well. According to the story the operations of the hospitals have continued mostly unaffected throughout the network outage, and it's taken the staff 2-3 days to bring key parts of all 3 hospitals back online. Although there is one thing that struck me as a little off about the whole thing...

From the article:

A serious computer virus infection at the Trust - later identified as caused by the Mytob worm - was first detected on Monday.

Wait, the Mytob worm is what brought down 3 hospital networks? You mean, this Mytob worm? Mytob primarily spreads via mass mailing. The malware grabs the address book from a Windows computer and sends email with an attachment to everyone in it. The Sophos information page also notes that it can spread using the LSASS vulnerability, a flaw patched in Windows 4 years ago. I think I know why that disaster recovery plan was locked down so tight.

This is another great example of how hard security is, especially on large networks that must support legacy software, and it's even harder on healthcare networks that have a huge amount of specialized hardware installed on them. If nothing else, the hospitals are in good company, the Wikipedia page on the Zotob worm (a Mytob variant that spreads via a Microsoft flaw patched in 2005) quotes a Businessweek article that lists ABC, CNN, AP, the New York Times and Caterpillar, Inc. as companies being hit by this worm (all of whom, presumable, have larger IT security budgets than a UK hospital group).

And, speaking of being in the company of larger budgets, news also came out today about a worm that's been spreading across military networks. All the details are still classified, so we don't know what worm or anything else about it, except that the DoD has taken the drastic step of banning all external media from the network (everything from thumb drives to burned CDs and DVDs). It's really easy to get viruses into a network, really hard to get them out, and it only takes one mistake to open the door. Defense-in-depth and compartmentalization are great strategies, but they're also expensive to implement, difficult to implement well, and a determined user can usually outmaneuver the systems.

Also, as an interesting side note, a frequent solution to these kinds of problems, both by lawmakers and non-security people, is that we need tougher legislation or new laws to handle these kinds of things. In the case of the Mytob and Zotob worms, the creators were both arrested after the fact. While law enforcement takes some time to work, even if they were arrested the day after the worms were released (or the hour after, for that matter), it wouldn't have mattered.

Once the worm is on the network, it's a feeding frenzy. A pathology-mimicking performance with the new code playing the part of the biological attacker seeking the machines with no defenses prepared, and system administrators playing the role of evolution, trying to keep their systems working against the onslaught of malicious code. Just like in the real world the viruses don't get tired, they just try and replicate using whatever is in reach, whether the vulnerability is 4 days or 4 years old. And even when the systems are patched and everything seems safe, it just takes one email attachment to bring the attacker inside, and it all starts again.

I'm not sure exactly what the solution to these problems is, but I'm pretty sure it has less to do with the "new legislation" method and more to do with the "disaster recovery" method the hospitals used: having trained, professional people on hand to put things back together when they all fall apart.

Hackers Gain New Ally In Their Semantic War

About a month ago I wrote about Sarah Palin's Yahoo! email account getting hacked. Police found a suspect fairly quickly and arrested a University of Tennessee student, on suspicion of committing the crime. An article over at The Register today details a new filing made by the defense attorneys in the case, specifically, that their client not be referred to by the misleading term "hacker".

There are 2 interesting things of note in this case: one of them comes from the article, and the other comes from the comments on the article. For years a semantic war has raged over the true definition of the word "hacker". On one side you have the legions of the tech-savvy, fighting to uphold the good name of their good word. On the other side are the laypersons, who don't understand the rich history of the term, that are potentially brainwashed by media outlets telling them of the dangers of hackers.

To understand why, we'll have to take a look back into the before-time, in the long long ago of the 1960s...

Brief History

As far back as the 1960s a culture of "hacking" had emerged at prestigious institutions like MIT. These people thought of themselves as hackers, and their main focus was on solving problems in creative ways. At this point the term hacker was almost synonymous with "free thinker" and "problem solver". Seeing these people as role models, other people adopted the term.

As the 1980s and 1990s came around the hacker culture had expanded. More and more people started to have home computers and wanted in on the hacker culture. So now computer hobbyists, and enthusiasts in general, considered themselves hackers. They, too, found creative solutions to problems and found interesting ways of putting together various hardware components. Hacking no longer meant "free thinker", the term had evolved to mean "computer expert".

Because computer enthusiasts also frequently wrote code, the term hacker also became linked to coders, specifically clever coding. It's one thing to take code from a book on coding and tweak it slightly to do what you want, but to do something different or original or novel with code, now that's hacking. Linus Torvalds and Bill Gates were hackers, what you do in an Introduction to Programming class certainly is not.

As the mid-1990s came around, and Microsoft helped set off a PC revolution, the barrier to entry for owning a computer was significantly lowered. Many people had no idea about the culture of hacking. For many people what they had purchased was a black box full of magic. They knew enough to write documents and play games, but not enough to know why these things worked, because the answers to those questions is deep magic. And who are the people who can control the deep magic? Only the hackers.

And as the Internet swept across the planet, and things like identity theft became rampant, the only people that had the knowledge to make computers do their bidding was the dreaded hacker.

Back to the Present

The term "hacker" has evolved considerably since its creation 50 years ago. Searching around the Internet (or reading the comments in that article) is enough to show that the battle is still going strong. Purists maintain that hackers, by definition, are not malicious. A hacker, by their definition, is simply an intelligent person that finds clever and novel solutions to problems. Along the same lines they use the term "cracker" to define a malicious hacker that uses their skills to break into computer systems.

A couple of my friends in college would constantly argue over this point. On one hand, by the original definition of the word, breaking into a computer system doesn't make you a hacker, it makes you a cracker. On the other hand, the definition of words is dictated by their popular usage; the meaning of words frequently changes as the people that use the word change. Over the past several years society at large has taken the definition of hacking to mean the more negative "someone that breaks into computers", and it's tough to fight it when all the major news networks and a lot of bloggers use it that way on a daily basis.

Back to the Article

But in any case, the motion mentioned in the article is for the defendant not to be referred to as a "hacker" and for his actions not to be referred to as "hacking" (even by witnesses), because of the negative connotation associated with the words. While it might seem a little strange to make this request, it's not unprecedented. "Hacking" isn't actually illegal in the United States, "unauthorized access to a restricted computer" is the crime that (I believe) he's being tried for. In this context it doesn't really make sense to use a word that probably amounts to a slang term in the courtroom.

The important thing is this: if you hold the opinion that there's nothing wrong with being a hacker then, as the title implies, you've got yourself a new ally. And when it comes to arguments dealing with semantics, they're second to none.

Cyber War is Bullshit is Bullshit

Last week, at the Hack in the Box: Malaysia conference, Marcus Ranum, CSO of Tenable Network Security, gave a keynote speech titled "Cyber War is Bullshit". Slides from the speech [pdf] are available from the HITB materials page. To be fair I wasn't actually at the speech so everything I say in the following post is based completely off of those slides and the few quotes that were posted in this article from The Star online (which could end up being very unfair).

The presentation attempts to break down the various forms of cyber "attacks" that can take place across a network. Ranum attempts to clarify the differences between crime, terror and war as they apply to actions on the Internet (cybercrime, cyberterror, cyberwar) or any other network. He also draws out a piece of cyberwar specifically for digital spies (cyber-espionage). The crux of the presentation seems to be that cyberwar is so ineffective and far-fetched that spending money on researching it is beyond a waste of that money, which could be used for conventional warfare research. His argument is that the cost is so high, and the return on investment so low, that cyberwar has no substance, and that cyberwar is utterly useless because the only people using these tactics are the people that would win a conventional conflict anyway.

Ranum's argument is based on 5 paradoxes he's identified in the underlying concepts of cyberwar. I've written about aspects of cyberwar on this blog before, but I'm not above saying that it's bullshit. In fact I think that much of what many people envision in cyberwar is more bullshit than not, and much more centered in science fiction than reality. While I respect Mr. Ranum's achievements and technical knowledge, I think he's completely missed the mark on the military aspect here.

Paradoxes

par*a*dox [par-uh-doks] - noun:

1. a statement or proposition that seems self-contradictory or absurd but in reality expresses a possible truth.
2. a self-contradictory and false proposition.
3. any person, thing, or situation exhibiting an apparently contradictory nature.
4. an opinion or statement contrary to commonly accepted opinion.

Ranum's Paradoxes

1. The disarmament effect
2. The cost factor
3. Packets don't hold ground
4. The "Blind Mike Tyson Effect"
5. The "who'd win anyhow" question

Common usage tends to lean toward the 3rd definition in the list above so, I think, is that each of these things exhibits an aspect that is inherently contradictory to what cyberwar attempts to achieve.

The Disarmament Effect

From the presentation:

• The disarmament effect
  • Imagine what happens if you're the commandant of the cyber-strike force
  • ...and D-Day is patch Tuesday?

I'm sure the last line was said to be somewhat humorous, but the point is still valid: cyberwar depends on exploiting software vulnerabilities in your targets. If you go to launch an attack and, suddenly, you realize that the target's machines are patched and your attack is ineffective then what do you do?

Of course, this happens in conventional warfare, as well. What if you send a special forces team in to an area to demo a building, and it turns out there are 50 guards instead of 15? Are special forces teams an ineffective warfare option because they aren't 100% effective against all targets? What if you call in an airstrike on an area that's been called secure and someone in the area has a Stinger? Does this make aircraft a useless warfare accessory?

Tactical warfare operations aren't static. Troops aren't fire-and-forget. Missions are drafted, people are sent to complete the mission, and if variables within that mission change then the mission can be adapted to fit the new scenario or the mission can be aborted, and nobody has to know.

The Cost Factor

From the presentation:

• To attack a network, you have to have effective management control over it (unless you’re just DOSsing it, in which case your attack may be deflectable)
  • Therefore: cyberwar == involuntary remote system administration
  • So, we need, what, a combat version of UniCenter? See where this is going?

I think the real problem I have with the main bullet point is the word "effective". To attack a network you certainly have to have management control over it, but his other points seem to evoke other ideas like reliable and consistent. Involuntary remote system administration is just a euphemism for gaining access, and the effectiveness of my control depends on my objective. I don't need complete control over an asset to take action on it.

We completed ICE II (a cyber exercise) in Las Vegas a couple weeks ago. We put 50 hackers (over the course of the game) into a room, gave them target networks and told them that were no rules. Over 3 nights the Red Cell generated 120 billion events on a commercial IDS sensor. Hackers got in numerous times and defending teams scrambled to shore up their systems. When the hackers got in did they have effective system control? Frequently they didn't even know what they had, they launched blanket attacks to hit any and every target they could reach.

ICE II isn't a vision of cyberwar, it's more a look at what Georgia or Estonia saw from Russian hackers, but even with all the chaos the attackers still stole database information, shut down services, and rebooted systems at will. All without anything resembling consistent or reliable control of the systems.

Packets Don't Hold Ground

From the presentation:

• Before an attack is launched it needs to fulfil some useful military objective (to take or hold ground or destroy physical materials)
  • Taking and holding ground implies tactical and strategic superiority for the follow-through
  • Therefore cyberwar only makes sense to the side that is likely to win anyhow

Attacks need to fulfill some useful military object: True. The only useful military objectives are taking or holding ground or destroying physical materials: False.

A raid is a military operation that has no intention of holding ground. A raid uses troops to move into a location, complete an objective, then leave the location. Are those troops taking ground? In an extremely literal sense, but not in the tactical meaning of "taking ground". Are they destroying physical objects? They could be, or they could also be rescuing a hostage, for example Jessica Lynch. Her rescue was a raid by special operations forces, an operation that took or held no ground and didn't destroy physical materials.

In 1998 Bill Clinton ordered a bombing campaign against sites in Afghanistan and Sudan in retaliation for embassy bombings in Kenya and Tanzania. These strikes were all done with cruise missiles launched from ships. While the missiles did destroy physical materials I would argue that the tactical purpose was as a message to terrorists. And these missiles were not as a precursor to a ground assault, so while they demonstrated tactical superiority, the US never had any intention of invading after the strikes.

The "Blind Mike Tyson Effect"

From the presentation:

• Many proponents of cyberwar propose it could be used to temporarily degrade an enemy’s command/control or intelligence for tactical advantage
  • Blinding a superpower, even temporarily, invites a massive fear-triggered response
    • "Blind me, I nuke you."
  • This option only makes sense to the side that is likely to win anyhow

Not to argue semantics, or be pedantic, but command and control (C2) is an old term for the military's command infrastructure. The current command concept is C4ISR: Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance. The military has evolved their command concepts to include communications between nodes, the computers that run everything, intelligence from various sources, surveillance from satellites and drones and reconnaissance from troops on the ground. Each piece of C4ISR is important to coordinating and commanding a modern military.

If the "Blind Mike Tyson" hypothesis were true then the United States would currently be at war with China, Iran, North Korea, Syria, Venezuela and probably several other countries. North Korea sent out weapons inspectors, openly declared they were developing nuclear weapons and launched test rockets, towards one of our allies, into the Sea of Japan. The US response was diplomatic pressure and negotiations.

Thomas Wingfield, in his paper "An Introduction to Legal Aspects of Operations in Cyberspace" [pdf], explains a number of the issues surrounding offensive operations in cyberspace and the transition from cyber to physical conflict.

From the paper:

The first of these questions has been problematic for quite some time.  Until recently, the consensus among top legal scholars in the US and abroad was that a quantitative approach to cyber-warfare made the most sense.  That is, when evaluating whether an information operation rose to the level of a use of force or armed attack, one should disregard the means and focus exclusively on the ends.  Whether an oil refinery is set ablaze from a one-ton bomb or from a line of malicious computer code doesn’t matter.  A flaming refinery, they concluded, is a flaming refinery.  Any cyber-attack that causes damage indistinguishable from a kinetic attack should be legally indistinguishable as well.

...

Once the determination has been made that a state of de facto hostilities do exist and the law of armed conflict does apply, the analysis turns to the four central principles of the law of war:  discrimination, necessity, proportionality, and chivalry.

Considerably more details can be found in the paper but, to stay brief, discrimination means that a commander must differentiate between combatants and non-combatants. Necessity means that an operation can use all the force necessary to complete a mission, but not excessively more. Proportionality means that a commander must balance collateral damage against military advantage. Chivalry simply forbids the use of certain kinds of deception (like launching attacks from vehicles labeled as Red Cross trucks).

And all of that together means that nobody is allowed to get nuked because of some hacker turning off the Internet at the White House and making the President miss an episode of Heroes.

The "who'd win anyhow" question

From the presentation:

• Cyberwar is almost entirely only useful in two situations:

1. a scorched-earth defense, in which the defender just wants to inflict damage as they die
2. by the side that is likely to win anyhow

• This means the US is the most likely to use cyberwar

Cyberwar tactics seem to be effective in several different areas. For one, information gathering about enemies, by gaining access to their networks and looking into their files and information. The difference between cyberespionage and digital reconnaissance is really just who's on the other side of the keyboard.

One of the quotes in the article has Ranum saying that "cyberattacks aren't a good force multiplier in an actual war". Force multipliers are anything that make your force better than a force of similar size. If you're talking about infantry troops then force multipliers can be things like better weapons or better body armor, but can also include things like the weather, the troop's morale, and how afraid the enemy is of him (possibly via psychological operations).

The overall benefit of a force multiplier is based on how much it costs and how effective it is. If it costs a lot and isn't effective then it's bad, if it's cheap and really effective then it's good, and everything else lies somewhere in the middle. For argument's sake let's say that the benefits given to a force by cyberwar tactics are minimal. The cost of cyberwar tactics is extremely low; you have to train troops, spend money on research and development, but after all that it's still inexpensive compared to new and better weapons or armor.

While the benefits and possible future of cyberwar are certainly overblown by a lot of people, I think writing off network attacks against military computer systems as simply superpowers with too much money playing with their toys is equally naive. And given recent news articles I don't even think the US is the most likely to use cyberwar. China and North Korea are probably years ahead of the US when it comes to effectively utilizing cyberspace for military benefit, and the grassroots mobs that have formed during the Russia-Georgia conflict and in Estonia are definitely effective, albeit not physically damaging.

This post has gotten a bit lengthy, so I'll wrap up with a final thought: I hear your claim of bullshit, and I respectfully disagree.

Don't Want To Give Up Your Encryption Keys? That'll Be 2-5

At least in the UK it will be.

According to an article over at LinuxWorld discussing the results of a recent case that found individuals may not deny access to an encryption key under the rights of self-incrimination (or the right to silence, as it's referred to in the UK). The UK court determined that:

...an encryption key is no different than a physical key and exists separately from a person's will.

"The key to the computer equipment is no different to the key to a locked drawer," the court found. "The contents of the drawer exist independently of the suspect; so does the key to it. The contents may or may not be incriminating: the key is neutral."

I've written on this blog before about encryption techniques, as well as the legal standing of compelling encryption keys in the US, but I believe this is the first time the issue has been tested in the UK.

Quick History

I wasn't sure what the legal differences were between the US right to avoid self incrimination (5th Amendment rights) and the UK right to silence. I did some quick research (and had a quick conversation with a lawyer) only to discover that your rights are actually very similar under both sets of laws. The right to remain silent under police investigation under both systems came from police forces using beatings and torture methods to force detainees to talk about alleged crimes. Both sets of self incrimination statutes were instituted to prevent police misconduct in suspect interviews.

The primary difference I found is something UK law refers to as "adverse inferences". Under US criminal law the invocation of 5th Amendment rights cannot be used against a defendant as a sign of guilt. Basically, all that means is that refusing to speak doesn't make you seem any more guilty, it just means you're refusing to speak (hypothetically). In the UK there are certain circumstances where this isn't the case, mostly focusing on a defendant changing their story or refusing to account for things that were present at the time of arrest. In those cases the jury can draw inferences from the defendant's silence (they also may choose not to).

Back To Encryption Keys

The analogy seems fairly sound. If I have a safe, or even a locked desk drawer, in my house and the police show up to arrest me with a valid warrant I can't refuse to give them the key to the desk under the 5th Amendment. There may be physical evidence in the desk, the police have followed due process to be allowed to search it, and the key is a physical object which I cannot refuse to produce. If I do refuse to produce it, then the police will just break the lock (or blowtorch the safe) to search for evidence.

Similarly, encrypted storage is like my safe. My encryption key is like the combination to my safe. The UK court has determined that there is no difference between the safe combination and my encryption key, except in ths case there is. If I refuse to give up my encryption key, there is no "blowtorch option" for the police to use. If I've chosen a long enough encryption key, then the police are out of luck figuring out what I've encrypted.

Therein lies the problem.

Forcing 21st Century Ideas Into 20th Century Shoes

There is plenty of precedent to say that a court shouldn't be able to compel an individual to give up their encryption key. For one, US law says that the court cannot compel a performance. For example, if I enter into a contract to paint someone's house, then I break the contract, the court cannot compel me to paint the house. They can have someone else paint the house and then charge me for that work, but they can't force me to do it. Regardless of analogy, an encryption key (unless written down) is not a physical object. In order to compel the key I must type it or, more likely, tell you what it is or write it down.

For another, what if I have a safe with a built-in tamper mechanism (say an acid safe pouch that disperses if the safe is tampered with)? By refusing to give the combination to police, they will force their way into it, and the acid will destroy any documents within. In that case, you're now going to be charged with destruction of evidence, obstruction of justice or something along those lines.

The real issue at hand is that encryption introduces an unsavory element into criminal investigations. Without a way for police to force their way into encrypted documents they're left with a block of impossible to reach potential evidence. There may be important elements of the case (or other cases) inside, or even evidence of other crimes.

The ruling seems unnecessary to me, as the UK already has laws in place that allow juries to draw adverse inferences about information defendants refuse to divulge. This new ruling merely adds a new punishment for refusing to divulge your encryption keys. It might just seem excessive to me, but a 2-year sentence for refusing to give up a key seems a bit much.

Of course, comments are always welcome.

Ice II Wrap-up

Well, we finally made it back from a long week in Las Vegas. A lot of interesting things happened while we were out there but, most of all, ICE II went extraordinarily well. I don't think the exercise could have run any smoother, the participants were outstanding and everyone seemed to have a great time with it and, hopefully, got something out of it.

For those just getting information about the event now the information page is still available on our site. As soon as we can compile all the logs, reports and photos those will be posted, as well. I'm going to try and keep the writeup of events fairly brief, in an attempt to keep it interesting for those that weren't there to see it. Huge thanks to SANS, for hosting the event and giving us plenty of room and equipment to work with (especially the A/V guys, who willingly ran around finding all sorts of electronic gadgets that I forgot). Special thanks to Larry Pesce and Paul Asadoorian from the Pauldotcom podcast. Larry captained the defending teams while Paul captained the attacking teams, and both took on the unenviable job of organizing a group of participants into an effective IT team. Thanks also to Bill from i-hacked who came out to be a press guy, as well as participating as both an attacker and defender on various nights.

For those interested in a participant's perspective: Paul did a write-up from his perspective as captain of the attacking teams, and Bill did a writeup of his experiences from both sides of the exercise.

** EDIT **: Larry has also posted his experiences as captain of the defending teams.

The Setup

For the event SANS graciously gave us 4 conference rooms in Caesar's Palace for the game. 2 rooms on one side of the hallway and 2 rooms directly across from that. Caesar's Palace also helped us out by setting up VLANs for us on their switches, so we didn't have to run cables across the hallway (although I'm sure no Red Cell guys would ever attempt to mess with the Defenders physical cables in an open hallway...).

On one side of the hallway were the players. Separated by a movable wall, and a few sets of velvet ropes (to keep the spectators from wandering around, as well as to make the players feel downright classy) were the Red and Blue Cells. The Red Cell, our hackers, were stationed on the left, their room generally filled with a sense of calm determination and covered with relaxing techno-beats and beer. For hours on end they attempted to wreak havoc, cause mayhem and generally infuriate the defenders.

On the right side we had the Blue Cell, our defenders. Their room was filled with bustling energy and a lot of movement and covered with the soothing sounds of Whitney Houston (not a joke, though I believe this was psychological warfare against the Red Cell). Imagine that you're in a room with a door that has no lock, and outside are a pack of velociraptors, and you know that, given only a short time, they will learn how to operate the door handle. It was a lot like that. For hours on end they attempted to prevent the wreaking of havoc, deny the causation of mayhem and generally to resist infuriation.

Night 1

As you would expect, the first day was mostly about getting acquainted with the game network. Especially for those that ended up participating on multiple nights, it was all about learning what was in play, as well as what aspects of the networks were easy or difficult (to either attack or defend). Attackers from Core Security and Immunitysec worked with the SANS attendees to break in to machines and cause general havoc. All what you'd expect from a hacking exercise.

The one big event of Night 1 came near the end of game time. As I mentioned above the only barrier between the participants and the outside world was a set of velvet ropes. While velvet ropes are an effective visual barrier, their effectiveness as a physical barrier is wholly restricted to the honor system. Near the end of Night 1 the honor system of the velvet rope broke down into what some might call "simple assault" and I'll refer to here as a "lack of civility". Alright, so it sounds much worse than it actually is. In a fit of gloating Paul came to the Defender's side and hopped the velvet rope, the defenders then euphemistically "requested Paul leave the area", by physically carrying Paul out of the room.

Paul was not amused, and Night 2 began with a strict "No physical contact, not even thumb wrestling" rule.We'll know better for next time.

Night 2

The setup for Night 2 was almost identical to Night 1 with a couple minor additions. First was the addition of a wireless access point to defend (already encrypting traffic with WPA2) as well as the addition of spectator computers. A set of laptops was set up that spectators could use to browse the websites of the teams, as well as VoIP phones that could be used to call the teams if there were problems. These laptops were the source of fun for Night 2.

One of the spectator laptops was connected wirelessly to the defending team's access point. This was our legitimate roaming client. About halfway through the night, once the defender's began to really lock their systems down tight, we allowed the Red Cell to simulate an infected client by running a single executable on the laptop. The Red Cell turned this laptop into a pivot point, using some Immunitysec tools, and started routing attacks through the, now infected, host.

Night 3

On Night 3 we decided to replace their large standard looking access point, with a tiny access point hidden underneath the Defender's table. Let's see if they notice the difference...

Again, after the Defender's really started to lock down their networks we dropped hints to the Red Cell that there might be a hidden "rogue access point" in play. The defender's reactions to this play were especially good. The mini wireless access point has a default IP address of 192.168.1.1, so several defenders watching traffic saw this address but had no idea what it was, and just chalked it up to attackers trying to phone home to an incorrect address. There were about 45 minutes left in the game when the Red Cell got to play with the access point, and at the very end Tim called the defenders on their VoIP phone to tell them where to look for the access point.

We've got some great photos of an entire team of Red Cell members watching Blue Cell guys crawling under a table to try and find this hidden access point.

Wrap-Up

Overall the games went extremely well. We had about 100 participants over all 3 nights (with some repeat offenders) as well as a couple hundred spectators that came through just to watch parts of the game or see what was going on. At a conference with about 950 people, that's pretty impressive numbers for a hacking exercise. To those participants that might be reading this, thanks for making this an awesome exercise and having fun with it. If you attended the conference, or participated in ICE II please leave us some comments, we're always looking for ways to improve the game and the experience for those playing.

And huge thanks go to Fortinet, our IDS Sponsor, for providing IDS/IPS services for the teams, as well as showing traffic analysis and trending for the game traffic in real-time. Awesome stuff, and we hope to see even more people next year!

Warning: Web Proxies May Result in Unexpected Consequences

When teaching classes on network forensics to law enforcement officers there are always a few sections that stick out, to me, due to the reactions they generate: Internet Routing (attempting to explain the difference between an internal IP address here and what a server sees on the other end) and, similarly, Proxies.

For some students just learning about the complexities and intricacies of Internet architecture, discussions of proxy servers and chained proxies is just too much. Conceptually proxy servers are simple, they're simply servers that sit between a user and the Internet (or some other network). The proxy server takes requests from the user and sends them to a server, then receives responses from the server and gives it back to the user. A simple handoff. The real problem comes in trying to explain the method for tracking a user through a proxy, or chain of proxies.

Often students become frustrated; tracking users through multiple proxies in multiple countries seems like a very difficult and insurmountable task. And, certainly, it can be. The advice I give to them usually boils down to this: Don't think about how to find a proxied attacker head-on, because it probably won't work and will take up a lot of time. You're investigating the entire situation, not just this one connection, look at all the other pieces of information you have and narrow other things down, just keep the proxy in the back of your mind for when you've pieced together more of the investigation.

It turns out that, many times, someone using a proxy might make other mistakes that completely negate the benefits of the proxy.

Enter Sarah Palin, Republic Vice Presidential Nominee Extraordinaire.

A couple days ago 2 of Palin's private Yahoo! email accounts were hacked by a group called Anonymous. Anonymous has gained Internet notoriety over the past year for it's crusade against Scientology. Anonymous has hacked into numerous Scientology websites releasing internal documents and mail, as well as creating grass roots rallies against Scientology in a number of major cities around the world. And now, they've decided to take a shot at Governor Palin.

After the email accounts were compromised, the login details were posted to a popular underground message board site called 4chan. A user, presumably from 4chan, then logged in to Palin's Yahoo mail account using a web proxy, called CTunnel, and took screenshots of several of the email lists, contact lists, as well as some personal pictures from the emails. This information has been posted in other places around the web, most notably on Wikileaks.

So a simple diagram of this part of the attack looks like this:

CTunnel, the orange computer in the diagram above, is acting as a proxy. Requests from the hacker are sent to CTunnel, which then sends them to Yahoo. When Yahoo responds, it sends the response to CTunnel, which then goes back to the hacker. Pretty simple. This adds a layer of anonymity for the hacker. Yahoo doesn't know who logged in to Palin's account, only that it came from CTunnel. This means investigators need to get 2 sets of subpoenas, and go through 2 sets of logs, if the evidence is still there at all. Good for the hacker, bad for investigators.

The Catch

Well, actually, there are 2 catches. Rule #1 when dealing with Internet systems is that they are only as secure as the trust you can place in them. No matter how many layers of anonymity or types of encryption I use, if I can't trust the computers I'm transmitting to it probably doesn't matter. I'm sending all my data to a site I don't own, hosted in the United States, that offers a free service. How much can I trust that service?

From CTunnel's "About" page:

• Why should I trust Ctunnel?
  By going through any proxy, you trust any data you send or receive to the proxy owner. To earn your trust I will be as open and honest with you as possible. See below for information about who I am and why I run this service. Open proxies may be honeypots to steal your information, or may be left open accidentally and be down tommorow, or be otherwise unreliable. Ctunnel however, operates soley off money derived from advertising shown during the proxy session, and therefore will not be down tommorow. Because our visitors value their privacy, it is not in our interests to spy on you, lest we lose traffic and advertising revenue. Because government subpenoa could require us to hand over our server access logs, access logs are regularly deleted to protect your privacy. In short, we value your browsing experience as well as your anonymity, and would not do anything to break your trust in us.

Server access logs are deleted regularly. That's good, those are the things that are going to be tracing which computers made requests to which other computers. Somewhere in those logs is every website you visited using their service, which means somewhere in those logs is an entry showing someone logging into Sarah Palin's Yahoo mail account. But the logs are deleted regularly (probably on the order of several days, or weekly, depending on how the administrator sets it up) so all you have to do is wait a few days and you're in the clear. By the time the police get to the CTunnel server to look for your information it will have been deleted and you'll be safe.

Oh, but you know that's not the end.

How do we know that the hacker used CTunnel instead of some other anonymizing service, anyway? Because the screenshots he took of Palin's email account are of his entire browser window, not just the email. If you look at the screenshosts from Wikileaks, or just click this one for an example, you'll see the titlebar at the top displaying an address beginning with "http://ctunnel.com" followed by a long string of characters.

Those characters are not random, they link a user to his request. Those characters are exactly what you need to find the records you need in CTunnel's database. It's kind of like robbing a bank wearing a ski mask, but leaving your nametag from work on. Sure, nobody in that bank knows who you are, but it sure won't be too hard to find you now.

The CTunnel Admin Is Your Friend?

Last chance. CTunnel is a site that values privacy, maybe it's run by a left-wing privacy nut that, upon hearing about the story, will destroy all the logs to stick it to the man!

From The Register:

"Usually, this sort of thing would be hard to track down because it's Yahoo email, and a lot of people use my service for that," he told El Reg in a phone interview. "Since they were dumb enough to post a full screenshot that showed most of the [Ctunnel.com] URL, I should be able to find that in my log."

...

To prevent abuse of the service - such as the occasional bomb threat or other illegal act that's been known to happen - Ramuglia logs each user's IP address, along with the time and web destination...

Nope, the Admin tracks all this information in case of abuse...and thinks the hacker is an idiot for posting the screenshots like that. Well, on the plus side, the person who accessed the account doesn't appear to be the one who hacked in, they were just using the credentials they found. Of course, they did then download the address book, personal pictures and correspondence of the Vice Presidential Candidate of the Republican Party. Probably not the smartest move.

Oh, and a special message to Governor Palin (since I'm sure you'll be reading this blog post), rumor has it that your password was "popcorn". Just some friendly IT advice: you might want to try something a little more complex. Throw in some upper and lower case, maybe some symbols or numbers. It might not keep Anonymous out of your email accounts, but it definitely couldn't hurt.