[Feature Request] Add FRP antivirus note to documentation/README, maybe make FRP more visible on windows.
ZeroVocabulary opened this issue · 6 comments
Describe the feature request
FRP is a reverse proxy, which has good uses, but is also useful for getting past firewalls and security.
There are reports of malware using FRP to communicate so that they are not as easily identified:
- Attackers Using FRP (Fast Reverse Proxy) to Attack Korean Companies
- Fast Reverse Proxy Backdoor Analysis Report (IRIS-13302)
On a VirusTotal scan, you can see from the naming that some antiviruses are simply detecting it because of the utility for malware even though the antivirus vendors know it is not malware.
- ESET-NOD32: A Variant Of WinGo/Riskware.Frp.C
- Kaspersky: Not-a-virus:VHO:NetTool.Win64.Convagent.gen
- Sophos: Mal/Generic-S + Fast Reverse Proxy (PUA)
- Symantec: FastReverseProxy
- Zillya: Tool.Frp.Win64.41
- ZoneAlarm by Check Point: Not-a-virus:VHO:NetTool.Win64.Convagent.gen
etc.
Because of this, I doubt that it will stop being detected, and the likely best outcome is FRP still getting detected but marked as Not-a-virus, HackTool, Riskware, etc. so that users are not scared.
The documentation/readme should mention this in order to avoid confusion, particularly for windows users.
Maybe visibility on windows could also be increased, but it might make it uglier/be a distraction. For example, an icon could appear in the system tray or taskbar when FRPC is running, which would make malware authors more likely to avoid using it.
Describe alternatives you've considered
No response
Affected area
- Docs
- Installation
- Performance and Scalability
- Security
- User Experience
- Test and Release
- Developer Infrastructure
- Client Plugin
- Server Plugin
- Extensions
- Others
Can you commit a PR to update the README?
Hi, @fatedier, can you give the reports a closer look?
Apparently some features offered by FRP also made it a good tool for by hackers to facilitate actual attacks.
While changing the README is necessary to make users aware of the anti-virus situation before download/deploy, fundamentally something has to be changed in order to make this software less useful for attackers.
Showing an icon in the Windows system tray could be useful, but I'm afraid not to the degree that we might have hoped, since the analysis hosted on IBM X-Force Exchange suggested that the attacker might deploy their own fork of FRP with it's source code modified to help with their attacks. This in turn suggests that the attacker might also just remove whatever stinker code you put into FRP.
Maybe you can ship two versions? One open sourced one with limited forwarding capabilities (can only proxy specific protocols such as HTTP/HTTPS/FTP etc), and a close-sourced one with capability of relaying arbitrary TCP/UDP connections under numbers of hard restrictions (for example, hardcoded destination/port allowlist/blocklist).
Maybe you can also sell the close-sourced one for a profit too, which might help improve the personal situation that you've mentioned in the README file.
The reason for detections is that reverse proxies are used to bypass firewalls/port restrictions (whether that be for legitimate or malicious reasons). Reverse proxies are the core feature of frp, so I don't think it is possible/realistic to reduce the usefulness to malware by removing features. I don't think the protocols matter; malware can easily switch and its a huge restriction for users.
With regards to forking/modifications, forcing malware authors to modify the program allows antivirus to flag the modification rather than the whole program. Beyond that, code signing/certification could be used to stop the files from being modified.
I'm not sure it is worth trying too hard to remove detection/appease AV via modifications, as AV vendors probably will not care. If I were managing a company's computers/network, I would prefer that these tools be flagged and require approval from admin/IT for use, which is probably the mindset the AV vendors have here. The fact that some AVs already mark it as not-a-virus shows that they know it is not malware but still wish to restrict it anyway due to its capabilities.
For the English readme update, I added a small addition to the examples (installation) section informing users about the problem. I linked this issue if people want further information.
I guess the issue can remain open after the readme change if the maintainers think more discussions/improvements can be done. Two improvements I like are:
- Visibility improvements as mentioned earlier (taskbar icon), and code signing. Unfortunately, I am unfamiliar with code signing, Go, and Windows Api's, but I believe this can be used to add an icon: Shell_NotifyIconA. There is some information about code signing/certificates on this page.
- Communicating with antivirus companies and asking them to either stop flagging frp or to flag frp with a less dangerous-sounding message i.e.. not-a-virus, NetTool, HackTool, Riskware etc. This page has a list of vendors and ways to contact them
I might try to do # 2 (will make a new issue if I do).
The reason for detections is that reverse proxies are used to bypass firewalls/port restrictions (whether that be for legitimate or malicious reasons).
I understand the thinking, but I couldn't agree with the conclusion, since there are other reverse proxies out there, and antivirus software is giving them a complete different treatment.
For example, cloudflared can too facilitate reverse proxying while not been marked as any risk according to this VirusTotal report, the same is true for Inlets Pro and ngrok.exe too.
All of those are reverse proxies, Inlets Pro even allows you to self-host, just like FRP. So what is the different that made FRP (and NPS actually) a target? Or, to put it into other words, why hackers used FRP, not Inlets or cloudflared or ngrok or even just good old socat?
Or, to put it into other words, why hackers used FRP, not Inlets or cloudflared or ngrok or even just good old socat?
Well, because frp is smaller, faster and easier to deploy. And it's basically freeware, ngrok is commercial and they will file lawsuits if they mark it as malicious, because it will END the company in one day. It's all about corporate mentality.
Anyway this AV issue will never go away.
The only solution/workaround I found for this is by using a (rather convolute) WSL2 approach i.e. run frpc/frps into this Linux layer they built into Windows.
100% legit.
P.S.
Anti-viruses and "security softwares" are the NEW SOFTWARE MAFIA/MOB.
@Wyk72 , I tried to run frpc in WSL2 using latest 0.53.2_linux_amd64, but when I run frpc, it tells me :
-bash: ./frpc: cannot execute binary file: Exec format error.
Do you encountered this and how to solve it? Thanks