Election Hack Report FAQ: What You Need to Know

On Friday we published an analysis of the FBI and DHS Grizzly Steppe report. The report was widely seen as proof that Russian intelligence operatives hacked the US 2016 election. We showed that the PHP malware in the report is old, freely available from a Ukrainian hacker group and is an administrative tool for hackers.

We also performed an analysis on the IP addresses included in the report and showed that they originate from 61 countries and 389 different organizations with no clear attribution to Russia.

Our report has received wide coverage. Since then I have been interviewed on international network news and by online publications to share our findings. I’d like to provide some clarity both on the FBI/DHS report itself and our findings in the form of an FAQ.

Our business is WordPress security and our customers use WordPress and the Wordfence firewall and malware scanner. Some of this report will be talking directly to our customers, and some of it will be helpful for those interested in security in general and global events.

Table of Contents:

I’m a Wordfence customer who uses WordPress. What do I need to know?

Wordfence detects the PHP malware that is in the report. It also blocks it from being uploaded to a WordPress website. Even before the FBI/DHS released this report, we were blocking this malware.

That is how we found the original source code: By capturing a sample when a hacker tried to upload it to a customer website. The upload occurred before the FBI/DHS report came out. We tracked and logged over 130 unique attempts to upload the specific malware sample the FBI/DHS provided.

The samples the FBI released are old and limited. Wordfence detects thousands of malware varieties that are actively used to attack WordPress websites. We also track a much larger set of IP addresses.

The bottom line is that if you use Wordfence, you are safe from anything in the DHS report that affects your website, and much more.

Does the report prove that Russia Hacked the 2016 US Election?

No it does not. What Wordfence revealed on Friday is that the PHP malware sample that the US government provided is:

  • An old version of malware. The sample was version 3.1.0 and the current version is 3.1.7 with 4.1.1 beta also available.
  • Freely available to anyone who wants it.
  • The authors claim they are Ukrainian, not Russian.
  • The malware is an administrative tool used by hackers to upload files, view files on a hacked website, download database contents and so on. It is used as one step in a series of steps that would occur during an attack.

Wordfence also analyzed the IP addresses available and demonstrated that they are in 61 countries, belong to over 380 organizations and many of those organizations are well known website hosting providers from where many attacks originate. There is nothing in the IP data that points to Russia specifically.

If I find something in the DHS/FBI report on my website or network, does it mean that Russia hacked me?

No it does not.

This has caused serious confusion already among press and US policy makers. A Vermont electrical utility found a sample of what is in the DHS/FBI Grizzly Steppe report on a single laptop. That laptop was not connected to the Electric Grid network. It was reported as Russia hacking the US electrical grid.

Glenn Greenwald has provided some magnificent reporting on this incident and the response from the media and from US senators.

The data in the DHS/FBI Grizzly Steppe report contains “indicators of compromise” (IOCs) which you can think of as footprints that hackers left behind. The IOC’s in the report are tools that are freely available and IP addresses that are used by hackers around the world. There is very little Russia-specific data in the Grizzly Steppe report.

If you find an IOC that is in the report on your network or server, it is unlikely that you have been targeted by Russian Intelligence.

The PHP malware the report provided, for example, is freely available for anyone who wants it. You can even customize it to include your own password to limit access to others. Please see our original report for details. Any attacker can use it to hack your website, not just Russian Intelligence.

The DHS/FBI report also included IP addresses. The owners of IP addresses change from time to time. An IP that was being used by Russian Intelligence today to hack a target may be used by another attacker to hack a different target a few days later. This can happen for several reasons:

  • A hacked IP can be used by one attacker and then be compromised by a different attacker later on to also launch attacks.
  • IP addresses change ownership from time to time. A Linode IP may be hacked by Russia and used to launch attacks. Then it may be shut down by Linode, change ownership and the new owner’s site can get hacked. Then that IP address is attacking once again, but the attacker is someone else.
  • IP addresses are also dynamic if they belong to an internet service provider (ISP). Some of the IP’s in the Grizzly Steppe report do belong to ISP’s. For example we can see IP’s belonging to Yota.ru, a Russian internet service provider. The hostnames are ‘wimax-client.yota.ru’ which suggests that they are wifi customers. These IP’s are probably dynamic and regularly change hands. They may be used by one attacker today and a different attacker tomorrow.

How did Wordfence determine the malware source, the authors and the version?

We received the DHS/FBI report on Thursday. Rob McMahon, one of my colleagues and a security analyst at Wordfence alerted me to it’s existence at 8pm pacific time on Thursday December 29th. We worked through the night until 7am the next morning when we released the report. Here is what we did:

We read the report and noticed there was a Yara signature for PHP malware. That means that FBI and DHS provided just enough information to identify the existence of PHP malware. It didn’t actually provide the malware itself.

We went into Polestar which is a Wordfence proprietary big-data platform that we have developed to aggregate and mine a large number of attacks from a range of sources. We used the Yara signature to try to determine if anyone has attacked a WordPress site using this malware. At this point we didn’t know what it was or if it was even used against WordPress.

Jackpot! We had captured the entire 20k malware sample!

We extracted the malware sample from Polestar and I handed it to Rob who started analysis on the sample. We divided the work and I went off and analyzed the IP addresses that DHS/FBI had provided in Grizzly Steppe.

Rob realized that most of the malware is encrypted. The way it works is that a hacker will upload it to a website. They access the malware as a web page and are prompted for a password by a small amount of unencrypted code in the malware. They enter the password which is actually a decryption key.

That decryption key is stored in a cookie so the hacker doesn’t have to keep entering it. The key then decrypts the malware code which is executed. Then every time the hacker accesses the malware in future, the key stored in a cookie decrypts the malware so that it can execute. It’s quite clever and makes our jobs harder.

We needed to find the decryption key for the malware. So we went back to Polestar and tried to find an attack that was blocked and logged where the attacker was trying to access the malware they had uploaded.

Jackpot again! We found the key. Rob used the key to decrypt the malware and view the source code. Once he could see the source code, he could see the name of the malware and the version and a few Google searches revealed the source website that it came from.

The rest was much easier. We could now take the malware sample and put it on a sandboxed research environment and actually run it and see what it did. We could also download the newer version of the malware, called ‘P.A.S.’, and execute that to see what it does and how it differs.

This is how we determined that the FBI/DHS report contains an old malware sample that is publicly available and the hacker group that distributes it appears to be Ukrainian.

Why did Wordfence use the title “US Govt Data Shows Russia Used Outdated Ukrainian PHP Malware” when publishing this research?

Some of our readers commented that the title we used for the post was confusing or misleading. Keep in mind that when we published, my team and I had been working through the night.

The problem that some readers had with that title is that it suggests that Russia hacked the US election. But our research indicates that the DHS/FBI report actually does not contain any data attributing the attack to Russia.

If you rewrite the above title and put ‘Russia’ in single quotes it may make more sense.

