[Dovecot] Security Hole in 1.0.13?
I'm running 1.0.13
If I run dovecot for a while, I see a /var/run/dotvecot folder created
with the following:
drwxr-xr-x 3 root root 4096 2008-05-18 13:30 dotvecot
drwxr-xr-x 3 root root 4096 2008-05-18 13:47 . drwxr-xr-x 18 root root 4096 2008-05-18 13:47 .. srw------- 1 root root 0 2008-05-18 13:47 auth-worker.15138 srwxrwxrwx 1 root root 0 2008-05-18 13:47 dict-server drwxr-x--- 2 root dovecot 4096 2008-05-18 13:47 login -rw------- 1 root root 6 2008-05-18 13:47 master.pid
It appears to be created by imap-login
I've tried removing any dovecot remnants and reinstalling from the
1.0.13 tar.gz from the site.
After starting dovecot again after a few minutes the files appear.
The processes are running something on 6243 and 6244
(Presumably an exploit / login)
I have iptables setup to only allow existing ports in/out so I think
thats saved me so far.
I've switched to courier-imap in the interim.
Anyone want to assist in finding out how they are getting in?
Definitely dovecot related. If I don't run dovecot, seems secure. As
soon as I run dovecot, after a few minutes - rooted...
dovecot.conf
cat /etc/dovecot/dovecot.conf
base_dir = /var/run/dotvecot
protocols = imap imaps
listen = *
disable_plaintext_auth = no
shutdown_clients = yes
syslog_facility = local7 #<-- Ensure this is set up in syslog
conf
ssl_disable = no
login_max_processes_count = 128
login_max_connections = 256
login_greeting = K-Tex IMAP Server # <-- CUSTOMISE
FORYOUR SITE
login_process_size = 64
login_process_per_connection = yes
login_processes_count = 16
ssl_cert_file = /var/qmail/control/servercert.pem # /usr/local/etc/ssl/ italy1-cert.pem ssl_key_file =/var/qmail/control/clientcert.pem # /usr/local/etc/ssl/ italy1.pem
first_valid_uid = 89 first_valid_gid = 89
protocol imap { listen = *:143 ssl_listen = *:993 #mail_plugins = quota imap_quota #login_greeting_capability = no mail_plugin_dir = /usr/local/lib/dovecot/imap imap_client_workarounds = outlook-idle }
auth_process_size = 512 auth_cache_size = 512 auth_cache_ttl = 3600 auth default { mechanisms = plain
# vpopmail authentication passdb vpopmail { #args = }
# vpopmail userdb vpopmail { }
user = root }
dict { #quota = mysql:/etc/dovecot-dict-quota.conf }
plugin { quota = maildir }
namespace private { prefix = INBOX. inbox = yes }
On Sun, May 18, 2008 at 8:52 AM, Lawrence Sheed < lawrence@computersolutions.cn> wrote:
I'm running 1.0.13
If I run dovecot for a while, I see a /var/run/dotvecot folder created with the following:
drwxr-xr-x 3 root root 4096 2008-05-18 13:30 dotvecot
drwxr-xr-x 3 root root 4096 2008-05-18 13:47 . drwxr-xr-x 18 root root 4096 2008-05-18 13:47 .. srw------- 1 root root 0 2008-05-18 13:47 auth-worker.15138 srwxrwxrwx 1 root root 0 2008-05-18 13:47 dict-server drwxr-x--- 2 root dovecot 4096 2008-05-18 13:47 login -rw------- 1 root root 6 2008-05-18 13:47 master.pid
It appears to be created by imap-login
I've tried removing any dovecot remnants and reinstalling from the 1.0.13 tar.gz from the site. After starting dovecot again after a few minutes the files appear.
What is the problem according to you??? Excuse me for being blind to it if it is really there, but this appears okay to me! In your dovecot.conf, you have the following:
base_dir = /var/run/dotvecot
Given that it's actually your own typo putting that in place, how does that constitute a security hole?:-)
The processes are running something on 6243 and 6244
What are those? tcp ports??? pids??
(Presumably an exploit / login)
Oh, how? Your question is simply not clear to me at all, but that could be because I am not quite an security expert to see the obvious.
I have iptables setup to only allow existing ports in/out so I think thats saved me so far.
I've switched to courier-imap in the interim.
Anyone want to assist in finding out how they are getting in?
Definitely dovecot related. If I don't run dovecot, seems secure. As soon as I run dovecot, after a few minutes - rooted...
???
Lemme watch this in the periphery! I run dovecot-1.0.13 on over 20 hosts so I could be "rooted" as well. However, my setups tell dovecot to listen to ports 110 and 143 only and I have never observed anything strange.
Timo has some good amount of money to offer you if you could prove that there is a security exploit, but I don't see you getting even 0.001% of that amount just with the information you've provided here. Aren't you just being paranoid? Could you please provide more information that can make someone "see" what you are scared of?
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223
"Oh My God! They killed init! You Bastards!" --from a /. post
ROFL...
This was a good way to start the day...
Correct your typo in the dovecot.conf file ;)
Here's a hint ;) See base_dir...
drwxr-xr-x 3 root root 4096 2008-05-18 13:30 dotvecot
dovecot.conf
cat /etc/dovecot/dovecot.conf base_dir = /var/run/dotvecot
-- Andraž "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker
Be sure brain is in gear before engaging mouth. Ryle hira.
Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
Corrected that in the conf file.
If I check the dovecot user, I see its been compromised also - a bunch
of crap in their login folder.
I didn't create the dovecot.conf with a /var/run/dotvecot though, so
someone else did that.
More updates as I check further.
On May 18, 2008, at 2:54 PM, Andraž 'ruskie' Levstik wrote:
ROFL...
This was a good way to start the day...
Correct your typo in the dovecot.conf file ;)
Here's a hint ;) See base_dir...
drwxr-xr-x 3 root root 4096 2008-05-18 13:30 dotvecot
dovecot.conf
cat /etc/dovecot/dovecot.conf base_dir = /var/run/dotvecot
-- Andraž "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker
Be sure brain is in gear before engaging mouth. Ryle hira.
Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
On Sun, May 18, 2008 at 10:03 AM, Lawrence Sheed < Lawrence@computersolutions.cn> wrote:
Corrected that in the conf file.
If I check the dovecot user, I see its been compromised also - a bunch of crap in their login folder. I didn't create the dovecot.conf with a /var/run/dotvecot though, so someone else did that.
More updates as I check further.
If you allow your system to be compromised, you cannot attribute that to a particular application, unless you can prove the fact that that application led to the security hole. For now, it's easy to just take that 0wn3d host offline and deal with it - or just format the damn thing as it'll not be easy to track down the hole(s) now existing on your system. I'd do that, but I'd have to record that as a major milestone in my sysadmin life since I've never been so luck to get v1s1t3d by aliens:-)
Get the humor flowing.... I was having a really boring Sunday!
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223
"Oh My God! They killed init! You Bastards!" --from a /. post
Typically before I kill a system thats been compromised, I try to find
out the reason, so it DOESNT happen again.
In this instance I have 2 systems with exactly the same "issue"
Both were running smoothly until about last week, then load spikes
were observed.
In both systems, the the attacker has changed the dovecot.conf to
point at dotvecot
I'm guessing around the 13th as thats when the /var/run/dovecot folder
was updated.
I'll do the rest offlist.
Andraz, thank you. Washington, you're an asshole.
Cheers,
Lawrence.
On May 18, 2008, at 3:03 PM, Lawrence Sheed wrote:
Corrected that in the conf file.
If I check the dovecot user, I see its been compromised also - a
bunch of crap in their login folder. I didn't create the dovecot.conf with a /var/run/dotvecot though, so
someone else did that.More updates as I check further.
On May 18, 2008, at 2:54 PM, Andraž 'ruskie' Levstik wrote:
ROFL...
This was a good way to start the day...
Correct your typo in the dovecot.conf file ;)
Here's a hint ;) See base_dir...
drwxr-xr-x 3 root root 4096 2008-05-18 13:30 dotvecot
dovecot.conf
cat /etc/dovecot/dovecot.conf base_dir = /var/run/dotvecot
-- Andraž "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker
Be sure brain is in gear before engaging mouth. Ryle hira.
Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
On Sun, May 18, 2008 at 10:19 AM, Lawrence Sheed < Lawrence@computersolutions.cn> wrote:
Typically before I kill a system thats been compromised, I try to find out the reason, so it DOESNT happen again.
In this instance I have 2 systems with exactly the same "issue"
Both were running smoothly until about last week, then load spikes were observed.
In both systems, the the attacker has changed the dovecot.conf to point at dotvecot I'm guessing around the 13th as thats when the /var/run/dovecot folder was updated.
I'll do the rest offlist.
Andraz, thank you. Washington, you're an asshole.
I agree, but ..... It's made you come up with more details to make someone start thinking. Now you are heading towards Timo's cash offer to anyone who can discover and point out a security hole in dovecot, but you are a little far away still. We are all interested in what you find out ultimately, and I stop being an asshole now, so please share with us everything. As I told you, I run same version of dovecot as you on over 20 servers. They are all FreeBSD and configured the same in all aspects except domain names/ip addresses. Your discovery could help me and others as well.
-- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223
"Oh My God! They killed init! You Bastards!" --from a /. post
Are you perhaps running a debian host with compromised keys(see recent debian+ssl issues)?
-- Andraž "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker
Be sure brain is in gear before engaging mouth. Ryle hira.
Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
I am running Debian on both servers, but updated both the keys and the
ssh server as I saw it on Slashdot.
(A few days ago).
The intrusion seems to be around the 13th. They changed the dovecot configuration (as noted).
If I turned off the iptables firewalling, I see that
port 6244 and 6243 had something running on them if I checked from a
non-compromised server.
An nmap from the compromised server (including those ports in the
scan) showed nothing.
rkhunter showed nothing untoward.
Other relevant details.
I'm running /tmp as noexec and nosu.
unused ports are firewalled (which is probably what saved me from
being horribly compromised).
Certain files are root only
(I have a daily script which does)
chmod 750 /usr/bin/rcp
chmod 750 /usr/bin/wget
chmod 750 /usr/bin/lynx
chmod 750 /usr/bin/links
chmod 750 /usr/bin/scp
This usually stops script kiddies.
Also have fail2ban running for ssh and ftp dictionary attacks.
I saw a couple of strange things in the imap logs related to ssh*-dist
(can't remember the exact wording, and those logs are gone
unfortunately)
I run 5 servers with similar setups - although some are running 1.0.9
(which I've upgraded to 1.0.13 on all), although I'm running courier-
imap on them for the moment just to be sure.
2 out of 5 had the /var/run/dotvecot folder appear around the 13th.
I hadn't made any changes to dovecot other than updates as new
releases come out.
I'm not sure if the dict line in the dovecot.conf was there before.
It's not on most of the setups, but appears in both of the affected
ones.
I'm going to reinstall one of the affected servers, but can leave the
second running for a little while.
Any other thoughts (positive ones), or things you'd like me to post?
On May 18, 2008, at 4:02 PM, Andraž 'ruskie' Levstik wrote:
Are you perhaps running a debian host with compromised keys(see recent debian+ssl issues)?
-- Andraž "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker
Be sure brain is in gear before engaging mouth. Ryle hira.
Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
On 10:18:50 2008-05-18 Lawrence Sheed Lawrence@computersolutions.cn wrote:
I am running Debian on both servers, but updated both the keys and the ssh server as I saw it on Slashdot.
(A few days ago).
The intrusion seems to be around the 13th. They changed the dovecot configuration (as noted).
Could have happened then or a few days before that... Thi issue was around for a lot longer than since it was announced :)
-- Andraž "ruskie" Levstik Source Mage GNU/Linux Games grimoire guru Geek/Hacker/Tinker
Be sure brain is in gear before engaging mouth. Ryle hira.
Key id = F4C1F89C Key fingerprint = 6FF2 8F20 4C9D DB36 B5B6 F134 884D 72CC F4C1 F89C
Hello Lawrence,
Sunday, May 18, 2008, 9:19:40 AM, you wrote:
I'll do the rest offlist.
Please don't. Finding out it wasn't your Dovecot installation that was compromised is valuable information here (as is the opposite, of course).
-- Best regards, Robert Tomanek mailto:dovecot@mail.robert.tomanek.org
On Sun, 2008-05-18 at 15:03 +0800, Lawrence Sheed wrote:
Corrected that in the conf file.
If I check the dovecot user, I see its been compromised also - a bunch
of crap in their login folder.
What crap? By login folder do you mean /var/run/do[t]vecot/login? It's supposed to have some files in it. If they're clearly not created by Dovecot, could you send them to me?
On Sun, 18 May 2008, Lawrence Sheed wrote:
Anyone want to assist in finding out how they are getting in?
How about setting up rawlog? Details in the Wiki.
Definitely dovecot related. If I don't run dovecot, seems secure. As
soon as I run dovecot, after a few minutes - rooted...
Is your dovecot configuration writable by the dovecot user? It shouldn't.
What happens if you set the "+i" flag (immutable) with chattr on Linux (or schg on BSD, JFTR if someone else ), to prevent changes to the dovecot.conf file?
Can you obtain working and statically linked ps, top, netstat copies from an uncompromised system or a known-good live CD?
-- Matthias Andree
On Sun, 2008-05-18 at 13:52 +0800, Lawrence Sheed wrote:
It would be helpful to have some more information, such as:
If I run dovecot for a while, I see a /var/run/dotvecot folder created
with the following:drwxr-xr-x 3 root root 4096 2008-05-18 13:30 dotvecot .. I've tried removing any dovecot remnants and reinstalling from the
1.0.13 tar.gz from the site. After starting dovecot again after a few minutes the files appear.
Even if you change base_dir back to /var/run/dovecot? What if you unplug the network, does it still come back too?
The processes are running something on 6243 and 6244
netstat -ln don't show them? That would mean the attacker gained root access, which is very unlikely to have happened directly through Dovecot (but getting non-root via Dovecot -> root via some other exploit is possible of course).
passdb vpopmail { #args = }
vpopmail would be one possibility, I have some doubts about its security.
On Sun, 18 May 2008, Timo Sirainen wrote:
passdb vpopmail { #args = }
vpopmail would be one possibility, I have some doubts about its security.
Can you detail the spots you deem could take some more observation or investigation? vpopmail, after all, is highly popular in qmail environments which boast about their "security" (which is partially based on "proof by claim" like arguments and sometimes 'substantiated' by ad-hominem attacks of certain groups of people who can't bear criticism).
-- Matthias Andree
On Sun, 2008-05-18 at 12:45 +0200, Matthias Andree wrote:
On Sun, 18 May 2008, Timo Sirainen wrote:
passdb vpopmail { #args = }
vpopmail would be one possibility, I have some doubts about its security.
Can you detail the spots you deem could take some more observation or investigation?
I haven't looked at its code for several years now, but when I was implementing support for it the code didn't look all that secure. For example I had to add a workaround to Dovecot to make it work at all, because parse_email() didn't correctly NUL-terminate the output string:
/* vpop_user must be zero-filled or parse_email() leaves an
extra character after the user name. we'll fill vpop_domain
as well just to be sure... */
memset(vpop_user, '\0', VPOPMAIL_LIMIT);
memset(vpop_domain, '\0', VPOPMAIL_LIMIT);
if (parse_email(request->user, vpop_user, vpop_domain,
VPOPMAIL_LIMIT-1) < 0) {Also a quick look at its sources again shows that it uses strncpy() and strncat() wrong pretty much everywhere. Especially the strncat() calls are no better at protecting against buffer overflows than strcat().. But I don't know if any of these are actually exploitable. Probably not.
participants (7)
-
"Andraž 'ruskie' Levstik"
-
Lawrence Sheed
-
Lawrence Sheed
-
Matthias Andree
-
Odhiambo Washington
-
Robert Tomanek
-
Timo Sirainen