Taking advantage of regexp for fun&profit

I’m gonna tell you a story, based on real events.

Let’s assume a big network, with a highly restrictive policy about who can access the Internet and which sites you can browse. The users can’t access the Internet directly from their workstations (from a layer 3 routing point of view) the only way out is using the corporate browser (an IE6 by the way) which is configured and locked to use a proxy to get access to the world out there.

This proxy is the typical corporate web proxy, I mean, it demands the user to authenticate before it grants access to the requested URL, that previous authentication avoids any anonymous surfing moreover it’s used to track how long the user has been surfing, the requested URL is checked against a set of rules based on regular expressions that allow the proxy admins to filter which URLs or sites are allowed. In practice only a bunch of sites and URLs are allowed by the security policy, so the “interesting” Internet is completely blocked by this ‘fraking’ proxy, no google, no webmail, no access to the server in your home, no pr0n, nothing… just a bunch of bored and only work-related URLs.

Of course, the only protocols allowed by this proxy are HTTP and HTTPS, and as the access to the Internet isn’t network routed from the point of view of the local workstation but proxified at the application level, SSH, the magic-hacker-tool for network tunneling, is useless too :(

Nothing new under the sun so far, we’ve got the typical corporate Internet access scenario based in a HTTP/HTTPS proxy… but there’s more, the foolish-admin-factor works in our favor :)

As an eager mind myself, I wanted to check how these rules were setup by the admin. I managed to get a user account in the proxy server, and of course the first thing that I did was to learn more about the proxy that was installed there finding the config file… and you know what? the file rights were rw-r–r–

I like this admin :) config files readable to everyone in the system. I guess (and now I know for sure) that the admin doesn’t care about these kind things, he should think that everybody is good in this world, that everybody agree with the restrictions and the rules… or maybe he thinks that nobody cares about his servers and his config files… well, he’s wrong!

Be able to read the config file isn’t a big deal if there’s nothing interesting in the file… but if reading the file reveals a bad configuration that creates a hole in the system, then it’s important! I’m talking about how the regular expressions in the filtering rules were coded by our dear admin.

Let’s say you want your users be able to access slashdot.org, a simple and easy way to write a regular expression to permit this could be one like this: http://.*\.slashdot.org/.*

What do you say if someone claims to filter the access with a rule like this one: .*slashdot.org.*

Not so clever, don’t you think? This rule just says: accept any URL that has the string slashdot.org and the dot isn’t really a dot, is any character as it isn’t escaped :)

OK, let’s say you got your own DNS domain, so you can create whatever DNS name you want in it. Let’s say your domain is itsucks.org so you can create the name slashdot.org.itsucks.org so that matches the filtering rule that our “savvy” admin has written in his proxy configuration file.

So, just creating the right name in our DNS pointing at the IP of one of our systems, we got a direct link between the “protected” inside workstation in the “highly restricted” inside network and our external server.

Note that we haven’t cracked, tampered or modified in any way the browser, the proxy or the network. We’ve just took advance of the misconfiguration to reach directly a machine under our control from our internal PC.

Of course, we could use our external server as a forward or reverse proxy to freely browse any site or page, or better than that, we could create a SSH tunnel or any other kind of VPN tunnel being able to connect through the HTTPS proxy to freely get any TCP connection out or even in.

If you have an Apache server running in your server, you can do the trick with a configuration like this:

<VirtualHost *:443>
  SSLEngine On
  SSLProtocol All -SSLv2
  SSLCertificateFile /etc/apache2/ssl/cert.pem
  SSLCertificateKeyFile /etc/apache2/ssl/key.pem
  ServerName slashdot.org.itsucks.org
  ServerAdmin root@itsucks.org
  ErrorLog /var/log/apache2/proxy/error.log
  CustomLog /var/log/apache2/proxy/access.log common
  ServerSignature On
  ProxyRequests On
  ProxyVia On
  AllowCONNECT 22
  <ProxyMatch slashdot.org.itsucks.org>
    Order deny,allow
    Deny from all
    Allow from 1.2.3.4
  </ProxyMatch>
