Archivo

Archive for the ‘Mac OS’ Category

Vulnerabilidad en SUDO permite escalamiento de privilegios en Mac OS

agosto 29, 2013 Deja un comentario

Una vulnerabilidad en el proceso de autenticación de SUDO, reportado en marzo pasado, está ganando popularidad con el lanzamiento de un nuevo módulo de Metasploit que hace realmente fácil explotar dicha vulnerabilidad en Mac OS.

La vulnerabilidad identificada como CVE-2013-1775, consiste en saltar las restricciones de tiempo y mantener los privilegios administrativos, reajustando el reloj del sistema (UNIX Epoch) al 1 de enero de 1970. No se limita a OS X, y también se puede encontrar en 1.8.6p7 y 1.7.10p7.

Leer más…

Categorías:Mac OS, Noticias, Vulnerabilidades Etiquetas: ,

Malware afecta a Macs que ejecutan “viejas” versiones de OS X

agosto 28, 2012 Deja un comentario

El programa malicioso conocido como GetShell.A, requiere que se apruebe la instalación de un applet de Java. OS X, pero el sistema operativo advierte que se trata de un certificado raíz que “no es de confianza”.

Si aún así el usuario decide seguir adelante e instalar este applet, el dispositivo se infectará.

Según los analistas, lo “fascinante” del malware es que es multiplataforma, ya que una vez que se permite la instalación del applet, descarga un código específico de plataforma para Mac OS X, Linux y Windows y así intentar abrir una puerta trasera en el equipo.

Aquí está lo interesante – el código de OS X no se ejecutará sin Rosetta en una plataforma basada en Intel, ya que es un binario PowerPC.

Esto significa que cualquier Mac sin Rosetta, básicamente cualquier máquina que tenga Lion o Mountain Lion, es inmune al malware.

Más detalles en: Inteldig

Apple Remote Desktop no cifraba el tráfico aunque así estuviese marcado

agosto 26, 2012 Deja un comentario
Se ha confirmado la existencia de una vulnerabilidad en Apple Remote Desktop. Podría permitir a usuarios maliciosos acceder a información sensible.

Apple Remote Desktop es una herramienta para la gestión remota de equipos Mac, diseñada para la gestión de equipos en red. Es compatible con VNC y permite usarse como “visor” para otros servidores que funcionen como servidor VNC.

El problema (con CVE-2012-0681) se da porque, aun conectando a un servidor VNC de un tercero con la opción “Encrypt all network data” (cifrar todos los datos de red) activada, la información se envía sin cifrar. El programa tampoco alerta sobre el hecho de que los datos no serán cifrados.

Para evitar esto, se debe crear un túnel SSH para la conexión VNC. El problema fue introducido en la versión 3.5.2, de junio de este año, y se ha mantenido hasta la 3.6. Se recomienda la actualización a la versión 3.6.1.

Más información:
About the security content of Apple Remote Desktop 3.6.1
Antonio Ropero
Twitter: @aropero

Falla la seguridad de Apple y Amazon: hora de un cambio

agosto 24, 2012 Deja un comentario

Se le puede llamar “la experiencia de la falla de seguridad” para Amazon y Apple. El 3 de agosto pasado, un hackeo épico comprometió la cuenta de Twitter del periodista de tecnología Mat Honan. Al mismo tiempo, el atacante (conocido como Phobia) también se las ingenió para borrar de manera remota el contenido de la laptop, iPhone y iPad Apple de Honan.

Además, Phobia lo hizo por medio de métodos de ingeniería social, engañando a representantes de servicio a clientes de Amazon y Apple, lo que le permitió obtener información suficiente para accesar a las cuentas de iCloud y Gmail de Honan.

Es obvio que la habilidad del que se describe a sí mismo como un adolescente de 19 años de ejecutar un ataque de ingeniería social de múltiples niveles hace surgir la pregunta de quién más (agencias de inteligencia, criminales o legiones de adolescentes aburridos) pueden haber estado ya poniendo en operación estas técnicas, sin que las víctimas siquiera se dieran cuenta.

