Re: Removing ping/icmp from a network

[Ansgar -59cobalt- Wiechers <bugtraq () planetcobalt net>]

On 2008-04-04 Jason wrote:
> > Obscurity is NOT a replacement for due diligence. Which includes
> > hardening Internet-facing systems.
>
> You're absolutely correct. But if you've ever done any work outside of
> a few companies, you'd see just how often this is done... and we can
> recommend it until our face turns red but how often will it be done?

I am well aware that people are doing this kind of stuff. However, the
topic of this list is the basics of computer security. Which still does
not include obscurity, no matter how many people put their faith in it.

> > By running additional services you increase the code base that's
> > exposed to other networks.
>
> Your first statement did not mention exposure. I'm saying it doesn't
> increase the code base, it simply exposes it. I understand what you
> mean though.
>
> ICMP is part of the code base of the OS IP stack FYI. It's ALL
> software and sits in the kernel. So you ARE increasing the exposed
> code base by allowing the software module which controls ICMP to be
> exposed. Although the IP stack is already exposed, the ICMP module may
> have the vulnerability, possibly allowing it to be exposed for
> exploit, see below.

Indeed, the ICMP code may have exploitable vulnerabilities. However,
looking at the history of vulnerabilities in ICMP: how likely do you
think that is? Plus, unlike unnecessary services ICMP does serve a
purpose, which means that you should have a *good* reason for dropping
it. And no, the (not very likely) possibility that there *may* be an
exploitable vulnerability does not count as such.

[...]
> > External firewalls are exposed anyway (by definition). As are Internet-
> > facing servers. Your point being? You can't hide *and* expose a system
> > at the same time. Not to mention that IP simply doesn't have the option
> > to hide a system that's supposed to be accessible.
>
> Not hide completely, but reduce the exposure.

Again: whether your systems do or don't respond to ping DOES NOT CHANGE
ANYTHING AT ALL about their exposure. That's just wooly thinking.

> > Ummm... no, as a matter of fact you can't. You can try to establish a
> > connection to a TCP port, but that's completely different from ping.
>
> nmap options -PA / -PS
>
> tcping
>
> hping3
>
> These and a dozen others are just ways to check if a host is alive
> using TCP.
>
> If you want to argue semantics, it is considered a ping by most.

I'd prefer to call it "probe" rather than "ping", but you have a point
and I'm not here to discuss semantics, so I'll stick with ping for now.

[...]
> > > ICMP is not a required protocol for a web server, sorry. Convenient,
> > > yes. Required, no. If you believe it is then thats okay. That's the
> > > beauty of the Internet, everyone has an opinion.
> >
> > So basically you're justifying obscurity instead of security, because
> > there are so many stup^Wintellectually challenged admins out there?
> > What kind of argument do you think that is? You do realize that this
> > list is about security, don't you?
>
> I am not at all, please understand. What I am saying is that security
> by design comes first, and other steps might be required if some
> design is not immediately possible. Do you have any idea, ANY idea,
> how many organizations have difficulty integrating security into their
> business? To cite an example, a few companies could not install
> patches on their systems because their custom developed app was
> running a number of modules whose version wouldn't be supported if
> patches beyond a certain level were installed, so what, they are
> supposed to throw their support out the window and install the
> patches, possibly breaking a core app and bringing the business down?
> Or do they put some other measures in place to partially mitigate the
> risk for a time until the next version of the app comes out / is
> developed and supports the patches? You do realize that many networks
> are for businesses that use information systems as a means to
> accomplish their business goals, information systems is not most
> companies' business.

Ensuring the availability of the systems is one purpose of computer
security, and please don't tell me that this weren't a business
requirement. I know that many business people are reluctant to spend
money on appropriate security measures (at least until it bites them),
but that's no justification whatsoever. It also is no excuse at all for
establishing obscurity in place of security.

> And even if they do consider themselves hardened and secure, etc
> consider this:
>
> It doesn't take more than a few Google searches to find plenty of ways
> to use ICMP as a tunnel or find any number of worms (Welchia for one)
> which used ping to discover hosts. I mean there is a vast history of
> this, and although people believe the IP stack is well secured now,
> there was another vulnerability (and subsequent exploit to be sure)
> discovered against the Windows IP stack just a few months ago. It
> makes you wonder how many exploits are unknown.

Tunneling usually means outbound communication, which also means that
your security has already been compromised. And regarding Welchia: the
problem with that kind of worm is not hosts being pingable, but hosts
unnecessarily exposing services to other networks. Your point being?

> Check out MS08-001:
>
> http://www.microsoft.com/technet/security/Bulletin/MS08-001.mspx
>
> Covers a few known Windows IP stack issues, exploitable via ICMP as
> well, I might add (router discovery)... in fact it's apparently bad
> enough that a number of articles posted stated this could lead to the
> next big worm (a questionable statement, IMO). Remember patches
> against SQL slammer were available 4-6 months before the worm was
> written.

Quoting from the article:

| Windows Kernel TCP/IP/ICMP Vulnerability - CVE-2007-0066
| 
| A denial of service vulnerability exists in TCP/IP due to the way that
| Windows Kernel processes fragmented router advertisement ICMP queries.
| ICMP Router Discovery Protocol (RDP) is not enabled by default and is
| required in order to exploit this vulnerability.

This is a) merely a DoS condition, not something that allows for remote
code execution, and b) not exploitable in the default configuration.

The remote code execution vulnerability is in the IGMP handler, which is
something that indeed can be safely disabled unless you run something
that specifically requires IGMP.

> Now I don't necessarily believe that personally, but who knows. Yes it
> may need to be turned on, but at the same time, I wonder if there
> isn't another way to take advantage of this. No matter how good you
> might think you are, there's always someone out there better than you
> and with a lot more time on their hands.

Unless you can think of a way that's mere paranoia, which won't get us
anywhere as network admins/security people. Computer security is about
identifying/assessing attack scenarios and defining/implementing
appropriate countermeasures.

> Fact is so many people depend on the vulnerabilities and exploits they
> KNOW about, and I guarantee there are a ton of vulnerabilities and
> exploits that are not public knowledge.

Most certainly. However, that is no argument to disable something that
serves a purpose. It's just an argument to not run anything that
doesn't.

> So with ALL that being said, from my personal standpoint, I'd much
> rather err on the side of caution myself and don't really care if 'x'
> can't ping my web server anyway. Of course I don't think that someone
> who's web server I can ping is crazy, or that a web server reachable
> via ping is a big issue, but it is just another one of those little
> things that just isn't necessary.

Like I said before: paranoia doesn't help. Security is about knowing,
not about believing.

Regards
Ansgar Wiechers
-- 
"All vulnerabilities deserve a public fear period prior to patches
becoming available."
--Jason Coombs on Bugtraq