Perhaps a better title would have been: US Government report does not contain data attributing 2016 election hacks to Russia. The report includes outdated PHP malware that is publicly available and appears to originate from a Ukrainian hacker group. It also includes IP addresses with no clear link to Russia.  

That would have been too long, but I think it accurately captures what we were  trying to convey.

I chose to not change the headline to protect the credibility of our community. When we publish a blog post, many of you share that post on Twitter, Facebook and in other social media. Your share includes the post title. If I change the title later on, it makes it look like you edited the title yourself when sharing our post. You may be accused of exaggerating or changing our words. So once we pull the trigger on a post, the title is never edited.

Which other researchers are talking about this and are worth reading?

On Friday Jeff Carr said about the report:

It merely listed every threat group ever reported on by a commercial cybersecurity company that is suspected of being Russian-made and lumped them under the heading of Russian Intelligence Services (RIS) without providing any supporting evidence that such a connection exists.

Also on Friday Robert M Lee commented about the list of Russian Intelligence Services provided in the report:

But as the list progresses it becomes worrisome as the list also contains malware names (HAVEX and BlackEnergy v3 as examples) which are different than campaign names. Campaign names describe a collection of intrusions into one or more victims by the same adversary. Those campaigns can utilize various pieces of malware and sometimes malware is consistent across unrelated campaigns and unrelated actors. It gets worse though when the list includes things such as “Powershell Backdoor”. This is not even a malware family at this point but instead a classification of a capability that can be found in various malware families.

Or said more simply: the list of reported RIS names includes relevant and specific names such as campaign names, more general and often unrelated malware family names, and extremely broad and non-descriptive classification of capabilities. It was a mixing of data types that didn’t meet any objective in the report and only added confusion as to whether the DHS/FBI knows what they are doing or if they are instead just telling teams in the government “contribute anything you have that has been affiliated with Russian activity.”

Where is this being written about in main-stream news?

Here is a list of news coverage as of Sunday night at 11:15PM Pacific Time:

Final Note

Thank you very much to our community for your kind feedback and input on Friday’s report. I have read every single comment and responded to many. If you have any other questions, please post them in the comments below and I’ll be happy to answer them. Once again, please refrain from posting any political comments. Thank you.

The post Election Hack Report FAQ: What You Need to Know appeared first on Wordfence.

Read More

US Govt Data Shows Russia Used Outdated Ukrainian PHP Malware

The United States government earlier this year officially accused Russia of interfering with the US elections. Earlier this year on October 7th, the Department of Homeland Security and the Office of the Director of National Intelligence released a joint statement that began:

The U.S. Intelligence Community (USIC) is confident that the Russian Government directed the recent compromises of e-mails from US persons and institutions, including from US political organizations. The recent disclosures of alleged hacked e-mails on sites like DCLeaks.com and WikiLeaks and by the Guccifer 2.0 online persona are consistent with the methods and motivations of Russian-directed efforts.

Yesterday the Obama administration announced that they would expel 35 Russian diplomats and close two Russian facilities in the United States, among other measures, as punishment for interfering with the US 2016 election.

In addition, yesterday the Department of Homeland Security (DHS) and the Office of the Director of National Intelligence (DNI) released a Joint Analysis Report, or JAR, compiled by the DHS and FBI, which they say attributes the election security compromises to Russian intelligence operatives that they have codenamed ‘GRIZZLY STEPPE‘.

The report that DHS and DNI released includes in it’s first paragraph: “This document provides technical details regarding the tools and infrastructure used by the Russian civilian and military intelligence Services (RIS) to compromise and exploit networks and endpoints associated with the U.S. election, as well as a range of U.S. Government, political, and private sector entities. The report contains specific indicators of compromise, including IP addresses and a PHP malware sample.

At Wordfence our focus is WordPress security. Our security analysts spend a lot of time analyzing PHP malware, because WordPress is powered by PHP.

As an interesting side-project, we performed analysis on the PHP malware sample and the IP addresses that the US government has provided as “…technical details regarding the tools and infrastructure used by Russian civilian and military intelligence services (RIS)”. [Source]

We used the PHP malware indicator of compromise (IOC) that DHS provided to analyze the attack data that we aggregate to try to find the full malware sample. We discovered that attackers use it to try to infect WordPress websites. We found it in the attacks that we block. Here it is.

PAS 3.1.0

The above is the header and here is the footer. The middle contains an encrypted block of text.

PAS 3.1.0 footer

This is PHP malware that is uploaded to a server. An attacker then accesses the file in a browser and enters a password. The password also acts as a decryption key and decrypts the encrypted block of text which then executes. Once an attacker enters their password, it is stored in a cookie and they don’t need to enter the password again to access the malicious application.

We managed to capture a request from an attacker that contained their password. It was ‘avto’ without quotes. We used the password to decrypt the block of encrypted text.

This is what the decrypted PHP looks like. It is a big chunk of PHP code that is a web shell.

PAS 3.1.0 decrypted

We installed the web shell on a sandboxed environment. This is what it looks like:

PAS Web Shell

This is the kind of web shell that we see all the time in our day-to-day forensic operations. It includes the following basic features:

  • File browser/explorer
  • File search function
  • A database client to download the contents of a hacked site database
  • Network tools including a port scanner and the ability to bind a service to a port
  • A tool to brute force attack passwords on FTP and POP3 services.
  • A command line client to run arbitrary operating system commands
  • A utility to view server configuration info

By viewing the source code, we could find the name of the malware and the version. It is P.A.S. 3.1.0.

We googled it and found a website that makes this malware. You can find the site at this address: http://profexer.name/pas/download.php

PAS Website

You can enter a password that you will use to access your malware once it’s installed and then hit ‘download’ and a ZIP file downloads.

The ZIP contains a text file and the malware. The text file looks like this:

PAS malware text file

The website claims the malware is made in Ukraine and the date at the bottom has the Ukraine country code UA.

This malware is version 3.1.7 which is newer than the malware that the DHS indicator of compromise identifies. It is almost identical including it’s indentation:

PAS 3.1.7 malware header

And the footer:

PAS 3.1.7 malware footer

But PAS has evolved even further since 3.1.7. It is now version 4.1.1 which you can get from the same website:

PAS 4 Download

The 4.1.1b info.txt file:

PAS 4 info.txt

And the code has changed in 4.1.1 quite substantially. This is the header:

PAS4 header

The PAS malware is user friendly. It has an About page:

PAS About malware

They also have a helpful FAQ:

PAS malware FAQ

 

How does PAS infect WordPress websites?

This is a typical infection attempt for PAS 3.1.0 which is the DHS sample:

PAS 3.1.0 malware infection attempt

The above request is an attempt to install a plugin in the WordPress CMS through the normal file upload method. What surprised us is that this request had a full set of cookies that indicates that the user or bot doing this was signed in and this probably was an actual web browser.

