Re: [Dovecot] Security Hole in 1.0.13?
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 rootroot4096 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
Re: [Dovecot] Security Hole in 1.0.13?
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 rootroot4096 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
Re: [Dovecot] Security Hole in 1.0.13?
On Sun, May 18, 2008 at 10:03 AM, Lawrence Sheed [EMAIL PROTECTED] 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
Re: [Dovecot] Security Hole in 1.0.13?
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 rootroot4096 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
Re: [Dovecot] Security Hole in 1.0.13?
On Sun, May 18, 2008 at 10:19 AM, Lawrence Sheed [EMAIL PROTECTED] 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
Re: [Dovecot] Security Hole in 1.0.13?
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 Tomanekmailto:[EMAIL PROTECTED]
Re: [Dovecot] Security Hole in 1.0.13?
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
Re: [Dovecot] Security Hole in 1.0.13?
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
Re: [Dovecot] Security Hole in 1.0.13?
On 10:18:50 2008-05-18 Lawrence Sheed [EMAIL PROTECTED] 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
Re: [Dovecot] Security Hole in 1.0.13?
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
Re: [Dovecot] Security Hole in 1.0.13?
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 rootroot4096 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.
signature.asc
Description: This is a digitally signed message part
Re: [Dovecot] Security Hole in 1.0.13?
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? signature.asc Description: This is a digitally signed message part
Re: [Dovecot] Security Hole in 1.0.13?
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
Re: [Dovecot] Security Hole in 1.0.13?
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.
signature.asc
Description: This is a digitally signed message part
[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 rootroot4096 2008-05-18 13:30 dotvecot
drwxr-xr-x 3 root root4096 2008-05-18 13:47 .
drwxr-xr-x 18 root root4096 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
}
