July 10, 2009

Syscan 09 - Singapore

We've spent most of this week putting everything back together after a week in Singapore for the Syscan conference there. I didn't get to sit in on any of the talks as we were either setting up or managing the Capture the Flag competition there for the entire conference but I heard good things about a lot of the talks (Dave Aitel from Immunity stopped by to check on the competition periodically and share a few details about the recent talks).

This competition added some new challenges for our infrastructure and allowed us to try out some new things, as well. Everything went off without a hitch thanks in large part to our sponsors and the excellent work of Thomas Lim at COSEINC. Special thanks are due to the sponsors of the CTF at Syscan, iSight Partners, that provided the prizes for the event as well as some support. And thanks also to Ben Nagy and Cédric Blancher who killed a lot of time at the event with us.

5360_1178832116003_1384157367_1867693_1276613_n

The Event

The CTF event for Syscan was fairly similar to our previous exercises with a few differences that made this event unique. This event had 8 teams participating (max 3 members per team), 7 of the teams were from Singapore (most from various technical schools on the island) and one team flew in from South Korea to participate in the event. The teams were scored as usual for our events, a combination of service availability and integrity, responses to provided tasks and their ability to defend their networks against attackers.

The big difference in this competition was that each team had once computer to use as their attacking computer, so each team had to defend their network and attack the networks of the other 7 teams at the same time. Our competitions usually have the participating teams focus solely on defense (with a dedicated "Red Cell" team that attacks all the networks), but we decided to try something different for this one. Ostensibly each team had one attacker and two defenders at any given time (that was how many keyboards they had, though their resources could obviously be shifted as necessary).

The prize for this event, generously provided by iSight Partners, was $10,000S for first place.

Challenges


This was the first event of this size and complexity that we've done internationally so it presented a few new challenges for us. When we do our exercises in the US we usually set up the entire environment in our lab and test everything, then pack up the infrastructure and bring it with us to the location. This means that we've tested all the hardware and software and know that it's working (or, at least, that it was before we left). International shipping of that much gear (including routers, firewalls, servers, etc.) just wasn't practical for this event, so instead Thomas from COSEINC provided us with a set of very nice ESX Servers on site to use for our servers, as well as 24 desktops rented in Singapore for the teams to use for the exercise. This also meant that we had to be doubly sure that we had all the servers and resources that we might need. Having someone at the office try and transfer a 6GB VM over the hotel's connection would not have worked out very well.

Language and culture were also an interesting issue for this event. Our setup (and specifically our documentation) is really written with an American mindset about the rules and how they'll be interpreted (mostly because that's what we are, and I don't know how to write in other people's mindsets). For this exercise not everyone spoke English (the Korean team had a translator to relay questions between the team members and us) and the culture in Asia is such that nobody wants to break any rules, or even potentially break any rules. We had a lot of teams questioning very specifically about things they were and weren't allowed to do (specific attacks they could use, closing ports, disabling services, etc.). Even when these things were mentioned in the documents we provided, because this was a competition many players would double-check just to make sure that it was correct.

Overall

The competition went extremely smoothly and all the participants seemed to enjoy themselves (especially the kids that took home $10,000S). With the exception of some minor hiccups (hotel power is universal, if nothing else) everything went as planned. To all our participants, if you happen to be reading this, thanks for playing, and hopefully we'll see you next year!

February 17, 2009

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).

February 04, 2009

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.

December 05, 2008

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.

December 02, 2008

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?