Identifying Lucee

[Brad Wood]

Like, I mentioned in this thread, I submitted Lucee as a new technology to builtwith.com the other day.  I've been E-mailing back and forth with their support discussing how to best identify a Lucee (or any CFML) server.  Common approaches are:

• File extensions (not specific to Lucee, can be hidden with URL rewrites)
• Common session cookies (not specific to Lucee)
• Admin URL (they're reticent to scan for these, can also be hidden)
• Cause an error like a 404 and hope for standard error page (they're not doing this yet, only works if no global error handler in place)

What's the general consensus for adding a default HTTP header to Lucee that be disabled by an admin that has something like:

X-Powered-By: Lucee

I'm well aware this sort of thing flies in the face standard server hardening, but it's been a very common occurrence in technologies such as .NET or PHP and I can't help but wonder if it's made those technologies look "more used" just because they're easy to identify.  

Thoughts?

Thanks!

~Brad

[Andrew Dixon]

I'm sure that is one reason why those technologies show up more often as being used but I can imagine the answer my sys admin will give me now about this and it starts with "hell" and ends with "no", but to be honest he will probably be way more explicit than that!!!

Kind regards,

Andrew

about.me
mso - Lucee - Member

--
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/4bf5ec9c-ba28-4931-a327-e6ca395c2efb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Brad Wood]

Lol! well, that's why it would be able to be turned off :)

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

--
You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/ps2ST5N4jFU/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAG1WijWt%2B6h-%2BpHPq%2BWr%3D5%3DBW5HGb12JG34GAakOyF3MCXOb4Q%40mail.gmail.com.

[Tom King]

Yeah, I'd definitely not want this. It's like painting an extra bullseye on your webserver. Whoever came up with meta-tag of 'generated-by' for wordpress was also an idiot.

[Andrew Dixon]

+1

Kind regards,

Andrew

about.me
mso - Lucee - Member

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/99af2ba2-ef92-43e1-a9f5-6448b536af39%40googlegroups.com.

[Gert Franz]

Well was a setting in the Railo admin in the years back for exactly this. Under output as far as I remember. We changed the default to be off instead of on. Just check the admin, if its still there.

Gert

Sent from somewhere on the road

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/99af2ba2-ef92-43e1-a9f5-6448b536af39%40googlegroups.com.

[Malcolm O'Keeffe]

While a digital “fingerprint” has its downsides, there are real business advantages to LAS and the Lucee community if BuiltWith and other services like it are able to easily identify Lucee web servers. 

Lucee is a new technology, and will face lots of “credibility” challenges. The more that adoption can be demonstrated, both in terms of raw numbers as well as high-visibility sites, the more easily Lucee can be justified for new projects. 

I think having the HTTP header identify Lucee by default (but easily turned off) as Brad Wood suggested is the best option. 

Malcolm O'Keeffe
Blue River Interactive Group

(916) 608-8608 - office
(916) 834-3370 - cell

www.blueriver.com - Website Design and Development
www.getmura.com - Open Source CMS

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CC5AEA52-D13A-4011-B92E-79A4B290B120%40rasia.ch.

[Igal @ Lucee.org]

+1

Igal Sapir
Lucee Core Developer
Lucee.org

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/B6768B3C-858C-469E-9872-74FEA3FDFD2D%40blueriver.com.

[Andrew Dixon]

If this is done, please make sure three things happen:

1) It is easy to turn off

2) It doesn't include any version information, just the Lucee name and nothing else.

3) The "how to turn off" is included in a lock down guide.

Kind regards,

Andrew

about.me
mso - Lucee - Member

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/B6768B3C-858C-469E-9872-74FEA3FDFD2D%40blueriver.com.

[Alex Skinner]

Hi

I think these are two separate things.  I think we have responsibility to promote secure by default.

Many people do not spend the time to review admin settings and we all know best practice is security by obscurity.  I'm working this week and next to launch a feature of the Lucee site to make it easier for people to submit their success stories to LAS. 

I think we should encourage through documentation that our community is aware of ways to get the Lucee message out there and also more importantly let LAS know of their success too which is part of the problem.

But a credible platform is an opinionated one I think we need less config options and more baked in best practice.

Cheers

Alex

Sent from my phone

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/B6768B3C-858C-469E-9872-74FEA3FDFD2D%40blueriver.com.

[Igal @ Lucee.org]

how does identifying Lucee without version information making it less secure?  a hacker can easily find out that the engine is Lucee.  just by the presence of cfid cookie you know that this is one of a few possible options.

my servers disclose nginx as the web server.  does that make them less secure?  I don't think so.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFrbJ5X0H3WhwetyQLe-P7O9XEGq%2BfTJT58HUAkQeC3YEOnh9g%40mail.gmail.com.

[Adam Cameron]

On Thursday, 26 March 2015 21:58:39 UTC, Alex Skinner wrote:

But a credible platform is an opinionated one I think we need less config options and more baked in best practice.

I haven't tracked the rest of this thread, but this is a point worth dwelling on.

-- 

Adam

[Andrew Dixon]

my servers disclose nginx as the web server.  does that make them less secure?  I don't think so.

Of course it does, as soon as an attacker knows which server it is running then they know possible attack vectors by which to attempt to exploit it without having to try ever attack vector under the sun. Removing the version information goes some way to alleviating this a bit, but still if you know it is nginx then there is no point in trying the IIS, Apache, etc... attacks. Any information disclosure, no matter how small will assist attackers.

Kind regards,

Andrew

about.me
mso - Lucee - Member

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/551481ED.90503%40lucee.org.

[Igal @ Lucee.org]

it's very simple to identify the engine.  if the attacker can't do that then he wouldn't be able to do much damage anyway.

