Anti-Malware , Risk Management , Technology

Most anti-virus applications depend strongly on regular updates that supply technical descriptions of new malware, known as signatures. Although signatures aren't the only way to detect malware - some vendors are moving away from using them - they're useful for stopping viruses, albeit after an attack has been seen in the wild.

See Also: Vulnerability Management with Analytics and Intelligence

Enter MacKeeper, a security product for Apple computers whose annoying pop-up advertisements warning "Your Mac Might Be Infected!" abound across the web. MacKeeper, owned by Kromtech Alliance Corp. of Germany, has long been criticized for its marketing techniques.

Earlier this month, AV-Test, an independent anti-virus testing organization, released the results of an evaluation of a dozen Mac security products. It intended to test MacKeeper, but the software was dropped after it was found to not be updating itself. AV-Test says it was told MacKeeper, which licenses an anti-virus engine from Avira, had problems receiving updates for three months.

Having written about MacKeeper several times last year as its former owner was reacting to a class-action lawsuit that centered on alleged deceptive marketing practices, I decided to query Kromtech.

It's Not Us, It's Avira

Bob Diachenko, a senior PR expert with Kromtech, blamed Avira, saying a 32-bit file the company delivers to update MacKeeper's signature database was misconfigured. He said the issue didn't last three months, but between four to six weeks. I then reached out to an Avira spokeswoman, who told me that the problem, which didn't affect other Avira products, was resolved in May.

Six weeks seemed to me to be a long time for a security product to not receive signature updates. To be sure, far fewer malware programs target Apple Macs as compared to Windows. This year, there have only been about three true Mac malware programs (see Alert: Ransomware Targets Macs). But Mac security software often does flag so-called potentially unwanted programs such as adware, of which there have been a few dozen samples and variants circulating this year.

I asked Kromtech's Diachenko if his company notified its customers of the product error. "[The] AV database was outdated only for the mentioned period of time, so we did not notify our customers taking into account the temporary character of the issue," he says.

Simon Edwards, founder of the security software tester SE Labs in London, says that in the early 2000s, AV products would get updates weekly, but those days are long gone.

"I'd say that even a week was quite a long time in the world of anti-malware updates," Edwards says. "I would be very disturbed to learn that my anti-malware solution was quietly failing to download updates for any length of time."

Maik Morgenstern, CTO for AV-Test, says the risk to Mac users would be lower than if the same sort of glitch occurred with a Windows AV product. But still, the lack of notification to customers of a product fault smacks of irresponsibility.

"Any disruption in the service should be reported to the user," Morgenstern says.

Questionable Detection

Since Kromtech acquired MacKeeper in April 2013, it has sought to rehabilitate its image, toning down its marketing and tweaking warnings it presents to potential customers who stumble across its ads. As part of those efforts, it has sought to position itself as a peer of other security companies, and in January it launched an Analytical and Security Center run by Chris Vickery.

Vickery was retained about a month after he discovered a 21GB MongoDB database containing Kromtech's customer data online that required no authentication to view (see MacKeeper: 13M Customers' Details Exposed ).

But Kromtech would probably be best served by directing its research efforts toward its own product.

As part of research for this blog to figure out if MacKeeper had resumed getting updates, Thomas Reed, a Mac security expert who now works for Malwarebytes, took a look at MacKeeper version 3.10.1 running on Mac OS X 10.10.5.

Reed installed "Eleanor," the nickname for a backdoor discovered earlier this month that was seeded inside a fake file converter called EasyDoc Converter (see Mac Malware: Still No Need to Panic). MacKeeper detected a couple of PHP files associated with Eleanor but not the launch agents or executables.

"Eleanor should still work just fine in this state," Reed says.

The fault, though, lies with Avira, since MacKeeper licenses its AV engine. For reference, Reed tested Avira's engine against Eleanor and achieved the same result - the malware wasn't detected.

The lesson here from all of this isn't anything new: Be wary of MacKeeper and Avira.

Cybersecurity , Risk Management

