Archivo
Vulnerabilidad en SUDO permite escalamiento de privilegios en Mac OS
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.
Malware afecta a Macs que ejecutan “viejas” versiones de OS X
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
Se ha confirmado la existencia de una vulnerabilidad en Apple Remote Desktop. Podría permitir a usuarios maliciosos acceder a información sensible.
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.
Falla la seguridad de Apple y Amazon: hora de un cambio
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
-
El fallo CVE-2012-0507, corregido el 14 de febrero por Oracle, permite la ejecución de código. Desde entonces, se ha usado para el malware de la policía, los últimos Zbot,SpyEye… y para la botnet de Mac OS X recientemente destapada. Desde el 25 de marzo además, la vulnerabilidad se incorporó a varios kits de explotación usados por atacantes, como Blackhole, de los más completos y sofisticados actualmente. Contra esta vulnerabilidad además, no son efectivos ASLR, DEP o incluso otras técnicas anti-ROP (para evitar que los atacantes eludan esas medidas en sus exploits).
- CVE-2012-1723. La sucesora de la anterior. Solucionada el 12 de junio por Oracle. Más compleja de ofuscar por los atacantes y diferente, puesto que se trata de un problema en la implementación de la propia JRE.
Rakshasa: un rootkit permanente para hardware
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
Hackers en la red 
