Blog <-

Archive for the ‘security’ Category

RSS   RSS feed for this category

Re-use existing SSH agent (cygwin et al)

(Please note that this post is not specific to Windows nor Cygwin; it'll work on a remote unix machine just as well)

On my netbook, I use Windows XP in combination with Cygwin (A unix environment for Windows) and Mintty for my Unixy needs. From there, I usually SSH to some unix-like machine somewhere, so I can do systems administration or development.

Unfortunately, the default use of an SSH agent under Cygwin is difficult, since there's no parent process that can run it and put the required information (SSH_AUTH_SOCK) in the environment. On most Linux distribution, the SSH agent is started after you log in to an X11 session, so that every child process (terminals you open, etc) inherits the SSH_AUTH_SOCK environment setting and SSH can contact the ssh-agent to get your keys. Result? You have to start a new SSH agent, load your key and enter your password for each Mintty terminal you open. Quite annoying.

The upside is, it's not very hard to configure your system properly so that you need only one SSH agent running on your system, and thus only have to enter your password once.

The key lies in how ssh-agent creates the environment. When we start ssh-agent in the traditional manner, we do:

$ eval `ssh-agent`
Agent pid 1784

The command starts the SSH agent and sets a bunch of environment variables:

$ set | grep SSH_

The SSH_AUTH_SOCK is how the ssh command knows how to contact the agent. As you can see, the socket filename is generated randomly. That means you can't reuse the socket, since you can't guess the socket filename.

Good thing ssh-agent allows us to specify the socket filename, so we can easily re-use it.

Put the following in your ~/.bashrc:

# If no SSH agent is already running, start one now. Re-use sockets so we never
# have to start more than one session.

export SSH_AUTH_SOCK=/home/fboender/.ssh-socket

ssh-add -l >/dev/null 2>&1
if [ $? = 2 ]; then
   # No ssh-agent running
   rm -rf $SSH_AUTH_SOCK
   # >| allows output redirection to over-write files if no clobber is set
   ssh-agent -a $SSH_AUTH_SOCK >| /tmp/.ssh-script
   source /tmp/.ssh-script
   echo $SSH_AGENT_PID >| ~/.ssh-agent-pid
   rm /tmp/.ssh-script

What the script above does is, it sets the socket filename manually to /home/yourusername/.ssh-socket. It then runs ssh-add, which will attempt to connect to the ssh-agent through the socket. If it fails, it means no ssh-agent is running, so we do some cleanup and start one.

Now, all you have to do is start a single terminal, and load your keys once:

$ ssh-add ~/.ssh/fboender\@electricmonk.rsa
Enter passphrase for .ssh/fboender@electricmonk.rsa: [PASSWORD]
Identity added: .ssh/fboender@electricmonk.rsa (.ssh/fboender@electricmonk.rsa)

Now you can start as many new terminals as you'd like, and they'll all use the same ssh-agent, never requiring you to enter your password for that key more than once per boot.


I've updated the script with suggestions from Anthony Geoghegan. It now also works if noclobber is set.

Stop Pingback/Trackback Spam on WordPress

I guess the spammers finally found my blog, cause I've been getting a lot of pignback/trackback spam. I tried some anti-spam plugins, but none really worked, so I disabled pingbacks altogether. Here's how:

First, log into wordpress as an admin. Go to Settings → Discussion, and uncheck the Allow link notifications from other blogs (pingbacks and trackbacks.) box.

That's not all though, cause that just works for new articles. Old ones will still allow ping/trackbacks. As far as I could tell, WordPress doesn't have a feature to disable those for older posts, so we'll have to fiddle around in the database directly.

Connect to your MySQL server using the WordPress username and password. If you no longer remember those, you can find them in the wp-config.php file.

$ mysql -u USERNAME -p -h localhost
Password: PASSWORD
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1684228
Server version: 5.0.51a-24+lenny5 (Debian)

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.


At the MySQL prompt, we must now switch to our WordPress database. Again, if you don't remember the name, you can find it in the wp-config.php file. In my case, it is em_wordpress

mysql> USE em_wordpress;
Database changed

Finally, we update all posts and disable ping backs on them:

mysql> UPDATE wp_posts SET ping_status = 'closed';
Query OK, 1084 rows affected (0.10 sec)
Rows matched: 1084  Changed: 1084  Warnings: 0

There we go. No more ping- and trackback spam on old posts.

SSH Tips and Tricks

(The lastest version of this article is always available in stand-alone HTML format and in PDF format. The original AsciiDoc source is also available. Please link to the HTML version, not this Blog post!)

SSH is capable of more than you'd think! This article describes some of the lesser known features and configuration options. It covers authentication, authorization, tunnels and proxies, file transfer and more.

Read the rest of this entry »

Regular expression Denial of Service (ReDoS)

It's only logical, but I hadn't really thought about it much. Turns out Regular Expression can be vulnerable to external Denial of Service attacks.

Security Questions considered harmful

Many online services allow, or even worse, require, the so called "Security Question". It is a question/answer you can enter in case you ever forget your password or can't access your account for some reason. In my opinion, security questions are an incredibly bad idea, from a security perspective.

The usual security questions are things like "What was your mother's maiden name", "What's your pet's name", etcetera. People won't understand that actually supplying a truthful answer to these kind of questions exposes them to an incredible weakness in their account's security. These are all questions to which the answer can be found relatively easy by googling a person or applying a little social engineering. "Hey, I am John, and I think I might be related to you on your mother's side. What's her maiden name"?

The worst part is that every site has basically the same questions from which you can choose. This means that people either have to pick the same question and answer every time, or pick a different one for each account. The first will make them vulnerable to repeated attacks on all their online profiles once an attacker has found the answer. The second will make it very hard for people to remember that they must never let anybody know about their favorite pet's name "Buddy". A lose/lose scenario at best.

As is often the case with security protocols, they must be followed to the letter to be safe. One flaw in the procedure, and the security collapses. Security questions could be a good idea, provided that:

  • The user makes up his own question. No predefined questions should be supplied, and most importantly, different sites shouldn't all use the same questions.
  • The user should never be told what his security question was. If they need to reset their password, they should chose both the security question and the answer. This will make it much harder for a potential attacker to gain accees.

Of course, taking the above in consideration, security questions are just as hard to remember as a password, which makes them kind of pointless. Pointless or insecure, make your pick.

chkrootkit false positives filtering

Chkrootkit is a tool that searches for rootkits, trojans and other signs of break-ins on your system. Like most security scanners, it sometimes generates false positives. Chkrootkit doesn't have a native way to filter those out. From the FAQ:

[Q:] chkrootkit is reporting some files and dirs as suspicious: `.packlist', `.cvsignore', etc. These are clearly false positives. Can't you ignore these?

[A:] Ignoring some files and dirs could impair chkrootkit's accuracy. An attacker might use this, since he knows that chkrootkit will ignore certain files and dirs.

This is true, but getting an email every day is simply too annoying, and makes me skip chkrootkit generated emails on occasion because "It's probably a false positive anyway". So here's a small guide for setting up a filtering of chkrootkit's output.

First, we create a file /etc/chkrootkit.ignore which will hold a bunch of regular expressions that will match everything we don't want to be warned about. For instance, I've got a machine that needs to have a dhcp client installed. Chkrootkit keeps on generating emails with these lines:

eth0: PACKET SNIFFER(/sbin/dhclient[346])
eth1: PACKET SNIFFER(/usr/sbin/dhcpd3[1008])

So what we do is create the file /etc/chkrootkit.ignore and put the following in it:


^eth0: PACKET SNIFFER\(/sbin/dhclient\[[0-9]*\])$
^eth1: PACKET SNIFFER\(/usr/sbin/dhcpd3\[[0-9]*\]\)$

In order to test if the rules we created are correct, we put the two lines with false positives in a separate file (/tmp/chkrk-fp.txt) and run the following:


[root@sharky]/etc# cat /tmp/chkrk-fp.txt | grep -f /etc/chkrootkit.ignore
eth0: PACKET SNIFFER(/sbin/dhclient[346])
eth1: PACKET SNIFFER(/usr/sbin/dhcpd3[1008])

The lines that should be filtered out of the chkrootkit output should appear here. If nothing appears, or if not all of the lines that you want to filter appear, there's a problem. Refine your regular expressions in /etc/chkrootkit.filter until it works.

Now we need to modify the chkrootkit cronjob so that the false positives are filtered. To do this, we edit /etc/cron.daily/chkrootkit. Below is a patch that shows what should be changed. You can apply the patch with the 'patch' command, or you can manually add the lines that start with a '+', replacing the lines with a '-'.

--- /home/root/foo      2007-11-21 11:53:58.532769984 +0100
+++ /etc/cron.daily/chkrootkit  2007-11-21 11:54:00.689442120 +0100
@@ -1,27 +1,28 @@
 #!/bin/sh -e


 if [ ! -x $CHKROOTKIT ]; then
   exit 0

 if [ -f $CF ]; then
     . $CF

 if [ "$RUN_DAILY" = "true" ]; then
     if [ "$DIFF_MODE" = "true" ]; then
+        $CHKROOTKIT $RUN_DAILY_OPTS | grep -v -f $IGNOREF > $LOG_DIR/ 2>&1 || true
         if [ ! -f $LOG_DIR/log.old ] \
            || ! diff -q $LOG_DIR/log.old $LOG_DIR/ > /dev/null 2>&1; then
             cat $LOG_DIR/
         mv $LOG_DIR/ $LOG_DIR/log.old
+        $CHKROOTKIT $RUN_DAILY_OPTS | grep -v -f $IGNOREF || true

Next, we try running chkrootkit, to see if anything shows up:

[root@sharky]/etc/cron.daily# ./chkrootkit

There is no output, so our false positives are now being ignored.

SSH + SOCKS5 = Universal proxy

I didn't know it, but (Open)SSH supports setting up a Socks5 proxy:

-D [bind_address:]port
  Specifies a local ``dynamic'' application-level port forwarding.
  This works by allocating a socket to listen to port on the local
  side, optionally bound to the specified bind_address.  Whenever a
  connection is made to this port, the connection is forwarded over
  the secure channel, and the application protocol is then used to
  determine where to connect to from the remote machine.  Currently
  the SOCKS4 and SOCKS5 protocols are supported, and ssh will act
  as a SOCKS server.  Only root can forward privileged ports.
  Dynamic port forwardings can also be specified in the configura-
  tion file.

Socks5 is pretty neat, as it allows you to proxy stuff without the server having to know anything about the way the client works. For instance, if we give the following command:

$ ssh -N -D

We can now tell all kinds of clients such as web browsers and instant messaging clients that there is a Socks5 proxy running on the localhost at port 8080. SSH will forward all connections made to port 8080 to the host (all encrypted of course).

So, say we tell Pidgin that it should connect your MSN account through the Socks5 proxy at localhost:8080 by opening the Accounts (Ctrl-A) → Click MSN account → click ModifyAdvanced tab → Proxy options → Proxy type = SOCKS5 and setting it to Host: localhost, Port: 8080. Now, when we reconnect to our MSN account, all MSN traffic will be routed over an encrypted SSH tunnel to the host, and will enter the public Internet from there.

This works great if you don't trust the network you're currently on, but don't have access to a VPN for instance. You also don't have to specify a single forward for each application/port like you have to do when you use ssh -L. You can use the same SOCKS5 proxied port with multiple applications, as long as they understand SOCKS5.

Virtualization Security

Theo de Raadt on virtualisation security:

> Virtualization seems to have a lot of security benefits.

You've been smoking something really mind altering, and I think you
should share it.

x86 virtualization is about basically placing another nearly full
kernel, full of new bugs, on top of a nasty x86 architecture which
barely has correct page protection. Then running your operating
system on the other side of this brand new pile of shit.

You are absolutely deluded, if not stupid, if you think that a
worldwide collection of software engineers who can't write operating
systems or applications without security holes, can then turn around
and suddenly write virtualization layers without security holes.

> Anything we can do to increase security, *including* setting up VMs (of any
> flavor) is an improvement [that also increased hardware utilization].

This last sentence is such a lie.

The fact is that you, and most of the other fanboys, only care about
the [that also increased hardware utilization]. The yammering about
security is just one thing — job security. You've got to be able to
sell increased harwdare utilization in a way that does not hang you up
at the end of the day.

Of course, de Raadt is right… in his own tiny little world at least. Running services which would normally run on multiple machines on multiple hypervisored instances on a single host machine would indeed be less secure than running them from multiple physical machines.

But running multiple applications on virtualized machines which would normally run on a single machine is more secure, simply because it adds another layer of protection.

But, as usual, de Raadt's complete ineptitude when it comes to communications totally negates any point he's trying to make and only serves to rile up people against his cause.

It's the chrooted story all over again. Yes, chroot isn't completely secure. Yes, chroot isn't meant as a security construction. Yes, running multiple services on a single machine that would normally be run on several separate physical machines is less secure. That doesn't mean chroot (and virtualisation for that matter) can't add an extra layer of security if used properly!

Theo de Raadt's problem is that he views security the way cryptography experts view cyphers: as an absolute. But security isn't like math. It's not absolute. There are right and wrong ways of doing security. De Raadt is like that security consultant who says: "You must have randomly generated passwords consisting of at least eighteen characters, lower and upper case, numbers and symbols, nothing repeated twice, completely unique and changed every week, or your being insecure!", all the while ignoring the fact that that kind of password policy will only force people to write down passwords on a yellow-note under their keyboards. In theory, they're right. In practice, they're wrong. These people become blinded by their own viewpoint. Just as these so-called security consultants are blinded by their belief that strong passwords equal security, so is Theo de Raadt blinded by his belief that virtualization doesn't improve security.

Perhaps it's time to stop listening to de Raadt, and start listening to people with a broader overview of the situation.


So, I've read there's another virus on the loose. *g* When will this end? I'll tell you: never. At least, not until these virusses do some radical damage. They aren't destructive enough against the right targets. Right now, these virusses do create a lot of problems and damage to infrastructures and companies. The problem is, home users don't give a shit. There are lots of sites out there which educate the people on how to avoid such virusses, but do they read them? Do they learn from previous virusses? Hell no. Why should they care, all the virus does is replicate. It doesn't delete all their digital camera pictures, mp3's, downloaded movies or porn, so they don't give a rat's ass.

When the propagators of these virusses, the home users, start feeling the pain caused by these virusses, then they will take the time to think for a couple of seconds and do something about it. E.g. install and REGURALY UPGRADE their virusscanners, stop clicking of everything that say's click me, run the WSH files that will protect their inboxes from crap.

Disclaimer: I haven't actually looked at how MyDoom propegates at all, so I might be totally off on this. But since I'm not seeying as much as a glimp of this virus, I suspect it spreads in the usual fashion