Page 1 of 1

Site attack: templates_c

Posted: Mon Nov 17, 2008 7:45 pm
by Don Chambers
I know of a site running 1.3.1 (actually, its one of the never released 1.3.2) svn versions.

Someone is managing to insert <script> code into the the cached version of 2 files....

The actual tpls for that template have not been modified, and do not contain the <script>.

I purged templates_c yesterday, and today the bad files are back... so when I look at templates_c, I can see 2 different cached files for these 2 tpls... the only difference is all the characters in the filename, ie:

templatename^CHARACTERS%%entries.tpl.php.... the 'CHARACTERS', which I have never known how to decode, is different, but I essentially have 2 cached versions of entries.tpl.

Like I said, I purged everything yesterday, but today the nasty script is back, and 2 cached versions of the files are back.

Suggestions?

Re: Site attack: templates_c

Posted: Mon Nov 17, 2008 7:48 pm
by garvinhicking
Hi!

templates_c is often writable for the PHP process. thus, if a person manages to use any other PHP script, shell or remote exploit to write to any files that are world-writable, you can be subject of an attack. In this case, check all software involved in the server that runs with any privileges, because if it has access to your directory tree, it can tamper with those files.

Often PHP shells simply search for any writable files and simply insert their code everywhere.

Regards,
Garvin

Posted: Mon Nov 17, 2008 7:51 pm
by Don Chambers
Whew - that is a tall order.... lots of stuff on that server.... While I have not dug into everything just yet, the attack is very targeted to 2 files... anyway to help track down the problem knowing that?

Posted: Mon Nov 17, 2008 7:53 pm
by garvinhicking
Hi!

Are those the index*.php files?

Most PHP worms simply search for *index*.php files that are world-writable. That would only apply to those files in that case, because other files are not world-writable.

I'd check if all other installations of software on that server is secure. There is nothing inside current Serendipity that would suggest an attack vector, so I am quite sure the hack comes from another software.

You could check the server access files for suspicious HTTP activity. Search for anything with larger ?... query strings, or check the modification timestamp of that hacked index.tpl file and see if around that time specific HTTP requests were made.

Regards,
Garvin

Posted: Mon Nov 17, 2008 8:01 pm
by Don Chambers
The files being targeted are the cached versions of entries.tpl and entries_summary.tpl.

Posted: Mon Nov 17, 2008 8:08 pm
by garvinhicking
Hi!

I'd go with analyzing the HTTP logs at the time of the modification of the files, for nwo that's the best bet. If it doesn't shop up there, at least it means that serendipity or your web applications are not involved, in that case it might either be an FTP trojan or a server-side trojan/attack.

What code exactly is inserted?

Regards,
Garvin

Posted: Mon Nov 17, 2008 9:15 pm
by kleinerChemiker
and where is it inserted? maybe if its in the part where a plugin writes its content, than we could track it down to the plugin.

maybe you could post the code?

Posted: Mon Nov 17, 2008 9:18 pm
by Don Chambers
I am reluctant to post the code because it is malicious.... it is being written to various cached tpl files in templates_c.

Posted: Tue Nov 18, 2008 2:26 am
by Don Chambers
This stuff is way over my head...

If I am interpreting the logs correctly, the bug seems to resurface when a GET is made to something non-existent....

Does that help?

Posted: Tue Nov 18, 2008 11:23 am
by kleinerChemiker
not realy, at least to me. what non existant is called? an entry? is the malicious code in the get?

i'm not a security expert, but if you could send me the logs and the compiled files, i could try to look through the php files and try to look what php is doing. i'm a bit concerned, maybe there is a big hole in s9y?


register globals is off?