AutorMargarita Gil

Inicio/Artículos Publicados por Margarita Gil (Page 21)

Vulnerabilidad en SMB en Windows permite robo de credenciales

En la Conferencia Black Hat, un equipo de expertos liderado por Jonathan Brossard presentaron una vulnerabilidad en el protocolo SMB de Microsoft [PDF] utilizado para compartir archivos en redes locales. La vulnerabilidad afecta a todas las versiones de Windows, incluyendo Windows 10 y puede ser explotada a través de Internet, algo que los investigadores creían imposible.

SMB es un protocolo de 21 años de edad creado por IBM, que permite compartir archivos e impresoras en una red. Desde su creación, ha evolucionado y llegado a la versión 3.0, que se suministra ahora en la mayoría de los Windows. La mayoría de las veces este protocolo se utiliza en redes empresariales, junto al algoritmo de autenticación NTLMv2, que permite a los usuarios autentificarse rápidamente en servidores Windows.

La vulnerabilidad descubierta por el equipo de Brossard permite extraer las credenciales de usuario desde un dominio de Windows cerrado, utilizando una técnica de ataque llamada SMB Relay, basicamente un MitM para datos SMB. Mientras esta técnica generalmente trabajaba sólo en LAN, debido a que la mayoría de redes empresariales se han ampliado para incluir infraestructuras cloud, el ataque puede realizarse a través de conexiones a Internet.

La fuga de credenciales sucede cuando un usuario está tratando de leer un correo electrónico, acceder a una página Web utilizando el navegador o haciendo cualquier cosa que implique abrir una dirección URL. La vulnerabilidad se encuentra en una DLL específica que permite a un atacante realizar un ataque de retransmisión SMB, obtener las credenciales del usuario, romper el hash de la contraseña y luego utilizarlas para robar información de la red pasando como un usuario normal.

Como señala Brossard, todas las versiones de IE son vulnerables, incluyendo el nuevo navegador Edge, siendo este “el primer ataque contra Windows 10 y su navegador Spartan”.

Además, otras aplicaciones vulnerables incluyen Windows Media Player, Adobe Reader, Apple QuickTime, Excel 2010, Symantec Norton Security Scan, AVG Free, BitDefender Free Comodo Antivirus, IntelliJ IDEA, Box Sync, GitHub, TeamViewer, Dropbox y muchas otros aplicaciones.

La investigación también incluye técnicas de mitigación [PDF], pero según Brossard, el más eficiente sería definir configuraciones de Firewall personalizados, para prevenir fugas de datos a través de SMB.

Fuente: Segu.Info

Hackers han liberado toda la información robada de Ashley Madison

Hace un mes el sitio web Ashley Madison visitado por aquellos que buscan tener “aventuras” y citas a través del anonimato de Internet, fue comprometido cuando un grupo de hackers se hiciera con toda la información privada de más de 37 millones de usuarios. Desde base de datos de la empresa, a registros financieros, y datos personales de las personas registradas. Impact Team, como se hacen llamar los responsables por el hackeo, amenazaron con liberar los archivos si Ashley Madison no cerraba de inmediato y permanentemente.

Un archivo de alrededor de 10GB que presuntamente contiene correos electrónicos, perfiles de usuarios, transacciones con tarjeta de crédito, y otra información sensible apareció en las últimas horas de este martes disponible como una descarga en la Deep Web solamente accesible a través de Tor. Asumiendo que los archivos sean legítimos y haciendo caso a las amenazas recibidas, estaríamos frente a los registros de clientes, perfiles con fantasías sexuales secretas, las transacciones, nombres y direcciones reales, documentos de empleados y correos electrónicos.

Varios sitios como Wired y ARStechnica han podido descargar los archivos y se encuentran navegando a través de ellos para verificar su legitimidad y la extensión de la filtración.

 Fuente: Hipertextual

 

Se publica OpenSSH 7.0