It also includes the WordPress nonce which is a security feature, also indicating this is a user. Only about 25% of the attacks that we see include the WordPress nonce, which suggests that many of these attempts fail.

The vast majority of attacks we see that try to infect with PAS 3.1.0 use this kind of request. Here are a few theories:

  • WordPress website owners have malware installed on their workstations and that malware attempts to install PAS 3.1.0 on their WordPress websites.
  • This is CSRF, or cross site request forgery attack, that installs the malware. This is unlikely because the nonce is present in many requests. A nonce is a security feature that prevents CSRF attacks.
  • Users are voluntarily installing this on their own websites after downloading it from a malicious website thinking it is safe. Unlikely because the file that is uploaded is plain text PHP and it is clearly suspicious if you examine the file contents.
  • Attackers are compromising websites through some other means and then using the compromised credentials to manually sign in and install PAS 3.1.0 with a standard browser. These sign-ins could be partially or fully automated.

Malware Conclusions

DHS and DNI have released a joint statement that says:

This document provides technical details regarding the tools and infrastructure used by the Russian civilian and military intelligence Services (RIS) to compromise and exploit networks and endpoints associated with the U.S. election, as well as a range of U.S. Government, political, and private sector entities. The report contains specific indicators of compromise, including IP addresses and a PHP malware sample.

The PHP malware sample they have provided appears to be P.A.S. version 3.1.0 which is commonly available and the website that claims to have authored it says they are Ukrainian. It is also several versions behind the most current version of P.A.S which is 4.1.1b. One might reasonably expect Russian intelligence operatives to develop their own tools or at least use current malicious tools from outside sources.

Analysis of the IP addresses provided by DHS and DNI

DHS provided us with 876 IP addresses as part of the package of indicators of compromise. Lets look at where they are located. The chart below shows the distribution of IP addresses by country.

Distribution of IP addresses

As you can see they are globally distributed with most of them in the USA.

Lets look at who the top ISP’s are who own the IP addresses:

Hosting companies that own malicious IPs

There are several hosting companies in the mix including OVH SAS, Digital OceanLinode and Hetzner. These are hosting companies that provide low cost hosting to WordPress customers and customers who use other PHP applications. A common pattern that we see in the industry is that accounts at these hosts are compromised and those hacked sites are used to launch attacks around the web.

Out of the 876 IP addresses that DHS provided, 134 or about 15% are Tor exit nodes, based on a reverse DNS lookup that we did on each IP address. These are anonymous gateways that are used by anyone using the Tor anonymous browsing service.

Tor exit nodes

We examined our attack data to see which IP addresses in the DHS data are attacking our customer websites. We found a total of 385 active IP addresses during the last 60 days. These IP addresses have launched a total of 2,109,5492 complex attacks during that 60 day period that were blocked by the Wordfence firewall. We consider a complex attack to be an attack that tries to exploit a vulnerability to gain access to a target.

We also logged a total of 14,463,133 brute force attacks from these IP addresses during the same period.  A brute force attack is a login guessing attack.

The chart below shows the distribution of the number of attacks per IP address. It only takes into account complex attacks. As you can see, a small number of the IP addresses that DHS provided as IOC’s are responsible for most of the attacks on WordPress websites that we monitor.

Attack distribution from IPs

The following shows the list of the top 50 IP addresses in the DHS report sorted by the number of complex attacks we saw from each IP during the past 60 days.

screen-shot-2016-12-30-at-4-35-33-am

As you can see, many of the top attacking IP addresses are Tor exit nodes. There is also a relatively small number of IP addresses launching most of the attacks on websites we monitor.

Conclusion regarding IP address data

What we’re seeing in this IP data is a wide range of countries and hosting providers. 15% of the IP addresses are Tor exit nodes. These exit nodes are used by anyone who wants to be anonymous online, including malicious actors.

Overall Conclusion

The IP addresses that DHS provided may have been used for an attack by a state actor like Russia. But they don’t appear to provide any association with Russia. They are probably used by a wide range of other malicious actors, especially the 15% of IP addresses that are Tor exit nodes.

The malware sample is old, widely used and appears to be Ukrainian. It has no apparent relationship with Russian intelligence and it would be an indicator of compromise for any website.

You can find a public repository containing the data used in this report on github.

As always I welcome your comments. Please note that I will delete any political comments. Our goal in this report is to merely analyze the data DHS provided and share our findings.

Mark Maunder – Wordfence Founder/CEO

Special thanks to Rob McMahon and Dan Moen who provided valuable assistance with this research. 

The post US Govt Data Shows Russia Used Outdated Ukrainian PHP Malware appeared first on Wordfence.

Read More

US Govt Data Shows Russia Used Outdated Ukrainian PHP Malware

The United States government earlier this year officially accused Russia of interfering with the US elections. Earlier this year on October 7th, the Department of Homeland Security and the Office of the Director of National Intelligence released a joint statement that began:

The U.S. Intelligence Community (USIC) is confident that the Russian Government directed the recent compromises of e-mails from US persons and institutions, including from US political organizations. The recent disclosures of alleged hacked e-mails on sites like DCLeaks.com and WikiLeaks and by the Guccifer 2.0 online persona are consistent with the methods and motivations of Russian-directed efforts.

Yesterday the Obama administration announced that they would expel 35 Russian diplomats and close two Russian facilities in the United States, among other measures, as punishment for interfering with the US 2016 election.

In addition, yesterday the Department of Homeland Security (DHS) and the Office of the Director of National Intelligence (DNI) released a Joint Analysis Report, or JAR, compiled by the DHS and FBI, which they say attributes the election security compromises to Russian intelligence operatives that they have codenamed ‘GRIZZLY STEPPE‘.

The report that DHS and DNI released includes in it’s first paragraph: “This document provides technical details regarding the tools and infrastructure used by the Russian civilian and military intelligence Services (RIS) to compromise and exploit networks and endpoints associated with the U.S. election, as well as a range of U.S. Government, political, and private sector entities. The report contains specific indicators of compromise, including IP addresses and a PHP malware sample.

At Wordfence our focus is WordPress security. Our security analysts spend a lot of time analyzing PHP malware, because WordPress is powered by PHP.

As an interesting side-project, we performed analysis on the PHP malware sample and the IP addresses that the US government has provided as “…technical details regarding the tools and infrastructure used by Russian civilian and military intelligence services (RIS)”. [Source]

We used the PHP malware indicator of compromise (IOC) that DHS provided to analyze the attack data that we aggregate to try to find the full malware sample. We discovered that attackers use it to try to infect WordPress websites. We found it in the attacks that we block. Here it is.

PAS 3.1.0

The above is the header and here is the footer. The middle contains an encrypted block of text.

PAS 3.1.0 footer

This is PHP malware that is uploaded to a server. An attacker then accesses the file in a browser and enters a password. The password also acts as a decryption key and decrypts the encrypted block of text which then executes. Once an attacker enters their password, it is stored in a cookie and they don’t need to enter the password again to access the malicious application.

