What Tony meant to say is that in a near future, there will be no longer FTP provisioning for Polycom, so the user will probably be removed.
Denying ssh access to polycom user won't affect FTP provisioning and will secure the box against the this exploit itself. Also, if you don't need the forwarding, you can add "AllowTcpForwarding no" into the sshd_config. It's a nice catch Noah. I would say the DenyUsers approach would suffice for a stock install. Not sure how dificult it would be to implement automatically. - MM On Fri, Nov 16, 2012 at 5:14 PM, Noah Mehl <[email protected]> wrote: > OK, > > The must be some sort of communication issue here. Why would denying > ssh access remove a user from the system? I thought provisioning happens > via ftp, tftp, http, or https. I'm not talking about deleting the linux > user, only specifically denying any ssh access to the sipxecs server for > that user…? > > ~Noah > > On Nov 16, 2012, at 2:11 PM, Tony Graziano <[email protected]> > wrote: > > It would mean the user would no longer be present on the system because it > would not be required. > > On Fri, Nov 16, 2012 at 2:08 PM, Noah Mehl <[email protected]> wrote: > >> I don't understand: >> >> "so polycom provisioning in Sipx will cease using ftp and the user >> account will be removed at that time and move to http/HTTPS." >> >> Why would denying the PlcmSpIp user in the sshd config affect provision? >> >> Honestly, the exploit is the ability to use SSH port forwarding with >> the default PlcmSpIp user/pass. I doubt your ids will stop that if you >> have ssh access to the machine. >> >> ~Noah >> >> On Nov 16, 2012, at 1:48 PM, Tony Graziano <[email protected]> >> wrote: >> >> Fwiw I can test the exploit and my ids (commercial snort rules). >> >> so polycom provisioning in Sipx will cease using ftp and the user account >> will be removed at that time and move to http/HTTPS. >> On Nov 16, 2012 12:52 PM, "Noah Mehl" <[email protected]> wrote: >> >>> I can confirm that adding: >>> >>> DenyUsers PlcmSpIp >>> >>> to /etc/ssh/sshd_config solves this exploit. >>> >>> I'm back to my original opinion that if this user is installed >>> automatically, without my intervention, then that line should be added to >>> the sshd_config. >>> >>> ~Noah >>> >>> On Nov 16, 2012, at 12:46 PM, Noah Mehl <[email protected]> wrote: >>> >>> Tony, >>> >>> I just figured out an exploit in 15 minutes with the help of Google >>> http://www.semicomplete.com/articles/ssh-security/: >>> >>> $sudo ssh -vN -L25:localhost:25 PlcmSpIp@sipxecsip >>> $sudo ssh -vN -R25:localhost:25 PlcmSpIp@sipxecsip >>> $telnet localhost 25 >>> >>> Tell me if your ids stops that? >>> >>> This works on a stock SipXecs 4.4.0 install. >>> >>> ~Noah >>> >>> On Nov 16, 2012, at 11:46 AM, Tony Graziano < >>> [email protected]> >>> wrote: >>> >>> The user doesn't have login via ssh. Ssh in and of itself is not >>> protected and it is exposed. >>> >>> It is trivial to change the user password and/or delete it. We typically >>> don't expose ssh at all. You haven't provides any real evidence that a >>> dictionary attack didn't overwhelm the pam service either. >>> >>> I don't share your opinion here. My firewall protects against all kinds >>> of ids stuff even if I had ssh open. Just because you have iptables running >>> it doesn't mean you are inherently secure at all. >>> >>> Our firewalls sitting in front of sipx had ids rules running that would >>> protect anything behind it from a known attack against a well known service >>> like ssh. Ssh has lots of options which should be exercised according to >>> your security border device. >>> On Nov 16, 2012 11:36 AM, "Noah Mehl" <[email protected]> wrote: >>> >>>> The only hardening required to solve this particular problem would be >>>> an addition to the sshd config: >>>> >>>> DenyUsers PlcmSpIp >>>> >>>> I think this should be included in the default distribution of >>>> SipXecs isos and/or packages (I've only ever used the iso) because this is >>>> something that is specific to the distribution. That user, and its >>>> password and access, are created by SipXecs, and that addition to the sshd >>>> config should be made OOTB. Unless someone has a reason that PlcmSpIp >>>> should be able to have any ssh access? >>>> >>>> I'd really like some input from someone from eZuce, as this is an >>>> easy solution and protects the entire community. >>>> >>>> This was NOT a DDOS attack. This it that the PlcmSpIp user has a >>>> default password of PlcmSpIp, and there's something about the default >>>> access of that user that allow remote execution via SSH OOTB, and that >>>> *IS* a security issue. You know why? Because as far as I know, no >>>> other default linux service account is susceptible to this attack. >>>> Probably because linux system accounts DON'T HAVE PASSWORDS! In other >>>> words, if you're creating service users with default passwords, they >>>> probably should be denied from ssh OOTB. This is also, not documented as >>>> far as I can tell... >>>> >>>> ~Noah >>>> >>>> On Nov 16, 2012, at 11:26 AM, Tony Graziano < >>>> [email protected]> wrote: >>>> >>>> It really sounds like you don't have a method to harden your server >>>> if you are exposing it. Its entirely possible you were targeted with a ddos >>>> attack that overwhelmed the Linux system. If you had properly crafted >>>> iptables rules I and ssh protection mechanisms it would most likely not >>>> have happened. >>>> >>>> Any did or ddos can overwhelm system services to the point of failure >>>> this allowing (by unavailability) internal logging or protection >>>> mechanisms. Put the served behind a firewall and protect the vulnerable >>>> service (ssh) by limiting the footprint. Backup the system, wipe and >>>> restore it in the event a root kit was planted. >>>> >>>> I don't think iptables was adequately configured. I don't think there >>>> is anything inherently wrong with Sipx here either. >>>> >>>> It is a phone system. It is up to you to protect and/or harden it. Any >>>> vulnerabilities exposed are really Linux vulnerabilities and Linux is not >>>> hack proof. >>>> >>>> Good luck. >>>> On Nov 16, 2012 10:07 AM, "Noah Mehl" <[email protected]> wrote: >>>> >>>>> Todd, >>>>> >>>>> The private subnet is: 172.16.0.0 - 172.31.255.255. That IP is a >>>>> public IP address, which is part of AOL in Nevada I think. I actually >>>>> have >>>>> over 80 different public IP address entries in my log using that user to >>>>> SSH to my SipXecs box. >>>>> >>>>> I understand that it's a phone system and not a firewall. However >>>>> it's a linux server, and IPtables is the best firewall in world, IMHO. I >>>>> did have SSH access open to the world, that was my choice. I have never >>>>> been bitten by this before. Either way, you should not be able to execute >>>>> anything by SSH'ing with the PlcmSpIp user, whether it's a public IP or >>>>> not. >>>>> >>>>> ~Noah >>>>> >>>>> On Nov 15, 2012, at 7:07 PM, Todd Hodgen <[email protected]> wrote: >>>>> >>>>> > Here is a question I would have as well - 172.129.67.195 seems to be >>>>> an >>>>> > address that is local to your network. Who has that IP address, >>>>> why are >>>>> > they attempting to breach that server. If they are not a part of >>>>> your >>>>> > network, how are they getting to that server from outside your >>>>> network - >>>>> > there has to be an opening in a firewall somewhere that is allowing >>>>> it. >>>>> > >>>>> > Remember, this is a phone system, not a firewall, not a router. >>>>> It's a >>>>> > phone system with pretty standard authentication requirements, it's >>>>> up to >>>>> > the administrator to keep others off of the network. >>>>> > >>>>> > -----Original Message----- >>>>> > From: [email protected] >>>>> > [mailto:[email protected]] On Behalf Of Noah >>>>> Mehl >>>>> > Sent: Thursday, November 15, 2012 10:04 AM >>>>> > To: Discussion list for users of sipXecs software >>>>> > Subject: Re: [sipx-users] Hacked SipXecs 4.4 >>>>> > >>>>> > To that point: >>>>> > >>>>> > Users logging in through sshd: >>>>> > PlcmSpIp: >>>>> > 172.129.67.195 >>>>> > (AC8143C3.ipt.aol.com<http://ac8143c3.ipt.aol.com/>): >>>>> 1 time >>>>> > >>>>> > That can't be good. I understand that PlcmSplp is a user for the >>>>> Polycom >>>>> > provisioning. I have removed ssh access to the box from the world, >>>>> but how >>>>> > do I change the default password for that user? This seems like a >>>>> big >>>>> > security risk, as every sipxecs install probably has this user with a >>>>> > default password? >>>>> > >>>>> > ~Noah >>>>> > >>>>> > On Nov 15, 2012, at 12:41 PM, Todd Hodgen <[email protected]> >>>>> wrote: >>>>> > >>>>> >> Look at var/spool/mail/root There is a report you can find in >>>>> there >>>>> > that >>>>> >> shows system activity. Look for entries below --------------------- >>>>> >> pam_unix Begin ------------------------ and I think you will find >>>>> the >>>>> >> source of your aggravation. >>>>> >> >>>>> >> -----Original Message----- >>>>> >> From: [email protected] >>>>> >> [mailto:[email protected]] On Behalf Of Noah >>>>> Mehl >>>>> >> Sent: Thursday, November 15, 2012 6:29 AM >>>>> >> To: Discussion list for users of sipXecs software >>>>> >> Subject: Re: [sipx-users] Hacked SipXecs 4.4 >>>>> >> >>>>> >> I am seeing more spam in my mail queue. I have iptables installed, >>>>> >> and here are my rules: >>>>> >> >>>>> >> Chain INPUT (policy ACCEPT) >>>>> >> target prot opt source destination >>>>> >> RH-Firewall-1-INPUT all -- anywhere anywhere >>>>> >> >>>>> >> Chain FORWARD (policy ACCEPT) >>>>> >> target prot opt source destination >>>>> >> RH-Firewall-1-INPUT all -- anywhere anywhere >>>>> >> >>>>> >> Chain OUTPUT (policy ACCEPT) >>>>> >> target prot opt source destination >>>>> >> >>>>> >> Chain RH-Firewall-1-INPUT (2 references) >>>>> >> target prot opt source destination >>>>> >> ACCEPT all -- anywhere anywhere >>>>> >> ACCEPT icmp -- anywhere anywhere icmp >>>>> any >>>>> >> ACCEPT esp -- anywhere anywhere >>>>> >> ACCEPT ah -- anywhere anywhere >>>>> >> ACCEPT udp -- anywhere 224.0.0.251 udp >>>>> dpt:mdns >>>>> >> ACCEPT udp -- anywhere anywhere udp >>>>> dpt:ipp >>>>> >> ACCEPT tcp -- anywhere anywhere tcp >>>>> dpt:ipp >>>>> >> ACCEPT all -- anywhere anywhere state >>>>> >> RELATED,ESTABLISHED >>>>> >> ACCEPT tcp -- anywhere anywhere state >>>>> NEW tcp >>>>> >> dpt:pcsync-https >>>>> >> ACCEPT tcp -- anywhere anywhere state >>>>> NEW tcp >>>>> >> dpt:http >>>>> >> ACCEPT tcp -- anywhere anywhere state >>>>> NEW tcp >>>>> >> dpt:xmpp-client >>>>> >> ACCEPT tcp -- anywhere anywhere state >>>>> NEW tcp >>>>> >> dpt:5223 >>>>> >> ACCEPT all -- 192.168.0.0/16 anywhere >>>>> >> ACCEPT udp -- anywhere anywhere state >>>>> NEW udp >>>>> >> dpt:sip >>>>> >> ACCEPT tcp -- anywhere anywhere state >>>>> NEW tcp >>>>> >> dpt:sip >>>>> >> ACCEPT tcp -- anywhere anywhere state >>>>> NEW tcp >>>>> >> dpt:sip-tls >>>>> >> ACCEPT udp -- sip02.gafachi.com anywhere state >>>>> NEW udp >>>>> >> dpts:sip:5080 >>>>> >> ACCEPT udp -- 204.11.192.0/22 anywhere state >>>>> NEW udp >>>>> >> dpts:sip:5080 >>>>> >> REJECT all -- anywhere anywhere >>>>> reject-with >>>>> >> icmp-host-prohibited >>>>> >> >>>>> >> As far as I can tell, no one should be able to use port 25 from the >>>>> world. >>>>> >> Also, sendmail is only configured to allow relay from localhost: >>>>> >> >>>>> >> [root@sipx1 ~]# cat /etc/mail/access >>>>> >> # Check the /usr/share/doc/sendmail/README.cf file for a >>>>> description # >>>>> >> of the format of this file. (search for access_db in that file) # >>>>> The >>>>> >> /usr/share/doc/sendmail/README.cf is part of the sendmail-doc # >>>>> package. >>>>> >> # >>>>> >> # by default we allow relaying from localhost... >>>>> >> Connect:localhost.localdomain RELAY >>>>> >> Connect:localhost RELAY >>>>> >> Connect:127.0.0.1 RELAY >>>>> >> >>>>> >> Can someone please help me figure out where this spam is coming >>>>> from? >>>>> >> Thanks. >>>>> >> >>>>> >> ~Noah >>>>> >> >>>>> >> On Oct 13, 2012, at 10:17 AM, Noah Mehl <[email protected]> >>>>> wrote: >>>>> >> >>>>> >>> I did not change the configuration of anything related to the >>>>> >>> PlcmSpIp >>>>> >> user. It does however make me feel better that it is related to the >>>>> >> vsftpd service and the polycom phones. >>>>> >>> >>>>> >>>> From /etc/passwd: >>>>> >>> >>>>> >>> >>>>> PlcmSpIp:x:500:500::/var/sipxdata/configserver/phone/profile/tftproot: >>>>> >>> /sbin/nologin >>>>> >>> >>>>> >>> So, that user cannot ssh to a shell. So I don't think it was that. >>>>> >>> >>>>> >>> ~Noah >>>>> >>> >>>>> >>> On Oct 12, 2012, at 9:05 AM, Tony Graziano >>>>> >>> <[email protected]> >>>>> >> wrote: >>>>> >>> >>>>> >>>> ... more -- its a user that does not have login to the OS itself, >>>>> >>>> just vsftpd, which is restricted to certain commands and must >>>>> >>>> present a request for its mac address in order to get a >>>>> configuration >>>>> > file. >>>>> >>>> It is not logging into linux unless someone changed the rights of >>>>> >>>> the user. >>>>> >>>> >>>>> >>>> On Fri, Oct 12, 2012 at 7:30 AM, George Niculae <[email protected] >>>>> > >>>>> > wrote: >>>>> >>>>> On Fri, Oct 12, 2012 at 2:26 PM, Tony Graziano >>>>> >>>>> <[email protected]> wrote: >>>>> >>>>>> this is not a valid system user unless you have manually added >>>>> it >>>>> >>>>>> to the system. I do think the logs would show more if access was >>>>> >>>>>> granted. Why are you exposing sshd to the outside world with an >>>>> >>>>>> acl or by protecting it at your firewall? >>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> PlcmSpIp is the user used by polycom phones for fetching config >>>>> >>>>> from server >>>>> >>>>> >>>>> >>>>> George >>>>> >>>>> _______________________________________________ >>>>> >>>>> sipx-users mailing list >>>>> >>>>> [email protected] >>>>> >>>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>>> >>>> >>>>> >>>> >>>>> >>>> >>>>> >>>> -- >>>>> >>>> ~~~~~~~~~~~~~~~~~~ >>>>> >>>> Tony Graziano, Manager >>>>> >>>> Telephone: 434.984.8430 >>>>> >>>> sip: [email protected] >>>>> >>>> Fax: 434.465.6833 >>>>> >>>> ~~~~~~~~~~~~~~~~~~ >>>>> >>>> Linked-In Profile: >>>>> >>>> http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 >>>>> >>>> Ask about our Internet Fax services! >>>>> >>>> ~~~~~~~~~~~~~~~~~~ >>>>> >>>> >>>>> >>>> Using or developing for sipXecs from SIPFoundry? Ask me about >>>>> >>>> sipX-CoLab >>>>> >> 2013! >>>>> >>>> >>>>> >>>> -- >>>>> >>>> LAN/Telephony/Security and Control Systems Helpdesk: >>>>> >>>> Telephone: 434.984.8426 >>>>> >>>> sip: [email protected] >>>>> >>>> >>>>> >>>> Helpdesk Customers: http://myhelp.myitdepartment.net >>>>> >>>> Blog: http://blog.myitdepartment.net >>>>> >>>> _______________________________________________ >>>>> >>>> sipx-users mailing list >>>>> >>>> [email protected] >>>>> >>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>>> >>> >>>>> >>> >>>>> >>> Scanned for viruses and content by the Tranet Spam Sentinel >>>>> service. >>>>> >>> _______________________________________________ >>>>> >>> sipx-users mailing list >>>>> >>> [email protected] >>>>> >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>>> >> >>>>> >> _______________________________________________ >>>>> >> sipx-users mailing list >>>>> >> [email protected] >>>>> >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>>> >> >>>>> >> _______________________________________________ >>>>> >> sipx-users mailing list >>>>> >> [email protected] >>>>> >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>>> > >>>>> > _______________________________________________ >>>>> > sipx-users mailing list >>>>> > [email protected] >>>>> > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>>> > >>>>> > _______________________________________________ >>>>> > sipx-users mailing list >>>>> > [email protected] >>>>> > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>>> >>>>> _______________________________________________ >>>>> sipx-users mailing list >>>>> [email protected] >>>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>>> >>>> >>>> LAN/Telephony/Security and Control Systems Helpdesk: >>>> Telephone: 434.984.8426 >>>> sip: [email protected].**net<[email protected]> >>>> >>>> Helpdesk Customers: >>>> http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net/> >>>> Blog: http://blog.myitdepartment.net >>>> _______________________________________________ >>>> sipx-users mailing list >>>> [email protected] >>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> sipx-users mailing list >>>> [email protected] >>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>> >>> >>> LAN/Telephony/Security and Control Systems Helpdesk: >>> Telephone: 434.984.8426 >>> sip: [email protected].**net<[email protected]> >>> >>> Helpdesk Customers: >>> http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net/> >>> Blog: http://blog.myitdepartment.net >>> _______________________________________________ >>> sipx-users mailing list >>> [email protected] >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >>> >>> >>> >>> _______________________________________________ >>> sipx-users mailing list >>> [email protected] >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >>> >>> >>> >>> >>> _______________________________________________ >>> sipx-users mailing list >>> [email protected] >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >> >> LAN/Telephony/Security and Control Systems Helpdesk: >> Telephone: 434.984.8426 >> sip: [email protected].**net<[email protected]> >> >> Helpdesk Customers: >> http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net/> >> Blog: http://blog.myitdepartment.net >> _______________________________________________ >> sipx-users mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >> >> >> >> >> _______________________________________________ >> sipx-users mailing list >> [email protected] >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> > > > > -- > ~~~~~~~~~~~~~~~~~~ > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: [email protected] > Fax: 434.465.6833 > ~~~~~~~~~~~~~~~~~~ > Linked-In Profile: > http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4 > Ask about our Internet Fax services! > ~~~~~~~~~~~~~~~~~~ > > Using or developing for sipXecs from SIPFoundry? Ask me about sipX-CoLab > 2013! > <http://sipxcolab2013.eventbrite.com/?discount=tony2013> > > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: [email protected].**net<[email protected]> > > Helpdesk Customers: > http://myhelp.myitdepartment.**net<http://myhelp.myitdepartment.net/> > Blog: http://blog.myitdepartment.net > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > > > > > _______________________________________________ > sipx-users mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-users/ >
_______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
