Port 25: The Open Source Community at Microsoft : Security, Linux

Technical Analysis: OpenSSH on Linux using Windows/Kerberos for Authentication

jcannon — Fri, 06 Jun 2008 14:35:00 GMT

Abstract: Secure remote access to UNIX and Linux systems is generally accomplished through SSH. The most frequent implementation of that protocol is OpenSSH, originally written for the OpenBSD project but now ported to a wide variety of platforms. This paper will show how to use OpenSSH with the Kerberos portion of Active Directory to automate authentication.

Download OpenSSH on Linux using Windows/Kerberos for Authentication

Note: This paper represents testing and documentation in a lab environment. User Account Control (UAC) is an essential security component to Windows and Microsoft does not recommend turning off UAC in production environments.

Using Vista's Boot Manager to Boot Linux and Dual Booting with BitLocker Protection with TPM Support

MichaelF — Fri, 13 Oct 2006 19:57:00 GMT

Today we are introducing Cyril Voisin, Security Advisor for Microsoft in France where he has worked for 9 years. Cyril is a CISSP (Certified Information Security Systems Professional) and along with his work at Microsoft also teaches systems and network security in local schools as time allows. Cyril has started a blog, primarily focused on security (exact blog intent can be seen here) but occasionally dealing with interoperability as it relates to security.

Cyril has given us permission to syndicate his content on Port 25, the first example is below. Please feel free to post any questions or clarifications below or on Cyril’s blog.

We welcome Cyril to Port 25 and look forward to featuring his work and insight in the future.

-michael

-------------------------------------------------------------------------------------------------------

How to use Windows Vista’s Boot Manager to boot Linux

The Web is full of explanations on how to dual boot Windows and Linux using a Linux boot manager like GRUB or LILO. If you want to dual boot Windows Vista and Linux using Windows Vista’s Boot Manager, please read on. I will assume that you already have installed Linux on your machine using GRUB as your boot loader.

Step 1 – Install GRUB on the Linux partition (outside of MBR)

As Windows Vista will replace the Master Boot Record (MBR) with its own, we need to relocate GRUB elsewhere by running grub-install with the Linux partition as a parameter.

• On Linux, launch a Terminal with root privileges

• Find the name of the partition Linux is installed on by running fdisk –l (the partition you’re looking for is the one whose system is Linux, can be something like /dev/sda1 or /dev/hda1. For the rest of this post, I’ll use /dev/sda1)

• Install GRUB on the Linux partition by running : grub-install /dev/sda1

Step 2 – Get a copy of Linux boot sector

We will need to instruct Windows Boot Manager how to boot correctly Linux using Linux boot sector, which we will extract using dd.

• On Linux, launch a Terminal with root privileges

• Take a copy of Linux boot sector : dd if=/dev/sda1 of=/tmp/linux.bin bs=512 count=1

• Copy linux.bin on a FAT formatted USB key or any storage accessible from Windows Vista

Step 3 – Install Windows Vista

Step 4 – Configure dual booting in Windows Vista

We will create an entry for GRUB in Windows Vista boot configuration data store using bcdedit.

• On Windows Vista, launch a command prompt with administrative privileges (by right clicking on cmd and choosing Run as Administrator)

• Copy Linux boot sector on the root of the Windows boot (active) partition, namely the one containing bootmgr. If you don’t know for sure you can use diskpart or diskmgmt.msc to find out which one it is.

• Create an entry for GRUB :

o bcdedit /create /d “GRUB” /application BOOTSECTOR

o Note: bcdedit will return an ID for this entry that we will call {LinuxID} below. You will need to replace {LinuxID} by the returned identifier in this step. An example of {LinuxID} is {81ed7925-47ee-11db-bd26-cbb4e160eb27}

• Specify which device hosts a copy of the Linux boot sector

o bcdedit /set {LinuxID} device boot

• Specify the path to a copy of the Linux boot sector

o bcdedit /set {LinuxID} PATH \linux.bin

• Add Linux entry to the displayed menu at boot time

o bcdedit /displayorder {LinuxID} /addlast

