On the IBM Security Intelligence site there's a new article posted talking about webshells. For those not familiar with webshells, they're scripts that can be used to control servers or work as a platform to access other systems put in place by attackers. In this article they introduce some of the basics around webshells and the rise they're seeing in their use.

The IBM X-Force Research team reported an increase in PHP C99 webshell attacks in April 2016. More recently, webshells dubbed b374k made their mark with attacks that the team has been tracking over the past few months.

Although this blog highlights some features of the b374k shell, the main objective is to call your attention to the fact that PHP applications are becoming an increasingly popular choice for attackers aiming to glean your data and deface your website without much hard work. This threat should be pushed to the top of your priority list — primarily because of the power of the tool used for this type of attack, but also because of the startling increase in this attack type this year.

They start off with some of the basics of webshells, more related to the PHP versions: what they are, what kind of functionality they commonly provide and an example of the UI of a shell. They then talk about some of the common delivery methods, potential entry points of these attacks and some of the "indicators of compromise" you can use to detect them. They also include mitigations you can perform to rid yourself of these webshells including adding additional plugins/software and locking down features of PHP itself.

The Paragon Initiative has a post showing you how to prevent timing attacks when comparing strings using a double HMAC method. Essentially this method replaces timing safe comparison methods (non-native) using a constant key in the HMAC generation.

One of the common cryptographic side-channels that developers should be aware of is how long a specific operation, such as a string comparison, takes to complete. Thus, they are called timing attacks. [...] Timing attacks are possible because string comparison (usually implemented internally via memcmp()) is optimized. [...] These concerns have led many security to propose a Double HMAC strategy instead of writing a constant time comparison loop where one is not already provided (e.g. PHP before 5.6.0).

He points out that while the has_equals approach can be effective in preventing this kind of issue, if you're not running PHP 5.6 you're a bit out of luck. There are polyfill functions that mimic it but he suggests another option - the double HMAC. He includes an example of the code to perform this kind of evaluation, using the same constant key value in the HMAC generation for both input strings. He then refactors this and shows how to use a more randomized key making use of the native CSPRNG functions coming in PHP 7 (ployfill available for this too).

Pádraic Brady has a new post to his site talking about the recently announced (but actually relatively old) issue with PHP hash comparison, the "magic hash" issues.

A while back, I noticed a flurry of activity around a somewhat obvious outcome of PHP’s type juggling antics. As the snowball gathered pace and grew, it’s being more widely reported as a vulnerability dubbed “Magic Hashes”. What is this mysterious potential vulnerability in PHP applications? The vulnerability is a straightforward outcome of PHP’s type juggling antics.

He talks about the == (double equals) versus === (triple equals), how they differ and how the use of the triple equals basically negates this issue. The problem comes back around to PHP's type juggling and how it assumes equality based on the data given. He includes some specific examples showing places the issue can happen even when comparing two variables of the same type. He also makes a mention of another issue that can come in separate from this called timing attacks and how to prevent them as well.

In his latest post Anthony Ferrara talks about a tricky subject in PHP - timing attacks. A timing attack has to do with vulnerabilities that can come up because of the differences in time it takes to perform cryptographic operations (like hashing or encrypting).

An interesting pull request has been opened against PHP to make bin2hex() constant time. This has lead to some interesting discussion on the mailing list (which even got me to reply :-X). There has been pretty good coverage over remote timing attacks in PHP, but they talk about string comparison. I'd like to talk about other types of timing attacks.

He starts with a definition of what a remote timing attack is and provides an example of a simple script showing the delay that's key to the attack. His script deals with string location but it gives you an idea of how the attack works and where the danger lies. He points out that even remotely attackers could determine the times to perform operations (down to the nanosecond) and use this to their advantage. He points out that both == and === are vulnerable to this type of attack because of how the comparison happens. He gives two options (one an internal function) to help protect your application and briefly covers a few other types of timing attacks: index lookup, cache-timing and branch-based timing attacks.

In her latest post Anna Filina has made some recommendations of countermeasures you can use to help prevent abuse against brute force attacks in your applications. The recommendations aren't PHP-specific, but they're a good guide and a place to start.

Password brute-forcing refers to trying all password permutations until the attacker finds the right one. Here are some of the most common ways to mitigate that risk: increase the length of the password and increase the number of possible characters. [...] The human factor should not be ignored here. People often use letters in the beginning and numbers at the end.

She recommends a few other tactics to helping prevent the brute forcing including locking an account after a number of unsuccessful login attempts and requiring a CAPTCHA after a number of unsuccessful logins. She recommends not relying on a single method to help prevent this kind of attack, however. Multiple layers can only help, but be careful not to introduce too much complexity.

