Dicen que la programación es lo más parecido a la magia que tenemos hoy en día. ¿Y saben qué? Tienen razón. Unas pocas líneas de código que a los no iniciados no les parecen más que un galimatías… y puedes crear mundos enteros. ¿Cómo puede no ser magia?
En el lado opuesto, unas pocas líneas de código diferentes pueden crear los sistemas de seguridad más intrincados. Pero cuanto más intrincados son, más difícil es que caigan. Ahí es donde entran las amenazas a la seguridad del software. Amenazas como la desconfiguración de la seguridad hacen que los sistemas, grandes y pequeños, sean vulnerables a todo tipo de ciberataques.
Pero, ¿es la desconfiguración de la seguridad la amenaza más acuciante? ¿Y qué implica este término, a decir verdad, un tanto vago? Siga leyendo para averiguarlo.
Desconfiguración de la seguridad: Explicación, ejemplos, prevención
Un término comodín (hasta cierto punto), la mala configuración de seguridad cubre los controles de seguridad que se han dejado inseguros o mal configurados, poniendo en riesgo los datos y, a veces, todo el sistema. Simple y llanamente, cualquier problema técnico en cualquier componente que pueda surgir de los ajustes de configuración de la aplicación y no de un código incorrecto puede clasificarse como una vulnerabilidad de error de configuración de seguridad.
Ajustes por defecto chapuceros, cambios de configuración mal documentados, permisos incorrectos, lo que sea… todos ellos entran dentro de este paraguas.
Las más frecuentes suelen provenir de los errores más simples (como los ejemplos de abajo). Pero no hay nada de simple en las consecuencias a las que las organizaciones se enfrentan a menudo debido a estos errores. Desde la exposición de datos sensibles hasta la toma completa de servidores, páginas web y aplicaciones, los errores de configuración de seguridad han causado graves daños a innumerables empresas en el pasado. Y, teniendo en cuenta el puesto número 5 que esta amenaza obtuvo el año pasado en la lista de los 10 principales riesgos para la seguridad de las aplicaciones web de OWASP, no va a desaparecer. Así que puedes rezar para que no te afecte, o puedes aprender más sobre la desconfiguración de la seguridad, incluyendo cómo prevenirla y gestionarla.
¿Le parece bien? Pues vamos allá.
Cómo se produce una mala configuración de seguridad
Como hemos aprendido antes, hay razones más complejas e inusuales de vulnerabilidad a la desconfiguración de seguridad, pero también hay algunas increíblemente simples y comunes. Estas últimas incluyen:
Depuración activada
La mayoría de las empresas trabajan con entornos separados. Imagínate esto: activas la depuración en un entorno de desarrollo para acelerar el progreso de la depuración. Nada inusual, ¿verdad?
Pero tampoco hay nada inusual en olvidarse de desactivar esta pequeña característica antes de la fase de producción. Entonces, todo lo que los atacantes tienen que hacer es activar los errores verbose que contienen datos internos, y, et voilà, están IN.
Credenciales por defecto
Una preocupación trivial la mayoría de las veces, pero las credenciales por defecto pueden, a veces, causar graves estragos también. Y, nueve de cada diez veces, la culpable es una mala configuración de seguridad.
Verás, las credenciales por defecto suelen venir con multitud de soluciones integradas. Se pueden encontrar en aplicaciones web, diferentes dispositivos de red, casi cualquier cosa que requiera autenticación. Y, cuando no las cambias una vez que has terminado con la parte de instalación, estás abriendo las puertas de par en par. Y, quién lo iba a decir, los primeros en cruzar esas puertas suelen ser los hackers.
Permisos mal configurados
Negligencia. Siempre es negligencia. Pero, sí, incluso los mejores desarrolladores a veces se olvidan de establecer los permisos correctos en directorios expuestos (públicamente también), consolas de administración y paneles de control. Así, incluso los hackers menos expertos pueden acceder a estos archivos no autorizados sin problemas.
Ahora, usted podría pensar que el problema aquí es un exploit de control de acceso roto, pero ese no es el caso. No, BAC es el resultado, pero la parte culpable aquí es un problema de mala configuración de seguridad. Estaba presente antes de que el módulo llegara a cualquier característica de la aplicación web, sólo que normalmente lo descubres en esa fase.
Desconfiguración de la nube
La nube es algo maravilloso. Gracias a las soluciones de almacenamiento y compartición de archivos en la nube, tanto las pequeñas empresas como las grandes compañías pueden poner en marcha centros de datos enteros en cuestión de minutos, sin preocuparse de no disponer de los recursos necesarios.
Pero una gran libertad conlleva una gran… ya se sabe. Además, las empresas que utilizan estas soluciones tienen que seguir el modelo de responsabilidad compartida. Es decir, lo que ocurre en la nube se queda en la nube, es responsabilidad del cliente, no de los propietarios del servicio en la nube.
Lo que esto también significa es que, nos guste o no, las brechas que se producen debido a errores de seguridad en la nube seguirán apareciendo. Por poner un ejemplo rápido de vulnerabilidad por errores de configuración de seguridad, solo los errores de configuración de Amazon S3 sumaron más de 400.000 resultados de Google, que incluían fallos de seguridad de los nombres más importantes del sector.
Mala configuración del hardware
En el lado opuesto, la red y los diferentes dispositivos de seguridad también pueden estar mal configurados, causando verdaderos problemas tanto en el camino como desde el principio.
Lo que ocurre con bastante frecuencia es que los ingenieros de red son un poco laxos con las configuraciones de los dispositivos de red. Y, lo entendemos, solucionar problemas de red puede ser una lata. Pero eso no es motivo para olvidar la siguiente configuración de seguridad.
Porque cuando no lo haces (o cuando lo haces a medias), los atacantes pueden tener la oportunidad de acceder a los activos internos, realizar shells inversos sin ninguna restricción, y mucho más. Además, las soluciones mal configuradas como IPS, SIEM e IDS pueden crear más vulnerabilidades de seguridad. Por ejemplo, si se olvida de configurar un bind shell durante la intervención, los hackers no tendrán problemas para desfigurar su página web.
Y esto es sólo el principio. Las vulnerabilidades de desconfiguración de seguridad también ocurren debido a:
- Habilitar funciones innecesarias (normalmente por defecto) como servicios inútiles, cuentas, privilegios, puertos, páginas, etc.
- Trabajar con cabeceras y directorios inseguros o configurarlos con valores inseguros.
- Pasar por alto la configuración de seguridad (es decir, NO configurarla con valores seguros) en los servidores de aplicaciones, frameworks de aplicaciones, bibliotecas, bases de datos, etc.
- Utilizar componentes vulnerables y/o anticuados (que, por cierto, se encuentra justo detrás de la configuración de seguridad incorrecta en los 10 principales riesgos de seguridad de las aplicaciones web de OWASP mencionados anteriormente).
- No implementar medidas de seguridad apropiadas en toda la pila de la aplicación (en casi cualquier parte de ella).
- Y, por último pero no menos importante, no desactivar las cuentas por defecto con contraseñas estándar (sí, lo creas o no, eso pasa MUCHO).
¿Suena un poco vago de todos modos? Veamos entonces algunos ejemplos de escenarios de ataques por desconfiguración.
Posibles escenarios de ataque
El servidor de aplicaciones viene empaquetado con aplicaciones de ejemplo que no se han eliminado del servidor de producción.A menudo, estas aplicaciones de muestra incluyen fallos de seguridad conocidos, fallos de seguridad que los atacantes pueden explotar para comprometer su nuevo servidor. Digamos que una de estas aplicaciones es una consola de administración con cuentas predeterminadas habilitadas. En ese caso, todo lo que tienen que hacer los hackers es acceder a esa consola con una contraseña por defecto y, ya está, ahora es el capitán.
No se ha desactivado el listado de directorios. De nuevo, no es un escenario poco común, por desafortunado que sea. Los hackers sondean los servidores en busca de esta vulnerabilidad ante todo. Entonces, digamos que descubren que pueden simplemente listar directorios. Es un poco más complicado, pero los atacantes experimentados no tendrán problemas para encontrar y descargar las clases Java compiladas.A partir de ahí, pueden descompilar y aplicar ingeniería inversa a estas clases para ver el código del servidor. En este punto, localizar un fallo crítico de control de acceso en la aplicación es una cuestión de cuándo, no de si.
El servidor de la aplicación está configurado para devolver mensajes de error detallados (como stack traces) a los usuarios. En este escenario, puedes dejar expuestos todo tipo de fallos subyacentes. Información sensible, seguro, pero también las versiones de los componentes que tienen vulnerabilidades bien conocidas. Cuando las descubren, no hay límite a lo que los hackers pueden ser capaces de hacer con tu servidor. Y, como puedes suponer, todo lo que tienen que hacer (y, lo más probable, harán) es solicitar estos mensajes de error detallados, que es un juego de niños.
La nube tiene permisos de compartición por defecto abiertos (y disponibles para cualquiera que sea lo suficientemente amable como para preguntar) por otros usuarios del servicio. ¿Recuerdas el modelo de responsabilidad compartida que hemos mencionado antes? Sí, es ése. Significa que, a veces, ni siquiera tienes que ser tú. Basta con que uno de tus vecinos de nube se olvide de desactivar los permisos predeterminados y, a través de ellos, los ciberdelincuentes pueden acceder a tus datos confidenciales dentro de este servicio de almacenamiento en la nube. Dependiendo de estos permisos, los hackers podrían incluso obtener acceso de alto nivel al sistema.
¿Crees que esto son sólo hipótesis que no ocurren en la vida real? Piénselo de nuevo.
Ejemplos reales de desconfiguración de la seguridad
Los problemas de vulnerabilidad por desconfiguración de la seguridad son tan antiguos como las propias medidas de seguridad, por lo que hemos visto innumerables ejemplos en el pasado. He aquí sólo un par:
El incidente NASA/Jira
Uno pensaría que una de las empresas tecnológicamente más avanzadas y orientadas al progreso del mundo sabría hacerlo mejor. Pero no.
Todo lo que hizo falta fue un humilde entusiasta de la seguridad para identificar un error de configuración de seguridad en la herramienta de colaboración más grande (y quizás la más desagradable) que existe: Jira. Este error de configuración de la autorización por defecto dejó vulnerables a varias empresas de Fortune 500, incluida la NASA. A través de esta vulnerabilidad, terceros pudieron acceder a datos internos de usuarios, incluidos nombres, ID de correo electrónico, detalles de proyectos y otra información confidencial.
¿Qué ha ocurrido? Cuando Jira desarrollaba cuadros de mando y filtros para incidencias individuales o proyectos enteros, la configuración de visibilidad se establecía en Todos los usuarios y Todos por defecto. Por supuesto, idealmente, cosas como las tareas de hoja de ruta deberían haberse compartido dentro de la organización, pero el “querido” Jira las compartía con el público.
Conclusión clave: Asegúrate de revisar las configuraciones de uso compartido de archivos en cada SaaS que utilices para evitar exponer datos confidenciales.
Contratiempos con Amazon S3
El Servicio de Almacenamiento Simple de Amazon, también conocido como Amazon S3, ha sido objeto de abusos por parte de hackers más veces de las que se pueden contar. Desde el cubo S3 mal configurado que reveló 50.000 historiales de pacientes en Estados Unidos hasta los que expusieron más de 80 municipios estadounidenses, los atacantes no perdonaron a nadie.
Incluso el Mando de Inteligencia y Seguridad del Ejército de los Estados Unidos ha filtrado varios archivos sensibles en el pasado debido a Amazon S3, incluidos volúmenes OVA (Oracle Virtual Appliance) con partes marcadas como alto secreto.
Conclusión clave: El hecho de que cientos de empresas (incluidas agencias militares y gubernamentales) confíen en Amazon S3 no significa que sea seguro. De hecho, a la vista de las docenas de incidentes de seguridad ocurridos en el pasado, deberías vigilar cuidadosamente la autorización del servicio si decides utilizarlo.
Cómo evitar una mala configuración de seguridad
¿Recuerdas cómo se producen los errores de seguridad? Sí, eso es lo que debes evitar hacer. En otras palabras:
Desactivar la depuración. Cuando mueves la aplicación de la etapa de desarrollo a la etapa de producción, asegúrate de volver a comprobar todas las características de depuración en toda la configuración. Así es, TODAS deben estar deshabilitadas.
Cambiar las credenciales por defecto. Lo primero que debe hacer una vez que haya instalado cualquier pieza de software es cambiar las credenciales por defecto. De hecho, le recomendaríamos hacer de esto un hábito obligatorio dentro de su empresa.
Restringir el Acceso a los Paneles y Consolas de Administración. La segunda práctica obligatoria que debe implementar en toda la empresa es deshabilitar el acceso a las herramientas de administración antes de la implementación. Ni que decir tiene que sólo deben tener acceso a ellas aquellos usuarios que las necesiten. Asimismo, asegúrese de respetar esta práctica con auditorías sistemáticas.
Deshabilite el listado de directorios y verifique los permisos de los mismos. La aplicación desplegada no debe permitir el listado de directorios, simple y llanamente. Aparte de eso, asegúrate de que los permisos de las carpetas y archivos separados están configurados correctamente.
Aplique medidas de refuerzo de la seguridad repetibles. Cuando se configura correctamente, un proceso de endurecimiento repetible hará que el despliegue de otros entornos (que también están correctamente bloqueados) sea rápido y fácil. Por lo tanto, asegúrese de que los entornos de desarrollo, control de calidad y producción están configurados de forma idéntica, utilizando credenciales diferentes para cada entorno. Automatice esto y podrá configurar nuevos entornos seguros sin esfuerzo.
Utilice una arquitectura de aplicaciones segmentada. Una arquitectura de aplicaciones segmentada garantiza una separación eficaz y, lo que es aún más importante, segura entre sus componentes e inquilinos. Además de la segmentación, la arquitectura debe incorporar la contenedorización y/o grupos de seguridad en la nube (ACL).
Mantenga limpia la plataforma. Deshazte de todas las características, componentes, documentación y muestras innecesarias. Además de ser básicamente inútiles (de ahí lo de “innecesarios”), también son una amenaza para la seguridad. Elimina también los frameworks que no utilices. Lo ideal sería que no los hubieras instalado.
Recapitulemos
Desconfiguración de la seguridad es un término genérico para cualquier control de seguridad inseguro o mal configurado. Cuando se explota, permite a los hackers acceder a información confidencial o tomar el control de toda la página web, servidor o aplicación. El impacto de una mala configuración de seguridad ha paralizado a innumerables gigantes en el pasado. Por lo tanto, asegúrese de informarse sobre el tema y siga los consejos de prevención de errores de configuración de seguridad que hemos tratado anteriormente. Buen viaje y que las probabilidades estén siempre a tu favor.
