How to Bury a Major Breach Notification

Amid the hustle and bustle of the RSA Security Conference in San Francisco last week, researchers at RSA released a startling report that received very little press coverage relative to its overall importance. The report detailed a malware campaign that piggybacked on a popular piece of software used by system administrators at some of the nation’s largest companies. Incredibly, the report did not name the affected software, and the vendor in question has apparently chosen to bury its breach disclosure. This post is an attempt to remedy that.

The RSA report detailed the threat from a malware operation the company dubbed “Kingslayer.” According to RSA, the attackers compromised the Web site of a company that sells software to help Windows system administrators better parse and understand Windows event logs. RSA said the site hosting the event log management software was only compromised for two weeks — from April 9, 2015 to April 25, 2015 — but that the intrusion was likely far more severe than the short duration of the intrusion suggests.

That’s because in addition to compromising the download page for this software package, the attackers also hacked the company’s software update server, meaning any company that already had the software installed prior to the site compromise would likely have automatically downloaded the compromised version when the software regularly checked for available updates (as it was designed to do).

Image: RSA

Image: RSA

RSA said that in April 2016 it “sinkholed” or took control over the Web site that the malware used as a control server — oraclesoft[dot]net — and from there they were able to see indicators of which organizations might still be running the backdoored software. According to RSA, the victims included five major defense contractors; four major telecommunications providers; 10+ western military organizations; more than two dozen Fortune 500 companies; 24 banks and financial institutions; and at least 45 higher educational institutions.

RSA declined to name the software vendor whose site was compromised, but said the company issued a security notification on its Web site on June 30, 2016 and updated the notice on July 17, 2016 at RSA’s request following findings from further investigation into a defense contractor’s network. RSA also noted that the victim software firm had a domain name ending in “.net,” and that the product in question was installed as a Windows installer package file (.msi).

Using that information, it wasn’t super difficult to find the product in question. An Internet search for the terms “event log security notification april 2015” turns up a breach notification from June 30, 2016 about a software package called EVlog, produced by an Altair Technologies Ltd. in Mississauga, Ontario. The timeline mentioned in the breach notification exactly matches the timeline laid out in the RSA report.

As far as breach disclosures go, this one is about the lamest I’ve ever seen given the sheer number of companies that Altair Technologies lists on its site as subscribers to eventid.net, an online service tied to EVlog. I could not locate a single link to this advisory anywhere on the company’s site, nor could I find evidence that Altair Technologies had made any effort via social media or elsewhere to call attention to the security advisory; it is simply buried in the site. A screenshot of the original, much shorter, version of that notice is here.

Just some of the customers of Eventid.

Just some of the customers of Eventid.

Perhaps the company emailed its subscribers about the breach, but that seems doubtful. The owner of Altair Technologies, a programmer named Adrian Grigorof, did not respond to multiple requests for comment.

“This attack is unique in that it appears to have specifically targeted Windows system administrators of large and, perhaps, sensitive organizations,” RSA said in its report. “These organizations appeared on a list of customers still displayed on the formerly subverted software vendor’s Web site. This is likely not coincidence, but unfortunately, nearly two years after the Kingslayer campaign was initiated, we still do not know how many of the customers listed on the website may have been breached, or possibly are still compromised by the Kingslayer perpetrators.”

It’s perhaps worth noting that this isn’t the only software package sold by Altair Technologies. An analysis of Eventid.net shows that the site is hosted on a server along with three other domains, eventreader.com, firegen.com and grigorof.com (the latter being a vanity domain of the software developer). The other two domains — eventreader.com and firegen.com — correspond to different software products sold by Altair.

The fact that those software titles appear to have been sold and downloadable from the same server as eventid.net (going back as far as 2010) suggests that those products may have been similarly compromised. However, I could find no breach notification mentioning those products. Here is a list of companies that Altair says are customers of Firegen; they include 3M, DirecTV, Dole Food Company, EDS, FedEx, Ingram Micro, Northrup Grumman, Symantec and the U.S. Marshals Service.

RSA calls these types of intrusions “supply chain attacks,” in that they provide one compromise vector to multiple targets. It’s not difficult to see from the customer lists of the software titles mentioned above why an attacker might salivate over the idea of hacking an entire suite of software designed for corporate system administrators.

“Supply chain exploitation attacks, by their very nature, are stealthy and have the potential to provide the attacker access to their targets for a much longer period than malware delivered by other common means, by evading traditional network analysis and detection tools,” wrote RSA’s Kent Backman and Kevin Stear. “Software supply chain attacks offer considerable ‘bang for the buck’ against otherwise hardened targets. In the case of Kingslayer, this especially rings true because the specific system-administrator-related systems most likely to be infected offer the ideal beachhead and operational staging environment for system exploitation of a large enterprise.”

A copy of the RSA report is available here (PDF).


Source: krebsonsecurity.com
How to Bury a Major Breach Notification How to Bury a Major Breach Notification Reviewed by Anonymous on 9:59 AM Rating: 5