Una simple vulnerabilidad en telnetd de FreeBSD permite elevar privilegios

Se ha encontrado un fallo en el servidor telnet de FreeBSD que podría permitir a un atacante remoto ejecutar código como root. Aunque el servicio telnet no sea de los más usados hoy en día, se trata de una grave vulnerabilidad generada por un error del equipo de programación de FreeBSD. Recuerda a un fallo muy parecido que sufrió Sun Solaris hace ahora dos años.

FreeBSD es un sistema operativo OpenSource gratuito y de alta calidad, perteneciente a la familia *BSD, como NetBSD u OpenBSD. Está creado con la seguridad como prioridad desde un principio, y con su configuración por defecto, resulta uno de los sistemas operativos más seguros.

El problema encontrado recientemente en el demonio telnet (telnetd) permite a un atacante realizar un ataque basado en variables de entorno. Aunque el demonio limpia las variables de entorno antes de permitir una conexión, cambios recientes en FreeBSD han hecho que esta limpieza no sirva realmente, sin que se hayan percatado los programadores. Por tanto, por ejemplo es posible compilar una librería que cambie el valor de la variable de entorno LD_PRELOAD, y hacer una conexión al demonio telnet usándola (cargando la librería en la llamada). Como no será correctamente filtrada, la cargará y el atacante podrá obtener una shell con privilegios de root (que normalmente ejecuta el demonio telnetd). Aunque el ataque en esencia permite elevación de privilegios local, si además tiene la posibilidad de “subir” a través de cualquier medio esa librería creada a la máquina víctima, el ataque puede realizarse en remoto.

Telnet no es un servicio muy usado hoy en día, por carecer totalmente de mecanismos de seguridad integrados. Aunque hace años se usaba para administrar las máquinas, hoy en día ha quedado relegado por la conexión cifrada y autenticada SSH. Sin embargo, este es uno de los errores más “claros” y sencillos de explotar cometidos por FreeBSD en los últimos años.

Se recomienda seguir los enlaces en el apartado de “más información” para conocer cómo solucionar el problema.

Recuerda a un error cometido por Sun Solaris en febrero de 2007. Se dio a conocer una vulnerabilidad en Sun Solaris 10 tan simple como sorprendente. El fallo permitía el acceso trivial como cualquier usuario (incluido root) también a través de telnet. Sin necesidad de conocimientos especiales, sin shellcode ni exploits, el fallo rozaba lo vergonzosamente simple. La vulnerabilidad fue ya descubierta y corregida en sistemas UNIX en 1994, aunque se reprodujo por error de nuevo en 2002 hasta que fue “redescubierta” en 2007.

FreeBSD-SA-09:05.telnetd Security Advisory

http://security.freebsd.org/advisories/FreeBSD-SA-09:05.telnetd.asc

14/02/2007 Sun Solaris vuelve a sorprender resucitando una vulnerabilidad “histórica”

http://www.hispasec.com/unaaldia/3035

Sergio de los Santos
[email protected]

Fuente: Hispasec

Chrome, Firefox vulnerables al clickjacking

Investigadores de seguridad han descubierto una falla que afecta a navegador Chrome de Google que lo expone al ‘secuestro de clic’ o clickjacking – donde un atacante secuestra funciones del navegador reemplazando enlaces legítimos por otros elegidos por el atacante.

Google ha reconocido la falla y está trabajando para emparchar las versiones de Chrome 1.0.154.43 y anteriores cuando corren en sistemas Windows XP SP 2, según el investigador de seguridad de SecNiche Aditya K Sood.

Sood divulgó la falla el 27 de enero y entonces publicó una prueba de concepto en el foro de divulgación de vulnerabilidades de Bugtraq.

“Los atacantes pueden engañar a los usuarios para realizar acciones que los usuarios nunca quisieron hacer y no hay manera de ubicar luego esas acciones, una vez que el usuario se autentificó en la otra página,” dice Sood en su nota de divulgación.

Mientras Google está trabajando en un arreglo, un portavoz de la compañía en Australia señaló que el clickjacking afecta a todos los navegadores, no solo al Chrome.

“El problema [clickjacking] está ligado con la formar de trabajar en que la web y las páginas web fueron diseñadas, y entonces no hay un arreglo sencillo para ningún navegador en particular. Estamos trabajando con otros jugadores para llegar a una forma de enfoque de la mitigación de largo plazo estandarizada,” dijo.

