Re:

Well the description of the smrsh problem says ....

An attacker can bypass the restrictions imposed by sendmail's restricted shell, smrsh(8), and execute arbitrary commands with the privileges of his own account.

I would interpret that to mean he ( or she ) must have had an account on the box before the smrsh issue could be leveraged..

So unless im way of the mark they have gotten in another way....

Dan

-----Original Message-----
From: owner-misc@openbsd.org [mailto:owner-misc@openbsd.org] On Behalf Of Jon Quiros
Sent: 11 November 2002 22:34
To: misc@openbsd.org
Subject:

I got back from a trip last night and noticed a new user in my passwd file:

koped:*:1010:10:Mr. Kopad Koped:/home/koped:/bin/csh

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related openbsd.org Links advocacy announce bugs ipv6 misc ports ports-changes security-announce smp source-changes tech Request more information about Pantek

a shame, because though i had restricted ssh to only be possible from a few ip's, last wednesday, on the 5th i decided it would be safe to allow ssh connections from any
ip- esp since i'd be travelling and not have to worry about where i connected from.

at the time i believe i got owned, i was running 3.1/i386 stable with patches 1-15...
i just patched up to the 18th one...

these are the connections i see the person made (as koped):

Nov 9 13:39:13 tlaloc sshd[10102]: Accepted password for koped from 202.158.77.37 port 62627
Nov 9 14:35:15 tlaloc sshd[2353]: Accepted password for koped from 202.158.77.37 port 62725
Nov 9 16:09:41 tlaloc sshd[9378]: Accepted password for koped from 202.158.77.37 port 62890
Nov 10 13:17:04 tlaloc sshd[26780]: Accepted password for koped from 202.158.77.37 port 61098
Nov 10 13:45:13 tlaloc sshd[23489]: Accepted password for koped from 202.158.77.37 port 61158
Nov 8 16:07:04 tlaloc sshd[19770]: Accepted password for koped from 203.130.222.114 port 14361

I also see this for one of the addresses in authlog:

Nov 8 15:59:02 tlaloc sshd[22724]: Failed password for illegal user ferry from 203.130.222.114 port 13980
Nov 8 15:59:08 tlaloc sshd[22724]: Failed password for illegal user ferry from 203.130.222.114 port 13980

here's what snort saw (which to me doesn't show much except for addresses):

[**] [1:498:3] ATTACK RESPONSES id check returned root [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
11/06-11:47:33.087011 10.0.1.147:22 -> 216.29.175.74:4641 TCP TTL:64 TOS:0x0 ID:23726 IpLen:20 DgmLen:93 DF ***AP*** Seq: 0xC7844988 Ack: 0x7F99B3A5 Win: 0x43E0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 1947328007 164909513

Do you need more help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related openbsd.org Links advocacy announce bugs ipv6 misc ports ports-changes security-announce smp source-changes tech Request more information about Pantek

[**] [1:498:3] ATTACK RESPONSES id check returned root [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
11/06-12:18:43.387069 10.0.1.147:22 -> 61.1.118.14:4617 TCP TTL:64 TOS:0x0 ID:40139 IpLen:20 DgmLen:93 DF ***AP*** Seq: 0x8EE9828A Ack: 0xAEF9B68C Win: 0x43E0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 1947331747 21034157

[**] [1:498:3] ATTACK RESPONSES id check returned root [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
11/06-12:39:38.723128 10.0.1.147:22 -> 61.1.118.14:2779 TCP TTL:64 TOS:0x0 ID:59766 IpLen:20 DgmLen:93 DF ***AP*** Seq: 0xCFBD2DDF Ack: 0xFE3340CE Win: 0x43E0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 1947334258 21159690

[**] [1:498:3] ATTACK RESPONSES id check returned root [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
11/06-12:48:03.841480 10.0.1.147:22 -> 216.29.175.74:4928 TCP TTL:64 TOS:0x0 ID:8650 IpLen:20 DgmLen:93 DF ***AP*** Seq: 0xEEE82977 Ack: 0x65745307 Win: 0x43E0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 1947335268 165272600

[**] [1:498:3] ATTACK RESPONSES id check returned root [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
11/06-15:03:35.830022 10.0.1.147:22 -> 61.1.118.14:2062 TCP TTL:64 TOS:0x0 ID:48825 IpLen:20 DgmLen:93 ***AP*** Seq: 0x52DF865B Ack: 0x1D20DD58 Win: 0x43E0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 1947351532 22023399

[**] [1:498:3] ATTACK RESPONSES id check returned root [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
11/08-16:57:58.959604 10.0.1.147:22 -> 80.49.131.137:3712 TCP TTL:64 TOS:0x0 ID:62252 IpLen:20 DgmLen:93 DF ***AP*** Seq: 0x179F6CEB Ack: 0x1BAB9616 Win: 0x43E0 TcpLen: 32 TCP Options (3) => NOP NOP TS: 1947710858 43692335

Also, I guess my logs, though still there, are pretty much NOT to be trusted (laziness stopped me from logging properly to somewhere else on this machine)

Apart from entirely distrusting the box now and starting fresh, i'd still like to know more about how this happened.

Does it look like
a) a brute force attack to ssh right when i set pf to allow ssh connections from anywhere (though i'd see more failed login attempts -like the nonexistent ferry, above- if
the logs weren't messed with)?
OR
b) could i have been compromised through the then unpatched smrsh vulnerability?
c) i haven't the nearest clue but you can help me see things i'm not seeing?

Can we help you?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related openbsd.org Links advocacy announce bugs ipv6 misc ports ports-changes security-announce smp source-changes tech Request more information about Pantek

thanks for any help. Received on Mon Nov 11 17:43:10 2002