In the world of data security there are many different types of encryption, but arguably the two most common are AES and PGP. With so many three-letter acronyms in the technical landscape, it’s easy to get lost in data security conversations. So let’s catch up!
First, we’ll define both AES and PGP, and then we’ll look at how they compare to each other.
AES encryption
AES stands for Advanced Encryption Standard. It is the dreamchild of two cryptographers’ proposal of a symmetric key encryption algorithm based on the Rijndael cipher. This algorithm was developed when the National Institute of Standards and Technology (NIST) sent the call out to the cryptographic community to develop a new standard. NIST spent five years evaluating 15 competing designs for the AES project. In 2001, NIST announced the cipher developed by the two Belgians, Joan Daemen and Vincent Rijmen, as the adopted standard (known as FIPS-197) for electronic data encryption.
AES is a symmetric key encryption algorithm, which essentially means that the same key is used to encrypt and decrypt the data. A computer program takes clear text and processes it through an encryption key and returns ciphertext. If the data needs to be decrypted, the program processes it again with the same key and is able to reproduce the clear text. This method required less computational resources for the program to complete its cipher process, which means lower performance impact. AES is a good method to protect sensitive data stored in large databases.
That said, AES will not always be your go-to for encrypting data.
When sharing sensitive information with trading partners or transferring information across networks, using AES would leave your data vulnerable because you would need to share your encryption key with your trading partners. This means that while they would be able to decrypt the information you sent them, they could also decrypt anything else encrypted using that same key.
And if the key itself were compromised, then anyone in its possession could decrypt your data.
PGP encryption
The answer to your above data sharing security problem is found in PGP encryption. This is because PGP uses both symmetric and asymmetric keys to encrypt data being transferred across networks.
PGP stands for Pretty Good Privacy. Which is ironic because it’s actually much better than just “pretty good.”
PGP was developed by the American computer scientist Phil Zimmerman, who made it available for non-commercial use at no charge in 1991. To encrypt data, PGP generates a symmetric key to encrypt data which is protected by the asymmetric key.
Asymmetric encryption uses two different keys for the encryption and decryption processes of sensitive information. Both keys are derived from one another and created at the same time. This key pair is divided and referred to as a public key and a private key. Data is only encrypted with a public key, and thus, can only be decrypted with its matching private key.
PGP is just as strong as that of AES, but it adds an additional layer of security to prevent anyone who only has the public key from being able to decrypt data. Another benefit of asymmetric encryption is that it allows for authentication. After you have exchanged public keys with your trading partners, the private keys can be used to digitally sign the encrypted content, allowing the decryptor to verify the authenticity of the sender.
PGP requires more computational resources, which is why it is usually not recommended for encrypting data in large databases where information needs to be accessed frequently, and each record that you access needs to be ran through a cryptographic process.
AES or PGP: Which should I use?
When you are considering which encryption to use for your sensitive information, choose whichever will suit your needs best:
AES is fast and works best in closed systems and large databases
PGP should be used when sharing information across an open network, but it can be slower and works better for individual files.
One thing that’s become abundantly clear in the internet age is that preventing unauthorized people from gaining access to the data stored in web-enabled computer systems is extremely difficult. All it takes is for a worker to click on the wrong link in an email, or respond unwarily to a seemingly legitimate request for information, and an intruder could gain complete access to all your data. In today’s regulatory and public relations environments, that kind of breach can be catastrophic.
But what if you could be assured that even if an attacker got access to your information, they couldn’t use it? That’s the role of data encryption.
How encryption works
The basic idea of encryption is to convert data into a form in which the original meaning is masked, and only those who are properly authorized can decipher it. This is done by scrambling the information using mathematical functions based on a number called a key. An inverse process, using the same or a different key, is used to unscramble (or decrypt) the information. If the same key is used for both encryption and decryption, the process is said to be symmetric. If different keys are used the process is defined as asymmetric.
Two of the most widely used encryption algorithms today are AES and RSA. Both are highly effective and secure, but they are typically used in different ways. Let’s take a look at how they compare.
AES encryption
AES (Advanced Encryption Standard) has become the encryption algorithm of choice for governments, financial institutions, and security-conscious enterprises around the world. The U.S. National Security Agency (NSC) uses it to protect the country’s “top secret” information.
The AES algorithm successively applies a series of mathematical transformations to each 128-bit block of data. Because the computational requirements of this approach are low, AES can be used with consumer computing devices such as laptops and smartphones, as well as for quickly encrypting large amounts of data. For example, the IBM z14 mainframe series uses AES to enable pervasive encryption in which all the data in the entire system, whether at rest or in transit, is encrypted.
AES is a symmetric algorithm which uses the same 128, 192, or 256 bit key for both encryption and decryption (the security of an AES system increases exponentially with key length). With even a 128-bit key, the task of cracking AES by checking each of the 2128 possible key values (a “brute force” attack) is so computationally intensive that even the fastest supercomputer would require, on average, more than 100 trillion years to do it. In fact, AES has never been cracked, and based on current technological trends, is expected to remain secure for years to come.
RSA encryption
RSA is named for the MIT scientists (Rivest, Shamir, and Adleman) who first described it in 1977. It is an asymmetric algorithm that uses a publicly known key for encryption, but requires a different key, known only to the intended recipient, for decryption. In this system, appropriately called public key cryptography (PKC), the public key is the product of multiplying two huge prime numbers together. Only that product, 1024, 2048, or 4096 bits in length, is made public. But RSA decryption requires knowledge of the two prime factors of that product. Because there is no known method of calculating the prime factors of such large numbers, only the creator of the public key can also generate the private key required for decryption.
RSA is more computationally intensive than AES, and much slower. It’s normally used to encrypt only small amounts of data.
How AES and RSA work together
A major issue with AES is that, as a symmetric algorithm, it requires that both the encryptor and the decryptor use the same key. This gives rise to a crucial key management issue – how can that all-important secret key be distributed to perhaps hundreds of recipients around the world without running a huge risk of it being carelessly or deliberately compromised somewhere along the way? The answer is to combine the strengths of AES and RSA encryption.
In many modern communication environments, including the internet, the bulk of the data exchanged is encrypted by the speedy AES algorithm. To get the secret key required to decrypt that data, authorized recipients publish a public key while retaining an associated private key that only they know. The sender then uses that public key and RSA to encrypt and transmit to each recipient their own secret AES key, which can be used to decrypt the data.
Every so often, we encounter someone still using antiquated DES for encryption. If your organization hasn’t switched to the Advanced Encryption Standard (AES), it’s time for an upgrade. To better understand why: let’s compare DES and AES encryption:
Data Encryption Standard (DES)
What is DES encryption?
DES is a symmetric block cipher (shared secret key), with a key length of 56-bits. Published as the Federal Information Processing Standards (FIPS) 46 standard in 1977, DES was officially withdrawn in 2005.
The federal government originally developed DES encryption over 35 years ago to provide cryptographic security for all government communications. The idea was to ensure government systems all used the same, secure standard to facilitate interconnectivity.
Why DES is no longer effective
To show that the DES was inadequate and should not be used in important systems anymore, a series of challenges were sponsored to see how long it would take to decrypt a message. Two organizations played key roles in breaking DES: distributed.net and the Electronic Frontier Foundation (EFF).
The DES I contest (1997) took 84 days to break the encrypted message using a brute force attack.
In 1998, there were two DES II challenges issued. The first challenge took just over a month and the decrypted text was “The unknown message is: Many hands make light work”. The second challenge took less than three days, with the plaintext message “It’s time for those 128-, 192-, and 256-bit keys”.
The final DES III challenge in early 1999 only took 22 hours and 15 minutes. Electronic Frontier Foundation’s Deep Crack computer (built for less than $250,000) and distributed.net’s computing network found the 56-bit DES key, deciphered the message, and they (EFF & distributed.net) won the contest. The decrypted message read “See you in Rome (Second AES Candidate Conference, March 22-23, 1999)”, and was found after checking about 30 percent of the key space – finally proving that DES belonged to the past.
Even Triple DES is not enough protection
Triple DES (3DES) – also known as Triple Data Encryption Algorithm (TDEA) – is a way of using DES encryption three times. But even Triple DES was proven ineffective against brute force attacks (in addition to slowing down the process substantially).
According to draft guidance published by NIST on July 19, 2018, TDEA/3DES is officially being retired. The guidelines propose that Triple DES be deprecated for all new applications and disallowed after 2023.
Advanced Encryption Standard (AES)
What is AES encryption?
Published as a FIPS 197 standard in 2001. AES data encryption is a more mathematically efficient and elegant cryptographic algorithm, but its main strength rests in the option for various key lengths. AES allows you to choose a 128-bit, 192-bit or 256-bit key, making it exponentially stronger than the 56-bit key of DES.
In terms of structure, DES uses the Feistel network which divides the block into two halves before going through the encryption steps. AES on the other hand, uses permutation-substitution, which involves a series of substitution and permutation steps to create the encrypted block. The original DES designers made a great contribution to data security, but one could say that the aggregate effort of cryptographers for the AES algorithm has been far greater.
One of the original requirements from the National Institute of Standards and Technology (NIST) for the DES replacement algorithm was that it had to be efficient both in software and hardware implementations. (DES was originally practical only in hardware implementations.) Java and C reference implementations were used to do performance analysis of the algorithms. AES was chosen through an open competition with 15 candidates from as many research teams around the world, and the total amount of resources allocated to that process was tremendous.
Finally, in October 2000, a NIST press release announced the selection of Rijndael as the proposed Advanced Encryption Standard (AES).
What are the differences between DES and AES encryption?
We believe that WISPs serve a crucial role in these difficult times by providing Internet connectivity to all our communities. Our goal with UNMS Cloud and CRM is to empower WISPs with world-class tools and services so that they can focus on connecting the world.
That’s why we are proud to introduce the Ubiquiti Payment Gateway.
Easy and Affordable Payment Processing
We know that fees can add up. That’s why Ubiquiti Payment Gateway is offering an industry-leading processing fee of 1.9%+30c per transaction for the first year.
Better yet, the UPG is simple to use! No need to set up accounts with other payment gateways or use a separate site to manage your subscriptions – simply activate the UPG with a few clicks, go through our quick onboarding process, and you will be using the UPG in no time.
If you are currently using other payment options for your subscriptions, you can easily switch to the UPG from the billing settings. We will continue to support other payment options, if you prefer to keep your existing payment processors.
For now, Ubiquiti Payment Gateway is only available in the United States, but we are working to bring it to other countries. Stay tuned.
Automatic Payments
The UPG isn’t the only thing we’ve been working on. We know that managing monthly payments can be time-consuming. That’s why we have built autopayments into the latest release of CRM. You can activate it in the billing settings:
Autopayments can be set to trigger at invoice creation date or at the due date. No more need to keep track of due dates!
An IoT device is simply any physical device with a defined purpose that has an operating system and can communicate through the internet with other things. Projections show that by 2021, about 25 billion IoT devices will be in operation, and 75 billion by the year 2025.
The support of so many connected devices used to be impossible. Now, advances in technology such as IPv6—the communications protocol that provides an identification and location system for computers on networks and routes traffic across the Internet—and 5G is enabling the IoT revolution.
Benefits of IoT
The benefits of IoT span across all industries, including agriculture and healthcare, but personal lives are enhanced by IoT as well. For example, IoT thermostats monitor and control temperature, which is both convenient and cost saving. Smart watches and Fitbits monitor health stats such as pulse and steps, going so far as to send this information to a doctor or sounding an alert if a risk is detected. Smart cities, homes, and cars are other large-scale examples of IoT. While the ultimate realization of these technologies is a long way off and involves the use of imagination, advancements in IoT aren’t slowing down.
In fact, wearables are a perfect example of this. What was once a clunky step-tracking device is now a fashion statement that serves multiple purposes. In addition, designers and engineers are playing with fabrics that can be interwoven with IoT components so a sport shoe can measure speed, heartbeat, and sweat output or a jacket can charge phones.
Cyber Security With Wearables
However, wearables are prone to cyber attacks. While not a wearable but similar, a connected pacemaker was compromised in 2018, which opened the eyes to the industry of the associated risks that come along with IoT devices. As Dr. Antoniou explains, “The pacemaker was compromised through a remote execution of the code into the person who was having the pacemaker.”
Manufacturers of connected wearables must practice their due diligence to ensure that the security of devices is done correctly. Dr Antoniou emphasizes that the onus lays on the manufacturer.
Smart Cities and IoT
When people think of smart cities, they often envision traffic signals that change according to the current traffic pattern, tickets handed out automatically after cameras catch illegal incidents, or tolls automatically deducted from checking accounts when a sensor deems it appropriate. Smart cities are so much more than that, however.
Dr. Antoniou explains that a smart city exists as an ecosystem of those sensor components plus the services the city is providing. That includes public lighting, smart roads and parks, and free Wi-Fi across the city. Services include DMV renewal and efficiency measures that help keep costs and resource draining low through the use of a connected device or app.
Enterprise IoT
Enterprise IoT, also called Industry 4.0 consists of IoT devices that are designed to operate within a business to drive efficiency, effectiveness, and cost savings. Examples include voiceover IP phones, smart lighting within the building, and smart TVs and vending machines located in an enterprise building. With these tools, internet connection enables TVs with internet access and vending machines can take debit cards. Security features like cameras and intrusion detection also fall into the realm of Enterprise IoT.
There is some concern that Industry 4.0 will eliminate jobs, but Dr. Antoniou believes the contrary. “I think we will see some reduction in certain jobs, but then we will see more demand in other jobs. As we know, cyber security is a very hot field nowadays, and if you go to the Department of Labor, you can see millions of openings especially in cyber security.” He goes on to explain that what IT administration and project management jobs are lost to IoT, cyber security jobs will fill—and then some. He also believes any collateral damage will be worth one other key benefit: sustainability.
“Sustainability is a big, big issue and a trending around the globe. So these devices, they will be helping us to accomplish [the things that make] a better planet: reduce waste [and] make more effective use of resources and consumption.”
On-Prem IoT Security
Many at-home IoT devices run on Wi-Fi connected to home modems. Dr. Antoniou encourages everyone who purchases a new IoT device to always read the manufacturer instructions in order to understand what kind of security parameters and configurations need to be put in place for that device. He also talks about Rule Zero, or his firewall rule. “I explicitly deny everything inbound to my home… That would protect your IoT, but also your other devices that are connected to your home network.”
Dr. Antoniou stresses the fact that IoT technology is still in its infancy. There are a lot of security and connectivity kinks to be worked out. Too many manufacturers are rolling out new, snazzy devices without actively imagining all the future security risks the device may enable. Cyber security needs to be an active part of the manufacturing supply chain.
Digital Identities
Finally, each device must have its own digital identity, or an identity that the device can assume for the entirety of its life. “So the digital identities on the IoTs, it is similar to what we call the identity access management, and it's important to have them. And today, we don't have a centralized digital identity management for IoTs.” Dr. Antoniou is an expert in the future of digital identity evolution: “if you get that digital ID and marry it with a microchip that is embedded to this device and it creates a strong encryption algorithm and somehow creates a digital ID in a centralized identity and access management database that is utilizing blockchain for verification, authentication, and authorization, that device now has a digital ID. It has a body of existence.”
Humans are defined with a social security number which enable transactions like home loans or tax payments. Digital identities for IoT devices identify them within their ecosystem. From there, authorization is granted only to the IDs of the devices we want active on our home or enterprise network. This system is not currently in place. For example, a rogue employee could potentially go to work, pair their smart witch with a Bluetooth device, piggyback into the work network, and steal data. If that smart watch had a digital ID, the network would know instantly that it doesn’t belong.
Currently, Dr. Antoniou explains that the best defense to IoT threats is enterprise education and policy. By running a risk analysis, companies start to think about connectivity as a whole. From there, they can create policies and train employees on those policies.
When asked about current IoT regulations, Dr. Antoniou exhaustedly explains that there aren’t any. Some countries are farther ahead than others, however, and most countries are working on them. Also, there are commonly-accepted preliminary guidelines. “NIST the National Institute of Standards and Technology, run by United States government, has some preliminary frameworks for IoT, but it has not been come to a fruition as a standard yet.”
VirusTotal, the famous multi-antivirus scanning service owned by Google, recently announced new threat detection capabilities it added with the help of an Israeli cybersecurity firm.
VirusTotal provides a free online service that analyzes suspicious files and URLs to detect malware and automatically shares them with the security community. With the onslaught of new malware types and samples, researchers rely on the rapid discovery and sharing provided by VirusTotal to keep their companies safe from attacks.
VirusTotal relies on a continuous stream of new malware discoveries to protect its members from significant damage.
Cynet, the creator of the autonomous breach protection platform, has now integrated its Cynet Detection Engine into VirusTotal.
The benefits of this partnership are twofold. First, Cynet provides the VirusTotal partner network cutting-edge threat intelligence from its ML-based detection engine (CyAI) that actively protects the company's clients around the globe.
CyAI is a continuously learning and evolving detection model that routinely contributes information about new threats that are not available in VirusTotal. Although many vendors are using AI/ML models, the ability of the models to detect new threats vary greatly.
Cynet routinely outperforms third party and open source detection platforms and is frequently relied upon in incident response cases when underlying threats remain hidden from other solutions.
For example, Cynet recently conducted an Incident Response engagement for a large telecom provider. Cynet discovered several malicious files that did not appear in the VirusTotal database.
Contributing information on these newly discovered files helps our entire industry perform better and protect businesses against cyber-attacks.
Second, Cynet will leverage intelligence in VirusTotal to inform its CyAI model in order to continuously improve its detection capabilities and accuracy.
Cynet AI is continually evolving, constantly learning new datasets in order to improve its accuracy and decrease its already-low false positive ratio. Comparing files found to be malicious by CyAI against files also found to be malicious by other providers helps to quickly validate Cynet's findings.
With Docker gaining popularity as a service to package and deploy software applications, malicious actors are taking advantage of the opportunity to target exposed API endpoints and craft malware-infested images to facilitate distributed denial-of-service (DDoS) attacks and mine cryptocurrencies.
According to a report published by Palo Alto Networks' Unit 42 threat intelligence team, the purpose of these Docker images is to generate funds by deploying a cryptocurrency miner using Docker containers and leveraging the Docker Hub repository to distribute these images.
"Docker containers provide a convenient way for packaging software, which is evident by its increasing adoption rate," Unit 42 researchers said. "This, combined with coin mining, makes it easy for a malicious actor to distribute their images to any machine that supports Docker and instantly starts using its compute resources towards cryptojacking."
Docker is a well-known platform-as-a-service (PaaS) solution for Linux and Windows that allows developers to deploy, test, and package their applications in a contained virtual environment — in a way that isolates the service from the host system they run on.
The now taken down Docker Hub account, named "azurenql," consisted of eight repositories hosting six malicious images capable of mining Monero, a privacy-focused cryptocurrency.
The malware author behind the images used a Python script to trigger the cryptojacking operation and took advantage of network anonymizing tools such as ProxyChains and Tor to evade network detection.
The coin mining code within the image then exploited the processing power of the infected systems to mine the blocks.
The images hosted on this account have been collectively pulled over two million times since the start of the campaign in October 2019, with one of the wallet IDs used to earn more than 525.38 XMR ($36,000).
Exposed Docker Servers Targeted With DDoS Malware
That's not all. In a new mass-scanning operation spotted by Trend Micro researchers, unprotected Docker servers are being targeted with at least two different kinds of malware — XOR DDoS and Kaiji — to collect system information and carry out DDoS attacks.
"Attackers usually used botnets to perform brute-force attacks after scanning for open Secure Shell (SSH) and Telnet ports," the researchers said. "Now, they are also searching for Docker servers with exposed ports (2375)."
It's worth noting that both XOR DDoS and Kaiji are Linux trojans known for their ability to conduct DDoS attacks, with the latter written entirely from scratch using Go programming language to target IoT devices via SSH brute-forcing.
The XOR DDoS malware strain works by searching for hosts with exposed Docker API ports, followed by sending a command to list all the containers hosted on the target server, and subsequently compromising them with the XORDDoS malware.
Likewise, the Kaiji malware scans the internet for hosts with exposed port 2375 to deploy a rogue ARM container ("linux_arm") that executes the Kaiji binary.
"While the XOR DDoS attack infiltrated the Docker server to infect all the containers hosted on it, the Kaiji attack deploys its own container that will house its DDoS malware," the researchers said, noting the difference between the two malware variants.
In addition, both the two pieces of malware gather details such as domain names, network speeds, process identifiers of running processes, and CPU and network information that are needed to mount a DDoS attack.
"Threat actors behind malware variants constantly upgrade their creations with new capabilities so that they can deploy their attacks against other entry points," the researchers concluded.
"As they are relatively convenient to deploy in the cloud, Docker servers are becoming an increasingly popular option for companies. However, these also make them an attractive target for cybercriminals who are on the constant lookout for systems that they can exploit."
It's advised that users and organizations who run Docker instances immediately check if they expose API endpoints on the Internet, close the ports, and adhere to recommended best practices.
One flaw allowed any authenticated user with subscriber-level and above permissions the ability to update and modify posts with malicious content, amongst many other things. A second flaw allowed attackers to forge a request on behalf of a site’s administrator to modify the settings of the plugin which could allow for malicious Javascript injection.
We initially reached out to the plugin’s developer on April 30, 2020 and after establishing an appropriate communication channel, we provided the full disclosure on May 1, 2020. They responded quickly on May 2, 2020 letting us know that they were beginning to work on fixes. An initial patch was released on May 2, 2020 and an optimal patch was released on May 6, 2020.
These are considered high-level security issues that could potentially lead to attackers wiping your site’s content or taking over your site. We highly recommend an immediate update to the latest version available at the time of this publication, which is version 1.1.4.
Wordfence Premium customers received a new firewall rule on April 30, 2020, to protect against exploits targeting this vulnerability. Free Wordfence users will receive this rule after thirty days, on May 30, 2020.
PageLayer is a very easy to use WordPress page builder plugin that claims to work with nearly all themes on the market and in the WordPress repository. It provides extended customization of pages through the use of widgets that can add page elements like buttons, tables, excerpts, products and more.
We discovered that nearly all of the AJAX action endpoints in this plugin failed to include permission checks. This meant that these actions could be executed by anyone authenticated on the site, including subscriber-level users. As standard, these AJAX endpoints only checked to see if a request was coming from /wp-admin through an authenticated session and did not check the capabilities of the user sending the request.
There were nonce checks in use in all of these functions, but nonces can be easily compromised if incorrectly implemented – for example, if a usable nonce is displayed within the source code of the site’s output. Unfortunately for the PageLayer plugin, this is precisely what happened. A usable nonce was visible in the header section of the source code of any page that had previously been edited using the PageLayer plugin. Any site visitor could find this nonce, whether they were logged in or not, allowing any unauthenticated user the ability to obtain a legitimate nonce for the plugin’s AJAX actions.
PageLayer nonce obtainable from page source.
Using a single nonce as the mechanism for authorization control caused various security issues in the functionalities of the page builder due to this nonce being so easily obtainable.
WordPress nonces should never be used as a means of authorization as they can easily be compromised if implemented improperly or if a loophole is found. WordPress nonces are designed to be used for CSRF protection, not authorization control. Implementing capability checks in conjunction with CSRF protection on sensitive functions for full verification provides protection to ensure a request is coming from an authorized user.
The Impact
As previously mentioned, several AJAX functions were affected, causing a large variety of potential impacts. A few of the most impactful actions were wp_ajax_pagelayer_save_content, wp_ajax_pagelayer_update_site_title, and wp_ajax_pagelayer_save_template.
The pagelayer_save_content function is used to save a page’s data through the page builder. The lack of permission checks on this function allowed authenticated users, regardless of permissions, the ability to change any data on a page edited with PageLayer.
An attacker could wipe the pages completely or inject any content they would like on the site’s pages and posts. In addition, a few widgets allowed Javascript to be injected, including the “Button” widget. There is no sanitization on the “Button” widget’s text, which allows for malicious Javascript to be used as a text. This Javascript would execute once any user browsed to a page containing that button.
PageLayer button with alert JS injected.
The pagelayer_update_site_title function is used to update a site’s title. The lack of permission checks on this function allowed authenticated users the ability to change a site title to any title of their choosing. Though less detrimental, this could still affect your sites search engine ranking if unnoticed for an extended period of time.
The pagelayer_save_template function is used to save PageLayer templates for the PageLayer Theme Builder. The lack of permission checks on this function allowed authenticated users the ability to create new PageLayer templates that were saved as new posts.
Though this function was intended to be used in the PRO version of the plugin, the function could still be executed in the free version, affecting all 200,000+ users of the PageLayer plugin. An attacker could create a new template, which created a new page on the site, and inject malicious Javascript in the same way they could with the pagelayer_save_content function.
Malicious Javascript can be used to inject new administrative users, redirect site visitors, and even exploit a site’s user’s browser to compromise their computer.
The Patch
In the latest version of the plugin, the developers implemented permissions checks on all of the sensitive functions that could make changes to a site, and reconfigured the plugin to create separate nonces for the public and administrative areas of a WordPress site.
The PageLayer plugin registers a settings area where configuration changes can be made. This includes functionality such as where the editor is enabled, basic content settings, basic information configurations, and more.
PageLayer settings area.
The settings update function used a capability check to verify that a user attempting to make any changes had the appropriate permissions. However, there was no CSRF protection to verify the legitimacy of any request attempting to update a site’s settings. This made it possible for attackers to trick an administrator into sending a request to update any of the PageLayer settings.
156
157
158
159
160
161
162
163
164
165
166
167
functionpagelayer_settings_page(){
$option_name= 'pl_gen_setting';
$new_value= '';
if(isset($_REQUEST['pl_gen_setting'])){
$new_value= $_REQUEST['pl_gen_setting'];
if( get_option( $option_name) !== false ) {
// The option already exists, so we just update it.
update_option( $option_name, $new_value);
The “Information” tab in the settings area provides site owners with a way to set a default address, telephone number, and contact email address that are displayed whenever the corresponding widgets were used on a page. There was no sanitization on the address or telephone number settings, and due to the administrator’s capability to use unfiltered_html, Javascript could be injected into these settings.
PageLayer Address updated with alert JS.
The Impact
This allowed attackers the ability to inject malicious scripts while exploiting the CSRF vulnerability in the settings. If the widget was already enabled, any injected malicious scripts would execute whenever someone browsed to a page containing that widget. If the widget was not yet enabled, the malicious scripts could be executed once an administrator started editing and inserting the widget into a page. As always, these scripts can do things like create a new administrative account and redirect users to malicious sites.
The Patch
In the patched version of the plugin, the developers implemented CSRF protection consisting of a WordPress nonce and verification of that nonce when updating settings.
176
177
178
if(isset($_REQUEST['submit'])){
check_admin_referer('pagelayer-options');
}
PoC Walkthrough: pagelayer_save_content
Disclosure Timeline
April 24, 2020 to April 30, 2020 – Initial discovery of minor security flaw and deeper security analysis of plugin. April 30, 2020 – Firewall rule was released for Wordfence Premium customers. We made our initial contact attempt with the plugin’s development team. May 1, 2020 – The plugin’s development team confirms appropriate inbox for handling discussion. We provide full disclosure. May 2, 2020 – Developer acknowledges receipt and confirms that they are beginning to work on fixes. An update is released the same day. May 4, 2020 – We analyze the fixes and discover a few security issues left unpatched and responsibly disclose these issues to the developer. May 6, 2020 – Developer releases the final sufficient patch. May 30, 2020 – Free Wordfence users receive firewall rule.
Conclusion
In today’s post, we detailed several flaws related to unprotected AJAX actions and nonce disclosure that allowed for attackers to make several malicious modifications to a site’s pages and posts in addition to providing attackers with the ability to inject malicious Javascript. These flaws have been fully patched in version 1.1.2. We recommend that users immediately update to the latest version available, which is version 1.1.4 at the time of this publication.
Sites running Wordfence Premium have been protected from attacks against this vulnerability since April 30, 2020. Sites running the free version of Wordfence will recieve this firewall rule update on May 30, 2020. If you know a friend or colleague who is using this plugin on their site, we highly recommend forwarding this advisory to them to help keep their sites protected.
Between May 29 and May 31, 2020, the Wordfence Firewall blocked over 130 million attacks intended to harvest database credentials from 1.3 million sites by downloading their configuration files.
The peak of this attack campaign occurred on May 30, 2020. At this point, attacks from this campaign accounted for 75% of all attempted exploits of plugin and theme vulnerabilities across the WordPress ecosystem.
We were able to link these attacks to the same threat actor previously targeting XSS vulnerabilities at a similar scale. All Wordfence users, including Wordfence Premium and those still using the free version of Wordfence, are protected by our firewall’s built-in directory traversal protection.
Different vulnerabilities, same IPs
The previously reported XSS campaigns sent attacks from over 20,000 different IP addresses. The new campaign is using the same IP addresses, which accounted for the majority of the attacks and sites targeted. This campaign is also attacking nearly a million new sites that weren’t included in the previous XSS campaigns.
As with the XSS campaigns, almost all of the attacks are targeted at older vulnerabilities in outdated plugins or themes that allow files to be downloaded or exported. In this case the attackers are attempting to download wp-config.php, a file critical to all WordPress installations which contains database credentials and connection information, in addition to authentication unique keys and salts. An attacker with access to this file could gain access to the site’s database, where site content and users are stored.
Indicators of Compromise
Attacks by this campaign should be visible in your server logs. Look for any log entries containing wp-config.php in the query string that returned a 200 response code.
The top 10 attacking IP addresses in this campaign are listed below.
Sites running Wordfence are protected against this campaign. If your site is not running Wordfence, and you believe you have been compromised, change your database password and authentication unique keys and salts immediately.
If your server is configured to allow remote database access, an attacker with your database credentials could easily add an administrative user, exfiltrate sensitive data, or delete your site altogether. Even if your site does not allow remote database access, an attacker who knows your site’s authentication keys and salts may be able to use them to more easily bypass other security mechanisms.
If you’re not comfortable making the changes above, please contact your host, since changing your database password without updating the wp-config.php file can temporarily take down your site.
Conclusion
In today’s post, we covered another large-scale attack campaign against WordPress sites by a threat actor we have been tracking since February. All Wordfence users, including sites running the free version of Wordfence, and Wordfence Premium, are protected against these attacks. Nonetheless, we urge you to make sure that all plugins and themes are kept up to date, and to share this information with any other site owners or administrators you know. Attacks by this threat actor are evolving and we will continue to share additional information as it becomes available.
WordPress Core version 5.4.2 has just been released. Since this release is marked as a combined security and bug fix update, we recommend updating as soon as possible. With that said, most of the security fixes themselves are for vulnerabilities that would require specific circumstances to exploit. All in all this release contains 6 security fixes, 3 of which are for XSS (Cross-Site Scripting) vulnerabilities. Both the free and Premium versions of Wordence have robust built-in XSS protection which will protect against potential exploitation of these vulnerabilities.
A Breakdown of each security issue
An XSS issue where authenticated users with low privileges are able to add JavaScript to posts in the block editor
This flaw would have made it possible for an attacker to inject JavaScript into a post by manipulating the attributes of Embedded iFrames. This would be exploitable by users with the edit_posts capability, meaning users with the Contributor role or higher in most configurations.
This issue was discovered and reported by Sam Thomas (jazzy2fives)
An XSS issue where authenticated users with upload permissions are able to add JavaScript to media files
This flaw would have made it possible for an attacker to inject JavaScript into the “Description” field of an uploaded media file. This would be exploitable by users with the upload_files capability, meaning users with the Author role or higher in most configurations.
This issue was discovered and reported by Luigi – (gubello.me)
An open redirect issue in wp_validate_redirect()
For this flaw, the wp_validate_redirect function failed to sufficiently sanitize URLs supplied to it. As such it would have been possible under certain circumstances for an attacker to craft a link to an impacted site that would redirect visitors to a malicious external site. This would not require specific capabilities, but it would typically require either social engineering or a separate vulnerability in a plugin or theme to exploit.
This issue was discovered and reported by Ben Bidner of the WordPress Security Team.
An authenticated XSS issue via theme uploads
This flaw would have made it possible for an attacker to inject JavaScript into the stylesheet name of a broken theme, which would then be executed if another user visited the Appearance->Themes page on the site. This would be exploitable by users with the install_themes or edit_themes capabilities, which are only available to administrators in most configurations.
An issue where set-screen-option can be misused by plugins leading to privilege escalation
For this flaw, a plugin incorrectly using the set-screen-option filter to save arbitrary or sensitive options could potentially be used by an attacker to gain administrative access. We are not currently aware of any plugins that are vulnerable to this issue.
An issue where comments from password-protected posts and pages could be displayed under certain conditions
For this flaw, comment excerpts on password-protected posts could have been visible on sites displaying the “Recent Comments” widget or using a plugin or theme with similar functionality.
Most of these vulnerabilities appear to be exploitable only under limited circumstances or by trusted users, but we recommend updating as soon as possible. Attackers may find ways to exploit them more easily, or the researchers who discovered these vulnerabilities may publish Proof of Concept code that allows simpler exploitation. This is a minor WordPress release, so most sites will automatically update to the new version.
Conclusion
We’d like to thank the WordPress core team and the researchers who discovered and responsibly reported these vulnerabilities for making WordPress safer for everyone.
You can find the official announcement of the WP 5.4.2 release on this page. If you have any questions or comments, please don’t hesitate to post them below and we’ll do our best to answer them in a timely manner. If you are one of the researchers whose work is included above and would like to provide additional detail or corrections, we welcome your comments.
