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] 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/
