Website was hacked with iframe and php bd I think, where can I educate myself?

[stilly]

long story short a website that was put up for a small local business was hacked, they gained access to the .htaccess file and inserted something there, they edited the rollover.js file in the assets directory and inserted an iframe line there.

What I did in response:

replaced ALL of the website with a fresh copy just to be safe.

BUT, about a day or so later it was infected again.

SO, I dug a little deeper and did this:

saved the rollover.js file and viewed it compared to a clean one, found the malware string as the first line or two. replaced the bad file with a clean one, did some research and generated a NEW htaccess file and replaced the one that was there. I also found a base_64 encoded php file named default.php (lazy asshats) and I did not think that there was any need to have a php file that was base_64 encoded (back in mac days of newsgroups) so I renamed that as defaultpossiblyinfected.php or I just removed it period. It was not in the root directory, but with the htaccess file. I also saw that there was one user listed in the htpassword or whatever it is called file and the user and pass did not match what I had changed anything to, the user matched, but the pass was different, I think that might have been an old PW, but the site has had a new PW assigned to it and I also used my ftp client to remove WRITE access to all of the web files and I think even some of the other files in the urchin5 directory are also write protected. When I generated a new htaccess file I think I was able to somewhat protect the htaccess file and some other stuff.

Is this sufficient? I hate that it happened on my watch and I have this feeling that there is more that I can do to lock the site down. It is being run from AT&T webhosting (not my choice, it is free) and oh I just realized that I will need to change the password for the ftp backup that takes place each week at the store. Anyways, it is an apache server I believe and I found a few sites that talk about the htaccess site but I think I need a good ebook on how to lock down a website like that. I only have one php script and it looks like that file was not messed with but it is used to send an e-mail for a contact form.

On top of that I followed the domain listed in the iframe trj and found it belonged to some asshats in west africa (ZA). I found a reference to a file there, so I made a DOC file with the link and then saved it as a htm file and then opened it and saved the file that was mentioned and then I opened it up to view it. It is an odd file, it is differently named then what the html file is on the link, but it looks like some sort of google_com or something that has a lot of google stuff in it.

Anyways, any words of advice from seasoned website vets or security. OR a link to an ebook or even a good ebook title would be sufficient. TIA

[ocabj]

Well, you need to go over all the php code to see if there's any code that can be exploited. PHP code pretty much runs with the rights as the web daemon user. If you have any directories or files with write access for the web daemon user, then poorly written php can be exploited to write to the filesystem in the places where there is write access for the web daemon user (or even gain a shell).

If the web daemon runs as root, then you're kind of hosed because then you have to vet all php code to make sure there's no exploitable code (overflows and what not).

[stilly]

There was only one PHP form that I had and it was only designed to be the action for a contact/e-mail form and it has not been touched that I am aware of. I have removed the other php form that was called default.php because I did not recognize it and it was encoded in base_64 and since I did not find a decoder for it (various results though) I pulled it and will assume that it is a hack file.

Thank you for replying, I do need to get some terms straight though.

web daemon? Is that supposed to be the website itself that a user gets pointed to and starts the index.html file if nothing else is designated in the htaccess file?

Gain a shell? Can you explain that a bit further please? I have heard about shell accounts and I was under the impression that a shell account is like a virtual machine- but anyways, can you explain that a bit please?

web daemon runs as root meaning that it is at the very BASE folder or it has superuser access and can do whatever? All of the docs start from a www folder from what I saw and they all appear to be seperated from other things, however, their are two different folders that had bad code in them, the one with the htaccess files and what not had the default.php file AND an edited htaccess file and then in another folder, (not a sub folder, but a parallel folder) the rollover.js file was edited with the iframe code.

I just got the greenlight from google that the website no longer has anything bad detected on it but it still miffs me how it even happened. I did not want to spend any perks in my webmaster skill sets so that I could have more in my hardware and networking skills...

I had to decide between php and aspx for the form a while ago and I happened on what I thought was a decent and well written piece of php code. It had remarks between the lines and made mention of not leting hackers insert spaces and what not.

thanks for the info so far.

[ocabj]

