I was bored yesterday so I started looking at Glasswire and how it works. It turns out that you can block a program in Glasswire from going online, but still go online through non blocked programs using the blocked program. So I made a small program to check this and sure enough. The program itself is blocked but can go online using a simple API call invoking i.e the default browser on the system or any other program that isn’t blocked by Glasswire. If I only use API calls the calling program won’t even show in Glasswire as the one trying to go online. In fact it won’t even show up in Glasswire at all if the program being called isn’t blocked.
On one hand I’m a bit surprised about how easy it is to bypass but at the same time I also understand the complexity of this. But can anything be done to prevent this ? or enhance Glasswire ?
We use the Windows Firewall API for blocking. If there is an issue with the Microsoft Windows Firewall API you could report this directly to Microsoft and possibly receive a bug bounty for your work.
If you feel we have somehow implemented the Windows Firewall API incorrectly with GlassWire you could report this to our own bug bounty program and we’ll pay you if this issue is real.
When submitting the bug bounty to us or Microsoft please include every single step in detail to recreate the problem. The info provided so far is extremely vague.
I’ve noticed this on the Glasswire Android app too.
3rd party apps can use Google Services Framework / Google Play services to sneak thru the Glasswire firewall. There are warnings concerning this behavior in the Glasswire UI ( ie for Whatsapp), and I’m not sure that much more can be done.
What you’re describing is normal Android behavior unfortunately and it’s not related to Windows. Windows works differently.
With Android some apps send data through “Google Play Services” for ads, or messaging in some cases. This is how Android itself is designed. To solve the issue you have to block Google Play Services, but of course that can cause issues sometimes if you want to update apps, buy apps, etc…
As Ken pointed out, Glasswire does not provide a unique firewall API, since it uses the Windows Firewall API. So if you have uncovered a leak, it’s most likely in Windows rather than Glasswire.
The above image is a snippet of what is shown on the Glasswire homepage. To me it looks like Glasswire is the firewall. I’m pointing out some problems and you are saying the problem is the built in firewall in windows. I disagree. I don’t care what API Glasswire use because that’s not what they are selling on their homepage. Don’t get me wrong I like Glasswire, but to simply blame the built in firewall is not right.
Edit
As it turns out if an app is badly behaved it cannot be blocked which was the point to begin with.
When designing GlassWire many years ago we thought carefully about the best way to implement the firewall blocking.
We ourselves did not feel comfortable replacing the built in Windows firewall with some unknown and unproven technology that’s not transparent to the user.
After researching carefully we decided the Windows Firewall API is the best option available because:
It’s trusted by over a billion Windows users world-wide along with millions of IT and Information Security Professionals.
It’s transparent, so GlassWire users can see exactly what we’re doing with the GlassWire firewall rules.
It uses almost zero resources.
It works even if GlassWire is stopped or not running.
It works on boot up before GlassWire starts running.
It’s unlikely to clash with or cause issues with any third party applications.
Many people use GlassWire with other firewall software because they prefer our unique network visibility tools. By using the Windows Firewall API we can avoid conflicting with those tools. In fact GlassWire doesn’t touch the Windows Firewall API as long as our firewall is switched to “Off”.
Stopping network connectivity is something that can make a machine completely useless. Accidentally introducing a bug to millions of people that could cause their machines to lose all network connectivity is not something our team wishes to be a part of and is frankly quite frightening to think about. Do you trust a firewall software on your critical organization infrastructure that isn’t transparent, and that can’t be easily reversed? That would be a tough pill for us to swallow, so we don’t try to force anyone else to do that. With the Windows Firewall API I believe the worst that could happen would be that the customer could go to the Windows Firewall and choose “restore defaults”.
To say that our software isn’t a firewall because we use an API you don’t like isn’t a fair comment. We could build our own ‘firewall’ without any visibility to the user on what’s happening but I don’t believe most security or IT people want that.
Thanks for your feedback and we’ll continue looking at new firewall technologies in the future. If something better comes along we’ll look at switching to it.
I will be on the lookout for your bug bounty report so we can continue to improve GlassWire.
GlassWire is essentially a handy user level front-end for the Windows Firewall, and uses the Windows firewall. I think that you may have misunderstood what using an API means on a technical level, and that is apparently a cause for a very common misconception of GlassWire. Maybe they could describe it better in layman’s terms on the marketing side. But that has become the norm for most 3rd party firewalls for the past few versions of Windows.
I wasn’t unjustly blaming the “built-in” firewall, I was trying to clarify that GlassWire uses the “built-in” firewall, and does not provide any additional firewall technology of its own.
I think that Ken’s explanation gives a good rationale for that approach.
I never said your software isn’t a firewall nor did I say anything about not liking the API. You are putting words into my mouth trying to defend your decisions. A decision you already explained. The problem is the wording on your homepage which in no way shape or form matches the performance of the firewall and also portraits Glasswire as the firewall. No where does it say Glasswire is using the windows firewall API. The windows firewall is recognized by many as being good at preventing things from getting in, but vastly inferior when it comes to preventing things from going out.
I’m not going to submit a bug report since this isn’t a bug but a design decision which have existed since windows firewall was first introduced with Windows XP Service Pack 2. Even if I did publish a video showing and describing how to bypass Glasswire it would be futile since the executing chain apparently isn’t something implemented in the windows firewall API nor in Glasswire.
I agree with you that it would be good to have this “loophole” closed but I don’t know of a single firewall that actually does this. Maybe someone else does. You’ve worked that out yourself when you say:
I’m largely writing the rest of this post to, hopefully, make it clearer to others who find this topic.
The GlassWire team are not directly addressing your query nor trying to close the “loophole” because they are referring you to the normal behavior for a firewall. But it would be good for them to acknowledge there is an issue and address you more directly than referring to what is common.
The problem that you found is not novel or unknown. I thought good on you for trying it out which is why I liked () your original post. I’ve had a similar problem with some Windows processes which have to be blocked outside of the Firewall. For example:
You created an Inter-Process Communication (IPC) to get another process to perform the network communication. You performed this on the same system so this is normally called a Local Producedure Call (LPC). If the other process were on another system then it would be called a Remote Procedure Call (RPC) and these are monitored by firewalls because they cross the firewall boundary.
This is where host-based/IP-based blocking would be useful to allow us to block communication through processes we want to give access to the network (e.g. our web browser) but which we don’t want to be used. Using my example of trying to block Windows telemetry would be easier if I could block any Microsoft hosts in GlassWire.
GlassWire is functioning as a firewall utilizing the “Windows Firewall with Advanced Security API”. It is normal for Windows firewall software to do this to varying extents. Glasswire is a firewall even if all the firewall functions aren’t performed using its program code. So there is no need to change their website. But a clearer explanation of how it works would be useful to more technical users.
The same situation occurs with anti-virus software which now use Windows APIs. Anti-virus software is still anti-virus even if all anti-virus functions aren’t performed by their program code.
The technical explanation is that the Windows Advanced Firewall (old name) or Windows Defender Firewall (new name) is actually performing the blocking when GlassWire uses the API.
As of today I have taken it one step further. Using BITS ( Start-BitsTransfer) I was able to download a file from my NAS (It could be any device, cloud or server - since BITS supports authentication) without any issues or detections. Using Start-BitsTransfer in Asynchronous mode complicates the problem further, since a file transfer will be initiated as a background process and will even persist between reboots without the involvement of the initial executing chain. You can see the transfer taking place in Glasswire,but no alarm or attention is raised. What complicates things even further is the fact that BITS can be initiated remotely as well - which I didn’t try.
I posted this earlier in the thread, but in case you missed it Microsoft and GlassWire both have processes for reporting bugs. Here is another link to our bug bounty program where we pay money for bugs and you can see Microsoft does the same. You can then get paid for your hard work while getting the bug fixed.
If you feel this is a real issue please file a detailed report with steps on how to do what you claim so we and Microsoft can both improve in the future.
i guess glasswire is useless against hecklers and virases ? they surely know how to use this glasswire bypass/exploit to download files undetected. in tis case glasswire provides false sense of security. glasswire does not help against hecklers and vid.
Are you having an issue with “hecklers and virases”? If so please let me know the details so I can help.
We use the Windows Firewall API for blocking. This API is created by Microsoft itself and it’s in use by over a billion Windows users world-wide, so we trust this API for use with our firewall.
The API created by Microsoft has no known exploits/bypasses that I know of, but the Windows Bug Bounty program is here Microsoft Bounty Programs | MSRC.
If you feel we have implemented the API incorrectly somehow, our own bug bounty program is here: HackerOne
) your original post. I’ve had a similar problem with some Windows processes which have to be blocked outside of the Firewall. For example: