Current values:

grep . /proc/sys/net/ipv6/neigh/default/gc_thresh*

/proc/sys/net/ipv6/neigh/default/gc_thresh1:128
/proc/sys/net/ipv6/neigh/default/gc_thresh2:512
/proc/sys/net/ipv6/neigh/default/gc_thresh3:1024

Add to sysctl.conf

net.ipv6.neigh.default.gc_thresh1 = 512
net.ipv6.neigh.default.gc_thresh2 = 2048
net.ipv6.neigh.default.gc_thresh3 = 4096

Reload sysctl parameters

sysctl -p

It connects to Google Accounts and adds  a default prefix to the phone numbers which don’t have one yet. Very handy if you moved abroad and you don’t want to add that damn country prefix by hand.  Privacy wise it’s fine, opensource and it runs only in the browser.

Reading Hacker news today I stumbled upon a cool piece of softare: sshuttle. Acording to the developer, it allows you to seamlessly run traffic over ssh in a VPN kinda way, but without the vpn hassle. All you need is a working ssh connection and sudo rights on your machine. Traffic gets somehow redirected via ipfw or iptables to the ‘tunnel’ and out it goes to the remote ssh endpoint. I just tested this with a couple of remove ssh servers and it works pretty good. Ah yes, and it’s open source so you can inspect the code for funny stuff..

https://github.com/apenwarr/sshuttle

zone "example.com" {
        type master;
        file "/etc/bind/zones/example.ro/zone.db";
};

I was in the mood form automation but I wanted something light and quick to setup. Obvious answer: bash.

I created a “template” file where and I replaced the domain name with a place holder:

zone \"$domain\" {
        type master;
        file \"/etc/bind/zones/$domain/zone.db\";
};

I then wrote a small bash loop that walks the array of domains and feeds them one by one to the template file. The end result was a nice config file with all of the domain names.

#!/bin/sh
for i in `find * -prune -type d`; do
domain=$i
eval "echo \"$(cat db.zones.tmpl)\""
done


The essence here is that the eval function forces bash to do parsing and variable replacement once more on the argument.

The more and more I use Linux the more I find myself stuck into some console. While the default terminal app shipped with Gnome is just fine for small jobs it gets annoying when I accidentally close it and or when it’s not on the right desktop. Alt-tab-ing all the time is painful.

This is where the geek in me comes in. Remember the times of Quake and the “console”, when you pressed the ’tilda’ key (~) and a nice console dropped down from the top of the screen allowing you to type game commands ? Well that nifty little concept  made its way to the modern desktop!

Enter Yakuake or “A drop-down terminal emulator based on KDE Konsole technology” as the About menu says. I install it even if I use gnome and although it ads some tens of megs of libraries and breaks the “pure gnome install”. It’s so damn worth it! Pressing a magic key (default F12) instantly pops out the Yakuake window. Do your thing in the console and press the magic key again and the console disappears making way for your other apps. It’s simply brilliant. Yakuake has support for multiple terminal tabs so you can have multiple sessions opened. Using short cut keys you can quickly change the tabs. I consider that Yakuake improves my productivity just as much as the ‘screen’ utility, even tough it has nothing to do with ‘screen’

Yakuake is not the only app that offers this type of functionality. Tilda is another ‘quake console clone’ and it’s based on GTK instead of QT.

Another alternative is ‘guake’, a younger app that aims at the same goal: quake style terminal emulator. It is also GTK based , hence the ‘g’, and it feels more snappy than tilda. With a bit of customizing it comes close to yakuake but I find it a bit unpolished.

Personally I find Yakuake faster and more friendly but it’s all about habits. Give them all a chance!

If you are using a Mac and want the same thing take a look at Visor ( Quake3 anyone? ). It is roughly the same thing.

The same thing goes for you Windoes Powershell lovers out there. You can have the amazing Powershell in a quake console: http://poshconsole.codeplex.com/

Nice pic goes here.

Keyloggers are nifty things used to grab keyboard input for later analysis and use.

The most common type of keylogger is the software keylogger as it is just some program that records key presses. Running it usually requires administrator privileges and this limits the attack surface as one must first gain this type of privileges.

Hardware keyloggers on the other hand are just small devices that sit between the keyboard and PC and listen and record all the keystrokes.

This article refers to the KeyDaemon USB, a hardware keylogger produced by the Polish company KeeLog. Official website

The device is pretty small: on one end there’s an USB A plug (this goes to the PC) and on the other end there’s an USB A receptacle (here the keyboard is plugged). The plastic casing contains a microcontroller that listens in to the USB traffic. A 2GB storage module is also embedded in the small casing and is used to store the sniffed key presses.

The default mode is the “record mode” where the device silently records data. When a magic 3-key combination is pressed ( KBS is the default) the keylogger goes into “playback mode” and it makes visible the embedded flash storage. The keyboard is disabled and in place a flash storage device is detected by the operating system. Inside the flash disk there are two important files: log.txt which contains all the key presses captured by the keylogger and config.txt, which contains configuration settings for the device. By editing config.txt one can change the magic key combination (more on this later).

The keylogger is transparent and does not change the USB vendor ID or product ID. One can not tell that the device is plugged in just by looking at the USB device enumeration ( lsusb for example). This makes the detection of the device quite difficult at first sight.

Detection

The initial approach was to see if the current drain on the USB port was higher with the keylogger in place, but this turned out to be too impractical as it’s hard to do an accurate measurement. The OS support for this is also limited and I felt that this was a dead end.

Next I wanted to see how the keylogger handled unexpected flows of commands. The ioctl interface in linux permits changing the leds on the keyboard from user space. This nifty python script makes your keyboard flash the leds like a Las Vegas Casino billboard:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

import fcntl
import os
import time
 
KDSETLED = 0x4B32
SCR_LED  = 0x01
NUM_LED  = 0x02
CAP_LED  = 0x04
 
console_fd = os.open('/dev/console', os.O_NOCTTY)
 
all_on = SCR_LED | NUM_LED | CAP_LED
all_off = 0
 
while 1:
	fcntl.ioctl(console_fd, KDSETLED, all_on)
	fcntl.ioctl(console_fd, KDSETLED, all_off)

Unfortunately the keylogger had no trouble in handling this type of data.

The next step was to see how the device handles traffic sent from the PC to the keyboard and not the other way around. One would expect that a properly designed keylogger would also take into consideration the direction of the traffic flow. As you will see this is not the case…

The USB keyboard uses the HID protocol to send and receive data to and from the PC. The basic data packet (or report) has 8 bytes. The first byte contains keycodes for the modifier keys (ALT, SHIFT, CTRL), the second byte is reserved for OEM and the remaining 6 bytes are used to send the keycodes for the pressed keys. So one can simultaneous press the modifier keys and 6 other keys.

Using libusb I wrote a very small application that sends the magic 3-key combination out to the keyboard. I didn’t think that this would work as I was expecting a propper design but to my surprise the device flash storage opened like a Christmas present from the first run. One interesting detail is that the keylogger needs to “warm up” since it was first plugged in. Sending the magic key combination immediately after plugging it in does not open the flash storage.

The next logical step was to further extend the app to brute force all the 3-key combinations. If no data can be written to the device then the flash storage has just popped up and a keylogger has been detected.

The device does not take into account the order in which the magic keys are pressed so KBS is also KSB or BKS. Also due to the fact that one can press a key only once a key combination of AAA for example would be invalid. This makes the number of key combinations very small and the brute force takes less than 1 second! While the code needs some polishing and some bugfixes (the USB handle is not cleanly released and this makes the keyboard unusable after execution – it needs to be replugged) it clearly proves that hardware keyloggers can be detected. This is a design flaw it will take a while until it will be fixed.

The PS2 variant of the keylogger has the same flaw and can be detected in the same manner : send all 3 key combinations out the ps2 port and the device will be detected at some point.

My proof-of-concept code uses a small library written by Paul J Stoffregen and Robin Coon of pjrc.com.

Given the fact that this device is so weak (less than 1s to detect) a script or service could be executed at boot time. Maybe companies that write security software could use this to implement a hardware keylogger detection function.

Other devices use a passphrase instead of a key combination. This is harder to brute force and as stated above it all depends on the way the keyloger snoops the traffic. If it does take into account the source of the traffic then the above method is useless and the keylogger is still invisible.

Tar file with the code : keelogdetect.tar
Source code available via SVN : http://code.google.com/p/cdumitru/source/browse/#svn/trunk/keelogdetect

A nice tool that makes one’s life easier when it comes to XML is XML2. It can convert a normal xml file to a more line oriented file format. The standard debian distribution has this neat tool in the repos so you are one apt-get away from using it.

One simple example. Take this XML file:


<xml>
<fruits>
<fruit name="apple" type="royal gala" quantity="2" price="1"/>
<fruit name="orange" type="tasty" quantity="4" price="1.5"/>
<fruit name="banana" type="green" quantity="3" price="1"/>
</fruits>
</xml>


We run xml2 against it:

cosu@roadwarrior:/tmp$ xml2 < fruits.xml
/xml/fruits/fruit/@name=apple
/xml/fruits/fruit/@type=royal gala
/xml/fruits/fruit/@quantity=2
/xml/fruits/fruit/@price=1
/xml/fruits/fruit
/xml/fruits/fruit/@name=orange
/xml/fruits/fruit/@type=tasty
/xml/fruits/fruit/@quantity=4
/xml/fruits/fruit/@price=1.5
/xml/fruits/fruit
/xml/fruits/fruit/@name=banana
/xml/fruits/fruit/@type=green
/xml/fruits/fruit/@quantity=3
/xml/fruits/fruit/@price=1

And now we extract all the fruit names:

cosu@roadwarrior:/tmp$ xml2 < fruits.xml |grep name |cut -d"=" -f2
apple
orange
banana


There you go! A fruit salad! Of course for more complicated stuff use other tools

The largest Romanian IXP is Interlan . Funny enough, Interlan is a response of the smaller ISPs  to the other big Romanian IXP, Ronix. Because 3 years ago joining Ronix was a complicated affair, a few small companies decided to take matters into their own hands. Currently,  Interlan has 3 times more traffic than Ronix.

sudo aptitude install pdfjam

Then all that needs to be done is cd-ing into the folder containing the large number of pdfs and running:

pdfjoin *.pdf –outfile out.pdf

There you go, instant pdf!

As organizers we had to pick out the lucky winner of the raffle. Usually this is done by someone who is impartial. Due to the fact that we had about 1600 entries and that we are geeks we wanted to do something that geeks would do. Therefore we ditched the “extract the name of the lucky winner from a bowl”. The geek version of this is described in RFC2777 – Publicly Verifiable Nomcom Random Selection

In short RFC2777 describes a simple publicly verifiable algorithm to pick out a set of entries from a group as random as possible. The keywords here are public – anyone can see how the entries are picked – and as random as possible. To have random values a thing called information entropy is needed. To get that initial random value full of juicy entropy we used, as suggested in the RFC, the results from three international lotteries. This initial random value was slightly modified for each “extracted” entry and then transformed into a MD5 hash. Due to the nature of a hash when slightly modifying the original the resulting hash differs heavily from the original hash.

Below you can find a naive python implementation that can be freely used for any purpose. Just make sure you fill in the entropySource with a good initial random value.

import md5                                                 

if __name__ == '__main__':

    entropySource = "9.24.30.32.36.40./18.25.35.43.46.47./1.3.4.8.23.31./"

    numberOfEntries = 1655
    numberOfWinners = 10  

    numbers = map( lambda x: x + 1, range( numberOfEntries ) )

    i = 0
    entries = numberOfEntries
    print "index \t hex value of MD5 \t div \t selected"
    while ( i < numberOfWinners ) :
        md5hash = md5.new()
        md5hash.update( chr( i ) + entropySource + chr( i ) )
        val = int( md5hash.hexdigest(), 16 )
        modulo = val % entries
        print str( i + 1 ) + "\t" + md5hash.hexdigest() + "\t" + str( entries ) + "\t" + str( numbers[modulo] )
        del numbers[modulo]
        i += 1
        entries -= 1