IP Office 500 - Can this be compromised?

[BSFH]

Hi Guys,

I've inherited an IPO 500. Having no prior experience with administrating telephony systems, and no training on this one, I have some pretty big gaps in knowledge. Before I hit my shiny red PANIC! button I wanted to confirm as to whether you've ever heard of an IP office unit being compromised or otherwise attempting the below comms. My specific issue is that our IP Office is generating traffic with a fake IP, trying to talk to other IPs that while routable, don't exist. It is attempting communications on a wide variety of ports and protocols. We recently upgraded the firmware, but its still occasionally trying. To give you some idea of what its attempting:

Attempted to reach (external IP, "A") on UDP 2427
Attempted to reach (internal, non-dhcp range IP) on UDP 137
Spoofed IP from above (external IP, "A"), attempting to reach external IP, "B" on UDP 14378
Spoofed IP from above (external IP, "A"), attempting to ping external IP, "B".
Spoofed IP from above (external IP, "A"), attempting to reach external IP, "C" on TCP 19954
Spoofed IP from above (external IP, "A"), attempting to reach external IP, "D" on TCP 26424


As far as I can tell, there is no external routable access to the IPO, with the exception of VPNs. I'm hoping to get superior firewalls soon which should let me get greater visibility of what is going on.
Within the IP Office Manager I see no references to any of those external IPs. It should only declare itself on an internal IP. The external IPs do not and have never belonged to our organisation.

So to return to the original question. Could an IP office be compromised and execute code? I've opened a case with our maintainer as well, but just wanted to hear directly from the community as well.

 

[Westi]

none of these ports are listed as ports the IPOffice does anything on.
2127 is a port it had dealings with in older releases for CCC Wallboard

Spoofing an IP address is also not something the IPO really does.
Is the second LAN port maybe the "spoof" IP address or is there something connected to that port that would try to go through the IPO?

Joe W.

FHandw, ACSS (SME), ACIS (SME)

http://convergednetworks.ca

Give a tech a solution and he will be back tomorrow to ask you the next question, teach a tech how to read the manual and he will be able to solve the problems for a life time.

 

[BSFH]

No I don't think so. I've checked the LAN 1 and 2, and any SIP / STUN / DNS etc IPs to see if there is any mention of those IPs anywhere. When I say "spoof" I just mean its packets have a source address which is an IP it doesn't own. ie non-routable through public internet.
The IPs themselves are all over the world- China, Georgia (Eastern Europe), Germany, US etc. The IP Office is based in Australia though.

 

[hairlessupportmonkey]

The IPO 500 can not be "hacked" to run dodgy code (apart from the dodgy code Avaya put in it) Its a solid state proprietary hardware platform.

The IP1000 (server edition) might be different as it runs on linux

I wouldnt get too stressed about it, its probably some false positives your FW is throwing up.

ACSS - SME
General Geek

 

[BSFH]

I'm detecting these packets just after they leave the IP Office- the mac address on the packets is that of the IP Office unit. This was accomplished by mirroring the port its connected to and capturing packets with wireshark.
I agree that its not necessarily a compromised system, but nor should it generate these packets at all. I just can't find an explanation for it. The unit has been in place for years, but these alerts only started happening in the last few weeks.

 

[mattKnight]

I would look again

I suspect *something* is compromised, but highly likely not the IP office

Some of those UDP ports (google says) look like trojan downloaders...

How many devices use the IPO as their network gateway - concentrate on checking those out - I suspect you'll find a virus/malware on a windows box - possibly even VM pro!



Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[Edata]

BSFH, the IPO does search the network for open ports but what you are see is not the IPO. to be sure, download wire shark and install on a pc or server. run the software and you will find the ip address of the system doing the request. you and also while running the wire shark turn off the IPO. with the resolute you will then know if the IPO is the origin or another device.

ACIS, ACSS, IPO expert,
ACDS, ACSS, Enterprise

http://www.edataelect.com

 

[Bas1234]

I would hit the PANIC BUTTON!

___________________________________________
It works! Now if only I could remember what I did...

Dain Bramaged (Avaya Search tool

http://tinyurl.com/bas1234

)
______________________________________

 

[Westi]

edata
if you read the post 2 above yours then you will see that he ran wireshark and that is how he found the information that worries him.

This was accomplished by mirroring the port its connected to and capturing packets with wireshark.

BSFH
if you have no IP sets and no SIP trunks then I would try and take the IPO off the network and run wireshark without the other network connected just to see if that still happens. I agree with HSM that the only dodgy stuff comes directly from Avaya but nobody has ever heard of someone being able to hack into the IPO to make it kill your kittens or strangle your dog or whatever Trojans and viruses and all the other bad stuff does these days.

Joe W.

FHandw, ACSS (SME), ACIS (SME)

http://convergednetworks.ca

Give a tech a solution and he will be back tomorrow to ask you the next question, teach a tech how to read the manual and he will be able to solve the problems for a life time.

 

[mattKnight]

I'm still going with a compromised windows box routing through the IP Office

Take Care

Matt
I have always wished that my computer would be as easy to use as my telephone.
My wish has come true. I no longer know how to use my telephone.

 

[BSFH]

Thanks for the replies so far guys. Some good ideas so far but I don't think I can rule the Avaya server out.

