Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Exploitbox: WordPress Unauthorized Password Reset Vulnerability
May 05, 2017 @ 11:14:48

On the DotDev.co site Eric Barnes has written up a post talking about a recently announced vulnerability (and 0-day exploit) for WordPress allowing for password reset emails to be delivered to a user-specified address instead of the correct one on the account:

On the Exploitbox site Dawid Golunski shares a 0 day vulnerability in the WordPress core affecting all versions:

The vulnerability stems from WordPress using untrusted data by default when creating a password reset e-mail that is supposed to be delivered only to the e-mail associated with the owner’s account.

The post includes a snippet of code from the WordPress core where the issue lies, relying on the value from PHP's $_SERVER['SERVER_NAME'] variable for the domain in the address the reset email is sent to. Unfortunately this value is pulled from the Host header in the request and is user-controllable. There's a solution offered using an Apache setting and it's noted that this exploit only seems to work against the default VirtualHost as it will act as a fallback if the Host does not reference a configured domain.

tagged: exploit wordpress password reset vulnerability zeroday security

Link: https://dotdev.co/exploitbox-wordpress-unauthorized-password-reset-vulnerability/

Community News:
HTTPoxy Vulnerability Announcement
Jul 19, 2016 @ 12:40:10

Recently a major security vulnerability was announced centering around the the HTTP "Proxy" header and how incorrect handling could result in major issues with external requests. In the PHP ecosystem, a major HTTP library - Guzzle - was vulnerable (along with any application using it). However, according to Michael Dowling, a lead developer on the project, a new release has already been made to correct the problem.

httpoxy is a set of vulnerabilities that affect application code running in CGI, or CGI-like environments. It comes down to a simple namespace conflict [between the "Proxy" and "HTTP_Proxy" headers]. This leads to a remotely exploitable vulnerability. If you’re running PHP or CGI, you should block the Proxy header now. Here’s how.

The main HTTPoxy site as more information about how you can test to see if your application is vulnerable and what software/server configurations are typically vulnerable. There's also more language-specific information on the page as well as some immediate mitigations for various web server types.

tagged: httpoxy http proxy header vulnerability announcement guzzle webserver

Link: https://httpoxy.org/

Paragon Initiative:
Securely Implementing (De)Serialization in PHP
Apr 18, 2016 @ 11:58:22

The Paragon Initiative site has a new tutorial posted aiming to help you more securely use the serialize and unserialize handling in PHP to prevent security issues. In this tutorial they offer some advice - mainly don't unserialize unless you're on PHP7 - and some other solutions you could use.

A frequent problem that developers encounter when building web applications in PHP is, "How should I represent this data structure as a string?" Two common examples include:
  • Caching a complex data structure (to reduce database load)
  • Communicating API requests and responses between HTTP-aware applications
This seems like the sort of problem that you could expect would have pre-existing, straightforward solutions built into every major programming language that aren't accompanied by significant security risk. Sadly, this isn't the case.

He starts with a look at the serialization handling and how it could allow remote code execution if an attacker were to modify the serialized data. He includes an example of using the new "allowed classes" parameter in PHP 7 too, though, preventing the issue. He also walks through two other ways you could replace serialized data: JSON structure and XML handling. Each of these have their own issues too but they're very different than the code execution with serialization.

tagged: serialize unserialize security json xml tutorial example vulnerability

Link: https://paragonie.com/blog/2016/04/securely-implementing-de-serialization-in-php

Check Point Blog:
Finding Vulnerabilities in Core WordPress: A Bug Hunter’s Trilogy, Part I
Aug 06, 2015 @ 11:44:14

The Check Point blog has posted the first part of a series from one of their vulnerability researchers about finding security vulnerabilities in the core WordPress code (and some of the results along with CVE numbers).

In this series of blog posts, Check Point vulnerability researcher Netanel Rubin tells a story in three acts – describing his long path of discovered flaws and vulnerabilities in core WordPress, leading him from a read-only ‘Subscriber’ user, through creating, editing and deleting posts, and all the way to performing SQL injection and persistent XSS attacks on 20% of the popular web.

In this first part he focuses on the concept of "identity" in a WordPress application. He focused on the "roles and capabilities" functionality to find bypass methods in operations like editing and adding new posts. As he works through his process, code is included from the WordPress core showing where the issue(s) lie and what would be needed to exploit the issue.

tagged: bug hunt wordpress vulnerability core code part1 series checkpoint

Link: http://blog.checkpoint.com/2015/08/04/wordpress-vulnerabilities-1/

Paragon Initiative:
Everything [About] Preventing Cross-Site Scripting Vulnerabilities in PHP
Jun 17, 2015 @ 12:19:29

The Paragon Initiative has posted a new tutorial that wants to provide you with everything you need to know about preventing cross-site scripting in PHP applications.

Cross-Site Scripting (abbreviated as XSS) is a class of security vulnerability whereby an attacker manages to use a website to deliver a potentially malicious JavaScript payload to an end user. XSS vulnerabilities are very common in web applications. They're a special case of code injection attack; except where SQL injection, local/remote file inclusion, and OS command injection target the server, XSS exclusively targets the users of a website.

[...] Cross-Site Scripting represents an asymmetric in the security landscape. They're incredibly easy for attackers to exploit, but XSS mitigation can become a rabbit hole of complexity depending on your project's requirements.

