Anna Delaney: Criminals hold 1,200 unsecured Elasticsearch databases to ransom. And how can we prevent mobile phone fraud? These stories and more on this week's ISMG Security Report.
(Theme music)
Hi, I'm Anna Delaney. Security researchers at Secureworks have warned of a new attack campaign targeting internet-facing unsecure Elasticsearch databases. Here's executive editor Mathew Schwartz with more on the story.
Mathew Schwartz: Warning: If you store data in the cloud in an unsecure manner, expect extortionists to come calling. This week, for example, security researchers reported finding more than 1,200 cloud-based Elasticsearch databases that had been wiped. Attackers left behind a calling card in the form of a ransom note, stored in the message field of an index inside many of those databases that demands the victim remit a Bitcoin payment. Those details come from a new report released this week by Secureworks. It says, in this attack campaign, the attackers were demanding a ransom of about $620 per ransom note payable to one of two different Bitcoin wallets. Secureworks says, it hasn't been able to identify the owners of the databases. So the good news is that this attack campaign seems to have failed, in the sense that the researchers only found a single low value payment that got made to one of the wallets. The bad news for victims, however, is that the data in those databases is probably gone for good, even if they were to pay a ransom. Here's why: Secureworks says the attacker probably used an automated script to identify the vulnerable databases, wipe the data and then drop the ransom note. The ransom note, of course, promises that the data can be restored. But Securework says that given the cost and logistical hassle of storing the data, the attacker probably never bothered to back it up. This is hardly the first time the data being stored in the cloud has been inadvertently exposed. Just this week, for example, researchers warned that 6.5 terabytes of sensitive electronic flight data belonging to Turkey's Pegasus Airlines had been exposed via a misconfigured Amazon S3 bucket. Beyond S3 buckets, numerous data exposure incidents continue to trace to unsecured Elasticsearch, MongoDB, and other cloud-based databases. Such data exposure comes despite many of these tools, by default, never exposing any data they store to the internet. In other words, administrators must disable built-in protections for this type of data exposure to occur. If cloud database administrators enable public access to the data, experts say they should and must never assume any access controls will be in place. I spoke with Joshua Feather, a security researcher at Secureworks, about what organizations should be doing better. And he told me, users of cloud-based databases that are made to be publicly accessible, must focus on authentication, among other security controls. In particular, he said there's a range of plugins that can increase security. These include encryption, role-based access controls, Lightweight Directory Access Protocol support, and also auditing and logging. But again, these are add-ons, and they need to be added by the user and then made active. One challenges with unsecure databases is attackers can write scripts that automatically find them, automatically delete the data, and automatically leave a ransom note. Very simple! By the same token, however, security teams can also use scripts and automated tools to regularly look for publicly accessible cloud-based databases that might be getting used by the organization to ensure that they are complying with security policies, and simply being actively monitored. Given the ease with which this can be done, don't be surprised if an attacker comes along and tries to hold these databases to ransom if a security team hasn't already found and made them safe first. For Information Security Media Group, I'm Mathew Schwartz.
(Transition ad: You are listening to the ISMG Security Report on ISMG Radio. ISMG - Your number one source for information security news.
Delaney: If software has a dangerous and easy-to-exploit security vulnerability, should its maker tell customers to shut it down until it's fixed? That's a question explored in this next segment from executive editor Jeremy Kirk, with another taster of The Ransomware Files, where ransomware gang REvil is foiled.
Jeremy Kirk: In July 2021, the Dutch company Hoppenbrouwers, in the Netherlands, was one of 1,500 organizations infected by the REvil ransomware gang. The gang seated a fake update in remote monitoring software made by an American vendor called Kaseya. Marcel de Boer is Hoppenbrouwers' financial director.
Marcel de Boer: It was beginning of the evening, when one of our people was trying to log into the system and couldn't get in. It happened to be a problem with ransomware. So that was when all alarms got off.
Kirk: The attackers wanted a $50,000 ransom, but Hoppenbrouwers had good backups.
de Boer: Oh, they asked for $50,000 dollars in Monero, which is a relatively small amount for a company of our size. We stopped the negotiations and we were already recovering from our backups by that time.
Kirk: Kaseya had been warned by security researchers three months prior to when REvil struck that its virtual system administrator software had several zero day vulnerabilities By early July 2021, it had patched some but not all of the issues. One of the outstanding flaws included a nasty remote authentication bypass issue, and Marcel has a thought. He thinks Kaseya should have told its customers that the on-premises version of the VSA software was dangerously vulnerable. Soon after the company found out about the flaws, then customers could decide on their own whether it was worth the risk of continuing to run it while Kaseya engineered patches. Here's Marcel:
de Boer: We were very disappointed that they didn't warn us beforehand.
Kirk: And as we all know, the story has an ugly ending. REvil somehow discovered the unpatched remote authentication bypass flaw plus others. We still don't know how they did that. Regardless of how all that went down, though. Marcel says Hoppenbrouwers would have gladly shut down its VSA software in advance to spare themselves the stress of a ransomware attack.
de Boer: We would have taken it down. It happens a lot. I think that if there is a problem with software, it is fixed before you know it. I think there's a lot happening that we don't know. In this case, it was quite a big problem.
Kirk: There's much more to this story in the latest episode of The Ransomware Files podcast. The episode is called REvil is foiled. You can find it on your favorite podcast platform or on ISMG's websites. For Information Security Media Group, I'm Jeremy Kirk.
Delaney: And finally, mobile phones are an integral part of our digital lives. We've linked banking, emails, and other sensitive data to our phones, making them a perfect target for identity theft and fraud. So how is the telecoms industry responding? I asked Kristi Wilson, senior manager - fraud, Special Investigations Unit and Criminal Analytics at T-Mobile, what her company is doing differently today to spot and stop the scale of the scams that they're seeing. This is from a panel discussion, which is part of our annual virtual Fraud Summit. Do join us on June 16 and 17, 2022.
Kristi Wilson: The telecom industry is there to make communication easy. And that has been a struggle with SMS multifactor authentication. Telecoms are not a third-party security company. And that's what is being currently utilized as, and that is definitely a huge risk. So we are putting in additional mitigation factors to help combat this type of account takeover. But always understand since the goal of communication is communication, not to prevent communication, there is that butting of heads when you come to this situation. But what we are doing and you see it across the industry, we are looking at instituting port out pins. Most carriers are currently at that rate where you have a specific pin to your port out versus the pin to your account. We have things that we can implement like a sim block, which will prevent a sim swap from occurring. The issues with those types of prevention measures is so often they are customer initiated. So I can't just go and put a sim block on every consumer’s account. One of the most common transactions in telecom is the swapping of a device because every time you get a new phone, every time your phone breaks, or anything like that you have to swap the device. At this day and age in society, we are so attached to our phones that it has to be simple. You have to be able to do it easily and quickly. And you have to be able to do it in-person as well as in a faceless environment. Those are the things that we can do and we're really looking at doing to help present or help prevent some of that fraud.
Delaney: That's it from the ISMG Security Report. Theme music is by Ithaca Audio. I'm Anna Delaney. Until next time!
