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:
- Ingresar a la web de movistar
- Loggearse con usuario y contraseña. Si tienen uno se pueden registrar.
- 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
Un comentario que me hicieron sobre el código de área.
ResponderEliminarSi 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.
GENIAL!
ResponderEliminarMe 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.
Buenísimo.
EliminarMe alegro.
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...
EliminarPasarlo 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.
EliminarLa 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:
Eliminarselect 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
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.
EliminarLe informé por twitter a la cuenta oficial de Movistar Argentina.
ResponderEliminarSu respuesta: https://twitter.com/suelopoder/status/455901190170345472
Si... necesito que lo arreglen... @#$#$@#$@#$
EliminarNo lo puedo creer.
ResponderEliminarY para colmo la respuesta robotizada de su "atención al cliente"....
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
ResponderEliminartal 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.
EliminarNi que hablar que la información no viaja de ida y vuelta por un canal seguro.
Despues desestiman los controles de calidad del software. Cuan importante es el testing y tener ambientes preproductivos para poder detectar estos defectos.
ResponderEliminarHola.
ResponderEliminarNo 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.
Increible.... pero como se interpreta por ejemplo "fecha":1397503214000
ResponderEliminarHola.
EliminarEse 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
Me parece que ya lo arreglaron porque me dice que la página solicitada no está disponible :S
ResponderEliminarEsto 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
ResponderEliminarNo importa la url, fijate que estan hablando del pedido que se le hace al server
EliminarHernan 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.
EliminarMás info sobre api restfull:
http://en.wikipedia.org/wiki/Representational_state_transfer
Esto pasa cuando uno quiere hablar/escribir de lo que no sabe..
Eliminarhttp://www.infotechnology.com/internet/Una-falla-de-Movistar-permitio-acceder-a-datos-privados-de-llamadas--20140415-0003.html
ResponderEliminar¡Genial!
EliminarNo se pude denunciar a la DNPDP? http://www.jus.gob.ar/datos-personales.aspx
ResponderEliminarBuen arranque del blog. Felicitaciones.
ResponderEliminarMe suscribo a ver qué otras cosas publicás.
¡Saludos!
Martín.
Gracias, ahora no puedo bajar el nivel =P
EliminarSigue funcando? recien intente y no pude :s
ResponderEliminarHola, 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!
ResponderEliminarMuy interesante, desde España no lo podemos comprobar, esperemos que lo reparen pronto.
ResponderEliminarSabiendo 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.
ResponderEliminarSon una bestias los de Movistar no pueden tardar tanto en solucionarlo.
ResponderEliminarPrimero 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
Probé también por POST y no anda, ya fue?
ResponderEliminarToma capo yo aporto otro fallo mas y van...
ResponderEliminarhttps://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
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...
EliminarExcelente post y buen comienzo. Sigan así.
ResponderEliminar¡Gracias!
Eliminarya lo arreglaron... y yo que queria hacer maldades
ResponderEliminarhttp://grooveshark.com/#!/s/Vamos+A+Portarnos+Mal/4O9oQo?src=5
EliminarEste comentario ha sido eliminado por el autor.
ResponderEliminar¿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¡Que loco!
EliminarAhora tenías que estar loggeado, quizás eso es lo que cambió.
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.
EliminarSí, o sino pueden agregar un hash para validar el request.
EliminarSupongo que saldrán con esto último porque es lo más fácil de implementar.
Yo no recuerdo si termine la secundaria creo que no, pero estudia loco. abrazo
ResponderEliminarSi 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.
ResponderEliminarUna, 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..
Error 500--Internal Server Error
ResponderEliminarFrom 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.