Security

No. 1 thing IT departments can learn from the Panama Papers hack

Staggeringly out of date software supports the conclusion that documents from Mossack Fonseca were exfiltrated by a hacker. Learn what vulnerabilities could have been used.

panama.jpg
Image: iStockphoto/CyberKristiyan

In the world of investigative journalism, the "Panama Papers"—the recent leak of 11.5 million documents, totaling 2.6 terabytes of data from the law firm Mossack Fonseca—is the gift that keeps on giving. As journalists continue to sort through the trove of documents, more people are named in tax-avoidance schemes, and fallout from the reporting continues to increase.

While there is already ample coverage of the social and political implications of the Panama Papers, the focus of this article is the enterprise security lessons that can be learned from this event.

SEE: Three important lessons crooked world leaders should learn from the Panama Papers (ZDNet)

Considering the widespread implications of the Panama Papers, a variety of explanations have been proffered by various experts and commenters as to how this information was exfiltrated from Mossack Fonseca. The originating newspaper, Süddeutsche Zeitung, claims it does not know how its source obtained the data, but the source's motivation was that he "want[ed] these crimes to be made public."

Ramón Fonseca, co-founder of Mossack Fonseca, claims that the law firm was hacked, though the origin or identity of the hacker is still unknown. While the potential exists that this was an inside job, the more likely scenario is that poor security practices enabled the Panama Papers leak.

Years behind in security updates

Astute TechRepublic readers understand the importance of security updates, and the urgency with which they should be applied—no matter how large or small the organization is. Far too often in these situations, the IT staff is hamstrung by management who does not share in this understanding, leaving the IT staff without the resources needed to perform their duties effectively.

WordPress 4.1 (Released December 18, 2014)

The homepage blog of Mossack Fonseca appears to use WordPress 4.1, which, aside from being out-of-date, has had a variety of high-profile vulnerabilities. In general, the heavy reliance of plugins in WordPress is known to be problematic, though the security issues of Mossack Fonseca extend beyond one WordPress installation, or associated plugin.

Drupal 7.23 (Released August 8, 2013)

The client portal operated by Mossack Fonseca was found to be using Drupal 7.23 at the time the story broke. Drupal was operating on top of Apache 2.2.15, from March 6, 2010. To further complicate matters, it is actually Oracle's fork of Apache, which by default allows viewing the directory structure. As Drupal files use the .module file extension—which is not executed by default in Apache—any user is able to view the source of the module files as plain text, as well as view the directory in which module files are placed.

SEE: Three ways encryption can safeguard your cloud files (Tech Pro Research)

An in-depth look at Mossack Fonseca's Drupal installation was performed by Unicorn Riot, which, at the time of their report, noted that a "portfolio" module exists that appears to serve the purpose of allowing account holders to view their documents, and the "Oracle" module exists allowing Drupal to use Oracle as the database backend (rather than the default MySQL).

The Drupal installation itself is vulnerable to the highest-profile vulnerability in the history of the project, a vulnerability which allows any anonymous user to achieve privilege escalation or execute arbitrary PHP code. Unicorn Riot inferred that this vulnerability would have allowed attackers to gain access to the "portfolio" data store, which can reasonably be presumed to be the contents of the Panama Papers provided to the press.

While some attempts have been made to secure the Drupal installation since the disclosure of the Panama Papers, some of the aforementioned security issues appear to persist. Directory view has been disabled, though error pages are still served by Oracle instead of Joomla—the error pages still report the Oracle server as 2.2.15, which is still woefully insecure.

Microsoft Exchange / Outlook Web Access (2009)

Mossack Fonseca uses Microsoft Exchange server for email, of which Outlook Web Access (OWA) is a component. The login portal reports the copyright date as being 2009—you can try it yourself—which is probably insecure. Giving the benefit of the doubt, if it runs Exchange Server 2007, there is still one year left before that version reaches the end of extended support. In consideration of the aforementioned unpatched software, it is probable that this, too, was not updated. Multiple vulnerabilities have been found in Exchange and OWA, the bulk of which were discovered in 2015.

Even with the end of extended support a year away, a migration path should be well underway to remove aging software from your infrastructure. City of Seattle IT Analyst Marcus Eaton noted that "Mossack Fonseca's situation is a fantastic example of why patching and maintaining software is arguably more important than deploying. A car needs regular maintenance and has a limited lifespan, and your software used in production and development systems should be treated the same way."

What's your view?

Do you think that Mossack Fonseca was the victim of a hack, or was this a whistleblower inside the organization? Do you have doubts about the security practices for organizations whose services you retain? Share your thoughts in the comments.

Also see

About

James Sanders is a Java programmer specializing in software as a service and thin client design, and virtualizing legacy programs for modern hardware.

Editor's Picks