All the CISCO networking solutions contain Easter eggs, that allow you to see everything because you get full root. Haters insist on calling them backdoors of course.

If they are security risks, why are they not removed?

You can't expect a software distributor to be aware of all of the Easter eggs developers added to its software.

Even after communicating the fact to them several times, and one country or another asking the prison of some high executive. Those things are just too hard to keep track of.

I believe the person you are replying to is attempting humor.

I think this is really why we can't "have fun" anymore. Because bad actors exist and can exploit things being done "just for fun". I do wonder, however, how much of the "serious" nature comes from actual bad actors or from the security research community.

> I do wonder, however, how much of the "serious" nature comes from actual bad actors or from the security research community.

I think it’s hard to think of the problem that way.

These days* of course you have to worry about security on almost anything you work on. And when you do, the folks who think of security all the time are going to tell you to simplify your interfaces so they are easier to think about, then then armor them. What a pain!

But we do those things because of all the bad actors. The security recommendations are a consequence, not the cause.

* I grew up — literally — in a non-security environment: networked computers with no passwords or any other security. The only “protection” what would be called today kernel space memory barrier just to protect against bugs, and most machines didn’t have that. It was the late 70s and security was considered a barrier to hacking. I knew people working on security and frankly it seemed weird.

Counterpoint. In our org we'd eliminate pretty much every security incident if users would not download attachments on suspicious emails, give out their password and try and click on the monkey to win the iPad.

To quote James Mickens "most of the security reasearch community seems to be obssesed with avant-garde horrors such as the ability to induce a heart attack in those wearing pacemakers during a solar eclipse with a pringles can."

At this point it seems that most of it really is just security theater and most really security actually comes from proper training.

In my household back around Y2K era (95 - 05), I eliminated a large number of virus infections by having the computer that the kids used set up so them clicking on the AIM icon actually did an X connection over ssh to my Linux server to run GAIM (using Cygwin/X on the Windows side).

That quotation simply reflects what’s exciting enough to get attention.

And of course there are the theatrical password rotation and such that cause passwords to be written down in the first place.

But even in this comment stream someone asked who cares if the remote side learns the version number of the code you’re running, and somebody else wrote that security would not be a problem if users didn’t do what they considered foolish things. These pragmatic problems are where the risks lie.

Physical access to computers in the late 70s was decently secured. Most computers were at large businesses (typically with access through a lobby with a receptionist watching) or universities with access limited to students & faculty. So there was some security, not usually great, but few bad actors could get access, even across networks. As computers became more common physical-security-only stopped working well.

Indeed. Mysteriously, “firewall” devices later became popular even though they merely replicated the weaknesses of physical security.

Defense at depth is the only way to go, unfortunately.

It's more of a risk/reward thing. Any code on a networked computer has non-zero risk. And what's the reward... an engineer had fun at work today? That's not a very compelling argument in a business context.

I say this as someone who snuck an easter egg into our product at my last job. Yes, it was fun, but if I had gotten in trouble for it, I would have deserved it.

> I think this is really why we can't "have fun" anymore. Because bad actors exist and can exploit things being done "just for fun".

That's often how things works. With friends we joke around a lot because we know each other well and know there aren't bad actors. At work, I'm way more careful. If there were no cases of harassement, exploitation or things like that at work I may joke around more. But since they exist, I'm more careful. I don't want to harass people, be seen as an harasser, or create an atmosphere were harassers feel welcomed.

When bad actors exist, the way to show good will is to not act like them, so they can be quickly identified and removed.

MoTD and have fun all you want for people who should have access.

It looks like they were removed several years ago.

> Update 12-04-2017: This feature was removed in PHP 5.5.

This is precisely why it's useful for fingerprinting -- If you get this response, you know that an old, out of date version of PHP is in use.

The post says that Easter egg only works if 'expose_php' is set in php.ini, which will also report the PHP version in the X-Powered-By header of every response. So it doesn't seem to leak any information that wouldn't already be available.

Unfortunately it is (or at least was) enabled by default.

Question is what you gain by knowing the version. Better just fire your arsenal of attacks than waste time trying to figure this out as many sites will hide these things anyways.

By knowing the version, you can more efficiently determine which CVEs may apply, surely?

The arsenal of attacks includes "let's try and figure out server version", too.

Because if you know the version, it gives you a shortcut, and you can immediately switch to a smaller arsenal designed for that specific version.

On an individual basis it's sometimes hard to see the harm in this. But more specifically the problem with version identifiers is that attackers can scan across many servers, iterating which ones have a certain vulnerable version.

While a bit of an extreme scenario, I can imagine it being useful for high-level actors with their own private vulns which they'd like to keep on the down low unless absolutely necessary.

Exploiting a memory corruption vulnerability depends on the exact details of the software version and platform. Attempting the wrong exploit risks crashing the process, which might be noticed and investigated.

Not sure why you're being downvoted. Your question is reasonable and any attacker worth their salt will fire a full arsenal of all the CVE's at your environment regardless of version.

Hiding version numbers etc is an example of "Security through obscurity" and is a weak defence strategy:

https://en.wikipedia.org/wiki/Security_through_obscurity

An attacker worth their salt will most definitely not fire all their CVEs at risk of crashing the target process or leaving it in an undefined state.

And your second point is debatable. See defense in depth.