most servers (and I'm not only talking about web servers) identify the product name.  if this was an issue then this practice would have changed long ago.

Igal Sapir

Lucee Core Developer
Lucee.org

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG1WijVDsxfQNjHJ6CHid_gywYcUmWQSjhC-QQPLbsy-R%2BNO_g%40mail.gmail.com.

[Nando Breiter]

 Any information disclosure, no matter how small will assist attackers.

I'm not sure how best to phrase this properly, but the gist of it is that a determined, very skilled hacker will likely manage to penetrate any server. The attacks I see against my sites are not of this caliber, because, well, such hackers are not interested in my sites. 

So while this statement seems factually true, in practice, I don't think a disclosure identifying Lucee would matter in nearly all cases ... as a common sense perspective on the issue. A very skilled hacker will figure that out on his way in. The rest will get a bit of head start trying known vulnerabilities a developer should have locked down. I see a lot of automated scripts at work, and these typically hit the server hundreds of times in a few minutes, so that head start won't make a big difference if your server isn't secured.

Again, I'm likely not phrasing this well, but it's an effort to say something like " ... um yeah, but common sense would indicate that ... "

[Alex Skinner]

My argument is that if best practice is to hide identifying platform information and it is considered a normal part of server hardening then for me that should be the default as it far outweighs any anecdotal benefit of some website being able to list which website is built with what.

Plus automated scripts which search for known vulnerable systems tend to rely on headers and known responses to work out platforms they then proceed using metasploit or other platforms to run known vulnerabilities.

Disclosure in itself makes you no less secure but there is some benefit of security by obscurity.

I have raised a feature request a few times about not setting cfid and CF token unless a session is actually created this would also help in not leaving an obvious fingerprint.

If as we do in some cases u strip cookies,  offending headers,  use rewrite rules and generally catch errors u make it quite difficult for someone to identify the tech which is helpful.

A

Sent from my phone

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/551497C4.4080406%40lucee.org.

[Igal @ Lucee.org]

I have raised a feature request a few times about not setting cfid and CF token unless a session is actually created this would also help in not leaving an obvious fingerprint.

I've raised a ticket to make the cookie names customizable
https://bitbucket.org/lucee/lucee/issue/114/make-all-system-cookie-names-configurable

Igal Sapir
Lucee Core Developer
Lucee.org

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFrbJ5WfaqZA-CcBPp9s7MtHFWsmGYpXtDhw7xYqUkXWzOPnAA%40mail.gmail.com.

[Chip Pinkston]

I think it's important to point out that probably most of these sites are for our customers.  We might think of them as ours, but at the end of the day, this is a question of risk - and that is something the site owners need to chime in on.

Personally, I'd prefer not disclosing the engine just by default.  I'm actually a little bit wary that there might be a setting that could enable the engine to provide that data.  That said, I'd like to be able to promote my main project as a Lucee powered site (customer and higher ups permitting).  So it's a bit of a Catch-22.  Part of the resistance to this idea, I feel, is that it's like saying 'This is my house - I am out of it between the hours of 9-5.  Please swing by and take a look around the property.'  Some people will check if you've locked the door or left it open.  Of course, if someone wants in, they'll just break a window, but advertising it makes it more of an appealing target than every other house in your neighborhood.

I'm not a decision maker on my project, but I believe there would be less resistance to submitting stats about things like:

• Number of sites we support running Lucee
• General Business Sectors
• Our company details

But even there, I think there would be a greater comfort level knowing that data was just going into a aggregated roll up from a 'trusted' entity - such as LAS.  But I'd be very concerned about that data being a publicly available 'menu' for anyone that's just heard of a 0-day and wants to test out.

Chip.

[ADK]

I completely agree with Alex here.

As a developer looking at a new language for the first time, I'd find the promotion of "secure by default" far more enticing than a list or tally of sites sites built with it... unless you're listing some blue-chippers.

Furthermore, you can debate whether it's only security by obscurity, etc. but I think the perception that
"these Lucee guys understand the importance of security out of the gate" is more powerful than knowing x number of sites were built with it.

[Michael Offner]

I'm a 100% with Alex on this, this would be a step in the wrong direction, make cfid/cftoken customazible is on our agenda and will come.

There is simply no need to be compatible with acf there. We also work to make it possible to define extensions simply in the in the servlet specification, so we could not only do guides hoe to hide the identity, we could also do guides how to look like a php engine. So for me the journey goes in the different direction.

Micha

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/2757c33e-5081-42e0-ba86-81e5df679970%40googlegroups.com.

[Adam Cameron]

On Friday, 27 March 2015 00:06:37 UTC, Alex Skinner wrote:

My argument is that if best practice is to hide identifying platform information and it is considered a normal part of server hardening then for me that should be the default as it far outweighs any anecdotal benefit of some website being able to list which website is built with what.

[...]

Disclosure in itself makes you no less secure but there is some benefit of security by obscurity.

This is one of the baseline tenets of system security, and it shows no small amount of hubris for ppl to be thinking their opinions or anecdotal evidence somehow contradicts the broader industry's position on this.

Secondly, whether or not the risk is real (but it is), it's the perception of the risk that also needs to be mitigated here.

In the real world, we have had two separate security audits that yellow-flagged predictable cookie names. We don't expose anything else that might suggest our site runs on CF, except for CFID/CFTOKEN cookies which - despite we don't use them - we can't switch off. However these cookies still caused us problems. We had to make a point of explaining and demonstrating to the auditors there was no risk. It'd simply be better to not have to do that.

I'd possibly go further with this and consider these:

* in a instance-settable "production mode" error situations return nothing at all except the correct HTTP status code.

* as mentioned, configurable cookie names, which are only set if they're needed

* possibly consider handling directory requests within Lucee, where either index.cfm (if present; or any of the configured welcome files) is served, or if no welcome files exist or the directory itself doesn't exist treat the last subdir in the path as an obscured filename, eg: /this/is/some/path/ would serve /this/is/some/path.cfm. This way Lucee sites do not leak information about the fact they sue CFML files (by the .cfm extension)

* make it easy to get rid of the web-based admins. Or not have them enabled in the first place at all.

* and obscure (or don't have by default) any predictable asset paths (like Lucee's equivalent of /CFIDE/scripts/, if there is one)

Indeed instead of having a setting to switch prod stuff on, perhaps have this lot on by default and require it to be configured to behave any other way.

Security is a very marketable feature, because it's something everyone is concerned about these days, with its abuse increasing prevalent in the media.

-- 

Adam

[Andrew Dixon]

As a security by default enhancement starting point I've added the following ticket:

https://bitbucket.org/lucee/lucee/issue/240/add-ip-restriction-to-lucee-admin-and-lock

Kind regards,

Andrew

about.me
mso - Lucee - Member

--

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/aab16f1b-151d-45cf-ad2d-32f3d1995684%40googlegroups.com.

[Jochem van Dieten]

On Fri, Mar 27, 2015 at 12:53 AM, Nando Breiter wrote:

I'm not sure how best to phrase this properly, but the gist of it is that a determined, very skilled hacker will likely manage to penetrate any server.

One of our clients, an ISO 27001 certified company, put in their security policy that "attacks by nation states and terrorists, possibly assisted by legal or physical coercion, is out of scope". I like that phrasing.

 

 

So while this statement seems factually true, in practice, I don't think a disclosure identifying Lucee would matter in nearly all cases ... as a common sense perspective on the issue.

Except that after this very public discussion putting this header in would signal to the whole world that Lucee values marketing over best practices. I think that would more than negate any hypothetical marketing benefits.

Jochem

--

Jochem van Dieten
http://jochem.vandieten.net/

[Jean Moniatte]

http://builtwith.com/lucee.org

Powered by Adobe ColdFusion. We safe :-)

