my zeroshell compromised [hacked]

Home Page Forums Network Management ZeroShell my zeroshell compromised [hacked]

This topic contains 3 replies, has 0 voices, and was last updated by  ieee754 9 years ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #42634

    ieee754
    Member

    its an unfortunate situation. after 155 days of uptime since i comissioned 1.0.beta13 my zeroshell has been compromised.

    i dont claim to be a security guru – but i am at a loss as to how i was penetrated. any assistance deducing the entry point would be appreciated.

    setup:

    vmware hosted zeroshell 1.0.beta13.
    multiple wan’s: 5x ppp connections.
    multiple vpn’s, bonded, to 3 other remote zeroshell’s.
    eth0 is lan.
    eth1 through eth5 are wan/ppp.
    no dhcp.
    nat enabled on vpn bonds and all ppp connections.

    no default passwords. admin password > 20 char in length w/ no dictionary content.
    ssh and https management only allowed on lan subnet.

    firewall chains as per defaults -> accept.

    virtual lan has a handful of specific entries for my asterisk box.
    udp 5060 and udp 10000:20000 in particular only fwd from my voip providers specific server ip.

    exact chain detail is as follows;

    Chain PREROUTING (policy ACCEPT 833 packets, 80286 bytes)
    pkts bytes target prot opt in out source destination
    xxx.147.xxx.12 udp dpt:5060 to:192.168.xxx.250:5060
    0 0 DNAT udp -- ppp0 * 0.0.0.0/0 xxx.147.xxx.12 udp dpts:10000:20000 to:192.168.xxx.250:10000-20000
    0 0 DNAT tcp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 to:192.168.xxx.7:80
    0 0 DNAT udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp dpts:10000:20000 to:192.168.xxx.250
    0 0 DNAT udp -- ppp0 * 0.0.0.0/0 0.0.0.0/0 udp dpt:5060 to:192.168.xxx.250

    Chain POSTROUTING (policy ACCEPT 45 packets, 6197 bytes)
    pkts bytes target prot opt in out source destination
    829 74870 SNATVS all -- * * 0.0.0.0/0 0.0.0.0/0
    459 44548 MASQUERADE all -- * BOND00 0.0.0.0/0 0.0.0.0/0
    36 4302 MASQUERADE all -- * BOND01 0.0.0.0/0 0.0.0.0/0
    2 1340 MASQUERADE all -- * BOND02 0.0.0.0/0 0.0.0.0/0
    91 6156 MASQUERADE all -- * ppp0 0.0.0.0/0 0.0.0.0/0
    53 4024 MASQUERADE all -- * ppp1 0.0.0.0/0 0.0.0.0/0
    42 2668 MASQUERADE all -- * ppp2 0.0.0.0/0 0.0.0.0/0
    55 3816 MASQUERADE all -- * ppp3 0.0.0.0/0 0.0.0.0/0
    68 4924 MASQUERADE all -- * ppp4 0.0.0.0/0 0.0.0.0/0

    Chain SNATVS (1 references)
    pkts bytes target prot opt in out source destination

    ok so…..how do i know that i’ve been compromised? a couple of international calls are made using my asterisk box. my dialing pattern DOES support international, but i dont call international. so i knew something was up.

    i investigated.

    there is a ‘shadow’ registration of one of my internal extensions. the sip password has been cracked somehow – ok i haven’t used very complex passwords which is a weakness, so brut force probably.

    however, registration is to an external ip. an external ip that is fwding through the zeroshell, over udp 5060. to an ip other than that of my voip isp which i have defined in zeroshell’s port forwarding.

    the ip address is spoofed. its something like 99.89.123.44. i can ping it – 250ms from the lan. tracert confirms its routed straight out and through the zeroshell and about 12 hops away.

    geoip lookup cant located it.

    so i investigate zeroshell’s connections. as i’m doing so, i notice, using the onnection tracker, that im being port scanned, from guess what ip???

    127.0.0.1!

    heaps of attempted connections with ascending port numbers.

    lovely!

    nothing in the admin interface hints that i’ve been hacked though. it all looks fine and as i left it.

    i added some iptables entries into the asterisk box for insurance, and rebooted it and the zeroshell.

    i then observed these connections to my asterisk box:

    udp      17 6 src=192.168.xxx.250 dst=72.18.205.156 sport=123 dport=123 packets=1 bytes=76 src=72.18.205.156 dst=165.xxx.xx.7 sport=123 dport=123 packets=1 bytes=76 mark=101 use=1
    udp 17 3562 src=192.168.xxx.2 dst=192.168.xxx.250 sport=1024 dport=5060 packets=134149 bytes=59862708 src=192.168.xxx.250 dst=192.168.xxx.2 sport=5060 dport=1024 packets=136333 bytes=75650541 [ASSURED] mark=0 use=1
    udp 17 3562 src=192.168.xxx.2 dst=192.168.xxx.250 sport=5060 dport=5060 packets=134953 bytes=60870939 src=192.168.xxx.250 dst=192.168.xxx.2 sport=5060 dport=5060 packets=137111 bytes=76084706 [ASSURED] mark=0 use=1
    udp 17 3033 src=125.88.105.44 dst=165.228.xxx.7 sport=5060 dport=5060 packets=1 bytes=437 [UNREPLIED] src=192.168.xxx.250 dst=125.88.105.44 sport=5060 dport=5060 packets=0 bytes=0 mark=0 use=2
    udp 17 3557 src=192.168.xxx.2 dst=192.168.xxx.250 sport=5060 dport=5060 packets=37989 bytes=17021053 src=192.168.xxx.250 dst=192.168.xxx.2 sport=5060 dport=5060 packets=47152 bytes=26264985 [ASSURED] mark=0 use=1
    udp 17 144 src=192.168.xxx.250 dst=192.168.xxx.253 sport=33524 dport=53 packets=72 bytes=5184 src=192.168.xxx.253 dst=192.168.xxx.250 sport=53 dport=33524 packets=72 bytes=23060 [ASSURED] mark=0 use=1
    udp 17 3564 src=192.168.xxx.250 dst=202.xxx.xxx.12 sport=5060 dport=5060 packets=418765 bytes=257622409 src=202.147.130.12 dst=165.xxx.xxx.7 sport=5060 dport=5060 packets=420309 bytes=183205860 [ASSURED] mark=101 use=1

    those to 202.xxx.xxx.12 are fine – and those to 192.xxx are ok also – as they are all vpn lans – EXCEPT those connections to 125.88.105.44 and to 192.168.xxx.253 (which is the zeroshell).

    Also, these connections are established as ‘127.0.0.1’ which i know is not normal.

    I added ‘DROP’ entries into the firewall INPUT chain for all 127.0.0.1 on all interfaces – reboot – but these connecitons remain:


    tcp 6 431713 ESTABLISHED src=127.0.0.1 dst=127.0.0.1 sport=56021 dport=389 packets=16911 bytes=2294613 src=127.0.0.1 dst=127.0.0.1 sport=389 dport=56021 packets=16909 bytes=2754780 [ASSURED] mark=0 use=1
    tcp 6 431947 ESTABLISHED src=127.0.0.1 dst=127.0.0.1 sport=56020 dport=389 packets=17108 bytes=2319563 src=127.0.0.1 dst=127.0.0.1 sport=389 dport=56020 packets=17108 bytes=2791776 [ASSURED] mark=0 use=1

    I have taken additional steps to harden my asterisk registrations, but
    I’m scared!

    Ditching the zeroshell box or starting from scratch involves a great deal of pain, and it appears it will only return me to the same level of weakness.

    A weakness in my understanding perhaps?

    Thanks for reading this far – now for your thoughts…… 😥

    #51063

    dr1
    Member

    Ok for starters the bottom entry is a connection to LDAP, which is normal. So target phasers elsewhere, lol.
    Sounds to me, if anything happened, your asterisk machine was hacked.

    #51064

    LL0rd
    Member

    About a year ago, I had the same problem with my asterisk server. I have no idea how, but somebody hacked my asterisk server (in the data center) and placed a lot of international calls to nigeria or something like that.

    I think, it’s more an asterisk problem than a ZeroShell

    #51065

    atheling
    Member

    “firewall chains as per defaults -> accept.”

    That might be default to allow you into a new installation to configure it but the more general practice by firewall administrators it to have a default policy of reject and then specific rules to pass desired traffic.

    I have noticed a number of attempts to hack my Asterisk box, usually by brute force dictionary attacks. I don’t know of a way in Asterisk itself to block this. But you can greatly reduce the issue with a couple of rules in your firewall. I get a bit confused by the GUI and a lot of examples on how to do things on the web assume just straight IP tables, so I put the following into my “NAT and Virtual Servers” script. It basically cuts off an IP address if there are too many new connections (log in attempts) in a short amount of time. Don’t do this on HTTP because each fetch is another connection.

    Each protocol has two sets of entries, one for each of my two WAN links.

    # Block dictionary and flood attacks against traffic to servers
    iptables -t filter -N custom_forward
    # SSH port
    iptables -t filter -A custom_forward -p tcp –dport 22 -i ETH01 -m state –state NEW -m recent –update –seconds 600 –hitcount 4 -j DROP
    iptables -t filter -A custom_forward -p tcp –dport 22 -i ETH01 -m state –state NEW -m recent –set
    iptables -t filter -A custom_forward -p tcp –dport 22 -i ppp0 -m state –state NEW -m recent –update –seconds 600 –hitcount 4 -j DROP
    iptables -t filter -A custom_forward -p tcp –dport 22 -i ppp0 -m state –state NEW -m recent –set
    # POP3 port
    iptables -t filter -A custom_forward -p tcp –dport 110 -i ETH01 -m state –state NEW -m recent –update –seconds 60 –hitcount 10 -j DROP
    iptables -t filter -A custom_forward -p tcp –dport 110 -i ETH01 -m state –state NEW -m recent –set
    iptables -t filter -A custom_forward -p tcp –dport 110 -i ppp0 -m state –state NEW -m recent –update –seconds 60 –hitcount 10 -j DROP
    iptables -t filter -A custom_forward -p tcp –dport 110 -i ppp0 -m state –state NEW -m recent –set
    # Mail submission port
    iptables -t filter -A custom_forward -p tcp –dport 587 -i ETH01 -m state –state NEW -m recent –update –seconds 60 –hitcount 10 -j DROP
    iptables -t filter -A custom_forward -p tcp –dport 587 -i ETH01 -m state –state NEW -m recent –set
    iptables -t filter -A custom_forward -p tcp –dport 587 -i ppp0 -m state –state NEW -m recent –update –seconds 60 –hitcount 10 -j DROP
    iptables -t filter -A custom_forward -p tcp –dport 587 -i ppp0 -m state –state NEW -m recent –set
    # POP3S port
    iptables -t filter -A custom_forward -p tcp –dport 995 -i ETH01 -m state –state NEW -m recent –update –seconds 60 –hitcount 10 -j DROP
    iptables -t filter -A custom_forward -p tcp –dport 995 -i ETH01 -m state –state NEW -m recent –set
    iptables -t filter -A custom_forward -p tcp –dport 995 -i ppp0 -m state –state NEW -m recent –update –seconds 60 –hitcount 10 -j DROP
    iptables -t filter -A custom_forward -p tcp –dport 995 -i ppp0 -m state –state NEW -m recent –set
    # CVS port
    iptables -t filter -A custom_forward -p tcp –dport 2401 -i ETH01 -m state –state NEW -m recent –update –seconds 60 –hitcount 4 -j DROP
    iptables -t filter -A custom_forward -p tcp –dport 2401 -i ETH01 -m state –state NEW -m recent –set
    iptables -t filter -A custom_forward -p tcp –dport 2401 -i ppp0 -m state –state NEW -m recent –update –seconds 60 –hitcount 4 -j DROP
    iptables -t filter -A custom_forward -p tcp –dport 2401 -i ppp0 -m state –state NEW -m recent –set
    # SIP port
    iptables -t filter -A custom_forward -p udp –dport 5060 -i ETH01 -m state –state NEW -m recent –update –seconds 60 –hitcount 4 -j DROP
    iptables -t filter -A custom_forward -p udp –dport 5060 -i ETH01 -m state –state NEW -m recent –set
    iptables -t filter -A custom_forward -p udp –dport 5060 -i ppp0 -m state –state NEW -m recent –update –seconds 60 –hitcount 4 -j DROP
    iptables -t filter -A custom_forward -p udp –dport 5060 -i ppp0 -m state –state NEW -m recent –set
    iptables -t filter -A FORWARD -j custom_forward

    #51066

    ieee754
    Member

    @dr1 wrote:

    Ok for starters the bottom entry is a connection to LDAP, which is normal. So target phasers elsewhere, lol.
    Sounds to me, if anything happened, your asterisk machine was hacked.

    …but i dont have ldap enabled, nor have i – and on my other zeroshell’s this connection doesn’t exist. also – i had atleast 30 of them simultaneously.

    @ll0rd wrote:

    I think, it’s more an asterisk problem than a ZeroShell

    @atheling wrote:

    “firewall chains as per defaults -> accept.”

    That might be default to allow you into a new installation to configure it but the more general practice by firewall administrators it to have a default policy of reject and then specific rules to pass desired traffic.

    definately my weakness of implementation here. i set up port forwading rules for specific ip address’ but this is clearly inadequate.

    after watching and listening for some time with the nmap and connection tracking i observed port scans of the WANs from the same 24 subnet. spoofed ip, or compromised machine at my isp perhaps?

    i have since added DROP rules to all NEW connections and created exceptions to the port fwding as required.

    many thanks for your help and the lols 🙂

    ieee

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.