martes, 27 de octubre de 2009

Salto de políticas de seguridad en Asterisk

Se ha confirmado la existencia de una vulnerabilidad en Asterisk 1.6,
que podría permitir a un atacante evitar restricciones de seguridad.

Asterisk es una aplicación de una central telefónica (PBX) de código
abierto. Como cualquier PBX, se pueden conectar un número determinado
de teléfonos para hacer llamadas entre sí e incluso conectarlos a un
proveedor de VoIP para realizar comunicaciones con el exterior. Asterisk
es ampliamente usado e incluye un gran número de interesantes
características: buzón de voz, conferencias, IVR, distribución
automática de llamadas, etc. Además el software creado por Digium está
disponible para plataformas Linux, BSD, MacOS X, Solaris y Microsoft
Windows.

El problema se debe a que no se realiza una comprobación ACL cuando
se tramitan SIP INVITEs, un atacante podría emplear esto para que un
dispositivo realice llamadas en redes destinadas a ser prohibidas tal
y como se hayan defino en las líneas "deny" y "permit" de "sip.conf".

Se recomienda actualizar a Asterisk Open Source versión 1.6.1.8 :
ftp://ftp.digium.com/pub/telephony/asterisk

O aplicar el parche :
http://downloads.digium.com/pub/security/AST-2009-007-1.6.1.diff.txt

Fuente: Hispasec.com

jueves, 22 de octubre de 2009

(JAJA algunas me dieron mucha risa) Te das cuenta que sos un Geek cuando...

amlmohadas geek Sabes que eres geek cuando...

  • Cuando te das cuenta que en la foto de la noti­cia, las teclas [Ctrl] y [Alt] tienen el orden invertido (aportado por josemaX)
  • La única ocasión en que ves tu cara reflejada es cuando la pantalla se pone en negro
  • Preguntas en el supermercado si aceptan PayPal
  • Pierdes fe en la humanidad cuando ves que alguien usa IE6
  • Cuando ves carteles publicitarios reales te preguntas si son de 468×60 o más
  • Empiezas a ver deportes… por Justin.tv
  • Mientras tus amigos se ríen normalmente, tu eres el único gritando LOL OMG ROFL
  • Al decir que “vas a jugar un partido“, en realidad estas diciendo “voy a jugar una partida
  • Vas al zoológico, ves un pingüino y te extrañas que su nombre no sea Tux
  • Estas dispuesto a pagar por una invitación para Google Wave, a diferencia de una entrada para un partido de fútbol de tu país, que lo encuentras “un robo”
  • Te sabes de memoria la dirección de todos los sitios que visitas, mientras que no puedes recordar la dirección de tu propia casa
  • Ignoras a tus amigos en Facebook porque tu propósito allí es jugar (y pobre del que te hable cuando estés a punto de batir tu récord)
  • Crees que el concepto de popularidad está basado en la cantidad de enlaces entrantes a tu web o seguidores en Twitter
  • Te pasan “cosas” con los productos de Apple
  • No entiendes cómo algo puede funcionar sin WordPress, Blogger o otro sistema de blogging
  • Para ver tu aspecto prefieres sacarte una foto con la webcam que usar un espejo
  • Entiendes lo que dice Sheldon Cooper (aportado por @jorgefelipe)
  • Peor que enten­der a Shel­don Cooper es cuando empiezas que querer ser como él (aportado por Lorenzo)
  • El sonido del computador te parece más relajante que el canto de cualquier pájaro
  • Tu teléfono móvil hace de todo menos recibir llamadas (aportado por @emeaguiar)
  • Tus contactos solo te hablan por messenger cuando tienen problemas con su PC (aportado por @tunageek)
  • Entiendes los Chuck Norris Facts (aportado por @kvca)
  • Al sen­tarte con una cerveza frente al pc lo con­sid­eras “ir de copas con los amigos” (aportado por Amugal)
  • En las matrícu­las de los coches no paras de ver WTF, LOL, FLK… (aportado por Nicole)
  • Necesitas saber si eres geek o no
