lunes, 21 de noviembre de 2011

Hacking Web Services [Parte II]

La función de un web service es brindar un servicio a través de una interface pública que pueda ser utilizada por cualquiera para construir aplicaciones que consuman el mencionado servicio. Es por esto que, de primera intención, la autenticación del cliente no es una prioridad cuando nos referimos a web services puesto que la idea es que estos mismos sean públicos.

Sin embargo, en la práctica, los web services no solo se utilizan para brindar servicios públicos donde no se requiere autenticar al usuario. También podemos encontrar web services que dan soporte al backend de algunas aplicaciones y que pueden ejecutar funciones administrativas. En esos casos la autenticación es una necesidad prioritaria.

Sin embargo muchas veces no se implementan medidas de autenticación y podemos encontrar muchos web services administrativos expuestos en internet. Por poner un ejemplo, podemos buscar con Google documentos WSDL con métodos interesantes como getUsers, uploadFile, updateInfo, deleteUser, etc.

Fig. 1 - Buscando Web Services para subir archivos.

También podemos probar con nombres más directos como por ejemplo "admin".

Fig. 2 - Buscando Web Services de administración.

Luego cargamos el WSDL en SOAPui y vemos si se ha implementado alguna medida de autenticación o si permite ejecutar los métodos sin más. Seguro encuentras alguno como este:

Fig. 3 - Obteniendo todos los usuarios.

Personalmente he visto un caso de un CMS propietario que es ofrecido por una empresa de la cual no daré más detalles pero que espero sus clientes reconozcan por las imágenes que pondré.

La parte cliente de este CMS está desarrollada en flash y se comunica con el servidor enviando mensajes SOAP a un web service. Una arquitectura por lo menos interesante. Sin embargo se olvidaron de la autenticación y cualquiera puede comunicarse con el web service y pedir la lista de usuarios y contraseñas, eliminar publicaciones, subir vídeos u otros archivos, etc.

La URL del WSDL se encuentra "hardcodeada" dentro del flash.

Fig. 4 - WSDL hardcoded.

Además, este CMS, tiene problemas con el manejo de sesiones. El web service de logeo devuelve un 1 si las credenciales son correctas y un 0 si no lo son. Ni cookie, ni token, ni viewstate, ni nada. Solo es cosa de interceptar el 0 antes que llegue al navegador (con ZAP por ejemplo) y cambiarlo por un 1 para loguearse como administrador.

Fig. 5 - Panel de administración del CMS.

Quizá la cereza de este pastel sea este mismo web service también es vulnerable a SQL injection. Un clásico ' or ''=' en el formulario de login y pa'dentro otra vez como administrador.

Fig. 6 - Login del CMS.

¿También hay SQLi en Web Services? Por supuesto. SOAP, por decirlo así, es una forma estandarizada de enviar entradas a una aplicación. Así que no sería raro encontrar errores típicos de validación de entradas como lo son las inyecciones SQL.

Lo único que cambia es la forma en que envías la inyección. En este caso será usando mensajes SOAP. Por lo demás todo es igual. Por ejemplo:

Fig. 7 - Generando un Syntax Error.

Fig. 8 - Extrayendo información.

En resumen: Malas prácticas de programación, falta de autenticación, falta de manejo de sesiones, falta de validación de entradas, en fin... toda una joyita. Si eres cliente de esta empresa y has contratado su producto para tu página web date por avisado que los datos de tus usuarios no están seguros.

Es todo por hoy, hasta la próxima.

Actualización:

Otros capítulos de la serie:

No hay comentarios:

Publicar un comentario