He introduces the concept of cross-site scripting (XSS) for those new to the term and provides a brief "mitigation guide" for those wanting to jump to the end. He then gets into some examples of what a XSS vulnerability could look like, both stored and reflected and provides the "quick and dirty" method for preventing them. He also mentions some tips in implementing your solution including avoiding HTML in your data if at all possible. He goes on to talk about the use of HTMLPurifier to prevent attacks, context-sensitive escaping (HTML vs JS vs CSS) and some of the browser-level features that help prevent XSS for the user.

tagged: prevent xss crosssitescripting security prevent vulnerability context browser

Link: https://paragonie.com/blog/2015/06/preventing-xss-vulnerabilities-in-php-everything-you-need-know

Pádraic Brady:
PHP’s “Magic Hash” Vulnerability (Or Beware Of Type Juggling)
May 14, 2015 @ 12:19:43

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.

tagged: magichash vulnerability typejuggling timing attack doubleequals tripleequals

Link: http://blog.astrumfutura.com/2015/05/phps-magic-hash-vulnerability-or-beware-of-type-juggling/

Anthony Ferrara:
PHP Install Statistics
Dec 31, 2014 @ 09:29:43

Anthony Ferrara has a new post to his site sharing the results of some PHP version statistics he's gathered and how it relates back to the security of applications.

After yesterday's post, I decided to do some math to see how many PHP installs had at least 1 known security vulnerability. So I went to grab statistics from W3Techs, and correlated that with known Linux Distribution supported numbers. I then whipped up a spreadsheet and got some interesting numbers out of it. So interesting, that I need to share...

He starts with the versions that currently have no known security issues and matches those up with the linux releases that currently include them. He then looks at the adoption rates for more recent versions and maps those against the security status as well...with some "grim results". He summarizes the totals of all of the version results and comes up with an interesting statistic: over 78 percent of PHP installations (and thus applications) are vulnerable to some kind of security vulnerabilities just because of what they're hosted on.

tagged: install statistics security vulnerability issue percent

Link: http://blog.ircmaxell.com/2014/12/php-install-statistics.html

Anthony Ferrara:
A Lesson In Security
Nov 03, 2014 @ 09:11:49

In his most recent post Anthony Ferrara gives a lesson in security prompted by the recent major issue with a SQL injection vulnerability in Drupal. He gets into detail about the vulnerability itself and the ultimate question: "how could this happen?"

Recently, a severe SQL Injection vulnerability was found in Drupal 7. It was fixed immediately (and correctly), but there was a problem. Attackers made automated scripts to attack unpatched sites. Within hours of the release of the vulnerability fix, sites were being compromised. And when I say compromised, I'm talking remote code execution, backdoors, the lot. Why? Like any attack, it's a chain of issues, that independently aren't as bad, but add up to bad news. Let's talk about them: What went wrong? What went right? And what could have happened better? There's a lesson that every developer needs to learn in here.

He details (complete with code examples) where the vulnerability was, how it could be exploited and what the resulting SQL would look like when it was abused. Fortunately, the fix for the issue was relatively simple, but fixing is easy - distributing that fix is much more difficult.

How did this happen? Everyone makes mistakes. Everyone. It's going to happen sooner or later. Heck, this vulnerable code was in the database layer since 2008, and was just discovered two weeks ago. That says something about how complex vulnerabilities can be.

He suggests that the bigger lesson here isn't about who made the mistake or even the code that caused it. It's more about how it was handled, and that, in using any kind of CMS/framework like this there's always risk. People are human, people make mistakes - "the key is how you deal with it".

tagged: security drupal vulnerability detail lesson risk handle

Link: http://blog.ircmaxell.com/2014/10/a-lesson-in-security.html

Evert Pot:
Composer's bug now fixed
Feb 24, 2014 @ 12:38:06

Evert Pot has posted an update to a previous post around Composer's vulnerability around installing the wrong packages in the case of a conflict. In this latest post he points out, however, that the bug is now fixed.

As an update to my previous post, the composer security problem now appears fixed. Good to see that a quick response was possible after all.

The original issue was caused by the "replace" functionality, allowing the possibility for an incorrect package to be installed instead of the one requested. Other posts with more details include this one from Pádraic Brady and Nils Adermann. if you're a Composer user, it's highly suggested you update your currently installed version (run a "composer self-update").

tagged: composer bug security vulnerability fix selfupdate

Link: http://evertpot.com/composer-bug-fixed

Pádraic Brady:
Composer: Downloading Random Code Is Not A Security Vulnerability?
Feb 21, 2014 @ 10:04:52

In his latest post Pádraic Bradyhas posted a response to a recent post stating that in issue in Composer where the wrong package could be installed is not a security issue. Pádraic disagrees, here's why:

The problem here is quite simple. A user defines a composer.json file that requires the package bloggs/framework. Someone else creates a package on Packagist.org called evil/framework whose own composer.json states that it replaces bloggs/framework. Next, a group of poor random victims, potentially thousands, use composer to install applications with a dependency on bloggs/framework. Composer does some internal wizardry and installs evil/framework when certain conditions are met. The victims didn’t request evil/framework but they get it anyway.

He suggests that this is a kind of remote file inclusion and possibly a remote code execution vulnerabilities. He points out that the manual steps suggested in the post aren't listed in the Composer documentation and fixes for it are still pending work.

Saying one thing, but acting like it’s the other thing you don’t want people to call it, makes me think it really is the other thing. Probably because it is. Users can fall victim to a replace and it’s called “unintuitive”, but if a package states that it replaces something that might lead to the unintuitive behaviour, it’s an abuse.
tagged: composer random code vulnerability security package

Link: http://blog.astrumfutura.com/2014/02/composer-downloading-random-code-is-not-a-security-vulnerability/