Hacked Lucee / IIS server - can I disable .asp and other unnecessary handlers ?

[Ivan Rotrekl]

Hi,

today I have experienced a rather annoying attack of my Lucee / IIS 7.5 server. Looks like somebody created and sb.asp file in one webroot, which in turn created a lot of folders containing html and js files all over the server.

Actually, all IIS servers of my hosting provider, have been similarly infested.

I am not expert on the subject at all, but I was thinking the easy way to prevent this in the future, would be to simply disable execution of .asp, .php and some other unnecessary handlers.

At the end I want to run only .cfm and .cfc scripts on my server.

Would that be posssible ? I believe for example the Boncode connector is written in .NET, but I am not sure if it needs the asp.net handler and so on.

Could perhaps somebody more experienced have a look at my attached list of handlers and point out which of those are truly needed to run Lucee ?

I understand there might be more steps needed to truly secure the server, but believe this could be a good first step to take.

Thanks a lot for any info on this.

Best Regards

Ivan

[Julian Halliwell]

Hi

That's quite a list! Part of our server hardening is always to remove
all handlers we don't need. For Lucee sites the only ones we found we
need are:

BonCode-Tomcat-CFM-Handler
BonCode-Tomcat-CFC-Handler
StaticFile

Julian.

[Ivan Rotrekl]

Hi,

thanks a lot for this !  Well, quite a list, yes.  I simply did not know, what some of these are, so I let them there. Did not want to fix what was not broken.

Now, I  have tried to disable some of these handlers on the server level, but the funny thing is:  I can not disable them one by one.

If I right click for example on *.asp, choose "edit feature permissions" and uncheck "script"  ALL of them get disabled.

Am I doing something wrong ?

Also I am using IIS rewrite on the server, does it not need some of those handlers ?

Regards

Ivan

[Julian Halliwell]

If you don't need the handlers, then I'd remove rather than disable
them. You might find it better to edit the applicationHost.config file
in

Windows\System32\inetsrv\config

Make a copy of that file before making changes so you have a backup.
Then search for "<handlers" and within that section delete all the
entries you don't want.

I don't think URL rewrite needs to know anything about your handlers:
it just rewrites or redirects URLs as they come in. Works fine for us
with just the Lucee handlers I mentioned.

[Ivan Rotrekl]

Thanks a lot for this !  I have edited the applicationHost.config, kept just the handlers you had mentioned and it works beautifully.

Regards

Ivan

[Alex Skinner]

Hi,

Once you have an "infested server" my advice would be that you commission new servers, lock them down and then migrate your client's sites to them, inspecting your code based and comparing against source control. Once a machine is compromised you can never with certainty be sure you have found all the files that have been modified or set especially if there has been a permissions escalation.

You definitely want to remove all the handlers as you've done but it would certainly be an additional step worth considering.

Cheers

Alex

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/04e33aed-5357-4156-9ef8-87f86013f835%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Alex Skinner
Managing Director

Pixl8 Interactive, 3 Tun Yard, Peardon Street, London SW8 3HT, United Kingdom T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: in...@pixl8.co.uk

Follow us on: Facebook Twitter LinkedIn

CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended solely for the addressee, is strictly confidential and may also be subject to legal, professional or other privilege or may be protected by work product immunity or other legal rules. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. Pixl8 Interactive Ltd Registered in England. Registered number: 04336501. Registered office: 8 Spur Road, Cosham, Portsmouth, Hampshire, PO6 3EB

[Pete Freitag]

On Mon, Jul 27, 2015 at 12:57 PM, Alex Skinner <al...@pixl8.co.uk> wrote:

Once you have an "infested server" my advice would be that you commission new servers, lock them down and then migrate your client's sites to them, inspecting your code based and comparing against source control. Once a machine is compromised you can never with certainty be sure you have found all the files that have been modified or set especially if there has been a permissions escalation.

+1, I always recommend that as well.

--

Pete Freitag
https://foundeo.com/ - ColdFusion Consulting & Products
http://hackmycf.com - CFML Server Security Scanner

[Ivan Rotrekl]

Thanks. I appreciate the advice and will probably have to follow it.

Currently I am running Lucee on the same machine and IIS install, where I used to run CF8 for several years and then Railo, so it might be a really good time to start fresh from the scratch.

But I suspect  to truly  lock down the new server would involve a bit more than removing the handlers. Is there some sort of  "lock down guide"  for a Lucee server available, which I could follow step by step to do it properly ?