OpenSSH es una variante abierta del protocolo SSH, que permite la conexión segura a equipos remotos, y llegó por primera vez al mundo *Nix en 1999, cuando fue implementado en OpenBSD 2.6. Desde entonces su adopción creció hasta el 100 por ciento puesto que todas las distros de Linux la implementan en la actualidad, aún cuando SSH liberó su código fuente luego del éxito de esta variante abierta.

Como herramienta de comunicación y de seguridad, es esencial mantenerla siempre actualizada y por eso es importante destacar que hace pocas horas se produjo la llegada de OpenSSH 7.0. Una versión que trae numerosas mejoras y actualizaciones de seguridad, a la vez que comienza a recorrer el camino hacia versiones futuras y próximas en las cuales algunos elementos irán cambiando y por ello se ofrece importante información al respecto.

Una de las cuestiones que se modifican respecto a versiones anteriores de OpenSSH es la de la opción PermitRootLogin, que ha sido cambiada de “yes” a “prohibit-password”, con lo cual únicamente podremos loguearnos como root si tenemos una clave SSH instalada en el servidor, eliminando el ingreso de contraseña por teclado y con ello aumentando muchísimo nuestra seguridad. Se ha eliminado el soporte para SSH versión 1, ya completamente obsoleto a estas alturas, y también sucede lo propio con el formato de certificados V00, que estaba hasta ahora por cuestiones de retrocompatibilidad.

Luego se mejora la compatibilidad para Portable OpenSSH y se corrigen varios bugs, y entre los cambios que se irán implementando en las próximas versiones podemos mencionar la eliminación de las claves RSA de menos de 1024 bits (cabe destacar que el mínimo actual es de 768 bits), y algunos cifrados que serán eliminados por defecto como es el caso de Blowfish-CBC, Cast128-CBC, Rijndael-CBC para AES y todas las variantes de ARCfour.

Fuente: Segu.Info

Hackean sistema de seguimiento de tobilleras de arresto domiciliario

Las tobilleras de seguimiento, que algunos delincuentes se ven obligados a usar después de haber sido sentenciados, han sido hackeadas en una de las conferencias de DefCon, lo que permitiría salir de la casa a un delincuente sin que nadie se percate del hecho.

El investigador de seguridad William “Amm0nRa” Turner demostró como la tobillera, fabricada por la compañía Taiwanesea GWG International, puede ser manipulada después de conseguir una muestra a través del uso de ingeniería social contra la empresa.

Los sistemas de seguimiento más antiguos funcionan sobre líneas telefónicas y utilizan frecuencias de radio de proximidad con la tobillera. Los elementos de GWG utilizan GPS y frecuencias de radio de corto alcance para determinar la ubicación del usuario y una red celular para enviar esa información al sistema central de monitoreo.

Amm0nRa logró eludir la protección colocando la pulsera dentro de una jaula de Faraday, envolviendo la tobillera en papel aluminio (U$S 2), para bloquear la señal real y hacer que la pulsera se conectase a una red rogue, creada por él mismo. Esto le permitió captar el mensaje de advertencia que el dispositivo envía a la policía en caso de que la pulsera se abra. Luego sacó la tarjeta SIM del dispositivo, la puso en su teléfono y envió un mensaje a otro teléfono para averiguar el número asociado a la tarjeta SIM. Con esa información, fue capaz de usar un servicio online SMS Spoofin para enviar un mensaje falso, especialmente diseñado y que informa a la policía que el delincuente está todavía en su casa.

Turner estuvo probando en un dispositivo particular, pero dice que hay muchos que funcionan de manera similar y tienen probablemente la misma vulnerabilidad.

Lamentablemente Amm0nRa no informó de sus hallazgos a la empresa debido a las malas experiencias que tuvo cuando trató de reporte vulnerabilidades en el pasado. Se pueden conocer más detalles sobre su investigación en las diapositivas de su presentación.

Fuente: Segu.Info

Continuar leyendo

Vulnerabilidades de cross-site scripting en IBM Domino Web Server

IBM ha publicado actualizaciones destinadas a solucionar tres vulnerabilidades de cross-site scripting en IBM Domino Web Server 8.5.x y 9.0.x.

