Categoría: Noticias-Seguridad

Noticias, Ponencias y Formaciones de éxito realizadas y relacionadas con el Departamento de Seguridad Informática de Sidertia Solutions

En el contexto informático actual, cuando hablamos en el ámbito de las grandes empresas, la gestión de correo y documentación ofimática es una ardua tarea y supone una vulnerabilidad. Para ello Microsoft actualiza sus herramientas con nuevas características que nos permiten hacer más sencilla la administración de cuentas y la detección de ciertos ataques de ingeniería social destinados a los usuarios, en este caso de alto cargo.

Las cuentas administradas por altos cargos suelen tener acceso a información más sensible y contar con privilegios de acceso, Microsoft denomina a estas como cuentas prioritarias o de alta prioridad.

Lo que hace más difícil de proteger este tipo de cuentas es que, hay una gran cantidad de tráfico legítimo y necesario, pero de igual manera, tráfico irregular que suele ser spam, phishing, etc. Y es en esto en lo que se pueden basar los atacantes para realizar sus incursiones. Estudian el tráfico que fluye, tanto de correo como documentación y lo pueden utilizar para solicitar algún tipo de acceso o privilegio, incluso directamente hacerse con la cuenta.

Las mejores medidas convencionales contra este tipo de ataques, es prevenir a través de una buena política de concienciación y formación constantes, habilitando además una zona de reportes de correo sospechoso entre otros.

Desde Sidertia Solutions, somos conscientes de la problemática actual que esto conlleva y por ello hacemos esto mismo con simulacros para que nuestros empleados estén siempre alertas y minimizar riesgos, ya que tratamos con información sensible.

Además de siempre intentar concienciar a nuestros clientes de este tipo de medidas y lo importante que es su aplicación en todos los niveles y tipos de usuarios.

Microsoft incorpora continuamente herramientas de inteligencia que cada vez más ayudan a mitigar este tipo de problemáticas. Con herramientas de análisis y de control de tráfico, etiquetando como hemos dicho, los tipos de cuenta a nivel administrativo y valorando las direcciones y los dominios a los que pertenecen. Aprendiendo de ataques anteriores y mejorando el sistema de análisis con cada intento de ataque.

Microsoft 365 ha añadido dos nuevas funcionalidades para la protección en este ámbito:

  • Protección de cuenta prioritaria
  • Supervisión de flujo de correo premium.

Protección de cuentas prioritarias Microsoft

Microsoft Defender para Office 365 admite el uso de etiquetas especiales en las cuentas prioritarias que se pueden usar como filtros en alertas, informes e investigaciones.

Las etiquetas se habilitan desde el panel de seguridad:

Se añaden además dos funcionalidades extra sobre estas cuentas:

  • Heuristica adicional: La etiqueta de cuentas prioritarias ofrece un análisis con una heurística adicional especial que se adapta singularmente a las cuentas de cargos ejecutivos. Aprendiendo de análisis previamente

Supervisión de flujo de correo premium

La capacidad en un servicio de correo, de fluir de manera eficiente y sin dar grandes fallos, es una característica especialmente importante en estas cuentas que manejan información sensible, por tanto, esta opción que nos da la etiqueta de cuenta prioritaria, consiste en alertas para los administradores cuando los correos fallidos o pendientes de reenvío superan cierto umbral de fallo, mismo que el administrador deberá valorar con base en el tipo de cuenta prioritaria y su experiencia.

Con esta opción activada podremos ver también informes de los eventos fallidos de los últimos 15 minutos y los mensajes de correo electrónico retrasados de las últimas 6 horas que se enviaron desde cuentas prioritarias.

La sección de correo electrónico incorrecto muestra la siguiente información sobre los mensajes del usuario marcado como prioritario:

  • Fecha
  • Remitente
  • Destinatario
  • Asunto
  • Estado, siendo el valor de este último Fallido o Retrasado.

Requisitos a tener en cuenta:

La característica de protección de cuentas prioritarias sólo está disponible con los siguientes requisitos:

  • Microsoft defender para Office 365 plan 2, incluidos aquellos con Office 365 E3, Office 365 E5 o Microsoft 365 E5 Security.

La característica de supervisión de flujo de correo premium está disponible con los siguientes requisitos:

  • Tener al menos 5000 licencias de uno o varios de los siguientes servicios: Office 365 E3, Microsoft 365 E3, Office 365 E5, Microsoft 365 E5.
  • Tener al menos 50 usuarios activos mensuales para una o más cargas de trabajo principales: Teams, One Drive for Business, SharePoint Online, Exchange Online y aplicaciones de Office.

La seguridad continúa siendo una de las mayores preocupaciones y una gran responsabilidad que enfrentan las actuales empresas, sobre todo las PYMES, que suelen ser el principal objetivo de los atacantes.

Microsoft ha tomado cartas en el asunto presentando Microsoft Defender for Business, una solución de seguridad para pequeñas y medianas empresas integrada en Microsoft 365 Business Premium.

Desde Sidertia Solutions consideramos que, contar con esta solución de seguridad es de suma importancia para cualquier entorno, aplicando y trabajando sobre esta solución en los propios, así como recomendándola a nuestros clientes.

Funcionamiento de Microsoft Defender

Microsoft Defender for Business está diseñado para brindar seguridad de endpoint para pequeñas y medianas empresas, ofreciendo diferentes capacidades como la gestión de amenazas y vulnerabilidades, reducción de la superficie de ataque, protección de próxima generación, detección y respuesta de Endpoint, investigación y remediación automatizadas y API e integración.

En los endpoint es donde comienzan los ataques, y por todos es sabido que ofrecen protección contra virus y amenazas en estos mismos, su objetivo es solventar las amenazas antes de que se establezcan y se propaguen lateralmente en su entorno y así evitar que las amenazas se conviertan en administradores de su sistema, pudiendo modificar su infraestructura y servicios u obtener información sensible, Microsoft Defender for Business investigará y responderá automáticamente ante las amenazas.

Microsoft Defender for Business es compatible y aplicable a cualquier entorno independientemente del Sistema Operativo que este disponga, tales como Windows, Android y iOS. Estos sistemas pueden ser incorporados de diferentes maneras como puede ser desde Microsoft 365 Defender, directivas locales o desde Microsoft Intune.

Integración de Microsoft Defender for Business con Microsoft 365 Lighthouse