Leading U.S. banks, and other publicly traded companies, should expect increased cybersecurity scrutiny from the Securities and Exchange Commission.

See Also: 2016 State of Threat Intelligence Study

This week, during a meeting of the Treasury Department's Financial and Banking Information Infrastructure Committee, leaders of the SEC and the Commodity Futures Trading Commission, which aims to protect consumers from fraud, shared updates about their agencies' approaches to cybersecurity, as well as an overview of their examination processes, rules and other actions.

The Treasury committee focuses on improving information sharing among financial regulators, promoting public-private partnerships and enhancing the resiliency of the financial sector. And its membership reads like a who's who of regulatory authority, including Sarah Bloom Raskin, deputy secretary at the Treasury Department; Mark Gruenberg, chairman of the Federal Deposit Insurance Corp.; and Thomas J. Currey, comptroller of the Office of the Comptroller of the Currency.

While all meetings of the FBIIC are closed, the post-meeting synopsis of the committee's July 19 meeting reinforces what many cybersecurity and legal experts have been saying for months: The SEC is staking claim on its right to review the consumer privacy and data protection practices at all publicly traded companies.

At this week's meeting, SEC Chairwoman Mary Jo White and CFTC Chairman Timothy Massad discussed their agencies' strategies for ensuring cyber resiliency in the financial sector. And committee members were briefed about results from recent cyber exercises conducted to evaluate the impact of a cyber incident on the nation's financial stability, according to the meeting synopsis.

The FBI also played a role at the meeting, noting the need for more information sharing with the financial sector.

The themes discussed at this week's committee meeting repeat what I've been hearing at Information Security Media Group's recent fraud and breach prevention summits: More regulatory oversight is on the way; so brace for it.

At our Boston Fraud and Breach Prevention Summit, Randy Sabett, special counsel at law firm Cooley LLP in Washington, pointed out that because federal regulators are paying more attention to how businesses are protecting consumer information, having detailed incident response plans in place before a breach occurs is more important than ever (see Preparing for Post-Breach Regulatory Scrutiny).

"It's really an extension of what the FTC [Federal Trade Commission] started several years ago," Sabett says. "Now we're seeing, because these various other agencies, in some way shape or form, touch or have jurisdiction over some aspect of personal information, they're now all getting involved. ... They're looking at the breach side of it and going after companies in very much the same way the FTC has done over the years."

And financial fraud expert Avivah Litan, an analyst at consultancy Gartner, says the Treasury Department, in particular, is concerned about cyberthreats that continue to escalate.

"Cybersecurity threats are the No. 1 threats against the stability of the U.S. financial system," she says. "It's good they are taking this so seriously. Just by building a security awareness culture among the regulators and the regulated, they are taking a big step forward."

SEC States Concerns

For the last year, attorneys specializing in regulatory issues have warned that the SEC is taking a more hands-on approach to cybersecurity. And in recent months, the SEC has publicly stated its concerns about cybersecurity and financial stability.

In May, SEC Chairwoman White noted during a speech at Reuters Financial Regulation Summit that cybersecurity is the biggest risk factor facing the financial system today (see SEC Chair: Cybersecurity Is No. 1 Risk).

White told conference attendees that SEC examiners were proactive about doing sweeps of broker-dealers and investment advisers to assess their defenses against a cyberattack.

The SEC, she said, had found that major exchanges, dark pools - private forums for trading securities - and clearinghouses did not have cyber policies in place to match the risks they face.

"What we found, as a general matter so far, is a lot of preparedness, a lot of awareness, but also their policies and procedures are not tailored to their particular risks," she said. "As we go out there now, we are pointing that out."

White's comments at the Reuters' conference came just weeks after the last meeting of the Financial and Banking Information Infrastructure Committee in April, when Assistant to the President for Homeland Security and Counterterrorism Lisa Monaco discussed needed efforts "to better secure government and critical infrastructure."

Get Ready

We can expect in coming weeks to see more from the SEC and the CFTC about their plans to be more proactive about cybersecurity oversight, risk assessment and cyber examination.

