Blog

Los codificadores conquistan la infraestructura de seguridad como serie de códigos: Almacenamiento de contraseñas en texto plano

Doctor Matias Madou
Publicado el 18 de mayo de 2020

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.


Ver recurso
Ver recurso

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.

¿Quiere saber más?

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ón
Compartir en:
Autor
Doctor Matias Madou
Publicado el 18 de mayo de 2020

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.

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.

Compartir en:

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.


Ver recurso
Ver recurso

Rellene el siguiente formulario para descargar el informe

Nos gustaría contar con su permiso para enviarle información sobre nuestros productos y/o temas relacionados con la codificación segura. Siempre trataremos sus datos personales con el máximo cuidado y nunca los venderemos a otras empresas con fines de marketing.

Enviar
Para enviar el formulario, habilite las cookies "Analytics". Siéntase libre de desactivarlas de nuevo una vez que haya terminado.

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.


Acceso a recursos

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ón
Descargar PDF
Ver recurso
Compartir en:
¿Quiere saber más?

Compartir en:
Autor
Doctor Matias Madou
Publicado el 18 de mayo de 2020

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.

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.

Compartir en:

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

Descargar PDF
Ver recurso
¿Quiere saber más?

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ónDescargar
Compartir en:
Centro de recursos

Recursos para empezar

Más entradas
Centro de recursos

Recursos para empezar

Más entradas