Voy a estrenar el blog hablando de una “anécdota laboral” -por llamarlo de alguna manera- no demasiado agradable.
La empresa para la que trabajo se ha adjudicado el concurso de una importante multinacional para llevar la gestión integral de una intranet mediante la que prestan servicios de marketing y formación a empleados, clientes y colaboradores. Se trata de un servicio bastante completo: máquinas, software y contenidos. A mí me toca la parte de software.
Parece ser que la agencia saliente, que ha estado desarrollando la plataforma durante varios meses, no ha aceptado de buen grado que un competidor le levante un cliente, pese a que es algo muy normal y absolutamente cotidiano. Y bastante sano, añadiría.
La cosa ya empezó a oler mal cuando dimos inicio a los trámites para el traspaso del proyecto desde la infraestructura del antiguo proveedor a la nuestra: se negaron a enseñarnos las “tripas” del proyecto hasta una fecha concreta, que sería el día después ofrecernos una sesión de “formación” para la gestión de la plataforma. Un training de esos.
Y en la capital del Reino me planté, junto a mi compañero de fatigas, para que nos contaran la película. Y empezó bastante bien: la plataforma se ha construido sobre WordPress, un entorno en el que me manejo con relativa soltura y que, además, viene vestido con un theme a medida y aparentemente de buena calidad, además de un diseño impecable propio de un buen profesional.
Antes de entrar al edificio del cliente ya nos avisaron los compañeros de la oficina de Madrid de que los de la otra agencia no venían precisamente en son de paz, pero las sensaciones fueron bien distintas a medida que avanzaba el encuentro. Éramos muchas personas allí: unos cinco o seis por la parte del cliente, otros cuatro o cinco por nuestra parte y tres por la parte de la agencia que nos traspasaba el proyecto.
La gestión de la plataforma está bien planteada: vamos a poder dar de alta a cerca de diez mil usuarios mediante la importación de un fichero CSV generado por el CRM del cliente; la gestión de los contenidos es prácticamente la nativa de WordPress y encima vamos a tener a una nueva persona en el equipo que se encargaría de actualizarlos. Nos facilitaron los accesos a su servidor para que nosotros mismos moviéramos el proyecto de una máquina a otra, nos dieron un pendrive con la documentación y nos despedimos de la forma más cordial: asunto despachado en cuestión de hora y media. Teníamos apenas un mes para hacer la migración, y yo ya me había calculado que al día siguiente podríamos tenerlo funcionando en nuestro servidor. Era hora de volver a casa.
Demasiado bonito para ser verdad
Tras un pequeño tira y afloja de varios días para conseguir que nos traspasaran la gestión del dominio del proyecto pudimos levantar la plataforma, y en muy poquito tiempo: sube archivos, importa bases de datos, configura unos cuantos parámetros en el servidor y a correr. Es algo que hago todos los días y no tenía por qué suponer un problema.
No fue hasta varios días después cuando empecé a sospechar que lo que tenía entre manos era lo que yo llamo un regalito. Un auténtico marrón envuelto de un precioso papel de regalo y rematado con el lazo de un traspaso de poderes modélico: scripts que fallan porque la base de datos no está bien diseñada, inputs sin ningún tipo de control, funcionalidades fallidas que no han sido retiradas del código… Puedo decir que no abro un fichero del proyecto que no huela a prisas, chapuzas y nula planificación, y sobre todo que no de sensación de inseguridad.
Pero el colmo de todo -y el motivo que me ha animado a escribir este post– es lo que ves en la imagen que lo ilustra. Para los que no sepan qué significa, lo explico rápidamente: se trata de un script PHP al que le pasas como parámetro la ruta de un archivo cualquiera (repito: cualquiera) del servidor, lo localiza, lo descarga y posteriormente lo elimina. Su nombre: download.php.
No me sonaba en absoluto que la plataforma tuviese alguna característica relacionada con la descarga de ficheros, de modo que me dispuse a revisar la documentación que nos habían pasado, que por cierto es escasa y mala: un manual de WordPress pasado a bonito con cero referencias al código que la agencia había generado. Efectivamente no hay documentada ninguna funcionalidad en la plataforma que permita descargar ficheros, por lo que ya eran dos las incógnitas:
¿Para qué sirve ese script?
En un costoso intento de no ser malpensado interpreté que podía tratarse de un sistema mediante el cual la plataforma generaría algún tipo de archivo confidencial que se autodestruye justo tras ser descargado por parte del usuario. Creo que cualquiera que de pequeño haya visto algún episodio de “El Inspector Gadget” habría pensado lo mismo. Sin embargo, esta hipótesis es poco probable, toda vez que ya tenía más o menos confirmado que no hay nada que descargar en la plataforma y que además el script es accesible aunque no hayas iniciado sesión, lo cual me lleva a la siguiente incógnita:
¿Por qué el script puede ser ejecutado sin iniciar sesión en el sistema?
Reconozco que en ese momento ya había formulado una teoría sobre lo que estaba pasando, pero quería buscar una respuesta tranquilizadora antes de informar al cliente de mi hallazgo. Y no la encontré. ¿Para qué se escribe un programa que permita descargar y eliminar un archivo de un servidor?
Cualquiera que tenga nociones básicas de programación se ha dado cuenta rápidamente de la verdadera gravedad del asunto: hablamos de un script que que borra archivos, que puede ser llamado desde cualquier sitio sin ningún control y dentro de una plataforma basada en WordPress, un CMS que se identifica sólo con ojear el código fuente en el navegador. ¿Sabéis en qué pensé primero? En ejecutarlo y pasarle como parámetro el conocidísimo archivo de configuración de WordPress, llamado “wp-config.php” y que está alojado en la raíz de todas las web hechas así. El resultado fue, ni más, ni menos, el esperado: acababa de descargarme el fichero que contiene las credenciales de acceso a la base de datos y un montón de información adicional que permitirían a un tío malo malote hacer un montón de cosas chungas con la web. Pero es que encima el archivo ya no estaba: había sido eliminado por el script y la web ya no funcionaba. Esta vez no fui capaz de articular una hipótesis benévola y me limité a anular la línea de código que se encarga de borrar el fichero que se especifique y a avisar al cliente de que no me voy a responsabilizar de un proyecto que tiene un agujero de seguridad del tamaño de Pakistán. Y la empresa tampoco, como es obvio.
Mi hipótesis era ya una teoría. Presuntamente, el desarrollador “coloca” ese script, así, como el que no quiere la cosa, por si el cliente en el futuro deja de pagar el mantenimiento o simplemente le apetece en el futuro hacer algo de caja tan solo pulsando el botón rojo, descargando su archivo, rompiendo la web y esperando pacientemente la llamada de un cliente histérico que está dispuesto a dejarse unos cuantos cientos de euros para que la agencia se limite a reponer un archivo y a culpar al becario por tocar donde no debe. Brillante, pero es un truco más antiguo que el hilo negro.
Sé que es una acusación grave porque estaríamos hablando de un delito sobre el que hay muchos casos que han sido juzgados y sentenciados con condenas nada desdeñables. Honestamente, espero que con el paso de los días alguien me aclare que simplemente se trata de un código de mala calidad que ciertamente sirve para algo, pero hasta el momento nadie ha dado explicaciones por un asunto que, en mi opinión, es bastante jodido.
Me ha llevado un par de días escribir este post y podría seguir hablando de más perlas que me he ido encontrando en el código del proyecto (el último, otro script que, esta vez, permite manejar remotamente la base de datos y que también ha sido convenientemente desactivado). El cliente ya está al tanto del problema, ha sabido entender nuestra postura y ya ha encargado a su equipo de IT la preceptiva auditoría que este regalito merece.
Continuará…
