Ayer se conoció otra violación de seguridad, esta vez en el banco Capital One, con la particularidad que las victimas llegan a los 100 millones de personas. No es que el banco tenga esa cantidad de clientes, pero procesa tarjetas de crédito y muchas personas aplican a las mismas, y mas allá del resultado de la aplicación (rechazo o aceptación), los datos son procesados y almacenados por Capital One.
Según el documento federal donde se hace la acusación a la imputada principal, todo empezó por una aviso al banco de parte de un hacker sombrero gris. En la jerga de seguridad se habla de sombrero gris a los hackers que sin violar la ley, no actúan dentro de los protocolos de la industria. En este caso, el hacker pidió una paga para ayudar a encontrar al hacker que había publicado en GitHub una serie de archivos propiedad del banco. En base a esta denuncia se investigó los archivos que estaban en esa cuenta de GitHub y se confirmó que había datos personales de millones de personas que habían aplicado para tener una tarjeta de crédito.
Explicación completa desde el podcast #Takocoin:
Conectar con la responsable no fue difícil, ademas de haber dejado rastros en diversos chats en Slack y foros con su nick habitual («erratic»), el Github usado estaba vinculado a su cuenta personal donde tiene su apellido (paigeadelethompson es el user de Github, su nombre completo es Paige A. Thompson).
¿Cómo se pueden «filtrar» 30Gb de datos de una entidad financiera? Según la acusación, hubo al menos un bucket de S3 (almacenamiento de archivo de AWS, Amazon Web Services) mal configurado. No es la primera vez que ocurre, ya debe haber decenas de casos donde una empresa deja un permiso que no corresponde en este sistema de archivos y cualquiera puede ver el contenido de los archivos. Incluso hay herramientas gratuitas para buscarlos, por ejemplo:
How to search for Open Amazon s3 Buckets and their contents
Este sistema de almacenamiento tiene la posibilidad de abrir los archivos al público general porque se usa para publicar en páginas web, tipicamente se usa con imágenes, pero hay páginas enteras con este sistema (HTML, CSS, JS, etc).
No sabemos exactamente como hizo Paige para encontrar el bucket S3 que contiene los archivos, pero probablemente haya usado el hecho que por defecto el nombre del bucket está compuesto por un dominio y otra información predecible. Que los buckets tengan un nombre predecible no debería ser un problema si los permisos están bien establecidos. Pero aparentemente este no fue el caso, lo que es notable porque por defecto los permisos de S3 son restrictivos, y hay que hacer un esfuerzo para dejar el contenido público. Este «esfuerzo» puede ser voluntario o no, ya que siempre puede haber errores, pero necesariamente el cliente de AWS tiene que hacer algo.
Como decía anteriormente, esto ha ocurrido varias veces antes, lo sorprendente en este caso es que quien encontró esta información la puso en su propio repositorio de GitHub. Tampoco sería la primera vez un hacker hacer algo estúpido, aunque es un tema para estar atentos en que pasó y cual fue el motivo. Por lo pronto, no hay que dejar de destacar la mala praxis de Capital One al dejar toda esta información al alcance de cualquiera, ya que Paige no usó ninguna clave privada ni hizo un «hackeo» en el sentido común de la palabra, simplemente encontró algo que otro dejó descuidado.
La enseñanza de esta historia, ademas del potencial peligro que es usar mal un storage online como AWS S3, es como consumidor pensar que cualquier dato que uno ingrese online, puede potencialmente terminar público, no hay ninguna garantía de lo contrario.
Sebastián Bassi es AWS Certified Solutions Architect – Associate.
infosertecla.com 