Thursday, March 15, 2012

No news today

Well, what a lazy poster i am. But i can explain it, i have a family, some projects running at the moment and not too much time to test out a nice lvm setup and other interesting stuff...but read on.

Hacking Hacking-Lab

Trying to become more involved with the world of penetration testing i made myself an account for Hacking Lab. A swiss based online training lab setup, partly for free.
To use the lab you will either need a live cd which can be downloaded from their homepage (after registering) or setup your PC to match their VPN environment. I am working on the latter a bit to have BackBox as my core platform. But the live cd includes some nice tools which should be looked up too.

After you registered you can choose an event. Inside this event you find different challenges inside a lab which can only be reached through VPN.
The labs themselves are made with different virtual hosts that needs to be hacked, mostly in a capture-the-flag style. So become root and get a file from the system. But there are also more riddle-like hacking activities like notpron or application relevant todos. Some stuff can be done locally without the access to the lab. From what i have done until now (which isn't that much) the challenges seem to be more mis-configuration relevant, i was not able to exploit a system.

Once you made a challenge you can send your solution together with some proof/logfiles (don't forget the gold nuggets) to the jury/teacher and if you have done well, you will receive points based on the difficulty and your solution.

Sounds fun? Then go on, register and try it out. A better (and more important - visual) introduction was made by the hacking lab guys themselves and can be watched here.

Become MSFE

Yeah, i registered for SMFE. While it is focused "only" on the famous Metasploit Framework it is still a great opportunity, the price is affordable for a private person and super cheap for an IT sec related course.
I have choosen the Exam plus 30 day lab access (which i haven't enrolled at the moment). But you can also do all the things on a private lab setup and just choose to do the exam. Look up the options on the website.

As usual Securitytube offers you all training videos for free. Vivek does a great job explaining and showing you the internals of Metasploit. Sadly i find the lab questions a bit confusing and apart from all courses i took in the past, they seem to apply for the next chapter, not the current. But to be honest i haven't read them all.

If you are a professional you sure should choose another training, especially since you will use Metasploit Pro which has some extended capabilities (best and most important thing sure is reporting) and is usually handled through the webinterface. But everyone must decide this for himself.

If i really find the time to do the lab and finally make the exam i will maybe go for the PWB certification. This is a more general course from the tools included with Backtrack Linux and from what i have read doesn't allow Metasploit during the certification at all.
I know, i switched to BackBox but the toolbox from Backtrack is much bigger. BackBox only want's one tool for a task while BackTrack includes almost all famous tools. Question of philosophy, i can understand both.

Bashing kdump

Well, actually what every sysadmin ever dreamed about - crashing a server system the whole day without any trouble. But the reason is, as  usual, not the fun.
After some unexpected crashes of our systems we need to get a crash dump for our RHEL 6 installations (RH: Looks like a hardware failure, do you have a dump?). Usually an easy task - install kexec-tools, configure /etc/kdump.conf, start kdump and you're done. Well, reserve some memory for the crashkernel...

kdump will insert an additional initrd image inside RAM. Once the "main kernel" crashes, this will dump the memory contents at time of the crash to a device, network share or via ssh to another system. So RH will have something to look at.
The memory for the extra kernel gets allocated during boot time via the crashkernel=X@Y parameter (or auto for the lucky and lazy). X means the size of the region and Y is the offset.

But then why do i have to enter the prominent echo c > /proc/sysrq-trigger all the day?
As it turned out the HP servers we are using have a controller that the crash kernel can't handle. Nice! NFS is not an option so we choose ssh. Works with a fresh install in an VM out of the box, dumps just nice.
But not in our environment - we have to use the prior kernel version because the net performance with the current kernel is too slow and additionally we have a huge amount of RAM, which doesn't seem to be handled well by the kexec-tools and our kernel. The crashkernel allocation is limited to something between 820MB and 1024MB (still testing - looks like 850MB - but that is really not for sure). With the current kernel in RH 6.1 this seems to be sufficient - or at least i think so. But bug hunting is sometimes a task where you crawl all day behind those little creatures without really catching one of them, they just slip through your fingers. So crashing, waiting (takes around 6 minutes before you know that the crash dump will be written), changing the crashkernel size, installing different versions of kdump and so on.

Well, we have a support contract with RH, so why not ask them? As it turns out, they also have to play the old trial and error game. Not really helpful with all of our problems so far. Just do it yourself.
But i had no filesystem or any other problem during my current tests which are more than 30! So crashing RH systems work without a problem.

Enough moaned...

See you soon!

Tuesday, March 6, 2012

Decrypting the LVM-Cryptsetup - part 2

Review

Some little things have been done until now.
A disk has been partitioned to support a /boot filesystem (holding the kernel, initram image and bootloader configuration) and an LVM volume.
Before applying the LVM setup, we created an encrypted device /dev/mapper/crypt. Data written to that device is handled by the dm_crypt module and writes the raw data encrypted onto the physical disk. On this layer the LVM setup was made, including the logical volumes and filesystems/swap for the installation

Installation

Well, personally i don't really like Ubuntu and its derivates because they tend to be to macroscopic. Additionally it seems that they use just the Debian development resources to update their systems and don't develop/fix much on their own. But that is just my view.
Ubuntu did indeed one really great step for the linux community. They helped a lot of people getting a linux up and running with a superb and easy installer. I would say that installing Ubuntu is easier than installing Windows.
Drawback: Because the installer is so easy it won't offer you all install options that could be possible. That's why we needed to take the round on the command line and do some things manually. If you just want to install BackBox (or Ubuntu), throw in the DVD, boot and then click install. After some clicks and minutes you're done. But LVM (which should be default in Ubuntu soon) and cryptsetup, since it's a transparent layer, will be honored by the installer.

The steps:
  • click on the install icon (you guessed it)
  • choose an installation language. I recommend choosing English US for all Linux installations.
  • let away the update during installation (the vid shows something different but who cares) and optional choose 3rd party software. Please check the informations on the top of the window, net should be available (actually you installed software from the network), you system should not run on battery power (just to be sure) and need at least 4.4GB free disk space (BackBox 2.0.1)
  • next comes the interesting step - disk partitioning. Well, sure we need to do "Something else" than just click install entire system. Inside the advanced partitioning window, everything looks familiar. Just use /dev/sda1 as /boot with ext4 filesystem, /dev/mapper/cryptvg-rootlv as / (choose format here, otherwise the installer will complain about this) and /dev/mapper/cryptvg-homelv as /home (if you want to, format is optional). /dev/mapper/cryptvg-swaplv is already recognized as swap area.
  • now its time to install. During the installation you will be asked which time zone you live in, which keyboard layout you want to have (doesn't matter which installation language you choose) and you should create a user. If you create the user with automatic login (which i don't recommend, especially hen using an encrypted installation - be completely paranoid, not just a bit), you still have to remember the password. sudo (for administrative tasks) will ask for it, to confirm that you are you. A user account can be hacked remotely, a password compromised (over net) is not so easy if you follow the usual best practices for passwords (long and strong).
    You are offered to encrypt you home folder, but that is more for a not-encrypted installation or the paranoids with people tracking them.
  • after the installation: Continue Testing!
Pretty easy and straightforward installation. Good for beginners - that's what makes up Ubuntu. Everyone can install and use it (Xubuntu is not much different here).
As mentioned above, because it's easy it won't offer you many install options. You can choose to install it beneath another operating system, you can install it over another operating system, on a blank disk and do something else. Something else offers a bit more but needs some preparations.

The chroot

chroot (Change Root) is mainly mainly to devide applications from the rest of the system. The application runs in its own area of the system and has just the programs it needs for itself. Maybe those programs can also be from a different operating system level. Read more about the basic functionality at wikipedia.

In our case we need the chroot to emulate the later running system. We sure need the root filesystem and /boot is also needed because the initramfs needs to be updated to include lvm2 and the crypt-modules at boot time.

The first step is self explanatory - just mount the root-filesystem of the machine to /mnt. You could create your own mount point for this if you want to, but /mnt is wiedly known as standard mount point and available on every Linux/Unix system. Just stick to the basics.

After this we mount some virtual filesystems onto /mnt:

  • /proc is for processes and kernel related informations that must be known in the chroot. I would say that it is the most interesting virtual filesystem, you can lookup and do a lot of things inside. Look here.
  • /sys is the system filesystem - which holds the driver and device informations about your running system.
  • /dev is the device filesystem which holds all devices and is used to access them - like /dev/sda1 or /dev/cryptvg/rootlv

Now /boot is mounted. Since we mounted the relevant system filesystems on /mnt, this step could be done after chrooting to /mnt. But i did it before, thinking that the steps are more straighforward.

chroot /mnt

Works as designed, we are now "inside" the newly installed system. All changes done inside the chroot will be persistent. And that's great. So we can install and update software and also change configuration files. Just what we need, because lvm2 and cryptseup is not installed on the default install and additionally there is no configuration for LUKS.

Note: Changes made to the desktop at this time won't be persistent because it still runs from the Live-CD system. We just use it to ensure that the relevant configuration files are in place and correct and the needed packages are installed, setup and included in the initrd image.

Just 1 mile to go

Inside the chroot the grub default configuration has to be extended to make grub aware of our new cryptdevice. This can be done by manually editing the GRUB_CMDLINE_LINUX_DEFAULT and add the parameter cryptdevice=/dev/sda2:crypt. This way update-grub will automatically add it to the kernel line and grub is aware of the device.
The next part is a bit tricky - or at least it looks like it. Actually you just tell luks how which device should be handled and where to find the key.
So the file /etc/crypttab needs to be edited. There are 4 parameters:

  • target name: Defines the mapper target for the device, in our case crypt
  • source device: This should be the UUID of the device, using /dev/sda2 caused some problems in the past.
  • key file: This could be a path to a keyfile (like /etc/key) or a usb device which stores the key (this is out of scope). In our case we want to enter our overly long passphrase (i really recommend 20+ characters) everytime at boot time, so we say none.
  • options: If you choose something different or another encryption method you could add this here. We just enter luks.
The UUID can be inserted in several ways. The method i used is complicated but works. There is more than one way to skin a cat.

ls /dev/disk/by-uuid/$(ls -l /dev/disk/by-uuid | grep sda2 | grep cut -d" " -f8) >> /etc/crypttab

This cuts out the UUID for /dev/sda2 and appends it to /etc/crypttab. After this you have to edit /etc/crypttab to make it work.
A better way could be

ls -l /dev/disk/by-uuid | awk '/sda2/ { print "crypt\t\tUUID="$9"\tnone\tluks" }' >> /etc/crypttab

but this is up to you.

And thats it - just update your newly installed system inside the chroot and don't forget to install lvm2 and cryptsetup:


apt-get update
apt-get upgrade
apt-get install lvm2 cryptsetup

Don't do a dist-upgrade, this should be run later when the machines comes up again.
Good thing when installing lvm2 and cryptsetup, it will automatically update the initrd image for you. So the needed drivers and modules will be included in the initrd mini-root. Oh, and besides...you are running in a chroot, the package database is also updated with the necessary informations. Nice!

Conclusion

Well, installing an Ubuntu based system is really easy. And if you make up your mind a bit its not much harder with encryption and lvm2.
If you leave away the cryptsetup you can install the system with LVM only - maybe using the internal home-only-encryption offered by the installer. Or you can just partition your system like you always do (maybe /dev/sda1 for /boot and an extended partition for / on /dev/sda5) and just encrypt it without LVM.
If you understand what happened it is also really easy to install BackBox next to another existing operating system. Keep in mind that the boot loader of any operating system might break the ability to boot into another one - but must work for its own system.

Hope you enjoy this article, see you the next time.

Saturday, March 3, 2012

Open Curtain - Cryptsetup and LVM with BackBox

Finally progress


After a lot of trouble i made progress in video editing - please don't expect too much. It's the content that counts :)


Movie

Credits


  • Installation done with BackBox 2.0.1 on Virtual Box (host Arch Linux with spectrwm window manger - thats what caused the red borders)
  • Shot was taken using recordmydesktop
  • Converted for editing using mencoder: mencoder install_backbox_with_crypt_and_lvm.ogv -ovc lavc -lavcopts vcodec=mjpeg -nosound -o output.dv
  • Video editing was done with OpenShot (great tool but really needs some time to get used to it - or better: RTFM ;) )
  • Music: "Dont' touch" by SunIce - had to be an italian artist ;) Support them please if you like their music.