Anti-Malware , Data Breach , Fraud

SWIFT Deduction: Assume You've Been Hacked Ukrainian Bank Was Hacked in April, National Bank of Ukraine Confirms Mathew J. Schwartz (euroinfosec) • July 4, 2016     National Bank of Ukraine. (Photo: Andrew Butko, via Wikimedia Commons.)

Memo to financial services firms around the world: Assume that attackers have been attempting to make fraudulent SWIFT requests via your network, and that they may have already breached your systems and begun doing so.

See Also: Detecting Insider Threats Through Machine Learning

That's the obvious cybersecurity takeaway from the rolling - if delayed - reports that keep coming to light in the wake of the theft of $81 million from the central bank of Bangladesh in February, of banks saying that they too have fallen victim to fraudulent SWIFT transactions.

The attacks have targeted the messaging system maintained by the Brussels-based, bank-owned cooperative SWIFT - formally known as the Society for Worldwide Interbank Financial Telecommunication - which is designed to guarantee that money-moving messages between banks are authentic. But attackers have long targeted the system to try and steal money from banks.

The latest such report surfaced last week, pertaining to an unnamed bank in Ukraine that lost $10 million to hackers who successfully executed fraudulent SWIFT transactions, the Kiev Post reported.

Subsequently, Reuters said that an April memo it had obtained from the central bank of Ukraine warned the country's banks to be on the lookout after the Bangladesh Bank hack, and recommended that banks implement all of SWIFT's security guidance, ensure that all anti-virus technology was fully updated as well as vet the security of all bank systems that connect to the SWIFT network.

"We are also informing you that a similar incident took place in one of the Ukrainian banks," read the notice, which was signed by a deputy governor at the central bank, known as the National Bank of Ukraine, Reuters reports.

Reached for comment, the press service of the National Bank of Ukraine declined to share a copy of the memo, which it says was issued on April 28 and "based on SWIFT's letter about [the] latest cyber incidents," citing bank secrecy concerns. But it confirmed that in April, a Ukrainian bank reported a "cyber-attack" to the central bank, and that "thereafter NBU appealed to the banks asking them to follow SWIFT rules and regulations strictly and keeping anti-virus software up to date."

The press office also suggested that the bank would have reported the attack to SWIFT. "Relationships between the banks and SWIFT are regulated directly by bilateral agreements, which include conditions of reporting about incidents," the press office says.

Reached for comment, SWIFT noted that the Ukrainian bank wasn't compromised by hacking into SWIFT's network. "As we have said before, our network and core messaging services have not been compromised," the spokeswoman tells me.

Beyond that, however, SWIFT declined to discuss the case. "As we have said before, we will not comment on individual entities," she says. "When a case of potential fraud is reported to us, we offer our assistance to the affected user to help secure its environment, and we share relevant information on an anonymized basis with the community. This preserves confidentiality, whilst assisting other SWIFT users to take appropriate measures to protect themselves."

Six SWIFT Heists, and Counting

The Ukraine bank hacking and fraudulent SWIFT transaction fraud revelations follow reports from at least five other banks that have experienced similar attacks. In the wake of the attacks, SWIFT has promised to provide better security guidance to banks, and also urged targeted organizations to come forward and share attack details, for the benefit of other banks (see SWIFT to Banks: Get Your Security Act Together).

Here's the list of institutions that have logged fraudulent SWIFT attacks over the past few years:

Sonali Bank: Bangladesh bank lost $250,000 to attackers in 2013. Banco del Austro: Court documents filed this year revealed that $12.2 million was stolen from this Ecuadorian bank in January 2015. Bank in the Philippines: As yet unnamed, this bank was attacked in October 2015, security firm Symantec says. TPBank: This Vietnamese bank blocked the attempted theft of $1.4 million in December 2015. Bangladesh Bank: The central bank of Bangladesh lost $81 million to attackers, who attempted to steal nearly $1 billion in their February heist. Bank in Ukraine: $10 million was reportedly stolen from an unnamed bank.

Separate or Connected Campaigns?

What's not clear, however, is how many of the above attacks might be related. Systems at Bangladesh Bank, for example, were infected with a Trojanized version of the Foxit PDF reader, which allowed attackers to suppress evidence of their fraudulent transactions.

