Hispasec Una-al-día

La nueva versión de PHP 5.3.10 resuelve una vulnerabilidad que permite la ejecución de código remoto, y que fue introducida al intentar arreglar la anterior actualización.
Si hace un par de semanas se publicaba la actualización 5.3.9 de PHP, ahora se detecta una nueva vulnerabilidad provocada por los cambios introducidos en el parche que solucionaban la anterior, relacionada con las tablas hash (CVE-2011-4885).
Según el  investigador Stefan Esser (i0n1c), esta nueva vulnerabilidad (CVE-2012-0830) permitiría la ejecución remota de código o en su defecto, una ataque de denegación de servicio. Existe una prueba de concepto que la aprovecha.
La vulnerabilidad se presenta en la introducción de una nueva propiedad dentro de php.ini, llamada "max_input_vars" que limita el número máximo de parámetros que pueden ser usados en una petición (por ej: http://www.sitio.com/peticion.php?a=1&b=2&c=3). Por defecto le es asignado el valor 1000.
Esto, unido a los cambios introducidos en la función 'php_register_variable_ex' que no controlan correctamente cuándo se supera el valor max_input_vars y se utiliza un array de variables, permite que se pueda ejecutar código remotamente.
Si se observa el código cambiado en php_variables.c, se comprueba que sólo se controlan los valores menores o iguales a "max_input_vars":
if (zend_hash_num_elements(symtable1) <= PG(max_input_vars)) {
if (zend_hash_num_elements(symtable1) == PG(max_input_vars)) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "Input variables
exceeded %ld. To increase the limit change max_input_vars in php.ini.",
PG(max_input_vars));
}
...
Sin "else" que encamine por otras vías el código. Por tanto, si se supera dicho valor el código seguiría ejecutándose hasta llegar a:
symtable1 = Z_ARRVAL_PP(gpc_element_p);una macro que devuelve referencias a la tabla hash actualizada. Es aquí donde se podría ejecutar el código arbitrario o, provocar una denegación de servicio.
PHP ha publicado rápidamente la actualización de PHP 5.3.10 que se encuentra disponible en:http://www.php.net/downloads.php
Más información:
Una vulnerabilidad podría permitir dejar sin servicio a la mayoría de servicios webhttp://unaaldia.hispasec.com/2011/12/una-vulnerabilidad-podria-permitir.html
Critical PHP Remote Vulnerability Introduced in Fix for PHP Hashtable Collision DOShttp://thexploit.com/sec/critical-php-remote-vulnerability-introduced-in-fix-for-php-hashtable-collision-dos/
Simple proof of concept for PHP bug described by Stefan Esser (@i0n1c)https://gist.github.com/1725489

José Mesa Orihuelajmesa@hispasec.com

Según afirma el programador Chris Hessing (que participa en el Open1X Group), y el investigador Bret Jordan, existiría una vulnerabilidad crítica (CVE-2011-4872) en los terminales móviles de HTC con Android. El fallo facilitaría la revelación de información sensible tal como datos de configuración y credenciales de las redes WIFIs (802.1X) guardadas en el móvil.
El HTC Desire HD es uno de los
terminales afectados por este
problemaLa vulnerabilidad afectaría a nueve terminales de la marca taiwanesa HTC:·         Desire HD - Versiones FRG83D, GRI40·         Desire S - Versión GRI40·         Sensation Z710e - Versión GRI40·         Glacier - Versión FRG83·         EVO 3D - Versión GRI40·         Droid Incredible - Versión FRF91·         Thunderbolt 4G - Versión FRG83D·         Sensation 4G - Versión GRI40·         EVO 4G - Versión GRI40
El error se debe a los permisos asociados a "android.permission.ACCESS_WIFI_STATE" en las versiones afectadas y al uso del miembro .toString() de la clase WifiConfiguration. Esto daría acceso a todas las configuraciones almacenadas y las contraseñas en texto claro (otra característica de la vulnerabilidad presente), a través de aplicaciones especialmente manipuladas para transmitir estos datos de manera remota. Se necesitarían los permisos "android.permission.INTERNET". Este es bastante habitual a la hora de instalar ciertas aplicaciones en Android que necesitan acceso a Internet.
Por ejemplo, un atacante podría obtener la siguiente información en un servidor remoto, si la víctima ejecutara una aplicación especialmente diseñada para aprovechar este fallo:   ID: 0 SSID: "wpa2eap" BSSID: null PRIO: 21KeyMgmt: WPA_EAP IEEE8021X Protocols: WPA RSNAuthAlgorithms:PairwiseCiphers: CCMPGroupCiphers: WEP40 WEP104 TKIP CCMPPSK:eap: TTLSphase2: auth=PAPidentity: testanonymous_identity:password: testclient_cert:private_key:ca_cert: keystore://CACERT_wpa2eapGoogle y HTC (que fueron notificados de manera privada en septiembre de 2011) están trabajando coordinadamente para solucionar la vulnerabilidad y actualmente no se conocen aplicaciones en el Market que la aprovechen, siempre según fuentes oficiales.
Las posibles actualizaciones estarán disponibles a través de los canales oficiales de cada operador o mediante HTC: http://www.htc.com/europe/help/
Más información:
802.1X password exploit on many HTC Android deviceshttp://www.kb.cert.org/vuls/id/763355
802.1X password exploit on many HTC Android deviceshttp://blog.mywarwithentropy.com/2012/02/8021x-password-exploit-on-many-htc.html

José Mesa Orihuelajmesa@hispasec.com

La Fundación Mozilla ha publicado nueve boletines de seguridad (del MFSA 2012-01 al MFSA 2012-09) que solucionan diez vulnerabilidades para todos sus productos (Firefox, Thunderbird y SeaMonkey).
Atendiendo al sistema de clasificación de la propia fundación, cinco boletines solucionan vulnerabilidades con impacto considerados como “crítico”, dos de ellos como “alto”, otros dos como “moderado” y un último como “bajo”.
Los boletines publicados son:
MFSA 2012-01: Considerado crítico. Corrige múltiples problemas de seguridad de la memoria en el motor del navegador usado por Firefox (CVE-2012-0443 y CVE-2012-0442).
MFSA 2012-02: Boletín de carácter bajo que añade restricciones a la sintaxis de las direcciones web para evitar una posible revelación de información sensible con determinadas direcciones IPv6 (CVE-2011-3670).
MFSA 2012-03: Vulnerabilidad de gravedad alta (con CVE-2012-0445). Resuelve una vulnerabilidad de cross-site scripting a través de iframes que podría ser usada para ataques de phishing.
MFSA 2012-04: Considerado crítico (con CVE-2011-3659). Corrige una vulnerabilidad por la que un nodo hijo de nsDOMAttribute podía ser accesible después de ser borrado. Permitiría ejecutar código de forma remota.
MFSA 2012-05: Destinado a solucionar una vulnerabilidad crítica por la que objetos que no son de confianza podrían saltarse una comprobación de seguridad llegando a permitir ataques cross-site scripting a través de páginas web o extensiones de Firefox (CVE-2012-0446).
MFSA 2012-06: De gravedad alta (con CVE-2012-0447). Soluciona un posible desbordamiento de memoria intermedia al codificar imágenes, existiendo la posibilidad de que información sensible sea revelada.
MFSA 2012-07: Considerado crítico (con CVE-2012-0444). Corrige un problema al procesar archivos de audio con formato Ogg Vorbis pudiendo causar una corrupción de memoria y una potencial ejecución de código.
MFSA 2012-08: Vulnerabilidad crítica (con CVE-2012-0449). Corrige un problema que podría causar una potencial ejecución de código al procesar hojas de estilo XSLT.
MFSA 2012-09: Vulnerabilidad de carácter moderado (con CVE-2012-0450). Evita que el archivo con la clave de sincronización ("Firefox Recovery Key.html") de Firefox sea guardado con los permisos inadecuados siendo accesible por otros usuarios en Linux y sistemas OS X. Este fallo, no afecta a Thunderbird.
Todos estos problemas ha sido corregidos en Firefox 10.0, Thunderbird 10.0 y SeaMonkey 2.7, disponibles desde: http://www.mozilla.org/
Más información:
MFSA 2012-09 Firefox Recovery Key.html is saved with unsafe permissionhttp://www.mozilla.org/security/announce/2012/mfsa2012-09.html
MFSA 2012-08 Crash with malformed embedded XSLT stylesheetshttp://www.mozilla.org/security/announce/2012/mfsa2012-08.html
MFSA 2012-07 Potential Memory Corruption When Decoding Ogg Vorbis fileshttp://www.mozilla.org/security/announce/2012/mfsa2012-07.html
MFSA 2012-06 Uninitialized memory appended when encoding icon images may cause information disclosurehttp://www.mozilla.org/security/announce/2012/mfsa2012-06.html
MFSA 2012-05 Frame scripts calling into untrusted objects bypass security checkshttp://www.mozilla.org/security/announce/2012/mfsa2012-05.html
MFSA 2012-04 Child nodes from nsDOMAttribute still accessible after removal of nodeshttp://www.mozilla.org/security/announce/2012/mfsa2012-04.html
MFSA 2012-03 <iframe> element exposed across domains via name attributehttp://www.mozilla.org/security/announce/2012/mfsa2012-03.html
MFSA 2012-02 Overly permissive IPv6 literal syntaxhttp://www.mozilla.org/security/announce/2012/mfsa2012-02.html
MFSA 2012-01 Miscellaneous memory safety hazards (rv:10.0/ rv:1.9.2.26)http://www.mozilla.org/security/announce/2012/mfsa2012-01.html

Daniel Vacadvaca@hispasec.com

Se ha descubierto un problema de seguridad en sudo que permite a cualquier atacante local elevar privilegios y convertirse en root. El fallo afecta a casi todas las distribuciones basadas en el kernel Linux y además de BSD, Mac OS X, etc.
Sudo es una herramienta de administración, utilizada en muchas de las distribuciones basadas en el kernel Linux, que permite delegar privilegios (normalmente de root) a determinados usuarios y para ciertos comandos en concreto. Ello posibilita, por ejemplo, que determinado grupo de usuarios tenga acceso a ciertas herramientas, con privilegios de administrador, pero de forma controlada y segura.
El fallo, descubierto por joernchen del Phenoelit Groupoernchen, se encuentra en un error de formato de cadena en la función "sudo_debug de sudo.c", a la hora de procesar el nombre del programa que se le pasa por parámetro.
Para aprovechar la vulnerabilidad (con  CVE 2012-0809), el atacante debe, por ejemplo, realizar un enlace a nivel de sistema de fichero (ln) del binario sudo hacia un fichero con un nombre manipulado con caracteres especiales de cadena (por ejemplo "%n"). Al ejecutar ese nuevo enlace creado, se podrá ejecutar código con privilegios de root.
El fallo se ha confirmado en las versiones 1.8.x, y para solucionarlo, es necesario actualizar a 1.8.3.p2.
Este fallo es heredado por multitud de distribuciones y sistemas operativos que utilizan sudo. Fue notificado el día 24 de enero, y el día 30 ya se publicó un parche. Corren especial peligro las máquinas compartidas entre usuarios. También es posible que sea usado en un futuro para la elevación y "liberación" de dispositivos Android, por ejemplo.
Más información:
Vulnerabilidad:http://seclists.org/fulldisclosure/2012/Jan/att-590/advisory_sudo.txt

Laboratorio Hispaseclaboratorio@hispasec.com

Se ha anunciado una vulnerabilidad en Samba que podría permitir a un atacante provocar una denegación de servicio.
Samba es una implementación libre del protocolo de compartición de archivos Microsoft para sistemas de UNIX. De esta manera equipos con sistemas GNU/Linux, MacOS o Unix en general pueden formar parte de la red de directorios compartidos de Windows.
La vulnerabilidad, descubierta por Youzhong Yang e Ira Cooper, está causada por un error en el demonio smbd al no liberar memoria cuando maneja solicitudes de conexión, incluso si estas no tienen éxito debido a una autenticación incorrecta.
Un atacante en red local podría explotar esta vulnerabilidad para agotar la memoria y aumentar el uso de la CPU del sistema, causando una denegación de servicio mediante el envío de un gran número de solicitudes de conexión.
La vulnerabilidad, identificada como CVE-2012-0817, afecta a las versiones de Samba 3.6.0 hasta 3.6.2.
Desde la página oficial de Samba se puede descargar la versión 3.6.3, así como parches para otras versiones que corrigen la vulnerabilidad explicada anteriormente: http://www.samba.org/samba/security/
Más información:
CVE-2012-0817 - Memory leak/Denial of Servicehttp://www.samba.org/samba/security/CVE-2012-0817
Samba 3.6.3 Available for Downloadhttp://www.samba.org/samba/history/samba-3.6.3.html

Juan José Ruizjruiz@hispasec.com

Describíamos en la entrega anterior un ataque de elevación de "serie" en Windows cuyo mayor obstáculo era perpetrar un ataque ataque "second-preimage" contra MD5. Veamos por qué eso no es tan complicado.
Esquema de una operación MD5.
Fuente: WikipediaLa función de hash criptográfico MD5 (Message-Digest algorithm 5) lleva años mostrando signos de debilidad, inadecuado para los tiempos que corren. Si bien se ha llevado varios varapalos desde su creación, hace tiempo recibió lo que se pudo considerar su golpe de gracia: se podían crear arbitrariamente dos flujos de datos que resulten en el mismo hash o firma.
Desde su diseño en 1991 por Ron Rivest (uno de los implementadores de la criptografía pública), MD5 ha sido tomado prácticamente como estándar de facto para control de hash para firma de ficheros. Por diseño, convierte cualquier flujo de datos de cualquier tamaño en una serie de 128 bits diferente. Esto permite crear una "firma" corta que identifique a un archivo o flujo de datos. En la teoría, reduce un conjunto infinito a otro finito de 2 elevado a 128, con lo que las colisiones serían siempre posibles, pero en la práctica esta cantidad ha sido suficiente.
Desde 1996 ya se vienen recomendado otros algoritmos que han demostrado mejores capacidades (como el SHA en sus distintas variantes) pero su implantación es tan fuerte que, como muchos otros estándares en informática, descartarlo es un proceso lento y a veces incluso "doloroso".
El enemigo natural de estos algoritmos son las colisiones. Es decir, que varios ficheros tengan una misma firma identificadora. Esto sería como si dos personas tuvieran el mismo número de DNI o tarjeta de la seguridad social: podrían hacerse pasar uno por el otro. La firma MD5 también es usada en algunos casos para realizar hashes que a posteriori son firmados con claves privadas, por lo que su debilidad también salpicaría a la criptografía pública. En 2004 se consiguió crear dos certificados  X.509 distintos con igual hash MD5.
Además de las colisiones, MD5 tiene otros problemas. Para una firma o hash criptográfico, por definición, debe ser matemáticamente muy complicado realizar el proceso contrario: calcular los datos que produjeron el hash. Así, por esta razón, muchos programas almacenan el hash MD5 de las contraseñas de usuarios en las bases de datos. Hace algunos años se popularizaron las tablas rainbow con información preprocesada sobre hashes MD5. Esto, en teoría, permite a alguien que tenga acceso a esos hashes, realizar el proceso inverso en tiempo razonable, o sea: pasar del hash MD5 a la palabra que lo generó. Se ha popularizado como método eficaz de "crackeo" para contraseñas de este tipo, con lo que el almacenamiento de credenciales en este formato también se considera ya inseguro.
En verano de 2005 se dio un caso realmente curioso. Un australiano consiguió anular una multa de tráfico ante la imposibilidad de las autoridades de tráfico de demostrar fehacientemente que la imagen registrada por un radar no había sido alterada. El sujeto circulaba por una carretera que estaba siendo controlada con un radar. Cuando fue cazado y su coche "fotografiado", el abogado que representaba al amonestado recurrió la denuncia, argumentando que no se había probado que la imagen obtenida por la cámara asociada al radar no hubiese sido modificada de ninguna forma. Las autoridades australianas de tráfico respondieron que se utilizaba el algoritmo MD5 para obtener el hash de las imágenes obtenidas. No encontraron a ningún perito que demostrase ante el tribunal la validez de dicho algoritmo, y por tanto se libró de la multa.
Marc Stevens, Arjen Lenstra, y Benne de Weger le dieron el tiro de gracia en 2008. Diseñaron un método por el que, añadiendo un puñado de bytes a un archivo, pueden hacer que su firma, su hash MD5, sea idéntico a otro fichero arbitrario. La diferencia en este caso es que las colisiones pueden ser elegidas, provocadas sobre dos ficheros cualesquiera. Lo consiguieron con una sola máquina en menos de dos días. Un tiempo más que razonable. Ese mismo año, investigadores consiguen hacer que cualquier certificado SSL parezca válido, usando la firma MD5. Usaron la potencia de 200 consolas PlayStation3 para conseguir su objetivo.
Todas estas son pequeñas razones por las que nadie debería usar MD5 para asuntos medianamente serios. Y menos Microsoft.
Más información:
17/08/2005 Utilizar MD5 para recurrir las multas de tráficohttp://www.hispasec.com/unaaldia/2489
High-Speed Collisionshttp://www.symantec.com/enterprise/security_response/weblog/2008/01/highspeed_collisions.html
Investigadores consiguen hacer que cualquier certificado SSL parezca válidohttp://unaaldia.hispasec.com/2008/12/investigadores-consiguen-hacer-que.html

