Port 113 - is it usefull for attackers ?
Oleg Letsinsky
Our server (FreeBSD 2.1.0-RELEASE) was under attack some days ago.
I'm not sure, that the attack is over. There's someone
who tries to gain an access to the port 113 from a certain
sites. I'd like to know, if this port can be used for
system hacking ? Or am I just a paranoid :) ?
/*****************************************************************
* You live and learn. Or you don't live long. *
* Lazarus Long *
* Oleg Letsinsky *
* E-Mail : a...@ultersys.ru *
****************************************************************/
Christophe Person
Oleg Letsinsky wrote:
>
> Our server (FreeBSD 2.1.0-RELEASE) was under attack some days ago.
> I'm not sure, that the attack is over. There's someone
> who tries to gain an access to the port 113 from a certain
> sites. I'd like to know, if this port can be used for
> system hacking ? Or am I just a paranoid :) ?
/etc/services:
auth 113/tcp authentication
(sometimes can be ident) There was a flaw in sendmail using identd a
little while ago. The latest sendmail 8.?.? fixed that...
Thomas H. Ptacek
Wed, 30 Oct 1996 09:54:30 -0600 chr...@dirac.bcm.tmc.edu:
>auth 113/tcp authentication
>(sometimes can be ident) There was a flaw in sendmail using identd a
>little while ago. The latest sendmail 8.?.? fixed that...
The 8.6.9 and 8.6.10 exploits, both of which involved Sendmail choking and
overwriting memory because of malformed identd responses, have nothing to
do with the identd on the target host. The exploit involves setting up a
modified identd local to the machine attempting the attack, which will
respond to queries with an appropriately unexpected long answer.
The issue to which you are referring should have been resolved as of
Sendmail 8.6.12, which is considerably older than 8.8.2, the most recent
release.
The only publically-acknowledged issue with identd (to my knowledge) is
that the service can be used to find the "owner" of any given program
bound to a port, which makes it a useful addition to portscanning tools.
--
-----------------------------------------------------------------------------
Tom Ptacek at The rdist Organization / exit(main(kfp->kargc, argv, environ));
------------------------------------------------[ tq...@rdist.org ]-----------
"If you're so special, why aren't you dead?"
Craig H. Rowland
On Wed, 30 Oct 1996, Oleg Letsinsky wrote:
> Our server (FreeBSD 2.1.0-RELEASE) was under attack some days ago.
> I'm not sure, that the attack is over. There's someone
> who tries to gain an access to the port 113 from a certain
> sites. I'd like to know, if this port can be used for
> system hacking ? Or am I just a paranoid :) ?
>
The ident protocol can be used to scan a system for active daemons and
determine what userid they are operating under. This is very useful for an
attacker who needs a certain process ownership of a daemon to have an
exploit work, but wants to be sure you are vulnerable before
trying to use it. It is also useful because it enables an attacker to
perform a port scan of a host and not have the actual daemons register a
connection (except of course for identd which often is set to not log
connects).
There are many programs available that do identd scans (identd-scan.c and
netcat come to mind). I personally recommend that identd (and many
other services) on all servers be disabled. It's usefulness is debatable
as a true identification protocol and provides too much information to
outsiders.
>
> /*****************************************************************
> * You live and learn. Or you don't live long. *
> * Lazarus Long *
> * Oleg Letsinsky *
> * E-Mail : a...@ultersys.ru *
> ****************************************************************/
>
>
-- Craig
crow...@psionic.com
Anders Thulin
In article <557e0f$20ik...@ultersys.ru>,
Oleg Letsinsky <a...@ultersys.ru> wrote:
>I'm not sure, that the attack is over. There's someone
>who tries to gain an access to the port 113 from a certain
>sites. I'd like to know, if this port can be used for
>system hacking ? Or am I just a paranoid :) ?
The Well Known Port Number list from IANA (usually available by FTP
where RFC's are found) lists all assigned ports.
113 is used for ident, as described in RFC 1413.
It's usually used in response to connection attempts to identify the
user who is trying to connect as far as the connecting system permits
such identification to be made.
--
Anders Thulin Anders...@lejonet.se 013 - 23 55 32
Telia Research AB, Teknikringen 2B, S-583 30 Linkoping, Sweden
D. J. Bernstein
Craig H. Rowland <crow...@vni.net> wrote:
> The ident protocol can be used to scan a system for active daemons and
> determine what userid they are operating under.
If you don't want other people to interpret your port 113 responses,
encrypt them.
> It's usefulness is debatable
How do you figure out which one of your users tried to break into the
White House mail server yesterday?
Does your OS have a connection-logging feature? Do you have the disk
space to log every connection without any hints from the remote end
saying that certain connections are important?
---Dan
Craig Rowland
On 31 Oct 1996, D. J. Bernstein wrote:
> Craig H. Rowland <crow...@vni.net> wrote:
> > The ident protocol can be used to scan a system for active daemons and
> > determine what userid they are operating under.
>
> If you don't want other people to interpret your port 113 responses,
> encrypt them.
If I have to worry about encrypting potentially damaging information
that a daemon voluntarily provides to any schmoe who asks, I probably
shouldn't be running it.
>
> > It's usefulness is debatable
>
> How do you figure out which one of your users tried to break into the
> White House mail server yesterday?
>
Identd responses are easily forged by anyone who has root privs on a
system, being such it's usefulness is debatable, not because it isn't a
good idea, but because the information it's supposed to (reliably) provide
is so easily spoofed. If it is an identification protocol, it needs to be
an identification protocol based on a strong cryptographic methodology
which it currently is _not_.
Finding out what users are misbehaving is _very_ easy to do if the remote
site provides times that connections took place. Using local system logs
such and accounting programs (last, ac, etc.) it is trivial to find the
culprit. I never rely on identd alone to finger out a particular user, all
information should be cross checked with local sources and logs. At most,
identd will get you in the right direction, but should never be used as
absolute proof.
> Does your OS have a connection-logging feature? Do you have the disk
> space to log every connection without any hints from the remote end
> saying that certain connections are important?
>
I don't understand how identd helps in this area even if it were enabled.
Every UNIX system I've used logs connections to the system from outside
sources. This includes the IP address and time. This is all you need.
Identd still requires that the sysadmin on the other system gives a hoot
about the hacking problem originating from their site. If they do care,
it's just as easy for them to use local sources to track the person.
If they don't care it doesn't matter if identd runs or not. As a sysadmin
I prefer not to run daemons that do not serve a truly useful purpose.
IMHO, identd in its current form does not serve a useful purpose, I'm
sorry we don't agree..
>---Dan
>
>
-- Craig
crow...@psionic.com
D. J. Bernstein
Craig Rowland <crow...@vni.net> wrote:
> On 31 Oct 1996, D. J. Bernstein wrote:
> > How do you figure out which one of your users tried to break into the
> > White House mail server yesterday?
> site provides times that connections took place.
You didn't answer the question.
200 of your users were logged on at 11:30 last night. One of them tried
to break into the White House mail server with the 8.8.0/8.8.1 F9 hole.
How do you find out which one it was?
A Secret Service computer expert is on the phone yelling at you (``This
is _very_ easy to do, eh? So why haven't you DONE it?'') and calling you
incompetent.
> Using local system logs
> such and accounting programs (last, ac, etc.) it is trivial to find the
> culprit.
Oh, really?
last tells you that there were 200 users logged on.
ac tells you that there were 500 processes running, including 100 called
telnet, 20 called irc, and 40 called a.out.
So who's the culprit?
I think I agree with the Secret Service's assessment of you.
> Identd still requires that the sysadmin on the other system gives a hoot
> about the hacking problem originating from their site.
We're talking about the hacking problem originating from _your_ site.
> If they do care,
> it's just as easy for them to use local sources to track the person.
What local sources? Which operating system are you using? Since when did
it log outgoing connections?
> If I have to worry about encrypting potentially damaging information
> that a daemon voluntarily provides to any schmoe who asks, I probably
> shouldn't be running it.
Nonsense. ``I must protect my logs'' does not mean ``I probably
shouldn't be keeping any logs.''
> Identd responses are easily forged by anyone who has root privs
All logs are easily forged by root. Are you going to argue that the
``usefulness'' of a log is ``debatable''?
Kerberos is easily broken by root on the server. (In fact, despite MIT's
claims to the contrary, it's easily broken by anyone who has previously
been root on the terminal where you're logging in.) Are you going to
argue that the ``usefulness'' of Kerberos is ``debatable''?
> If it is an identification protocol,
Historical note: the name ``identification'' was chosen by someone who
was trying to kill this protocol. (He failed.)
> I never rely on identd alone to finger out a particular user, all
> information should be cross checked with local sources and logs.
Encrypted ident responses are trustworthy, just like local logs.
> I don't understand how identd helps in this area even if it were enabled.
> Every UNIX system I've used logs connections to the system
Wake up: I'm talking about _outgoing_ connections.
---Dan
Craig Rowland
On 31 Oct 1996, D. J. Bernstein wrote:
> Craig Rowland <crow...@vni.net> wrote:
> > On 31 Oct 1996, D. J. Bernstein wrote:
> > > How do you figure out which one of your users tried to break into the
> > > White House mail server yesterday?
> > Finding out what users are misbehaving is _very_ easy to do if the remote
> > site provides times that connections took place.
>
> You didn't answer the question.
>
The question was answered in the original context asked:
(paraphrasing)
"If identd is running on my system, can it be used by attackers"
The answer is YES it can be used by attackers to gather information about
your site. The default configuration for identd does not use encrypted
replies so the vast majority of sites are vulnerable to this technique.
> 200 of your users were logged on at 11:30 last night. One of them tried
> to break into the White House mail server with the 8.8.0/8.8.1 F9 hole.
>
I don't know why the Whitehouse would run sendmail to talk to external
hosts to begin with, but to answer your question:
(please stand by while I engage my hypothetical-reality-warping system)
> How do you find out which one it was?
>
> A Secret Service computer expert is on the phone yelling at you (``This
> is _very_ easy to do, eh? So why haven't you DONE it?'') and calling you
> incompetent.
>
> > Using local system logs
> > such and accounting programs (last, ac, etc.) it is trivial to find the
> > culprit.
>
> Oh, really?
>
> last tells you that there were 200 users logged on.
>
lastcomm tells you what commands they were executing and at what times...
> ac tells you that there were 500 processes running, including 100 called
> telnet, 20 called irc, and 40 called a.out.
>
certainly a possibility...Since we are in the hypothetical realm though
why don't I just initiate a SYN attack against port 113 of the system I'm
hacking from so the port is dead when it is queried? (seeing as how our
hacker is hitting the whitehouse he would have thought of this of course)
>
> I think I agree with the Secret Service's assessment of you.
Getting nasty aren't we? I'm here trying to establish how identd can be
used as leverage against a site to gain information and you have no other
recourse but to call me incompetent? Or is that what your ident server
told you?
>
> > Identd still requires that the sysadmin on the other system gives a hoot
> > about the hacking problem originating from their site.
>
> We're talking about the hacking problem originating from _your_ site.
The original question was talking about hacking coming from an OUTSIDE
site.
>
> > If they do care,
> > it's just as easy for them to use local sources to track the person.
>
> What local sources? Which operating system are you using? Since when did
see: man syslog, man ac, man sa, man last, man lastcomm, TCP wrapper, etc.
> it log outgoing connections?
Of course most systems do not do this, this is typically a feature only
found in firewalls. You may have me here...
>
> > If I have to worry about encrypting potentially damaging information
> > that a daemon voluntarily provides to any schmoe who asks, I probably
> > shouldn't be running it.
>
> Nonsense. ``I must protect my logs'' does not mean ``I probably
> shouldn't be keeping any logs.''
The context above refers to daemons that supply public information that is
sensitive. I consider daemons such as finger and identd to supply too much
information to outsiders and I feel it is a very good idea to disable
them. I additionally encourage the disabling of the VRFY and EXPN
commands for sendmail, and a host of other changes to systems to deny
information to outsiders. We obviously have a different point of view on
the subject so you go your direction and I'll go mine.
We are not talking about logs here. We are talking about using a server
daemon to gain information about a target host. Read the original
question. I am a strong proponent of keeping good auditing trails and
denying information to outsiders that is not necessary.
>
> > Identd responses are easily forged by anyone who has root privs
>
> All logs are easily forged by root. Are you going to argue that the
> ``usefulness'' of a log is ``debatable''?
>
> Kerberos is easily broken by root on the server. (In fact, despite MIT's
> claims to the contrary, it's easily broken by anyone who has previously
> been root on the terminal where you're logging in.) Are you going to
> argue that the ``usefulness'' of Kerberos is ``debatable''?
This is an apples to oranges comparison. I'm not going to argue about this
here because it is too far out of context to be useful..
>
> > If it is an identification protocol,
>
> Historical note: the name ``identification'' was chosen by someone who
> was trying to kill this protocol. (He failed.)
>
> > I never rely on identd alone to finger out a particular user, all
> > information should be cross checked with local sources and logs.
>
> Encrypted ident responses are trustworthy, just like local logs.
>
Oh, You mean encrypted identd responses like the ones from your server
koobera.math.uic.edu. You mean identd responses like THIS:
crowland:~> identd-scan koobera.math.uic.edu 20 100
Port: 21 Service: ftp Userid: :root
Port: 25 Service: smtp Userid: :qmaild
Port: 53 Service: domain Userid: :named
...
Yep, look encrypted to me alright...I'm sure you are absolutely right that
they are trustworthy, and that the qmaild account is in fact running your
mailer just as identd says...nice to know...
> > I don't understand how identd helps in this area even if it were enabled.
> > Every UNIX system I've used logs connections to the system
>
> Wake up: I'm talking about _outgoing_ connections.
>
I'm awake....but the conversation is putting me to sleep...
> ---Dan
>
-- Craig
crow...@psionic.com
Jacques Distler
In article <Pine.BSI.3.95.961031...@hq.vni.net>, Craig
Rowland <crow...@vni.net> wrote:
>The answer is YES it can be used by attackers to gather information about
>your site. The default configuration for identd does not use encrypted
>replies so the vast majority of sites are vulnerable to this technique.
Who the hell cares what the "default" configuration is? Put
ident stream tcp nowait root /usr/local/etc/identd identd -C
in you inetd.conf, and presumably, you will go back to being able to sleep
nights.
> . . .
>The context above refers to daemons that supply public information that is
>sensitive. I consider daemons such as finger and identd to supply too much
>information to outsiders and I feel it is a very good idea to disable
>them.
Or, at least, tailor the information that they do provide.
But, if you run identd with the -C flag, what information ARE you
providing to a would-be attacker?
Jacques Distler
D. J. Bernstein
I asked Rowland how he would figure out, without identd, which of his
users tried to break into the White House mail server last night.
He claimed it was easy. Bullshit.
Next he claimed that he could figure it out with wtmp and acct.
To illustrate how stupid that claim was, I gave an example of what those
logs might show: 200 users logged in at the instant of the attack; 100
processes running called telnet; 20 called irc; and 40 called a.out.
Craig Rowland <crow...@vni.net> wrote:
> certainly a possibility...
Indeed. So how do you figure out who did it?
When are you going to admit that you can't answer the question?
> I don't know why the Whitehouse would run sendmail
They don't; that's why your user failed to break in. Now stop dodging
the question.
> why don't I just initiate a SYN attack against port 113 of the system
That problem has been solved. If the system is using SYN cookies, your
attack will accomplish nothing. Stop dodging the question.
> see: man syslog, man ac, man sa, man last, man lastcomm, TCP wrapper, etc.
Sorry, you're just repeating yourself. The fact is that none of those
logs contain the information you need.
> Getting nasty aren't we?
No. ``Incompetent'' is a remarkably polite term for a sysadmin who (1)
can't figure out what his users were doing and (2) refuses to admit it.
> I consider daemons such as finger and identd to supply too much
> information to outsiders
For sites where usernames are secret, that's a reasonable view. That's
why some people encrypt their port 113 responses.
> Oh, You mean encrypted identd responses like the ones from your server
> koobera.math.uic.edu.
Nope. That server is purely for advertising.
---Dan
Thomas H. Ptacek
Thu, 31 Oct 1996 13:30:41 -0500 crow...@vni.net:
>Identd responses are easily forged by anyone who has root privs on a
>system, being such it's usefulness is debatable, not because it isn't a
>good idea, but because the information it's supposed to (reliably) provide
>is so easily spoofed. If it is an identification protocol, it needs to be
>an identification protocol based on a strong cryptographic methodology
>which it currently is _not_.
I don't get this at all.
Anyone with root creds on any arbitrary machine can defeat any
accountability measures that exist between that arbitrary machine and the
rest of the net. Logs (wtmp, utmp, last, lastcomm, ac, syslog, whatever)
don't get you any further than identd does when the person involved in the
mischief can transperantly edit them under your nose.
Assume that if root is broken on your machine, you're fucked.
That said, in the presence of systems that potentially HAVEN'T been
entirely comprimised, identd allows me to find out who's doing what, in a
morass of users. As an admin of a fairly active ISP, I can say it's a
convenient out to be able to answer irate admins with "well, did your
daemon do an ident lookup to find out who it was?".
This is surprisingly useful. =)
identd can't solve every problem on the net. It's not an authentication
protocol and wasn't intended as such. It's a simple little utility program
that allows large, active sites to single out users misusing the system.
----------------
Thomas Ptacek at EnterAct, L.L.C., Chicago, IL [tq...@enteract.com]
----------------
exit(main(kfp->kargc, argv, environ));