| ||||||
Description: A follow-up to the SharePoint server patch mess. How Russia arranges to spy on other countries' local embassies. "Dropbox Passwords" manager app is ending in October. Signal will leave Australia rather than help spy. YouTube deploys viewing history age-estimation heuristics. Chrome adds clever lightweight extension signing to prevent abuse. A domain registrar is coming close to losing its rights. A TP-Link router that doesn't encrypt its configuration. What is "TruAge" and might it be useful for age verification? An update on "Artemis." With U.S.-China tensions on the rise, should Chinese security companies receive weeks of advance notice of forthcoming Microsoft flaw patches?
High quality (64 kbps) mp3 audio file URL: http://media.GRC.com/sn/SN-1037.mp3 |
SHOW TEASE: It's time for Security Now!. Steve Gibson, he's mad as heck, and he's not going to take it anymore. He's pretty upset about how Microsoft did its patches for the SharePoint server fiasco. You might be upset, too, when you hear about it. A warning about Signal leaving Australia, rather than help the Australian government spy on people. Plus a solution to verify your age that might not be too bad. Or is it? All that and a whole lot more coming up next on Security Now!.
| Leo Laporte: This is Security Now! with Steve Gibson, Episode 1037, recorded Tuesday, August 5th, 2025: Chinese Participation in MAPP. It's time for Security Now!, the show where we cover the latest in security, privacy, and home computing, and like that. I don't know. All sorts of stuff. |
| Steve Gibson: Yay. |
| Leo: It's really up to this guy over here, this cat. Steve Gibson is the king of Security Now!. Hi, Steve. |
| Steve: Yo, Leo. Here we are. We have entered August. Which is our birth month. |
| Leo: The show's birth month, yeah. We're approaching our 20th anniversary in just a few days. |
| Steve: That's right. Yeah, I got that wrong one year, and Elaine corrected me because of course she's been transcribing for almost 20 years now. |
| Leo: She knows. Has she been doing all the shows, really? |
| Steve: Yeah. We got her, like a ways in. And then I went back, and I said, let's catch up. Let's do them all. So she said, oh, I'd be happy to. Here's my bill. |
| Leo: If you go to TWiT, our website, TWiT.tv/sn1, you can actually see the very first episode, which is August 18th, 2005. So that will be our birthday. |
| Steve: It will, yeah. So that's - we're going to... |
| Leo: The 18-minute version of this show. So what happened this week, Steve? |
| Steve: Not really anything. |
| Leo: There was nothing to talk about back in the day. |
| Steve: How's that ingrown toenail doing? |
| Leo: No. It didn't stay 18 minutes for very long. We found there was a lot to talk about. You were worried at first there wouldn't be nearly enough. |
| Steve: I thought, we're just going to run out of stuff to say, yeah. It's like, no. |
| Leo: Twenty years. There's no way either of us thought we'd be doing this 20 years later, though, that's for sure. But here we are. |
| Steve: Nope, we're going strong. And in fact we're going to talk this week. We've got China on our mind after the SharePoint fiasco. There's two different aspects of the unfortunate tension that our two countries, China and the U.S., are continuing to manifest and arguably increase. So we're going to look at both of those. Some things that have come to light since last week we'll start with, but we're going to end up talking about Microsoft's deliberate sharing, weeks in advance of their release, to legitimate, accredited, great Chinese security companies. But China's got the possibility of influencing them. So anyway, we're going to look at that. There's some really, really, I think, very fair analysis that I want to share about where that is. And we'll see where we come down on that afterwards. But first, as I said, we're going to follow-up on a different aspect of what's come to light about the SharePoint server patch mess. We're going to look at how Russia arranges to spy on other countries' embassies within its borders. It turns out that Dropbox has a password manager. Who knew? But not for much longer. I just wanted to give our listeners a heads-up in case they might have stumbled into that at some point. Signal is going to leave Australia rather than spy. YouTube deploys viewing history age estimation heuristics, which we're going to touch on. Chrome has added a very clever, lightweight extension signing option, which will help its developers to prevent the abuse of their own reputations for extensions. Ah. And a domain registrar is coming right up to the line of losing its rights to be a registrar. That's something we've never talked about before. We've looked at it on certificate authorities, but not registrars. So there's some fun stuff there. TP-Link's router, there's a particular model that our listeners, if anyone happens to have one - see, I really get inertia. Right? Unless there's a reason to stop doing something, the industry doesn't. We see this at every end of the spectrum, all across the spectrum. So here's another instance. Also we're going to look at what is TruAge and might it be useful for age verification. I have my own brief update on "Artemis," a few comments. And then with U.S.-China tensions on the rise, should Chinese security companies, even having signed Microsoft's NDA, their non-disclosure agreement, continue receiving weeks of advance notice for forthcoming Microsoft flaw patches? You know, can they really be expected to honor their commitment not to let something that might be really juicy come along when, you know, their own nation seems hell bent on attacking ours. So, interesting questions. And of course we've got a great Picture of the Week that I've already had - the email with these notes and the Picture of the Week went out yesterday early afternoon. I got a lot of work done on Sunday and Monday. And I got a lot of great feedback about this one, Leo. This one will, you know, you want to center yourself over your ball before you see this picture. |
| Leo: I haven't looked at it. I haven't looked at it. |
| Steve: Yeah. Our listeners, they're all saying, oh, I can't wait to hear what happens when Leo sees this because, yeah. |
| Leo: I try to save it for the show, so - not always easy. |
| Steve: If you can. If you can. |
| Leo: But I always go like this when I open your... |
| Steve: My mother would have once said, "Hold your horses." I'm not sure that - keep your powder dry, maybe, you know. So, yeah. Never said that. |
| Leo: All of the above. |
| Steve: Yeah. |
| Leo: All right. A great show ahead, as always with Security Now!. We're thrilled to have Steve here, and even more thrilled to have you here. Okay. Shall I scroll up, Steve? |
| Steve: Well, I gave this Picture of the Week the caption "Not every solution that works should be recommended." |
| Leo: Yeah. That could be the caption to a lot of your Pictures of the Week, Steve. |
| Steve: This one, this one will hit you. Not every solution... |
| Leo: Uh, you want to explain this? |
| Steve: Okay. So what we have is a very simple device. |
| Leo: Oh, yes. |
| Steve: It's an AC plug. |
| Leo: Yes. |
| Steve: With wires coming out maybe five inches or so that have been stripped and wrapped together and a wire nut stuck on the end. |
| Leo: It's shorted out, in other words. |
| Steve: It is the definition of a deliberate short circuit. What makes this funny is that it's got a tag on it, just in case someone wasn't sure what this was for. It's labeled "Breaker Finder." |
| Leo: Yeah. |
| Steve: And of course the idea here, we fill in the gaps, is that, if you're trying to figure out which is the circuit breaker for that plug because you'd like to turn the power off - actually, this does both features. It does both jobs at once. Really it's, you know, finding the breaker is then secondary. Normally you want to turn off the breaker because you're going to do some electrical rewiring, and you want the power off on the circuit that you're using. So here you just plug this handy-dandy little plug into the plug, which creates a dead short circuit, certainly more than the 15 amps of your typical residential breaker. That'll snap off immediately. Now... |
| Leo: One hopes it'll snap off before things start getting exciting. |
| Steve: Well, melting your hand or the wires or the interior house wiring and so forth. |
| Leo: I hope he threw this out after he made this obviously joke tool. |
| Steve: Well, one of our listeners wrote and said, "Look at the prongs on that plug. I don't see any black scorch marks." |
| Leo: Yeah, yeah. |
| Steve: So it's questionable whether this was actually ever used. |
| Leo: I certainly hope not. Can't recommend it. |
| Steve: But certainly it [crosstalk]. And just so people know, there are neat little tools that homeowners can use where you plug a little transmitter into an outlet, and it sends a signal out the wires, and then over by the breaker box you're able to use a probe in order just to get near the handle of the breaker. And you'll hear the sound increase when you're over the breaker that's associated with that particular plug. |
| Leo: Perfect, perfect. |
| Steve: So there are actually recommendable solutions. This is not one of them. |
| Leo: That will not hurt anybody. |
| Steve: In a pinch, I mean, if you had no choice. But no, don't do that. Probably better just to shut the whole house down if that's your - if you're unable to find the specific breaker. But, you know, anyone who's been in a house for long has probably encountered this problem; and one person had an enterprising, not recommended, solution. |
| Leo: No. |
| Steve: Okay. So a bit of additional interesting information surfaced about the Microsoft SharePoint zero-day remote code execution vulnerability after our coverage of this last week. I'm glad I was skeptical of The Register's allegation that someone within Microsoft's MAPP program had leaked the information. We're going to be talking about the MAPP program at the end of the show, of course. But we don't have any evidence of that. I believe The Register picked this idea up, however legitimately, from someone at Trend Micro's Zero-Day Initiative, and that was unfortunate because speculation really doesn't have a role here. But first remember that, even so, that initial pre-release of the SharePoint was not the big issue. You know, it's true that somebody was found to be exploiting this vulnerability on July 7th, the day before, you know, one day before the official patch was released on July's Patch Tuesday. But the big mess did not occur until after Microsoft's botched patch was made public. At that point everyone was able to compare the modified new code against the original old code to immediately zero-in on the location of the problem and design a workaround for it. But it was still troubling that someone did exploit the original completely unpatched vulnerability the day before anyone was supposed to know about it. All supposed to be, you know, non-disclosure agreement secret. Nobody knows until the patches come out. So how'd that happen? ProPublica offered an interesting theory that did not require any of Microsoft's MAPP program participants to leak anything. ProPublica's headline was "Microsoft [get this] Used China-Based Engineers to Support Product Recently Hacked by China." In other words, whoops. ProPublica's subhead noted: "Microsoft announced that Chinese state-sponsored hackers had exploited vulnerabilities in its popular SharePoint software, but did not mention that it has long used China-based engineers to maintain the product." Okay, that's news. They wrote: "Last month, Microsoft announced that Chinese state-sponsored hackers had exploited vulnerabilities in SharePoint, the company's widely used collaboration software, to access the computer systems of hundreds of companies and government agencies, including the National Nuclear Security Administration and the Department of Homeland Security. The company did not include in its announcement, however, that support for SharePoint" - meaning patches - "is handled by a China-based engineering team that has been responsible for maintaining the software for years. "ProPublica," they wrote, "viewed screenshots of Microsoft's internal work-tracking system that showed China-based employees recently fixing bugs for SharePoint 'On-Prem,' the version of the software involved in last month's attacks. Microsoft said the China-based team 'is supervised by a U.S.-based engineer and subject to all security requirements and manager code review.' Then they also said: 'Work is already underway to shift this work to another location.'" Yeah. "It's unclear," they wrote, "if Microsoft's China-based staff had any role in the SharePoint hack. But experts have said allowing China-based personnel to perform technical support and maintenance on U.S. government systems can pose major security risks. Laws in China grant the country's officials broad authority to collect data, and experts say it's difficult for any Chinese citizen or company to meaningfully resist a direct request from security forces or law enforcement. The Office of the Director of National Intelligence has deemed China the 'most active and persistent cyber threat to U.S. government, private-sector, and critical infrastructure networks.' "ProPublica revealed," they wrote, "in a story published last month that Microsoft has for a decade relied on foreign workers including those based in China to maintain the Defense Department's cloud systems, with oversight coming from U.S.-based personnel known as digital escorts. But those escorts often don't have the advanced technical expertise to police foreign counterparts with far more advanced skills, leaving highly sensitive information vulnerable, the investigation showed." Okay, now, I'll just note also that, you know, this escort service Microsoft runs would not prevent foreign coders from learning about vulnerabilities. They must know about vulnerabilities in order to fix them. So this entire digital escort concept seems like a crock, at least as regards, controlling leakage of information. ProPublica continued, writing: "ProPublica found that Microsoft developed the escort arrangement to satisfy Defense Department officials who were concerned about the company's foreign employees, and to meet the department's requirements that people handling sensitive data be U.S. citizens or permanent residents. Microsoft went on to win federal cloud computing business and has said in earnings reports that it receives 'substantial revenue from government contracts.' ProPublica also found that Microsoft uses its China-based engineers to maintain the cloud systems of other federal departments, including parts of Justice, Treasury, and Commerce." So this of course is where we march out our favorite byline or slogan, "What could possibly go wrong?" "In response to the reporting, Microsoft said that it had halted its use of China-based engineers to support Defense Department cloud computing systems, and that it was considering the same change for other government cloud customers. Additionally, Defense Secretary Pete Hegseth launched a review of tech companies' reliance on foreign-based engineers to support the department. Senators Tom Cotton, an Arkansas Republican, and Jeanne Shaheen, a New Hampshire Democrat, have written letters to Hegseth, citing ProPublica's investigation, to demand more information about Microsoft's China-based support." And they ended their coverage of this by writing: "Microsoft has said that, beginning next July" - next July - "it will no longer support on-premises versions of SharePoint." |
| Leo: That's almost a year. |
| Steve: Yeah. "It has urged customers to switch to" - and this is the problem is nobody wants to switch. And actually I've got some great feedback from one of our listeners that I'll share next week, who explains in some detail what enterprises really do face. I mean, and it is such a mess, Leo. I mean, oh. You know, you'd rather license... |
| Leo: Well, there's a solution. Fix your software, Microsoft. |
| Steve: Yes, exactly. Ultimately that's the problem. Exactly right. They wrote: "It [Microsoft] has urged customers to switch to the online version of the product, which generates more revenue" - this is ProPublica. I know it sounds like me, but no - "generates more revenue because it involves an ongoing software subscription, as well as usage of Microsoft's Azure cloud computing platform. The strength of the Azure cloud computing business has propelled Microsoft's share price in recent years. On Thursday, it became the second company in history to be valued at more than $4 trillion." |
| Leo: Wow. |
| Steve: And that's because subscriptions, baby. If you can get those... |
| Leo: Yeah, yeah. |
| Steve: Yeah. Okay. So now it might be, Leo, that the call was coming from inside the house. Microsoft's own China-based coders were the maintainers of the SharePoint codebase. |
| Leo: Oh, no. Oh, my god. |
| Steve: This means that they were the ones who directly received the early information about the SharePoint vulnerability from the Pwn2Own competition by way of Trend Micro's Zero-day Initiative. It was Chinese coders who prepared the patch. But knowing this begs another even greater, and frankly far more worrisome question: Could the patch, whose initially defective design caused the majority of the damage, been deliberately botched by these Chinese developers? I'm not saying that that happened. But the circumstances at least present the question. And I think it at least needs to be asked. We would always assume that any botched patch from Microsoft could only be a mistake. What could Microsoft possibly have to gain from fumbling a patch of a critical CVSS 9.8 vulnerability in their own widely deployed enterprise file sharing server? At the very least, it's significant reputational damage. The tech press is now comparing this SharePoint fiasco to the similar 2021 Exchange Server debacle that's widely viewed as having been a catastrophe. But now we learn that the flawed patch didn't really come from Microsoft, at least not directly. The bad patch actually came from China, apparently subject only to some low-level oversight by a Microsoft escort. |
| Leo: Well, by the way, did you read who these escorts are? They're not technical. |
| Steve: Uh-huh. |
| Leo: They're military. They're just some guys. |
| Steve: That the DOD said, okay, we're going to give you a chair, and you just sort of, you know, talk to these... |
| Leo: They're not sufficiently technical to, for instance, notice that the patch fixes a symptom, not the cause. |
| Steve: Right, right. And so then we learn that Microsoft has decided to change now, has now decided to change that development process to move it away from China. You know, I hate that China and the U.S. are entering into a cyber cold war. But when Chinese state-sponsored attackers are actively attacking U.S. assets, there's no denying the fact. And we know from back-tracking the IP addresses that were found to be attacking Microsoft's On-Prem SharePoint servers, it was those same well-known Chinese state-sponsored attackers who jumped on this vulnerability with a vengeance. There's one other aspect that's been missing from all the reporting. And that's to note that the fact that the first attack on SharePoint servers was detected on July 7th, the day before July's Patch Tuesday, does not mean that July 7th was the first day of any attack. We've talked about this many times before, and we've seen it in practice. The optimal strategy for anyone who's in possession of an unpatched, critical, unknown zero-day remote code execution exploit is to use that unique advantage with extreme care so as to remain off the radar and prevent the raising of any alarm for as long as possible. You want to carefully choose your targets, remain quiet, and infiltrate the most valuable networks first, before the rest of the world wakes up to the fact that on-premise SharePoint servers can be remotely compromised. The implementation of this strategy suggests that widespread exploitation of the flaw, which would have quickly become evident, may have been deliberately held back until just the day before the Patch Tuesday release, at which point it was unleashed with full automation so as to rapidly penetrate as many remaining SharePoint servers as possible just before the patch was made available. What we now know is that Chinese developers working for Microsoft would have been informed of this shortly after May's Pwn2Own competition. And now even Microsoft appears to be uncertain of where their loyalties lie. And now we also know that the patch did not completely work. Whether or not this occurred deliberately in this instance, it seems the height of recklessness for Microsoft to be outsourcing its software development to China while China is actively - and successfully - attacking the same software systems it's developing for Microsoft. What's wrong with this picture? |
| Leo: It's really suspicious, now that you say this. This is, I mean, it was a bad patch. It didn't work. |
| Steve: Right. And as a consequence, the U.S. suffered tremendous damage. |
| Leo: Yeah, all the damage was subsequent to the first patch; right? |
| Steve: And who did that benefit? |
| Leo: Yeah. |
| Steve: And who did that hurt? |
| Leo: Yeah, Microsoft wouldn't have done it on purpose. |
| Steve: No. No, it would have been reputational damage for them. But by making it a bad patch, it's okay, whoops. |
| Leo: Whoops. |
| Steve: And we've seen it before. It's not like it's the first time this has happened. And so even Microsoft now appears to have reached a similar conclusion and has said they'll be moving this activity elsewhere. Well, not a moment too soon, Microsoft. Ouch. |
| Leo: Unbelievable. |
| Steve: Yeah. And... |
| Leo: You couldn't make this up. This is like fiction. |
| Steve: I know. It's amazing. |
| Leo: But nobody would believe it. Nobody would say, well, of course they're not going to use China to fix the bug. Oh, boy. Geez Louise. |
| Steve: And Leo, they have an escort. What could possibly go wrong? |
| Leo: A babysitter who doesn't know anything about coding. |
| Steve: Yeah. |
| Leo: Well, good reporting from ProPublica. They're really good. I'm very impressed, yeah. |
| Steve: Yeah, they did a great job on saying, you know, you might want to think about this. |
| Leo: Yeah. Somebody made the point in the Discord that, even if you did the patch work in the United States, we're so compromised at this point, you don't even know if that would be good enough. I mean, they needed, clearly, wherever they're doing it, a chain of command of competent people reviewing the code. |
| Steve: Yeah. |
| Leo: Multiple people. Why wouldn't they have that, reviewing the patch? Why wouldn't they have that? |
| Steve: Well, and, you know, we've talked about this, too. It's been - remember those printer flaws where it took - it was month after month after, I mean, they kept trying to fix it, and they just like seemed unable to get it right. |
| Leo: You said they probably had an intern working, a summer intern working on it. |
| Steve: Yeah, I mean, so it's not only can they not get it right initially, but when someone says look over, I mean, the people finding the flaws were pointing at it and said, here's the problem. Here's what you need to fix. And they didn't. They said, oh. I mean, it's like the guy that it was assigned to fix it said, oh, look, here's the symptom. I've got to keep this from happening. |
| Leo: Right. |
| Steve: But no, fix the underlying flaw. |
| Leo: But remember? Isn't that what the AI did? We were talking about that vibe coding? |
| Steve: Yes, yes. |
| Leo: And that was Microsoft, too, by the way. |
| Steve: Yes. It was. It was over on GitHub. There was a flaw, and the guy who was doing the oversight pointed at AI and said, aren't you just - it was like it was a regular expression that had a bad - when it was backtracking, it underflowed the stack. And so the question was, why is the algorithm causing the stack to underflow? Instead it put a test on it to prevent the underflow. |
| Leo: We didn't find it. |
| Steve: Without fixing the problem. So, yeah... |
| Leo: And by the way, I was talking to Paul Thurrott. That guy is a very senior guy at Microsoft. |
| Steve: Yes. |
| Leo: And he caught it. But that's just the problem. You have non-senior people looking at these patches who don't have the skills to say, [crosstalk] fix the symptom. |
| Steve: And Leo, and when you think about it, having a highly skilled person overseeing AI doesn't help. |
| Leo: Yeah, right. |
| Steve: What's going to happen is that AI is going to end up getting one of these DOD, you know, escorts. Let's give the AI an escort. |
| Leo: Well, but in this first - in that case, though, you had this senior guy caught it and blocked it. It's pretty clear that you didn't have anybody senior looking at this patch. |
| Steve: Right. You know, does it fix the problem? Yeah, doesn't happen anymore. Okay, good. |
| Leo: They've got to start taking this stuff more seriously. That's terrible. Unbelievable. |
| Steve: Yeah, again, you know, China is the one attacking us, and they're writing the software which they're attacking. What? |
| Leo: I'm sure they're very adept coders. |
| Steve: Oh, yeah, they're as good as we are. Of course. |
| Leo: Yeah, better in many cases. |
| Steve: Everybody's got great coders. That's, you know... |
| Leo: Yeah. |
| Steve: That's a thing now. Let's take a break, and we're going to talk about Russia attacking their own embassies within their borders, and how that happens. |
| Leo: God. What a day. What a life. What a world. What - I don't know how we got in this timeline. It's just... |
| Steve: We're not running out of things to talk about. |
| Leo: We're not, so not running out of stuff. |
| Steve: So Microsoft's Threat Intelligence group posted a report detailing one way Russia has arranged to intercept and monitor the Internet traffic of the foreign embassies operating within its borders. It was so diabolical that I wanted to share it with our listeners. Russian ISPs all have SORM (S-O-R-M), which is the System for Operative Investigative Activities. That's this equipment installed on their premises that gives the Russian government the ability to tap and intercept access to any of the ISP's customers. But of course all communications are encrypted and authenticated. Right? Well, that's what Russia somehow needed to get around. What Microsoft discovered has been going on for at least a year. The company attributed the attacks to a group it tracks as Secret Blizzard, and it's a group we've talked about before. They're also known as Turla. Previous reporting has linked the group to something known as Center 16 of the Russian FSB intelligence agency, which manages most of the FSB's signal intelligence units. So all that tracks and makes sense. The group first selects specific targets and redirects them to an ISP captive portal. Which, you know, happens when you're sometimes connecting through ISPs. That portal explains to the person wanting to connect to the Internet that they need to update their Kaspersky antivirus. Of course, Kaspersky's a Russian brand, so it's trusted within Russia. The alleged AV update package actually installs a new root certificate into the victim's computer, along with a malware strain known as ApolloShadow. The malware relaxes the victim's firewall rules while the new root certificate, as we know, serves to legitimize malicious traffic, or at least to accept malicious certificate signatures. So from that point on, Russia is able to freely impersonate any remote site the compromised target may visit. They perform an adversary-in-the-middle attack, synthesizing a certificate for a remote website on the fly for the target to obtain fully unencrypted and visible plain-text traffic. So they get to see everything that's going on. Anyone using an SSL/TLS, even an SSL/TLS-style VPN, whose server certificates chain down to standard local root certs, will have all of their VPN network decrypted and inspected. So I hope that the internal embassy IT staff are routinely checking for the appearance of any "extra" certs or any change to the root stores of the machines that they're responsible for, since otherwise this would be a tricky attack to catch because we know as users, routine users of remote HTTPS sites, there's no visibility unless we go deliberately looking into which certificate we've received and who has signed that certificate. You've got to, you know, look, you know, got to bring up the certificate, view the certificate, look at the certificate's chain of trust, and see who the signer is. And that can be spoofed, as well. So it's a mess. Microsoft didn't say which embassies Turla had attacked. But taking into account that Turla uses a fake Kaspersky update, their assumption is that it may be Russian-friendly countries from Africa, the Middle East, and Latin America that still use software that's been largely banned from official government use across most Western democracies. One would hope that no one in a U.S. embassy in Russia - if we even still have one that's open. I think I remember that we pulled everybody out of there a long time ago. But any Western democracy's embassy hopefully is saying, I don't think we want to update our Kaspersky AV because, after all, we're not using Kaspersky AV. So why would we be updating what we're not using? So hopefully a little bit of caution would go a long way. But for Russian-friendly countries, maybe not so much. And this gives Russia complete access to all of their embassy traffic. I was unaware that Dropbox offered their own password manager. And obviously, Leo, you and I are not using it and probably never have. But if any of our listeners might have ever used it, inertia being what it is, who knows? Some may still be. So I just wanted to mention that Dropbox Passwords, which is the name of this password manager, is being discontinued this coming October 28th. So get ready to switch. I would make the switch now. And of course we recommend one of our sponsors, Bitwarden, as a terrific alternative, getting better all the time. Good old Meredith Whittaker is once again threatening to leave another country. Signal Foundation's president has been pushed to, once again, threaten to withdraw all availability of their Signal app, their Signal messenger app, this time from Australia. She recently proclaimed that Signal would leave Australia if the government attempted to force it to backdoor its encryption or demand unencrypted user data through any means. As we know, she's voiced similar threats to pull Signal from other countries that explored encryption backdoors. In the past we've seen that happen in France, Sweden, and the UK. And as we noted last week, the European Union's newest head plans to once again push forward on legislation this coming October. October is going to be a busy month for the security world, Leo. We've got all of, you know, Microsoft's stuff is ending, and the EU is going to be moving forward and lots of things happening that month. Anyway, as was noted by last week's coverage here on the podcast, the EU is now planning to leave the encryption itself alone and to, instead, attempt to perform surveillance outside of the encrypted channel, so both before data enters and after it exits from the encrypted channel. Since this might not involve Signal, which accepts incoming data from the underlying OS and asks for its display by the OS, I wonder what Signal's position would be in that case because it's not Signal that is being in any way changed or compromised. And of course that begs the equally interesting question which is what would Apple's position be, since this would make the design of iOS complicit in turning everyone's iPhone into known surveillance devices. Everything we know about Apple suggests that they would never be willing to turn their iDevices into state surveillance tools. Some sort of reckoning appears to be on the horizon. In the present case of the Signal uproar, the publication Information Age added a little bit of background. They said: "Laws enabling government access to encrypted private messaging platforms would make Signal's Australian operations a 'gangrenous foot' that would have to be cut off by shutting - by shutting down all local operations." And this is gangrenous foot. That's what Meredith called it. That was her term. |
| Leo: Sounds like another Chinese ransomware gang, but okay. |
| Steve: Uh-huh. That's right. "Ongoing demands from the likes of ASIO, whose director Mike Burgess has been trying for more than five years to get more power to monitor encrypted messages, have maintained friction between the two communities that has yet to be resolved. "Citing the importance of human rights and secure communications as key privacy rights, Signal's president Meredith Whittaker told The Australian that 'For many people, private communication is the difference between life and death.' Even if it were technically possible to snoop on Signal messages - which it is not, due to the platform's zero knowledge encryption design - she warned that Australian laws mandating access via engineered 'back doors' would risk user security worldwide. "With 'millions' of Australians using Signal, Whittaker said withdrawing from the country 'would hurt the people who rely on us'" - those are in quotes - "but added that she would not hesitate because 'if you let the gangrene spread, you poison the body.' Among the users affected by such a move," they wrote, "would be the government itself, which - despite police bans on the use of the apps - has allowed Signal and its disappearing messages to be used by Home Affairs" - which is an official office - "and other agencies since COVID began. A recent review of 22 Australian government agencies by the Office of the Australian Information Commissioner (OAIC) found widespread use of secure messaging apps even though many lacked appropriate policies for security and transparency. "Individuals grilled over their use of Signal include Foreign Affairs Minister Penny Wong and Burgess himself, even as he continues to agitate for access to apps he says are go-to platforms for extremists and 'aggressive and experienced' spies targeting Australia. "Whittaker's comments come from reports the government - whose Encryption Act stops short of requiring backdoors - has been intensifying pressure on Signal amidst an escalating campaign to strengthen investigation, interrogation, and other powers. "The focus on Signal is notable," they wrote, "given that it has only 40 million users worldwide - a fraction of WhatsApp's 2.5 billion, WeChat's 1.37 billion, and Messenger's 1.36 billion - and accounts for just 0.85%" - so less than 1% of the U.S. messaging app market last year. Yet its user base skews towards government executives, journalists, whistleblowers, and other highly security-aware individuals" - we know why, right, because it's the best - "attracted to perceptions that it offers higher security that cannot be compromised by court orders." And of course that's the reputation it's got due to Meredith's continual proclamations. They finish, writing: "Concern about laws compromising that security have grown so much that media outlet The Guardian recently tapped the University of Cambridge to develop an open source tool enabling end-to-end secure messaging for whistleblowers inside of its own news app," inside of The Guardian's own news app. So it's interesting that the Australian government is targeting Signal. And I wonder whether they might be deliberately aiming at a smaller fish first to see whether they can get capitulation from them, then use that to climb the ladder to larger targets, saying: "Well, Signal did it for us, so why can't you, too?" Of course one problem is that it seems very clear that Signal is never going to do anything for them. You know? The other is that politicians who have no understanding of the technology are making these requests. The entire industry, the entire industry keeps telling all the politicians no, and they keep insisting that the industry is just being stubborn and just doesn't want to do it for them. They assume they can ask for any feature they may want, and the techies will somehow figure out how to deliver it. In the case of Signal, they may be failing to appreciate that Signal's entire existence surrounds their refusal to capitulate. Meredith's repeated clear and well-publicized public refusals to compromise on Signal's integrity is of significant marketing value to Signal. Just, you know, as Information Age's article said, that's why the government is using Signal is they're the ones the government trusts to be safe and secure for their own internal messaging. Given the well-publicized moves that the EU may soon be making, that is, that stuff coming in October, I would be surprised if Australia increases its pressure further. I expect that the world will now be waiting and watching the EU. I know that everybody on this podcast will be. And of course we'll be covering that as it happens. I gave this next piece the title "YouTube deploys age-estimation heuristics." We've spoken about heuristic solutions broadly in the past. I generally dislike them because they're inherently fuzzy touchy-feely rules, you know, they're rules of thumb that don't always do what we intend. But there are times when they're all that's available. Last week the official YouTube blog posted under the headline "Extending our built-in protections to more teens on YouTube," with the subhead "We're extending our existing built-in protections to more teens on YouTube using machine learning age estimation." So here's what they wanted the world to know. They wrote: "People come to YouTube to learn and be entertained. This is true even for the youngest audiences, and it's why we remain laser focused" - and Leo, every time I see that phrase I think, well, you don't have to focus a laser. So I'm not really sure [crosstalk]. Okay. |
| Leo: Focused like a laser maybe. |
| Steve: Focused like a laser, that's good, "...on making sure they have a safe and age-appropriate experience. Over 10 years ago we launched YouTube Kids, and four years ago implemented supervised accounts for pre-teens and teens. Back in February, we shared that we would soon introduce technology that would distinguish between younger viewers and adults to help provide the best and most age-appropriate experiences and protections. Over the next few weeks" - and this was in their blog last week. So they said: "Over the next few weeks we'll begin to roll out machine learning to a small set of users in the U.S. to estimate their age, so that teens are treated as teens and adults as adults. We'll closely monitor this before we roll it out more widely. This technology will allow us to infer a user's age and then use that signal, regardless of the birthday in the account, to deliver our age-appropriate product experiences and protections. We've used this approach in other markets for some time" - meaning non-U.S. markets - "where it is working well. We are now bringing it to the U.S., and as we make progress we'll roll it out to other markets. We will closely monitor the user experience, and partner with creators to ensure that the entire ecosystem benefits from this update. "Here's how it works. We will use AI to interpret a variety of signals that help us to determine whether a user is over or under 18. These signals include the types of videos a user is searching for, the categories of videos they have watched in the past, or the longevity of the account. When the system identifies a teen user, we'll automatically apply our age-appropriate experiences and protections, including disabling personalized advertising, turning on digital wellbeing tools, and adding safeguards to recommendations, including limiting repetitive views of some kinds of content. If the system incorrectly estimates a user to be under 18, they will have the option to verify that they are 18 or over, such as using a credit card or a government ID. We will only allow users who have either been inferred or verified as over 18 to view age-restricted content that may be inappropriate for younger users." So I presume that the experience of a YouTube viewer who is deemed to be under 18 is that, as this rolls out, they will lose access to content that they may have had access to before because YouTube will decide, okay, based on the history of your viewing experience, we think you're under 18. So now the over 18 content is no longer, you know, showing up in your search results. You don't have access to it. It's not being selected for you. And the behavior of the platform changes in age-appropriate ways. So I think until we obtain proper online age verification solutions, heuristics are probably the best we can do at this point. And it's more responsible than doing nothing. And I think it's reasonable for YouTube to examine a user's viewing history. And if they clearly appear to be a younger viewer, modify the platform's behavior to better suit that viewer. And they do offer a path for optionally allowing people to assert that, whoop, you've made a mistake in my case. I'm not under 18, and I'm willing to prove it to you. So, and Leo, when they talk about the longevity of the account, I assume they mean that if an account is newly created, they'll be much more skeptical, right, because they don't have a history yet to... |
| Leo: Or if it's 18 years old, then they know you're at least 18. |
| Steve: Ah, that's a very good point, isn't it, yeah. |
| Leo: I mean, YouTube hasn't been around that long, but it's getting there. You know, if you've had it for 10 years, you're probably not a 12 year old; right? |
| Steve: That's a very good point, yeah. |
| Leo: Yeah, yeah. |
| Steve: Google has just rolled out an optional feature they're calling "Verified CRX Upload." Now, we've talked about the danger presented by the compromise of high-profile extension developer accounts, and it's happened; right? If bad guys are able to somehow get into a developer's account, until now nothing would prevent them from maliciously modifying the extension, uploading it to the Chrome Store, and causing all instances of Chrome to update and begin using the malicious code. Now, Google allows developers to create a 2048-bit RSA public/private key pair and to provide the public key to Google for use in verifying the signature of any Chrome Extension that's subsequently offered by the developer. Google's instructions to developers make very clear that they must not, in any way, store their private key in any of their Google assets; right? Because you don't want to put the key where it could be compromised. You know, it should never be uploaded. And, in fact they provide the OpenSSL one-liner, the OpenSSL command one-liner to generate the key pair in a console session outside of any browser: openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048, and then they set the output to privatekey.pem. And so once the public key has been provided to Google, no Chrome extension that is not properly signed by its matching private key, which Google, no aspect of Google will ever touch that private key, no Chrome extension not properly signed by the matching private key will be accepted for publication. So I love this. It's very clear, it's very clean, and as lightweight as could be. They're adding another completely independent layer of authentication to the process. The onus is on the developer to not misplace their private key, as well as to keep it out of the hands of any attackers. But the flipside is the developer gets absolute protection that, if anything should ever compromise their account, the fact that they have an offline private key and know that Google will be checking it against the public key they gave them previously, that protects the developer. So, yeah, the developer's got some responsibility, but they're getting a tremendous benefit in return. Google's instructions say: "Don't upload the private key to any public repository or other place. Don't store your private key in your Google Account. This means someone with access to the Developer Dashboard through your Google Account could publish on your behalf. Consider storing your private key securely using a keystore like PKCS#12 or Java Keystore." And then "Warning: Don't lose your private key; otherwise, you must reach out to CWS support, and replacement can take up to one week." Because of course they're going to want to make sure that you're you, and not a bad guy trying to compromise this protection. So anyway, this is terrific. Minimal, sufficient, and bulletproof. No need for any certificate rigmarole since the authenticated developer is creating the key pair and uploading only the public key to Google where it cannot be changed once it's been set. So it is a perfect free and lightweight solution. And, you know, this is the kind of - this is like, why did it take them so long? But I'm glad it's there now. It's just a perfect way to solve this problem. Okay, Leo. We're going to take a break. Then we're going to look at the interesting case of a domain registrar that's on the ropes right now. We've not talked about this before, but wait till you hear what these clowns have not been doing, and what the consequences are. Wow. |
| Leo: Yeah. Back to you, Steve. |
| Steve: Okay. Through the past 20 years we've looked at many instances where a Certificate Authority was repeatedly found, documented, and proven to be acting irresponsibly, either by design or through carelessness. In those instances, when that behavior did not change, those certificate signers had their signing privileges revoked, and their businesses were effectively ended. You know, it's a privilege to be able to charge people for a digital signature, and with that privilege comes the responsibility to do so properly. There's another somewhat related privilege that the Internet offers, which is the privilege to charge people for domain names they wish to use, and to have those domain names registered with the Internet's DNS servers so that traffic addressed to those domains will be able to find its way to the registrant's domain-based servers and services. I don't recall that we've ever encountered a story of misconduct on the part of a domain name registrar where their continued right to register domain names - and charge a nice fee for the privilege - was close to being lost. Today we have such a story. Last Wednesday, the publication Domain Name Wire - there actually is such a thing - posted some news under their headline "ICANN sends breach notice to domain registrar WebNIC." And Leo, you should bring up WebNIC.cc. |
| Leo: Okay. |
| Steve: It looks like a going concern. I mean, it's like, who wouldn't trust these people? |
| Leo: Yeah. |
| Steve: But just wait till you hear. You know, wow. The subhead of Domain Name Wire's coverage was "Domain industry overseer" - which, you know, would be ICANN - "says domain registrar is lax" - and boy, are they - "when investigating and responding to DNS abuse complaints." Here's how the story was told by Domain Name Wire. And we've got it here on the screen, Leo. I mean, it looks like a legitimate, like, who would not trust these guys? Right? |
| Leo: Yeah. |
| Steve: Oh, look at that, DigiCert, wow, wonderful. And, you know, they're namedropping, and they've got logos for everybody. Turns out they're doing something wrong with the ICANN logo, which is part of the... |
| Leo: Yeah, the ICANN logo's on here, yeah. |
| Steve: And apparently it's not supposed to be in the way that they did it. Anyway, the guys wrote: "ICANN has sent a breach notice to Web Commerce Communications Limited dba [doing business as] WebNIC.cc, a fairly large domain name registrar in Asia. WebNIC has about 500,000 dotcom domain names under management in addition to domains in other extensions. ICANN says the registrar is not complying with Section 3.18.2 of the registrar accreditation agreement (RAA)" - we'll be hearing that abbreviation a lot - "the registrar accreditation agreement which addresses DNS abuse mitigation. In other words, people who have registered domains there are abusing their domain names egregiously without any consequences." They wrote: "The organization said WebNIC failed to follow appropriate steps when receiving DNS abuse complaints. ICANN's notice said" - and now they're quoting ICANN. "ICANN has observed a concerning pattern regarding DNS Abuse mitigation requirements in cases involving WebNIC. In multiple instances reviewed by ICANN Contractual Compliance" - that's an official department, ICANN Contractual Compliance - "actionable evidence of DNS Abuse was provided to the registrar through abuse reports. "However, mitigation actions were repeatedly delayed and, in some instances, only taken after the abuse reporter escalated the matter by submitting a complaint to ICANN. The registrar frequently issued repeated requests for evidence to abuse reporters, even when the abuse reports appeared already to be actionable, and failed to fully consider information or clarifications provided by the abuse reporter, ICANN, or otherwise reasonably accessible to the registrar. In other cases, the registrar requested evidence from the abuse reporters that did not appear to be relevant to the reported activity, causing additional delays." In other words, this registrar is just not doing their job, not holding up their end of the agreement, literally. The reporting said: "ICANN said the registrar frequently responds to ICANN Contractual Compliance notifications on the last day of the deadline or after it has passed, and those responses are incomplete. Additionally, ICANN says the registrar is not displaying information on its website that is required, including the details of the registrar's deletion and auto-renewal policies, the registrar's renewal and redemption/restore fees, the methods used to deliver pre- and post-expiration notifications, the name and positions of the registrar's officers, and the name of the ultimate parent entity. ICANN Compliance has been contacting the registrar about issues since at least February of this year. Finally, WebNIC has until August 19" - that's two weeks from today - "to cure the violations, or ICANN will begin the termination process." So once again, this just makes me shake my head. More than 500,000 dotcom domains, in addition to many others. You know, that enterprise is probably generating at least 10 to 15, probably many, many more, million dollars per year, for basically just setting up an eCommerce website, taking registration information, and maintaining accounts. And apparently, just as we've seen several times in the past with the Certificate Authority business, the owners and managers appear to have lost sight of the fact that this ability to print money is a privilege. It's not a right. And it's a privilege that can be withdrawn and lost. And we have seen that happen over on the CA side. So this made me curious to know what these WebNIC people had and had not done. So I tracked down the notification that ICANN had sent to WebNIC. Now, once again we see that ICANN is falling all over themselves to give these apparent cretins every benefit of the doubt and chance and opportunity to save their own skins. The notice that I found indicated that it had been sent on July 29th. That's exactly a week ago. And it was transmitted finally, after months of communication failures, via electronic mail, facsimile, and courier. Here's what ICANN sent with the title "RE: NOTICE OF BREACH OF REGISTRAR ACCREDITATION AGREEMENT." They wrote: "Please be advised that as of 29 July 2025, Web Commerce Communications Limited dba WebNIC.cc, hereinafter referred to as 'WebNIC' or 'Registrar,' is in breach of its 2013 Registrar Accreditation Agreement with the Internet Corporation for Assigned Names and Numbers ('ICANN') dated 25 October 2023 ('RAA'). This breach results from WebNIC's failure to comply with Section 3.18.2 of its RAA concerning Domain Name System abuse mitigation." So under "Additional Concerns" in this notice it then lists those website documentation issues that were mentioned in the news report that I already shared. The notice also states that "The ICANN logo on WebNIC's website does not appear to conform with the requirements in the Logo License Specification of the RAA." The notice gets into some interesting bits, writing: "To cure the breach, WebNIC must take the following actions by 19 August 2025, 21 days from the date of this letter." And since that was one week ago, that's two weeks hence. So that's exactly, you know, here are the steps that ICANN requires of WebNIC by two weeks from today. First, they wrote: "Explain all steps the Registrar took to reasonably investigate and reach a determination regarding the use of the domain names us-ledger[.]com, uni-stores-info[.]com, tronlink[.]trading, tronink[.]net, theuni-swap[.]com, thebalan-er[.]com, raydiumx[.]org, kodiak-finance[.]org, app-uni-infos[.]com, and keplr-apps[.]net for DNS Abuse before and after being contacted by ICANN Contractual Compliance regarding these cases. The explanation must include evidence of each step taken and the date each step was taken." Now, so there's a list of domains that have been under significant abuse such that the registrar was contacted, told what was going on, given evidence of what was going on by probably legitimate security firms. You know, CrowdStrike, Palo Alto Networks, you know, we know them all. We report on their actions. They're the guys who see bots and spam and phishing and all this, and say to the registrar, hey, you've got some bad guys who've registered domains with you, and you need to take them down. Silence. Static. Nothing. When nothing happens, then the security firms contact ICANN and say, hey, we've reported to this WebNIC.cc gang that bad guys are abusing their domain name privileges, and we've never heard anything from them. They're just ignoring us. So ICANN tries to do it, and they ignore them, too. Second thing on the list: "Explain why the evidence that the Registrar possessed regarding the use of the domain names listed in Item 1 at the time the Registrar investigated the initial abuse reports submitted by the reporters was deemed insufficient to compel WebNIC to reasonably investigate and determine whether the domain names were being used for the specific type of DNS Abuse reported, if applicable." In other words, we're going to assume you are honoring your agreement, so we're confused. Explain to us in each case why, after investigating these reports, as we assume you did because, after all, you're a domain registrar in good standing, how the evidence that you obtained from your investigations failed to motivate you to take action. We need, you know, we need to understand that. And you need to provide evidence that convinces us. Right. Good luck. Three: "Explain the process the Registrar has implemented to enable WebNIC to fully and promptly assess and act on reports of DNS Abuse in the terms prescribed by Section 3.18 of the RAA. And this description must include: A, each step of the process and the date the step was implemented. B, the target response and mitigation timelines at each stage of the process, and how unnecessary delays are prevented and tracked. C, the criteria that the Registrar will generally use for evaluating the sufficiency and relevance of evidence submitted in DNS Abuse reports. And, D, an explanation of how, and how often, the Registrar will monitor and measure the effectiveness of this process to ensure continued compliance with DNS Abuse mitigation requirements." In other words, you guys are so deeply dug into this doghouse that you're going to have to really shape up here. Four: "Provide a link to the location on the Registrar's website where WebNIC displays the following information: Its renewal and redemption/restore fees," because, you know, we've been unable to find it so far. "A description of the methods used to deliver the Registrar's renewal notifications. The Registrar's deletion and auto-renewal policies. The names and positions of the Registrar's officers. The name of the Registrar's ultimate parent entity. The correct ICANN logo in accordance with the Logo License Specification of the RAA; or remove the ICANN logo from WebNIC's website." Five: "Provide evidence that the Registrar's registration agreement includes a link to the fees and descriptions referenced in items 4.a and 4.b above." And, six: "Provide the remediation measures the Registrar has implemented, including the dates of implementation, to ensure that WebNIC provides full and timely responses to ICANN Contractual Compliance matters. "If WebNIC fails to timely cure the violations explained in this Notice of Breach and provide the information requested by 19 August 2025, ICANN may commence the RAA termination process." In other words, we have finally run out of patience with you. You have exactly three weeks to explain your past flagrant lack of compliance with the agreement under which you are being allowed to print money, to bring yourself into compliance, and to prove it. If you once again fail to heed these warnings, as you repeatedly have all year, you will find that all of the domains you have had the privilege of renting to your customers will cease to function. They will be de-registered from the Internet's DNS, and you can deal with the fallout from that. Have a nice day. |
| Leo: Did they write "Have a nice day," or did you add that? |
| Steve: No, no, that's... |
| Leo: Okay. |
| Steve: That's going to be a very bad day. |
| Leo: Yes. What happens to somebody who has a domain registered with them if they get their... |
| Steve: Ah. We're going to get to that in a second, yes. |
| Leo: Okay, good. |
| Steve: There was also an attachment to this which was interesting. It was titled "Failure to comply with DNS Abuse mitigation requirements," and it read: "Section 3.18.2 of the RAA requires registrars to take prompt mitigation actions when they reasonably determine that a registered" - so this is also, this was an attachment to this notice, which is also what they received by email, fax, and courier a week ago. So just, like, no excuse for not knowing what agreement you signed a few years ago, which you're no longer - which you're in blatant breach of. They said: "Section 3.18.2 of the RAA requires registrars to take prompt mitigation actions when they reasonably determine that a registered domain name sponsored by the relevant registrar is being used for DNS Abuse which, for the purposes of the RAA, is defined as malware, botnets, phishing, pharming, and spam (when spam serves as a delivery mechanism for the other four forms of DNS Abuse) as those terms are defined in Section 2.1 of SAC115. The Registrar did not demonstrate compliance with these requirements with respect to the reports addressed in the compliance cases in the chronologies below." I'm not going to go into those. We then have the paragraph that was originally cited in that article, and that was about ICANN having observed continued pattern of neglect and abuse regarding these issues. And they also, they said: "This pattern was observed in multiple cases beyond those referenced in this notice of breach, including compliance cases," and we've got four serial numbers. So, I mean, they've just documented the crap out of the fact that this registrar is basically completely ignoring the work side of their money printing business and just taking people's money and getting the domain set up for them. So the attachment said: "On 25 July 2025, the Registrar informed ICANN Contractual Compliance that WebNIC had implemented certain improvements to its DNS Abuse mitigation processes as of 11 June 2025. However, a review of case records and communications after 11 June 2025 demonstrates that the Registrar remains out of compliance." In other words, you lied to us, and we know you lied to us, so we're just writing it down here so that you don't try to say you didn't. They wrote: "The Registrar has also developed a pattern of responding to ICANN Contractual Compliance notifications either on the last day of the specified deadline or after the deadline has passed, often providing incomplete responses and causing further delays and escalations. Moreover, ICANN continues to receive new complaints exhibiting similar allegations and patterns of noncompliance involving a large number of domain names registered with WebNIC. This ongoing behavior constitutes repeated violations of Section 3.18.2 of the RAA and facilitates the prolonged exposure of DNS Abuse to potential victims." In other words, people are being hurt, actively being hurt by this. So then they have chronologies stating day by day, week by week, dating back from February, of all the back-and-forth, and basically nothing has happened. They said: "In the compliance cases detailed in the chronologies below, ICANN notified the Registrar of the violations, including the relevant ICANN policies, agreements, and processes. Each communication requested the evidence, information, and actions needed from WebNIC to become compliant. Each subsequent communication to the compliance notifications constituted an additional attempt by ICANN to obtain evidence of compliance from the Registrar." "The telephone call details below describe further attempts from ICANN to communicate to the Registrar the details of the cases, and to make an ICANN Contractual Compliance staff member available to address any questions in order to assist WebNIC in becoming compliant. All efforts were unsuccessful." Basically, ICANN has just been blown off, as they say. So the bottom line is that the bad guys are using this Asian domain name registrar, the bad guys, you know, malware authors, using this Asian domain name registrar that's probably become known as a safe haven for registering malicious domain names that will never be taken down because these guys want to take their money, their registration money, and just ignore all the complaints that come in. So they're using this registrar to establish domain names that are being used for various malicious purposes. And when the abuse of these domain names - with ample evidence - is brought to this registrar's attention, they blow it off. Eventually, those reporting the abusive domain names - as I said, probably well-known and respected security organizations - decide they need to escalate this to and involve ICANN. At this point we see the same sort of falling all over themselves attempts from ICANN to not abuse their ultimate power of pulling the plug. And we've seen the same thing repeatedly from the CA/Browser forum members who really don't want to put a certificate authority out of business, but they're really left with no choice. Here, ICANN is giving these WebNIC.cc guys every possible chance to save themselves and to not be kicked off of the gravy train. I went over to their website, as I said. And Leo, you brought it up, www.WebNIC.cc. And it looks fantastic. It's got every bell and whistle you could ever want. Stuff is sliding in from offstage. It fades in and out, and it spins around as I scroll. There are photos of happy people working and children playing in the sun. Life is grand, and everything looks great. But apparently that's all just surface glitz created by some fancy web designer and a bunch of JavaScript. We know that underneath this fancy faade this registrar is behaving so irresponsibly that they may soon be out of business. This, of course, begs the question, as you said, Leo, what then happens to all of their hundreds of thousands of customers who were seduced by the glitzy website into entrusting their cherished domains to this registrar. ICANN has a procedure for handling that. ICANN asks around among other domain registrars in good standing to determine who would like to take over, in this case WebNIC's domains and their customers. ICANN appoints what's known as a "gaining registrar" - and you bet they're going to gain - to take over the affected domain names. There's even an acronym for this: BTAT stands for Bulk Transfer After Termination. All of the terminating registrar's domains are assigned to the gaining registrar, with the current domain registrants not needing to take any action. There's no discontinuity of service. They don't even know anything happened. ICANN then notifies the domain holders via email and public announcement. And, importantly, the current domain holder's rights are retained. Their domain registrations remain valid with their expiration dates and other settings preserved, and the new registrar has agreed to honor the remaining registration term. And existing registrants are then given the option to transfer their domain elsewhere if they prefer. So yes, down in the mess, down in the trenches, it's a mess. But it's the best that can be done under the circumstances. It's difficult to imagine that these guys are not going to come up with some, you know, some sort of face-saving attempt to hold onto their registrant status. Maybe this final notification will come to somebody's attention. They've got two weeks to somehow cook up a bunch of cockamamie excuses and stories to explain their previous negligence or to somehow convince ICANN that they'll deal with all of the past and do right going forward. It's going to be interesting to see what happens in two weeks. But, boy, what a sad thing to happen to a registrar. I mean, you know, they'll simply be out of business. |
| Leo: Do you want to take a break here? |
| Steve: Let's take a break, yeah. |
| Leo: Okay. |
| Steve: Because then we've got some feedback, and we're at about an hour and a half, so that's probably time. |
| Leo: Yeah, this would be a good time to do it. All right. You're watching Security Now! with the inestimable Steve Gibson. I don't know what that word means, but I think you are inestimable. |
| Steve: Sounds good. |
| Leo: Steve? |
| Steve: Okay. So if any of our listeners might still have an old TP-Link Archer C50... |
| Leo: I think a lot do. That was recommended by Wirecutter for years as the best router. |
| Steve: Unfortunately, it turns out it's got a problem. It's got a CVE 2025-6982. TP-Link made the mistake of encrypting its settings using DES, not triple, just one DES, in the least secure of all cipher modes, which is ECB, Electronic Code Book, where there's no chaining among successive blocks. You just independently encrypt each block. What this means is that it's possible for attackers to obtain all of the settings in the router, including the admin credentials, the WiFi passwords, and everything else that the router knows. So the routers are End-of-Life, and TP-Link is strongly advising that people just say goodbye, router, it's time for a new one. It's not an emergency. It's not a remote code execution vulnerability. But this is a serious concern for these routers. And newer routers offer much better security. A router's the kind of thing that, you know, I would give it a five-year life, and then it's probably time just to rotate the router out of service and put in a new one. |
| Leo: Yeah. New ones are better, faster, et cetera, et cetera, right. |
| Steve: Yeah, yeah. And they'll support the latest WiFi standards and so forth. So anyway, I just wanted to give everybody a heads-up. If there happens to be an Archer C50 around, you might want to go to TP-Link. You'll probably find some information there saying you want to get rid of it. |
| Leo: Yeah. |
| Steve: I think even CISA said, you know, stop using these because they're just not secure any longer. Okay. Before we examine specific listener feedback, I got one neat piece of feedback I want to share which launched me on an interesting journey. I wanted to note that many listeners said they're now going to give the Brave browser another try. And many others sort of asked rhetorically in email that I received, "What took you so long, Gibson?" Some said that they looked at Brave in the past and they were not impressed; but they looked at it again, and it seemed like it had gotten better. I've never really looked at it before. I like it from a privacy enforcing standpoint. So anyway, just wanted to - I got so many pieces of email from our listeners about Brave, I wanted to discuss it all at once from everyone. And thank everybody for their feedback, which I appreciated. Aaron Shaffer wrote, saying: "Steve, you seem to be entirely unaware of Apple's..." |
| Leo: I never finish emails that begin that way. |
| Steve: I know. |
| Leo: Okay. |
| Steve: "You seem to be entirely unaware of Apple's state ID program for Apple Wallet. Several states already have it deployed. A digital version of my Ohio driver's license has been in my wallet for the last year, for example. The state of Ohio has a free app that someone else can use for me to tap my phone to their phone to verify age from that digital ID. Correct me if I'm wrong, but it seems that all we need is some kind of API call to do the same validation for websites. Thank you for all your good work. I've been a listener since Episode 1. Aaron." Okay. So Aaron was completely correct in concluding that I had not been keeping up with the state of smartphone wallets and existing efforts. So I spent some time since seeing this note, looking into what's been going on in that space. In California, as in Ohio, we have a digital drivers license program. It goes by the abbreviation mDL for "Mobile Drivers License." And it looks like that's going to be a U.S.-wide abbreviation. There's a California DMV Wallet app for both Apple and Android phones, and it offers a system known as "TruAge." I installed the apps under both platforms - into my iPhone and into that $39 Samsung A15 smartphone I had just purchased, that I talked about a couple weeks ago, for Android - and I configured it. The app setup was quick and easy. The apps required me to show them the front and back of my California driver's license, and to then pose for facial recognition while it brightly illuminated the screen in various colors which were reflected off my face. Once that was done, the apps were satisfied, and I had effectively installed a biometrically locked digital driver's license into my phones. Next up was figuring out what TruAge was all about. The TruAge system was developed by NACS - the National Association of Convenience Stores - together with a nonprofit entity known as Conexxus. Conexxus is a retail-focused technology standards developer. Together, NACS and Conexxus developed the TruAge technology for the retail convenience store industry to support the purchase of age-restricted consumables such as alcohol and tobacco. In bragging about TruAge, they explain, they say: "TruAge verifies only age, not identity. It does not store name, address, eye color, et cetera, unlike many legacy ID scanners that may capture over 30 personal fields. The encrypted token cannot be linked back to you, and data is not sold or shared." Unfortunately, however, the "cannot be linked back to you" portion is not entirely true. I was immediately suspicious when I saw that the token presented was described as a single-use encrypted composite consisting of the presenter's driver's license number (whoops!), the issuing state, the license expiration date, and the presenter's date of birth. And sure enough, the CA.gov FAQ page says, in answering the question "What happens to the data you do capture?" they answer: "TruAge encrypts your data points and then protects them even further by creating anonymous tokens. These anonymous tokens cannot be traced back to you without legal authorization from a court-issued subpoena." |
| Leo: Oh. So they can be traced back to you, as a matter of fact. |
| Steve: Exactly. |
| Leo: Oh, but you have to have a court order. |
| Steve: Yeah. They finish, saying: "Neither retailers nor cashiers retain any of the extracted information." Okay. So it's true that in a retail convenience store setting TruAge will be far more privacy preserving than the traditional requirement of revealing a driver's license which discloses the individual's entire identity with their name, home address, exact date of birth and everything else in the clear. But, unfortunately, TruAge also fails the "minimal information sharing" test when the only thing being required is a proof of biological age. However, less than three months ago, this past May 15th, the NACS association, that association of convenience stores, proudly published a press release with the headline: "TruAge's Technology Named the De Facto Standard for Digital Age Verification" with the subhead: "The World Wide Web Consortium" - that's the W3C - "has incorporated TruAge's underlying technology into its new Verifiable Credentials." Okay, now that suggests that at least some aspects of the TruAge verification system will be coming soon to a web browser near us. So here's what they wrote. They said: "TruAge" - you know, and again, to do a little patting on the back - "the innovative, universally accepted age-verification system that makes it easier to more accurately verify an adult customer's age when purchasing age-restricted products, and its core-technology, have been incorporated into the latest W3C Verified Credentials, Verifiable Credentials 2.0, that were introduced today. "The World Wide Web Consortium is an international council created in 1994 to create and publish web standards to ensure the growth and development of the web. The new W3C Verified Credentials, which were ratified in late April by its governing body, are a comprehensive update to web standards and affirm that TruAge technology is the centralized standard for digital personhood, making TruAge the accepted standard for all applications that involve age verification. "Paul Ziv, TruAge's vice president of technology and operations, said: 'TruAge was developed to address strong consumer interest in using a trusted and reliable digital ID that combined consumer privacy and ease of use with the potential for mass retail integration, and it has delivered on that promise. It is very gratifying that W3C agrees with our vision and solution.'" Then back to the press release from TruAge: "Verifiable credentials are increasingly important as communications and commerce continues to go digital, because they can contain all the same information as physical credentials, similar to driver's licenses and other identification cards. Importantly, by adding technologies such as digital signatures, verifiable credentials can be tamper-proof and seen as more trusted than their physical counterparts. "TruAge scans all U.S. driver's licenses and is also incorporated into the State of California's mobile driver's license (mDL) and digital wallet. The W3C announcement makes TruAge the de facto standard for age verification that could be incorporated into all relevant code for pertinent products developed by companies including Microsoft and Apple. "While Verifiable Credentials 2.0 was approved to improve the ease of expressing digital credentials, there were also several privacy-preserving goals that were important; both of these objectives are central to the core of TruAge." Anyway, the article continues to elaborate and congratulate itself at some additional length. And it goes again to assert that: "It also provides admissible proof-of-age verification appended to retailers' transaction logs that can be unlocked under subpoena and submitted as evidence." So because TruAge explicitly and deliberately binds the credentialed user's identity into their age assertion, it does not do what we want for general purpose online age assertion. So we're left with the question of how much of TruAge's over-identification is actually part, you know, actually survived the W3C's new Verifiable Credentials 2.0 specification. Since things like driver's license number and issuing state are explicitly U.S. identifiers, and the W3C's specifications need to be global and country-agnostic, I assume that what the W3C may have inherited from TruAge is just its broad single-use encrypted token technology without there being any requirement for what's encrypted within that token. We'll see. Aaron's note started me looking into this with his mention of Ohio. But Ohio and California are not alone. The U.S. states currently offering some form of smartphone wallet storable digital drivers licenses include Arizona, California, Colorado, Delaware, Georgia, Hawaii, Iowa, Louisiana, Maryland, Mississippi, Missouri, New York, Ohio, Utah, and Puerto Rico. Additionally, Montana, New Jersey, Pennsylvania and Texas have pending mobile drivers license legislation underway, and 10 other states plus Washington, DC have announced their intentions to adopt mobile drivers licenses. So at the moment, you know, we're on the way as a country in the U.S. toward creating biometrically locked driver's licenses that are secure enough to be honored and carried around in our phones. I have in my little Android, you know, there's the California Mobile Drivers License app. |
| Leo: I have yet to have any occasion to use that after several years. |
| Steve: Yeah. Unfortunately, I do regret the goofy picture that I... |
| Leo: Well, that's the actual picture, though, isn't it? |
| Steve: Yeah. |
| Leo: That's from your driver's license. |
| Steve: Yeah. And that is from, you know, it's the original digital storage that California made when I last updated my driver's license. But in the show notes I have a picture of one of the panels that's available where, under age check, you're able to open up a set of brackets where one of them is over 18, over 21, over 25, over 62, and over 65. Unfortunately, I qualify for all of those. |
| Leo: Yes. Got to check them all, okay. |
| Steve: And I don't know yet anything more about that. I've not taken the time to dig into the underlying technology. So it's unclear how all of this is going to shake out and fit together. But for what it's worth, my experience with setting things up, at least in California, was surprisingly quick, easy, and streamlined. I now have, for what it's worth - I just did it, you know, in the way Jerry Pournelle used to do things, just to see what it looked like so I could talk about it a bit. I've got iOS and Android apps in my phones that are able to scan, you know, to look at my face, decide that's me, scan a website's QR code to in some fashion assert my full identity if I wish, or presumably whether I am only above a given age. And while we know that the TruAge system itself is asserting more than just our ages, it's still, you know, early days. And my guess is that what the W3C will wind up with will be a minimal information disclosure solution because that is all most people are going to be willing to put up with. None of this, you know, I mean, sure, maybe if you're buying tobacco or alcohol at a retail purchase location, this is better than revealing your full driver's license. But it's not, it doesn't do what we want for minimal information disclosure. Before we leave the topic I should also mention that, as I had hoped, and I mentioned this last week, Yubico's Stina Ehrensvard is all over this. Last Wednesday, after last week's podcast, she sent me a note which read: "Hi, Steve. Hope all is well. Please find our whitepaper on age verification at Internet scale." She attached a short five-page position paper authored by the SIROS Foundation. It's title is "Deployability First: Making Age Verification Work at Internet Scale." It has the subhead "A Position Paper for the 2025 Joint W3C/IAB Workshop on Age-Based Content Restrictions." Now, we couldn't ask for anything more on-point than that. And Stina is the founder of the SIROS Foundation. She's putting the money she made from first founding Yubico to very good use. And, Leo, you and I both know Stina. God help anyone who stands in her way. You know, she has a way of obtaining the results that she's after. So with Stina on the case, the world's needs for online privacy-respecting, age-based content restrictions are in the best hands possible. |
| Leo: Yeah. I'm really glad that she's taking this on. That's great. |
| Steve: Yeah, she is. And she will not settle for anything less than what we know is technically possible, which is no assertion other than a person is above a given stated age that they are wishing to assert. So, you know, and as Yubico's founder, she has earned her sway. I mean, people will listen to her. And, I mean, she knows everybody in the business. I mean, again, we couldn't ask for this to be in better hands. So I was certainly uninformed when I recently commented that nothing was happening on the age verification front. A great deal is happening, and the best possible people are at work on this problem. In the meantime, I looked for any sort of TruAge demo site, but I was unable to find anything. It looks like it's locked up in proprietary technology at this point. They're having to unlock whatever this encrypted token stuff is in order to have it be put into the W3C because that's going to be all open standards and open source and open implementation. And besides, this is not a hard problem to solve. These guys just did it for a cash register where you sell vape products. So, fine. I'm sure that what we end up with will be fully privacy enforcing. And before we take our last break and talk about China, I wanted to take a moment to say that Andy Weir's second novel "Artemis" is, in a word, wonderful. The synopsis that I saw of it being about some sort of lunar heist doesn't begin to do it justice. I'm at 60%, and the book is just pure pleasure. It occurs to me that Andy is very good at creating anti-heroes. Project Hail Mary's Dr. Grace was certainly no one's hero, and neither is Artemis's Jasmine. |
| Leo: She's great, though; isn't she. |
| Steve: Yes, she is. |
| Leo: She's a real character, yeah. |
| Steve: Yeah. And if you consider the words "Science" and "Fiction," you would be hard pressed to find any book that better satisfied those terms. You know, there are no neural implants, super-human augmentation, anti-gravity repeller rays, or trans-dimensional space folding utilizing energy tapped and funneled down from the 12th dimension. There's none of that. What there is, however, is a very satisfying, entirely plausible story, penned by someone who's very comfortable with actual science and who writes very enjoyable prose. |
| Leo: Yeah, yeah. |
| Steve: You know, at 60% of the way through, I am fully engaged. I'm on pins and needles. I can't wait to get back to it. |
| Leo: Oh, good. |
| Steve: And I have no idea what's going to happen next. |
| Leo: So I think it was good probably that I warned you that it's not "The Martian"; right? It's very different. |
| Steve: Yeah. |
| Leo: If you were expecting another "Martian," or maybe another "Hail Mary," you might have been disappointed? I don't know. That's just... |
| Steve: I don't know. I guess maybe I'm easy. I just think it's... |
| Leo: It's a good story. |
| Steve: I think it's great. I think it's great. We know that I'm a sucker for good writing, and he's a good writer, |
| Leo: Yeah. |
| Steve: And there's nothing that's like annoying or that bothers me. It's just very pleasant. |
| Leo: Yeah, good. |
| Steve: So, you know, I guess the only downside is it's not free. But we're pretty spoiled by free books on Kindle Unlimited. And the fact is you often get what you pay for. |
| Leo: Yeah. I think there's a lot of AI crap now on Kindle Unlimited. |
| Steve: Yeah. And for nine bucks, this is - I'm having a ball. |
| Leo: By the way, I think I have a much better picture of my California ID. There you go. I look happy there. |
| Steve: Yeah, you do. Well, I deliberately went like this. |
| Leo: You look happy. |
| Steve: I was just having, no, I was being goofy. I was having a... |
| Leo: You look crazy. |
| Steve: The guy who was looking through the camera did like a double-take and, like, jerked back from his viewfinder because he's like, whoa. Is that a zombie? Anyway, I... |
| Leo: And I'm trying to do the TruAge thing. So that's - I didn't realize that California directly supports TruAge. I mean, they actually mention it in the wallet app, yeah. |
| Steve: Yeah. It's right there, yes, in their app. |
| Leo: Yes. Yeah. Okay. Cool. |
| Steve: And I don't quite understand the Apple Wallet integration. I don't think my California driver's license is over in the Apple Wallet. I have, like, credit cards in there, but I don't have my driver's license. Because I have that, |
| Leo: Oh, I do; don't I? I thought I did. Let me look. I thought I put it in there. |
| Steve: Well, I don't know how to put it in there. I couldn't find that. |
| Leo: Okay. Oh, well, yeah. |
| Steve: But if you click on that button... |
| Leo: Age verification button? |
| Steve: No, the center one, the reader. And there you will see the minor check. Oh, mine's changed now. How did it change? Huh. |
| Leo: Well, let's see. Check it. |
| Steve: Minor check, over 18, over 21, over 25. Oh, senior check, over 62 or over 65. I mean, so you get to choose what you want to share. You can share your entire identity. |
| Leo: Yeah. |
| Steve: Your name, DOB, sex, issue date. |
| Leo: I think that's good. And you choose. |
| Steve: You're able to share something that law enforcement wants - identity, address, driving privileges. Or then something called "custom," which is coming soon, where you can probably select which items you want to share. |
| Leo: Yeah. And you get a QR code that you can give the checker at the convenience store. |
| Steve: Yeah. I think it's... |
| Leo: By the way, I am over 21. So there you go. |
| Steve: Oh, and here's - I'm getting a permission request: "Allow CA DMV wallet to find, connect to, and determine the relative position of nearby devices." I want to know what that's for. |
| Leo: There's a scanner; right? See... |
| Steve: Oh, it's for mapping while using the app... |
| Leo: Ah. |
| Steve: [Crosstalk] to know where I am. |
| Leo: You still, you know, if you get pulled over, you still have to give them your real driver's license. In fact, they say specifically you can't stop carrying your driver's license because of this. |
| Steve: Yeah. Oh, and the reason it asked me for that was that this - but the Android will do NFC, but iOS won't let you do NFC. It forces you to do QR code. |
| Leo: Ah, okay. |
| Steve: So I'm able to switch to the QR code scanner. |
| Leo: I guess when they say "wallet," it's not the Apple Wallet. I remember that they were - that some states you can put it in your Apple Wallet, and I remember California I think decided not to make that possible. Not sure why you would need that except it's easier to get to. |
| Steve: Yeah, there is an Explore Add-ons, but it doesn't - and I've got the TruAge add-on. But there's no, like, export. |
| Leo: Right, that's the only add-on I can see, too. |
| Steve: Yeah. |
| Leo: All right. |
| Steve: Anyway, we're getting there. Our last break. |
| Leo: I am ready to do your last commercial, and we're going to talk MAPP. |
| Steve: And then we're going to talk about the wisdom of China's participation in Microsoft's MAPP program. What could possibly go wrong? |
| Leo: I also will refer you to something our Club TWiT members have just put in the Discord about a critical security flaw in the Broadcom chips used in more than 100 models of Dell computers. |
| Steve: Ooh. |
| Leo: Allowing attackers to take over 10s of millions of user devices. Five vulnerabilities, CVE 24311 through 15, 22 - quite a few. All in the Broadcom chip. |
| Steve: Oh, boy. |
| Leo: Cisco at it again. Thank you, Paul. Paul Holder put that in our Club TWiT Discord. Appreciate that update. We'll I'm sure be covering that next week. |
| Steve: Paul will hopefully post it over in the GRC newsgroup. |
| Leo: Yes, he's a regular on your forums, too; that's right, yeah. |
| Steve: Yeah. Big help. |
| Leo: Yeah. I know he's a big help in our forums, too. We appreciate Paul. Now, let's get to this shocking story about MAPP. |
| Steve: Okay. So I want to share what I feel is a very fair and balanced assessment of the consequences of the unfortunate, but nevertheless very real, geopolitical tensions that have been growing between the U.S. and China, and the consequences of China's longstanding early access to Microsoft's serious security vulnerabilities. And Leo, you're going to love the name of these guys. This was posted to the Natto Thoughts Substack last Thursday... |
| Leo: Oh, yeah. I read that one. Yeah. |
| Steve: ...in the wake of the SharePoint - you are amazingly well read. |
| Leo: Well, I do it, I have feeds galore. I mean, I read as much as I can. Yeah. |
| Steve: Gosh, I guess. So this one, they posted this last Thursday in the wake of the SharePoint-driven global network breaches. They describe themselves, for our listeners who are not aware, writing: "Natto Thoughts explores the intersection of culture, technology, and security, with stories, analysis, and insights into the humans of the information age - whether decision-makers, criminals, or ordinary users. We probe the language, culture, institutions, political systems, and unwritten social rules that constrain and inspire their actions. Natto is a sticky Japanese fermented soybean dish..." |
| Leo: It's very good. |
| Steve: "...with an acquired taste." They said: "Fermented foods are slow foods. It helps keep your microbiome, that complex ecosystem that helps you digest, healthy. Like natto, our thoughts have had time to 'ferment.' We're a group of experts with decades of experience in geopolitical analysis and cyber threat intelligence between us. We do research in a variety of European and Asian languages." So last Thursday, having "fermented" on this for some time, they posted under the headline: "When Privileged Access Falls into the Wrong Hands: Chinese Companies in Microsoft's MAPP Program." And they added the subhead: "Chinese companies face conflicting pressures between MAPP's non-disclosure requirements and domestic policies that incentivize or mandate vulnerability disclosure to the state." Since we've touched on the Chinese government's disclosure requirements for their Chinese enterprises in the past, and since it's so relevant today, having read what these guys have to say, I felt that this audience needed to hear it, too. So they wrote: "On July 25, 2025, Bloomberg reported that Microsoft is investigating whether a leak from its Microsoft Active Protections Program (MAPP) allowed Chinese hackers to exploit a SharePoint vulnerability before a patch was released." Now, we know from the first topic we covered, which is that Chinese programmers wrote the patch, that maybe there was another way, another exit path for those details. But that doesn't mean that this is not an issue, too. "Microsoft attributed," they wrote, "the campaign - dubbed 'ToolShell' after the custom remote access trojan used - to three China-linked threat actors: Linen Typhoon, Violet Typhoon, and Storm-2603. The attackers reportedly compromised over 400 organizations worldwide, including the U.S. National Nuclear Security Administration. "Launched in 2008" - okay, so that's when this program began, 2008, quite a while ago - "MAPP is designed" - and before tensions with China were as they are today - "MAPP is designed to reduce the time between the discovery of a vulnerability and the deployment of patches. By giving trusted security vendors early access to technical details about upcoming patches, Microsoft enables them to release protections (such as antivirus signatures and intrusion detection rules) in sync with its monthly updates. The program, however, relies on strict compliance with non-disclosure agreements and the secure handling of pre-release data. "Concerns about whether some Chinese companies violated MAPP requirements are longstanding. In 2012, Microsoft removed Chinese company Hangzhou DPtech Technologies Co., Ltd. from the program for violating its nondisclosure agreement. According to Bloomberg, in 2021, Microsoft" - now, that was in 2012. And according to Bloomberg in 2021: "Microsoft suspected that at least two other Chinese MAPP partners leaked details of unpatched Exchange server vulnerabilities, enabling a global cyber espionage campaign linked to the Chinese threat group Hafnium." So this is serious business. "The Microsoft Exchange hack affected tens of thousands of servers, including systems at the European Banking Authority and the Norwegian Parliament, and was met with global condemnation. Although Microsoft said it would review MAPP following the incident, it remains unclear whether any reforms were implemented, or whether a leak was ever confirmed. In light of the SharePoint case, today's piece examines how MAPP operates, the risks posed by Chinese firms in the program, and which companies are currently involved. "The core purpose of MAPP is to minimize the window of risk between patch rollout and deployment. Simply releasing a patch doesn't mean systems are protected. Many organizations delay patching, and attackers often exploit known vulnerabilities during this lag. By giving trusted vendors early access to vulnerability details, Microsoft ensures they can build and distribute detection signatures and other defensive measures in advance, you know, like CrowdStrike, for example. So these protections are already active when the patch is published. Without MAPP, vendors would only begin creating protections after public disclosure, leaving many systems globally, including in China, exposed for critical hours or days. "To participate in MAPP, security vendors must meet criteria that demonstrate their ability to protect a broad customer base." You know, they must demonstrate that they're worth disclosing these details to. "Applicants must be willing to sign a non-disclosure agreement, commit to coordinated vulnerability disclosure practices, share threat information, and actively create in-house security protections such as signatures or indicators of compromise based on Microsoft's data. Microsoft retains discretion over admission and may suspend or expel members who fail to meet participation standards. "According to the MAPP website, members are divided into three tiers based on the amount of time they receive vulnerability information before its public release and other criteria: Entry level, which is 24 hours in advance; ANS, which is up to five days in advance; and Validate, which is invite-only and focused on testing detection guidance. However, recently admitted MAPP partners and recognized experts have observed that Microsoft may provide critical vulnerability and threat intelligence as early as two weeks prior to public disclosure. Criteria for determining the criticality which warrants such early releases and to whom the intelligence flows is unclear. "These companies operated within MAPP present a unique risk due to national regulations mandating the disclosure of vulnerabilities to the state. In September 2021, China implemented the Regulations on the Management of Network Product Security Vulnerabilities (RMSV), which require any organization doing business in China to report newly discovered zero-day vulnerabilities to the government authorities within 48 hours. This gives Chinese state agencies early access to high-impact vulnerabilities, often before patches are available. "Microsoft acknowledged the implications of this policy in its 2022 Digital Defense Report, noting that 'this new regulation might enable elements in the Chinese government to stockpile reported vulnerabilities toward weaponizing them.' "While the RMSV serves as the primary legal pathway for the state to acquire zero-days, it is not the only mechanism. In 2023, cybersecurity analysts Dakota Cary" - and he's one of the authors of this paper, by the way - "and Kristin Del Rosso uncovered a parallel, more opaque process involving the China National Vulnerability Database of Information Security (CNNVD), which is overseen by the Ministry of State Security (MSS). "Under this framework, Chinese cybersecurity firms voluntarily partner with the CNNVD to report vulnerabilities" - get this - "in exchange for financial compensation and prestige. These firms, known as TSUs, Technical Support Units, are stratified into three tiers based upon the number of vulnerabilities they submit each year. Tier 1 TSUs must submit at least 20 'common' vulnerabilities annually, including a minimum of three classified as 'critical risk' in order to qualify for their Tier 1 status." So, yikes. I imagine that everyone listening appreciates how traditional Chinese culture could factor into both the financial compensation and the prestige aspects of this, and how these minimal annual submission requirements to achieve and maintain tier status would tend to introduce unhealthy incentives. China's CNNVD Handbook provides a requirements chart for the three participation tiers, where you have Level 1, Level 2, and Level 3, requiring higher and more frequent and more plentiful turnover of vulnerabilities in order to obtain that tier. Who knows where they're getting them. Their report continues: "As early as 2017, the U.S. threat intelligence firm Recorded Future, whom we've often quoted here, demonstrated that vulnerabilities reported to CNNVD are assessed by China's Ministry of State Security for their potential use in intelligence operations. As of this writing, 38 companies are classified as Tier 1 contributors to CNNVD, 61 as Tier 2, and 247 as Tier 3. Of these, 10 Tier 1 companies, one Tier 2, and one Tier 3" - okay. Of these, that is, those that are turning things over to China's Ministry of State Security for their potential use as intelligence operations, here's the number of those that are currently Microsoft MAPP members: 10 in Tier 1, one in Tier 2, and one in Tier 3. So they are receiving the intelligence from Microsoft in advance of its release, and they're being paid and obtain prestige for turning some vulnerabilities over to the Ministry of State Security. What could possibly go wrong? "In addition to providing new vulnerabilities to the CNNVD, these Technical Support Units are also required to provide 'vulnerability early warning support' to the Ministry of State Security: at least five 'critical alerts' annually for Tiers 1 and 2, and at least three for Tier 3. As cybersecurity and tech companies, many of these TSUs likely provide this early warning support by reporting newly observed attacks on their customers or systems. Nothing other than Microsoft's non-disclosure agreement precludes TSUs from sharing MAPP data with CNNVD, which may view such submissions as fulfilling this vulnerability early warning support requirement." And not be unhappy about it. They wrote: "Our analysis of the MAPP main page via the Wayback Machine shows that the number of Chinese companies listed in MAPP increased from 13 in December" - so this is the number of companies that Microsoft is disclosing this stuff to - "increased from 13 in December of 2018" - which was the earliest available snapshot they could find with the Wayback Machine - "to 19 out of a total of 104 member companies globally as of this writing. China has the largest national representation after the U.S." So there are 19 Chinese firms currently as MAPP partners. They wrote: "Since 2018, several Chinese companies have appeared and disappeared from the MAPP list. Companies that have since disappeared include Beijing Leadsec, Huawei, and Neusoft (removed between December 2018 and November 2019); Qihoo 360 (between November 2019 and October 2020); Hangzhou H3C Technology (between December 2021 and October 2022); and Sangfor (between October 2022 and September 2023). "The reasons for a company's removal from the MAPP list are not always clear. In the case of Huawei and Qihoo 360, the timing aligns with their addition to the U.S. Entity List in 2019 and 2020, respectively. For others," they wrote, "we could not locate any public explanation from Microsoft, unlike the 2012 public notice from the Microsoft Security Response Center regarding DPtech's removal for violating MAPP's NDA requirements. "Of the 19 Chinese companies currently participating in MAPP, 12 are classified as CNNVD TSUs. Based on previous research into their vulnerability submissions to Microsoft's bug bounty program, Tier 1 TSUs such as Tencent, Cyber Kunlun, Sangfor, QiAnXin, and Venustech operate dedicated labs with varying levels of focus on identifying vulnerabilities in Microsoft software products. "It's also possible that individuals working at MAPP companies in China individually decide to pass along or sell information to offensive teams. With access to valuable information and a clear market for buyers, insider risk at MAPP partners themselves cannot be ruled out. "Regardless of the specific mechanism for information diffusion, it is clear that China's incentives for reporting such vulnerabilities - both economic and reputational, as companies seek to meet CNNVD quotas and maintain TSU status for potential business opportunities - create an environment which incentivizes abuse. "Vulnerabilities reported to the Ministry of State Security-run CNNVD may be evaluated for potential operational use before being disclosed to the public. Chinese APT groups are known for their speed and coordination in exploiting such vulnerabilities. According to advisories from multiple national cybersecurity agencies and threat intelligence firms, groups such as APT40 and 41 have exploited vulnerabilities within hours of their public disclosure. Chinese APTs are also effective in sharing exploits across groups. Once a vulnerability has been successfully weaponized, it often circulates rapidly among operators. "Both these dynamics were on display during the 2021 Microsoft Exchange campaign. On February 23rd, 2021, MAPP distributed proof-of-concept code to its members so they could engineer detections. Five days later, mass exploitation of the vulnerabilities with similar code to that distributed via MAPP blanketed the web. According to threat intelligence firm ESET, exploitation began with the China-linked threat group Tick and was quickly followed by other China-linked groups, including LuckyMouse, Calypso, and the Winnti Group. Microsoft made patches available for customers shortly thereafter on March 2, 2021, seven days after distributing proof-of-concept code to MAPP members. "A similar pattern emerged with the exploitation of the SharePoint vulnerabilities first disclosed at Pwn2Own Berlin in May. The winning submission was reported to Microsoft shortly after the event. As per standard MAPP procedures, Microsoft distributed vulnerability details to selected partners up to two weeks before the public patch, scheduled for July 8th. Yet CrowdStrike observed exploitation as early as July 7th, again suggesting that threat groups may have gained access to vulnerability details before protections were made widely available. Microsoft attributed the activity to no fewer than three China-linked groups on July 22nd. "Microsoft's stated mission is to 'empower every person, every organization on the planet to achieve more.' In line with this mission - and given Microsoft's strong global presence, including a vast user base in China - initiatives like MAPP play a critical role in protecting users from malicious actors. However, such programs require strong safeguards and clear accountability, and ensuring full compliance can be difficult. In unique contexts such as China's centralized vulnerability disclosure system, the inclusion of Chinese companies warrants special scrutiny, especially those participating in domestic programs that incentivize reporting vulnerabilities to the state." And they conclude: "Unfortunately for Microsoft's user base in China, the government incentivizes behavior which should jeopardize the continuing participation of legitimately defensive companies in MAPP. It is the role of the PRC government to enforce laws on companies operating within its jurisdiction and responding to its policies. In consideration of Microsoft's pursuit of adequate defense and support of its users, and in line with the company's mission statement, it may be appropriate for Microsoft to temporarily suspend PRC-based companies from MAPP pending an investigation by the PRC government into the potential violation of Microsoft's NDA with local companies. Microsoft has the systemic importance to request such an investigation, as the behavior clearly jeopardizes the safe operation of Critical Information Infrastructure under the PRC Cyber Security Law." So given all of the facts that these guys lay out, and the future - if not the past - potential for the rapid abuse of a critical global flaw in widespread Microsoft networking systems, I for one sincerely hope that Microsoft is seriously at this point reconsidering the trusting relationship they have long enjoyed with China's security firms. You know, in paraphrasing Kahn, if we were all one big happy planet, then I'd say that Microsoft's historical position makes sense. Why not share these discovered vulnerabilities before they are patched and remediated? But the sad truth is, tensions are escalating; and there doesn't appear to be any reasonable end in sight. Given that U.S. intelligence agencies have firmly concluded that U.S. interests are under constant cyberattack from Chinese threat actor groups which are being actively supported by the People's Republic of China, how can it possibly remain rational for Microsoft to be willfully providing Chinese researchers - and indirectly the Chinese government - with the very means to attack us, perhaps devastatingly? |
| Leo: From your lips to Microsoft's ears. Well, that sounds kind of creepy. But I hope they listen and pay attention. |
| Steve: Yeah. I mean, I get it. It's valuable. But Leo, we've just, you know, Exchange Server is an example, and SharePoint is another. |
| Leo: It's happening too much. |
| Steve: There are defects, serious, critical, remote code execution defects in Microsoft's products. And when they're discovered, they need to be fixed without them being at risk of being weaponized against us before they can be patched. And unfortunately, they're willfully giving advance notice to a hostile foreign entity. |
| Leo: Well, Microsoft says they're going to eventually move it out of China. They don't say they're going to move it back to the U.S. |
| Steve: No. And actually what they said they would move out was the fact that it's even worse. They have Chinese people writing the patches at the moment. |
| Leo: Yeah. |
| Steve: But then also they have the MAPP participants that are different than that. |
| Leo: Oh, okay. |
| Steve: So they have two different means by which, you know, they're, like, deliberately having knowledge of these problems in China before the patches are released. |
| Leo: I'm surprised they're even allowed to do this, frankly. |
| Steve: I think it's only because Microsoft is so strong, and our politicians don't really understand what's going on. |
| Leo: Yeah. |
|
 | Gibson Research Corporation is owned and operated by Steve Gibson. The contents of this page are Copyright (c) 2026 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: Aug 11, 2025 at 07:40 (155.41 days ago) | Viewed 15 times per day |