• Let the menu be displayed 10 seconds to allow for OS selection

o bcdedit /timeout 10

Building a dual boot system with Windows Vista BitLocker protection with TPM support

Many people have wondered if it would be possible to dual boot a TPM-bitlockered instance of Windows Vista with Linux, or another OS. The answer is yes and the following procedure will hopefully help you setup your machine correctly.

Some (simplified) background on Bitlocker:

Bitlocker Drive Encryption allows encryption of Windows Vista’s partition and provides a secure startup process when in use with a TPM (a crypto chip on the motherboard). Basically the BIOS, the TPM, the MBR and the boot sector will collaborate to help verify that there was no modification to the boot sequence since Bitlocker was activated. This is done by using a function of the TPM to compute and store a hash of the code before executing it, at each of the initial steps of the boot sequence. Different hashes will be computed and stored in specific registers of the TPM. Then Windows Vista will ask the TPM to unseal its volume encryption key and the TPM will only provide this key if its registers are correctly set. Therefore if you replace Windows Vista’s MBR by a MBR that is not TPM aware, it won’t hash the boot sector before executing it and a register in the TPM won’t be populated. Same with the boot sector. Therefore Bitlocker will simply refuse to be enabled.

The underlying idea here is to have Bitlocker enabled with the original Windows Vista boot files. Another possibility would be to use a TPM-aware version of GRUB. However this would imply using files in the boot sequence that were not tested by Microsoft, which I would not recommend. Moreover, using original Windows Vista files offers you the benefits of code that went through the Security Development Lifecycle, which I personally find very valuable.

Note: I assume that you have a Bitlocker compatible machine (including TPM 1.2, TCG BIOS). See http://www.microsoft.com/technet/windowsvista/library/c61f2a12-8ae6-4957-b031-97b4d762cf31.mspx#BKMK_require

Step 1 – Install Linux

Note: be sure to leave enough unpartitioned space for Windows Vista: about 11 GB of free unpartitioned space and slots for 2 partitions are needed

Step 2 – Install GRUB on the Linux partition (outside of MBR)

See other post “How to use Windows Vista’s Boot Manager to boot Linux”

Step 3 – Get a copy of Linux boot sector

See other post “How to use Windows Vista’s Boot Manager to boot Linux”

Step 4 – Create partitions for Windows Vista

We need to create 2 primary NTFS formatted partitions on the disk: one active, 1.5GB size minimum and another larger (all the rest for instance with a minimum of 8.5GB). The former will be used to boot the machine (active partition) and will remain unencrypted while the latter will host Windows Vista and will be encrypted when we activate Bitlocker.

You can use diskpart tool to do this (available from Repair options on the Windows Vista DVD). Here is what the instructions may look like :

· select disk 1

· create partition primary size=2048

· active

· create partition primary

Step 5 - Install Windows Vista

Install Windows Vista on the largest NTFS partition.

Step 6 - Set up Windows Vista Boot Manager to boot Linux

See other post “How to use Windows Vista’s Boot Manager to boot Linux”.

Step 7 - Enable BitLocker on Windows Vista

See BitLocker documentation, like http://www.microsoft.com/technet/windowsvista/library/c61f2a12-8ae6-4957-b031-97b4d762cf31.mspx#BKMK_S3

Honeypots and User Mode Linux Part 2: Forensic Analysis

MichaelF — Fri, 04 Aug 2006 19:50:00 GMT

UML (User Mode Linux) and Forensic Analysis

(Special thanks to Dan Simonton for the testing and writing in support of this tech tip)

Processes running under UML will have no access to the hosting system, accept where explicitly allowed. Because of this UML is an ideal candidate for operating a honeypot. While processes running in UML have no outside access to the host operating system memory or filesystem; hypothetically, if an attacker managed to break out of userspace into some section of the host filesystem, they could do further damage on the host . Best-practice demands that host access be limited within the UML instance wherever possible.

For any of this to be practical, obviously some services would need to be established. We’ll just assume these are already in place and forwarding iptables rules setup on the host. For instance, to forward inbound http connections to your UML instance:

