Going back as far as the 2004 release of Windows XP SP2, Windows has offered various GUIs to help users understand the security state of their PC. In modern Windows 10 and Windows 11, this graphical user interface is called the “Windows Security Center/App“.
The Windows Security App (WSA) is a surface upon which Windows exposes various settings and information, including lightweight status for antivirus and firewall products (including those built by third-parties) and entry points to those products’ user-experiences.
The WSA can be launched via the Start Menu, or by clicking on various toast notifications sent by features within the app.
The default view aims to provide a “single status screen” showing the state of the system’s security components:
By default, Windows includes Microsoft Defender Antivirus (MDAV) and the “Virus and Threat Protection” section of the WSA shows the state of MDAV, including details about the most recent scan, any previously-allowed threats, and the “Protection history” which outlines any threats previously encountered.
Notably, the WSA is also the only client graphical user-interface for Microsoft Defender Antivirus and Microsoft Defender for Endpoint security products: unlike all third-party security products on Windows there is not today a separate Defender app (except our D4I product; keep reading).
The Quick scan button allows invoking a quick scan of sensitive system locations (primarily, locations used by malware to establish persistence), while the Scan options link allows invoking other types of scans:
With that said, as outlined previously in my post about Understanding Defender AV Scans, there is rarely any need to manually kick off an AV Scan.
Defender for Endpoint
Until recently, the WSA would not show anything special if a device was onboarded to Microsoft Defender for Endpoint (MDE), the corporate version of Defender that adds numerous additional protection features beyond the free MDAV included with Windows. As I explained last month, it was previously non-trivial to determine whether a PC was onboarded to Defender for Endpoint’s XDR and monitored by a Security Operations Center.
Fortunately, this has recently changed, and the WSA now shows specific information when a device is onboarded, including which MDE features are enabled:
The Device Details link in the footer reveals more information, including status and version numbers of the protection components:
Third Party Antivirus
When a 3rd party security product installs on a client version of Windows, it calls the Windows Security Center API to announce its presence and status. Supported products include Virus and Threat Protection products and Firewall products. WSA previously showed a Web Protection category intended to indicate the status of any Edge Legacy browser protection extensions, but this section was removed in a recent update because Edge Legacy was removed years ago.
Registering a product in the Virus and Threat Protection category directs MDAV to enter “passive mode” (disabling real-time protection and other features), allowing the 3rd party product to be the active protection component of the system. The product in question has short window after each system startup to register with the API: if it fails to do so, or if it indicates that it is not working properly, MDAV resumes operations. The APIs for registering with the Windows Security Center are not fully public, and only callable by members of the MVI program.
When a 3P security product registers, the UI of the Windows Security Center is updated to show lightweight status information from that product and offer an Open app entry point into the 3P product’s (typically) richer user-interface.
Windows Security App behind the 3P Sophos Home application spawned from the “Open app” button.
Multiple 3P products (AV and Firewall) may be installed at one time, although it’s generally recommended to only have one product of each time active to avoid conflicts and performance impact.
Notably, many consumers who buy PCs from major vendors may find that they have a “time-limited trial” of a 3rd party antivirus product pre-installed on their PC, leaving Defender in passive mode. Antivirus product vendors commonly pay PC vendors for such installations as a way to acquire customers for their security product subscriptions. As mentioned, uninstalling the trial product should automatically move MDAV back into “Active” mode.
In Passive Mode, MDAV can evaluate file trust/reputation for Smart App Control, and, for MDE onboarded devices, work with EDR in Block Mode to provide protections against detected threats. It can also provide services to other products, like Purview DLP.
End users can also optionally enable “limited periodic scans” to provide additional protections on top of their third-party product.
Navigating the WSA Programmatically
Individual pages of the WSA can be accessed via commands to the windowsdefender://App Protocol:
For example, windowsdefender://appbrowser/ opens the App & Browser control page of the app:
Defender for Individuals app
Above, I mentioned that Defender does not have its own app, relying on WSA for all of its graphical user-interface. That’s generally true with the exception of the Defender for Individuals (D4I) product bundled into Microsoft 365 subscriptions for individuals and families. When installing D4I, you get a new app named “Microsoft Defender” that exposes the additional capabilities provided by your subscription, which include a unified dashboard across multiple devices (e.g. to see your kids’ PC’s status) and other features which vary per-market (e.g. identity protections and dark web scanning services).
Even when a D4I subscription is active, the underlying Virus and Threat Protections are provided by MDAV included in Windows. Entry points for antivirus-related activities in the D4I Microsoft Defender app ultimately navigate to the appropriate pages in the WSA.
Windows Server
WSA is not present on Windows server, nor are the underlying Windows Security Center APIs that would allow 3P security products to register with Windows. Instead, if a third-party product is installed on Windows Server, a registry key must be set explicitly to put Defender in passive mode.
On servers, it’s expected that Windows Security features will be configured via PowerShell, Group Policy, the MDE Security Portal, or similar management mechanisms.
Attackers are adept at using new technologies to enhance their attacks. Earlier this afternoon, for example, I got call from “American Express” suggesting that I needed to “verify a transaction.” The caller used a robotic voice similar to the one used by American Express’ automated systems, and only obvious signals that it was a scam were a) they didn’t have my name or card number, b) I have been using my Visa exclusively for the past few weeks, and c) I have their app, and I get push notifications from it.
Recently, there’s been some excited press about attackers abusing AI-powered “deepfake” technology to persuade users to take unsafe actions (for instance, sending money or sharing secrets) by using a trusted person’s voice or appearance to make the pitch more compelling. Attackers no longer need to limit themselves to spoofed phone numbers or names, they now can use a real-looking voice or video.
But is cloning still an advanced technique, or are we soon going to see it everywhere?
Free Voice Cloning
The best AI models require money to use and I don’t have the time or attention span to fully explore them, but as a browser lover/enthusiast, I’m intrigued to look at how convincing a spoof I can do using an in-browser speech cloning tool.
Beyond being free, such a tool will allow an attacker to generate speech without calling a web service that might keep logs that could be used to catch the attacker. Behold SoundTools.io. It’s free, trivial to use, and is very upfront about its market position and level of quality vs. competitors:
Throughout, the tool includes clear explanations of how it works:
To use it, you can either feed it previously recorded audio, or (preferably) a live recording of a paragraph of text:
After collecting the audio sample, the page downloads several large models (just over a gigabyte, cached for later use), to generate a cloned voice. It then allows the user to provide text that should be read aloud, and a desired quality level (lower-quality reproduction is faster):
The time required depends on the quality chosen and the performance of the browser on your device. In my quick test, the “High quality” level, which requires 60 to 150 seconds per sentence, seems to generate pretty good results. If it’s enabled, you’ll definitely want to turn off Edge’s “Enhanced Security Mode” for this site because its WebAssembly runs much more slowly in interpreted mode.The site makes heavy use of the system GPU:
…and surprisingly to me, doesn’t seem to work on Windows ARM devices like Surface Laptop 7.
Finally, when the generation completes, the recording is available to play or download.
Folks who have heard me speak would probably agree that the results are pretty plausible. While my real voice has more “ums”, “uhs”, variable pauses, and animation, careful preparation of the source text would yield even more compelling output. (For example, the web app doesn’t currently handle “smart quotes” properly, voicing contractions like “Can’t” as “Can Tee”.)
Both of these are pretty solid, and attackers who worry about the quality of the clone would also likely simulate the speaker being in a noisy environment or suffering from a poor phone signal.
Not just voice, obviously
Don’t even get me started about how trivial photo editing has gotten:
Dating profiles where guys hold a giant fish will never be believable again 🤣
Running with my buddy
Even today’s high schools can afford to generate sizzle videos for marching bands that would’ve cost millions of dollars to render when I was high school.
Exciting stuff! But scary in the hands of bad guys. I don’t even know what to suggest folks do to stay safe, other than slow down and think, be extra skeptical of situations where someone unexpectedly contacts you, and be cautious of all non-in-person interactions, especially when it’s not a real-time conversation (which can still be faked, but it’s harder).
For years, it’s been easy to fake an entire company, but today it’s not too hard to shallowly fake a family member or close friend. Perhaps in the future, we will all share a Shibboleth with close friends, or demand out-of-band confirmations of all requests?
Stay safe out there, and don’t believe everything you hear, or see!
I’ve shared the stories behind the Fiddler Web Debugger a fair bit over the years, in the Fiddler Book, in a talk at the CodeMash conference in 2015, and on this blog. It features prominently in my to-be-completed (some day?) memoir, and I’ve enjoyed telling Fiddler stories to folks who ask over the years. (I’ve also written a ton of content about using Fiddler.)
Over two decades, what was once a little side project came to influence a very meaningful percentage of my life, including where I live today and so many of my life’s experiences.
Receiving the Engineering Excellence Award for Fiddler, circa 2007
On Monday morning, I got a ping from someone from Progress Software, acquirers of Telerik in 2014, after Telerik acquired Fiddler (and for a few years, me) back in 2012. They asked for an email address to which they could send a note.
“This isn’t gonna be good“, I assumed. Correctly.
After I left Telerik for Google in 2016, development on the “Fiddler Classic” application had stagnated as the owners put their investments into a series of products they could monetize.
To be fair, this pivot was not unexpected. Initially, Telerik had purchased Fiddler largely for the community attention: the tool had a huge userbase of the exact developers the company was courting. Still, we always expected that eventually we’d have a cross-platform version of the product (a highly-requested improvement), and that non-Windows version could be sold like Telerik’s other professional tools.
Fiddler: Free Forever?
Telerik had loudly promised that Fiddler would remain “free forever” to avoid expected community outrage about commercializing a previously-free tool. Before Telerik, I had spoken to one potential acquirer who estimated the brand damage of their commercializing another previously-free tool at 25x their acquisition price, meaning they’d likely never turn a profit on it.
Telerik’s blog post announcing the change was explicit:
… but even that wasn’t enough, so a follow-up post was made shortly after:
The unambiguous clarity of this promise had meant that improving the “Fiddler Business” meant we’d need to: 1) monetize the technology behind Fiddler (we had several solid ideas), or 2) pivot to a new cross-platform product they could sell, or 3) renege on their promise and start charging for Fiddler for Windows, or 4) use Fiddler to showcase (and juice sales of) Telerik’s .NET component products.
While I was at Telerik, I worked a little on #1 — we created a licensable version of FiddlerCore, the core engine inside Fiddler, with the idea that other companies could sell products based on it. Telerik had used FiddlerCore inside their Test Studio product (that’s how I came to their attention to start with), and we assumed that other companies might want similar technology. Interest was… not very high… in part because we made little effort to evangelize, and partly because the license price would limit it to larger companies.
Very frustratingly and humiliatingly, my once-and-future employer wanted to use FiddlerCore inside their Message Analyzer product. But Microsoft didn’t want to pay the license fee. So instead, the software juggernaut worth hundreds of billions of dollars wrote code to prompt their end-users to pirate FiddlerCore:
This is the sort of behavior then most often seen from shady apps trying to avoid paying MP3 patent fees. To this day, I remain shocked that the lawyers from both companies allowed this experience to ship. (The fact that Microsoft-ecosystem developers made up virtually all of Telerik’s customers probably had something to do with Telerik not suing).
Days after I started at Telerik, I started work on strategy #2 (build a cross-platform version). I spent months trying to get Fiddler running on Mono, an early cross-platform version of the .NET Framework that ran on Mac and Linux. It didn’t go great. I built a serviceable version for Linux, but the UI port for MacOS would crash constantly. A hybrid strategy, using Mono for FiddlerCore, and building a new front-end on Electron, seemed like a plausible path forward. Alas, this vision was put on pause in 2014 after Telerik conducted broad US-based layoffs in advance of an expected IPO on the US stock market. After its aborted IPO and subsequent acquisition by Progress Software, Telerik eventually restarted this strategy, eventually shipping Fiddler Everywhere. Fiddler Everywhere offered several key advantages over the Windows-only Fiddler Classic (cross platform! some team features!) but it also had many shortcomings (fewer features, no extensibility model).
I’d hoped that Progress/Telerik might open-source Fiddler Classic at some point in order to grow the ecosystem— things like the Fiddler SAZ format would get even more popular and create the possibility of monetizable synergies. Alas, this never happened. Instead, Fiddler Classic just quietly decayed. As browsers adopted new standards (e.g. http2, h3, GREASE, tls1.3, zstd content compression), Fiddler Classic required more and more caveats and workarounds for continued use. However, Fiddler’s rich extensibility model means that I could keep building new capabilitiesinand on Fiddler in the ten years since I lost the ability to commit updates to Fiddler’s source directly.
I still use Fiddler on Windows almost every single day, but in many cases I’m not even using Fiddler to capture traffic anymore, instead just using it as a viewer for traffic captured natively by Chromium, or to use its TextEncoder and Inspectors, or even as a frontend for other tools.
Progress added a pre-download survey to collect user emails (annoying!) and periodically added surveys and advertisements directly inside the Fiddler Classic UI. But even if those were sometimes gratingly misleading, they weren’t too annoying.
Other changes of dubious value were also only mildly annoying.
This Week’s Rug Pull
Opening Fiddler on Monday, I was presented with a Fiddler Update announcement, including some neat improvements, particularly support for ZSTD decompression (obsoleting my workaround):
However, I didn’t accept the update straight away because I suspected something was afoot. (I also got distracted because Windows complained about the installer’s signature).
Sure enough, the first screen of the installer mentions another IMPORTANT change in Fiddler that was not mentioned in that shiny update announcement:
Progress Telerik has decided to start demanding Fiddler Classic not be used for “commercial” purposes. Beyond the new text in the license, Fiddler shows this big orange bar:
So… it appears that the owners of Fiddler have reneged on their promise to the community and the product is no longer free.
Dialogue with Progress/Telerik
Taken literally, the license agreement says you cannot use Fiddler Classic for commercial purposes, even if you pay! This is rather shocking, because it means that Fiddler’s most engaged users, who’ve built extensions and workflows around Fiddler, cannot use them, even if they’re willing to pay up. Such a position seems so wildly foolish that I assumed it must just be an oversight. I inquired, and Progress Telerik provided the following statement:
No, Progress is not planning to offer Fiddler Classic under a paid licence.
We recognise the important role Fiddler Classic has played in supporting developers’ debugging workflows over many years. Continuing to invest in the product at the level required for commercial and enterprise customers, including ongoing feature development and platform modernisation, is not aligned with our long-term product strategy. Accordingly, in recent years, Progress has focused on maintaining and supporting Fiddler Classic, while directing its development efforts towards Fiddler Everywhere.
That said, we recognise the value of the extensibility capabilities available in Fiddler Classic. As a result, we will continue to work on scripting functionality in Fiddler Everywhere to help users continue their existing workflows with minimal disruption. We will also continue to evaluate additional feature requests based on customer needs and use cases. As always, we remain open to feedback and are committed to understanding how we can best support our users.
Improved scripting functionality may satisfy some users, but it definitely will not encompass the wide range of scenarios enjoyed by Fiddler Classic today, especially for users who’ve built custom Inspectors, Transcoders, or other extensions that integrate Fiddler with other systems and processes used within their companies.
In a closing paragraph of their response, the Progress/Telerik product manager (or, more likely, their lawyer) appears to have attempted to suggest that I shouldn’t share my thoughts with you fine folks (emphasis mine):
Last but not at least, no person outside Progress is authorized to make announcements, provide comments, or respond to customers’ inquiries regarding Progress’ business on behalf of the company. All questions should be directed to Progress’ official communication channels fiddler@progress.com.
Needless to say, I don’t speak on behalf of my former employer, but they’re also not going to stop me from talking about this change.
My Feelings
Some folks have asked how I feel about this. In short, disappointed, somewhat betrayed, but ultimately not surprised. Fiddler for Windows is a powerful tool that provides a tremendous amount of value to its users, and the nature of short-term profit maximization is that companies with valuable assets often struggle to recognize the long-term value of not abusing their users.
As I talked about previously in my post about mistakes I made when building Fiddler, my lack of a monetization plan was a key shortcoming in the product’s strategy. When Telerik acquired Fiddler, I assumed that the business folks there would develop a strategy beyond “monetizing the eyeballs” of the tens of thousands of weekly downloaders (although it was a bargain for that traffic acquisition alone).
As I’ve described above, development of a monetizable product strategy never got any real attention. Meanwhile, the team over at Postman hypothesized that a team-based product would be a winner, they tailored their offering accordingly, and their valuation skyrocketed to $5.6B after $433M in VC funding. I suspect that Postman’s true pre-IPO valuation may be lower, but for perspective, Progress Software’s entire market capitalization is currently just $1.7B.
I was excited to recently see Progress move Fiddler Everywhere toward the hottest trend in tech (Artificial Intelligence) by introducing support for MCP and the popular agents. Done right, this could be a killer feature that people are willing to pay big money for because of the value it can deliver.
However, I worry that Progress may have just vaporized the trust and goodwill that would’ve smoothed their plan to move users from a solid (if outdated) free product to an actively-developed paid product with a disjoint feature set. That’s especially true because Fiddler’s Session Archive Zip (SAZ) format could’ve allowed compatibility between the two.
Where Do We Go From Here?
Many Fiddler Classic users can happily continue to use the product for free for their personal non-commercial needs. Some Fiddler Classic customers may be happy to switch to Fiddler Everywhere with prices starting at $84/user/year for a feature-limited version of the product, or $444/user/year for the full Fiddler Everywhere feature set (which does not, as noted above, have all of Fiddler Classic’s features or compatibility with its extensions).
Some users have told me that they’ve be taking measures to disable Fiddler 5.x’s upgrade logic and remain on the final free version forever under its original license. They’ll use the extensibility model to keep it compatible with the modern web. Unfortunately, public redistribution of the older installer is not permitted under its license.
Some users will likely just stop using Fiddler entirely. As browser developer tools have evolved, many web developers’ needs are now fully met by the Network tab in their respective browsers.
Some users will likely move to competitive products, whether pay (Postman, Charles) or free open-source (mitmproxy).
Fiddler -> CLeARINET?
One thing that’s particularly baffling about Progress’ decision is the timing. Crippling Fiddler might’ve made some (evil) sense back in 2020 or so, but if you haven’t noticed, times have changed.
AI agents have enabled vibe-coding of production-quality code rapidly and cheaply. When a pre-Telerik acquirer asked me how long it would take them to implement their own, I guessed about 2000 hours, or about 700 if I guided them. Using an AI coding agent, I suspect you could get 90% of the way there in about 160 hours.
Much of the work in building Fiddler was in “figuring stuff out”, and the resources for doing that are dramatically better than ever before: we have better blogs, better tooling, better RFCs, and more open-source code than ever before.
The .NET platform is dramatically more capable (particularly related to async) than the v2.0 framework that Fiddler mostly targeted. I’ve already laid out a set of mistakes and pitfalls to avoid.
There’s a large community of .NET developers who might be interested in lending a hand, including many hundreds that recently voluntarily retired from Microsoft. And there are some amazingly bright developers (Kevin, Jérôme, Chrisx3, etc) who have built extensions and other code for legacy Fiddler who might jump at the chance to get their PRs into an open-source replacement.
Fiddler has no “moat” — the SAZ file format is simple and easily read and written. The product is designed to interact with protocols and formats based on open-standards. The true value of Fiddler was almost entirely “goodwill.”
Times seem ripe for a change.
When I named Fiddler, I did so because I was on the Microsoft Office clipart team and I knew we had plenty of free pictures of violins handy. Time has passed, and we have AI that can generate any images we want. An important kid in my life plays clarinet. If you squint at it, Clarinet sounds kinda like “Clear INET”, and seeing internet traffic in the clear is the whole point here.
In about 5 minutes, we’ve got a name, a domain, and a splash screen.
Now we just need some code. :)
I’m currently in an especially busy period at work and in life (I’m moving houses this month) but I hope to have some progress and updates in this space sometime soon. Unless Progress Software wants to save me the trouble and win tons of kudos for open-sourcing FiddlerClassic themselves! ;-)
First, a confession—the Fiddler Web Debugger is not the result of a grand vision or the ambition to develop the world’s most popular debugging proxy. A tool born of necessity, I never set out to build a platform so flexible, powerful, and complicated that I’d be forced to spend a year writing a book to explain how to fully take advantage of it. But here we are.
Before diving into the technical chapters, I will begin by sharing the story behind how Fiddler came to be.
As a student at the University of Maryland in the spring of 1999, I had the chance to interview for a Program Management internship on a new team at Microsoft. One of my final interviewer’s first questions was “How does HTTP work?” Knowing only the basics, I gave an incomplete and somewhat inaccurate answer, but didn’t embarrass myself too badly. That summer and the following, I worked on features for the first version of SharePoint. On rare occasions, I found myself looking at web traffic in Microsoft Network Monitor (NetMon), a powerful but then primitive and difficult-to-use packet sniffer. In the early summer of 2001, I joined Microsoft full-time as the Program Manager for the Office Clip Art client and website.
At that time, most of the developers and testers working on my team were new to web development, having previously been responsible for writing native code applications in C and C++. It was quickly apparent that the debugging process was overly cumbersome—many of my colleagues were loath to use NetMon. I even watched some developers debugging HTTP requests by hovering over variables in Visual Studio, examining the raw traffic in hex:
Having developed several small Windows utilities, I was confident that I could code something to make web debugging simpler. My first simplistic effort was based on taking an existing C++ proxy server and making minor modifications to it so that it would spew HTTP traffic to the system console:
It’s generous to call this effort primitive—the proxy couldn’t handle secure traffic or authentication protocols. Non-text content was another problem—comically, the utility would try to render binary content as ASCII. Old-school console users may recall that the octet 0x07 represents the “bell” character, and when it’s displayed in the console, a system beep is played. Soon after its release, the hallways of the Office Online team sounded like a Las Vegas casino, as binary content flowed through the debug proxies running in each tester’s office.
Despite the very annoying limitations, this tool was still popular, and I was inspired to get started on the next version. I mocked up a quick little demo in Borland Delphi, a native code language used for most of my development work at the time. The colorful UI foreshadowed Fiddler’s eventual appearance:
However, as I pondered the security and memory-management implications of writing a proxy server in native code, I soon decided that my next effort would be developed in C#, a new language being developed by the Visual Studio team that my best friend had just joined. The notion of writing a HTTP proxy server from scratch in .NET posed just two significant challenges: I didn’t really know how HTTP worked, and I didn’t know how to code in C#.
Fortunately, given a few trips to the bookstore and a lot of spare weekends, both shortcomings would be remedied. Two books were my constant companions: HTTP: The Definitive Guide and the C# Cookbook. Chapter by chapter, I learned about HTTP and C#, and week-by-week Fiddler came to life. About six months after I started, I had a basic version of Fiddler ready:
Like its predecessors, it too had a large number of limitations (and thousands of bugs) but it was eagerly adopted by colleagues whose PC speakers were in danger of burning out from the incessant beeps of my first proxy utility.
Over the subsequent years, Fiddler was progressively enhanced with two extensibility models, a mechanism to automatically generate and modify responses, and support for secure (HTTPS) traffic, FTP, and HTML5 WebSockets. In 2012, Fiddler was ported to the Mono Framework, enabling it to run directly on Mac and Linux PCs and virtual machines.
Fiddler’s “About” box shortly after Telerik’s acquisition
The Easter Egg in Fiddler’s “About” box just before leaving Telerik
Appendix: Progress Announcement
Progress sent all registered Fiddler users the following email:
It started innocently enough. I saw a tweet about a new product offering from one of my favorite companies, Cloudflare.
Neat! I clicked through to the site and there it is:
And huzzah!, my preferred handle, @ericlaw is still available. I’d better hurry to claim it before someone else gets it!
Since I’m already a long-time Cloudflare user, I just need to sign in. That makes sense, how else will they bind the handle to my account?
Easy peasy. I’m in. Looks like there’s just one more step, I gotta authorize the new feature?
But wait a sec!
This looks exactly like one of those Consent Phishing attacks that have been so popular over the last few years!
And wait, why is the entry point on cloudflare.pay, a site that doesn’t already have my credentials, rather than something within the cloudflare.com domain which does (e.g. cloudflare.com/pay)? There is no inherent technical relationship between a .com domain and a .pay domain. Domain names under the.pay sTLD are available to anyone with $20 (unlike, e.g. .bank which requires more vetting), so there’s nothing that would stop me from registering my own cloudflarepayments.pay domain name in just a few minutes.
And why doesn’t Cloudflare’s permission site recognize its own company’s feature? And that green checkmark looks suspicious as heck– an attacker could probably just shove that emoji inside their misleading display name, the same way that folks trying to phish Microsoft email accounts use misleading app names and icons:
Fake Outlook OAuth phishing request
The guys at Cloudflare are geniuses who know their stuff. This has got to be an attack. It’s a clever one — I was feeling such a sense of urgency because I wanted to “win” the race to get my desired handle. Very very clever!
Unfortunately, the Cloudflare permission page doesn’t follow best practices, so there’s no “Report suspicious request” link I can use to let the Cloudflare folks know that their customers are under attack.
Let me go back to my Cloudflare dashboard and try to get to the Wallet feature from its sidebar. Hrm. It’s not there. Now, Wallet purports to be “a new feature”, so maybe the Dashboard just isn’t updated yet. A search of the docs turns up nothing. Let’s ask the AI agent in chat.
The very first thing the chat agent wants is access to my account:
This feels a little weird, but the page is still cloudflare.com so I guess I can give the thing access to things it already has access to. Weirdly, the AI agent first proposes that I grant it full control rather than read only access, which feels like a failure of the principle of least privilege, but I don’t actually need to ask an account specific question anyway. After granting read permission, the agent allows me to ask my question:
After a few minutes of further frantic searching, it turns out that this is, in fact, a legitimate new Cloudflare product and a legitimate site, despite giving every indication of being a clever phishing attack.
It further turns out that that suspicious green checkmark is not part of the app’s untrustworthy display name but instead a (poorly placed) security UI element that a user is expected to hover over to get the security details:
Update Aug 6th: The Cloudflare folks have improved this UI today. It now plainly shows the relationship information by default and not directly adjacent to the third-party string:
The Cloudflare folks apparently want security issues reported via HackerOne (which wouldn’t let me log in because the Cloudflare CAPTCHA HackerOne uses seems to be broken…).
When even legitimate websites sometimes act very very phishy, consider how hard it must be for URL Reputation services like Microsoft SmartScreen and Google SafeBrowsing to block malicious sites without false positives, especially in a world where millions of new sites are added to the web every week.
Lessons
Web Developers, please follow every best practice, I’m begging you:
Host apps and content under your trusted domain name (e.g. cloudflare.com/pay or pay.cloudflare.com. If you must add a new name, link to it directly from a page on your trusted domain name.
Show relevant security information in a trustworthy place when asking the user to make security decisions.
When a user attempts to run a file with elevated privilege, Windows will show a User Account Control elevation prompt that asks whether the user trusts the file to run.
For a regular file, the user will see a prompt like this:
For a file signed by a certificate in the Untrusted Certificates store, elevation is explicitly blocked:
For a file with a trustworthy signature, the user is expected to see a prompt like this one:
However, I’m sometimes sometimes surprised to encounter a different behavior when running signed files.
Surprise #1 – Windows Files are Special
The first surprise occurred last year when we were working testing the Defender Deployment tool. If we looked at the executable in File Explorer’s Properties dialog, we saw that it was correctly signed:
However, when double-clicking the file in Explorer, the UAC prompt behaved as if the file were not signed.
What gives?
After investigation, I learned that UAC has a special carve out for files that are signed by the Windows Build lab. If such a file is encountered outside of a limited set of directories deemed “secure” (e.g. %systemroot%\system32) the file is treated as unsigned.
Windows executables are non-hermetic so running them from untrustworthy locations can have dangerous outcomes. Showing the file as unsigned is intended to discourage a user from doing this.
Surprise #2 – Chain Building
Today, I was downloading the updater for the latest update to Telerik Fiddler and unexpectedly encountered the Unknown Publisher UAC prompt. Before I fired off a flaming tweet to the team, I double-checked the binary and…
What? I immediately thought of the “only special folders” case I hit last year, but of course this third-party file wasn’t signed by the Windows build lab:
To double-check, I looked at the same file on a different machine, where the correct UAC prompt appeared showing the expected publisher. Hmmm…
I asked Gemini, which hallucinated a plausible but incorrect answer:
I knew this guess was wrong right away because I’ve studied the MoTW behaviorextensively for decades. Gemini’s second guess was better:
This guess was non-hallucinated and plausible, but the fact that the File Properties dialog showed the file as correctly signed implied that this guess was wrong.
Still. I looked at my affected machine’s Trusted Root Certification Authorities stores. Note the s there– your trusted roots are a merge of two storage areas, one for your local user account, and one for your local machine.
And here’s where things get interesting: I’ve got the GCC R45 Intermediate certificate in my local user account but not for the local machine:
That seems… weird. Weird enough to be an explanation. I complained to Gemini that it had gotten it wrong, but didn’t wait around for its insightful answer:
Instead, I used an old signature troubleshooting trick, enabling CAPI2 Logging in the Windows Event Viewer, and getting another data point. The problem was indeed that consent.exe (the UAC prompt) was failing to build a chain to a trusted root.
At that point, I used the certificate viewer to export the GCC root from the local user store and imported it into the local machine store.
Success!
Now, unlike Gemini, I have access to the source code to Windows, so I went off to discover exactly what it had already told me in my forgotten browser window:
Gemini further suggested that I try using an Elevated command prompt to verify the file’s signature:
… but Gemini failed to recognize that using an elevated command prompt isn’t going to use the non-working SYSTEM context. My user account, even elevated, will verify the signature just fine:
Finally, only one real mystery remained: How did I have the correct intermediate in the local user store and why didn’t whatever magic put it there get it into the local machine store too?
AIA Fetching
By default, when Windows builds a certificate chain, if it cannot find the Intermediate certificate that the signing certificate chains to, it will look for a place to download that Intermediate using a process called Authority Information Access (AIA). And indeed, you can see the intermediate certificate’s URL right there:
As a part of chain building for a normal certificate validation, WinVerifyTrust will fetch the intermediate, confirm that it validly chains to a trusted root, and then use it to complete the chain.
Unless you tell WinVerifyTrust not to do that.
And, indeed, it turns out that UAC‘s consent.exe code disables URL fetching by passing the WTD_CACHE_ONLY_URL_RETRIEVAL flag into its WinVerifyTrust call. This flag prevents hitting the network to fetch information related to the certificate. Most of the time, that flag means not fetching a CRL or OCSP URL to see if the certificate was revoked, but the flag also controls whether AIA is used to fetch any needed intermediates in the rare instance that such an intermediate is missing locally. Like this one.
And there we have it. Explorer’s File Prompting and UAC’s Consent Prompt exhibit different behavior because Explorer’s signature verification uses the user’s certificate context and fetches intermediates via AIA, while UAC uses the system context and refuses to fetch intermediates. One way a software developer can help prevent this problem is to embed the intermediate certificate into the file’s Authenticode signature directly using the ac parameter to signtool.exe.
