ECE 4112 Internetwork Security
Lab X: Sandboxing
Group Number: ______
Member Names: ______
Date Assigned:
Date Due:
Last Edited:
Lab Authored By: Gary Kao & Jimmy VuongFall 2007
Please read the entire lab and any extra materials carefully before starting. Be sure to start early enough so that you will have time to complete the lab. Answer ALL questions and be sure you turn in ALL materials listed in the Turn-in ChecklistON or BEFORE the Date Due.
Goal: This lab will introduce the concept of sandboxing, which is a way to run a program isolated from the main host system. You will be investigating what a sandbox protects you from and how not all sandboxes are created equal.
Summary: In this lab you will be running three sandbox programs: Sandboxie, Virtual Sandbox, and Shadowsurfer. These are all available for free, with limitations, online. We will use programs from previous labs such as the Hacker Defender, FU, AnnaKournikova worm, and the dcom buffer overflow exploit. We are also going to investigate features of a sandbox, such as the ability to mess with processes outside of the sandbox.
Background and Theory: Sandboxes are a type of virtualization – similar to VMware. A sandbox is supposed to try to behave like the host as much as possible. It is a simple way to safely run programs, such as untested code or untrusted code. Generally, sandboxes are a transparent layer that sits on top of the host machine, so once the sandbox is being used, anything that changes the host machine actually only changes the transparent layer. This transparent can be deleted by restarting your computer or by cleaning the sandbox, depending on the program. Some security groups firmly believe in sandboxes as the ultimate form of security, since it does not change the host’s filesystem and everything reverts back to how it was before the sandbox was used. In this lab we will examine three different Sandbox programs: Sandboxie, Shadow Surfer, and Virtual Sandbox.
Sandboxie extends the operating system (OS) with sandboxing capabilities by blending into it. Applications can never access hardware such as disk storage directly, they have to ask the OS to do it for them. Since Sandboxie integrates into the OS, it can do what it does without risk of being circumvented. The following classes of system objects are supervised by Sandboxie: Files, Disk Devices, Registry Keys, Process and Thread objects, Driver objects, and objects used for Inter-process communication: Named Pipes and Mailbox Objects, Events, Mutexs (Mutants in NT speak), Semaphores, Sections and LPC Ports. Sandboxie also takes measures to prevent programs executing inside the sandbox from hijacking non-sandboxed programs and using them as a vehicle to operate outside the sandbox.
Shadow Surfer captures a snapshot of your volume(s) and runs an exact duplicate in a virtual PC or server state. This virtual state, called ShadowMode, allows the user to use the PC orserver as normal, but without premanently writing system changes to the hard drive. If system changes and folder or files changes occur during a ShadowMode session, then these changes can be automatically or manually committed tothe PC or server. If malicious or unwanted changes occur during aShadowMode session, then they canbe discarded with a simple reboot.
Virtual Sandbox is a secure software system designed to allow unknown or untrusted programs to be run in an isolated environment without access to personal files, local networks, and system settings. With Virtual Sandbox installed, programs can be allowed to run in a discardable, carefully tailored, virtual environment that is contained and isolated from the operating system, but appears on your Windows desktop.
Lab Scenario: We will be using three identical Windows virtual machines. Take one of your virtual machines and copy it twice.
First, goto your VMware folder, which is /home/vmware. Now find your Windows XP install folder, which should be called winXPPro and copy it twice with two different folder names that you should remember. Each VM will be used for each sandbox program (Sandboxie, Virtual Sandbox, and Shadow Surfer). For example, you can do
#cp –r winXPProSandboxie
This will create a new winXPPro instance in the folder called Sandboxie. Do this one more time to make the 3rd Windows image.
Next, we will grab the following files from corresponding labs.You will need to remember how to use them, so we’ve included the relevant sections in each lab as appendices.
:
Lab5: HackerDefender (appendix A), FU (appendix B), netcat (appendix C), VNC (appendix D), IceSword
Lab6: dcom exploit (appendix E)
Lab8: AnnaKournikova (appendix F)
Lab10: SDBot (appendix G)
Note that these appendices are only used to remember how to run the programs.
Links to the three sandbox programs are found in the sources section.
Section 1: Installing the Sandboxes and testing
Installing the sandboxes is relatively easy. Simply run the executables for the corresponding sandbox on each machine. For example, sandboxie.exe will install Sandboxie. On the 1st Windows VM, install Sandboxie. On the 2nd Windows VM, install Virtual Sandbox. On the 3rd Windows VM, install ShadowSurfer. After the install of each, restart the computers. When we refer to goto Sandboxie, that means to load up the 1st Windows VM, Virtual Sandbox the 2nd VM, etc.
The Sandboxie install is easy and straightforward. The Virtual Sandbox install will search your computer for files, but do not let it scan so simply click cancel. Shadow Surfer asks for a restart, allow it to do so.
Q1.1: You should notice that each PC will have something new when you start up. What did you notice about each sandbox after the restart?
First we will do the most basic sandbox test – seeing how transparent the sandbox is.
- First, open Sandboxie by double clicking the new icon in the system tray. Now right click on the “Default Sandbox” and click “Run Application” and open “Any Application.” Now type in “explorer” and press enter. Goto the desktop and create a new file on the desktop that you remember. Now, do you see this file on your desktop?
Q1.2: Do you see the file on your desktop?
- In Virtual Sandbox, create a text file on the desktop.
- In Shadow Surfer, create a text file on the desktop.
Also, for each VM, load up IE and ftp to the host computer (remember to load it up via the Sandboxie console in the Sandboxie VM), so if your host is a.b.c.d, then type ftp://a.b.c.d and then login. Grab a file and put it on your desktop.
Screenshot #1-3: Take a screenshot in each VM with the IE window with the copied file name highlighted and the file on the desktop in the same screenshot.
Restart all 3 computers. Once you’re booted back up, see if you can find the files on the desktop.
Q1.3: For each VM, do you see the file on your desktop?
Q1.4: Upon bootup, for each of the computers, is the FTP’d file still there?
Now, we will try to load a program and see how it effects the computer. This test is important because we can check whether malware can do the same thing – open a process and close the sandbox.
- First, open Sandboxie by double clicking the new icon in the system tray. Now right click on the “Default Sandbox” and click “Run Application” and open “Any Application.” Now type in “taskmgr” and press enter. This should load up a sandboxed Task Manager (you can tell its sandboxed in Sandboxie with # # around the title). Now, try to close the sandboxie.exe process. An example is shown in the screenshot below loading IE.
- Now, in the Virtual Sandbox computer press ALT+CTRL+DEL and this will bring up Task Manager. Virtual Sandbox sandboxes the entire system using a dialog box so there’s no direct interface to use like Sandboxie. VS *might* ask you if you want to allow Task Manager to be accessed with a sandbox. So click the Launch in Default Sandbox option (option 2). See the below screenshot for an example that uses ping. For this entire lab, you will use the “Launch in Default Sandbox” option.
In Task Manager, choose to close frst.exe which is the Virtual Sandbox process.
- In ShadowSurfer, everything is sandboxed no matter what you do. You have to disable it, then restart in order to get your computer unsandboxed (but don’t do this). So press ALT+CTRL+DEL and try to close the ShadowSurfer process. It’s called ShadowProtectSvc.exe.
Q1.5: What happens with each of the three sandboxes when you try to close the sandbox?
Now for each of these computers create a file on the desktop that you remember. Next, restart the computers.
Q1.6: Upon bootup, for each of the computers, is the text file still there?
This is one major feature of a good sandbox – the ability to not interfere with the sandbox. Malware can be written that detects sandboxing and does a simple close like this. Passing this test means that the coder won’t be able to close the sandbox this easily. These tests were only to test the basic Sandbox functionality.
Section 2: Susceptibility to Remote Attacks and Local Attacks
Does a sandbox protect you from crashes? Sandboxes are supposed to mimic an actual host computer. So they have no real protection from crashing, but we will investigate this.
Q2.1: Since a sandbox is supposed to mimic and actual host, should it allow crashes if the host crashes?
This is a common question that is asked. Should a sandbox improve the security of the host, or simply completely mimic the host and have the same vulnerabilities as the host?
First we will test a local vulnerability, the JpegOfDeath exploit. Since our VMs are unpatched Windows XP machines, they are vulnerable.
Grab the file exploit-test.exe from NAS on each VM. Now, run this program and click yes through all the dialogs until you get the explorer window that opens up. In this Window, double click the image that is presented to you. Everything will be ran identical on all theree VMs.
Note that in Sandboxie, run all programs via the Sandboxie console, so in this case load exploit-test.exe from the console.
Q2.2: For each of the VMs, did you crash?
Your Windows should still be intact, even after you crashed.
Next, load up the dcom exploit from Lab 6 on the host computer. It is also in appendix E. Get the IP addresses of each VM and run the dcom exploit, choosing the same option as the Appendix.
Q2.3: For each of the VMs, did you crash?
In general, sandboxes don’t offer any added protection over the host, it is simply a method of virtualization to try to be similar to the host without directly affecting the host.
Section 3: Susceptibility to Rootkits, Backdoors, Worms, Botnets
We’ve encountered a variety of nasties from previous labs. So now we will go through some of them to see how much protection a sandbox offers, such as rootkits (HackerDefender and FU), backdoors (netcat and VNC), worms (AnnaKournikova), and botnets (SDBot).
The first exploit we will examine is the netcat exploits. Consult Appendix C for information on how to install and set up Hacker Defender. Make sure to do so for each of the simulated WinXP.
Q3.1: For each of the VMs, did netcat bypass the security?
For the ones in which netcat did manage to penetrate, load up ice sword and see if you could find hxdef.
Q3.2: Can you find hxdef in ice sword?
The first exploit we will examine is the Hacker Defender. Consult Appendix A for information on how to install and set up Hacker Defender. Make sure to do so for each of the simulated WinXP.
Q3.3: For each of the VMs, did Hacker Defender bypass the security?
Next comes VNC. Load up VNC (as shown in Appdneix D) on all three computers, doing what is necessary on each to ensure that the program is run in sandbox mode. Next, attempt to connect to it from your host Linux Redhat computer.
Q3.4: For each of the VMs, did VNC bypass the sandbox security?
Q3.5: For the ones in which VNC did not manage to connect, what happened?
Load up FU next (consult Appendix B for more information) on all three WinXP.
Q3.6: For each of the VMs, did fu bypass the sandbox security?
For the ones that did get bypassed, now choose a process to hide. After doing so, open up Ice Sword again and try to find the file that was hidden.
Q3.7: Can you find the process in ice sword?
Now we will work with the AnnaKournikova worm from lab8. Look to Appendix F for how to run it on each VM. Press ALT+CTRL+DEL and close wscript.exe.
Q3.8: For each of the VMs, did all of them load the worm correctly? Why or why not?
On each VM, run the registry editor with the command “regedit.” In Sandboxie, you’ll need to run this through the console, as usual. Goto the registry entry that the worm created (HCKU\software\OnTheFly).
Screenshot #4-6: Take a screenshot showing this registry entry
Additionally, in Sandboxie, go to Start > run and type in regedit. Press enter. Now, try to goto the OnTheFly registry entry.
Q3.9: Is this registry key there? Why or why not?
Next we will load up the SDBot on each VM, one by one. See Appendix G for instructions on how to create the SDBot. Also remember to load up the irc server on the RedHat host computer that we did in lab 10 with the command:
# /usr/local/sbin/ircd –s
Load the bots up one by one because SDBot chooses a random name, so you won’t know which VM loaded which SDBot.
Q3.10: Did SDBot load up successfully on each VM? If not, why?
Section 4: Clearing the Sandbox
From everything we’ve installed from section 3, how clean are the sandboxes?
In the screenshot above, one can see that the regedit instance is ran via Sandboxie, while the left instance is the normal regedit instance. The sandboxed instance has the OnTheFly registry entry unlike the normal one. Sandboxie does indeed make a transparent layer on top of Windows. If you check for the Hacker Defender or SDBot registry entries, you will notice the same thing.
Each of the 3 VMs has been infected in some way or another, so now we can see if each sandbox does what its meant to do – erase all traces of work done from previous sandboxes. To do this, restart all the VMs. You can also manually clear the sandboxes, but restarting is far easier.
Q4.1: After the restart, did you notice any of the programs we used in section 3 load up? If so, what programs are active?
Screenshot # 7-9: Take a screenshot of the OnTheFly registry key, or where it would be
Q4.2: What sandbox do you prefer? Why?
Section 5: Defenses Along With the Sandbox
Sandboxes are vulnerable to the same thing the main machine is vulnerable to. In this lab, we found that sandboxes alone are not powerful because their goal is to emulate the Windows machine, rather than prevent malware from getting on your computer in the first place.
Running programs sandboxed is safe because any files that are stored will be removed so no permanent damage can be done. This is ideal for a browser that may download malware to your computer for example, since all you need to do is clear the sandbox. The main weakness is that malware can still be executed normally, but you can get rid of malware by clearing the sandbox. Used in conjunction with anti malware, anti virus, and a firewall will greatly increase the chances of getting any permanent infection. We have already investigated anti-viruses and firealls in previous labs but the threats that got past these defenses have to save files on your computer. Since sandboxes don’t allow permanent storage, these threats are not nearly as dangerous to us as without a sandbox.
For those users that already have an anti-virus and firewall, sandboxes can add an extra layer of protection to ensure that if anything gets past the anti-virus and firewall, you are safe. Also the biggest reason that use of sandboxes is growing now is because of the threat of Botnets. Since some botnet programs can be undetectable by anti-viruses and firewalls, a sandbox is a way to protect from the undetectable. However, more sophisticated botnet programs are able to detect sandboxes and as time passes, they may be able to get past sandboxes.
Appendix A: Hacker Defender (excerpt from lab 5)
Section 4: Hacker Defender
First, make a copy of your winXPPro virtual machine by opening a terminal in you Linux WS 4.0 physical machine and typing: