0

I get some hits every then and there from different IPs, always the same scheme:

GET /blah/Resources/Public/Css/data:image/svg+xml;base64,... HTTP/1.1" 404 795 "http://some.referer/" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; InfoPath.3; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)"

Browser seems outdated but legit, the base64-decoded svg-thingie seems legit too and reads:

<?xml version="1.0" ?>
<svg xmlns="http://www.w3.org/2000/svg" width="100%" height="100%" viewBox="0     0 1 1" preserveAspectRatio="none">
  <linearGradient id="grad-ucgg-generated" gradientUnits="userSpaceOnUse" x1="0%" y1="0%" x2="0%" y2="100%">
  <stop offset="0%" stop-color="#fdf226" stop-opacity="1"/>
  <stop offset="100%" stop-color="#fad71b" stop-opacity="1"/>
  </linearGradient>
  <rect x="0" y="0" width="1" height="1" fill="url(#grad-ucgg-generated)" />
</svg>

so my question is: is this a probe? for what? i read this interesting paper on hidden svg-payload but cannot find anything malicious.

2 Answers 2

1

It looks like a CSS script (check out the Referrer field) might contain an inline SVG.

This kind of inlining is not supported by all browsers, though. So where a modern Firefox might see

src="data:image/svg+xml;base64..."

and display an image (or a SVG), an older browser would "believe" this to be a file name. So it appends the name to the base directory it was using, and blithely requests that filename. Which earns it a 404 instead of a cigar.

If this is the case, you either ignore the fact, or could use a Rewrite to answer with a remediation SVG to these malformed requests (it might be awkward if there's more than one SVG in the same virtual path - but you could use a SVG crafted to display 'Upgrade your browser!'), or modify the CSS, if you have access to it, to use a (slower) off-line SVG inclusion instead of the current online one.

Update

Apparently, this used to happen a lot with users of old browser which also installed some "browse enhancing" widget. The widget was probably injecting some JS/CSS in the page, and the result wasn't always correctly interpreted by the browser. Rendering a gradient background in SVG and embed it as a base64 string was a trick used for IE9.

So, I'm convinced that it's nothing you should worry about -- there is a problem somewhere but it definitely seems to be not your problem.

7
  • according to the devs there is no svg used at all Aug 20, 2013 at 23:49
  • Check the referring URL. The request seems legit, not an exploit, and a 404 is its natural response, so a "probe" makes no sense. Does the Css path exist, at least?
    – LSerni
    Aug 21, 2013 at 6:43
  • Iserni: > Does the Css path exist, at least? nope. Aug 21, 2013 at 15:15
  • And you checked the referer's contents? Maybe there's some error in that file -- something like, you own gogle.com, and Google's webmasters misspelled one of their hrefs...
    – LSerni
    Aug 21, 2013 at 15:27
  • yeah, we run a grep over all access-log and checked all referers, all are legit from our domain and are working Aug 21, 2013 at 15:38
0

@all: i checked different referers: all of those are legit, but dont produce any kind of svg when browsing manually.

we checked the css-files and found no svg-references at all. the /Resources/Public/Css/ - path is not a valid. i assume this is some kind of probe for whatever.

we have now some rules to monitor those urls, and i'll report if there're some findings.

gracias, senores

0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .