EF485 - EuroFach Electrónica

INVESTIGACIÓN 42 mico). Ningún código es perfecto y el malware encuentra dichos errores y los explota con sigilo, para ganar acceso a los sistemas, redes, dispositivos, objetos IoT, etc. Ejemplos de estas vulnerabi- lidades son los buffer-overflows, las race-conditions, las fugas-filtraciones de memoria, espionaje e intercambio de información entre máquinas vir- tuales aisladas, etc. El buffer-overflow puede permitir al malware ganar el control, sobre todo, potencialmente conduce al robo de datos privados e incluso al control del propio dispositivo, sistema, red, etc. (2) Alteración del código. Se trata de cualquier modificación que el malware puede realizar en el código de la APP/ API. Existe una gran variedad de formas de hacer esto, por ejemplo, hooking de métodos y clases, hooking dinámico, patching, etc. El malware puede utilizar la modificación del código para obte- ner acceso a características premium, violación del copyright y saltarse por completo el modelo de distribución existente para la APP. Lo que incluso es aúnmás importante es que el malware puede añadir más código malicioso a la APP vía cambios directos en los binarios o recursos. La APPmodificada se distribuye utilizando plataformas de distribución autorizadas (GooglePlay, AppStore, etc.) y de terceras partes. (3) Ingeniería inversa. El malware utiliza esta técnica para obtener la información necesaria para explo- tar vulnerabilidades de seguridad y descifrar datos. La información sobre algoritmos de cifrado utilizados, así como los trabajos generales de un servidor de back-end son particular- mente críticos de proteger. Puede ser obvio, pero cada APP es susceptible de ingeniería inversa. (4) Funcionalidades extrañas. Estas vulnerabilidades surgen cuando los desarrolladores no eliminan caracte- rísticas adicionales creadas durante el proceso de desarrollo para hacer más fácil el test de la APP. Un ejemplo de dicha característica es una cuenta de desarrollador que permite saltarse completamente las comprobacio- nes de seguridad y proporciona un amplio conjunto de privilegios. Es esencialmente un tipo de puerta trasera (backdoor) que proporciona al malware un control completo sobre la APP. Estas vulnerabilidades son fáciles de explotar. Se trata de incluir código de test en la construcción de la APP. (5) Almacenamiento inseguro de datos. Posibilita el robo y fuga de datos no intencionada (exfiltración de infor- mación) y violaciones de privacidad. El vector de ciber-ataque varía, desde APPs de terceras partes utilizando caché, cookies y otra información para recoger datos protegidos al objeto de poder de forma maliciosa ver infor- mación del dispositivo. Se necesita manipular el almacenamiento de datos, su autenticación, su cifrado, todas las características de la caché, etc. (6) Comunicación no segura. Es una vulnerabilidad muy común, presente en la mayoría de APPs con estructura cliente-servidor. Se basa en no cifrar (con algoritmos robustos y bien imple- mentados. Mejor utilizar algoritmos post-cuánticos o sino cifrado robusto, con varias capas usando diferentes algoritmos) los datos enmovimiento lo cual conduce al robo de dichos datos. El no cifrar datos en tránsito, sin auten- ticación, posibilita que su APP se vea sujeto a ciber-ataques MITM (Man In The Middle), dichos ciberataques nor- malmente vienen de dispositivos de red como routers, un malware en su propio dispositivo o incluso un agente infectado separado compartiendo la misma red que la víctima. Como pre- vención cifrar (de forma anidada y con algoritmos profesionales) y autenticar/ verificar los datos. Utilizar SSL/TLS y prohibir certificados autofirmados. (7) Autenticación insegura. Engloba tanto la debilidad del procedimiento de autenticación como lamanipulación de la sesión. Para APPs de móvil el malware utiliza técnicas amedida para saltarse por completo la APP del lado del cliente y enviar una petición direc- tamente al servidor. Los esquemas de autenticación para APPs de móvil nor- malmente sonmuchomás débiles que para APPs Web. Puesto que la mayoría de APPs necesitarán operar offline, se proporciona al usuario una opción de autenticación offline que puede ser explotada. Esto permite al malware obtener el control total del sistema. Los malware pueden de forma anónima borrar o robar datos o emitir comandos a la APP o al servidor. Como prevención utilizar autenticación robusta (mutua, multi-factor, ZK) online siempre que sea posible mientras se procesan todas las peticiones de autenticación del lado del servidor. También es una buena práctica reforzar la autenticación del lado del servidor y realizar compro- baciones de integridad locales que detectan cualquier tipo de cambios no autorizados de código. (8) Autorización no segura. Se trata de las vulnerabilidades del lado del servi- dor vinculadas con el procedimiento de autorización (que proporciona los privilegios sobre las operaciones que se puede hacer a cada recurso cada entidad/usuario). Como prevención asegurarse que los derechos del usuario sean comprobados siempre por el lado del servidor. Evitar confiar información alguna sobre el nivel de permisos que la aplicación le da a usted, ya que puede estar compro- metida. También debería verificar cualquier petición de un cliente inde- pendientemente del lado del servidor asegurándose que dichas peticiones pertenecen a un usuario autorizado. (9)Uso incorrectodeplataformasmóvi- les (APPsensmartphones, tablets, etc.). Proporcionan un conjunto de caracte- rísticas que los desarrolladores pueden acceder. Sin embargo, el uso incorrecto de dichas características puede dejar su APP expuesta a ciberataques malware. El vector de ciberataque más común es cualquier API expuesta. C M Y CM MY CY CMY K