Lo más importante si hablamos de consultoría, es mantener protegidos y securizados a los clientes, Microsoft ha integrado los servicios de Microsoft Defender for Business y Microsoft 365 Lighthouse para poder brindar un servicio de protección a los clientes que estén en Microsoft 365 Lighthouse ofreciendo a los socios la posibilidad de ver todas las alertas de seguridad que puedan presentarse en los sistemas tanto Windows como Linux.

Configuración de directivas de seguridad

Las directivas de seguridad son un conjunto de reglas que hacen referencia a diferentes características, servicios y permisos con el fin de configurarlos adecuándose a las preferencias de su entorno y de este modo garantizar un extra de seguridad.
Microsoft Defender for Business dispone de la configuración de directivas de seguridad aplicables a través de grupos de dispositivos.

Visualización y respuesta ante amenazas detectadas

Microsoft Defender for Business ofrece un panel de administración de incidentes, en el cual se puede ver información como puntuación de exposición de la amenaza y los dispositivos que están expuestos.
En el caso de presentarse algún incidente, seleccionándolo se accederá a la información de este mediante un panel emergente, en el que se podrá ver información relevante como título y lista de recursos afectados, realizar acciones contra el incidente, así como asignarlo a usuarios o administrarlo.

Una pregunta que puede surgir es ¿de qué sirve asignarlo o administrarlo si no puedo tomar acciones contra la amenaza? Pues resulta que, sí se pueden tomar acciones, Microsoft Defender for Business dispone de un apartado llamado “Action center” el cual incluye distintas posibilidades de acciones contra infecciones en su entorno.

Uno de los mejores métodos para mantenerse protegido, es mantenerse informado, para ello, Microsoft Defender for Business contiene un apartado llamado “Threat Analytics”, en el que trabajan expertos investigadores de seguridad de Microsoft para brindarle información relacionada sobre las amenazas más recientes y las amenazas que actualmente están en curso, de este modo podrá anticiparse a la infección con malware.

En conclusión, Microsoft Defender for Business es una herramienta sencilla e intuitiva con la cual mantener seguro un entorno de no más de 300 usuarios.

En el artículo anterior se explicó cómo modificar la aplicación para evadir la detección de rooteo del dispositivo. En este vamos a ver cómo reempaquetar, firmar, instalar y probar.

Una vez tenemos ya la aplicación parcheada, el siguiente paso consiste en reempaquetar la aplicación con el siguiente comando:

				
					apktool b

En esa ocasión utilizamos apktool con la opción “b”, para indicar que hay que construir (build) la aplicación. Este comando creará un archivo .apk en la ruta: 

<DIRECTORIO_APP>/dist/<DIRECTORIO_APK>.apk.

Ahora, para firmar la aplicación, primero necesitamos un almacén de claves (keystore) para poder firmar. Para crear este keystore usamos el siguiente comando:

				
					keytool -genkey -alias test -keyalg RSA -keystore test.keystore -storepass test123 -keysize 2048 -validity 10000 -dname "CN=TEST, OU=TEST, O=TEST, L=TEST, S=TEST, C=TEST"

 

 

Este comando crea un keystore de pruebas con la contraseña “test123” y un alias llamado “test” que usaremos para firmar.
Después firmamos la aplicación con el siguiente comando:

				
					jarsigner -sigalg MD5withRSA -digestalg SHA1 -storepass test123 -keystore test.keystore base/dist/base.apk test

Es importante destacar que, aunque se use MD5 con RSA y SHA1 (lo cual también indica jarsigner), no es relevante puesto que esta aplicación no se va a distribuir, solamente está firmada con una clave de pruebas para hacer pruebas.

En este punto tenemos una aplicación parcheada y firmada, queda pendiente instalar y probar. Antes de instalar debemos desinstalar la aplicación legítima puesto que, al no estar firmadas por la misma clave, va a dar error.

Por tanto, desinstalamos la aplicación legítima con el siguiente comando:

				
					adb uninstall

Ahora se instala la aplicación parcheada con el siguiente comando:

				
					adb install

Debería haber aparecido una nueva aplicación instalada en el dispositivo, la ejecutamos y vemos si el comportamiento nuevo es el esperado:

Comprobamos que, efectivamente, hemos evadido la detección de rooteo del dispositivo. En el caso de esta aplicación sólo cambia un mensaje, pero en una aplicación real puede suponer que, si el dispositivo está rooteado la aplicación se cierre. Esta técnica permite eliminar este tipo de impedimentos para poder realizar un análisis de una mejor forma.

En el artículo anterior revisamos cómo extraer un fichero APK, en esta ocasión explicaremos cómo parchear las Apps de Android.
Una vez tenemos el fichero APK de la aplicación a analizar, es posible que detectemos una serie de comportamientos o restricciones que presenta la aplicación y que nos dificulta su análisis. Para evadir estas restricciones hay varias opciones:

  • Instrumentación dinámica de la aplicación
  • Parcheo del código Smali

Según la naturaleza de la restricción puede ser más interesante una opción que la otra, aunque desde Sidertia solemos preferir el parcheo del código Smali.
Las aplicaciones Android contienen ficheros .dex (Dalvik Executable). Estos ficheros se pueden descompilar para obtener un código de bajo nivel llamado Dalvik Bytecode. Utilizando smali/baksmali (ensamblador/desensamblador) se puede obtener una representación en un lenguaje de bajo nivel con el que se puede trabajar más fácilmente, al cual llamaremos código Smali.

Las aplicaciones Android contienen ficheros .dex (Dalvik Executable). Estos ficheros se pueden descompilar para obtener un código de bajo nivel llamado Dalvik Bytecode. Utilizando smali/baksmali (ensamblador/desensamblador) se puede obtener una representación en un lenguaje de bajo nivel con el que se puede trabajar más fácilmente, al cual llamaremos código Smali. Para este ejemplo, vamos a utilizar la APP InsecureBankv2, descargable desde: 

La cual cuenta con detección de rooteo del dispositivo y es la restricción que vamos a parchear:

El primer paso es ejecutar la utilidad apktool para desempaquetar el fichero APK y la utilidad enjarify para obtener una aproximación del código fuente de la aplicación (desde Sidertia recomendamos enjarify frente a dex2jar). Para realizar esta operación usamos el siguiente comando:

				
					apktool d <FICHERO_APK> && enjarify <FICHERO_APK>

Utilidad apktool

 

Se utiliza la opción “d” de apktool para desempaquetar la aplicación. Apktool creará una carpeta llamada como el fichero, en este caso base y enjarify creará un fichero llamado base-enjarify.jar:

 

En este caso vamos a buscar la cadena que aparece en la pantalla, aunque hay que saber que el hecho de encontrar el punto donde se produce el comportamiento o restricción puede llegar a ser más difícil que el propio parcheo. Para buscar esta cadena, ejecutamos el siguiente comando dentro del directorio que se creó por la ejecución de apktool:

				
					grep -iR "<CADENA_A_BUSCAR> "

 

Se utiliza la opción “-iR” de grep para que se realice una búsqueda recursiva por los diferentes subdirectorios y que la búsqueda no discrimine entre mayúsculas y minúsculas. En este punto ya sabemos que la cadena está escrita tal cual en el código (no se usa el fichero strings.xml para referenciar la cadena) y sabemos también qué fichero la contiene.

Con la utilidad JD-GUI y el fichero resultado de enjarify podemos ver el código fuente de la clase PostLogin:

 

Aunque enjarify ha dado un fallo en la función showRootStatus, se observan las siguientes cuestiones:

  • En la línea 7 se llama a la función doesSuperuserApkExist() que comprueba si está instalado el apk.
  • En la línea 16 se llama a la función doesSUexist() que comprueba si el comando “su” está disponible en el sistema

La representación de esta función en el código Smali es la siguiente:

En la imagen anterior se detalla en rojo la función doesSuperuserApkExist() y en caso de que esta función devuelva un resultado verdadero, envía la ejecución a la sección “cond_0”, donde se establece el valor de la variable local v0 al valor de v1, que es 1, por tanto v0 tomará el valor 1 y a continuación la ejecución entra en la sección “goto_0”.

Se detalla en amarillo la función doesSUexist() y en caso de que el resultado sea falso, envía la ejecución a la sección “cond_1”, donde se establece la variable local v0 con el valor 0 y se envía la ejecución a la sección “goto_0” (detallado en naranja).

En la sección “goto_0” se comprueba si el valor de la variable local v0 es igual al valor de v1. En caso de no ser igual, la ejecución va a la sección “cond_2” y se establece el mensaje de que el dispositivo no está rooteado. En caso de ser igual, la ejecución continúa y se establece el mensaje de que el dispositivo sí está rooteado.

En este momento, cuando ya tenemos un conocimiento de las operaciones que se ejecutan, aparecen varias opciones para modificar el comportamiento, en este caso vamos a optar por la modificación más sencilla que consiste en introducir un salto de ejecución al principio de la función, directamente a la sección “cond_2”. Por tanto, el inicio de la función cambia de la siguiente forma:

Llegados a este punto, lo que queda es volver a empaquetar la aplicación, firmarla, instalarla y comprobar si la modificación ha surtido el efecto que buscábamos.

Estas operaciones se explicarán en otra entrada.

 

¿Qué es el TAP?

TAP (Temporary Access Pass) es un código de acceso de tiempo limitado que permite a los usuarios registrar métodos de autenticación sin contraseña y recuperar el acceso a su cuenta sin necesidad de una contraseña.

Microsoft ha anunciado en junio que su Pase de Acceso Temporal (TAP) ya se encuentra disponible para todo el público. Fue en el mes de marzo cuando se pudo comenzar a probar esta nueva funcionalidad como public preview, ahora, oficialmente ya ha adquirido la condición de general availability.
En su lucha diaria por conseguir un equilibrio entre la seguridad y la fluidez en el trabajo, ha desarrollado esta funcionalidad como un nuevo método de autenticación sin contraseña que puede ser implementado a escala por las organizaciones, dentro del marco de operaciones de Microsoft 365.

Métodos de Autenticación

Antes de adentrarnos en las cualidades y beneficios de TAP, hagamos un repaso de algunos de los diferentes métodos de autenticación existentes y su valía respecto a la seguridad que proporcionan.

Métodos de autenticación 

 

Nivel de seguridad:

  • Malo – Contraseña: El uso de únicamente una contraseña como factor de autenticación representa la peor de las soluciones en cuanto a seguridad se refiere. Para el usuario es el método más fácil y cómodo de autenticación, pero el uso de diccionarios, fuerza bruta o ingeniería social pueden comprometer su descubrimiento.
  • Bueno – Contraseña y…: El añadir a la contraseña un segundo método de autenticación, mediante el envío de un SMS o una llamada a un dispositivo registrado, mejora la seguridad, pero tiene el inconveniente de impedir la autenticación en entornos donde no exista cobertura.
  • Mejor – Contraseña y…: Debido a los inconvenientes que podría suponer el método anterior, se establecieron nuevos métodos de autenticación multifactor. A la tradicional contraseña se le podrían añadir notificaciones push, a través de una aplicación de autenticación, así como tokens, tanto de software como de hardware, de un solo uso.
  • Lo mejor – Sin contraseña: Métodos que no hacen uso de contraseñas pueden ser Windows Hello (que basa la autenticación en biometría o pin local), mediante una aplicación de Autenticador (Single Sign-On a través de móvil) o dispositivos FIDO2 (autenticación dactilar o token hardware).

El tiempo ha demostrado que el uso de contraseñas es contraproducente para el usuario en un doble sentido, por un lado, la posibilidad de olvido por parte del usuario o la posibilidad de descubrimiento por algún actor malicioso y, por otro lado, el tiempo perdido que supone su escritura cada vez que tenemos que hacer uso de ella. 

Por este motivo, cada vez más se hace uso de métodos de autenticación sin contraseña, como el TAP de Microsoft.

Volviendo al TAP

También se puede usar un TAP para configurar dispositivos Windows, ya sea que los usuarios estén configurando directamente sus propios dispositivos o que usen Windows AutoPilot, uniendo dispositivos a Azure AD o incluso configurando Windows Hello para empresas.

Se puede instalar y configurar TAP para la organización con la directiva de métodos de autenticación. Por ejemplo, se puede limitar la asignación de TAP a usuarios y grupos específicos, limitar el uso durante un período corto o configurarlo para un uso único.

Una vez que el método de autenticación está habilitado por la directiva, un administrador de autenticación con privilegios o un administrador de autenticación puede crear un TAP para el usuario visitando la hoja de métodos de autenticación del usuario o accediendo a través de una API. También se ha agregado la capacidad de los administradores para anular los TAP existentes o eliminarlos.