iptables -t nat -A PREROUTING -i eth0 -p tcp -s 0/0 \
--dport 80 -j DNAT --to-destination (uml ip):80

This process could be repeated for any other service you wish to run. Just be sure the appropriate destination port is specified both with the “--dport” option and also at the end of the command. Essentially you are instructing all inbound traffic to port 80 to be forwarded to your UML. The same process could be repeated for ssh,ftp and others.

Typically, the first order of business for an intruder with root access is to wipe out log files. It is best therefore to have log files written to the host (or another remote) machine. To achieve this, the host system’s syslogd daemon must be configured to receive inbound logs. Add “-r” to the runlevel script of the host machine where it invokes syslogd the correct path is: /etc/rc.d/syslog. On the client machine, add the following to /etc/syslog.conf:

*.* @yourhostmachine
(note: @ipaddress will work also)

Now inbound connections to the UML honeypot and activity on the honeypot can be investigated through log files on the host machine.

Conveniently for the purpose of running UML as a honeypot, tty_logging of UML into a directory on the host machine is built as an option into the kernel. The simplest way to achieve this is to add the following to the kernel command line:

tty_log_dir=dir

This way, even if they zap the shell log files on the UML, you will still have an account of their activity on the machine.

There are a few quick and common methods of checking running activity. The following two should be familiar to anyone with a relatively basic understanding Linux, but we’ll mention them here for propriety’s sake:

ps auxwww (check running process table)

netstat –lvnap|less (check open sockets, associated process, and user ids)

In the past, whenever I’ve found any strange binaries (sometimes named something really vague or obscure), I’ll run the following command, sift through, and evaluate the output:

strings (filename)|less

An all-to-commonly overlooked tool for inspecting a system is “lsof” (list of open files). It can be used to check file-to-file access, files listening on a socket and evaluate the state of a running process. It is helpful to know the normal running health of a system for comparison when using lsof. For a quick check of a specific process:

lsof –p (pid)

To get socket info on a process:

lsof -i -nP|grep -i (process name)

To protect against potential outbound denial-of-service attacks, it might be prudent to explicitly declare hosts you wish to allow outbound ICMP traffic to (the host ip being one for example) and deny everything else. This can be done on the host by adding the following rules to iptables. You can add as many “ACCEPT” rules as you need, just be sure to put them before the “DROP” rule.

        iptables -A INPUT -p icmp –s (uml ip) –d (host ip) –j ACCEPT
        iptables –A INPUT –p icmp –s (uml ip) –d (other ip) –j ACCEPT
        iptables –A INPUT –p icmp –s (uml ip) –d 0/0 –j DROP

Similiarly, you could block potential outbound syn-flooding:

   iptables -N syn_flood
     iptables -A INPUT -p tcp --syn –s (uml ip) -d 0/0 -j syn_flood
     iptables -A syn_flood -m limit --limit 1/s --limit-burst 3 -j
RETURN
   iptables -A syn_flood -j DROP

A quick search of http://sourceforge.net or http://freshmeat.net will quickly realize a vast sea of various analysis tools. Provided the disk image size for your is adequate, any of these can be copied to the drive image or simply downloaded once you have the UML instance running. A few useful tools are:

Tripwire: Useful for monitoring data integrity. In a nutshell, it takes a snapshot of your system binaries (or other specified directory), creates a checksum, runs routine system integrity checks against it, and reports any deviation.

The Coroner's Toolkit: A suite of utilities for checking running process and file/filesystem information, recent changes and other such information.

Snort: Snort is so prevalent, it almost needs no description. Still, it is one of the best tools for traffic analysis and intrusion detection. To accurately provide a description that does this monster justice would be a blog unto itself. There is a great FAQ on their website:

http://www.snort.org/docs/faq/1Q05/

Chkrootkit: A utility for identifying rootkits installed on the system.

This is but a small (microscopic) primer into a much larger world of intrusion detection and integrity analysis, but we hope some may find this useful. We will likely delve into these subjects in the future.