Se trata de tres vulnerabilidades de cross-site scripting en el servidor web de IBM Domino. En uno de los casos cuando se encuentra configurado para webmail (CVE-2015-1981), otro de los casos permitiría una redirección abierta (CVE-2015-2014) y un último fallo cuando la plantilla Domino Directory está disponible sobre http (CVE-2015-2015).

Como es habitual en estos casos el problema reside en una validación insuficiente de las entradas suministradas por el usuario. Un atacante remoto podría ejecutar código arbitrario HTML o script en el navegador del usuario en el contexto del sitio afectado. Esto podría permitir que el atacante accediera a información sensible basada en el navegador como cookies de autenticación y los datos presentados recientemente.

IBM ha publicado actualizaciones en IBM Domino 9.0.1 Fix Pack 4 y en Domino 8.5.3 Fix Pack 6 Interim Fix 8.

Para 9.0.1

http://www-01.ibm.com/support/docview.wss?uid=swg24037141

Para 8.5.3

http://www.ibm.com/support/docview.wss?uid=swg21663874

El cross-site scripting en la plantilla se corrigió en la versión Domino 9.0.0 de la plantilla Domino Directory (pubnames.ntf).

La vulnerabilidad de redirección abierta se ha corregido en Domino 8.5.3 Fix Pack 6 Interim Fix 9 y Domino 9.0.1 Fix Pack 4. Para habilitar la corrección se debe añadir la configuración de inicio (DominoValidateRedirectTo=1) en el notes.ini del servidor Domino.

Más información:

Security Bulletin: IBM Domino Web Server Cross-site Scripting Vulnerability (CVE-2015-1981)

http://www-01.ibm.com/support/docview.wss?uid=swg21959908

Security Bulletin: IBM Domino Web Server contains two vulnerabilities (CVE-2015-2014, CVE-2015-2015)

http://www-01.ibm.com/support/docview.wss?uid=swg21963016

Fuente: Hispasec

El futuro de la seguridad en Android pasa por Google Play Services

En medio de todo el lío de la seguridad en Android nadie parece dar con una solución definitiva para este problema pero, ¿y si ya hubiera una solución? ¿Y si Google Play Services fuera la respuesta a todos los problemas en Android?

GooglePlayServices

Las dos últimas semanas para Android no han sido las más fáciles. Desde la grave vulnerabilidad de Stagefright a otra descubierta dos días después, para finalmente rematar con un descuido de seguridad con nuestra huella dactilar por parte de los fabricantes, el sistema operativo de Google ha sido puesta en evidencia por su fallos de seguridad. Y lo peor es que no parece haber una solución, no sólo para este caso, sino para la seguridad en Android en general.

Sí, es cierto que el caso de Stagefright ha sido algo beneficioso para Android, pero ya lo dijo Ron Amadeo: el Armageddon de seguridad en Android puede llegar cualquier día, y la preparación tanto por parte de Google como por los OEM es muy insuficiente. Lo de que Google pase los updates a los fabricantes y esperemos semanas e incluso meses a que lleguen es algo inadmisible, y si éstos últimos no van a hacer nada para mejorar esta situación Google ha de tomar los mandos, y quizás tenga la solución para todo desde hace tiempo en sus filas: Google Play Services.

Google Play Services ya es utilizado para que los servicios de Google funcionen en cualquier dispositivo sin importar su versión pero, ¿y si se puede estirar más su funcionalidad?
Fuente: Bloomua I Shutterstock.

Sin ponernos demasiado técnicos, la función de Google Play Services es simple pero tremendamente útil: permite un acceso total a las APIs de Google entre aplicaciones para que, sin importar la versión de Android que posea el usuario, Play Services sirva como puente entre una aplicación y una API de Maps, Localización, Drive, entre muchas otras. Sin embargo, lo verdaderamente importante de Google Play Services es su alcance: entre un 95 y un 99% de dispositivos con Android tiene instalado Google Play Services, desde Android 2.2 Froyo hasta 5.1 Lollipop, la versión más reciente.

