Some kind of Hack

1

Hello All,

Running: 6.12.65-32

Trying to figure out how someone has made several international calls.
IPS in this log: 1.2.3.4 is the PBX and 5.6.7.8 is the hacker.
I verified the extension they appeared at had an outrageous password as automatically generated, so this may be some other method of authenticating.
Since I can see the IP I used that to search all log files and can only see the IP in the fail2ban logging in /var/log/astersk

The log shows that they are passing the international number they want to dial in the “AccountID” value.

fail2ban-20161007:[2016-10-06 23:10:30] SECURITY[7788] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“1475809830-790217”,Severity=“Informational”,Service=“SIP”,EventVersion=“1”,AccountID=“0112917162381”,SessionID=“0x7fe55ca2dc68”,LocalAddress=“IPV4/UDP/1.2.3.4/5060”,RemoteAddress=“IPV4/UDP/5.6.7.8/6036”,UsingPassword=“1"
fail2ban-20161007:[2016-10-06 23:12:18] SECURITY[7788] res_security_log.c: SecurityEvent=“ChallengeSent”,EventTV=“1475809938-832691”,Severity=“Informational”,Service=“SIP”,EventVersion=“1”,AccountID="sip:[email protected]”,SessionID=“0x7fe55c4f60d8”,LocalAddress=“IPV4/UDP/1.2.3.4/5060”,RemoteAddress=“IPV4/UDP/5.6.7.8/6036”,Challenge="14863ecb"
fail2ban-20161007:[2016-10-06 23:12:19] SECURITY[7788] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“1475809939-54614”,Severity=“Informational”,Service=“SIP”,EventVersion=“1”,AccountID=“01150427888372”,SessionID=“0x7fe55c4f60d8”,LocalAddress=“IPV4/UDP/1.2.3.4/5060”,RemoteAddress=“IPV4/UDP/5.6.7.8/6036”,UsingPassword=“1"
fail2ban-20161007:[2016-10-06 23:12:24] SECURITY[7788] res_security_log.c: SecurityEvent=“ChallengeSent”,EventTV=“1475809944-888588”,Severity=“Informational”,Service=“SIP”,EventVersion=“1”,AccountID="sip:[email protected]”,SessionID=“0x7fe55cad6eb8”,LocalAddress=“IPV4/UDP/1.2.3.4/5060”,RemoteAddress=“IPV4/UDP/5.6.7.8/6036”,Challenge="36b601ee"
fail2ban-20161007:[2016-10-06 23:12:25] SECURITY[7788] res_security_log.c: SecurityEvent=“SuccessfulAuth”,EventTV=“1475809945-108512”,Severity=“Informational”,Service=“SIP”,EventVersion=“1”,AccountID=“01150427888372”,SessionID=“0x7fe55cad6eb8”,LocalAddress=“IPV4/UDP/1.2.3.4/5060”,RemoteAddress=“IPV4/UDP/5.6.7.8/6036”,UsingPassword=“1”

2

At this point are you still trying to prevent the international/hack calls or just trying to sort out how it was done?

3

I have disabled the trunk for international calls, but I do want to understand how it was done and try to prevent it not only on this server but others.

4

Are your database or admin web servers open to the Internet?

Did you send the password out to the recipient in an e-mail?

Have you checked the PCs of the people that are supposed to use that extension for Trojans/keyloggers?

Has anyone in your organization taken a call from “one of your users” asking for the SIP password?

Did you change the extension password and was the new password compromised?

Guessing a 32-character password is pretty “not happening”, so it’s got to be something stupid.

5

The phones are provisioned via EPM, the password was NOT changed to something simple, it’s the autogenerated password.
No one has access to the passwords or the management UI.

6

My point exactly. No one is going to just guess it, so the only way the password could get compromised is through a system access failure or through human engineering.

Clearly that isn’t the case. Someone outside your organization is using the extension and the password is correct. The password has been compromised, either through access to the Web GUI, the database, or through a user e-mail. Someone has access to that password - you need to change it to another complex password.

Did you look for any of the “usual suspects”? Did you look through your user manager and make sure that there are no unauthorized users in there? Did you check the /etc/asterisk/manager*.conf files to make user that no one has added a new management user? Check your system for unauthorized outbound routes? Bad inbound routes?

The recent “Hotel Wakeup Call” vulnerability allowed one of my systems to be compromised and they tried to install a bunch of stuff that could have done a lot more damage if I hadn’t caught it.

7

Do you not think the fail2ban logging looks a little strange and may have some assistance in pointing to the issue?

