4:01 p.m.
>On Mon, 02 Aug 2004 12:21:01 -0700, Ow Mun Heng
<Ow.Mun.Heng(a)wdc.com> wrote:
>This was in my logs last night at 11.56pm.
Aug 2 03:21:18 ciscy sshd[27030]: Failed password for illegal user test from
::ffff:69.59.166.236 port 41532 ssh2
Aug 2 03:21:21 ciscy sshd[27032]: Failed password for illegal user guest from
::ffff:69.59.166.236 port 41714 ssh2
Seems to be coming from San Fransisco...
tracert 69.59.166.236
[snip]
8 74 ms 71 ms 70 ms so-10-0.ipcolo1.SanFranciso1.Level3.net
[4.68.112.234]
9 73 ms 72 ms 70 ms unknown.Level3.net [63.211.150.226]
10 74 ms 72 ms 72 ms border1-ge0-0-0.sfo.servepath.net
[209.213.192.123]
11 76 ms 72 ms 72 ms border-core1-pos0-1.sfo2.servepath.net
[216.93.189.34]
12 75 ms 71 ms 72 ms access1-ge0-1-5.sfo2.servepath.net
[69.59.136.50]
13 75 ms 71 ms 72 ms customer-reverse-entry.69.59.166.236
[69.59.166.236]
--
Steve
The fact that a user and password is getting flagged indicates that the
hacker is getting past your /etc/hosts.deny file. I keep my ssh access
shut down except for IP address ranges I am expecting. I realize this is
not possible in all cases, but stopping the hacker before they get a login
prompt is in my opinion a preferred situation.
4:57 p.m.
New subject: MORE SSH Hacking: heads-up
On Mon, 2004-08-02 at 16:01, STYMA, ROBERT E (ROBERT) wrote:
>>On Mon, 02 Aug 2004 12:21:01 -0700, Ow Mun Heng
<Ow.Mun.Heng(a)wdc.com> wrote:
>
>>This was in my logs last night at 11.56pm.
>
>
>Aug 2 03:21:18 ciscy sshd[27030]: Failed password for illegal user test from
>::ffff:69.59.166.236 port 41532 ssh2
>Aug 2 03:21:21 ciscy sshd[27032]: Failed password for illegal user guest from
>::ffff:69.59.166.236 port 41714 ssh2
>
>Seems to be coming from San Fransisco...
>
>
The fact that a user and password is getting flagged indicates that the
hacker is getting past your /etc/hosts.deny file. I keep my ssh access
shut down except for IP address ranges I am expecting. I realize this is
not possible in all cases, but stopping the hacker before they get a login
prompt is in my opinion a preferred situation.
Yeah, but you may as well firewall the world. This seems to be
everywhere.
And one such place is at the building I'll start guarding this Wed
starting at 2200-0600. It's a large black piece of telecommunications
equipment. I just happened to see the label when on the orientation
tour.
I told the bank liason, 'You're gonna think I'm the biggest geek
you've ever met, but there's an attack on this equipment right now." He
looked at me, uncomprehendingly, like cows at a passing train.
I really hate being on the outside...
--
------------------------------------------------------------------------
Brian Fahrländer Christian, Conservative, and Technomad
Evansville, IN http://www.fahrlander.net
ICQ 5119262
AIM: WheelDweller
------------------------------------------------------------------------
10:03 a.m.
New subject: MORE SSH Hacking: heads-up
On 08/02/2004 05:57 PM, Brian Fahrlander wrote:
On Mon, 2004-08-02 at 16:01, STYMA, ROBERT E (ROBERT) wrote:
>>>On Mon, 02 Aug 2004 12:21:01 -0700, Ow Mun Heng <Ow.Mun.Heng(a)wdc.com>
wrote:
>>>
>>>
>>>This was in my logs last night at 11.56pm.
>>>
>>>
>>Aug 2 03:21:18 ciscy sshd[27030]: Failed password for illegal user test from
>>::ffff:69.59.166.236 port 41532 ssh2
>>Aug 2 03:21:21 ciscy sshd[27032]: Failed password for illegal user guest from
>>::ffff:69.59.166.236 port 41714 ssh2
>>
>>Seems to be coming from San Fransisco...
>>
>>
>>
>>
>The fact that a user and password is getting flagged indicates that the
>hacker is getting past your /etc/hosts.deny file. I keep my ssh access
>shut down except for IP address ranges I am expecting. I realize this is
>not possible in all cases, but stopping the hacker before they get a login
>prompt is in my opinion a preferred situation.
>
>
Yeah, but you may as well firewall the world. This seems to be
everywhere.
So use hosts.allow instead, and specify the few particular hosts that
are allowed to attempt to connect. Everyone else will be summarily
rejected. (Firewalling the world is not a bad option, either).
10:22 a.m.
New subject: MORE SSH Hacking: heads-up
On Wed, 04 Aug 2004 11:03:33 -0400, Matt Morgan
<matt.morgan-fedora-list(a)brooklynmuseum.org> wrote:
On 08/02/2004 05:57 PM, Brian Fahrlander wrote:
>On Mon, 2004-08-02 at 16:01, STYMA, ROBERT E (ROBERT) wrote:
>
>
>>>>On Mon, 02 Aug 2004 12:21:01 -0700, Ow Mun Heng
<Ow.Mun.Heng(a)wdc.com> wrote:
>>>>
>>>>
>>>>This was in my logs last night at 11.56pm.
>>>>
>>>>
>>>Aug 2 03:21:18 ciscy sshd[27030]: Failed password for illegal user test
from
>>>::ffff:69.59.166.236 port 41532 ssh2
>>>Aug 2 03:21:21 ciscy sshd[27032]: Failed password for illegal user guest
from
>>>::ffff:69.59.166.236 port 41714 ssh2
>>>
>>>Seems to be coming from San Fransisco...
>>>
>>>
>>>
>>>
>>The fact that a user and password is getting flagged indicates that the
>>hacker is getting past your /etc/hosts.deny file. I keep my ssh access
>>shut down except for IP address ranges I am expecting. I realize this is
>>not possible in all cases, but stopping the hacker before they get a login
>>prompt is in my opinion a preferred situation.
>>
>>
>
> Yeah, but you may as well firewall the world. This seems to be
>everywhere.
>
>
>
So use hosts.allow instead, and specify the few particular hosts that
are allowed to attempt to connect. Everyone else will be summarily
rejected. (Firewalling the world is not a bad option, either).
take a look of this.
http://www.dshield.org/port_report.php?port=22&recax=1&tarax=2&am...
10:54 a.m.
New subject: MORE SSH Hacking: heads-up
On Aug 4, 2004 at 11:03, Matt Morgan in a soothing rage wrote:
[...]
So use hosts.allow instead, and specify the few particular hosts that
are allowed to attempt to connect. Everyone else will be summarily
rejected. (Firewalling the world is not a bad option, either).
Does SSH use tcp
wrappers on FC? If no, then modifying hosts.allow
and/or hosts.deny would be futile. If you have less than three
users connecting to your machine using ssh, I would just add
those users to the AllowUsers directive, else create a group and
add the users to it then use the AllowGroups directive.
N.Emile...
--
Registered Linux User # 125653 (http://counter.li.org)
Switch to: http://www.speakeasy.net/refer/190653
Unix is a Registered Bell of AT&T Trademark Laboratories.
-- Donn Seeley
11:45:04 up 37 days, 5:00, 4 users, load average: 0.00, 0.01, 0.00
12:45 p.m.
New subject: MORE SSH Hacking: heads-up
On Wed, Aug 04, 2004 at 11:54:03AM -0400, ne... wrote:
On Aug 4, 2004 at 11:03, Matt Morgan in a soothing rage wrote:
[...]
>So use hosts.allow instead, and specify the few particular hosts that
>are allowed to attempt to connect. Everyone else will be summarily
>rejected. (Firewalling the world is not a bad option, either).
Does SSH use tcp wrappers on FC? If no, then modifying hosts.allow
and/or hosts.deny would be futile. If you have less than three
users connecting to your machine using ssh, I would just add
those users to the AllowUsers directive, else create a group and
add the users to it then use the AllowGroups directive.
Yes, FC has tcp wrapper-enabled sshd. Not using the hosts.access files to
add another layer of security is foolhardy, IMO.
--
Jack Bowling
mailto: jbinpg(a)shaw.ca
12:06 a.m.
New subject: MORE SSH Hacking: heads-up
Unfortunately I cannot lock my SSH source hosts as they are always
different and I got tired
of constantly blocking at my firewall.
Worked up swatch this config below to modify the host IPTABLES and drop
traffic if root was attempted
or if a non existent user was provided.
For those not familiar with swatch you can get it here:
http://swatch.sourceforge.net/
Make sure you get 3.0.8 because "exec" was not working for me in the
newer versions.
good luck
#start
watchfor /sshd.*: Failed password for root from/
mail=myaddress,subject=Root_Login_Attempt
exec /sbin/iptables -I INPUT -i eth0 -s $11 -d 0/0 -p tcp
--dport 22 -j DROP
watchfor /sshd.*: Illegal user/
mail=myaddress,subject=Illegal_user_attempt
exec /sbin/iptables -I INPUT -i eth0 -s $10 -d 0/0 -p tcp
--dport 22 -j DROP
#end
On Wed, 2004-08-04 at 13:45, Jack Bowling wrote:
On Wed, Aug 04, 2004 at 11:54:03AM -0400, ne... wrote:
> On Aug 4, 2004 at 11:03, Matt Morgan in a soothing rage wrote:
>
> [...]
> >So use hosts.allow instead, and specify the few particular hosts that
> >are allowed to attempt to connect. Everyone else will be summarily
> >rejected. (Firewalling the world is not a bad option, either).
> Does SSH use tcp wrappers on FC? If no, then modifying hosts.allow
> and/or hosts.deny would be futile. If you have less than three
> users connecting to your machine using ssh, I would just add
> those users to the AllowUsers directive, else create a group and
> add the users to it then use the AllowGroups directive.
Yes, FC has tcp wrapper-enabled sshd. Not using the hosts.access files to
add another layer of security is foolhardy, IMO.
--
Jack Bowling
mailto: jbinpg(a)shaw.ca
10:06 a.m.
New subject: MORE SSH Hacking: heads-up
Am Mo, den 09.08.2004 schrieb Dave Rinker um 7:06:
For those not familiar with swatch you can get it here:
http://swatch.sourceforge.net/
Make sure you get 3.0.8 because "exec" was not working for me in the
newer versions.
#start
watchfor /sshd.*: Failed password for root from/
mail=myaddress,subject=Root_Login_Attempt
exec /sbin/iptables -I INPUT -i eth0 -s $11 -d 0/0 -p tcp
--dport 22 -j DROP
watchfor /sshd.*: Illegal user/
mail=myaddress,subject=Illegal_user_attempt
exec /sbin/iptables -I INPUT -i eth0 -s $10 -d 0/0 -p tcp
--dport 22 -j DROP
#end
swatch is certainly a nice tool to automatically observe logfiles and
react on specific occasions. See i.e.
http://www.fedoranews.org/ghenry/swatch/
Short comment on above example by Dave: be careful to not exclude
yourself from access on a remote system! This is easily done with above
code: first case - you mistype your root's password; second case - you
mistype your username.
Alexander
--
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.7-1.494.2.2smp
Serendipity 17:00:50 up 5 days, 10:28, load average: 0.22, 0.21, 0.18
11:30 p.m.
New subject: MORE SSH Hacking: heads-up
I agree with both comments but recommend that you disable the ability of
root to login at all. Users can always su to root.
Howto here: (Fedora is /etc/ssh/sshd_config)
http://www.karkomaonline.com/article.php?story=20030803200809356
On Mon, 2004-08-09 at 11:06, Alexander Dalloz wrote:
Am Mo, den 09.08.2004 schrieb Dave Rinker um 7:06:
> For those not familiar with swatch you can get it here:
> http://swatch.sourceforge.net/
> Make sure you get 3.0.8 because "exec" was not working for me in the
> newer versions.
> #start
>
> watchfor /sshd.*: Failed password for root from/
> mail=myaddress,subject=Root_Login_Attempt
> exec /sbin/iptables -I INPUT -i eth0 -s $11 -d 0/0 -p tcp
> --dport 22 -j DROP
>
> watchfor /sshd.*: Illegal user/
> mail=myaddress,subject=Illegal_user_attempt
> exec /sbin/iptables -I INPUT -i eth0 -s $10 -d 0/0 -p tcp
> --dport 22 -j DROP
>
> #end
swatch is certainly a nice tool to automatically observe logfiles and
react on specific occasions. See i.e.
http://www.fedoranews.org/ghenry/swatch/
Short comment on above example by Dave: be careful to not exclude
yourself from access on a remote system! This is easily done with above
code: first case - you mistype your root's password; second case - you
mistype your username.
Alexander
7:54 a.m.
New subject: MORE SSH Hacking: heads-up
Am Di, den 10.08.2004 schrieb Dave Rinker um 6:30:
I agree with both comments but recommend that you disable the ability
of
root to login at all. Users can always su to root.
That has the severe downside, that if someone got on the system as an
unprivileged user he could sniff while you are su'ing to root, which is
not successful if you ssh in as root using publick key authentication
rather than password authentication.
Alexander
--
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.7-1.494.2.2smp
Serendipity 14:52:41 up 6 days, 8:20, load average: 0.38, 0.46, 0.74
8:12 a.m.
New subject: MORE SSH Hacking: heads-up
On Tue, 2004-08-10 at 08:54, Alexander Dalloz wrote:
Am Di, den 10.08.2004 schrieb Dave Rinker um 6:30:
> I agree with both comments but recommend that you disable the ability of
> root to login at all. Users can always su to root.
That has the severe downside, that if someone got on the system as an
unprivileged user he could sniff while you are su'ing to root, which is
not successful if you ssh in as root using publick key authentication
rather than password authentication.
Alexander
Your saying that if you use ssh2 to connect to a server and the su to
root that they can sniff your root password?
I don't think that would work.
The main reason I always suggest people login with a normal user ID and
then su to root if needed is so there is an audit trail on the servers.
I can see who actually logged in and jumped to root instead of just
seeing that someone that knew root logged in.
And true, someone with root privileges could attempt to cover their
tracks by mucking with the log files.
--
Scot L. Harris <webid(a)cfl.rr.com>
10:02 a.m.
New subject: MORE SSH Hacking: heads-up
On Tue, 2004-08-10 at 09:12, Scot L. Harris wrote:
On Tue, 2004-08-10 at 08:54, Alexander Dalloz wrote:
> Am Di, den 10.08.2004 schrieb Dave Rinker um 6:30:
>
> > I agree with both comments but recommend that you disable the ability of
> > root to login at all. Users can always su to root.
>
> That has the severe downside, that if someone got on the system as an
> unprivileged user he could sniff while you are su'ing to root, which is
> not successful if you ssh in as root using publick key authentication
> rather than password authentication.
>
> Alexander
Your saying that if you use ssh2 to connect to a server and the su to
root that they can sniff your root password?
I don't think that would work.
The main reason I always suggest people login with a normal user ID and
then su to root if needed is so there is an audit trail on the servers.
I can see who actually logged in and jumped to root instead of just
seeing that someone that knew root logged in.
And true, someone with root privileges could attempt to cover their
tracks by mucking with the log files.
--
Scot L. Harris <webid(a)cfl.rr.com>
I believe what he is saying is that if
someone is already sniffing, then
they will get the root password.
--
jludwig <wralphie(a)comcast.net>
10:38 a.m.
New subject: MORE SSH Hacking: heads-up
On Tue, 2004-08-10 at 11:02, jludwig wrote:
I believe what he is saying is that if someone is already sniffing,
then
they will get the root password.
--
jludwig <wralphie(a)comcast.net>
But if you connected via ssh2 the password for root as well everything
else would already be encrypted.
--
Scot L. Harris <webid(a)cfl.rr.com>
11:18 a.m.
New subject: MORE SSH Hacking: heads-up
jludwig wrote:
On Tue, 2004-08-10 at 09:12, Scot L. Harris wrote:
>On Tue, 2004-08-10 at 08:54, Alexander Dalloz wrote:
>
>
>>Am Di, den 10.08.2004 schrieb Dave Rinker um 6:30:
>>
>>
>>
>>>I agree with both comments but recommend that you disable the ability of
>>>root to login at all. Users can always su to root.
>>>
>>>
>>That has the severe downside, that if someone got on the system as an
>>unprivileged user he could sniff while you are su'ing to root, which is
>>not successful if you ssh in as root using publick key authentication
>>rather than password authentication.
>>
>>Alexander
>>
>>
>Your saying that if you use ssh2 to connect to a server and the su to
>root that they can sniff your root password?
>
>I don't think that would work.
>
>The main reason I always suggest people login with a normal user ID and
>then su to root if needed is so there is an audit trail on the servers.
>I can see who actually logged in and jumped to root instead of just
>seeing that someone that knew root logged in.
>
>And true, someone with root privileges could attempt to cover their
>tracks by mucking with the log files.
>
>--
>Scot L. Harris <webid(a)cfl.rr.com>
>
>
I believe what he is saying is that if someone is already sniffing, then
they will get the root password.
IN that case might I respectfully suggest that he's wrong. If you
connect via ssh then all traffic between the ssh client and the server
is encrypted. So it doesn't matter what is typed in the client -
sniffing will only give gobblegook.
JDL
11:43 a.m.
New subject: MORE SSH Hacking: heads-up
Am Do, den 12.08.2004 schrieb John Lagrue um 18:18:
>>>That has the severe downside, that if someone got on the
system as an
>>>unprivileged user he could sniff while you are su'ing to root, which is
>>>not successful if you ssh in as root using publick key authentication
>>>rather than password authentication.
>>Your saying that if you use ssh2 to connect to a server and
the su to
>>root that they can sniff your root password?
>I believe what he is saying is that if someone is already
sniffing, then
>they will get the root password.
IN that case might I respectfully suggest that he's wrong. If you
connect via ssh then all traffic between the ssh client and the server
is encrypted. So it doesn't matter what is typed in the client -
sniffing will only give gobblegook.
JDL
I was not speaking about the network transfer between client and server.
I thought this was obvious. I was speaking about the possibility to
locally, on the SSHD system itself, to sniff password entries when
running "su".
Alexander
--
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.7-1.494.2.2smp
Serendipity 18:41:21 up 8 days, 12:09, load average: 1.17, 1.36, 1.29
12:07 p.m.
New subject: MORE SSH Hacking: heads-up
I was not speaking about the network transfer between client and
server. I
thought this was obvious. I was speaking about the possibility to locally,
on the SSHD system itself, to sniff password entries when running "su".
Alexander
Than that wouldn't be 'sniffing' would it?
Sniffing pertains to the network.. a 'su' doesn't use any network sockets.
You are talking about tracing their processes.. and a normal user can't do
that to another user.
An already logged in user ALSO can't do it, because you can't trace SUID
binaries..
try it 'strace su'.
You could trojan the su, by putting a 'su' in the path before the system su,
and taking their password, recording it, and then passing it to the system
'su'.. but you'd still need to be that user (or root of course, but if
you're
root.. why would you care?)
Lastly, you might be able to record it via injected modules using LD_PRELOAD..
But i've never researched this method in depth.. You can easily use
LD_PRELOAD though to bypass restricted shells. (Nothing to do with this).
12:19 p.m.
New subject: MORE SSH Hacking: heads-up
An already logged in user ALSO can't do it, because you can't
trace SUID
binaries..
try it 'strace su'.
Sorry, let me be more specific on this:
you can't remotely attach to it..
'strace su' in one term, strace -p $PID in another.. You'll get an
'operation not permitted'
further, if you 'strace' su, sudo, or anything else.. it wont run with root
permissions, it'll run with the permissions of the user who ran strace.
12:21 p.m.
New subject: MORE SSH Hacking: heads-up
you can't remotely attach to it..
'strace su' in one term, strace -p $PID in another.. You'll get an
'operation not permitted'
haha.. Sorry for all of the extra list traffic, but I wanted to correct this
as well before people may try and think I'm crazy.
Don't 'strace su' in one term.. just 'su' in one term.. and then try
to attach
to it with strace in another term.
further, if you 'strace' su, sudo, or anything else.. it wont run with root
permissions, it'll run with the permissions of the user who ran strace.
Again, apologizes on having to send two extra messages.
12:30 p.m.
New subject: MORE SSH Hacking: heads-up
Am Do, den 12.08.2004 schrieb netmask um 19:07:
> I was not speaking about the network transfer between client and
server. I
> thought this was obvious. I was speaking about the possibility to locally,
> on the SSHD system itself, to sniff password entries when running "su".
> Alexander
Than that wouldn't be 'sniffing' would it?
Sniffing pertains to the network.. a 'su' doesn't use any network sockets.
To my knowledge the word sniffing does not only belong to observing
network traffic. See i.e.
http://www.seifried.org/security/articles/20020126-keyboard-sniffing.html or
http://www.wired.com/news/privacy/0,1848,49455,00.html.
You are talking about tracing their processes.. and a normal user
can't do
that to another user.
An already logged in user ALSO can't do it, because you can't trace SUID
binaries..
try it 'strace su'.
You could trojan the su, by putting a 'su' in the path before the system su,
and taking their password, recording it, and then passing it to the system
'su'.. but you'd still need to be that user (or root of course, but if
you're
root.. why would you care?)
Lastly, you might be able to record it via injected modules using LD_PRELOAD..
But i've never researched this method in depth.. You can easily use
LD_PRELOAD though to bypass restricted shells. (Nothing to do with this).
Well, you are right in may aspects. Maybe I was too short with my
comment. I did not say and didn't want to say that logging in as normal
user and then su to root is insecure at all. I just wanted to say that
it weakens the root login, against the possibility to use public key
authentication with SSH login. Not more, not less. I am no hacker nor
cracker, so I have no proof of concept for using the possibility to
"listen" to the input a user makes when su'ing. Again: it would be a
local hack. I am not speaking about decrypting the SSH connection,
either established by password auth nor by pubkey auth. The "weak" point
is the local system, given the attacker has local unprivileged user
permissions.
Alexander
--
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.7-1.494.2.2smp
Serendipity 19:22:26 up 8 days, 12:50, load average: 1.52, 1.74, 1.70
12:52 p.m.
New subject: MORE SSH Hacking: heads-up
To my knowledge the word sniffing does not only belong to observing
network
traffic. See i.e.
http://www.seifried.org/security/articles/20020126-keyboard-sniffing.html or
http://www.wired.com/news/privacy/0,1848,49455,00.html.
True.. I guess in the world of corporate America that I work in, on our
networks and under ITIL we use 'sniffing' only to pertain to packets.
I would call keyboard 'sniffing' to be logging, interception, etc.. but yes,
in a way.. you're sticking your nose out there and seeing what goes by... That
was completely my mistake.
> Lastly, you might be able to record it via injected modules using
LD_PRELOAD..
> But i've never researched this method in depth.. You can easily use
> LD_PRELOAD though to bypass restricted shells. (Nothing to do with this).
Well, you are right in may aspects. Maybe I was too short with my
comment. I did not say and didn't want to say that logging in as normal
user and then su to root is insecure at all. I just wanted to say that
it weakens the root login, against the possibility to use public key
authentication with SSH login. Not more, not less. I am no hacker nor
cracker, so I have no proof of concept for using the possibility to
"listen" to the input a user makes when su'ing. Again: it would be a
local hack. I am not speaking about decrypting the SSH connection,
either established by password auth nor by pubkey auth. The "weak" point
is the local system, given the attacker has local unprivileged user
permissions.
I know you weren't talking about decrypting ssh, etc. While I'm not a big fan
of allowing any remote root access.. I do see where you are coming from.. If
someone compromised your home machine/certificate/passphrase, they would have
instant root access to your sshd box. However, if you were ssh'ing and
su'ing, and they had compromised the box doing the ssh'ing, they'd still
compromise root if you ever su'd.
Remote root access via keys and using 2 factor authentication (tokens, etc)
wouldn't be too bad at all.. but for the purposes of auditing, its usually
not plausible. There needs to be an audit trail. I think the way to go would
be using su, and still having 2 factor.. At the same time, I use gr-security
on my kernels which doesn't allow a user to put anything in their own path
(gets around their account being compromised, and someone trojan'ing su).
It's never completely fool proof.. and using RSA tokens certainly isn't
affordable or easy for a home user. Things like S/Key are, but they're a pain
to carry around a list of passwords.. Biometrics aren't really plausible (and
are a bad thing in general in my opinion.. If someone ever compromises your
thumb print.. Oops, you're screwed forever)
Both ways have their issues.. Personally, I'm not a fan of passwords at all..
But if you use public key, then you run into the problem of your users not
setting passphrases on their keys at all.. Which you can't really control..
and then their windows/linux box getting compromised, and the attacker doesn't
even have to go through the hassle of sniffing their passphrases.. they just
walk onto your system.. as a normal user. Then they can attempt to escalate
privs from there.
So anyway.. I see where you're coming from, and I see the extra risk of a user
account being compromised and then someone attempting to escalate from there
if they are a user that has 'su' ability. But this is also the reason that
root users should be extremely limited.. sudo is great for doing this, as
long as you know exactly what you're doing.. So many applications have shell
escapes.. like giving sudo vi, is just like giving sudo bash.. sudo cat,
gives shadow file (also gives raw access to /dev devices.. sudo cat
/dev/hda|strings)
However you can restrict sudo down pretty well, require absolute paths, etc.
anyway.. I've rambled enough.
12:13 p.m.
New subject: MORE SSH Hacking: heads-up
I was not speaking about the network transfer between client and
server.
I thought this was obvious. I was speaking about the possibility to
locally, on the SSHD system itself, to sniff password entries when
running "su".
Ok, I'll go ahead and risk embarrassment in the name of enlightenment
and ask: If the traffic between client and server is encrypted, even
with access to the sshd system, how does one "sniff" traffic sent
between two local processes (sshd and su) without a keylogger, which
wouldn't apply since the keyboard in question is on the client-side?
Is there some technique for eavesdropping on inter-process
communications that I don't know about, then, or did I just
misunderstand you?
--Brad
1:14 p.m.
New subject: MORE SSH Hacking: heads-up
Am Do, den 12.08.2004 schrieb Brad Smith um 19:13:
Ok, I'll go ahead and risk embarrassment in the name of
enlightenment
and ask: If the traffic between client and server is encrypted, even
with access to the sshd system, how does one "sniff" traffic sent
between two local processes (sshd and su) without a keylogger, which
wouldn't apply since the keyboard in question is on the client-side?
Is there some technique for eavesdropping on inter-process
communications that I don't know about, then, or did I just
misunderstand you?
Brad
The question is about "potential weakness". Certainly an attacker has to
use bugs on the system (the server if you speak about remote machines in
this case) to be able to listen to inter-process communications or
trojans to get what a user types in when trying to become root.
At all you did understand me right. What netmask just in this moment
replied explains it a bit better than I did.
In the field of security you always have to observe the weakest points
of a system or a structure. So my intention was not to say "hey, ssh in
as normal user and then su to root is a security hole". But I wanted to
point out that you might have a risk if feeling too safe.
You know where this thread is coming from, what the starting point was.
It is exactly that, that obviously too much Linux admins believe that
Linux is secure by architecture or what else. It is obvious from my
investigations too, that the hackers/crackers get access to vulnerable
Linux hosts as unprivileged users and then using local exploits to
become root. I know, many Linux admins think local root exploits are
much less severe than remote root exploits. This is wrong and we now see
to what it leads, unfortunately.
Alexander
--
Alexander Dalloz | Enger, Germany | GPG key 1024D/ED695653 1999-07-13
Fedora GNU/Linux Core 2 (Tettnang) kernel 2.6.7-1.494.2.2smp
Serendipity 19:31:34 up 8 days, 12:59, load average: 1.36, 1.31, 1.48
1:36 p.m.
New subject: MORE SSH Hacking: heads-up
You know where this thread is coming from, what the starting point
was.
It is exactly that, that obviously too much Linux admins believe that
Linux is secure by architecture or what else. It is obvious from my
investigations too, that the hackers/crackers get access to vulnerable
Linux hosts as unprivileged users and then using local exploits to
become root. I know, many Linux admins think local root exploits are
much less severe than remote root exploits. This is wrong and we now see
to what it leads, unfortunately.
Remote root is certainly nice.. however these days it is a lot more common to
gain access remotely via a process with drop'd privs.. You then have to find a
local exploit to escalate privileges.
Sometimes we get lucky and exploits in PHP come out where the exploit is
handled before privs are dropped.. and you get root. Other times in apache
exploits, you end up as the 'nobody' user.
However, I treat local vulnerabilities as serious as remote. While it's
definitely the smart thing to do to put your processes in jails, and make sure
they aren't running as root.. It's just not possible to completely not run as
root while the stack requires root privs to bind ports under 1024, and a few
other reasons (device access, etc).. Jails can be broken, etc.
The 'vulnerabilities' I don't worry about it.. are things like the
'info'
overflow that came out last week on Bugtraq. Is your 'info' binary suid root?
Do you give people 'sudo info' ? No.. Do I really care if someone injects
shellcode into their instance of info and drop to their own privs? not really.
But when you are talking about vulns in su, sudo, etc.. anything that is suid
on the system (On my server that doesn't run any X.. there is only a need for
4 suid bins total).
blah blah blah, security if a process.. blah blah, etc etc.
:P
6:59 p.m.
New subject: MORE SSH Hacking: heads-up
funny to still see this thread running.
Your conversation of the su issue prompted me to look for an exploit.
Found this linux "su" exploit that copies the passwords to /tmp/.tmp
The only problem is you'd have to get it there first.
http://packetstormsecurity.nl/groups/shadowpenguin/unix-tools/passwd_linux.c
Has anyone used my iptables suggestion with success?
On Thu, 2004-08-12 at 14:36, netmask wrote:
> You know where this thread is coming from, what the starting
point was.
> It is exactly that, that obviously too much Linux admins believe that
> Linux is secure by architecture or what else. It is obvious from my
> investigations too, that the hackers/crackers get access to vulnerable
> Linux hosts as unprivileged users and then using local exploits to
> become root. I know, many Linux admins think local root exploits are
> much less severe than remote root exploits. This is wrong and we now see
> to what it leads, unfortunately.
Remote root is certainly nice.. however these days it is a lot more common to
gain access remotely via a process with drop'd privs.. You then have to find a
local exploit to escalate privileges.
Sometimes we get lucky and exploits in PHP come out where the exploit is
handled before privs are dropped.. and you get root. Other times in apache
exploits, you end up as the 'nobody' user.
However, I treat local vulnerabilities as serious as remote. While it's
definitely the smart thing to do to put your processes in jails, and make sure
they aren't running as root.. It's just not possible to completely not run as
root while the stack requires root privs to bind ports under 1024, and a few
other reasons (device access, etc).. Jails can be broken, etc.
The 'vulnerabilities' I don't worry about it.. are things like the
'info'
overflow that came out last week on Bugtraq. Is your 'info' binary suid root?
Do you give people 'sudo info' ? No.. Do I really care if someone injects
shellcode into their instance of info and drop to their own privs? not really.
But when you are talking about vulns in su, sudo, etc.. anything that is suid
on the system (On my server that doesn't run any X.. there is only a need for
4 suid bins total).
blah blah blah, security if a process.. blah blah, etc etc.
:P
10:01 p.m.
New subject: MORE SSH Hacking: heads-up
On Thu, 2004-08-12 at 19:59 -0400, Dave Rinker wrote:
funny to still see this thread running.
Your conversation of the su issue prompted me to look for an exploit.
Found this linux "su" exploit that copies the passwords to /tmp/.tmp
The only problem is you'd have to get it there first.
http://packetstormsecurity.nl/groups/shadowpenguin/unix-tools/passwd_linux.c
Has anyone used my iptables suggestion with success?
Perhaps I'm being daft, but the exploit appears to be a 'passwd' trojan,
not an su trojan. And the attacker would need to get it in a place where
it would get inadvertently run (preferably by root).
--
Aaron Gaudio <prothonotar(a)tarnation.dyndns.org>
10:45 p.m.
New subject: MORE SSH Hacking: heads-up
my error, this is passwd code
On Thu, 2004-08-12 at 23:01, Aaron Gaudio wrote:
Perhaps I'm being daft, but the exploit appears to be a 'passwd' trojan,
not an su trojan. And the attacker would need to get it in a place where
it would get inadvertently run (preferably by root).
--
Aaron Gaudio <prothonotar(a)tarnation.dyndns.org>
6:01 p.m.
New subject: MORE SSH Hacking: heads-up
On the possibility of "sniffing" a password sent through a SSH-encrypted
tunnel:
There were a series of papers some time ago -- one of them is at
http://www.cs.virginia.edu/cs588/projects/reports/team4.pdf -- which
claimed that it was possible to guess which keys a user presses by
measuring the time between keystrokes.
SSH sessions tend to send one packet for each key the user presses, so
this data could be visible to an attacker with access to the data
stream. The theory goes that the attacker could guess when passwords
were being entered, because normally when a user types a key, the server
displays something. When passwords are sent, this doesn't happen, and
an attacker can see the lack of screen updates.
It is supposed to weaken passwords by a factor of 50: very roughly, it
would make a 6-character password as easy to crack as a 5-character
password without this data.
James.
--
E-mail address: james | 'In a serial interface, the data bits move down a
@westexe.demon.co.uk | single channel one after the other, like railway
| trains. This is different from the parallel interface
| in which groups of bits arrive together, like London
| buses.' -- 'The Computer Dictionary', Jon Wedge
7:58 p.m.
New subject: MORE SSH Hacking: heads-up
Behold, James Wilkinson <james(a)westexe.demon.co.uk> hath decreed:
On the possibility of "sniffing" a password sent through a
SSH-encrypted
tunnel:
There were a series of papers some time ago -- one of them is at
http://www.cs.virginia.edu/cs588/projects/reports/team4.pdf -- which
claimed that it was possible to guess which keys a user presses by
measuring the time between keystrokes.
I'm not privvy to the intricacies to the ssh authentication protocol, but
why doesn't/can't the ssh client simply not send any of the password until
the user presses Enter, thereby defeating this attack against an initial
ssh authentication (presumably the ssh client knows when the server is
asking for a password)? As for other passwords, such as sent to sudo once
the connection is established, the connection is encrypted, so it seems
unlikely the attack would work. And if all else fails, the ssh client could
(maybe it already does) insert some artificial random delays into
transmissions coming from key entries.
--
prothonotar at tarnation.dyndns.org
"Every man is a mob, a chain gang of idiots."
- Jonathan Nolan, /Memento Mori/
11:55 a.m.
New subject: MORE SSH Hacking: heads-up
I wrote:
There were a series of papers some time ago -- one of them is at
http://www.cs.virginia.edu/cs588/projects/reports/team4.pdf -- which
claimed that it was possible to guess which keys a user presses by
measuring the time between keystrokes.
Aaron Gaudio replied:
I'm not privvy to the intricacies to the ssh authentication
protocol, but
why doesn't/can't the ssh client simply not send any of the password until
the user presses Enter, thereby defeating this attack against an initial
ssh authentication (presumably the ssh client knows when the server is
asking for a password)?
I should have made this clearer: it does. At least when the
connection is
first established. The problem is when the user is asked for passwords
later (e.g. su or sudo).
As for other passwords, such as sent to sudo once
the connection is established, the connection is encrypted, so it seems
unlikely the attack would work.
Although the connection is encrypted, the fact that one exists can be
deduced (an attacker, in the right place, can see all those encrypted
packets going backwards and forwards). He or she can even tell when
they go, and how big they are, and deduce some details about what
is happening (a screen refresh is a lot bigger than a single character
being displayed).
And if all else fails, the ssh client could
(maybe it already does) insert some artificial random delays into
transmissions coming from key entries.
For that to work, the client would have to recognise when the server
was asking for a password. That would mean deducing the intent of what
was displayed. OpenSSH clients don't interpret the display at all: they
just pass it on to the terminal. PuTTY, of course, has an integrated
terminal emulator, but it still only displays what is sent: it has
no notion of "su".
Alternatively, of course, you could just drop these delays into all
communication. To be effective, you'd need enough delays that it might
be noticable over a slow connection. I've got ssh users over such
slow connections, and I can tell you they'd not be happy about it.
A cleaner solution would be to invent an API and a terminfo code for
programs to request passwords from a terminal, and terminals that would
know to prompt for a password and not send anything until Return was
pressed. If you patched su, sudo and passwd to use such a thing, and
PuTTY and several of the Linux xterms to understand the codes, you could
probably get enough momentum for most other vendors to jump on board.
The fact that this hasn't happened should tell you something -- notably
that it is a highly theoretical weakness, and none of the professional
paranoids are sufficiently worried.
James.
--
E-mail address: james | "It has taken 24 years to get the Reichstag wrapped.
@westexe.demon.co.uk | Chancellor Kohl said it would only be wrapped over
| his dead body, so sensing an opportunity the
| Bundestag outvoted him." -- The Guardian
3:45 p.m.
New subject: MORE SSH Hacking: heads-up
On Mon, 2004-08-16 at 17:55 +0100, James Wilkinson wrote:
> And if all else fails, the ssh client could
> (maybe it already does) insert some artificial random delays into
> transmissions coming from key entries.
For that to work, the client would have to recognise when the server
was asking for a password. That would mean deducing the intent of what
was displayed. OpenSSH clients don't interpret the display at all: they
just pass it on to the terminal. PuTTY, of course, has an integrated
terminal emulator, but it still only displays what is sent: it has
no notion of "su".
You misinterpreted. I said "coming from key entries". All the client
would need to know is if the input was coming from a terminal or not. No
reason (other than efficiency) to only protect passwords from such
sniffing.
Alternatively, of course, you could just drop these delays into all
communication. To be effective, you'd need enough delays that it might
be noticable over a slow connection. I've got ssh users over such
slow connections, and I can tell you they'd not be happy about it.
If you delayed only terminal input (as opposed to, say, tunneled
application data), I think the scale of the delays necessary to confound
potential sniffers would be small enough as to be imperceivable; and on
a slow connection these delays would not be your limiting factor anyway.
A cleaner solution would be to invent an API and a terminfo code for
programs to request passwords from a terminal, and terminals that would
know to prompt for a password and not send anything until Return was
pressed. If you patched su, sudo and passwd to use such a thing, and
PuTTY and several of the Linux xterms to understand the codes, you could
probably get enough momentum for most other vendors to jump on board.
The fact that this hasn't happened should tell you something -- notably
that it is a highly theoretical weakness, and none of the professional
paranoids are sufficiently worried.
Especially in the case of SSH, I have a feeling that you are correct.
8:36 p.m.
New subject: MORE SSH Hacking: heads-up
On Mon, Aug 16, 2004 at 12:01:49AM +0100, James Wilkinson wrote:
On the possibility of "sniffing" a password sent through a
SSH-encrypted
tunnel:
There were a series of papers some time ago -- one of them is at
http://www.cs.virginia.edu/cs588/projects/reports/team4.pdf -- which
claimed that it was possible to guess which keys a user presses by
measuring the time between keystrokes.
SSH sessions tend to send one packet for each key the user presses,
so
this data could be visible to an attacker with access to the data
stream. The theory goes that the attacker could guess when passwords
were being entered, because normally when a user types a key, the server
displays something. When passwords are sent, this doesn't happen, and
an attacker can see the lack of screen updates.
It is supposed to weaken passwords by a factor of 50: very roughly,
it
would make a 6-character password as easy to crack as a 5-character
password without this data.
Counter measures have already been implimented (timing jiggers
and normalization).
It was a cute trick but easy to defeat through a number of
tricks. All my passwords are "touch type" I can't even type them
if I look at the keyboard (because I'm thinking about them too much).
James.
--
E-mail address: james | 'In a serial interface, the data bits move down a
@westexe.demon.co.uk | single channel one after the other, like railway
| trains. This is different from the parallel interface
| in which groups of bits arrive together, like London
| buses.' -- 'The Computer Dictionary', Jon Wedge
Mike
--
Michael H. Warfield | (770) 985-6132 | mhw(a)WittsEnd.com
/\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
7199
days inactive
7215
days old
30 comments
16 participants
participants (16)
-
Aaron Gaudio -
Alexander Dalloz -
Brad Smith -
Brian Fahrlander -
dave -
Jack Bowling -
James Wilkinson -
jludwig -
John Lagrue -
Matt Morgan -
Michael H. Warfield -
ne... -
netmask -
Scot L. Harris -
Styma, Robert E (Robert) -
Yang Xiao