Regards

Ivan

[Stephan]

Hi Ivan,

It looks like the lucee site doesn't have any info on their wiki page about locking down for IIS, at least not here:

https://bitbucket.org/lucee/lucee/wiki/Securing%20IIS

Basic security would be to restrict public access to the /WEB-INF/ and /railo-context/ or /lucee/ folders (to protect the admin).

We do this in our main iis applicationHost.config file so that it applies to all our sites automatically.

In the file's <rewrite> section add a rewrite map with ip's you want to allow, and then add a global rule below like this:

<rewrite>

<rewriteMaps>

                <rewriteMap name="Authorized admin IPS">

                    <add key="xxx.xxx.xxx.xxx" value="1" />

                </rewriteMap>

</rewriteMaps>

<globalRules>

<rule name="Block Railo admin" patternSyntax="Wildcard" stopProcessing="true">

            <match url="railo-context*" />

            <conditions logicalGrouping="MatchAny">

                        <add input="{Authorized admin IPS:{REMOTE_ADDR}}" pattern="1" negate="true" />

            </conditions>

            <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />

        </rule>

  <rule name="Block Railo WEB-INF" patternSyntax="Wildcard" stopProcessing="true">

            <match url="WEB-INF*" />

            <action type="CustomResponse" statusCode="403" statusReason="Forbidden" statusDescription="Forbidden" />

        </rule>

            </globalRules>

        </rewrite>

This will block access to WEB-INF entirely, and restrict the railo admin to only authorized ip addresses.

If your server was patched (OS and any web apps like wordpress) and didn't have known security vulnerabilities then the next thing to check is user uploaded content.

Never trust user uploaded content, make sure the user uploaded content is not in a folder that has any handler mappings enabled.

Also look into maybe moving your sites behind a WAF, using Cloudflare or Sucuri for example.

A lot of other things to check for probably but at least this should cover the basics for lucee/railo on IIS.

hope that helps...

[Ivan Rotrekl]

Hi Stephan,

thanks. Well, I have moved the WEB-INF folders outside the webroots via the setting in tomcat web.xml like this:

<init-param>
      <param-name>lucee-web-directory</param-name>
      <param-value>{web-root-directory}/../WEB-INF/lucee/</param-value>
      <description>Lucee Web Directory (for Website-specific configurations, settings, and libraries)</description>
    </init-param>

Also, I have disabled the access to the Lucee Admin server-wide via the built-in option in BonCode connector.

If I understand this properly, this could provide a  similar level of security as the approach you are suggesting ?


My main trouble at this moment is, that  I can see a lot of requests in logs, banging the server and trying to access various random (mostly non-existent) files which could be possibly exploited.  Like those in the log I am attaching.

Yesterday I have installed Dynamic IP restrictions in IIS, which could help to block concurrent or highly repeatable requests.

But I am not sure if this is effective,  as the troublesome requests are neither concurrent or repeatable ( occuring  just every couple of minutes).

Also, I am not sure if these  requests are  actually harmful, because they usually end up as 404. Just it is funny to see that someone or something is constantly testing it.


Well, i have checked some IPs and they  come from China or other countries, completely unrelated to the content of my server.

I am toying with the idea of blocking IP ranges of  certain countries, or even more draconic one, allowing only countries which are related to my sites.

But from what I could have seen so far, this might be quite difficult to implement in practice. Looks like I would have to input a dozens of ranges.

Regards

Ivan

[Stephan]

Good to know about this other way of protecting these directories, I wasn't aware of them.

Regarding the invalid/hack attempt requests we see a lot of these too, urlscan on iis can help a little bit (depending on how your application is configured and how much you can restrict the type of requests you want to allow). Dynamic ip restrictions or blocking by country will not help in my experience - blocking by country is very easily bypassed, and not every attack comes from China/Russia, we also see a lot coming from compromised Amazon AWS or other US based hacked co-located servers.

For what you're experiencing you really a need a WAF, either you can host yourself in front of your web server (or even on the same box with some software versions), or if you don't want to have to manage it as a service like Cloudflare or Sucuri (we use Sucuri, they do a pretty good job.)

[Ivan Rotrekl]

Thanks Stephan. I will try to look into the solutions you have mentioned.  You were right, the Dynamic IP Restrictions didn't help too much. So far, it had only blocked images on certain sites, so I had to lift up the limits. I was quite disappointed - thought it would work better than that.