Label: security
Tuesday 17th December 2013 PHP.net Breached With Potentially Unique Malware
In what is no doubt an embarrassing security breach, PHP.net, the official website of the PHP programming language, was compromised temporarily by hackers. Having a server compromised is not a particularly rare occurrence in the modern digital era, although as the flagship site of the PHP language, it must be particularly galling - as well as being a potent cautionary tale for PHP programmers everywhere. After all, if it can happen there, it can happen anywhere.
The attack, which compromised the site for nearly 3 days in October, was intended to force users who visited the site to download and execute some malicious code - also not particularly uncommon in this day and age. More recently, however, security researchers were analyzing the payload that was downloaded to user's machines, and found it to be a highly specific and potentially unique piece of malware dubbed DGA.Changer, which employs sophisticated techniques to evade detection and maintain links with command and control systems, for the purpose of downloading other pieces of malware to the infected machines which would otherwise be caught and removed.
Here's where things get curious, though: the machines infected by DGA.Changer from the PHP.net attack don't seem to be downloading other pieces of malware. There have been no reported cases of additional malware downloads in the wild, and security researches are concerned that something more complex is at work - the digital equivalent of the 'long con', perhaps. Aviv Raff, CTO and security researcher at Seculert writes, "Our analysis at this point is that 'no news is bad news.' Why would adversaries deploy a malware which downloads nothing, on a site used by software developers, and then engineer it so that it can receive commands from a C2 server to change the DGA seed? It makes no sense—and that [is] worrisome. Not all adversaries are geniuses, but they typically have an agenda."
The current running theory is that PHP.net was targeted because it has a very high probability of being visited by PHP programmers who are working on high-value projects that may not even be released yet, giving whoever holds the keys to DGA.Changer a very valuable pool of potential targets. While there seems to be no activity or damage caused as a result of the attack, the possibility that someone is specifically targeting PHP programmers rather than average users is a disturbing trend that should have every developer concerned - and ensuring their antivirus definitions are up-to-date and working properly.
Posted on December 17th 2013 at 09:46pm
0 Comments
Wednesday 04th December 2013 The Importance of Keeping PHP Up to Date
PHP is a robust and flexible language, used almost everywhere on the web in one form or another - and, increasingly, it's being used in many non-standard environments. As we grow into the so-called Internet of Things - the holy grail of web connectivity where every device we own is integrated into a network - the places PHP can be found are often extremely surprising to the unexpecting user. Never before has this been more highlighted than by a new piece of malware that was identified in the last two weeks by security firm Symantec.
Capitalising on a by-now ancient PHP bug, the malware is a worm known as Linux.Darlloz has currently only been infected Intel x86-based systems, but security researchers warn that there are variants of the worms code that are designed for chip architectures that are most commonly found in consumer-grade routers, IP security cameras, and even television set-top boxes, which are not typically devices that are targeted by malware attacks. While there have been no recorded incidents of any devices being infected 'in the wild', the possibility exists that the current operational structure will change.
This serves to highlight the importance of working with up to date versions of PHP, and ensuring that if you or your company are responsible for working with devices that contain web interfaces, as most devices in the Internet of Things do for control and configuration purposes, it's absolutely crucial to roll out properly timed security updates. The particular flaw exploited by the Linux.Darlloz worm is only found in PHP versions 5.4.1 and earlier ; the patch for the flaw was implemented as far back as May 3rd of 2012.
It doesn't take much time to ensure that your current development environments are running the latest version of PHP - a quick version check and an update to your binaries is all it takes. It's possible that you may have to make some updates to any projects that are currently in the works, and if you've got any deployed projects they should be updated to patch any security flaws, but the benefits of the added stability and security far outweigh the hassles involved in staying updated. Even if you're not ready to adopt the latest bleeding edge version, at least try to stay with a version that was released in the current year.
Posted on December 04th 2013 at 02:29am
0 Comments
Thursday 24th October 2013 Securing Your PHP Application with a Custom Configuration File
When it comes to securing your PHP application against hackers and other types of malicious use, there are a number of different things to consider. We touched on a few of them previously, including what's probably the most important one: filtering all user input. We can't stress enough the importance of correctly validating all user input, including any input that comes in the form of file uploads. However, one of the most useful tools to secure your PHP code against malicious users is built right into the way PHP operates: the php.ini file.
The php.ini file is a customisable configuration file that is called when PHP loads which specifies a number of key settings for how PHP operates and executes your code. Because of this, it's also a great place to handle a couple of security vulnerabilities that are almost as crucial as controlling user input.
The first of these is the issue of error reporting. Obviously, when you're working in a test development environment, it's incredibly valuable to have your error reporting visible to help you quickly source any bugs in your code - but once you move out of the testing phase into a production environment, the data offered by error reporting can provide valuable clues to a hacker about potential vulnerabilities in your code. While you can try to ensure that doesn't happen by writing flawless code, there are a number of global parameters you can set in your php.ini file that will ensure your production code is safe from this issue. The first parameter, error_reporting, does exactly what it says on the tin, namely enabling error reporting at all, and should be set to E_ALL. The follow-up to this is the parameter display_errors, which should be 'off' once you move out of the testing phase. However, as you will probably want to ensure that any errors that do occur are logged, enable log_errors and specify the path using error_log. That's all there is to it!
The other important security vulnerability to prepare for is the type of attack known as session fixation. Essentially, this type of exploit tricks your code into accepting a session ID that has been faked by the malicious user. This can occur in a few different ways, but the methods for overcoming it can all sit in the php.ini file. A few different parameters are very useful: both session.use_cookies and session.use_only_cookies should be set to 1, which prevents GET parameters from setting your session ID. Session.use_trans_sid should be set to 0 to prevent session IDs from persisting, and as a final measure you should modify the name of the session parameter - session.name - away from the default "PHPSESSID" to something random.
These tips won't guarantee the perfect security of your code, but they can go a long way towards preventing the casually snooping hacker from easily breaking into your application and causing untold damages. Take the time to write technically exacting code, and you'll be rewarded by an app that flows smoothly and robustly!
Tuesday 08th October 2013 Important Practices for Securing Your PHP Apps
For high-profile, mission-critical PHP applications, security is a paramount concern. Bad security solutions can compromise important servers and lead to the kind of privacy breaches that make news headlines. But for those of us writing more every-day PHP apps, security is still an important concern - especially for anyone who's new to the language. We'll take you through some basic considerations for securing your PHP applications, letting you rest a little bit easier once you finally put your app out into the wild.
One of the most important concerns for any app that accepts user input is validating said input, to ensure that it doesn't throw your app a curveball it can't handle - or worse. Frustratingly, the basic assumption should be that user input can't be trusted, as anything more lenient can leave gaping holes in your security. Many coders use Javascript to validate user input, but this is inherently flawed as users have the ability to disable Javascript, so ensure you validate in PHP.
When your code runs on a page that accepts and then displays user input, such as a comment thread system, bulletin board or similar, it's important to make sure that your application has screened out any possible malicious Javascript code or HTML tags present in the user input. Fortunately, PHP has two built-in functions that make this simple: strip_tags() and htmlentities(). These two can save you a great deal of hassle, so get in the habit of using them!
Everything, naturally, comes back to the user, but sometimes vulnerabilities can be unintentionally exposed by a user and shared with a malicious one - which makes proper error handling critical for the integrity of your security. Many developers hate dealing with this particular aspect of development when trying to get their code out the door in a hurry, but it's far better to invest the time now than to try explaining why you cut corners.
Finally, another important concern is the way your include files are handled. PHP code routinely references other PHP files, often for database access or regularly repeated code segments, which can be inadvertently displayed to the user as plaintext if not properly named. Any extension other than .php may not be parsed properly by a browser, leaving your code vulnerable, so always use the correct extension. To be doubly-safe, store your includes in a folder that doesn't have user access permissions.
This is only the tip of the iceberg when it comes to PHP security, but you can save yourself from a good many problems by following these simple practices.
