Online Services

eWorldLinx

Category: Security

  • The June 2017 WordPress Attack Report

    Today’s post is a continuation of the WordPress Attack Report series we’ve been publishing since December 2016. Previous months’ reports can be found here:

    This report contains the top 25 attacking IPs for the month of June and their details. It also includes charts of brute force and complex attack activity for the same period. We also include the top themes and plugins that were attacked, and which countries generated the most attacks for this period.

    The Top 25 Attacking IPs

    The next section is our standard explanation of how the table below works. If you are familiar with our attack reports, you can skip down to the table below this section, which contains the data for June along with some commentary.

    Brief Introduction (If You Are New to Viewing These Reports)

    In the table below, we’ve listed the most active attack IPs for June 2017. Note that the “Attacks” column is in millions, and is the total of all attacks that originated from each IP. Farther right in the table (you may have to scroll right) we break down the attacks into “brute force” attacks and “complex” attacks.

    Brute force attacks are login-guessing attacks. (You can learn more about how brute force attacks work in our Learning Center’s article about them.)  What we refer to as “complex attacks” are attacks that were blocked by a rule in the Wordfence firewall.

    We have also included the netblock owner, which is the organization (usually a company) that owns the block of IP addresses that the attack IP belongs to. You can Google the name of each owner for more information. A Google search for any of these IP addresses frequently shows reports of attacks.

    The hostname included is the PTR record (reverse DNS record) that the IP address owner created for the IP, so this is not reliable data, but we still include it for interest. For example, we have seen PTR records that claim an IP is a Tor exit node, when, based on traffic, it is clearly not.

    We also include the city and country, if available. To the far right of the report, we show the date in June when we started logging attacks and the date the attacks stopped.

    The Top Attacking IPs

    The total attacks from the top 25 attacking IPs decreased slightly from 144 million in May to 133 million in June.

    Brute force attacks made up 67% of total attacks for June, up from 72% in May. Complex attacks accounted for 33%.

    Ukraine had the most IPs on the top 25 list with 7, followed by the United States with 7.

    Brute Force Attacks on WordPress in June 2017

    In the chart below, we show the number of daily brute force attacks on the sites we monitor for the month of June.

     

    The average number of daily brute force attacks increased 36% from last month, a return to “normal volumes” after a relatively quiet May. As we discussed in our June 15th post, a home router based botnet resumed attacking mid-month. The peak day for the month was much higher, at over 41 million versus just over 30 million in May.

    Complex Attacks on WordPress in June 2017

    In the graph below, we show the daily complex attacks (attacks that attempt to exploit a security vulnerability) for June.

    Average daily attack volume for June was up 32% from May for the sites that Wordfence protects at 7.2 million.

    Attack volume was quite a bit higher in the second half of the month, peaking at over 11 million attacks in a single day.

    Attacks on Themes in June 2017

    The table below shows the total number of attacks on WordPress themes. We identify each theme using its slug, which is the directory where it is installed in WordPress.

    As usual, there was quite a bit of change in the rankings from last month. There were four new themes on the list: elegance, awake, infocus and dejavu. The large majority of the attacks on all of the themes are attempts to exploit a well known vulnerability in a php file they all shared that was publicly disclosed a few years ago. Almost 98% of these attacks originate from just two IP addresses: 194.28.115.252 and 194.28.115.228. Both are from the same ISP: SpeciaList S.R.L. in the Netherlands. The jump in attack volume is almost certainly due to the actions of a single attacker.

    Attacks on Plugins in June 2017

    The table below shows the total number of attacks on WordPress plugins. As with themes, we identify each plugin by its unique slug, which is the unique installation directory where the plugin is installed.

    The top 25 list for plugins also changed quite a bit. Five plugins in the top 25 this month weren’t on the list in May.

    We took a look at the plugin with the biggest jump in the ranking, dzs-zoomsounds, to see what is behind the increase. The attacks are all malicious file upload attempts, trying to exploit a vulnerability that was disclosed over two years ago. Over 99% of the attacks originate from the same Russian IP address: 194.28.115.252.

    Attacks by Country for June 2017

    The table below shows the top 25 countries from which attacks originated in the month of June on WordPress sites that we monitor.

    The top 3 countries remained stable, with the United States and Ukraine swapping places at 2 and 3. There was a lot of movement at the bottom of the list, primarily driven by the home router botnet resuming its attacks. You’ll notice that Algeria is back on the list, climbing 65 spots. It was Algeria’s rise in the rankings in our March report that led to our original discovery of the home router botnet.

    Conclusion

    That concludes our June 2017 WordPress attack report. We were disappointed to see attack volumes up in June after a quieter-than-normal May. Let’s hope that trend reverses itself in July.

    The post The June 2017 WordPress Attack Report appeared first on Wordfence.

  • The WPSetup Attack: New Campaign Targets Fresh WordPress Installs

    At Wordfence, we track millions of attacks from a wide variety of sources every day. From this data we create a list of the worst-of-the-worst attackers and add those to our IP blacklist to protect our Premium customers. We also carefully monitor the activity that those known bad IP addresses engage in.

    In May and June, we saw our worst-of-the-worst IPs start using a new kind of attack targeting fresh WordPress installations. We also had our first site cleaning customer that was hit by this attack.

    Attackers scan for the following URL:

    /wp-admin/setup-config.php

    This is the setup URL that new installations of WordPress use. If the attacker finds that URL and it contains a setup page, it indicates that someone has recently installed WordPress on their server but has not yet configured it. At this point, it is very easy for an attacker to take over not just the new WordPress website, but the entire hosting account and all other websites on that hosting account.

    The graph below shows the campaign we tracked and the number of scans per day for /wp-admin/setup-config.php that we saw from several known bad IPs:

    How the WPSetup Attack Works

    There are several ways you can install WordPress. You can simply unzip the ZIP archive into a directory on your hosting account, or many hosting providers provide a one-click install that does the same thing.

    At this stage, even though you have the base WordPress files installed, there is no configuration file yet, so it needs to be created. You used to have to do this manually, but new versions of WordPress guide you through creating this file using a web interface.

    If you unzip WordPress or use a one-click installer and don’t immediately complete the installation steps, an attacker who is scanning for fresh installs on your server can use your fresh install to take control of your website.

    Let’s walk through the steps to understand how the attacker takes control of your site once they have located your fresh WordPress installation. The first step is to select your language:

    Then you see an introductory message:

    And finally, you let WordPress know your database name, username, password and which server it lives on.

    If an attacker finds your fresh install, they can easily click through the first two steps and then enter their own database server information in this final step. Their database can be on their own server, and it doesn’t have to contain any data – it can simply be an empty database. They just need to get a working WordPress installation running on your site that they have admin access to.

    Once this step is complete, WordPress confirms that it can communicate with the database – in this case, the attacker’s database:

    Once the attacker clicks “Run the install,” they are prompted to enter information to create the first admin-level account.

    They enter their own account information, click the Install button and receive a confirmation that WordPress has been installed and the admin account has been created.

    The attacker then retypes the admin credentials they created in the setup process…

    … and is signed into a fresh WordPress install on your server using their own database.

    How the WPSetup Attack Gets Full Control of Your Hosting Account

    Once an attacker has admin access to a WordPress website running on your hosting account, they can execute any PHP code they want in your hosting account. There are several ways they can do this.

    Executing PHP Using the Theme or Plugin Editor

    WordPress gives you the ability to edit the code of themes and plugins within the administrative interface. To execute their own code, an attacker simply launches the theme or plugin editor and inserts their own PHP code. The next time a page is refreshed, their code will execute.

    Executing PHP Using a Custom Plugin

    Once an attacker has admin access to a WordPress site, they can upload any plugin with any PHP code, including their own custom plugin. To execute their code, they spend a few minutes creating a basic WordPress plugin and then upload it to the site and activate it.

    What an Attacker Does Once They Can Execute PHP Code

    Once an attacker can execute code on your site, they can perform a variety of malicious actions. One of the most common actions they will take is to install a malicious shell in a directory in your hosting account. At that point they can access all files and websites on that account. They can also access any databases that any WordPress installation has access to, and may be able to access other application data.

    How to Protect Yourself Against the WPSetup Attack

    This attack is gaining popularity. To avoid falling victim, we have provided two procedures you can use below:

    Procedure 1: The Safe Way to Install WordPress

    Before you install a fresh WordPress installation, create a .htaccess file in the base of your web directory containing the following:

    order deny,allow
