8

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

UA Tracker search for "=)"

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

  • 1
    Do you have more details? Is their IP address and this agent actually from an ISP, or is it a server to API kinda thing? – dhaupin Apr 5 '16 at 20:01
  • @dhaupin, not server/API, definitely (which is one of the reasons I'm comfortable saying that the "no libwww-perl" WAF signature isn't unreasonable). I've updated the question with more info which might help. – gowenfawr Apr 5 '16 at 21:58
  • What does the Women's Air Force have to do with this? Or am I clueless as to what you are talking about? – Rob Apr 6 '16 at 0:52
  • @Rob "Web Application Firewall" – Analog Apr 6 '16 at 1:36
  • @gowenfawr I stumbled onto various logs as well. Could it be that they are leveraging some kind of log profiling? Or, perhaps it's salted as tamed Shellshock strings to come back to later? blog.cloudflare.com/inside-shellshock – dhaupin Apr 11 '16 at 20:51
3

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.

  • Although if "The user has worked around [the] problem by using a browser plugin to modify their User-Agent" then that would seem to rule out the "inserted by a proxy device" idea? – MrWhite Apr 13 '16 at 22:42
  • @w3dk probably a hardware/network proxy however there could still be software on the system that was intentionally making this change. It becomes much easier to monitor outgoing traffic if all browsers are using the same User-Agent. Thus correlating a unique string to a user and/or system. Since there's a business relationship its best to engage their technical support staff to rule this out since its contrary to a default installation of Windows. – user2320464 Apr 14 '16 at 19:56
2
+100

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.

  • Upvoted and awarded bounty as this post has the most info directly addressing the questions, but holding off on accepting answer as I'm still hoping someone will track down the responsible software and provide a rationale for their behavior. I do thank you and appreciate your answer as it brought in both RFC and 'real world' data. – gowenfawr Apr 18 '16 at 15:28
  • Incidentally WAF finds libwww-perl simply because the base64 string includes the letter string "LWP" - clearly, the WAF is being stupid and string matching without regards to product vs. comment. – gowenfawr Apr 18 '16 at 15:29
1

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

  • while this is interesting information, it doesn't address the question of what the base64 string is doing in the User-Agent or why it was put there. I'll upvote because it inspired me to get use search to get more data for the problem space, however. Thanks. – gowenfawr Apr 11 '16 at 13:59
  • 1
    If your going to downvote please comment and say why you're downvoting to allow a chance for improvement. – Chris Rutherfurd Apr 13 '16 at 23:51
  • 1
    I imagine it was downvoted because it doesn't actually answer the question: What is the significance of the base64 encoded string in the user-agent and where does it come from? You have focused on the IP address and how to block it, which is the crux of the problem the OP is already facing: the user is already being blocked from accessing their website because of this base64 encoded string in the user-agent. (I didn't downvote btw.) – MrWhite Apr 14 '16 at 20:46
0

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.

  • What kind of analysis did you do to discover that? How did you find out they were looking for updates? This is a very promising answer but it could use a lot more detail. Can you please edit it and add to it? – Stephen Ostermiller May 3 '18 at 16:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.