Honeypots and User-Mode-Linux (UML): Part 1

jcannon — Sun, 23 Jul 2006 22:21:00 GMT

Honeypots and User-Mode-Linux (UML)
Part I: Setting up UML

(Special thanks to Dan Simonton for the testing and writing in support of this tech tip)

In technical terms, a honeypot performs a function very similar to that of a “honeypot” in the outside world: a sweet lure. A “honeypot” is a system designed with the purpose of attracting the attention of prospective attackers, to assess how they are attempting to infiltrate the machine and what they doing once they gain access. There are literally thousands of honeypot networks and systems setup by security professionals and hobbyists worldwide. These systems can provide a wealth of information into forensics and assessing trends in network intrusion.

This is Part One of a two part tech tip, which will address the setup of User Mode Linux (UML) for honeypot use. Part Two of the tech tip will cover the containment of intrusions and other security topics that arise while using UML as a honeypot. Also addressed in Part two will be the “forensics” i.e. identifying what exploits were tried on the honeypot.

One of the more popular methods for constructing honeypots in the Linux world is to set up a kernel to run in “user mode” on a host Linux machine. In function, this is very similar to running a “Virtual PC” on a Microsoft Windows or Apple Macintosh system. The primary difference is that “User Mode Linux”, or UML is open source and (depending on your personal depth of knowledge of the Linux kernel) you can really tweak any and every aspect of the host and UML kernel to your liking.

User Mode Linux is essentially an entire operating system running as a program in user space. It masquerades as an OS because for most purposes, it is one. The immediate benefit of running a honeypot this way is that with proper precautions taken, there is no significant threat to the host machine, or its operating system. When or if an attacker gains control of the UML instance, you can simply shut it down and restart at no cost to the hosting machine’s uptime or stability.

The first step is to download a copy of the actual kernel source that you wish to compile on the designated host machine. This can be obtained from http://www.kernel.org/ or any associated mirror site. In this tech tip we will use the 2.6.16 kernel. The patches for the UML kernel can be obtained from:

http://www.user-mode-linux.org/~blaisorblade/patches/skas3-2.6/skas-2.6.16-v8.2/skas-2.6.16-v8.2.patch.bz2

You will also want to create a filesystem for the UML. In the interest of time and space, there are a number of filesystems that can be downloaded for various distributions from:

http://uml.nagafix.co.uk/

In this example we will be using Slackware-10.2

First of all, the standard commands are applied to unpack the source

$ tar –zvxf linux-2.6.16.tar.gz
$ bzip2 –d skas-2.6.16.-v8.2.patch
$ cp skas-2.6.16.-v8.2.patch linux/
$ cd linux-2.6.16/
$ patch –p1 < skas-2.6.16.-v8.2.patch

Note: In every step of the build process, it is crucial that the “ARCH=um” argument be passed along with the various kernel configuration and compilation commands.

Next we will clean out any .config files (if any are present) and generate a default configuration:

$ make mrproper && make mrproper ARCH=um
$ make defconfig ARCH=um

Now we manually check and edit the configuration:

$ make menuconfig ARCH=um

At the very top of the list are UML-specific options. It is important to know what some of these are:

[ ] Tracing thread support
[*] Force a static link
[ ] Host processor type and features --->
[ ] Three-level pagetables (EXPERIMENTAL)
[ ] Memory model (Flat Memory) --->
[*] Networking support
[*] Kernel support for ELF binaries
<M> Kernel support for MISC binaries
< > Host filesystem
< > HoneyPot ProcFS (EXPERIMENTAL)
[*] Management console
[ ] Magic SysRq key
(0) Nesting level
[ ] Highmem support (EXPERIMENTAL)
(2) Kernel stack size order
[*] Real-time Clock

There are two options here in particular to take note of.

The first is the “Host Filesystem” option. This gives the UML Linux kernel access to the host filesystem. If you enable this, be careful how the access is applied. A safe course is to apply extended mount and read-write restrictions over filesystems on the host machine.

The second is the “HoneyPot Procfs” option. This essentially overwrites entries in the /proc filesystem of the UML kernel with that of the host. This is useful in that it removes fingerprints which might otherwise indicate the host is a honeypot. It could also be a potential troublespot for someone could map out the architecture of the hosting machine using this information. This is less of a threat than it is something to keep in mind.

NOTE: Be sure to include general kernel support for ext2, ext3 and reiserfs.

Looking further down from the kernel configuration tree, see the options for UML network devices. If you want to get to the outside world from the user mode kernel, be sure to enable ethertap and tun/tap support. This will allow the user mode kernel to communicate with the host tun/tap device.

Be sure to check any other “non-uml” options for your kernel that might be relevant to your machine. There is one last step before you can build the kernel. Due to a macro called by the patch that is now deprecated, one of the kernel source files must be manually edited. In whatever text editor you prefer, open up the file: (within the source tree) arch/um/os-Linux/sys-i386/registers.c and add the following to the preprocessor directive:

#ifndef JB_PC
#define JB_PC 5
#define JB_SP 4
#define JB_BP 3
#endif

Once all this is done, build the kernel with:

$ make ARCH=um

At this point, we have our hard drive image (with distribution) and a UML Linux kernel. We have a few more things to set up on the host before we are ready to boot our UML instance. First, we need to make /dev/net/tun writable (by the user the UML kernel will be running as). The quick and dirty way to achieve this is to make it world writable (NOTE: not a “best practice”, just a quick way to get from a to b).

Alternatively you could create a separate group with write access to /dev/net/tun. Tun0 which is a tunneled interface to eth0, is used to negotiate traffic between the user mode kernel and the primary physical interface of the host machine. To configure the 1^st interface (tun0)

tunctl –u umluser umldev

This command invokes tunctl, specifies the creation of a device, assigns ownership to user (via –u) to “umluser” and name its “umldev”. The IP side is configured the same way as a standard Ethernet interface via ifconfig:

ifconfig umldev (ip address)

We’re ready to start our instance. We’ll want to specify the Ethernet device on start.

linux ubd0=Slackware-10.2-root_fs mem=256M eth0=tuntap,umldev

Once you are asked for a login, simply enter “root” and it should drop you right to a shell.

dhcpcd: MAC address = fe:fd:00:00:00:00
Starting OpenSSH SSH daemon: /usr/sbin/sshd
Updating shared library links: /sbin/ldconfig

Welcome to Linux 2.6.16-skas3-v8.2 (tty0)

yadda-yadda login: root
Linux 2.6.16-skas3-v8.2.
Last login: Thu Jul 20 00:53:38 +0000 2006 on tty0.
You have mail.
root@yadda-yadda:~#

On the UML side, use ifconfig to give an ip address to eth0. This needs to be something routable by the umldev IP of the host machine. The route then must be set to the outside world (via the host umldev interface).

route add default gw (umldev ip)

On the host, packet forwarding and proxy_arp must be enabled:

Host# echo 1 >/proc/sys/net/ipv4/ip_forward
Host# echo 1>/proc/sys/net/ipv4/conf/umldev/proxy_arp

Now you should be able to reach the outside world from UML:

[uml@yadda-yadda]$ ping www
PING www.yadda-yadda..com (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=127 time=12.1 ms

root@yadda-yadda:~# ssh www.yadda-yadda.com
root@www.yadda-yadda.com’s password:
Last login: Thu Jul 20 11:00:50 2006 from yadda-yadda.com
[root@www ~]#

You should have a functional UML kernel running in its most basic form. You may kick it around, experiment with distributions (see links provided below), or otherwise abuse it as you see fit without consequence to your hosting system. This entry barely scratches the surface of one use of a usermode kernel, but if you have not considered running one before or are new to the idea, we hope this provides some useful information. Below are some links to some other resources, as well as the user-mode-linux project homepage.

http://user-mode-linux.sourceforge.net/ - UML Project homepage
http://www.honeynet.org/misc/project.html - The honeynet project
http://uml.nagafix.co.uk/ - A repository of disk images to use with your kernel