En cualquier auditoría de una aplicación web es importante buscar los puntos en los que se introducen los comandos. Decía Michael Howard que "All input is EVIL until it proves otherwise" para referirse a la necesidad de controlar absolutamente todos los datos de entrada de un sistema sin importar de donde vengan. En el mundo del pentesting, localizar las entradas de parámetros pronto y testear las inyecciones de comandos de las distintas tecnologías es algo básico que se hace siempre.
 |
| Figura 1: Dorking & Pentesting con Tacyt. SQL Injection, LDAP Injection y Command Injection |
En el mundo del dorking masivo se ha utilizado mucho en el pasado a través de los buscadores. Hemos visto ataques SQL Injection realizados masivamente que se han llevado millones de aplicaciones web inseguras indexadas en Google, hemos visto campañas de explotación masiva que se han llevado a Apple.com por delante, y hemos visto como a través de buscadores como Shodan o los mismos buscadores de repositorio de código OpenSource se crean dorks para localizar sitios vulnerables. Esto también lo podemos hacer buscando en el código de las apps.
(Blind) SQL Injection
No voy a centrarme mucho en explicar los ataques de SQL Injection o Blind SQL Injection, ya que de ellos he escrito largo y tendido en el pasado e incluso tenéis un libro en 0xWord para profundizar más [Hacking Web: SQL Injection]. En esta parte, cuando comencé a mirar si con las apps se podría llegar fácilmente a localizar sitios de backend vulnerables a SQL Injection comencé por buscar enlaces con parámetros como SQLQuery o Query y luego nombres de aplicaciones en el backend que fueran como MySQL.php, SQL.php, QuerySQL.aspx, etcétera y salió de todo.
 |
| Figura 2: Un enlace en una app para conectarse a una base de datos |
Como era de suponer, muchas de estas aplicaciones en backend no están indexadas en otros buscadores y por supuesto no están sometidas a los dorks de búsqueda masivos que hay ya creados para todos esos motores, así que aún no han sentido la importancia de revisar mucho el código de ejecución de una consulta SQL para detectar los ataques de SQL Injection.
 |
| Figura 3: Código decompilado de una app con ShowMyCode para ver los parámetros de SQLQuery.php |
Algunos de estas aplicaciones envían, como es normal, el envío de parámetros por POST usando un URLEncodedFormEntity, por lo que es cierto que cuando se descubre el enlace, en muchas ocasiones hay que decompilar el código (descomprimir el APK, decompilar el classes.dex, y con los ficheros en Bytecodes .class hacer un ShowMyCode para el ver el fichero Java y sacar los parámetros). El resto, inyectar con cualquier herramienta tipo Burp Proxy o similares.
 |
| Figura 4: En el parámetro Query basta con poner la consulta. FAIL! |
Buscando por cosas como DBlink, QueryBBDD, BDD.php, SQLServer, etcétera, el resultado es que aparecen miles de resultados que llevan a backends con poca o ninguna protección contra ataques de inyección de comandos SQL.
 |
| Figura 5: Otro enlace en una app sin ningún tipo de protección en el parámetros query |
(Blind) LDAP Injection
Desde hace años llevo yo jugando personalmente con las inyecciones de comando LDAP - tenéis el whitepaper que hicimos para BlackHat 2009 [(Blind) LDAP Injection] - y uno de los problemas ha sido siempre el encontrar entornos LDAP expuestos en Internet, ya que la mayoría de los árboles están siempre en la red interna. Por eso yo buscada en Shodan, con trucos en Robtex y hasta en las listas CRL de los certificados digitales para poder inspeccionar los árboles LDAP.
 |
| Figura 6: Una app con un backend LDAP |
Buscando por LdapSearch, también aparece alguna app que, lógicamente, lleva un enlace que permite inyectar parámetros en LDAP Search filters. Por supuesto, como es un enlace creado para una app, está fuera de los circuitos habituales para los dorks, así que tampoco está muy machacado.
 |
| Figura 7: Un LdapSearch en una app con escritura de LDAP Searh Filters |
El número de apps utilizando LDAP es alto, así que los dorks para localizar estos entornos facilitan la misión. Teniendo en cuenta que las técnicas LDAP Injection no son "mainstream" y no todo el mundo está puesto con ellas, el resultado es que estas apps casi no tienen ninguna protección contra ellas.
Command Injection
Una vez metidos en harina, buscar cualquier tipo de aplicación web que pudiera tener un bug de estas características no es demasiado complicado. Basta con pensar qué no se debería hacer nunca para ver si a alguien le ha parecido una buena idea. Buscando por apps con Command Injection, busqué enlaces con el parámetro "command" o con la cadena Command.php, o Execute.cgi, o ... lo que se te ocurra.
 |
| Figura 8: Un enlace a un command.cgi en una app (con enlace local) |
De hecho, después de eso comencé a buscar directamente comandos como mkdir en los enlaces y llegué a este mkdir que cuando se invocaba en el lado del servidor daba un error muy significativo.
 |
| Figura 9: Llamada aun programa para hacer directorios en el servidor. Muchos lo han debido de usar ya. |
Al final, la imaginación para hacer los dorks es tuya, y la gracia es que al tener en Tacyt un potente motor de filtros, cada vez que se descubre un nuevo app se le pasa por todos esos filtros. Si por cada dork que se te ocurra generas un filtro, por la mañana solo tienes que leer el feed RSS de tus dorks y ver qué ha caído nuevo.
Mañana la última parte
Si has seguido esta historia hasta aquí, supongo que ya te habrás hecho una idea de que en las apps que subas debes ser muy escrupuloso a la hora de dejar información, pues igual que dejar un leak en una aplicación web puede atraer a muchos atacantes que te localicen por medio de dorks, esto es exactamente los mismo con las apps móviles - peor aún, que también les dejas el código -. Por si queréis aprender más sobre esto, os dejo la referencia del libro "Desarrollo Android Seguro".
Saludos Malignos!
***********************************************************************************
- Dorking & Pentesting con Tacyt: Las APIs de terceros
- Dorking & Pentesting con Tacyt: Inyección de comandos
- Dorking & Pentesting con Tacyt: Inyección de comandos
***********************************************************************************
No hay comentarios:
Publicar un comentario