I ran into some trouble modifying my product and reinstalling it, so I tried installing the version I know works on my live site.
Still no love, just an error message I can't decipher which seems to contain spam! Any suggestions as to how I can diagnose this or where to seek help?
This pastie has the error, truncated due to size:
http://www.pastie.org/2715995
Come to think of it I did see an unidentified user listed at one stage...
Thanks!
Most likely, your site has been compromised by an automated script exploiting CVE-2011-2528. The script adds accounts, changes passwords of existing accounts, and customizes your main_template macro.
In order to clean this up, you need to:
Install the Plone Hotfix.
Reset your session secrets to prevent reuse of old session cookies the attacker may still have.
Audit the accounts present, removing any you do not know, especially if they Administrator access.
Clean up your main_template macro. If you never customized it through the web, simply delete it from your portal_sites/custom folder (go to the ZMI, select portal_sites, select custom, and delete), otherwise edit it and remove the hidden links at the bottom.
Related
I have a running Kentico 11 portal engine site and need to update the transformations in my navigation menu control. Something I have done many times before.
Today I went through all of the steps and the save button does not update the code. It never displays the change were saved messaging.
When I open the browser dev tools I see several errors on the page:
errors
A couple of things to check.
Is this happening in different browsers, also?
Can you save other transformations?
On this particular web part, if you select a different transformation, will that save successfully?
And, is the event log registering any errors?
Sounds like it may be a caching issue. What I'd suggest is the following:
restarting IIS
Open a private browser window and log in
attempt to make an edit to the code in question
If this does not resolve the issue, have you made any changes recently to the web.config, in particular the CMSHashstringsalt value? If so, this will cause your macros to become invalidated. You'll need to go to System > Macros > Signatures and check both boxes and resign the macros. It may take some time depending on your site but this could also help resolve your issue.
After uploading a normal jpg or png (anything) to the media library, we get the above error.
I've seen many posts on this topic and tried everything but still stuck.
I'm not the regular user, but I see dozens of other pictures have been uploaded, and suddenly we're getting this error.
I checked the server, there is disk space, the permissions for Uploads and Images folders are writable (777) and I've confirmed that I can upload through the Plex control panel. I also tried deactivating all the plugins.
There are a couple things I'm also curious about, but I'm not sure if they are related:
1) One said to make sure "Always use HTTPS" is checked, but I do not have that option which is talked about here: http://en.support.wordpress.com/https/
2) If I go to wp-admin/network/settings.php I get the WordPress message "You do not have sufficient permissions to access this page," even though I have a user with the Administrator role.
Is there another hidden user with greater permissions? Still not sure if that would help though, since everything was fine until recently.
Edit:
I found the cause, however I don't know why it happened or how to prevent it from happening in the future. The user for the 2013 folder, and a subdirectory for this month only, was set to Apache instead of ourusername like all the other folders. I don't know why this happened or how to prevent it from happening. I copied the folder and the user was by default set to ourusername which prevents the issue for now, but still wondering how to avoid this problem popping up again.
To get over this uploading an image error, you must make sure the permissions to this folder wp-content are set correctly.
ANSWER: The IUSR account should have read and write access. (Works for Plesk IIS and others)
Do not create the folders yourself in the WordPress area!
So I'm pretty sure my site's been infected with some kind of trojan or virus that attached itself to the scripting within the site. Every time I try and update my Drupal-based site, I get a white screen with this stupid "i'mhere" message. Upon reload, the changes will take affect but I don't know what this is doing once changes are saved. This only pops up while adminstering the site, I.E. posting new content, activating/deactivating modules etc.
Problem is, I haven't the faintest idea how or where to go to remove this. The source code doesn't make reference to any malicious code. It isn't the iFrame link kind of trojan that I've seen brought up through trying to find an answer to this problem.
Things I've tried:
-Scanned computer multiple times for virus (supposedly these things attack insecure FTP data & hijack your client to upload malicious code)
-Changed FTP credentials
-Changed admin user passwords to the backend of the site (Drupal login)
-Updated Drupal
Nothing's worked so far and I'm at my wit's end trying to figure this out. Any tips in the right direction would be greatly appreciated.
Assuming the problem is really Drupal, first check to see if there's some code in a module somewhere firing during a form submit. If you have shell access and it's a Unix/Linux/etc.-based server, navigate to the Drupal directory and run:
grep -r "i\'mhere" *
This will tell you if it exists in code and what file contains it. If it's a module (likely), disable it and either see if there's an update or modify it yourself.
If it's not in code, check your database. Create a dump of your database, and run:
cat databasedump.sql | grep "i\'mhere"
Where databasedump.sql is the name of the database dump you just created. This should at least give you a general idea of what table the data exists in. Then, you can decide how you want to proceed: restore from a previous backup, delete the offending data, etc.
If it's not in either, it might be local. Check with others to see if it's occurring for them.
If it's not local, you've got something really nasty and hopefully someone else has some other ideas on what you can check. :)
Here are a list of potentially useful tools which can help you alleviate, reduce or prevent a virus infection:
bdcored chkrootkit clamd drwebd ipfw iptables kav lidsadm
logcheck logwatch ninja nod32 ossec portsentry rkhunter
sav sawmill shieldcc snort sxid sysmask tcplodg tripwire
uvscan wormscan zmbscap
It is coming straight out of an infamous backdoor malicious software, described on this stackoverflow article.
You may want to manually search for other instances of the virus by running this simple command:
[~] grep -r "base64_decode" .
as suggested in this RAT infection article on thegothicparty.com:
http://thegothicparty.com/dev/article/server-side-virus-rat/
For some reason I can no longer post a comment as an Anonymous user in my Drupal installation. I haven't tried in a while, so I'm not quite sure when this functionality was broken.
I have Services installed, and I can post anonymous comments using comment.save. I have altered the Input Formats if that could break something.
I have enabled both post comments and access comments on the anonymous user. The comments does not show up in the database. In fact, the native Drupal function comment_save isn't called when I try to comment as Anonymous (I check this by adding print_r($edit);die(); at the top of the comment_save function in comment.module. Also I read something that not having a User with the UID 0 would break the Anonymous commenting, this user exists (obviously, since commenting through Services works)
I have tried out the AntiSpam module, and posted a comment as Anonymous that would get caught(and did) in the spamfilter, but this module is now disabled.
I'm really running out of ideas here, does anyone have any other suggestions on what to do? In the meanwhile I'm going to attempt to backtrack the code to figure out why comment_save() isn't being called.
Edit: Anonymous users also don't have to submit email and such to post, if that matters in any way.
By what you say, I suspect the problem is with some contributed code hooking on the comment form and modifying it in a way that makes it fail submission. This can be caused by a number of causes: a jQuery that adds fields to the form without regenerating the form-id on the server, an added or cusomised field that changes the callback to submit the form, etc...
I cannot know it for sure, but here's what I would do if I were you, in order to check what's up with your installation:
Make sure you disinstalled (and not only disabled) the modules you tried and don't use anymore. Modules should never touch core tables, but who knows... It does not cost anything and it actually frees some of your DB.
Try disabling all contrib modules and see if you can comment that way. If this is the case, activate the contrib modules one at a time until you find out which one is the culprit. Chances are you will already find a patch/workaround in the issue queue for that module on http://drupal.org. If you don't find a fix, I would investigate (xdebug or manual tracking) the code, and I would pay special attention to all implementations of hook_form_alter() and hook_form_FORM_ID_alter().
If even disabling all contrib modules doesn't help (which I would be very astonished of), try updating the core with a fresh installation if you consider as a possibility that your cat walked on the keyboard while you had a core file opened, or you live with Gordon Brown's family.
Failing that, the only alternatives coming to my mind are much more esoteric, such DB failure, a greasemonkey script on your browser interfering with commenting and similar unlikely possibilities.
HTH!
I solved this once by resetting the permissions table (http://drupal.org/node/64114), but I would do a proper backup and keep the permissions page open in a tab, just in case.
I have an incredibly frustrating problem cleaning up my site at the moment. On the same hosting space I have Umbraco (ASP.NET) and Blab Lite (PHP Chatroom) installed. The former talks to SQL 2005, and the latter to MySQL 5.
On my Umbraco site I had a guestbook with an entry form. Upon postback it does an Akismet check and skips the creation/saving of the corresponding Umbraco document if it is verified by Akismet as spam.
However, recently I started getting entries created under my guestbook node which are verified as spam, and yet the document is still saved. I have even gone as far as hiding the form using "display:none" and yet these entries are still created! I have modified the DLL to include logging to Umbraco document event logs and somehow the creation of these still does not trigger any entries to the logs. I've even created an eventhandler for Document.BeforeSave event in a separate assembly and this event handler is not catching the saving of these entries.
I'm really stumped as to how the spammers can create these entries. Has anyone got any ideas how this can be done, and how I can secure my site to prevent this kind of attack?
Thanks,
Dany.
This seems like an old post but it's not marked as answered so I'll give it a go. I havnt used Umbraco in a while so I'm not sure if they've fixed this in the latest version, but the problem is with Umbraco it self. Document.BeforeSave() gets fired AFTER the node is created, that's why your spam filter is not working. Marking the form as not visible wont work because the bot will look at the source code and just pattern match the form fields it finds. Have a look here for more details on the Umbraco problem:
http://forum.umbraco.org/yaf_postst9312_BeforePublish-and-BeforeSave-Event-Handlers.aspx
Like I said I haven't used Umbraco in ages, but hopefully it will help someone even if you've found a fix.
Paul
My guess is that there is a bug in your code to skip the creation/saving of the Umbraco document... although it is strange that the Document.BeforeSave event is not triggered. Are you sure that your event listeners are also working (i.e. do they register the saving of non-spam entries?)
By the way, setting "display:none" won't stop spammers as bots will generally ignore CSS anyway.
Yup, the event listeners are working indeed. This lead me to think something else is odd here. I finally took the plunge and went through it all with a finer-toothed comb. First I compared the content of the bin folder between standard Umbraco 4 distribution and the one on my host. I figured it was easiest to overwrite each one with a fresh one. Then I went through each Umbraco package I've installed and made sure the DLLs are also fine. Well, there was 1 DLL that didn't match anything else in Umbraco or packages I've installed - EO.Web.dll!
It seems there's a legit thing out there by EssentialObjects but I don't think Umbraco, my code, or any of the packages actually uses it! I deleted it and every part of my Umbraco install still works! I've now set visibility of of the form in ascx markup so it's not rendered - now we wait and see if that was the offending piece of malware!