lunes, 14 de abril de 2014

Movibug

Descubrí un bug (comportamiento no esperado en una aplicación) de seguridad en movistar. Me parece que lo mejor que puedo hacer es compartirlo para que sea de público conocimiento. La primera vez que lo vi fue en enero y sigue en vigencia.

Estaba revisando mis movimientos en la página y me llamó la atanción lo mucho que demoraban las peticiones. Entonces entré en el modo desarrollador del browser y mi fijé cómo era la petición HTTP para ejecutarla yo.

Aqui un ejemplo modificado de la url:
https://online.movistar.com.ar/services/movimientoServlet?fechaDesde=14042014&fechaHasta=14042014&categoria=&orden=0&numeroLinea=XXXXXXXXXX

Como conté en otro post las peticiones HTTP pueden tener una serie de parámetros que se envían al servidor. En este caso me sorprendí bastante con los parámetros:

  • fechaDesde y fechaHasta, indican el período en el que se quieren ver los movimientos
  • categoria, indica qué tipo de movimientos, vacío es todo de tipo
  • orden, este parámetro no entendí bien su uso, pero no importa demasiado
  • ¿numeroLinea?
El último parámetro es el número de línea, y era mi número de celular. Por lo que pensé que si cambiaba este parámetro por otro número ¡podría ver los llamados y SMS hechos por cualquier otro número de Movistar!

Esperaba que sucediera algún tipo de error, pero no. Funcionó. Ingresé varios números de amigos clientes de Movistar y pude ver sus movimientos.

Nota: el formato de la respuesta es JSON, pero si se presta atención se puede entender un poco. También hay herramientas que ayudan a visualizar estos formatos.

Para reproducir el bug:
  1. Ingresar a la web de movistar
  2. Loggearse con usuario y contraseña. Si tienen uno se pueden registrar.
  3. En la barra de direcciones escribir una url como la siguiente reemplazando las "X", con código de area, por su número de línea: https://online.movistar.com.ar/services/movimientoServlet?numeroLinea=XXXXXXXXXX&fechaDesde=14042014&fechaHasta=14042014&categoria=&orden=0


Espero que arreglen esto pronto.
Saludos