Sergio de los Santosssantos@hispasec.comTwitter: @ssantosv

Se han anunciado cuatro vulnerabilidades en Apache Struts (versiones 2.0.0 - 2.3.1.1), que podrían permitir a un atacante remoto ejecutar código Java.
Struts es un framework de código abierto para el desarrollo de aplicaciones Web Java EE bajo el patrón de arquitectura de software Modelo-Vista-Controlador (MVC). Anteriormente se desarrollaba como parte del proyecto Jakarta de la Apache Software Foundation, pero actualmente es un proyecto independiente conocido como Apache Struts.
Apache Struts2 utiliza XWork OpenSymphony y bibliotecas OGNL (Object-Graph Navigation Language). En XWork, existe por defecto el parámetro 'ParametersInterceptor' que permite hacer uso de las expresiones OGNL.
A través de OGNL se utilizan funciones Java estáticas. Esto podría ser usado por un atacante remoto para ejecutar código arbitrario a través de un valor de 'ParametersInterceptor' especialmente codificado en OGNL.
Este fallo se ha solucionado en la versión 2.3.1.2 y se le ha asignado el identificador CVE-2011-3923.
Más información:
Security Bulletins:https://cwiki.apache.org/confluence/display/WW/S2-009
Fix:http://struts.apache.org/download.cgi#struts2312
Mailing list:http://mail-archives.apache.org/mod_mbox/struts-user/201201.mbox/%3CCANrzj0k5HZDDkJ7x%3DTVqY%2BjfCtd4FORcs7ehrfRgyp02Dg3gxQ%40mail.gmail.com%3E

Víctor Antonio Torrevtorre@hispasec.com

Cesar Cerrudo ha presentado un método que podría ser usado para elevar privilegios en Windows de forma relativamente "sencilla". Solo es necesario realizar un ataque "second-preimage". O sea, a partir de un fichero de sistema, crear otro con un mismo hash MD5. Veamos exactamente cómo funciona.
Instalaciones en Windows
En los últimos sistemas operativos de Microsoft, el directorio C:\Windows\Installer\ contiene ficheros de instalación de Windows (.msi y .msp). Ahí encontrarás los instaladores de los programas que utilizas en tu sistema. Los nombres son aleatorios.

Ejecutando como usuario normal estos ficheros, comenzará la (re)instalación de los programas... Se puede comprobar como ciertos programas se comportan diferente cuando son lanzados desde esa ruta o cuando son lanzados desde cualquier otra. En algunos paquetes oficiales de Microsoft, el intento de elevación (UAC) aparecerá en diferentes momentos de la instalación y en otros, no aparecerá.
Comprobarlo es sencillo. Basta con ejecutar como usuario cualquier msi mientras se aloja en C:\Windows\Installer\. Luego, lo copiamos en otra localización (por ejemplo F: en la imagen) y lo intentamos lanzar.

Puesto que ocurre con pocos paquetes y el usuario no tiene permisos para escribir ni modificar C:\Windows\Installer\, esto queda como un comportamiento "curioso". Lo peor viene cuando se estudia qué ocurre entre bambalinas en el sistema al lanzar alguno de estos instaladores oficiales de Microsoft. En el ejemplo, he probado con Microsoft Office Publisher MUI (English) 2007.
Parece que este y otros paquetes de este tipo elevan privilegios automáticamente durante unos momentos. Como se aprecia en la imagen, se crea un fichero del tipo Hx#cuatro números aleatorios en hexadecimal#.tmp en el directorio %temp% (o sea, c:\users\sergio\appdata\local\temp en el ejemplo) y además es lanzado por SYSTEM.


Un posible ataque
Si conseguimos recuperar ese fichero temporal (sólo está accesible unos instantes) comprobamos que se trata de una instancia de la librería HXDS.dll. En la imagen se comprueba cómo lo he hecho.


Esta librería la carga msiexec.exe (el instalador de ficheros .msi) cada vez que se lanza un proceso de instalación. A veces la lanza como el usuario y a veces... como SYSTEM, y aquí está el problema. El directorio temporal de cada usuario puede ser modificado por él mismo (tiene permisos totales sobre él). Así que el usuario podría sustituir ese fichero temporal por otro código y se lanzaría como SYSTEM cuando se ejecutase un MSI alojado en C:\Windows\Installer. Ya tenemos la elevación.
La restricción al ataque
Pero en teoría Microsoft lo tiene en cuenta y pone una pequeña restricción: Msiexec.exe en realidad conoce el hash MD5 de HXDS.dll (lo almacena temporalmente en c:\windows\installer\) y lo compara con la copia de la instancia de la DLL creada en el temporal. Si no coincide, no lanzará el instalador y por tanto, la DLL.
El posible ataque
Si se sustituye la DLL oficial con un ejecutable cuyo hash coincida con el hash MD5 que espera msiexec.exe (en principio en mi sistema es 9e7370cc3d6a43942433f85d0e2bbdd8), entonces el ataque será posible y la elevación viable (se ejecutará como SYSTEM si lanzamos el MSI desde c:\windows\installer como usuario).
Por tanto el éxito queda supeditado la dificultad de encontrar un ataque llamado "second-preimage". Lo que comúnmente se entiende por una colisión MD5 deseada entre dos flujos de datos. Quizás para atacantes "de a pie" no sea posible, pero para otras organizaciones de mayor envergadura, es totalmente viable, puesto que MD5 está roto desde hace tiempo. Si, el mayor problema para el atacante es realizar un ataque second preimage al MD5, solo es necesaria cierta cantidad de tiempo y capacidad de cómputo.
Hay que tener en cuenta que no ocurre con todos los paquetes ejecutables (no en todos crea la copia de la DLL en el directorio temporal y la lanza como SYSTEM). Sólo lo he conseguido por ahora con paquetes de Microsoft Office, que ejecutan varios procesos de msiexec.exe como SYSTEM.
Microsoft, ¿No quedamos en dejar de utilizar MD5?
Ahora que se cumplen 10 años de la Trustworthy Computing, hay que recordar que MD5 está "prohibido" en Microsoft dentro de su Security Development Lifecycle desde 2005. No se deben usar funciones criptográficas consideradas débiles... y no se nos ocurre una función más débil que MD5 como control para restringir una ejecución de código. Veremos por qué en la siguiente entrega.
Más información:
A free Windows Vulnerability for the NSAhttp://blog.ioactive.com/2012/01/free-windows-vulnerability-for-nsa.html?m=1

Sergio de los Santosssantos@hispasec.comTwitter: @ssantosv

Se ha publicado una vulnerabilidad en PCAnywhere que permite ejecutar código en el sistema donde esté corriendo la aplicación. Esto es especialmente grave puesto que la aplicación, por diseño, está pensada para ser accesible en remoto.

PCAnywhere es una popular aplicación comercial de control remoto creada por la empresa Symantec que permite a los usuarios administrar un ordenador a distancia. Esto es especialmente útil para situaciones donde el acceso físico no sea posible, para tareas de soporte en remoto, etc., por lo que suele estar accesible en redes abiertas. En el servidor, el proceso escucha por defecto en el puerto TCP 5631.
En el servidor, los procesos de conexión los maneja el componente awhost32. En este proceso existe un fallo a la hora de validar o filtrar los datos de acceso introducidos por el usuario, lo que permite un desbordamiento de memoria intermedia. Si se envían peticiones especialmente manipuladas, se podría ejecutar código arbitrario en el equipo con privilegios de SYSTEM (los máximos en Windows).
Symantec conocía el problema desde agosto de 2011, aunque a pesar de su gravedad se ha hecho público ahora. Fue reportado de forma privada a través de ZDI, y ahora han coordinado una solución. Aunque en teoría el gravísimo problema fuese conocido solo por el descubridor, ZDI (que "compró" la vulnerabilidad al descubridor) y por Symantec, esto siempre conlleva riesgos. Durante cinco meses, se puede desde filtrar la información hasta ser descubierta por cualquier otro investigador de forma independiente, y quizás con otras intenciones.
El fallo recuerda al que sufrió VNC en mayo de 2006. No se trataba entonces de un problema de desbordamiento de memoria intermedia, pero permitía eludir la autenticación en el servidor. Aun hoy se pueden encontrar muchos servidores con versiones no corregidas de este programa.
Los administradores de PCAnywhere que no hayan modificado el puerto por defecto, restringido el rango de direcciones que pueden conectarse, protegido el proceso con DEP, ASLR, o tomado otras consideraciones de seguridad básicas, tienen un grave problema hasta que actualicen. El fallo ya ha sido corregido y se recomienda actualizar a la última versión disponible lo antes posible.
Más información:
Security Advisories Relating to Symantec Products - Symantec pcAnywhere Remote Code Execution, Local Access File Tamperinghttp://www.symantec.com/security_response/securityupdates/detail.jsp?fid=security_advisory&pvid=security_advisory&year=2012&suid=20120124_00
Symantec PCAnywhere awhost32 Remote Code Execution Vulnerabilityhttp://www.zerodayinitiative.com/advisories/ZDI-12-018/

una-al-dia (15/05/2006) Grave vulnerabilidad en RealVNC
http://unaaldia.hispasec.com/2006/05/grave-vulnerabilidad-en-realvnc.html


Daniel Vacadvaca@hispasec.com
Sergio de los Santosssantos@hispasec.comTwitter: @ssantosv

El pasado día 17 de enero, Linus Torvalds hizo un commit para corregir una elevación de privilegios en el kernel Linux 2.6 (CVE-2012-0056). El fallo fue descubierto por Jüri Aedla y según comenta Torvalds en el propio parche, se debe a una incorrecta comprobación de privilegios al abrir el '/proc/#pid#/mem' de un proceso.