We managed to capture a request from an attacker that contained their password. It was ‘avto’ without quotes. We used the password to decrypt the block of encrypted text.

This is what the decrypted PHP looks like. It is a big chunk of PHP code that is a web shell.

PAS 3.1.0 decrypted

We installed the web shell on a sandboxed environment. This is what it looks like:

PAS Web Shell

This is the kind of web shell that we see all the time in our day-to-day forensic operations. It includes the following basic features:

  • File browser/explorer
  • File search function
  • A database client to download the contents of a hacked site database
  • Network tools including a port scanner and the ability to bind a service to a port
  • A tool to brute force attack passwords on FTP and POP3 services.
  • A command line client to run arbitrary operating system commands
  • A utility to view server configuration info

By viewing the source code, we could find the name of the malware and the version. It is P.A.S. 3.1.0.

We googled it and found a website that makes this malware. You can find the site at this address: http://profexer.name/pas/download.php

PAS Website

You can enter a password that you will use to access your malware once it’s installed and then hit ‘download’ and a ZIP file downloads.

The ZIP contains a text file and the malware. The text file looks like this:

PAS malware text file

The website claims the malware is made in Ukraine and the date at the bottom has the Ukraine country code UA.

This malware is version 3.1.7 which is newer than the malware that the DHS indicator of compromise identifies. It is almost identical including it’s indentation:

PAS 3.1.7 malware header

And the footer:

PAS 3.1.7 malware footer

But PAS has evolved even further since 3.1.7. It is now version 4.1.1 which you can get from the same website:

PAS 4 Download

The 4.1.1b info.txt file:

PAS 4 info.txt

And the code has changed in 4.1.1 quite substantially. This is the header:

PAS4 header

The PAS malware is user friendly. It has an About page:

PAS About malware

They also have a helpful FAQ:

PAS malware FAQ

 

How does PAS infect WordPress websites?

This is a typical infection attempt for PAS 3.1.0 which is the DHS sample:

PAS 3.1.0 malware infection attempt

The above request is an attempt to install a plugin in the WordPress CMS through the normal file upload method. What surprised us is that this request had a full set of cookies that indicates that the user or bot doing this was signed in and this probably was an actual web browser.

It also includes the WordPress nonce which is a security feature, also indicating this is a user. Only about 25% of the attacks that we see include the WordPress nonce, which suggests that many of these attempts fail.

The vast majority of attacks we see that try to infect with PAS 3.1.0 use this kind of request. Here are a few theories:

  • WordPress website owners have malware installed on their workstations and that malware attempts to install PAS 3.1.0 on their WordPress websites.
  • This is CSRF, or cross site request forgery attack, that installs the malware. This is unlikely because the nonce is present in many requests. A nonce is a security feature that prevents CSRF attacks.
  • Users are voluntarily installing this on their own websites after downloading it from a malicious website thinking it is safe. Unlikely because the file that is uploaded is plain text PHP and it is clearly suspicious if you examine the file contents.
  • Attackers are compromising websites through some other means and then using the compromised credentials to manually sign in and install PAS 3.1.0 with a standard browser. These sign-ins could be partially or fully automated.

Malware Conclusions

DHS and DNI have released a joint statement that says:

This document provides technical details regarding the tools and infrastructure used by the Russian civilian and military intelligence Services (RIS) to compromise and exploit networks and endpoints associated with the U.S. election, as well as a range of U.S. Government, political, and private sector entities. The report contains specific indicators of compromise, including IP addresses and a PHP malware sample.

The PHP malware sample they have provided appears to be P.A.S. version 3.1.0 which is commonly available and the website that claims to have authored it says they are Ukrainian. It is also several versions behind the most current version of P.A.S which is 4.1.1b. One might reasonably expect Russian intelligence operatives to develop their own tools or at least use current malicious tools from outside sources.

Analysis of the IP addresses provided by DHS and DNI

DHS provided us with 876 IP addresses as part of the package of indicators of compromise. Lets look at where they are located. The chart below shows the distribution of IP addresses by country.

Distribution of IP addresses

As you can see they are globally distributed with most of them in the USA.

Lets look at who the top ISP’s are who own the IP addresses:

Hosting companies that own malicious IPs

There are several hosting companies in the mix including OVH SAS, Digital OceanLinode and Hetzner. These are hosting companies that provide low cost hosting to WordPress customers and customers who use other PHP applications. A common pattern that we see in the industry is that accounts at these hosts are compromised and those hacked sites are used to launch attacks around the web.

Out of the 876 IP addresses that DHS provided, 134 or about 15% are Tor exit nodes, based on a reverse DNS lookup that we did on each IP address. These are anonymous gateways that are used by anyone using the Tor anonymous browsing service.

Tor exit nodes

We examined our attack data to see which IP addresses in the DHS data are attacking our customer websites. We found a total of 385 active IP addresses during the last 60 days. These IP addresses have launched a total of 2,109,5492 complex attacks during that 60 day period that were blocked by the Wordfence firewall. We consider a complex attack to be an attack that tries to exploit a vulnerability to gain access to a target.

We also logged a total of 14,463,133 brute force attacks from these IP addresses during the same period.  A brute force attack is a login guessing attack.

The chart below shows the distribution of the number of attacks per IP address. It only takes into account complex attacks. As you can see, a small number of the IP addresses that DHS provided as IOC’s are responsible for most of the attacks on WordPress websites that we monitor.

Attack distribution from IPs

The following shows the list of the top 50 IP addresses in the DHS report sorted by the number of complex attacks we saw from each IP during the past 60 days.

screen-shot-2016-12-30-at-4-35-33-am

As you can see, many of the top attacking IP addresses are Tor exit nodes. There is also a relatively small number of IP addresses launching most of the attacks on websites we monitor.

Conclusion regarding IP address data

What we’re seeing in this IP data is a wide range of countries and hosting providers. 15% of the IP addresses are Tor exit nodes. These exit nodes are used by anyone who wants to be anonymous online, including malicious actors.

Overall Conclusion

The IP addresses that DHS provided may have been used for an attack by a state actor like Russia. But they don’t appear to provide any association with Russia. They are probably used by a wide range of other malicious actors, especially the 15% of IP addresses that are Tor exit nodes.

The malware sample is old, widely used and appears to be Ukrainian. It has no apparent relationship with Russian intelligence and it would be an indicator of compromise for any website.

You can find a public repository containing the data used in this report on github.

As always I welcome your comments. Please note that I will delete any political comments. Our goal in this report is to merely analyze the data DHS provided and share our findings.

Mark Maunder – Wordfence Founder/CEO

Special thanks to Rob McMahon and Dan Moen who provided valuable assistance with this research. 

The post US Govt Data Shows Russia Used Outdated Ukrainian PHP Malware appeared first on Wordfence.

Read More

WordPress Table Prefix: Changing It Does Nothing to Improve Security