Sin embargo, el investigador independiente, CEO de la consultora australiana de seguridad Novologica, Nishad Herath, le dijo a ZDNet.com.au que después de correr la prueba de conepto de Sood encontraron que el Internet Explorer 8 (versiones release candidate 1 y beta 2) y el Opera 9.63 (la ultima versión) no estaban expuestos a la falla. Pero, tal como el Chrome, el Firefox 3.0.5 también está expuesto.

Los investigadores de seguridad de Google no han encontrado ningún ataque de esta vulnerabilidad específica que esté siendo explotado de forma activa, dijo el portavoz de Google.

El clickjacking es un ataque al navegador relativamente nuevo que los investigadores Robert Hansen y Jeremiah Grossman presentaron a finales del año pasado en la conferencia de seguridad OWASP en Nueva York. El ataque encaja perfectamente dentro de la categoría de falsificaciones XSS, en donde un atacante usa maliciosamente código preparado de HTML o de JavaScript que fuerza al navegador de la víctima para enviar requerimientos HTTP a un sitio de su elección.

“El clickjacking significa que cualquier interacción que uno tenga con un sitio web en el que esté por ejemplo cuando hace clic en un enlace, puede no hacer lo que uno esperaba,” explicó Herath.

“Podría hacer clic en un enlace que parece que apunta a una imagen de Flickr, pero en realidad, primero lo dirigirá a un servidor de descarga conducida (drive-by-download) que contiene malware. Este tipo de ataques pueden ser usados cuando se interactúa con servicios web en los que uno ya se ha validado de formas en las que uno nunca hubiera querido, sin siquiera uno sabe que sucedió eso.”

Traducido para blog de Segu-info por Raúl Batista
Autor: Liam Tung de ZDNet Australia
Fuente: www.zdnet.com.au

Más información
Clickjacking: Investigadores alertan por vulnerabilidad que afecta a todos los navegadores
¿Clickjacking con Firefox y NoScript instalado?
Protección contra ClickJacking en navegadores
ClickJacking, nueva técnica de ataque a través de navegadores web

Apple soluciona ocho problemas de seguridad en QuickTime

Apple ha publicado una nueva versión de QuickTime (la 7.6), que solventa siete problemas de seguridad en sus versiones para Windows y OS X (Leopard y Tiger). Además se ha publicado un boletín de seguridad adicional para solucionar un fallo en el componente MPEG-2 de QuickTime Media Player para Windows, aunque éste no viene instalado por defecto.

A continuación se detallan las siete las vulnerabilidades solventadas en la nueva versión Quicktime 7.6:

* Denegación de servicio y posible ejecución remota de código causada por un desbordamiento de búfer basado en heap al intentar procesar un objeto multimedia apuntado por una URL RTSP (Real Time Streaming Protocol).

* Ejecución remota de código al aprovecharse de un desbordamiento de búfer basado en heap provocado por el tratamiento erróneo de átomos THKD en un archivo de vídeo QTVR (QuickTime Virtual Reality) especialmente manipulado.

* Denegación de servicio o ejecución remota de código arbitrario a través de archivos AVI especialmente manipulados, que podrían causar un desbordamiento de búfer basado en heap.

* Otro desbordamiento de búfer, debido a un manejo incorrecto de archivos MPEG-2 con contenido de audio en formato MP3, que podría ser aprovechado por un atacante remoto para causar una denegación de servicio o ejecutar código arbitrario.

* Denegación de servicio o ejecución remota de código causada por un fallo de corrupción de memoria en Quicktime al manejar los archivos de vídeo codificados con H.263.

* Desbordamiento de búfer basado en heap que podría ser aprovechado por un atacante remoto para ejecutar código arbitrario por medio de un archivo de vídeo codificado con Cinepak.

* Ejecución remota de código al aprovecharse de un desbordamiento de búfer basado en heap provocado por el tratamiento erróneo de átomos jpeg en un archivo de vídeo QuickTime especialmente manipulado.

El segundo boletín de seguridad publicado por Apple, informa sobre una vulnerabilidad solventada en el componente QuickTime MPEG-2 Playback Component para Windows, que podría ser aprovechada para ejecutar código arbitrario lo que permitiría comprometer un sistema por completo.

Todos los fallos corregidos son del tipo “Improper Input Validation”, es decir, un fallo al comprobar y validar las entradas introducidas por un usuario y que, bajo ciertas circunstancias, podría ser aprovechado para ejecutar código arbitrario. Este tipo de fallo encabeza el “Top 25 de los fallos de programación más peligrosos” y que podrían ser causantes de problemas de seguridad. Esta lista fue publicada a principios de año y ha sido elaborada por MITRE y SANS en colaboración con diferentes organismos oficiales, empresas y universidades.

Recordamos que todas las actualizaciones pueden ser instaladas a través de las funcionalidades de actualización automática (Software Update) de Apple, o según versión y plataforma, descargándolas directamente desde:

QuickTime 7.6 para Windows:

http://support.apple.com/downloads/QuickTime_7_6_for_Windows

QuickTime 7.6 para Leopard:

http://support.apple.com/downloads/QuickTime_7_6_for_Leopard

QuickTime 7.6 para Tiger:

http://support.apple.com/downloads/QuickTime_7_6_for_Tiger

Más información:

About the security content of QuickTime 7.6
http://support.apple.com/kb/HT3403

QuickTime MPEG-2 Playback Component
http://www.apple.com/quicktime/mpeg2/

2009 CWE/SANS Top 25 Most Dangerous Programming Errors
http://cwe.mitre.org/top25/pdf/2009_cwe_sans_top_25.pdf

Fuente: http://www.hispasec.com/

Análisis de Vulnerabilidades?

Debemos tener en cuenta que este documento es solamente una pequeña semilla del gran mundo de la seguridad informatica, aquí solamente encontraremos nociones basicas de un procedimiento de auditoria de redes.

Objetivo

El objetivo de nuestra auditoria, es tratar de localizar vulnerabilidades a nivel de infraestructura y aplicación, configuraciones erróneas de lo sistemas de información y verificar los niveles de control de accesos a los mismos.

Fases de la auditoria

La ejecución de la auditoria consistirá en varias fases:

* 1) Data Gathering (escaneos, analisis de DNS, scaneos web,aproximaciones TCP/UDP prediccion de numeros de secuencia)
* 2) Deteccion de vulnerabilidades.
* 3) Intrusion.
* 4) Reporte

Data Gathering

El objetivo de esta fase es recaudar la mayor cantidad informacion de los objetivos o de algun componente relacionado.

Para esto podemos emplear herramientas como las que exponemos debajo, como asi tambien buscar informacion en internet.

* Nslookup
* Xprobe
* Nmap
* Dig
* Whois
* Nbtscan
* Unicornscan
* Scanrand
* SSHscan
* xSMBrowser
* Telnet
* Utilidades Privadas
* Netcat

Descubrimiento de vulnerabilidades

Dependiendo de los resultados obtenidos en el paso anterior se procederá a emplear utilidades para auditar los servicios que están en produccion en los equipos y problemas típicos de configuración.

Aquí es donde debemos evaluar en profundidad los posibles falsos positivos que obtuvimos en la fase anterior.

* Nessus3
* Nikto
* HTTrack
* Fuzzer’s
* Nemesis
* Scapy
* Metasploit
* W3af
* Acunetix
* joomlascan
* Cms_few
* Aspaudit
* Vbscan
* Cain & Abel
* Core impact
* Immunity Canvas
* Utilidades Privadas
* Owasp
* MBSA
* BFSQL
* SQLNINJA
* SQLIBF
* BSSQLHacker
* SQL Injection Cheat Sheet
* XSS (Cross Site Scripting) Cheat Sheet
* Retina

Los Análisis de Vulnerabilidades incluyen:

* Detección de Puertos
* Detección de Servicios
* Deteccion de Protocolos
* Detecccion de Sistema Operativo
* Deteccion de Aplicaciónes

Validación manual del resultado para eliminar los resultados que son “Falsos Positivos”.

* Examinación manual del contexto de la información y contenido para determinar si el resultado es apropiado para su distribución pública.

Más que un simple escaneo de puertos, este Análisis de Vulnerabilidades presentará las debilidades de los sistemas y redes que de ser explotadas por personas mal intencionadas que pueden poner nuestra información en riesgo.

