OWA Keep-Alive en http, a pesar de que se debe forzar https

2

Ayer, recibí una alerta del IDS de un cliente de que se detectó un paquete de autenticación Base64. En cuanto a la decodificación ASCII, puedo ver que es para su OWA (Outlook Web Access), y de hecho, la información de autenticación fue Base64, fácilmente decodificada al nombre de usuario / contraseña de un usuario.

Lo que es extraño es que el servidor Exchange de esta compañía está configurado para nunca permitir conexiones sin cifrar (a través de HTTP o POP / SMTP). Siempre redirigirá http a https antes de que se requiera la autenticación.

Desde que recibí esta alerta, he buscado otras alertas del mismo tipo, pero no puedo encontrar mucho más ... Parece ser un caso de ventaja.

¿Alguna idea sobre lo que está pasando?

=====Ascii Decode of packet====

GET./.HTTP/1.1
Host:.xxxxxx.com 
User-Agent:.Mozilla/5.0.(iPod;.CPU.iPhone.OS.5_0_1.like.Mac.OS.X).AppleWebKit/534.46.(KHTML,.like.Gecko).Version/5.1.Mobile/9A405.Safari/7534.48.3
Accept:.text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Authorization:.Basic.xxxxxxxxxxxxxxxxx==
Accept-Language:.en-us
Accept-Encoding:.gzip,.deflate
Cookie:.UserContext=ecc88b90b86c483f89db34eb673c259c;.OwaLbe={A907E8ED-3881-4B44-B84E-F036E6485722}
Connection:.keep-alive
    
pregunta Josh Brower 08.02.2012 - 14:07
fuente

3 respuestas

1

Acerca de ese paquete de autenticación Base64, está relacionado con esta discusión en las comunidades de McAffee aquí . Esto se debe a que han configurado el modo de autenticación básica para OWA.

El tema se explica en detalle, parte de la explicación:

  

La autenticación básica es un medio para enviar nombres de usuario y contraseñas a través de la red para iniciar sesión en un dispositivo en sentido ascendente.   Esta forma de autenticación es intrínsecamente insegura porque se envía en texto sin formato a través de la red, sin embargo, es ampliamente adoptada   por la mayoría de los clientes / servidores, que todavía lo hace relativamente popular, especialmente en entornos multiplataforma.   Le recomendamos encarecidamente que si lo va a utilizar, debería usarlo sobre   HTTPS (SSL / TLS), para evitar que alguien use un rastreador de paquetes y recoja contraseñas mientras está en tránsito.

     

La autenticación básica es simplemente un nombre de usuario / contraseña codificado en base64 que se envía a través del cable como   nombre_usuario: contraseña

     

Para codificar en base64 un nombre de usuario y contraseña:   echo -n "valid_user_name: valid_user_password" | openssl base64 -base64

Con respecto a la comunicación HTTP sin cifrar, podría ser una falla con la implementación ActiveSync en IOS 5.0.1. O relacionado con este ticket de soporte de MS que dice:

  

La nueva funcionalidad envía solicitudes HTTP incluso cuando el cliente está inactivo. El cliente envía una solicitud de keepalive (/owa/keepalive.owa), y luego el cliente envía más información sobre la actividad del usuario agregando la siguiente ruta de la URL de OWA publicada:   /owa/ev.owa?UA=0

Me pregunto por qué MS no dijo que envía una solicitud HTTPS ??? Se necesita más prueba. Y esto solo está relacionado con las nuevas funcionalidades de OWA de Exchange 2010.

    
respondido por el Muhammad 08.02.2012 - 15:04
fuente
1

El hecho de que el servidor requiera SSL no impide que el cliente intente HTTP.

Esta es una filtración común de credenciales en todas las aplicaciones web. El navegador web guarda las credenciales en el servidor. El usuario luego escribe la URL con enlace . Luego, el navegador envía las credenciales almacenadas en caché en claro al puerto 80, momento en el que el servidor redirige al puerto 443.

Además, las herramientas automatizadas (como se describe en otra respuesta sobre ActiveSync) están dañadas y pueden probar HTTP cuando se pretende HTTPS.

La única forma de evitar que esto suceda es bloquear el puerto 80. La única forma de evitar que el cliente revele la contraseña es evitar que el cliente establezca una conexión.

Tenga en cuenta que intentar mejorar sobre la autenticación "Básica" no ayudará mucho. La mayoría de los otros métodos de autenticación que utilizan la respuesta de desafío se pueden descifrar con crackers de contraseñas (como "Cain y Abel").

    
respondido por el Robert David Graham 08.02.2012 - 18:18
fuente
1

¿Es posible / concebible que OWA fue previamente configurado a través de HTTP (incluso brevemente) y luego se cambió a HTTPS? Si se usó a través de HTTP en el pasado y un usuario conectado a él en ese entonces, el navegador podría haber guardado las credenciales. Luego, cuando el usuario vuelve a ingresar el http: // ... url (o usa un marcador), el navegador puede enviar las credenciales en caché en la primera solicitud, que luego se redirige a HTTPS.

De lo contrario, no creo que ningún navegador decente (en este caso, los encabezados de solicitud sugieren que es un iPod con iOS 5.0.1 que ejecuta Safari) enviará el encabezado de Autorización HTTP sobre un nombre de host, puerto o protocolo diferente al de utilizado antes Dicho esto, es posible que te hayas encontrado con un error (bastante serio). Lo mejor es probarlo, idealmente con el iPod que este usuario estaba usando y ver si la configuración estaba configurada, si es posible. Si no puede acceder al mismo dispositivo exacto o si la configuración ha cambiado, quizás debería intentar simular esta condición con un dispositivo similar y ver si puede reproducirlo.

    
respondido por el Yoav Aner 09.02.2012 - 18:16
fuente

Lea otras preguntas en las etiquetas