There is an idea that was popularized a few years ago that if you change WordPress table prefix in your database, it helps protect your WordPress website from attackers.

Changing your WordPress table prefix is risky to implement and it does absolutely nothing to enhance your site security. In today’s post I’m going to explain what the original idea is behind this and why you should simply not do it.

Why change your WordPress table prefix?

WordPress Table PrefixThere is a certain kind of attack called a SQL injection attack where an attacker uses a vulnerability in an application, like a WordPress plugin, to gain access to your database. Using SQL injection, an attacker essentially gains the same level of access to your database that your own WordPress website has.

I’m vastly oversimplifying SQL injection for the sake of brevity. We go into more detail about SQL injection in our WordPress Security Learning Center if you’re interested.

The important concept to grasp here is that, once an attacker succeeds at gaining access to your database, they have access to everything that your WordPress site does. They can usually run any SQL command and can see the output. [Except in the case of blind SQL, but that’s beyond the scope of this post]

An idea became popular a few years ago that went something like this: If an attacker has access to your database via SQL injection, you can prevent them from accessing your data by renaming your tables to some unique prefix.

Once that idea was popular and generally accepted, several security products for WordPress started offering the ability to help you rename your database tables.

That was it. The idea was generally accepted and because security vendors were offering the feature, it was generally accepted as fact.

Why changing your WordPress database table prefix does nothing to improve security

WordPress table prefix burglarWhat if I told you that a great way to prevent burglaries is to turn off all the lights in your home? That way a burglar would be able to gain entry, but they would not be able to see where your stuff is and so they couldn’t steal it.

You’d tell me that the burglar would either bring a flashlight or turn on the lights themselves.

It’s exactly the same concept when it comes to renaming your WordPress database table prefix. Once an attacker can access your database using SQL injection, they are inside your home. If you rename your database tables using a unique prefix, you’ve turned out the lights in your home.

So what’s the first thing an attacker does? They do this:


SELECT DISTINCT SUBSTRING(`TABLE_NAME` FROM 1 FOR ( LENGTH(`TABLE_NAME`)-8 ) ) 
FROM information_schema.TABLES WHERE 
`TABLE_NAME` LIKE '%postmeta';

Let’s look at what the output of this query is:

WordPress Table Prefix

The above query simply asks the database what WordPress table prefix is being used for the postmeta table. It turns on the lights.

Any bot, attack script or manual attack, using a tool like sqlmap, will always run a query like the above before assuming any default table prefix.

Changing your WordPress table prefix for security reasons does not make a SQL injection attack “slightly harder” for attackers. They simply run the above query before assuming your tables have a default prefix.

Suggesting that this improves security is like assuming a thief won’t bring a flashlight to a burglary. Sticking with the burglary metaphor for a moment, the situation we’ve found ourselves in with WordPress plugins renaming the table prefix is like security vendors who sell you different ways to turn out the lights in your home to help keep you secure. It’s absurd.

Why is changing your WordPress database table prefix risky?

When you change your table prefix in WordPress you usually use a WordPress security plugin to do the job. Unfortunately the security plugin needs to execute as the change is taking place. That means that during execution, half your tables have one prefix, and the other half have another prefix. If execution stops for any reason you are left with a broken website that you need to restore from backups.

Any plugin that makes this change also needs to modify your wp-config.php file successfully. This file may not be writable under certain conditions which can cause the change to fail.

While preparing for this post, I actually tried to change the WordPress table prefix using a security plugin on one of my test servers. For some reason it changed the wp-config.php file but failed to change the database table names. I think the issue may have been that the database user did not have the correct permissions.

The result was that when I refreshed my admin page, I was confronted with the “Welcome” page that you see when you first install a fresh WordPress. My site had disappeared.

Changing the WordPress Database Table Prefix is ‘Security Theater’

Changing the WordPress table prefix is what we refer to in the industry as ‘security theater’. In other words, it is busy-work that makes you feel more secure but does nothing to make you more secure. It only adds risk and complexity.

We have another cool sounding phrase that describes this: ‘Security through obscurity’. What this means is that you’re trying to secure yourself by making things harder for an attacker to find. In the security industry this is widely accepted as a pointless exercise.

Things that do actually make you more secure against attacks are a WordPress Firewall, like the one included free with Wordfence. This actually blocks SQL injection attacks before an attacker can gain access to your database.

The Wordfence firewall includes rules to block SQL injection attacks. It even includes a sophisticated SQL parsing engine that understands SQL the same way a database does. When we see incoming SQL, we intelligently parse it to determine if the intent is malicious or not. If it’s a SQL injection attack, we block it. If we detect it’s a site user or administrator doing something safe like posting a blog post, we allow it through.

This site uses the Wordfence Firewall and while I was posting this blog post, which includes sample SQL, I wasn’t blocked. Wordfence is smart enough to know that I’m not doing anything bad. But if Wordfence sees a SQL injection attack, it will block it immediately.

I hope this has shed some light on a misunderstanding in the WordPress community that exists for legacy reasons. Please share this with the larger community to help us all focus on implementing real security measures that keep us all safe.

The post WordPress Table Prefix: Changing It Does Nothing to Improve Security appeared first on Wordfence.

Read More

Critical Vulnerability in PHPMailer. Affects WP Core.

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.

Don’t Panic

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 or anyone else panicking that your WordPress site will be exploited. This research is currently ongoing and we are making you aware of this issue early for two reasons:

  1. So that you can be ready to upgrade WordPress core and any other affected themes and plugins if you are a user, once a fix is released.
  2. So that, if you are a developer who has used a vulnerable version of PHPMailer, you can start patching your code and get a release out to your customers.

The Details

If you are unfamiliar with RCE vulnerabilities, they are a worst-case-scenario. All of the worst vulnerabilities in the history of WordPress have been remote code execution vulnerabilities. They allow an attacker to execute their own code on a victim website and thereby take control of the website.

We have performed a brief analysis on the affected code in PHPMailer. To exploit this vulnerability, it appears that an attacker would need to be able to control the sender email address.

A snippet of the vulnerable code in PHPMailer and the fixes is shown below.

Vulnerable code that was fixed in PHPMailer

Source: Github.

In the vulnerable version of PHPMailer, the sender email address is passed unescaped to a shell command. An attacker could include shell commands in the sender email that execute malicious code on a target machine or website.

What to do

We’re sending out this email as an early warning for our subscribers and customers. The WordPress core team are currently working on a fix that will be included in a WordPress core security release. There is also no word on timing but it may be as soon as within 24 hours.

Please update to the newest version of WordPress core as soon as it is released.

If you are using PHPMailer older than 5.2.18 in your own PHP applications, themes or plugins, please upgrade to PHPMailer 5.2.18 or newer immediately.

If you are a WordPress theme or plugin developer and have included your own copy of PHPMailer in your plugin or theme code, you need to update to PHPMailer 5.2.18 or newer immediately and release a fix to your customers.

