Desbordamiento de búfer en CiscoWorks Common Services

Cisco ha confirmado la existencia de una vulnerabilidad en CiscoWorks Common Services para Oracle Solaris y Microsoft Windows, que podría permitir la ejecución de código arbitrario a atacantes remotos sin autenticar.

El problema afecta a múltiples productos:
CiscoWorks Common Services versiones 3.0.5 a 3.3.0
CiscoWorks QoS Policy Manager versión 4.0
CiscoWorks QoS Policy Manager versión 4.0.1
CiscoWorks QoS Policy Manager versión 4.0.2
CiscoWorks LAN Management Solution versión 2.6 Update
CiscoWorks LAN Management Solution versión 3.0
CiscoWorks LAN Management Solution versión 3.0 (Update Diciembre 2007)
CiscoWorks LAN Management Solution versión 3.2
Cisco Unified Operations Manager versión 2.0.1
Cisco Unified Operations Manager versión 2.0.2
Cisco Unified Operations Manager versión 2.0.3
Cisco Unified Service Monitor versión 2.0.1
Cisco Security Manager versión 3.0.2
Cisco Security Manager versión 3.1
Cisco Security Manager versión 3.1.1
Cisco Security Manager versión 3.2
Cisco TelePresence Readiness Assessment Manager versión 1.0

CiscoWorks Common Services es un conjunto de servicios de administración compartidos por las aplicaciones de gestión de redes de Cisco.

Se ha encontrado un desbordamiento de búfer explotable de forma remota en el código de autenticación del módulo de servidor web de CiscoWorks Common Services. Esto podría permitir a un atacante remoto sin autenticar la ejecución de código arbitrario de forma remota con privilegios de administrador.

Cisco ha publicado actualizaciones para evitar esta vulnerabilidad, que queda corregida en CiscoWorks Common Services versión 4.0 y con los siguientes parches:

cwcs33-sol-CSCti41352.tar  para Oracle Solaris
cwcs33-win-CSCti41352.zip – para Microsoft Windows
Que pueden descargarse desde:
http://tools.cisco.com/support/downloads/pub/Redirect.x?mdfid=268439477
(En “Routing and Switching Management > CiscoWorks LAN Management Solution Products > CiscoWorks Common Services Software > CiscoWorks Common Services Software 3.3”)

Microsoft publica una alerta por vulnerabilidad 0-day en Internet Explorer

Microsoft acaba de publicar un aviso de seguridad para informar y alertar sobre una nueva vulnerabilidad descubierta recientemente en su navegador y que podría permitir la ejecución remota de código arbitrario.

Se anuncian como vulnerables las versiones de Internet Explorer 6, 7 y 8, mientras que la beta de Internet Explorer 9 se libra de este problema. Según reconoce Microsoft en su aviso, en la actualidad la vulnerabilidad se está explotando de forma activa.

El problema reside en que Internet Explorer al procesar determinadas combinaciones de hojas de estilo asigna la memoria de forma incorrecta. Concretamente en el módulo “mshtml.dll” al procesar el atributo “clip” con una posición determinada de las CSS (Cascading Style Sheets). Esto podría permitir a un atacante remoto la ejecución de código arbitrario a través de una página específicamente manipulada.

Microsoft se encuentra desarrollando las actualizaciones necesarias para corregir este problema, mientras tanto como contramedida se recomienda anular las hojas de estilo con una CSS definida por el usuario, asignar las zonas de seguridad del navegador a un nivel Alto, implementar el Enhanced Mitigation Experience Toolkit (EMET) o habilitar Data Execution Prevention (DEP) para Internet Explorer 7.

 

Microsoft Security Advisory (2458511)
Vulnerability in Internet Explorer Could Allow Remote Code Execution
http://www.microsoft.com/technet/security/advisory/2458511.mspx

DEP, EMET protect against attacks on the latest Internet Explorer vulnerability
http://blogs.technet.com/b/srd/archive/2010/11/03/dep-emet-protect-against-attacks-on-the-latest-internet-explorer-vulnerability.aspx

Bancos y SSL ¿Quien aprueba?