Numerous legal experts have told me in recent months that the SEC and other regulatory bodies are staking their claims of jurisdiction over cybersecurity, and this week's Treasury committee meeting seems to affirm that.

Cybersecurity attorney Chris Pierson, general counsel and CISO at invoicing and payments provider Viewpost, says regulators "are communicating early and often on their expectations and changing expectations. Taking a look at committee notes, meetings and public sessions is an important way to understand the direction of the regulators, as these items later find their way into guidance."

Publicly traded banks and other businesses need to be proactive, ensuring that they are prepared to answer SEC examiners' questions about risk assessment practices and incident response plans.

Why are the SEC, CFTC, FTC and others so interested in ensuring they have jurisdiction to enforce penalties for lax cybersecurity? We'll explore that question at our upcoming New York Fraud and Breach Prevention Summit on Aug. 2 and 3, which will feature a panel discussion on the subject.

To learn more about the event, visit our agenda and registration page.

Anti-Malware , Risk Management , Technology

Security products haven't been inspiring a lot of confidence lately. A growing batch of research has shown that security software contains vulnerabilities that can be extremely useful for attackers. A presentation scheduled for Black Hat, which kicks off July 30 in Las Vegas, will reveal a cluster of problems affecting anti-virus applications and other software, including Microsoft Office.

See Also: Rethinking Endpoint Security

A variety of applications do something called "hooking" to get greater insight into another application's behavior. An application's processes and API calls are intercepted, injected with new code and then observed. The invasive process is a critical one for security applications, which need to figure out if something malicious is afoot. Hooking is also used by virtualization, sandboxing and performance monitoring programs.

But researchers at the security firm Ensilo say they've found a half-dozen problems in hooking engines, including Microsoft Detours, an open-source engine called EasyHook, and proprietary engines used by about 20 other vendors, including Trend Micro, Symantec and Kaspersky Lab. The flaws enable attackers to bypass built-in operating system protections, such as Microsoft's ASLR and Control Flow Guard, as well as third-party defenses against exploits.

Any would-be hacker would first need to find a separate way to gain remote access to a targeted system, says Udi Yavo, Ensilo's co-founder and CTO. But once in, an attacker could hack a hooking engine to force the software to inject malicious code into any system process, he says.

Think of it as a force multiplier. For example, a simple buffer overflow vulnerability that gets automatically blocked by security improvements baked into Windows in recent years might once again become exploitable, Yavo says.

ASLR could also become irrelevant because it's possible to figure out the memory addresses of relevant operating system functions.

"Even simple things [become] far easier to exploit," he says. "You don't need to find a place to inject your code. You can simply use places used by these vendors, which are in predictable addresses."

Who's on the Hook?

One of the most popular hooking engines is Microsoft Detours, which Ensilo says is wrapped into the products of about 100 independent software vendors. Microsoft has been notified and is scheduled to patch Detours next month, Ensilo writes. Ensilo suspects the vulnerability has been in Detours since the third version of the software was released, some eight years ago.

The Microsoft Office suite is also affected. Office has a virtualization mechanism called App-V, and Detours is used in App-V, Yavo says. That essentially means that millions of devices are vulnerable. While Office 2010 is not vulnerable, all newer versions are at risk, Yavo says.

Since finding these issues, Ensilo says it's notified a raft of vendors over the past eight months, including AVG, Avast, BitDefender, Citrix, Emsisoft, Webroot, Symantec, Kaspersky Lab and Trend Micro. Those vendors quickly patched the issue. But Yavo says a major anti-exploit vendor and another major anti-virus vendor - both of them have yet to be publicly named - have yet to patch their software.

Ensilo isn't revealing much about how an attacker could use the vulnerabilities, presumably because not all vendors have patched, as well as to save some punch for its Black Hat presentation. But the company says that patching isn't straightforward, because each vendor must recompile affected applications.

Also, Yavo says software vendors are dependent on the hooking engine developer to first deploy a patch before they can recompile their applications.

Seeking Secure Security Software

