Rants of a madman

Regarding the “new” sshd root kit thats circulating, SANS did a blog post about it. In the blog post they explain that is a rootkit hitting RPM based distros and they contribute a ClamAv signature for detection..

Unfortunately, i just found this rootkit on Ubuntu, which is DEB based.


Upon running the ClamAv signature, a lot of non-relevant things matched (tested on a clean install). So it looks that signature is useless on Debian derived systems. So i made a new one.

The rootkit is a bit tricky to detect, since it hasn’t been littered with strings supplied by the hacker (as rootkits usually are). However, the rootkit utilizes Shared Memory for inter-process-communication, and SSH does NOT use shared memory. So the mere inclusion of Shared Memory functions, like shmctl, shmget  and so forth, is a dead giveaway that something is awry.


To see if you’re infected, you could simply do:

$ grep shmget /usr/sbin/sshd
Binary file sshd matches

And a match, as shown above, means infection.

However, if you wanted to scan your whole disk for possible hidden infected sshd’s, a working ClamAV signature is better.



Save to a .ndb file. Eg. “sshd.ndb”.. Can be run with:
$ clamscan -d sshd.ndb /usr/sbin/sshd

or whatever file or path you wish to scan.


Signature Explanation


This header means:

<name>:ELF-File:search from byte 128 to byte 35000 in every file.

Then we look at the actual bytes…

find “shmget”

Within the next 5k

find “OPENSSL”

Skip ahead 220k

Find “usage: sshd “
Skip ahead 20k

find something like “@@@@@@@@@@@@@@@  WARNING: UNPROTECTED PRIVATE K”


As you can see, i try very hard to EXACTLY match an sshd-daemon. That is, an ssh-daemon which uses shmget.

The signature has been tested on 2 different Ubuntu LTS versions, 1 Debian version and 1 CentOS version without false positives. But as always, use at your own risk :)


  - Dan

I googled a bit to find a way to negate a Files match in Apache 2, since i wanted to reject access to anything but images in an image directory. No luck. Apache doesnt support negating a regex match like that, unless you use mod_rewrite for it.

I’ve made a regex that effectively negates itself instead and this fixes the problem for me..

<Files ~ “(?!.*(?:jpe?g|gif|png|bmp|pdf|avi|mpe?g|mp4)$)….$”>
Order allow,deny
Deny from all

So the match will only be positive if the last four chars are NOT gif, jpg, jpeg ect.

The only caveat here, is that filenames shorter that 4 chars will be rejected, but i cant really imagine that being a problem.

  - Dan

Here’s a patch i did to fix httpfs not being able to mount a DVD9 iso. The problem is due to the use of a size_t to hold the file_size , which is simply too small for a DVD9. Ive changed it to a “long long” and that fixes the problem for me.

--- httpfs2.c.org	2010-03-13 21:07:56.000000000 +0100
+++ httpfs2.c	2011-07-09 16:02:41.000000000 +0200
@@ -96,13 +96,13 @@
char * req_buf;
size_t req_buf_size;
-    size_t file_size;
+    long long file_size;
time_t last_modified;
} struct_url;

static struct_url main_url;

-static ssize_t get_stat(struct_url*, struct stat * stbuf);
+static long long get_stat(struct_url*, struct stat * stbuf);
static ssize_t get_data(struct_url*, off_t start, size_t size);
static int open_client_socket(struct_url *url);
static int close_client_socket(struct_url *url);
@@ -185,7 +185,7 @@
* The FUSE operations originally ripped from the hello_ll sample.

-static int httpfs_stat(fuse_ino_t ino, struct stat *stbuf)
+static long long httpfs_stat(fuse_ino_t ino, struct stat *stbuf)
stbuf->st_ino = ino;
switch (ino) {
@@ -925,7 +925,7 @@

static ssize_t
parse_header(struct_url *url, const char * buf, ssize_t bytes,
-        const char * method, size_t * content_length, int expect)
+        const char * method, long long * content_length, int expect)
/* FIXME check the header parser */
int status;
@@ -1040,7 +1040,7 @@