A estas alturas todo el mundo está familiarizado con SSL, es la capa de seguridad mediante cifrado que incorpora HTTP para proteger las comunicaciones.

Bajo las siglas SSL se encuentra un complejo entramado de longitudes, algoritmos y tipos de certificados. La forma en la que se combinan estos parámetros hace que un servidor ofrezca una conexión SSL mas o menos robusta. Como tantas cosas en el mundo de la seguridad, se cumple el axioma: mas robusto = mas inversión.

Teóricamente y sobre el papel la banca online debería ser ejemplo a la hora de implementar SSL en sus servicios por dos motivos:

1- Son entidades que manejan mucha inversión
2- El tipo de actividad a la que se dedican requiere todas las garantías

Pero … ¿Es así? Hemos realizado un estudio sobre los principales portales de banca online Españoles analizando diversos parámetros para evaluar la robustez del servicio.

Criterios evaluados:

  • Soporte a SSL v2: Se puntúa como Bien no dar soporte a negociaciones SSL v2 (obsoletas y con numerosos vectores inseguros) y Mal si el servidor lo admite
  • Tipo de certificado: Puntúa como Mal tener un certificado SSL normal y corriente (ver post sobre Agencia Pituitaria) y bien tener un certificado con Validación extendida (mucho mas riguroso y caro)
  • Longitud de la clave RSA del certificado: Puntúa como Mal tener un certificado de 1024 o menos y Bien tener 2048
  • Soporte de algoritmos ‘débiles’: Se entiende por algoritmo débil aquel que cuya longitud de clave es 56 o 64 bits y puntúa como Mal admitir esos algoritmos para cifrar la conexión y Bien no hacerlo

Los resultados (click en la imagen para mayor definición):


Destaca sobremanera el caso del BBVA, que ha puntuado en todo Mal, incluso sospecho que el hecho de que la longitud de su clave pública sea de 1023 y no 1024 se deba a un bug en la generación del CSR (hay documentados bugs de ese tipo en algunas plataformas).

Por contra, hay que destacar muy positivamente al Banco Popular, Bankinter, Deutsche Bank y Bancaja que sacan un Sobresaliente merecido.

Por último mencionaré de soslayo algo que me llama poderosamente la atención. En el mundo bancario existe una normativa llamada PCI-DSS que especifica niveles de seguridad y buenas prácticas en las entidades bancarias. En el punto 4.1 dice: ‘Utilice criptografía y protocolos de seguridad sólidos como SSL/TLS o IPSEC para salvaguardar los datos confidenciales de los titulares de las tarjetas durante su transmisión a través de redes públicas abiertas‘ Y mas concretamente: ‘Controle que se implemente la solidez de cifrado adecuada para la metodología que se utiliza

Esto, que suena tan vago e inconcreto, por lo general se suele interpretar como el NO uso de SSL v2 y el NO uso de algoritmos débiles.

Ficha técnica
Urls analizadas:

Banco Pastor https://pastornetparticulares.bancopastor.es/
Banco Popular https://www2.bancopopular.es
Banco Santander https://www.gruposantander.es
Banesto https://extranet.banesto.es
Bankinter https://www.bankinter.com/
BBVA https://www.bbva.es
Deutsche Bank https://ww3.deutsche-bank.es
Citibank https://www.production.citibank.es
ING https://www.ingdirect.es/
Bancaja https://www.bancaja.es/
Caja España https://www.cajaespana.net/
Caja Madrid https://oi.cajamadrid.es/
La Caixa http://portal.lacaixa.es/

Metodología empleada:

Verificación SSL v2:
openssl s_client -ssl2 -connect servidor:443

Tipo de certificado (Normal / EV):
Cualquier navegador actual (Chrome, Firefox, IE)

Longitud clave pública:
openssl s_client -connect servidor:443

Soporte de algoritmos débiles:
openssl s_client -cipher LOW:EXP -connect servidor:443

El puerto 3268 del catálogo global no responde

