Comments

ash p • April 6, 2017 3:30 PM

To protect from this kind of attack, I use Microsft EMET Certificate pinning for all the bank sites I use. The only problem is EMET needs a correct web site URL to work and it does not verify if the URL is correct. For example, if a “dot” is present in the URL (difficult to see), EMET will not check the Certificate. To overcome this I wrote a special C# program which constantly checks the URL against a good list in an XML file. So, if the Certificate check fails EMET will alert me. If the URL check fails than my program will alert me.

65535 • April 7, 2017 3:11 AM

@ Bob and a hat tip to Simon Leinen

“…source or guess for what the name…”- Bob

Cough, a big one.

https://en.wikipedia.org/wiki/Banrisul

[Will this fix work for the DNS system and question about fake certificates by Let’s Encrypt]:

‘“Absolutely all of the bank’s online operations were under the attackers’ control for five to six hours,” says Dmitry Bestuzhev, one of the Kaspersky researchers…” …Kaspersky’s Bestuzhev argues that, for banks, the incident should serve as a clear warning to check on the security of their DNS…. half of the top 20 banks ranked by total assets don’t manage their own DNS, instead leaving it in the hands of a potentially hackable third party… regardless of who controls a bank’s DNS, they can take special precautions to prevent their DNS registrations from being changed without safety checks, like a “registry lock” some registrars provide and two-factor authentication that makes it far harder for hackers to alter… Without those simple precautions, the Brazilian heist shows how quickly a domain switch can undermine practically all other security measures a company might implement…encrypted website and locked down network won’t help when your customers are silently routed to a bizarro version [or fake banking site – ed]…“- Wired

[And Counter claims from NIC.br about faking DNS records and probably the fake cert’s from Let’s Encrypt]:

“In a phone call, NIC.br’s technology director, Frederico Neves, disputed Kaspersky’s claim that all 36 of the bank’s domains had been hijacked. “I can assure that the numbers Kaspersky is putting out are speculation,” Neves said. He denied that NIC.br had been “hacked.” But he conceded that accounts may have been altered due to phishing or via customers’ compromised email, adding… “any registry the size of ours has compromises of user accounts regularly…the certificates had been issued six months earlier by Let’s Encrypt, the non-profit certificate authority that’s made obtaining an HTTPS certificate easier in the hopes of increasing HTTPS adoption.” – Wired

https://www.wired.com/2017/04/hackers-hijacked-banks-entire-online-operation/

These fake certificates and this flimsy DNS registrar system needs to harden – not to mention Giggles hosting of the rouge servers in the scam – which needs to be addressed by Giggle. Who is telling the real story? Kasperky, NIC.br, or Let’s Encrypt?

ATN • April 7, 2017 3:38 AM

Amazing this doesn’t happen more often…
Isn’t there enough Mafias in the world having a big enough budget to buy one of the “zero days” accumulated by the “secret” services and making some spare cash, few billions of it…
I still do not understand this world… maybe those Mafias make more money selling “preventive” insurances to these banks.

Vincent Lynch • April 7, 2017 10:52 AM

Has anyone some source or guess for what the name of the bank is

As some others have commented, the target was Banrisul Bank.

Even though Kapersky did not disclose this, we can use the details they did provide to help us narrow down the potential target by searching Certificate Transparency logs (public records of issued SSL certificates).

Right before the attack, two certificates were issued by Let’s Encrypt for Banrisul’s domains. This is the only time that Banrisul has used that CA. Here are the certificates:

https://crt.sh/?id=47630635
https://crt.sh/?id=47675898

I covered this in my article:

https://www.thesslstore.com/blog/ssl-certificates-used-in-major-bank-hack/

Winter • April 7, 2017 10:57 AM

I am pretty sure the blame will be deflected to let’s encrypt, and not to the domain registrars or the bank. Neither to the browser manufactorers who do not destinguish between unchecked domain certificatss and fully checked bank’s certificates.

ab praeceptis • April 7, 2017 11:33 AM

Winter

“I am pretty sure the blame will be deflected to let’s encrypt” – how despicable! Everyone should know by now that let’s encrap is the most totally awesomely special super secure and trustworthy thing in this part of the galaxy.

Next week: Actually rattlesnakes make great pets!

John Galt • April 7, 2017 1:10 PM

@ Vincent, Winter and ab….

[[[ I am pretty sure the blame will be deflected to let’s encrypt, and not to the domain registrars or the bank. Neither to the browser manufacturers who do not destinguish between unchecked domain certificates and fully checked bank’s certificates. ]]]