The hooking problem adds to growing concerns that many anti-virus products might be riddled with dangerous, unknown vulnerabilities that could completely undermine a system's security.

Last month, Google Project Zero researcher Tavis Ormandy - for the second time - found a vulnerability in Symantec's anti-virus engine that could be exploited merely by sending someone an email (see Second Symantec Anti-Virus Bugfest Found). Ormandy's finding added to a long list of problems he's found in products from such security software vendors as Avira, ESET, FireEye, Kaspersky Lab and Sophos.

Meanwhile, expect more details on hooking engine hacks via Ensilo's upcoming "Captain Hook: Pirating AVs to Bypass Exploit Mitigations" Black Hat presentation, with Yavo and Tomer Bitton, Ensilo's vice president of research. It is scheduled to take place on Wednesday, Aug. 3, at 4:20 p.m. in the Jasmine Ballroom at the Mandalay Bay in Las Vegas.

Anti-Malware , Anti-Money Laundering (AML) , Compliance

"Inertia and clumsiness" at the Federal Reserve Bank of New York nearly led to one of the biggest cyber-heists in history being even worse.

See Also: Achieving Advanced Threat Resilience: Best Practices for Protection, Detection and Correction

So says a new investigative report from Reuters that traces the theft of $81 million from the central bank of Bangladesh in February in what was one of the most audacious - and successful - cyber-heists ever. Bangladesh police, as well as the U.S. Department of Justice and the FBI, are continuing to investigate the heist.

Attackers used fraudulent SWIFT inter-bank messages to request the transfer of $951 million from Bangladesh Bank's account at the Federal Reserve Bank of New York, of which $101 million was transferred and $81 million ultimately distributed to accounts in the Philippines and Sri Lanka.

But the Reuters report - based on interviews with current and former officials at banks, investigators and lawyers across multiple countries, and which involved a review of payment messages sent via SWIFT, as well as emails and documents - finds that there was "disarray and bungling at all the financial institutions involved."

The report is most scathing, however, when it comes to the New York Fed, which is the most powerful of the U.S. central bank's 12 regional units, handling about $800 billion in transfers per day. Indeed, despite hackers submitting unusual SWIFT money-moving requests - they requested money be transferred to individuals, the messages were at first incorrectly formatted, and overall they looked different than the bank's typical requests - the bank fulfilled $101 million of the fraudulent requests (see Fraudulent SWIFT Transfers: Congress Queries New York Fed).

Furthermore, it was a "total fluke" that the New York Fed didn't transfer the entire $951 million that had been requested, an unnamed person with knowledge of the investigation tells Reuters. That's because attackers reportedly requested that some of the funds be transferred to a Philippines bank that had the name "Jupiter" in its address, which tripped internal alarms at the New York Fed, because Jupiter is also the name of an oil tanker and shipping company that appears on a U.S. government sanctions list against Iran, which prohibits U.S. firms from doing business with designated organizations or individuals.

As a result, Reuters reports, the bank ultimately did review some of the transactions more closely - finding no link to the oil shipping company - although it moved relatively slowly, meaning that by the time it discovered other irregularities, it had already fulfilled five of 35 transfer requests and had moved $101 million out of Bangladesh Bank's account.

After the bank discovered the fraud, it and Bangladesh Bank were able to freeze and recover about $20 million of the transferred funds. But much of the outstanding $81 million that was transferred to individuals in the Philippines - and reportedly laundered via the country's casinos - still remains missing.

No Real-Time Fraud Controls

The theft revealed that the Federal Reserve's Central Bank and International Account Services unit, or CBIAS - the equivalent to a "bank within a bank," according to a former employee - wasn't using real-time controls for spotting fraud, although such systems are in use at other institutions, Reuters reports. Instead, the unit manually reviewed some transactions after they had been fulfilled, largely to comply with U.S. sanctions, it says.

The theft has damaged the Fed's reputation, especially with central banks of smaller countries who trusted the management and security of their funds to large, well-resourced banks in Western countries, such as the United States, according to Reuters.