I can change the password, but it can happen again.
I did look for the usual running apps, files in tmp and root, but all looked good.

8

Yeah, the fail2ban log is interesting, but I’m not a SIP expert. We probably need @xrobau or someone more well versed in the intracacies of the protocol to weigh in.

9

I would have to point out that it is not actually a fail2ban related log, it is a log produced by Asterisk’s “security” logging that is called fail2ban.log and watched by fail2ban , but because the result of the challenge was “successful” then please don’t blame fail2ban. Apparently 5.6.7.8 knows enough about 1.2.3.4’s accounts to bypass the firewall, it is probably not from asterisk, (perhaps 5038 if open) but likely by another successful penetration of the FreePBX code that allows "AccountID=“0112917162381” to be accepted which is a number in Eritrea, AccountID=“01150427888372” which is a number in Honduras, I suspect a bigger problem here . . .

Perhaps

has already found that vulnerabilty. . . .

10

Thanks for the reply dicko.
I wasn’t blaming fail2ban, I was pointing out some of the parameters available in the log which gave me the impression that possibly a different app was being passed values which allowed someone to somehow create a call. While we take certain steps to secure all of the servers, this one is on cloud, so we have a little less ability than when it’s behind a firewall. We did use different http ports and ssh ports, but in this case, I was trying to figure out what app or method was used to compromise the box.
We will have to upgrade this to FreePBX 13 to utilize the new firewall features and take advantage of newer code.

Do you know which vulnerability this utilized, you mentioned “has already found that vulnerability”

Thanks again!

11

No I didn’t suggest that anyone has “has already found that vulnerability” , but the fact that “AccountID=“0112917162381” et al is acceptable suggests to me that something untoward is happening, ( I have been closely watching “penetrations” for years and generally caught them eventually, to me this looks like a new one”), I will leave it to the experts to parse what is happening and if it happens to me i will also be vigilant.

12

I’m curious what your CDR logs show for these calls? Do they show up as normal calls or something “different”?

13

The log looks 100% normal call, like if a specific extension made the call.

14

dicko, to me it feels like some facility is being passed the information, rather than a user registering with a password and then requesting the call.

Also, looking at the [email protected], what do you think of blacklisting 1.2.3.4? I’m sure an easy thing to try another IP but if it’s scripted maybe they won’t analyze it and move on.
Now I’m leaving the above in, just because, but of course the user isn’t at 1.2.3.4 so it’s just conforming to the requirement of user@ip, so that probably won’t work since a blacklist will only block the legit 1.2.3.4. Sometimes you think of something and then realize hmmm, no.

15

What kind of external access to the PBX exists (do you limit access by source IP?), and how are the configurations to the phones transferred (tftp, ftp, https, etc.)?

16

Hi there,

Sorry to warm up this old thread… However, - this problem still exist also on newer fail2ban versions. The following failregex works definitely better, it is more effective then the original one in asterisk.conf (which should be updated):

^(%(__prefix_line)s|\[\]\s*)%(log_prefix)s SecurityEvent="(FailedACL|InvalidAccountID|ChallengeResponseFailed|InvalidPassword)",EventTV="[^"]+",Severity="[\w]+",Service="[\w]+",EventVersion="\d+",AccountID="\d*",SessionID="[\da-fx]+",LocalAddress="IPV[46]/(UD|TC)P/[\da-fA-F:.]+/\d+",RemoteAddress="IPV[46]/(UD|TC)P/<HOST>/\d+"(,Challenge="\w+",ReceivedChallenge="\w*")?(,ReceivedHash="[\da-f]+")?(,ACLName="\w+")?$

I can confirm that it works with stock fail2ban 0.9.6 (under FreePBX 11). I have found this updated code at https://www.ip-phone-forum.de/threads/neue-hackversuche-fail2ban-muss-angepasst-werden.284351/

17

The ‘most effective’ way to make changes like this happen is to submit a “Feature Request” ticket so the code monkeys will see it.

18

Really the most effective way is to actually check on current versions what is being used and if this was actually resolved. We’re talking about FreePBX v11 here and we’re on v14. There have been some changes in the last 5 years that might need to be looked at first before submitting a feature request against a 6 year old release of the project.

19

This error is most likely also present at more recent FreePBX versions. So far I know these have no newer version then fail2ban 0.9.6 installed. (The outdated failregex is part of fail2ban and not Asterisk or FreePBX.)

Whatever, someone should contact the original authors of the asterisk.conf fail2ban filter file.:wink:

20

I honestly wouldn’t know. I don’t use fail2ban, I like to stop things before they actually happen and am just told about it later.

1 Like