During a routine work done in January of this year, Tempest´s former consultant, Roberto Santos*, identified a critical and still uncorrected vulnerability in four devices produced by Brazilian manufacturer Aligera. The affected equipment are the SIP Gateways models AG300, AG561, AG562 and AG563. The vulnerability allows an attacker to gain full control of the device.
SIP Gateways are devices that convert voice signals to IP protocol and transmit this communication over a VoIP-based data network. The protocol that controls much of this “translation” is the SIP, first described in RFC-2543 of 1999. This kind of device is usually acquired by large organizations, especially telecommunication companies.
The vulnerability — cataloged as CVE-2018–5707 — allows for the remote execution of commands, so attackers can interact directly with the device’s operating system with administrative access.
The proof of concept was tested against the models mentioned above, with 3.39 firmware version — which was the latest at the time of testing. However, there is evidence that versions 3.26b, 3.28, 3.35, 3.38, 4.11 and 5.45 (current) are also vulnerable because they have the same type of communication that permits the attack. Since the discovery of the flaw, Aligera has made software updates for its devices, but the changes have not covered the fix for this vulnerability.
At the time this article was closed, there were 167 vulnerable devices exposed to the Internet and indexed by Shodan and 200 others indexed by Censys.
Aligera was alerted about the vulnerability on 17th January, 2018. Questions about a fix were made during all the months that followed, until September 3rd, when Tempest reported that this alert would be released, asking if the fix had been implemented in the new firmware versions. Aligera’s support team answered saying that the problem persists and a new firmware version, planned for the end of September, will solve the problem. More technical details on the vulnerability will be released later this month.
We recommend the revision of the security controls in order to eliminate any unnecessary access to Aligera devices. Especially deactivating the exposure of these devices to the Internet.
Timeline
17/01/2018 — Tempest alerts Aligera.
17/01/2018 — Aligera claims it has not identified vulnerabilities in its tests and requests details.
18/01/2018 — Tempest requests a secure channel to send the technical information, because the communication system with Aligera’s support is based on an unencrypted (HTTP) channel.
18/01/2018 — Aligera states that it does not have another channel with encryption and closes the ticket.
18/01/2018 — Tempest reopens the ticket.
18/01/2018 — Tempest sends details of the vulnerability.
25/01/2018 — Tempest requests receipt confirmation of vulnerability details
25/01/2018 — Aligera confirms the reception of the details and claims that the development team is working on a fix.
25/01/2018 — Aligera closes the ticket.
03/03/2018 — Tempest reopens the ticket.
03/03/2018 — Tempest asks if the vulnerability has been fixed.
28/03/2018 — Aligera responds that the engineering team has not yet corrected the vulnerability.
28/03/2018 — Aligera closes the ticket.
03/09/2018 — Tempest reopens the ticket.
03/09/2018 — Tempest asks if the vulnerability has been fixed.
03/09/2018 — Aligera responds that the engineering team has not yet corrected the vulnerability.
03/09/2018 — Aligera closes the ticket.
04/09/2018 — Representatives of Tempest and Aligera meet and the manufacturer states that the fix for the problem will be made available by the end of September.
* Since September 2018, a few weeks after the release of this article in our intelligence reports, the consultant Roberto Soares is no longer part of our staff
