A lo largo de la historia se han producido innumerables fracasos debido a que los planificadores confiaban demasiado en la calidad de sus soluciones. Ya se trate del insumergible Titanic o de la inexpugnable línea Maginot de la Segunda Guerra Mundial, depositar demasiada confianza en una única solución ha provocado terribles catástrofes una y otra vez.
En el mundo de la ciberseguridad, no es diferente. Si tienes una defensa de ciberseguridad de solución única, te estás buscando problemas.
Los peligros de una solución única para la seguridad
En este artículo, analizaremos un caso particular en el que esto ocurrió con un proveedor de comercio electrónico. Esta empresa creó una nueva API de inicio de sesión para su aplicación móvil. Reforzaron su seguridad exigiendo un cifrado RSA de 1024 bits de la contraseña en la carga útil de cualquier solicitud de autenticación.
Es una buena idea. Después de todo, hace que los ataques man-in-the-middle sean prácticamente inútiles, ya que la información de autenticación no sería legible por humanos. Aparece como una cadena codificada en base64 y cifrada con RSA. Dado que las solicitudes de autenticación procedían de su propia aplicación, este era un enfoque bastante bueno. Pulgares arriba.
Pero... hay más que eso. Lo que no fue una buena idea fue pensar que esta medida de seguridad era todo lo que necesitaban. En lugar de seguir mejorando la seguridad con medidas como imponer un máximo de intentos fallidos de contraseña, decidieron simplemente distribuirlo, y luego se dedicaron a otros trabajos de desarrollo.
Aunque pueda parecer que todo iba bien, había un fallo importante en su solución. La clave pública de 1024 bits era fácilmente observable utilizando JADX para descompilar su aplicación móvil.
Al guardar la clave pública en un archivo local, un atacante podría pasar por todas las contraseñas que quisiera, cifrándolas todas de acuerdo con la clave pública del objetivo y deshaciendo por completo el trabajo de asegurar el punto final de autenticación en primer lugar.
Como no había un límite máximo de intentos fallidos de contraseña en este endpoint, escribí un script en bash que automatizaría la comprobación de tantas contraseñas como quisiera. Probé el problema a este proveedor de comercio electrónico con una simple cuenta atrás de mi contraseña que había configurado para demostrar el problema:
#!/bin/bash |
Este es el resultado de mi script:
Welcome 10 |
Desglosémoslo. En un for bucle, empiezo con un mensaje de bienvenida para anunciar qué dígito estoy insertando en mi intento de llegar a la contraseña que he establecido para esta prueba de concepto. Luego, vemos la contraseña y el subsiguiente valor encriptado que será enviado a la API. (No pensarías que iba a usar una contraseña tan sencilla, y mucho menos que la iba a revelar aquí, ¿verdad?)
Por último, doy salida a la respuesta de la API a mi comprobación de contraseña. Durante los seis primeros intentos, obtengo una respuesta infructuosa, pero cuando finalmente llego a mi contraseña hipersegura (😉) de faster4wardla API me permite entrar con mi ámbito de autorización normal.
Demasiado para cargas útiles de autenticación encriptadas RSA...
Cómo evitar el mismo tipo de error
Ahora que hemos identificado el problema, ¿qué podemos hacer? Empecemos por el error fundamental que nos ha traído hasta aquí. Hay muchas cosas que hacer para asegurar con éxito cualquier aplicación web, ¡ya que no hay una bala de plata para asegurar una aplicación! Para nuestro ejemplo específico de arriba, quieres otras medidas además de la fuerte encriptación RSA.
- Asegúrate de que tus claves de cifrado son seguras.
- Imponer un número máximo de intentos fallidos de verificación de contraseña, lo que resulta en un bloqueo de la cuenta.
- Implantar la limitación de la tasa de peticiones.
Toda seguridad de un sistema expuesto a Internet debe adoptar el principio de defensa en profundidad: Deben desplegarse múltiples capas de defensa en toda la superficie de tu presencia en Internet, no sólo en los puntos que te parezcan más interesantes u obvios de defender.
Afortunadamente, Linode ofrece muchas grandes características de seguridad integradas en nuestra plataforma, y hay muchos estándares de la industria para hacer frente a algunos vectores de ataque comunes. Algunas de estas soluciones se aplican a su cuenta de Linode, y algunas se aplican directamente a sus Linodes. Veamos ambos tipos de protección.
Proteger el acceso de administrador a su cuenta Linode
Si alguien puede entrar en tu cuenta de Linode, se acabó el juego. Entrar en tus Linodes se convierte en algo trivial. Esta es la razón por la que las cuentas Linode están construidas pensando en la seguridad. Por defecto, cada cuenta Linode debe ser asegurada con verificación telefónica. Linode también requiere la configuración de preguntas y respuestas de seguridad para la recuperación de la cuenta.
Además de la verificación telefónica, también puedes configurar la autenticación de dos factores mediante un código de autenticación de contraseña de un solo uso basado en el tiempo (TOTP). Aunque no es obligatorio en las cuentas, es muy recomendable activar 2FA, ya que es mucho más seguro que una simple contraseña y preguntas de seguridad, e incluso más seguro que los códigos de verificación telefónica.
Hay otro nivel de seguridad disponible para evitar completamente tener una contraseña de Linode. Puede utilizar una fuente de autenticación de terceros (TPA). Usando este método, puedes configurar métodos seguros de inicio de sesión en la fuente de terceros que elijas (ahora mismo Google y GitHub están soportados para esto). Esto reduce las posibilidades de que una contraseña filtrada le haga perder el acceso a su cuenta Linode.
Un último método para proteger tu cuenta es establecer usuarios específicos que puedan acceder a partes concretas de tu cuenta. Esto le permitirá establecer ciertos permisos en torno a lo que los subusuarios pueden hacer en su cuenta, reduciendo así aún más la posibilidad de que un atacante cause daños sin paliativos a su cuenta.
Introducir esta separación de preocupaciones entre los usuarios que acceden a las distintas partes de tu infraestructura es una buena práctica. Por supuesto, si eres un equipo de uno, esto podría no ser necesario. Sin embargo, si tienes una verdadera separación de intereses, esto te permitirá asegurarte de que no se realizan cambios no autorizados en tu cuenta o infraestructura.
Proteja sus Linodes
Asegurar su cuenta es definitivamente importante, pero asegurar sus servidores e infraestructura puede ser aún más importante. Después de todo, la mayoría de los atacantes tratarán de entrar en su infraestructura a través de la infraestructura en lugar de a través de su proveedor de alojamiento. Linode te cubre aquí también.
Uno de los mejores lugares para empezar es Linode App Marketplace. Tanto si necesitas desplegar soluciones de seguridad como Haltdos WAF para detener el tráfico malicioso a las puertas de tus servidores como si quieres tener una instalación de un solo clic de una pila de monitorización como una configuración dePrometheus + Grafana , no hay nada más fácil para asegurar y monitorizar tu pila que Marketplace.
Las aplicaciones de terceros tampoco son las únicas soluciones que tienes a tu disposición. Linode Cloud Firewall es una gran solución que se configura fácilmente directamente desde Cloud Manager. Usar tanto Linode Cloud Firewall como un cortafuegos en tu Linode es también una gran idea.
Otra buena práctica es asegurarse de que sus servidores están protegidos contra ataques DDoS. Con Linode, defiendes toda tu infraestructura contra estos ataques por defecto, ¡sin coste alguno! Ni siquiera necesitas hacer nada para configurarlo.
Conclusión
Hay mucho más que decir sobre la seguridad, pero esto probablemente sea suficiente por ahora. En definitiva, evita que tu inteligente solución a un problema te haga olvidar otras cosas que podrían faltar en tu enfoque de seguridad.
Comentarios