En la mitología griega, Chrono es el dios que personificaba el tiempo, y de él han llegado hasta nuestro tiempo las connotaciones temporales en nuestra cultura para muchos de nuestros términos. En los sistemas UNIX, cron es el daemon que gestiona la ejecución de las acciones planificadas a lo largo del tiempo, siguiendo una partitura escrita en el fichero crontab. Configurar este fichero y los comandos de cron es la manera de sacar partido al planificador de tareas en sistemas UNIX y conseguir que recurrentemente se hagan determinadas acciones.
En aplicaciones web, también es necesario realizar acciones planificadas de forma recurrente, centradas en lanzar tareas de mantenimiento, o para ejecutar funciones que tienen que suceder cada cierto tiempo. Muchos de los frameworks CMS de aplicaciones web (y los plugins de estos) que se utilizan habitualmente en muchos sitios de Internet necesitan esas funciones recurrentes planificadas, para lo que suelen crear un fichero que debe ser invocado cada cierto tiempo.
Figura 2: Arquitectura de ficheros cron en un CMS |
La forma en la que se configura esto habitualmente es mediante la introducción de una entrada en el fichero crontab del sistema que invoca un fichero donde se encuentran los comandos con las acciones que el framework necesita hacer recurrentemente. Si los comandos están basados en el motor del sitio web, es decir, el engine PHP, JSP o .NET, la invocación del fichero se hace mediante una llamada a una URL que está publicada en la web.
Figura 3: Ejecución de tareas configuradas en el fichero cron.php de un framework |
Cada vez que se realiza esa llamada a esa URL, la lista de tareas definidas dentro de ese script, que suele llamarse cron.php, cron.jsp o similares, es ejecutada a través del motor PHP, JSP o .NET que está soportando el sitio web. Y esto, si no se hace de forma segura, puede ser un problema para el sitio web.
Figura 4: Ejecución de recordatorios en el fichero cron.php de un plugin |
Los ficheros cron.php realizan acciones en el sitio web que pueden ser de mantenimiento, consumiendo a veces altas cargas de tiempo de CPU, volúmenes de datos o memoria RAM. Esto podría ser aprovechado por un adversario para hacer un ataque de Denegación de Servicio al sitio, pero además puede conllevar consumos económicos si es un sitio que está en un entorno Cloud de pago por consumo.
Figura 5: Invocación de un fichero cron.php de una instalación de Moodle |
En el artículo dedicado a Pentesting de Moodle en el blog de FWHIBBIT explicaban el otro día un caso concreto con el cron de este framework en muchas instalaciones, que además es bastante "verbose" y si no está protegido se puede ejecutar, en cada llamada, un consumo del sistema. En este caso, se puede ver al final del mismo la memoria que ha tomado la ejecución de estas acciones.
Figura 6: Resumen del consumo de la ejecución de las acciones de cron.php de un Moodle |
Estos ficheros, dependiendo del framework que se use, pueden tener diferentes nombres y formatos. En el caso de los sitios con instalaciones de WordPress, es común encontrarse con WP-Cron.php que se usan para la búsqueda de actualizaciones, la realización de copias de seguridad, o la publicación programada de artículos. Se pueden buscar en cualquier sitio web basado en WordPress y ver si existen o no en el sitio, si están prohibidos o permitidos e, incluso, ver si están correctamente configurados o no.
Figura 7: WP-Cron.php de un WordPress con errores de configuración |
Lo más curioso es que no solo los frameworks de aplicaciones web cuentan con estos ficheros cron.php para las acciones globales recurrentes o planificadas, sino que muchos plugins suelen tener sus propios ficheros de planificación de tareas que también se dan de alta en la configuración del daemon cron en el sistema.
Figura 8: Fichero cron.php para un plugin de WordPress |
En este ejemplo de la Figura 4, un plugin está enviando recordatorios cada vez que se invoca, y en el caso del plugin de BirthDayPresent, para el framework PrestaShop, se envía un e-mail cada vez que se ejecuta su cron.php a todas las personas que ese día cumplen años.
Figura 9: Fichero cron.php en plugin BirthdayPresent de PrestaShop |
Por supuesto, si un atacante puede invocar estos ficheros, existe un riesgo para la seguridad del sitio, por lo que se buscan diferentes estrategias de seguridad. Desde proteger el fichero para que solo pueda ser invocado por un usuario, para que solo pueda ser invocado desde una determinada dirección IP o para que se pueda pedir su ejecución solo con un token de seguridad.
Figura 10: Distintas protecciones en ficheros cron de plugins y frameworks |
Si esto no está protegido, entonces el sitio cuenta con un problema de seguridad que debe ser subsanado. Si tienes un CMS, con un framework, busca todos los ficheros con tareas para tu daemon cron y comprueba que todos ellos están protegidos contra una invocación no autorizada por parte de visitantes de tu web.
Saludos Malignos!
Muy bueno chema, siempre es una buena referencia tener en cuenta que las web realizan tareas programadas sin la intervención del usuario y que un atacante claramente las puede utilizar a su favor.
ResponderEliminarA mi me toco auditar varios WordPress en donde los atacantes no modificaron la web como defacement sino que agregaron scripts en el cron para lanzar una catarata de SPAM en determinadas horas del día.
Saludos!
ResponderEliminarHola Chema. Vi tu conferencia de la Universidad Europea de Madrid. Estuviste excelente, pero hay dos cosas que no entiendo,
1) Que estes dando clase a pijos de la UEA en lugar de en una Universidad Publica.
2) La referencia a Nadal y a Arria. Menos deportistas y posturistas, mas cirujanos y bomberos. Menos Steve Jobs, mas Steve Wozniak.
Gracias. Saludos benignos.