--
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/CABPCP-1S574WWkLnz9RMKT%3Dnvj_fmZ3FXgeqfgJbV2%2BcJKY8Tg%40mail.gmail.com.

[Nando Breiter]

LOL :-)

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAG-7QUvjzTFh6J2ueBjEZgVSgwj%2B1%3DQ%2BD_KvNUECE43yqqFMjQ%40mail.gmail.com.

[Pritesh Patel]

Normally, x-powered-by  required to be turn off if site required PCI compliance.  

[Andrew Penhorwood]

Wow if you look at http://trends.builtwith.com/framework# things look bad for CF.

Andrew Penhorwood

[Andrew Dixon]

How much of that decline is via system lock down and URL ossification as many of the top one's are declining. 

Kind regards,

Andrew

about.me
mso - Lucee - Member

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/cad4b7b2-5bed-44e2-9473-ab738b757ebe%40googlegroups.com.

[Andrew Penhorwood]

Don't know but good question.

Andrew Penhorwood

[Andrew Dixon]

Just noticed my strange spelling for obfuscation, no idea where that word came from... going to blame the Mac auto-incorrect!!!

Kind regards,

Andrew

about.me
mso - Lucee - Member

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/b3e54e0c-8cdb-42bd-8254-5098426450a7%40googlegroups.com.

[Pete Freitag]

You can already identify an unhardened server as running Lucee very easily, so adding a header would just be another step for people to do when locking down the server.

Here's a few things HackMyCF looks for to identify lucee:

/lucee/doc/index.cfm

/lucee/admin/server.cfm

/lucee/form.cfm

Probably the easiest one would be make a request to /lucee/form.cfm if it contains "LuceeForms" you are running Lucee. 

--

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

[Brad Wood]

Pete, thanks for those additions.  The guys at builtwith.com were reticent to go 'snooping' on people's servers since they didn't think admins would like it.  They also have millions of domains they check, so I'm sure they try to stick to as few HTTP hits to each domain as possible.  They had asked me what they could look for on a Lucee site's home page.

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

