making bbPress (and WordPress) work better!

babloo/blyat spammer attack on many WordPress blogs

wp-attack-256 I’ve learned recently that a number of WordPress powered blogs (including xkcd) were hit by some kind of spammer attack (bablooO aka babloo-O).

It injected many spam links into the database before the “read more” part of a post.

I am trying to figure out how this happened so it can be prevented from happening again, if it’s a plugin vulnerability or from WP’s xmlrpc.

So if anyone has more details please let me know. I do know it was not tied to any specific version, I have found the signature on WP 2.3 2.5 2.7 & 2.7.1

(sometimes the signature says “blyat” instead of “babloo”)

59 responses

  1. My blog ( was hit also. Current stats are wordpress-2.7.1, plugins = akismet, BDP RSS aggregator, Subscribe widget, and WordPress Database Backup.

    June 8, 2009 at 11:40 am

  2. Thanks for the feedback John. Every little piece of info helps.

    Is this the subscribe plugin you use or is it something else?

    Oh and what exactly is BDP ?

    June 8, 2009 at 2:04 pm

  3. Warkior

    We’ve experienced the same problem on our site. Code injected into the beginning of the footer.php file.

    June 9, 2009 at 1:48 pm

  4. Warkior, footer injection is typically how the attack works.
    But can you please tell me which version of WordPress you use
    and which plugins you use? I am trying to find a pattern, thanks.

    June 9, 2009 at 2:15 pm

  5. Warkior

    WordPress v. 2.7.1
    Our plugins:
    Akismet 2.2.3
    Author Image 3.1.2
    Clean Notifications 1.1
    Diagnosis 1.2.1
    FLV Embed 1.2
    FormBuilder 0.76
    Kimili Flash Embed 2.0
    Moderator 0.1
    Page Category Plus 2.2
    Page Excerpt 1.0
    Pages+ 0.3
    podPress 8.8
    Post-Plugin Library
    Post Thumbnail 0.5
    Recent Comments
    Recent Posts
    RS Event 0.9.3
    Similar Posts
    Simple Tags 1.6.4
    Subscribe To Comments 2.1.2
    tags4page 1.1
    the_excerpt Reloaded R1.4
    Time Since Calculator 1.0
    Trackback Validator 0.7.1 Stats 1.3.5

    June 9, 2009 at 2:46 pm

  6. So far I think I see “Subscribe to Comments” on each of the hacked sites.

    It may be the culprit but that’s just a theory for now.

    June 9, 2009 at 3:46 pm

  7. Any news?

    June 11, 2009 at 7:26 pm

  8. Oliver

    From what I can see it may be a vulnerability in the theme-editor.php.

    X.X.X.X – – [05/Jun/2009:06:04:03 +1000] “POST /blog/wp-admin/theme-editor.php?file=/themes/myblog/footer.php&theme=myblog HTTP/1.1” 200 40861 “http:/
    /X.X.X.X/blog/wp-admin/theme-editor.php” “Opera”

    Anyone know if a bug report has been filed?

    June 11, 2009 at 10:19 pm

  9. Interesting, I was just telling someone the other day to delete theme-editor.php as in general it’s a bad idea to have that kind of access, and definitely never, ever chmod 777 your templates directory.

    If it is a bug, it’s been in there since 2.3 or even older and still exists even in 2.7.1, maybe even in the newest 2.8

    June 11, 2009 at 10:53 pm

  10. liljason

    We saw the same attack on our website over the weekend. The first sign was that two posts that were “drafts” got mysteriously published. When we looked at the posts the bablooO stuff was inserted at the end. All of the links had the blog “www.environmentalgraffiti” in the URL – Ihope they’re an unwitting victim!

    Also, the bad content is actually inserted in the HTML of the main post (at the bottom) – it is actually in our (and I suspect your) wp_posts table in the database!

    No idea what is going on here, so we’re anxious to hear if someone fixes this!

    June 14, 2009 at 12:47 pm

  11. Name changed to protect the innocent

    One of my sites was attacked as well. We’ve seen three phenomena, not sure whether the first two are bablooO — at this point we’ve cleaned up the evidence and can only see the third.

    1. Many bogus account creations. (We had been planning to have an open group blog, quickly gave up on that idea and disabled account registration.)

    2. Bogus posts from the “admin” account. They were copies of our legit posts, using the screen name of legit users, with hidden spam content inserted, not sure whether this was bablooO. (We shut down the “admin” account, created new accounts with admin privileges.)

    3. Insertion of bablooO hidden spam content into legit posts. Not sure whether 3 happened at the same time as 2.

    Has anyone else seen bablooO in conjunction with account creation attacks and/or bogus posts which copy content from legit posts?

    Relating to the suggestions in this thread: our themes directory is not writable (the only writable directory we have is uploads) and we do not use the theme editor. All of our bablooO damage appears to be in posts in the database, none in the files, but we’re still looking. Are the “footer.php” injections mentioned above supposed to be the *method* of the attack or just the site of the damage? I’m looking but not seeing how footer.php can be passed arguments that result in a code injection.

    A recovery tip that may be obvious to many of you: I used the WP “Export” function to download an XML file of all my posts and opened it up in a text editor to efficiently scan for spam content. I found that only three of my posts were affected so I will clean them up by hand. Had there been more, I would consider cleaning the XML in an editor or perl script and re-importing the content into WP (after thoroughly testing on a sandbox version of my site!).

    June 16, 2009 at 10:33 am

  12. Name changed to protect the innocent

    I’ve posted a link to this discussion in the Forums:

    Is there a formal channel for reporting WordPress security issues to the WP community?

    June 16, 2009 at 11:01 am

  13. I’ve already reported it formally to WP, but no reply (yet).

    I know how to reach the developers more directly but I wanted to have something more definitive first. We still don’t know exactly how this is getting in.

    I suspect there are going to be several thousand sites compromised soon, including high profile ones and that’s really going to make WordPress (and Automattic) look bad. I’m hoping that can be avoided.

    June 16, 2009 at 11:38 am

  14. I’m seeing this on one of my sites as well, but it’s being injected into the RSS2 feed (but not the regular web page). I upgraded to 2.8, and that didn’t seem to make any difference, though the content could be cached somewhere in between. I also deactivated Feedburner FeedSmith, which didn’t seem to make any difference.

    June 17, 2009 at 3:56 pm

  15. I spoke too soon. The content is there on the web page as well, but i can only see it by doing a “view source”.


    June 17, 2009 at 4:05 pm

  16. They embedded the content within a <p> elemnent that was styled with height:0 and width:0. They injected the content directly into several posts on my site. I changed the admin password and removed the content.

    June 17, 2009 at 4:14 pm

  17. just a guy

    One of my major websites was hit by this darn thing last month, I have the very basic plugins installed and the spammer injected the links into the database directly (it wasn’t even in footer.php).

    I took the following actions:

    – Insalled every anti-hack wordpress plugin
    – Upgraded to the latest version of wordpress (wp 2.7.1 at that moment)
    – Monitored my database regularly

    The site is OK for now.

    Btw, these things don’t happen by accident, I know for a fact that a competitor did this to my website (my site got eventually penalized by Google, he did several other things), so before blaming it on the spammers, think of something that you did (or haven’t done) that pissed one of your competitors. There’s always a reason behind anything.

    June 18, 2009 at 10:53 am

  18. just a guy

    Note: I also changed all the passwords (hosting account, ftp account, wordpress admin account).

    June 18, 2009 at 11:01 am

  19. Name changed to protect the innocent

    Just a Guy, thanks for the info. It sounds like you’re in the same boat as the rest of us, namely there’s no new damage since you took those measures but you don’t know how they got in, right?

    One thing I wonder about: it seems possible that what we “victims of bablooO” share is what the intruder(s) did to us but not how the intruder(s) got in. In other words, there may not be a single common exploitable weakness among our sites, just a common blob of spam HTML copied and pasted into our sites once we were broken into.

    And one other hypothesis: those of us who had the spam HTML pasted into our blog posts (the database) rather than into our themes (the PHP files) only saw damage on a limited number of posts, right? If true, that suggests that the exploit was carried out by a human. Had it been a bot, we should expect every post on the site to have been hit. Has anyone seen any evidence to the contrary?

    June 18, 2009 at 12:12 pm

  20. I think you’re right, but for a different reason.

    Even if it was a bot, it might only target a few posts in order to further avoid detection. What tells me that it wasn’t a bot (or at least, not a particularly smart one) is that it added the content to recent posts, rather than older ones.

    Yes, I only had about 8 posts affected — and they were all recent.

    The most likely attack vector in my mind is the admin password. That would allow access to all content, and if the theme editor is enabled would also allow access to the theme files. Has anyone had their theme hacked who does not have the theme editor enabled? If so, was your FTP/SSH password the same as your admin password?

    June 18, 2009 at 12:32 pm

  21. There is no way they are guessing the raw admin password on all these sites, it’s simply not possible. We’re talking hundreds of sites, a dictionary attack would take forever. It has to be some kind of mysql injection.

    June 18, 2009 at 2:29 pm

  22. Through a comment maybe?

    It could be a password crack, if there is some vulnerability in WordPress that can be used to reveal the password.

    June 18, 2009 at 4:22 pm

  23. webstoc

    We were just hit with this where I work. We’ve got 9 wordpress blogs (4 affected), each at version 2.8.

    We’ve spent the afternoon combing through apache access logs. There’s a whole host of accesses from an ip in Germany around 3 in the morning, accessing /wp-admin/theme-editor.php in 3 of the 4 affected blogs.

    June 18, 2009 at 5:53 pm

  24. innocentandincensed

    I am pasting a slightly modified entry from our Apache access log, below. We are finding a strong correlation between this IP# hitting the theme-editor.php (which we have since deleted) and the appearance of the babooO spam in several of our blogs: – – [18/Jun/2009:03:52:04 -0700] “POST /blog/wp-admin/theme-editor.php HTTP/1.0” 200 18257 “” “Opera”

    June 18, 2009 at 5:55 pm

  25. just a guy

    @Name changed to protect the innocent: 30 posts were hit, or about 1% of the total posts that I have, so yes, only a fraction and not everything. These posts were not recent, actually some of them were very important posts receiving lots of traffic (or did receive) and got hit. This leads me to believe that these things are just not random. Prior to being hit by this thing, my footer.php got hacked with the usual thing (eg. hidden spam). What I did back then was to chmod all my template files to 444. I thought I was safe, and apparently, I was wrong.

    My personal opinion is that it’s not a password crack (all my passwords are different btw). It’s just not feasible. I think there’s a leak in the system somewhere.

    The scenario I have in my mind is that a competitor pays some money to someone to do this to your website.

    Major lessons I learnt from this are:

    – Never take security on a website for granted.
    – Never rely on Google for traffic, they can kill you anytime they want, and the only thing that you can do is begging to remove the penalty.

    June 18, 2009 at 6:06 pm

  26. Name changed to protect the innocent

    Webstoc/incensed, thanks for the report.

    Did the bablooO spam HTML appear in your themes (your PHP files), in the blog posts in your database, or both?

    And was your themes directory writable?

    June 18, 2009 at 6:44 pm

  27. webstoc

    Themes directory was 775, group-owned by root. Unfortunately (?), we have unidirectional synchronization scripts set up that would have overwritten any changes to footer.php within the active theme, so we can’t answer that question for sure. Anyone else?

    June 18, 2009 at 7:12 pm

  28. webstoc

    That is to say, we can’t answer that question about the themes. Yes, the entries appeared in the blog posts and in the database. It was plainly visible when editing the affected posts in wordpress (although I did cleanup using the terminal and a shell script, so I can’t say definitively for every instance).

    June 18, 2009 at 7:24 pm

  29. Name changed to protect the innocent

    I found one hole on my site: a third-party theme wasn’t validating its arguments. I’ve confirmed that it was vulnerable to cross-site scripting (XSS) by appending javascript to a URL. Background:

    I added a line of input validation to the theme and sent the patch to the theme developers. Hole closed.

    Now my burning question is whether that hole is the likely source of my intrusion or there are others. The symptoms we bablooO victims describe seem most consistent with an intruder being able to log into WordPress using the admin account. In practical terms is a javascript insertion in the URL really likely to result in interactive access to the WP Dashboard?

    June 19, 2009 at 3:03 pm

  30. If somebody can put code anywhere on your site, then they can basically own it. The theme and plugin editors are one way to do this, however they are protected by the access controls same as the rest of the system. The only way to have the correct rights is to pass along the proper authorization cookie.

    So while the theme editor may be the method of the initial injection, it’s not the root cause. They had to get your admin cookie, somehow.

    Now, it’s possible that a theme or a plugin contains a cross-site scripting weakness that would allow them to get that cookie by some means. I’ve seen themes with XSS holes before. That’s the only method I can think of offhand that I know would work.

    June 19, 2009 at 4:04 pm

  31. You most certainly do NOT need the admin password or cookie to compromise a site, especially if you have an injection ability into the theme editor. If you can inject code into the footer you can basically get visitors to run the code for you and make that code modify as many other pages as you’d like.

    The most valuable visitor would still be admin or even authors as the admin that accidentally run that code injected into the footer would allow the code to access the other posts AS the admin. The code can just sit in the footer and wait for the admin to show up, eventually, but clever code wouldn’t even need the admin and be able to inject directly into the db without waiting for privileges through WordPress’s API.

    The easiest thing to do would be to have the injected code show the contents of config.php (including DB login/password) to the hacker or even email it to them via php’s mail which has no log, so you’d never even know.

    Be sure to change the db username/password on compromised sites.

    June 19, 2009 at 5:12 pm

  32. I’ve also seen this on a site that has the “Subscribe to Comments” plugin. However, the host is also setup poorly and the web server can write to any file in the users directory unless all write permissions are removed. So, if another user has a file browser or exploit on their section of the shared server they can probably browse files for other sites.

    I found in the access logs where it appeared that they had actually logged into wordpress by normal means, went to the theme editor and made updates to files. However, this was after all passwords had been changed so I think there is something more going on than stealing a password somehow.

    If someone gets access to the wp-config.php they can use the keys to spoof the authentication cookie and get into the admin side of WP.

    I’ve also been reviewing the Subscribe to Comments plugin to see if I can find anything.

    June 19, 2009 at 5:52 pm

  33. Name changed to protect the innocent

    CK, some of us were hacked through the theme editor and/or had code inserted in the footer, but others among us don’t use the theme editor, don’t have writable theme directories and never saw any damage in our PHP files, only in the database.

    That leads me to believe that either (1) there are multiple initial methods of attack and bablooO is merely the payload, or (2) there’s a single initial method of attack that we haven’t identified yet and the attacks on the theme editor, footer.php and the database are all subsequent to that one. Both of these hypotheses seem like possibilities. Is there evidence to rule either of them out?

    Meanwhile, as I noted in a comment a few hours ago that is still awaiting moderation, I found and fixed a cross-site scripting vulnerability on my site. Could it have been the initial point of attack on my site (I’m in the database-only, no-theme-damage camp)? Otto appears to be saying yes. Could an XSS attack have been the initial attack for all of us, both the database victims and the theme victims? Dunno, but it seems like it’s worth exploring.

    June 19, 2009 at 6:06 pm

  34. Nctpti, can you be more specific about the XSS vulnerability? I’m in the same camp with you, and I’d like to close it if I have the same issue.

    June 19, 2009 at 6:21 pm

  35. Bob H.

    Does somebody have a relatively low-traffic WordPress site on which they can install logging of HTTP POST data? This may help us isolate the attack vector!

    I got this idea after reading the comment by “Name Changed”. I would like to enable this logging on my own site, but we get thousands of POSTs an hour so this would log too much…


    June 20, 2009 at 3:14 am

  36. @Bob: you could reduce the amount of logged traffic by skipping $_POST data with the most common isset($_POST[‘comment’])

    It’s unlikely the attacker is getting in via comment data, so that would radically reduce the size of the log.

    June 20, 2009 at 9:44 am

  37. I also wonder whether this cracker has ever attacked the same site twice. I haven’t seen any evidence of such on my site.

    June 20, 2009 at 2:44 pm

  38. Mandaloin

    I wonder… Does everyone who was attacked have some kind of connection to each other?

    June 23, 2009 at 4:54 am

  39. Name changed to protect the innocent

    Mandaloin, I haven’t wanted to reveal my site until I’m sure my holes have been plugged, but I haven’t seen any connection with any of the sites named so far. I compared notes with Sterling and he is not running the plugin where I found a cross-site scripting hole. Unlike “Just a Guy” above, there is no indication that my site was attacked by enemies or competitors – in fact, since the bablooO payload is invisible spam rather than defacement, I think that’s mild evidence against Just a Guy’s belief that the attacks are not random. Like Sterling, I have not heard of any sites being attacked twice.

    I still would like to know whether cross-site scripting is commonly used to steal passwords or session cookies, or whether that’s just a theoretical possibility and rare in practice. My hunch is that my intruder got into the admin interface and I’d like to have some idea how likely it is that I’ve closed the point of entry.

    June 23, 2009 at 10:27 am

  40. Warkior

    I’m sorry to be the bearer of bad news, but our site has been attacked repeatedly. After initial comments above we deactivated the subscribe-to-comments plugin but were attacked again after that point. We have since removed the theme editor, but don’t know if that plugged the hole.

    I would agree with “Name changed” though that I don’t think it is an attack by enemies or competitors.

    June 23, 2009 at 11:29 am

  41. Hi, I also get this kind of attack in my client’s site.
    Here’s a complete list of installed plugin in the site:

    All In One SEO Pack
    FeedBurner FeedSmith
    Google Analytics for WordPress
    Google XML Sitemaps
    Ozh’ Better Feed
    Smart 404
    Subscribe To Comments Stats
    WP Shopping Cart

    The bad thing: Google stopped indexing the site due to the bad links. I’m submitting a reconsideration proposal to Google now, and still trying to close any possible hole.

    btw, would you guys share which web host company you’re using?

    June 25, 2009 at 11:16 am

  42. Alex

    I just found out that I was attacked by this hack. I was running 2.7.1 and using the default Kubrick theme. The links appeared in my footer.php file (every link was a hi-fisoft domain) of this theme. I’m searching through the db now, but so far the db doesn’t appear to be infected. I noticeed that I left my footer.php, style.php and header.php files as CHMOD 777 after originally editing them back in march.

    Here’s the plugins that I have installed:

    Add Meta Tags
    FeedBurner FeedSmith
    Google XML Sitemaps
    Hello Dolly
    Secure and Accessible PHP Contact Form
    Subscribe me

    Today I upgraded to the newest version 2.8. I haven’t changed my admin passwords yet, because I’m not 100% convinced this is the cause of the problem. I removed the code in the footer but this time I made sure all files are CHMOD 644.

    Any other suggestions?

    June 25, 2009 at 1:03 pm

  43. For those asking, I am 100% positive this attack is not based on a specific host, or because of shared hosting for that matter. I know of at least two dedicated servers that were hit.

    July 6, 2009 at 6:59 am

  44. Name changed to protect the innocent

    Huda and Alex, the only plugin my site had in common with either of yours is Akismet, which is so widely used that I doubt it’s hole.

    To recap: my best guess at this point would be that the attackers don’t specialize in particular plugins but uses cross-site scripting attacks that can get through any plugin which doesn’t properly scrub its input. Once in, they have two methods of exploiting the leaks: editing footer.php (if you have the template editor enabled) or posting/editing individual blog entries. The newly posted blog entries are disguised to mimic existing blog entries by repeating content and username from existing entries but are actually posted by user “admin”. The edited blog entries are only a handful in number rather than every entry on the site, suggesting that the actual work is done by a human not a bot.

    Any evidence to the contrary on any of the above? The main weakness is that I don’t know how easy it is to go from cross-site scripting to an admin login.

    Another mystery is why the babloo/blyat string is inserted in the page. Why leave fingerprints like that? If it were for kicks I would expect a taunting message. Here’s one hypothesis: the perpetrators get paid per page and the string is there so customers can verify that they did the work. Has anyone heard of spam networks that work that way?

    July 6, 2009 at 10:22 am

  45. On my blog they edited existing posts, rather than creating new ones (verified by permalink). So I had to clean their garbage out of the existing posts.

    Yes, I think the fingerprints must be for some form of tracking — perhaps to see how long their handiwork remains untouched. I just hope they don’t catch a clue and start leaving it out.

    July 6, 2009 at 12:02 pm

  46. Why leave fingerprints like that?

    Signatures like that are sometimes a sign of script-kiddies using 3rd party software which already has the signatures in place. The people using the scripts did not write them so they either don’t know how to remove the signature or they don’t care.

    July 6, 2009 at 8:01 pm

  47. Anne

    I have a somewhat interesting situation in that I have my own server. I host several WordPress blogs for people and also host a number of osCommerce sites. I know everyone who uses the server–nevertheless, register globals is set to off.

    One blog in particular is becoming nationally known and receives more hits than all the other sites combined. About a month ago, the owner received the dreaded Google take-down notice. I took a look at his blog and found the bablooO code in his footer.php. I dumped out his database, did a search of his .php files, and found nothing else. His theme was custom-written for him by someone else. He was at that point running WP 2.6, since updated to 2.7. I cleaned up the footer, changed all the passwords, and we had no further trouble.

    By coincidence, at that same time (a month ago) my notebook (Windows) was infected by a rootkit. I was at some pains to get rid of it, finally resorting to an fdisk and restore of the system. I never determined what exactly the rootkit was or what it was. My real working computer is a Mac, and I seldom use the Netbook for anything but casual browsing. But I concluded that perhaps I had logged into the afflicted blog and had perhaps had my keystrokes logged.

    The attack has returned just tonight to the same blog. All the other WordPress blogs are clean, all the osCommerce sites are clean, and I’d stake my life that the server is clean. The database on the afflicted site appears to be clean, though I will have to check more carefully tomorrow. I do not believe there is any validation in the footer.php but will suggest to the programmer that he add some. The “subscribe to comments” plugin is active, and it is NOT being used on any of the other blogs.

    On my personal blog, which is miniscule, I have to clean up every day after user registrations from a domain called “” which I can’t find anything about–can’t do a lookup on it. Some poor schlub in India is being paid a tenth of a cent per registration–or at least that’s my guess. Registered users on my blog can’t do anything–your first comment has to be approved by me–so I can’t figure out why they are doing this unless they’re trying the doors.

    I intend to take more action when I can contact the “big” blog’s programmer tomorrow–but suggestions wlll be most welcome.

    July 7, 2009 at 11:15 pm

  48. Anne there is a wordpress plugin that can blacklist certain domains for registration which might stop the “”

    I suspect if they keylogged your admin password they would do far more than damage one WordPress blog on a dedicated server.

    July 8, 2009 at 12:32 am

  49. Name changed to protect the innocent

    Anne, what version of the “Subscribe to Comments” plugin are you running?

    Apparently the author closed some cross-site scripting (XSS) vulnerabilities in version 2.1:

    If I understand you correctly that the only compromised blog was running Subscribe to Comments, and if it is a version prior to 2.1, then I think we’ve found a smoking gun.

    Add that to my site where I found an XSS vulnerability in a different plugin, then we could conclude that our attacker is using some kind of generic XSS tool.

    July 8, 2009 at 10:38 am

    • Anne

      Name Changed, I have a bit of disappointing news. Yesterday when I began to evaluate the site in-depth, I found that while the plugin was installed, it had not been activated. I can check with the programmer to find out when it was deactivated if that would be of some help. Site was upgraded from 2.6 to 2.7 at the time of the first attack, which I think was about six weeks ago. I’m here in hopes of getting snippets of code that might assist the programmer in setting up validation in that footer.php file, as I think that is somehow our Achilles heel. Yesterday I added the additional secret keys, changed the name and password of the mySQL account, and set up dual accounts for the blog owner and for myself–one administrator login, a second to be used for comments and participation on the blog. I have also changed the name of the theme editor in order to disable it.

      I also combed through my server and found only a few minor vulnerabilities, which I plan to address (things like moving FTP to a different port). The server is your typical Linux/Apache/cPanel/whm installation, hosted in a secure facility. I upgraded the hardware and software back in December, and it was done with security in mind.

      The only other mildly interesting tidbit I found related to an IP deny I had set up on the blog’s site almost a year ago–the IP address of some newspaper in Nigeria from which people were attempting to post a lot of spam. After I posted that initial note here night before last, I returned to the blog and received a “server taking too long to respond” error in Firefox. It was of short duration, and when I did get in, I found that the log showed 300 access attempts on the site from that IP address in a span of less than 45 minutes. I set up the deny at the server level and there has been no further trouble on that score.


      July 9, 2009 at 11:39 am

  50. Pingback: Hardcopy » Blog Archive » Bah, mijn blog was geïnjecteerd!

  51. Name changed to protect the innocent

    Anne, thanks for the update. To bad there’s no smoking gun.

    To ask what may be an obvious question: what kind of “validation” are you talking about in footer.php? I know about HTML validation (not what you mean) and input validation to foil cross-site scripting attacks, but what input does footer.php take?

    Or maybe you say that some attackers invoke footer.php directly (…). But if footer.php doesn’t expect arguments or do anything with them, is this a vulnerability? And even if it were, how would that lead to injecting a spam payload into the footer.php file itself? Hmm.

    July 9, 2009 at 12:16 pm

  52. Leftout

    This bablooo spaming happend on one of our sites today I contacted the webmaster.. she said not a problem and we had NOT been hacked.. I’m sure she just modified the bad posts that she could find. After I did some reseach I found you (good reading) and this looks like they fixed the problem today in wordpress 2.8.1?


    July 9, 2009 at 9:59 pm

  53. Name changed to protect the innocent

    Leftout, thanks for the info. Fascinating. I’m having a little trouble on one quick read reconciling the AUSCERT bulletin with this statement from WordPress:

    “WordPress 2.8.1 fixes many bugs and tightens security for plugin administration pages. Core Security Technologies notified us that admin pages added by certain plugins could be viewed by unprivileged users, resulting in information being leaked. Not all plugins are vulnerable to this problem, but we advise upgrading to 2.8.1 to be safe.”

    So does the vulnerability discovered by AUSCERT and patched in 2.8.1 only result in a leak of plugin configuration info? Or can it be used to alter the contents of the database or PHP files?

    July 9, 2009 at 11:44 pm

  54. Hacked

    Hi, just to add some more information to the mix,

    The exploit showed up on my WP 2.7 blog as:

    * footer.php had spam in it, removed.
    * wp-blog-header.php had encrypted spam generating code, removed it.
    * lots of bogus “subscriber” accounts created, not sure if this was related

    These files were not world-writable, but at BlueHost only user-writable is required for WP to overwrite them.

    After fixing the two files above, upgraded to 2.8.1 which will hopefully patch things.

    My hunch is that this exploit has to do with a WP hole present up through and including 2.8 re:
    “WordPress Privileges Unchecked in admin.php and Multiple Information Disclosures”


    July 11, 2009 at 7:11 pm

  55. Pingback: Help for “bablooO” hacked / attacked WordPress Sites | Canton Becker

  56. Pingback: every WordPress install vulnerable to new security hack « _ck_ says…

  57. Pingback: bablooo, dangerous spammer - WordPress Help - bootstrapx

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s