Categoría: Seguridad

Falla de seguridad en iPhone expone información del usuario

El iPhone no deja de estar en las noticias, el día de hoy (27 de agosto) en Gizmodo hay un post con video incluído que detalla lo sencillo que resulta para cualquiera tener acceso a la información privada del usuario (contactos, e-mails, SMS), incluso si el iPhone ésta protegido con un password. El problema se presenta para aquellos usuarios que han actualizado a la última versión del iPhone 2.0.2, que arreglaba algunos problemas, pero ha introducido esta tremenda vulnerabilidad.

La forma de "hackear" el iPhone es muy sencilla, no requiere chips, ni complicados procedimientos, aquí la explicación del procedimiento:

  1. Entre en el modo de "desbloqueo" (unlocked), aquí les preguntará por el password.
  2. En lugar de introducir un password hay que precionar "Llamada de emergencia" (Emergency Call).
  3. Cuándo aparece el dial para hacer la llamada de emergencia (911 en USA), se hace doble click en Home.
  4. El teléfono cambia a la lista de contactos del usuario desde donde se pueden hacer llamadas a cualquier contacto, acceder al historial de llamadas, chequear el voicemail del usuario y hasta leer los SMS.

Cómo si lo anterior no fuera suficientemente malo, aquí algo peor, si se presiona la flecha azul al costado de los nombres de los contactos, esto da acceso total a información privada en las entradas de favoritos, desde alli ya todo es posible:

  • Si se hace click en una dirección de correo, se accede a la aplicación de correo electrónico desde donde se pueden leer todos los correos enviados y recibidos por el usuario.
  • Si hay un URL en la información de contacto, o en un e-mail, y se hace doble click sobre ella, automáticamente esto abre Safari y se tiene acceso total a Internet.
  • Si se hace click en "send a message" en la lista de contactos, esto da full acceso al gestor de SMS, para leer mensajes enviados e incluso enviar nuevos.

Ojalá que este importante problema de seguridad que afecta a la mayoría de usuarios de iPhone, exponiendo su información privada a cualquiera que tenga acceso al teléfono, se resolverá lo antes posible. Hasta entonces, puede evitar cualquier posible violación haciendo lo siguiente:

  • En el home (Inicio) del iPhone, vaya a Settings (Configuración).
  • Haga click en General.
  • Haga click en botón de Home (Inicio).
  • Haga click en cualquier boton ya sea "Home" o "iPod".

Y pensar que hay gente que ha gastado $200 sólo en adquirir el bicho éste y además se ha amarrado en un contrato de dos años con una tarifa mínima de $30 al mes (al menos ese es el caso de AT&T, aquí en USA), para que usarlo sea equivalente a una tortura. Así que hay dos opciones, una es que  los usuarios del iPhone son masoquistas, o la otra es que creen cualquier cosa que les dicen. Pero como decía mi abuelita "cuando hay plata, jeringa no mata", después de haber gastado $200 en el iPhone y haberlo presentado en sociedad, ¿quién va ha aceptar que metió la pata?




Nota: El video es cortesía de Gizmodo.

Publicado el por volkan68 0

Grave falla en el diseño del protocolo BGP podría colapsar Internet

Aunque no se ha hecho mucha propaganda sobre el asunto, la falla de diseño del protocolo BGP explotada por Alex Pilosov y Anton Kapela, que permite escuchar todo el tráfico de una red bajo la modalidad de man in the middle y que fuera motivo de su disertación en el último Defcon de Las Vegas, poco a poco comienza ha conocerse a través de los medios, al menos de los medios espacializados, porque justo el día de hoy (27 de agosto) he visto que Kim Zetter ha blogueado sobre el tema en los blogs de la revista Wired.

El asunto había pasado más o menos desapercibido hasta hace poco, eclipsado por el más publicitado problema con el protocolo DNS que fuera expuesto en el mismo evento por Dan Kaminsky y al cual le dedicáramos el post "Toda la verdad sobre la vulnerabilidad de los DNS". Pero como dice Peiter Zatko, éste problema con el protocolo BGP es mucho más grave que el de los DNS y tiene la capacidad de colapsar toda Internet en menos de 30 minutos si es convenientemente explotado. Pero antes de que la desesperación cunda, y los profetas del desastre comiencen a comentar sin saber de que se trata dedicare unas líneas de éste post a explicar cuál es el problema, por qué es un problema y bajo que condiciones puede aprovecharce esta devilidad del protocolo BGP.