Intrusion

En esta fase debemos realizar una intrusión activa teniendo en cuenta los parametros pre-acordados por el responsable de seguridad informática de la empresa donde se realiza la auditoria.

Aqui debemos emplear exploits, herramientas y por supuesto la utilidad fundamental a mi parecer que es el sentido comun y el ingenio de cada uno, estas 2 ultimas pueden darnos accesos inimaginados.

Reporte

Elaboraremos un informe sobre los problemas de seguridad que se hayan detectado. Este podrá contener referencias a documentación e información para solucionar los problemas detectados.

Debemos tener en cuenta que el informe debe estar divido por niveles de seguridad para tener una vista rápida de la situación.

Usaremos como template del reporte, el dado por OSSTMM.

Fuente: http://www.wikipeando.com/index.php/archives/415

Falla de navegadores permite phishing sin envío de correo electrónico

Una falla hallada en la mayoría de los navegadores podría facilitar a los criminales el robo de credenciales de banca online usando un nuevo tipo de ataque denominado “phishing in-session,” según investigadores del proveedor de seguridad Trusteer.

El “phishing in-session” le da a los chicos malos una solución al problema más grande que enfrentan los phishers por estos días: como llegar a víctimas nuevas. En un ataque de phishing tradicional, los estafadores envían millones de correos electrónicos falsos simulando como si vinieran de empresas legítimas, tales como bancos o compañías de pagos en línea.

Esos mensaje usualmente son bloqueados por el software de filtrado de spam, pero con el phishing in-session, el mensaje se saca de la ecuación, reemplazado por una ventana emergente del navegador.

Así es como podría funcionar un ataque: Los chicos malos comprometen un sitio Web legítimo y plantan un código HTML que parece como una ventana pop-up de seguridad de Windows. El pop-up entonces le pide a la víctima que ingrese nuevamente su contraseña y datos de ingreso, y posiblemente responda con algunas preguntas de seguridad que usualmente los bancos realizan para verificar la identidad de sus clientes.

Para los atacantes, la parte difícil sería convencer a las víctimas que esa ventana de pop-up es legítima. Pero gracias a una falla encontrada en los motores de JavaScript de todos los navegadores mas usados, hay una forma de hacer que este tipo de ataque parezca más creíble, dijo Amit Klein, jefe de tecnología de Trusteer.

Estudiando la forma en que los navegadores usan JavaScript, Klein dice que ha encontrado la forma de identificar cuando alguien está en una sesión o no en un sitio Web determinado, siempre que se use cierta función JavaScript. Klein no dará el nombre de la función porque eso le daría a los criminales el media con el cual lanzar el ataque, pero ha notificado a los fabricantes de navegadores y espera que la falla eventualmente sea emparchada.

Hasta ese momento, los criminales que descubran la falla pueden escribir código que verifique si el navegante tiene una sesión con, por ejemplo, una lista predeterminada de 100 sitios bancarios. “En lugar de lanzar este pop-up aleatoriamente con el mensaje de phishing, un atacante se puede hacer más sofisticado comprobando y hallando su el usuario esta efectivamente conectado con uno de los sitios Web de esas 100 instituciones financieras,” dijo.

“El hecho que uno esté efectivamente en sesión le da mucha credibilidad al mensaje de phishing,” Agregó.

Los investigadores de seguridad han desarrollado otras formas de determinar si una persona ha ingresado acierto sitio, pero no es algo siempre confiable. Klein dijo que su técnica no funciona siempre pero podría usarse en muchos sitios incluyendo bancos, negocios en línea, sitos de juegos y de redes sociales.

Traducido para blog de Segu-info por Raúl Batista
Autor: Robert McMillan
Fuente: www.networkworld.com
Más:

http://www.trusteer.com/files/In-session-phishing-advisory-2.pdf

http://www.idg.es/pcworld/Un-fallo-en-los-navegadores-puede-permitir-el-phis/doc75609-Software.htm

http://www.vnunet.es/es/vnunet/news/2009/01/14/un_fallo_en_navegadores_permitiria_ejecutar_phishing_sin_necesidad_de_email

http://www.ebanking.cl/seguridad/nuevo-tipo-de-ataque-de-phishing-001408