Seguridad Informática archivos - Sidertia by Izertis

Un año más reafirmamos nuestro compromiso con la seguridad renovando la certificación del Esquema Nacional de Seguridad (ENS) y, además, con el espíritu de mejora continua sumamos una nueva certificación más: ISO 27001. Las certificaciones de estos estándares suponen el cumplimiento de una serie de medidas de seguridad, así como el compromiso de la asunción de las normas establecidas.

La protección de la información es un elemento fundamental para las empresas, dado que, en los últimos años, los ciberataques han crecido de manera exponencial. Por tanto, las compañías buscan depositar su confianza en grandes especialistas para proteger y fortalecer sus infraestructuras.

Con este logro buscamos servir de ejemplo de modelo de seguridad y apostar por la protección de las empresas y entidades para que puedan desarrollar sus actividades sin ningún tipo de riesgo y puedan llegar a alcanzar sus objetivos en un entorno de amenazas constantes.

Aportamos experiencia a nivel internacional en proyectos públicos y privados, donde trabajamos codo con codo con los mejores profesionales del sector de la ciberseguridad.

Las XVI Jornadas STIC CCN-CERT , el mayor evento de ciberseguridad de España organizado por el Equipo de Respuesta ante Incidentes de Seguridad de la Información del Centro Criptológico Nacional (CCN-CERT), acogerá en la nueva edición de 2022 la celebración de las IV Jornadas de Ciberdefensa ESPDEF-CERT del Centro de Respuesta ante Incidentes (ESP DEF-CERT) del Mando Conjunto del Ciberespacio.

El Centro Criptolótgico Nacional (CCN) y el Mando Conjunto del Ciberespacio (MCCE) impulsan su alianza estratégica en materia de ciberseguridad aunando la celebración de sus eventos insignia. De esta forma, en Kinépolis Ciudad de la Imagen del 29 de noviembre al 1 de diciembre, se celebrarán las XVI Jornadas STIC CCN-CERT y las IV Jornadas de Ciberdefensa ESPDEF-CERT del MCCE, con el objetivo de articular «Un ciberescudo único para España».

Las Jornadas permitirán un año más estudiar y analizar la ciberseguridad desde diferentes perspectivas. En esta edición, tendrán gran protagonismo las amenazas y tendencias del ciberespacio en distintos ámbitos, el cibercrimen, la Red Nacional de SOC, las operaciones militares en el ciberespacio, el Esquema Nacional de Seguridad, los productos y tecnologías de Ciberseguridad, la Inteligencia Artificial, las tecnologías cuánticas y el 5G, y la seguridad industrial, entre otros. En esta nueva edición, también se desarrollará la sala ATENEA, dedicada a retos de ciberseguridad, y volverán a organizarse los ya célebres CCN-CERT LABS que, como novedad, este año se celebrarán en Kinépolis durante el trascurso de las Jornadas STIC.

Las XVI Jornadas STIC CCN-CERT y las IV Jornadas de Ciberdefensa ESPDEF-CERT del MCCE reunirán a más de 3.600 profesionales del sector de forma presencial y a más de 5.000 de forma online, tanto del panorama nacional como internacional. Todos ellos se darán cita durante los tres días del evento en un foro común para el intercambio de conocimiento y las investigaciones más avanzadas, ratificando esta cita como el principal encuentro de ciberseguridad celebrado en España.

En el siguiente enlace puede consultarse el programa: https://www.ccn-cert.cni.es/xvijornadas-programa.html

Fuente: https://www.ccn-cert.cni.es/

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:

https://github.com/dineshshetty/Android-InsecureBankv2/releases/tag/2.3.1

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>

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.

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

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>

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>

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>

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.

El pasado martes 28 de junio se ha oficializado la incorporación de Sidertia Solutions en Izertis, compañía tecnológica española especializada en proyectos de Transformación Digital. Fundada hace más de 25 años, Izertis cuenta con oficinas en 9 países y más de 1.200 empleados, y desde noviembre de 2019 cotiza en el BME Growth.

La unión de ambas empresas tiene un gran calado estratégico, ya que nos sitúa como una de las primeras proveedoras de servicios tecnológicos de Ciberseguridad con proyección de crecimiento en el plano internacional, así como en la ampliación y consolidación de su posición en el ámbito nacional.

