Hacked calls - how?


#1

In the CDR I see this over and over again.
Anyone seen this?
How can a call show up on the CDR without a source?

1/14/2020 1:00 "" <> 1.15016E+11 asterisk-outcalls Local/0115016102229@asterisk-outcalls-00000cd1;1


(Dave Burgess) #2

To start with, as an admin, stop using the CDR to debug. It’s good for an indicator, but once you have a question like this, you need to pivot to the /var/log/asterisk/full log to figure out what actually happened.


(Lorne Gaetz) #3

The context asterisk-outcalls is not a FreePBX generated context. You likely have spurious dialplan in /etc/asterisk/extensions_custom.conf that you will want to remove and then reload. Ensure all modules and rpms are up to date, and secure the system so that there is no untrusted traffic reaching the Admin GUI.


(Nate) #4

fwconsole validate --clean and fwconsole ma refreshsignatures will go some way in helping with this, but I also recommend checking a few other things, such as FreePBX administrator accounts that don’t belong there, linux users that either don’t belong or should not have passwords or have the wrong UID in /etc/passwd and /etc/shadow, and check the asterisk.cronmanager table in your database.

Note that fwconsole validate --clean will indiscriminately wipe out extensions_custom.conf, manager_custom.conf and one other config file that escapes me at the moment. However after you run it, you can find these in /tmp/freepbx_quarantine. I also think it ignores hidden files (those preceded with a dot) so you may want to check over things manually for good measure, particularly in the web root.

It would also be wise to assume your SIP secrets and admin passwords are compromised and reset them.


#5

This is what I found in the extensions_custom.conf
I don’t see a call out of the list of telephone numbers.

[asterisk-outcalls]; reloadout
exten => _.,1,Macro(user-callerid,LIMIT,EXTERNAL,); reloadout
exten => _.,n,Set(MOHCLASS=${IF($["${MOHCLASS}"=""]?default:${MOHCLASS})}); reloadout
exten => _.,n,Set(LANGUAGE()=en); reloadout
exten => _.,n,Set(_NODEST=); reloadout
exten => _.,n,NoCDR(); reloadout
exten => _.,n,Macro(dialout-trunk,1,${EXTEN},on); reloadout
exten => _.,n,Macro(dialout-trunk,3,${EXTEN},on); reloadout
exten => _.,n,Macro(outisbusy,); reloadout


(Nate) #6

That is a variant of this classic:

Usually occurs due to some outdated module, etc.

Recommend deleting that and carrying on with the items I recommended in a previous post on this thread. (alternatively, wipe and start fresh or restore from a known clean backup)


(Dave Burgess) #7

I recommend restart from scratch, set up the Integrated Firewall correctly, don’t allow access to port 80 from almost anywhere but your management console, and take your lumps.

A simple solution to this problem doesn’t teach the lesson that a good “belt session” from having to start over from scratch does.


(Lorne Gaetz) #8

To clarify, the recommendation is don’t allow access to the Admin GUI of FreePBX, regardless of what port it’s on. It’s actually necessary to allow access to port 80 if you are using it for LetsEncrypt validation.