Hace un tiempo escribí sobre una clásica vulnerabilidad de servidores Linux, más molesta que peligrosa y que de forma repetitiva ingresaba a ciertos servidores de Odoo. Con el auge de los sistemas automatizados, vivimos en una era de mil maravillas tecnológicas y también de los mil desastres. Esto es lo que sabemos.
Criptomineros insistentes
De momento, la lógica detrás de estos malwares es la misma que hace años: un minero cripto que utiliza el CPU del servidor para justamente minar criptos, haciendo que el Odoo funcione lento o trabado. Los ingresos se camuflan siempre como procesos de postgres lo que hace que sea difícil identificarlo aun con agentes de IA.
De hecho, no recomiendo simplemente dejar a un agente buscando esas vulnerabilidades, porque tienden a ignorar procesos de postgres. Los que los detectan a veces eliminan trazas que si son de postgres, o tienen problemas de permisos o exceso de los mismos.
La diferencia con los malwares anteriores es el increíble nivel de insistencia que tienen. Previamente, armaban un cron de linux para que no sean eliminados con facilidad, pero se ve que la información ya fue recibida y empiezan a mejorar. Actualmente se esconden muy bien en subprocesos, utilizan el usuario postgres para que no salen las alarmas fácilmente e incluso identifican el consumo de CPU para no ser detectados con tanta facilidad; esto produce que sistemas estén infectados durante meses. Por eso es importante el mantenimiento periódico de los sistemas, un buen técnico (lo que llamamos generalmente "arquitecto de sistemas") se da cuenta en pocos minutos si hay un proceso sospechoso ejecutándose, por más que esté consumiendo poco.
¿Cómo ingresa el malware?
Por el momento detecté dos y uno es muy común en odoo. Empecemos por el menos común: puerto expuesto de postgres. Generalmente conectan sistemas externos con el postgres de Odoo para hacer análisis de datos o powerBI, pero lo que vi mucho es que quien lo arma suele exponer el puerto por defecto de postgres (gran error) y encima a cualquier conexión externa. Hay mucha gente que trabaja muy bien pero también mucha que trabaja muy mal, o muy rápido. Errores como esos cuestan caro a largo plazo y se resuelve simplemente con coherencia al exponer puertos. Mi consejo es que trabajen sobre sistemas que tengan IP fija y que bloqueen todo ingreso externo a postgres desde una IP que no sea esa.
¿Y el error más común sobre Odoo? Las bases de datos duplicadas, de prueba o que quedan en el mismo sistema. Muchas veces tienen passwords de demo, las dejan inactivas durante años y son fuente de ingreso muy simples para infectar servidores. ¿De qué forma? Bueno, con acciones planificadas de Odoo; las generan en bases inactivas pero se siguen ejecutando, llamando scripts externos y a veces logrando ingresar al home del usuario que administra Odoo en debian. Y no, el dbfilter no hace nada ya que no inactiva las bases de datos, XMLRPC queda abierto; incluso eliminarlas con el manager de Odoo no siempre es efectivo, es preferible un DROP de raíz directamente.
¿Qué responsabilidad tiene Odoo?
Bueno, en si Odoo es un ERP muy sólido, acá la responsabilidad la tienen quien lo monta en un servidor particular. Entiendo que OdooSH estas cosas no pueden pasar tan fácil, aunque realmente no intenté replicarlo, después de todo si se puede ingresar al postgres desde OdooSH y crear accesos externos. Las bases de test ya son mas complejas.
Lo importante igualmente en todos los casos es el mantenimiento periódico; un equipo profesional que mensualmente esté al tanto de casos nuevos y pueda realizar las pruebas correspondientes en cada servidor vale muchísimo.