La Herramienta Microsoft® Exchange Server Analyzer consulta el servicio de directorio de Active Directory® para determinar el valor del atributo isGlobalCatalogReady de este servidor. El valor True en este atributo indica que el servidor de directorio también es un servidor de catálogo global en funcionamiento, mientras que el valor False indica que el servidor de directorio no es un servidor de catálogo global.

A continuación, la herramienta se conecta al puerto 3268 del servidor de Exchange para comprobar que dicho puerto responde.

La herramienta muestra un mensaje de error si se dan las siguientes condiciones:

  • El servidor es un servidor de catálogo global.
  • El puerto 3268 no responde.
Aa995905.note(es-es,EXCHG.80).gifNota:
Este mensaje puede ser erróneo si hay un servidor de seguridad entre el equipo que ejecuta la Herramienta Exchange Server Analyzer y el servidor de catálogo global.

Este problema se suele dar cuando la casilla de verificación del servidor de catálogo global se ha activado, pero el servidor no se ha reiniciado.

Para corregir este problema

  • Reinicie el servidor.

El servidor de Exchange denominado para este acuerdo de conexión no existe en la organización

La Herramienta Microsoft® Exchange Server Analyzer consulta el servicio de directorio de Active Directory® para determinar el valor del atributo msExchServer2NetworkAddress en cada objeto de acuerdo de conexión. El atributo msExchServer2NetworkAddress representa la dirección de red del servidor que participa en este acuerdo de conexión. La herramienta enumera los grupos administrativos de Active Directory para comprobar si el nombre del servidor que se muestra en el acuerdo de conexión es miembro de un grupo administrativo. Si este nombre de servidor no aparece en un grupo administrativo, se muestra un error.

Este error indica un acuerdo de conexión huérfano. El motivo puede ser un equipo con Exchange Server que se haya decomisado. Si el equipo con Exchange Server se ha eliminado de la organización, deberá cambiar el nombre del servidor de Exchange en la ficha Conexiones de las propiedades del acuerdo de conexión en la herramienta de administración Conector de Active Directory (ACD). Si el servidor de Exchange en cuestión no está conectado por motivos de mantenimiento o por cualquier otra razón conocida, puede obviar este error.

Para corregir este error
  1. Haga clic en Inicio, Programas, Herramientas administrativas y, a continuación, seleccione Conector de Active Directory.
  2. En el panel izquierdo, haga clic en el servidor ADC que aloja el acuerdo de conexión que desea modificar.
  3. En el panel derecho, haga clic con el botón secundario en el acuerdo de conexión que desea modificar y, a continuación, haga clic en Propiedades.
  4. Haga clic en la ficha Conexiones.
  5. Cambie el nombre del servidor utilizado para las conexiones por otro que sí exista.

La función FSMO de emulador PDC no ha respondido

La Herramienta Microsoft® Exchange Server Analyzer consulta el servicio de directorio de Active Directory® para determinar el valor del atributo fSMORoleOwner de la raíz de la partición de directorio de dominio en el Contexto de nombres de dominio. Por ejemplo, en un dominio llamado contoso.com, fSMORoleOwner para el emulador de controlador de dominio principal (PDC) es un atributo de DC=contoso,DC=com. La herramienta intenta entonces abrir una conexión de Protocolo ligero de acceso a directorios (LDAP) al puerto TCP 389 en el controlador de dominio que actualmente tiene esta función. En caso de no poder conectarse a este controlador de dominio, se muestra un error.

El emulador PDC actúa como controlador de dominio principal para la compatibilidad con versiones anteriores de sistemas operativos Microsoft Windows®. Microsoft Windows 2000 Server y Microsoft Windows Server™ 2003 interoperan con estaciones de trabajo, servidores miembros y controladores de dominio de reserva de Microsoft Windows NT®. El PDC de un dominio de Microsoft Windows NT 3.51 o de Microsoft Windows NT 4.0 es responsable de:

  • Procesar los cambios de contraseña de usuarios y equipos
  • Replicar las actualizaciones en los controladores de dominio de reserva
  • Ejecutar el Examinador principal de dominio

En cualquier momento, la función de maestro de emulador PDC sólo se puede asignar a un controlador de dominio de cada dominio.