More information and discussion

An issue in WP core was opened about 4 hours ago that included a patch to fix this issue. It updates WP core from using PHPMailer 5.2.14 to 5.2.19. This is just a proposed patch, not the final fix.

You can find the code changes on github showing the changes in PHPMailer to fix this issue. They make it fairly clear the issue is with the sender email address being sent to a shell command unsanitized.

A basic proof of concept exploit has also been posted to exploit-db which links to a more detailed demo of this exploit in action on github. The researcher has built their own web application which is vulnerable to this exploit, and then created an exploit for their own app. This is clearly not a real-world PoC, but it demonstrates the weakness in PHPMailer and paves the way for real-world exploits to emerge.

According to the post by the researcher who found this:

“The researcher also developed an Unauthenticated RCE exploit for a popular open-source application (deployed on the Internet on more than a million servers) as a PoC for real-world exploitation. It might be published after the vendor has fixed the vulnerabilities.”

The issue was posted to Hackaday yesterday and to The Hacker News earlier today.

It is being widely discussed on Twitter.

It is being discussed on WP Slack #forums and #core. [Login required]

Also being discussed on Hacker News.

It was posted to Reddit /r/netsec about 20 hours ago and is being discussed there.

We expect it to hit mainstream press tomorrow as everyone returns to work.

The post Critical Vulnerability in PHPMailer. Affects WP Core. appeared first on Wordfence.

Read More

2016 for Wordfence: A Break-Through Year

2016 is drawing to a close and has been a very busy year for us at Wordfence. In today’s post I’d like to share some of the major events for Wordfence in 2016 and some interesting data.

Our Awesome Customer Support Team

In 2016 our support team resolved 15,976 Premium support tickets, site cleanings and general inquiries.

Tickets resolved by month for Wordfence

Our average response time for Premium support requests was 3 hours and 25 minutes to get a first response to the customer. The average for the past 3 months was 2 hours 26 minutes and then the past month has been 1 hour and 59 minutes. It’s great to see our good response time get even better as the team works to improve our processes.

We also provide free community support in the WordPress.org forums. It’s difficult to extract date constrained statistics from those forums. But here are some stats from our more prolific team members showing how many topics they have each replied to so far on the WordPress forums:

  • Matt R: 2466 total replies
  • Tim C: 2,150 replies (Sorry Tim, Matt still holds the record!!)
  • Åsa R: 1,349 replies
  • Alaa S: 789 replies

That’s a total of 6,754 support responses so far for our free customers in addition to the premium support that our team provides in our ticketing system. We’re proud of our contribution to open source software with Wordfence and the contribution we make to the community. It’s an important part of our mission to secure WordPress.

The Wordfence Engineering Team

The Wordfence engineering team has been very busy this year. The chart below shows the projects we have been working on and the number of bugs and features we resolved for each project throughout 2016.

The large brown section is the core Wordfence plugin. As you can see we did a huge sprint for the Wordfence 6.1.1 release in April. Our engineering team was almost exclusively dedicated to 6.1.1 because it was such a large and ambitious project. I’m incredibly proud of how the team took big risks to improve our customer website security and delivered in a big way!

Once we completed 6.1.1, we kicked off several new projects that are running concurrently. Work on the core Wordfence plugin has continued and the engineering team has expanded their focus into other projects. Some of those initiatives are confidential which is why this chart does not include a legend. We will have a few big announcements to make in early to mid 2017.

Wordfence Engineering Chart

Wordfence Innovation in 2016

To date Wordfence has been downloaded over 22 Million times. We saw our product downloaded between 180,000 and 400,000 times each week in 2016.

Wordfence downloads

In 2016 we launched 28 new Wordfence releases, each with significant improvements to help keep our customers secure and make their lives easier.

The most significant release in the history of Wordfence was on 12th April, when we released wordfence 6.1.1 which included our new Web Application Firewall.  This was a game changer for our company and our customers. Wordfence had finally matured into a full featured firewall and malware scanner complete with real-time updates. Since the 6.1.1 release we have been continuously releasing scan and firewall updates in real-time to our customers via the Wordfence Threat Defense Feed.

Wordfence 6.1.1

On September 8th we released Wordfence 6.1.16 which integrated our malware scanner with the Wordfence firewall. This release introduced real-time scanning for requests that may contain malware.

On September 27th we released Wordfence 6.2.0 which was another big step forward. We had been quietly working with hosting providers to understand how we can improve compatibility across their systems and reduce operational load. Wordfence 6.2.0 increased the scan performance of Wordfence by 18 times on average. The more files a user has, the bigger the performance increase.

On October 11th we released Wordfence 6.2.1 which again improved the firewall by adding the ability to intelligently parse anything that looks like PHP code and determine if it is malicious or not. This further improved our ability to detect incoming malware via the firewall and block it.

Wordfence 6.2.4 was released on November 9th which further improved scan performance for sites that are very large with many files.

In addition to constantly improving Wordfence, we have been steadily growing the number of malware signatures in the Wordfence Threat Defense Feed. Today we have 1169 unique malware signatures in production and many of those detect multiple malware variants. Our free users have 1003 signatures available and our Premium customers have 166 recently added signatures available that were released to their sites in real-time during the past 30 days. We also have 570 scan signatures in beta which our team is testing and will be releasing during the coming weeks to continue to improve our malware detection capability.

The Wordfence Team in 2016

The wordfence team is now 23 people in locations that include Washington, Nebraska, Florida, Virginia, Pennsylvania, Colorado, Maine, Ohio, Tennessee in the USA and in Sweden and Greece internationally.

Our whole team at Wordfence works remotely. We use Slack for about 80% of our communication and VOIP chat and conference tools for the rest. We started using Slack in early 2015. The chart below shows how our communication has increased over the past 1.5 years as the team has grown and the number and intensity of our projects has increased.

Slack statistics Wordfence

 

It’s interesting to note the spike in April 2016. That was when we released Wordfence 6.1.1 which included the Wordfence Firewall. It was a time of intense product testing and communication among the team. We are currently involved in another all-consuming project which we will announce in 2017 and as you can see, communication is beginning to spike again in December. I expect January 2017 to be quite spectacular as the team ramps up.

And you…

The Wordfence Blog has also been very busy in 2016. In the past year, this blog has been visited by over 900,000 unique people. This year we received 2,190 comments from 1,414 people.

I’d like to thank you all very much for visiting us and participating in the conversation here throughout the year. The Wordfence team and I read all of your comments, we appreciate the positive feedback and we pay attention when you share an opinion or you share data with us.

Thank you for your support and encouragement in 2016!

Mark Maunder – Wordfence Founder/CEO.

Thanks to Dan Moen for help editing this post. 

The post 2016 for Wordfence: A Break-Through Year appeared first on Wordfence.

Read More

Who is Really Behind the Ukrainian Brute Force Attacks?

