Hi all, I help administer a Linux(RH6.1) box running icecast 1.3.5. I'm going to go ahead and upgrade to 1.3.10 shortly. Recently a user from a strange(to us) dial-in account logged in as operator and issued a shutdown command. I changed the passwords to see if someone in our group had let it out, but the same thing happened two days latter. I'm trying to figure out how this was done, so I can decide whether we should consider the whole system compromised, or if perhaps there is another machine on the LAN that's been compromised and used to sniff us out. Thanks! --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> I'm trying to figure out how this was done, so I can decide whether > we should consider the whole system compromised, or if perhaps there > is another machine on the LAN that's been compromised and used to > sniff us out.You should never send cleartext passwords across the network. Unfortunately, icecast encourages this behaviour. A much safer way to administer the box you should ssh into it and telnet to localhost. To encourage this you should restrict admin logins to the localhost by putting the following in your /etc/hosts.deny. icecast_admin: ALL EXCEPT 127.0.0.1 Using crypt passwords may help if you need to telnet remotely, but cracking crypt is fairly trivial unless you use MD5 passwords. Ideally it would be good if icecast supported challenge/response logins, possibly through SASL. I've been pondering this recently, but I don't know enough about icecast yet to see how it would fit in. Cheers, Steve --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Apr 09, 2001 at 09:15:26PM -0700, Seth de l'Isle wrote:> I'm trying to figure out how this was done, so I can decide whether we should > consider the whole system compromised, or if perhaps there is another machine > on the LAN that's been compromised and used to sniff us out.First off, you should not be allowing global access to the admin port of the icecast server. Either firewall it off, or use TCP wrappers on the port, and lock it down to only the IPs you want to allow admin access to. Better yet, disable remote access entirely and only allow telnets in from the local machine. That way, if you're on console or ssh into the box, no one can sniff the network traffic and pull the plaintext password out of the stream. The fact that this person got in even after the password was changed suggests that he either has local network access and has been sniffing passwords, or he has access to the machine itself and is pulling the password out of the icecast.conf file. Check the server for obvious signs of a rootkit (foreign entries in /etc/inetd.conf, system binaries with creation dates in the recent past [i.e., after system creation], daemons running on wierd ports), and pray it's not a kernel module hack. If the point-of-entry is not easily discernable, firewall off the IP block of the dialup account and sniff traffic looking for anything martian. It is never a good idea to rely solely on the built-in authentication scheme of any program, especially one with text in the clear. (If I could code, I'd be working on an OpenSSL-based admin console for icecast...) - -- "If this is Paradise, I wish I had a lawnmower." - Talking Heads, "Nothing But Flowers" -----BEGIN PGP SIGNATURE----- Comment: For info see http://www.gnupg.org iD8DBQE60pPv36NTGsm+2Z4RApd4AKCG44tsvSx4zkRKBfrcLNGvenUrBgCglLi9 4SL01mdTPsovmnhPu95bVts=dlhA -----END PGP SIGNATURE----- --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
> I'm trying to figure out how this was done, so I can decide whether we should > consider the whole system compromised, or if perhaps there is another machine > on the LAN that's been compromised and used to sniff us out.Ah, this points to a potentially serious problem. I'm not aware of any problems with the oper login code that would allow you to bypass the password. Oper passwords are sent in the clear. Sniffing on a LAN will get them, unless you're on a switch. In that case, sniffing on the local machine will get them. Oper passwords are stored in the clear in a file that more than likely is world readable. If a user has access to login, they can probably read it. It's possible someone compromised this system, or a system on your network. It's possible they did this through bugs in icecast. But, there are ways to figure out who they are and where they come from, and just how they are doing what they are doing. Can't help much unless we get more information. You could try changing the password, and monitoring logins, to see if they are coming in through an account. You could try upgrading icecast and see if they were coming in that way. The only good way to tell if you've been compromised is by comparing file hashes. Check things like 'who', and 'ps', and 'login', and 'bash', etc, to see if they've been modified. Considering installing tripwire (www.tripwire.org) on all systems to detect these kinds of problems. Some network monitoring will tell you how they are doing it as well. And where they are coming from (hopefully). I wish you luck. jack. --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.