deny from all
allow from

    Replace the ‘’ with your own IP address. You can find this out by visiting a site like whatsmyip.org.

    This rule ensures that only you can access your website while you are installing WordPress. This will prevent anyone else from racing in, completing your installation and taking control of your hosting account by uploading malicious code.

    Once complete, you can remove the .htaccess rule and allow the rest of the world to access your website.

    Procedure 2: The Risky Way to Install WordPress

    This procedure is risky because, if an attacker is fast enough, they can still take control of your site. We don’t recommend this, but include it for completeness.

    Instead of creating the .htaccess rule above, you can use the standard WordPress installation method. To reduce the risk of being attacked, you need to shorten the time between installing the WordPress files and completing installation as much as possible.

    1. Install your WordPress files by unzipping them or doing a one-click install.
    2. Access your site immediately and complete the installation steps as quickly (though accurately) as you can.
    3. Once your site is up and running, an attacker can no longer run the installation and your site is no longer vulnerable.

    Recommendations for Server Administrators and Hosting Providers

    If you operate a server or a network of servers that provides WordPress hosting to customers, we recommend the following to mitigate this attack:

    Scan your hosting accounts for WordPress installations that do not have a wp-config.php. These may be fresh installations that have not yet completed setup. If navigating to the base URL of the site redirects you to /wp-admin/setup-config.php then you have confirmation that setup is incomplete. We suggest you alert your customer they should either complete setup or remove the files.

    If you have an IDS (intrusion detection system), you should consider monitoring traffic from your web servers to the open Internet for any MySQL traffic. This may indicate an attacker has configured a WordPress site on your network using their own database on the Internet.

    If you have any other mechanisms in place to monitor or prevent connections from your web servers to arbitrary databases on the open Internet, we recommend you use those to mitigate this attack.

    Final Advice and Your Thoughts

    I recommend that you take the additional step of auditing your own hosting account to make sure you have not accidentally left any unconfigured WordPress installations lying around. If you don’t want to do this yourself, consider our WordPress Site Audit service, which provides a comprehensive site security audit and will include a check for incomplete installations.

    As always, I welcome your feedback in the comments below. If you have additional ideas to help mitigate this attack or to help WordPress improve the setup process to avoid this attack, I’d love to hear them.

    ~Mark Maunder – Wordfence Founder/CEO

    PS: Please share this with the WordPress community to create awareness of the risks of unconfigured WordPress installations.

    The post The WPSetup Attack: New Campaign Targets Fresh WordPress Installs appeared first on Wordfence.

  • NGINX and PHP Malware Used in Petya/Nyetya Ransomware Attack

    Author’s note: This is a technical blog post which I’m hoping server administrators and web hosting providers will find helpful. It also includes malware history and video footage which I hope you enjoy. ~Mark Maunder

    Cisco’s Talos security group published an excellent blog post yesterday describing the recent ransomware campaign that goes by various names, including Petya, NotPetya and Nyetya. For clarity, I’m going to call it Nyetya from here on in.

    The Talos team’s post provides a very clear account of how the initial ransomware infections started. In the account, they describe how the attackers reconfigured an NGINX web server to reverse proxy requests to a compromised server at a hosting provider. The Talos team also discovered a well-known malware variant on the compromised web server. This immediately got our attention because, of course, PHP malware and attack vectors are what we think about all day long at Wordfence.

    In this post, I’m going to try to provide a clear picture of how the web components in the attack were used and abused by attackers. At the end of the post I’ll discuss what hosting providers and site admins can learn from this attack.

    How and Why the Attacker Used NGINX Reverse Proxying to Control Infected Machines

    M.E.Doc is a company in Ukraine that makes accounting software. They have many clients, and they distribute their software directly to their customers. Around April this year, their network was compromised because an attacker managed to acquire stolen credentials belonging to an administrator. Using these credentials, the attacker was able to log in and start modifying server configurations and software.

    The attacker modified the nginx.conf config file on an M.E.Doc update server to reverse proxy requests to a server hosted at OVH. The server was being used by a hosting reseller called THCServers.com. This server had been compromised by the attacker prior to launching the attack on M.E.Doc.

    The attacker then modified the M.E.Doc accounting software to include their own malicious code. Unaware of the infection, M.E.Doc then distributed the compromised software to its clients as usual. Once installed on a workstation, the modified software contacted the compromised M.E.Doc NGINX server every two minutes to fetch commands the attacker wanted to run.

    That request to the M.E.Doc NGINX server for commands was reverse proxied through to the compromised OVH command and control server the attacker controlled. When the attacker wanted to send commands to infected workstations, they simply set up a new command on the compromised OVH server which the workstations then dutifully fetched via the compromised NGINX server.

    To summarize:

    • The attacker modified the M.E.Doc accounting software to fetch commands from a hacked M.E.Doc update server.
    • That software was distributed to clients.
    • The hacked M.E.Doc NGINX server proxied those requests for commands to a hacked OVH server.
    • Attacker sent commands back to the hacked NGINX server, which were forwarded to the compromised workstations running the M.E.Doc accounting package.

    The following diagram illustrates the configuration the attacker created.

    This Is Smart Because It Is Evasive

    Many network administrators have intrusion detection systems on their networks. One of the intrusion methods those IDS systems look for is communication from malware to a command and control (C&C) server. The IDS systems have a database of indicators of compromise, or IOCs. Those IOCs include IP addresses of known C&C servers.

    If the attacker in this case had communicated directly from the hacked M.E.Doc software to their C&C server, a network IDS would have detected it, then would have blocked the request and alerted the network administrator. Instead, the network administrators saw M.E.Doc software communicating with an M.E.Doc update server as expected, and assumed everything was okay.

    How the Attacker Distributed Ransomware

    Once the attacker controlled a large enough number of machines using the above technique, they simply ran a command that caused the controlled machines to fetch ransomware and install it. It was that simple. The rest is the story of the Petya/Nyetya/NotPetya ransomeware infection you’ve read about in the news recently.

    The PHP Malware Used In This Attack Has a Colorful History

    The Cisco Talos team also found PHP malware on the compromised NGINX machine with the following path: http://www.me-doc[.]com[.]ua/TESTUpdate/medoc_online.php [Square parentheses included for safety.]

    We managed to get a sample of the malware from intelligence-sharing partners, along with the password to decrypt it. Surprise, surprise: the malware is our old friend “PAS.” Last year in December, we wrote a detailed analysis of the PHP malware used in the US election hack. The malware was released by the U.S. Department of Homeland Security as part of a set of indicators of compromise related to the election hack. We analyzed the malware back then, and found that it is well-known, widely used, freely available and is known as PAS.

    We tracked down the site that provides the malware. At the time it was available from: http://profexer.[name]/pas/download.php

    That site is now offline, and for good reason. Someone posted a link to the DHS report and our blog post to the forums at rdot.org where the author who goes by profexer hangs out. When he discovered his web shell and website had been linked to the election hack, he presumably got nervous and took his site offline. It has been offline since then.

    The malware that the Cisco Talos team found in the Nyetya ransomware attack is a version of PAS. Once you access the malware via a web interface and enter the password to decrypt it, this is what it looks like:

    The Talos team don’t seem to have data showing how the PAS web shell was used in the attack. My guess is that it was just used as a convenience by the attacker to provide them with a graphical interface in a browser rather than having to use SSH and the command line.

    What is interesting is that accessing this malware would have been “noisy.” It would have left a trail in the web server access logs, and if it had been accessed via HTTP and not HTTPS, it may have triggered alarms. SSH would have looked less suspicious because the only data would have been the source and target IP and the connect and disconnect. Using a web shell creates a log entry for every command run. This suggests a lack of sophistication or perhaps simply a lack of care on the attackers’ part.

    Once we received this sample, we checked our own attack data to determine if this exact variant of PAS had been used to target our own customer sites. It has not; however, we did find several instances where other PAS variants had targeted customer sites. In all these cases, Wordfence successfully blocked the attacks. We’ve since confirmed that Wordfence is also blocking this specific sample.

    Takeaways for Web Hosting Providers and Server Admins

    As I mentioned at the start of this post, the hackers in this attack were able to compromise the M.E.Doc network using stolen credentials. If you are a hosting provider or server admin, consider using two-factor authentication for any server access, including SSH. Assuming the attacker did not have access to the credential owner’s other devices, two-factor authentication would have stopped this attack, or at least made it significantly harder for the attacker to gain access.

    Better configuration management might have helped alert a system administrator to a change in an nginx.conf file. This might have also caught the malicious change in the M.E.Doc software when the file hashes changed.

    If M.E.Doc had had an internal IDS configured to monitor the default gateway, they might have caught the traffic from the compromised NGINX server being reverse proxied to a compromised OVH server.

    The M.E.Doc servers had reportedly not been updated since 2013. So it goes without saying: bring all your servers up to the latest patch levels, and actively maintain all other software.

    The Ukraine National Police posted the video below, showing them raiding the M.E.Doc servers. Notice the “creative” server cooling tech being used at around 1:00 in the video.

    As always I’ll be around to reply to any questions or comments. Stay safe out there, keep your credentials secure, and keep those servers up to date.

    ~Mark Maunder

    The post NGINX and PHP Malware Used in Petya/Nyetya Ransomware Attack appeared first on Wordfence.

  • Vulnerability Roundup: 3 Vulnerable WP Plugins and Update Your Joomla

    It’s been a tough week for the WP Statistics plugin. Last Friday, Sucuri (now owned by GoDaddy) discovered a SQL injection vulnerability in the WP Statistics plugin version 12.0.7 and older. To exploit the vulnerability, an attacker needs to register an account (or use a compromised account) with subscriber-level access. They can then exploit a weakness in a WP Statistics shortcode to launch a SQL injection attack. This allows them to, for example, create an admin-level user and sign in to your website as an admin.

    Then, 2 days ago Ryan Dewhurst discovered a cross site scripting vulnerability in the same plugin, which was fixed within a few hours of discovery.

    Over 300,000 websites use WP Statistics. If you use the plugin, you should immediately update to version 12.0.9 which fixes both of these vulnerabilities.

    Wordfence includes built-in protection against SQL injection attacks and cross site scripting (XSS) attacks. As a precautionary measure, we’ve released an additional rule to our Wordfence Premium customers in real-time to protect them against the specific SQL injection attack that targets this plugin.

    Other WordPress Vulnerabilities You Should Be Aware Of

    The All-in-One WP Migration plugin for WordPress reportedly suffered from a cross site scripting vulnerability which was fixed about 6 weeks ago. Wordfence free and Premium has built-in XSS protection, as mentioned above, so even if you were running the vulnerable plugin, you would have been safe. Nevertheless, if you haven’t already, we recommend you update to 6.51, the newest version of All-in-One WP Migration.

    A few weeks ago, a reflected cross site scripting vulnerability was discovered in the WordPress Download Manager plugin versions 2.9.51 and older. We suggest you update to 2.9.53, which is the newest version of this plugin. Wordfence also protects against this exploit (free and Premium).

    Don’t Forget to Update Your Joomla Installations

    Joomla released a security update 48 hours ago which fixes three vulnerabilities. The new release is Joomla 3.7.3 and includes fixes for two XSS vulnerabilities and an information disclosure vulnerability. If you run Joomla on your website, you can visit https://www.gravityscan.com/ to run a quick scan on your Joomla site and find out if you are vulnerable and need to take action. Details on the release can be found on Joomla.org and we also mentioned this update on the Gravityscan blog.

    That’s all for today’s updates. As always, I’ll be around to reply to your comments if needed.

    The post Vulnerability Roundup: 3 Vulnerable WP Plugins and Update Your Joomla appeared first on Wordfence.