Last Friday we published a report showing a significant increase in Brute Force Attacks. We showed that most of the attacks are originating in Ukraine and we shared the most active IP addresses with you.

Top 8 Ukraine Attack IP's

I have chatted via Skype and email with a source in Kiev, Victor P, who sent me some additional info. The company that owns the malicious IP block is “SKS-Lugan”. They are based in Alchevs’k in eastern Ukraine. According to a business guide Victor sent me, they have 16 employees and their CEO is Lizenko Dmitro Igorovich.

The eastern part of Ukraine is currently occupied by Russia. The map below, dated December 18th (yesterday), is from the Ukrainian Ministry of Defense. It shows which territories within Eastern Ukraine are currently occupied by Russia.

Ukrainian Occupation Map Late December 2016

 

I’ve marked the location of Alchevs’k on the map with a red arrow. Victor is familiar with the reputation of the attacking IP block. He says that the company is being controlled by Russia and is being used to launch cyber attacks globally.

“Gabriele”, one of our readers, pointed out in the comments on our earlier post that the full IP block is 91.200.12.0/22. If you aren’t familiar with CIDR notation, that is an IP block that starts at 91.200.12.0 and ends at 91.200.15.255. It contains 1024 addresses (1022 usable addresses).

The network block is known for “Spammer & cybercriminal hosting”. The range of activities that are listed for this IP block are:

  • Botnet controller
  • Spam email leading to domains hosted on this block
  • Spammer hosting
  • Citadel botnet controller
  • Neurevt botnet controller
  • Smoke Loader botnet controller
  • Locky botnet controller
  • Canadian Pharmacy Botnet spam
  • Tinba bonet controller
  • Carding fraud site
  • Madness botnet controller
  • FindPOS botnet controller
  • Pony bonet controller
  • DDoS botnet controller
  • Forum/Comment spam source
  • Vawtrack botnet controller
  • Necurs botnet controller
  • Russian botnet drug spammer server
  • Andromeda botnet controller
  • Cutwail botnet controller
  • KINS botnet controller
  • Vawtrak botnet controller

Those are just some of the spam and botnet activities logged from this network. The list is long.

Russia has staged a military intervention in Ukraine that started in 2014. It wasn’t until December 2015 when Putin first admitted that Russian military intelligence officers were operating in the country.

In cyber security, attributing attacks to an individual or state is very difficult, sometimes impossible. Attackers on the Internet can route their traffic through as many servers in as many countries as they like before they reach their target.

The Russian intervention in Ukraine makes attribution of attacks even more complex. Using a Ukrainian Internet service provider gives Russia the ability to launch attacks globally with plausible deniability.

It makes sense that disputed areas like eastern Ukraine and Syria are a hotbed of malicious activity because they provide attackers with means, motive and opportunity. Occupying forces have the means to launch their attacks by using local ISP’s. They have several motives: They want to benefit from the attack itself and also discredit local businesses or government. And they have plenty of opportunity as these regions are usually occupied for years.

What to do about these attacks

Wordfence blocks these attacks by default. It will handle any brute force attacks and our firewall does a great job of blocking more sophisticated attacks. The free version of Wordfence receives our ‘community’ firewall and scan rules which are 30 days old. The Premium version of Wordfence receives real-time updates, so if we release a new rule for the firewall or malware scan, you receive it in real-time.

To combat these attacks, we recommend you simply install the free version of Wordfence if you haven’t already. Wordfence will lock down your site and protect your investment against these attacks.

Mark Maunder – Wordfence Founder/CEO.

Feedback: As always please share your thoughts in the comments below. I will be around to reply. If you would like to send a tip or data related to this story, you can email us at feedback@wordfence.com.

Thanks to Matt Rusnak and Kerry Boyte for their assistance editing this post. 

The post Who is Really Behind the Ukrainian Brute Force Attacks? appeared first on Wordfence.

Read More

5 Things to be Aware of When Buying WordPress Security

If you are new to WordPress or reevaluating your security strategy, you are overwhelmed by choice in today’s market. The reality is that there are only a handful of tools that truly protect your WordPress website from a hack and help you detect an incident. With all of the claims that vendors are making, it can be tough to choose the most effective product to protect your investment and your customer data.

To help you in your decision making, I’m going to call out 5 things in this post that you need to be aware of before you choose a security plugin, a cloud solution or something that runs in the hosting environment that your hosting provider is selling.

1. Not all security products include a firewall

Many of the best known security plugins for WordPress don’t actually include a firewall. To understand this, it’s important to understand what a firewall actually is. The firewall in Wordfence is known as a Web Application Firewall or ‘WAF’.

For a WAF to be effective, it needs to fulfill a few basic requirements:

  1. It needs to block a wide range of attacks based on it’s ability to recognize website requests as attacks. Types of attacks include SQL injection attacks, remote code execution, cross site scripting and cross site request forgery attacks.
  2. The WAF needs to have a rule-set that is continuously updated. These rules are used to recognize attacks and block them. They can’t be updated only when the software is upgraded. They need to be updated constantly via a ‘feed’.
  3. The WAF needs to analyze ALL requests, not just requests that hit a particular application. In other words, if you have installed a WordPress WAF, it must block requests that try to directly access a script in a WordPress subdirectory along with requests that hit WordPress itself.
  4. The WAF needs to be very high performance. It will be inspecting every request that hits your site and it’s very important it doesn’t slow your site down at all.

Wordfence fulfills all these requirements. It has a comprehensive rule-set that blocks a wide range of attacks and is continuously updated via our Threat Defense Feed. The Wordfence WAF inspects every request made to a PHP application on your website. Whether it’s a WordPress request or a direct attack on a script like Timthumb, Wordfence will see it and analyze it and block it if necessary. Wordfence is extremely high performance. We use core PHP functionality for our rule-set that executes very fast, we pre-filter rules and only execute what is relevant and our rule-set is highly optimized.

Many popular security plugins for WordPress don’t include a WAF, or firewall. They include features like brute-force protection, file change detection, backups, strong password enforcement and so called system ‘tweaks’. But they don’t include the most basic security component of them all: An effective web application firewall.

When purchasing a security product, make sure it actually includes a firewall.

2. Cloud firewalls can be bypassed and don’t have identity data

cloud-waf-diagramBecause cloud firewalls execute on remote servers out on the Internet, it’s possible for an attacker to go around them and attack your site directly. We’ve written about this in some detail.

Because cloud firewalls execute remotely, they don’t have access to your WordPress API and database. That means they don’t know basic things like: “Is a user signed into your website or not?” They don’t have this data so they can’t use it in their decision making about who to allow and who to block.

If you don’t even know whether a request is coming from a site administrator or an attacker, how can you provide effective protection? We’ve written about the cloud WAF user identity problem in some detail.

Cloud firewalls also use a rule-set that is generic. Their rules are designed for all websites. That means they don’t specialize in a specific platform. The result is that they can allow through some of the best known and most basic attacks on a platform like WordPress.

