When I attempt to save changes to blocks, I am presented with a page that has only two textfields and a button that says authenticate.

When I enter my user name and password in these fields, it kicks me back to the block configuration page without saving the changes.

There seems to be no way for me to change my blocks settings.

I thought this might have something to do with the fact that I just changed the username for user 1, but I chaged it back and still have the same problem.

Any help you can offer is greatly appreciated.

Comments

Mike in Maine’s picture

logging out and in
switching themes
giving another user block configuration permission and attempting to configure them using that account
turning off all contributed modules

Nothing seems to work. I'm really at my wits end about this one.

WorldFallz’s picture

I am presented with a page that has only two textfields and a button that says authenticate.

What does it look like? If it's not obviously drupalish, it could be some sort of webserver authentication.

===
"Give a man a fish and you feed him for a day.
Teach a man to fish and you feed him for a lifetime."
-- Lao Tzu
"God helps those who help themselves." -- Benjamin Franklin
"Search is your best friend." -- Worldfallz

Mike in Maine’s picture

It's absolutely blank except for the two fields (which are unlabeled) and the button, all in the top-left corner.

mooffie’s picture

...or it could be a trojan something.

Mike in Maine’s picture

The location bar for the weird page just says "http://(my site)/admin/build/block"

Here's its source:

<form action='/test/admin/build/block' method='POST'><input type='text' name='login'><br/><input name='pass' type='password'><br /><input type='submit' value='authenticate'></form>

I've changed my password in case it's a trojan - but how would that have infected my site, and how can I fix this?

The theme is Marinelli. It's the latest Drupal 5 installation, and hosted at siteground.

Mike in Maine’s picture

Any other thoughts on this?

mooffie’s picture

I'd start by going to Drupal's root folder and issuing the command:

grep --color -R "value='authenticate" *

And also:

grep --color -R 'decode\|unescape' *

It'll print lines where your 'authenticate' may come from. You'll have to inspect all of them. This check is superficial, it's only a start.

Mike in Maine’s picture

Is that something I can do from CPanel?

I've also tried updating the whole install with the same version (keeping the same database and the same "sites" and "files" folders)

I am able to create blocks fine through Drupal, and I can move them around by changing the values in the mysql table, but I still get the same weird page when trying to do it from the configure blocks page.

rodzilla1951’s picture

I've had the exact same problem.

In my case the problem appeared in a 5.4 site, so I upgraded to 5.10 and the problem disappeared for a while.

However, today on my 5.10 site, I uploaded Ubercart and with required and optional modules imagefield, thickbox, tapir, ubrowser, and workflow_ng. Now the problem has resurfaced: I am in the Admin --> Site Building --> Blocks menu. My URL shows http://{www.mysite.com}/admin/build/block.

When I hit the "Save Blocks" button an unthemed page appears with no title (the URL is still the same) and two fields are displayed - a text field and a password field that are pre-populated. The text field has my user name, the password field has the right number of characters for my password. This happens when I am using Google's Chrome browser and the browser remembers my user/password. When using IE7 without "save passwords" then the fields are not pre-populated.

When I examine the source code for the page, there is nothing listed in the source code that seems like it would generate the mystery page I see. For example if I look for the text "authenticate" that is the button label on this mystery page there is nothing in the source code that matches.

The html source code around the Save Blocks is:

<input type="submit" name="op" id="edit-submit" value="Save blocks"  class="form-submit" /> 
<input type="hidden" name="form_token" id="edit-block-admin-display-form-token" value="{an id number}"  /> 
<input type="hidden" name="form_id" id="edit-block-admin-display" value="block_admin_display"  /> 

I also just tried re-uploading the various Drupal source folders - includes, misc, modules, profiles, scripts. No help.

This sure looks like a great way for a virus to be grabbing system admin user/pasword information..

rodzilla1951’s picture

I sent a post off to the good drupal security folks and got this back:

It looks like your site may have been the victim of an sql injection attack. I found some pointer on the internet suggesting the same behavior on a variety of setups (see [1], in particular).

Finding the origin of the issue may prove to be tricky. The issue may not even be Drupal-related (Drupal is generally well protected against sql injection attacks).

Please see http://drupal.org/node/213320 for some instructions on what you could do to investigate the issue.

[1] http://groups.google.com/group/mailing.www.horde-bugs/browse_thread/thre...

I've already reloaded the orginal Drual source files; since I had installed a BUNCH of modules just before this problem occured, I am backing out the modules and will see if that removes the problem. If so, I'll start reloading one-at-a-time till I narrow down the offending module...

rodzilla1951’s picture

Sorry for the stream-of-events approach, but I just COMPLETELY blew away the old site, re-loaded 5.10 source files (without my long list of added modules) to a new data base and was able to go through the ADMIN --> SITE BUILDING --> BLOCKS --> SAVE BLOCKS cycle without the problem described above. Interesting that when I deleted-then-replaced MOST of the source files (everything in the sub-directories: includes, misc, modules, profiles, scripts, sites) the problem was not solved. But a complete fresh install DID solve the problem.

I also switched back to my original database and again did not encounter the SAVE BLOCKS problem. So far, so good.

Next step is to upload my long list of modules and see if that brings back the problem...

rodzilla1951’s picture

I found hundreds of files php on my site that have had virus php code inserted in them that starts with:
<? /**/eval(base64_decode({a long string of randomish text}

Unix find and sed are my new friends (who knew?). In my case I used shell access and putty run a command that erased the offending line in every file on my site:
find . -type f -exec sed -i '/{the string to be found - something from the virus string like awkodifhpy}/ d' {} \;

Note I am NOT a unix expert and the potential for this type of thing to go horribly wrong is very very high. Caveat emptor.

Next I am going to try to write protect the php files on my site...444 is my current thought...