Cuando los clientes interactúan con su negocio, lo más probable es que pasen por una aplicación web primero. Es la cara pública de su empresa – y por ese simple hecho, un punto obvio de vulnerabilidad.

La mayoría de los ataques contra las aplicaciones web son sigilosos y difíciles de detectar. Eso es un problema, porque una vez que los atacantes entran, pasan desapercibidos en las redes por un promedio de 205 días, según el Reporte del 2015 de Verizon Data Breach Investigations. La mayoría de las organizaciones se enteran que han sido comprometidas por otra persona, por ejemplo, cuando reciben una llamada de la policía o un cliente furioso.

¿Cómo saber si su aplicación web ha sido hackeada? “Cuando se ve comprometida, empezará a hacer cosas fuera de lo normal”, señaló Steve Durbin, director general de Information Security Forum. La clave es obtener un conocimiento profundo de lo que constituye un comportamiento normal para su aplicación, para luego mantener los ojos bien abiertos en caso de aberraciones.

Aquí hay cinco señales de que su aplicación web ha sido comprometida -y por dónde comenzar su investigación. También encontrará algunos consejos de sentido común sobre la seguridad de su aplicación web, haya o no sido hackeada.

Señal No. 1: La aplicación no está haciendo lo que debería

El monitoreo de aplicaciones es la mejor manera de darse cuenta si algo sospechoso está ocurriendo.

Tal vez la aplicación ahora se demora mucho más tiempo en cargar la página de resultados de la base de datos que antes. Puede ser que esté mostrando páginas en momentos inesperados o redirigiendo a los usuarios a una página diferente. Quizá el tráfico de redes ha incrementado, pero no hay ninguna campaña de marketing de acompañamiento para explicar el aumento. Por ejemplo, una tienda web pequeña que normalmente tiene unos 50 pedidos al día, debe cuestionar un día con cinco mil pedidos.

Por supuesto que estos no necesariamente son indicadores de una aplicación web comprometida. Que las páginas se demoren en cargar puede ser fácilmente el resultado de los problemas de conectividad temporales -o incluso un ataque DDoS, si cree que los atacantes tendrían alguna razón para lanzar uno. Pero siempre es mejor investigar algo raro de inmediato en lugar de esperar una perturbación importante.

Si la aplicación redirige a los usuarios a una página diferente, averigüe por qué. ¿Acaso un anuncio malicioso se ha apoderando de la función de la página? ¿Se ha modificado el código de la página recientemente? ¿La información de la base de datos ha sido manipulada? Interactúe regularmente con la aplicación en el entorno de producción para analizar el comportamiento normal, de modo que los comportamientos inesperados puedan ser identificados de forma inmediata para su investigación.

Señal No. 2: Encuentra mensajes de registro inesperados

Los registros pueden ser una mina de oro de información de ataque si son configurados correctamente. Moviéndose a través de registros de la base de datos, se pueden mostrar consultas inesperadas y revelar cuándo es que la información se desechará. Si estos muestran múltiples errores en un corto período de tiempo, puede ser una señal de que alguien está dentro de la aplicación buscando -o ya ha encontrado- un vector de inyección SQL. Determine dónde se originaron las consultas de la base de datos y asegúrese de que la aplicación esté manejando correctamente los inputs.

El software de su servidor web puede registrar las conexiones de entrada y de salida de la red a través de los registros del sistema FTP y HTTP. (Están encendidos, ¿verdad?) Esos registros pueden recoger señales de advertencia de actividad no autorizada o maliciosa.

Generalmente, los servidores web solamente deberían iniciar conexiones con bases de datos internas. Si existen conexiones de red salientes desde el servidor web hacia direcciones IP públicas, es el momento de preguntar por qué. Las transferencias de archivos inexplicables muestran que los datos están abandonando el servidor web. Eso podría ser un indicio de que los atacantes ya han desviados los datos de la aplicación y están transfiriendo los contenidos a servidores remotos.

