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 [email protected].