| ||||||
Description: The EU aborted their Chat Control vote knowing it would fail. Salesforce says it's not going to pay; customer data is released. Hackers claim Discord breach netted 70,000 government IDs. Microsoft to move GitHub to Azure. What could possibly go wrong? New California law allows universal data sharing opt-out. OpenAI reports that it's blocking foreign abuse. Who cares? IE Mode refuses to die, so Microsoft is burying it deeper. The massive mess created by Texas legislation SB2420. The BreachForums website gets a makeover. 100,000 strong global botnet attacking U.S. RDP services. UI experts weigh in on Apple's iOS 26 user-interface. 330,000 publicly exposed Redis servers are RCE-vulnerable.
High quality (64 kbps) mp3 audio file URL: http://media.GRC.com/sn/SN-1047.mp3 |
SHOW TEASE: It's time for Security Now!. Steve Gibson is here with good news on the EU Chat Control vote. We'll talk about that Discord breach. Salesforce says we're not going to pay. And then there is a very bad bug in 330,000 publicly exposed Redis servers. It's got a CVSS of 10. Stay tuned. All will be revealed next on Security Now!.
| Leo Laporte: This is Security Now! with Steve Gibson, Episode 1047, recorded Tuesday, October 14th, 2025: RediShell's CVSS 10.0. It's time for Security Now!, the show where we cover the latest in security, privacy, computing, pretty much anything Steve Gibson wants to talk about because he's the Man of the Hour. Hello, Mr. G. |
| Steve Gibson: And I do try to largely keep us on topic as much as possible, although... |
| Leo: No, I'm the one who distracts. I'm the distracter. |
| Steve: There are some times we wander a little bit off the range. But I always get feedback from our listeners saying, hey, that was fun, or that was interesting. Or, like, with, you know, like sci-fi stuff. Some of the best sci-fi series that I've read have come from listeners saying, hey, try this. |
| Leo: That's true. That's true, yeah. |
| Steve: Also some of the worst. But that's just the nature of - that's just the nature of the game. So the topic I chose for today is just one of a bunch of interesting news that we're going to cover. And, you know, it came at the end. So, okay, that's what we're going to talk about when we wrap things up. And that's an arguably really worrisome remote code execution exploit in all Redis servers, which have been around for the last - the exploit has been around for the last 13 years. It's in Lua. |
| Leo: We use Redis. We use Redis for caching our website. |
| Steve: I do. Even I have a Redis server at GRC. So anyway, it's got the - it has earned itself the difficult-to-obtain 10.0 CVSS score. |
| Leo: Oh, boy. |
| Steve: And we're going to finish by talking about that. But we've got news on the EU's Chat Control vote, which we know is happening on the 14th of October, which is today, for Episode 1047 of Security Now!. Salesforce says it's not going to pay any ransoms, and we're starting to see data leakage. Hackers claim that Discord lost control of tens of thousands of government IDs. We'll look at that. Microsoft plans to move GitHub to Azure, which is where we roll out our "What could possibly go wrong?" with that. Actually, they've tried a few times and then aborted the effort because it's not going to be easy. We've got a new California law that our governor, Gavin Newsom, signed last week that should help things. We'll talk about that. Open AI blocking foreign abuse. Does anyone care? IE, there's actually some news about IE mode, which believe it or not refuses to die. We've got, okay, we're going to spend a little bit of time on a Texas law that's going into effect on January 1st. Tim Cook reportedly phoned Greg Abbott and said please, please don't let this happen. Veto this, or at least amend it because it's really bad. Well, Greg, you know, I don't think he has much sympathy for anything Tim Cook has to say, so we're getting this in 10 weeks. And, oh, boy, is it going to be a problem. Also, BreachForum, which we showed last the BreachForum's web page. Remember that was with the extortion demand from Salesforce. Well, that site has received a makeover, which we'll be looking at today. Also we've got - oh, boy - a 100,000 strong global botnet attacking U.S.-based RDP services. And again, what could possibly go wrong there? I did see, one of our listeners sent me a UI expert's weigh-in on Apple's iOS 26 user interface. I did talk a little bit about going off topic. Well, I just have to indulge myself here. |
| Leo: You don't like it one bit, I know. |
| Steve: Oh ho. |
| Leo: Liquid Glass is not... |
| Steve: And it turns out I'm in good company, yes. |
| Leo: Yeah. |
| Steve: Anyway, so that, the Redis servers, we've got a Picture of the Week. And I think maybe, Leo, this time we've got a good podcast. |
| Leo: For once. |
| Steve: Yeah. I think, you know... |
| Leo: It's about damn time. |
| Steve: Maybe this will be worthwhile. |
| Leo: I should mention this is also the last Patch Tuesday for Windows 10. Today... |
| Steve: That's right. |
| Leo: The End of Life. |
| Steve: Ho ho ho. |
| Leo: Ho ho ho for Windows 10. Ho ho ho. |
| Steve: Except, of course, if you click your heels twice and look at the moon. |
| Leo: Right. Yes. |
| Steve: Then Microsoft says okay, fine. |
| Leo: I, well, before we get to the Picture of the Week, because I know that's imminent. And now I shall turn on my extra camera so that we can see the Picture of the Week. |
| Steve: This was just - this was very clever. The goal is to prevent dementia patients from leaving the hospital, which has an elevator. |
| Leo: Okay. |
| Steve: So how do you... |
| Leo: My mom is in a memory care ward, and that's exactly right. They have a code panel in the elevator; right. |
| Steve: Right. And so above this code it says: For access to elevator, One must ask the Desk, To get the new code. Seven times to remember. Starry blue skies ahead. |
| Leo: Whoa. That's a code. |
| Steve: The code is 4127, the first word of the first four sentences. |
| Leo: And they've capitalized each of them, too, to make it a little bit more obvious. |
| Steve: Yup. For access to elevator. |
| Leo: But if you've got dementia, you're probably not going to be able to... |
| Steve: Uh-huh. |
| Leo: Yeah. |
| Steve: Well, and you wouldn't know. No one would tell you. |
| Leo: Right. |
| Steve: So here is the code, published above the keypad. For access to elevator, One must ask the desk, To get the new code. Seven times to remember. And so 4127. So everybody who - all of the staff who... |
| Leo: This is kind of brilliant. |
| Steve: Isn't it wonderful? Yeah. |
| Leo: Yeah. |
| Steve: And nobody would ever think - they would think, oh, I'd better go to the desk and ask for the new code. |
| Leo: You know what, I'm stupid enough, that's exactly what I would have done. Oh, that's clever. I like it. I like it. Yeah, in order to get up to see my mom, I have to get them to come and open the door and enter the code and bring me up, and then I have to do the same to get down. And I wish they had something like this. But they don't. I have to have help every time. That's all right. Yeah. |
| Steve: Okay. So... |
| Leo: Good news. |
| Steve: The much-anticipated, yes, good news. The much-anticipated vote among EU member countries, originally slated for today, October 14th, was called off once it became clear that the vote for the adoption of the controversial measure would fail. Thankfully, remember last week we reported that Germany seemed to be waffling a little bit, although the Netherlands said they were a firm no. Turns out Germany made up their mind, also signaling a firm no. I learned of this from a blurb on the Risky Business newsletter, which offered some additional detail. They wrote: "The European Union has scrapped the vote on Chat Control, proposed legislation that would have mandated tech companies to break their encryption to scan content for child abuse materials. The project was supposed to be put to a vote on Tuesday, October 14, during a meeting of interior ministers of EU member states. Denmark, which currently holds the EU presidency and was backing the legislation, scrapped the vote, according to reports on Austrian and German media. Danish officials scrapped the vote after failing to gather the necessary votes to pass the legislation and advance it to the EU Parliament. Only 12 of the bloc's 27 members publicly backed the proposal, with nine against, and the rest undecided. The final blow to Chat Control came over the past two weeks when both the Netherlands and Germany publicly opposed it." |
| Leo: I love what the - oh, go ahead, you're going to say it. Here's the... |
| Steve: Yeah. "Germany's Justice Minister, Dr. Stefanie Hubig, went out of her way to describe Chat Control as a 'taboo for the rule of law,' arguing that the fight against child pornography does not justify removing everyone's right to privacy." |
| Leo: She used the phrase "suspicionless Chat Control." And I think that's key because of course it was for everyone, not just... |
| Steve: Yes. That's really - yes. |
| Leo: Yeah, yeah. |
| Steve: Right. Well, I mean, and that's what you have to do. If you're going to find people you don't know... |
| Leo: You've got to scan everybody. |
| Steve: ...sharing illegal content, everybody has - exactly. It's like if a website says you have to be an adult, well, then, everybody has to prove their age. You know, not just young people. Because you don't know. So anyway, the Risky Business newsletter said: "The law has seen the usual mass opposition from privacy groups, such as the EFF, but also from the tech sector, too, with over 40 major EU tech companies signing an open letter to EU officials. Signatories described Chat Control as" - and this is really interesting. I'm going to share this letter because it also contains some interesting stuff - "a blessing for U.S. and Chinese companies," since EU users will migrate to products that respect their privacy and ignore Chat Control. "The Chat Control opposition also received major help from a Danish programmer, whose Fight Chat Control website allowed Europeans to mass-mail their representatives and urge them to vote against. According to a Politico Europe report, the website had driven so much traffic that it 'broke' the inboxes of EU members of Parliament over the past few weeks." And you can imagine that might get their attention. So anyway, it's one thing to be living within a government that declares itself to be a democracy. But it's truly wonderful to see a movement where the voices, opinions, and feelings of that democracy's subjects can be and are heard. So I checked out that open letter, as I mentioned, to the EU Parliament that was signed by 40 major European Union companies. Since this is one of the major issues of our time, I want to share that letter. It was addressed to "Open letter to EU Member States on the proposed CSA regulation," and it read - so this is from the 40, you know, co-signed by the 40 top tech companies in the EU. "Dear Ministers and Ambassadors of EU Member States. We, the undersigned European enterprises, as well as the European DIGITAL SME Alliance" - you know, small, medium enterprise alliance - "which represents more than 45,000 digital Small and Medium Enterprises across Europe, write to you with deep concern regarding the proposed Regulation on Child Sexual Abuse. Protecting children and ensuring that everyone is safe on our services and on the Internet in general is at the core of our mission as privacy-focused companies. We see privacy as a fundamental right, one that underpins trust, security, and freedom online for adults and children alike. "However, we are convinced that the current approach followed by the Danish Presidency would not only make the Internet less safe for everyone, but also undermine one of the EU's most important strategic goals: progressing toward higher levels of digital sovereignty. Digital sovereignty is Europe's strategic future. In an increasingly unstable world, Europe needs to be able to develop and control its own secure digital infrastructure, services, and technologies in line with European values. The only way to mitigate these risks is to empower innovative European technology providers. "Digital sovereignty matters for two key reasons. First, economic independence: Europe's digital future depends on the competitiveness of its own businesses. But forcing European services to undermine their security standards by scanning all messages, even encrypted ones, using client-side scanning would undermine users' safety online, and go against Europe's high data protection standards. Therefore European users - individuals and businesses alike - and global customers will lose trust in our services and turn to foreign providers. This will make Europe even more dependent on American and Chinese tech giants that currently do not respect our rules, undermining the bloc's ability to compete. "And second, national security: Encryption is essential for national security. Mandating what would essentially amount to backdoors or other scanning technologies inevitably creates vulnerabilities that can and will be exploited by hostile state actors and criminals. For this exact reason, governments exempted themselves from the proposed CSA scanning obligations. Nevertheless, a lot of sensitive information from businesses, politicians, and citizens will be at risk should the CSA Regulation move forward. It will weaken Europe's ability to protect its critical infrastructure, its companies, and its people. "The CSA Regulation will undermine trust in European businesses. Trust is Europe's competitive advantage. Thanks to the GDPR and Europe's strong data protection framework, European companies have built services that users worldwide rely on for data protection, security, and integrity. This reputation is hard-earned and gives European-based services a unique selling point which Big Tech monopolies will never be able to match. This is one of the few, if not the only, competitive advantage Europe has over the U.S. and China in the tech sector; but the CSA Regulation risks reversing this success. "This legal text would undermine European ethical and privacy-first services by forcing them to weaken the very security guarantees that differentiate European businesses internationally. This is particularly problematic in a context where the U.S. administration explicitly forbids its companies to weaken encryption, even if mandated to do so by EU law. Ultimately, the CSA Regulation will be a blessing for U.S. and Chinese companies, as it will make Europe kill its only competitive advantage and open even wider the doors to Big Tech. "The EU has committed itself to strengthening cybersecurity through measures such as NIS2, the Cyber Resilience Act, and the Cybersecurity Act. These policies recognize encryption as essential to Europe's digital independence. The CSA Regulation, however, must not undermine these achievements by effectively mandating systemic vulnerabilities. It is incoherent for Europe to invest in cybersecurity with one hand, while legislating against it with the other. European Small and Medium-sized Enterprises (SMEs) would be hit hardest if obliged to implement client-side scanning. Unlike large technology corporations, SMEs often do not have the financial and technical resources to develop and maintain intrusive surveillance mechanisms, meaning compliance would impose prohibitive costs or force market exit. "Moreover, many SMEs build their unique market position on offering the highest levels of data protection and privacy; which particularly in Europe is a decisive factor for many to choose their products over the counterparts of Big Tech. Mandating client-side scanning would undermine this core value proposition for many European companies. This will suffocate European innovation and cement the dominance of foreign providers. Instead of building a vibrant, independent digital ecosystem, Europe risks legislating its own companies out of the market. For these reasons, we call on you to" - and they have five points: "Reject measures that would force the implementation of client-side scanning, backdoors, or mass surveillance of private communications, such as we currently see in the Danish proposal for a Council position on the CSA Regulation. "Second, protect encryption to strengthen European cybersecurity and digital sovereignty. Third, preserve the trust that European businesses have built internationally. Fourth, ensure that EU regulation strengthens, rather than undermines, the competitiveness of European SMEs. And pursue child protection measures that are effective, proportionate, and compatible with Europe's strategic goal of digital sovereignty. "Digital sovereignty, they finish, "cannot be achieved if Europe undermines the security and integrity of its own businesses by mandating client-side scanning or other similar tools or methodologies designed to scan encrypted environments, which technologists have once again confirmed cannot be done without weakening or undermining encryption. To lead in the global digital economy, the EU must protect privacy, trust, and encryption." So that's sort of the business side, you know, business-centric view of what this meant for the EU's businesses. And I wanted to share that because we don't want this to rear its ugly head again. You know, I mean, this - it's hard to put this thing to bed once and for all. We keep, you know, smacking it down, and it pops up because, you know, legislators say, well, but what about the children? And that gets everybody all riled up again. So hopefully this is, you know, having this come to as much a head as it has, and really getting everyone's attention, notice that they weren't breaking encryption, they figured out, okay, we're not going to do that, we're going to do client-side scanning before and after encryption, but leave that alone, you know, trying to come up with a way of shimming their scanning into the system. And even that didn't go. The idea being, no, sorry, we're just not - we're not going to become a surveillance state. Doing that would, you know, we're thinking of companies like Threema, right, that are EU-based and couldn't do what they do. I mean it would just kill the Threema Messenger completely to have to operate under a Chat Control legislation. So one line stood out for me in that letter that I thought was interesting. It said: "This is particularly problematic in a context where the U.S. administration explicitly forbids its companies to weaken encryption, even if mandated to do so by EU law." Even though it wasn't the EU, you know, that feels like a response to the UK's order, right, to Apple, which as we know was loudly and publicly rebuffed when Tulsi Gabbard, the U.S. Director of National Intelligence, tweeted on X that, as a result of the U.S. administration's closely working with the UK, Americans' private data would remain private, and our constitutional rights and civil liberties would be protected." You know, she stated in that tweet that, "As a result, the UK has agreed to drop its mandate for Apple to provide a "backdoor" that would have enabled access to the protected encrypted data of American citizens and encroached on our civil liberties." So you know, unfortunately, as we know, it's now believed that the UK has since issued another "order" to Apple, requiring it to allow the government access to the iCloud data of its own citizens, not everyone everywhere. And so we're going to see how that plays out. Overall, though, I think that this Open Letter made a very good point about the fundamental competitive disadvantage that the entire EU business sector would face if its companies were forced to abide by a clearly surveillance-oriented privacy-invading law. They're right about, you know, what the rest of the world would do in response. So anyway, that bullet got dodged. We still have this unknown order in the UK. And of course the UK is still strong on enforcing age restrictions. So we'll see how those things continue to play out. |
| Leo: Yeah, you saw, well, probably going to talk about it. But you saw what California did with that. |
| Steve: Yeah. |
| Leo: Yeah. |
| Steve: Yeah. Okay. So Salesforce said, unh-unh, it's not going to pay. And this is the extortion demand threatening a billion, in fact it was 984 million, you know, just shy of a billion records belonging to, it's believed to be 39 of its customers whose networks were all breached as a consequence of their relationship with Salesforce. So as I said, last week we showed the ransom demand posted to BreachForums by the Scattered LAPSUS$ Hunters group. Salesforce's public response was widely covered in the tech press. Here's what Dan Goodin writing for Ars Technica said. He wrote: "Salesforce says it's refusing to pay an extortion demand made by a crime syndicate that claims to have stolen roughly one billion records from dozens of Salesforce customers. Google's Mandiant group said in June that the threat group making the demands began their campaign in May, when they made voice calls to organizations storing data on the Salesforce platform. The English-speaking callers would provide a pretense that necessitated the target connect an attacker-controlled app" - we know now that that was an OAuth-based authentication app - "to their Salesforce portal." Dan wrote: "Amazingly, but not surprisingly, many of the people who received the calls complied. "The threat group behind the campaign is calling itself Scattered LAPSUS$ Hunters, a mash-up of three prolific data-extortion actors: Scattered Spider, LAPSUS$, and ShinyHunters. Mandiant, meanwhile, tracks the group as UNC6040 because the researchers so far have been unable to positively identify the connections. Earlier this month, the group created a website that named Toyota, FedEx, and 37 other Salesforce customers whose data was stolen in the campaign. In all, the number of records recovered, Scattered LAPSUS$ Hunters claimed, was '989.45 million, approximately a billion.' The site called on Salesforce to begin negotiations for a ransom amount, 'or all your customers' data will be leaked.' The site went on to say: 'Nobody else will have to pay us, if you pay, Salesforce, Inc.' The site said the deadline for payment was last Friday." "In an email Wednesday, a Salesforce representative said the company is spurning the demand. The representative wrote: 'I can confirm Salesforce will not engage, negotiate with, or pay any extortion demand.' The confirmation came a day after Bloomberg reported that Salesforce told customers in an email that it won't pay the ransom. The email went on to say that Salesforce had received 'credible threat intelligence' indicating a group known as ShinyHunters planned to publish data stolen in the series of attacks on customers' Salesforce portals. "The refusal comes amid a continuing explosion in the number of ransomware attacks on organizations around the world. The reason these breaches keep occurring is the hefty sums the attackers receive in return for decrypting encrypted data and/or promising not to publish stolen data online. Security firm DeepStrike estimated that global ransom payments totaled $813 million last year, that being down from $1.1 billion in 2023." So $1.1 billion in ransom payments in 2023, 813 million in 2024. Dan wrote: "The group that breached drug distributor Cencora alone received a whopping $75 million in ransomware payments, Bloomberg reported, citing unnamed people familiar with the matter." So one payout of 75 million for the breached drug distributor Cencora's ransom payment. No wonder these guys, you know, stay at it. "Making ransomware payments," he finishes, "has come increasingly under fire by security experts who say the payments reward the bad actors responsible and only encourage them to pursue more riches." Right. "Independent researcher Kevin Beaumont wrote on Mastodon, referring to the UK's National Crime Agency: 'Corporations should not be directly funding organized crime with the support of the National Crime Agency and their insurance. Break the cycle.' Beaumont said in an interview, while the NCA publicly recommends against paying ransoms, multiple organizations he's talked to report having NCA members present during ransom negotiations. On Mastodon, Kevin warned that payments pose threats to broader security, writing: 'It's becoming a real mess to defend against this stuff in the trenches, let me tell you. I'm concerned about where this is going.'" So I imagine that Kevin is worried because there's no end in sight. The bad guys have figured out that the human factor is reliably the weakest link in the enterprise security chain. This gets the attackers inside the enterprise, and enterprise networks are not currently hardened against abuse from the inside. Among the approximately 39 companies believed to have been breached due to their customer relationship with Salesforce, Salesloft, and Drift, is the Australian airline Qantas - that we talked about last week with its looney injunction against anyone republishing their data after it's leaked on the Dark Web, like those guys are going to care about an injunction, and also reportedly the Australian Telco Telstra, although Telstra is denying the Cyber Daily report of their breach. Unfortunately, these ransomware groups are compelled to release the data they have obtained once they've made such a public spectacle of their data breach. Right? You know, they can't ever be seen to be bluffing or making empty threats, or they'll lose their ability to threaten. So I imagine that next week we'll be seeing stories of nearly one billion records of data from around 39 major Salesforce customers being leaked online. The bad guys need to leak the data so that their next victim will take them seriously. Oh, Leo. What a world. But we have some good news, and it comes from one of our sponsors. |
| Leo: That I can definitely provide you with. Can't help you with the other stuff though, unfortunately. It's unbelievable, I swear. We live in difficult times. |
| Steve: Yup. And after this we're going to talk about the extent of Discord's horrible breach. |
| Leo: Yeah. And of course since we use Discord for our Club, I read that story with great interest. I have never been asked for my government ID from Discord. But I asked in our Club, and a number of our Club members have. Mostly outside the U.S. |
| Steve: And it's when their estimate of your age needs to be challenged. So they come back, and they say, "We think you're a teenager." |
| Leo: Yeah. |
| Steve: And it's like, you know... |
| Leo: You talk a lot about Pokmon Go. I don't know. |
| Steve: That's right. Actually, you know, we looked at your discourse on Discord, and it looks a little junior. |
| Leo: Yeah, there's no question I'm a kid. Back to you, Steve. |
| Steve: Okay. So Hackers are claiming that the Discord breach exposed the data of 5.5 million users. |
| Leo: Ooh. I didn't know it was that many. Ooh. |
| Steve: Yeah. But not the government IDs. That's a subset. |
| Leo: Ah, okay, okay. |
| Steve: So since my initial reporting of the Discord breach last week, additional troubling details have surfaced. BleepingComputer reports this significant breach at Discord, though the attacker's and Discord numbers don't agree. BleepingComputer reported: "Discord says they will not be paying threat actors who claim to have stolen the data of 5.5 million unique users from the company's Zendesk support system instance. The stolen data includes government IDs and partial payment information for some people. The company is also pushing back on claims that 2.1 million photos of government IDs were disclosed in the breach, stating that approximately" - as if this is not, I mean, not much better - "70,000 users had their government ID photos exposed." So folks, we need a better solution for proving age. Wow. |
| Leo: Yeah. This shows exactly why, yeah. |
| Steve: Yes. They said: "While the attackers claim the breach occurred through Discord's Zendesk support instance, the company has not confirmed this and only described it as involving a third-party service" - so they're being coy - "used for customer support." Gee, I wonder what that could be. "Discord told BleepingComputer in a statement: "First, as stated in our blog post, this was not a breach of Discord" - okay, who cares - "but rather a third-party service we use to support our customer service efforts. Second, the numbers being shared are incorrect and part of an attempt to extort a payment from Discord. Of the accounts impacted globally, we have identified approximately 70,000 users that may have had government-ID photos exposed." Uh-huh. That's like saying, well, this zero-day exploit may be attacked - "which our vendor," they wrote, "used to review age-related appeals. Third, we will not reward those responsible for their illegal actions. "In a conversation," writes BleepingComputer, "with the hackers, BleepingComputer was told that Discord is not being transparent." So Bleeping Computer talked to the hackers, and the hackers said Discord is not being transparent about the severity of the breach, stating that they stole 1.6TB of data from the company's Zendesk instance. "According to the threat actor, they gained access to Discord's Zendesk instance for 58 hours beginning on, you know, because it takes a while to exfiltrate 1.6TB of data. They gained access for 58 hours, beginning on September 20th, 2025. However, the attackers say the breach did not stem from a vulnerability or breach of Zendesk, but rather from a compromised account belonging to a support agent employed through an outsourced Business Process Outsourcing" - that's our new term of art, a BPO, Business Process Outsourcing - "provider used by Discord. As many companies have outsourced their support and IT help desks to BPOs, they have become a popular target for attackers to gain access to downstream customer environments. "The hackers allege that Discord's internal Zendesk instance gave them access to a support application, known as Zenbar, that allowed them to perform various support-related tasks, such as disabling multifactor authentication and looking up users' phone numbers and email addresses. Using access to Discord's support platform, the attackers claimed to have stolen 1.6TB of data, including around 1.5TB of ticket attachments and over 100GB of ticket transcripts. "The hackers say this consisted of roughly 8.4 million tickets affecting 5.5 million unique users. I'll just mention that all those numbers track. They all make sense in terms of, like, the ratios that you would expect to see. And that about 580,000 users contained some sort of payment information. The threat actors themselves acknowledged to BleepingComputer that they are unsure how many government IDs were stolen, but they believe it's more than 70,000, as they say there were approximately 521,000 age-verification tickets." So more than half a million age verification tickets among the 8.4 million tickets total. "The threat actors also shared a sample of the stolen user data, which can include a wide variety of information, including email addresses, Discord usernames and IDs, phone numbers, partial payment information, date of birth, multi-factor authentication-related information, suspicious activity levels, and other internal info. "The payment information for some users was allegedly retrievable through Zendesk integrations with Discord's internal systems. These integrations reportedly allowed the attackers to perform millions of API queries to Discord's internal database via the Zendesk platform and retrieve further information. BleepingComputer could not independently verify the hackers' claims or the authenticity of the provided data samples. The hacker said the group demanded $5 million in ransom" - only five million - "later reducing it to $3.5 million, and engaged in a private negotiation with Discord between September 25th and October 2nd. "After Discord ceased communications and released a public statement about the incident, the attackers said they were 'extremely angry' and plan to leak the data publicly if an extortion demand is not paid. BleepingComputer contacted Discord with additional questions about these claims, including why they retained government IDs after completing age verification..." |
| Leo: That's the key. |
| Steve: Uh-huh, "...but did not receive answers beyond the above statement." So no one's going to shed a tear for angry extortionists whose $3.5 million payday fell through. Unfortunately, as I noted in the case of Salesforce, the attackers must now follow through with their threats. I would not want to have my own photo ID out on the Internet circulating among criminals. And Leo, it's interesting, in the details that we got thanks to BleepingComputer's pursuit of this, this is what we are increasingly seeing. We are seeing that automated back-end systems which publish an API are then being used by their clients or their customers in order to get the services. So like Discord's platform accesses Zendesk or vice versa. You know, they've got APIs going in both directions. "Which means that if - and in this case, this BPO guy, this Business Process Outsourced person, they got compromised, who knows, clicked on email, phishing, whatever. That allowed their credential, which allowed them to log into either Discord or Zendesk, to get them in. And then the bad guys were able to use basically the automated API cross-access in order to plumb the other services, using the API at high speed in order to obtain more data and create problems. "So basically what's happened is we've sort of - the enterprises that are establishing operational backends have, like, an underground private network which is data rich, and now bad guys are breaking into that, and then taking advantage of these APIs in order to suck out all of the data that is normally, you know, layers deep from the front end that users see. You know, convenient for those people who are doing it. But, boy, it magnifies the effect of a breach when one happens. And guess what, they're happening. And yeah, maybe half a million government IDs. And as you clued in on, and as we mentioned before, why are the age verification records being kept? |
| Leo: That's just lazy. That's just lazy. |
| Steve: Yes. Well, and it's also, it's data aggregation fever. |
| Leo: It's valuable, yeah, yeah. |
| Steve: I mean, it's like, oh, the more data we have, you know, who knows what we'll be able to do with this in the future. |
| Leo: Right. Right. |
| Steve: So why delete what might be of some value to us? Yikes. Okay. So I suppose it was only a matter of time before Microsoft would decide to move its GitHub property over to their own Azure cloud infrastructure. But the details behind the move will likely be of interest to many of our listeners. The publication The New Stack provided the background for this move. They wrote: "After acquiring GitHub in 2018, Microsoft mostly let the developer platform run autonomously. But in recent months, that's changed. With GitHub CEO Thomas Dohmke leaving the company this August, and GitHub being folded more deeply into Microsoft's organizational structure, GitHub lost that independence. Now, according to internal GitHub documents The New Stack has seen, the next step of this deeper integration into Microsoft structure is moving all of GitHub's infrastructure to Azure, even at the cost of delaying work on new features. In a message to GitHub's staff, CTO Vladimir Fedorov notes that GitHub is constrained on capacity in its Virginia data center. He writes: "It's existential for us to keep up with the demands of AI and Copilot." Well, of course, Leo. If you're going to have AI and Copilot, you've got to move to a facility that's big enough for that. He said: "Which are changing how people use GitHub. The plan," he writes, "is for GitHub to completely move out of its own data centers in 24 months. 'This means we have 18 months to execute, with a six-month buffer,' Fedorov's memo says. He acknowledges that since any migration of this scope will have to run in parallel on both the new and old infrastructure for at least six months, the team realistically needs to get this work done in the next 12 months," so during 2026. "To do so, he's asking GitHub's teams to focus on moving to Azure over virtually everything else. Fedorov wrote: 'We will be asking teams to delay feature work to focus on moving GitHub. We have a small opportunity window where we can delay feature work to focus, and we need to make that window as short as possible.' "While GitHub had previously started work on migrating parts of its service to Azure," they write, "our understanding is that these migrations have been halting and sometimes failed. There are some projects, like its data residency initiative, internally referred to as Project Proxima, that will allow GitHub enterprise users to store all of their code in Europe, that already solely use Azure's local cloud regions." Fedorov writes: "We have to do this. It's existential for GitHub to have the ability to scale to meet the demands of AI and Copilot, and Azure is our path forward. We have been incrementally using more Azure capacity in places like Actions, search, edge sites, and Proxima, but the time has come to go all-in on this move and finish it." The New Stack said: "GitHub has recently seen more outages, in part because its central data center in Virginia is resource-constrained and running into scaling issues. AI agents are part of the problem. But it's our understanding that some GitHub employees are concerned about this migration because GitHub's MySQL clusters, which form the backbone of the service and run on bare metal servers, won't easily make the move to Azure and lead to even more outages going forward. "In a statement, a GitHub spokesperson confirmed our reporting and told us that "GitHub is migrating to Azure over the next 24 months because we believe it's the right move for our community and our teams. We need to scale faster to meet the explosive growth in developer activity and AI-powered workflows, and our current infrastructure is hitting its limits. We're prioritizing this work now because it unlocks everything else. For us, availability is job one, and this migration ensures GitHub remains the fast, reliable platform developers depend on while positioning us to build more, ship more, and scale without limits. This is about ensuring GitHub can grow with its community, at the speed and scale the future demands. "For open source developers, having GitHub linked even closer to Microsoft and Azure may also be a problem; though for the most part, some of the recent outages and rate limits developers have been facing have been the bigger issue for the service. Microsoft has long been a good steward of GitHub's fortunes; but in the end, no good service can escape the internal politics of a giant machine like Microsoft, where executives will always want to increase the size of their fiefdoms." So to me, it makes sense for Microsoft, but it also sounds as though it's going to be more easily said than done. And the thing about unforeseen consequences is that they're unforeseen. |
| Leo: Right. |
| Steve: Yeah. Outages for any service such as GitHub, upon which so much depends, are going to be a big problem. You know? But no one sees another way. So I have the feeling that some future Security Now! podcasts will be reporting on the consequences of this move. And, boy, if moving to Azure gets screwed up from a security standpoint, that's going to be a big nightmare for GitHub because that's not something anyone wants to see happening. So I've been noting that the proper place for consumers to specify how they would like the Internet to treat them is their browser. That was what I loved so much about the original DNT, the "Do Not Track" beacon. With just the flip of a switch, just once, a user could configure their web browser to always append a DNT header to every Internet resource request; and, had anyone ever cared to honor that request, which of course was the big problem, that would have been their "one and done" prohibition against tracking. Because this broad concept has merit, the newer incarnation of DNT is GPC, the Global Privacy Control. And remember, globalprivacycontrol.org is a site you can go to, and right up at the top of the page you are notified whether your browser is broadcasting the GPC signal, saying no thank you. But even though the GPC signal has been around since its release, like quite a while, sorry, only today, only Brave, the DuckDuckGo, and Tor browsers are broadcasting that signal by default. Firefox since its release #95 has supported GPC, but it needs to be turned on. And of course I went over to globalprivacycontrol.org with Firefox and, yup, right up at the top I get a little green light saying "Your browser is GPC enabled. Sadly, and perhaps not surprisingly, there is no support for GPC from the various other Chromium-based browsers: Chrome, Edge, Vivaldi, and Opera. Anyone wishing to emit the GPC signal from any Chromium-based browser other than Brave will need to install an add-on. And there's also been no sign of GPC from Safari, which I find kind of surprising. Okay. So all of that makes news because of California's new legislation last Wednesday, which Gavin Newsom signed. The Record reported: "California Governor Gavin Newsom on Wednesday signed a bill which requires" - that's right, requires - "web browsers to make it easier for Californians to opt-out of allowing third parties to sell their data. The California Consumer Privacy Act, signed in 2018, gave Californians the right to send opt-out signals, but major browsers have not had to make opt-outs simple to use. The bill signed Wednesday requires browsers to set up an easy-to-find mechanism that lets Californians opt-out with the push of a button, instead of having to do so repeatedly when visiting individual websites. "Privacy and consumer rights activists have been nervously waiting for Newsom to sign the bill, which passed the California legislature on September 11th. This is the first law in the country of its kind. The governor vetoed a similar but broader bill last year which also applied to mobile operating systems. Matt Schwartz, a policy analyst at Consumer Reports, said: 'These signals are going to be available to millions more people, and it's going to be much easier for them to opt out.' "Until now," Schwartz said, "individuals who want to use a universal opt-out have had to download third-party browser extensions or use a privacy protective browser." You know, meaning Brave, DuckDuckGo, Tor, or Firefox, if you flip the switch on. "Other bills signed by Newsom on Wednesday also give Californians important data privacy rights. One of them requires social media companies to make it easy to cancel accounts and mandates that cancellation lead to full deletion of consumers' data. A second bolsters the state's Data Broker Registration Law by giving consumers more information about what personal data is collected by data brokers, and who can obtain it." So I did some additional research and found that this was measure "AB 566" relating to "Opt-Out Preference Signals." Unfortunately, it appears that we're not going to be getting it for another 14 months since the new law doesn't take effect until January 1st, 2027. But at that time, all web browsers will need to include functionality for Californians to send an opt-out preference signal to businesses they visit online through the browser. The law follows the California Privacy Protection Agency (CPPA) announcement of a joint investigative sweep with privacy enforcers in Colorado and Connecticut to investigate potential noncompliance with Global Privacy Control, the GPC signal. So at least we have some progress. Chromium browsers will need to get with the GPC plan, which just basically means the Chromium core is going to have to support it, as will Apple's Safari browser. And once we have GPC available, privacy enforcers will then be able to start investigating who is and who is not honoring the clear preference setting that will be sent to all browsers. As we saw, Do Not Track never got enforcement. And just having a GPC signal means nothing if there's no penalty for ignoring it. And while we're at it, how about we also allow our browsers to send a "Cookie Acceptance Preference" signal so that we can also dispense with all of those ridiculous cookie permission pop-ups. That would be a step forward for the world's user interfaces. Anyway, it's, you know, it's progress. We have the technology, and then we have the legislation to require its use and that it actually be honored. So, you know, it takes years, but we're getting there. Last Tuesday, OpenAI posted a piece titled "Disrupting malicious uses of AI." Their little blurb pointed to a detailed and lengthy 37-page report about their efforts to block many different abuses of their technology. Among those cited, OpenAI moved to disrupt PRC (People's Republic of China) espionage operations. Their security team banned ChatGPT accounts used by Chinese state-sponsored hackers to write spear-phishing emails. The accounts were allegedly used by groups tracked by the infosec industry as UNK_DROPPITCH and UTA0388. The emails targeted Taiwan's semiconductor industry, U.S. academia, U.S. think tanks, and organizations representing Chinese minorities. OpenAI says threat actors primarily abuse its service to improve phishing messages, rather than write malware, which is also what the threat intel company Intel 471 has observed. Okay, now, this is certainly a good thing for them to do. We've noted how phishing email is no longer obviously grammar-impaired, basically removing the first obvious sign that you should hit delete in your email instead of bothering to even read the nonsense that it's spewing. But I suppose I'm not hugely impressed because OpenAI was likely being used only because it was among the lowest hanging of the myriad of available fruit. There are so many other sources of the same or similar generative AI assistance, I mean, the threat actors could even spin up their own, as we know, that this feels like a battle that will always be lost. You know, just it seems to me that there's just no way that AI is not now going to always be used to improve the quality of phishing mail, regardless of what barriers any of the commercial providers put up. There will always be, you know, alternatives available. So I guess I'm not hugely impressed. It would be difficult to find a better example of the need to continue supporting, long past its prime, website code, than is evidenced by the fact that Microsoft continues, believe it or not, to need to offer the option to reload very old web pages under its creaky old "IE Mode." It's true. And in fact, this email went out yesterday afternoon, and I have already heard from one of our listeners who said he'd just the other day encountered an instance where some government websites would not run under Edge. And he had to switch to IE Mode, and then the page rendered. So they're still out there. What's also true, unfortunately, is that IE's old "Chakra" JavaScript interpreter contains known exploitable flaws that bad guys want access to. We're talking about this ancient history today because it's apparently less ancient than we might hope. IE Mode is still being exploited to the point that Microsoft's most recent iteration of Edge has removed all of the easy-to-click buttons from the browser's UI. An unknown threat actor has been tricking Microsoft Edge users into enabling Internet Explorer mode in Edge to run their malicious code in the user's browser in order to take over their machine. These mysterious attacks have been conducted since at least August of this year, according to the Microsoft Edge security team. IE's legacy mode, or IE Mode, is a separate website execution environment within Edge. It works by reloading a web page, but running the reloaded page and its code inside the old Internet Explorer engines. And as we know, Microsoft included IE mode in Edge when it retired its official IE predecessor. And I guess we had - we had, like, IE 11, I think was the last version of IE. But there was still some code that was dependent upon it. So to access a site under IE Mode previously, users would have to press a button or a menu option to reload the page from Edge into the old IE execution environment. Microsoft has said that it has received credible reports that hackers were using clones of legitimate websites to instruct users to reload the cloned pages in Edge's IE Mode. |
| Leo: IE Mode, oh god. |
| Steve: Yup. Yup. |
| Leo: And why would they do that, Steve? Why? |
| Steve: Well, when that happened, the malicious site would execute an exploit chain targeting IE Mode's creaky old Chakra JavaScript engine. |
| Leo: Oh, lord. |
| Steve: That has bugs that have never been patched. The exploit chain contained a Chakra zero-day that allowed them to run malicious code, and a second exploit that allowed them to elevate privileges and take over the entire user platform. |
| Leo: Oh, god. |
| Steve: Now - I know. |
| Leo: That's actually pretty ingenious, though. |
| Steve: It is. |
| Leo: I mean, if you think about it... |
| Steve: Again, if there's a way, these guys... |
| Leo: They'll do it. |
| Steve: So in response, Microsoft did not assign a CVE nor release a patch. Instead, they overhauled the entire IE Mode access. The Edge security team has completely removed all the dedicated buttons and menu items that could once easily refresh and relaunch a website under IE Mode. This includes the dedicated toolbar button, the context menu option, and under the hamburger main menu item. From this point on, anyone wishing, needing, actually, to relaunch a website in IE Mode will first have to go into the browser's settings and specifically enable the normally disabled feature there. They'll then need to relaunch the browser, you know, shut it down completely, relaunch their browser, and manually add the URL of a website into an allow list of sites permitted to be reloaded in IE Mode. So, I mean, you really have to need it that way. But it does sound like, for those people, for example, who are using a government site that is old and creaky and only runs under IE Mode, well, you can still do it. You just have, you know, you have to go in, and you turn it on. Then you relaunch the browser. Then you manually put that government URL into the allow list. And then you'll be able to access it. So it sure sounds as though Microsoft is none too happy that their old Internet Explorer code is still coming back to bite them, so they've decided that while they still cannot safely just kill it off once and for all, at least they can make it really much more difficult to use, and thus to abuse. So that's good. Leo, break time. |
| Leo: Yes, sir. |
| Steve: And then we're going to look at some news that actually occurred while I was putting the show together about Salesforce customer data leakage. And we're going to get to this horrifying new Texas law that takes effect in 10 weeks, that Tim Cook begged not to have. |
| Leo: Yeah, Apple's not thrilled about what California did, either, although it's exactly what you proposed, I think, in the past, which is that the App Store ask people when they're setting up an account, are you 18 or over? Are you over 18? And then I guess what they do is they say is this being set up for somebody besides you, and what is the age of this child? And then it's in the phone, and there's an API that apps can query it. That seems like such a sensible plan. It's what Meta wanted. Google even wanted it. OpenAI wanted it. But Apple's kind of like, well, do we have to be responsible for this, as well? |
| Steve: Well, as we're going to see in a few minutes, everybody's going to get it as a result of SB2420. |
| Leo: This Texas thing. Yeah. |
| Steve: Yes. |
| Leo: Oh, you're going to talk about SB2420, good, okay. |
| Steve: Yes. |
| Leo: Okay, Steve. |
| Steve: Okay. Here we go. Wow. So, first of all, remember how I was saying that we were almost certainly going to soon be hearing news of the leaks of Salesforce customer data? Just during the time I was assembling today's show, the news broke that the first tranche of those nearly one billion leaked Salesforce customer records has been published. Top of the list was Qantas Airlines. And what do you know, the criminals were not dissuaded by that permanent injunction the Qantas CEO managed to obtain from Australia's Supreme Court. Joining Qantas in private database publication we also have Vietnam Airlines, Albertson's, The Gap, Fujifilm, and Engie Resources, spelled E-N-G-I-E Resources. And in the case of Vietnam Airlines, who we're mentioning for the first time, the Scattered Lapsus$ Hunters group leaked 7.3 million details from Vietnam Airlines customer loyalty program, which was data taken from the company's Salesforce account. So Salesforce said no, we're not paying you your $3.5 million, which, you know, doesn't really seem like that much for 39 of their customers, all the data of 39 of their customers. But what are you going to do? Again, I mean, they made a big stink about it. Everyone says don't pay the bad guys. So they're not going to. But, you know, their customers' customers are paying the price. Wow. Okay. Here we go. Last Wednesday, Apple's developer portal posted their position and response to the Texas Senate Bill SB2420 whose official title is "Relating to the regulation of platforms for the sale and distribution of software applications for mobile devices." Okay. So there's been a lot of recent child protective legislation activity in Texas recently, so things can get a little bit confusing there. So first, to clarify, this Senate Bill 2420 legislation, which Apple is responding to, is not the same bill that recently caused Pornhub to go dark across Texas. Pornhub suspended its services in Texas because of a Texas law that was passed two years ago, back in 2023. That was House Bill HB1181. That bill was immediately challenged in the courts, and it wound up surviving. That's the law that requires websites hosting a majority of content that's inappropriate for minors to proactively verify the age of every single visitor before they are allowed to view the site's contents. Lacking any accepted privacy-enforcing means to do that, and given that we're now seeing tens of thousands of extremely personal government ID scans falling into criminal hands during data breaches, which appears to be inevitable, Pornhub probably correctly determined that the percentage of people who would be willing to be fully deanonymized during their visits to their site would not be appreciable. So just closing their doors to Texans was the right solution for them. It's worth mentioning that this Texas legislation HB1181, now having survived the courts all the way up to and including the Supreme Court, is likely to become a model for other states' legislation which will therefore not need to struggle for adoption and enforcement because Texas already did that, you know, verifying that the legislation passed the court's scrutiny. So we might expect to see many other states driving adult content websites out of their jurisdictions simply by following Texas's lead. Okay. But back to Texas's newer legislation, which is Senate Bill SB2420. While its official title is "Relating to the regulation of platforms for the sale and distribution of software applications for mobile devices," it is commonly referred to as the "App Store Accountability Act." It regulates how app stores and software application developers operating in Texas must verify users' ages and handle purchases or downloads by any minors in the state. The legislation states that the owners and operators of app stores - meaning Apple and Google; right? - must verify a user's age via a "commercially reasonable method" when an account is created. If a user is a minor (under 18, as defined in the bill), the legislation requires that the minor's account be tied to, you know, affiliated with a parent's or guardian's account. Additionally, each download or purchase by a minor must first receive explicit parental consent. I'll expand on some of these points in detail from the language of the law. The store must also clearly and conspicuously display each app's age rating and the content elements that were used to derive that rating. App stores must limit their data collection - and let me just reinforce, this is going into effect in 10 weeks. This is not, you know, 2029 or something. This is January 1st, 2026. This is happening. And I'll preempt something I mention later. There has been no legislation filed against this, probably because people, after what happened with HB1181, no one's bothering. So this is happening. App stores must limit their data collection to what is needed for obtaining age verification, consent, and recordkeeping. And any violations of any of these provisions such as attempts to obtain blanket consent or making any misrepresentations can be treated as deceptive trade practices. Okay. So that's on the app store side. Software developers have obligations under this new legislation, as well. Developers must assign an age rating to each of their apps, including any in-app purchases. And those age assignments must be consistent with the age categories specified in the bill. Developers much also substantiate their age assignments by providing the app content elements which lead to that rating. They must notify app stores of any significant changes to the app's terms, its privacy policy, changes in monetization or features, or any change in the app's resulting rating. Apps must use the age and consent information from the app store to enforce age restrictions, to comply with the law, and enable any safety features. Apps must delete any personal data received for age verification once such verification is completed. So that's very good. That gives us what we didn't see happening with Discord's Zendesk deal. And any violations such as misrepresenting the app's age rating, enforcing terms against minors without consent, wrongful disclosure of personal data and such are actionable. However, there are some liability protections. If the developer follows widely adopted industry standards in good faith, this new Texas law states that they may be exempt from liability. So mistakes are understood. Okay. So until we had this new Texas law, which was signed into law by Texas Governor Greg Abbott and is scheduled to take effect on January 1st, 2026, so in less than three months, app store and application age and content ratings were advisory only. App stores run by Apple and Google were assigning age ratings to apps using self-regulatory frameworks such as the IARC (International Age Rating Coalition) system. Developers answered questionnaires about their apps, the stores would generate an age rating such as "12+" or "Teen," and display those indications. But all of those were informational only. Nothing prevented app acquisition and download by younger users. That is the big thing that SB2420 changes. One of them, at least. Now, app developers are legally required to assign an age rating using criteria defined by this Texan law. App stores must display those ratings and the specific content descriptors. And these ratings now carry legal weight and must be enforced by app store technology to trigger parental-consent requirements and enable or disable the app's download. And any developer who mis-rates an app or fails to update ratings after material changes can face liability under deceptive trade-practice law. Naturally, Apple, who sees privacy concerns hiding around every corner, has not been happy about any of this. And Tim Cook is believed to have called Greg Abbott to argue against the provisions of the legislation, asking Abbott to either modify or completely veto the bill. Those pleas apparently fell on deaf ears. Apple's concerns have been that the new law would require "sensitive, personally identifying information" to be collected from any Texan who wants to download apps, even innocuous ones such as weather apps, sports scores, et cetera. |
| Leo: Because everything's going to be designated, even if it's a weather app, I'm going to designate it "adults only" because I don't want to take any chances. Right? |
| Steve: Right. |
| Leo: Almost all apps will be adults only. |
| Steve: And but get this, Leo. Even if it says "age 2 and above," still requires. |
| Leo: Just got to identify. |
| Steve: Anything. Anything. Yes. Anything. Any app downloaded by a minor, regardless of its rating, requires parental consent. I mean, parents are going to get fed up having to say yes, fine, you can download the sports scores app. Anyway, Apple has warned of downstream data sharing since SB2420 requires app stores to implicitly share age and parental consent status with developers. And of course the bottom line is that Apple really, really, really, really doesn't want to do this or get involved in any way with any of this. However, that doesn't feel like a practical long-term position for Apple to be taking, given the legislation which we're seeing. You mentioned California. That's, like, generous compared to what Texas is doing in 10 weeks. Everything we see everywhere evidences a growing awareness of age-related Internet content control. Okay. So I started out noting that last Wednesday, Apple's developer portal posted their position and response to these new Texas requirements. Apple's posting was titled "New requirements for apps available in Texas." And Apple writes: "Beginning January 1st, 2026, a new state law in Texas SB2420 introduces age assurance requirements for app marketplaces and developers. While we share the goal of strengthening kids' online safety, we're concerned that SB2420 impacts the privacy of users by requiring the collection of sensitive, personally identifiable information to download any app, even if a user simply wants to check the weather or sports scores. Apple will continue to provide parents and developers with industry-leading tools that help enhance child safety while safeguarding privacy within the constraints of the law. "Once this law goes into effect, users located in Texas who create a new Apple Account" - and I'll come back to this, but this is interesting, Leo - "create a new Apple Account." There is no language that is retroactive in this legislation, which is really interesting. Apple said: "...will be required to confirm whether they are 18 years or older." Again, required to confirm whether they're 18 years or older. That means everybody. I mean, all adults. "All new Apple Accounts for users under the age of 18 will be required to join a Family Sharing group, and parents or guardians will need to provide consent for all App Store downloads, app purchases, and transactions using Apple's In-App Purchase system by the minor. This will also impact developers, who will need to adopt new capabilities and modify behavior within their apps to meet their obligations under the law." In 10 weeks. "Similar requirements will come into effect later next year in Utah and Louisiana." So Texas alone for now. Here comes Utah and Louisiana. So, and just wait till Mississippi gets wind of this and figures out that they can do the same thing. Apple continued: "Today, we're sharing details about updates we're making and the tools we'll provide to help developers meet these new requirements. To assist developers in meeting their obligations in a privacy-preserving way, we'll introduce capabilities to help them obtain users' age categories and manage significant changes as required by Texas state law. The Declared Age Range API is available to implement now, and will be updated in the coming months" - I hope it's in weeks - "to provide the required age categories for new account users in Texas. And new APIs launching later this year, meaning in time this year, will enable developers, when they determine a significant change is made to their app, to invoke a system experience to allow the user to request that parental consent be re-obtained. "Additionally, parents will be able to revoke consent for a minor continuing to use an app. More details, including additional technical documentation, will be released later this fall." In other words, Apple is scrambling in order to provide the API, the APIs the developers will need in order to be compliant with this Texas law. They said: "We know protecting kids from online threats requires constant vigilance and effort. That's why we will continue to create industry-leading features to help developers provide age-appropriate experiences and safeguard privacy for their apps and games, and empower parents with a comprehensive set of tools to help keep their kids safe online." Okay. So I went over to check out Apple's "Declared Age Range" API. The page is titled "Declared Age Range: Create age-appropriate experiences in your app by asking people to share their age range." Okay. I was struck by the language "by asking people to share" and by the name of the entire API, the API which is, after all, the "Declared Age Range" API. What follows, then, is the "Overview" of the API on the page. And it just says - so here's the overview of the Declared Age Range API. "Use the Declared Age Range API to request people to share their age range with your app. For children in a Family Sharing group, a parent or guardian or the Family Organizer can decide whether to always share a child's age information with your app, ask the child every time, or never share their age information. Along with an age range, the system returns an AgeRangeService.AgeRangeDeclaration object for the age range a person provides." |
| Leo: This is Apple's compliance with the California law because it doesn't work with the Texas law. |
| Steve: Okay. Right, right, right. |
| Leo: So the California law does exactly that. It says maker of an app store or operation system - by the way, the California law would apply to Linux - has to ask for an age of the user and then have an API that returns that age range. And it's like zero to five... |
| Steve: Right. It's like four or five brackets; right. |
| Leo: Five to 10, 10 to 13, 13 to 16, 16 to 18, 18 or over. But that satisfies California. There's no way this satisfies what Texas is asking for. |
| Steve: No, no. Just wait till we get to the specifics. |
| Leo: Yeah. |
| Steve: So, but even on Apple's page, in a vividly highlighted callout box labeled "Important," the page states: "Data from the Declared Age Range API is based on information declared by an end user..." |
| Leo: Right. |
| Steve: "...or their parent or guardian. You are solely responsible for ensuring compliance with associated laws or regulations that may apply to your app." So, you know, Apple is saying we're not responsible for verifying what is declared as the user's age. So exactly to your point, Leo, none of this is useful for Texas. |
| Leo: Right. |
| Steve: And so, you know, this is Apple saying that all they're doing here is functioning as a middleman to pass along whatever age declaration the user might assert, and that the app's developer in this instance remains responsible for ensuring compliance with associated laws or regulation. So this of course begs the question, what does the forthcoming Texas SB2420 law require in that regard? We know that in other jurisdictions and contexts, self-declaration of age is specifically regarded as insufficient. So what about Texas? |
| Leo: Because kids are going to lie. They're going to say I'm 18. |
| Steve: Right, of course. |
| Leo: I'm 18, honest. |
| Steve: Yeah. |
| Leo: Yeah. |
| Steve: The bill does not mandate a single specific age-verification method, such as uploading an ID, but it does require app stores to use a "commercially reasonable method" to verify a user's age, not just accept whatever age the user may self-declare. So as a clarifying example, the legislation states that app stores may not rely on a birth date entered into a form or any other method that is "reasonably likely to be circumvented by a minor." So I've been studying this carefully in an attempt to understand how and whether Apple's "Declared Range" API is in any way sufficiently responsive to what Texas requires. Clearly, it's not. The only way I can see that it could be applicable would be if Apple starts out with "Declared Age," then later replaces the "declaration" part with some sort of full responsibility-taking verifiable age determination mechanism. Because that's what Texas requires. And in that way, the same API could be used, and just the source of the age determination information would change. And Apple has said that they will have other new APIs, you know, later this year. There's not much of this year left. So I'm sure they're working on it. So, for example, what could be done state-by-state or political jurisdiction by jurisdiction would allow self-declaration to continue to be sufficient within regions that have not yet clamped down on their citizens, and only using (and requiring) verifiable age verification where the governing laws require that it be used. So what Apple has today with their Family Sharing is that Apple asks for a date of birth during account creation. For accounts under 13, Apple requires an adult parent or guardian to be a member of the Family Group. And for ages 13-17, a teen can create their own Apple ID without parental verification, with Apple trusting the date entered. Which seems screwy to me. If you were 12, why not, what prevents you from just declaring that you're 13 and then not having parental verification. So again, Apple historically has done what they can not to get involved in all this. All of this changes in 10 weeks. It all dies in Texas on New Year's Day. What's required by Texas SB2420 is an affirmative "commercially reasonable method" of age verification for every account created. Self-declaration never is sufficient in Texas. This implies that, for Texas users, Apple will need - Apple will need - to implement some new form of age verification: ID checks, credit-card based validation, or some other form of verifiable age-assurance technology. And Apple has fewer, as I've mentioned, than three months to bring this online. While Apple currently only requires and enforces parental linking for account owners younger than 13, SB2420 specifically applies to all minors under 18. Under Apple's current Family Sharing plan, the so-called "Ask to Buy," option is available to parents who may choose to enable it for their kids, but it can be disabled, and parents can also choose to grant blanket permissions. Under SB2420, blanket or any form of pre-authorized permission is expressly forbidden in the law. It states it. Under SB2420, parental consent is legally required for every app download and in-app purchase by any minor. Imagine being a 17-year-old high school senior in Texas and needing to obtain your mother's permission to add an app - any app, regardless of its age rating - to your iPhone. I mean, Leo, think of, I mean, think of all the apps we've downloaded just because it was easy. You know, just to see what they were. Now... |
| Leo: Well, and anything that accesses the Internet, like a browser, would probably have to be marked "adult only." Right? |
| Steve: Good point. |
| Leo: So kids are not going to have much access to anything except kiddy stuff. |
| Steve: Right. You're right. |
| Leo: Explicitly for kids. |
| Steve: It's a mess. The language of the law states, from the text of the legislation, it says: "An operator of a digital distribution platform [app store] shall obtain verifiable parental consent before allowing a minor to download or purchase any software application through the platform." And also: Parental consent must be obtained on a per-transaction basis, and may not be granted as a blanket authorization." So anyway, it's not difficult to see why Tim Cook would have given Greg Abbott a call to plead with him to amend or to veto this legislation. One interesting aspect of the legislation is that nothing in it appears to apply retroactively, as I noted. The age verifications are only performed upon new account creation. However, existing adult accounts might need to have their adult status reasserted, you know, verified if a minor's account were to be linked to it as a parent or guardian. So, wow. Whatever the case, this new Texas SB2420 legislation is going to create a mess, and it's only about 10 weeks away from coming into effect. So far, the law has not been challenged in court, as I mentioned, and I assume that's because Texas's earlier HB1181 legislation survived both the Fifth Circuit Court of Appeals and then the U.S. Supreme Court's analysis. So under the current U.S. legal climate, it might be viewed as a fait accompli that's not even worth fighting. Which leaves us with the question: How is Apple going to verifiably determine the ages of any new account holders in Texas? One thought occurred to me, which is perhaps an age verification performed at the purchase time of a new iPhone. You know, you're buying it with a credit card, presumably, or Mom and Dad are buying it for their kids. So perhaps you tie age verification to purchase. But, you know, but then you have the problem going forward of new accounts being created. Any new account created will need to have its age determined. And it does seem like a huge loophole in SB2420 that there doesn't appear to be any retroactive action here. So I don't understand that, Leo. But, boy, you know. And if Apple has to do this in Texas, and if it's coming in Utah and Louisiana, and lord knows Mississippi. |
| Leo: They're just going to do it nationwide, yeah. |
| Steve: Yeah. |
| Leo: Because, as you've pointed out, GeoIP location is not... |
| Steve: Yeah, yeah. Geo locate, I mean, IPs were not designed to be, you know, about states of the U.S. And they're not, very much so. Okay. Break time. And then we're going to look at the interesting site makeover that the BreachForum's Scattered Spider, LAPSUS$, Hunters site recently got. |
| Leo: Okay. Now, back to Mr. Steve Gibson. |
| Steve: So this was a little bit tongue-in-cheek. I described what happened to Scattered Spider, LAPSUS$, Hunters ransom forum as a "makeover" because BreachForums.hn... |
| Leo: Is it beautiful? |
| Steve: ...is no longer showing the extortion notice that we had in the show notes last week. |
| Leo: Ha ha. Well, hello. |
| Steve: That's right. This domain has been seized. And then we have the Department of Justice seal, the FBI's investigation, looks like, what is that, Spain? |
| Leo: The Brigade de Lutte Contre la Cybercriminalit. |
| Steve: Yup, and then certainly then France. |
| Leo: Yeah, yeah, yeah. Parquet de Paris. |
| Steve: BreachForums.hn, "hn" is the top-level domain for the Central American country of Honduras. So the FBI has taken over that domain's DNS, pointed it to one of their servers. So for anyone who goes over to BreachForums.hn, whoopsie. They're not home anymore. The domain... |
| Leo: I like the email address on the new page: breachforums@fbi.gov. |
| Steve: Yeah, just give it a ring. |
| Leo: Wow. Wow. |
| Steve: Yeah. So GreyNoise has detected and reported a widespread botnet-driven attack, which began last Wednesday, so six days ago on the 8th of October. That attack is being sourced by more than 100,000 individual bots scattered across the globe, all aimed at U.S.-based exposed RDP endpoints. Now, as we know all too well, RDP is Microsoft's very poorly authenticated Remote Desktop Protocol, which keeps being used because it works so well, and it's built in. |
| Leo: It's so easy. |
| Steve: It's so handy, yes. Unfortunately, it has also been an unending source of remote network intrusions through the years as bugs and other various failings have continued to be found in its code. Now, just to be clear, I love RDP. It works incredibly well, and I use the crap out of it. But nowhere among any of GRC's Internet-facing IPs and ports will anyone ever find any exposed RDP service because for me - or anyone - to publicly expose any instance of RDP to the Internet would be just begging for an intrusion. |
| Leo: Yes. |
| Steve: So I have three words: Don't do it. |
| Leo: Oh, I thought you were going to say "VPN." But okay. |
| Steve: Don't do it. |
| Leo: Don't do it. Don't expose... |
| Steve: Now, those are a good three also because you need to have some way to not do it. But one way or another... |
| Leo: Don't do it. |
| Steve: Arrange to don't do it. Don't do it. |
| Leo: Okay. |
| Steve: Okay. Now, unfortunately, my repeated admonishment flies in the face of convenience. Right? As we all know, convenience often trumps security. You know, it's like, "But why would the great and powerful Microsoft allow us to turn it on if it wasn't secure? And my god, it's so handy!" Right. A Shodan search for "Remote Desktop Protocol" returns on the order of 2.4 million results. Some sources have claimed that Shodan has indexed more than 3.5 million exposed RDP ports, and some non-Shodan research has shown 4,493,357 exposed RDP services when scanning for RDP running on its default port of 3389. All of this, all of this RDP nonsense is very nicely covered by one of the most important lessons all of us who've been participating together in this podcast for the past 20 years have learned: Authentication is generally broken and should never be trusted. The only Internet servers that should ever be placed onto the Internet are those that do not use any authentication. Authentication that's never used can never be broken - because there isn't any. So things like web servers and DNS servers and email servers which are designed and intended to be accessible by anyone, anywhere - whose entire purpose is that they are for use by anyone, anywhere - they're safe to deploy. But anything that requires any form of authentication is inherently risky. The only exception to this, and I even hesitate, but I've got to be a little reasonable. The only exception is that I would be inclined to trust well-tested and carefully vetted connections to SSH servers running on a non-standard port, if those connections are authenticated with cryptographically secure certificate credentials. But even there, wherever possible, filter all incoming connections by region. If you never roam outside of your own country, why would you ever entertain connections from China, Russia or Iran? None of those people are friends of the West. Don't even consider accepting their traffic to your non-public servers. Use some geofencing to drop any traffic coming in to authenticated endpoints if its IP is foreign. Why not? GreyNoise wrote: "Since October 8th, 2025, GreyNoise has tracked a coordinated botnet operation involving over 100,000 unique IP addresses from more than 100 countries targeting Remote Desktop Protocol services in the United States. The campaign employs two specific attack vectors, RD Web Access timing attacks and RDP web client login enumeration. Again, you can never trust authentication. Don't. With most participating IPs sharing one similar TCP fingerprint, indicating centralized control. Source countries include Brazil, Argentina, Iran, China, Mexico, Russia, South Africa, Ecuador, and more than 92 others. So I would only ask that everyone consider filtering and dropping any traffic coming into any non-public authenticating services. You know you don't need or want that traffic. You should never assume that your authentication will hold. All of our experience says it probably won't. Blocking and dropping traffic that you know you don't want is what firewalls are for. But firewalls won't help if they're not used. So again, you'll never find RDP at GRC, even though I use it like crazy. A listener of ours, Dan Linder, wrote: "This well-respected UI/UX organization agrees the new iOS 26 interface is a mess. They clearly describe a lot of our feelings well. I hope Apple listens." And he provided a link to the nngroup.com/articles/ liquid-glass. And of course Dan is posting this at least in partial response to last week's UI rant where I detailed my feelings about the unproductive nonsense that Apple had added to their user interface, forgetting the #1 rule of UI design, which is that the interface should never call attention to itself for its own sake, and should do everything it can to disappear and to facilitate the user's use of whatever it is it's interfacing. So the brief TL;DR summary at the top of the wonderful takedown piece reads: "iOS 26's visual language obscures content instead of letting it take the spotlight. New, but not always better, design patterns replace established conventions." And I just want to share a bit of the piece, which begins: "With iOS 26, Apple seems to be leaning harder into visual design and decorative UI effects but at what cost to usability? At first glance, the system looks fluid and modern. But try to use it, and soon those shimmering surfaces and animated controls start to get in the way. Let's strip back the frost and look at how these changes affect the real use. "iOS 26 introduces Apple's new glassmorphic visual language into its phones. Apple describes Liquid Glass as 'a translucent material that reflects and refracts its surroundings, while dynamically transforming to help bring greater focus to content, delivering a new level of vitality across controls, navigation, app icons, widgets, and more.' "Translated," they write, "the interface now ripples and shimmers as if your phone were encased in Jell-O. At first glance, it does look cool. But problems arise as soon as you start actually using your phone. Transparency equals hard to see. Liquid Glass makes UI elements translucent and bubbly. The result is light, airy, and often invisible. One of the oldest findings in usability is that anything placed on top of something else becomes harder to see. Yet here we are, in 2025, with Apple proudly obscuring text, icons, and controls by making them transparent and placing them on top of busy backgrounds. "Text on top of images is a bad idea because the contrast between the text and the background is often too low. So why does Apple now encourage users to set photos as backgrounds for translucent text messages? The result is that your friend's words are camouflaged against their beach-vacation photo, or worse, their pet's fur. Content may technically be "in focus," but you can't read or see it. "And then comes Apple's boldest (or dumbest) experiment: text on top of text. Apparently, designers decided users have eagle vision and infinite patience, because deciphering one line of text written across another is now fair game. Reading an email subject line now requires Dan Brown-level cryptographic decoder skills. Not only is it illegible, it's also ugly." Okay. And while this goes on, and there's much, much more, I'll just finish by sharing this piece verbatim because, if you recall my rant last week, you would be inclined to wonder whether I had written this one, too. The section heading is "Animated Buttons: Motion Without Meaning." And it reads: "Animations can be delightful the first time. When used intentionally, they can also be satisfying, creating the feeling when someone just "clicks" or "snaps" into place. Our eyes are finely tuned to detect motion, which is why animated buttons grab attention instantly. But delight turns to distraction on the 10th, 12th, or hundredth time. "In iOS 26, controls insist on animating themselves, whether or not the user benefits. Carousel dots quietly morph into the word Search after a few seconds. Camera buttons jerk slightly when tapped. Tab bars bubble and wiggle when switching views, and buttons briefly pulsate before being replaced with something else entirely. It's like the interface is shouting 'look at me' when it should quietly step aside and let the real star the content take the spotlight." |
| Leo: Right on. Right on. Wow. |
| Steve: Anyway, I thank Dan for sharing another view, posted last Friday, by a group that specializes in UI design. As Dan says, I hope Apple is listening. I'm glad it's possible to turn those superfluous wiggles, jiggles, zips, and zings way down to a tolerable level. |
| Leo: Yeah. In accessibility you can turn it almost off entirely. But just as a footnote, who is NNG? It's the Nielsen Norman Group. And I've interviewed Jakob Nielsen and Don Norman both. They are the king... |
| Steve: Nielsen is legendary. |
| Leo: They're the legends. In fact, Don Norman's incredible book, what was it, "The Usage of Everyday Things," is one of the best things ever written about usability. |
| Steve: Yeah, yeah. It's the bible on UI. |
| Leo: Yeah. So this is not just any, you know, company. This is the UI company. And I, you know what, I've been putting up with Liquid Glass, you know, trying to get used to it. And now that I read this article, I'm not going to, I'm really not going to get used to it. I guess you can kind of turn it down. But what was Apple thinking? I really have to wonder. |
| Steve: I just think maybe something's in the water? Or they're just so self-obsessed. I mean, it's... |
| Leo: It's truly awful. It's really bad. |
| Steve: It's truly awful. |
| Leo: Yeah. |
| Steve: Yeah. I mean, really, I mean it does, it really, I mean, it's like a game. I don't, you know, there are games you can play on your phone, but you don't want your phone to be the game. |
| Leo: Well, maybe they're trying to reach a younger audience. I don't know. I don't know. It's terrible. |
| Steve: If you shake it hard enough, does it come out the end? |
| Leo: I wish it would. Like toothpaste. |
| Steve: Oh, gosh. Okay. Last break. Then we're going to look at what happened with the Redis server. |
| Leo: Oh, all right. |
| Steve: Oh, boy. So a trio of researchers at Wiz, that's W-I-Z, as in wizard, there's no "H," Research, they worked through Trend Micro's Zero-Day Initiative to disclose the significant problem they uncovered in Redis servers, which are exposed over the public Internet. Why, it's hard to understand. We already know from today's episode title that this vulnerability has received the difficult-to-obtain CVSS score of 10.0. You know, 9.8 is normally the limit. It's difficult to get beyond 9.8. And 9.8 are really bad zero-days. This is a 10.0. The reason this has come to the attention of the Internet community is that there are - get this - nearly 330,000, a third of a million, 330,000 publicly exposed Redis servers on the Internet, with around 60,000 of those which require no authentication. They are wide open, ripe for exploitation. Now, Redis (R-E-D-I-S) stands for REmote DIctionary Server. It was created back in 2009 by Salvatore Sanfilippo, who built it to solve his own problem, performance issues with his startup company. He initially created it to improve the performance of a real-time web analytics system. But the speed of an in-memory network accessible dictionary ended up being so useful that it evolved into a standalone open source project of its own. Since then, it's evolved beyond a simple key-value cache into a full in-memory data structure server. Unfortunately, that means there's a lot of data stored out on the Internet in all these servers. And they're on networks. And unfortunately they're penetrable. Now, I run a Redis server for Windows to improve the performance of the PHP-based web forums. I've got my Redis server bound to the localhost IP 127.0.0.1 and listening on its default port of 6379. So a number of the PHP-based services on that server take advantage of Redis to improve their performance. What I'm doing differently - and Leo, what I'm sure you're doing differently - from 330,000 other instances, is that the last thing I would ever think of doing would be binding the Redis service to any network interface that's connected to the public Internet. |
| Leo: I use RDP for that. Is that okay? No, of course not. |
| Steve: Historically, you know, there have been thousands of botnet infections and data leaks due to open Redis ports. I mean, it has been a magnet for exploitation. So on the one hand, nothing horrible involving Redis would be the first time. But what's been found is still new, and maybe worse than anything. The guys at Wiz Research titled their report "RediShell: Critical Remote Code Execution Vulnerability (CVE-2025-49844) in Redis, 10 CVSS score." And their tease was "Wiz Research discovers vulnerability stemming from 13-year-old bug present in all Redis versions, used in 75% of cloud environments." So they wrote: "Wiz Research has uncovered a critical Remote Code Execution vulnerability CVE, which we've dubbed RediShell, in the widely used Redis in-memory data structure store. The vulnerability has been assigned a CVSS score of 10.0, the highest possible severity. The vulnerability exploits a Use-After-Free memory corruption bug" - there's Use-After-Free again - "that has existed for approximately 13 years in the Redis source code. This flaw allows a post-auth attacker to send a specially crafted malicious Lua script, a feature supported by default in Redis, to escape from the Lua sandbox and achieve arbitrary native code execution on the Redis host. This grants an attacker full access to the host system, enabling them to exfiltrate, wipe, or encrypt sensitive data, hijack resources, and facilitate lateral movement within cloud environments. "Given that Redis is used in an estimated 75% of all cloud environments, the potential impact is extensive. Organizations are strongly urged to patch instances immediately by prioritizing those that are exposed to the Internet." And again, why any are, I have no idea. But almost a third of a million are, and 60,000 of them require no authentication at all. So being post-auth means post nothing. "On October 3rd," they wrote, "Redis released a security advisory along with a patched version of Redis. We extend our gratitude to the entire Redis team for their collaboration throughout the disclosure process. We greatly appreciate their transparency, responsiveness, and partnership during this engagement. In this post we will provide a high-level overview of our discovery and its implications. Given the prevalence and sensitivity" - they didn't say "severity," but I would - "of this vulnerability, we will defer some of the technical details to a future installment, omitting exploit information for now to allow impacted organizations sufficient time to address the vulnerability. Organizations utilizing Redis are strongly encouraged to update their Redis instances to the latest version immediately." And I'll just note also, exposure to the Internet is bad, but when bad guys get into a network through any means, they look around for some means of obtaining a foothold, some other server which they can access which is vulnerable from the inside. So even Redis sitting inside a network containing a remote, full remote-code execution, native code execution on the host, would be a juicy target for somebody to jump onto once they got inside and were sitting on a machine they couldn't do anything with. They'll start looking around for one they can. So there are plenty of public targets. That's going to be a problem. But all Redis everywhere should be updated. They wrote: "The newly discovered RediShell vulnerability in Redis has been assigned a CVSS of 10.0, a rating rarely seen, with only around 300 vulnerabilities receiving it in the past year." So yes, rarified, as we've said. "It's also the first Redis vulnerability to be rated as critical. The score reflects not just the technical severity of remote code execution, but also how Redis is commonly used and deployed. Redis is widely used in cloud environments for caching, session management, and pub/sub messaging. While Redis has had a strong security history, the combination of this flaw and common deployment practices significantly increases its potential impact. "The vulnerability is a Use-After-Free memory corruption that allows an attacker to send a malicious Lua script that leads to arbitrary code execution outside Redis's Lua interpreter sandbox, gaining access to the host. The urgency with which you should address this vulnerability depends upon how Redis was installed and its exposure level. Our analysis across cloud environments revealed the extensive scope of this vulnerability: Approximately 330,000 Redis instances are exposed to the Internet at the time of this blog post. About 60,000 instances have no authentication configured. 57% of cloud environments install Redis as container images, many without proper security hardening. "The official Redis container, by default, does not require authentication. Our analysis shows that 57% of cloud environments install Redis as an image. If not installed carefully, these instances may lack authentication entirely. The combination of no authentication and exposure to the Internet is highly dangerous, allowing anyone to query the Redis instance and, specifically, send Lua scripts, which are enabled by default. This enables attackers to exploit the vulnerability and achieve remote code execution within the environment. "Redis instances are also frequently exposed to internal networks where authentication may not be prioritized, allowing any host in the local network to connect to the database server. An attacker with a foothold in the cloud environment could gain access to sensitive data and exploit the vulnerability to run arbitrary code for lateral movement into sensitive networks." So they conclude their report, as they promised, without disclosing any of the critical details behind their discovery because Redis has been updated to cure this 13-year-old vulnerability and because they most want the world to update. Sadly, we pretty much know how that's going to go. And given that Redis is a widely used open source project, it will not be difficult for the bad guys, now knowing that there is a huge vulnerability in all of the past 13 years of open source Redis, to determine what has been broken for the past 13 years and start scouring the Internet for networks to attack and infiltrate. Also, since Redis is almost ubiquitously available on internal networks, even when instances are not publicly exposed, attackers will be able to scan the internal network for anything answering on port 6379 to see whether they've found a long-ignored instance of Redis, which no one ever bothered to update, which would allow them, as I mentioned before, to pivot their attack into that machine to obtain a deeper foothold inside the network. The Wiz guys - which first demonstrated this during the Berlin Pwn2Own competition, by the way - concluded their write-up, writing: "RediShell represents a critical security vulnerability that affects all Redis versions due to its root cause in the underlying Lua interpreter. With hundreds of thousands of exposed instances worldwide, this vulnerability poses a significant threat to organizations across all industries. The combination of widespread deployment, default insecure configurations, and the severity of the vulnerability creates an urgent need for immediate remediation. Organizations must prioritize updating their Redis instances and implementing proper security controls to protect against exploitation. This vulnerability also highlights how deeply today's cloud environments depend on open source technologies like Redis." So the biggest takeaway for our listeners is to check your own use in your organizations for any creaky older instances of Redis that might be running. You could simply perform an internal port scan for anything accepting TCP connections on port 6379. If any are found or known, carefully examine and consider who could obtain connections to its services. And of course it's always best to keep current with open source releases. In this instance, it could be crucially important. And if you've got any Redis in a cloud environment, make sure that it's not publicly exposed. It's just crazy. But for some reason, 330,000 instances are. Which, again, you can't trust authentication. 60,000 don't have any need for that, but the other ones, yeah, who knows what the username and password is going to be. Wow. |
| Leo: Well, I'm just going to trust that Patrick has locked our Redis instance down and is keeping it up to date. I think probably... |
| Steve: And if he's listening to this podcast... |
| Leo: He is. He listens religiously. |
| Steve: In that case, I'm sure it's probably already been fixed. But if not, it will be. And the good news is, as far as I have seen, there's as yet no proof of concept. As soon as one gets published, then it's Katy bar the door, I think is an expression you and I have probably heard before. |
| Leo: Once or twice. I don't know who Katy is, but... |
| Steve: Not sure who Katy is, yeah. |
| Leo: Yeah. And whether it's the barn door. I don't know. You know, there's a lot of stuff written in Lua. It's a pretty cool language. |
| Steve: Yeah. |
| Leo: Do you think this Lua interpreter flaw might hit other software? |
| Steve: That's a good question, whether it's a - whether that's a shared exploit. Whatever it is, the problem in Lua escapes its own sandbox, allowing external access. So that's, I would imagine... |
| Leo: Yeah, that's not good. |
| Steve: ...the Wiz guys are on it, if it hasn't occurred to... |
| Leo: There's a ton of stuff coded in Lua. I actually like it as a language. Huh. |
| Steve: Yeah. |
| Leo: Okay. A lot of it's gaming. So, you know, so what if you have a Use-After-Free bug. |
| Steve: Yeah, it's one of those hobby languages that sort of grew up. |
| Leo: Oh, yeah. |
| Steve: Sort of like PHP. |
| Leo: Yeah. It's not as bad as - I think it's a little better than PHP. Maybe not, now that I know that it's got this problem. Okay. Ladies and gentlemen, that concludes this thrilling gripping edition of Security Now!. We're getting better every episode. And considering now this is our 1047th, we must be pretty darn good by now. |
| Steve: I think we're getting the hang of it. |
| Leo: Getting the hang of it, yeah. |
|
 | Gibson Research Corporation is owned and operated by Steve Gibson. The contents of this page are Copyright (c) 2024 Gibson Research Corporation. SpinRite, ShieldsUP, NanoProbe, and any other indicated trademarks are registered trademarks of Gibson Research Corporation, Laguna Hills, CA, USA. GRC's web and customer privacy policy. |  |
| Last Edit: Oct 20, 2025 at 11:01 (29.17 days ago) | Viewed 12 times per day |