Robert Escriva

On my Ubuntu desktop I often find myself installing many packages to test new software, and then removing unwanted packages several hours later. The Debian package manager "aptitude" tends to remove packages that were pulled in as dependencies. For good reasons it does not always remove configuration files (e.g. they were modified).

While it does not hurt to have excess config files laying around, they build up over time, and can easily be removed.

The one-line shell command sudo aptitude purge $(dpkg -l | grep '^rc' | awk '{print $2}') will completely remove all packages that left configuration files after the package was removed.

A breakdown of this command:

• dpkg -l lists all packages registered with the package manger.
• | grep '^rc' takes the output of the previous command and only passes lines that begin with 'rc'.
• | awk '{print $2}' further changes the output by only displaying the second space-delimited column on each line.
• $(...) takes the output of evaluating the contents of the parenthesis and includes it on the command line.
• sudo aptitude purge ... will completely remove specified packages.

A quick example would make this more clear. Let's assume I have installed mysql-en-us, and then removed it, but not its configuration files. The output of dpkg -l | grep '^rc' would be:

myspell-en-us     1:2.4.0-2ubuntu4      English_american dictionary for myspell

The output of dpkg -l | grep '^rc' | awk '{print $2}' would be:

myspell-en-us

Thus when I enter sudo aptitude purge $(dpkg -l | grep '^rc' | awk '{print $2}') it is equivalent to sudo aptitude purge mysql-en-us.

I'm sure there are other methods of achieving the same thing using other means. I've found that aptitude removes the dependencies and configuration files more often than apt-get, but this extra step helps to eliminate even more unnecessary files.

Our server for Software Design and Documentation failed over Halloween weekend. I've just finished migrating all services from that box to others within my dorm, and I am very thankful for my team's choice (heavily influenced by me) to chose git as for our version control.

A little background on git: it is the distributed source control system used to control projects such as the Linux Kernel or X.org. The distributed nature ensures that each clone of a repository contains the entire revision history of the original.

To make a long story short, restoring our revision control system was easy as cake. Had we used subversion, all changes checked into the repository since the most recent backup would have been lost.

So this is a presentation I gave for the Software Design and Documentation course here at RPI. Each member of the class has been tasked with sharing a certain design pattern.

I was assigned the Template Method pattern. This pattern was familiar to me, but I did not know its name until I was tasked with preparing this presentation.

The slides basically speak for themselves, so if you're interested, take a peak. I've licensed them under CC-BY-ND as this is a class assignment, and I wish to prevent plagiarism by preventing derivatives.

I've put together a little interactive introduction to g++/gcc and gdb for a presentation given by ALAC at RPI. I hope someone out there finds this useful. I have some basic slides and an exercise written in C.

To compile the code, type gcc -o learn learn.c.

Slides are CC-BY-SA, and code is BSD. Have fun!

This challenge was appropriately named as it leaked much more than most people would suspect.

The basic premise was that the password file was chosen from a GET parameter. In the same directory as the file, there was a default password file that the user could request via the webserver.

If one were to set the auth file to be the publicly visible one, and login with the username and password specified on the first line the challenge would provide the answer.

There is a basic security flaw in this challenge in that any file on the server can be included. From this I was able to determine (with reasonable certainty):

• What files were present on the system
• The contest host was Ubuntu 8.04.1
• The kernel version was 2.6.24-19.36-server

The first point is relatively simple. The script will fail if it tries to open a non-existant file, and thus can be used to verify the presence of files on the system.

The second and third points are related. The system essentially verifies the first two space-delimited words from the "auth file". If the file to open is set to /etc/issue, the username will be "Ubuntu," and the password will be "8.04.1." Thus if the script is fed these parameters and the file /etc/issue, it will return success if the system is Ubuntu 8.04.1. A similar technique for the file /proc/version_signature will return the kernel version.

These two techniques can be used for a variety of things:

• It is possible to verify which packages has been downloaded into the cache by APT.
• .htaccess and .htpasswd files can be probed for in the web accessible directories.
• It is possible to exhaust the memory of the server, and possibly force the system to swap to disk.

Admittedly the utility of the above points varies when looked at from an attack perspective. The presence of an .htaccess or .htpasswd file is of limited utility as it does not provide much information to an attacker.

The attack can be used to examine the apt cache for presence of security upgrades. An attacker simply has to crawl /var/cache/apt/archives on Debian-based systems to make reasonable guesses about the state of the system.

The final attack vector is exhausting the memory on the system by setting the file /dev/random as the auth file. This will cause excess memory consumption and can be used as part of a denial of service attack.

From a defensive perspective, all of the above attacks are less than desirable. The system leaks unnecessary information to an attacker, and in cases of an inadequately patched or improperly configured server, can quickly become a thorn in any system administrator’s side.

The easiest way to thwart the attacks is to setup the webserver in a chroot’ed environment, or perform proper sanitation of the input for the auth file. While some may shrug off the holes I presented above, from an overall security perspective any hole is too big.

RPISEC is officially approved as a RPI Union sponsored club.

This will allow RPISEC to grow in membership, participate in Union-sponsored activities fair events, and operate with an official budget.

We're hoping to use the Union resources to host copies of the software distributed in past CTF contests. This will allow members to have access to past images (such as from the Cipher 4 and DA-Open contests).

In the coming weeks, we're hoping to develop a platform for the club website that will allow members of RPISEC to allocate resources such as Trac, Subversion, Git, etc. for use in club projects. I'll post updates about that system as it progresses.

This weekend I'll be doing a writeup on a bug I found in the "leaky" challenge of the 2008 CSAW contest. Ryan's blog has a nice writeup on the CSAW contest as well as how our team (RPISEC) performed.

Tonight I gave a presentation to the RPI ACM on FreeBSD rootkits. The slides and examples themselves vary very little from those in my previous post on FreeBSD rootkits.

Those who did not make the first presentation would benefit by first walking through this presentation, and then possibly reviewing the udp_hook example given in the previous talk.

Anyway, here are the downloads as promised:

• Slides
• hello
• rot13
• process
• hide_file
• 42

Please respect the law when playing with these examples. The slides are licensed under a Creative Commons By-SA, and the code is BSD.

I presented this material to a group of RPISEC members on August 30, 2008. It generated some lively discussion as to where the material could be expanded. In particular, the following points were made:

• Expanding 'udp_hook' to potentially cover all protocols by hooking IP. It was mentioned that poor firewall rule-sets could be bypassed by looking for non-standard packets.
• Modifying 'process' to perform more complete hiding of processes; primarily by disconnecting all associations with parents or children.
• Check whether the techniques in 'process' interfere with signals in any way.
• Hooking the syscall trapping itself to hide hooked syscalls.

I'm presenting this material with the hope of furthering discussion on this topic, and I hope that those who were unable to attend the meeting find it useful as well.

Here are samples and slides:

• Slides
• Hello World
• ROT13
• Process Hiding
• UDP Hooking

Please look at the slides for information about references I used.

Leave messages in the comments if you have any ideas for improvement, or any interesting comments.

As for licenses, the code is BSD, and the slides are Creative Commons By-SA.

Update 9-16-08: I changed the licenses to permit a little more freedom to share (if you do anything interesting with it, please let me know).

Welcome to my blog. I plan to update this blog with interesting, (hopefully) unique articles as I find time to write them.

I hope to write about the following topics:

• Security (both at the system administrator level, and at code level).
• Web development using newer technologies (my preference for frameworks right now is Django.
• Systems programming (interacting with the kernel, etc.).
• Tricks that make life easier for users and developers.

I hope to present enough unique content that you will become a regular reader of my blog.

-Robert Escriva