En el paradigma moderno de seguridad de la información para las masas, se ha establecido firmemente la creencia de que la ciberseguridad es costosa, difícil y prácticamente imposible para el usuario promedio. Entonces, si desea proteger completamente sus datos e información personal, cree una cuenta con Google o Amazon, identifíquelo en términos de identificación del propietario y verifique periódicamente las alertas de alarma de que una empresa grande y fuerte ha detenido otro intento de inicio de sesión.
Pero las personas que conocen la seguridad de la información siempre lo han sabido: los servicios en la nube son mucho más vulnerables que una estación de trabajo separada. De hecho, en caso de una situación de fuerza mayor, la PC puede restringir físicamente el acceso a la red, y allí la carrera ya comienza a cambiar las apariencias y las contraseñas en todas las áreas atacadas. La infraestructura de la nube es enorme, a menudo descentralizada, y los datos de varios clientes pueden almacenarse en el mismo medio físico, o viceversa, los datos de un cliente se extienden por los cinco continentes, y solo una cuenta los combina.
En resumen, cuando Internet era relativamente reciente y joven (y lo fue en 2003), los expertos en seguridad de la información analizaron cuidadosamente
el sistema de protección contra desbordamiento del búfer de buffer de 1997 y se incorporaron a la tecnología, que ahora llamamos
Honeytoken o Canarytoken. Y durante quince años han estado funcionando correctamente (y aún funcionan), solo la última investigación dice que, en lugar de la última línea de defensa en una serie de servicios de AWS, Honeytoken se convirtió en un agujero en la seguridad de la información debido a las peculiaridades de la implementación en el lado de Amazon.
¿Qué es Honeytoken?
Honeytoken, al igual que su progenitor ideológico en el sistema de protección de desbordamiento de pila, utiliza el enfoque de "advertir, no prevenir". De hecho, Honeytoken es un cebo para los atacantes, que se deja bajo el pretexto de información valiosa y se puede presentar en forma, por ejemplo, de un enlace. El Honeytoken más obvio en la práctica de los usuarios comunes es una alarma de enlace, oculta en una carta con el título "información de la cuenta bancaria" o "mis cuentas". El principio también es simple: tan pronto como un atacante echa un vistazo a la información que Honeytoken pretende ser, este último envía una alerta al propietario / administrador de que se ha violado el perímetro de seguridad.
El Honeytoken en sí obviamente no está incluido en el perímetro: en su forma clásica, es un muñeco banal que ya está dentro del perímetro y juega el mismo papel que los canarios que mueren en jaulas en las caras mineras, una advertencia sobre el peligro.
Y aquí está el progenitor de tecnología.Tales "sistemas de señalización" ahora son bastante comunes y se utilizan para alertar a los titulares de cuentas personales para alertar sobre violaciones de seguridad de AWS. Al mismo tiempo, no existe un único estándar Honeytoken: puede ser cualquier cosa. Por ejemplo, se agregan varios buzones muertos especiales a las listas de direcciones de correo electrónico de los clientes, con la aparición de una lista de correo en la que se indicará la descarga de toda la base de datos.
¿Cuál es la vulnerabilidad encontrada en AWS?
Amazon Web Services utiliza activamente el sistema Honeytokens para recibir alertas de alerta en la nube del perímetro del servicio. Amazon Canaries son claves de acceso de cuenta falsas. Esta herramienta, con toda su simplicidad, es extremadamente importante: los servicios en la nube están sujetos a intentos constantes de piratería y otros ataques. El hecho mismo de tener conocimiento sobre el "avance" del perímetro de ciberseguridad de AWS en una de las direcciones ya es la mitad de la victoria para los ingenieros de Amazon.
Ayer, 2 de octubre de 2018, los especialistas de Rhino Security Labs
publicaron un estudio extremadamente desagradable, cuya esencia se expresa en la siguiente declaración: Honeytokens Amazon Web Services se puede eludir sin alterar el sistema de señalización en la nube. Esto les da a los atacantes la oportunidad de "entrar" en silencio, "tomar" lo que necesitan y también "salir" en silencio.
Toda la arquitectura de Honeytokes AWS se basa en el uso de claves falsas junto con
CloudTrail , que también mantiene registros de actividad. Pero disponible gratuitamente en la guía del usuario de Amazon, hay una lista completa de direcciones y servicios que no son compatibles con CloudTrail. De hecho, esto significa que cualquier solicitud a estos servicios, incluso a través de la API, no está registrada en ningún lugar. Al mismo tiempo, Amazon devuelve los mensajes de retorno con un error de acceso junto con
ARN .
A continuación, los investigadores de Rhino Security "golpearon"
AWS AppStream a través de
la API DescribeFleets y recibieron la siguiente información sobre la cuenta de prueba:
Luego, con su ayuda, un atacante extrae información sobre el usuario / rol de
IAM del siguiente plan:
IAM User:
arn:aws:iam::111111111111:user/the-path/TheUserName
IAM Role:
arn:aws:iam::111111111111:role/the-path/TheRoleName/TheSessionNameComo resultado, gracias al retorno de ARN y los datos de usuario / rol de IAM recibidos, los especialistas pudieron comprometer las claves de cebo de Honeytokes en los servicios anteriores a través del análisis.
Contramedidas
La ruta encontrada pone
en peligro no solo a AWS, sino también a los desarrolladores de sistemas populares de honeytoken para sistemas de Amazon como
CanaryToken y
SpaceCrab . Ambos desarrolladores han sido notificados y están tomando todas las medidas posibles para resolver el problema.
Además, los especialistas de Rhino Security
publicaron un script PoC
en GitHub que verificará si la clave de AWS que se le proporciona es un token, ya que no todas las configuraciones se han actualizado todavía.
Reacción amazónica
Amazon informó a Rhino Security Labs que ARN no es información confidencial, CloudTrain funciona (y no funciona) donde sea necesario, y no hay ningún problema como tal.