[Kobra]

Some days ago one of my site logs had been hacked, it has been added an iframe code, but since it was a .log, the iframe hack didnt work on browser.
I just want to know if web servers are so vulnerable that any hacker may just get into them and do whatever they want like deleting files and so.

[webzen]

Okay, there's a bunch of grey zones you don't mention in your post.

First off, what's the 411 on your web server? Are you running Apache or IIS? These are necessary to properly address the security issue.

Apart from the hacking questions, you should know that anyone in the world can easily iframe your web pages into his, for whatever purpose... unless you install a code that breaks such "inclusion frames".

In the case of logs, forgive me for asking but why haven't you hosted those behind the air-tight protection of a realm (especially easy under Apache)?

If your "iframer" doesn't have the access codes to your newly created realm, the he can't see you log pages... even less share them with the world.

Wouldn't that be a short term -and effective- fix?

[Kobra]

Let me see if i can explain this better:

I have a file called example.log (just an example)

File structure is:

..
error line 1
error line 2
..

somebody, somehow, accessed that file and changed it into this:

<iframe>
..
</iframe>
error line 1
error line 2
..

[curbview.com]

Originally Posted by Kobra

Let me see if i can explain this better:

I have a file called example.log (just an example)

File structure is:

..
error line 1
error line 2
..

somebody, somehow, accessed that file and changed it into this:

<iframe>
..
</iframe>
error line 1
error line 2
..

True security practices by your hosting company would simply make sure that your access.log file was non-web accessible. Having said that, you have to check the permissions of your root directory to make sure that other people hosting sites on the same server cannot access YOUR files and folder as well. This seems to be more and more common with hosting companies not enforcing *better* security measures. Most hosting companies would have CHMOD'd your root folder to 755 at worst. This means that the server have read(4) + write(2) + execute(1) permissions =7, others on the server have read(4) + execute(1) permissions =5, and anyone on the Internet has read(4) + execute(1) permissions =5 thus giving you the resulting 755 permission settings. Some servers are different when it comes to CGI directories, but that is another conversation...

Hope that helps...

[Kobra]

Is there any possibility someone got into webserver cpanel? I heard that cpanel is vulnerable to external attacks...

[King Coder]

Originally Posted by Kobra

Is there any possibility someone got into webserver cpanel? I heard that cpanel is vulnerable to external attacks...

If they have your password. I think if your CPanel was hacked you would have a lot more damage done. I've given my CPanel and FTP passwords out before so that I could have work done, but I immediately changed them afterwords.

It's probably been some simple exploit scan that came up positive on your site. As curb basically said, your hosting company should have holes like that closed.

[curbview.com]

Originally Posted by King Coder

If they have your password. I think if your CPanel was hacked you would have a lot more damage done. I've given my CPanel and FTP passwords out before so that I could have work done, but I immediately changed them afterwords.

It's probably been some simple exploit scan that came up positive on your site. As curb basically said, your hosting company should have holes like that closed.

I was going to leave this thread be since the OP hasn't of late, responded to the feedback given. I have been able to replicate the hack on a local server. This method has been in the wild and is similar of "cross-site scripting". It is not a case of hacking the server as Kobra's original post stated that it showed up in his log file. If you were a client, I would look at your log file to find which script was used and secure it by sanitizing user-input (namely, the $ENV{'QUERY_STRING'}.)

To exploit this type of hack, the hacker believes that the victim will view his server logs with a browser (as many hate looking at the raw format and the abundance of log-analyzing software on the open market) and in doing so, tries to gather data for a perhaps future security compromise be it on or off-line.

You may want to find a CEH and have them perform a security analysis of your server and scripts.