Trying to keep this calm and not a flame thread now.. But 'ANY' step which can be
taken to make a service less obvious is a step in the right direction. We all know
that if something is gonna get hacked, it will. But why decide that because of this
all the small little things should be left out? Sure, hiding the banner isn't going to
stop 80% of hacks and scans.. but the skript kiddies who are scanning for certain
MTA's with their l33t program aren't going to turn up your server if the banner
doesn't match something on their signature list. And when I refer to skript kiddies, I
mean those who think WinNuke is a powerful tool. They don't generally target certain
systems, they look for vulnerable systems.
A cracker will footprint a system and then hack it, this is the major danger out there
which will (IMHO) never be stopped.
Lee Rich
ICTS Security
Welsh Local Government Association
-----Original Message-----
From: Davide Libenzi <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Sent: 04/09/2002 23:03
Subject: [xmail] Re: greeting banner
On Wed, 4 Sep 2002, Lars Troen wrote:
>
> Shawn wrote:
> > Hmm, I have a vague recollection of Davide release a quick=20
> > fix like less
> > then 12 hours after a regular release -- I figured it was him=20
> > that found
> > a fixed the issues -- still 2 in how many years? How many other mail
> > vendors can say the same :-D
> >=20
>
> qmail & postfix.. atleast for remote exploits.. not sendmail, exchange, =
> notes, groupwise and others I guess.
>
> That xmail has not had many vulnerabilities the last few years doesn't =
> mean that xmail is flawless. Just look to apache httpd. Or sshd. Or the =
> OpenSSL lib. These were living for quite a few years without remote =
> exploits.
>
> I wish I could change the greeting banner in order to let potential =
> hackers know as little about my systems as possible. It's possible to =
> fool nmap's os detection and I guess most hackers move on to the next =
> system if they can't figure out much about your systems.
>
> Why do you think we get regular scans for bind versions? Also in bind =
> you can return bogus versions here without loosing functionality.=20
>
> Also it wouldn't break anything (else than not being RFC compliant) by =
> changing the banner. All extended mail options are still available =
> through ehlo.
>
> Quite a few programs let you alter greeting messages. Usually not with =
> commercial software, but enterprise firewalls can also do that. Pix for =
> instance automaticly filters out any such responses from the mailserver =
> (inserts 'X's in place for the message) while some others have built in =
> smtp secure proxies (Checkpoint/Raptor).
>
> So I'd say it's quite an accepted thing to do this and you're actually =
> gaining something from it too. I also can imagine it wouldn't be the =
> hardest thing on earth to implement such a feature.
I tried to stay out of this, but i couldn't resist. Hiding banners is the
most stupid and useless thing that one can do. It's so useless that is not
even funny. Do you really think that the attacker will become
kind-of-scared because it won't be able to detect the MTA and will pass to
something else ?
<hacker algorithm>
if port-25-open {
if banner == xmail {
shoot-xmail-exploits
} else if banner == exim {
shoot-exim-exploits
} else if ...
...
} else {
shoot-all-the-damn-exploits
}
}
</hacker algorithm>
And this is the smart version, the dumb one is to just shoot all known
exploits for the given port. More, you can differentiate MTAs only by
error responses if you want. An open port is a precious resource for an
hacker and he simply won't pass because the banner is anonymous.
About exploits, XMail is obviously not invulnerable. But suppose that a
code like this is present inside XMail :
void foo(void) {
char buffer[10];
...
read_from_socket(sock, buffer);
...
}
What the hacker can do ? To inject code he has to guess that stack
pointer, and this is easy for other softwares because you have simply to
try to make the program crash and look at the coredump ( or dr watson dump
). XMail has, at each thread creation, a random stack pointer movement
that with current values can assume 256 different positions. This means
that the attacker has less that 0.5% of probability to get it right. And
what will hapen if he won't get it right ? The program will crash ( 99.5%
of the times ) by generation a coredump and this will be sufficent for me
to know the exact point of failure. More, being XMail multi-threaded the
whole program will crash and the attacker won't have another immediate
opportunity to retry. This is not true with (x)inetd daemons where the
attacker can continuosly try the exploit. Hope this will clarify for
another couple of months.
- Davide
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
For general help: send the line "help" in the body of a message to
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line "unsubscribe xmail" in
the body of a message to [EMAIL PROTECTED]
For general help: send the line "help" in the body of a message to
[EMAIL PROTECTED]
