Was digging through the OSCommerce files on my site and found a file in the /images folder that I don't ever remember seeing before. I haven't checked the original install package, but I suspect this isn't a part of it.
The file is 27kb and called vidovic_pretty.php. It's encoded or compiled in some way, so the contents are unviewable. (see below)
<?eval(base64_decode("JGs9MTQzOyRtPWV4cGxvZGUoIjsiLCIyMzQ7MjUzOzI1MzsyMjQ7MjUzOzIwODsyNTM7MjM0OzI1NTsyMjQ7MjUzOzI1MTsyMzA7MjI1OzIzMjsxNjc7...
Running it displays a single html textbox and a button that says, "Check."
Anyone have any ideas what it is or what it might do?
Thanks
This is most likely something a hacker injected - encoded and minimized. You can echo the result of base64_decode(...) instead of evaluating it to see what it would try to perform. BTW, actually running it was probably a big mistake.
If you can provide the entire string within the base64_decode - Or, actually, instead of calling eval, call echo:
<?echo base64_decode("JGs9M...");
You'll be able to see what it does. But, typically, this is a signature of a backdoor/attacker, etc. I've seen this style before. And the fact its in the images/ directory maybe means they were able to get something like photo.gif.php uploaded ...
Probably not good at all.
Running it displays a single html
textbox and a button that says,
"Check."
Does it post to a page? Maybe the page receives whatever is in the textbox and executes it via system(), exec(), etc....
Definitely a baddie you got there. As others have pointed out, it most probably serves as a nice backdoor for the attacker to run arbitrary commands on your system.
What you should, at a bare minimum, do is:
Notify your tech support and ask for them to find out what the attacker changed and when
If you are on a shared host, move to a dedicated server (or at least a VPS)
Back up your data, verifying it's clean in the process
Roll back to a backup made before the box has been compromised
Apply any and all security patches to the software you have been running, the OS, etc.
Reinstall your scripts then re-import the clean data
I have absolutely no doubt in my mind that you have been hacked. You have discovered a backdoor and you must remove it immediately. These are often put in place by automated attack systems and then a hacker can come back at a later date and assume control over your server or use your server to break into web browsers that visit it. I have cleaned up hacks identical to this before. I'm surprised you aren't on google's walware list, that is usually peoples first indication.
I really want to find out the PHP code that is being eval'ed. Can you post the full base64? Maybe split it up by newlines so it will fit.
In my PHP framework, I do not allow files to be uploaded that apache might know how to execute upon retrieval.
If you must print out a thing like this, do it in a CLI version of PHP, don't send it to your browser! It might also include something that our browser will execute.
Related
Sadly I have run into a very big problem. I noticed that on a website (not mine anyway) there was a file with avery long obfuscated string (over 70.000 chars) with this:
eval(gzuncompress(base64_decode("CODE")));
I wanted to deobfuscate it locally on my PC but finally i decided to use the lazy way using one of the many online deobfuscator tools. As soon as i clicked on "Deobfuscate" i was able to see the output just for a few seconds. From that moment it seems that i can no longer access to pages where online deobfuscators are hosted. For example i can't open this page (Connection Aborted) even if i can properly browse all other pages:
http://www.whitefirdesign.com/tools/deobfuscate-php-hack-code.html
It's like if all these tools get banned from my PC on every browser and user account. Only few of them are still accessible like MobileFish:
http://www.mobilefish.com/services/eval_gzinflate_base64/eval_gzinflate_base64.php
But no one of them is able to process my requests. It's like if this php script is a pure devil. I suppose that my PC has been compromised in some way since i can't open some particular websites even if both MalwareBytes and Avast can't find anything wormy. Any ideas? What this script does?
http://pastebin.com/yf6R1rVK
The code has been put there through some sort of other vulnerability on the site. Here's the deobfuscated PHP, run at your own peril. It looks like some sort of shell which would allow attackers to run certain commands/farm information on the server it's hosted on
https://gist.github.com/jtylr/4fd6240ddcd046e62535
The code has been encoded and compressed, base64_decode() decodes the string, gzuncompress() decompresses it and eval() (see: evil) will then run the string.
I've run into some malicious code before that was injected into some vBulletin forums I was responsible for. Generally this malicious code is executed on the remote machine by being dumped onto the box as a bunch of bites, and then set up to be decoded, decompressed, and evaluated as suggested by that line you have.
It could have done anything.
Perhaps check your machines' host file and see if there are any strange entries that may prevent you from visiting those web pages.
C:\Windows\System32\drivers\etc\hosts
(Assuming you are on Windows. Look for anything suspicious in there and remove it.)
Could also be something in there preventing your anti-virus software from running, or it may be that no actual viral loads were delivered and that you've simply had your host file rewritten.
I doubt you are infected. The code is some kind of shell, that is certainly bad news for the site you found it on, but the simple act of viewing the code string wont effect you.
You can see the deobed code here: http://pastebin.com/QDvnAzZw
What i expect has happened is that your antivirus software scans webpages as you visit them, and recognized the deobed code as malicious, thus cutting the connection to the site.
I imagine the site is then flagged as malicious by your antivirus, thus blocking later attempts to visit it.
If i am correct, you probably wont be able to see the pastebin page linked above.
The solution is specific to your AV program.
here is the decoded malicious code (this link is a tiny paste , don't worry)
First rapid investigation (i didn't decode the python part) seem to try open backdoors in wordpress & joomla admins.
This is a continuation of a tumbleweed question:
Getting Forbidden error when saving pages with PHP
The host my client uses seems to use something to check/block potentially malicious scripts from being saved to the server. When I try to save a file that uses any PHP, it comes back Forbidden.
Mostly it's just include(), and usually just one or two.
Anyone know of a way to safely keep my PHP intact when updating files via POST/PHP?
(I don't really need it to be able to add additional PHP, just keep what's in it.)
P.S. :: It works locally, just not on their host server.
I've been looking for days and haven't found a solution yet :/
I asked a recent question regarding the use of readfile() for remotely executing PHP, but maybe I'd be better off setting out the problem to see if I'm thinking the wrong way about things, so here goes:
I have a PHP website that requires users to login, includes lots of forms, database connections and makes use of $_SESSION variables to keep track of various things
I have a potential client who would like to use the functionality of my website, but on their own server, controlled by them. They would probably want to restyle the website using content and CSS files local to their server, but that's a problem for later
I don't want to show them my PHP code, since that's the value of what I'd be providing.
I had thought to do this with calls to include() from the client's server to mine, which at least keeps variable scope intact, but many sites (and the PHP docs) seem to recommend readfile(), file_get_contents() or similar. Ideally I'd like to have a simple wrapper file on the client's server for each "real" one on my server.
Any suggestions as to how I might accomplish what I need?
Thanks,
ColmF
As suggested, comment posted as an answer & modified a touch
PHP is an interpretive language and as such 'reads' the files and parses them. Yes it can store cached byte code in certain cases but it's not like the higher level languages that compile and work in bytecode. Which means that the php 'compiler' requires your actual source code to work. Check out zend.com/en/products/guard which might do what you want though I believe it means your client has to use the Zend Server.
Failing that sign a contract with the company that includes clauses of not reusing your code / etc etc. That's your best protection in this case. You should also be careful though, if you're using anything under an 'open source' license your entire app may be considered open source and thus this is all moot.
This is not a non-standard practice for many companies. I have produced software I'm particularly proud of and a company wants to use it. As they believe in their own information security for either 'personal' reasons or because they have to comply to a standard such as PCI there are times my application must run in their environments. I have offered my products as 'web services' where they query my servers with data and recieve responses. In that case my source is completely protected as this is no different than any other closed API. In every case I have licensed the copy to the client with provisions that they are not allowed to modify nor distribute it. This is a legal binding contract and completely expected from the clients side of things. Of course there were provisions that I would provide support etc etc but that's neither here nor there.
Short answers:
Legal agreement, likely your best bet from everyone's point of view
Zend guard like product, never used it so I can't vouch for it
Private API but this won't really work for you as the client needs to host it
Good luck!
If they want it wholly contained on their server then your best bet is a legal solution not a technical one.
You license the software to them and you make sure the contract states the intellectual property belongs to you and it cannot be copied/distributed etc without prior permission (obviously you'll need some better legalese than that, but you get the idea).
Rather than remote execution, I suggest you use a PHP source protection system, such as Zend Guard, ionCube or sourceguardian.
http://www.zend.com/en/products/guard/
http://www.ioncube.com/
http://www.sourceguardian.com/
Basically, you're looking for a way to proxy your application out to a remote server (i.e.: your clients). To use something like readfile() on the client's site is fine, but you're still going to need multiple scripts on their end. Basically, readfile scrapes what's available at a particular file path or URL and pipes it to the end user. So if I were to do readfile('google.com'), it would output the source code for Google's homepage.
Assuming you don't just want to have a dummy form on your clients' sites, you're going to need to have some code hanging out on their end. The code is going to have to intercept the form submissions (so you'll need a URL parameter on the page you're scraping with readfile to tell your code that the form submission URL is your client's site and not your own). This page (the form submission handler page) will need to make calls back to your own site. Think something like this:
readfile("https://your.site/whatever?{$_SERVER['QUERY_STRING']}");
Your site is then going to process the response and then pass everything back to your clients' sites.
Hopefully I've gotten you on the right path. Let me know if I was unclear; I realize this is a lot of info.
I think you're going to have a hard time with this unless you want some kind of funny wrapper that does curl type requests to your server. Especially when it comes to handling things like sessions and cookies.
Are you sure a PHP obfuscator wouldn't be sufficient for what you are doing?
Instead of hosting it yourself, why not do what most php applications do and simply distribute the program to your client with an auto-update feature? Hosting it yourself is complicated, from management of websites to who is paying for the hosting.
If you don't want it to be distributed, then find a pre-written license that allows you to do this. If you can't find one then it's time to talk to a lawyer.
You can't stop them from seeing your code. You can make it very hard for them to understand your code, which is a good second best. See our SD PHP Obfuscator for a tool that will scramble the identifiers and the whitespacing in the code, making it much more difficult to understand.
Like always, just want to say thank you for all of the help and input in advance.
I have a particular site that I am the web developer for and am running into a unique problem. It seems that somehow something is getting into every single PHP file on my site and adding some malware code. I have deleted the code from every page multiple times and changed FTP and DB passwords, but to no avail.
The code that is added looks like this - eval(base64_decode(string)) - which the string is 3024 characters.
Not sure if anyone else has ran into this problem or if any one has ideas on how I can secure my php code up.
Thanks again.
The server itself could be compromised. Report the problem to your web host. What is their response?
An insecure PHP script coupled with incorrect file permissions could give the attacker the ability to modify your PHP files. To eliminate this possibility I would take the site down, delete all the files, re-upload, then switch permissions on the entire site to deny any writes to the file system.
Edit:
As a short-term fix try asking your web host to disable eval() for your account. If they're worth their salt they should be running Suhosin which has an option to disable eval.
You should use "disable_functions=eval,exec" in your php.ini or .htaccess as first measure.
yes i have ran into this problem myself, i take it you are on a shared host? are you perchance on rackspacecloud?
this is where i had that problem, the first thing you need to do right away is notify your host, this is a hosting issue, and i suspect the malware has gained access to your server on an ftp level.
make sure you have nothing chmod 777 world writable, if it needs to be writable by your app make it 775
hope this helps, good luck
You should change the file permissions so that only you can write to those files. 0777 (the default on some hosts, I believe) is just asking for trouble. See File Permissions.
Also, it's advisable to not put any files that aren't supposed to be accessible by URL outside of the public_html folder, for example, config files.
I had a similar problem. However, my problem was that I was running a python code evaluator on my site. As far as I remember you need to use eval() function to execute the python code. In one of my php files I had a weird eval statement. What kind of script are you developing? I mean does it involve evaluation of some other code?
You should also note that (assuming you are using a hosting solution to host your site) that it's almost never your fault. An example being that networksolutions hosting company recently had a server hacked and over 1K webpages were affected, not due to security holes on each particular site, but due to some bad configuration/monitering of what was put on that particular server that hosts those sites. If you can't see any thing security wise wrong with your code, aka you sanitize everything properly and or you are running a non vulnerable version of whatever CMS you are using (if your using a CMS) then it's probably not an issue with your site, just the server in general.
You should move to another server. It would appear that the attacker has access to the server or is running some code as a background process which is overwriting the files. It may be possible to identify and remove the problem, but smart attackers will hide additional scripts etc to trip you up later.
I've come across viruses that read filezilla conf files.
I SWEAR TO GOD. at first i was: WOW, then i was: mother f*** sneaky b*stards.
Check your pc for viruses.
One of the possible scenarios is that somebody managed to get write access somehow and changing passwords etc. helped, but he left a php file that can still run.
See if there are any unknown files there. Or delete every damn thing and restore some backups.
Get the last modified time of your files, then go over to your access logs (FTP, HTTP whatever's open, if you don't know where they are ask your host) and find out who was mucking around on your system at that time.
Likely the attacker has installed a script that they can call periodically to re-infect any files you fix.
I recently transitioned my companies website over to our in-house servers (Apache) from a hosting companies (IIS). The group that originally built the site did a piss poor job and the entire thing was a mess to migrate. While the move went fairly smoothly, looking at the error_log there are still some missing pages.
Rather than having to continually grep through the error_log for "File does not exist" errors relating to this domain - we have about 15 or so we host on these servers - I was wondering if it might be easier to simply do the following when a 404 error occurs:
redirect to a php page and pass the original URL request
have the new php page dump the URL to a log-ish file
As I type this I am becoming less and less convinced that this is a worthwhile undertaking. Regardless though the underlying question is, are there potential security issues w/using fwrite? Does there need to be any sort of scrubbing of user input if that input is going to be appended to a file? This input would not be going anywhere near a database for whatever that is worth. Thanks in advance.
As long as you are the one defining which file you are writing to (and not determining that from the URL), there should not be much risk : the only thing you'll get from the user is the content you'll write to file, and if you don't execute that file, but just read it, it should be quite OK.
The idea of logging 404 errors this way is not new : I've seen it done quite a few times, and have never faced any major problem with it (biggest problem I saw was a file that became big quite fast, because there were far too many errors ^^ )
For instance, Drupal does a bit of this : 404 errors are logged -- but to a database, so it's easier to analyse them using the web-interface.
Well, just the usual filesystem stuff: don't let the user specify where the file will go: things like script.php?filename=../../../../../../../etc/passwd shouldn't even have a chance of writing to /etc/passwd (also the script shouldn't have FS permissions for that).
Other than that, fwrite() doesn't have any special chars that would allow it to jump into some sort of command mode.
Also, the 404 page is pretty simple (in httpd.conf):
ErrorDocument 404 /error_page.php
and just dump the REQUEST_URL to a file
fwrite should be pretty safe.
Alternatively you can use some access log analyzer which usually lists not found pages.
If all it is doing is writing to disc, the only thing someone from the outside is to get it to write to disc. Obviously, the file name should not be a parameter that gets passed with the invalid url. Some one could try to exploit it by just sending tons of invalid pages requests with really long urls. But they would have to know you were doing this and care enough when there are other ways that would be more effective that are just general attacks.
There is a potential issue to look out for is if you are writing logs as HTML (or other file type that happens to allow code to be embedded). These file are of course vulnerable to XSS attacks.
A common logfile attack is to request URLs containing embedded malicious javascript. These URLs are written directly to a log file which will then execute when anyone views the file in a web browser.
Ensure the file you write cannot be served as HTML by the web server
Consider URL-encoding or HTML-encoding the URLs.
You should already be recording the 404 errors in your error_log.
By all means use a custom error handler to give the user a friendlier error message, but if this site sees any sort of serious throughput, then using fwrite from the script is not a good idea. PHP does not intrinsically have the sort of sophisticated file locking semantics to support concurrent file access - but since the webserver is recording the information for you, why bother?