How to Rob a Bank: The SWIFT and Easy Way to Grow Your Online Savings
•Download as PPTX, PDF•
3 likes•583 views
Bank heists make great stories. This year, we’ve got some really good stories to tell courtesy of a trusted network known as SWIFT, and some banks that believed they were inherently protected by virtue of being connected – except they weren’t. Hundreds of millions of dollars have revealed some ugly truths and dangerous assumptions. In this security fairy tale we’ll talk about scary godmothers, big bad wolves, fire breathing dragons and what’s inherently wrong with the banking system. Because the emperors have no clothes on.
Recommended
More Related Content
Similar to How to Rob a Bank: The SWIFT and Easy Way to Grow Your Online Savings
Similar to How to Rob a Bank: The SWIFT and Easy Way to Grow Your Online Savings (20)
Recently uploaded
Recently uploaded (20)
How to Rob a Bank: The SWIFT and Easy Way to Grow Your Online Savings
- 1. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 1 How To Rob A Bank The SWIFT and easy way to grow your online savings
- 2. Cheryl Biswas @3ncr1pt3d Toronto, Canada Threat Intel Analyst at KPMG Canada Into: Stuxnet, Mainframes, ICS SCADA, Startrek LinkedIn Pulse, Talks, Blogs, TiaraCon DISCLAIMER The views expressed here are solely my own and do NOT reflect those of my employer. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 2
- 3. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 3
- 4. A Tale of Two Servers 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 4
- 5. Once Upon a Time There was a bank 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 5
- 6. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 6
- 7. It needed … Magic! 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 7
- 8. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 8
- 9. What Is SWIFT • The Society forWorldwide Interbank FinancialTelecommunications (if that doesn’t sound like something from a James Bond movie …) • A secured and trusted exchange for financial messages • Banks use it to send back end payment instructions to each other • Brussels-based banking consortium • Does NOT hold funds or manage accounts for customers 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 9
- 10. SWIFTTransactions for Dummies • Each financial org gets a unique code of 8 or 11 characters.This is the BIC or Bank Identifier code or SWIFT ID or ISO 9363 code • The first 4 characters are the institute; next 2 are Country; next 2 or location/city; last 3 are branch codes and optional. Eg DEUTDEFF Deutche bank, Germany, Frankfurt • You can send a message through a SWIFT member bank if you have the recipients corresponding SWIFT code and account id • Other message services are Fedwire, CHIPS, Ripple but SWIFT is the biggest and best at doing this 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 10
- 11. SWIFT By NUMBERS Currently: • 200 countries • 10,800 users • $9 trillion transferred daily • Started 40 years ago • 99.99 % availability (thank you mainframes) 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 11
- 12. “The global backbone of the financial industry” 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 12
- 13. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 13
- 14. A Zero-RiskApproach to Failure • Confidentiality • Efficiency • Reliability • Security • Resilient topology • Robust software designs 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 14
- 15. Just How Does This Add Up to Security? “Our record availability levels are a direct result, and proof of, our security commitment” 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 15
- 16. “We relentlessly pursue operational excellence and continually seek ways to lower costs, reduce risks, and eliminate operational inefficiencies” What’s missing here? 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 16
- 17. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 17
- 18. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 18
- 19. DangerousAssumptions • Air-gapped is absolute. It isn’t • Private networks ensure safety.They don’t • Special systems operating in their own secure enclaves, with their own proprietary setups will remain impenetrable.They won’t • Inherent Protections. Are not. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 19
- 20. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 20 NoVirginia, there is no Inherent Security
- 21. TRUST ISSUES What do we know aboutTRUST people? Complete the sentences 1. Trust … 2. Trust … 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 21
- 22. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 22
- 23. Then one day the Magic stopped working 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 23
- 24. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 24
- 25. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 25
- 26. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 26
- 27. Banker’s Hours 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 27
- 28. Hello? 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 28
- 29. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 29
- 30. BAE SYSTEMS DIAGRAM 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 30
- 31. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 31
- 32. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 32
- 33. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 33
- 34. TheTelltale Printer: "HP LaserJet 400 M401" 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 34
- 35. TheTelltale Printer: "HP LaserJet 400 M401" 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 35
- 36. And another question “Extensive integrity controls built into SWIFT apps to protect against unauthorized changes to messages and to detect corruption of messages” SWIFT website So how exactly did that Oracle db thing get by you? 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 36
- 37. "It was the bank's systems or controls that were compromised, not the software.The SWIFT software behaved as it was intended to, but was not operated by the intended person or process.This is a bank problem, not a SWIFT problem.“ William Murray, independent payments security consultant 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 37
- 38. Heist by Numbers COUNTRY BANK AMOUNT DATE Bangladesh Bangladesh Bank $81 Mil Feb 2016 Philippines Unnamed 2015 Ecuador Banco Del Austro $12 Mil June Vietnam Tien Phong Bank Failed June Ukraine Unnamed $10 Mil April 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 38
- 39. About that $10 switch … 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 39
- 40. The FED vs SWIFT 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 40
- 41. “SWIFT is … as flaky as ICS or SSL… you can’t separate workstations from SWIFT and remove them from the network.” Risky Business Podcast 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 41
- 42. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 42
- 43. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 43 Now with MORE Security!
- 44. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 44 A SWIFT Response • The new Customer Security Programme CSP • 5 Steps to better security: 5 strategic initiatives • DailyValidation Reports. Out of band access. • “customer systems or operational staff that have been compromised and locally stored records that have been obfuscated”
- 45. SWIFT New Core Security Standards 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 45
- 46. “The Swift payment system is only as strong as the operational controls built and enforced around it … and a lack of strong policies and procedures for increased vulnerabilities.” MarkWilliams, lecturer at Boston University 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 46
- 47. “TheVietnam case shows that the global banking system is vulnerable to cyber attacks, and we should make a global effort to prevent these attacks” Bangladesh Bank spokesman Subhankar Saha said Monday. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 47
- 48. Who Dunnit? 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 48
- 49. It was the Lazarus Group, 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 49
- 50. It was the Lazarus Group, in North Korea, 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 50
- 51. It was the Lazarus Group, in North Korea, with a wrench 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 51
- 52. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 52
- 53. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 53
- 54. The Sony Hack 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 54
- 55. Meanwhile, back on the ranch … 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 55
- 56. “If we haven’t seen them in the US it’s because nobody’s bothered … MostWestern Banks have not had to deal with these attacks” Brian Krebs on Risky Business podcast 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 56
- 57. “Banks are fighting a war on every conceivable front. It’s a losing battle.There’s no way to share enough information among enough people.” Anonymous source 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 57
- 58. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 58
- 59. 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 59
- 60. Which brings us to … Odinaff • Discovered January 2016 attacking banks, securities, trading, payroll globally • Mounted attacks on SWIFT users, malware hiding fraudulent transactions • Lightweight backdoorTrojan • Makes use of common hacking and legitimate software tools like mimikatz, PSExec, Netscan, Powershell, Runas • Malware designed to compromise specific computers. Requires a lot of manual intervention • Linked to Carbanak through shared infrastructure, 3 C+C IP addresses, backdoor Batel 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 60
- 61. Imagine Dragonz 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 61
- 62. But what if I told you there was a fire- breathing dragon 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 62
- 63. Breach the Moat 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 63
- 64. How the Mighty Fall 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 64
- 65. Bigendian POC 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 65
- 66. Hospital ransomware + JBOSS 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 66
- 67. WhatWouldYou Do Better? 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 67
- 68. The Moral of the Story • Trust No One/Trust butVerify • Go looking for the big bad wolf before you get eaten • For God’s sake do the basics right • Don’t Assume Anything. It makes an ass out of U and Me 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 68
- 69. Thank You!! • @bigendiansmalls • @mainframed767 • SecTor • DefensiveSec, Brakeing Down Security and Risky Bus Podcasts • Numerous members of the InfoSec community 12/6/2016 "How to Rob a Bank" by @3ncr1pt3d 69
Editor's Notes
- Let’s start with this. We assume that banks take better care of our money than anyone. The service fees alone tell us that. So we assume that these institutions understand security at a higher level than almost anyone because of all that money. We are given to expect that there are effective security processes in place to safeguard our assets, because, after all, if anyone should know how to do security right, it’s a bank. Right. Yeah, right. We know better.
- So boys and girls, it’s story time. I’m going to tell you a security fairy tale. A cautionary security fairy tale called A Tale of 2 servers. And it goes like this…
- Once upon a time, there was a bank. And like all the banks in the kingdom, it had clients, networks and a lot of money to send back and forth. Securely. But like adulting that was hard …
- And one day - poof! There appeared Scary Godmother SWIFT. With a wave of her magic wand, she created a system centered on uptime & efficiency to help the banks make their transfer payments. Now all the banks across the kingdom were connected and protected
- And Scary Godmother Swift told them they were all protected by the most powerful magic of all … TRUST So what is SWIFT … and if that doesn’t sound like a nefarious organization from a James Bond movie ..
- SWIFT started as a Telex based system. But that was slow, and if you can believe it, less secure. SO banks, security brokers, traders are the main users. It sends payment orders between institutions using the unique SWIFT codes, using Relationship Management App over Bilateral key exchange. IT’s about syntax and processes and turnkey solutions SO basically, SWIFT provides a centralized store-and-forward mechanism, with some transaction management. For bank A to send a message to bank B with a copy or authorization with institution C, it formats the message according to standard and securely sends it to SWIFT. SWIFT guarantees its secure and reliable delivery to B after the appropriate action by C. SWIFT guarantees are based primarily on high redundancy of hardware, software, and people. Some of the more well-known interfaces and CBTs provided to their members are: SWIFTNet Link (SNL) software which is installed on the SWIFT customer's site and opens a connection to SWIFTNet. Other applications can only communicate with SWIFTNet through the SNL. Alliance Gateway (SAG) software with interfaces (e.g., RAHA = Remote Access Host Adapter), allowing other software products to use the SNL to connect to SWIFTNet Alliance WebStation (SAB) desktop interface for SWIFT Alliance Gateway with several usage options: SWIFT assigns each financial organization a unique code that has either eight characters or 11 characters. The code is called interchangeably the bank identifier code (BIC), SWIFT code, SWIFT ID, or ISO 9362 code. (See related: What's the difference between an IBAN and a swift code?) To understand how the code is assigned, let’s look at Italian bank UniCredit Banca, headquartered in Milan. It has the 8-character SWIFT code UNCRITMM. First four characters: the institute code (UNCR for UniCredit Banca) Next two characters: the country code (IT for the country Italy) Next two characters: the location/city code (MM for Milan) Last three characters: optional, but organizations use it to assign codes to individual branches. (The UniCredit Banca branch in Venice may use the code UNCRITMMZZZ.) The SWIFT secure messaging network is run from two redundant data centers, one in the United States and one in the Netherlands. These centers share information in near real-time. In case of a failure in one of the data centers, the other is able to handle the traffic of the complete network. Read more: How The SWIFT System Works | Investopedia http://www.investopedia.com/articles/personal-finance/050515/how-swift-system-works.asp#ixzz4NYCJMRpK Follow us: Investopedia on Facebook
- Let’s do a little SWIFT by Numbers
- And yes, it’s all about trust
- Now this is what SWIFT sets out as priorities. That’s a lot of nice words. Notice the focus on security.
- And just how does this add up to security?
- Sorry but when does Uptime equal security?
- So let’s look at how things work. Behold the magic that is SWIFT! Hmmm. They’ve got all the good stuff here. IT is A Layered security model. .They use A VPN. They have PKI. I feel safer already.
- Well, according to these rules, they trust and verify. It really is magic. But is it security? Your Turn: Should this have been enough to keep the banks safe?
- Security has its own mythology. We run on some dangerous assumptions
- 15 MINUTES******** It’s about trust, assumptions, and how the road to Hell is paved with all those good intentions. It keeps coming back to what we don’t know. Because we are blinded by what we think we know. We assume that’s enough. That we have adequately provided for our own security. And given that we should put out trust in other parties to protect us, like SWIFT. Because of who they are.
- It comes down to Trust Issues. And what do we know about trust? YOUR TURN Trust No One Trust but verify
- So back to the banks in the kingdom. Sure, they were protected. From Bogeymen. Narwals, Trolls. Goblins. Orcs. Bogarts. Just not The Big Bad Wolf. And if you’re not afraid of the Big Bad Wolf, well you sure as hell should be. YOUR TURN: Tell me who you think it is … North Korea and China So we’re not seeing the magic here, are we? But what about those banks? Well this is a security fairy tale. About trust and assumptions. And we got a lot of emperors running around without any clothing on.
- In a big bank, in the faraway land of Bangladesh, attackers almost made off with a cool $billion. Except spelling apparently wasn’t their strong suit. When I first heard this story on the Defensive Sec Podcast in March, I was hooked. It started with how a typo in the transfer requests kept thieves from getting the other $900 million of what they went after.
- The folks at the bank had no idea anything was wrong. It wasn’t like they had AlarmForce. There were no warnings that went off to say that intruders were in the system.
- Nobody had any idea until February 5, when there were no SWIFT printouts. And those printouts are key to this story because they were part of the SWIFT trusted messenger system, and were generated every day single day. Rain, snow, sleet or hail. Until they weren’t. So you can imagine the folks in Bangladesh, scratching their heads wondering where the heck their printouts were.
- And here’s where things get clever. This happened on a Thursday when the bank in Bangladesh was closed for business but the American side was open. They lost an entire day as the bank made manual printouts and then discovered something was very wrong. As the story goes, from ongoing testimony, someone got a bad feeling about this being more than a computer glitch and the Bangladesh Bank contacted SWIFT to help them analyze the transactions. Then they e-mailed and faxed the Federal Reserve Bank of New York, where they kept an account, and put in a stop order for all unauthorized payments until further notice.
- For 2 days, both that Saturday and Sunday, Bangladesh Bank failed to reach officials in New York by phone. Because it was now the weekend in the U.S., and nobody was available. Sorry – what year is this? Nobody answered the calls for help from Bangladesh. SWIFT didn’t have a 1-800 number apparently. Desperate, Bangladesh did the only thing they could think of. They relied on the trusted messenger system to send their calls for help. No. I am not kidding.
- By Monday morning, the money had been successfully sent out to branches in the Philippines where the attackers had set up dummy accounts months in advance.
- BAE systems did a really good analysis and breakdown of events right after this happened. It was clear the level of skill that had been required to pull these heists off. We still aren’t sure how the system was initially compromised; how exactly the attackers found their way in. We do know that they were in the networks for a while, gathering all the info they needed without detection. Does this sound familiar? And all that information gathering gave them the depth of knowledge needed to write the targeted malware against the SWIFT’s system. This took far more than just insider help.
- The malware was discovered uploaded to online malware repositories. IT’s been described as being highly configurable and part of a wider attack toolkit. That means what you think. They were going after more targets. And not necessarily banks What it does is inspect the SWIFT messages for certain strings, then it extracts certain fields like transfer references or SWIFT addresses. IT uses these to interact with the Oracle Database in the SWIFT Alliance access software and update or delete actual transactions. The tool was custom made for this job. The malware inspects all processes to see if they contain this module: lboradb.dll When it finds it, the malware applies a patch and overwrites 2 specific bytes. This is the JNZ opcode. It’s a conditional jump instruction that follows an important key validity or authorization success check. It throws the systems off the scent of any fraud. So these 2 “do nothing” instructions trick the host application into believing that the failed check has actually succeeded. Now what liboradb.dll does consists of 3 things: It reads the Alliance database path from the Registry It starts the database And it performs database backup and restore functions So every member bank within this SWIFT network runs its own instance of the Alliance access software. The attackers don’t have to go after SWIFT directly when they can access one of the many offshoots.
- Let me show you what that would look like.
- A whole lot of checking and monitoring of files goes on. The malware intercepted the confirmation SWIFT messages. Read, parsed and converted those into PRT files. And in the PCL language used the attackers specify the EXACT printer model being used. "HP LaserJet 400 M401“. And these temporary PRT files are submitted for printing. Once sent, they are overwritten with zeros and effectively deleted. Let me say this. IF SWIFT and the FED had been been checking files on either side of the network even half as well as the attackers were, well we wouldn’t be having this talk today.
- So let’s come back to those printer confirmation messages that get sent, every single day, by SWIFT. The ones that didn’t go through that day because they would have revealed those modified transactions the attackers made. And game over. That serves as a check on the system to detect anomalies. Which the attackers figured out because they really did their homework. They needed to give the printer a temporary gag order.
- So let’s come back to those printer confirmation messages that get sent, every single day, by SWIFT. The ones that didn’t go through that day because they would have revealed those modified transactions the attackers made. And game over. That serves as a check on the system to detect anomalies. Which the attackers figured out because they really did their homework. They needed to give the printer a temporary gag order.
- And then there’s this. Now the messages were being sent by the system, albeit with typos. But only because the attackers were able to manipulate that liboralb.dll file. So how exactly did that Oracle database hack get by those controls? I’m seeing malware exploit the SWIFT app to bypass the validity check within the ORACLE DLL so that the attackers could change or delete actual transactions. And then, those confirmation messages from SWIFT that were supposed to go to the printer but never made it there. Because they were tampered with in real time.
- You can bet SWIFT was swift indeed to draw and point their finger at the other guy. This wasn’t on them. They had those controls. Their software wasn’t hacked. So let’s look at this as a bank problem.
- BUT it wasn’t just one bank. There were more. And we should expect there to be others
- HALFWAY 28 Minutes******* There was no firewall. Instead there were second hand $10 switches connecting the network computers to SWIFT Much has been made about this. And it’s true. The banks own their share of responsibility. But what about the SWIFT techs who couldn’t be bothered to get access to the secure room where the network was, and instead set up a wifi which they forgot to take down. Can you say backdoor? But this isn’t an isolated incident. There are other banks within that region doing similar things. And honestly, it isn’t limited to the developing nations. Don’t be surprised to find this kind of behavior here: unpatched XP systems. Incomplete fixes against Shellshock. The list goes on.
- And if they can’t blame the bank, then SWIFT will blame the Federal Reserve. Here’s my issue. Why wouldn’t you make sure than anything connecting to you was secure? Why would you just absolve yourself of it when you know – because you have to know – what the consequences would be? "Swift should stop putting the burden of secure access on the banks and complement the banks' security measures with their own fraud detection measures that mitigate the risk of account takeover," said Avivah Litan, vice president at Gartner. "There are plenty of security measures in place these days — for example gesture analytics and user and entity behavior analytics — that can greatly reduce the risks of fraudulent Swift payments. These are measures that Swift must implement, as the requesting banks don't have the data or computer processes to put them in place, as Swift is the custodian here."
- Just one of the glowing endorsements of SWIFT I came across when doing research.
- The SWIFT website has since undergone a major transformation. They let the numbers speak for themselves. And yes, uptime is everything. Thank you mainframes!
- On a recent Defensive Sec podcast, they analyzed the new SWIFT approach citing “There wasn’t a 24/7 mindset around these transfers; there was just implicit trust. “ But SWIFT was adamant their software was not hacked. Their constant refrain: It’s not me – it’s you. Here it is on their shiny new site. And yet this site, and its offerings are in direct response to the attacks.
- They promised more at the end of the month. CISO Alain Desausoi declared it a “watershed event”. He was surprised by the gaps in banks’ cyber security practices. “We were surprised by the gap between the skills of the attackers and cyber sec practices in the banking industry. “ Alain to FT Cyber Sec Summit in London. SWIFT acknowledged the heist involved altering SWIFT software to hide evidence of fraudulent transfers but said its core messaging system was not harmed. Now SWIFT is introducing pen testing, sec ops centres and proactively hunting for attackers. SWIFT is advocating more that tech solutions. Training and support. SWIFT is now on the detect and look for anomalies train. “The best way to find attackers is to look for abnormal activity, although defining ‘normal’ is a never ending quest” Desausoi.
- But the facts speak for themselves. Those controls seem to be more words than anything actual. Like the Emperor’s new clothes. ** THE WAY ACCESS WAS GAINED HAS NOT BEED RELEASED** IT WAS NOT A VULN WITHIN SWIFT
- Once the banks and SWIFT stop pointing fingers at each other, they might consider the likely perpetrators. From the evidence at hand, that would be The Lazarus Group. So who are the Lazarus Group? They’re a well-established organized crime group whose name represents how they tend to disappear and then seemingly resurrect from the dead. And they are directly connected to North Korea. While nothing has been officially declared because Attribution is a dangerous game, Symantec researcher Eric Chien pointed out how distinctly similar the code is between that used in the Sony Hack and the malware found in the repository. I don’t have time to get into it here, but the key distinctions are about a specific piece of code. And this was also used to attack media companies and banks in South Korea in 2013. And here’s the story in the story. Some years ago China was looking for a way into the Mexican banking system. Well, lo and behold, what they actually found was a way into the North American system thru Mexico. They were able to make their way through our banking system for years. Years. Gathering all the info they wanted. And when they were done, they put that code up for sale in 2015. Guess who bought the code? North Korea bought that malware that was used in the heists for the Lazarus Group. YOUR TURN:
- You all remember the Sony Hack end of 2014? That was some attribution blame gaming at its finest, and a whole lot of blaming and shaming went on. But this was one of the most destructive deliberate cyber – there I said it – attacks post Stuxnet. Wiper malware means never having to say you’re sorry.
- So let’s move things closer to home. Like right here in the USA. Because I’ve got some news for you, and it ain’t good. On a scale of 1-10, how safe do you think banks in the US are? What’s the likelihood of something like this happening here?
- Well, let’s start by looking at how banking is structured here. We’ve got the megabanks: JP Stern. Morgan Stanley. Wells Fargo. Too big to fail Followed by the big ones, major city and state banks. Now these guys are well-regulated. And they have a lot of incentive to do things right. They spend the money to secure the money. BUT The problem is COMPLEXITY. YOUR TURN: Can anyone tell me what I mean by that?
- Too many moving parts. Virtual servers are hard to inventory. Physical ones are tough. I talked to some anonymous sources to get a feel for what it’s like. They find boxes that aren’t listed anywhere, unaccounted for. So imagine what isn’t being found that you can’t see. This is an environment that enables people to operate as rogue employees, who can move around within the networks undetected. This is your insider threat. Then there’s the medium sized ones, that are found in every city and town And last but not least those small-town friendly ones that still do business with a handshake and smile. That’s a whole lot of layers, and a nightmare to regulate from a security perspective. And juicy targets according to Brian Krebs. He painted a grim picture of what may be coming for US banks. They go where the money is and where they can most easily move it. A lot of small and medium banks that don’t have the time, money or most importantly, the inclination, to really secure. Because they operate from the ASSUMPTION that “nobody will come after them.” They have this perception of Inherent Security. Because they run on mainframes and they are also connected to SWIFT. But they aren’t as regulated as the bigger banks. That makes them ripe for the picking. And this is the thing – they offer a gateway into the system for attackers. Now, I’ve listened to people tell me some interesting stories about banks. Bout Telneting to Root because SSH didn’t handle the characters otherwise. About presumptions that a firewalls was sufficient security in and of itself because nobody would dare go after that. And about having all the equipment for disaster recovery sitting unused, undeployed because they didn’t want to risk testing the systems. If you don’t test it, how do you even know it works? It’s an attitude. We’ll come back to this in a moment.
- I love podcasts. On a Risky Business, they were speaking with Brian Krebs on his take regarding financial crime. Now, we know Brian is like that proverbial canary in this security coalmine. He’s onto things before the rest of us. And he had grim tidings for the US, observing that most western banks have not yet had to deal with these attacks. But I have one word for you. Carbanak. And yes, that is one big, bad wolf.
- When the story first broke in 2015, this was an APT that went after mostly Russian financial institutions. They bough access to employee computers already compromised by malware Once victim endpoints were infected we saw privilege escalation, lateral movement in the network and infrastructure, deep recon and then attack. Similar to this, the attackers compromised the Oracle database, created fraudulent accents, modified balances and sent themselves money. USING SWIFT to move mass amounts. According to Kaspersky labs, 100 banks in 11 countries were hit to the tune of $1 billion. Undetected for well over a year.
- So our friends at Symantec found evidence that the Odinaff group has mounted attacks on SWIFT users, using malware to hide customers’ own records of SWIFT messages relating to fraudulent transactions. The tools used are designed to monitor customers’ local message logs for keywords relating to certain transactions. They will then move these logs out of customers’ local SWIFT software environment. They are careful to state “We have no indication that SWIFT network was itself compromised.” Which is the SWIFT byline What’s interesting to me here is whereas the Lazarus group comes across as more nationstate, Carbanak is a highly sophisticated criminal group. Those guys are in it to win it. They are all about efficiency and bank for the buck. So investing time in developing targeted malware would go against their ethos. However, if Odinaff were to bridge that need, to serve the purposes of the state via the existing mechanisms of an established criminal group, then … you can see where I’m going with this and darn I don’t have my attribution dice to roll.
- 50 MINUTES *********** Here’s what you need to worry about. The nature of the mindset of the adversary has changed. You can no longer assume their lack of will to make the effort or lack of knowledge of your systems will protect you Why? Because there are so many other ways in. Easier ways than what you expect. But what should scare us is this: There is no more honour among thieves. The ransomware attacks on hospitals proved that. They crossed a line and they aren’t going back. Loss of life doesn’t mean what it once did. And all those kingdoms out there are ripe for the picking. So what is the worst you think could happen and why?
- But this is what you really came for. And I promised.
- So tell me what banks run on? What anything that needs constant uptime and super fast processing speeds runs on? (Mainframes) Right! And how safe are these? Pretend like you don’t know it’s me asking. Right. For the most part, they really are secure. It’s the part that isn’t secure I’m going to show you. Be afraid. Be very afraid.
- So, as some of you may know, I have these friends, Bigendiansmalls and SoldierofFortran. We kinda have a thing for Big Iron. Anyway, when I told them about what I was doing, they offered to set me up with a little something called a POC. And being the standup guys they are, they even sent me this to share with you all today. Because if you still think you can’t hack a mainframe, I’m about to show you how you can, courtesy of these experts. And to prove again why our trusted assumptions are no more than a security fairy tale.
- So - here we have a secured, patched mainframe z/OS v2.1 running an older version of JBOSS (5.1 here, but 6.x also worked for this demo). JBoss is often packaged with 3rd party products as a container for their management interfaces (e.g. Java apps that are used to manage whatever the actual Z product is). The JBoss (or Tomcat for that matter) installs and configs are often afterthoughts and many vendors don't put much work into securing or maintaining them. Here I'm showing that an out of the box JBoss install that could come with a 3rd party product on mainframe (and does, but not naming names). Is vulnerable to the out-of the box jexboss.py exploit kit - complete with a command shell that works perfectly! JAVA does all the EBCDIC <-> ASCII character translation for you, so what you get is a nice clean USS (Unix System Services) on z/OS shell! If the JBoss instance is running as a privileged ID, and they often are, then you inherit those privileges as well. Game on.
- WE all know about the ransomware that hit hospitals this past winter. What you may not know is that spread via a layer of older, unpatched middleware: Jboss. Which had a well known vulnerability that was being exploited via jexboss but nothing had happened with that for well over a year. Until some script kiddies found it online and decided to make a lot of gain from other people’s pain – literally. This scenario should scare you because Jboss runs on so many things, and we are talking not just banks, but critical infrastructure and transportation. DO you know what’s on your AS400?
- You need to question your assumptions. Be paranoid. Start thinking like an adversary and look at what is their endgame. The fact is that it only takes 1 well placed person to tip the system over. And when that mainframe goes down hard, it doesn’t tend to come back up. We know that standard detection capabilities aren’t working. We’re dealing with Exploitation, download, installation, malware modules, exfiltration, remote access and endpoint takeover, plus SE and fraud account setups. These were not discovered by the existing security. And we know Had the reconnaissance stage of the attack been discovered quickly, the entire operation would have failed. What needed to happen with Carbanak was a multilayered defense approach to protect corporate endpoints against advanced malware and credential theft — for example, disrupting the exploit chain that was used in the Carbanak attack to download remote access Trojans and other malware on the machine. By disrupting the exploit chain, the spear phishing scheme would have failed and employee endpoints would not have been compromised to begin with.
- So there you go. The fact is, whether we like it or not, attackers are able to empty electronic bank vaults. And they just have to enter the system through one of the smaller banks to get to where the gold is. We’re only as strong as the weakest link in that security chain. SWIFT CEO Gottfried Liebrandt said in may other attacks may have been unreported. And that attackers could strike another bank and bring it down. Well you can bet that the financial world, and the rest of the world, are paying close attention to how this scenario develops. Because, hey, money talks. Especially when it’s hundreds of millions. The BOTTOM LINE is, we need to stop handing over control with blind trust based on assumptions. Because security in not inherent. SWIFT needs to realign their priorities and not hide behind a smokescreen of uptime and efficiency. If we keep letting ourselves believe what we are told will work we’re believing in fairytales. Only there will be no happy ending. GO tell the emperor he has no clothes on.