Security question

7 posts by 3 authors in: Forums > CMS Builder
Last Post: June 11   (RSS)

By hiroko - June 8

Hi,

One of my client's site's Newsletter builder manage page has been hacked (not sure what exactly happened).

There was a number of spam registration on the newsletter and I unconfirmed those registerations.

Yesturday, the server company contacted me that the manage page is being used to transfer URL to a fraudulent website

I deleted the manage page, but I would like to know if there is any way to protect my files from something like this.

The url that the server company sent me was like this https://www.xxx.com/manage.php?l=http://fraudulentsite.com

there is an URL attached after the question mark.

I looked into the file and other files, but couldn't find anything suspicious.

If anyone have information about something like this, please let me know.

Thank you,

Hiroko

By daniel - June 9

Hi Hiroko,

It is difficult to provide specific advice without knowing what sort of code was on manage.php, but I can give some general advice that will hopefully be useful to you.

There was a number of spam registration on the newsletter and I unconfirmed those registerations.

First - a very effective way to prevent spam is with a CAPTCHA; Google's reCAPTCHA v2 is a good place to start.

I deleted the manage page, but I would like to know if there is any way to protect my files from something like this.

The url that the server company sent me was like thishttps://www.xxx.com/manage.php?l=http://fraudulentsite.com

there is an URL attached after the question mark.

One thing to be aware of is that anyone can modify URL parameters and send them to a site, so these sorts of URLs may or may not be created by your code. This is potentially an example of Cross-Site Scripting attacks (Or "XSS": https://riptutorial.com/php/example/11883/cross-site-scripting--xss-). With proper escaping, this can be rendered harmless, but how the code handles the URL parameters is important. For example, if a URL parameter is being used to control a page redirect, a 3rd party can potentially create a link that changes the parameter and modifies how the redirect works.

In your example of "https://www.xxx.com/manage.php?l=http://fraudulentsite.com" - the sorts of questions to ask are: Does the "l" parameter exist in the code, and if so, what does it do? If this parameter contains something unexpected, what happens? etc.

I hope that gives you some useful information - let me know if I can help clarify anything, or if you have any other questions.

Thanks!

Daniel
Technical Lead
interactivetools.com

By daniel - June 9

Hi Hiroko,

A quick update: We've found something that may give some insight into the issue with manage.php causing a redirect. I'll follow up once I've investigated further.

Cheers,

Daniel
Technical Lead
interactivetools.com

By hiroko - June 10

Hi Daniel,

Thanks for the response.

The manage page was just about the same as the PHP generator with some styles. And yes, I should have used ReCaptcha in the first place and that was not smart. I had someone to look through my server and there was no trace of falsification, which I was very relieved.

So, as you mentioned about the Cross-Site Scripting attacks, this issue that anyone can make a link by using your domain plus the "l" parameter, could be a vulnerability to our sites. I guess the first step is to not let them know about the "l" parameter and maybe that was possible by using the ReCaptcha. When the spam registered the newsletter, they received the confirmation mail with links where the "l" parameter is used. (or is it popular to use l parameter?)

I had the .htaccess file rewritten so that any external site on theĀ  "l" parameter will be rejected. This may cause effect on some function, and it is a temporary measure, but for now, everything on my site seems ok.

In case anyone in the future experience the same issue, I can share the code, but I can't guarantee.

Best,

Hiroko

By daniel - June 11

Hi Hiroko,

Thanks for the followup. I did a bit more digging and found that this redirect is part of the Newsletter Builder plugin; this parameter is used to track links included in newsletters. Having an open redirect like this can create a potential security risk, and while we have some background processing that prevents some of these issues, I've logged an internal task to have this redirect be reviewed. In the meantime, if you don't need to track link clicks within your newsletters, I recommend disabling this feature. You can do so by taking the following steps in the newsletterBuilder.php plugin file:

  1. At the top of the file (at or near line 16) change the "NLB_TRACK_LINKS" setting to false. This will prevent the newsletter from replacing links in sent newsletters with the tracking URL.
  2. Add a "return;" to the first line of the "nlb_frontend_trackLinks()" function (at or near line 73). It should look something like this:
    function nlb_frontend_trackLinks() {
      return;
      if (!@$_REQUEST['l']) { return; }
    
      nlb_log(@$_REQUEST['m'], @$_REQUEST['n'], '6', @$_REQUEST['l']);
      redirectBrowserToURL($_REQUEST['l']);
      exit;
    }

    This will disable the open redirect.

Step #2 is similar to what you've done with the .htaccess, except this will only disable "l" parameter for the newsletter builder plugin, and won't interfere with any other uses.

Let me know if you have any further questions.

Thanks!

Daniel
Technical Lead
interactivetools.com

By hiroko - June 11

Hi Daniel,

Thank you for your help.

This is the code that was added to my .htaccess file.

# Block Open-Redirect
RewriteCond %{QUERY_STRING} (^|&)l=([^&]+)($|&)
RewriteRule .* -[E=X_QUERY_REDIRECT:%2]RewriteCond %{ENV:X_QUERY_REDIRECT} !^$
RewriteCond %{ENV:X_QUERY_REDIRECT} !^http(s)?://(www\.)?mysite.com.*
RewriteRule .* -[F]

The tracking link is a nice feature, but I guess I will use the code you have suggested.

Thanks!

Best,

Hiroko