Don’t you realize that swapping out the NS records at ICANN and replacing the DNS zone with your own renders EVERYTHING worthless — including SSL certificates AND DNSSEC ?

Look for an ICANN insider in LA (Silicon Valley). Ten bucks says they took the day off to count $10 billion Brazilian Reals they put in their offshore bank accounts.

Freezing • April 7, 2017 2:28 PM

In fact it is not a major bank. It is a small Southern Brazilian bank. I`d be worried if it was Itau or BRADESCO.

Their lax approach to security doesn`t surprise me at all [weak passwords on the Registro.br].

My Info • April 7, 2017 4:48 PM

Researchers at the security firm Kaspersky on Tuesday described an unprecedented case of wholesale bank fraud, one that essentially hijacked a bank’s entire internet footprint. … Kaspersky researchers believe the hackers may have even simultaneously redirected all transactions at ATMs or point-of-sale systems to their own servers, collecting the credit card details of anyone who used their card that Saturday afternoon.

I believe this is one of the techniques of the banking crime cartel that seems to be operating in the BRICS (Brazil, Russia, India, China, South Africa). They achieve a much greater degree of infiltration and control over the banks than the public is led to believe.

Then at the appointed time, they carry out the attack, and by somewhat of a “gentlemen’s agreement” with the bankers, a ransom is paid or other conditions are met, the cartel’s hackers back off, and the public is told that the bank was successful in fending off the attack and that situation is under control.

Neither bankers nor criminal hackers have any interest whatsoever in letting the public know the true extent and persistence of the infiltration of organized crime into the worldwide banking system.

@Freezing

In fact it is not a `major` bank. It is a small Southern Brazilian bank. I`d be worried if it was Itau or BRADESCO.

Their lax approach to security doesn`t surprise me at all [weak passwords on the Registro.br].

Small banks do not generally use weak home-grown in-house internet security solutions. They follow industry standards. If you can get into a small bank, rest assured you can get into a big bank. We have plenty of such small banks and credit unions in the U.S.

Freezing • April 8, 2017 8:09 AM

@ My Info

Small banks do not generally use weak home-grown in-house internet security solutions. They follow industry standards. If you can get into a small bank, rest assured you can get into a big bank. We have plenty of such small banks and credit unions in the U.S.