--
You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/ps2ST5N4jFU/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAADZ8V58x3Lj6EJrw5%3DAg3BP79VPyx_9PscThPnha1qbVt88xA%40mail.gmail.com.

[Igal @ Lucee.org]

Probably the easiest one would be make a request to /lucee/form.cfm if it contains "LuceeForms" you are running Lucee.

+1

Igal Sapir
Lucee Core Developer
Lucee.org

--
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/CAADZ8V58x3Lj6EJrw5%3DAg3BP79VPyx_9PscThPnha1qbVt88xA%40mail.gmail.com.

[Brad Wood]

I passed that suggestion on to them.  I pointed out it's not part of the admin so it most likely won't be seen as malicious traffic and will be less likely to be locked down.

Thanks!

~Brad

ColdBox Platform Evangelist

Ortus Solutions, Corp 

E-mail: br...@coldbox.org

ColdBox Platform: http://www.coldbox.org 

Blog: http://www.codersrevolution.com

--
You received this message because you are subscribed to a topic in the Google Groups "Lucee" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/lucee/ps2ST5N4jFU/unsubscribe.
To unsubscribe from this group and all its topics, 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/551ADAC0.8040703%40lucee.org.

[Igal @ Lucee.org]

given the fact that it's so simple to identify Lucee, I will reiterate my opinion that a Powered-By header, with an option to disable it, does not make Lucee less secure in any way.

Igal Sapir
Lucee Core Developer
Lucee.org

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CALbQ1omqjEVMDGeHYydy_BG60SbS%3DsMZvqbQaArQTaSYR27fZA%40mail.gmail.com.

[Adam Cameron]

On Tuesday, 31 March 2015 18:59:39 UTC+1, Igal wrote:

given the fact that it's so simple to identify Lucee, I will reiterate my opinion that a Powered-By header, with an option to disable it, does not make Lucee less secure in any way.

If someone - for some daft reason - wants to add an "x-powered-by" header to their responses they can.

But it's just shit house marketing, serving almost no purpose, so - seriously - why waste time with this? If Lucee was already adding it by default I'd be all for an E/R to be able to switch it off, but this is just a non-event of a suggestion, other than being a mild vector for exploitation.

To the ppl who advocate it... would you ever consider adding this sort of thing by hand? No. So why ask for it to be integrated into the platform?

This answer on Stack Overflow is what the link reference for X-POWERED-BY on wikipedia links to: http://stackoverflow.com/a/1288385/894061. Quote:

I know that PHP does this. I guess there is no real purpose, other than marketing and making it easier for script kiddies to find suitable victims. For PHP it's better to disable the flag entirely since it shows the PHP version and therefore makes the server more vulnerable to attacks.

Well... quite.

-- 

Adam

[Steven Durette]

Igal, 

Given that we need thing like lockdown guides and many of the comments I hear when people use them are "why didn't it install this way by default?" I would suffer that if you want to add it, then turn it OFF by default and then people can turn it on if they want to. 

That is from the "security" part of me. The other part of me says well if we are talking about moving so many things out to a plugin type where you add in just what you need, then why in the world would we add in something that will either edit http response codes or the html output of our carefully crafted web pages. 

If someone really wants it then they can add a header to their webserver, leave the app engine out of it. 

just my opinion. 

Steve

Sent from my iPhone

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/551AE068.9040804%40lucee.org.

[Jay B]

I always change mine to

 x-powered-by: Caffeine & Cookies.

[Risto]

I can't believe I'm the only one who thinks this site is crazy for calling everything a framework. You can't just go changing terminology. I've been around for more than 20 years an I've never heard anyone refer
to Perl as a "Framework". I also checked all my public sites over the last two years running cfml and not one of them lists that they are running CFML. Sites like this are bad for languages and technologies. In my opinion they
should take the site down.