</VirtualHost>

First of all, I didn’t want to move my SSH server from the 22/tcp to the 80/tcp or 443/tcp, doing that I could avoid the trick and connect directly to the SSH server, but I wanted to keep my HTTP/HTTPS ports for the web services so the connection redirection from Apache turn out to be pretty useful.

How it works:

A SSL virtual host is defined in the standard way on the 443/tcp port. The X.509v3 certificate and the private RSA key are created and defined. The server name is the one that is recognized as a valid and allowed external site by the corporate proxy as it matches the regular-expression filtering rules. This DNS name is resolved by our own DNS server to our own external server IP address. At this point, the HTTPS connection reach our Apache web server from our PC. The forward proxy feature is enabled with the ProxyRequests sentence but the access is denied from all but the IP address that we know is the public address of the corporate proxy that give us access to the Internet from the internal LAN.

The AllowCONNECT sentence is an interesting one, it defines which ports the proxy will be able to connect to when the HTTP CONNECT method is in use. In this case we’re interested in transport the SSH session inside the HTTPS session so when the connection ends in the Apache server and the SSH client sends the CONNECT method to connect to the SSH server, it’ll try to connect to the 22/tcp port so we’ve to permit it.

The last piece of this puzzle is the SSH client. Any client with HTTPS proxy support will do the trick. I got PuTTY in my PC which is perfect to do the trick. You only need to configure the corporate proxy in the Connection/Proxy preferences, try to connect to your server using the funny DNS name that matches the regexp and here you have!

Now, if you configure a tunnel using a local port to go out or a remote port to go in, or even if you use PuTTY as a socks server, you’ll have free rein.

December 16, 2009 | Filed Under (In)Security, English, IT Professional, Linux, Networking, SysAdmin

2 Comments 

RedHat, Qumranet y KVM

El pasado jueves, 4 de septiembre, se hizo publica la compra de Qumranet por parte de RedHat. La transacción, de $107 millones, le proporciona a RedHat dos productos que la posicionan como otro jugador más dentro del campo de juego de la virtualización al verse reforzada en varios frentes:

RedHat quizás llegue un poco tarde a la “hypervisors war“, al menos si lo que pretende es confrontar a KVM de forma directa con Xen ya que no hay que olvidar que KVM va un par de años por detrás de Xen tecnológicamente hablando. Aunque teniendo en cuenta la vista general al completo, es decir, KVM+SolidICE+oVirt, lo que se obtiene es una solución para gestión de VDI (Virtual Desktop Infrastructure) lista para competir contra el resto de jugadores.

Los dos objetivos de RedHat para el futuro están claros:

September 8, 2008 | Filed Under Castellano, Linux, SysAdmin

Leave a Comment 

Build your own LiveCD collection

There are lots of live Linux distros out there. Some of them are general distros, designed to have a fully functional Linux environment without the need of installing it on a hard disk partition. On the other hand, there are some specialized live distros, that can boot from CD/DVD and run from RAM.

Personally, I find these distros the most useful ones, since I get a system designed to be used for a specific task and with loads of tools to perform network/system security audits, system forensics, system cloning, password cracking, parallel computing… You can visit livecdnews, livedistro or distrowatch to know some of them.

As but one example, I have in my toolbox the following:

All those distros together take up less than 4 GB, so would be great to join all of them in only one DVD. Depending on each live CD design, it will require changes to many scripts inside the initial ramdisk and/or the compressed root file system, but in most cases the system will boot smoothly after twiking the init script to adjust the path where it expects to find the distribution files.

First of all, the directory tree for the distros and the isolinux files have to be created:


mkdir ~/dvdiso
mkdir ~/dvdiso/isolinux
mkdir ~/dvdiso/clonezilla
mkdir ~/dvdiso/gparted
mkdir ~/dvdiso/cdrouter
mkdir ~/dvdiso/bt
mkdir ~/dvdiso/fccu
mkdir ~/dvdiso/inq
mkdir ~/dvdiso/ophcrack
mkdir ~/dvdiso/ntpasswd