¿A quién culpar?
Si se busca culpar a alguien, se puede comenzar con el sistema de verificación de identidad que emplean los gigantes de la tecnología. “El sistema de Amazon tiene una falla parcial, pero el vínculo más débil es por mucho Apple”, dice Marco Arment, cofundador de Tumblr, en su blog. “Resulta atroz que den control de su cuenta en iCloud a cualquier persona que sepa su nombre y domicilio (lo que cualquiera puede averiguar muy fácilmente), y los últimos cuatro dígitos de su tarjeta de crédito (que en general se considera seguro mostrarlos en sitios Web y recibos)”.

Cuando se trata de hacer revisiones a consumidores, las empresas son perezosas. “A lo que se reduce esto es a la autenticación (¿cómo verifica que alguien es quien dice ser?). Ahora mismo, la norma de la industria señala que usted proporcione un poco de información personal”, dice en conversación telefónica el gerente de Inteligencia de Amenazas de Trustwave SpiderLabs, quien se presenta como Space Rogue. Para él, el problema es obvio: “Nada de eso es información secreta. Toda se consigue fácilmente por medio de Google o de otros métodos”

La falla de los equipos de seguridad de Amazon y Apple al no poder detectar (o molestarse por contemplar) de forma proactiva los ataques al estilo de Phobia es patente. (Se ha informado que ambas compañías están revaluando sus verificaciones y consecuencias.)

En la conferencia Black Hat Europa, realizada en Ámsterdam a principios de año, comprobadores de penetración describieron trabajos temporales en los cuales habían sido contratados por una empresa para identificar sus vulnerabilidades a la seguridad de la información.

En ocasiones encontraron las fallas esperadas en aplicaciones Web. Pero muy a menudo también hallaron literalmente puertas traseras sin llave a la oficina misma, además de impresiones de nombres de usuario, contraseñas u otra información confidencial indizada cuidadosamente en archiveros sin llave.

Comprobadores de penetración profesionales se habrían comido completitas a Amazon y Apple, dada la facilidad con la que se puede robar la identidad de los consumidores. “Las personas hacen esto todo el tiempo; no es un caso aislado lo que le sucedió a Honan”, dice Space Rogue, quien ayudó a fundar la destacada agencia de consultores @Stake, y quien ha trabajado antes para el ‘think tank’ (u organismo de políticas) L0pht Heavy Industries.

Usuarios flojos
Si las empresas son perezosas, también lo son los consumidores, y Honan admitió su culpabilidad en el ataque contra su identidad en línea. “Esos lapsos de seguridad son culpa mía, y en verdad me lamento por ellos”, escribió en un resumen de los ataques. No obstante, tras hacer esa declaración al principio de su artículo, Honan dedicó después 3,300 palabras a analizar lo que los demás, incluidos Amazon y Apple, hicieron mal.

Para reiterar: No hay que aprender de Honan. Él no hizo una copia de seguridad de sus dispositivos en un disco duro, a pesar de contar con el sorprendente software de respaldo “dispara y olvida” Time Machine, incluido con su laptop Apple con OS X. Además, utilizó prefijos de direcciones de correo electrónico idénticos (primer nombre, apellido) en numerosos servicios, lo que hizo que las direcciones de sus cuentas fueran fáciles de adivinar para un atacante. Y vinculó numerosas cuentas unas con otras, creando con ello un punto de falla único.

Honan es difícilmente la primera persona con conocimientos técnicos que comete este tipo de errores. El acusado de LulzSec y participante de Anonymous, Donncha O’Cearrbhail, afirmó haber comprometido el AppleID del principal investigador del crimen cibernético de Irlanda. Como el policía re-enviaba también sus correos de trabajo a una cuenta de Gmail que había configurado en su iPhone para revisarla, O’Cearrbhail pudo escuchar a escondidas una conferencia telefónica entre el FBI y agencias internacionales de procuración de justicia.

Por desgracia, cuando se trata de proteger los estilos de vida cada vez más conectados de las personas, no hay respuestas fáciles. “Las personas desean aprovechar la tecnología para facilitar sus vidas, de modo que vinculan todas estas cuentas entre sí, y al hacerlo las pone en riesgo”, señala Space Rogue. “¿Es culpa de las compañías IT, por permitir a las personas hacer esto, o es culpa de las personas? Esto es algo con lo que la sociedad tendrá que lidiar conforme pase el tiempo.”

Por fortuna, la historia aleccionadora de Honan (y el excelente análisis de cómo fue hackeada su vida, que Phobia hizo posible al contarlo, a cambio de la garantía de que Honan no lo demandara) ha puesto este problema bajo el reflector central.

