/var/www/html/admin/assets/js/modgettext.js altered. Hacked?

IMO this sort of blocking gives a false sense of security, because anyone specifically attacking your server will come from a source in your country.

If you only want to defend against the automated tools that probe every IPv4 address on the internet, it is much simpler and more secure to use strict SNI, as the attackers don’t know your domain name.

OTOH, if you also want defense against targeted attacks, take the effort to use client certificates (or a VPN). In the long run, this is less work than updating blacklists, analyzing logs, etc.
See “How can I force clients to authenticate using certificates?” in SSL/TLS Strong Encryption: How-To - Apache HTTP Server Version 2.4

Where did you come up with this logic?

Well I suppose there could be an occasional exception, but competitors, disgruntled employees and contractors, etc. all know who and where you are.

I’m sorry but that is very poor logic. Go through this forum alone and look at the hacks that are reported. You know like the thankyu hack or others where people end up with $4K phone bills. These weren’t former employees or competitors.

I compete with ATT and Comcast in my market area, based on your logic I should be concerned they might DDoS me or try to hit me with a FOP2 exploit.

I rigorously enforce strict SNI using haproxy , the admin page on a completely different domain than UCP on a different domain than provisioning, also for fop2, so no IP based drive-by’s here.

If you look at your logs over the last couple ‘penetrations’ you will see a C&C type behavior from that ASN , first the worker bees probing, then more directed, I saw that on a server needing rescuing a few months ago but you will likely see that ASN slowly buy persistantly knocking at your open ports, not necessarily the ones you expected.

We have many PBXes hit. Every PBX hit had FOP2 open to more than know networks. Every hit PBX had, in fop2/lang a file ko.php - dates vary, but none were recent, and each had an index.php file. Confirmed that non-compromised machines did not have ko.php nor index.php.

We really need to understand the vector here so we can know we have things secured.

Do you know how the attackers discovered any of these domain names? I thought that if it’s not in reverse DNS, not an obvious subdomain like sip.yourcompany.com and not visible via certificate transparency, you should be safe.

AFAIK, 100% of the hacks reported here were discovered by automated scanners and not targeting a specific victim. I believe that the vast majority are of this type, though there have likely been a few targeted attacks. I suspect that the targeted victims would in general not post details in a public forum.

None of my machines behind a reverse proxy where penetrated, the ones I saw where the result of drive-bys where the domain was leaked by the webserver initially serving connections to a bare ip. A reverse proxy can be configured such that there is no backend for IP/port connections, the front ends only forward a connection itself has validated certs for.

I am surprised to see nothing has yet been posted about this on https://forum.fop2.com

It was, years ago. There was an exploit found in v2.31.03 which was released towards the end of 2016, Flash Operator Panel 2.31.03 - Command Execution - PHP webapps Exploit (exploit-db.com) now that has a wee bit different content in the index.php that was added but the same concept.

The issue, IMO, is the fact that around 2016 to 2018ish where Nicolas kind of let the project go and was doing other things. To the point that around 2018 people were asking him if the project was dead, including me. Over the last few years he’s been releasing updates every 3-4 months it looks like. There were about 3 updates in 2021, there have been three so far in 2022. Hard to say if this has been fixed as other issues like urlencoding problems having be resolved over the last year or so. You really can’t trust the release numbers on older versions because there have been cases where it has jumped a bit between releases.

@xptpa2020 Since you seem to have multiple boxes with ko.php/index.php in them, what is the newest ones found on the boxes? Are we still taking around 2020-ish? Have you had any boxes compromised with this in 2021 or 2022?

Looks like my fop2 lang folder (fop2/html/lang, if that sounds right) is free from ko.php or index.php.

Do you think ko.php is a bad file all around? When I did a search I found a few places where there is a ko.php file.

This is a good question. I am searching my PBXes for the file anywhere.

I did notice that the file size on the ko.php files you have are small, 1-8k. The “bad” ko.php files in fop2/lang, are much larger.

Can you see what that process is that is using the ko.php?

Well, the ko.php might be a red herring. I’m finding it on other boxes and in the FreePBX repos under certain vendor libraries. What made it stand out for me in FOP2 is the fact 1) it doesn’t exist on a newer install. 2) the file has a bunch of code in it none of the other language files has. 3) It was modified at some point.

However, the index.php found in the FOP2 lang directory is a problem as it is an upload script to write files to any location on the system.

So what is the date/time of the /var/www/html/fop2/lang/index.php file that you find?

This is what I’m seeing:

What is this supposed to be showing us?

I think this shows that previous post by ksdpbx has a process id of 13308 using KO.PHP. The second post shows that process ID to be asterisk.

I did not save a snip that shows that data, but the KO.PHP file in fop2/lang was never a current date. The date was always a few years old - namely June 2020 - from what I remember.

So you don’t have the index.php file anymore on any of the systems?

Our new installs do not have the index file. We deleted the index file on all PBXs

Thanks. I was trying to see if the exploit might have been fix in the last couple years but once you were hit, it didn’t clean it up. So far this other box has been running for 2 years and has the user side open for access. Been clean so far.