User-Agent with base64-encoded component?

Question

(Bounty question at the bottom)

I'm having an issue with a client accessing our site, and the root cause is that the WAF (Web Application Firewall) doesn't like their User-Agent string:

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

In this case, the base64-encoded string is triggering a false positive in the WAF which thinks the User-Agent is libwww-perl. The base64 string does not decode to any readable text.

• Is having a base64-encoded string inside a User-Agent normal or unusual?
• Is the use of base64 strings inside a User-Agent covered by any RFCs or major vendor practices?

I'm trying to understand what's happening here; I don't feel the WAF signature is completely out of line to object, so I'd rather not just disable it, but I haven't seen this sort of User-Agent string before so I'd rather understand better how common and/or legitimate a use case this is.

The site is designed for use by humans with browsers - it's not an API or anything like that - and it has been reported to me that the user has tried accessing the site with "FF/IE/Chrome" and failed. I do, however, show successful connections from the same client IP with an Opera user-agent:

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

It's a little odd that the user reports having tried IE but all the User-Agent strings I see appear to be Linux. (As usual, contact with the end user is mediated through several parties so I can't fully trust anything I hear). It's also likely the IP is the outbound side of a business class web proxy, which would explain why I see some Opera working for someone while someone else reports problems from the same IP.

Update

Inspired by @PlanetScaleNetworks example, I googled the string and from there ended up using UA Tracker to search for base64 strings (or, the subset of them which were padded - I searched for "=)"). It returned about 20 User-Agents:

I'm going to add a bounty to this question, and the answer space I'm looking for is "what sort of software is putting base64 strings into User-Agents, and why? And is there any stamp of legitimacy for this practice?"

Minor point:

The user has worked around our problem by using a browser plugin to modify their User-Agent, so this is now an academic problem - but I think it's an interesting academic problem :)

Answer 1

If all other traffic from this IP address is legitimate, then I wouldn't worry about the WAF rule being triggered. It doesn't decode into a human readable string. So it was likely inserted by a proxy device for tracking purposes.

Regarding your concern about the RFC, they're written as a recommendation for how the field should be used though there is little consistency between platforms. That being said, it's a value defined by the client which cannot be trusted as it's trivial to modify. Thus why WAF rules are needed.

There are two areas in which I see User-Agent strings becoming a concern:

1. Buffer Overflow - either trying to overflow the buffer on the server or within the website/application. This clearly isn't happening in the provided example.
2. Script/Code Injection - providing inline scripting, references to remote files, etc. Again, clearly not applicable to your situation.

If you're really worried/paranoid, change the User-Agent string of your own system to this one and browse the same pages while using a proxy such as Fiddler, Burp, etc. How do the request/responses compare to using your original User-Agent string?

I wouldn't recommend blocking any IP addresses based off the provided example unless all traffic from this IP is malicious. Even then it should only be blocked for a limited time. Better yet, create a "blocked web page" with details of how to be unblocked. Redirect traffic there until contacted.

Answer 2

Is having a base64-encoded string inside a User-Agent normal or unusual?

Digging though the list of User agents at WhichBrowser. It is reasonable to conclude that this is rare, but possibly the result of a malware infection.

However I also abused this behaviour to add another security layer to my own site in the past, where only a few clients with a specific base64 UA token would even be displayed the login page. Similarly this unique fingerprinting could also be used to serve an attack page or redirect elsewhere.

Is the use of base64 strings inside a User-Agent covered by any RFCs or major vendor practices?

Not specifically. Nothing is documented in any of Gecko browsers vendor information. In the UA you provided, the base64 it is not part of the product information, but a comment. There are seemingly no restrictions of the comment field although having base64 in the product information is not allowed by RFC7231 as it can be seen as unnecessary information appended to the UA string.

---

Your WAF likely can't identify the UA as anything specific and maybe returns libwww-perl because the filter is unspecific (false positive) and gets too happy with the Linux/X11 bit as it cannot make sense of the base64 comment.

Answer 3

Doing a check online has come across this user agent string on the site closetnoc.org. This user agent was identified as being one of a number which have been traced to a single IP address 192.185.1.20 which has been flagged as a spammer by list.quorum.to, bl.csma.biz, and spamsources.fabel.dk.

To block access to this IP (and in turn to that User-Agent)...

Using CISCO Firewall

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

Using Nginx

Edit nginx.conf and insert include blockips.conf; if it does not exist. Edit blockips.conf and add the following:

deny 192.185.1.20/32;

Using Linux IPTables Firewall

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

Using Microsoft IIS Web Server

<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>

Using Apache .htaccess

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

Source: closetnoc.org

Answer 4

I'm seeing simil-b64 encoded user agents too. After some analysis it turns out that thay are clients having Kaspersky antivirus installed and looking for updates.