Otras definiciones

Otras definiciones importantes que reconocer son:

• Actores de amenaza: estos actores son individuos o grupos de personas que realizan un ataque contra otros.

• Aficionados o script kiddies: son aquellos que tienen poca o nula habilidad, pero utilizan script o descargan y usan herramientas o programas sofisticadas desarrollados por otros, fáciles de usar, para atacar sistemas informáticos, redes y defectos de sitios web. (Valencia, 2018)

• Hacktivista: sus actividades contra ideologías políticas o sociales, del tipo protesta. Generalmente sus intenciones son de denegar servicio, modificar páginas web o filtrar información sensible. La diferencia con el hacking es que éste es una irrupción ilegal a sistemas computacionales con fines criminales, mientras que el hacktivismo es el uso legal o ilegal de herramientas digitales para fines políticos y de protesta. (Muy Interesante, 2018)

• Usuario descuidado: es un usuario sin conocimientos específicos o apropiados y que accidentalmente daña la información, servicios o infraestructura de un sistema informático.

• Cracker o ciberdelincuente: Del inglés to crack, que significa romper o quebrar. Este término se utiliza para referirse a las personas que tienen grandes conocimientos de software, hardware y redes, y rompen o vulneran algún sistema de seguridad y puede diseñar sus propias armas para atacar a una persona u organización para un beneficio económico, protesta o por desafío. Este utiliza sus conocimientos para invadir sistemas, descifrar y algoritmos de encriptación, ya sea para poder correr juegos sin un CD-ROM, o generar una clave de registro falsa para un determinado programa, robar datos personales, o cometer otros actos ilícitos informáticos. Algunos intentan ganar dinero vendiendo la información robada, otros sólo lo hacen por fama o diversión. (Valencia, 2018)

• APT o amenaza persistente avanzada: es un ataque dirigido con un gran nivel de sofisticación, grandes recursos, gran entrenamiento y motivación. Usan malware, vulnerabilidades de día cero, ingeniería social y otras herramientas.

¿Cómo podemos prevenir la Pérdida de Control de Acceso?

Según hemos revisado a lo largo de este módulo, la primera respuesta que deberíamos dar a esta pregunta es diseñando la aplicación en base a políticas de acceso claras para cada archivo y tipos de usuarios/administradores. El control de acceso debe implementarse y ejecutarse a través de una matriz de control de acceso, que definirá las reglas para cada tipo de usuario. Estos puntos de acceso deben ser probados rigurosamente creando diferentes cuentas e intentando acceder a áreas no autorizadas, para así asegurarnos de no dejar “abierto” ningún acceso que ponga en riesgo nuestro sistema y/o aplicación.

Otras recomendaciones incluyen:

• Comprobar los permisos de los archivos individuales, no solo los directorios.
• Asegurarse de que el público no tenga acceso a los archivos de configuración, archivos predeterminados y scripts. Limitar los accesos al directorio y los archivos ejecutables también.
• Restringir el almacenamiento en caché. El almacenamiento en caché del lado del cliente ayuda a acelerar los sitios web, pero otros pueden volver a acceder a esta información.
• Use encabezados http y meta etiquetas para evitar que se recarguen las páginas restringidas
• No confíe en el «control de acceso a la presentación». La eliminación de un botón de navegación no evitará que atacantes lleguen allí. Cada página debe estar autenticada.
• Limitar los permisos de administración remota tanto como sea posible.

Finalmente, un ciclo de desarrollo seguro debe incluir una prueba de penetración antes de lanzar el sistema a producción y mientras éste esté operando.

¿Cómo podemos detectar vulnerabilidades de Control de Acceso?

Tener una guía escrita que describa los diversos permisos necesarios es indispensable. Es altamente probable que, si se carece de esta guía, la aplicación sea vulnerable a Pérdida de Control de Acceso

Para detectar las posibilidades de Pérdida de Control de Acceso es necesario efectuar revisiones manuales del código, puesto que herramientas automatizadas son inefectivas para detectar estos errores en la programación. Es imprescindible, además, comprender cómo los usuarios y administradores se autentican y acceden al sitio (lo que suele suceder en un portal de acceso remoto), por lo que las pruebas de penetración hechas por una entidad independiente se hacen ultra necesarias, y éstas deben incluir una auditoría exhaustiva de todos los datos accesibles y sus permisos otorgados.

¿Cómo se usa la Pérdida de Control de Acceso en un ataque?

• En 2012, hackers maliciosos obtuvieron acceso a los servidores de IRS (el SII estadounidense) en Carolina del Sur a través de una contraseña de administrador predeterminada, robando 3.6 millones de números de seguridad social.
• Un sitio web que enumera su rol de usuario en la URL, por ejemplo, http: // sitio web / usuario / cuenta. Un atacante simplemente puede cambiar la URL a http: // sitio web / administración / cuenta y eludir las contraseñas u otros controles.
• Un ataque de fuerza bruta podría dañar un panel de administración si éste tuviese una contraseña débil o predeterminada.
• Las referencias inseguras de objetos directos son variables que pueden ser manipuladas por el destinatario y utilizadas para recuperar más datos. Por ejemplo, un usuario puede obtener una lista de contraseñas o acceder a otros archivos con comandos simples en la ventana de la URL.

