New SSH vulnerability or what? Users acted as root...
Hi! We've had a strange episode with out servers, maybe somebody has seen something similar. We first had one of those SSH attacks with invalid users. But then something that I had not seen before, but probably nothing serious. Here is some log: Sep 29 08:15:58 server sshd[20976]: Invalid user andreyd from ::ffff:194.51.214.195 Sep 29 08:15:59 server sshd[20976]: reverse mapping checking getaddrinfo for 195.192-255.214.51.194.in-addr.arpa failed - POSSIBLE BREAKIN ATTEMPT! Sep 29 08:16:00 server sshd[20978]: reverse mapping checking getaddrinfo for 195.192-255.214.51.194.in-addr.arpa failed - POSSIBLE BREAKIN ATTEMPT! But then somewhat after that (half an hour) our /var was suddenly turned to read-only. So the logs had a gap for about an hour: Sep 29 09:24:27 syrphus kernel: Additional sense: Invalid field in cdb Sep 29 09:25:01 syrphus /usr/sbin/cron[22405]: (root) CMD (/usr/local/bin/bruschedule) Sep 29 09:25:28 syrphus kernel: st0: Error with sense data: Current st0: sense key Illegal Request Sep 29 09:25:28 syrphus kernel: Additional sense: Invalid field in cdb Sep 29 10:29:15 syrphus syslogd 1.4.1: restart. Sep 29 10:29:16 syrphus SuSEfirewall2: Warning: FW_MASQ_NETS needs FW_MASQUERADE set to yes to work! Sep 29 10:29:16 syrphus nmbd[4536]: [2005/09/29 10:29:16, 0] libsmb/nmblib.c:send_udp(790) Sep 29 10:29:16 syrphus nmbd[4536]: Packet send failed to 10.0.0.255(137) ERRNO=Operation not permitted When something made the /var read-only, we of course had multiple problems. So the first question is: is there some new hole in SSH? We have SuSE 9.2 with open ssh 3.9p1-3.2 which is the newest one from YOU. And we do not have any other ports open to the server. We returned /var and some other stuff from tapes and checked that nothing really is changed. So we do not believe that anybody got in. But how else can the /var become read-only... any ideas? One of the problems that read-only /var caused is that "random" files changed to be owned by root in users home dirs. These included files like: .Xauthority, .DCOPserver_*, .ICEauthority as well as others from .kde. Fixing this was a pain... As we looked at the situation in data files more carefully, it seemed that all the files that had been modified during that time were now owned by root. We think this means that when the users logged in, the setuid didn't work correctly and the processes were left as root - i.e. the users were acting as root. Which, if is true, is kind of scary... -- HG.
On Mon, Oct 03, 2005 at 02:35:33PM +0300, HG wrote:
Hi!
We've had a strange episode with out servers, maybe somebody has seen something similar.
We first had one of those SSH attacks with invalid users. But then something that I had not seen before, but probably nothing serious. Here is some log:
Sep 29 08:15:58 server sshd[20976]: Invalid user andreyd from ::ffff:194.51.214.195 Sep 29 08:15:59 server sshd[20976]: reverse mapping checking getaddrinfo for 195.192-255.214.51.194.in-addr.arpa failed - POSSIBLE BREAKIN ATTEMPT! Sep 29 08:16:00 server sshd[20978]: reverse mapping checking getaddrinfo for 195.192-255.214.51.194.in-addr.arpa failed - POSSIBLE BREAKIN ATTEMPT!
But then somewhat after that (half an hour) our /var was suddenly turned to read-only. So the logs had a gap for about an hour:
Sep 29 09:24:27 syrphus kernel: Additional sense: Invalid field in cdb Sep 29 09:25:01 syrphus /usr/sbin/cron[22405]: (root) CMD (/usr/local/bin/bruschedule) Sep 29 09:25:28 syrphus kernel: st0: Error with sense data: Current st0: sense key Illegal Request Sep 29 09:25:28 syrphus kernel: Additional sense: Invalid field in cdb Sep 29 10:29:15 syrphus syslogd 1.4.1: restart. Sep 29 10:29:16 syrphus SuSEfirewall2: Warning: FW_MASQ_NETS needs FW_MASQUERADE set to yes to work! Sep 29 10:29:16 syrphus nmbd[4536]: [2005/09/29 10:29:16, 0] libsmb/nmblib.c:send_udp(790) Sep 29 10:29:16 syrphus nmbd[4536]: Packet send failed to 10.0.0.255(137) ERRNO=Operation not permitted
When something made the /var read-only, we of course had multiple problems.
So the first question is: is there some new hole in SSH? We have SuSE 9.2 with open ssh 3.9p1-3.2 which is the newest one from YOU. And we do not have any other ports open to the server.
We are not aware of open vulnerabilities in openssh as of this time. Make really sure that all your users have good passwords to avoid problems from SSH worms. Ciao, Marcus
On Monday 03 October 2005 13:35, HG wrote:
But then somewhat after that (half an hour) our /var was suddenly turned to read-only. So the logs had a gap for about an hour:
This tends to happen after a filesystem corruption is detected or a failure to perform a disk read or write. Have you checked kernel messages with dmesg? Checked the drive /var is on with smartctl -a? I have never heard of a partition going read-only out of the blue, but have seen this happen numerous times when the disk was giving read and/or write errors, or a shared-storage cluster mounting the same physical disk from separate nodes... -- Jure Koren, n.i.
Hello, Am Montag, 3. Oktober 2005 15:17 schrieb Jure Koren:
On Monday 03 October 2005 13:35, HG wrote:
But then somewhat after that (half an hour) our /var was suddenly turned to read-only. So the logs had a gap for about an hour:
This tends to happen after a filesystem corruption is detected or a failure to perform a disk read or write.
ACK - this would be my first guess too.
I have never heard of a partition going read-only out of the blue, but have seen this happen numerous times when the disk was giving read and/or write errors,
You can set the behaviour with tune2fs (and maybe the tools for other filesystems too). I usually set it to "remount ro on error". This is annoying if it really happens, but much better than destroying my data more and more... Regards, Christian Boltz --
Führst Du schon Selbstgespräche? ;-) Hm. Kann sein. Was meinst du? Nein, glaube ich nicht. Sicher? Ganz sicher. Nein, tun wir nicht. [> Christian Boltz und Ratti in fontlinge-devel]
participants (4)
-
Christian Boltz -
HG -
Jure Koren -
Marcus Meissner