Fighting attackers in the era of data jacking
In this podcast recorded at RSA Conference 2017, Zohar Alon, CEO at Dome9 Security, talks about how attackers can compromise systems with valuable data that are either on-prem or in the cloud, how they can monetize them, and what we as security vendors and security professionals can do in order to prevent them.
Here’s a transcript of the podcast for your convenience.
Hi! My name is Zohar Alon. Am the founder and the CEO of Dome9 Security. Dome9 Security is a cloud infrastructure security startup based out of Tel Aviv and Silicon Valley, California.
I’m going to talk about era of data jacking, as we call it, on how attackers can compromise systems with valuable data that are either on-prem or in the cloud, how they can monetize them, and what we as security vendors and security professionals can do in order to prevent them from happening in the long haul.
What we saw in the last few months is a rise in reports on database systems, new database technologies that are essentially being compromised; and where attackers will hack into a database, encrypt the data or sometimes delete or do something to the data, and essentially leave a message where they ask you for not too may bitcoins in order to get your data back.
The reports span technologies like MongoDB, Hadoop, CouchDB and others. In our view, it probably also spans some SQL-based technologies, because leaving a door open for an attacker is not only the challenge of new technologies or kind of non-SQL-based solutions. And when we analyzed it, we realized that that data jacking is, really, finding ways to monetize an environment, and not just the standalone PC, which is what the rise of ransomware that we saw over the last few years. Essentially, it’s taking ransomware to the infrastructure.
An attacker today can scan a wide variety of IP addresses and subnets at a very low cost; and try to find those, essentially, default settings on security that were being configured by the people who deployed those technologies. Sometimes those systems are dev tests, just experiments that are sitting out there waiting to be tested or tried by their user. In other cases it starts as a dev test, and then it works great, and the application evolves, and you have the same data that was a POC or a test becoming production data, it has the old security configurations, the defaults, a very weak password. And in most cases, the best thing for firewall – from a developer’s perspective, there’s no firewall between you and your data, you can always access your data. The bad guys also like it, because it allows them to access your data.
We need to realize that while today we can use cloud technologies to block, and cloak, and shield those – by definition – vulnerable servers from being accessed remotely, and we can actually build very granular security policies around them. It requires understanding, it requires mapping of the challenges and some awareness. As more and more people get into developing those technologies, they don’t necessarily have the awareness of what does a secure environment or secure practices really mean. And sometimes it’s laziness, sometimes it’s negligence, sometimes it’s, ‘Yeah, I just opened it to sync the database, and I forgot to close it afterwards’ or ‘I couldn’t find the actual granular rules, so I left it open.’ We saw that with RDP-based vulnerabilities and SSH-based vulnerabilities over the past 15 years, remote code executions on those two technologies. And while it was common practice to leave SSH open, we now know it’s not anymore. It’s actually a bad practice because it’s not just allowing an attacker to brute force his way in, there are unknown vulnerabilities, not the zero days, the ones that we are unaware of, the ones that weren’t even published since the last time we patched the system.
Leaving a window exposed even, just to be visible to an attacker, sometimes you lose the game there and then. While I could hack systems for a long time and compromise systems, those systems, now with, essentially, the success of bitcoin, now I can actually monetize that compromise. Now, to compromise a server without data, in many cases, especially in the cloud, the developer or the user can kill that server, kill the entire subnet, and get rid of all the application and essentially rebuild them, treating them as compromise. That’s why accessing data assets and data jacking, as we like to call it, is kind of a new twist on that, because yeah, you can’t get rid of your data, you need your data. In many cases, it can be production data. In many cases, it can be user-sensitive data that before monetization through leverage on the person that owns that data originally, we could maybe publicize it, essentially let it be known publicly, essentially hurting the reputation of that organization. Now we can skip that. We can go straight to the victim and say, ‘Look, you left a door open. We came in, we obfuscated your data, we have the decryption key, it will cost you a bitcoin. Do you want or not?’
The attackers are doing it at scale, it’s not targeted, they don’t care who you are; you left the door open, game set and match for them – right? And they’ve done it at scale, they have hundreds and maybe thousands of victims. While we are talking, they’re looking for more and more victims. And they use the same cloud technologies to make their operations more efficient. Attackers use DevOps and automation like the most successful Silicon Valley startups. So they don’t care who you are, they just want to catch you in a tough spot, have some leverage on you. And yeah, if you didn’t have a backup or your backup is a couple of days old, and now your application is down because they… Elasticsearch was another example. Any of those technologies that have that vulnerability, all of them are vulnerable to that kind of attack, but essentially, if you use one of them or use more than one of them, and I’ve got the leverage, you’re faced with a decision. ‘Should I pay under $1,000 for an opportunistic victim?’ I know of people that have paid. I’ve met them. We know that there was a recent attack on MongoDB where actually the attacker asked for 0.2 bitcoins, which is $200 at today’s price. In many cases, it’s a no-brainer, ‘Let’s do it.’ What happened in that particular case, they didn’t get their data back, so the they had to resort to an old backup. But the reality is that it’s not going to go away. And we’re probably going to see data jacking expand to, I suspect probably even to on-prem scenarios.
The thing with on-prem, your crown jewels Oracle database, I will need kind of a relay point inside the organization to essentially proliferate the attack internally. And while enterprises do invest in data protection assets, database firewalls, things of that nature, I’m sure we can get access or we’ll have reports of some more enterprise occurrences of that thing. If it can be monetized, trust them that they’ll find a way to leverage. And for us, the tools to prevent that, it starts with awareness. For example, on a IDBS account or a Google account, to map and see that you’re not exposing any data assets, essentially shielding all your database assets from the random IP address that an attacker could come from, it’s very easy to tell. This is kind of the basic capability of many of products, including ours, the Dome9 Security Arc platform. Within under five minutes, you can not just analyze your situation at that given moment, on a continuous basis. When it’s very easy to build, it’s very easy to leave things that are half built out there. You can effectively enjoy monitoring those occurrences.
Sometimes you can just save by understand that you have a piece of infrastructure that you don’t use anymore, ‘Let’s just tear it down.’ You know, Amazon is making great money without us paying them for unused infrastructure. When those experiments become good real applications, let’s make sure they get the proper attention from Day Zero – if I can use the term – because there’s a chance if they were built… when they just spawned the database, you left it open, there’s high likelihood that a smart attacker will plug his way into the system and wait until the data there gets valuable and gets massive. And then, if your applied security control afterwards, you might even talk about an already compromised system. And it starts with education, but the tools today are accessible. You don’t need to sow anything SaaS-based looking at your API and, essentially, describing your infrastructure with you as it grows. And this is what we do for enterprise, and for development teams, and cool startups all over the world.
At Dome9, we are a SaaS platform. You just come in to dome9.com, register for a free trial, no credit card needed. We offer a 14-day free trial for the entire platform, but for small setups of under five servers, you essentially enjoy a free license; we’ll wait until you grow for more than 25 VMs. Actually, the number of 100 VMs is where our customers’ sweet spot is. Yeah, experience the platform, connect their AWS as your Google assets to the platform, and get kind of a current report of where they stand.
Start building security into the DevOps, into the processes in an enabling way, not in a preventive way. So, dome9.com, very simple.
