I've had a boat building website online since 1999.
My site got hacked for the first time in those ten years just the other day.
I use a "virtual dedicated" server at godaddy.
I found a file with the spurious eval gz inflate base 64 decode stuff in it,
which ultimately allowed (somebody) to display a phoney pharacutical website,
that prompts unsuspecting users for credit card numbers.
I used find and grep to identify all the bad files (some had names like dot comma '.,' )
Then I changed the root password and my login password.
And then I changed ALL files to 555 permissions, except for a few LOG files here
and there that need to be written to. That was two weeks ago and I seem to be OK.
MY QUESTION:
How the hell were they able to write to my hand-written PHP files in the first place?
I have run phorum for almost a decade, with now close to 15,000 individual posts.
Right before the hack I experimented with the SMF forum, for perhaps a week.
I imported all 15,000 posts to SMF, and immediately started to get bot-like spam.
I say bot like, because the server logs showed zillions of failed login attempts.
And maybe 6 successful SMF posts per day. The SMF captcha was visually weak.
So maybe they have code that guesses captcha images. Each spam post to the
SMF forum was matched with a new user_id in the SMF mysql user table, with machine like names (cnFall2010 etc)
So I zapped SMF and went back to phorum.
But a few days later I noticed the eval gzinflate hack. Maybe this had nothing to do with SMF.
I just want to know how it was done in the first place.
I do also use a mysql password system (written by me)--users who pay for a password (PayPal)
get a password which grants them access to normally hidden directories of
boat building information. All page content in my home-rolled CMS system comes from files (div contents = file_get_contents($filepath).
But that system checks for illegal file paths and exits silently. I've tried to break it a million times and never yet succeeded.
And unlike Wordpress, Drupal, etc, nobody in the whole world knows my souce code except me.
I use mysql for the login mechanism only. I do not encrypt the login passwords. I figured
thieves don't care about boat building instructions anyway. I could generate keys and switch to https.
I'll think about that one. Probably have to get that together soon.
I do also now run fail2ban. Anyway, is there any hope of somehow figuring out how this
was done? Analyzing error_log.gz stuff? What do I look for?
Eval Gz inflate Base64 decode
Moderator: General Moderators
-
pittendrigh
- Forum Newbie
- Posts: 2
- Joined: Sat Oct 16, 2010 8:42 am
- John Cartwright
- Site Admin
- Posts: 11470
- Joined: Tue Dec 23, 2003 2:10 am
- Location: Toronto
- Contact:
Re: Eval Gz inflate Base64 decode
My checklist I created for a website I've recently had hacked as well (a very old website).
1. Change all your passwords, as you have already done.
2. Update all versions of software you are running, specifically PHP -- to the latest version.
3. Determine whether you are open to Remote File Inclusion.
-- 3a. Do you allow users to upload any file types whatsoever?
----3.a.a. How secure is your validation, i.e., if you are allowing image uploads, I tend to perform some kind of image manipulation to guarantee it is actually an image. (can't be too careful here).
----3.a.b. Do you run your uploaded content under the same user as your website?
-- 3b. Do you implement some kind of front controller, combined with allow_url_wrapper settings may allow arbitrary files to be included.
4. If you have automated backups, restore your site to a previous state previous to cracking.
5. Check your logs for anything out of the ordinary.
-- 5.a. If suspicious logs come from a particular IP, ban the ip.
-- 5.b. If suspicious logs come from various IP addresses, consider implement additional security for login, registration, and password reminding actions. I.e., Captchas.
6. Create a cron job file to recursively iterate your entire web root, which checks the last modified time of your files. If any of them change from the last one, without being expected from your programmer/admins (obviously), then have it notify your admins that a cracking may have occured.
1. Change all your passwords, as you have already done.
2. Update all versions of software you are running, specifically PHP -- to the latest version.
3. Determine whether you are open to Remote File Inclusion.
-- 3a. Do you allow users to upload any file types whatsoever?
----3.a.a. How secure is your validation, i.e., if you are allowing image uploads, I tend to perform some kind of image manipulation to guarantee it is actually an image. (can't be too careful here).
----3.a.b. Do you run your uploaded content under the same user as your website?
-- 3b. Do you implement some kind of front controller, combined with allow_url_wrapper settings may allow arbitrary files to be included.
4. If you have automated backups, restore your site to a previous state previous to cracking.
5. Check your logs for anything out of the ordinary.
-- 5.a. If suspicious logs come from a particular IP, ban the ip.
-- 5.b. If suspicious logs come from various IP addresses, consider implement additional security for login, registration, and password reminding actions. I.e., Captchas.
6. Create a cron job file to recursively iterate your entire web root, which checks the last modified time of your files. If any of them change from the last one, without being expected from your programmer/admins (obviously), then have it notify your admins that a cracking may have occured.
Re: Eval Gz inflate Base64 decode
Can you change your root password and post the old one here? I've had this happen to clients who were simply hosting .html files. I suspect it has something to do with bad passwords, or bad web hosting company. When it happened to him it was on a shared server, we moved him to a VPS and restored from backup - hasn't come back since. It used the base64 obfuscated code like you describe but was installing malware according to google.
-
pittendrigh
- Forum Newbie
- Posts: 2
- Joined: Sat Oct 16, 2010 8:42 am
Re: Eval Gz inflate Base64 decode
RE> "the Eval gz inflate base 64_encode hack appeared on static html sites"
Interesting. It's hard to draw any conclusions because it was on a shared host.
RE> "would I post my old password?"
I can say the old password had 9 characters, including one digit, one punctuation mark and two caps.
Setting all PHP files to 555 permissions is a pain. I have to log in and manually
change permissions before editing. But I haven't been exploited a second time yet.
If the apache process cannot write to my files, neither can they ( I hope ).
In the original post to this thread I mentioned that I suspect the SMF forum, which
I had experimented with for several weeks (only). My server logs STILL show numerous
daily requests to that URL, even though the mysql tables directories and files
are long gone. So it does seem that old SMF URL is out there on a hackable list somewhere.
It is also interesting that spammers started registering phony users on SMF within
hours of its installation.
=========found this on the net, at http://www.securityfocus.com/bid/26144============
SMF Image File HTML Injection Vulnerability
SMF is prone to an HTML-injection vulnerability because it fails to properly sanitize user-supplied input before using it in dynamically generated content.
Attacker-supplied HTML and script code would execute in the context of the affected website, potentially allowing an attacker to steal cookie-based authentication credentials or to control how the site is rendered to the user; other attacks are also possible.
Note that this vulnerability may be triggered only in the Internet Explorer browser.
SMF version 1.1 is vulnerable to this issue.
I have better luck with Phorum.
Interesting. It's hard to draw any conclusions because it was on a shared host.
RE> "would I post my old password?"
I can say the old password had 9 characters, including one digit, one punctuation mark and two caps.
Setting all PHP files to 555 permissions is a pain. I have to log in and manually
change permissions before editing. But I haven't been exploited a second time yet.
If the apache process cannot write to my files, neither can they ( I hope ).
In the original post to this thread I mentioned that I suspect the SMF forum, which
I had experimented with for several weeks (only). My server logs STILL show numerous
daily requests to that URL, even though the mysql tables directories and files
are long gone. So it does seem that old SMF URL is out there on a hackable list somewhere.
It is also interesting that spammers started registering phony users on SMF within
hours of its installation.
=========found this on the net, at http://www.securityfocus.com/bid/26144============
SMF Image File HTML Injection Vulnerability
SMF is prone to an HTML-injection vulnerability because it fails to properly sanitize user-supplied input before using it in dynamically generated content.
Attacker-supplied HTML and script code would execute in the context of the affected website, potentially allowing an attacker to steal cookie-based authentication credentials or to control how the site is rendered to the user; other attacks are also possible.
Note that this vulnerability may be triggered only in the Internet Explorer browser.
SMF version 1.1 is vulnerable to this issue.
I have better luck with Phorum.