The report is also sure to rekindle Bangladesh Bank's simmering dispute with the New York Fed and SWIFT. Indeed, Bangladesh Bank says responsibility for the attacks should be shared by both the Fed and the Brussels-based, bank-owned cooperative SWIFT, formally known as the Society for Worldwide Interbank Financial Telecommunication, which maintains a messaging systems designed to guarantee that money-moving messages between banks are authentic.

Both the New York Fed and SWIFT have denied having any responsibility for the attacks or related fraud. Following weeks of acrimony and finger-pointing, representatives from all three organizations met in May and issued a joint statement pledging greater cooperation.

Officials from Bangladesh Bank and the New York Fed were due to meet last week in New York to discuss efforts to recover the missing $81 million, but that meeting was postponed and no explanation given for the delay. "We are in talks with the Fed and hoping that the meeting will take place anytime at the end of this month or next month," a senior Bangladesh Bank official, speaking on condition of anonymity, told Reuters.

An unnamed Fed official told Reuters that the purpose of the meeting would be to "understand what happened, what remediation steps have been taken by Bangladesh Bank to meet its contractual obligations, and to begin a path to normalize operations."

Bangladesh to Seek Compensation

According to the new Reuters report, however, Bangladesh Bank is now preparing a lawsuit that seeks compensation relating to the missing funds, based in part on alleged errors by both the Fed as well as SWIFT, which left the bank vulnerable to hackers.

Officials from the Fed and SWIFT couldn't be immediately reached for comment on the report. But both organizations have previously denied any wrongdoing or culpability relating to the fraud.

"It is important to note that the recent incident with the Bangladesh Bank was not caused by a breach or compromise of the New York Fed's systems," the New York Fed said last month in a statement.

In the wake of the heist, SWIFT also issued a warning that the malware used against Bangladesh Bank was part of a coordinated campaign against banks, followed by the launch of a customer security program that's designed to help SWIFT-using organizations spot when they've been hacked and to share related intelligence with other SWIFT users.

In criticism leveled squarely against Bangladesh Bank - based on details shared by investigators - SWIFT also noted that it's banks' responsibility to get their information security defenses in order. In a May letter to all 11,000 SWIFT customers, the organization noted that "SWIFT is not, and cannot, be responsible for your decision to select, implement (and maintain) firewalls, nor the proper segregation of your internal networks" (see SWIFT to Banks: Get Your Security Act Together).

Malware Slowed Response

Based on a report seen by Reuters that was generated by incident response firm FireEye - which Bangladesh Bank hired to investigate the heist - whoever stole the bank's funds first obtained the computer access credentials for one of the bank's SWIFT operators, then installed six different types of malware. The attackers reportedly began probing the bank's systems in January, before launching their attack late on Thursday, Feb. 4, apparently timed to coincide with the weekend in Bangladesh, which began the next day (see Bangladesh Bank Ends FireEye Investigation Into Heist).

After the New York Fed's CBIAS team began noticing suspicious transactions, they queried Bangladesh Bank via SWIFT, Reuters reports, but the malware installed on the bank system that connected to SWIFT had disabled the printer, suppressing the messages, and the Fed didn't attempt to contact Bangladesh Bank using any other channels. Meanwhile, it reports, Bangladesh Bank officials on Saturday, Feb. 6, searched and failed to find a manned weekend phone line at the Fed, and also attempted to contact the Fed via email, sending a message that read: "Our system has been hacked. Please stop all payment (debit) instructions immediately." But the New York Fed reportedly apparently didn't receive the message until the start of its workday on Monday morning, and it didn't inform Bangladesh Bank that it had alerted correspondent banks to the fraud until Monday evening, New York time.

Last month, the New York Fed said that it "has and is taking immediate steps to help strengthen the safety of global payments in light of the potential vulnerabilities that have been exposed in the payments chain," but it declined to specify what those measures entail. A source with knowledge of the investigation tells Reuters that the bank has set up a 24-hour emergency telephone hotline for 250 accountholders, most of which are central banks.