Los codificadores conquistan la infraestructura de seguridad como serie de códigos: Almacenamiento de contraseñas en texto plano
Cuando se trata de desplegar una infraestructura segura como código en su propia organización, ¿cómo lo está haciendo? Puede que sea una curva de aprendizaje, pero aprender a hacerlo será una gran oportunidad para mejorar tus habilidades, destacar entre tus compañeros y mantener más datos de los usuarios finales a salvo.
Antes de que empecemos con el siguiente capítulo de nuestra última serie Coders Conquer Security, me gustaría invitarte a jugar un desafío gamificado de la vulnerabilidad del almacenamiento de datos sensibles; juega ahora y elige entre Kubernetes, Terraform, Ansible, Docker o CloudFormation:
¿Cómo fue eso? Si tus conocimientos necesitan un poco de trabajo, sigue leyendo:
La clave de la mayor parte de la seguridad informática hoy en día tiene que ver con las contraseñas. Incluso si se emplean otros métodos de seguridad, como la autenticación de dos factores o la biometría, la mayoría de las organizaciones siguen empleando la seguridad basada en contraseñas como uno de los elementos de su protección. Para muchas empresas, las contraseñas son de uso exclusivo.
Utilizamos tanto las contraseñas que incluso tenemos reglas sobre cómo crearlas. Se supone que esto las hace menos vulnerables a los ataques de fuerza bruta o incluso a las adivinanzas. Por supuesto, algunas personas siguen utilizando contraseñas débiles, como demuestra un reciente informe de NordPass. Es difícil de creer que en 2020 la gente siga usando 12345 y un montón de otras palabras adivinables como chocolate, contraseña y Dios para proteger sus activos más sensibles.
Siempre habrá quien no se preocupe por utilizar contraseñas seguras, pero la mayoría de las organizaciones profesionales obligan a los usuarios a elaborar sus palabras o frases de acceso de determinadas maneras. Todos conocemos ya las reglas: las contraseñas deben tener al menos ocho caracteres y estar compuestas por letras mayúsculas y minúsculas, con al menos un número y un carácter especial.
Lo malo es que incluso si los usuarios se adhieren a las reglas para hacer los tipos de contraseñas más fuertes, puede que no sirva de nada si todas están almacenadas en texto plano. La contraseña 12345 es tan mala como Nuts53!SpiKe&Dog12 si un hacker es capaz de leer todo el archivo de contraseñas.
¿Por qué es peligroso almacenar contraseñas en texto plano?
Almacenar las contraseñas en texto plano es malo porque pone en riesgo tanto al sistema como a los usuarios. Obviamente, tener un hacker capaz de encontrar y leer cada una de las contraseñas utilizadas para acceder a un sistema sería un desastre. Podrían simplemente encontrar un usuario con credenciales de administrador y comprometer todo el sistema o sitio. Y como estarían utilizando nombres de usuario y contraseñas adecuadas, la seguridad interna podría no detectar la intrusión o detectarla mucho después de que el daño esté hecho.
Facilitar a los atacantes el robo de contraseñas almacenadas en texto plano también perjudica a los usuarios, porque mucha gente reutiliza las contraseñas. Como hemos hecho que las contraseñas sean tan difíciles de crear, mucha gente recurre a reutilizar las que puede recordar en varios sitios. Si un atacante compromete un archivo de contraseñas, es casi seguro que intentará acceder a otros sistemas utilizando el mismo nombre y la misma contraseña, lo que pone a los usuarios en gran riesgo de delitos secundarios.
Es relativamente fácil almacenar accidentalmente las contraseñas en texto plano o no darse cuenta de que esto podría causar grandes problemas en el futuro. Por ejemplo, el siguiente código es un método común empleado para almacenar contraseñas al definir un recurso de AWS utilizando plantillas de Terraform:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
En ese ejemplo, la contraseña utilizada para gestionar la instancia de la base de datos MySQL en AWS se está almacenando en texto plano. Eso significa que cualquiera con acceso al repositorio de código fuente podría leerla, o incluso copiarla.
La protección de las contraseñas varía según el marco de trabajo, pero existen métodos de protección para cada plataforma. Por ejemplo, la contraseña de MySQL puede guardarse en un almacenamiento seguro como AWS Secrets Manager:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
En ese ejemplo, la plantilla de Terraform obtendrá la contraseña del servicio AWS Secrets Manager y nunca se almacenará en texto plano en los archivos de la plantilla.
Proteger las contraseñas evitando el almacenamiento en texto plano
Las contraseñas son las llaves de tu reino y nunca deberían almacenarse en texto plano. Ni siquiera las personas internas de una organización deberían tener acceso a un gran repositorio de contraseñas sin protección, ni debería ser un protocolo empresarial aceptado (hoy en día hay muchos gestores de contraseñas que permiten compartir credenciales cifradas, ¡no hay excusas!) También existe el peligro de que personas malintencionadas de dentro fisgoneen los archivos y obtengan acceso donde no deben.
Y en el caso de un ataque externo, imagínate el doble golpe que se puede dar si se encuentra una puerta trasera a tu base de datos a través de algo tan simple como una vulnerabilidad de inyección SQL, y además consiguen acceder al directorio donde se almacenan las contraseñas. ¿Crees que son demasiados pasos cargados de errores para llegar a buen puerto? Lamentablemente, este escenario exacto ocurrió en la brecha de Sony de 2011. Más de un millón de contraseñas de clientes estaban almacenadas en texto plano, y el grupo de hackers Lulzsec accedió a ellas y a muchas más a través de un ataque común de inyección SQL.
Todas las contraseñas deben ser protegidas por cualquier defensa disponible dentro del marco de apoyo. En el caso de Terraform, las contraseñas nunca deben almacenarse en archivos de plantilla. Se recomienda utilizar un almacenamiento seguro como AWS Secrets Manager o Azure Key Vault, dependiendo del proveedor de la infraestructura.
Obligar a los usuarios a crear contraseñas seguras es una buena idea, pero también hay que poner de su parte en el backend. Mantener las contraseñas fuera del almacenamiento de texto plano contribuirá en gran medida a proteger a sus usuarios y sus sistemas. El principal peligro del almacenamiento de contraseñas en texto plano es el escaso control de acceso; básicamente, cualquiera puede verlas. Es imperativo (especialmente en un entorno de IaC donde de repente, más personas tienen acceso a la información sensible) que se les aplique un hash adecuado y que sólo se les conceda acceso a aquellos que absolutamente lo necesitan.
Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos y vulnerabilidades de seguridad. También puedes probar un reto IaC de demostración dentro de la plataforma de formación Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.
La clave de la mayor parte de la seguridad informática hoy en día tiene que ver con las contraseñas. Incluso si se emplean otros métodos de seguridad, como la autenticación de dos factores o la biometría, la mayoría de las organizaciones siguen empleando la seguridad basada en contraseñas como uno de los elementos de su protección.
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónMatias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
Cuando se trata de desplegar una infraestructura segura como código en su propia organización, ¿cómo lo está haciendo? Puede que sea una curva de aprendizaje, pero aprender a hacerlo será una gran oportunidad para mejorar tus habilidades, destacar entre tus compañeros y mantener más datos de los usuarios finales a salvo.
Antes de que empecemos con el siguiente capítulo de nuestra última serie Coders Conquer Security, me gustaría invitarte a jugar un desafío gamificado de la vulnerabilidad del almacenamiento de datos sensibles; juega ahora y elige entre Kubernetes, Terraform, Ansible, Docker o CloudFormation:
¿Cómo fue eso? Si tus conocimientos necesitan un poco de trabajo, sigue leyendo:
La clave de la mayor parte de la seguridad informática hoy en día tiene que ver con las contraseñas. Incluso si se emplean otros métodos de seguridad, como la autenticación de dos factores o la biometría, la mayoría de las organizaciones siguen empleando la seguridad basada en contraseñas como uno de los elementos de su protección. Para muchas empresas, las contraseñas son de uso exclusivo.
Utilizamos tanto las contraseñas que incluso tenemos reglas sobre cómo crearlas. Se supone que esto las hace menos vulnerables a los ataques de fuerza bruta o incluso a las adivinanzas. Por supuesto, algunas personas siguen utilizando contraseñas débiles, como demuestra un reciente informe de NordPass. Es difícil de creer que en 2020 la gente siga usando 12345 y un montón de otras palabras adivinables como chocolate, contraseña y Dios para proteger sus activos más sensibles.
Siempre habrá quien no se preocupe por utilizar contraseñas seguras, pero la mayoría de las organizaciones profesionales obligan a los usuarios a elaborar sus palabras o frases de acceso de determinadas maneras. Todos conocemos ya las reglas: las contraseñas deben tener al menos ocho caracteres y estar compuestas por letras mayúsculas y minúsculas, con al menos un número y un carácter especial.
Lo malo es que incluso si los usuarios se adhieren a las reglas para hacer los tipos de contraseñas más fuertes, puede que no sirva de nada si todas están almacenadas en texto plano. La contraseña 12345 es tan mala como Nuts53!SpiKe&Dog12 si un hacker es capaz de leer todo el archivo de contraseñas.
¿Por qué es peligroso almacenar contraseñas en texto plano?
Almacenar las contraseñas en texto plano es malo porque pone en riesgo tanto al sistema como a los usuarios. Obviamente, tener un hacker capaz de encontrar y leer cada una de las contraseñas utilizadas para acceder a un sistema sería un desastre. Podrían simplemente encontrar un usuario con credenciales de administrador y comprometer todo el sistema o sitio. Y como estarían utilizando nombres de usuario y contraseñas adecuadas, la seguridad interna podría no detectar la intrusión o detectarla mucho después de que el daño esté hecho.
Facilitar a los atacantes el robo de contraseñas almacenadas en texto plano también perjudica a los usuarios, porque mucha gente reutiliza las contraseñas. Como hemos hecho que las contraseñas sean tan difíciles de crear, mucha gente recurre a reutilizar las que puede recordar en varios sitios. Si un atacante compromete un archivo de contraseñas, es casi seguro que intentará acceder a otros sistemas utilizando el mismo nombre y la misma contraseña, lo que pone a los usuarios en gran riesgo de delitos secundarios.
Es relativamente fácil almacenar accidentalmente las contraseñas en texto plano o no darse cuenta de que esto podría causar grandes problemas en el futuro. Por ejemplo, el siguiente código es un método común empleado para almacenar contraseñas al definir un recurso de AWS utilizando plantillas de Terraform:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
En ese ejemplo, la contraseña utilizada para gestionar la instancia de la base de datos MySQL en AWS se está almacenando en texto plano. Eso significa que cualquiera con acceso al repositorio de código fuente podría leerla, o incluso copiarla.
La protección de las contraseñas varía según el marco de trabajo, pero existen métodos de protección para cada plataforma. Por ejemplo, la contraseña de MySQL puede guardarse en un almacenamiento seguro como AWS Secrets Manager:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
En ese ejemplo, la plantilla de Terraform obtendrá la contraseña del servicio AWS Secrets Manager y nunca se almacenará en texto plano en los archivos de la plantilla.
Proteger las contraseñas evitando el almacenamiento en texto plano
Las contraseñas son las llaves de tu reino y nunca deberían almacenarse en texto plano. Ni siquiera las personas internas de una organización deberían tener acceso a un gran repositorio de contraseñas sin protección, ni debería ser un protocolo empresarial aceptado (hoy en día hay muchos gestores de contraseñas que permiten compartir credenciales cifradas, ¡no hay excusas!) También existe el peligro de que personas malintencionadas de dentro fisgoneen los archivos y obtengan acceso donde no deben.
Y en el caso de un ataque externo, imagínate el doble golpe que se puede dar si se encuentra una puerta trasera a tu base de datos a través de algo tan simple como una vulnerabilidad de inyección SQL, y además consiguen acceder al directorio donde se almacenan las contraseñas. ¿Crees que son demasiados pasos cargados de errores para llegar a buen puerto? Lamentablemente, este escenario exacto ocurrió en la brecha de Sony de 2011. Más de un millón de contraseñas de clientes estaban almacenadas en texto plano, y el grupo de hackers Lulzsec accedió a ellas y a muchas más a través de un ataque común de inyección SQL.
Todas las contraseñas deben ser protegidas por cualquier defensa disponible dentro del marco de apoyo. En el caso de Terraform, las contraseñas nunca deben almacenarse en archivos de plantilla. Se recomienda utilizar un almacenamiento seguro como AWS Secrets Manager o Azure Key Vault, dependiendo del proveedor de la infraestructura.
Obligar a los usuarios a crear contraseñas seguras es una buena idea, pero también hay que poner de su parte en el backend. Mantener las contraseñas fuera del almacenamiento de texto plano contribuirá en gran medida a proteger a sus usuarios y sus sistemas. El principal peligro del almacenamiento de contraseñas en texto plano es el escaso control de acceso; básicamente, cualquiera puede verlas. Es imperativo (especialmente en un entorno de IaC donde de repente, más personas tienen acceso a la información sensible) que se les aplique un hash adecuado y que sólo se les conceda acceso a aquellos que absolutamente lo necesitan.
Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos y vulnerabilidades de seguridad. También puedes probar un reto IaC de demostración dentro de la plataforma de formación Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.
Cuando se trata de desplegar una infraestructura segura como código en su propia organización, ¿cómo lo está haciendo? Puede que sea una curva de aprendizaje, pero aprender a hacerlo será una gran oportunidad para mejorar tus habilidades, destacar entre tus compañeros y mantener más datos de los usuarios finales a salvo.
Antes de que empecemos con el siguiente capítulo de nuestra última serie Coders Conquer Security, me gustaría invitarte a jugar un desafío gamificado de la vulnerabilidad del almacenamiento de datos sensibles; juega ahora y elige entre Kubernetes, Terraform, Ansible, Docker o CloudFormation:
¿Cómo fue eso? Si tus conocimientos necesitan un poco de trabajo, sigue leyendo:
La clave de la mayor parte de la seguridad informática hoy en día tiene que ver con las contraseñas. Incluso si se emplean otros métodos de seguridad, como la autenticación de dos factores o la biometría, la mayoría de las organizaciones siguen empleando la seguridad basada en contraseñas como uno de los elementos de su protección. Para muchas empresas, las contraseñas son de uso exclusivo.
Utilizamos tanto las contraseñas que incluso tenemos reglas sobre cómo crearlas. Se supone que esto las hace menos vulnerables a los ataques de fuerza bruta o incluso a las adivinanzas. Por supuesto, algunas personas siguen utilizando contraseñas débiles, como demuestra un reciente informe de NordPass. Es difícil de creer que en 2020 la gente siga usando 12345 y un montón de otras palabras adivinables como chocolate, contraseña y Dios para proteger sus activos más sensibles.
Siempre habrá quien no se preocupe por utilizar contraseñas seguras, pero la mayoría de las organizaciones profesionales obligan a los usuarios a elaborar sus palabras o frases de acceso de determinadas maneras. Todos conocemos ya las reglas: las contraseñas deben tener al menos ocho caracteres y estar compuestas por letras mayúsculas y minúsculas, con al menos un número y un carácter especial.
Lo malo es que incluso si los usuarios se adhieren a las reglas para hacer los tipos de contraseñas más fuertes, puede que no sirva de nada si todas están almacenadas en texto plano. La contraseña 12345 es tan mala como Nuts53!SpiKe&Dog12 si un hacker es capaz de leer todo el archivo de contraseñas.
¿Por qué es peligroso almacenar contraseñas en texto plano?
Almacenar las contraseñas en texto plano es malo porque pone en riesgo tanto al sistema como a los usuarios. Obviamente, tener un hacker capaz de encontrar y leer cada una de las contraseñas utilizadas para acceder a un sistema sería un desastre. Podrían simplemente encontrar un usuario con credenciales de administrador y comprometer todo el sistema o sitio. Y como estarían utilizando nombres de usuario y contraseñas adecuadas, la seguridad interna podría no detectar la intrusión o detectarla mucho después de que el daño esté hecho.
Facilitar a los atacantes el robo de contraseñas almacenadas en texto plano también perjudica a los usuarios, porque mucha gente reutiliza las contraseñas. Como hemos hecho que las contraseñas sean tan difíciles de crear, mucha gente recurre a reutilizar las que puede recordar en varios sitios. Si un atacante compromete un archivo de contraseñas, es casi seguro que intentará acceder a otros sistemas utilizando el mismo nombre y la misma contraseña, lo que pone a los usuarios en gran riesgo de delitos secundarios.
Es relativamente fácil almacenar accidentalmente las contraseñas en texto plano o no darse cuenta de que esto podría causar grandes problemas en el futuro. Por ejemplo, el siguiente código es un método común empleado para almacenar contraseñas al definir un recurso de AWS utilizando plantillas de Terraform:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
En ese ejemplo, la contraseña utilizada para gestionar la instancia de la base de datos MySQL en AWS se está almacenando en texto plano. Eso significa que cualquiera con acceso al repositorio de código fuente podría leerla, o incluso copiarla.
La protección de las contraseñas varía según el marco de trabajo, pero existen métodos de protección para cada plataforma. Por ejemplo, la contraseña de MySQL puede guardarse en un almacenamiento seguro como AWS Secrets Manager:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
En ese ejemplo, la plantilla de Terraform obtendrá la contraseña del servicio AWS Secrets Manager y nunca se almacenará en texto plano en los archivos de la plantilla.
Proteger las contraseñas evitando el almacenamiento en texto plano
Las contraseñas son las llaves de tu reino y nunca deberían almacenarse en texto plano. Ni siquiera las personas internas de una organización deberían tener acceso a un gran repositorio de contraseñas sin protección, ni debería ser un protocolo empresarial aceptado (hoy en día hay muchos gestores de contraseñas que permiten compartir credenciales cifradas, ¡no hay excusas!) También existe el peligro de que personas malintencionadas de dentro fisgoneen los archivos y obtengan acceso donde no deben.
Y en el caso de un ataque externo, imagínate el doble golpe que se puede dar si se encuentra una puerta trasera a tu base de datos a través de algo tan simple como una vulnerabilidad de inyección SQL, y además consiguen acceder al directorio donde se almacenan las contraseñas. ¿Crees que son demasiados pasos cargados de errores para llegar a buen puerto? Lamentablemente, este escenario exacto ocurrió en la brecha de Sony de 2011. Más de un millón de contraseñas de clientes estaban almacenadas en texto plano, y el grupo de hackers Lulzsec accedió a ellas y a muchas más a través de un ataque común de inyección SQL.
Todas las contraseñas deben ser protegidas por cualquier defensa disponible dentro del marco de apoyo. En el caso de Terraform, las contraseñas nunca deben almacenarse en archivos de plantilla. Se recomienda utilizar un almacenamiento seguro como AWS Secrets Manager o Azure Key Vault, dependiendo del proveedor de la infraestructura.
Obligar a los usuarios a crear contraseñas seguras es una buena idea, pero también hay que poner de su parte en el backend. Mantener las contraseñas fuera del almacenamiento de texto plano contribuirá en gran medida a proteger a sus usuarios y sus sistemas. El principal peligro del almacenamiento de contraseñas en texto plano es el escaso control de acceso; básicamente, cualquiera puede verlas. Es imperativo (especialmente en un entorno de IaC donde de repente, más personas tienen acceso a la información sensible) que se les aplique un hash adecuado y que sólo se les conceda acceso a aquellos que absolutamente lo necesitan.
Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos y vulnerabilidades de seguridad. También puedes probar un reto IaC de demostración dentro de la plataforma de formación Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.
Haga clic en el siguiente enlace y descargue el PDF de este recurso.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Ver el informeReservar una demostraciónMatias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Matías es un investigador y desarrollador con más de 15 años de experiencia práctica en seguridad de software. Ha desarrollado soluciones para empresas como Fortify Software y su propia empresa Sensei Security. A lo largo de su carrera, Matías ha dirigido múltiples proyectos de investigación sobre seguridad de aplicaciones que han dado lugar a productos comerciales y cuenta con más de 10 patentes en su haber. Cuando está lejos de su escritorio, Matias ha servido como instructor para la formación de seguridad de aplicaciones avanzadas courses y regularmente habla en conferencias mundiales como la Conferencia RSA, Black Hat, DefCon, BSIMM, OWASP AppSec y BruCon.
Matías es doctor en Ingeniería Informática por la Universidad de Gante, donde estudió la seguridad de las aplicaciones mediante la ofuscación de programas para ocultar el funcionamiento interno de una aplicación.
Cuando se trata de desplegar una infraestructura segura como código en su propia organización, ¿cómo lo está haciendo? Puede que sea una curva de aprendizaje, pero aprender a hacerlo será una gran oportunidad para mejorar tus habilidades, destacar entre tus compañeros y mantener más datos de los usuarios finales a salvo.
Antes de que empecemos con el siguiente capítulo de nuestra última serie Coders Conquer Security, me gustaría invitarte a jugar un desafío gamificado de la vulnerabilidad del almacenamiento de datos sensibles; juega ahora y elige entre Kubernetes, Terraform, Ansible, Docker o CloudFormation:
¿Cómo fue eso? Si tus conocimientos necesitan un poco de trabajo, sigue leyendo:
La clave de la mayor parte de la seguridad informática hoy en día tiene que ver con las contraseñas. Incluso si se emplean otros métodos de seguridad, como la autenticación de dos factores o la biometría, la mayoría de las organizaciones siguen empleando la seguridad basada en contraseñas como uno de los elementos de su protección. Para muchas empresas, las contraseñas son de uso exclusivo.
Utilizamos tanto las contraseñas que incluso tenemos reglas sobre cómo crearlas. Se supone que esto las hace menos vulnerables a los ataques de fuerza bruta o incluso a las adivinanzas. Por supuesto, algunas personas siguen utilizando contraseñas débiles, como demuestra un reciente informe de NordPass. Es difícil de creer que en 2020 la gente siga usando 12345 y un montón de otras palabras adivinables como chocolate, contraseña y Dios para proteger sus activos más sensibles.
Siempre habrá quien no se preocupe por utilizar contraseñas seguras, pero la mayoría de las organizaciones profesionales obligan a los usuarios a elaborar sus palabras o frases de acceso de determinadas maneras. Todos conocemos ya las reglas: las contraseñas deben tener al menos ocho caracteres y estar compuestas por letras mayúsculas y minúsculas, con al menos un número y un carácter especial.
Lo malo es que incluso si los usuarios se adhieren a las reglas para hacer los tipos de contraseñas más fuertes, puede que no sirva de nada si todas están almacenadas en texto plano. La contraseña 12345 es tan mala como Nuts53!SpiKe&Dog12 si un hacker es capaz de leer todo el archivo de contraseñas.
¿Por qué es peligroso almacenar contraseñas en texto plano?
Almacenar las contraseñas en texto plano es malo porque pone en riesgo tanto al sistema como a los usuarios. Obviamente, tener un hacker capaz de encontrar y leer cada una de las contraseñas utilizadas para acceder a un sistema sería un desastre. Podrían simplemente encontrar un usuario con credenciales de administrador y comprometer todo el sistema o sitio. Y como estarían utilizando nombres de usuario y contraseñas adecuadas, la seguridad interna podría no detectar la intrusión o detectarla mucho después de que el daño esté hecho.
Facilitar a los atacantes el robo de contraseñas almacenadas en texto plano también perjudica a los usuarios, porque mucha gente reutiliza las contraseñas. Como hemos hecho que las contraseñas sean tan difíciles de crear, mucha gente recurre a reutilizar las que puede recordar en varios sitios. Si un atacante compromete un archivo de contraseñas, es casi seguro que intentará acceder a otros sistemas utilizando el mismo nombre y la misma contraseña, lo que pone a los usuarios en gran riesgo de delitos secundarios.
Es relativamente fácil almacenar accidentalmente las contraseñas en texto plano o no darse cuenta de que esto podría causar grandes problemas en el futuro. Por ejemplo, el siguiente código es un método común empleado para almacenar contraseñas al definir un recurso de AWS utilizando plantillas de Terraform:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "s3.cr3t.admin.p2ss"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
En ese ejemplo, la contraseña utilizada para gestionar la instancia de la base de datos MySQL en AWS se está almacenando en texto plano. Eso significa que cualquiera con acceso al repositorio de código fuente podría leerla, o incluso copiarla.
La protección de las contraseñas varía según el marco de trabajo, pero existen métodos de protección para cada plataforma. Por ejemplo, la contraseña de MySQL puede guardarse en un almacenamiento seguro como AWS Secrets Manager:
resource "aws_db_instance" "default" {
engine = "mysql"
allocated_storage = 10
instance_class = "db.t2.micro"
username = "admin"
password = "${data.aws_secretsmanager_secret_version.password.secret_string}"
db_subnet_group_name = aws_db_subnet_group.default.name
vpc_security_group_ids = [aws_security_group.default.id]
}
En ese ejemplo, la plantilla de Terraform obtendrá la contraseña del servicio AWS Secrets Manager y nunca se almacenará en texto plano en los archivos de la plantilla.
Proteger las contraseñas evitando el almacenamiento en texto plano
Las contraseñas son las llaves de tu reino y nunca deberían almacenarse en texto plano. Ni siquiera las personas internas de una organización deberían tener acceso a un gran repositorio de contraseñas sin protección, ni debería ser un protocolo empresarial aceptado (hoy en día hay muchos gestores de contraseñas que permiten compartir credenciales cifradas, ¡no hay excusas!) También existe el peligro de que personas malintencionadas de dentro fisgoneen los archivos y obtengan acceso donde no deben.
Y en el caso de un ataque externo, imagínate el doble golpe que se puede dar si se encuentra una puerta trasera a tu base de datos a través de algo tan simple como una vulnerabilidad de inyección SQL, y además consiguen acceder al directorio donde se almacenan las contraseñas. ¿Crees que son demasiados pasos cargados de errores para llegar a buen puerto? Lamentablemente, este escenario exacto ocurrió en la brecha de Sony de 2011. Más de un millón de contraseñas de clientes estaban almacenadas en texto plano, y el grupo de hackers Lulzsec accedió a ellas y a muchas más a través de un ataque común de inyección SQL.
Todas las contraseñas deben ser protegidas por cualquier defensa disponible dentro del marco de apoyo. En el caso de Terraform, las contraseñas nunca deben almacenarse en archivos de plantilla. Se recomienda utilizar un almacenamiento seguro como AWS Secrets Manager o Azure Key Vault, dependiendo del proveedor de la infraestructura.
Obligar a los usuarios a crear contraseñas seguras es una buena idea, pero también hay que poner de su parte en el backend. Mantener las contraseñas fuera del almacenamiento de texto plano contribuirá en gran medida a proteger a sus usuarios y sus sistemas. El principal peligro del almacenamiento de contraseñas en texto plano es el escaso control de acceso; básicamente, cualquiera puede verlas. Es imperativo (especialmente en un entorno de IaC donde de repente, más personas tienen acceso a la información sensible) que se les aplique un hash adecuado y que sólo se les conceda acceso a aquellos que absolutamente lo necesitan.
Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos y vulnerabilidades de seguridad. También puedes probar un reto IaC de demostración dentro de la plataforma de formación Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.
Índice
Matias Madou, Ph.D. es experto en seguridad, investigador y CTO y cofundador de Secure Code Warrior. Matias obtuvo su doctorado en Seguridad de Aplicaciones en la Universidad de Gante, centrándose en soluciones de análisis estático. Más tarde se incorporó a Fortify en EE.UU., donde se dio cuenta de que no bastaba con detectar problemas de código sin ayudar a los desarrolladores a escribir código seguro. Esto le inspiró para desarrollar productos que ayuden a los desarrolladores, alivien la carga de la seguridad y superen las expectativas de los clientes. Cuando no está en su escritorio como parte de Team Awesome, le gusta estar en el escenario presentando en conferencias como RSA Conference, BlackHat y DefCon.
Secure Code Warrior está a disposición de su organización para ayudarle a proteger el código a lo largo de todo el ciclo de vida de desarrollo de software y crear una cultura en la que la ciberseguridad sea una prioridad. Tanto si es director de AppSec, desarrollador, CISO o cualquier persona implicada en la seguridad, podemos ayudar a su organización a reducir los riesgos asociados a un código inseguro.
Reservar una demostraciónDescargarRecursos para empezar
Evaluación comparativa de las competencias en materia de seguridad: optimización del diseño seguro en la empresa
El movimiento Secure-by-Design es el futuro del desarrollo de software seguro. Conozca los elementos clave que las empresas deben tener en cuenta cuando piensan en una iniciativa Secure-by-Design.
DigitalOcean reduce su deuda de seguridad con Secure Code Warrior
El uso por parte de DigitalOcean de la formación Secure Code Warrior ha reducido significativamente la deuda de seguridad, permitiendo a los equipos centrarse más en la innovación y la productividad. La mejora de la seguridad ha reforzado la calidad de sus productos y su ventaja competitiva. De cara al futuro, SCW Trust Score les ayudará a seguir mejorando las prácticas de seguridad y a continuar impulsando la innovación.
Recursos para empezar
La puntuación de confianza revela el valor de las iniciativas de mejora de la seguridad mediante el diseño
Nuestra investigación ha demostrado que la formación en código seguro funciona. Trust Score, que utiliza un algoritmo basado en más de 20 millones de puntos de datos de aprendizaje procedentes del trabajo de más de 250 000 alumnos en más de 600 organizaciones, revela su eficacia a la hora de reducir las vulnerabilidades y cómo hacer que la iniciativa sea aún más eficaz.
Seguridad reactiva frente a seguridad preventiva: Prevenir es mejor que curar
La idea de introducir la seguridad preventiva en el código y los sistemas heredados al mismo tiempo que en las aplicaciones más recientes puede parecer desalentadora, pero un planteamiento basado en el diseño seguro, aplicado mediante la mejora de las competencias de los desarrolladores, puede aplicar las mejores prácticas de seguridad a esos sistemas. Es la mejor oportunidad que tienen muchas organizaciones de mejorar su seguridad.
Ventajas de la evaluación comparativa de las competencias de seguridad de los desarrolladores
La creciente atención que se presta al código seguro y a los principios del diseño seguro exige que los desarrolladores reciban formación en ciberseguridad desde el principio del proceso de desarrollo de software, con herramientas como Secure Code Warrior's Trust Score, que ayudan a medir y mejorar sus progresos.
Impulsando iniciativas de seguridad por diseño para empresas con éxito significativo
Nuestro último documento de investigación, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise, es el resultado de un análisis profundo de iniciativas reales de Secure-by-Design a nivel empresarial y de la derivación de enfoques de mejores prácticas basados en hallazgos basados en datos.