Our SIP honeypot sprung last night on hackers out of Palestine. On the face of it their attack was very typical – OPTIONS request, dictionary REGISTER scan followed by a number of INVITEs once they had identified a successful user name and password. Typically too their IP address (one with no adverse history) was submitted to ThreatSTOP so IP Reputation customers could be protected from attacks from the same source very quickly.
However, our attention was also drawn to traffic from one of our friendly UK competitors. Initially we suspected foul play (sorry guys!) until we discovered we were initiating the traffic to them and on investigation this traffic was tied back to the Palestinian intrusion.
We’ve used a pretty much default installation for our Honeypots in order to catch attacks targeting the same, and on closer inspection we’ve caught a style of attack we have not seen before. These guys are very clever it seems and the methodology used enables an attacker to leverage an open ENUM service to turn equipment performing ENUM lookups into a SIP relay. By default even with no gateways/trunks configured most of the common open source gateway solutions make ENUM lookups by default and are vulnerable to this.
In this case our attackers passed a call to an international toll-free number, an ENUM lookup was made and a result returned from Freenum. That result contained URIs at two other providers, one wholesale, one retail, both of whom had injected records into FreeNum for the completion of such calls.
This got us thinking that theoretically this could be used to make an INVITE to any URI from the account on the compromised box even if URI dialling is disabled. This could have multiple consequences:
- – Calls ‘from’ the compromised box to an authenticated route would be billed as originating from that box. This is more easily done with the user name and password they have obtained by direct INVITEs however.
- – The compromised account may not be permitted to make chargeable calls in the dial-plan but using ENUM this can be circumvented. This might have interesting knock-on implications for many types of fraud monitoring which consider the ENUM routed call to be free.
- – The compromised box can trivially be used as a relay to route to other compromised boxes, or initiate attacks and appear as the perpetrator.
Tjardick set about putting our theory to the test and indeed with a compromised account on a box performing the default ENUM lookups, was able to make both chargeable calls and dial URIs via the compromised box.
Freenum allocates registrants a short code which refers to their entity. This enables a number to be assembled of the form <any_number>*<my_freenum_id>. An ENUM lookup for this number will return a record containing available URIs. There’s nothing unusual here but as this all hangs under <my_freenum_id> one has complete control what those records are and they can easily be of the form sip:<dial_this_number>@<any_sip_provider>. Records can be changed on the Freenum website or users can even have delegated DNS and make changes locally. We could dial 1*<my_freenum_id> and change that FreeNum side to return <dial_another_number>@<any_sip_provider> or simply set up some wildcard matching such that 1*<my_freenum_id> routes to provider X, and 2*<my_freenum_id> routes to provider Y.
As the compromised box is dialling a ‘number’ any restriction on URI dialling doesn’t apply and since the call follows a positive ENUM hit it might be assumed to be settlement free for fraud monitoring purposes. This requires a compromised registration and to actually place calls chargeable to the compromised network would require a hit on the provider authenticating traffic from that source, but it is possible. With a single Freenum account an attacker can quickly try multiple third party providers using pre-configured patterns.
We consider the biggest risk here is that the box is used to route to other relays or conduct attacks, implicating the compromised equipment, hiding the true source and all remotely controlled through configuration of the ENUM records.
We recommend turning off the default ENUM look-ups or certainly making them conscious and part of considered dial-plan logic. You could also force INVITEs resulting from ENUM lookups out over a dedicated interface which has no gateways configured on it although this will still enable the relay to used against third parties.
In conclusion we consider this validates the idea that monitoring cost reports or the other home-grown methods of fraud control in use by providers are inadequate and too late in the cycle. Stopping traffic getting to equipment through the use of IP Reputation helps prevent intrusion in the first place and in this case the attacker’s IP address was blocked from production equipment and customers before they began passing actual INVITEs to the Honeypot.
