I am looking for some advice - I hope someone can help
My php site got hacked and I just found this code 'Script Encoded by Devil-Shell':
eval(gzinflate(base64_decode($encoded)))
And all these random letters/numbers...
I have a few questions:
What will happen if I delete this code? Will it have a knock on effect?
Is my site ruined?
Is there anything that can be done?
Thanks for your help.
It pretty much looks like a backdoor - I'd suggest to comment this out.
As long as $encoded is a variable that can be set externally (through HTTP GET or POST for example), anyone can execute any code on your server.
Unzip it to see what it does. Ensure it cannot be executed. Understand the damage it has done
Find your flaw in security
If that is PHP code, that is pretty serious, as they were able to append to a PHP file or to add their PHP malicious file. They basically own the server. Apart from general advices (fix your security, that can be a year of work :)) some real-life tips:
Don't erase logs, application logs or web server or db logs; keep them, it is very unlikely someone injected anything bad (apart from strings) there. Collect and keep all the logs, trust me they will be useful in the future if something bad happens.
They could have compromised the whole server with an attack like that. You need to be careful with your hosting company: they could consider you responsible for data breaches in other people's data, config, etc... It depends on their configuration and the agreement you signed with them.
Do not consider anything safe: the DB could be compromised as well, all keys and passwords and passphrases and sessionIDs you have stored since now are insecure and are in the hands of them now. So replace them ALL, as their aim could be not you but your user, and they are totally in control of their browsers too now (if they want).
You can comment that out, it seems safe enough; but they will add it again, in more subtle forms. Consider that.
Check (if you can) the traffic FROM your website. Usually they build simple webshells like that to be part of a bigger botnet. Usually they are used for Distribuited Denial of Service (DDOS), bitcoin mining or traffic exchange. So you could be considered legally responsible for such attacks/illegal behaviours as they are connected to your account and it is yours the contract for hosting.
In the internet this topic is called 'Intrustion Response' or 'Attack Response'. It is usually tailored only for big enterprises so I doubt you can find anything useful, but at least for theoretical topics it may help to google for it http://www.certiguide.com/secplus/cg_sp_SixStepIncidentResponseProcess.htm
Related
As most programmers I try to program my applications in the safest way possible but this we know that does not guarantee security at 100%. Therefore I think it is also appropriate to have methods to monitor if we may be being attacked. So this is my question.
(My websites are made with PHP and MySQL)
In the case of SQL injection I think this can be done in two ways, but if there are other ways I would also like to know them.
Parsing access/error logs. Does anyone have or know a script that adequately analyzes the access logs (apache) to detect possible attacks? And notify to the administrator automatically with all details.
Analyze HTTP params at real time. It would be a script that analyzes in real time the content passed by GET / POSt and notify (e.g. via email) to the administrator of the website
For example, I do not know much about SQLi attacks but I think it's common for the 'SELECT', 'UINON',...(Others?) strings to appear in query strings and params.
In this way we can analyze the attack and see if it succeeds or not, and then take the consequent actions.
Thanks for your attention!
Edited: Simple bash script
I have made a simple system for analyzing the Apache access_log files and communicate results by email. Which is detailed in this question:
Linux bash to iterate over apache access_log files and send mail
In addition, another one using AWK. The only one resource I've found related about that:
https://www.unix.com/shell-programming-and-scripting/248420-sql-injection-detection.html
(But I have not been able to make it runs in my case)
Oh boy.
Alright, where to start?
For starters, remember that bad hackers are usually financially motivated. You know your website has been injected if you wake up one morning to a red error message from Chrome or Firefox, and you open it anyway to find that your website is now among the more popular places to find free cruises and viagra online.
Sites that score well with SEO are more likely to be hacked than sites that do not. More users means more exposure. Password protected sites don't get hacked as often, but the password protection itself does not necessarily mean any added security. If you're vulnerable, you're vulnerable, and you need to be on top of it.
First and foremost, remember to filter your variables. Never trust anything that comes in from a browser. IT'S ALL SUSPECT. That's means filtering anything that counts as a super global, GET POST, REQUEST, etc. I wouldn't even trust sessions, honestly. Filter it all. More on this can be found here: http://php.net/manual/en/function.filter-var.php
Something else to think about is file uploading. Bad guys love uploading files, and taking over your server. Most common method is exploit files disguised as images. You're going to want to resample every image that comes in. GD Works, but I like Imagick better, personally, more options. More on that here: http://php.net/manual/en/book.imagick.php You're also going to want to make sure that your site can't upload images or any other type of file from pages that you don't explicitly designate as form or upload pages. You would be shocked how often I see sites that can upload from the index, it's insane.
Another method you can deploy for this, is use your php ini to set a global include, and open up any file in a $_FILES array that comes in. Open up the first million spaces in the file, and scan it for php reserved words, and unix shell scripting. If you find one, kill the upload, exit or die, whatever you like to do there.
Apache has a setting for forensic logs. Forensic logs will capture all GET and POST stuff, but the issue with it, and the reason it's not exposed by default is that your log get big, and quickly. You can read up on it here: https://httpd.apache.org/docs/2.4/mod/mod_log_forensic.html
Lastly, you're going to want to evaluate your site for injection vulnerabilities and cross site scripting. Cross site scripting isn't the issue it once was, given the way browsers are constructed these days. All those little details that make life harder for us as a developers actually make us more secure.
But you do want to check for SQL vulnerabilities, especially if you're writing code from scratch. There are a couple reasonably solid plugins for Chrome that make pen testing a little easier.
Hackbar: https://chrome.google.com/webstore/detail/hackbar/ejljggkpbkchhfcplgpaegmbfhenekdc?utm_source=chrome-ntp-icon
HackTab:
https://chrome.google.com/webstore/detail/hack-tab-web-security-tes/nipgnhajbnocidffkedmkbclbihbalag?utm_source=chrome-ntp-icon
For Firefox, there's scrippy
https://addons.mozilla.org/en-US/firefox/addon/scrippy/?src=search
Hope that helps.
Good luck.
Therefore I think it is also appropriate to have methods to monitor if we may be being attacked.
The biggest waste of time ever.
ANY site gets "attacked" 100% of time. There are freely avalable scripts that allow any stupid schoolboy to scan whole internet, probing sites just by chance. You'll grow bored the very next day after scouring these logs of your detection system.
In your place I would invest in the protection. Other vectors than you could think of. For examle, all recent breakings I was a vitness of were performed by means of stealing ftp passwords stored on the webmaster's PC. And I can assure you that there are much more attack vectors than a blunt SQL injection. Which is a simplest thing to protect from, with only two simple rules to follow:
Any variable data literal (i.e. a string or a number) should be substituted with a parameter, whereas actual value should be sent to the query separately, through bind/execute process.
All other query parts that happen to be added through a variable, should be explicitly filtered through a hardcoded list of allowed values.
I have a script, and I sell it to some people. I need a way to make sure that my script won't work on any website that not in my clients list.
First of all, I am using IonCube to encrypt my PHP code.
I have all my clients in my server database.
Each Client has a domain name, email, name, phone.
What is the best method to avoid making people from stealing my script?
I read about making a license key in the script, so any script without license won't work. However, there are many ways to generate a license key without taking my permission right?
All I need is to not activate any script in any domain name, unless I have it in my clients list.
Your question is very interesting because way too many php developers wonder the same thing. How can I protect my product from being stolen and copied?
Some of the comment talk about not being greedy, but the truth is that many people program for a living, so it isn't a matter of just some software you built as a hobby, it is your work and you deserve to get paid for it, just like any other profession.
Sadly, PHP is a language that is very hard to protect, but I will give you a few pointers:
1) Don't trust encryption: I have seen way too many tools for un-encrypting code, even some tools that I used to trust like Zend Guard, are also vulnerable. The most advanced tools I have seen can reveal your code in minutes.
EDIT: Another thing I forgot to mention about encryption. It will require the server to have certain special modules installed in order for your code to work and this is a deal-breaker for all the people who use shared hosting and can't install the unencryption module.
2) Try obfuscation: Even though your code will be still readable, if the obfuscator does a good job at mixing variables, adding nonsense and making functions within functions, the code itself will become almost non-modificable, so it will be useless to try to modify it.
3) Take advantage of obfuscation to insert domain-lock code within your software itself: Instead of a license file, just sell the software to a certain customer with some domain verification code within the software itself, that approach combined with obfuscation, will make it very hard to figure out what to change to make it work in some other domain, so you will probably achieve your goal.
4) Make a great software: This is the most important part, build an outstanding software that people will be willing to pay for, create a proper website for it, get the word out there.
I hope I have helped you.
There's a reason Adobe, Microsoft, and others don't over actively pursue pirates (not saying they don't, just not at epic, absolutism levels) - they make most of their money from business to business sales and support. A simple license and support structure is typically enough to posture yourself for profit from legitimate businesses and parties who want your product.
Technical protection is a losing battle if you're going to give anyone the code. That's why SaaS is so popular.
The only true way to lock down script-based code that you give away, is to keep a core part of that code executing on a server you control -- and have the code you've given to your client 'call home' to your server on each execution. Then all you have to do is block access to this 'call home' script based on the requesting ip.
Also, in this 'call home' mechanism it is no good just performing a simple connection test or handshake because this can be worked around -- the script on your server has to do something integral to the system as a whole so that the client would have to rewrite that missing part in order to use your code elsewhere without you knowing. This could be some key calculation or data provision.
Obviously this is not ideal as many clients will not like a script calling a remote server, plus you'd have to make sure your network and server could handle the number of requests -- otherwise you'll slow or timeout your clients own systems.
All I need is to not activate any script in any domain name, unless I have it in my clients list.
Ok you narrowed it enough.
create your openssl certificate, hardcode public part to checking code, when issuing license sign domain.name string with your private key, issue sign part as license, in your license:
$lic=<<<EOL
LICENSE CODE HERE - SIGNATURE of string contained domain name
EOL;
in your code to check license:
include 'license.php';
$cert=<<<EOK
PUBLIC KEY DATA HERE
EOK;
$pub_key=openssl_get_publickey($cert);
$ok = openssl_verify($_SERVER['SERVER_NAME'], $lic, $pub_key);
if ($ok !== 1) {die ('bad license!')}
O'c all should be encrypted as much as possible.
this probably vulnerable for special crafted libopenssl binaries but I hope it will help you.
to avoid running of such code every you can add condition like this:
if (int(random()*100))==6) {check_license();}
but it depends on which part is should be protected.
also, in all parts of the code you should check md5summ of file that contain license check code.
You can use http://www.ioncube.com to obfuscate your source code or http://www.phplicengine.com to license your php code remotely or locally.
My thoughts are that you can't successfully save code from to be nulled. I really don't like way the Non-Free apps are created, but I won't judge you. Best solution to protect code is sometimes not worth of it, because many people (read websites) have very restricted hosting, where they cant install ioncube... Best protection is to join many types of protections (ex. IonCube + injected licence connection to your data server in different places with different code+if site NEED to use some ssl, you can try to make some protection with to sell also ssl with public key check on your data server), or many, many, other ways, just be creative)
But however as I said, If you want very high protection, you will get loss of money for creating it, and loss of money of loosing your customers, because they use some cheap hosting...
You need to think about everything...
Forgot to say: Hosting on your server is best protection, but have disadvantages: you need to add possibility for 'templating' site, access to be created some plugins, and similar stuff... But sometimes Clients just don't like to keep all data on your hosted server.
I think I helped somehow...
There are some good comments from other posters to this. Depending on the edition of the ionCube Encoder that you're using the features that you need are there already (in Pro and Cerberus), including features to allow you to craft your own layers of licensing if you wish, though this shouldn't be necessary. Some basic steps give the biggest wins, and as others have said, it's not generally worth going over the top with a massive licensing infrastructure. Keep in mind too that a main benefit to licensing comes not so much from stopping those who are intent on cheating and not paying, but from keeping the paying customers in line.
Say that you have a fee for each domain where your software is used. If you mention this somewhere but do nothing to enforce it, then when an honest customers tries your scripts on a second domain and finds that it works, chances are that they'll simply use it without even realising that they should have paid. In contrast, if your software alerts them to the fact that a new license is needed, it's likely that they'll purchase for the second domain.
Realistically it's impossible to stop the most determined thieves, and as one poster eluded to it may even be beneficial in the long term to have cheaters using software for free rather than not at all, but licensing can definitely lock in revenue from the honest majority who are happy to purchase good software (plus support, bug fixes, upgrades etc.), and it's foolish not to do that.
PHP - Apache with Codeigniter
JS - typical with jQuery and in house lib
The Problem: Determining (without forcing a download) a user's PC ability &/or virus issue
The Why: We put out a software that is mostly used in clinics, but can be used from home, however, we need to know, before they go to our mainsite, if their pc can handle the enormities of our web-based, browser-served software.
Progress: So far, we've come up with a decent way to test dl speed, but that's about it.
What we've done: In php we create about a 2.5Gb array of data to send to the user in a view, from there the view calculates the time it took to get the data and then subtracts the php benchmark from this time in order to get a point of reference of upload/download time. This is not enough.
Some of our (local) users have been found to have "crappy" pc's or are virus infected and this can lead to 2 problems. (1)They crash in the middle of preforming task in our program, or (2) their virus' could be trying to inject into our js thus creating a bad experience that may make us look bad to the average (uneducated on how this stuff works) user, thus hurting "our" integrity.
I've done some googling around, but most plug-ins or advice forums/blogs i've found simply give ways to benchmark the speed of your JS and that is simply not enough. I need a simple bit of code (no visual interface included, another problem i found with one nice piece of js lib that did this, but would take days to remove all of the authors personal visual code) that will allow me to test the following 3 things:
The user's data transfer rate (i think we have this covered, but if better method presented i won't rule it out)
The user's processing speed, how fast is the computer in general
possible test for infection via malware, adware, whatever maybe harmful to the user's experience
What we are not looking to do: repair their pc! We don't care if they have problems, we just don't want to lead them into our site if they have too many problems. If they can't do it from home, then they will be recommended to go to their nearest local office to use this software "in house" so to speak.
Further Explanation
We know your can't test the user-side stuff with PHP, we're not that stupid, PHP is mentioned because it can still be useful in either determining connection speed or in delivering a script that may do what we want. Also, this is not a software for just anyone on the net to go sign up and use, if you find it online, unless you are affiliated with a specific clinic and have a login name and what not, your not ment to use the sight, and if you get in otherwise, it's illegal. I can't really reveal a whole lot of information yet as the sight is not live yet. What I can say, is it mostly used by clinics/offices for customers to preform a certain task. If they don't have time/transport/or otherwise and need to do it from home, then the option is available. However, if their home PC is not "up to snuff" it will be nothing but a problem for them and make the 2 hours task they are meant to preform become a 4-6hour nightmare. Thus the reason, i'm at one of my fav quest sights asking if anyone may have had experience with this before and may know a good way to test the user's PC so they can have the best possible resolution, either do it from home (as their PC is suitable) or be told they need to go to their local office. Hopefully this clears things up enough we can refrain from the "sillier" answers. I need a REAL viable solution and/or suggestions, please.
PHP has (virtually) no access to information about the client's computer. Data transfer can just as easily be limited by network speed as computer speed. Though if you don't care which is the limiter, it might work.
JavaScript can reliably check how quickly a set of operations are run, and send them back to the server... but that's about it. It has no access to the file system, for security reasons.
EDIT: Okay, with that revision, I think I can offer a real suggestion - basically, compromise. You are not going to be able to gather enough information to absolutely guarantee one way or another that the user's computer and connection are adequate, but you can get a general idea.
As someone suggested, use a 10MB-20MB file and several smaller ones to test actual transfer rate; this will give you a reasonable estimate. Then, use JavaScript to test their system speed. But don't just stick with one test, because that can be heavily dependent on browser. Do the research on what tests will best give an accurate representation of capability across browsers; things like looping over arrays, manipulating (invisible) elements, and complex math. If there is a significant discrepancy between browsers, then use different thresholds; PHP does know what browser they're using, so you can give the system different "good enough" ratings depending on that. Limiting by version (like, completely rejecting IE6) may help in that.
Finally... inform the user. Gently. First let them know, "Hey, this is going to run a test to see if your network connection and computer are fast enough to use our system." And if it fails, tell them which part, and give them a warning. "Hey, this really isn't as fast as we recommend. You really ought to go down to the local clinic to perform this task; if you choose to proceed, it may take a lot longer than intended." Hopefully, at that point, the user will realize that any issues are on them, not on you.
What you've heard is correct, there's no way to effectively benchmark a machine based on Javascript - especially because the javascript engine mostly depends on the actual browser the user is using, amongst numerous other variables - no file system permissions etc. A computer is hardly going to let a browsers sub-process stress itself anyway, the browser would simply crash first. PHP is obviously out as it's server-side.
Sites like System Requirements Lab have the user download a java applet to run in it's own scope.
Possible reasons:
1) so the user can't figure out the code and "issue himself more licenses" or other stuff that is commercially sensitive to you
2) so the user can't "just make a tiny change" and break what he doesn't understand, then tell you he didn't change anything and expect you to fix it (sure, you can make him pay, but it's easier to avoid the hassle in the first place)
3) so the customer can't take some of your software and use it do develop new products
4) you are embarrassed to let your uncommented spaghetti code be seen ;-)
5) any more?
What do you generally do? And how do you do it?
If hosting the php code on your servers is not an option, the best thing is to simply deliver the source code with a restrictive license and accept the risks you outlined above. If the user "issues more licenses" and it violates your terms, you can pursue legal actions.
On the receiving end, I have purchased PHP software that was ofsucated/encoded with ionCube PHP Encoder (http://www.ioncube.com/). It required adding an additional server component and including effectively closed-source code no our servers, neither of which our IT team was happy about. But it prevented us from fiddling with the source as you are attempting.
I deliver it as is. End-users expect to be able to edit the code whether it's free or commercial. Most of them aren't pirates, so getting in their way will just hurt your business (less happy customers = less positive mentions and referrals). The pirates will steal your software whether you obfuscate/encode it or not, anyway.
If a client breaks my code and try to pin it on me I offer to restore the code to the last known working configuration. This usually ends the conversation because they know it was a modification they made.
Seems like an unnecessary precaution to me. Even if you obfuscate it it can still be redistributed. As a developer, piracy is a known risk and the best way to avoid it is to release software that is open source. :)
I would seriously think twice about doing business with a developer in the future if I purchased a script that was obfuscated (making it difficult for me to make changes). I mean.. what PHP script needs ZERO modification to get it to do exactly what you want it to?
Concerning point #2:
You can always generate a hash of your deliverables. Very simple method: generate an md5 hash using the source files as input. If you suspect tampering when receiving a support call, simply hash the deployed files to figure out if your client has tampered with the code and tries to get you to fix their mess.
This is non-intrusive (you just hash before you deliver, and keep the hashes in your files) and a quite safe way to check the contents of your files.
No one has addressed that delivering the licensing source allows customers to switch it off and have unlimited licences. That is my main concern
Maybe this isn't really feasible. But basically, I've been developing a snippet-sharing website and I would like it to have a 'live demo area'.
For example, you're browsing some snippets and click the Demo button. A new window pops up which executes the web code.
I understand there are a gazillion security risks involved in doing this - XSS, tags, nasty malware/drive by downloads, pr0n, etc. etc. etc.
The community would be able to flag submissions that are blatantly naughty but obviously some would go undetected (and, in many cases, someone would have to fall victim to discover whatever nasty thing was submitted).
So I need to know:
What should I do - security wise - to make sure that users can submit code, but that nothing malicious can be run - or executed offsite, etc?
For your information my site is powered by PHP using CodeIgniter.
Jack
As Frank pointed out, if you want to maintain a high level of security use a whitelist technique. This of course comes with a price (might be too restrictive, hard to implement).
The alternative route is to develop a blacklist technique. i.e. only allow code that hasn't triggered any bells. This is easier, because you have to specify less things, but it will not catch new exploits.
There is plenty information available on the web on both techniques.
Relying on CodeIgniters security functions (XSS filtering etc.) will not get you very far as most of the snippets will not be allowed through.
Whatever you do you have to remember this:
Do not think malicious code will aim to just harm your website's visitors. It may as well aim to compromise your server via your parser/code inspector. For example, lets say Alice uploads snippet foo. Alice intentionally crafts the snippet so that your parser will flag it as malicious due to an XSS exploit. Lets say your parser also updates a database with the malicious snippet for further investigation. Alice knows this. Along with the XSS exploit Alice has injected some SQL code in the snippet, so that when you INSERT the snippet to the database it will do all sorts of bad stuff.
If you are really paranoid, you could have an isolated server which its solely responsibility would be to inspect code snippets. So in the WCS only that low-risk server would be compromised, and you would have (hopefully) enough time to fix/audit the situation.
Hope this helps.
You cannot whitelist or blacklist PHP, it just doesn't work. If you write up a list of commands that I can use, or stop me from using malicious functions, what is to stop me from writing:
$a = 'mai';
{$a .'l'}('somebody#important.com', 'You suck', 'A dodgy message sent from your server');
You cannot whitelist or blacklist PHP.
For your information my site is powered by PHP using CodeIgniter
Sorry Jack, if you think that is in the least bit relevant you're a very long way from understanding any valid answer to the question - let alone being able to distinguish the invalid ones.
Any sandbox you create which will prevent someone from attacking your machine or your customers will be so restrictive that your clients will not be able to do much more than 'print'.
You'd need to run a CLI version of suhosin on a custom chroot jail - and maintianing seperate environments for every script would be totally impractical.
C.
Assuming you are only allowing javascript code, then you should do the following -
Purchase a throw-away domain name that is not identifiable with your domain
Serve the user-entered code in an iframe that is hosted from the throw-away domain
This is essentially what iGoogle does. It prevents XSS because you are using a different domain. The only loophole I am aware of is that evil code can change the location of the webpage.
If you intend to share snippets of server side code, then it is a different ballgame. For java/jsp snippets, you could use JVMs internal Security classes to run the code in a sandbox. You should find a lot of information on this if you google. I would like to think this is what google uses in App Engine (I am not sure though).
Anything other than Java, I am not sure how to protect. Dot Net perhaps has a similar concept, but I doubt you could sandbox PHP code snippets in a similar manner.