Obviamente, nos referimos únicamente a aquellos que usan Android con los servicios de Google, por lo que forks como el de Amazon quedan fuera de este grupo de dispositivos. Por eso, aunque no cuentes con las novedades de Android per se si cuentas con una versión antigua, podrás disfrutar de todas las APIs de Google, lo que también beneficia a Google al haber más gente que utiliza sus productos. Pero ¿y si se le pudiera dar más poder a Google Play Services? ¿Y si se pudiera utilizar el alcance de esta aplicación no sólo para mejorar el ecosistema de Android, sino para mejorar su seguridad?

Imaginemos una situación hipotética pero plausible: una nueva vulnerabilidad embebida en el sistema en sí, extendida a todas las versiones de Android. Google podría coger simplemente deslizar una nueva actualización de Google Play Services a través del Play Store que incluyera un fix para este exploit, y dejar que la aplicación se ocupara del resto sin tener que dar cuentas a los fabricantes, incapaces de hacer llegar una actualización a todos sus dispositivos, incluyendo los antiguos y ya abandonados. Sería algo rápido, seguro y sobre todo, con un alcance amplio, algo muy demandado a Android, la cual deja (o dejaba) a dispositivos con tres años a su merced en cuestiones de seguridad.

El problema no es la seguridad en Android per se, sino en hacer llegar lasupdates cuando lo necesitan: lo antes posible.Por supuesto, esta solución es puramente teórica y puede ser que incluso insuficiente: quizás haya algún exploit imposible de corregir mediante este método, por lo que se tendría que buscar otro camino. También existe el riesgo de que, si se pudiera hacer entrar todo tipo de código en Android a través de Google Play Services, los desarrolladores de malware intenten explotar esta vía de entrada para hacer aún más daño al sistema operativo, por lo que Google Play Services debería estar “blindado” para que sólo Google introduzca modificaciones mediante esta vía, ya sea mediante una forma de identificación que sólo Google pudiera emitir o algo similar.

Esto nos deja con otro tema preocupante: si Google puede introducir cualquier tipo de dato en mi dispositivo Android, por definición también se podría sacar datos, algo que puede dejar aún más en evidencia a Google a la hora de respetar la privacidad de los datos, por lo que Google Play Services no sería una solución definitiva. Sea como fuere, una cosa está clara: la situación de seguridad de Android tiene que ser corregida de inmediato y, en el caso de que Google pudiera convertir en realidad lo de Google Play Services, ya fuera mediante permisos root o incluyéndolo directamente en la raíz de Android, puede ahorrar a la compañía de Mountain View muchos quebraderos de cabeza. Ahora es cuestión de llevarlo a la práctica.

Fuente: Hipertextual

¿Cómo fue el hackeo más grande de la historia a Saudí Aramco?

En el 2012, Saudí Aramco sufrió el peor hackeo de la historia mundial y, por primera vez, estamos conociendo nuevos detalles acerca del monstruoso ataque cibernético contra una de las compañías de petróleo más grandes del mundo.

En cuestión de horas, 35.000 computadoras fueron parcialmente limpiadas o totalmente destruidas. Sin una forma de compensarlos, los camiones cisterna de gasolina que necesitaban volverse a llenar tuvieron que darse la vuelta. La capacidad de Saudí Aramco para proveer el 10% del petróleo del mundo, repentinamente estaba en riesgo.

Y una de las empresas más valiosas en la Tierra fue obligada a regresar a la tecnología de 1970 y hacer uso de máquinas de escribir y faxes.

Cuando se trata de simples costos, los recientes ciberataques contra Sony Pictures y el gobierno estadounidense palidecen en comparación.

La persona promedio nunca ha oído hablar de Saudí Aramco… o de este hackeo. Pero todos sentimos sus misteriosos retumbos.

Hasta ahora, poco de esto era de conocimiento público. Pero Chris Kubecka, una antigua asesora de seguridad de Saudí Aramco después del hackeo, le habló a CNNMoney sobre su experiencia. Ella le contó la historia antes de que el jueves hiciera una presentación de la historia en la conferencia Black Hat de hacking en Las Vegas.

