vulnerabilidad

Muchas empresas contagiadas con la arrollante embestida del mundo móvil, decide entrar con aplicaciones móviles de todo tipo y sabor. Desde simples app informativas hasta sistemas de gestión o banca móvil.

Todo va bien, el entusiasmo por desarrollar apps móviles es impresionante, vemos muchos eventos promoviendo esto. Pero lamentablemente temas de Seguridad van por detrás. El optimismo de la gente hace que las preocupaciones y riesgos no sean parte del procesos de desarrollo sino hasta que las vulnerabilidades saltan.

Para demostrar este punto de la inseguridad, hemos realizado un relevamiento con 11 APKs compartidas en el Play STORE de google, todas bolivianas. Todas estas Apps pertenecen a entidades XXX-XXX (Censurado para no despertar a los GGX) y están en actual explotación con sistemas considerados sensibles.

Entendamos que la vulnerabilidad de una APP no solo expone el sistema de la Entidad XXX-XXX que la desarrollo. sino también expone los datos del usuario cliente. Casi todas las apps evaluadas consideramos no han tenido una evaluación de privilegios necesarios, sino en algunos casos como utilizan componentes de terceros, solicitan control de gps, wifi, micrófono, cámara, envio de sms y muchos mas. Al final uno se pregunta Por que tantos privilegios? estamos seguros y retamos a las entidades XXX-XXX que publiquen la justificación de esos privilegios.

Recordemos que un celular puede exponer:

credenciales de acceso
datos de ubicación por el gps,
la conexión telefónica por las antenas, datos
de los sensores (acelerómetro, giroscopio, podómetro y otros)
mucho mas

Entonces la publicación de APPs debe ser mas controlada, sobre todo si el usuario asume que la seguridad esta siendo cubierta por la Entidad que la despliega en el play store.

Voy a ser redundante en el tema de que estar en los Store de aPPs no hace las mismas seguras. Google no se ocupa de ver cuan segura es la aplicación, siempre y cuando no este afectando a su ecosistema.

Algunas características genéricas de Las APK analizadas

tienen entre 35mb y 2mb de tamaño
Las Apps de mayor tamaño contienen mas cantidad de vulnerabilidades.
Algunas tienen semanas de haber sido actualizadas y otras mas de un año de no Haber sido actualizadas
Todas están el el Play store
Solo una tenia controles para no ser montadas en un emulador

Se han evaluado 34 vulnerabilidades (OWASP mobile)

De esa cantidad se han encontrado 16 vulnerabilidades presentes en las App analizadas. En el cuadro siguiente exponemos las 16:

File unsafe Delete Check

SSL Implementation Check - SSL Certificate Verification

Certificate Pinning

Using activities/improper export of android application activities

Fragment Vulnerability Check

Usage of Adb Backup

Usage of Native codes

Outputting Logs to logCat/ Logging Sensitive information

SQLite Journal Information Disclosure Vulnerability

WebView addJavascriptInterface Remote Code Execution

Usage of Root/Superuser Permission

Usage of Installer verification code

Executing "root" or System Privilege Check

Emulator Detection Check

Unencrypted Credentials in Databases (sqlite db) Vulnerability check

Access Mock Location

El resultado en terminos porcentuales por SEVERIDAD es el siguiente:

Desglozadas por su nivel de Severidad tenemos:

Las vulnerabilidades expuestas NO son nuevas. Solo veamos un ejemplo con Certific ate Pinning

Les dejo un enlace del 2013 donde se expone la misma: http://blog.elevenpaths.com/2013/08/certificate-pinning-el-que-el-como-y-el.html

y otro enlace de OWASP: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning

ACLARACION

El presente articulo continen datos que han sido colectados a inicios del mes de diciembre. Las evaluaciones se han terminado antes del 10/12. En ese tiempo podrian haberse dado algunas modificaciones, pero estimamos que no muchas.

El contenido trata de ser lo mas generico posible para llegar al publico en general. Sin embargo el soporte es tecnico.

CONCLUSION:

La innovacion por supuesto que es bueno y no podemos cargar con temas de seguridad toda esa corriente que motivada por el acelerado crecimiento de la tecnologia movil esta buscando nuevas formas o reinventando nuevos conceptos. Por eso en las entidades y en general estamos quienes nos ocupamos de temas de seguridad. No queremos estar contra la corriente y el entusiasmo. Pero seria irresponsable sacar un ultimo modelo de automovil sin la seguridad necesaria.

Las entidades reguladas, reguladoras deben prestar atencion a la bomba de tiempo que estamos colocando en cada telefono movil. Y el usuario final debe entender que ese Compañero digital llamado telefono movil, puede traerle muchos problemas en un momento dado.

Candaditos HTTPS vemos debilidades no sabemos!!

Guido Rosales 20/12/2017

¡DEBE SER Y PARECER!! TENER UN HTTPS NO ES SUFICIENTE

Lamentablemente aun nuestra entidades toman de mala manera cuando se publican verdades facticas.

Este reporte llega a ALGUNAS entidades con datos completos, pero para fines de difusion publica se ha enmascarado cierta informacion.

Aun tenemos generacion X reaccionado al Rojo Vivo y generando un espiritu de limitacion a la libertad de expresion. Pero a buen entendor pocas palabras!!!

Por muchos años contar con un protocolo HTTPS y su correspondiente certificado digital en los servidores web, que soportan sistemas de entidades xxx--xxx ha sido sinónimo inobjetable de SEGURIDAD.

Sin embargo, los certificados Digitales con el tiempo han enfrentado el descubrimiento de vulnerabilidades en los algoritmos criptográficos, los protocolos de seguridad, la compatibilidad y seguridad de navegadores, así como la configuración de los servidores. Entonces para mantener el estado SEGURO de los sitios HTTPS se deben contemplar diferentes variables. El solo hecho de contar con un candado visual y un protocolo HTTPS ya no es suficiente.

Figura 1: Relación de seguridad con HTTPS

En términos simples podemos decir que existen Niveles de seguridad entre los sitios que tienen configurado un protocolo HTTPS.

OBJETIVO:

Yanapti SRL con el afán de apoyar en la seguridad de xxx--xxx ha realizado un trabajo de investigación técnica mediante una evaluación externa, COMPLETAMENTE PUBLICA, PASIVA Y NO INTRUSIVA en los sitios web de 23 entidades xxx--xxx!!!!

El Objetivo es apoyar para que TODOS los sitios tengan un nivel ALTO en términos de seguridad de acuerdo con los métodos y criterios utilizados a la fecha.

Las vulnerabilidades institucionales afectan la MARCA PAIS en cuanto a nivel y percepción de la seguridad de la información devaluando las capacidades tanto como nación, así como profesionales. Los resultados pueden y han sido enviados unicamente con datos de entidades comprendidas en la muestra.

RESULTADO GENERAL:

El resultado de la evaluación es el siguiente:

Figura 2: Niveles de RIESGO detectados - agosto 2017

Se volvio a realizar las evaluaciones al 15 de diciembre 2017

Figura 3: Niveles de RIESGO detectados - diciembre 2017

Esta figura refleja los porcentajes por grupos donde se puede apreciar los extremos

Para determinar los niveles se ha tomado la relación entre la calificación más baja y la más alta.

Al mes de agosto se tuvieron los siguientes resultados

NIVEL DE RIESGO MUY BAJO. 13% significa un grupo donde la conjugación de variables ha cubierto las diferentes vulnerabilidades conocidas hasta hoy. Se puede decir que tienen un nivel de seguridad MUY ALTO
NIVEL DE RIESGO MUY ALTO. 18% - Representa un grupo de entidades que, si bien tienen un certificado digital, la conjugación de variables no es óptima según los criterios de seguridad. Requieren de forma inmediata la reconfiguración de sus sitios. Se puede decir que tienen un NIVEL DE SEGURIDAD MUY BAJO.

Si consideramos que a Menor nivel de seguridad se puede entender MAYOR riesgo tenemos los siguientes resultados:

Figura 4: Relación Cantidad y Porcentaje – agosto 2017

Para el mes de diciembre 2017 la situacion ha cambiado un poco. se han invertido los resultados en promedio. El nivel de riesgo alto es de 13% y el nivel muy bajo subio hasta 17%

