From fj.gutierrezs91 en gmail.com Wed Sep 25 23:18:26 2019 From: fj.gutierrezs91 en gmail.com (Javier Gutierrez-Maturana sanchez) Date: Wed, 25 Sep 2019 23:18:26 +0200 Subject: [Hacklab] =?utf-8?q?Incompatibilidad_del_Protocolo_Radius_en_la_i?= =?utf-8?q?mplementaci=C3=B3n_NPS?= Message-ID: Buenas Noches, En este mesaje voy a comentar un problema sobre la implementación NPS del protocolo Radius. El protocolo radius es un estándar para la autenticación de usuarios dentro de una red. En nuestro escenario el cliente radius es un punto de acceso que da servicio de red a las estaciones wifi. El servidor radius es la implementación de Microsoft NPS (Network Policy Server). El problema surge en el envio de mensajes entre el cliente y el servidor Radius, el servidor radius descarta los mensajes mandados por el cliente donde la configuración aparentemente parece correcta en ambas partes. El servidor loguea un error en la compartición del secreto con el código 18 (Invalid Message-Authenticator), Para quien no entienda como funciona el protocolo Radius el campo Message-Authenticator es una hash md5 compuesta por los campos del mensaje mas un secreto que solo conocen el cliente y el servidor, esto de forma simplificada. Message-Authenticator = md5(Secret + Message). Sin entrar en detalles de cómo se genera el mensaje. El servidor comprueba la hash md5 del mensaje en caso de que no coincidan el servidor descarta el mensaje sin contestar al cliente. Con este campo se intenta comprobar la integridad y autenticación de los mensajes mandados por el cliente al servidor. Los campos de la especificación pueden ser String Text o Enteros. En el caso de string se espera un Array de Bytes y en el campo texto caracteres codificados en UTF-8. El campo secret esta definido como un String sin embargo los campos String no se dice que codificación. En el caso de la implementación de freeradius el secreto se leerá de un fichero de texto que dependerá la codificación al sistema de ficheros en el que esté almacenado en nuestro caso era un debian jessie con UTF-8 en el punto de acceso. NPS utiliza una base de datos y en Windows 2012 la base de datos de NPS esta codificada en ISO8891 Latin2. Se puede entender que hay una incompatibilidad entre las codificaciones de las dos implementaciones del estándar. Fue dificil replicar el problema ya que ambas codificaciones realizar el mismo paso de carácter a bytes con caracteres ASCII-7. Si el secreto fuera "test" en ambas partes se codifica el secreto de la mima manera. Si en vez de "test" el secreto fuera "Çtest" se observa el problema mencionado anteriormente. Al no codificarse de la misma manera el secreto la hash md5 cambia en origen y destino dando a entender al servidor que el mensaje está mal formado. La solución propuesta fue realizar un parche del programa hostapd leyendo el campo secret del fichero hostapd.conf y despues haciendo una conversión de utf8 a iso8891 antes de mandar el mensaje al servidor. Me pareció interensante comentar este problema de compatibilidad entre Linux y Windows en el protocolo Radius en la lista de correo :). https://tools.ietf.org/html/rfc2865#section-5 https://tools.ietf.org/html/rfc2865#page-17 https://tools.ietf.org/html/rfc2869#section-5.14 Un Saludo y que tengais un buen inicio de curso, Javier, ------------ próxima parte ------------ Se ha borrado un adjunto en formato HTML... URL: