- Hace poco fue posible encadenar un ataque que, aprovechando una vulnerabilidad de inyección JSON en dispositivos Samsung, llegaba hasta la ejecución de código en el dispositivo
- Puede servir como lección sobre cómo se pueden explotar APIs que confían ciegamente en el JSON del payload
Inyectar de forma "inteligente" en todo
- En el caso de Samsung Smart Hub, una app móvil podía comunicarse de forma remota con el hub para controlar todo lo conectado
- Al enviar una solicitud POST maliciosa al endpoint /credentials, era posible modificar las credenciales que el hub usaba para conectarse a un servidor remoto y manipular los datos, lo que podía derivar en una inyección SQL
- La librería json-c de la que dependía Samsung estaba compilada con JSON_TOKENER_STRICT=0, lo que permitía definir cadenas con comillas simples y dobles
- Esto permitía que un atacante creara columnas personalizadas en la base de datos sqlite interna del hub
- Después de insertar una cadena ROP excesivamente larga en la tabla camera, se podía enviar un DELETE al endpoint /cameras para hacer que el proceso video-core intentara leer los datos y fallara, provocando un desbordamiento de búfer tradicional basado en pila
- La lección aquí fue: inyección JSON → inyección SQL → desbordamiento de búfer → ROP = toma de control
¿Qué es la inyección JSON?
- La inyección JSON es una vulnerabilidad en la que se insertan datos maliciosos en un flujo JSON para cambiar el comportamiento de una aplicación o activar acciones no previstas
- La inyección JSON del lado del servidor ocurre cuando datos de fuentes no confiables se usan en el servidor, directa o indirectamente, en código sin ser saneados correctamente
El problema está en el parser
- En las aplicaciones web modernas y las APIs, pueden usarse varios parsers dentro del pipeline de solicitudes, cada uno con características y vulnerabilidades propias
- Las discrepancias entre parsers, combinadas con el procesamiento de solicitudes en múltiples etapas, pueden producir vulnerabilidades graves
- Los parsers JSON enfrentan dificultades porque el RFC oficial de JSON deja abiertos temas como las claves duplicadas y la representación de números
- El RFC oficial no es la única especificación: también existen ECMAScript, JSON5, HJSON y Binary JSON (BSON)
- La interoperabilidad entre parsers expone riesgos de seguridad cuya existencia mucha gente ni siquiera conoce
Problemas de seguridad en la interoperabilidad de parsers JSON
- Inconsistencias en la forma de manejar claves duplicadas
- Inconsistencias en la forma de manejar caracteres especiales o comentarios
- Inconsistencias en la (de)serialización de JSON
¿Cómo se puede explotar JSON?
- Manipulando JSON, se pueden inyectar datos para que la aplicación funcione de formas que el desarrollador no esperaba
- Cuando es posible manipular cómo pasan los datos por los componentes dentro de la infraestructura de una API, aparece la oportunidad de controlar la lógica de negocio
- Si se entiende cómo los parsers procesan la entrada, se puede abusar de su comportamiento para lograr que interpreten los datos de una forma que permita manipularlos y evadir la validación de entrada
Conclusión
- El ataque a Samsung Smart Hub es solo un ejemplo de cómo una inyección JSON puede llevar a una cadena compleja de vulnerabilidades, desde inyección SQL hasta ejecución remota de código
- La causa raíz suele estar en inconsistencias en la forma en que los parsers JSON procesan los datos, especialmente cuando intervienen varios parsers peculiares
- Al inspeccionar a fondo cómo se serializan, deserializan y procesan los objetos JSON, es posible descubrir cómo crear payloads que evadan filtros de saneamiento y afecten la lógica de negocio
- Como las APIs siguen siendo la piedra angular de las aplicaciones modernas, garantizar la seguridad de cómo procesan los datos es más importante que nunca
1 comentarios
Supongo que habrá que validar con bastante rigor los datos recibidos en el body JSON.