When I say "web daemon" I'm referring to the actual web server program. Typically, most web servers use Apache HTTPD, or the httpd service. httpd needs to be initially started as root (superuser) in order to bind to a privileged port (e.g. port 80), but all the httpd child processes (if the admin setup apache securely) will run as a non-privileged user. Usually that user is also called 'httpd', 'apache', 'www', or some other reserved username. Since httpd needs to be able to at the very least read your web directory in order to serve it out to the world, you usually have your web docs folder world readable (or at the very least, group readable for the httpd user's group).

Anyway, as long as you don't have any dirs or files that are writeable by the httpd user or httpd user's group, you should be fine, but this of course assumes that the web daemon isn't actually running as root for all child processes. Otherwise, any poorly written php code (especially anything that can write to disk) could potentially give an attacker a way to write to your web docs directory (or any files within).

Shell is basically an interactive interface to execute commands on the system. For example, you might SSH into your server to get to a command line interface. That is a shell. There are some functions in php that can be exploited (if they are not validating input) to invoke shell commands on the web server.

[stilly]

When I say "web daemon" I'm referring to the actual web server program. Typically, most web servers use Apache HTTPD, or the httpd service. httpd needs to be initially started as root (superuser) in order to bind to a privileged port (e.g. port 80), but all the httpd child processes (if the admin setup apache securely) will run as a non-privileged user. Usually that user is also called 'httpd', 'apache', 'www', or some other reserved username. Since httpd needs to be able to at the very least read your web directory in order to serve it out to the world, you usually have your web docs folder world readable (or at the very least, group readable for the httpd user's group).

Anyway, as long as you don't have any dirs or files that are writeable by the httpd user or httpd user's group, you should be fine, but this of course assumes that the web daemon isn't actually running as root for all child processes. Otherwise, any poorly written php code (especially anything that can write to disk) could potentially give an attacker a way to write to your web docs directory (or any files within).

Shell is basically an interactive interface to execute commands on the system. For example, you might SSH into your server to get to a command line interface. That is a shell. There are some functions in php that can be exploited (if they are not validating input) to invoke shell commands on the web server.

I see now. Well, a little better. I need to see things at different angles multiple times sometimes before I grasp their concept fully. The PHP IS mainly just a validation file for the e-mail form. I am going to guess that you might know how to use php and exploit it to get these shell commands? I need to test the site now although google has it still showing as clean, and it has been clean now for the past 3 days.

How about a good book to learn how to hack these things or how to plug the holes? I did not touch nor was I aware of those files in the urchin directory. Is there a website that has a checklist of things for me to look at before I can consider it locked down?

So maybe they found a way to exploit the single php file that I had and that allowed them to bypass security? Well they have not been back or if they have at least not in a way that I have noticed.

[ocabj]

For an idea of how input sanitizing applies to various contexts:

http://coding.smashingmagazine.com/2011/01/11/keeping-web-users-safe-by-sanitizing-input-data/

PHP docs on php filters available:

http://php.net/manual/en/filter.filters.php

[stilly]

Nice thanks. I will give them a read.

[atto]

I'm pretty sure that they are using the base64 encoded file to enter code.

For example, a friend of mine had a notepad app on his website that let you write a subject and insert text. I named it foobar.php and inserted php with a "z" variable that would be decoded via base64. I then wrote php code, encoded it in base64, and added z=MYBASE64 to the end if his url.

Eg. Foobar.php?z=mybase64

That would allow me to run anything I wanted on his server, including a remote shell.

More to come later (on my phone)

[stilly]

interesting. This is good to know too. What does that do for you?

[atto]

Basically, it would allow me to do anything that I wanted. If I were an azz, I could delete his site. I told him about it and told him he should remove the notepad app.

Anyways, my advice re: your situation is that you should update the Phpbb software to the latest version.

Some hackers write scripts that roam the internet looking for vulnerable software. Once they find, for example, Phpbb version xx (version that has a vulnerability), the script runs an exploit and does any number of things.

Wait..

I only have one php script and it looks like that file was not messed with but it is used to send an e-mail for a contact form.

I think I might have read it wrong. So there is no discussion forum on the site? Only the email contact form?

In that case I would look for a replacement contact form from another source.