Fuente: francescjosep.net

jueves, 15 de octubre de 2009

Adobe soluciona 29 fallos de seguridad en Acrobat y Adobe Reader

Adobe entra de lleno en el mundo de las actualizaciones de seguridad
programadas solucionando en este ciclo nada menos que 29 problemas de
seguridad en su software más popular: los lectores y editores de PDF
Adobe Reader y Acrobat. Rivaliza con Microsoft, que en este ciclo ha
resuelto también 34 fallos.

Los administradores de sistemas deben andar todavía ocupados intentando
actualizar sus productos Microsoft y Adobe. Adobe emitió en mayo un
comunicado por el que se comprometía a mejorar su política de seguridad.
Básicamente, decía que mejoraría el código de desarrollo centrándose en
la seguridad, que mejoraría los procesos de respuesta a incidentes, y
que programaría regularmente las actualizaciones de sus productos. En
concreto, cada tres meses, lo segundos martes de cada mes. Con un
criterio discutible, coincidiría con los días de actualización que
hace años eligió Microsoft.

Estas promesas recuerdan inevitablemente a la Trustworthy Computing que
Microsoft tuvo que implantar a principios de 2002 (a través de un
comunicado del propio Bill Gates) para intentar encarar los continuos
reveses en seguridad que sufría. Se puso en marcha la Strategic
Technology Protection Program (STPP) que más tarde daría sus frutos en
proyectos que se han demostrado eficaces como el Windows Software Update
Services, Microsoft Operations Manager, la política de actualización
periódica, sistemas fortificados "por defecto", etc. Aun así lo peor
estaría por llegar en 2003 con Blaster, pero eso ya pertenece a la
"prehistoria", y los esfuerzos de Microsoft comenzaron a dar resultados
años después.

Adobe acaba de publicar uno de sus primeros ciclos de actualizaciones
con nada menos que 29 vulnerabilidades resueltas. Entre ellas la que
estaba siendo aprovechada por atacantes desde hace semanas, y que
permitía la ejecución de código arbitrario a través de archivos PDF
especialmente manipulados. El mismo día Microsoft corregía 34, pero
en una mucha mayor gama de productos.

Adobe comienza así a mejorar su seguridad, siete años más tarde que
Microsoft (que aún lo está adaptando y asumiendo)... De hecho, ya se
empieza a conocer a Adobe como "la nueva Microsoft", heredando sus
problemas logísticos a la hora de mejorar la seguridad, teniendo que
rediseñar su estrategia (cuando quizás sea tarde), y actuando de forma
reactiva en vez de haber aprendido de otros fabricantes. Ahora que Adobe
se toma en serio su seguridad, esperamos que no sean necesarios tantos
años para, como le está costando a Microsoft, materializar los
resultados, puesto que el mundo del malware no es el mismo que en 2002,
y las consecuencias de los problemas de seguridad de hoy son mucho más
serias.

Fuente: hispasec.com

martes, 6 de octubre de 2009

Análisis de la última vulnerabilidad en el kernel de Linux

El 1 de octubre Jan Beulich publicó el "advisory" y el parche de un
fallo en el kernel de Linux en versiones x86-64 iguales o menores a
la 2.6.32-rc1. El fallo es una fuga de información en los valores de
ciertos registros de 64 bits cuando son accedidos desde un programa de
32 bits que a su vez esté ejecutando código de 64 bits, es decir que
ejecute instrucciones bajo 64-bit mode.

¿Cómo es posible que en la arquitectura de x86-64 bits se pueda ejecutar
código de 32 bits?

"x86-64 long mode" en el sub-modo "compatibility mode" soporta de forma
nativa x86 (32 bits), es decir, las instrucciones de x86 pueden
ejecutarse directamente en el sub-modo "compatibility mode". Los
sub-modos son controlados por el descriptor del segmento de código
(USER_CS en Linux).

¿Cómo puede un proceso de 32 bits ejecutar código de 64 bits?

