Usuario-Agente con componente codificado en base64?

(Pregunta de recompensa en la parte inferior)

Tengo un problema con un cliente que accede a nuestro sitio, y la causa raíz es que al WAF (Firewall de aplicaciones web) no le gusta su cadena de User-Agent:

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0; C7QcSBPWTsrpX5YLvVZMqiujEZLWPtOYk3tDZ9WhW18=) Gecko/20100101 Firefox/34.0

En este caso, la cadena codificada en base64 está activando un falso positivo en el WAF que piensa que el User-Agent es libwww-perl. La cadena base64 no se decodifica a ningún texto legible.

• ¿Tener una cadena codificada en base64 dentro de un User-Agent es normal o inusual?
• ¿El uso de cadenas base64 dentro de un User-Agent está cubierto por RFC o prácticas de proveedores importantes?

Estoy tratando de entender lo que está pasando aquí; No creo que la firma WAF esté completamente fuera de línea para objetar, por lo que prefiero no solo deshabilitarla, pero no he visto este tipo de cadena de User-Agent antes, así que prefiero entender mejor qué tan común y / o un caso de uso legítimo es este.

El sitio está diseñado para ser utilizado por humanos con navegadores (no es una API ni nada por el estilo) y me han informado que el usuario ha intentado acceder al sitio con "FF / IE / Chrome" y ha fallado. Sin embargo, muestro conexiones exitosas desde la misma IP del cliente con un agente de usuario de Opera:

User-Agent: Opera/9.80 (X11; Linux i686) Presto/2.12.388 Version/12.16

Es un poco extraño que el usuario informa haber probado IE, pero todas las cadenas de User-Agent que veo parecen ser Linux. (Como de costumbre, el contacto con el usuario final se realiza a través de varias partes, por lo que no puedo confiar plenamente en nada de lo que escucho). También es probable que la IP sea el lado saliente de un proxy web de clase empresarial, lo que explicaría por qué veo que Opera funciona para alguien mientras que otra persona informa problemas desde la misma IP.

Actualizar

Inspirado en el ejemplo de @PlanetScaleNetworks, busqué en Google la cadena y desde allí terminé usando UA Tracker para buscar cadenas de base64 (o el subconjunto de ellas que estaban rellenadas, busqué "=)"). Devolvió unos 20 agentes de usuario:

Voy a agregar una recompensa a esta pregunta, y el espacio de respuesta que estoy buscando es "¿qué tipo de software está poniendo cadenas base64 en User-Agents y por qué? ¿Y hay algún sello de legitimidad para esta práctica? "

Punto menor:

El usuario ha solucionado nuestro problema utilizando un complemento de navegador para modificar su User-Agent, por lo que ahora es un problema académico, pero creo que es un problema académico interesante :)

Si el resto del tráfico de esta dirección IP es legítimo, no me preocuparía de que se active la regla WAF. No se decodifica en una cadena legible por humanos. Por lo tanto, probablemente fue insertado por un dispositivo proxy para fines de seguimiento.

Con respecto a su preocupación por el RFC, están escritos como una recomendación de cómo se debe usar el campo , aunque hay poca consistencia entre las plataformas. Dicho esto, es un valor definido por el cliente en el que no se puede confiar, ya que es trivial modificarlo. Por eso se necesitan las reglas WAF.

Hay dos áreas en las que veo que las cadenas de User-Agent se vuelven una preocupación:

1. Desbordamiento del búfer: ya sea tratando de desbordar el búfer en el servidor o dentro del sitio web / aplicación. Esto claramente no está sucediendo en el ejemplo proporcionado.
2. Inyección de secuencia de comandos / código: proporciona secuencias de comandos en línea, referencias a archivos remotos, etc. Nuevamente, claramente no es aplicable a su situación.

Si está realmente preocupado / paranoico, cambie la cadena de User-Agent de su propio sistema a esta y explore las mismas páginas mientras usa un proxy como Fiddler, Burp, etc. ¿Cómo se compara la solicitud / respuestas con el uso de su original Cadena de agente de usuario?

No recomendaría bloquear ninguna dirección IP basada en el ejemplo proporcionado a menos que todo el tráfico de esta IP sea malicioso. Incluso entonces solo debe bloquearse por un tiempo limitado. Mejor aún, cree una "página web bloqueada" con detalles sobre cómo desbloquearla. Redirigir el tráfico allí hasta que se contacte.

¿Tener una cadena codificada en base64 dentro de un User-Agent es normal o inusual?

Excavando a través de la lista de agentes de Usuario en WhichBrowser . Es razonable concluir que esto es raro, pero posiblemente el resultado de una infección de malware.

Sin embargo, también abusé de este comportamiento para agregar otra capa de seguridad a mi propio sitio en el pasado, donde solo unos pocos clientes con un token UA base64 específico incluso mostrarían la página de inicio de sesión. Del mismo modo, esta huella digital única también podría usarse para servir una página de ataque o redirigir a otro lugar.

¿El uso de cadenas base64 dentro de un User-Agent está cubierto por RFC o prácticas de proveedores importantes?

No específicamente. Nada está documentado en la información del proveedor de los navegadores Gecko. En la UA que proporcionó, la base64 no es parte de la información del producto, sino un comentario. Aparentemente no hay restricciones en el campo de comentarios, aunque no está permitido tener base64 en la información del producto, RFC7231ya que puede verse como información innecesaria añadida a la cadena UA.

Es probable que su WAF no pueda identificar el UA como algo específico y tal vez regrese libwww-perlporque el filtro no es específico (falso positivo) y se pone demasiado contento con el bit Linux / X11, ya que no puede entender el comentario de base64.

Hacer una verificación en línea ha encontrado esta cadena de agente de usuario en el sitio closetnoc.org . Este agente de usuario se identificó como uno de un número que se han trazado a una sola dirección IP 192.185.1.20que ha sido marcado como un spammer por list.quorum.to, bl.csma.biz, y spamsources.fabel.dk.

Para bloquear el acceso a esta IP (y a su vez a ese Usuario-Agente) ...

Usando el cortafuegos CISCO

access-list block-192-185-1-20-32 deny ip 192.185.1.20 0.0.0.0 any
permit any ip

Usando Nginx

Edite nginx.conf e inserte include blockips.conf; si no existe Edite blockips.conf y agregue lo siguiente:

deny 192.185.1.20/32;

Usando Linux IPTables Firewall

/sbin/iptables -A INPUT -s 192.185.1.20/32 -j DROP

Uso del servidor web Microsoft IIS

<rule name="abort ip address block 192.185.1.20/32" stopProcessing="true">           
    <match url=".*" />   
    <conditions>    
        <add input="{REMOTE_ADDR}" pattern="^192\.185\.1\.20$" />   
    </conditions>  
    <action type="AbortRequest" /> 
</rule>

Usando Apache .htaccess

RewriteCond %{REMOTE_ADDR} ^192\.185\.1\.20$ [NC] 
RewriteRule .* - [F,L]

Fuente: closetnoc.org

También estoy viendo agentes de usuario codificados simil-b64. Después de un análisis, resulta que son clientes que tienen instalado el antivirus Kaspersky y buscan actualizaciones.