El Usuario Final

Una vez que un usuario tiene un TAP válido, puede usarlo para iniciar sesión y registrar información de seguridad, como el inicio de sesión telefónico sin contraseña directamente desde la aplicación Authenticator, para agregar una clave FIDO2 desde la página “Mi información de seguridad” o incluso para configurar Windows Hello for Business en máquinas unidas a Azure AD e híbridas unidas a Azure AD. En escenarios donde se requiere MFA, TAP también se puede usar como un factor adicional.

Con esta nueva funcionalidad, Microsoft sigue desarrollando nuevas maneras de tener un entorno de trabajo cada día más seguro y eficaz. En definitiva, TAP ha venido para quedarse.

Las auditorías a aplicaciones es uno de los servicios que ofrecemos en Sidertia Solutions. Este tipo de análisis permite detectar vulnerabilidades.

La primera operación que realizamos es la extracción del fichero APK (Android Application Package) para su análisis. Esto en caso de que el cliente no nos proporcione una versión concreta.

Esta operación se puede hacer desde un dispositivo no rooteado sin ningún problema, pero en este ejemplo se va a realizar desde un emulador de Genymotion que sí está rooteado (Android 7, API 24).

En este caso vamos a extraer una aplicación de linterna llamada “Flashlight”, para ello el primer paso es conectar con el dispositivo o emulador utilizando ADB (Android Debug Bridge). Es esencial que, si el dispositivo no está conectado con cable al PC, esté conectado a la misma red que el PC. Ejecutamos el siguiente comando para conectar con el emulador en el puerto por defecto 5555:

				
					adb connect <IP_DISPOSITIVO>:5555
adb connect

Una vez conectados, vamos a listar todos los paquetes (aplicaciones) que están instalados en el dispositivo con el siguiente comando:

				
					(Linux) adb shell pm list packages | grep -i <NOMBRE_APP>
(Windows) adb Shell pm list packages | findstr -i <NOMBRE_APP>
adb shell pm list packages

El comando anterior utiliza adb para invocar una Shell del dispositivo y pm para invocar al Package Manager del dispositivo. 

Luego ejecuta el comando list packages de Package Manager para obtener la lista completa de paquetes. Posteriormente se filtra la lista para obtener el que estamos buscando.

Una vez localizado el nombre del paquete que estamos buscando, ejecutamos el siguiente comando para obtener la ruta de dicho paquete:

				
					adb shell pm path <PAQUETE_APP>
adb shell pm path

Este comando es similar al anterior, pero ahora se usa el comando path y el nombre del paquete.

Por último, extraemos el fichero utilizando la ruta obtenida en el comando anterior de la siguiente forma:

				
					adb pull <RUTA_PAQUETE_APP>
adb shell pm list packages

Este comando ha creado un fichero llamado base.apk en el directorio actual, este es el fichero APK de la aplicación.

Antes de comenzar con el análisis, se recomienda obtener el hash de la aplicación:

Esto permitirá identificar correctamente el APK que ha sido objeto de auditoría.

En este artículo vamos a analizar algunas de las diferentes herramientas que nos proporciona Amazon Web Services (AWS) y así como parte de las estrategias que adopta Sidertia Solutions y cómo emplea dichas herramientas para aportar seguridad al entorno.

Los principios y configuraciones de seguridad que expondremos a continuación serían prácticas recomendables no solo en un entorno AWS o de nube pública, sino en cualquier sistema TIC que maneje información sensible o que requiera de una cierta seguridad y, en cierta medida, se basan en algunos de los requisitos de seguridad descritos en diferentes guías del Esquema Nacional de Seguridad (ENS) incluidas en el sitio del Centro Criptológico Nacional.

AWS es lo que se denomina un servicio de nube que proporciona una infraestructura completa para el alojamiento de ficheros, aplicaciones, sistemas, etc. Las soluciones que proporciona permiten el uso de sistemas completos empresariales que mejoran los tradicionales. Se pueden encontrar herramientas de computación, almacenamiento, bases de datos, análisis, redes, desarrollo, administración, IoT, etc.

Obviamente, todas estas herramientas y la información que contienen deberán ser protegidas adecuadamente para tratar de garantizar la confidencialidad, trazabilidad, autenticidad, integridad y disponibilidad de los datos. Sidertia Solutions ofrece a través de AWS, diferentes elementos de seguridad que permiten alcanzar tales propósitos en gran medida, como veremos a continuación.

 

AWS proporciona un modelo deseguridad compartida. AWS asume la responsabilidad de todo aquello que administren ellos directamente. 

 

Entre los productos que se pueden adquirir habría que diferenciar entre elementos gestionados por el cliente y elementos gestionados por AWS.

Los diferentes elementos de almacenamiento, computación, base de datos, etc., se pueden adquirir con modelos de Infraestructura como Servicio (IaaS), Plataforma como Servicio  (PaaS) y Software como Servicio (SaaS), siendo IaaS gestionado por el cliente (por ejemplo, se generan máquinas virtuales se instalan y mantienen sus sistemas operativos y configuraciones entre ellas) y SaaS (por ejemplo, se contrata una base de datos pero no se mantiene el servidor, solamente los datos introducidos, AWS se encarga del mantenimiento de esa base de datos).

Por tanto, si se monta un servidor de base de datos en una instancia de EC2 (el “hipervisor” de máquinas virtuales de AWS), la instalación de sistema operativo y aplicaciones recaería en el cliente, mientras que, si se contrata una base de datos gestionada, recaería sobre AWS. Del mismo modo, la responsabilidad en lo que a seguridad se refiere funciona de forma parecida.

El cliente es el responsable de la seguridad de sus propios datos, de la plataforma y aplicaciones, así como la gestión de accesos e identidades, los sistemas operativos y las configuraciones de red y su protección (FW, cifrados en sistemas de archivos, cifrados en tránsito, etc.).

AWS es responsable de los elementos de software contratados, la seguridad en la computación, el almacenamiento, BBDD y red sobre aquellos servicios en los que el cliente no puede decidir porque son gestionados por AWS y, por supuesto, también es responsable de la infraestructura global y disponibilidad de sus centros de datos.

Distintivo_ens_certificacion_MEDIA
Distintivo_ens_certificacion_MEDIA

