Internet NO es un lugar seguro. Maravilloso por derecho propio, seguro, y útil en más de un sentido. Pero el ciberespacio también está lleno hasta los topes de agentes maliciosos: ladrones, piratas informáticos, infinidad de delincuentes diferentes que buscan aprovecharse de los débiles y los vulnerables. Pero no se alarme todavía. Mientras sepa a qué se enfrenta, tendrá más que una oportunidad de luchar contra los intrusos. Y, en 2022, lo más probable es que se enfrente a amenazas de control de acceso roto (BAC).
De hecho, destronando a las inyecciones SQL, el BAC se ha colocado a la cabeza de los 10 principales riesgos para la seguridad de las aplicaciones web según OWASP. Sí, según la mayor fundación de seguridad de software sin ánimo de lucro, el 3,81% de las aplicaciones analizadas eran susceptibles de sufrir amenazas de control de acceso roto (lo cual es MUCHO, por cierto).
Pero demos varios pasos atrás. ¿Qué es el control de acceso? Y, posteriormente, ¿qué es un control de acceso roto? ¿Cómo se “rompe” per se y eres vulnerable a ello? Todas buenas preguntas, así que vamos a entrar en materia.
Control de acceso roto: Explicación y ejemplos
Como se puede adivinar por el nombre, un control de acceso roto es una amenaza para la seguridad que permite a los intrusos acceder a datos no autorizados. El control de acceso, por otro lado, cubre las políticas y mecanismos que aseguran que usuarios específicos tengan acceso a componentes específicos y sólo a estos componentes.
Para simplificarlo (no es un juego de palabras), en cualquier sistema hay personas que desempeñan distintas funciones. Quieres que puedan hacerlo libremente (hasta cierto punto), pero rara vez quieres que todos los implicados puedan acceder a todo el sistema. Ahí es donde entra en juego el control de acceso.
Por supuesto, cuando se rompe, y cualquiera puede acceder a lo que quiera, se desata el infierno. Al saltarse los permisos previstos, los intrusos pueden revelar información confidencial, modificar y borrar directamente todos los datos o realizar funciones empresariales que usted no desea que lleven a cabo.
Y, siendo el control de acceso roto la amenaza de seguridad de aplicaciones web número 1 en el mundo hoy en día, hemos visto innumerables ejemplos exitosos de BAC. Desde pequeñas empresas que caen víctimas por confiar en datos no verificados hasta los mayores imperios en línea que han sido llevados a la quiebra por hackers que fuerzan la navegación en las URL objetivo.
Pero antes de ver ejemplos concretos, vamos a averiguar qué es el control de acceso en el mundo del software y qué lo rompe.
¿Qué es el control de acceso roto?
Un control de acceso roto es un fallo por parte de la aplicación web a la hora de llevar a cabo y mantener políticas de acceso preestablecidas. ¿Cuáles son estas políticas? Desde el punto de vista de las aplicaciones web, el control de acceso se divide en tres categorías principales:
- Control de acceso administrativo. En este caso, se trata de los protocolos de acceso definidos e implementados para aplicar la política de seguridad general. En general, este tipo se divide en dos subcategorías: protocolos de personal y protocolos de negocio. Por poner algunos ejemplos más concretos, se trataría de las políticas cotidianas, los procedimientos de contratación y la comprobación de antecedentes.
- Control de acceso técnico. En el lado opuesto, también conocido como control de acceso lógico, están las restricciones basadas en software y hardware. Éstas crean múltiples capas de protección adicionales para salvaguardar el sistema (o sus recursos) de accesos no autorizados. Estas implementaciones suelen incluir elementos como contraseñas, tarjetas inteligentes, diferentes claves digitales, protocolos, cortafuegos y mucho más. Como es de esperar, ayudan mucho a la hora de aumentar la seguridad de la API del sistema.
- Control de acceso físico. Esta es la parte que abarca cámaras de vídeo, puertas, vallas, guardias de seguridad y cerraduras que limitan el acceso a entornos específicos. Como su nombre indica, el control de acceso físico se centra en el lado no tecnológico de la ecuación. Huelga decir que esta categoría es tan importante como las dos anteriores, pero hoy hablaremos sobre todo de la perspectiva “tecnológica”.
Cómo se realiza el control de acceso
En cuanto al aspecto técnico, el control de acceso se divide en tres grupos: archivos de sólo lectura, datos legibles y grabables, y recursos ejecutables. Pero, dependiendo del tipo de archivo con el que estés trabajando en ese momento, estos pueden variar mucho. Dicho esto, siempre querrás que se lleven a cabo mediante el procedimiento operativo aprobado (de antemano). Para ser más precisos, el sistema debe aplicar protocolos precisos de varios pasos.
En primer lugar, debe identificar la identidad del sujeto. Esta identificación indica al sistema quién ha solicitado el acceso.
El siguiente paso es identificar a la persona que está detrás de la solicitud, lo que suele hacerse mediante algún proceso de autenticación.
Suponiendo que el paso de autenticación no lo detenga, el siguiente paso es comprobar la solicitud con la lista de control de acceso. Aquí es donde el sistema se asegura de que la persona detrás de la solicitud tiene la autoridad para acceder a los recursos que está solicitando. Además, el sistema determina el nivel de acceso que se debe conceder a esta persona.
Por último, pero no por ello menos importante, el sistema debe incluir siempre mecanismos de auditoría que detecten y examinen posibles fallos y puntos débiles. Con ellos, debería ser capaz de detectar las formas en que alguien podría eludir las restricciones de acceso antes de que lo haga.
Qué rompe el control de acceso
Para entender cómo proteger el sistema, primero tienes que entender cómo romper el sistema, ¿verdad? Así es. Con eso en mente, vamos a ponerlo todo en la línea y averiguar lo que rompe el control de acceso.
Lo primero es lo primero, hay múltiples maneras en que los servidores pueden proporcionar y denegar derechos para solicitar ciertos recursos. Estos incluyen cookies de sesión, tokens JWT, y más. Como hemos establecido anteriormente, cuando los usuarios solicitan acceso a recursos específicos, el sistema primero se asegura de que pueden acceder a estos recursos antes de ejecutar la solicitud. La parte de “asegurarse” puede llevarse a cabo a través de llamadas GET, así como diferentes métodos HTTP como POST/PUT/DELETE. Ahí es donde radica el problema. Dado que los desarrolladores deben asegurar cada punto final con cada método HTTP posible, es fácil pasar por alto al menos una (o más) entrada.
En otras palabras, el control de acceso “se rompe” cuando los intrusos son capaces de solicitar con éxito el acceso a algo a lo que no deberían tener acceso. La mayoría de las veces, esto ocurre cuando los desarrolladores no aseguran los protocolos de autorización. El ejemplo más común serían los endpoints en sitios que arrojan errores 403 forbidden que luego se pueden eludir añadiendo un X-Forwarded-For: “127.0.0.1”.
Otro ejemplo típico serían los directorios antiguos de la fase de desarrollo que deberían haberse eliminado o protegido pero no lo han hecho.
Los usuarios más inexpertos también podrían almacenar contraseñas en texto plano en el sistema. Así, cuando el sistema (normalmente el ordenador) se ve comprometido, los hackers también podrían acceder a diferentes sistemas utilizando estas contraseñas.
Otras veces, la gente confía en contraseñas débiles que, incluso sin exposición accidental, pueden ser fácilmente descifradas, permitiendo un control de acceso roto.
Y eso sin contar con los ataques intencionados al control de acceso, que son harina de otro costal.
Ejemplos de controles de acceso rotos
Los posibles vectores de ataque que los hackers pueden adoptar para romper el control de acceso son demasiados para contarlos. Dicho esto, suelen funcionar a través de los mismos principios.
No restringir el acceso a las URL
El ataque de control de acceso más común se produce cuando una URL se salta la autenticación, engañando al sistema haciéndole creer que ya ha sido autenticado. Utilizando tanto el formato como el conocimiento de patrones, los hackers son capaces de escribir la URL de páginas privilegiadas que no han sido configuradas correctamente.
Por poner un ejemplo, imagina un pequeño pez que se registra. Su página principal se vería algo así:
| 1 2 3 | https://webdevsagainsthackers.net/fish_login.html |
¿Ves algo sospechoso (intencionado esta vez)? La URL muestra fish_login.html como página principal.
Todo lo que los hackers tienen que hacer en este caso para recibir acceso completo de tiburón es poner la URL así:
| 1 2 3 | https://webdevsagainsthackers.net/shark_login.html |
En este punto, los atacantes han sido capaces de obtener acceso a los tiburones sin hacer nada más que cambiar la URL. ¿Fácil? Claro, pero efectivo contra desarrolladores inexpertos.
Referencias directas inseguras a objetos (IDOR)
Esto es un poco más complicado. Verás, hay múltiples formas en las que los agentes maliciosos pueden acceder al código duro de una aplicación web. Partes de ese código podrían revelar cómo está organizada tu base de datos en lo que se refiere a formato, patrón y más. Con sólo estas pocas piezas, los hackers habilidosos pueden exponer más información a sondeos posteriores.
En el siguiente acceso, entras en tu cuenta de un sitio web y estás viendo su página principal. En la barra de direcciones, ves una URL como esta:
| 1 2 3 | https://webdevsagainsthackers.net/index.php/view?account=4200 |
¿Qué tenemos aquí? Algo que parece una larga lista de cuentas, y tú eres el número 4200 de la base de datos.
A primera vista, nada sospechoso. Pero todo lo que tiene que hacer un agente malicioso para acceder a las cuentas de otros usuarios es poner un número de cuenta diferente. A veces (más a menudo de lo que debería), la(s) cuenta(s) de administrador(es) está(n) asignada(s) a los primeros números 1-10. Así que, lo giras así:
| 1 2 3 | https://webdevsagainsthackers.net/index.php/view?account=1 |
y los usuarios equivocados podrían acceder a las cuentas de administrador.
“Espera un segundo, ¿eso no parece (ni suena) tan diferente del ataque anterior?”. Tienes razón. Pero también te equivocas.
La diferencia aquí es que, en este caso, los hackers están explotando referencias a objetos. La mayoría de las aplicaciones web utilizan nombres de página predeterminados basados en la configuración MVC (modelo, vista y controlador). En este caso, los piratas informáticos pueden acceder al código fuente de estas aplicaciones web.
Consideremos la sección “Acerca de nosotros” que tienen la mayoría de los sitios web. La siguiente dirección muestra que todas las páginas terminan con .htm (o algo parecido):
| 1 2 3 | https://webdevsagainsthackers.net/against/default.aspx?content=about_us.htm |
Los hackers saben que la parte default.aspx.cs es la página principal y podrían querer investigar más.
Utilizando un ataque de byte nulo (./), pueden engañar al código del navegador haciéndole creer que la URL está completa. La cadena que sigue al byte nulo permite a los atacantes revelar qué hay dentro de cualquier archivo escrito:
| 1 2 3 | https://webdevsagainsthackers.net/against/default.aspx?content=%20./default.aspx.cs%00.htm |
En este ejemplo, los hackers han podido acceder a una página completa de código fuente desde default.aspx.cs. Por supuesto, es posible con cualquier nombre de página por defecto.
Las referencias directas a objetos también podrían aparecer en un código de error. Todo lo que los hackers tienen que hacer es manipular las entradas para averiguar qué excepciones/errores podrían aparecer y qué podrían decir. Esto les da más información que necesitan buscar en la URL.
Ejemplos reales de alcoholemia
De nuevo, teniendo en cuenta que el BAC es la principal amenaza para la seguridad del software en la actualidad, ni siquiera los mayores monstruos mediáticos se han librado en el pasado. Estos son sólo algunos ejemplos:
Snapchat.Gibson Security ha detectado vulnerabilidades de control de acceso en el sistema de Snapchat que en un principio se descartaron como intrascendentes. No pasó más de una semana y las enumeraciones por fuerza bruta habían revelado 4,6 millones de nombres de usuario y números de teléfono. Ni que decir tiene que los usuarios afectados no estaban nada contentos con la filtración de datos.
Páginas de empresa de Facebook.Laxman Muthiyah ha descubierto que usuarios malintencionados podían emitir una solicitud para asignarse a sí mismos permisos de administrador para determinadas páginas de Facebook. Como Facebook no garantizaba medidas seguras de control de acceso, todo lo que tenían que hacer los hackers era utilizar una solicitud como ésta:
| 1 2 3 | Request :- |
POST //userpermissions HTTP/1.1
Host : graph.facebook.com
Content-Length: 245
role=MANAGER&user=&business=&access_token=
Response :-
true
y se harían administradores de la página. Como puedes adivinar, con este nuevo privilegio, podrían denegar el acceso a los administradores/gestores reales de la página.
Cómo prevenir la alcoholemia
Para garantizar un control de acceso eficaz, primero hay que asegurarse de que el sistema lo aplica a través de código de confianza del lado del servidor o API sin servidor. De este modo, podrá evitar que los piratas informáticos modifiquen la comprobación del control de acceso o los metadatos.
Aparte de eso, los siguientes pasos le ayudarán a evitar que se rompa el control de acceso:
- Comprueba los permisos y asegúrate de que están en su sitio. Por supuesto, el truco está en ser minucioso y comprobar todos y cada uno de los archivos. En caso de duda, sigue el principio del menor privilegio: asegúrate de que sólo tienen acceso de escritura a determinados archivos las personas que necesitan poder editarlos.
- Desactiva la caché cliente en las páginas restringidas. De lo contrario, usuarios no autorizados podrían volver a acceder a esas páginas.
- Evita los llamados mecanismos de control de acceso de presentación. Que no haya un botón visible que lleve a los usuarios a páginas restringidas no significa que los atacantes no puedan encontrarlo. Es básicamente seguridad a través de la oscuridad, que es un principio que NO se sostiene contra hackers serios. En su lugar, bloquee las páginas sensibles tras la autenticación.
- Deniega el acceso a todas las funciones por defecto. De esta manera, le será más fácil mantener los permisos en su punto. Además, asegúrese de utilizar listas de control de acceso, así como prácticas de autenticación basadas en roles.
- No nombres las páginas de destino con significado. Si lo hace, estará ayudando a los intrusos a identificarlas. En su lugar, utilice pares clave-valor que hagan referencia a los objetos.
Resumen rápido
Uno no se gana el primer puesto en la lista de amenazas a la seguridad del software sin causar graves daños y permitir que se produzcan aún más daños en el futuro. A menos que aún no lo hayamos dejado suficientemente claro, tienes que respetar la amenaza del control de acceso roto, o puede que no te guste la alternativa. Aún así, siempre que sepas a qué te enfrentas, cómo prevenirlo y cómo luchar contra el BAC, deberías estar bien.