static ssize_t
exchange(struct_url *url, char * buf, const char * method,
-        size_t * content_length, off_t start, off_t end, size_t * header_length)
+        long long * content_length, off_t start, off_t end, size_t * header_length)
ssize_t res;
ssize_t bytes;
@@ -1117,7 +1117,7 @@
* to determine the file size

-static ssize_t get_stat(struct_url *url, struct stat * stbuf) {
+static long long get_stat(struct_url *url, struct stat * stbuf) {
char buf[HEADER_SIZE];

if( exchange(url, buf, "HEAD", &(url->file_size), 0, 0, 0) < 0 )
@@ -1126,7 +1126,8 @@

stbuf->st_mtime = url->last_modified;
-    return stbuf->st_size = url->file_size;
+    stbuf->st_size = url->file_size;
+    return url->file_size;

@@ -1142,7 +1143,8 @@
ssize_t bytes;
off_t end = start + size - 1;
char * destination = url->req_buf;
-    size_t content_length, header_length;
+    long long content_length;
+    size_t header_length;

bytes = exchange(url, buf, "GET", &content_length,
start, end, &header_length);

  - Dan

Ive been hearing alot of “splunk this” and “splunk that” from a colleague of mine, so i finally decided to check it out myself. Though it is a neat tool that make syslog log-analysis easier, it does come at a price in more than one way.

First of, its extremely expensive. Second of, you sign away your soul in their EULA.

Heres a few things i find horrific (a few copy&paste from their EULA, emphasis added by me):

“You agree not to (i) use the Software except as expressly authorized in this Agreement and your Order Confirmation;”

Right, so if its not expressively authorized in the agreement to, say, have splunk analyze your calendar instead of a log, youre in violation? Dont be creative, is the message. Dont worry, it gets worse:

“[You agree not to] (vi) disclose to any third party the results of any benchmark tests or other evaluation of the Software,..”

You are not allowed to publish a benchmark!?? How f*cking DARE they?? Even worse, you’re not allowed tell ANYBODY what you think of (or how you “evaluate”) the software. Microsoft had the same benchmark clause many many years ago for their SQL-Server product, but grew up.

“At Splunk’s written request, you will furnish Splunk with a certification signed by an officer of your company verifying that the Software is being used in accordance with the terms and conditions of this Agreement and the applicable Order Confirmations.”

A bit excessive, but all good and well. If they ask if youre cheating, you should at least give them the guarantee that you’re not. But hold on to your horses:

Upon at least ten (10) days prior written notice, Splunk may audit your use” …. ” Any such audit will be conducted during regular business hours at your facilitiesYou will provide Splunk with access to the relevant records and facilities

Riiight. So all Gestapo like, they’ll show up at your door, demanding access to “records and facilities”. And according to the agreement, you MUST find time for them and they dont have to pay for all the time they waste. This is very extreme and not something you’d expect be possible anywhere in the western world, but here it is.

“You agree that Splunk may identify you as a Splunk customer on Splunk websites, client lists, press releases, and/or other marketing. You also agrees that Splunk may publish a brief description highlighting your deployment of the Software.”

Lastly, once you give them all your money for their tool, they can use your name, for free, in commercials and on their website.

They can even tell the world the exact details of your installation. So no confidentiality agreement there. And if youre running a sensitive facility, like a bank or like me, internet payments (adhering to the PCI standard), you may actually be prohibited from disclosing details of your setup publicly.

So you cannot agree to this (piece of garbage) EULA.

Shame on you Splunk! This is the WORST EULA i’ve EVER read, and i’ve read a few in my life time. Any Linux/Unix/Freedom lover should reject this promptly!. And if you’ve already bought Splunk, write them, demanding an explanation for these digital-rights atrocities. (even better; ask for your money back or sue them ;))

  - Dan

The Problem

When i first discovered this, my world shattered for a couple of hours. Ive been working with Unix & Linux for more than 15 years and my brain was firmly wired with the notion that “A file owned by root, cannot be touched by any other user” (unless, of course, the user is giving explicit permissions to do so via chmod 777 or the likes).

So when i discovered that a file, owned by root, with nothing but read permissions, had been deleted by an FTP user, i started hunting for exploits in the FTP daemon. In this case it was vsftpd.

I quickly saw in the source code of vsftpd, that all it did was leave the permission decision up to the filesystem/linux kernel. So i started googling. Apparently i wasn’t the only one with this issue and i found posts relating to ProFTPD as well. And the answer was almost always “thats just the way it is, get used to it” without the actual explanation.

So is this an FTP server issue? A lot of answers i found on the net would suggest yes. But actually this is not true. And actually its not even a bug.

Heres a test that may surprise a lot of people (it sure surprised me):

As root:

$ touch /home/user/testfile
$ chmod 000 /home/user/testfile
$ exit

(back as normal user)

$ rm /home/user/testfile
rm: remove write-protected regular empty file `testfile'? y
$ ls /home/user/testfile
ls: /home/user/testfile : No such file or directory

The file is successfully deleted. Whoa.. Brainfreeze!.

Let me explain in detail and then give you a “fix”.

Read the rest of this entry »

  - Dan

If you’ve ever tried to crack passwords from a new ubuntu or other new linux’s, you may have noticed that John The Ripper cannot crack the hashes starting with $5$ or $6$.
I had 2 passwords i needed to check. The passwords came from /etc/shadow from a newer Ubuntu version and i didnt even notice that the hash started with $6$ instead of the usual $1$. After searching and reading for a while, i found out that this is simply the newest generation of password hashes for linux. The “normal” hash ($1$) is MD5. The new ones are $5$ and $6$ and are SHA256 and SHA512 respectively.
The implementation of SHA passwords in linux is done by Ulrich Drepper at RedHat and his original paper can be found here.

Well.. Long story short. I needed to check/crack some passwords and there was no cracker out there for SHA passwords. At the time of writing, not even good old “John The Ripper” has support for these.

So i coded my own brute force cracker. Its made in perl, and it simply uses the operating system’s crypt function. So if you have a system that supports SHA passwords, so will my tool. Hence ive named it “cryptcracker”. It should support any type of hash supported by crypt(), thus (hopefully) not needing a rewrite when new algorithms emerge. The downside is that the crypt() function may be slower than using a version optimized for cracking. But since there isnt such an optimized version out there (and who knows if there ever will be one), this is not an issue at the moment :).

the SHA algorithms are made slower on purpose, making them harder to crack. Cryptcracker can test ~45 passwords per second, per CPU-Core on my 2.53GHz laptop. Ive made the crypocracker multithreaded, meaning i can utilize both cores on my laptop and run a whopping ~90 passwords per second. if you have more than 4 cores, remember to use the “-t” option to set number of threads higher than the default 4.

I share it here, in the hopes that someone will find it usefull.

Download cryptcracker here.

Note: cryptcracker reads the passwords from STDIN.


$ cat password.lst|./cryptcrack.pl -f shadow

or how about using john’s -rule option?

$ john -stdout -rules -w:password.lst |./cryptcrack.pl -f shadow

Remember that found passwords are only shown to screen unless you specifically give an “-o outfilename” option.

Heres an example output of a successfull crack:

$ cat password.lst |./cryptcrack.pl -f shadow -o my_found_passwords
Read 1 hashes from file
Spawning 4 threads
90.911 keys per second.
92.251 keys per second.
92.111 keys per second.
92.401 keys per second.
88.791 keys per second.
FOUND: jamesdick ($6$/2CahJnQ$4cl6vYMRg/ytkZsfBDrBEORmneK45hqDC77KAdkW/NgPumKHwL04SXUequNzktFSEwHcdpLOF.gOSHfLyJvlo.)

Cracked passwords:
jamesdick ($6$/2CahJnQ$4cl6vYMRg/ytkZsfBDrBEORmneK45hqDC77KAdkW/NgPumKHwL04SXUequNzktFSEwHcdpLOF.gOSHfLyJvlo.)

  - Dan

Oh rejoice!

I just found out today (December 2009), that my patch from 2005 actually got included in the main Linux kernel back in Oct. 2007.


This is great news and quite fun too.. Look ma’, my initials are in the kernel!

kernel patch source

Its pretty cool to see my ~150 lines of codes inside the official Linux Kernel. What is also really cool to see, is that someone (Jeff Garzik) actually read and checked all my work, and even fixed up comments and some code standard issues. This just showed that all the FUD about “any one can stick code into the kernel” and “4 geeks in a basement dont have time to check everything” is definently disproved.
A few examples:

Original: /*We have a copper wire (or a couple of copperwires at least…. hopefully)*/
Changed to: /* We have copper */

Original: /*we have optical thingie-majiggy*/
Changed to: /* we have optical interface */

Common for both theese examples is, that my blatant attempt to sneak in comment-humor, is gunned down :). Also notice that a space is added after /* and before */, which is the coding standard (which i apparently didnt read well enough).

Also my highly advanced “ternary-in-ternary” statement:

cmd->speed     = (
        ((cfg / CFG_SPDSTS0) & 3) >= 2 ? SPEED_1000 :
        (((cfg / CFG_SPDSTS0) & 3) == 1 ? SPEED_100  : SPEED_10 )

is replaced with the simple equivalent:

switch (cfg / CFG_SPDSTS0 & 3) {
     case 2:
         cmd->speed = SPEED_1000;
     case 1:
         cmd->speed = SPEED_100;
         cmd->speed = SPEED_10;

So ive learned that Linux-Kernel coders do not appreciate unreadable one-liners as much as the perl community. (and i was just getting good at unreadable one-liners).

  - Dan

I have an encrypted home dir, which is automatically decrypted upon login. (Linux, if you were in doubt). I want to mount a large truecrypt partition automatically when i log in.

I wrote a small script that mounts the truecrypt drive. I added to .bashrc (you could also use .profile i guess) that this script automount script is mounted upon login.

Heres the initial script

truecrypt -t -k "" --auto-mount=devices -p 'MySuperSecretPassword'

Storing the password inside the script isnt the problem (remember that homedir is already encrypted). The problem is, when doing “ps ax”, the password shows up in the list, as such:

3471 ? Ssl 0:00 truecrypt -t -k --auto-mount=devices -p MySuperSecretPassword

Bad idea.. I want to mount using a password and not a “keyfile”, but truecrypt doesn’t provide any other way of supplying a password.

However the solution was pretty simple, once i found it.

echo "MySuperSecretPassword" | truecrypt -t -k "" --auto-mount=devices -p ''

Its really a coincidence that this works. Truecrypt tries to mount using a blank password.. Once this fails, it will prompt for a password.. The prompt will be filled from the pipe.. And now password is gone from ps ax and im a happy camper.

  - Dan

We’re back from HAR2009.. It was a blast :)..

You can see all our photos on our danish blog camp.hacker.dk

  - Dan

Holland beware. Several thousand hackers & nerds from all over the world are marching towards your country.


At last, at last. Time to crawl outside our dungeons,
defy the Evil Daystar (even though it is trying to kill us) and make our way towards the “Hacking-At-Random” camp in Holland.

Its almost here!..  August 13-16.
We have moved all “camp” related stuff to our new blog on http://camp.hacker.dk. If you wish to follow our exploits (so-to-speak) while we’re there, camp.hacker.dk is the place to look. It will most likely be in Danish, but there will be photos (and cake!) so come on over anyway.

  - Dan