En primer lugar hay que entender que el protocolo BGP está diseñado para permitir el ruteo de una "red" sobre multiples enlaces, así si uno de los enlaces cae el tráfico puede ser re-enrutado por otro, para ello la "red" que se re-enruta debe poseer un ANS (Autonomous System Number), que es asignado por IANA, el protocolo BGP confía en que todo router que forma parte de este anillo de super-routers de proveedores de Internet, es confiable y enviará la información correcta sobre los enlaces y las redes asociadas a los mismos. Por diseño del protocolo se supone que todos los routers que usan el protocolo BGP diran la verdad. En el experimento conducido por Alex y Anton, lo que se hizo fue introducir una ruta falsa (haciendo un spoofing del IP real del router dueño de la red que se pretende secuestrar, creado una paquete BGP manipulado) y forzar a que todo el tráfico fuera re-enrutado a través del data center de Alex en New York, en el cuál la empresa donde trabajo tiene hosteado sus racks (dicho sea de paso conozco a Alex Pilosov personalmente). Ésto fue posible por dos cosas, primero el hecho de que Alex tiene acceso a un router BGP reconocido por todos los proveedores Internet, y segundo a que cuenta con bastante ancho de banda para que la nueva ruta no sea más costosa en términos de tiempo y sólo añada un salto más a la ruta original. Osea que cualquier aprendiz de brujo que crea que puede colapsar Internet desde su línea ADSL es tan fantacioso como aquel adolescente que creía que era cierto que desde un Altair 8800 se podía iniciar la tercera guerra mundial así como en la película "Juegos de Guerra". El protocolo tiene una falla sí, pero es explotable sólo desde un router que pertenezca a un proveedor de Internet importante.

En teoría un terrorista que tuviera acceso a uno de estos routers principales, podría enviar información de rutas ciclicas, que colapsarian el tráfico porque enviarian los paquetes a un loop sin fin entre una pareja o trio de routers, claro sólo hasta que se reinicie el router que esta confundiendo a los demás. Es sólo un ataque que teóricamente es posible, pero dado a que los routers BGP en Internet son sólo unos miles, es relativamente fácil detectar al culpable.

Es por ello que si quiere estar seguro de que la información que esta transmitiendo por Internet esta segura, y Alex no la está escuchando , use protocolos de encriptación como SSL, así si alguién esta escuchando el tráfico sus claves e información personal no viajara en texto claro. Así que concluyendo aunque la falla de diseño del protocolo lo expone a un ataque que podría afectar a millones de usuarios, éste ataque sólo puede realizarce desde un lugar específico, el cuál puede ser custodiado.

Publicado el por volkan68 0

Crackeando passwords en Windows XP/Vista

En la semana pasada mi buen amigo Juan Juarez me preguntó cómo podía crackear el password de una máquina con Windows Vista, ésto suele pasar cundo se olvida el password del administrador por diversas razones. Pero es el equivalente a dejar las llaves dentro del auto y haber cerrado todas las puertas, ciertamente es una posición bastante incómoda para un administrador de red, pero un problema sencillo de resolver con las herramientas apropiadas.

Hay básicamente dos soluciones posibles, una es sobre-escribir el password del administrador lo que comunmente se conoce como resetear el password, la otra posible solución es usando un diccionario de passwords encontrar el password sin necesidad de cambiarlo. Ambas soluciones son posibles usando estas herramientas Open Source o gratuitas (hay también soluciones propietarias por las que hay que pagar, pero no se discutirán aquí):

Ophcrak, ésta es una herramienta que nos permite encontrar el password (sus autores aseguran que tiene una eficiencia del 99%),  y permite descargar un LiveCD tanto para crackear los password de Windows Vista y XP, se basa en tablas de hashes LM y NTLM. Pueden descargarse versiones para correr desde Windows, pero es mejor usar el LiveCD que esta en Linux.

Offilne NT Password, ésta es una herramienta que resetea o borra el password de Windows Vista/XP, escribiendo sobre el archivo SAM, igualmente cuenta con un LiveCD que esta basado en Linux y reconoce un buén número de controladores SCSI, es igualmente una herramienta Open Source.

PCLoginNow, ésta es una herramienta para resetear/borrar el password de Windows XP/Vista escribiendo sobre el archivo SAM, no es Open Source, pero si es gratuita y viene en la forma de un LiveCD.

Así que si formas parte del grupo de los que olvidaron su password de administrador de un Windows XP/Vista o incluso Windows 2000/2003 (no lo he probado aún en 2008), puedes usar cualquiera de las herramientas arriba descritas. Sólo hay que descargar la imagen ISO, quemarla en un CD, bootear el PC que se desea resetear/crackear el password usando el CD que se ha creado y siguen las instrucciones.

Los linuxeros no tenemos ese problema, básicamente porque resetear el root password es mucho más sencillo en Linux, sólo se debe de arrancar en runlevel 1 y usar la herramienta "passwd". Y en el peor de los casos si el boot loader esta protegido con password, basta con arrancar con un LiveCD de cualquier distribución, montar la partición del sistema, luego correr el comando "chroot" sobre la partición que hemos montado y volver a ejecutar el comando "passwd" para la cuenta root y establecer el nuevo password.

