Hola a todos. Por si a alguien le interesa he encontrado el archivo ejecutable que elimina de forma automática tanto algunos archivos PHP provistos por freePBX, como Java archives y .htacces, después de ser vulnerado con el exploit magnito o MesSI.
En mi caso, el ataque fue perpetrado por vulnerabilidades de a2billing en un sistema con elastix 4, freePBX-2.11.0-26, elastix-a2billing 2.2.0-0 sobre CentOS 7.
Como puede verse en este log de apache, fueron incrustados y ejecutados los archivos: asterisk/xyx.php, asterisk/3AZFCL1QVIP8L6I.php, asterisk/magnito.php y asterisk/turkish.php
216.218.206.69 - - [06/Dec/2017:07:34:36 -0600] "GET / HTTP/1.1" 200 5409
212.83.150.38 - - [06/Dec/2017:08:06:26 -0600] "GET /a2billing/common/javascript/misc.js HTTP/1.1" 200 102
162.243.250.164 - - [06/Dec/2017:08:19:32 -0600] "GET / HTTP/1.1" 200 5409
162.243.250.164 - - [06/Dec/2017:08:20:40 -0600] "POST //a2billing/customer/checkout_process.php HTTP/1.1" 200 -
162.243.250.164 - - [06/Dec/2017:08:20:41 -0600] "POST //a2billing/customer/checkout_process.php HTTP/1.1" 200 -
162.243.250.164 - - [06/Dec/2017:08:20:41 -0600] "GET //a2billing/admin/Public/A2B_entity_backup.php?path=/var/www/html/asterisk/xyx.php&form_action=add&name=check HTTP/1.1" 302 -
162.243.250.164 - - [06/Dec/2017:08:20:42 -0600] "GET /a2billing/admin/Public/PP_error.php?c=accessdenied HTTP/1.1" 200 2975
162.243.250.164 - - [06/Dec/2017:08:20:43 -0600] "POST //a2billing/admin/Public/A2B_entity_backup.php HTTP/1.1" 200 11
162.243.250.164 - - [06/Dec/2017:08:20:43 -0600] "POST //asterisk/xyx.php HTTP/1.1" 200 154194
162.243.250.164 - - [06/Dec/2017:08:20:44 -0600] "POST //asterisk/3AZFCL1QVIP8L6I.php HTTP/1.1" 200 1245
162.243.250.164 - - [06/Dec/2017:08:21:42 -0600] "GET //asterisk/3AZFCL1QVIP8L6I.php HTTP/1.1" 200 165
162.243.250.164 - - [06/Dec/2017:08:21:42 -0600] "POST //asterisk/3AZFCL1QVIP8L6I.php HTTP/1.1" 200 14
162.243.250.164 - - [06/Dec/2017:08:21:43 -0600] "POST /asterisk/magnito.php HTTP/1.1" 200 10
162.243.250.164 - - [06/Dec/2017:08:21:43 -0600] "POST /asterisk/magnito.php HTTP/1.1" 200 -
162.243.250.164 - - [06/Dec/2017:08:21:44 -0600] "POST //asterisk/turkish.php HTTP/1.1" 200 529
Seguí los pasos sugeridos en este foro para salvar la situación:
1.- Desinstalar elastix-a2billing: yum remove elastix-a2billing
2.- Eliminar la base de datos mya2billing: MariaDB [(none)]> drop database mya2billing;
3.- Eliminar el usuario 'a2billinguser': delete from mysql.user where user = 'a2billinguser';
4.- Cambiar las contraseñas del administrador de mysql y las de los usuarios asociados (admin, asterisk y asteriskuser) y actualizar el archivo amportal.conf
5.- Eliminar la carpeta /var/www/html/asterisk con todo su contenido: rm -Rf /var/www/html/asterisk
6.- Limpiar los archivos temporales en /tmp/ : rm -Rf /tmp/*
7.- Reinstalar freePBX: yum reinstall freePBX
8.- Cerrar o proteger el acceso público por https (puerto 443) para evitar nuevas intrusiones
Pero sin embargo, diariamente me encontraba nuevamente con archivos eliminados que estropeaban la GUI web como es descrito en las colaboraciones anteriores de este foro.
Me dí a la tarea de hacer el análisis forense, encontrando lo siguiente:
En la base de datos asterisk, en la tabla cronmanager, me topé con lo siguiente.
En uno de mis equipos, el contenido de dicha tabla era:
MariaDB [asterisk]> select from cronmanager;
+---------------+-----------+------+------+------------+-----------------------------------------------+
| module | id | time | freq | lasttime | command |
+---------------+-----------+------+------+------------+-----------------------------------------------+
| module_admin | UPDATES | 21 | 24 | 1513126261 | /var/lib/asterisk/bin/module_admin listonline |
| system_update | every_day | 1 | 24 | 0 | /tmp/check.system |
+---------------+-----------+------+------+------------+-----------------------------------------------+
para el que no había ya mayor afectación, después de eliminar el contenido de /tmp. Pero en otro equipo, igualmente vulnerado, el campo 'command' era algo diferente:
select from cronmanager;
+---------------+---------+------+------+------------+-----------------------------------------------+
| module | id | time | freq | lasttime | command |
+---------------+---------+------+------+------------+-----------------------------------------------+
| module_admin | UPDATES | 21 | 24 | 1513120741 | /var/lib/asterisk/bin/module_admin listonline |
| system_update | UPDATES | 0 | 24 | 1513145942 | /var/lib/asterisk/bin/check.system |
+---------------+---------+------+------+------------+-----------------------------------------------+
Y ese, "check.system" es justo el ejecutable maldito que el atacante logró incrustar hasta /var/lib/asterisk/bin/
file check.system
check.system: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=7084322a576c807cdc679afa2aa444b5fd76cbf4, not stripped
Hay que agregar entonces a la lista, un número 9:
9.- Eliminar de cronmanager, el comando para el supuesto módulo 'system_update' : delete from cronmanager where module = 'system_update'; Y desde luego, el ejecutable mismo: rm -f /var/lib/asterisk/bin/check.system
Sólo restaría averiguar, el mecanismo exacto que llevó a incrustar un ejecutable hasta /var/lib/asterisk/bin
¡Que los desarrolladores tomen nota por favor!
Espero a alguien le sirva. Saludos