Based on a technical analysis of the malware, security researchers say that it reuses parts of the malware and attack infrastructure that was employed in the 2014 hack attack against Sony Pictures Entertainment, which the U.S. government blamed on North Korea. As a result, security experts say, it appears that at least some of the recent bank hacks and fraudulent SWIFT transactions were carried out by individuals working for - or on behalf of - the North Korean government in Pyongyang (see F-Secure's Mikko Hypponen Details 5 Top Cybercrime Trends).

Regardless of which individuals or groups have been behind these SWIFT attacks, they've been a wake-up call for financial services firms, especially as they move toward more real-time payment and transfer systems (see Improving Fraud Prevention After SWIFT-Related Heists).

In the wake of the Bangladesh Bank hack, the Bank of England - the U.K.'s central bank - and U.S. officials, amongst others, began querying banks and SWIFT about their preparedness against related attack attempts (see Fraudulent SWIFT Transfers: Congress Queries New York Fed). But the takeaway for all SWIFT-using banks in any country by now should be crystal clear: Analyze all SWIFT-connected systems to ensure that they haven't been hacked, and keep a close eye on those systems going forward, since they're being actively targeted by hackers.

Bring Your Own Device (BYOD) , Encryption , Mobility

57% of All Android Phones Vulnerable to Related Exploits Mathew J. Schwartz (euroinfosec) • July 6, 2016    

More than half of all Android smartphones in current use have a flaw that can be exploited to bypass the devices' full-disk encryption. As a result, law enforcement agencies - or malicious attackers - could access all supposedly encrypted data being stored on vulnerable devices.

See Also: How to Mitigate Credential Theft by Securing Active Directory

To prevent brute-force cracking attempts against device hardware, Android employs a hardware-backed keystore known as the KeyMaster, which is designed to generate encryption keys and perform other secure functions without interacting with the non-secure part of the device or operating system environment.

But security researcher Gal Beniamini has published details of how KeyMaster keys in Qualcomm devices can be extracted and used to crack full-disk encryption, using a flaw that he discovered, which has been designated CVE-2016-2431.

"These attacks affect Android devices with processors manufactured by Qualcomm - and Qualcomm happens to dominate the Android market," says Kyle Lady, a senior research and development engineer at Duo Labs, in a blog post.

The flaw was fixed as part of the May 2016 Android security update. But just because Google patches its open source Android operating system doesn't mean that original equipment manufacturers - OEMs - will craft related updates for subscribers or customers in a timely manner, especially for older devices. Indeed, Duo Security, which develops authentication software, says that "an analysis of Duo's dataset of [500,000] Android phones used as a second factor in two-factor authentication" found that 57 percent of all Android phones do not yet have a patch for CVE-2016-2431, and are thus vulnerable to attacks that bypass full-disk encryption.

Software-Based Crypto Key

Beniamini says the exploit involves Qualcomm-built ARM chips used in Android devices, which include a technology called TrustZone. This can be used to create a so-called Trusted Execution Environment that facilitates a special CPU mode called "secure mode" that can be used to secure everything from the operating system kernel and on-device fingerprint scanner to secure boot and digital rights management.

Android generates an "SHK" - silicon-based hardware key - that's tied to the device itself, meaning that short of using an electron microscope to study the chip, or else brute-forcing the key, it's unlikely that it can be cracked.

But Android then uses the SHK to create - or derive - a second, software-based key that gets used for full-disk encryption (FDE), and Beniamini discovered that this can be retrieved and cracked. "The key derivation is not hardware-bound. Instead of using a real hardware key which cannot be extracted by software (for example, the SHK), the KeyMaster application uses a key derived from the SHK and directly available to TrustZone," Beniamini says. "Since the key is available to TrustZone, OEMs could simply create and sign a TrustZone image which extracts the KeyMaster keys and flash it to the target device. This would allow law enforcement to easily brute-force the FDE password off the device using the leaked keys."

Missing: Hardware Entanglement

While Google has fixed the bug, Beniamini says "this issue underscores the need for a solution that entangles the full disk encryption key with the device's hardware in a way which cannot be bypassed using software," and which may involve redesigning Android FDE from the ground up, and potentially adding new hardware to keep it secure.

As of iOS 8, for example, all Apple devices use full-disk encryption by default, and create "an encryption key which is derived from the user's password," as well as tied to the device hardware, he says. As a result, cracking an Apple crypto key would most likely require having to first guess the user's password, or else compelling Apple to create a backdoored version of iOS. The latter approach was the focus of the Apple-FBI crypto battle, in which the Department of Justice attempted to legally force Apple into creating a crackable version of iOS software that could be loaded onto an iPhone 5c used by San Bernardino shooter Syed Rizwan Farook. Ultimately, however, the FBI backed off - at least in that case.

Fast Patches: Nexus, Samsung

For Android users who want to protect themselves against the encryption bypass attack detailed by Beniamini, "Duo recommends that users patch your phones, which is no surprise," Lady says. "If your manufacturer has not yet made patches available, put some pressure on them to do so."

Of course, many Android smartphone buyers have long complained that device manufacturers and carriers can be slow to release updates and patches, if they release them at all. The lack of timely patching by many Android device providers continues to draw scrutiny from U.S. regulators, although to date they have taken no action to fix the problem (see FTC, FCC Launch Mobile Security Inquiries).

Duo Labs says that Android users who want to ensure that their smartphones get protected against the likes of CVE-2016-2431 as quickly as possible should opt for Nexus devices, which use a vanilla implementation of Google. Likewise, it says that recent handsets from Samsung have also been seeing relatively fast updates. As of July 1, 75 percent of all Samsung Galaxy S6 devices, which Duo says is the most-used phone model in its dataset, had been patched, which was equivalent to the number of patched Nexus devices. Meanwhile, 45 percent of Galaxy S5 phones had been patched.

Top Smartphone OEMs:
U.S. subscribers as of Jan. 2016
Source: comScore https://t.co/96sEV69fnX pic.twitter.com/vGfIwt8Exg

"Given these improvements in the security stance of Samsung phones, we're hopeful that Samsung will continue this trend of rolling out security updates at a rapid rate," Duo's Lady says.

Anti-Malware , Data Breach , HIPAA/HITECH

Letter Makes Breach Response Recommendations to HHS Marianne Kolbasuk McGee (HealthInfoSec) • July 5, 2016     Reps. Ted Lieu, D-Calif., and Will Hurd, R-Texas

A bipartisan duo of Congressmen sent a letter to the Department of Health and Human Services, making specific breach notification and response recommendations for upcoming ransomware guidance planned by HHS' Office for Civil Rights, noting that ransomware attacks are "different" from other data breaches.

See Also: Rethinking Endpoint Security

The "differences" between ransomware attacks - which could potentially impact patient safety by making patient health data inaccessible to clinicians - and other breaches, where patient privacy is primarily at risk, necessitates different response and notification by affected entities, write Ted Lieu, D-Calif. and Will Hurd, R-Texas, in a June 27 letter to Deven McGraw, OCR deputy director of health information privacy.

"We want to raise some issues that differentiate ransomware from conventional hacking and encourage the timely issuance of proposed guidance to address these differences," the Congressmen write.

"From a technical standpoint, ransomware is likely subject to a risk assessment analysis of a data breach," they say, noting that under HIPAA a breach is defined as "the acquisition, access, use, or disclosure of protected health information in a manner not permitted."

Because "access must occur in order for any malware event that creates a disruption of service or corruption of data, thereby placing patients at risk, including ransomware, the definition of a breach has been met and subject to a required risk assessment to determine what additional steps, if any are necessary," the letter notes.

"However, just because a ransomware attack qualifies as a conventional breach, that does not mean they should be treated the same or subject to the exact same risk assessment. One reason for this difference is that the effect of a ransomware breach is different," the Congressmen note.

In the case of a ransomware attack, "the threat is not usually to privacy, but typically to operational risks to health systems and potential impacts on patient safety, and service."

For example, a suspected ransomware attack on MedStar Health in March "resulted in patients being turned away due the inability to provide care," Lieu and Hurd write.

Ransomware vs. Other Breaches

The legislators suggest that the "differences" between ransomware and other data breaches be reflected in OCR's upcoming ransomware guidance.

Specifically, Lieu and Hurd recommend the guidance instruct the healthcare sector that:

Patients be notified of ransomware attacks "without unreasonable delay" - but only in cases where the ransomware attack could affect patient safety due to "either a denial of access to an electronic medical record and/or loss of functionality" necessary to provide medical services; OCR "aggressively require" reporting of ransomware attacks to HHS and appropriate healthcare-related information sharing and analysis organizations; Since ransomware does not always involve viewing or stealing personal health information, "requiring a provider to offer credit counseling services may be an unnecessary expense."

The letter also notes, "we urge OCR to include clear guidance related to data modification from ransomware or malware attacks, including deletion of entire servers or drives that constitute a breach under [HIPAA], even if the deletion does not involve direct modification of the original files." The destruction of records "is the same as accessing them and has a similar impact to an organization," Lieu and Hurd write.

In a statement to Information Security Media Group, a spokesman for Lieu says, "we sent this letter both to let [HHS] know that there are those of us in Congress who care about this issue from a patient safety perspective and appreciate their rapid response. We also sent the letter because we wanted to make sure that the effort, while appreciated, was also properly focused on the unique aspects of ransomware as opposed to other hacks involving malware or denial of service attacks."

An OCR spokesman tells ISMG, "OCR is presently drafting guidance on ransomware and HIPAA and expect to be able to release it shortly."

Fine Lines

While new OCR ransomware guidance for the healthcare sector could be useful, not everyone is convinced that ransomware attacks on healthcare entities necessitate different rules.

"I don't believe the HIPAA breach notification rule should be modified for this one type of malware," says privacy and security expert Kate Borten, founder of consulting firm, The Marblehead Group.

"HHS guidance on breach determination may be helpful," she notes. "In the meantime, if an expert analysis of the particular ransomware attack determines that nothing beyond encryption occurred, it might not be considered a reportable breach."

The letter to OCR from Lieu and Hurd "proposes an unworkable process," says privacy attorney David Holtzman, vice president of compliance at security consultancy CynergisTek.

"These proposals would take away from healthcare providers and health plans critical flexibility provided in the [HIPAA] Breach Notification Rule to assess for the probability that an incident has compromised the privacy or security of the organization's protected health information," he says.

Healthcare attorney Betsy Hodge of the law firm Akerman LLP notes that given the language of the HIPAA breach notification rule, "it seems unlikely that OCR would say that all ransomware attacks should be reported to OCR, but only some may require patient notification; that contradicts the language of the rule."

Rather, "it seems more likely that OCR would issue guidance explaining how the definition of a breach applies to a ransomware attack and how covered entities should consider the risk assessment factors when analyzing whether a particular ransomware attack is a reportable breach," she says.

Too Much Notification?

The letter to OCR also reflects some areas of ongoing confusion when it comes to ransomware attacks and breach notification issues, notes privacy attorney Kirk Nahra of the law firm Wiley Rein LLP.

"It is certainly correct that the 'typical' ransomware event - if there is such a thing - is different than many other situations where patients have been notified about security breaches," such as when data is lost or stolen - and provided to an unauthorized party, he notes. In a ransomware attack, the data typically isn't "taken" by anyone. "It is simply 'locked' so that the right person, for example, a hospital, can't access it. That is a very different kind of event," he says.

"There is an ongoing policy question of 'why' notice is being provided - for example, potential identity theft, where an individual can do something, vs. potential reputational risk, where there may be nothing to do - and we could certainly move to a situation where notice is being provided 'just because,' even if there is no wrongful access to the data, but that is not the current law."

Current breach notification laws require reporting to the government only in situations where there is also notice to an individual, he notes.

"So, while it might make sense to develop a new rule or law relating to notice to the government in situations where no notice to an individual makes sense, that also is not current law." So, even if OCR were to include in its upcoming guidance recommendations that entities hit by ransomware attacks notify HHS or ISAOs, current HIPAA rules do not support that requirement, he says.

"HIPAA today does not have any general 'notify the government' obligation independent of an obligation to notify individuals."

Sharing Cyber Info

Earlier this year, the Department of Homeland Security set up the Cyber Information Sharing and Collaboration Program, or CISCP, as a national public-private partnership for the sharing information rapidly across all sectors of our country's critical infrastructure, including healthcare, Holtzman notes.

But the proposals in the letter requiring the reporting to healthcare ISAOs of ransomware attacks potentially could have negative impact. "It could turn out to be counterproductive to have competing proprietary threat sharing programs that value exclusivity over widespread information sharing, limiting distribution of reported vulnerabilities only to their subscribers," he says.

Jim Reavis

Co-founder & CEO, Cloud Security Alliance

For many years, Jim Reavis has worked in the information security industry as an entrepreneur, writer, speaker, technologist and business strategist. Jim's innovative thinking about emerging security trends have been published and presented widely throughout the industry and have influenced many. Jim is helping shape the future of information security and related technology industries as co-founder, CEO and driving force of the Cloud Security Alliance. Jim was recently named as one of the Top 10 cloud computing leaders by SearchCloudComputing.com.

Jim is the President of Reavis Consulting Group, LLC, where he advises security companies, governments, large enterprises and other organizations on the implications of new trends such as Cloud and Mobility and how to take advantage of them.

Jim has previously been an international board member of the ISSA, a global not for profit association of information security professionals and formerly served as the association's Executive Director. Jim founded SecurityPortal, the Internet's largest website devoted to information security in 1998, and guided it until a successful exit in 2000.

Jim has been an advisor on the launch of many industry ventures that have achieved a successful M&A exit or IPO. Jim is widely quoted in the press and has worked with hundreds of corporations on their information security strategy and technology roadmap. Jim has a background in networking technologies, marketing, product management and systems integration. Jim received a B.A. in Business Administration / Computer Science from Western Washington University in 1987 and formerly served on WWU's alumni board.