Time Flies – BIND, CentOS4 and Spammers

Its been over a month since I have been able to take a moment and say hello to my blog.  After my own time off, my colleagues have dared to take their own time off and I am stuck with extra work while they are gone.  What goes around, comes around, I guess.


In the meantime, the only work I have been able to do around here is moderate spammy comments to the trashbin.  Viagra, Online Loans, Escort services, they all seem to come over here with their bots and spam my admin panel with bogus comments with links back to their crap…



One thing I guess they are trying to exploit are the WordPress pingbacks.  Much to my annoyance since I really don’t mind speaking out loud to nobody on this blog, its crappy to have bots polluting my space with their spam.   I might try a WordPress CAPTCHA plugin of some sort, was too lazy to look for one since I didn’t figure I needed one….little did I know!


In any case, as time goes on, people still (*shiver*) running RHEL4/CentOS4 systems are getting more and more vulnerabilities.  CVE-2012-1823 being the first reasonably big bug that will go unpatched with RHEL4/CentOS4, and now BIND has announced CVE-2012-1667, a rather nasty one that apparently can in some cases expose system memory (!!!).  RHEL4 and clones shiiped with BIND 9.2, and it is of course vulnerable.  Thankfully systems I manage have been moved past EL4, however I do have a server or two that is still yet to be replaced.  I came across a blog that had shown promise of a rebuild of BIND 9.7.3 (which ships with CentOS 6.2 I believe), yet I was never able to get the .src.rpm for that.  I ended up building my own.  Its based on Fedora Linux’s FC14 9.7.4 RPM, with the 9.7.6_P1 source from ISC.ORG.  You can download my .src.rpm here.  I have tested it happily for a few weeks now, your mileage may vary.  Rebuild at your own risk! 🙂  I have it running on a mail server for DNS caching as well as a reasonably busy authoritative server and so far, no issues at all.    At least now RHEL4/CentOS4 can have allow-recursion { acl; } in named.conf!!! (yay)

Anyway, if you do download the source and compile it, let me know your results.


PHP updated – CVE-2012-1823 / CVE-2012-2311


A bug in PHP 5 was released, somewhat accidentally (apparently somebody made a reddit post public inadvertently…why people would use these sites for sensitive info is beyond me…anyhoo), and is finally patched by RedHat and derivatives, CentOS, ScientificLinux –


Ubuntu has also released a patch –


RHEL5&6 would be no longer vulerable to either CVE-2012-1823 or its re-incarnation CVE-2012-2311, as the bug was not correctly patched the first time around.   RedHat claims their fix is complete, I cannot vouch for Ubuntu so don’t blame me if you have to patch it again later.


The vulnerability itself was quite old, sneaking into the code 8 years ago and lying undiscovered until recently.  It relies on the use of php-cgi (running PHP as a cgi forked process, not in the more mainstream mod_php mechanism).  One of the many consequences of this bug was source code exposure (via ?-s), and many PHP sites having database username/password information contained in the PHP code, this vulnerability could and will compromise sites where this is the case that remain unpatched.  This is one of the many reasons it is a better idea to use PHP include functionality to provide database/user/password/security connnection info to PHP, and have that included file outside of the http webroot in the first place.  Other possible exploits would be to execute code/upload files on the remote filesystem….scary, nasty stuff!!!!

Even the allmighty Facebook, set for an IPO this week, was vulnerable to this (they were running as a cgi, apparently!!)

The IPO could have been something of a bust had Facebook been hacked a week before it hopes to raise 95$ billion USD.  Who would have seen that one coming?!?!?!?!


/bin/false, /sbin/nologin and SSH

It is common knowledge that if on a linux system, a local account is set to /bin/false or /sbin/nologin, that user cannot use SSH, right?




As one of my clients learned the hard way.  Alerted to the fact his server was blacklisted on a (large!) number of RBLs, we started investigating how and why spam was getting sent from his server.  What we found was that a local user account (listed in /etc/passwd) had been compromised, due to an easy to guess password.

On all the recent Linux distributions I attempted this on, it is possible to connect to the SSH daemon and initiate not a shell, but a TCP port forwarding session. Using /sbin/nologin as a shell only causes the SSH daemon to spawn a shell that closes immediately. So if you tell SSH not to spawn a shell, and use TCP port forwardings instead, you can then exploit the remote host.

Here is how it works.


if I create a user with [/bin/false|/sbin/nologin] as a shell, and give him a password. I can then SSH to the machine and forward a local port.

Like this:

[user@panel~]ssh -N testacct@linuxserver.cconn.info -L 2525:

this forwards my local port of 2525 to the remote port 25. Allowing me to spam via the remote server, via my local TCP 2525 socket I just created:

[user@panel ~] telnet localhost 2525
 Trying ::1...
 Connected to localhost.
 Escape character is '^]'.
 220 linuxserver.cconn.info ESMTP Sendmail 8.14.4/8.14.4; Sun, 6 May 2012 18:06:57 -0400

From “panel” I can connect to “linuxserver” over my ssh tunnel, and spam…my email appears to come from when you look at the headers, causing a certain level of difficulty in tracing the spam back to that account after the fact;

Received: from foo (localhost [])
 by linuxserver.cconn.info (8.14.4/8.14.4) with SMTP id q36MAbio019457
 for spambait@sucker.com; Sun, 6 May 2012 18:10:48 -0400

Why does this work?  Because sshd by default is configured, on my distros anyway, to use PAM for authentication, and has TCP port forwardings enabled by default.  If a shell listed in /etc/shells is configured for the account (/sbin/nologin is listed in /etc/shells), the password is valid and TCP port forwarding is enabled, this allows an account to establish said port forwardings and utilize services on the remote host.  Spam is an example, but there could be more.

How can this be fixed?


Well, there are a number of ways.  The simplest and most drastic, if possible in your scenario, is to simply disable TCP port forwarding in your sshd configuration file (/etc/ssh/sshd_config on many systems):

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no

However, note that this will not deny the actual ssh connection to be established; it will simply deny the ability to exploit the forwarding (see below);

ssh -N testacct@linuxserver.cconn.info -L 2525:
testacct@tohs.cconn.info's password:
channel 2: open failed: administratively prohibited: open failed
channel 2: open failed: administratively prohibited: open failed

The SSH session is allowed, however when I try to connect to my local 2525 TCP port, I note a “prohibited” error.  Therefore there is still room for exploitation possibly via DoS.  As far as I know however it is not possible to spam using this method 😉

Another way appears to be by not have the user shell listed in /etc/shells (/bin/false is not in every distro I checked).  Adding users with an invalid shell will invalidate this exact issue since sshd, via PAM, checks if the shell exists.  However, this will break any other system daemon that queries PAM for this very information, for example vsftpd/proftpd.  Therefore this “solution” is just a broken way of limiting ssh, however could have other, nasty consequences.

The other, smarter ways, would be to use AllowUser/AllowGroup directives in the sshd configuration, to specify exactly which users can and cannot connect.  And in all cases, it would be ideal to deny the ability to connect via SSH in iptables/ip6tables since OpenSSH has in the past (and likely will again) had security vulnerabilities that could be exploited to gain root access an pnwn the server :-\  As well, having your ssh socket open to the Internet attracts people to bruteforce scan your server, which is ugly in itself and causes a massive amout of syslog spam.