Sidertia, como referente en la prestación de servicios de valor 360º en Ciberseguridad, complementa el portfolio de soluciones de Izertis donde destacan entre otras áreas: IA, Data & Intelligence, Digital Experience, Devops, Cloud, Quality Assurance, Hyper Automation, Business Solutions, Blockchain, Project & IT Governance Consulting, junto a otras tecnologías habilitadoras de los procesos de transformación digital.

Esta operación conllevará el desarrollo de un Plan Estratégico de Ciberseguridad con proyección a largo plazo, y cuyo objetivo es potenciar nuestra presencia en un mercado con una demanda de soluciones para el “manejo de información sensible” y “protección de la información” cada vez mayor, tanto en el ámbito público como privado.

Cuidado estos días con el teletrabajo, los cibercriminales están utilizando la pandemia del coronavirus (COVID-19) para realizar múltiples campañas de malware, incluyendo ransomware y phising.

Para ello el Centro Cripológico Nacional ha preparado un documento donde se recogen las principales medidas a tener en cuenta.

Cómo estar (ciber)seguro trabajando desde casa ?

Estamos viviendo una semana complicada a causa del coronavirus COVID19, el cual ha puesto en jaque la logística de medio mundo.

Vemos que se está avanzando a marchas forzadas al modelo de teletrabajo para intentar controlar la expansión de este.

El problema reside en todas aquellas empresas que no tienen una infraestructura dedicada para acceder de forma remota. Existen muchas soluciones Cloud de ágil/fácil instalación, pero estos sistemas deben ser correctamente instalados y configurados para mantener la correcta protección del dato.

El día 9 de marzo, el Centro Criptológico Nacional (CCN-CERT), publicó un artículo denominado «Medidas de seguridad para Acceso Remoto«, documento que recoge la implementación de soluciones de acceso remoto en cualquier organización, dependiendo de la capacidad de sus instalaciones.

Estos son los cuatro posibles escenarios.

Soluciones On-Premise
Sistemas de Interfaces de Escritorio Virtual (VDI)
Servicio de Escritorio Remoto
Acceso Directo al equipo

Desde Sidertia, siempre hemos observado el teletrabajo como una alternativa de valor si se lleva efecto en unas condiciones de seguridad adecuadas. La continuidad de negocio de empresas y organizaciones con las que colaboramos ha sido también una de nuestras prioridades. La combinación de estos dos factores forma parte de nuestra filosofía de trabajo. Desafortunadamente en estos momentos este planteamiento se acentúa de forma muy excepcional.

A través de las soluciones Citrix en las que trabajamos en conjunto con el fabricante para obtener una securización integral y óptima de la información sensible que facilite el adecuado acceso remoto a la misma evitando poner en riesgo la continuidad de negocio.

Correos electrónicos, salas de reuniones virtuales, conexiones con proveedores o procedimientos de actuación de las personas o equipos con acceso remoto son algunos de los puntos recogidos en el Abstract publicado por el CCN-CERT.

Aquí os dejamos el enlace.

Con el objetivo de facilitar a las Administraciones Públicas el uso de su solución de Automatización y Normalización de Auditorías, el CCN-CERT, del Centro Criptológico Nacional, ha desarrollado este servicio en formato de nube privada: ANA Central.

Esta solución tiene por objeto incrementar la capacidad de vigilancia y conocer la superficie de exposición, reduciendo los tiempos en la gestión de la seguridad, mediante una gestión eficiente de la detección de vulnerabilidades y la notificación de alertas. Asimismo, entre sus características principales destaca su posibilidad de integrarse con otras herramientas, como LUCÍA, PILAR, CLARA, EMMA y MARTA.

Cada organismo solicitante contará con un nuevo espacio de trabajo en ANA Central, el cual incluye las mismas funcionalidades que una instalación de ANA On Premise, independiente del resto de organismos; con certificados de acceso a la herramienta, válidos para la conexión a su propio espacio de trabajo; y con un usuario administrador del espacio de trabajo específico para dicho organismo.

De esta forma, esta solución permite a los organismos adscritos el despliegue automático de nuevas capacidades para la gestión de las vulnerabilidades, la actualización automática de la herramienta y del CPE y CVE, el mantenimiento de la infraestructura, copia de seguridad de la base de datos y custodia de los datos de las auditorías por parte del CCN-CERT, además de un canal de comunicación con el equipo de soporte, reduciendo los tiempos de respuesta y resolución de incidencias.

«ANA incrementa la capacidad de vigilancia y permite conocer la superficie de exposición, mediante una gestión eficiente de la detección de vulnerabilidades y notificación de alertas.«

Para más información:

LEER MÁS