Quien llege a sufrir una desgracia similar no debe esperar el trato con guantes blancos que obtuvo Honan, el cual incluyó el trabajo de Apple para recuperar los archivos que fueron eliminados de manera remota de su disco duro. “La víctima aquí es un conocido periodista de tecnología, de modo que obtuvo el nivel de soporte técnico del cual no disponemos la mayoría de nosotros”, sentencia Bruce Schneier, director IT de seguridad de BT, en una publicación en el blog. “Creo que esto será cada vez un problema más grande, y que los proveedores de servicios de Nube necesitarán soluciones mejores y más automatizadas.”

¿Qué aspecto podrían tener estas soluciones de seguridad mejoradas? Como se ha dicho, Apple y Amazon pueden comenzar al menos ofreciendo autenticación bifactorial. Dado que ambas compañías ganan mucho dinero operando tiendas de aplicaciones para smartphones y cuentan con esos canales de distribución, crear una aplicación bifactorial para teléfonos inteligentes será un próximo paso natural. O simplemente podrían usar la aplicación para smartphones de Google.

Mientras tanto, conviene someter a interrogatorio a quienes deseen llamar al servicio a clientes para restablecer una contraseña, pero que (al igual que Phobia cuando contactó a Apple) carecen de las respuestas a las preguntas de seguridad archivadas. Por ejemplo, después de permitir que un usuario solicite restablecer una contraseña por vía telefónica, ¿por qué no “hacer que la persona vuelva a llamar al día siguiente?”, propone Marco Arment, cofundador de Tumblr: “Si olvida su contraseña y las respuestas a sus preguntas de seguridad, no es irracional esperar un poco de incomodidad”, en especial si no desea ver su vida digital comprometida por un atacante con conocimientos de ingeniería social.

Fuente: Information Week

Si no actualizas Java, estás infectado

agosto 8, 2012 Deja un comentario
Los applets de Java, unidos a una máquina virtual JRE vulnerable, son hoy por hoy la combinación perfecta para que los atacantes infecten a sus víctimas. No importa qué hábitos se sigan en el sistema: no tener actualizado JRE, es garantía de infección. Veamos por qué y cómo protegerse.
En nuestro laboratorio realizamos habitualmente análisis forenses a máquinas infectadas con troyanos bancarios. Así podemos detectar el binario, aislarlo y estudiar su comportamiento.
De esta manera comprobamos cómo y con qué se infecta la gente ahí fuera, en el mundo real donde el malware limpia las cuentas bancarias de los usuarios (una media de 3.000 euros por robo).
Entre otros descubrimientos, en los últimos meses,  hemos comprobado que en el 100% de los análisis realizados (y no han sido pocos) la razón de la infección con troyanos bancarios era una máquina virtual Java desactualizada. En concreto dos vulnerabilidades (aunque también otras más antiguas):

 