El inconveniente que podría verse en la parte gestionada por AWS es precisamente la opacidad y falta de control de la que dispone el cliente, pero a cambio, AWS cuenta con la certificación del Esquema Nacional de Seguridad en su categoría alta,  lo que garantiza el cumplimiento de los estándares que aplican a agencias gubernamentales y organizaciones públicas

Los principios que se tienen en cuenta a la hora de aplicar seguridad son las siguientes:

  • Gestión de identidades.
  • Trazabilidad y gestión de eventos de seguridad.
  • Seguridad en las diferentes capas y protección de datos en tránsito y en reposo.
  • Buenas prácticas, procesamiento de datos y garantía de disponibilidad.
 

Gestión de identidades

El usuario con el que se da de alta el servicio de AWS es, a todo efecto, el usuario más privilegiado, se podría decir que es el usuario “root”. Debido a esto, la recomendación de Sidertia Solutions es que dicha cuenta no sea utilizada salvo en ocasiones estrictamente necesarias. Las herramientas que proporciona AWS para la gestión de identidades hacen que la necesidad de uso de la cuenta sea prácticamente inexistente.

Es posible gestionar identidades de usuario y de equipo, pudiendo administrar pertenencias a grupos y asignar atributos. Esta posibilidad permite segmentar los permisos para garantizar que únicamente quien debe hacer algo tiene el privilegio de hacerlo. Además, existe la posibilidad de aplicar los permisos a roles en vez de a cuentas de equipo o usuario, de modo que se podría asociar un rol específico al objeto de usuario o equipo permitiendo que solamente lo asuma en el momento en que tiene que realizar una tarea privilegiada.

Todo esto puede ser definido por políticas que automatizan la entrega de privilegios y la temporalidad de éstos. Es importante evitar el uso de wildcards o comodines en el uso de las políticas de identidades para garantizar que no se entregan privilegios administrativos completos.

También es importante evitar el uso de contraseñas comunes o reutilizadas, almacenar contraseñas en claro en código o scripts, etc. Igualmente, AWS proporciona mecanismos de Multi factor de autenticación que, del mismo modo, deberían usarse.

Estas prácticas permiten aplicar el principio de mínimo privilegio y reducen notablemente la superficie de exposición y el riesgo de sufrir ataques de suplantación de identidades y privilegios.

Trazabilidad y gestión de eventos de seguridad.

La Gestión de Identidades debe ofrecer la posibilidad de trazar lo que sucede con los diferentes usuarios. AWS proporciona la herramienta “Credential Report” así como AWS Cloud Trail para registrar los accesos exitosos o fallidos entre otros eventos. 

La herramienta CloudTrail en combinación con CloudWatch son los pilares de la monitorización de los elementos de los que se hace uso en AWS. Es importante habilitar alertas para intentos de accesos no permitidos, accesos sin MFA, uso de la cuenta “root” y cambios en las políticas de identidades.

AWS VPC FlowLogs permite además monitorizar el tráfico de los diferentes elementos virtuales de red.

Seguridad en las diferentes capas y protección de datos en tránsito y en reposo.

Existen herramientas como AWS WAF, Shield y NetWork Firewall que permiten establecer reglas de filtrado de tráfico, mantenimiento de listas blancas y negras para IPs y dominios, aprendizaje automático para detectar comportamientos sospechosos, etc.

Tanto los datos almacenados en bases de datos como los propios logs y registros de eventos deberían ser cifrados. Existe una herramienta denominada (AWS KMS) que permite gestionar las claves tanto generadas a través de AWS KMS, como las generadas por el cliente a través de terceros o sus herramientas on premise y posteriormente importadas.

Igualmente, los elementos de red virtuales y las nubes interconectadas (Virtual Private Clouds) permiten el cifrado del tráfico haciendo uso de las mismas herramientas de cifrado. Se deberían por tanto, habilitar los mecanismos de cifrado en tránsito para garantizar la confidencialidad.

Buenas prácticas, procesamiento de datos y garantía de disponibilidad.

AWS proporciona al cliente herramientas que permiten analizar grados de cumplimiento y nivel de aplicación de actualizaciones en aquellos elementos en los que la responsabilidad de la seguridad recaiga sobre él.

Las herramientas AWS autoscaling y AWS Shield van a permitir, además, la protección ante ataques de denegación de servicio distribuidos (DDoS). Además existen multitud de centros de datos en diferentes zonas del mundo que garantizan la disponibilidad e integridad de dichos datos. Es posible y recomendable hacer uso de varias zonas de disponibilidad por redundancia y a modo de centro de respaldo en caso de catástrofe.

Si bien es cierto que AWS proporciona muchos mecanismos que permiten mitigar numerosos riesgos de ataque o pérdida de servicio, no hay un sistema 100% seguro y menos si éste está publicado en la internet.

Lo que sí está claro es que las herramientas de seguridad que brindan las soluciones de nube actuales, AWS entre ellas, demuestran el esfuerzo y sobre todo la mentalización a nivel global de la importancia de la seguridad y su aplicación, ofreciendo soluciones verdaderamente innovadoras y efectivas que, aprovechando la flexibilidad que proporciona la computación en nube, van a ofrecer mejores y mayores garantías para la seguridad de las TIC.

Sidertia Solutions ofrece a sus clientes los medios para poder configurar los diferentes elementos de la plataforma de Amazon Web Services de forma que la superficie vulnerable y los riesgos de recibir ataques y perder integridad o acceso a la información se vean reducidos y de este modo se pueda garantizar el entorno como un medio seguro y fiable para el uso y mantenimiento de datos y aplicaciones.

La publicación del nuevo Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad pone fin al periodo de espera ante la actualización del ENS, periodo de espera que pudimos hacer más llevadero gracias al borrador publicado con fecha 14 de junio de 2021 titulado “Proyecto de Real Decreto por el que se regula el Esquema Nacional de Seguridad” con el que en Sidertia Solutions empezamos a valorar los cambios previstos en la norma.

Es la actualización del ENS que, valga la redundancia, actualiza la normativa aplicable atendiendo a tres grandes cuestiones, que son: 

  • La alineación con el marco normativo y el contexto estratégico existente, conforme la Estrategia Nacional de Ciberseguridad de 2019 y el Plan Nacional de Ciberseguridad
  • La inclusión del “perfil de cumplimiento específico” de aplicación a ciertos colectivos y tipos de sistemas previa aprobación por CCN
  • «Facilitar una mejor respuesta a las tendencias en ciberseguridad, reducir vulnerabilidades y promover la vigilancia continua“

