lunes, mayo 25, 2015

Exposición insegura de WebServices .NET en apps Android

Aunque cada vez más en desuso, todavía podemos encontrar bastantes servicios web desarrollados en .NET utilizando ASMX, y curioseando en nuestra plataforma Tacyt en búsqueda de posibles servicios web expuestos que implementen esta tecnología uno puede descubrir un buen número de aplicaciones que hacen uso de ellos, tal y como se puede ver en la Figura 2.

Figura 1: Exposición insegura de servicios web .NET en apps Android

Una de las curiosidades de este tipo de servicios es que, dependiendo de la versión utilizada de .NET y de la configuración establecida en el fichero web.config bajo el elemento <WebServices>, se puede proveer cómodamente una forma de testear un webservice a través de un simple botón.


Figura 2: Aplicaciones Android en Tacyt con links que apuntan a webservices

Para conseguir esta ejecución, basta con pulsar el botón Invoke, tal y como se puede ver en la Figura 3. Esta facilidad de botón gordo (habilitada por defecto sólo para pruebas locales en sus últimas versiones) no supone un riesgo mayor que la exposición de un servicio que no disponga de las medidas de seguridad adecuadas, ya que si encontramos dicho botón deshabilitado podremos suscribirnos al servicio igualmente e invocar a los servicios web a través de un cliente.

Figura 3: Botón de Invoke para ejecutar un webservice

Sin embargo esta facilidad puede llegar a suponer un riesgo doble al facilitar un posible abuso por parte de un usuario malintencionado que esté inspeccionando, por ejemplo, aplicaciones Android. La siguiente imagen muestra cómo en los enlaces de una app se puede llegar a localizar información de webservices fácilmente.

Figura 4: enlaces de una app de Android con links a webservices

Entre los ejemplos de servicios web expuestos que me han llamado la atención por su falta de seguridad destacaría por ejemplo el siguiente listado de información de usuarios basado en un ID que se le puede facilitar e incluso por el que se podría iterar para obtener un volcado de cuentas de correo y passwords (en este caso pasadas por una función hash):

Figura 5: Un Webservice descubierto en una app de Android que devuelve los datos de las cuentas

Curiosamente bajo ese mismo servicio web existe otro método web que sin solicitar ningún tipo de credenciales de forma adicional permiten el borrado dado un ID… ¿peligroso verdad?:

Figura 6: Webservice para borrar una cuenta de usuario

Otro ejemplo interesante lo he encontrado en un conocido juego de billar que nos permitirá listar todas las partidas en curso que están realizando los jugadores:

Figura 7: Webservice para acceder a los datos de las partidas

Y por el mismo precio, eliminarlas:

Figura 8: Webservice para eliminar todas las partidas del juego

Podemos llegar incluso a encontrar servicios que, por el mero hecho de ser invocados, provoquen errores devolviendo información como nombres de bases de datos, tablas, columnas, relaciones…

Figura 9: Leaks de información conseguidos a través de un webservice inseguro

O como explicábamos en un principio, servicios que no disponen de ese botón gordo Invoke

Figura 10: Webservices sin botón "Invoke"

… pero que igualmente nos permitirán realizar una suscripción al servicio:

Figura 11: Invocación del webservice. Se puede hacer también con SoapUI.

Reflexiones finales

Finalmente y sacando algunas conclusiones sobre estas líneas:
- Todo servicio expuesto debe implementar los mecanismos de seguridad que le apliquen según su criticidad y funcionalidad. Cifrado, autenticación y autorización son nuestros aliados cuando tenemos información sensible, contenido al que sólo se puede acceder si se es reconocido como un usuario válido del sistema o cuando necesitamos una granularidad fina como para que un determinado método web sólo lo ejecute un usuario concreto. 
- Recordar que cualquier código entregado al cliente (como lo es una app Android) es susceptible de ser analizado de forma estática y dinámica, de modo que cualquier servicio externo finalmente quedará expuesto. 
- Y esto último ya más como un apunte curioso, es interesante ver como aunque Microsoft recomienda utilizar WCF frente a ASMX, si buscamos las apps publicadas desde hace 3 meses encontraremos bastantes más servicios ASMX:
Figura 12: Los WebServices con ASM siguen siendo más usados que en WCF

Autor: Miguel Ángel García (@nodoraiz)
Software Engineer en Eleven Paths

4 comentarios:

Anónimo dijo...

Aunque cada vez más en desuso, todavía podemos encontrar bastantes servicios web desarrollados en .NET utilizando ASMX

Me confunde esa afirmación: ¿Lo que está cada vez más en desuso son los servicios web o su implementación en ASMX?

Miguel A. Garcia dijo...

Hola Anónimo,

Como imaginas por la duda que planteas, los servicios web son un básico y hoy día prácticamente cualquier app se soporta sobre ellos de una u otra forma.
Me refería a su implementación en ASMX, este tipo de servicio web ha evolucionado a WCF, e incluso se dispone de otras alternativas como Web Api.

Un saludo!

Anónimo dijo...

Conozco que es un ws, he implementado unos cuantos.

Me había sorprendido la afirmación porque hoy cada día se usan más.

Jaime Chiquita dijo...

La solucion es filtrar la llamada al servicio.
Y no comprendi como lo has llamado!

Entrada destacada

Navaja Negra: La CON de Albacete el 29 de Septiembre @navajanegra_ab @elevenpaths @0xWord

Es la sexta edición de esta CON que comenzó hace ya más de un lustro en la ciudad de Albacete , reúne el próximo 29 de Septiembre a una b...

Entradas populares