Hay que tener en cuenta que cualquier solución de crackeo/reseteo de password de super usuario, tanto para Windows, Linux y Mac OSX, requiere que sea realizada localmente (osea en frente de la máquina), de alli que sea necesario la seguridad física de los equipos.

Publicado el por volkan68 0

Herramienta para hackear Gmail

Una herramienta que automáticamente roba los ID de sesiones no cifradas y permite usurpar una cuenta de correo Google se ha presentado a los hackers en la última conferencia Defcon en Las Vegas.

La semana pasada, Google presentó una nueva funcionalidad en Gmail que permite a los usuarios cambiar en forma permanente y el uso de SSL para cada acción relacionada con Gmail, y no sólo, la autenticación. Los usuarios que no activaron esa opción, ahora tienen una gran razón para hacerlo. Ya que Mike Perry, el autor de dicha herramienta esta planificando liberarla dentro de dos semanas.

Al acceder a Gmail, la página web envía una cookie (un archivo de texto claro) que contiene el ID de la sesión hacia el navegador. Este archivo hace posible que el sitio web pueda saber que usted está autenticado y mantenerlo conectado durante dos semanas, a menos que usted manualmente pulse la tecla para salir. Cuando usted cierra su sesion este cookie se elimina.

Aunque al acceder a Gmail se obliga a usar la autenticación a través del cifrado SSL (Secure Socket Layer), usted no está seguro, ya que vuelve a la forma regular después (sin cifrado) luego de la autenticación. Según Google este comportamiento fue escogido debido a los bajos de ancho de banda los usuarios, ya que las conexiones SSL son más lentas.

El problema radica en el hecho de que cada vez que accede a Gmail, incluso para ver una simple imagen, el navegador también envía la cookie al sitio web de Google. Esto hace posible que un atacante haga un sniffing (huela) de tráfico en la red para insertar una imagen que sirve el URL http://mail.google.com y fuerza al navegador a enviar el archivo del cookie, por lo tanto, obtener su período de sesiones de identificación. Una vez que esto sucede el atacante puede acceder a la cuenta sin la necesidad de una contraseña. Las personas que leen sus e-mail desde redes wifi (inalámbricas) públicas son más vulnerables a éste tipo de ataques que los que utilizan las redes cableadas.

Perry dijo que notificó a Google sobre esta situación hace más de un año y aunque Google ha hecho esta opción disponible (usar sesiones SSL), no está satisfecho con la falta de información. "Google no ha explicado por qué utilizar esta nueva función es tan importante", dijo. Perry explicó que las consecuencias de no informar a los usuarios son que: "Esto da a las personas que habitualmente acceder a Gmail con un URL que comienza con https: / /  un falso sentido de seguridad, porque piensan que están seguros aunque realmente no lo están. "

Si usted accede a su cuenta de Gmail desde distintos lugares y le gustaría beneficiarse de esta opción sólo cuando usted está usando redes sin garantía, puede forzarlo manualmente usando la siguiente dirección https://mail.google.com. Esto acceder a la versión de Gmail con SSL y será persistente durante todo su período de sesiones y no sólo durante el proceso de autenticación.

Nota: Traducido y adaptado de la versión original en inglés encontrada en hacking truths.

Publicado el por volkan68 0

Toda la verdad sobre la vulnerabilidad de los DNS

Desde hace un mes aproximadamente, se ha venido hablando en los foros y blog sobre la falla encontrada por Dan Kaminsky en el protocolo DNS, una falla que según los medios ha sido parchada con gran celeridad debido a la acción oportuna de Kaminsky de informar primero a todos los ISPs y entidades pertinentes para que el sistema sea parchado, antes de hacer público su descubrimiento; es más algunos lo pintan hasta comu un gran logro, lean la columna que escribió sobre el tema Dennis Fisher. Sin embargo el viernes pasado (8 de agosto), el investigador ruso Evgeniy Polyakov posteo en su blog, que había podido vulnerar exitosamente un servidor DNS que había sido parchado, la noticia fue recogida por el New York Times.

Entonces, ¿fue la falla fue más grave de lo que se pensaba?, ¿cuál es en realidad la falla?, ¿qué tan vulnerables son nuestros PCs a ésta falla?, y ¿cómo podrían usar dicha vulnerabilidad los cyberdelincuentes para sacar partido de ella?, son los puntos que trataremos de aclarar en el presente post.

