83% of Canada’s population affected by recent Telco bug

Today we present you an entertaining tale of a company based out of New York called SOLEO. SOLEO develops a TRS (telecommunications relay software) called IP Relay which allows people with disabilities, such as hard of hearing, to place calls utilizing an assistive device. On August 18th, 2018 we had released a white paper outlining the Local File Disclosure vulnerability in question as well as remediation steps. At the time of discovering this vulnerability, every ISP in Canada was vulnerable and could have been susceptible to the loss of nearly 30 million Canadian records.

Pwnage

While Dominik Penner was scouring the web, he noticed an anomaly in an ISP web application. He noticed that the web application was serving pages using a GET parameter. Instinctively, he changed the parameter value to a random string only to be viewed with a 404 page. Shortly after, he had established that it was attempting to load a JSP file but it was circumventing attempts by not allowing the servlet to serve files without appending a “.jsp” file extension.

At this point, Project Insecurity researchers turned to utilize HTTP parameter poisoning and were able to circumvent the mechanism by including a trailing question mark after the file name. Effectively, this truncated the terminating file extension. One thing to note is that traversing out of the IPRelayApp directory was not possible, so only the files from within that directory were accessible. This wasn’t really an issue as multiple class files, as well as SQL/LDAP connection information, could have been found within the IPRelayApp directory.

There were a variety of other potential attack vectors such as the possibility to remotely execute code; however, this was not tested. Source code disclosure and SQL/LDAP credentials are everything a determined attacker would need to compromise the system and gain a foothold into an internet service provider’s internal network.

Disclosure

Penner had sent multiple emails over the course of a few days to the email listed on SOLEO’s website. After getting getting no response for several days Security Operations Manager, Manny Mand, sent a connection request to the CEO of SOLEO on LinkedIn with a note providing some more details on the situation. After a few days SOLEO’s VP of Service Assurance, Andy Sawczuk, reaches out to Manny via a connection request on LinkedIn. After a dozen messages exchanged back and forth it became apparent that SOLEO was in fact avoiding both public disclosure and talking to the media as evident by this quote said by Mr. Sawczuk.

“Manny, honestly I would prefer if we had opportunity to at least review and characterize the true risk potential of the vulnerability before any press disclosure so that we could be in agreement. I would hate for our customers to have to put out unnecessary fires.”

A few days later Mr. Sawczuk sent a follow up message informing Mand that a patch release was provided to the customers over the weekend. Afterwards Mand sent a follow up message re-asking the initial media inquiry and was met with this response from Mr. Sawczuk.

Hello Manny, We would at least like an opportunity to provide updates to the report to properly characterize the true impacts and address the fact that the remediation has taken place. Thanks.

At this point it became evident that SOLEO had no intention to allow us to relay this report to the media. Mand then attempted to, at the very least, establish a public disclosure date for the report which was also met with various ‘roadblocks’. Mand’s last inquiry to establish a disclosure, sent August 15th, was ignored altogether. Mand explicitly stated that Project Insecurity is more then willing to delay the release of the report, by up to 90 days as indicated in our disclosure policy, yet no follow up was sent.

SOLEO did do a good job quickly remediating the issue once we had gotten in contact with them, but disclosing this vulnerability could have gone a lot smoother if SOLEO had security contact details listed on their website or in /.well-known/security.txt, a proposed standard to define security policies. It is important for companies to have an active email dedicated to security issues for researchers to responsibly disclose vulnerabilities and prevent a data breach.

You can read more about this vulnerability in the official report or zine.