Para corregir este error
  1. Compruebe que el servidor de directorio especificado en el error está conectado y que los servidores de Exchange de su organización pueden obtener acceso a él.
  2. Si este servidor de directorio se ha decomisado, debe asignar la función de emulador PDC a otro controlador de dominio.

Para obtener más información acerca de la transferencia de la función de emulador PDC de un controlador de dominio a otro, consulte los artículos siguientes de Microsoft Knowledge Base:

No se pueden instalar funciones de Exchange 2007 después de preparar Active Directory para Exchange 2010

Al ejecutar Microsoft Exchange Server 2010 Setup /PrepareAD, la herramienta Microsoft Exchange Server Analyzer consulta la topología de Active Directory existente para determinar si existen roles de servidor de Microsoft Exchange Server 2007. Si no se detectan roles de servidor de Exchange 2007, recibirá el siguiente mensaje de advertencia:

La instalación va a preparar la organización para Exchange Server 2010 a través de ‘Setup /PrepareAD’ y no se han detectado roles de Exchange Server 2007 en esta topología. Después de esta operación, no se podrán instalar roles de Exchange Server 2007.

Antes de implementar Exchange Server 2010, tenga en cuenta los factores siguientes, que pueden requerir la implementación de un servidor Exchange 2007 con todos los roles de servidor instalados antes de implementar Exchange 2007:

  • Aplicaciones desarrolladas internamente o por otros fabricantes Puede que las aplicaciones desarrolladas para Exchange 2003 no sean compatibles con Exchange 2010 y que haya que actualizarlas o reemplazarlas. Puede mantener estas aplicaciones y la población de usuarios asociados de Exchange 2003, moverlas a Exchange 2007 o reemplazar el software por una versión compatible con Exchange 2010.
  • Requisitos de coexistencia o de migración Si piensa migrar los buzones a la organización, puede implementar Exchange 2007 y usar Microsoft Transporter Suite o puede usar una solución para migración o coexistencia de otros fabricantes. Para descargar Microsoft Transporter Suite, vaya a Microsoft Transporter Suite en el Centro de descarga de Microsoft.

Además, cuando evalúe las opciones para su organización, asegúrese de que ha tenido en cuenta los aspectos siguientes:

  • ¿Tiene una estrategia organizada para mover las aplicaciones dependientes a Exchange 2010 antes de que finalice el soporte para Exchange 2003? Para obtener información adicional, visite la página Ciclo de vida de soporte técnico de Microsoft en (http://go.microsoft.com/fwlink/?linkid=55839).
  • ¿Necesita la coexistencia de WebDAV y los servicios web para su estrategia (Exchange 2007)?
  • ¿Ha tenido en cuenta los productos de otros fabricantes compatibles con Exchange u otras tecnologías de Microsoft que permiten satisfacer los requisitos de migración o de coexistencia?
  • ¿Cómo es el ciclo de vida del hardware (seguir usando todos los servidores de 32 bits existentes el máximo posible frente a comprar nuevos servidores de 64 bits)?
  • ¿Cuál es el plan de migración (migrar todos los servidores lo más rápido posible o migrar según una estrategia por fases)? Asimismo, ¿cuál es el límite de tiempo de la coexistencia de distintas versiones de Exchange?

Si decide que necesita implementar un servidor Exchange 2007 antes que Exchange 2010, la implementación de un servidor Exchange 2007 único con todos los roles de servidor es suficiente para habilitar la implementación de futuros servidores Exchange 2007 en la organización. Para implementar un servidor Exchange 2007 en la organización de Exchange 2003, siga estos pasos:

  1. Ejecute Exchange 2007 Setup /PrepareSchema.
  2. Ejecute Exchange 2007 Setup /PrepareAD.
  3. Ejecute Exchange 2007 Setup /PrepareDomain en todos los dominios que contienen destinatarios, servidores Exchange 2003 o catálogos globales que se podrían usar en un servidor Exchange.
  4. Instale un servidor Exchange 2007 con los cuatro roles de servidor (transporte de concentradores, acceso de clientes, buzón de correo y mensajería unificada).