Transcript
Hey there, how are you? I'm outstanding. My name is Matt Radlach. I'm joined by our co-host David Gibson, and we are so pumped to talk with you guys for another episode of State of Cybercrime. I see a bunch of people chiming in, letting us know where we're chatting to and connecting with you from today. I'm at home in Maryland. What about you, David? I'm at home in Connecticut. It's so great to have you here today. We're going to crack right into it, and we'll go through a bunch of our usual segments. We'll definitely cover whether or not there's any good news. We'll talk about all the latest happenings in AI. We'll jump on the highway to the danger zone and talk about some threat actors and some attacks that you should be worried about. We'll cover some vulnerable vulnerabilities. So with that, let's jump into it. What's the name of our first segment here, Matt? Yeah, this is, is there any good news? And if I had it autoplay, then we would get to hear that. That's what we were waiting for. Our first segment is, we like to cover all the good news and the good things happening in cyber. For those of you who join us for the first time, there's often a ton of doom and gloom. Everybody's got a lot to say, and it's usually not very good. So yeah, let's crack into it. Excellent. So we, there's, there's Operation Morpheus is kind of our first topic, and that, I think it's well-named, but this was a coordinated effort by law enforcement from Australia, Canada, Germany, the Netherlands, Poland, the US, and was led by the UK National Crime Agency. But essentially what they did was over several years, it looks like, they identified almost 700 IP addresses that were kind of on the other end of Cobalt Strike beacons, malicious Cobalt Strike beacons, which attackers can use to achieve command and control, right? So command, I guess the first stage is you deploy a beacon. By the way, this was a red team tool that was kind of, I guess, appropriated by attackers and modified so that they could use it for their own ends, but essentially dropper on a victim host that then beacons out to a command and control server where they can drop another payload and do more stuff. So I think this is a win for the good guys. Almost 700, actually it looks like about, they identified 700 IP addresses on 690, and so far, almost 600, 593 of the addresses have been taken down. A few more to go there, but that's a lot fewer bad guy servers than there were before, right? Yeah, and I still, you know, to this day, the Cobalt Strike framework, when the source code got leaked online, you know, we are still paying the damages for that one. Even here in 2024, I think that that leak happened maybe even in close to a decade ago or eight or nine years ago. So it's great though to see, you know, law enforcement come together and these cross border, cross continent, even collaborations between cyber agencies definitely shows progress towards, you know, taking down the hackers, the attacker groups and their infrastructure. But that's not the only good news we've got, David. A lot of people, you know, get excited or worried when they hear about ransomware groups like Scattered Spider. They were responsible for a large attack campaign called Octopus. I don't know if you remember us talking about that. Targeted hundreds of organizations like Twilio and CloudFare, and they were behind that. But the one that really got, the story that really got Scattered Spider under the eyes of law enforcement and really the world was the attack on MGM. And it was after that attack that the FBI led an offer for a reward for information that would lead to the arrest of those involved in Scattered Spider. Now it's interesting, there's a little bit of an inception happening here. Scattered Spider actually used the Black Cat and Alpha V ransomware to take on MGM resorts. So at the time, even we said we thought it was Black Cat and Alpha V that was behind the attack, but it looks like it was Scattered Spider. Well, just a few months after the FBI offered their initial reward, a 22 year old British man got arrested in Mallorca trying to board a flight to Italy. This man was in possession of right around 30 million in Bitcoin and is suspected to be the leader of the Scattered Spider ransomware group. This arrest was due to a coordination between the Spanish police and the U.S. Federal Bureau of Investigation. So it does continue to look like that if you start to do this cybercrime, you might have to do the time. So when you've got 30 million in Bitcoin, can you fit that on a carry-on or did you have to check that? You know, there's this thing, it's a digital currency, David, so you can probably fit it in your pocket, I would imagine. All right, got it. Let's jump on to our next segment here. And this is our newest segment, and it's one that is the topic that everybody loves to talk about. I mean, come on, nobody is tired of hearing about AI. And saying AI to yourselves is probably what you're doing right now. So we'll cover the good, the bad, and the ugly as it happens and relates to AI and our eventual demise to the robot overlords. First up is prompt engineers got a win, and mankind's hope for ethical AI has lost again. Researchers are banging away at generative AI prompts to find loopholes. How this skeleton key loophole works is you're going to ask the AI model to augment rather than completely change its behavioral guidelines. So in the case of asking for something like how to make a Molotov cocktail, in this case, the prompt engineer asked, but said, hey, look, I know you're not supposed to do this, but if you give me the response with a warning label, then you can give it to me for educational purposes, right? And that's exactly what happened, right? You're able to trick these generative AI co-pilots and provide you with responses that they otherwise wouldn't. And this skeleton key didn't only work on Microsoft co-pilot, though. It also worked on Metas Llama 3, Google's Gemini Pro, ChatGBT 3.3 and a half, OpenAI's ChatGBT 4, Mistral Large, Anthropic Cloud, Opus, Cohere Commander R+, they really all seem to be vulnerable to this. And David, when we were talking about this, you really brought up how this might not be something that we can stop because there's always going to be ways that we can ask for information that if asked in the right way, you're going to get the response, but if used in the wrong way, could be malicious or potentially harmful. Do you want to talk more about your thoughts on that or really what is good enough in terms of stopping AI from providing these types of results? Well, AI helps you get that information and information can be used for good or not so good. I think it's going to be hard to know what the spirit is behind asking the question and how somebody wants to use the information that they're getting. The same information that could be used to save somebody could also be used to hurt them. And I think we've got a tall order ahead of us. I think it probably it's going to involve a lot of sophisticated analytics on what people are actually doing with the AI and what the intent is. But I feel like just like any tool can be used for good or for evil, it's going to be hard to know what the intent is, what the outcome of providing that information is going to be. You could be an evil genius or a genius that does a lot of good in the world. It's the same wetware. At that point, is it any different from running a Google search or an internet web search? Because if we're talking about the law enforcement angle or the court case angle, they use the searches that you made in your surgery, all these famous cases of people killing their spouses. And right before they did it, they Googled how to hide a body or how to kill someone quietly or something like this. Are we going to see prompts as the next iteration of what comes up in court around how you gained access to harmful information? I always like to say with great power comes great responsibility and AI can't escape that. But talking about AI, what is this VANA AI and does it have anything to do with VANA White and Wheel of Fortune? Absolutely. It was a Wheel of Fortune hack. It's interesting. This is a little different than the skeleton key. I think the skeleton key, the way that people are thinking of it, it's kind of an impromptu escape. So the damage would be you'd be getting a response, you'd be getting information inside the prompt that could be potentially dangerous. This one is different in that it exposes a remote code execution. So you're essentially escaping out of the AI. And actually on the last session, we talked about how AI is made up of kind of multiple modules in some cases. And last time we talked about a hugging face and the pickle module that is one of the things that makes AI functions work. And if you have a malicious pickle, you can escape the AI prompt. And this is another one of these vulnerabilities. And essentially, it exploits the ability to kind of do a SQL hack. Essentially, there's a way to craft a SQL select statement so that it prints an output. And if they use that in conjunction with another library that Vanna uses, and just to kind of summarize, Vanna does text to SQL. So the idea, you put in natural language and it'll do the SQL prompt for you. But Vanna also can generate the response in a graph. So it'll show you a graph. And to do that, it uses a library called Plotly. And essentially, if you craft the SQL statement in a way that it prints a command, that gets passed to Plotly and Plotly will execute that on the host it's running on. So it reminds me a lot of a SQL injection, but it's a bit more abstract. And this is kind of where you can craft an AI prompt that actually goes outside the boundaries of the AI prompt. Hopefully, I'm making some sense there. It was really interesting. By the way, it was with Tower, there was a really great write up on how this worked. And I'll find that and put it in the chat. But really, really interesting stuff. Yeah. And it sounds like a SQL injection vulnerability, but with like a layer of abstraction to it because of what gets called by the SQL injection. So it's interesting to see these kind of OWASP top 10 get applied to AI, whether it's on the language model or on the co-pilot side as a lot of the same things that work on non-AI powered applications from an exploitation or vulnerability standpoint are present in these AI based applications as well. Now in preparing for this one, did you say something about a malicious pickle, David? I did. Last time I asked the audience, what would be a better band name, malicious pickle or pickle malicious. And I did want to thank everybody for the input. So one night only. Yeah. Well, that's probably not the only thing that we have to talk about, getting ourselves into a malicious pickle or naming the AI based band that we'll probably never perform with. There is this Elvis act. And I give a lot of credit, Tennessee does tend to lead the way for artists and for musicians around protecting copyrighted work. And musicians are definitely celebrating this victory against the robots as Tennessee has impassed the ensuring likeness voice and image security or Elvis act. I love that name. Yeah, I know. Right. Especially with all that title fraud stuff going on with the Elvis estate. It's very timely. So what it does is it expands personal rights law to include protections for songwriters, performers, and others in the music industry. It protects their voice, their voice from the misuse of artificial intelligence. So really it calls out voice as another form of protected art. And really the goal of the legislation is to continue to protect artists whose likeness has been cloned or reused by AI tools for reproduction, obviously without the striking a deal or paying for the license to use that person's likeness. So it's great to see at least at a state level that we see protections for artists from their work being reproduced or cloned or reused by AI. Yeah. I would really rather imagine a future where AI is able to do our TPS reports or do the dishes and we can do the art. We can make the music rather than having the AI do the music in the arts. Yeah. And we had an audience member chime in and say, isn't that a bit of a double statement? Yes, we're trying to cleverly use alliteration from time to time on the show. And so we call this segment Vulnerable Vulnerabilities just to make sure you know what we're talking about. Now, David, what is this first vulnerability with OpenSSH? So this is called regression. And apparently there was a vulnerability a long time ago, and we've since had a regression. So this old flaw was patched a while back, but it has reappeared in versions 8.5 P1 all the way up to 9.7 P1. And apparently it affects at least any 32-bit Linux systems running glibc. And actually, I think it's probably going to extend more than that. But the way it works is it essentially creates a race condition. So an attacker can try to connect to SSH, but they don't finish the authentication. And they do that over and over and over again. And apparently what happens is it calls a SIGALARM function in an unsafe way. It's kind of, they call it async signal safe or not. And I think to oversimplify this, it's essentially like when you're sending signals in an unsafe way, it's kind of like sending two things to your printer at the same time and having it try to keep printing at the same time. It kind of overlaps the output. But instead of going to paper, it's going into RAM. And if the attacker does it just right, they can manage to get something that can be remotely executed or executable code in that address space. So it's POC code. It seems like it's a little bit hard to exploit. And really, if somebody is trying to do this, it looks like it takes an average of six to eight hours to do all those sessions and kind of time them out and have that condition happen. So it should be noisy, kind of a POC code, but patch SSH. Not the first one we've seen. I think the interesting one here is that they have to flood the table. It kind of reminds me of a bit like a denial of service combined with a buffer overflow and that you're trying to flood the connection table. And then eventually, one is going to be triggered the signal alarm, which runs an unsecured library that allows you to put more code in it. Yet again, we see kind of the old but trusted vulnerability shine through or get found in other systems. Now, that's not the only repeat one there. Go ahead, David. I was just going to say, I think that's a really great way to put it. It's kind of like an old sin flood, except it's poisoning the well behind it. Combined with poisoning the ARP table after the sin flood, right? We were talking about that 10 or 15 years ago. Now, that's not the only sequel that we're going to talk about today, though. Hackers have found another flaw in Moovit, this time to bypass authentication. It feels like over a year ago, we were talking about Moovit and the latest Moovit vulnerability. And so Moovit transfer, this is a managed file transfer solution, has a new vulnerability CPE 2024-5806. This allows attackers to bypass the authentication in the SFTP module, which is responsible for the secure file transfers over Moovit using SSH. According to Census, there's a company that scans the open internet. There are at least 2,700 Moovit devices available on the open internet to be exploited and patches are available. Combine that with talking to Shadow Server Foundation, they've actually found that attackers are actively exploiting this Moovit vulnerability. So if you're here joining us on the show today and you haven't patched this yet, you probably should. Yeah, this is another scary one and some good write-ups about how this works to vulnerability in SFTP. Well, not in SFTP, but in the implementation of it. Yeah, in the implementation of it that allows you to take over and really kind of exfiltrate data from Moovit yet again. Now, what is this polyfill? Does this have anything to do with the stuff in those pillows you get at the carnival or am I missing out on something here, David? This is an installation attack. You're absolutely right. Now, I wasn't aware about this, but apparently polyfills are libraries that help to overcome differences or deficiencies between web browsers. So essentially, you can insert these libraries so that a web browser can do the things you want it to do. Now, apparently polyfill.io was a place that stored all these libraries and a lot of different websites would call the library from polyfill.io. Now, if I'm reading this right, that got taken over and these libraries became infested with malware. And so really people's browsers would call these libraries and then be running malicious code on their hosts. So the recommendation is remove any references on your website to polyfill.io and you can replace those with different polyfill repositories in Cloudflare or Fastly. And I think how this had happened, right, was the polyfill developers had probably mistakenly, I mean, obviously we think it's mistakenly, it wasn't intentionally malicious, put some keys, their Cloudflare keys in a publicly accessible, you know, just expose them in a publicly accessible way. And then attackers were able to use those keys, remove the references of, you know, pointing back to polyfill, pointed instead at Cloudflare, Fastly references to the malicious code that then gets run on everyone that visits or intends to do it via polyfill. So there's like some, I mean, very potentially broad impact. I mean, tens of millions or, you know, even dozens of millions of websites could have been impacted by this. Yeah, this is pretty big damage. And definitely I would mitigate that. Yeah, somebody said, I know we block polyfill.io now. And I think that it's being blocked by a DNS in a couple of different ways too, but definitely would want to remove the references to it in your sites. Well, let's jump into our last segment, the dangers. Here, we usually talk about attackers, techniques, their protocols, breaches that might've happened, or even just, you know, talking about the same thing yet again. I feel like Snowflake is, I mean, three episodes in a row, we're still talking about the fallout from the blizzard that was the attack on Snowflake and its customers. The latest victim being AT&T, one of the largest cell phone carriers in the world said that they lost a lot of data, including call logs, SMS messages for over 25 million customers. And in addition to that, Mandiant also has come out and said that they see a connection between the attacker group, they think purported the attack on Snowflake and its customers, UNC5537 and Scattered Spider. This because around 10 organizations of the 160 or so that got breached by Snowflake have been contacted in order to pay a ransom in order to not have additional data be leaked online. Some of those including companies like Ticketmaster and Neiman Marcus. And for Ticketmaster, I think the number so far between 40,000 and 60,000 tickets had been fraudulently printed and reused, which actually caused real harm to people, you know, concert goers and event goers around the world. Yeah, this is, by the way, I see what you did there with the blizzard, right, and quite a bit of fallout on this one. And, you know, I think it's kind of important to kind of review those steps, right, with the MFA and kind of all the tips that we've put on our, you know, before on how to monitor the stuff. Yeah, I think it's quite simple. When we think about like a SaaS application or, you know, database service daily as a service like Snowflake that allows connections from the outside, the way that this attack happened was quite trivial, in my opinion. People reuse their usernames and passwords. It's just a fact. If you reuse your username and password, or one of your employees did, and an Info Stealer malware was able to pick up their login credentials to Snowflake, and your organization didn't have multi-factor authentication or trusted network access blocks in place for your Snowflake, you were vulnerable to a simple password reuse attack. And that's what happened. You know, hundreds of Snowflake customers got targeted by this. They didn't have MFA enabled on those accounts. They didn't have things set up in a way that only their organization's IPs could get to Snowflake. And a lot of sensitive data got leaked onto the internet. And we're only still learning just today about AT&T being included in all of that. Yeah. And that looks like there's a lot of people in that breach, right? Like all their wireless customers as well. Call logs, SMS messages, millions and millions of consumers. Now, that wasn't the only little bit. It looks like Lockbit is, you know, chomping at the bit to do a little bit more in the ransomware gang as well. Yeah, this one was interesting. A little bit of a head scratcher. Apparently in June, Lockbit had claimed to have breached the Federal Reserve and threatened to release, you know, 33 terabytes of data or some of that. It looked like, I think the Fed, you know, offered to pay it. Yeah, 50 grand for the data. And I had even said, like, what's going on here? Why do they value this so little when the last time we talked about this? But maybe it's because it wasn't their data. Yeah, it turned out after the data was kind of released, that analysts determined it was stolen from Evolve Bank and Trust. And they confirmed that, yep, this is their data. Apparently an employee clicked on the malicious link back in May or so. And so this is where that data came from. That's where the exposure was, kind of a run of the mill ransomware attack that was not really concerning the Federal Reserve. Nonetheless, Lockbit has been really busy, right? They're very active and they were associated with an attack on a Croatia hospital recently as well. Well, I think that pretty much wraps up everything we had planned on going through today. So let's check out and see if anything came in in the chat or anything came in via the Q&A that we need to cover. I think just a couple of questions. Should polypill.io be blocked at the perimeter as one of them, David? And then one of our other audience members wants to know if we know who was behind the polyfill attack. Yeah. And I know that that was something that looks like we said we would to talk about who was behind that. What I was reading on that is that, as you said, that what was really behind it was kind of some keys that were put in an open GitHub repository by mistake. But it also looks like there was some association with a Chinese actor, right? Did I read that correctly from your notes? Yeah. And I'm not sure we know exactly who it is yet. I think we have some suspects from Chinese APT groups. But if you put secret and keys in a public domain, you probably should expect them to get misused or abused, especially if they're still valid. We hope that you guys enjoyed our show today. It is made possible by you, our audience. So we super appreciate you sticking around. We hope that you'll leave us some feedback, and we look forward to seeing you on our next episode of State of Cybercrime.
