[Hacklab] Incompatibilidad del Protocolo Radius en la implementación NPS

[Javier Gutierrez-Maturana sanchez]

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: <http://gsyc.urjc.es/pipermail/hacklab/attachments/20190925/3dd4253b/attachment.html>