46 comentarios:

  1. Un comentario que me hicieron sobre el código de área.
    Si mi número es 1541111111 y mi código de área es 011. Entonces el número que va por parámetro debe ser 1141111111. Es decir, el código sin el 0 y el número sin el 15.

    ResponderEliminar
  2. GENIAL!

    Me sirvió de ejemplo para mis alumnos. Justo hablábamos la semana pasada sobre que cosas si y que cosas no, pasar por queryString. Que problemas se encontraban de las malas prácticas de desarrollo.

    Y este es el mejor ejemplo de todos.

    ResponderEliminar
    Respuestas
    1. me parece que no es un tema de seguridad de que pasar por querystring, que pasar entre las barras o por body... la seguridad es la misma (nula)... deberia haber (por ejemplo) alguna clase de token de sesion habiendose logueado que implica el nro, ergo, solo podes consultarte a vos mismo...

      Eliminar
    2. Pasarlo por el body tampoco sirve. Esto es un ejemplo, en todo caso, de que cierta información *NO* debe ser enviada a través de HTTP.

      Eliminar
    3. La esencia del problema es que no se está validando que la linea sobre la que se hace la consulta esté asociada a la cuenta desde donde se hace la consulta. En segunda instancia, por un tema de usabilidad, debería haber un selector ofreciendo las lineas disponibles:

      select id="linea"
      option value="1" 6666 6666 /option
      option value="2" 7777 7777 /option
      option value="3" 8888 8888 /option
      /select

      Un error común, para ahorrarse una consulta es hacer:


      select id="linea"
      option value="6666 6666" 6666 6666 /option
      option value="7777 7777" 7777 7777 /option
      option value="8888 8888" 8888 8888 /option
      /select

      Y aceptar el value sin validarlo

      Con respecto al impacto no pienso que sea tan terrible como lo pintan los titulares, lo que yo verifiqué ayer cuando nos contó Diego era hora y duración de la llamada, no había destino. Sirve para hacer una análisis muy parcial de tráfico o para que una pareja celosa pueda verificar si es verdad que su par estaba sin poder comunicarse. Depende de la latencia que tenga podría servir para saber si ya colgó sin tener que llamar.

      Lo que podría indicar, como ya ha sido expuesto por acá y en los mails de la facultad, es que un error como este evidencie una falta de calidad del software, una ausencia de verificación apoyada sobre un diseño muy pobre e implementado por desarrolladores sin experiencia o motivación.

      Pero eso sólo lo podríamos saber si analizáramos todo el sitio, existen los accidentes

      http://seguridad-agile.blogspot.com/2014/02/medidas-contra-el-anonimato.html


      Eliminar
    4. Es como dice diegoap, acá el problema no es que se manda o que no, sino que no se valida correctamente antes de dar una respuesta.

      Eliminar
  3. Le informé por twitter a la cuenta oficial de Movistar Argentina.
    Su respuesta: https://twitter.com/suelopoder/status/455901190170345472

    ResponderEliminar
  4. No lo puedo creer.
    Y para colmo la respuesta robotizada de su "atención al cliente"....

    ResponderEliminar
  5. es una llamada ajax y con pocos parametros, no hay problema que sea por get, si es por post con el propio browser podes ver los parametros o con programas tipo fiddler poder re ejecutar la consutla, el problema es que no estan verificando si la linea corresponde a login actual, ya que solo verifican que este loqueado

    ResponderEliminar
    Respuestas
    1. tal cual. No verifican que el que consulta tenga privilegios para la acción. Seguramente es algo que se extiende a otro nivel, no me sorprendería que se pueda realizar otra acción.
      Ni que hablar que la información no viaja de ida y vuelta por un canal seguro.

      Eliminar
  6. Despues desestiman los controles de calidad del software. Cuan importante es el testing y tener ambientes preproductivos para poder detectar estos defectos.

    ResponderEliminar
  7. Hola.
    No quise decir que el problema era que ese parámetro se pasaba por query string. Está claramente mal que ese parámetro se tome sin validaciones en el servidor, venga por donde venga.
    Saludos.

    ResponderEliminar
  8. Increible.... pero como se interpreta por ejemplo "fecha":1397503214000

    ResponderEliminar
    Respuestas
    1. Hola.

      Ese número es una representación de la fecha en formato timestamp de javascript.
      En esta página se explica mejor: http://www.w3schools.com/jsref/jsref_obj_date.asp
      Viene a ser la cantidad de milisegundos desde la medianoche del 1/1/1970.

      Saludos

      Eliminar
  9. Me parece que ya lo arreglaron porque me dice que la página solicitada no está disponible :S

    ResponderEliminar
  10. Esto es mentira, acabo de entrar a mi cuenta de movistar y para ver mi detalle se ejecuta la siguiente URL: https://online.movistar.com.ar/contrato/consumos/DetalleSMS.do

    ResponderEliminar
    Respuestas
    1. No importa la url, fijate que estan hablando del pedido que se le hace al server

      Eliminar
    2. Hernan se trata de un API Rest. Las URL no son visibles a simple vista. Como dice en el post tenes que usar un plugin para tu navegador como firebug.
      Más info sobre api restfull:
      http://en.wikipedia.org/wiki/Representational_state_transfer

      Eliminar
    3. Esto pasa cuando uno quiere hablar/escribir de lo que no sabe..

      Eliminar
  11. http://www.infotechnology.com/internet/Una-falla-de-Movistar-permitio-acceder-a-datos-privados-de-llamadas--20140415-0003.html

    ResponderEliminar
  12. No se pude denunciar a la DNPDP? http://www.jus.gob.ar/datos-personales.aspx

    ResponderEliminar
  13. Buen arranque del blog. Felicitaciones.
    Me suscribo a ver qué otras cosas publicás.

    ¡Saludos!

    Martín.

    ResponderEliminar
  14. Sigue funcando? recien intente y no pude :s

    ResponderEliminar
  15. Hola, me loguie, copie la url, probe con mi propio numero pero me pone que la pagina no esta disponible, lo habran arreglado (como corresponderia) o me falta algun paso? Gracias!

    ResponderEliminar
  16. Muy interesante, desde España no lo podemos comprobar, esperemos que lo reparen pronto.

    ResponderEliminar
  17. Sabiendo que el bug es por pasar los parametros usando un GET, no creo que hayan remodelado el sistema para tunelearlos, lo mas seguro es que hayan pasado la consulta por POST, si generas una petición con esos parámetros por post y estas logueado en site de movistar, sigue siendo replicable el bug.

    ResponderEliminar
  18. Son una bestias los de Movistar no pueden tardar tanto en solucionarlo.
    Primero deberían chequear el referer del request para aceptar solo consultas de los referers tales como movistar.com y sus aplicaciones móviles.
    Y en segundo, mínimo tienen que chequear en el server que el usuario de esa línea esté logueado y sea de la misma sesión desde que se le está haciendo el request :s

    ResponderEliminar
  19. Probé también por POST y no anda, ya fue?

    ResponderEliminar
  20. Toma capo yo aporto otro fallo mas y van...
    https://scontent-b-mia.xx.fbcdn.net/hphotos-frc3/t1.0-9/28376_1441515393534_707090_n.jpg
    https://scontent-a-mia.xx.fbcdn.net/hphotos-ash2/t1.0-9/37416_1468916798552_2585108_n.jpg

    ResponderEliminar
    Respuestas
    1. Zarpado capo, q onda? Repartí (?) Estudio sistemas también, me da mucha lástima que sea una empresa de mierda gracias a que contranten gente capacitada para el orto, aprendan algo en la facu capos...

      Eliminar
  21. Excelente post y buen comienzo. Sigan así.

    ResponderEliminar
  22. ya lo arreglaron... y yo que queria hacer maldades

    ResponderEliminar
    Respuestas
    1. http://grooveshark.com/#!/s/Vamos+A+Portarnos+Mal/4O9oQo?src=5

      Eliminar
  23. Este comentario ha sido eliminado por el autor.

    ResponderEliminar
  24. ¿Saben qué es lo peor? Que este error se los reporté a mediados de 2013 y me decían que estaba equivocado y que ese error no existía, por lo que les insistí para que lo vea un técnico y no cualquiera porque el error existía y era un problema grave de seguridad. A los pocos días modificaron el servicio, el error desapareció o no era tan sencillo acceder como copiar una URL y nunca me dijeron "che, tenías razón". Lo que no entiendo es por qué volvieron a poner el servicio que no verificaba la sesión del usuario.

    ResponderEliminar
    Respuestas
    1. ¡Que loco!
      Ahora tenías que estar loggeado, quizás eso es lo que cambió.

      Eliminar
    2. Es que lo lógico es que el servicio devuelva los movimientos del usuario en sesión y no que espere un parámetro por URL indicando sobre qué línea tiene que devolver información.

      Eliminar
    3. Sí, o sino pueden agregar un hash para validar el request.
      Supongo que saldrán con esto último porque es lo más fácil de implementar.

      Eliminar
  25. Yo no recuerdo si termine la secundaria creo que no, pero estudia loco. abrazo

    ResponderEliminar
  26. Si no entendi mal en la nota de "La Nación", la posibilidad de ver los movimientos solo sera para las nuevas cuentas con plan ONE, y se deja la consulta de movimientos para el plan Control.
    Una, ya se sabe que el plan control ya esta dejando de existir, -ya han avisado que vuelan los nros. free-,solo se mantienen los viejos usuarios, seguramente nos terminen pasando a todos...
    Dos, ahora y mientras no se pueda controlar los movimientos, seguramente aparecerán decenas de mensajes 19114 de esos que se cobran mucho y nunca fueron requeridos.

    No creo en la inocencia de este "Descuido" de seguridad, lo entiendo como una excelente estrategia..

    ResponderEliminar
  27. Error 500--Internal Server Error

    From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1:

    10.5.1 500 Internal Server Error

    The server encountered an unexpected condition which prevented it from fulfilling the request.

    ResponderEliminar