Uncategorized

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.

CCLEANER eliminar o mantener? – Voto por mantener!

Guido Rosales 22/09/2017

Con el analisis realizado, personalmente reitero mi voto de confianza a esta herramienta de la cual soy usuario por mas de 5 años. Se generan dudas que deben ser analizadas, lastimosamente nunca tendremos respuestas concretas. Toca convencerse uno mismo para vertir opinion ante las constantes preguntas sobre que hacer, desinstalar ccleaner? creo que no es la solucion. La seguridad debe tomar por ejemplo el modelo del quezo suizo (James Reazon) donde existen varias capas, controles, herramientas, habitos que en conjunto dan el nivel de seguridad. No hay soluciones magicas, sino estado de alerta, inversion y dedicacion por parte del negocio y los responsables por la seguridad en cada nivel tanto empresarial como domestico.

Comparto parte del analisis realizado en Yanapti SRL:

Segun las estaditicas AVAST, un conocido producto antimalware, producido desde 1988 en la ciudad de praga ha logrado alcanzar una cuota de mercado mundial cerca al 25%, se estima unos 400 millones de instalaciones.
En septiembre de 2016 anuncia la adquisiscion de AVG otro producto antimalware, producido desde 1991 tambien de la republica cheka. AVG se ha ubicado en un septimo lugar en la distribucion de mercado.
Piriform produce ccleaner mas o menos desde el año 2005. Y ha logrado una cuota de mas o menos 130 millones de instalaciones en PC y unos 15 millones en moviles andorid.
En julio del 2017 se anuncia la compra de piriform por parte de AVAST
En agosto se detecta la infeccion de una version (5.35) con malware espia que aparentemente hubiera sido descargado por unos 700.000 usuarios. Inicalmente se descia que el malware recolectaba datos del equipo victima para enviarlos a algun lugar del ciber espacio. Entonces se creia que pudiera ser la preparacion para un gran ataque de malware o DDOS.
Con el analisis mas profundo se reporta que firmas de tecnología y telecomunicaciones de Japón, Taiwan, Reino Unido, Alemania y Estados Unidos fueron el blanco de este ataque. El objetivo era atacar directamente a los gigantes de la tecnología como Google, Apple, Amazon, Facebook o Cisco. "Ntdev.corp.microsoft.com, vmware.com, samsung.sk, htcgroup.corp, amr.corp.intel.com, linksys, hq.gmail.com...." La lista de los servidores a los que apuntaba el malware incluye la mayoría de los gigantes de la tecnología e internet, por lo que los investigadores creen que el ataque masivo se basaba en una demostración que consistía en soltar el mayor número de copias infectadas para ver si había suerte y alguna de ellas recaía en algún equipo corporativo.
Cabe destacar que el ataque no fue controlado por las firmas antivirus hasta despues de haber sido detectado. Es decir el concepto de analisis Heuristico, patrones, etc. no fue capaz de identificar el comportaniemto anomalo de una herramienta que gozaba de la confianza en base a las firmas y certificados de fabricante.

Los cuestionamientos que nacen de este evento son:

Que cambio con la compra de Piriform por Avast? se relajo el control y la seguridad? o la fusion no le gusto a alguien y pudo ser un sabotaje?
Si analizamos las cuotas de mercado (fuente; www.av-comparatives.org/) segun el reporte 2016 podemos presumir motivos comerciales:
En el cuadro se puede observar que la posicion de AVAST podria cambiar. Entonces mejor si se frena un poco.
Cuando se implementan reglas de Firewall, normalmente los productos que vienen de fuente fiable tiene tratamiento especial. Paasporte diplomatico. Esto cuestionaria este concepto y nos deberia volver paranoicos y comenzar a analizar todo el trafico? seguramente una tarea imposible de hacer considerando que casi todos los productos generan trafico contra su fuente de actualizacion. Existe cierto grado de confianza que se estuviera poniendo en duda.
Se hubiera hackeado a Piriform o AVAST? de cualquier forma se entiende que empresas como estas deberian tener robustos controles en todos sus procesos. Nuevamente acudimos a la maxima "al mejor cazador se le va la liebre?" o podriamos decir "cazaron al cazador" al final tambien podriamos colocar "en casa de herrero.." finalmente podemos cuestionar nuevamente todo el conjunto de estandares y herramientas de seguridad reactivas que estamos implementando. Con tanta sofisticacion los hechos se revelan cuando ya hay victimas. No queremos ser muy paranoicos, pero estos temas deben ser analizados en diferentes niveles tanto empresariales como nacionales.
Particularmente hemos podido comprobar que los antivirus no funcionaron. recibimos y vimos reportes de herramientas que comenzaron a detectar el malware despues de la publicacion en medios abiertos. Como que la brecha no fue dada a concer en circulos especiales para que el remedio salga por lo menos junto a las noticias.
Esto afecta la confianza en CCLEANER? seguro que si. Pero personalmente soy usuario de ete producto por mas de 5 años con certeza y le doy aun un voto de confianza en lo que hace. He probado soluciones alternativas del otro extremo como las que trae BAIDU Pc faster o su version cloud baidu cleaner y si bien hacen un buen trabajo he podido comprobar que las ultimas actualizaciones de ccleaner superan la limpieza, los reportes, el control que se tiene a nivel de PC. Entonces toca elegir entre Mal conocido o mal por conocer. La confianza se gana en años, puede tambalear en casos como este, pero nadie esta excento de estos hechos.