Vulnerabilidades en aplicaciones

El documento de la OWASP Top Ten (2017, pág. 12) sobre Los diez riesgos más críticos en Aplicaciones Web, nos señala algunos ejemplos de vulnerabilidades en el siguiente listado:

• Falta hardening adecuado en cualquier parte del stack tecnológico, o permisos mal configurados en los servicios de la nube.
• Se encuentran instaladas o habilitadas características innecesarias (ej. puertos, servicios, páginas, cuentas o permisos)
• Para los sistemas actualizados, las nuevas funciones de seguridad se encuentran desactivadas o no se encuentran configuradas de forma adecuada o segura.
• Las configuraciones de seguridad en el servidor de aplicaciones, en el framework de aplicación (ej., Struts, Spring, ASP.NET), bibliotecas o bases de datos no se encuentran especificados con valores seguros.
• El servidor no envía directrices o cabeceras de seguridad a los clientes o se encuentran configurados con valores inseguros.

Hay que recordar que el atacante o ciberdelincuente por lo general intentará explotar vulnerabilidades que no han sido parchadas, acceder a cuentas por defecto, páginas no utilizadas, archivos y directorios desprotegidos, etc. Así, de este modo obtendrá acceso o conocimiento de nuestro sistema.

Por ello, algunos consejos para evitar vulnerabilidades de seguridad son:

• Configurar los entornos de desarrollo, de control de calidad (QA) y de producción de manera idéntica y con diferentes credenciales para cada uno.

• Usar una plataforma minimalista sin funcionalidades innecesarias, componentes, documentación o ejemplo. Elimine o no instale frameworks y/o funcionalidades que no serán utilizadas

• Diseñar y seguir un proceso para revisar y actualizar las configuraciones apropiadas de acuerdo a las advertencias de seguridad y siguiendo un proceso de gestión de parches

• Tener una arquitectura segmentada que proporcione una separación efectiva y segura entre componentes y acceso a terceros en el sistema y/o aplicación

• Utilizar un proceso automatizado para verificar la efectividad de los ajustes y configuraciones en todos los ambientes

Algunas recomendaciones para la mitigación de esta vulnerabilidad son:

• No utilizar contraseñas comunes
• No utilizar usuarios genéricos
• No usar configuraciones por defecto
• Configurar correctamente los permisos y propietarios de directorios y archivos
• Mantener los sistemas actualizados
• Configurar de forma correcta las cabeceras HTTP
• Evitar exponer componentes y versiones en las cabeceras o en las rutas de archivos

Formas de XSS para atacar navegadores:

Como se mencionó en párrafos anteriores, existen 3 formas de XSS para atacar a los navegadores de los usuarios, estos son:

• XSS Reflejado o no persistente: Una URL transporta un parámetro modificado que actúa al ser accedido por un visitante.

Es decir que el código que insertamos no se queda almacenado en la web, sino que va insertado dentro de un enlace que llega de algún modo a la víctima para que pinche en él, una vez hecho eso el navegador dirigirá a una página donde el usuario tenga cuenta o deba rellenar algún formulario, allí ejecutará el código (malicioso) insertado y el atacante le robará la cookie de la sesión, o los datos insertados en el formulario. Lo complejo de este ataque, como nombramos más arriba, es que nada queda almacenado en el servidor web. (NIVEL4 Seguridad, 2018)

• XSS Almacenado o persistente: La API almacena datos proporcionados por el usuario sin validar ni sanear, los que posteriormente son visualizados o utilizados por otro usuario o un administrador. Usualmente es considerado como de riesgo de nivel alto o crítico.

En ambos casos, el atacante malicioso inyecta código sobre algún campo de entrada de datos que ofrezca la página web, bien sea este la típica cajita con el icono de la lupa para búsqueda de palabras clave, un recuadro de espacio de participación en un foro, o un formulario de recogida de datos.

• XSS Basados en DOM: frameworks en JavaScript, aplicaciones de página única o APIs incluyen datos dinámicamente, controlables por un atacante. Idealmente, se debe evitar procesar datos controlables por el atacante en APIs no seguras.

• Los ataques XSS incluyen el robo de la sesión, apropiación de la cuenta, evasión de autentificación de múltiples pasos, reemplazo de nodos DOM, inclusión de troyanos de autentificación, ataques contra el navegador, descarga de software malicioso, keyloggers, entre otros.

• Hoy existen herramientas automatizadas que permiten detectar y explotar las tres formas de XSS, y también se encuentran disponibles kits de explotación gratuitos.