I understand that. But some time you have to deal with the registrar interface [Registro.br], where you don`t have things like 2-factor, to name one thing. I have experience working for organizations in Brazil, and that is a weak link in the process [besides small to medium organizations having bad practices of their own]. I have seen quite a few disturbing things – plus the link that @Simon Leinen provided up on the thread – to base my judgment on. Of course I could be wrong.

ATN • April 10, 2017 3:55 AM

@My Info:

Then at the appointed time, they carry out the attack, and by somewhat of a
“gentlemen’s agreement” with the bankers, a ransom is paid or other
conditions are met, the cartel’s hackers back off, and the public is told
that the bank was successful in fending off the attack and that situation
is under control.

The “other conditions are met” may be simply “never ever forbid us to wash our cash”, after all the “banking crime cartel” needs the banks to make the cash legitimate again…

Clive Robinson • April 11, 2017 8:52 PM

It amuses me that Google cloud was used, for a number of reasons, but it does raise a question

    What is Google’s legal liability?

Whilst Google might gain protection from it’s Cloud End User Licence Agreement for those signing up to use it’s service, it leaves open the question about those victims of the scam who did not sign up to the service…

Depending on the jurisdictional legislation they may well be liable either under the civil or criminal code. Google can not claim the usual “Common Carrier” status because it was “processing” not “carrying”, thus they would be more like a publisher than a postman.

At some point somebody is going to push on a cloud service provider and get a court to agree with the argument that the cloud service provider does indeed have responsibility thus liability. There is a sort of inevitability about this for various reasons…

When it does happen the cloud model will take a body blow in that cloud providers will have to take some preventative measures. Whilst there are a number of things a cloud provider could do, most would have cost implications as well as the chances being good that some if not all of their customers will be negatively effected.

Which of course raises the question of if cloud services will remain viable for those customers. If not the effects on the market could reach back all the way to the likes of Intel and AMD along with other suppliers of parts that go into the production of servers.

SL • April 19, 2017 8:15 AM

I have a hard time understanding why the Bank wasn’t able to send email to their client. It was their external DNS that was taken over, not their internal DNS.

Weird. Kaspersky’s explanation on this doesn’t work.

Rest of the article is pretty good. Time for a trust-worthy & secure DNS Registrar & root system. Hasn’t this need always been there since the beginning of Internet?

Wonder how easy/hard it is to hack the root system or CCTLDs these days.

Clive Robinson • April 19, 2017 9:32 AM

@ SL,

Think about “reverse DNS lookup” and IP address blacklisting carried out by some “mail servers” to reduce/stop spam.

I’m not saying that it is the cause but they have caused problems in the past.

SL • April 20, 2017 9:37 AM

@Clive Robinson

Respectfully I think you’re not getting the point, and your example doesn’t seem to fit.

To send outgoing email one would need to resolve MS records – normally using either an internal DNS resolver or sometimes relay that to an ISP DNS resolver or the over-used 8.8.8.8.

What was hijacked was not that – according to the article, it’s the external DNS server record hosted at the Brazil CCTLD, served by the Brazil CCTLD DNS servers.

Back to the same point – hijacking NS record for the domain does not prevent the bank’s internal DNS server to resolve anything they need to send email. That’s even if they (somehow) need reverse resolution. So I’m still having a hard time understanding this.

As to the reverse resolution fighting spam part, I was asking about outgoing email from the Bank to its clients. Even if the bank is filtering spam on their internal MTA … based on (what could that be???) destination domain’s MX records’s reverse lookup – what exactly does that achieve?

And again, that lookup would have worked anyways, since the internal DNS resolver, ISP DNS resolver weren’t mentioned to be hacked.

Clive Robinson • April 20, 2017 10:19 AM

@ SL,

As to the reverse resolution fighting spam part, I was asking about outgoing email from the Bank to its clients.

If your local MTA connects to the destination MTA at the ISP and it rejects the connection from either a failed reverse lookup or blacklisted IP address then the email does not get sent.

Whilst the Bank DNS lookup might or might not work, the ISP MTA reverse lookup is not going to the banks DNS server but to the CCTLD or one down stream of it that is giving the wrong details.

SL • April 20, 2017 10:52 AM

@Clive Robinson

Great! That is one working scenario.

However it’s not likely to be able to explain what the article describes as inability of the Bank to reach (any of its) clients by email. They must be able to reach some that are not doing this to filter.

I think this is likely inaccuracy on one technical detail from the Kaspersky article. If the Bank wasn’t able to send any email during the hijack, it’s because of something else, not the hijack of its NS record.

======
Correction: should be “MX” instead of “MS” in previous article. Been typing too much of “MS” lately….

Clive Robinson • April 20, 2017 11:17 AM

@ SL,

Correction: should be “MX” instead of “MS” in previous article.

That’s alright, unlike the article it did not get “lost in translation”.

I’m always cautious with what I read when the source is probably not “english as a first language” then reinterpreted by a journalist etc.

It’s also worse if the original source is not a technical person but a PR person or other intermediarie(s). Thus,

However it’s not likely to be able to explain what the article describes as inability of the Bank to reach (any of its) clients by email.

The “any of its” may be a case of them over egging the pudding to avoid litigation.

If you have a look at some of Prof Ross J. Anderson’s comments about UK banks and EVM when it comes to theft of customers money and the ommisions obfuscation and down right inaccuracy they spout whilst under oath etc will tell you a lot about what you need to know.

My Info • April 20, 2017 12:33 PM

@ATN

The “other conditions are met” may be simply “never ever forbid us to wash our cash”, after all the “banking crime cartel” needs the banks to make the cash legitimate again…

Yeah, I know. I left a dollar bill in my jeans pocket when I did my wash.

when it comes to theft of customers money and the ommisions obfuscation and down right inaccuracy they spout whilst under oath etc will tell you a lot about what you need to know.

I know. They took their customers’ money, moved out of the State of Washington, lawyered up, and reincorporated in Delaware like every other white-collar crook and criminal….

https://www.sos.wa.gov/corps/search_detail.aspx?ubi=601886284

SL • April 20, 2017 3:12 PM

@Clive Robinson

Didn’t know about Anderson. Just checked out his paper on where EMV fails – really a rare good read I’ve had on security matters. Thanks!

You’re probably right about the “omissions obfuscation and down right inaccuracy” that could play a part in these articles.

I’m disappointed at Kaspersky that they didn’t at least review the article prior to it went out. With that said, it’s still a good thing that this gets public exposure.

I was also shocked to learn that registro.br is run by nic.br. Not a lot of root operators in their right mind would run registrar business on the side – running a secure web store is just not their business.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.