• Skip to primary navigation
  • Skip to content
  • Skip to primary sidebar
  • Skip to footer

Sucuri Blog

Website Security News

  • Products
    • Website Security Platform
    • Website Firewall (WAF)
    • Enterprise Website Security
    • Multisite Solutions
  • Features
    • Detection
    • Protection
    • Performance
    • Response
    • Backups
  • Partners
    • Agency Solutions
    • Partners
    • Referral Program
    • Ecommerce
  • Resources
    • Guides
    • Webinars
    • Infographics
    • SiteCheck
    • Reports
    • Email Courses
  • Immediate Help
  • Login

Analysis of the Fancybox-For-WordPress Vulnerability

February 16, 2015Marc-Alexandre Montpas

5
SHARES
FacebookTwitterSubscribe

We were alerted last week of a malware outbreak affecting WordPress sites using version 3.0.2 and lower of the fancybox-for-wordpress plugin. As announced, here are some of the details explaining how attackers could use this vulnerability to inject malicious iframes on websites using this plugin.

Technical details

This vulnerability exploited a somewhat well-known attack vector amongst WordPress plugins: unprotected “admin_init” hooks.

Sucuri - Fancybox-for-WordPress Code

As “admin_init” hooks can be called by anyone visiting either /wp-admin/admin-post.php or /wp-admin/admin-ajax.php, this snippet could be used by remote attackers to change the plugin’s “mfbfw” option with any desired content. This got us asking ourselves, what was this option used for?

Sucuri-Fancybox-WordPress-Code2

We found that this option was being used in many places within the plugins codebase. The one that caught our attention was inside the mfbfw_init() function. This basically displays jQuery scripts configured to work with parameters that were set up earlier, in mfbfw_admin_options().

Sucuri-Fancybox-WordPress-Code3

As you can see from the above picture, the $settings array is not sanitized before being output to the client, which means an attacker, using the unprotected “admin_init” hook, could inject malicious Javascript payloads into every page of a vulnerable website, such as the “203koko” iframe injection we presented last week.

 

5
SHARES
FacebookTwitterSubscribe

Categories: Vulnerability Disclosure, Website Malware Infections, WordPress SecurityTags: WordPress Plugins and Themes

About Marc-Alexandre Montpas

Marc-Alexandre Montpas is Sucuri’s Senior Security Analyst who joined the company in 2014. Marc’s main responsibilities include reversing security patches and scavenging vulnerabilities, old and new. His professional experience covers eight years of finding bugs in open-source software. When Marc isn’t breaking things, you might find him participating in a hacking CTF competition. Connect with him on Twitter.

Reader Interactions

Comments

  1. soulseekah

    February 16, 2015

    The `extraCalls` setting key was used in this particular case, its content was output directly after the jQuery call before the tag was closed. `extraCallsEnable` was also set to “on”. Although other setting keys could have been used to escape the initialization object, `extraCalls` was a much saner, more straightforward and cleaner approach.

  2. aileenf

    February 16, 2015

    Thanks for this, it really makes it clear to me how easily this kind of thing can happen.

    And it begs the question – how can I make sure my own use of the admin_init hook does not open up a website to such abuse? Is it enough to make sure all variables are sanitized before storing in the database and displaying to the user?

    • soulseekah

      February 16, 2015

      Authorize, authenticate, validate, sanitize.

  3. Robert Paprocki

    February 16, 2015

    The problem wasn’t soley that data wasn’t sanitized, but that the request authorization wasn’t validated before the data was written to the DB. Plugin and theme developers need to be aware of exactly how they’re exposing their settings to the outside world. The WP plugin API has some coding examples on checking access control in this situation: http://codex.wordpress.org/Plugin_API/Action_Reference/admin_init

  4. Twentyfortysix

    February 17, 2015

    thanks for the explanation

  5. Raptor

    March 9, 2015

    v3.0.6, the latest version at this moment I write this comment, is still affected by the exploit.

    • Fencer04

      March 9, 2015

      Were you affected and then updated the plugin or were you on the latest version before you got infected?

      • Minister

        December 8, 2015

        It seems fixed already, but you need to clean your DB as described in the FAQ section of the plugin’s URL.

    • schwinn

      March 25, 2015

      I can confirm that as well. The latest release is still infected.

  6. Raptor

    April 24, 2015

    I was in v3.0.2

Primary Sidebar

Socialize With Sucuri

We're actively engaged across multiple platforms. Follow us and let's connect!

  • Facebook
  • Twitter
  • LinkedIn
  • YouTube
  • Instagram
  • RSS Feed

WordPress Security Course

The Anatomy of Website Malware Webinar

How to Clean a Hacked Website Guide

WordPress Security Guide

How to know you can trust a plugin

Join Over 20,000 Subscribers!

Footer

Products

  • Website Firewall
  • Website AntiVirus
  • Website Backups
  • WordPress Security
  • Enterprise Services

Solutions

  • DDos Protection
  • Malware Detection
  • Malware Removal
  • Malware Prevention
  • Blacklist Removal

Support

  • Blog
  • Knowledge Base
  • SiteCheck
  • Research Labs
  • FAQ

Company

  • About
  • Media
  • Events
  • Employment
  • Contact
  • Testimonials
  • Facebook
  • Twitter
  • LinkedIn
  • Instagram

Customer Login

Sucuri Home

  • Terms of Use
  • Privacy Policy
  • Frequently Asked Questions

© 2021 Sucuri Inc. All rights reserved

Sucuri Cookie Policy
See our policy>>

Our website uses cookies, which help us to improve our site and enables us to deliver the best possible service and customer experience.