En Sidertia Solutions, como una de las labores del Responsable de Seguridad en cuanto a atender las novedades y planificar los cambios normativos, hemos realizado un proceso de análisis del nuevo ENS evaluando los cambios y modificaciones que afectan a nuestra certificación, obteniendo, como resultado, los requisitos para adecuarnos al nuevo Real Decreto 311/2022, de 3 de mayo.

Artículos del ENS.

Se han renumerado los artículos del real decreto al incorporar y eliminar artículos, por lo tanto, es recomendable revisarlos y conocer esas novedades.

En el articulado destacamos ciertas modificaciones que nos han llamado la atención por su importancia, entre ellos el artículo 2 donde se establece que el real decreto será de aplicación a los sistemas que manejan o tratan información clasificada sin perjuicio de la normativa que resulte de aplicación como la Ley 9/1968, de 5 de abril, de Secretos Oficiales, así como otra normativa especial.

De especial importancia es el nuevo artículo 3 referente a sistemas de información que traten datos personales, incluyendo la necesidad de análisis de riesgos según el Reglamento General de Protección de Datos (RGPD) así como una posible evaluación de impacto en la protección de datos (EIPD) y lo que implica en nuestra Política de Seguridad como veremos más adelante en el artículo 12 al incluir como nuevo requisito mínimo de seguridad el relacionado con “los riesgos que se derivan del tratamiento de los datos personales”.

A destacar también la inclusión de la vigilancia continua dentro de los principios básicos en el artículo 5 y posteriormente desarrollada en el artículo 10 con la reevaluación periódica y por lo tanto de la importancia que se le da a partir de este momento a la detección temprana y una oportuna respuesta ante las amenazas.

Nos hemos encontrado el artículo 13 con una exposición de los diferentes roles del ENS y sus funciones en la organización, una información interesante de encontrar en el real decreto. Igualmente, en este artículo se anuncia una nueva regulación a tener en cuenta: “Una Instrucción Técnica de Seguridad regulará el Esquema de Certificación de Responsables de la Seguridad, que recogerá las condiciones y requisitos exigibles a esta figura”.

Por último, reseñar el artículo 30 con los “perfiles de cumplimiento específicos y acreditación de entidades de implementación de configuraciones seguras”, una novedad que permitirá que entidades o sectores de actividad concreto puedan aplicar el ENS con base en las especificaciones que el CCN, en el ejercicio de sus competencias, validará y publicará, siempre de acuerdo con el artículo 5 del real decreto sobre los principios básicos del Esquema Nacional de Seguridad.

Sidertia y su Certificación de Conformidad

Distintivo_ens_certificacion_MEDIA-ENS

 

Medidas Anexo II.

Encontramos en el Anexo II, modificaciones en los requisitos de aplicación según el nivel determinado por la categorización del sistema, hasta ahora eran requisitos tasados que debíamos incluir, mientras que en el nuevo real decreto, la aplicación de requisitos es por medio de unas exigencias básicas que, al aumentar el nivel, se ven ampliadas mediante “refuerzos”, que en algunos casos, nos permite seleccionar entre varios el que más se adecue a nuestro sistema, como por ejemplo en la medida [op.acc.5] Mecanismo de autenticación (usuarios externos). En esta medida, se nos permite elegir, a nivel bajo y medio, entre varios refuerzos posibles de aplicación.

Las medidas incluidas en el anexo II podemos dividirlas en varios grupos: 

  1. Medidas sin cambios reseñables
  2. Medidas modificadas y reforzadas para una mayor claridad
  3. Medidas con cambios significativos respecto a su estructura anterior
  4. Medidas de aplicación, esas medidas que actualizan el real decreto a la evolución de los sistemas y las amenazas actuales

También nos encontraremos con medidas que han desaparecido, en la mayor parte de los casos debido a su inclusión en otras nuevas como ha sucedido con las medidas [op.ext.9] y [mp.if.9] entre otras, que han sido integradas en la nueva medida [op.cont.4] Medios alternativos como veremos más adelante.

Comentar, antes de pasar a hablar de los diferentes grupos de medidas, que se ha realizado una modificación de la numeración de las medidas, de tal modo que la numeración sea correlativa evitando huecos en la misma, como podréis comprobar claramente en las medidas de Protección de la Información con la desaparición de la medida [mp.info.3] Cifrado y el consiguiente cambio de numeración de las restantes medidas del grupo.

Pasemos a ver ejemplos de cada uno de los grupos de medidas.

No han cambiado medidas como, por ejemplo, [org.2] Normativa de Seguridad, [op.exp.1] Inventario de Activos, … normas que cubren perfectamente las necesidades antes y ahora y que por lo tanto no necesitan de modificaciones.

Existe un segundo grupo con medidas que incluyen modificaciones reforzando su claridad y aplicabilidad, ya sea por el cambio del nombre la medida y/o la redistribución de las directrices que se incluían en la versión anterior, destacando las medidas del grupo de control de acceso [op.exp.] dentro del marco operacional de medidas, donde encontraremos cambios de nomenclatura y redistribución de las antiguas medidas [op.acc.5] Mecanismo de autenticación, [op.acc.6] Acceso local (local logon) y [op.acc.7] Acceso remoto (remote login) en dos medidas; [op.acc5] Mecanismo de autenticación (usuarios externos), y [op.acc.6] Mecanismo de autenticación (usuarios de la organización). Una modificación que las hace más fácilmente interpretables aún con el incremento en sus requisitos.

Hablemos ahora de las medidas que sí incluyen cambios que, a nuestro parecer, son importantes y deben ser tenidas en cuenta especialmente como, por ejemplo, la nueva aplicación de la medida [op.pl.5] Componentes Certificados a nivel medio, lo que supone un aumento de requisitos en la seguridad de los elementos a incorporar a nuestra infraestructura, y que a su vez requiere un mayor esfuerzo para el cumplimiento de alguno de los requisitos relacionados con la medida. Dentro de este grupo también nos encontraremos con la medida [mp.com.4] Segregación de Redes, convertida en [mp.com.4] Separación de flujos de información en la red y que ahora se aplica a nivel medio con lo que la segmentación de red deberá ser aplicada en los sistemas de este nivel.