Este error no pasó desapercibido a Jason A. Donenfeld que ha escrito y publicado un interesante exploit. Lo ha bautizado como 'Mempodipper'.
Donenfeld estudió en detalle el proceso de explotación. De partida se encontró con que efectivamente la comprobación de permisos era débil y además, que la protección contra escritura en el espacio de memoria del proceso fue eliminada del código del kernel. De hecho puede leerse en el comentario del commit correspondiente, que se eliminaba la restricción porque no se consideraba un peligro la escritura en /proc/#pid#/mem.
Esto hace virtualmente vulnerables a los núcleos con versión 2.6.39 o superior.
Cómo funciona
Cuando se abre /proc/#pid#/mem se usa la función 'mem_open'. Dicha función almacena el 'self_exec_id' correspondiente al proceso que solicita la apertura. Esto se hace para comprobar posteriormente si son suficientes privilegios cuando se efectúan operaciones de lectura o escritura sobre el descriptor de fichero obtenido.
static int mem_open(struct inode* inode, struct file* file)
{
file->private_data = (void*)((long)current->self_exec_id);

En el caso de la operación de escritura se hace la comprobación del 'self_exec_id' además de llamar a 'check_mem_permission'. En teoría, para escribir en /proc/#pid#/mem, o se es el mismo proceso #pid# o el proceso tiene ciertos permisos especiales relacionados con ptrace.
static ssize_t mem_write(struct file * file, const char __user *buf,
size_t count, loff_t *ppos)
{
...
...

Se llama a 'check_mem_permission' y si 'mm' vuelve con error no se efectúa la operación:
mm = check_mem_permission(task);
copied = PTR_ERR(mm);
if (IS_ERR(mm))
goto out_free;
                        'check_mem_permission' simplemente llama a '__check_mem_permission' y como se observa dentro de su código efectúa la comprobación "task ==current":
static struct mm_struct *__check_mem_permission(struct task_struct *task)
{
struct mm_struct *mm;

mm = get_task_mm(task);
if (!mm)
return ERR_PTR(-EINVAL);

if (task == current)
return mm;

...
...

Si no coinciden devuelve error. Luego debe ser el mismo proceso el que escriba en su propia memoria y si queremos elevar privilegios necesitaríamos un proceso con 'suid'.
Primera aproximación al exploit
Donenfeld se figuró cómo hacer esto:
$ su "yeeeee haw I am a cowboy"
Unknown id: yeeeee haw I am a cowboy

Cualquier cosa que se escriba pasa por la memoria del proceso creado por 'su' (que posee 'suid'). Parecia obvio qué hacer:
Abrimos '/proc/self/mem' y obtenemos su descriptor de archivo. Ejecutamos 'dup2' para multiplexarlo con 'stderr'. Escribimos nuestro shellcode en él y ejecutando posteriormente con exec obtendríamos root... pero no.
Esto no iba a funcionar debido a que aun queda otra restricción más:
if (file->private_data != (void *)((long)current->self_exec_id))
goto out_mm;

El 'self_exec_id' del proceso que va a ejecutar la escritura 'exec' ha de ser el mismo que abrió originalmente '/proc/#pid#/mem', recordad más arriba cuando se llama a 'mem_open'.
¿Por qué ha cambiado 'self_exec_id'?
Cuando se llama a 'exec' el 'self_exec_id', es aumentado en 1 impidiendo que esto ocurra:
void setup_new_exec(struct linux_binprm * bprm)
{
...
...
current->self_exec_id++;

Resumiendo. No podemos abrir el '/proc/#pid#/mem' de un proceso cualquiera, hacer 'dup2' con 'stderr' y luego hacer 'exec' de un proceso con 'suid' para escribir allí, ya que al hacer 'exec' no van a coincidir los 'self_exec_id'.
Donenfeld solucionó esto de manera sencilla pero ingeniosa, muy ingeniosa.
El exploit
Se hace 'fork' de un proceso y en este hijo se ejecuta 'exec' a un nuevo proceso. De este modo el 'self_exec_id', que se ha heredado del padre, ahora tiene un valor de +1 con respecto al padre.
Ahora hacemos que el padre ejecute 'exec' sobre un proceso 'suid' que va a escribir nuestro shellcode. En este momento, al ejecutar 'exec' en el padre su 'self_exec_id' acaba de aumentar a +1 coincidiendo con el del hijo.
Mientras tanto en el proceso 'exec' que ha llamado el hijo se obtiene, al abrir, el descriptor del '/proc/#parent_pid#/mem'; y es posible abrirlo porque no existe restricción en la operación de apertura. Es decir, no van a ser comprobados los privilegios del 'exec' que ha creado el hijo.
En este momento tenemos un 'exec' del padre con un proceso 'suid' dispuesto a escribir el shellcode. Un 'exec' del hijo con un descriptor del '/proc/#pid#/mem' del padre y la salida 'stderr' acoplada a ese descriptor (llamada a 'dup2') y lo más importante, tenemos los 'self_exec_id' igualados por lo tanto la restricción ha sido evadida.
Solo queda que el hijo pase el descriptor al padre y éste va a escribir el shellcode allí ya que cuando llame a 'mem_write', como hemos dicho, las comprobaciones van a ser correctas.
Pero aún queda más, averiguar "dónde" se debe escribir en memoria para poder ejecutar de manera exitosa el shellcode. Se necesita una dirección fija de memoria, algo que podría ser complicado si se usa ASLR, pero Donenfeld observó que la mayoría de binarios 'su' de las distribuciones no están compilados con 'PIE'(Position-independent executable)
Podemos observarlo si hacemos:
$ readelf -h /bin/su | grep Type
  Type: EXEC (Executable file)

Como el mismo Donenfeld apunta, si el 'Type' fuera 'DYN' entonces si podría protegerse con ASLR debido a que el ejecutable permitiría ser reubicado en distintas posiciones de memoria. Al no ser el caso el desplazamiento en memoria siempre va a ser el mismo.
Buscando Donenfeld obtuvo la dirección 0x402178, correspondiente a una llamada a 'exit@plt'. Tan solo tenía que escribir en 0x402178 menos la longitud de la cadena 'Unknown id: ' y su shellcode se ejecutaría.
En definitiva, un exploit más interesante que la propia vulnerabilidad que explota y una muestra de ingenio por parte de Donenfeld al conseguir la explotación de la forma que hemos visto.
Más información:
Parche de Linus Torvaldshttp://goo.gl/Yllg1
Commit de la eliminación de la protección de escriturahttp://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=198214a7
* Linux Local Privilege Escalation via SUID /proc/pid/mem Writehttp://blog.zx2c4.com/749

David Garcíadgarcia@hispasec.com

Se ha solucionado un fallo en la implementación de SRTP (Secure Real-time Transport Protocol) que podría permitir a un atacante provocar una denegación de servicio en Asterisk.
Asterisk es una implementació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.
SRTP es la implementación segura (que proporciona cifrado e integridad) de RTP (Real-time Transport Protocol) usado principalmente para el envío de flujo multimedia.
El fallo permite a un atacante remoto provocar una denegación de servicio en el servidor. Para conseguirlo debe crear una conexión de vídeo segura y que el servidor no tenga soporte de vídeo activo, pero sí cargado el módulo (res_srtp) de SRTP.
A esta vulnerabilidad se le ha asignado el identificador CVE-2012-0885, y se encuentra solucionada en las versiones 1.8.8.2 y 10.0.1.
Más información:
Security Advisory:http://downloads.asterisk.org/pub/security/AST-2012-001.html
Fix:https://code.asterisk.org/code/browse/asterisk/trunk/channels/chan_sip.c?r1=351409&r2=351506

Victor Antonio Torrevtorre@hispasec.com

Mi padre fue obligado a hacer el servicio militar en Madrid, partiendo desde un pequeño pueblo de Málaga. Cuando era niño, mi abuela paterna me contó cómo le hacía llegar una pequeña cantidad de dinero a su hijo mientras él sufría "la mili" de los 60. Sus métodos, aunque simples y lógicos, me sorprendieron entonces. Hoy, en la era digital, lo que sorprende es que no se respeten las más mínimas medidas de seguridad con nuestros datos.
 Eran los 60. El servicio militar duraba casi dos años y la distancia entre el pueblo y Madrid era de más de 500 kilómetros. En la mili, a mi padre le pagan 35 pesetas mensuales (de las que se le descontaban siempre gastos en desperfectos ocasionados por otros en ventanas, mantas robadas...). Mi abuela, con enorme esfuerzo e ilusión, enviaba a mi padre desde el pueblo un billete de 5 pesetas cada semana con un método muy sencillo: Envolvía el billete entre hojas de papel escritas (a veces con una carta real, otras con simples garabatos) y metía todo en un sobre. No usaba el buzón del pueblo, sino que acudía directamente a la pequeña oficina de correos principal. De vez en cuando, cambiaba el remitente. Aunque suene simple, son métodos que encierran un profundo conocimiento del sistema de correos, de las amenazas y sobre todo, que intenta mitigar los riesgos. Veamos por qué:

• Mientras que otros compañeros de cuartel recibían mensualmente entre 20 y 30 pesetas en una sola partida, mi abuela enviaba el dinero una vez cada semana, y siempre un billete de 5 pesetas. No más. Esto permitía que, si el dinero era interceptado, siempre se perdiera como máximo esa cantidad. Aunque algo más caro (gastaba más en sellos) invirtió en seguridad y en una especie de "divide y vencerás". Esto proporcionaba a mi padre un flujo semanal de dinero que toleraba alguna pérdida ocasional del sobre.     
• Evitaba riesgos conocidos. Sabía de la mala reputación del cartero del pueblo (un poco borracho) así que no usaba el buzón a pie de calle. Acudía a la oficina donde la persona tras la ventanilla le ofrecía mucha más confianza. El pequeño esfuerzo de caminar un par de calles eliminaba una potencial amenaza de la ecuación. Además, (aunque en aquel momento no existía el vandalismo en el pueblo) evitaba otros riesgos inherentes al buzón a pie de calle.      
• Impedía, al envolver el billete en otras hojas de papel, que fuera visto al trasluz. No se fiaba de que, una vez en el cuartel, alguien decidiese comprobar las cartas antes de entregarlas en mano. Así que el simple método de interponer hojas entre el sobre y el dinero, mitigaba eficazmente este riesgo.      
• De vez en cuando, cambiaba el remitente. A veces aparecía ella, a veces mi abuelo, en ocasiones otro familiar. Intentaba así que la persona que repartiese el correo en el cuartel, encontrara un patrón fijo en su comportamiento y envío semanal. Entre semana, enviaba a veces cartas sin dinero en su interior.

De esta manera mi abuela, a pesar de sus limitaciones culturales y económicas (no podía permitirse comisiones por giros postales, o cartas certificadas), a pesar de las imperfecciones del método, conseguía enviar dinero a su hijo de una manera razonablemente segura y económica para la época. Y lo hacía por tres razones simples:

• Con el dinero no se jugaba. Era un valor que merecía la pena proteger, y por el que incluso merecía la pena invertir modestamente (tiempo en ir a la oficina, más sellos para envíos semanales, etc.). Se tomó su tiempo para idear "un plan" razonado y eficaz dentro de sus posibilidades económicas.
    
• Conocía el funcionamiento del correo y sus riesgos (qué clase de cartero recogía el buzón, cómo se repartían las cartas en el cuartel...).
     
• Sabía que si no se preocupaba de su hijo y por el dinero, no lo haría nadie por ella. Las estrecheces económicas del momento afilaban la picaresca de muchos. Desconfiaba (con razón) por principios.

 En la era digital, sin embargo, parecemos esperar que sean los propios sistemas informáticos los que nos protejan de forma automática. Fallamos en las premisas que mi abuela mantenía muy presentes: Ni valoramos lo suficiente nuestros datos en la Red, ni nos preocupamos por entender el funcionamiento... y exigimos que sea la propia tecnología la que nos proteja de ella misma. Esta es la receta para fallar estrepitosamente en el campo de la seguridad. En la era digital, ¿se suelen establecer las mínimas medidas oportunas? ¿Utilizan los usuarios medios de mensajería cifrados?, ¿Instalan software preocupándose de su procedencia o informándose sobre qué hace realmente en su sistema operativo?; ¿Hacen copias de respaldo?... En general, parece que les resulta tedioso aprender cómo funciona el complejo mundo de la seguridad, prefieren restar importancia a sus datos ("¿a quién le va importar lo que hablo por WhatsApp, o mis datos en Facebook...?") antes que invertir en su protección. Si mi abuela fuese hoy como un usuario medio de Internet, estaría enviando a mi padre, a través del buzón de la calle, postales con un billete de 100 euros pegado con celo. Aunque parezca absurdo, es muy parecido al efecto que conseguimos hoy en día en Internet al infravalorar la protección de nuestros datos. Creo que habría que aprender algo de mi abuela y sus billetes de 5 pesetas.
 
 
 
 Sergio de los Santosssantos@hispasec.comTwitter: @ssantosv
 

RootedLabs es un conjunto de actividades formativas que se llevarán a cabo en febrero de 2012 en Madrid, durante los tres días previos al congreso de seguridad informática RootedCON. Estos laboratorios de alto nivel técnico y enfoque eminentemente práctico, impartido por reputados profesionales del sector, abarcarán diferentes disciplinas relacionadas con la seguridad. Este año participa Sergio de los Santos de Hispasec.

La agenda de RootedLabs de 2012 se compone de la siguiente manera:
·               Lunes, 27 de febrero 2012,
Joxean Koret - Fundamentos de Ingeniería Inversa I 
Raúl Siles - Analizando y explotando aplicaciones web con Samurai-WTF
Juan Luís G. Rambla - Ataques en redes de datos IPv4 e IPv6
   ·               Martes, 28 de febrero 2012
Joxean Koret - Ingeniería Inversa Práctica Básica
Alejandro Ramos - Iniciación al Pentest
Juan Garrido - Análisis Forense de iDevices (iPhone, iPad e iPod Touch)
   ·               Miércoles, 29 de febrero 2012
Sergio de los Santos - Máxima Seguridad en Windows
Sebastián Guerrero - Ingeniería Inversa en Android
Chema Alonso y Daniel Romero- Pentesting Web Applications
Para asegurar la calidad y el dinamismo de las actividades formativas, las plazas de cada uno de los laboratorios están limitadas.
Cada laboratorio tendrá una duración de un día completo y en él está incluido el desayuno y la comida. El precio es de 200 euros + IVA por cada uno. Las instrucciones para inscribirse y las plazas restantes se encuentra en:http://labs.rootedcon.es

Laboratorio Hispaseclaboratorio@hispasec.com

Esta semana Apache ha publicado la resolución de dos vulnerabilidades remotas calificadas como de nivel "importante" que afectarían a varias versiones de Apache Tomcat.
Apache Tomcat es un servidor web que funciona como contenedor de servlets, desarrollado en código abierto por la Apache Software Foundation. Tomcat implementa las especificaciones de las tecnologías servlets Java y de páginas JSP.
A continuación se detallan los errores:
·              Denegación de servicio remota (CVE-2012-0022) relacionada con las colisiones en las tablas hash. Este fallo ha afectado a otros fabricantes. Debido a una incorrecta gestión de las colisiones en las tablas hash, un atacante remoto podría generar una denegación de servicio a través del envío masivo de parámetros especialmente manipulados. Las versiones afectadas son la 5, 6 y 7 y para solucionar dicha vulnerabilidad deben actualizar a las siguientes:
Usuarios de Tomcat 7.0.x deben aplicar la revisión 7.0.23 o posterior.
Usuarios de Tomcat 6.0.x deben aplicar la revisión 6.0.35 o posterior.
Usuarios de Tomcat 5.5.x deben aplicar la revisión 5.5.35 o posterior.
·              Revelación de información sensible (CVE-2011-3375) debido a un error en el reciclado de objetos que podría volver visibles datos como IPs remotas o cabeceras HTTP a través de peticiones especialmente manipuladas. Las versiones afectadas son la 6 y 7 y para solucionar la vulnerabilidad deben actualizar a las siguientes:
Usuarios de Tomcat 7.0.x deben aplicar la revisión 7.0.22 o posterior.
Usuarios de Tomcat 6.0.x deben aplicar la revisión 6.0.35 o posterior.
Más información:
Apache Tomcat 7.x vulnerabilitieshttp://tomcat.apache.org/security-7.htmlhttp://tomcat.apache.org/security-6.htmlhttp://tomcat.apache.org/security-5.html

José Mesa Orihuelajmesa@hispasec.com

Oracle Systems ha publicado, como tenía establecido para el 17 de enero, un nuevo paquete de actualizaciones que afectaban a gran parte de sus productos, en especial a Oracle Database, MySQL y Solaris.
Ofrecemos un listado completo de los productos afectados:
·         Oracle Database Oracle Database 11g Release 2, versiones 11.2.0.2, 11.2.0.3
Oracle Database 11g Release 1, versión 11.1.0.7
Oracle Database 10g Release 1, versión 10.1.0.5
Oracle Database 10g Release 2, versiones 10.2.0.3, 10.2.0.4, 10.2.0.5
   ·         Fusion Middleware
Oracle WebLogic Server, versiones 9.2.4, 10.0.2, 11gR1 (10.3.3, 10.3.4, 10.3.5)
Oracle Outside In Technology, versiones 8.3.5, 8.3.7
Oracle Application Server 10g Release 3, versión 10.1.3.5.0
Oracle Fusion Middleware 11g Release 1, versiones 11.1.1.3.0,11.1.1.4.0, 11.1.1.5.0
    ·         E-Business Suite
Oracle E-Business Suite Release 11i, versión 11.5.10.2
Oracle E-Business Suite Release 12, versiones 12.1.2, 12.1.3
   ·         Oracle Supply Chain
Oracle Transportation Management, versiones 5.5, 6.0, 6.1, 6.2
    ·         PeopleSoft
Oracle PeopleSoft Enterprise PeopleTools, versión 8.52
Oracle PeopleSoft Enterprise HCM, versiones 8.9, 9.0, 9.1
Oracle PeopleSoft Enterprise CRM, versión 8.9
    ·         JDEdwards
Oracle JDEdwards, versión 8.98
    ·         Oracle Sun Product Suite
Oracle Communications Unified 7.0
Sun Java System Application Server 8.1, 8.2
GlassFish Enterprise Server 2.1.1, 3.0.1, 3.1.1
Communications Server 2.0
Solaris versiones 8, 9, 10, 11 Express
    ·         Oracle Virtualization Product Suite
Oracle Virtual Desktop Infrastructure, versión 3.2
Oracle VM VirtualBox, versión 4.1
     ·         Oracle MySQL Product Suite
Oracle MySQL Server, versiones 5.0, 5.1, 5.5
En resumen las vulnerabilidades pueden considerarse de nivel medio-bajo. La mayoría de ellas se catalogan como denegaciones de servicio (Oracle DB, Solaris, MySQL y servicios relacionados con HTTP), mientras que las más elevadas son las que afectan a Oracle WebCenter Content, con una gravedad según la puntuación CVSS de 6.4 (CVE-2012-0083) y las de Solaris (CVE-2012-0094, CVE-2012-0100) con 7.8 y 6.8 respectivamente.
A continuación ofrecemos una relación de productos y el número de vulnerabilidades corregidas:

• Oracle DB: dos parches que actualizan sendas denegaciones de servicio de remotas.
• Fusion Middleware: 11 vulnerabilidades, 8 de ellas explotables remotamente.
• E-Business Suite: tres vulnerabilidades relacionadas con el acceso a información confidencial y posible modificación de los datos.
• Oracle Supply Chain: una denegación de servicio explotable remotamente.
• PeopleSoft: seis vulnerabilidades relacionadas con el acceso a información confidencial y posible modificación de los datos.
• JD Edwards: ocho vulnerabilidades relacionadas con el acceso a información confidencial y posible modificación de los datos.
• Oracle Sun Products: 17 vulnerabilidades en total, 10 relacionadas con denegaciones de servicio y el resto  con el acceso a información confidencial y posible modificación de los datos.
• Oracle Virtualization Product Suite: tres vulnerabilidades relacionadas con el acceso a información confidencial y posible modificación de los datos.
• Oracle MySQL Product Suite: la mayor actualización, con 37 vulnerabilidades relacionadas en gran medida con denegaciones de servicio, acceso a información confidencial y posible modificación de los datos.

Debido a la amplia cuantía de sistemas afectados recomendamos la actualización de los mismos mediante los parches y guías de actualización facilitados.
Más información:
Oracle Critical Patch Update Advisory - January 2012http://www.oracle.com/technetwork/topics/security/cpujan2012-366304.html

José Mesa Orihuelajmesa@hispasec.com

El 15 de enero de 2002, Bill Gates envió un correo a todos sus empleados. Ya no podía más. La seguridad debía convertirse en una prioridad en todos sus productos. Bajo el nombre de Strategic Technology Protection Program (STPP) Microsoft presentó una iniciativa que pretendía mejorar la seguridad de sus sistemas operativos y su respuesta ante nuevos problemas de seguridad. Nació la "Trustworthy Computing". Diez años después... ¿ha sido un éxito o un fracaso?
Vista y 7
Aunque Microsoft afirme que Vista se empezó desde cero, obviamente no es verdad. Contiene código antiguo heredado, pero sí que es cierto que al menos se replantearon muy seriamente hacia dónde iba su desarrollo y descartaron buena parte del trabajo realizado antes del anuncio de Gates. Vista es un primer acercamiento a un gran sistema operativo extremadamente seguro por defecto. Además, se añadieron importantes herramientas para mejorar su seguridad, algunas no entendidas, algunas desactivadas. UAC fue un caso claro de una buena idea no entendida por el público.
ASLR, DEP, MIC, AppLocker, cortafuegos saliente... Vista materializaba un sistema operativo muy seguro, puntero, pero que empezaba a ser muy complejo para el usuario y cometió errores. Con Windows 7 Microsoft tuvo que dar un paso atrás con UAC, pero ha sido mejor acogido por la mayoría, aprendiendo de los errores cometidos.
Otros servidores
Donde radica el mayor éxito de Microsoft y su seguridad sea quizás en sus servidores. El cambio entre la tecnología anterior a 2002 y la actual ha sido realmente sorprendente. Si por aquel entonces sus servidores eran completamente vulnerables y los fallos constantes, los principales servidores de hoy en día de Microsoft se pueden considerar muy seguros. IIS, Microsoft SQL Server y Exchange sufren de muy pocos fallos de seguridad al año. Desde 2006, Microsoft Exchange e IIS han tenido que corregir solo 11 vulnerabilidades (la mayoría leves) cada uno. Microsoft SQL Server ha solucionado seis vulnerabilidades en más de cinco años. La mayor parte, de gravedad baja.
Conclusiones
 Gráfico de Microsoft que muestra la progresión de la
iniciativa Trustworthy Computing durante los últimos
10 años (pulsa para ampliar) En conjunto, se puede hablar de un éxito importante de la Trustworthy Computing, siempre que se entiendan algunos aspectos. Han pasado diez años y todavía, Microsoft tiene que lidiar y mantener código antiguo del que quiere deshacerse cuanto antes. En cuanto XP desaparezca, Microsoft solo soportará software que ha sido desarrollado por entero bajo esta nueva filosofía, y entonces los resultados globales serán mucho mejores. Si alguien pensaba que, de un día para otro, la seguridad global iba a mejorar, estaba equivocado. Iba a llevar su tiempo, y todavía queda por hacer, puesto que no es un campo "estático". A medida que se han solucionado grandes errores cometidos en el pasado, han aparecido nuevas amenazas. Al menos, Microsoft aguanta el chaparrón (que es especialmente insistente en sus productos) con cierta entereza. Sin aquel cambio en 2002, sus productos no hubieran sobrevivido.
Otro factor que indica un importante éxito del modelo ha sido el "plagio" que se ha hecho desde muchas compañías. El sistema de actualizaciones automático y periódico, ha sido imitado más tarde por Oracle, Cisco, Adobe... Aunque a veces suponga un hipotético retraso, la planificación de los parches es una importante ventaja para los administradores de grandes compañías y, no nos engañemos, el negocio de Microsoft está en las grandes compañías, por encima de los usuarios domésticos.
En diez años ha avanzado mucho, hasta el punto de convertirse en el sistema operativo que más medidas de seguridad incorpora de serie. Pero su peor fracaso es quizás que, si bien la iniciativa pretendía recuperar la confianza del público en general, esto no se ha conseguido por completo. A pesar de los esfuerzos y los datos, la percepción de que Microsoft en general y Windows en particular se parecen todavía a las versiones de los 90 pesa mucho entre una buena parte de los usuarios.
Más información:
Memo from Bill Gateshttp://www.microsoft.com/Presspass/Features/2012/jan12/GatesMemo.mspx
Microsoft. Trustworthy Computinghttp://www.microsoft.com/twc

Sergio de los Santosssantos@hispasec.comTwitter: @ssantosv

El 15 de enero de 2002, Bill Gates envió un correo a todos sus empleados. Ya no podía más. La seguridad debía convertirse en una prioridad en todos sus productos. Bajo el nombre de Strategic Technology Protection Program (STPP) Microsoft presentó una iniciativa que pretendía mejorar la seguridad de sus sistemas operativos y su respuesta ante nuevos problemas de seguridad. Nació la "Trustworthy Computing". Diez años después... ¿ha sido un éxito o un fracaso?
El correo enviado por el mismísimo Gates en 2002 se hizo bastante famoso. Era el toque de atención, el golpe de timón que, costase lo que costase (y de hecho fue muy caro) debía cambiar el rumbo de Microsoft. Entre otras muchas propuestas, el programa STPP pretendía proporcionar herramientas gratuitas y soporte técnico a empresas de cualquier tamaño, instaurar un teléfono de asistencia gratuita para ayudar a los clientes a resolver incidencias por malware, asesoramiento acerca del modo de instalar actualizaciones de seguridad... También fue entonces cuando Microsoft se comprometió a publicar de forma sistemática y periódica los conjuntos de actualizaciones de seguridad. Se estableció la idea de un sistema central de gestión de actualizaciones (lo que mas tarde se convertiría en los exitosos Software Update Services, Windows Software Update Services, Microsoft Operations Manager...).
Pero una de los cimientos más importantes que sentó fue un SDL (Security Development Lifecycle) para el desarrollo de su software. De hecho, este nuevo método de programación centrado en la seguridad fue la causa del retraso de Windows Vista. Si bien el periodo de publicación de sistemas operativos Windows venía siendo cada tres años, Vista tardó casi el doble.
Microsoft se tomó por fin en serio su "Trustworthy Computing" que anunció tras llegar a lo que (por aquél entonces) se creía techo de la inseguridad y problemas acarreados por el sistema operativo Windows y sus productos.
Service Pack 2Poco después, cuando todavía comenzaba a dar los primeros pasos hacia la implementación real de este nuevo concepto, virus como Blaster fueron mucho más allá y la situación se volvería casi insostenible. Fue un duro golpe, pero al menos supuso una de las últimas infecciones por gusano a gran escala.

Gráfico de Microsoft que muestra la progresión de la
iniciativa Trustworthy Computing durante los últimos
10 años (pulsa para ampliar)La primera materialización del Trustworthy Computing se produjo con el Service Pack 2 para XP en el verano de 2004. Detuvieron el desarrollo de lo que iba a ser su sistema operativo y sacaron un Service Pack con grandes avances en seguridad. El simple hecho de que esta actualización activase el cortafuegos por defecto, contuvo para siempre una buena parte de los gusanos. Fue un primer paso muy positivo. Como toda actualización importante, tuvo sus críticas. Muchos programas dejaron de funcionar por el simple hecho de no poder acceder a ciertos puertos. Fue un proceso de adaptación duro.
El Service Pack 2 también supuso una centralización de la seguridad del sistema operativo y, sobre todo, se empezó a olvidar la filosofía de "activado por defecto". Por ejemplo el fatídico servicio "Mensajero", que permitía que llegara spam en forma de mensaje de red, se deshabilitó por defecto.
Uno de los errores cometidos por entonces, fue mantener Internet Explorer 6, y no evolucionar a tiempo hacia un modelo donde el navegador cobraba cada vez mayor importancia. Tuvo que venir Firefox para comerse cuota de mercado y hacer reaccionar a Microsoft.
(Continúa en http://unaaldia.hispasec.com/2012/01/diez-anos-de-trustworthy-computing-en_19.html)

Más información:
Memo from Bill Gateshttp://www.microsoft.com/Presspass/Features/2012/jan12/GatesMemo.mspx
Microsoft. Trustworthy Computinghttp://www.microsoft.com/twc


Sergio de los Santosssantos@hispasec.comTwitter: @ssantosv

El Internet Systems Consortium (ISC) ha publicado una alerta de seguridad en referencia a una denegación de servicio en el servidor DHCP.
El protocolo DHCP (Dynamic Host Configuration Protocol) tiene como objetivo la asignación automática de direcciones IP y otros parámetros de la configuración de red en los sistemas clientes.
En una red que utilice este protocolo, cada vez que un equipo se inicia envía un mensaje de broadcast a la red para solicitar la concesión de una dirección. El servidor DHCP de la red es el encargado de recibir este mensaje y conceder, si procede, la dirección. De la misma forma, en el momento en que caduque la concesión de la dirección IP, el cliente solicita al servidor DHCP la renovación de la concesión.
La utilización de DHCP en una red facilita las tareas administración de configuración de los parámetros de comunicaciones en los equipos, ya que todo se realiza de forma centralizada. Además, al ser un sistema automático, se evitan los problemas originados por la duplicación de direcciones IP o la modificación de la configuración por parte de las estaciones clientes.
Una de las versiones más utilizadas del protocolo DHCP es el servidor desarrollado por el Internet Software Consortium (ISC), una organización sin ánimo de lucro dedicada al desarrollo de las implementaciones de  referencia de los principales protocolos básicos utilizados en Internet.
El fallo se da a la hora de manejar estructuras DHCPv6 (esto es, al trabajar con direcciones IPv6) combinados en la red con DNS dinámicos. Se puede hacer que el servidor dé un error de segmentación bajo ciertas circunstancias, lo que provocaría que dejase de responder, si se envían paquetes especialmente manipulados relacionados con la actualización del estado de las concesiones.
Las versiones afectadas serían las 4.2.2, 4.2.3 y 4.2.3-P1 por lo que el ISC recomienda actualizar a la versión 4.2.3-P2 que puede ser descargada desde http://www.isc.org/software/dhcp.
Más información:

An Error in DDNS Processing of DHCPv6 Leases Can Cause a Crash in ISC dhcpdhttp://www.isc.org/software/dhcp/advisories/cve-2011-4868

Borja Luacesbluaces@hispasec.com

Larry W. Cashdollar ha publicado tres problemas de seguridad hallados en el CMS Mambo.
Mambo es un popular sistema de portales CMS (Content Management System o Sistema de Gestión de Contenidos) basado en el lenguaje de programación PHP y base de datos de código abierto, para el que existen gran cantidad de módulos y componentes adicionales.
El primero de los fallos hace referencia al método empleado por Mambo para almacenar las diferentes contraseñas empleadas por el CMS.
En primer lugar, el programa almacena las contraseñas de la base de datos MySql en texto claro en la ruta raíz de la web. Esto, en principio, puede ser leído por cualquier usuario local.
Por otro lado, Mambo también almacena el hash de la contraseña de administrador en el fichero "configuration.php" y recomienda los permisos 644 para este archivo. Para más seguridad, deberían ser permisos 600 y ponerle como dueño al usuario sobre el que corre el servidor.
La segunda de las vulnerabilidades reportadas podría causar una denegación de servicio. Al parecer, no es necesario autenticarse para poder iniciar el proceso de subida de ficheros. Aunque el fichero no será almacenado, se consumirán recursos y ancho de banda del sistema.
Finalmente la última de las vulnerabilidades reportadas hace referencia a una revelación de ruta a través del error que aparece al acceder a ciertos ficheros incluidos en la distribución
La versión afectada por estas vulnerabilidades sería la 4.6.5 aunque existe la posibilidad de otras versiones afectadas.
Más información:
Mambo CMS 4.6.5 Denial Of Service / Disclosurehttp://packetstormsecurity.org/files/108462/mambocms465-permdosdisclose.txt

Borja Luacesbluaces@hispasec.com

Wireshark ha publicado tres boletines de seguridad informando de múltiples vulnerabilidades que afectan a las ramas 1.4.x y 1.6.x.
Wireshark es una aplicación de auditoría orientada al análisis de tráfico en redes. Su popularidad es muy elevada, puesto que soporta una gran cantidad de protocolos y es de fácil manejo. Además Wireshark es software libre (sujeto a licencia GPL) y se ejecuta sobre la mayoría de sistemas operativos Unix y compatibles, así como en Microsoft Windows.
A continuación, los identificativos de los boletines publicados y una breve descripción.
wpna-sec-2012-01: Existe un problema a la hora de comprobar los tamaños de registros cuando se procesan muchos formatos de captura. Si la víctima abre estas capturas, el programa dejaría de funcionar.
wnpa-sec-2012-02: Existe un error de comprobación en la función "bytes_to_hexstr_punct" localizada en el fichero "epan/to_str.c" que podría causar una referencia a puntero nulo. Un atacante remoto podría aprovechar esto para causar una denegación de servicio a través del envío de un paquete especialmente manipulado.
wnpa-sec-2012-03: Existe un error de desbordamiento de memoria en el archivo "/epan/dissectors/packet-rlc.c" del disector RLC. Un atacante remoto podría causar una denegación de servicio a través de un fichero especialmente manipulado.
Las vulnerabilidades se han corregido en las versiones 1.4.11 y 1.6.5 por lo que se recomienda la actualización desdehttp://www.wireshark.org/download.html
Más información:
wnpa-sec-2012-01http://www.wireshark.org/security/wnpa-sec-2012-01.html
wnpa-sec-2012-02http://www.wireshark.org/security/wnpa-sec-2012-02.html
wnpa-sec-2012-3http://www.wireshark.org/security/wnpa-sec-2012-03.html

Borja Luacesbluaces@hispasec.com