Maybe a simple select on the mailbox table - it should by default increment the id for each new user. So, a simple select will show the accounts in the order they were created. You can look from the bottom up for the most recently created accounts.
su - zimbra
mysql
use zimbra;
select * from mailbox;
zimbra 0-day
-
Klug
- Ambassador
- Posts: 2767
- Joined: Mon Dec 16, 2013 11:35 am
- Location: France - Drôme
- ZCS/ZD Version: All of them
- Contact:
zimbra 0-day
I've seen a couple compromised servers (6.x).
The compromising IP seems to be the same than seen in this thread: 179.43.141.149.
The compromising IP seems to be the same than seen in this thread: 179.43.141.149.
zimbra 0-day
So I deal with the initial threat; clear out said server of the zimlet in question, corrupted admin acct, presumably add this guy's IP to our badguys list of ips to block...
and come back today to find *TWO* servers now compromised.
Turns out the more senior engineer was mistaken about the firewall's config re: zimbra. Fantastic. Iptables time.
The servers which were compromised were patched, btw, using the nginx method a previous poster linked to. So this time, I saw something more concerning when I found the new zimlets installed of "com_zimbra_example_simplejspaction2"
The code file was called xd.jsp; obviously indicating the humor the user felt at such an easy hack.
XD = huge laughing smile with eyes closed, for those who didn't know.
The method of entry this time I can't quite make out exactly how it was done, as stated before I turned off the LFC loophole by closing it within nginx (verified it's no longer accessible).
This time the audit log for the one server (Release 7.1.0_GA_3140.UBUNTU10_64 UBUNTU10_64 FOSS edition) only showed this:
2014-01-01 12:38:57,735 INFO [btpool0-15://XXXXXXXX:7071/service/admin/soap] [name=zimbra;ip=179.43.141.149;] security - cmd=AdminAuth; account=zimbra;
2014-01-01 12:38:57,772 INFO [btpool0-15://XXXXXXXX:7071/service/admin/soap] [name=zimbra;ip=179.43.141.149;] security - cmd=Auth; account=zimbra; protocol=soap;
2014-01-01 19:41:49,954 INFO [btpool0-15://XXXXXXXX:7071/service/admin/soap] [name=zimbra;ip=179.43.141.149;] security - cmd=AdminAuth; account=zimbra;
2014-01-01 19:41:50,002 INFO [btpool0-15://XXXXXXXX:7071/service/admin/soap] [name=zimbra;ip=179.43.141.149;] security - cmd=Auth; account=zimbra; protocol=soap;
Same thing on the original server that got hacked ( Release 8.0.2.GA.5569.UBUNTU12.64 UBUNTU12_64 NETWORK edition.):
179.43.141.149 - - [31/Dec/2013:21:25:36 +0000] "POST /service/admin/soap HTTP/1.1" 200 487 "-" "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36" 2
179.43.141.149 - - [31/Dec/2013:21:25:36 +0000] "POST /service/admin/soap HTTP/1.1" 200 27498 "-" "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36" 4
At this point I can't tell what hack they used to get in and am not really sure what I need to do to secure against it should said person use a different IP other than the 179 one they've been working nearly exclusively from. The big problem here is the chief engineer is out on vacation until next week and I'm not authorized to begin server upgrades since we need to setup a maintenance window/etc for them.
and come back today to find *TWO* servers now compromised.
Turns out the more senior engineer was mistaken about the firewall's config re: zimbra. Fantastic. Iptables time.
The servers which were compromised were patched, btw, using the nginx method a previous poster linked to. So this time, I saw something more concerning when I found the new zimlets installed of "com_zimbra_example_simplejspaction2"
The code file was called xd.jsp; obviously indicating the humor the user felt at such an easy hack.
XD = huge laughing smile with eyes closed, for those who didn't know.
The method of entry this time I can't quite make out exactly how it was done, as stated before I turned off the LFC loophole by closing it within nginx (verified it's no longer accessible).
This time the audit log for the one server (Release 7.1.0_GA_3140.UBUNTU10_64 UBUNTU10_64 FOSS edition) only showed this:
2014-01-01 12:38:57,735 INFO [btpool0-15://XXXXXXXX:7071/service/admin/soap] [name=zimbra;ip=179.43.141.149;] security - cmd=AdminAuth; account=zimbra;
2014-01-01 12:38:57,772 INFO [btpool0-15://XXXXXXXX:7071/service/admin/soap] [name=zimbra;ip=179.43.141.149;] security - cmd=Auth; account=zimbra; protocol=soap;
2014-01-01 19:41:49,954 INFO [btpool0-15://XXXXXXXX:7071/service/admin/soap] [name=zimbra;ip=179.43.141.149;] security - cmd=AdminAuth; account=zimbra;
2014-01-01 19:41:50,002 INFO [btpool0-15://XXXXXXXX:7071/service/admin/soap] [name=zimbra;ip=179.43.141.149;] security - cmd=Auth; account=zimbra; protocol=soap;
Same thing on the original server that got hacked ( Release 8.0.2.GA.5569.UBUNTU12.64 UBUNTU12_64 NETWORK edition.):
179.43.141.149 - - [31/Dec/2013:21:25:36 +0000] "POST /service/admin/soap HTTP/1.1" 200 487 "-" "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36" 2
179.43.141.149 - - [31/Dec/2013:21:25:36 +0000] "POST /service/admin/soap HTTP/1.1" 200 27498 "-" "Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.57 Safari/537.36" 4
At this point I can't tell what hack they used to get in and am not really sure what I need to do to secure against it should said person use a different IP other than the 179 one they've been working nearly exclusively from. The big problem here is the chief engineer is out on vacation until next week and I'm not authorized to begin server upgrades since we need to setup a maintenance window/etc for them.
-
13335lindsey
- Advanced member
- Posts: 68
- Joined: Fri Sep 12, 2014 11:21 pm
zimbra 0-day
To those of you fixing affected systems, don't forget to reset your LDAP and MySQL passwords.
On a different note, what's the best way to find out about vulnerabilities? There's nothing on the Twitter or Facebook pages, and no emails were received to the account registered to the forums. It's obviously not very efficient to keep checking into the forums regularly to check for security issues.
On a different note, what's the best way to find out about vulnerabilities? There's nothing on the Twitter or Facebook pages, and no emails were received to the account registered to the forums. It's obviously not very efficient to keep checking into the forums regularly to check for security issues.
zimbra 0-day
[quote user="mmessina"]Any one have an easy way to isolate the new users? My zimbra install that was compromised has several hundred accounts and while I sorted by most recent I was unable to find the offending account.[/QUOTE]
@mmessina:
yes, for me was very simple to do the following:
su zimbra
zmaccts
This will show you the accounts with the Created and Last Logon date. Hope will help you. Didn't help me because i found no new created account
@mmessina:
yes, for me was very simple to do the following:
su zimbra
zmaccts
This will show you the accounts with the Created and Last Logon date. Hope will help you. Didn't help me because i found no new created account
-
BloodyIron
- Advanced member
- Posts: 67
- Joined: Sat Sep 13, 2014 2:58 am
- Contact:
zimbra 0-day
Thanks for this thread guys!
I had a compromised system but I thought they had got in another way, been wrestling with it on and off for weeks.
I'm pretty sure this has isolated the issue as they never made elevated accounts on the local system, only ever one email account. They did run a lot of coin miners, omg that was annoying.
I saw two additional zimlets though, email_dns and backup (I think were the ones). I determined these weren't included by comparing dates and against another zimbra server (which is known to be clean) which didn't have the zimlets.
Now running 8.0.6 OSE ;o Thanks admins/devs!
I had a compromised system but I thought they had got in another way, been wrestling with it on and off for weeks.
I'm pretty sure this has isolated the issue as they never made elevated accounts on the local system, only ever one email account. They did run a lot of coin miners, omg that was annoying.
I saw two additional zimlets though, email_dns and backup (I think were the ones). I determined these weren't included by comparing dates and against another zimbra server (which is known to be clean) which didn't have the zimlets.
Now running 8.0.6 OSE ;o Thanks admins/devs!