Entramos al grupo de medidas nuevas, medidas de aplicación que refuerzan la frase “facilitar una mejor respuesta a las tendencias en ciberseguridad, reducir vulnerabilidades y promover la vigilancia continua”, son siete nuevas medidas:

  • * [op.ext.3] Protección de la cadena de suministro: La importancia de la seguridad un paso más allá de nuestro perímetro bajo control, esos proveedores que pueden provocar impactos en nuestros sistemas. Medida incluida para poder evaluar impactos que afecten a la cadena de suministros, estimando el riesgo y aplicando las medidas de contención necesarias ante dichos riesgos.
  • * [op.ext.4] Interconexión de sistemas: Cada vez están más generalizadas las interconexiones, y más tras la pandemia COVID-19 donde se han generalizado. La medida exige que tengamos un control sobre dichas interconexiones y, por supuesto, que sólo se realicen bajo autorización previa y con una adecuada documentación explícita de las mismas.
  • * [op.nub.1] Protección de servicios en la nube: Es otro de los servicios generalizados en nuestros sistemas, hasta ahora protegidos por medidas generales, y que tras esta actualización del real decreto tendrá unas medidas particulares, incluyendo para nivel medio y alto la exigencia de certificación del servicio como indica la medida en sus refuerzos. Esta nueva medida ha supuesto la creación de un nuevo grupo de medidas operacionales, el [op.nub] Servicio en la Nube.
  • * [op.cont.4] Medios alternativos: Una medida necesaria, que engloba las medidas anteriormente desperdigadas por los diferentes grupos de medidas, todas ellas relacionadas con medios alternativos y que ahora se engloban en continuidad del servicio que es su ubicación natural. Las medidas incluidas, y que por lo tanto han desaparecido son [op.ext.9], [mp.if.9], [mp.per.9], [mp.eq.9], [mp.com.9], [mp.s.9].
  • * [op.mon.3] Vigilancia: Medida incluida para reforzar la necesidad de la recolección y correlación de eventos que permitan detectar amenazas a las que se exponen nuestros sistemas y/o servicios. A destacar la necesidad a nivel medio de un sistema automático de recolección de eventos que permita su correlación.
  • * [mp.eq.4] Otros dispositivos conectados a la red: Nos encontramos cada vez más dispositivos con capacidades de conexión a la red (proyectores, altavoces, impresoras, IoT, BYOD, …) que hasta ahora no tenían un reflejo claro en las medidas del ENS, esta medida viene para exigir un control de estos dispositivos y su seguridad, volviendo a encontrarnos ante el requisito de componentes certificados en nivel medio y alto.
  • * [mp.s.3] Protección de la navegación web: Importante medida que viene a especificar requisitos de seguridad para la navegación en internet de los usuarios y por lo tanto proteger de las amenazas que pueden afectarle.

En resumen, hay cambios, hay novedades importantes, el RD 311/2022 ha sido publicado y, como indica la disposición transitoria única, se fija un plazo de veinticuatro meses para que los sistemas de información del ámbito de aplicación del real decreto, preexistentes a su entrada en vigor, alcancen su plena adecuación al ENS.

El análisis que hemos realizado en Sidertia Solutions nos dice que los sistemas más afectados en cuanto al esfuerzo requerido serán aquellos de nivel medio, y en mayor medida como consecuencia de la aplicación a dicho nivel de la medida [op.pl.5] Componentes Certificados y las consecuencias que se derivan de ella sobre otras medidas de aplicación.

