[Proftpd-user] rstatus response

[Michael Green]

Hello collective wisdom,

We have here:
* Server version: 1.3.5~rc3-2.1ubuntu2.1
* Client version: ncftp-3.2.5-7.el7.x86_64

My concern is the response to “rstatus” command from ncftp which shows the name of the server software:

ftp> debug <— Turned on debugging to see what command the client sends.
Debugging on (debug=1).
ftp> rstatus
---> STAT <— STAT is sent
211-Status of ‘ProFTPD’ <— somehow the client knows it is ProFTPD
211-Connected from XXX.XXX.XXX.XX (XXX.XXX.XXX.XX)
211-Logged in as ftp
211-TYPE: ASCII, STRUcture: File, Mode: Stream
211-Total bytes transferred for session: 126
211-No data connection
211 End of status
ftp> stat


I consider this a security risk.

My configuration has these directives among the rest:

#ServerName "Debian"
ServerIdent on "--------------------------------------------------------------------------------"

Any idea when exactly the server responds to the client with “ProFTPD” string? Is it immediately in response to STAT or some time earlier in the session?
How to eliminate?

—
Regards,
Michael

[TJ Saunders]

Post by Michael Green
My concern is the response to “rstatus” command from ncftp which shows
ftp> debug <— Turned on debugging to see what command the client sends.
Debugging on (debug=1).
ftp> rstatus
---> STAT <— STAT is sent
211-Status of ‘ProFTPD’ <— somehow the client knows it is ProFTPD
#ServerName "Debian"
ServerIdent on
"--------------------------------------------------------------------------------"
Any idea when exactly the server responds to the client with “ProFTPD”
string? Is it immediately in response to STAT or some time earlier in the
session?
How to eliminate?

Every <VirtualHost> (and the default "server config") has a server name,
which defaults to "ProFTPD". You can change this server name of the
ServerName directive, the one that is commented out in your config.
Thus:

ServerName Debian

With that enabled in your config, the STAT response should change to
look like:

ftp> rstatus
211-Status of ‘Debian’
...

Hope this helps!
TJ

[Michael Green]

Thanks, TJ.

I understand that without an active ServerName directive, the server code defaults to “ProFTPD”, and that in order to not have the name of the product exposed, ServerName directive has to be used.

What you response also made me realize is that the line that contains “ProFTPD” is also hardcoded as well as probably the rest of the response to ‘rstatus’. My concern now is that this whole response is a “giveaway” to a potential intruder because if a string (Status of “ServerName”) with specific structure appears in a particular place in the response to known command, one can deduce the product because only this product prints this in response to STAT. Unless RFC dictates that STAT is responded with this particular verbiage.

What do you think?

Post by TJ Saunders

Post by Michael Green
My concern is the response to “rstatus” command from ncftp which shows
ftp> debug <— Turned on debugging to see what command the client sends.
Debugging on (debug=1).
ftp> rstatus
---> STAT <— STAT is sent
211-Status of ‘ProFTPD’ <— somehow the client knows it is ProFTPD
#ServerName "Debian"
ServerIdent on
"--------------------------------------------------------------------------------"
Any idea when exactly the server responds to the client with “ProFTPD”
string? Is it immediately in response to STAT or some time earlier in the
session?
How to eliminate?

Every <VirtualHost> (and the default "server config") has a server name,
which defaults to "ProFTPD". You can change this server name of the
ServerName directive, the one that is commented out in your config.
ServerName Debian
With that enabled in your config, the STAT response should change to
ftp> rstatus
211-Status of ‘Debian’
...
Hope this helps!
TJ
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

[TJ Saunders]

Post by Michael Green
What you response also made me realize is that the line that contains
“ProFTPD” is also hardcoded as well as probably the rest of the response
to ‘rstatus’. My concern now is that this whole response is a “giveaway”
to a potential intruder because if a string (Status of “ServerName”) with
specific structure appears in a particular place in the response to known
command, one can deduce the product because only this product prints this
in response to STAT. Unless RFC dictates that STAT is responded with this
particular verbiage.
What do you think?

ProFTPD will respond to a STAT command only if the client has
authenticated, so it's a "giveaway" of information to users that you
have already allowed. (If you don't trust your users, then you have
other issues.)