Solo necesita haber sido compilado como un programa de 32 bits y después
realizar lo que se llama un salto o una llamada de tipo FAR (también
conocido como FAR CALL/JMP) a la rutina dónde se encuentre el código de
64 bits usando el descriptor de segmente código USER_CS.

¿Para qué usa el exploit un FAR CALL/JMP?

Para ejecutar una rutina de 64 bits desde un proceso de 32 se necesita
realizar un cambio del descriptor de segmento de código actual a
USER_CS. Con un FAR JMP solo se consigue saltar al sitio indicado, como
interesa volver al código de x86 de forma fácil se usa un CALL FAR y
después de que se haya ejecutado el código de 64 bits un RET FAR
(sintaxis AT&T LRET). Resumiendo, la sintaxis del FAR CALL que
necesitamos conocer en este caso es:

CALL FAR DESCRIPTOR_DEL_SEGMENTO_DE_
CODIGO:DIRECCIÓN_DE_MEMORIA

Como ejemplo, si se quiere hacer un CALL FAR a la dirección de memoria
004011D0 usando el descriptor de segmento de código 38A4, la sintaxis
Intel sería tal que así:

CALL FAR 38A4:004011D0

El valor del descriptor de segmento de código USER_CS en Linux es 0x33.

¿Cómo se ha solucionado el fallo?

Poniendo a 0 los registros que potencialmente podrían representan un
riesgo. Son r8, r9, r10, y r11 de x86-64 y se ponen a 0 antes de volver
al espacio de usuario en una llamada al sistema.

¿Qué es realmente USER_CS?

Es un descriptor del segmento de código, en este caso USER_CS representa
el descriptor de segmento de código de 64 bits, para el de 32 bits se
usa USER32_CS, esto quiere decir que si desde 64 bits hacemos un cambio
a USER32_CS podemos ejecutar código de 32bits de forma nativa (lo
contrario de lo que estamos haciendo).

¿Cómo sabe el microprocesador si está en modo de compatibilidad x86 o en
64 bits mode?

Si el descriptor de segmento de código de la GDT tiene el bit "D/B" a 0
y el bit "L" a 1 está en modo 64 bits (USER_CS), en caso contrario está
en modo compatible x86 (USER32_CS).

Exploits públicos: el de Jon Oberheide

Usa un FAR JMP para pasar de x86 a 64 bit y ejecutar una rutina que
básicamente lo que hace es poner los registros de 64 en pares de
registros de 32 bits. Después genera una excepción para que se pueda
inspeccionar el crash dump con gdb por ejemplo y ver el valor de los
registros de 32 con los valores de los de 64.

Exploits públicos: el de Spender

El exploit de spender es más "avanzado", usa llamadas a sistema
(syscalls) para obtener información de los registros, usa FAR CALLs y
FAR RETs para ir de 64 bits y volver, además muestra los registros R8,
R9, R10, R11, R12, R13, R14 y R15 usando diferentes syscalls.

En definitiva el exploit lo que hace es: llamar a llamadas al sistema
desde el proceso de 32 bits, después de la llamada se cambia a
64bit-mode en el proceso y se obtiene el valor de los registros de 64
bits en registros de 32 a pares y se muestran con un printf.

¿De qué sirve realmente esta vulnerabilidad?

Este tipo de fallos pueden ser aprovechados para cuando existe un ASLR
(protección por aleatoriedad de carga de librerías). Así se puede
obtener alguna dirección útil para otro exploit o similar.

Fuente: www.hispasec.com

viernes, 2 de octubre de 2009

Y si, se vienen los cursos de Seguridad de la Informacion :) :)

Capacitaciones


http://www.balderrama.com.ar/capacitacion/balderrama_capacitacion.htm

¡Preparándonos para el Amanecer Cuántico! Los Nuevos Estándares de Criptografía Post-Cuántica del NIST

Como expertos en ciberseguridad, vivimos en un panorama de amenazas en constante evolución. Hoy, nos encontramos en la antesala de una revol...