Figura 5: Relación Cantidad y Porcentaje – diciembre 2017

Los cuadros permiten aprecias la cantidad y la relación porcentual.

Se resalta como PROMEDIO DEL SECTOR el NIVEL ALTO de RIESGO, por cuanto sería el resultado de todo el grupo que exactamente da 27.83 en el mes de agosto y de 24.13 para el mes de diciembre. Se observa una mejora muy leve.

RESULTADO ESPECIFICO

De acuerdo con las evaluaciones realizadas las 23 entidades están distribuidas de diferente manera. Se identifican 5 grupos por el grado de riesgo que presentan.

Los nombres de las entidades no son presentados por motivos de confidencialidad y reserva de información.

Figura 6: Resultados de la evaluación – agosto 2017

Para diciembre hubieron mejoras en varias entidades, solo algunas mantuvieron el nivel al mes de agosto. En realidad solo una entidad bajo de nivel hasta lograr una F, el nivel mas bajo de seguridad.

Figura 7: Resultados de la evaluación – diciembre 2017

Por confidencialidad no se despliegan las entidades.

Se observa que algunas, aunque pocas entidades han mejorado su resultado, lamentablemente otras se mantienen y una ha empeorado.

VULNERABILIDADES ENCONTRADAS

Se muestra las principales vulnerabilidades encontradas:

FREAK attack
POODLE TLS attack.
MITM attacks
The server uses SSL 3, which is obsolete and insecure.
Intermediate certificate has an insecure signature.
The server supports only older protocols, but not the current best TLS 1.2.
This server accepts RC4 cipher, but only with older
There is no support for secure renegotiation
The server does not support Forward Secrecy with the reference browsers.

El grado de gravedad de estas vulnerabilidades hace que el sitio aparentemente protegido reciba calificaciones menores. Muchas de estas vulnerabilidades están ampliamente descritas en foros y sitios especializados. Tanto de manera teórica, como facilidades para explotarlas.

RECOMENDACIONES:

Es importante que cada entidad analice la exposición presentada bajo la premisa “DEBE SER SEGURO Y DEBE PARECER SEGURO”. La evaluación se ha realizado tomando las mismas variables y métodos para las 23 Entidades.

Consideramos que para mantener la confianza en el concepto HTTPS, TODAS las entidades del Sistema xxx--xxx deberían estar mínimamente con calificación A, siendo que aún existe la calificación A+.

Las recomendaciones técnicas van en diferentes niveles:

Se supone que muchas hacen evaluaciones de hacking regularmente. Recomendamos validar si este informe comprende vulnerabilidades en el certificado digital.
Del lado de los servidores WEB. Sin duda el lado más importante y que le toca bajo responsabilidad total a las entidades reguladas. Las vulnerabilidades están desnudando la limitacion de seguir a buen ritmo la detección y publicación de vulnerabilidades por cuanto varias tienen más de 12 meses. Esta recomendación está en manos de cada entidad y puede ser rápidamente subsanada.
Del lado de los clientes. Sin duda aun la brecha digital entre usuarios comunes y usuarios seguros es muy grande. Los primeros pueden dejar las vulnerabilidades de sus navegadores expuestas. Esta recomendación es mucho más difícil de asegurar.
Del lado de los desarrolladores que sin duda recae en las pruebas de pase a producción, donde deberían saltar estas vulnerabilidades. Esta recomendación está en manos de cada entidad y puede ser subsanada en un plazo de semanas.
La tarea de los diferentes niveles debe ser más estricta en términos de pruebas y acreditaciones antes de que algo sea publicado al Internet. Las Re acreditaciones de seguridad permiten protegerse contra la dinámica de la relatividad en seguridad. Algo que ayer fue seguro, hoy ya no lo es.

Finalmente, se debería exigir que todas las entidades consideren de manera más integral el análisis de vulnerabilidades y seguimientos a este tipo de riesgos. Muchos de los certificados tienen más de 12 meses de estar implementados, por tanto, se infiere que las vulnerabilidades tienen más de ese tiempo sin haber sido corregidas.