Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

SV8100 hacked, toll fraud 1

Status
Not open for further replies.

bigdave1980

Systems Engineer
Dec 18, 2017
192
2
18
GB
Hi all,

We've had an SV8100 hacked and the attacker has made a series of calls to international numbers. Most of the following is based on assumption and my limited knowledge of the system, but please have a look and let me know if this would even be possible. First off, it seems that the SIP router was not secured in that it was possible for any outside IP address to reach the SV8100, owing to an entry which was missing from the router's access control list. Secondly, the usernames and passwords were secure but it transpires that connections to the DIM port were enabled and the DIM username and password were the defaults. Having said that, I don't think somebody from outside could have reached the DIM as there was no port-forward/NAT translation on the router to take external traffic to that specific port.

However the attacker was able to get access, they appear to have created themselves a Manufacturer level user account and then used that to log into the system with PCPro or WebPro.

Once in the system, they have changed 0 in the numbering plan from Operator to F-Route, and have set up an F-Route to take calls out over a trunk group, without adding or stripping any additional digits.

They have then dialled into one of the DDI's on the system. The DDI points at a VRS message which has 4 associated AA single digit options. The first option points at a virtual extension which is on a call forward always to an external number. This is normal and has not changed. The other 3 options all point at a loopback which in turn points at a department group pilot number - this too is normal and has not changed. All unused options simply play the same VRS message again. With that in mind, I do not know how the attacker has been able to break out of the VRS-based auto attendant and dial external numbers.

The call logs show that on several occasions the attacker only made a single call into the system, but from there they were able to make 10 or more calls to external numbers without having to hang up in between - I don't know how that would be possible?

Sorry it's a bit long, but based on the clues above is anybody able to suggest how they would have been able to break out from the VRS message to make these calls? I don't think they have done it via a mailbox as none of the AA options go to voicemail.

Thanks in advance,

Dave
 
That seems weird. BUT, not having that system locked down from outside access is a huge red flag. I would restore from a backup and lock it down and make sure you are running the latest 8100 firmware. So many of these system were put in by a large company with BOX in their name that shall not be mentioned have so many programming errors to seem almost incredible these system even function at all.
 
@CoralTech Thanks for the reply. I've already upgraded the firmware and locked it down as far as I can. The router's been locked down too so nobody's getting to the NEC unless they come from behind our company's public IP address or from the SIP provider's address range. I've run a Verify between the system in its hacked state and how it was when last backed up a few months ago and this has revealed the various changes that were made. I have reverted the changes and it all seems ok so far, fingers crossed. Whoever it was knew what they were doing, and certainly more than I do. Probably a support guy or an ex-support guy who's gone over to the dark side, I thought.
 
Could be. There are so many NEC systems out there it's pretty staggering. People mention Cisco and I laugh because we know who the big boy in the room is... :)
 
Ok so the fact that they had a Manufacturer level password means they could have changed things and then put them back after the event to cover their tracks. I personally wouldn't change the passwords, I always leave them at default. The reason I do this is the passwords can only be numerical and those can be cracked pretty quickly by any decent hacker. However I do change the usernames, reason is they can be as random and as complex as you can get and remotely, the only way you can access the system, is with a user name and password. As you can imagine if a hacker goes through the usual usernames and tries all number combinations possible (simple to automate) they then realize the username has been changed and they are looking at Everest!

The big advantage of this is that if you then lose the logins, you can login via a handset with just the default password (secure because you have to get to a phone to do it) and you can look up the username.

I'm still trying to work out how they managed to get a manufacturer password, however they gained access!
 
@coraltech

Ever heard the true story about the cisco dealers at a conference who called the presenters out about Cisco's security only to be told they were wrong. The hotel had a cisco system so they went back to their rooms and proceeded to hack the hotel's accounting system through the telephone system using a freely available program called VOMIT (Voice Over Misconfigured Ip Telephony). They went into the conference the next day and threw it in Cisco's face!
 
@OzzieGeorge Hi, yes you are very correct and that's a good idea. I choose complicated usernames but also change the passwords as well, maybe I'll not do that in future and just change the usernames only. With regards to the manufacturer password, it was left as the default so mystery solved, they've just logged in with the defaults as the router was not secured as it should have been. Interestingly the router is now secure and I have set the Manufacturer account to be a prohibited user, but after saving the changes and waiting a while I can once again connect to the system and see the Manufacturer level account is active again. Maybe part of the issue is that I need to be logged in at Manufacturer level in order to actually see the account under 90-02, and therefore I can't effectively disable that account as that's the one I'm logged in as? EDIT - I'm not actually logging into the system with the Manufacturer account as I incorrectly said before, my mistake, I am logging in as installer level.
 
We had a customer a month ago who was hacked by exploiting the Find me Follow me in the In mail. Naturally because they used weak passwords any lame hacker could figure out.



There are 10 kinds of people in the World.

Those that understand Binary and those that don't.
 
The 8100 was before our time. We learned some tough lessons about hacking on the 9100.

The modification history logs helped us a lot during incidents as well as teaching us what to secure.

I am ashamed about some of these but if they prevent future pain...

If you are using standard SIP phones via NAT, create hard passwords. If you can, only accept SIP requests from known IP addresses. A SIP scan can find you even if you use a non-standard port and a non-complex password will be broken pretty quickly.

Check databases for unknown SIP phones that may have been created if someone gets in via a MFG or Installer user. Carefully check IP addresses of registered SIP phones. We had someone log in as a conference room phone late at night and make calls as the extension. We caught it by noticing the IP of the phone was showing registration as a public IP address in WebPro. Knowing this shouldn't be the case, we looked deeper and found the password was simply the extension number. We had the customer make a better password and convinced them that SIP over NAT was unneeded. They thought they might "like to have it" until they saw how easily it could be used against them.

Change the username for the necii login. The default password for necii is easily found on Google. This was our first hard lesson.

Do not allow Webpro access from the outside. Makes it way too easy for the bad guys. Use TeamViewer or Google Chrome Remote, or any secure remote access to a PC from outside and then Webpro. I would also say the same for PC Pro. If you are compelled to keep this, change the default user names "necii" and "tech" to more complex names to at least strengthen the lock. Disable all other unused logins.

Lock down VM ports to only dial local calls unless need is proven otherwise.

Block international calls at the system and carrier level unless they are really needed.

Encourage users to use good security codes on voice mail boxes.

In 90-28 remove passwords for User Level programming. Especially if you are going to keep Webpro access via NAT.

This is by no means an exhaustive list, but it covers some of the basic "gotcha's
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top