The PHPClasses.org blog has a new post highlighting a vulnerability in the OAuth 2.0 specification that's been talked about quite a bit lately, the Covert Redirect Vulnerability. This issue allows potential attackers to trick users into redirecting to malicious sites and possibly gain access to personal information.

This vulnerability affects applications that implement protocols like OAuth 2.0 and OpenID. Lets see how this affects an OAuth 2.0 application. [...] The way it works is that your application redirects to a specific page of the Facebook site. There the user is asked if he wants to give your application permission to access Facebook API on his behalf. After the user agrees, his browser is redirected back to your site to a URL that your application specified called redirect_uri. From then on your site completes the process to get a special access token string that will be used by your site to access Facebook API on behalf of the user.

This token represents the user and can then be used to access the user's account. If that token fell into the wrong hands, they could access data they shouldn't. He includes a diagram of the flow and a link to a video explaining the problem in a bit more depth. He recommends three ways to help prevent this issue and what to look for in your implementation that could leave you vulnerable.

In this recent post to Reddit.com, a point is brought up about the popular PHP package manager, Composer about it being susceptible to a common attack called the "Man in the Middle". This issue on the project's Github repository talks more about it:

Composer runs code from HTTP sources without validating the source of the download or the code downloaded. As such, trivial man-in-the-middle attacks through any number of vectors (dns, networking, local server exploit, etc) will result in execution of code of an attackers choosing at the userlevel of the user running composer. (Typically a developer account)

Replace getcomposer.org for a given network perspective by replacing it with a malicious http instance (eg by changing the DNS locally, at the lan, at an isp or hosting provider dns resolver, or globally or equally easily by replacing a route to the legitimate server (eg arpspoof)) . The http server instance is configured to serve a malicious /composer.phar and a /version url that produces random data. When users run self-update, the malicious code will be downloaded and run as the user that is executing the self-update command.

As of yet some patches and ideas have been proposed to correct this issue, but it hasn't been resolved and is currently listed as a "blocker" on the project. One suggestion, signing packages, seems to be the front-runner in the current discussion, something that package managers for other languages have already implemented (like npm for Node.js and pip for Python).

Anthony Ferrara has written up a new post to his site looking at efective use of CSRF tokens and a few different strategies for generating them.

There's been a bit of noise in the past week about the proper way to prevent Cross-Site-Request-Forgery (CSRF) attacks. It seemed to have started with this post. There's been discussion in the comments, and on Twitter about it, and there seems to be several opposing viewpoints on the matter. I want to start off by saying that I agree completely with the post in question. But I figured I'd write a post to explain WHY I agree with it.

He starts with an overview of a few of the common types of request forgery including from a javascript injection, a Man-in-the-Middle attack and a replay attack. He then breaks up the "lines of defense" part of the post into three different sections - adding a hidden token field to forms, changing the token for each request and using random numbers when regenrating them.

According to this new post on DevShed, there have been several targeted attacks against U.S. bank websites (DDoS), some of which involved the compromise of PHP-based applications.

Once the hackers got into the PHP-based websites, they inserted toolkits to turn them into launch pads for their distributed denial-of-service attacks. Hackers then launched the attacks on banks by connecting directly to the compromised PHP-based websites and sending them commands, or took advantage of intermediate servers, proxies or scripts to make the websites do their bidding. InformationWeek lists three attack tools used by the hackers: KamiKaze, AMOS, and the “itsokaynoproblembro” toolkit, also known as Brobot.

Several major banks have been targeted including Bank of America, JP Morgan/Chase, HSBC and Well Fargo. The main problem was out-of-date software running on the site containing known security issues the attackers could exploit to install their own software.

If a hacker can break into a PHP-based website to use it as a staging area for an attack on a different website, they can also use that website to store stolen information. InformationWeek cited the example of the Eurograbber attack campaign, revealed earlier this month. The gang involved in that campaign stole $47 million from more than 30,000 corporate and private banking customers – and used PHP-based websites into which they hacked to store stolen information.

Anson Cheung has posted about some security attacks (six of them) that you need to watch out for when developing your apps.

Be aware of the most common security threats to PHP applications is the important step to secure your PHP scripts may not be immune. Here, the article is going to go over top 6 common security threads in PHP scripts. You may familiar with this, if not, this is a good time for you to read and keep in mind.

The top six on his list are:

• SQL Injection
• Cross-Site Scripting (XSS)
• Session fixation
• Session capturing/hijacking
• Cross-Site Request Forgeries (CSRF)
• Code Injection

For each item, he includes a bit of explanation as to what the issue is and a common solution as to how to prevent it.