Cómo suele funcionar el exploit
La víctima visita cualquier web. Cualquiera: desde páginas pornográficas hasta webs de ganchillo (ejemplos reales). No importa el navegador. De forma más o menos transparente (según el navegador) se carga el applet que explota la vulnerabilidad. El usuario quedará infectado. Una curiosidad es que el código Java se encargará de descargar “a trozos” un ejecutable que ensambla en local. También, que el ejecutable será “único” para la víctima. Aunque su funcionalidad sea la de intentar robar las credenciales del banco, su “hash” o firma será diferente en cada caso, y no funcionará en otra máquina que no sea la que ha infectado. Una especie de poliformismo del lado del servidor pero “en tiempo de ensamblado en local“.
Por si fuera poco, el malware no necesita de privilegios de administrador para funcionar. Se instala en %appdata%, dentro de un directorio con nombres aleatorios donde suele tener permisos de escritura, y se asegura la supervivencia posicionándose en la rama del registro del usuario CurrenVersion\Run donde también puede escribir.
¿Qué hace mal Oracle?
Oracle no es un buen ejemplo en el campo de la gestión de seguridad. Sun tampoco lo era (la compró en abril de 2009). Por ejemplo, tuvimos que esperar a finales de 2008 para que Sun hiciera algo muy simple: desinstalar las versiones vulnerables cuando un usuario se actualizaba. Sí, dejaban en el sistema la versión vulnerable dentro de la misma rama.
Pero el problema es que en cierta medida, Oracle sigue haciéndolo. Si bien dentro de la misma rama se borran las anteriores… no se eliminan, ni se actualizan, ramas anteriores. Muchos usuarios se encuentran en este momento con dos ramas de JRE en su sistema. La 6 (que va por su update 33), y la 7 (que va por su update 5). Conservar alguna anterior es más que arriesgado. Por ejemplo si con la rama 6 update 18 (arcaica) el usuario decide instalar la última versión 7 update 5 desde la web oficial, se encontrará con esto:
No solo no se elimina la rama 6, sino que tampoco se actualiza de la 18 a la última 33. Ni siquiera advierte del peligro de mantener esa rama. Y lo que es peor… los dos serán accesibles para el atacante desde el navegador.
Oracle tampoco se ha pasado a la “autoactualización“, a la que se ha visto obligada Adobe con su Flash recientemente. Primero permitía a los usuarios que se actualizasen libremente. Luego mejoró, con  un mensaje claro cuando aparecía una nueva versión (y en este estadio se encuentra Oracle). Pero más tarde se ha visto obligado a actualizar, sí o sí por defecto, y despreocupar al usuario. Oracle no quiere hacer eso. Tiene pánico a que los diferentes programas no funcionen en sus muchas ramas (todavía actualiza la rama 1.4).
Tal es el problema, que Firefox, Chrome e incluso Safari, bloquean las versiones antiguas de Java, para evitar más infecciones.
Protección
Las medidas de protección son las de siempre… más alguna otra. Por ejemplo, son varios los profesionales como Brian Krebs o Larry Seltzer que directamente aconsejan desinstalar Java por completo. Ambos alegan que no se echará de menos. Esto es discutible y depende del perfil de cada usuario. Pero sí es cierto que, al menos, se debe evitar que sea accesible desde el navegador. Existen varias páginas que ofrecen instrucciones para deshabilitarlo (independientemente del navegador) para Windows y Mac.
Otros métodos de protección incluyen, según el navegador, evitar los applets en páginas desconocidas, o directamente evitar el JavaScript selectivamente.
Más información:
Don’t Need Java? Junk It.
Java (por fin) eliminará las versiones antiguas al actualizar
How to protect yourself from Java-based malware
Ditching Java might be a good move
A Month Without Java: The Results
Sergio de los Santos
Twitter: @ssantosv
Fuente: Hispasec

Rakshasa: un rootkit permanente para hardware

agosto 3, 2012 Deja un comentario

Jonathan Brossard, de la firma francesa de seguridad Toucan System, ha presentado en BlackHat y Defcon un malware capaz de tomar el control de la BIOS de al menos 100 motherboards [PDF].

El malware es indetectable en el BIOS y la única forma de eliminarlo sería volver a actualizar el BIOS y, si además, los dispositivos periféricos también están infectados, podrían volver a infectar a la placa base. La única manera de garantizar la limpieza de un sistema infectado sería volver a actualizar tanto la placa base y todos los periféricos, al mismo tiempo, algo claramente más allá del usuario promedio.

Dado que el malware se encuentra en, o sustituye el BIOS, el malware tiene el control sobre el equipo antes de que el sistema operativo se cargue. Todo lo que es parte del sistema operativo puede ser controlado, el cifrado puede apagarse mientras el usuario cree que que está funcionando, el firewall puede ser traspasado y el software antivirus no tiene sentido.

En esencia es indetectable, ya que no deja ninguna huella en los archivos, en el disco duro o en memoria, a diferencia de otros programas maliciosos como los bootkits que se almacenan en la Master Boot Record (MBR) y en consecuencia eran fáciles de detectar. Rakshasa descarga el bootkit en memoria RAM cada vez que se inicia el equipo y luego se elimina de la memoria RAM sin dejar rastro alguno.

Si bien este no es primer acercamiento al tema y el virus CIH ya fue capaz de infectar un BIOS en 1998, esta nueva prueba de concepto abarcaría mayor cantidad de fabricantes y podría suponer una nueva etapa en el diseño de malware.

Fuente: http://blog.segu-info.com.ar/2012/08/rakshasa-un-rootkit-permanente-para.html