En primer lugar debemos entender qué es y como funciona el servicio DNS en Internet, la mayoría creo que ya tiene claro que los servidores DNS son aquellos que transforman los nombres que usamos comunmente como www.google.com en un número IP, que es finalmente como la conexión es establecida, sin embargo lo que la mayoría no parece tener claro es que hay dos tipos de servidores DNS, uno es aquel que es dueño de una "zona" y otro es el servidor DNS de cacheo, son éstos últimos los que se ven afectados por éste tipo de ataques.

¿Qué es y para que sirve un servidor DNS de cacheo?, para poner las cosas claras, lo que la mayoría de nosotros usamos ya sea a través de nuestro ISP o uno configurado por nosotros mismos en nuestra LAN, es un servidor DNS de cacheo, es decir un servidor de nombres de dominio que pregunta a los servidores DNS dueños de una zona, por el IP de un nombre que estamos buscando, una vez obtiene ese valor, lo almacena en una memoria cache, por un tiempo estipulado por el servidor DNS dueño del dominio en un parámetro llamado TTL (Time To Live), usualmente horas (hay casos en que pueden ser días), antes de intentar volver a pedir el IP de un nombre de dominio nuevamente.

El mecanismo de ataque es el siguiente:

  1. Se envía una solicitud de un nombre específico  al servidor que sera víctima del ataque.
  2. Inmediatamente después se envían una serie de tramas UDP fraguadas, con la intención de hacerse pasar por la respuesta del verdadero servidor dueño del dominio.
  3. Verifica que la respuesta falsa ha sido aceptada por el servidor.
  4. El servidor atacado devolverá la IP inyectada por el atacante cada vez que se le pregunte por el nombre.

El ataque es posible porque el intercambio DNS es hecho usando el protocolo UDP, que no verifica el establecimiento de una sesión. Para complicar aún más las cosas no se puede tomar ninguna contra medida porque los paquetes UDP se hacen pasar como enviados por el verdadero servidor, sólo analizando la trama no hay forma de saber si viene del servidor legítimo.

Por otro lado no es práctico pasar las solicitudes DNS del protocolo UDP a TCP, porque sobrecargarían a los servidores raíz, así que la solución que se ha intentando es randomizar el puerto con el cuál se hace la solicitud al servidor dueño del dominio, aunque según ha demostrado Evgeniy Polyakov, con suficiente tiempo y ancho de banda, igual es posible corromper los registros de cualquier servidor DNS, incluso si esta parchado.

¿Cuál sería la solución entonces?, puesto que para lanzar un ataque exitoso se requiere que el equipo desde donde lancemos el ataque tenga una latencia menor a la que tendrían los paquetes enviados desde el servidor dueño del dominio, se necitan entonces dos cosas, primero bastante ancho de banda, y una cantidad de saltos menor al servidor que se trata de suplantar. Entonces la mejor forma de estar a salvo de éste tipo de ataques es implementar un servidor DNS dentro de nuestra LAN, de esa forma un ataque sólo sería posible si se realiza desde dentro de nuestra LAN, además de que le haríamos las cosas mucho más difíciles a los hackers porque en vez de infectar un sólo servidor DNS de cacheo en un ISP y afectar a miles o millones de usuarios, deberían de infectar miles de servidores, lo cuál consumiría su ancho de banda. Aunque no he visto que nadie formule ese tipo de soluciones.

¿Cómo un hacker aprovecharía esta vulnerabilidad para atacar a sus víctimas?, de por sí la única forma posible de capitalizar éstos ataques sería a través del fishing, por ejemplo inyectando resgistros como update.tubanco.com, y solicitando a la víctima que actualice su información, desde la perspectiva de los usuarios, incluso si hicieran un ping a update.tubanco.com, obtendrian el IP del servidor impostor, así que un cliente promedio podría caer fácilmente en el engaño.

Los que deseen saber si los servidores de nombres de dominio que estan usando son vulnerables a éste tipo de ataques (es decir no esta parchados), pueden saberlo usando el test que provee Kaminsky en su blog.

Aquellos que ésten interesados en probar un exploit de prueba de concepto, lo pueden hacer descargandolo desde milw0rm, hay versiones en C, Python y para el toolkit metasploit. Aunque les recomendaría que instalen un DNS de cacheo en su LAN para que el experimiento sea exitoso, porque usar líneas con 128 o 256 Kbps de subida como es el caso de la mayoría de líneas ADSL, no garantiza el éxito de la experiencia.

Espero que toda ésta información les haya resultado de utilidad, y despejado sus dudas sobre el "apocalipsis" que podría resultar de la corrupción de los DNS, como veran corromper un sólo registro de un servidor DNS de un ISP principal consume tantos recursos y ancho de banda, que éste tipo de ataques es poco práctico, a menos que se encuentre una forma de llevarlo acabo coordinadamente por redes zombie, pero eso no es para nada una tarea fácil, hay formas más rentables de crackear una red.

Publicado el por volkan68 0