• El impacto de XSS es moderado para el caso de XSS Reflejado y XSS en DOM, y severa para XSS Almacenado, que permite ejecutar secuencias de comandos en el navegador de la víctima, para robar credenciales, secuestrar sesiones, o la instalación de software malicioso en el equipo de la víctima. (NIVEL4 Seguridad, 2018)

Según el artículo Buenas prácticas de desarrollo seguro: A7 – Secuencia de comandos en sitios cruzados (XSS) (NIVEL4 Seguridad, 2018), señala que, dado que los ataques XSS ocurren debido a inyecciones de código, para prevenir dichos ataques, es necesario que se manejen adecuadamente las entradas de información que el sistema o aplicación utilizará. También es importante que todos los parámetros de entrada sean correctamente validados y filtrados de acuerdo a distintos criterios.

El tratamiento de estos datos puede ser:

• Filtrar: En base a patrones o expresiones regulares, determinar qué tipo de datos acepta el sistema y cuáles no.
• Escapar: Aceptar todo tipo de datos, pero escapándolos correctamente.
• Sanear: Aceptar todo tipo de datos, pero eliminando el contenido inapropiado.
• Transformar: Aceptar todo tipo de datos, pero transformándolos a un tipo de datos aceptado.

Entender la diferencia que existe entre estos distintos métodos es fundamental, ya que se debe adaptar al funcionamiento de la aplicación. Por ejemplo, si tenemos un editor de texto enriquecido, mediante el cual se permite al usuario manipular código HTML, no se debería optar por la opción de escapar los caracteres, ya que al momento de mostrar la información el navegador no lo interpretará y lo mostrará como texto.

Para entender cómo funcionan cada uno de estos métodos, los invitamos a revisar la siguiente imagen:

En el input de ejemplo se puede ver un script javascript, el cual gatilla una alerta en el navegador. Dependiendo el tipo de método que apliquemos sobre los parámetros de entrada, podemos ver el output que deberíamos obtener.

Ejemplo de deserelización insegura

A continuación podemos visualizar un ejemplo en lenguaje Java de deserialziación insegura.

import java.io.*;
 
public class Main {
    public static void main(String[] args) throws IOException, ClassNotFoundException {
        ObjectInputStream ois = new ObjectInputStream(new FileInputStream("file.ser"));
        Object object = ois.readObject();
        ois.close();
 
        if (object instanceof User) {
            User user = (User) object;
            System.out.println("User: " + user.getName() + ", Password: " + user.getPassword());
        } else if (object instanceof Admin) {
            Admin admin = (Admin) object;
            System.out.println("Admin: " + admin.getUsername() + ", Role: " + admin.getRole());
        }
    }
}

Este ejemplo de deserialización insegura funciona utilizando ObjectInputStream para leer objetos serializados desde un archivo llamado file.ser. El código lee el primer objeto deserializado del archivo, que supón que es una instancia de la clase User o Admin, y luego imprime información específica según sea la instancia.

El problema se produce porque no hay ninguna validación ni filtro sobre los objetos deserializados antes de usarlos. Si un atacante crea un archivo serializado que contiene un objeto malicioso, como una clase no autorizada o que contenga código malicioso, el código podría ejecutar este código en memoria y provocar un ataque de deserialización inseguro.

Para reducir la exposición a vulnerabilidades de deserialización insegura, se debe implementar una lógica de validación adecuada antes de procesar los objetos deserializados. Esto podría incluir:

• Verificar que el tipo del objeto serializado coincide con la clase que se espera utilizar para el deserializador.
• Filtrar y/ó transformar los datos antes de intentar usarlos.
• Protegerse contra ataques de deserialización en cadena, asegurándose de que solo se puedan serializar tipos autorizados y no clases internas o específicas de la implementación del proyecto.

En resumen, el objetivo principal de deserialización insegura es permitir que un atacante modifique la lógica de la aplicación, lo que puede llevar a ataques de denegación de servicio (DoS), omisiones de autenticación y ejecución remota de código. Por lo tanto, es importante implementar medidas de seguridad para protegerse frente a esta vulnerabilidad, como limitar el tipo de objetos que pueden ser deserializados o filtrar los datos antes de utilizarlos.

Recomendaciones

El único patrón de arquitectura seguro es no aceptar objetos serializados de fuentes no confiables o utilizar medios de serialización que sólo permitan tipos de datos primitivos. Si esto no es posible, considere alguno de los siguientes puntos:

• Implemente verificaciones de integridad tales como firmas digitales en cualquier objeto serializado, con el fin de detectar modificaciones no autorizadas.
• Aísle el código que realiza la deserialización, de modo que se ejecute en un entorno con los mínimos privilegios posibles.
• Registre las excepciones y fallas en la deserialización, tales como cuando el tipo recibido no es el esperado, o la deserialización produce algún tipo de error.
• Monitoree los procesos de deserialización, alertando si un usuario deserializa constantemente.