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

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

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.On 24 July 2015 at 15:02, Ivan Rotrekl <@Ivan_Rotrekl> wrote:

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.

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.On 24 July 2015 at 16:31, Ivan Rotrekl <@Ivan_Rotrekl> wrote:

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 ?

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

Regards

Ivan

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

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.On Mon, Jul 27, 2015 at 12:57 PM, Alex Skinner <@Alex_Skinner> wrote:


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

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

AlexOn 26 July 2015 at 14:45, Ivan Rotrekl <@Ivan_Rotrekl> wrote:

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

Regards

Ivan


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+unsubscribe@googlegroups.com.
To post to this group, send email to lucee@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/lucee/04e33aed-5357-4156-9ef8-87f86013f835%40googlegroups.com
https://groups.google.com/d/msgid/lucee/04e33aed-5357-4156-9ef8-87f86013f835%40googlegroups.com?utm_medium=email&utm_source=footer
.
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: info@pixl8.co.uk

Follow us on: Facebook http://www.facebook.com/pixl8 Twitter
http://www.twitter.com/pixl8 LinkedIn http://www.linkedin.com/pixl8

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

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 section add a rewrite map with ip’s you want to
allow, and then add a global rule below like this:

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…On Monday, July 27, 2015 at 4:30:43 PM UTC-4, Ivan Rotrekl wrote:

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

Hi Stephan,

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

lucee-web-directory {web-root-directory}/../WEB-INF/lucee/ Lucee Web Directory (for Website-specific configurations, settings, and libraries)

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

IvanOn Tuesday, July 28, 2015 at 3:13:35 AM UTC+2, Stephan wrote:

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 section add a rewrite map with ip’s you want to
allow, and then add a global rule below like this:

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…

On Monday, July 27, 2015 at 4:30:43 PM UTC-4, Ivan Rotrekl wrote:

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

u_ex150728.log (35.5 KB)

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.)On Tuesday, July 28, 2015 at 2:42:16 AM UTC-4, Ivan Rotrekl wrote:

Hi Stephan,

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

lucee-web-directory {web-root-directory}/../WEB-INF/lucee/ Lucee Web Directory (for Website-specific configurations, settings, and libraries)

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

On Tuesday, July 28, 2015 at 3:13:35 AM UTC+2, Stephan wrote:

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 section add a rewrite map with ip’s you want to
allow, and then add a global rule below like this:

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…

On Monday, July 27, 2015 at 4:30:43 PM UTC-4, Ivan Rotrekl wrote:

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

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.