Resetting SNOM HTTP credentials for the lazy

Sometimes somebody locks your SNOM phone down to user mode and also sets credentials for the webinterface. You can revoke those changes either by using the HTTP provisioning mechanism or by flashing a recovery image via TFTP.

If you already have a working provisioning mechanism (e.g. by setting the option in your DHCP server) to unlock your phone then it wasn’t a problem in the first place.

Flashing a recovery image via TFTP is no fun either as you need physical access to the phone (for setting up a static ip address, etc) and also it deletes all settings (especially those you might be interested in…).

Fortunately SNOM phones have a plug and play mode which can be (ab)used by somebody on the local network. By default, a phone will send a SIP Subscribe message to the multicast ip address after each boot. A provisioning server can then send a SIP Notify message containg a HTTP URL for provisioning.

I made a small node.js application that listens for those SIP Subscribe messages and feeds them a XML configuration that resets the HTTP username and password to “admin” and also switches from user mode to admin mode.

Just start it with “node snomreset.js <yourIpAddress>” and have fun:

SIP listening
Received SUBSCRIBE from MAC 0004134001F4
Sending Ok
Sending NOTIFY with provisioning URL
Resetting HTTP user and password to “admin”, enabling admin mode.
Resetting HTTP user and password to “admin”, enabling admin mode.
Resetting HTTP user and password to “admin”, enabling admin mode.

You can download the snomreset.js application here.

Mass deployment of SIP phones

While implementing a mass deployment of SIP phones for a client, I took a closer look at how the process works and i found things on the public internet that you wouldn’t believe!

Scanning for SIP servers and bruteforcing accounts is very popular these days. But it is a lot more efficient when you can just ask for the SIP accounts without scanning (reverse mass deployment).

How does mass deployment work?

After booting (or in regular intervals) a device will contact a provisioning server (usually via HTTP, HTTPS or TFTP) to download a configuration file (usually XML or a proprietary format).

The URL of the provisioning server and configuration file is either learned by a DHCP option, a SIP Notify message or stored in the configuration of the device.

To identify individual devices the MAC address of the device is either part of the configuration file name or is passed as a parameter to a HTTP/HTTPS URL.

In most cases there is no authentication between the device and the provisioning server. The provisioning server will transmit the configuration data to anybody who is providing a valid MAC address (“valid” meaning “the address is known by the server”) .

What is a MAC address?

MAC (Media Access Control) addresses are unique identifiers assigned to network interfaces for communications on the the physical network segment.

Each MAC address consists of 6 octets. The 3 most significant octets are called the OUI (Organisationally Unique Identifier) and are identifying the manufacturer of the device.

The structuring of the remaining 3 octets are up to the device manufacturer.

What is a MAC address NOT?

A MAC address is a unique identifier. It is NOT an unguessable token suitable for authentication! Don’t confuse a sequence of 12 hexadecimal characters with something like a SHA1 hash. Just because it is hexadecimal doesn’t mean it is unguessable or secure.

There are only 16.7 million (2^24) addresses for one OUI (and the OUI is always known).

Some manufacturers use the most significant octet (of their 3 octets) to identify the device model, leaving only 2 octets for actual devices, reducing the number of MAC addresses for a known device model prefix to 65536.

If the list of device model prefixes is known then the attacker is able to select which type of device to bruteforce first (users of expensive business phones might have more interesting SIP accounts than users of cheaper phones).

How does reverse mass deployment work?

If an attacker knows the URL of the provisioning server, e.g. by having a device that is configured by his SIP provider (hosted PBX, etc), it is trivial to extract the configuration of all other devices by simply bruteforcing the MAC address which is part of the provisioning URL (given that there is no additional authentication apart from the MAC address).

Some provisioning systems generate the configuration on demand and are vulnerable to the usual SQL injection attacks. Usually it’s just a bit of PHP and MySQL.

Others generate static files and store them on a HTTP/HTTPS or TFTP server and allow access to the directory listing from the public internet!

What can be done to make mass deployment more secure?

The only secure way of provisioning requires mutual authentication between the device and the provisioning server, e.g. by storing individual client certificates on the device.
To implement this the device firmware needs to be modified, so it can only be implemented by the manufacturer. There is also a good chance that someone will get the SSL stuff wrong (once more).

Instead of the MAC address a UUID (Universally Unique IDentifier) should be used. It is a 16 octet number defined in RFC 4122, e.g. “550e8400-e29b-11d4-a716-446655440000”.

Ideally it would be generated and stored in non-volatile memory when the device is manufactured. Again this needs to be implemented by the manufacturer.

However something similar can be built without the help of the manufacturer if the provisioning server URL in the device can be configured (which is true in most cases). In a two step process a UUID will be generated and stored as part of the provisioning server URL:

First step (MAC-UUID pairing):

The regular MAC addressed based provisioning mechanism is used. The provisioning server will lookup the device in an “unconfigured devices” database table by its MAC address.

It generates a UUID which is inserted into a “configured_devices” database table, deletes the MAC address from the “unconfigured devices” table (or marks it as “paired”) and stores a new provisioning server URL (including the generated UUID) into the device. All configuration data is associated to the UUID (not the MAC).

Second step (UUID-based provisioning):

The device retrieves its configuration from the provisioning server by providing the UUID.

