Thanks for the confirmation Noah.
From: sipx-users-boun...@list.sipfoundry.org [mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Noah Mehl Sent: Friday, November 16, 2012 9:52 AM To: Discussion list for users of sipXecs software Subject: Re: [sipx-users] Hacked SipXecs 4.4 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 <n...@tritonlimited.com> 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 <tgrazi...@myitdepartment.net> 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" <n...@tritonlimited.com> 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 <tgrazi...@myitdepartment.net> 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" <n...@tritonlimited.com> 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 <thod...@frontier.com> 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: sipx-users-boun...@list.sipfoundry.org > [mailto:sipx-users-boun...@list.sipfoundry.org] 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 <thod...@frontier.com> 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: sipx-users-boun...@list.sipfoundry.org >> [mailto:sipx-users-boun...@list.sipfoundry.org] 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 <http://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 <n...@tritonlimited.com> 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 >>> <tgrazi...@myitdepartment.net> >> 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 <geo...@ezuce.com> > wrote: >>>>> On Fri, Oct 12, 2012 at 2:26 PM, Tony Graziano >>>>> <tgrazi...@myitdepartment.net> 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 >>>>> sipx-users@list.sipfoundry.org >>>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>>> >>>> >>>> >>>> -- >>>> ~~~~~~~~~~~~~~~~~~ >>>> Tony Graziano, Manager >>>> Telephone: 434.984.8430 >>>> sip: tgrazi...@voice.myitdepartment.net >>>> 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: helpd...@voice.myitdepartment.net >>>> >>>> Helpdesk Customers: http://myhelp.myitdepartment.net <http://myhelp.myitdepartment.net/> >>>> Blog: http://blog.myitdepartment.net <http://blog.myitdepartment.net/> >>>> _______________________________________________ >>>> sipx-users mailing list >>>> sipx-users@list.sipfoundry.org >>>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >>> >>> >>> Scanned for viruses and content by the Tranet Spam Sentinel service. >>> _______________________________________________ >>> sipx-users mailing list >>> sipx-users@list.sipfoundry.org >>> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >> _______________________________________________ >> sipx-users mailing list >> sipx-users@list.sipfoundry.org >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ >> >> _______________________________________________ >> sipx-users mailing list >> sipx-users@list.sipfoundry.org >> List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ > > _______________________________________________ > sipx-users mailing list > sipx-users@list.sipfoundry.org > List Archive: http://list.sipfoundry.org/archive/sipx-users/ _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/ LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpd...@voice.myitdepartment.net Helpdesk Customers: http://myhelp.myitdepartment.net <http://myhelp.myitdepartment.net/> Blog: http://blog.myitdepartment.net <http://blog.myitdepartment.net/> _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/ -- _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/ LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpd...@voice.myitdepartment.net Helpdesk Customers: http://myhelp.myitdepartment.net <http://myhelp.myitdepartment.net/> Blog: http://blog.myitdepartment.net <http://blog.myitdepartment.net/> _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/ -- _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/ --
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
