Hacked (?) - can't explain how


#1

Hi,

Like most people with an exposed-to-the-Internet PBX, hack attempts are too numerous to count. My fail2ban script does a good job of killing them quickly.

I am running asterisk 13.21-cert3 (latest) on an up-to-date CentOS7 server. Something just happened that sort of freaked me out. I have a few static SIP peers (for internal asterisk-to-asterisk communications). For example, on the relevant PBX I have a SIP friend calls PBX7, with ip 192.168.1.7 .

Suddently, while debugging something else I started seeing a lot of failed INVITES - messages I am not used to seeing. After a quick investigation, I realized by typing the command “sip show peer pbx7” that the address of this friend (host=192.168.1.7, so static) had now become 188.161.194 (quick search shows that it came from the Palestinian territory). I quickly reloaded sip with “sip reload” (and blocked the relevant Palestinian IPs).

That being said, how can a SIP friend/user/whatever that is set to be configured statically change IP suddently? I don’t even know where to start looking.

I looked at all the usual suspects here:

  • There was no console login (root or otherwise) besides my own
  • The SIP settings for PBX7 in the sip.conf file had not changed (still 192.168.1.7)
  • All services are firewalled to the world except for VoIP related (SIP and RTP)

Here is my sip show peer for this PBX7 peer (after the SIP reload, I didnt think of running this while the “hack” was going on.

  • Name : pbx7
    Description :
    Realtime peer: No
    Secret :
    MD5Secret :
    Remote Secret:
    Context : some_context
    Record On feature : automon
    Record Off feature : automon
    Subscr.Cont. :
    Language :
    Tonezone :
    AMA flags : Unknown
    Transfer mode: open
    CallingPres : Presentation Allowed, Not Screened
    Callgroup :
    Pickupgroup :
    Named Callgr :
    Nam. Pickupgr:
    MOH Suggest :
    Mailbox :
    VM Extension : asterisk
    LastMsgsSent : 0/0
    Call limit : 0
    Max forwards : 0
    Dynamic : No
    Callerid : “” <>
    MaxCallBR : 384 kbps
    Expire : -1
    Insecure : no
    Force rport : Auto (No)
    Symmetric RTP: No
    ACL : No
    DirectMedACL : No
    T.38 support : No
    T.38 EC mode : Unknown
    T.38 MaxDtgrm: 4294967295
    DirectMedia : No
    PromiscRedir : No
    User=Phone : No
    Video Support: No
    Text Support : No
    Ign SDP ver : No
    Trust RPID : Yes
    Send RPID : Yes
    Path support : No
    Path : N/A
    TrustIDOutbnd: Legacy
    Subscriptions: Yes
    Overlap dial : Yes
    DTMFmode : rfc2833
    Timer T1 : 500
    Timer B : 32000
    ToHost : 192.168.1.7
    Addr->IP : 192.168.1.7:5060
    Defaddr->IP : (null)
    Prim.Transp. : UDP
    Allowed.Trsp : UDP
    Def. Username:
    SIP Options : replaces replace timer
    Codecs : (ulaw)
    Auto-Framing : No
    Status : OK (1 ms)
    Useragent :
    Reg. Contact :
    Qualify Freq : 60000 ms
    Keepalive : 0 ms
    Sess-Timers : Accept
    Sess-Refresh : uas
    Sess-Expires : 1800 secs
    Min-Sess : 90 secs
    RTP Engine : asterisk
    Parkinglot :
    Use Reason : No
    Encryption : No
    RTCP Mux : No

So, the real/underlying question here is: how can a host=192.168.1.7 suddently become to “host=188.161.194” without human intervention?

I’d undertstand if it was a host=dynamic type of thing, but it wasn’t


#2

You can protect your SIP peer using acl.conf or using sip option deny/permit


#3

Not sure how this is relevant for a SIP that has a static IP defined. Doesn’t this imply a “permit” only for that IP?

(really asking for my comprehension - I may be misunderstanding something)


#4

You didn’t provide the actual configuration, but this is one of the reasons why the standard cookbook approach of using type=friend is wrong.

type=friend will accept a call if either the user part of the From header matches the section name, or the host IP address matches, and will prefer a user part match.


#5

This was indeed my config before I changed it an hour ago to type=peer:

[pbx7]
type=friend
qualify=yes
host=192.168.1.7
sendrpid=pai
trustrpid=yes
disallow=all
allow=ulaw
dtmfmode=rfc2833
context=somecontext
canreinvite=no

So you’re saying that this might have been the hole in which somebody succeeded in inserting their IP address?

I did finally get a shot of the config after the hack, the sip show peer command showed this:
ToHost : 192.168.1.7
Addr->IP : 188.161.194:8886


#6

It is a hole through which they could masquerade as pbx7. It wouldn’t allow them to change the configuration

Type=friend on local devices can also be attacked, although they normally have passwords.


#7

I’m sharing an useful information that help you to understand this better.


This is always a confusing part of the chan_sip SIP channel driver.

Rather than try to dig into any history, here is the current documentation (from sip.conf.sample in the Asterisk source of
1.8,11,12) that you should base your decision to use a particular
“type” on:

“; SIP entities have a ‘type’ which determines their roles within Asterisk.
; * For entities with ‘type=peer’:
; Peers handle both inbound and outbound calls and are matched by ip/port, so for
; The case of incoming calls from the peer, the IP address must match in order for
; The invitation to work. This means calls made from either direction won’t work if
; The peer is unregistered while host=dynamic or if the host is otherise not set to
; the correct IP of the sender.
; * For entities with ‘type=user’:
; Asterisk users handle inbound calls only (meaning they call Asterisk, Asterisk can’t
; call them) and are matched by their authorization information
(authname and secret).
; Asterisk doesn’t rely on their IP and will accept calls regardless of the host setting
; as long as the incoming SIP invite authorizes successfully.
; * For entities with ‘type=friend’:
; Asterisk will create the entity as both a friend and a peer. Asterisk will accept
; calls from friends like it would for users, requiring only that the authorization
; matches rather than the IP address. Since it is also a peer, a friend entity can
; be called as long as its IP is known to Asterisk. In the case of host=dynamic,
; this means it is necessary for the entity to register before Asterisk can call it.”

Most new work for SIP support in Asterisk is happening around res_pjsip[1][2]. I don’t know that there is any plans to deprecate type=user going forward in chan_sip.

New installs of older Asterisk versions? That doesn’t sound wise, seeing as the 1.6 branch doesn’t have any support, even for security issues… A new install of Asterisk should be on a version of Asterisk supported by the developers.[3] Right now, that would be the latest of the 1.8,11, or 12 branches. That being said, 12 is rather new and has many significant changes that should be considered.[3]


#8

Thanks for the info @david551 and @ambiorixg12 - I guess I should have known that, I simply assumed host=static_ip was sufficient to completely restrict the SIP user to that static IP. I changed all my none-passworded SIP friends to peers, hoping this fixes it once and for all.