Hack attempt. How to disable call transfers?

Hello everyone

I get an incomming call which asterisk sends to an ATA. ATA responds with “302 Moved Temporarily”. And then asterisk tries to make an overseas call. This is what I see on console.

– Got SIP response 302 “Moved Temporarily” back from 171.151.111.61
– Now forwarding SIP/1.1.1.1-adb0c890 to ‘Local/002209162112@voipprovider’ (thanks to SIP/950000000-aea36918)
– Executing [002209162112@voipprovider:1] Hangup(“Local/002209162112@voipprovider-71a8;2”, “”) in new stack

From what I can tell, if this particular extension would have overseas calls enabled in its dialplan, the call would succeed. How can I prevent this type of attacks?

You appear to be using rather an old version of Asterisk. Supported versions don’t use the form of SIP channel instance name that you have.

This is a redirection, not a transfer.

This attack seems to be an inside job, so the real solution is probably a social engineering one rather than a telephony one.

voipprovider sounds like an incoming calls context. Such contexts should never have the ability to make toll calls. I would therefore suggest that you have a basic security flaw in your dialplan.

Thanks for your reply.

Yes, the version is quite old. It is 1.6.0.9.

The device that is making a 302 redirect is a linksys ata. It is possible that someone gained access to it remotely and has setup a redirect.

voipprovider is a context of a linksys ata that is making a redirect. This ata is allowed to make outgoing in-country non-free calls (but not international calls). The original incomming call is received in another context which only allows calls to asterisk local extensions.

Even though I understand that the fault is on ATA that had the redirect configured, I still have a couple of questions:

Is it possible to limit a redirect within original context where the call was received? From what I can tell, the incomming call is being received in a safe context only with access to local extensions. However after a redirect the context changes to ATA’s context.

Is it possible to reflect the extension that made a “302 redirect” in asterisk CDRs? Currently I can see the original external caller as a source number and an overseas number as a destination. Having only CDRs I’d have no idea about who made a redirect.

If your context names are at all sensible, the redirect is already happening in the original context, and the problem is that the original context is insecure.

CDRs only handle simple cases. For complex cases you need Call Event Logging, which is not in that version.

If an ATA has been compromised, you may have more serious problems.

This is my very simplified setup:
sip.conf

[voipprovider] type=peer context=locals ... [ata] type=friend context = voipprovider ...
extensions.conf

[code][locals]
exten=>950000000,1,Dial(SIP/ata)

[voipprovider]
include => locals
exten=>_XXXXXXXXX,1,Dial(SIP/${EXTEN}@voipprovider)
exten=>_X.,1,Hangup[/code]

From what I understand, the context of the original incomming call is “locals”. However after redirect the context is “voipprovider”. Is my “local” context insecure? The context change should not be happening?

No. Your context naming is just confusing.

I actually thought that redirects were done in the default context, but to be certain of the answer I would need to read the code on your specific version of Asterisk, and as we have to use promiscredir, and a later version, that doesn’t benefit me.

Is there any possibility that you have set voipprovider as the default context?

It is possible that there is a channel variable to override the context for redirects.

However, if an internal device has been hacked, that is the real security breach.

Apart from a security issue with ATA I have another problem. In a case of redirect I can’t really bill based on asterisk CDRs. In CDRs I can see an original caller’s external number and a an external number where the call has been redirected to. Nothing on what extension made a redirect. Is there a way to detect the redirect attemt so I could change the CDR(accountcode) in dialplan when that happens?