The reason for that is the way port mirroring works.
##Boring back history here.
In the first place, I didn't know it was the Avaya server generating this traffic. All I knew was that the firewall was receiving packets with public IP's as a source, on an internal interface. (So the layer 3 properties were fake, and the layer 2 properties will only take me to the last device to have the packet)
I had to mirror traffic 1 segment at a time, and filter only on specific's of the layer 3 details I had. I worked my way from most serious segments, to least likely segments. Which is to say, I checked unprvilieged ports, privilieged ports, server ports, DMZ ports and so on. The Avaya server is on the telephony segment, and so was my least concerrn ("who would hack an IPO or IP Handset?"). It was the last segment.
Once I had found the segment, I then collected as many packets as possible, and sorted by source mac. There were only 2 source MACs for the IP-
The first source mac is the switch's MAC. This is when the switch is passing the traffic up to the next hop.
The second source mac is the Avaya's MAC. The Avaya is only plugged into 1 port on the switch (ethernet). The only other cables running into it are not ethernet- ISDN, Analogue lines into the analogue card.

##Discussion of theory here
So lets assume for a moment that the Avaya is acting as a gateway for other traffic. Whatever the true source was, if it passed the packet to the Avaya server for handling, it would have to traverse the port I'm monitoring. I would then know its MAC. But I had the port mirroring for hours, and waited a good 5 minutes for the traffic to cease its burst before finalising the capture. Only the 2 MACs. I've been in this long enough to know that I know nothing. The sheer number of ways to do crazy stuff in networking is beyond me ever knowing for sure. So all I can say is that at my best, with all the knowledge I have of TCP and the Avaya system, the packets have to be coming from the IP Office unit. The packets come whether its firmware was v7 or v8.1

So I reach out to hopefully crowd-think of ways that this traffic is not from the Avaya, ways that I've mishandled my data, or misunderstood the nature of the traffic. I'd love to wave it off, but my industry requires a bit of precaution. And after Stuxnet, it would be a little silly to assume that Avaya IP office units are more rare than specialised siemens industrial controllers. Even if they don't handle plutonium enrichment, they do handle communications and have inbuilt unannounced 'intrude' functionality which is probably really useful in the information age.
I'll also see if I can get a copy of the packet capture up here.
I can't turn off the IPO, we're a 24/7 company.
The IPO500s in our other offices are not generating similar traffic.

 

[amriddle01]

Bear in mind that the IP Office is also a RAS server, does the maint company have ISDN dial in? Say for example I dial into a customers IP Office I can make the IP Office my gateway and then if I programme it corrretly can use any address I like to try and attempt connection to another address on any port. I have in the past (with customers permission) dialled into a system and used it as my internet connection when our office internet connection failed. Hackers can do this if the systrem has it's default or an obvious username and password for the DialIn user



"No problem monkey socks

 

[BSFH]

They always use a VPN to manage, but honestly that sounds like the most probable way at the moment. I am actually excited/furious at the prospects, so logging into the server from home (VPN).
Can you tell me:
1) How to verify dialin user enabled/disabled
2) Whether the IPO would log anywhere any accesses that come over the ISDN link?

I'll also be trying to find it myself, just going a bit slow @ 8pm

 

[amriddle01]

It's already setup by default. In a default state there is a user called "RemoteManager" it uses those credentials



"No problem monkey socks

 

[BSFH]

Ok, the good news is that there is no user called "RemoteManager".
There is however an incoming call route with a destination "dialin". I already hate that route just for its name. I have no isdn modem so i can't verify what it does. I called the number, but it sounded like it rang once then hung up.
There is an IP route: 0.0.0.0 mask 0.0.0.0 with a correctly defined gateway IP. There is another one for our maintainer.
Under RAS I see "dialin", there is no extension, com port, ta enable, or encrypted password. Under ppp tab, chap challenge interval is 0, nothing under header compression is ticked. ppp compression is mppc. ppp callback is disable. data pkt size is 0. bacp and multilink/qos are unticked.


This is probably solved. I'll setup a much better trap this time, getting the ISDN side if I can. I found at least 1 user with "dialin" ticked (phone maintainer) so its possible someone has been using that. I had no idea these darned things could be layer 3 gateways over isdn. Oh well. I'll let you know how I go.

 

[amriddle01]

If you call it with a handset it will not answer as the call will be tagged as a voice call, when you use an ISDN modem it gets tagged as a data call and the systems ISDN modem answers, this will be what's happening I would wager, even if they didn't realise it. When you create a connection using an ISDN modem on your PC it uses the connection as it's default gateway by default (unless you change it) and so once dialled in anything on your PC will be attempting a connection via the system, so outlook, skype, IE, Logmein etc etc



"No problem monkey socks

 

[amriddle01]

In the meantime I would find out what number the maintainer dials in on and tie the dialin call route down to only answer calls from that number, then that rules out intruders and only the maintainer can be doing it then



"No problem monkey socks

 

[BSFH]

It was the RAS functions. When I inherited this we already had a site to site VPN in place for phone maintenance. After I took over we introduced an SSL vpn system as well. The phone maintainer must have preferred just dialling in, and we'd not known about that. As soon as the maintainer dialled in today I got the alert. Same IPs and everything.
That is a good outcome.

 

[tlpeter]

If i could choose between a quick VPN or a slow dialin then i for sure would go for the VPN
But some telecom companies are old fashion.


BAZINGA!

I'm not insane, my mother had me tested!

 

[amriddle01]

It's easily solved, they just need to untick the option to use that connection as default gateway, will not happen again if they do that



"No problem monkey socks