Please note that this solution does not protect against man-in-the-middle attacks.

Need help securing your mass deployment? Got feedback?

Please contact me at

Things I have learned from being hit by a SIP bruteforce attack…

The attac:k

This week it happened to me, too. Somebody (with an IP address from Belize) managed to bruteforce the password of a SIP account on one of our internal Asterisk servers. I noticed it purely by accident. Usually i never look at the CLI of that machine (except when things fail, which is pretty rare). Fortunately, luck is with the stupid, so i noticed it just two hours after the first calls were made.

Calls were made to a single number in the British Indian Ocean Territory. The same number seems to be used by a few malicious Android applications, too. I have learned that the username “droid” and password “android” are not secure enough for a SIP account. ;-)

Immediately i redirected all calls from that account to one of my SIP phones, which started ringing very soon. Unfortunately there was no one at the other end when i answered the call. The other side (which claimed to be an Asterisk) was only sending silence (in g.711 RTP). So, our BRI lines were not abused for call termination but probably for a premium number scam. I can’t wait to get the invoice next month. :-(

Things I have learned:

  • Do not use a dialplan pattern like “_X.” in your context for external calls. Set up an extension for every country you need to call, e.g. “_0049.”. I had this on all of our ITSP machines, but of course not on our internal box (“The shoemaker got the worst shoes.”).
  • Use good usernames and passwords. Try to avoid numeric usernames.
  • Protect you accounts from being bruteforced by using something like fail2ban.
  • When possible use a SIP domain instead of IP addresses. Make sure the domain cannot be guessed from the IP address!

The new setup:

Instead of setting up fail2ban on our Asterisk box, I decided to use kamailio in front of Asterisk. All authentication is done by kamailio and all calls are forwarded to Asterisk (even calls between local subscribers). The “antiflood” feature of kamailio keeps our fellow bruteforces outside.

The authentication between Asterisk and kamailio is done on a trusted IP basis. There are no SIP accounts on the Asterisk box. An very nice side effect is that you can now register the same SIP account on multiple SIP phones without any effort! Before I had to have one SIP account for each of my phones.

Kamailio’s multi-domain support is enabled. All automatic aliases have been removed. It is only listening to requests for the domains configured in the database. The SIP domain we use cannot be guessed from the IP address of the box. This feature alone would probably be sufficient to protect the accounts against bruteforcing!


I have just made some tests with the metasploit SIP options scanner and SIP enumerator. With kamailio’s multidomain support configured to a non-guessable domain it does not even respond to the SIP options message from the scanner. That way our fellow bruteforcers dont even recognize the kamailio server as a SIP server. And leave it alone. :-)

Asterisk memtesting reloaded

It was about time to re-test up to date Asterisk versions for memory leakage. As these tests take a rather long time, i will update this post when the 1.4 and 1.6 versions have gone through the test.
The test procedure is the same as in my previous test, incoming SIP calls that send a ringing, wait a little and hang up (no call is ever connected, no RTP is flowing).

Asterisk 1.8.4-rc2

Since my last test, things have improved a lot! Asterisk does not consume 200m+ right from the start and it does not leak that much any more. However it still leaks a bit. After 32M+ calls i stopped the test.

Memory consumption before the test: virt 513m  16m 5940 S

Memory consumption after the test: virt 712m res 192m 6432 S


After pushing 37M+ calls Asterisk stopped processing calls because it ran out of RTP ports (it was using the default RTP port range from 10000 to 20000). “netstat -l -n -p  | grep asterisk -c” shows that 10009 ports are in use by asterisk. Calls fail with:

[Mar 27 12:42:03] ERROR[25983] rtp.c: No RTP ports remaining. Can’t setup media stream for this call.
[Mar 27 12:42:03] WARNING[25983] chan_sip.c: Unable to create RTP audio session: Address already in use

Memory consumption before the test: 476m  14m 5412 S

Memory consumption after the test: 742m 197m 5868 S

Asterisk 1.4.41-rc1

After pushing 10M+ calls Asterisk is processing calls very slowly. The machine has a high load because it is constantly swapping pages to and from disk. Retransmissions start to fail:

[Mar 30 10:58:50] WARNING[10667]: chan_sip.c:2070 retrans_pkt: Maximum retries exceeded on transmission a3621613-d54e-122e-43b7-001aa0314ced for seqno 10401673 (Critical Response) — See doc/sip-retransmit.txt.

Memory consumption before the test: 392m  12m 4396 S

Memory consumption after the test: 1472m 358m 1324 S

Asterisk 1.2.40

During the test Asterisk was complaining about “avoiding initial deadlocks” and “avoiding deadlocks” a lot, but it did not deadlock or go into the famous 100% cpu loop. It just works. :-)

After processing 65M+ calls,  I decided to stop the test as i could not see an increasing memory consumption. The 1.2 branch of Asterisk keeps its place as my favourite branch (when it comes to stability).

Memory consumption before the test:  276m  11m 3464 S

Memory consumption after the test:  460m  79m 3768 S S

27C3 Having fun with RTP

I gave a talk (“Having fun with RTP”) at the 27th Chaos Communication Congress yesterday. The recordings are not online yet. You can already download my slides here.

UPDATE: The recording of my talk is now available at the 27c3 website or on youtube.