This, combined with the ability to change that information via
ServerName, to me suggests that the "leak", if construed as such, is not
that large.

TJ

[Michael Green]

Well, my users are anonymous. So no, I don’t trust them.
I agree that this is not a huge security hole, but a way to customize that message to disguise the product identity would still be much appreciated.

Thanks.

Post by TJ Saunders

Post by Michael Green
What you response also made me realize is that the line that contains
“ProFTPD” is also hardcoded as well as probably the rest of the response
to ‘rstatus’. My concern now is that this whole response is a “giveaway”
to a potential intruder because if a string (Status of “ServerName”) with
specific structure appears in a particular place in the response to known
command, one can deduce the product because only this product prints this
in response to STAT. Unless RFC dictates that STAT is responded with this
particular verbiage.
What do you think?

ProFTPD will respond to a STAT command only if the client has
authenticated, so it's a "giveaway" of information to users that you
have already allowed. (If you don't trust your users, then you have
other issues.)
This, combined with the ability to change that information via
ServerName, to me suggests that the "leak", if construed as such, is not
that large.
TJ
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Unsubscribe problems?
http://www.proftpd.org/list-unsub.html

[Bob Friesenhahn]

Well, my users are anonymous. So no, I don’t trust them.
I agree that this is not a huge security hole, but a way to customize that message to disguise the product identity would still be much appreciated.

There are likely many other ways to identify the product besides this
string.

As far as I am aware, ProFTPd itself is not known to be a security
hazard. The operating system you are using may be a security hazard.

Bob

[TJ Saunders]

Post by Michael Green
Well, my users are anonymous. So no, I don’t trust them.
I agree that this is not a huge security hole, but a way to customize
that message to disguise the product identity would still be much
appreciated.

As mentioned, the ServerName directive can be used to customize that
information in STAT; it also changes the information appearing
elsewhere. So it sounds like actually using, rather than commenting
out, the ServerName directive is what you might try.

TJ

[Michael Green]

Yes, I’ve uncommented the directive and “ProFTPD" appearing in the output of STAT is no longer an issue.
But the fixed structure of the verbiage is still a concern for me, albeit not a big one.

And while still at this, I don’t want to make it look bigger than it is, but I tend to disagree with Bob on his assessment "ProFTPd itself is not known to be a security hazard. The operating system you are using may be a security hazard.”

Everything (the OS and the apps) is a potential hazard and the more I can do to reduce the risks on every level, the better. The fact that OS may have more bugs and holes than a particular product, doesn’t sound like a proper justification to me to not address concerns in the product even if the concerns are few and small.

Post by TJ Saunders

Post by Michael Green
Well, my users are anonymous. So no, I don’t trust them.
I agree that this is not a huge security hole, but a way to customize
that message to disguise the product identity would still be much
appreciated.

As mentioned, the ServerName directive can be used to customize that
information in STAT; it also changes the information appearing
elsewhere. So it sounds like actually using, rather than commenting
out, the ServerName directive is what you might try.
TJ

[Bob Friesenhahn]

Yes, I’ve uncommented the directive and “ProFTPD" appearing in the output of STAT is no longer an issue.
But the fixed structure of the verbiage is still a concern for me, albeit not a big one.

"Finger-printing" methods may still allow identifying software even
without obvious messages. A few bytes difference in protocol handling
or timing difference is often enough to make a positive
identification.

If a user is allowed to log in so that they are able to exercise many
operations, I suspect that there are many other ways to tell if
ProFTPd is being used vs the few other popular servers.

And while still at this, I don’t want to make it look bigger than it
is, but I tend to disagree with Bob on his assessment "ProFTPd
itself is not known to be a security hazard. The operating system
you are using may be a security hazard.”
Everything (the OS and the apps) is a potential hazard and the more
I can do to reduce the risks on every level, the better. The fact
that OS may have more bugs and holes than a particular product,
doesn’t sound like a proper justification to me to not address
concerns in the product even if the concerns are few and small.

Your concerns are certainly valid. It would be good to disable this
feature (even to the point of editing source code) and then try
various remote tools which already identify software and operating
systems to see if the issue (ability to identify the software) is
really resolved. Some tools are remarkably good at identifying
software and operating systems, particularly since there are not
really all that many choices to select from.

Bob