Por último, recordaros que tenemos a vuestra disposición todos los recursos documentales para llevar a buen puerto la adaptación al nuevo ENS disponiendo, además del Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad, de la web del Centro Criptológico Nacional (https://ens.ccn.cni.es/es/) donde encontraremos todas las guías existentes en relación al ENS y necesarias para lograr nuestro objetivo y que veremos actualizarse para adecuarse al RD 311/2022.

 

No está siendo un buen mes en lo referente a vulnerabilidades para los Sistemas Operativos más conocidos. Recientemente recogíamos una vulnerabilidad bastante crítica que afectaba al servicio de impresión de los sistemas Windows. El martes de esta semana se reportaba otra vulnerabilidad “bastante atípica” para los sistemas operativos Microsoft.

Este carácter atípico se da por las siguientes circunstancias:

  • Afecta solo a determinadas versiones de Windows, y son solo versiones recientes.
  • La debilidad no se basa en cosas altamente complejas como la debilidad en una función de código en un servicio poco conocido y que resulta difícil de explotar. Es básicamente un problema de permisos de algo tan “windows” como es el contenido de la carpeta “config”, que contiene entre otros elementos el fichero “SAM” (administrador de cuentas de seguridad) o el fichero “System”.
  • Qué habrá fallado en Microsoft para que algo tan simple, y que estaba controlado por un bloqueo en la herencia de permisos, haya fallado para facilitar un acceso a algo tan crítico en el sistema.

En esencia el problema reside en el hecho que a los usuarios no privilegiados se les ha franqueado la posibilidad de poder acceder a información crítica del sistema como los ficheros comentados anteriormente: SAM o System, entre otros. Dentro de estos ficheros puede encontrarse entre otras cosas los hashes de los usuarios locales o el hash derivado de la contraseña del equipo.

Con el acceso a dicha información, un usuario, mediante técnicas de impersonalización, puede elevar su privilegio para ejecutar código localmente de forma privilegiada. Igualmente, con la clave del propio equipo, se puede conducir uno de los ataques más populares que emplean atacantes para moverse por la red, el ataque de Silver Ticket Kerberos.

Silver Ticket Kerberos
Silver Ticket Kerberos

El código identificativo al que hace referencia esta vulnerabilidad es CVE-2021-36934 y afecta a sistemas Windows 10 a partir de la versión 1809, así como a Windows 11 y Windows Server 2019. El nombre común con el que se conoce a la vulnerabilidad es HiveNightmare, derivado de hecho de que información crítica del sistema se almacena en una serie de ficheros de base de datos que se estructuran en una estructura arbórea de registro denominada “Hives”.

Esta debilidad además de ser aprovechada manualmente por un atacante, es bastante automatizable y por lo tanto aprovechable por aplicaciones de código dañino tales como ransomware.

Si bien la debilidad es algo manifiesta y fácilmente explotable, también es relativamente simple su remediación. Microsoft inicialmente no ha sacado una actualización que corrija el problema pero si un workaround. Este es bastante simple y se basa en dos conceptos:Modificación de los permisos, bien sobre la carpeta Config o bien sobre los ficheros críticos con información sensible.

  • La eliminación de las copias shadow realizadas mediante el servicio de “Volume Shadow Copy”.

Este último elemento es sumamente importante porque, aunque se modifiquen los permisos sobre los ficheros sensibles, las copias Shadow pueden mantener instantáneas del sistema que mantendrían los ficheros con los permisos anteriores a la modificación. Con esas instantáneas un atacante podría acceder a la información sensible, aún habiendo modificado convenientemente los permisos en la carpeta config. Por lo tanto, el proceso consistiría, una vez modificados los permisos, en eliminar todos los puntos de restauración existentes en el equipo y volver a realizar uno. Tener un fichero de restauración del sistema es importante para poder recuperar el equipo por ejemplo ante un incidente de intrusión por malware.

A priori la remediación no debería afectar a la funcionalidad del sistema, ni de las aplicaciones existentes. Esta afirmación es debida que en muchas versiones de Windows estos permisos nunca han existido y no ha habido problemas de funcionalidad. No obstante, como siempre recomendamos, hay que probar en un grupo de control antes de extender la solución al grueso de equipos de una organización.

Nuestro departamento interno, consciente de este hecho procedimentaron rápidamente la remediación y en menos de 15 minutos se estaba realizando la aplicación de la solución, incluyendo además con un mecanismo de control que verificaba la aplicación efectiva del mismo, incluso en un escenario de teletrabajo. Debe tenerse en cuenta las implicaciones que para las organizaciones supone este tipo de remediaciones en una situación actual marcada por el hecho de tener un número significativo de trabajadores operando en remoto. Es crítico aplicar la remediación en entornos donde se empleen para teletrabajo accesos de VDI, por las repercusiones múltiples que esta debilidad puede suponer.

Aunque parece que este sea un mes bastante crítico para sistema Microsoft, a los sistemas operativos Linux no parece estar yéndoles mucho mejor. Solo citamos como referencia las siguientes: CVE-2021-33909 o CVE-2021-33910.

En uno de los incidentes en los que ha estado involucrado el área de ciberseguridad de Sidertia, se pudo identificar la presencia de un “implante” de CS, en una instalación de MS Team que era vulnerable a DLL Hijacking. En ello se había identificado que la solución había empleado el mecanismo de persistencia empleando la ejecución de un proceso Update.exe (en la versión 32 bits), que llamaba a una librería (CRYOTSP.DLL) que no se encontraba en la ruta esperable originalmente. Si se posiciona una dll con el nombre esperado en la misma carpeta donde se encuentra el proceso Update.exe, aunque realmente se debería encontrar en la ruta Windows\syswow64, se cargará automáticamente cada vez que el usuario inicie la aplicación.

Una vez que la librería ha sido cargada, entrará en marcha el proceso de comunicación con el Command and Control. Empleando la funcionalidad denominada Beacon, permite la conectividad empleando protocolos tipo como HTTP, HTTPS o DNS. 

beacon console options
beacon console options
beacon console
Interacting with target's desktop
Interacting with target's desktop

El componente Beacon es altamente versátil y admite comunicaciones asíncronas o interactivas. El módulo asíncrono es muy útil para un atacante para crear distorsiones temporales, estableciendo conexiones basados en valores temporales aleatorios, que permite evitar que se puedan realizar asociaciones de ataques con patrones de comunicaciones concretas. En este sentido el componente de Beacon llamará al C&C evaluará si hay tareas, las descargará y las podrán en ejecución cuando sea necesario.

Los indicadores de red de Beacon son flexibles, empleado el lenguaje maleable C2 propio de Cobalt Strike. Esto le permite ocultar la actividad de Beacon para que se disfrace como otro malware o se haga pasar como tráfico legítimo.

La shell de comandos que proporciona Beacon permite la ejecución de acciones basadas en CMD o PowerShell. En aquellos casos que estén desactivados ambos programas, se puede emplear el comando powerpick para ejecutar cmdlets, sin necesidad del componente PowerShell de Windows.

También, aunque más agresivo permite la ejecución de cmdlets en procesos, mediante el empleo de la api psinject.

El uso de PowerShell resulta muy potente para el atacante y va a permitir interactuar de forma significativa con el sistema. La descarga de hashes, la impersonalización de cuentas, la modificación del registro o la ejecución de aplicaciones, son acciones que pueden ser fácilmente llevadas a cabo con la shell nativa que incorporan los sistemas operativos de Microsoft. De esta forma y sin la necesidad de aplicaciones de terceros, que en muchas ocasiones serán fácilmente identificables por aplicaciones de detección de malware, se puede obtener información crítica, que una vez exfiltrada, será utilizada en procesos posteriores. Por ejemplo, robar credenciales para emplearlas en accesos remotos o para venderla. También con la información obtenida puede llevar a cabo extorsiones a personas concretas u organizaciones.

Uno de los objetivos últimos que a buen seguro llevará a efecto el atacante es efectuar el cifrado del contenido de los sistemas de la información. Este hecho lógicamente revelará la presencia del atacante. Este, emplea Cobalt Strike como mecanismo para distribuir una aplicación maliciosa tal como Ryuk una vez que ha conseguido los privilegios oportunos. Aunque se han visto casos donde se ha empleado funciones propias del sistema para cifrar el contenido de los equipos, es más habitual emplear una aplicación malicioso como vector de ataque para el cifrado.

Como se ha podido intuir Cobalt Strike ofrece múltiples posibilidades para la explotación y que dependerá de:

  • Las capacidades o habilidades del atacante.
  • Lo silencioso que quiera llegar a operar.
  • El objetivo del ataque.

Se abordarán en futuros artículos técnicos cómo se llevan a cabo estas acciones, y cómo no, como poder identificarlos con las capacidades que tienen habitualmente las organizaciones.

Adaptamos la
Ciberseguridad 360º
a tu organización.

Distintivo_ens_certificacion_MEDIA
CCN-CERT Acreditación Difusión Limitada
CCN CERT
SidertiaSolutionsIso9001
Sidertia obtiene el certificado en Administración de sistemas por IQNET
Sophos Partner Sidertia Solutions

Copyright © 2022

cookies-sidertia
Utilizamos cookies propias y de terceros para obtener datos estadísticos de la navegación de nuestros usuarios y mejorar nuestros servicios. Si acepta o continúa navegando, consideramos que acepta su uso. Puede cambiar la configuración u obtener más información aquí.
Entendido