The isolinux directory contains the bootloader isolinux.bin, the main configuration file isolinux.cfg where all the menu options are described and the menu.c32 file to create the text menu.

The isolinux.cfg file have to be created ad-hoc to contain a menu item for each distro on the collection. For example:


DEFAULT menu.c32
PROMPT 0
ALLOWOPTIONS 1

MENU TITLE FuTuR3 Live Collection

LABEL clonezilla
MENU LABEL Clonezilla Live 1.1.0-8 (800×600x16)
KERNEL /clonezilla/live/vmlinuz1
APPEND initrd=/clonezilla/live/initrd1.img boot=live union=aufs noswap vga=788 ip=frommedia

LABEL gparted
MENU LABEL GParted Live 0.3.7-7 (800×600x16)
KERNEL /gparted/live/vmlinuz1
APPEND initrd=/gparted/live/initrd1.img boot=live union=aufs noswap vga=788 ip=frommedia

LABEL inq
MENU LABEL Inquisitor 3.0 LiveCD
KERNEL /inq/isolinux/alt0/vmlinuz
APPEND initrd=/inq/isolinux/alt0/full.cz live fastboot automatic=method:cdrom stagename=/inq/altlinux/livecd showopts

LABEL router
MENU LABEL Linux LiveCD Router 2.0
KERNEL /router/vmlinuz
APPEND initrd=/router/initrd.gz livecd_subdir=/router load_ramdisk=1 prompt_ramdisk=0 ramdisk_size=13312 rw root=/dev/ram0 console=tty0 pci=bios,biosirq ether=0,0,eth1 ether=0,0,eth2 ether=0,0,eth3

LABEL fccu
MENU LABEL FCCU Gnu/Linux Boot CD
KERNEL /fccu/live/vmlinuz1
APPEND initrd=/fccu/live/initrd1.img boot=live keyb=es noswap username=fccu hostname=fcculive union=aufs

LABEL bt
MENU LABEL BackTrack 3 (1024×768x24 KDE)
KERNEL /backtrack/boot/vmlinuz

APPEND vga=0×314 initrd=/backtrack/boot/initrd.gz ramdisk_size=6666 root=/dev/ram0 rw autoexec=xconf;kdm

LABEL ophcrack
MENU LABEL Ophcrack LiveCD 2.0.1
KERNEL /ophcrack/boot/vmlinuz
APPEND initrd=/ophcrack/boot/initrd.gz ramdisk_size=6666 root=/dev/ram0 rw autoexec=xconf;startx changes=/slax/

LABEL ntpasswd
MENU LABEL NTpasswd
KERNEL /ntpasswd/vmlinuz
APPEND rw vga=1 initrd=/ntpasswd/initrd.cgz,/ntpasswd/scsi.cgz

Note that the kernel and initial ram disk files have to be refered with the correct path, depending on the directory structure created.

When a distro is selected from the isolinux menu and starts booting, the kernel is loaded and the initrd file is decompressed and mounted as the initial root file system. At this point, problems show up, inside the initrd there are scripts that search for the main distro directory in the root filesystem of the bootable media, but that directory has been moved to a subdirectory (remember that each distro has its own subdirectory under the root) so we need to fix all those wrong paths.

Let’s see what have to be changed in each case, from easiest to hardest ;)

Inquisitor v3.0 Live CD

Boots like a charm, so no fixing needed.

NTpasswd

No modification is needed.

Linux LiveCD Router 2.0

Note that i have just added the parameter livecd_subdir=/router. That’s enough to make it boot.

GParted 0.3.8

The initrd file have to be mounted to modify a path in the live script. To decompress and mount the initrd file, follow these steps:


mkdir /tmp/initrd
mv ~/dvdiso/gparted/live/initrd1.img /tmp/initrd1.img.gz
cd /tmp/initrd
gzip -cd /tmp/initrd1.img.gz | cpio -i --no-absolute-filenames

Now we can edit the scripts/live file and change the LIVE_MEDIA_PATH variable from:

LIVE_MEDIA_PATH="live"

to

LIVE_MEDIA_PATH="gparted/live"

After this, you have to rebuild the initrd file:


rm /tmp/initrd1.img
find | cpio -H newc -o > ../initrd1.img
gzip -9 ../initrd1.img
mv ../initrd1.img.gz ~/dvdiso/gparted/live/initrd1.img
chmod 444 ~/dvdiso/gparted/live/initrd1.img

FCCU GNU/Linux Boot CD 12.0

The same case that previous one. You have to fix the LIVE_MEDIA_PATH variable in the live init script.

Backtrack 3

To make BT3 bootable, the initrd file have to be adapted too. In this case, the file is a compressed ext2 filesystem, so it’s easier to make the needed changes:


mkdir /tmp/initrd
mv ~/dvdiso/bt/boot/initrd1.img /tmp/initrd1.img.gz
cd /tmp/initrd
gzip -d /tmp/initrd1.img.gz
mount -t ext2 -o loop,rw /tmp/initrd1.img /mnt
vim /mnt/linuxrc

Search the following snippet of code in the linuxrc shell script, and add the subdirectory name where the backtrack distro is (bt/ in my case):


if [ "$DATA" = "" ]; then
# from= is not used or it didn't contain valid data
DATA=$(find_in_computer bt/$LIVECDNAME/$SGN)
DATA=$(dirname $DATA 2>/dev/null)
fi

Ophcrack

Same case as previous one as both distros are based in linux-live scripts. Search the same code snippet in the linuxrc file and add the directory where the distro was copied:

DATA=$(find_in_computer ophcrack/$LIVECDNAME/$SGN)

Clonezilla 1.1.0-8

At first, edit the ocs-live.d/S03prep-drbl-clonezilla script and add to the possible_path variable the path /live/image/clonezilla


possible_path="/live_media /cdrom /live/image /live_media/clonezilla /cdrom/clonezilla /live/image/clonezilla"

Uncompress and unpack the initrd file. Edit the scripts/live file, and change the path in the LIVE_MEDIA_PATH variable:

LIVE_MEDIA_PATH="live"

to

LIVE_MEDIA_PATH="clonezilla/live"

Finally, uncompress the squashfs file system:

mkdir /tmp/squashfs
cd /tmp/squashfs
mount -t squashfs -o loop,ro ~/dvdiso/clonezilla/live/filesystem.squashfs /mnt
cp -va /mnt/* .
umount /mnt
vim etc/rcS.d/S99start-ocs-live

Edit the file /etc/rcS.d/S99start-ocs-live and change the variable possible_path from:


possible_path="/live_media /cdrom /live/image"

to


possible_path="/live_media /cdrom /live/image /live_media/clonezilla /cdrom/clonezilla /live/image/clonezilla"

Note the path really used is /live/image/clonezilla. Rebuild the squashfs:


rm ~/dvdiso/clonezilla/live/filesystem.squashfs
mksquashfs /tmp/squashfs/ ~/dvdiso/clonezilla/live/filesystem.squashfs
chmod 555 ~/dvdiso/clonezilla/live/filesystem.squashfs

OK, just finishing… at this stage, we can build the ISO and test it before burn it in a DVD:


mkisofs -r -J -l -V "LiveDVD" -o livedvd.iso -b isolinux/isolinux.bin -c isolinux/isolinux.cat -no-emul-boot -boot-info-table -boot-load-size 4 dvdiso/


qemu -m 128 -boot d -cdrom livedvd.iso

If all seems to work fine in qemu, burn the ISO in a DVD and enjoy your new LiveCD collection! :)

Happy Hacking! :)

August 30, 2008 | Filed Under English, Linux, SysAdmin

4 Comments