CNNMoney le preguntó a Saudí Aramco a fin de confirmar la historia de Kubecka, pero la empresa no respondió cuando se solicitaron sus comentarios.

Alguien fue engañado

Todo comenzó en algún momento a mediados del 2012, recordó Kubecka. Uno de los técnicos de computación en el equipo de tecnología de la información de Saudí Aramco abrió un correo electrónico de estafa y presionó un enlace corrupto. Los hackers se habían infiltrado.

El ataque real se inició durante el mes sagrado islámico de Ramadán, cuando la mayoría de los empleados de Saudí Aramco estaban de vacaciones. En la mañana del miércoles 15 de agosto del 2012, los pocos empleados presentes notaron que sus computadoras estaban actuando de manera extraña. Las pantallas comenzaron a parpadear. Los archivos comenzaron a desaparecer. Algunas computadoras simplemente se apagaron sin explicación alguna.

Esa mañana, un grupo autodenominado “Cutting Sword of Justice” (La espada cortante de la justicia) seatribuyó la responsabilidad, haciendo mención del apoyo de Aramco a favor del régimen autoritario de la familia real Al Saud.

“Esta es una advertencia a los tiranos de este y de otros países que patrocinan tales desastres criminales con injusticia y opresión”, manifestó el grupo.

La compañía se queda sin conexión

En una frenética carrera, los técnicos de computación de Saudí Aramco arrancaron los cables que se conectaban a los servidores en los centros de información alrededor de todo el mundo. Cada oficina quedó físicamente desconectada del Internet para evitar que el virus se propagara todavía más.

La producción de petróleo se mantuvo estable en 9,5 millones de barriles por día, según los registros de la compañía que CNNMoney tuvo a la vista. La perforación, el bombeo… todo eso era automatizado, explicó Kubecka. Pero el resto de la empresa estaba en crisis.

Se vieron obligados a manejar todo la gestión de los suministros, el transporte, los contratos con los gobiernos y con los socios de negocios en papel.

Sin Internet en la oficina, el correo electrónico corporativo era inexistente. Los teléfonos de la oficina estaban muertos. Los empleados escribían los informes en máquinas de escribir. Los contratos se distribuían a través del correo interno. Las negociaciones extensas y lucrativas que necesitaban firmas eran enviadas por fax, hoja por hoja.

La compañía temporalmente dejó de venderle petróleo a camiones cisterna locales. Después de 17 días, la empresa cedió y empezó a regalar el petróleo para que continuara fluyendo dentro de Arabia Saudita.

Kubecka, quien vive en los Países Bajos, fue contratada como consultora independiente para ayudar a asegurar todas las oficinas satélite de Saudí Aramco en África, Europa y Oriente Medio.

“Era un ejército masivo de personas de tecnología de la información. Nunca había visto algo así en mi vida”, dijo Kubecka.

El gigante corporativo también flexionó su músculo. Mandó por avión a los representantes directamente a las fábricas de computadoras en el Sudeste de Asia para comprar todos los discos duros para computadora que estuvieran en ese momento en la línea de fabricación. De un solo golpe, compró 50.000 unidades de disco duro. Kubecka dijo que la compañía pagó precios más altos para colarse en la línea de producción de todas las compañías de computadoras en el mundo… provocando que se detuvieran temporalmente los suministros de discos duros para todos los demás. Los suministros mundiales de discos duros que ya se habían retrasado debido a las inundaciones en Tailandia quedaron incluso más restringidos.

“Todo el que compró una computadora o un disco duro de septiembre del 2012 a enero del 2013, tuvo que pagar un precio ligeramente superior por su unidad de disco duro”, dijo Kubecka.

Cinco meses más tarde, con una nueva red de computadoras salvaguardadas y un extenso equipo de seguridad cibernética, Saudí Aramco nuevamente dejó su sistema en línea. Un ataque de esa magnitud fácilmente habría dejado en bancarrota a una empresa más pequeña, dijo Kubecka.

Los hackers, según lo que nosotros sabemos, nunca fueron identificados ni atrapados.

Fuente: Segu.Info