1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

WordPress Tim Thumb Exploit

Discussion in 'Bits & Bytes' started by Greg, Mar 7, 2012.

  1. Greg

    Greg Full Member

    If you run your own WordPress blog (as opposed to being hosted on a managed site) then you should check out this exploit. Google wordpress timthumb vulnerability

    I'm impressed by how much of my traffic on my few usually very low traffic sites is being caused by these probes. They're hitting so fast they're even setting off my flood detectors (too many hits in too few seconds, far too many to be caused by real human site visitors).

    The script kiddies are active tonight. From what I can see the probes seem to be coming from hosting sites--where you can host your own websites, perhaps shell accounts where you can run your own scripts on the hosts. This is as opposed as to scripts that are being run on accounts on normal ISPs like most of us use to access the Internet.

    Lending more credence to the theory that it's some kind of script, the user agent is always "Mozilla/5.0" (which is far too simplistic for most real user agent strings).

    I bet GA admins are seeing the Tim Thumb hits on GA too...

    This is silly. Subtracting the search engine indexing of my sites the Tim Thumb traffic is exceeding real human traffic.
  2. Biker

    Biker Administrator Staff Member

    The vulnerability affects all WordPress installations that utilizes the function within the style/theme. It matters not if it's a managed site or not. It's theme based. If you installed a theme or plugin that utilizes the function, and it's using older, vulnerable files, you're at risk. Again, it doesn't matter if you host it yourself, or it's managed. If you have a vulnerable file, the site is at risk.
  3. Greg

    Greg Full Member

    By managed I meant sites where you just post and somebody else does the technical stuff. Please excuse if I used incorrect terminology.

    Meanwhile they're all scanning for timthumb.php and my WP blog doesn't even have that file, not that any of the script kiddies have realized my blog isn't in the root of my domain. What I don't understand is that my logs show double slashes in their probes:

    14:33:57  GET  404 //lib/timthumb.php
    14:33:57  GET  404 //wp-content/themes/Yen/timthumb.php
    14:34:02  GET  404 //wp-content/themes/SimplePress/timthumb.php
    14:34:17  GET  404 //wp-content/themes/Yen/timthumb.php
    14:34:23  GET  404 //wp-content/themes/DeepFocus-fa/timthumb.php
    14:34:23  GET  404 //wp-content/themes/DeepFocus/timthumb.php
    14:34:23  GET  404 //wp-content/themes/TheSource/timthumb.php
    14:34:23  GET  404 //wp-content/themes/ribbons/functions/timthumb.php
    14:34:23  GET  404 //wp-content/themes/TheStyle/timthumb.php
    14:34:23  GET  404 //wp-content/plugins/uBillboard/timthumb.php
    14:34:23  GET  404 //wp-content/themes/eNews/timthumb.php
    14:34:24  GET  404 //wp-content/themes/DailyNotes/timthumb.php
    14:34:24  GET  404 //components/com_virtuemart/themes/pbv_multi/scripts/timthumb.php
    I don't understand how www.example.com//something.php is going to execute on any LAMP server. I wonder if the script kiddies forgot to specify a directory name that goes between the slashes e.g. /blog/ or something. Is that // ever legal? (Except after the http:// of course.)

    All this probing reminds me of the Code Red exploit years ago. For a time there Code Red was taking up a significant share of all Internet traffic. Tim Thumb hasn't gotten that active. Yet.

Share This Page