¿Cómo enfocarnos descartando que los desarrolladores anteriores estén haciendo backdooring mi sitio web?

Hay infinitas formas en que un desarrollador puede colocar puertas traseras intencionales y no intencionales en el código. Cuando el desarrollador es experto, puede esconderlos bien y / o enmascararlos de una manera que parezca un error involuntario. Una revisión completa del código es la única manera de lograr una certeza razonable de que es poco probable que existan más puertas traseras. Pero realmente no hay una manera segura de descartar completamente la existencia de puertas traseras.

Cuando tenga prisa, al menos podría intentar descartar las cosas más obvias antes de comenzar a investigar el código completo línea por línea:

• Eche un vistazo al código de inicio de sesión y autenticación. Este es el lugar más obvio para tener un parámetro mágico, una contraseña universal o credenciales codificadas que le permiten a uno iniciar sesión sin una cuenta válida.
• Compruebe si hay secuencias de comandos en la base de código que no parecen estar referenciadas en ningún lugar; podrían ser un panel de control oculto o similar.
• Cuando los mensajes de correo electrónico en particular son una preocupación, grep el código base de los sitios web para aquellas funciones que envían correos electrónicos en su lenguaje de programación. También puede monitorear el tráfico de los servidores web para detectar el tráfico SMTP saliente y detectar cualquier correo electrónico que no coincida con el formato que generalmente envía la aplicación (cuando se supone que debe enviar correos electrónicos).

Por cierto: este también podría ser un tema que su departamento legal debe abordar. Backdooring la aplicación es probablemente un incumplimiento de contrato e incluso puede ser un delito grave en su jurisdicción.

Habiendo estado allí en el pasado con clientes: aquí hay algunas medidas prácticas para descartar que los desarrolladores (empleados o contratistas) dejen puertas traseras en el código para acceder al sitio.

1. Elimine todas las credenciales de la persona que dejó el servidor web (por ejemplo, las credenciales de autenticación básicas), los usuarios del sistema operativo, los usuarios de la base de datos y los usuarios del servidor de correo. Hazlo ahora y conviértelo en un SOP cuando la gente se vaya.
2. Revise la lista de usuarios con privilegios SUDO (o administrador si está en Windows). Poda todos los usuarios de sudo que no conoces o en los que no confíes. Si alguien necesita sudo, lo solicitarán y usted pedirá una justificación
3. Agarre el registro de seguridad para intentos de interrupción y grep el registro del servidor web para las incidencias de nombres que suenen como el desarrollador que se fue. Cierre los servicios FTP.
4. Si está usando Linux y ejecutando Samba - verifique los permisos permitidos - elimine a los usuarios que ya no trabajan para la compañía Agregue todo el código fuente del nombre o correo electrónico de la persona; si obtiene un resultado, elimine el código
5. Suponiendo que usa svn o git, examine todas las confirmaciones que realizó el desarrollador 1 semana antes de que se fuera o fue despedido. La mayoría de las cosas nefastas ocurren cerca de la terminación. Revise el código manualmente y con grep y busque específicamente excepciones a la autenticación basada en un nombre de usuario, un parámetro mágico en una cadena de consulta, una hora del día o una dirección IP. Cualquier código que diga si algo! autenticar es sospechoso.
6. Suponiendo que utilice un marco MVC como RoR o CakePHP: examine sus tablas de acl y examine las excepciones del controlador de autenticación como en el punto anterior
7. Post-exploit: implemente un SOP para barrer a través de su sistema operativo y usuarios de la aplicación web periódicamente y elimine las cuentas / cuentas no utilizadas de las personas que dejaron / cuentas con privilegios innecesarios.

Depende de lo minucioso que quieras ser. Aquí hay una lista de lugares para comenzar en orden ascendente de esfuerzo.

1. Reemplace todas las dependencias binarias / javascript con copias nuevas
2. Asegúrese de que el código de Autenticación y Autorización esté centralizado y sea lo más simple posible, preferiblemente configurado centralmente. Si el código de inicio de sesión o autorización es complejo, puede valer la pena reescribirlo.
3. Piense en todas las acciones sensibles que el sitio podría tomar, por ejemplo. Enviando un correo electrónico, haciendo una conexión de red. Encuentre todas las ocurrencias de estas acciones y revíselas.
4. Dependiendo del tamaño del sitio y del presupuesto que tenga que hacer a través de la revisión de todo el código base.
5. Si el desarrollador tuvo acceso al servidor, vuelva a crear una imagen del servidor (Paranoia Level High)

Si no se siente confiado en su capacidad para realizar esta revisión del código, hay compañías que se especializan en seguridad y harán una revisión por usted.

Esto depende de su postura de seguridad / política. El principal problema con algo de esta naturaleza es la dependencia del código. Especialmente en códigos heredados y bibliotecas. Las líneas de código hacen que sea virtualmente imposible examinar una sola parte del código. Esto es especialmente cierto si el desarrollador reemplaza partes de la pila, por lo que las compilaciones reproducibles son importantes, o al menos la capacidad de diferenciar diferencias. Esto podría no ser posible para instalaciones antiguas y la falta de propiedad.

El acceso centralizado frente al acceso descentralizado es un compromiso entre la carga de trabajo administrativa, así como el proceso de mitigación en el lugar una vez que se ha violado una parte del sistema. ¿Tienes suficiente gente para hacer esto? ¿Y puede ser automatizado?

En general, los días en los que se enmarañan cada instalación y no se cuenta con un proceso de mitigación coherente como parte del conjunto general, han pasado. Y, no puede descartar hasta cierto punto que el sitio web no haya sido comprometido en cierta medida.