Online Services

eWorldLinx

Category: Security

  • PSA: Multiple Vulnerabilities Present In Firefox 61

    In an advisory published yesterday, Mozilla disclosed the presence of nine security flaws in Firefox 61 which have been patched in the latest release of the browser. Some of the bugs are severe, but at this time do not appear to be receiving attacks in the wild. To protect yourself as a Firefox user, ensure that you have updated Firefox to the latest version as soon as possible. To do this, click the ‘Firefox‘ menu and ‘About Firefox‘. The browser will check for an update automatically and will download the update if available. You will then be prompted to ‘Restart to update Firefox‘

    This post is Copyright 2018 Defiant, Inc. and was published on the wordfence.com official blog. Republication of this post without permission is prohibited. You can find this post at: https://www.wordfence.com/blog/2018/09/psa-multiple-vulnerabilities-present-in-firefox-61/

    In the remainder of this post, we will take a closer look at some of the notable bugs from yesterday’s update and the types of vulnerabilities they contain. To help secure the broader web community, we would like to encourage you to let your friends, family and colleagues know that they should update Firefox as soon as possible. Either share this post or drop them a helpful note.

    Though the amount of detail available on each bug varies, Mozilla’s advisories contain brief descriptions and impact scores of disclosed issues. Five of the nine vulnerabilities were assigned scores of Low and Moderate and the remaining four items have been determined to be of High or Critical impact.

    The Bugzilla entries for these higher-severity bugs are all private at the time of this writing, most likely to limit the spread of details on the exploitability of these flaws while the Firefox user base collectively updates their browsers.

    Use-After-Free Flaws

    Two bugs marked high-impact in Mozilla’s advisory, CVE-2018-12377 and CVE-2018-12378, pertain to use-after-free vulnerabilities. This type of bug exists when an application can be made to attempt to reference data stored in memory which has already been freed. In other words, in certain cases a program can be made to crash or behave abnormally if it attempts to recall information it’s already been told to forget. The “abnormal behavior” can depend on how exactly the issue was triggered in the first place, as well as what new data may have replaced whatever the application attempted to load.

    In the case of these two Firefox bugs, the advisory specifies the existence of a “potentially exploitable crash”, which is common for this sort of vulnerability. No mention was made of possible remote code execution, another possible consequence of use-after-free flaws, suggesting that particular vector is not present in these cases.

    Memory Safety Bugs

    The other two notable issues, CVE-2018-12375 and CVE-2018-12376 (marked High and Critical-impact, respectively), have been labeled memory safety bugs. Memory safety is a fairly wide umbrella term, potentially referring to classes of vulnerability like race conditions, buffer overflows, and more, so the scope of these vulnerabilities remains to be seen. However, Mozilla’s details in the advisory entries on both of these CVEs state “Some of these bugs showed evidence of memory corruption and we presume that with enough effort that some of these could be exploited to run arbitrary code.”

    Patching Against The Theoretical

    Mozilla’s statement, that they “presume” the reported memory safety bugs “could” be used to run code “with enough effort”, is an important one. Mind you, it’s not necessarily an uncommon mindset to have, but it’s worth bringing attention to it when it comes up. Patching a vulnerability that may not be feasibly exploited today is still critical in an age where technologies and techniques advance so rapidly.

    This concept is of historical note, specifically in the example of CVE-2016-5195, better known as Dirty COW. Dirty COW (short for Dirty Copy-On-Write), was a major vulnerability in the Linux kernel publicly disclosed in 2017. The flaw allowed attackers with low-privilege access (such as a PHP web shell or even an unrooted Android device) to temporarily overwrite protected system files allowing a privilege escalation, up to and including root access to the affected system.

    Dirty COW’s relevance in this case stems from the fact that the flaw was actually identified and patched eleven years prior, before being reverted due to compatibility issues. In a commit message from 2016, Linus Torvalds stated “…what used a purely theoretical race back then has become easier to trigger,” referring to the race condition flaw that allows Dirty COW to be exploited. Put simply, when it was discovered it would have been arbitrarily unfeasible to successfully perform the exploit on existing hardware. Thus, it was deemed low-severity enough to get buried for over a decade.

    Mozilla’s decision, and similar choices made by security-conscious developers every day, benefit the community by reinforcing the mindset that a theoretical vulnerability is a vulnerability nonetheless.

    What Now?

    Information overload aside, these aren’t issues worth worrying about for most Firefox users. As usual, performing the update (if yours hasn’t automatically patched by now) is all it takes to protect yourself from these issues. With that in mind, please take a moment to make sure your peers are aware of bugs like these. Poke your friends and coworkers and nag them to click that update button, or just share this post with them. Either way, you’ll be doing your part to make them more secure.

    The post PSA: Multiple Vulnerabilities Present In Firefox 61 appeared first on Wordfence.

  • Duplicator Update Patches Remote Code Execution Flaw

    A critical remote code execution (RCE) vulnerability has been patched in the latest release of Duplicator, a WordPress backup and migration plugin with millions of downloads. In their public disclosure of this flaw, Synacktiv detailed its scope and severity, and provided a viable proof of concept exploit for the security community. In this post we’ll take a look at the basics of the vulnerability, what was patched, and what you can do if you think your site’s at risk.

    This post is Copyright 2018 Defiant, Inc. and was published on the wordfence.com official blog. Republication of this post without permission is prohibited. You can find this post at: https://www.wordfence.com/blog/2018/09/duplicator-update-patches-remote-code-execution-flaw/

    The Vulnerability

    Notably, the vulnerable code in this case isn’t present within the Duplicator plugin directory itself. The flaw becomes exposed when using Duplicator to migrate or restore a backed-up copy of a WordPress site.

    Backing up a site generates two files which are both necessary to restore the site’s content: an archived .zip file, and the script which unpacks and configures it, installer.php. These files can be moved to a new server and placed in an appropriate directory, then the admin can visit installer.php in their browser to begin the process of restoring the site’s files and database.


    Duplicator’s installer.php interface

    Once the restore is completed, you’re prompted to log into the new site. On login, a success page is displayed:


    Duplicator migration success screen

    On this success page, there’s a Final Steps list which reminds users to remove the leftover files from their Duplicator migration. In fact, if they don’t remove these files, a nag message will be displayed in the site’s WordPress dashboard until either the files are removed or Duplicator is uninstalled.


    Persistent “nag” message displayed by Duplicator while installer files still exist

    These messages are persistent for a good reason: leaving installation scripts available in a web-accessible location can be really dangerous. There’s a history of this sort of thing being exploited in the wild, like the campaign targeting fresh WordPress installations.

    In the case of unpatched Duplicator backups, the installer.php script (and generated copies, like installer-backup.php which will be found in a site’s document root after unpacking) introduces an injection vulnerability by failing to sanitize database configuration data submitted by the user, writing the values directly to the newly generated wp-config.php file.


    Example of vulnerable code in installer using raw $_POST input

    The above chunk of code is assembling a set of regular expressions to identify database connection strings in the site’s previous wp-config.php file, then defining new values for these strings to be replaced with. These new values are the injectable point.

    Exploiting this flaw on a vulnerable site is simple. While there are some basic protections in the installer script that will prevent an admin from overwriting an existing wp-config.php file from the installer’s web interface, these can be bypassed by just supplying the POST parameter action_ajax=3, effectively telling the installer that those checks have already passed.

    As for crafting the payload string to be supplied, the payload will be inserted predictably into an existing define()call in the config file, like DB_HOST or DB_USER. As long as a single quote can be successfully passed, an attacker has the ability to add any desired code to the affected site’s wp-config.php file. From this point, backdoors can be established and various malicious activity can be performed.

    The Patch

    Two issues regarding installation security were addressed in the recent patch to Duplicator. Most relevant to the code injection flaw described above, installer.php scripts generated by patched versions of Duplicator now use addslashes() to sanitize the database connection strings input by users. Now, attackers are unable to inject PHP code into these values.

    Additionally, when creating Duplicator packages, a new optional setting has been added for users to password-protect their generated installer scripts. This affords users additional security during the install process, as malicious third parties will no longer have access to the script at all. However, this option is concealed by a collapsible menu at first when generating new packages, so users who aren’t aware it’s been added may miss it at first.


    Package creation form in the new Duplicator release, with password protection visible.

    Caveats

    Although these patches make needed steps towards securing the process of migrating a WordPress site with Duplicator, it can’t be understated that it’s still of critical importance that any installation files are completely removed once they’re no longer needed.

    Even though the user-supplied connection strings are now sanitized before being written to a site’s active wp-config.php file–preventing new code from being introduced and executed–the existing values are still getting replaced by this process. This means if a patched but unprotected installer.php file is found, an attacker has the ability to bring down a site just by supplying incorrect database credentials to the installer.


    Oops.

    What Do I Need To Do?

    At the time of this writing, we have identified a number of malicious actors probing sites for the existence of installer.php and installer-backup.php. If you’ve used Duplicator in the past to migrate a WordPress site, take some time to confirm that any leftover files from the process have been properly removed. Wordfence Premium users will begin receiving alerts from their malware scanner if vulnerable versions of these files are detected on new scans. Additionally, a new rule has been deployed to protect Premium WAF users from exploits of the Remote Code Execution vulnerability discussed above as long as Extended Protection has been enabled. Free users will receive these new rules thirty days from today.

    As always, if you believe your site has fallen victim to the successful exploitation of an attack like this or any other, please don’t hesitate to contact our team of experts to discuss a site cleaning or security audit.

    The post Duplicator Update Patches Remote Code Execution Flaw appeared first on Wordfence.

  • WordPress Database Upgrade Phishing Campaign

    WordPress Database Upgrade Phishing Campaign

    WordPress Database Upgrade Phishing Campaign

    We have recently been notified of phishing emails that target WordPress users. The content informs site owners that their database requires an update and looks like this:

    The email’s appearance resembles that of a legitimate WordPress update message, however the content includes typos and uses an older messaging style. Another suspicious item in the content is the deadline. WordPress wouldn’t define deadlines without a valid explanation, and hosting providers wouldn’t either (if you believed the email was from them).

    Continue reading WordPress Database Upgrade Phishing Campaign at Sucuri Blog.

  • Ninja Forms Security Updates: What You Need To Know

    Yesterday, the popular WordPress plugin Ninja Forms released version 3.3.14, which disclosed and patched two security issues present in the plugin. Upon review of these issues we’ve determined their severity to be moderately low, however due to the plugin’s wide userbase of more than a million active installs we’ve elected to provide a detailed exploration of exactly what these vulnerabilities are and what risks they do pose if left unpatched. As usual, we recommend updating vulnerable versions of the plugin as soon as possible, despite the relatively low risk.

    This post is Copyright 2018 Defiant, Inc. and was published on the wordfence.com official blog. Republication of this post without permission is prohibited. You can find this post at: https://www.wordfence.com/blog/2018/08/ninja-forms-security-updates-what-you-need-to-know/

    Cross-Site Scripting (XSS) In Import Function

    The first security issue we’ll look at can be found in the WordPress Vulnerability Database as Ninja Forms <= 3.3.13 – Cross-Site Scripting (XSS) in Import Function.

    Ninja Forms contains Import/Export functionality which allows privileged users to create a form within the plugin, then save the configuration of that form in a portable .nff file downloaded to their local machine. This file can be used as a backup, migrated to other sites, etc. On import, the text data in the .nff file is parsed and converted into a functional web form.

    Because the content of this imported file is ultimately converted into an HTML web form, it’s possible for a user to craft a working .nff file which contains malicious JavaScript code. When the form is displayed, this JavaScript can execute within the browser of anyone viewing the form. Because the Import/Export tool is only available to site administrators, this isn’t necessarily a vulnerability by itself, since if an attacker secured administrative access to the WordPress site they’d be able to install whatever malicious content they had regardless.

    However, in unpatched versions of the plugin, it can be possible for malicious actors to manipulate a site administrator into unknowingly importing a bad .nff file. By crafting a link or redirect, or otherwise getting a logged-in administrator to visit an unsafe page, a Ninja Forms import can be triggered regardless of if the administrator has the Import page open at all.

    A formatted example of a malicious field in an .nff payload.

    If this import successfully triggers, the XSS payload will launch in the browser of any user who views the malicious form. Unless the shortcode for the malicious form is placed on a page or post of the affected site, this is generally limited to only affecting logged-in users who preview the form within their WordPress dashboard.

    The patch for this issue adds a nonce to the Import function in the Ninja Forms, which prevents malicious redirects from triggering the import, as the administrator will need to have opened the import page and uploaded the file themselves.

    What is Cross-Site Scripting (XSS)?

    Cross-Site Scripting refers to the practice of injecting malicious code (nearly always JavaScript) into a web page or application with the intention of the payload executing in the browsers of a site’s visitors or administrators. Flaws in vulnerable applications commonly render user input without sanitizing it first, allowing code to be inserted in unexpected ways.

    For further reading on XSS flaws, what they are, and how to prevent them, check out How to Prevent Cross Site Scripting Attacks.

    What Should I Do?

    Once you’ve updated Ninja Forms, take a moment to ensure there are no unknown forms on your site by clicking the Ninja Forms link in the sidebar of your WordPress dashboard (again, you must be logged in with an Administrator account to see this). If there are no unfamiliar forms present, no further action is required.

    In the event that you do confirm a malicious form is present, you can delete it from the list of forms by clicking the cog-wheel icon in the rightmost column of its row, then clicking Delete and following the subsequent prompt. Do not click into the form to see what’s inside, as you run the risk of launching a malicious JavaScript payload. 

    CSV Injection

    The second vulnerability can be found on the WordPress Vulnerability Database as Ninja Forms <= 3.3.13 – CSV Injection.

    Unrelated to the Import/Export functionality which allows the forms themselves to be exported, Ninja Forms also includes an Export function for users to archive the submissions to their forms in a .csv file, which can then be opened in a user’s spreadsheet software of choice. It behaves as you’d expect: the value in each field of a submitted form gets placed in its own cell in the spreadsheet, one row per submission.

    In unpatched versions of Ninja Forms, if a user submission contains a CSV injection payload in any form fields, the exported .csv file has the potential to perform unsafe actions if opened as a spreadsheet.

    What is CSV Injection?

    Discussing CSV injection vulnerabilities in the context of web security is tricky, and requires some understanding of what exactly takes place.

    Spreadsheet software like Microsoft Excel and LibreOffice Calc allow cells to be populated by a number of different elements. The most common are simple text and numeric values, but it’s likely that you’re also familiar with inserting formulas instead of static values.

    Cell C1 displays the value “3”, but is actually a formula that sums the values of A1 and B1.

    What many people may not be aware of are the sheer variety of things one can actually accomplish with this sort of syntax. Hyperlinks can be created, data from the affected spreadsheet and other open sheets can be exfiltrated, and system commands can even be executed.

    The reason CSV injection is a tricky subject is because there isn’t really an agreement on where the finger should be pointed when it comes up. Fundamentally, the malicious execution takes place within the spreadsheet software itself, which is usually happy to parse and execute any function it sees. However, the argument from the other side is that automatic formula expansion works as intended, and untrusted input should be sanitized before being exported to a .csv document in the first place.

    That said, in 2014 LibreOffice Calc and OpenOffice Calc both removed the DDE command execution functionality which allows this sort of command execution. Microsoft Excel instead implemented a warning dialogue, which prompts users to only allow execution if the file came from a trusted source. There’s a pretty strong issue here, though, because who doesn’t trust their own website? Outside of the fact that it’s well-known that most users are happy to click “allow” on any security pop-up they get on their computer, it’s less likely than usual that a user will know to block the execution.

    An example of the security prompt triggered by Microsoft Excel.

    Any application that generates spreadsheets has the potential to create unsafe files if input from untrusted users is involved. This, combined with the fact that many bug bounty programs (including HackerOne’s own bounty program for its sites) explicitly exclude CSV injection flaws from the scope of their programs, make it a unique issue for the security community at large. Since the concept of CSV injection itself is less a vulnerability in any one piece of software than it is a flaw in the way spreadsheet logic is handled globally, it’s a tough one to squash.

    Back On Subject

    The original patched version of Ninja Forms sanitizes potentially malicious form fields when they’re exported to a .csv file by prepending a single quote ' to any cell whose value begins with an equals sign =. This effectively prevents any spreadsheet formula from executing when rendered. However, the OWASP recommendation for mitigating CSV injection recommends additionally sanitizing cells beginning with the characters @, +, and -, as certain systems and software may have similar rendering behavior associated with these characters.

    With this in mind, I reached out to Zach Skaggs, product owner of Ninja Forms, in order to discuss potentially hardening this patch to prevent these edge-case evasions. Zach was already aware of these alternate characters, and originally determined after some testing that their exploitability was too low to be of concern. While the likelihood of these evasions being successfully implemented in the wild is indeed very low, after some discussion Zach agreed it was worth implementing a patch for these to be safe. A few hours ago at the time of this writing, Ninja Forms 3.3.14.1 was released, which adds this extra hardening.

    What Should I Do?

    If you’ve performed a CSV export of your Ninja Forms submissions prior to this patch, make sure that no values in any of the cells begin with the characters =, @, +, or -. You will need to perform this review via text editor or command line, as opening the file in spreadsheet software has potential to perform unsafe actions. You can also export a new CSV from a patched version of Ninja Forms to safely replace old exports if you wish.

    Conclusion

    Despite the potential for harm that can be caused by allowing a malicious spreadsheet document to execute, the flaws patched by Ninja Forms are of low severity. Successful exploitation of both vulnerabilities rely on a number of outside factors:

    • Successfully triggering an import of a malicious .nff file requires some level of interaction by a logged-in administrator of an affected site.
      • If a malicious .nff file is imported, the resulting form needs to then be viewed for the script to execute.
    • Successful implementation of the CSV injection vulnerability requires an administrator to eventually perform a CSV export, which isn’t a behavior an attacker can rely on or predict.
      • If an export is executed, most practical CSV injection payloads are specific to the spreadsheet software in use and the operating system it’s running on. While “Microsoft Excel On Windows” is the most likely combination, the increasing popularity of operating systems like OS X and Linux, as well as open source office software like OpenOffice and LibreOffice, makes this an attack unlikely to be launched outside of very targeted engagements.

    To learn more about the cause of these sorts of vulnerabilities, and how to prevent them from popping up in your code, check out our educational series Understanding PHP Vulnerabilities & How They Originate.

    The post Ninja Forms Security Updates: What You Need To Know appeared first on Wordfence.