No debe concentrarse tanto en aquello que se mueve fuera de la red, pues puede empezar a ignorar el movimiento lateral. Si el servidor web se está comunicando con otros recursos de la red interna, tales como los shares de los archivos de usuario y computadoras de usuarios individuales, puede ser una señal de que los atacantes han logrado entrar y se mueven alrededor de la red. Si la aplicación permite a los usuarios cargar archivos, entonces asegúrese que utiliza un servidor dedicado de archivos y no uno general empleado dentro de la empresa, por ejemplo.

Al igual que los registros del servidor, los registros de la aplicación pueden avisarle cuando las cosas van mal, siempre que hayan sido configurados correctamente y sean vigilados. Asegúrese de que la aplicación registre las tareas de nivel administrativo, como la creación de cuentas de usuarios, o de administrador. Si la aplicación crea cuentas a nivel de administrador u otras privilegiadas, verifique que estas sean legítimas -no establecidas por los atacantes.

Las aplicaciones web también deben mostrar cuándo los administradores inician sesión, por lo que debe comprobar regularmente el acceso desde lugares y momentos inesperados. Verifique lo que las cuentas de administrador están haciendo. Casos inexplicables de acceso a la cuenta de administrador de aplicaciones web suelen ser un fuerte indicador de una violación.

Si hay un aumento en el número de errores relacionados con los envíos de formularios o más errores aparecen cuando se cargan las páginas, es probable que la aplicación está tratando de hacer algo para lo que no fue diseñada. Si nota un aumento en los errores, localice la página que los está provocando y averigüe qué puede haber cambiado.

Señal No. 3: Encuentra nuevos procesos, usuarios, o puestos de trabajo

Vigile los procesos que se ejecutan en el servidor web, para detectar cuándo el servidor genera procesos desconocidos o ejecuta un proceso conocido en un momento inusual. Un proceso desconocido es generalmente una gran pista de que su aplicación ya no está bajo control.

Una vez que un atacante tiene una cuenta en el servidor, hay poco que éste no pueda hacer. Monitoree regularmente el servidor para los usuarios que están siendo creados, especialmente aquellos con privilegios elevados. Esas cuentas no son típicamente creadas sobre la marcha, así que vale la pena hacer un seguimiento siempre que se crea una nueva. Si ciertos usuarios que no deberían estar solicitando privilegios elevados o acceso de root, repentinamente empiezan a hacer esas solicitudes, es posible que esté presenciando al atacante usando una credencial robado.

Adquiera el hábito de mirar los crontabs en los servidores de Linux o Scheduled Tasks en los de Windows, y de saber cómo se ven las entradas normales. Si se añaden nuevos puestos de trabajo, ese podría ser un indicio de que la aplicación está haciendo algo inesperado. Tal vez sea solo un trabajo de mantenimiento específico -pero podría ser el intento de un atacante para obtener la aplicación, con el fin de llamar periódicamente para obtener nuevas instrucciones del servidor de comando y control. El atacante también podría estar enviando datos extraídos en pequeños lotes automatizados a un servidor remoto.

Señal No. 4: Los archivos han cambiado

¿Las marcas de tiempo en los archivos de la aplicación web muestran que archivos que cambió por última vez hace años, han sido editados recientemente? Si el servidor web no fue configurado correctamente o la aplicación tiene una vulnerabilidad, los atacantes podrían modificar la aplicación para ejecutar su propio código malicioso. Podría tratarse de JavaScript o un módulo reescrito. Compruebe las marcas de tiempo para asegurarse de que los archivos seguros no estén siendo modificados sin autorización. Si el archivo ha sido modificado, compárelo con una versión anterior para averiguar lo que ha cambiado.

Varias utilidades pueden escanear la aplicación para buscar código malicioso. Ejecútelas periódicamente para asegurarse de que no hayan cambios. (Sucuri es una de estas herramientas.)

¿Existen un montón de nuevos archivos en el servidor web que no pueden explicarse con el uso normal? Que se muestren nuevos archivos en el web root es un problema, sobre todo si son guiones u otro tipo de archivos ejecutables. La adición de archivos al web root debe ser un proceso bien documentado y nunca una sorpresa. Si está encontrando nuevos archivos ahí o en otro lugar del servidor, entonces hay una infracción. El atacante puede estar utilizando la aplicación para servir software malicioso a los visitantes desprevenidos del sitio, o ejecutando un script redirigiéndolos a otra parte. También podría ser un archivo de texto que contiene datos recolectados.

Se han dado casos de atacantes que han creado un directorio totalmente nuevo e instalado su propia aplicación. En lugar de tocar la aplicación web actual, hacen uso del dominio y el servidor para ejecutar sus propias herramientas.

Si la aplicación utiliza plugins de terceros, compruebe para asegurarse de que estos no estén siendo actualizados o instalados sin previo aviso. No instale plugins simplemente porque hacen que su sitio sea mejor -actúe con la debida diligencia para asegurarse de que el plugin no añadirá funcionalidad maliciosa al sitio. Herramientas de exploración tales como la de White Hat Security pueden ayudar a descubrir algún potencial código de ataque.

Señales Nº 5: Reciba advertencias

Si su aplicación se ha visto comprometida y está propagando malware de forma activa, es probable que otras herramientas de seguridad también lo hayan adquirido. Google es muy rápido cuando se trata del bloqueo de las páginas que tienen una mala reputación entre los usuarios de Chrome; otros navegadores también actualizan regularmente sus listas negras. A menudo, compruebe su aplicación desde otros navegadores para ver si hay algún mensaje -o busque su sitio utilizando la herramienta de navegación segura de Google.

Monitoree las redes sociales y el servicio de ayuda de correos electrónicos y busque las quejas de los usuarios. Si estos dicen que no están recibiendo mails de restablecimiento de contraseñas porque los mensajes están siendo tratados como spam, vale la pena investigar si su aplicación ha sido señalada como spam relay.

Recuerde: La higiene de seguridad también se aplica a las aplicaciones web

Si se encuentran problemas, haga una copia de seguridad de la aplicación y el servidor para que pueda analizarla más adelante. Si está restaurando las copias de seguridad, asegúrese de tener una copia limpia, pues así no vuelve a instalar el malware. Identifique los archivos afectados y reemplazarlos por otros limpios. Por supuesto, esto significa que los backups deben convertirse en un hábito.

Una vez que la aplicación ha sido restaurada y los archivos innecesarios han sido eliminados, cambie todas las contraseñas, incluyendo la de CMS, las cuentas de administrador, y todos los servicios individuales. Active la autenticación de dos factores donde sea posible y configure el acceso VPN donde no todavía no está. Esto hace que la aplicación sea segura y evita que los atacantes vuelvan a invadir.

Endurezca la aplicación. Quite permisos de escritura donde no se necesiten y nunca utilice contraseñas por defecto. Tiene sentido utilizar rutas de directorio que sean más difíciles de adivinar (no simplemente usar /admin para el panel de control si puede controlar eso). Para las aplicaciones PHP, puede ser tan simple como habilitar el modo seguro en el archivo php.ini. Los escáneres de seguridad buscarán vulnerabilidades de seguridad conocidas en su aplicación.

En su laptop personal o de trabajo utilice software antivirus, sea cuidadoso acerca de los programas que descarga, y aplique regularmente actualizaciones a su sistema operativo y software de terceros. Ese dispositivo aplica a los servidores y aplicaciones web, también. Actualice regularmente las aplicaciones de terceros para asegurar que las vulnerabilidades hayan sido parchadas. Las herramientas de antivirus modernas en servidores atraparán a la mayoría de web shells disponibles, y detectarán el malware que esté siendo instalado en el servidor.

En casi todos los casos, es necesario restaurar la aplicación y cerrar la falla que permitió el paso a los atacantes. Mientras que reconstruir el servidor desde cero y configurar la aplicación es una posibilidad, es por lo general guardado como el último recurso. Si no cuenta con copias de seguridad vigentes y limpias, una actualización completa puede ser su única opción. Pero no sabrá cómo arreglar sus aplicaciones, si no busca regularmente señales de que los atacantes ya han entrado.

-Fahmida Y. Rashid, InfoWorld (EE.UU.)