Dre and I talk the history of Sucuri and the future of internet security.
It’s early in the year and something to think about is security! Dre Armeda is here to tell us all about that – the full history of his company, Sucuri, where they’ve been and why they are kicking it up a notch. Super informative and important to anyone doing business on the web! Show Notes
I know it says not to panic, but my tummy took a tumble when reading this one. Hey, I'm not immune to fear. :)
A critical remote code execution vulnerability in PHPMailer has been discovered by Polish researcher Dawid Golunski. The vulnerability was announced on legalhackers.com yesterday but proof of concept exploit details were not included. Unfortunately someone posted a proof of concept to exploit-db and to github a few hours ago demonstrating how the vulnerability can be exploited in the PHPMailer library, but not targeting any web application that is in use.
We are publishing this unscheduled update to give PHP developers and our community advance warning of this issue. We expect this story to continue to evolve rapidly as more developers and malicious actors look at this code.
PHPMailer is used by WordPress core to send email. You can find the code in the wp-includes/class-smtp.php core file.
NOTE: There is no known exploit publicly available for WordPress core or any WordPress theme or plugin at this time. The only exploit we have seen is where a researcher has built their own application and then exploited it, demonstrating the existence of this vulnerability in PHPMailer. (Details below)
Please don’t contact the WordPress core team, WordPress forum moderators
By checking Google Analytics you can notice a lot of fake referral sites. This tutorial shows you how to block the so-called language spam sites.
Nobody likes spam, and it can be a very frustrating for WordPress site owners as it typically involves taking time to setup filters and researching the best way to block it. Many by now are used to dealing with referrer spam, as it something that has plagued us for years. However, in the past couple months there has been a new approach to this, in the form of what everyone is now calling language spam. Most of you probably started noticing this right around the time of the 2016 US elections. Follow our tutorial below on the best ways block language spam and prevent it from skewing your traffic and analytics statistics. It is very important to fix these as soon as they start appearing. 68% of a WordPress site's traffic we tested was from language spam.
Anyone else notice more attacks during December? My WordFence installs are off the hook with banning IPs.
At Wordfence we constantly monitor the WordPress attack landscape in real-time. Three weeks ago, on November 24th, we started seeing a rise in brute force attacks. As a reminder, a brute force attack is one that tries to guess your username and password to sign into your WordPress website. In today’s post we show you how attacks have increased during the past 3 weeks and share some data about where attacks are originating from.
First: How to protect yourself from these attacks
Brute force attacks are unsophisticated. They are simple password guessing attacks. A machine will automatically try to sign into your website over and over in the hope that it can guess your password.
If you install the free version of Wordfence, you are automatically protected against brute force attacks. It’s that simple. We also automatically block the worst offenders completely, and we share some information below on who those are.
We have a few other really cool options, like preventing username discovery and immediately locking out invalid usernames. All these techniques help protect you against brute force attacks.
Download and install the free version of Wordfence today to get instant protection
WordPress Security is something you should take seriously about or else you will end up with a Hacked WordPress Website. A WordPress Malware Redirect is a hack where your site is injected with malware forcing your visitors to be redirected to phishing or malware websites. Check out this guide on How to Detect and Clean WordPress Malware Redirects and avoid being blacklisted by Google and loose your SE Ranking.
So, did it hurt you when you see your website is redirecting to phishing or malware websites? Alas, even when you have strengthened your website’s defenses, about 30,000 web sites are hacked daily. So it’s very important to know what to do when that day comes! If your website was hacked there are more chances that attackers might insert malicious code that redirects your website to phishing or malware websites to grab traffic, that’s just adding insult to injury – and can really damage your website reputation.
In case your site is redirecting visitors to phishing or a malware site, you will possibly get blacklisted by Google! Google isn’t going to take any chances with its reputation, if your webpage(s) smell even the slightest bit fishy, it's going blacklist you. I will cover Google blacklist later on in this article.
What Is Malicious Redirect – A Definition
A hacker can use a script they created to systematically redirect your website to a Scam Website or an Adult(call me Porn) website in order to down the reputation of your own website. Most commonly they will use the following tricks to change the behavior of a website!
Upload or create a file
Well that would have been a major problem. Perhaps more needs to be considered when dealing with this particular point of failure.
At Wordfence, we continually look for security vulnerabilities in the third party plugins and themes that are widely used by the WordPress community. In addition to this research, we regularly examine WordPress core and the related wordpress.org systems. Recently we discovered a major vulnerability that could have caused a mass compromise of the majority of WordPress sites. The vulnerability we describe below may have allowed an attacker to use the WordPress auto-update function, which is turned on by default, to deploy malware to up to 27% of the Web at once.
Choosing the most damaging target to attack
The server api.wordpress.org (or servers) has an important role in the WordPress ecosystem: it releases automatic updates for WordPress websites. Every WordPress installation makes a request to this server about once an hour to check for plugin, theme, or WordPress core updates. The response from this server contains information about any newer versions that may be available, including if the plugin, theme or core needs to be updated automatically. It also includes a URL to download and install the updated software.
Compromising this server could allow an attacker to supply their own
Watch out for PHP Object injections - there are some out in the wild that are making trouble.
Over the past month or so I have been monitoring the activity of a series of attacks against our hosting customers which had one common vector: insecure WordPress plugins which exposed PHP objects to potential injection. Only a very small number of our customers were affected and with every compromised instance we work with our customers and provide every detail we can regarding the attack. In this case we found the vulnerability being exploited was an unpublished (or zero day) exploit in the wild. As we worked to mitigate the vulnerability we kept an open dialog with our affected customers as we worked with the plugin author on a patch or in some cases: disabling the insecure plugin. About PHP object injection attacks
The attack we saw was not a new type of attack, but an attack method that is a little obscure compared to the more commonly talked about: XSS and/or SQLi. PHP Object Injection is discussed in depth by security groups like OWASP as well as being so severe it warranted a large red warning on php.net warning not to utilize the unserialize() function with untrusted data. Many plugin developers have fallen short of this best practice and utilized this function insecurely from
Parts of this new API are available to anyone on the Internet. It's possible to list users on a WordPress website without registering.
WordPress 4.7 was released 6 days ago, on December 6th. It includes a REST API that will be used by many WordPress plugins, mobile apps, desktop applications, cloud services and even WordPress core in future. Every site that upgrades to WordPress 4.7 has this API enabled by default. The API is powerful and allows WordPress to move from being a simple web based content-management system into being an application framework. What this means is that developers can write applications that run anywhere and talk to your WordPress website. So in future you’ll be able to publish content and manage your site from the cloud, from your phone, tablet or desktop and plugin developers will be able to create new kinds of extensions that improve your WordPress experience. All of these applications will use the new WordPress REST API that was released in WordPress core version 4.7.
As the saying goes, with great power comes great responsibility. Parts of this new API are available to anyone on the internet. They don’t need to sign into your WordPress website to use the API. They can just connect and use it. With the launch of this API, we expect developers to embrace it, but we also expect
An interesting article that explains how attackers can use XSHM, a problem in the Same Origin Policy to identify WordPress websites running on internal networks and behind firewalls, and also launch a login brute force attack against them.
Statistics from w3techs suggest that 1 out of 4 websites (around 25%) on the internet are powered by WordPress. WordPress’ popularity is derived from its ease of setup and use, its contributing community, and the big repertoire of plugins and themes that are available. Why is WordPress Such a Common Target?
Even though WordPress is a beginner friendly web application, like every other platform it has its own issues and limitations. One of the most voiced security issues is that it is possible and very easy to bruteforce login credentials. WordPress’ advice on this is to install a security plugin, protect the WordPress login page with a .htpasswd file (HTTP authentication), and of course use strong credentials.
However many users, especially the unexperienced ones do not take these extra security measures onboard. They use very weak credentials and do not setup any additional layers of security on their websites, thus making WordPress a good target for brute force attacks.
How to Bruteforce WordPress Websites and Blogs on Internal Networks
WordPress blogs aren’t always used for publicly accessible websites. They are also frequently used as websites in intranets for
WordFence is very good at getting a few jabs in at their competitors, and this post is no exception. I'm sure it will rankle a few feathers, as they usually do.
In this post I’m going to discuss a major problem that exists with several WordPress malware scanners: The use of weak hashing algorithms for good and bad file identification. Some malware and antivirus scanners outside of WordPress suffer from this same issue. For brevity, I’m going to refer to this as the “weak hash scanner” issue.
This issue may allow an attacker to hide malware that is undetectable to scanners using the MD5 hashing algorithm. Below I will explain how hashes are used in the security industry, what the problem is and how to solve it. I’ll also point you to research demonstrating this issue and further reading. I’ll also describe how Wordfence uses a secure hashing algorithm for our malware scanner.
How we use hashes in the security industry to find bad things
In the security world we have a commonly used process of running a file through a piece of logic, called an algorithm, and generating a unique number. That number is used to uniquely identify files. This process is called a hashing algorithm and the unique number is called a ‘hash’.
We use hashing algorithms for all kinds of really cool and useful stuff. We can
Gravatars are nice ways to personalize posts and comments on websites and are widely used by WordPress. This is an interesting article that discusses a privacy weakness when using the Gravatar service. Even if the author or person commenting doesn't have a Gravatar, their email or identity could potentially be exposed.
Gravatar is a service that provides users with a profile image that can appear on many sites across the Net. It is integrated with WordPress.com (The version of WordPress hosted by Automattic) and is also integrated into WordPress.org, the self hosted version of WordPress. Gravatar is also used by many other popular services on the web like StackOverflow.com. If you sign up for a website on WordPress.com and publish a blog post, a Gravatar icon appears on your site as your profile photo, indicated by the red arrow below. You can visit gravatar.com to customize that icon and upload a photo of your own.
If you use WordPress.org, Gravatars are an option you can enable for your users and they are widely used. It will either show their profile photo if they have gone to Gravatar.com to create one, or it will show a default image. You can select from several kinds of default images.
Other services like StackOverflow, one of the most popular sites on the web, also use Gravatar for profile images.
In the HTML source code of your website, Gravatar loads images using a hash of your email address. If you read our post earlier this week where we discuss the problem of malware scanners using weak
Nice Sucuri posts on a hacking technique better than creating new admin users. A legitimate admin user will not be deleted during a cleanup.
When a site gets hacked, the attack doesn’t end with the malicious payload or spam content. Hackers know that most website administrators will clean up the infection and look no further. Many go on to patch vulnerable software, change their passwords, and perform other post-hack steps. All of this is good, but hackers who follow through the sustainment phase of the attack also leave behind ways to easily reinfect the site. After breaking into a website, hackers want to make sure they still have access if the original security hole is closed. Most often, they upload backdoors or create new malicious users. There is also a combination of the two approaches: login bypasses. These allow attackers to gain administrative rights without authentication by using a special parameter in the HTTP request.
WordPress Login Bypass
Recently, we found this buggy bypass code injected into a WordPress wp-login.php file.
Login bypass using the kidsid parameter
The request was placed inside legitimate comments, which made it more suspicious since this trick is only used by malware.
The purpose of this code is to provide an admin user ID for the kidsid parameter when requesting wp-login.php. This allows
ManageWP keeps getting better and pulling out new services to its Orion Platform. Raising the bar...
Some basic and a lot of advanced tips to make your site more secure. Most in-depth guide you'll find about WP security.
When it comes to WordPress, there are a lot of things you can do to lock down your site to prevent hackers and vulnerabilities from affecting your business or blog. The last thing you want to happen is to wake up one morning to discover your site in shambles. So today we are going to be sharing a lot of tips, strategies, and techniques you can use to better your WordPress security and stay protected. WordPress Vulnerabilities
WordPress gets a bad rap sometimes for being prone to security vulnerabilities and inherently not being a safe platform to use for a business. However, this is almost always due to the fact that users keep following industry-proven security worst-practices. Using outdated WordPress software, poor system administration, credentials management, and lack of necessary Web and security knowledge among non-techie WordPress users keeps hackers on top of their cyber-crime game. Even industry leaders don’t always use best practices. Reuters was hacked back in 2012 because they were using an outdated version of WordPress.
Now this is not to say vulnerabilities don’t exist. According to a Q2 2016 study by Sucuri, a multi-platform security company, WordPress continues
WordPress security starts with you. Learn how to add HTTPS and SSL to WordPress to keep your website and visitors' data safe and search engines happy.
SSL is a certificate which replaces the normal HTTP tunnel into a secured one. Thus, the data flowing through the tunnel is encrypted in order to stay secure. Other than the security benefits for your WordPress website, having an SSL certificate can actually boost the organic ranking. Of course, a search engine ranking depends on multiple factors, but Google has made it official that secured websites will be given priority.
An official word from Google is enough to get a clear understanding of their motive. They want more and more websites to use secured protocols so that the user’s data is protected and they are given an even better experience.
However, it is not mandatory to get onboard. Still, the added benefits and the security layer itself are enough to get in.
Judging from the fact you’re reading all this, you’ve already made the decision to go with SSL. So, let’s jump into the tutorial part and learn how to add SSL and HTTPs in WordPress.
HTTP is a protocol which is responsible for transferring files from one server to another. It’s the core of internet and works as a transport medium.
The default HTTP simply cares about transporting of files from
Good stuff on HTTPS and SEO from Zack Tollman looking back on the months-long full HTTPS rollout at Wired.com.
WIRED.com is now entirely HTTPS. In other words: All our content is encrypted in transit from our servers to your browser, and this ensures no one is fiddling with that content before it reaches you. We began this rollout nearly five months ago and took the final step of turning on HTTPS across the entire site last week. Now that we’ve reached this milestone, we wanted to share our experiences with you—just in case you want to move a media site to HTTPS.
Planning and preparing for moving to HTTPS was more of a human engineering than a technical engineering project. We started discussing the possibility of moving to HTTPS as far back as June 2015, with conversations intensifying toward the end of 2015. We coordinated closely with our ad teams—both the people who manage the technical and the operational aspects of ad delivery. We also worked with our SEO and business development teams as we evaluated risks associated with moving to HTTPS.
We decided that a staged rollout, where we convert one section at a time to HTTPS, would allow us to take on smaller amounts of risk at a time (a move that we cribbed from The Washington Post). With each section migration,
Nice information from a regular report from Sucuri looking at 9,000 infected websites. Looks like WP sites on a decrease overall, but half of WP sites still out of date.
Today we’re releasing our quarterly Hacked Website Report for 2016/Q2. The data in this report is based on compromised websites we worked on, with insights and analysis performed by our Incident Response Team (IRT) and Malware Research Team (MRT). CMS Analysis
Our analysis consisted of over 9,000 infected websites. The graphs below show a side-by-side comparison with our 2016/Q1 report.
The four open-source Content Management Systems (CMS) we focus on in our report include WordPress (78%), Joomla! (14%), Magento (5%), and Drupal (2%).
We dive into specific information about out-of-date software found on websites going through our cleanup process. Some interesting datasets include that WordPress installations were out-of-date 55% of the time while Joomla! (86%), Drupal (84%), and Magento (96%) continue to lead the way with out-of-date software.
We briefly cover specific extensible components within the WordPress platform. As it makes up the largest sampling in our environment (78%), we place special emphasis on the top three plugin vulnerabilities contributing to 22% of WordPress site hacks.
In this report, we also include a new telemetry dataset that shows the most popular WordPress
This month might seem like a slow month in terms of numbers, but it is definitely not a boring one. A sensitive information disclosure vulnerability in was reported in the WordPress REST API, which most probably was the concern that many WordPress users had when WordPress wanted to include the REST API in its core.
This is a monthly roundup of all the WordPress core, WordPress plugins and WordPress themes vulnerabilities reported during the month of October 2016. This roundup is made possible through WP Security Bloggers, an aggregate of popular WordPress security blogs and websites that publish WordPress security news and updates. Recap of WordPress Vulnerabilities in October 2016
October 2016 was a slow month in terms of reported vulnerabilities, though it is not a boring one, mainly because of an Sensitive Information disclosure vulnerability in the WordPress REST API plugin. Basically the attacker can obtain the username, email address, first name, last name, date of registration, and detailed privilege information about every registered user on the target WordPress with a single HTTP request. Such WordPress REST API security issues were the worry of many WordPress users when WordPress were planning of including the REST API in the core.
Well, the vulnerability was fixed, so we have a better WordPress REST API now. Also, it was never included in the WordPress core, so there is not much to worry about. Below is the complete list of all the reported vulnerabilities during October 2016.
Wordfence have just announced that they're removing the Falcon caching engine in a future update. This post explains the reasons, and what you need to know.
Version 6.2.1 of Wordfence was just released and you may have noticed in the changelog that we’ve announced that we will be removing Falcon from Wordfence. I thought I’d go into some detail about why we made this decision. When we launched Falcon, the caching feature that is part of Wordfence, it was a ground breaking caching engine that was faster than any cache available for certain user configurations. But caching is a complex beast and we have learned a lot during the past few years. When Falcon launched, we were just a team of two people. Wordfence is now a team of 23 people and our area of specialization is high performance security. Not caching.
During the past few months we have been working with hosting providers and what we’ve learned is that, for certain hosting provider configurations, Falcon cache actually can slow things down slightly and it’s preferable for the customer to instead rely on a much faster front-end cache that the host provides. The reason for this is because some hosts use slow local disk for their WordPress hosting but use very fast front-end caches. In those configurations, Falcon generates unwanted disk IO trying to outperform
Many of us used Dropbox for a while, so this is something to pay attention to. See if you've been pwned at https://haveibeenpwned.com/.
Earlier today, Motherboard reported on what had been rumoured for some time, namely that Dropbox had been hacked. Not just a little bit hacked and not in that "someone has cobbled together a list of credentials that work on Dropbox" hacked either, but proper hacked to the tune of 68 million records. Very shortly after, a supporter of Have I been pwned (HIBP) sent over the data which once unzipped, looked like this:
What we've got here is two files with email address and bcrypt hashes then another two with email addresses and SHA1 hashes. It's a relatively even distribution of the two which appears to represent a transition from the weaker SHA variant to bcrypt's adaptive workload approach at some point in time. Only half the accounts get the "good" algorithm but here's the rub: the bcrypt accounts include the salt whilst the SHA1 accounts don't. It's just as well because it would be a far more trivial exercise to crack the older algorithm but without the salts, it's near impossible.
At first glance the data looks legit and indeed the Motherboard article above quotes a Dropbox employee as confirming it. But I like to be sure about these things and as I've written
Upps. That must have been a scary morning for everybody in TechCrunch. They use WordPress VIP, and this was just because of weak password by a contributor, who most likely getting fired! Use strong password people, can't urge more.
TechCrunch is the latest victim in OurMine’s summer hacking rampage. The site, which is powered by WordPress and hosted via WordPress.com VIP, was hacked this morning and defaced with a message from the attackers who identify themselves as an “elite hacker group.” TechCrunch’s news ticker was updated to display: “Hello guys it’s OurMine Team, we are just testing TechCrunch Security, don’t worry we never change your passwords. Please contact us.” OurMine gained access to a contributor account and posted a similar message.
According to a report from Engadget, TechCrunch’s sister site, the hackers gained access via a contributor’s weak password, not by exploiting a vulnerability in WordPress or the site’s plugins. TechCrunch was able to regain control of the site within minutes and delete the content created by the attackers in the admin.
OurMine is the same group that hacked Mark Zuckerberg’s Twitter, Pinterest, and LinkedIn accounts after he used the same password for multiple sites. Bad password security can make even the most secure websites vulnerable to these types of attacks. Although OurMine is primarily targeting
Krasimir highlights an aspect most of us have probably never considered a security issue - a plugin's domain !
Recently our incident response team had a case in which a website was redirecting users to an external domain. Ad pop-ups were displayed, and some were obviously malicious. For example, below is this Comcast tech support scam pop-up that tried to block a web browser and asked to call their number.
Flexytalk Widget Plugin
With the constant increase of WordPress security awareness, we are seeing a number of WordPress audit trail plugins hitting the market. Similar to WordPress security plugins there are quite a few of them so finding the right one that checks all your requirements can be a bit of an experience. Here is a short guide of what to look for when evaluating WordPress audit log plugins.
Your business just switched from a custom made and complex CMS system to WordPress. All well and good, you have setup your blog, installed a few plugins and ready to get cracking. But how will you keep track of what the users are doing on your new WordPress website? Introducing WordPress Audit Trail Plugins
WordPress does not have any built-in audit trail / logging capabilities, therefore over the years several audit log and trail plugins have been developed, such as WP Security Audit Log, Simple History and Audit trail. These are just a few; there are several other WordPress audit trail plugins. With so many different audit trail plugins available, which one is the right one for your WordPress website or blog? This article explains which are the features and capabilities you should look for when evaluating an audit trail plugin for your WordPress website.
Details Reported in the WordPress Audit Log
Every WordPress audit trail (audit log) plugin reports the changes that happen on your WordPress differently. For example when a user changes something in a post some plugins simply log the change in the audit log that the post has been updated.
Other plugins, such as WP Security Audit Log
Free HTTPS for all custom domains on .com via Let’s Encrypt project.
Today we are excited to announce free HTTPS for all custom domains hosted on WordPress.com. This brings the security and performance of modern encryption to every blog and website we host. Best of all, the changes are automatic — you won’t need to do a thing.
As the EFF points out as part of their Encrypt the Web initiative, strong encryption protects our users in various ways, including defending against surveillance of content and communications, cookie theft, account hijacking, and other web security flaws.
WordPress.com has supported encryption for sites using WordPress.com subdomains (like https://barry.wordpress.com/) since 2014. Our latest efforts now expand encryption to the million-plus custom domains (like automattic.com) hosted on WordPress.com.
The Let’s Encrypt project gave us an efficient and automated way to provide SSL certificates for a large number of domains. We launched the first batch of certificates in January 2016 and immediately starting working with Let’s Encrypt to make the process smoother for our massive and growing list of domains.
For you, the users, that means you’ll see secure encryption automatically deployed on every new site within minutes. We are