Wordfence Protecting the EndpointWordfence is designed specifically for WordPress, it knows and uses user identity to make it’s decisions and it’s not possible to go around the Wordfence web application firewall because it runs directly on your WordPress website.

 

3. Some malware scans don’t check very much

When choosing a malware scanner for WordPress, it’s important to choose one that does a deep through scan of your site. Malware authors have become very creative in how and where they hide malware once they’ve compromised your website. Without a deep scan, your site may be infected and you won’t be aware of it.

iThemes Security, the second most popular security plugin for WordPress, uses Sucuri Sitecheck to perform a malware scan. You have to pay for iThemes Pro to gain access to this feature, which currently costs $48 per year.

Once you’ve paid for iThemes security and have access to the malware scan feature, you can launch a scan. A Sucuri scan using iThemes Security on my test WordPress site only performed 22 page requests. All the checks are remote, so no source code is inspected.

After doing this scan, this is what my logfile looks like. Click for a larger image.

ithemes sucuri malware scan

As you can see, it didn’t do very much.

Below we show what a typical free Wordfence scan looks like (it’s in reverse chronological order). As you can see we analyze the source code of over 4,000 files on the same site and perform a host of other checks. Click the image for a larger version in a new tab.

screen-shot-2016-12-13-at-4-01-54-pm

When choosing a malware scanner, make sure you pick one that performs a comprehensive scan of your website and doesn’t just do a cursory check. Malware can be hard to find and well hidden. Wordfence performs a deep and comprehensive scan of your site every time it runs.

4. Malware scanning takes a team, forensic work and processes

Forensic WorkHave you wondered why our Wordfence site cleaning service is is so reasonably priced, even though you get your own Wordfence analyst working closely with you to fix your hacked site?

It’s because your hacked website is an amazing source of forensic data for us. We take the footprints that a hacker left behind and add that to our malware scan.

To provide an effective malware scan, you need to perform hands-on forensic analysis of the latest attacks as they happen. That’s what our site cleaning team does.

Then you need to take that attack data and run it through a process to turn it into threat intelligence and distribute it, in real-time to a great malware scanner. That is what our Threat Defense Feed is. The TDF describes our process of gathering, analyzing and distributing threat intelligence to the Wordfence malware scanner and firewall.

I’m not currently aware of a single WordPress specific malware scanner that combines a high performance scan engine with a team and process like Wordfence does.

5. Watch out for ‘automated‘ malware removal

Some companies offer an ‘automated’ fix if they detect malware on your website. When we first heard about this we viewed the concept with deep skepticism. If malware is detected on a website, it has been compromised. The definition of a ‘compromised’ site is that someone unauthorized has gained access to the site.

Incident response is a complex field. We have certified forensic investigators on our team who have developed our site cleaning process. To get an idea of how the a typical incident response process works, you can reference NIST publication 800-61 “Computer Security Incident Handling Guide” [PDF].

In general, forensic analysts will divide incident handling into three phases:

  1. Detection and Analysis: This includes analyzing attack vectors, documenting the incident, prioritization and notification.
  2. Containment, eradication and recovery: This includes evidence gathering, identifying what has been attacked and evidence gathering.
  3. Post incident activities: In this phase forensic data is analyzed, evidence is retained and the data is used to prevent future incidents.

There are several different approaches to incident response and you can visit OWASP to learn more about how they tackle the problem.

If a site is compromised, an automated fix would leave out many of these steps. For example, it would not be able to determine how an attacker gained access and so the site may be repeatedly hacked.

We currently recommend that you avoid products that claim an automated fix is possible for a compromised website. Instead we suggest that you use a security analyst trained in incident response to help fix your hacked website. One of our human analysts would be glad to assist you.

The post 5 Things to be Aware of When Buying WordPress Security appeared first on Wordfence.

Read More

Wordfence Blocks Username Harvesting via the New REST API in WP 4.7

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 hackers to find ways to exploit it.

WordPress REST API Threats

The new WordPress REST API allows anonymous access. One of the functions that it provides is that anyone can list the users on a WordPress website without registering or having an account.

This can be exploited by bots that are launching brute-force password guessing attacks on WordPress websites. They can use this API to list the usernames of anyone who has published a post on a WordPress site. The list of users displayed via this API almost always includes a user with admin level access.

To see this WP REST API function in action, simply visit a site with WordPress 4.7 installed and hit the URL: example.com/wp-json/wp/v2/users

This will list all users that have published a post. It includes that user’s userid, username, gravatar hash and website URL. We are seeing well known brand name websites that have now upgraded to WordPress 4.7, where we are able to enumerate all usernames who have published posts, simply by visiting the above URL.

Wordfence already includes protection that makes it more challenging for bots to discover your admin username. This morning’s release updates this feature to extend this protection to the new WordPress 4.7 REST API.

Fine granularity: Keeping the bad guys out and letting the good guys in

Instead of providing an option to disable the entire REST JSON API, which some security vendors have done, we recognize how powerful and useful this new application programming interface is. We expect it to be widely embraced and to significantly enhance the power of WordPress.

To mitigate this threat, we have targeted the specific functionality in the API that exposes usernames. If you enable the feature (described below) it will simply stop anonymous users from being able to retrieve a list of users and their usernames. We don’t disable or break any JSON API functionality. Authenticated users using the API will be able to list their own user information. Authenticated users with list_users permission will be able to list all users.

We have made the REST API team aware of the new protection we have added on WordPress Slack and have received some helpful input. We will continue working with them and other developers to ensure that Wordfence enhances the security of WordPress and the new REST API, while ensuring compatibility with all applications.

How to enable protection against user enumeration

Wordfence 6.2.8 was released this morning and includes protection against attackers enumerating usernames using the new WordPress 4.7 JSON API. This option is enabled by default. To verify that this option is enabled, or to modify the setting, you can find it on your Wordfence options page with the label:

“Prevent discovery of usernames through ‘/?author=N’ scans, the oEmbed API, and the WordPress REST API”

You can find that option under the “Login Security Options” heading on the Wordfence options page.

This option is available to all Wordfence users, both free and paid.

You can find the documentation for this option on docs.wordfence.com.

We’d like to hear from you

We’d like to hear from any WP developers who are using this API and have any questions. We aren’t aware of any applications currently that rely on making unauthenticated requests to WordPress 4.7 to get a list of users. If you’re aware of any plugins or other applications that rely on the anonymous enumeration of users, and that are affected by this change, please post in our comments and we will modify our documentation.

As always I’ll be around to answer any questions from the community in our comments.

Special thanks to our team and especially Ryan Britton and Matt Rusnak for working hard to develop and test this feature in time for a Monday morning release.

Mark Maunder – Wordfence Founder/CEO.

The post Wordfence Blocks Username Harvesting via the New REST API in WP 4.7 appeared first on Wordfence.

Read More
Page 1 of 1012345»...Last »