Alcatel Unleashed

Hi there!

I'm arctus from Slovenia (EU), a student of computer and information science and have some basic knowledge of the 4400OmniPCX. I have been working with the system for about 5 years now. During these 5 years of configuration and maintenance tasks I came across a few bugs and vulnerablities and would like to discuss those with you. Some vulnerablities were already posted on the internet about 2-3 years ago and I knew about them all time along. I believe you did too. I will gather some texts I wrote years ago and post a reply. It will also take me some time to review the forum in order not to duplicate any data already discussed.

I am very glad this web-page was created since I have a great sympathy for the Alcatel 4400OminPCX.

talk to you soon,
arctus, SI

Hello Arctus,

Feel free to talk about the bugs and security issue. Actually, if you want I can create 2 new forums for that. Let me know if you want it !

Hello everybody,
I'm really sorry for this late reply. I was kinda busy.

I've checked my notes with 4400 and here's a brief summary.

On 13th Feb. 2002, Irib of the security bugware team [http://www.securitybugware.org] published an advisory titled "Playing around with Alcatel 4400". He pointed out several security issues of which I was very aware of about 2 years before this document came out. Not actually bugs, but mainly poor security settings on ChorusOS were discussed. Document included discussions about:

- default passwords on ChorusOS which allowed a remote root access
- bad file permissions
- etc.

Alcatel was notified about this and contacted all it's distributers around the globe to change the default passwords and maybe prepared some OS patches (I'm not aware of everything that was going on at that time).

Anyway, so much for the introduction. What I wanted to talk to you about is not ChorusOS bugs/exploits, because Sun released the source code for ChorusOS and everyone can examine the code now. However, I'm more interested in bugs that lie within 4400 itself.

One security issue that bothers me is the one which enables a remote caller to dial-out using company's phone line, without authorization. This
can be done by carelessnessly setting up a number to be used for external line seizure (for example, DSL trunk group seizure). Usually, that prefix number would be 0, or 9 or something that does not collide with the directory number shema. If this prefix is set as a number with the same number of digits as a regular directory number, that prefix number can be accessed for the outside line and therefore used to sieze the assigned trunk group. For example: directory shema is 212 555 4100 - 212 555 4599 (dir.no. 100-599). If the prefix for trunk group seize is set as 440, you're allowed to call up 212 555 4440 + <the calling number>. You will be connected to the calling party plus you get to hide your identy, because the company's identity will be transfered to the telco. I have tried this and I works on all systems I have access to in country I live, t.i. Slovenia. Numbering plan i used for the example was adjusted for NY, US.
If you look at this from the other point of view, you may ask: "And how can I find out if that number is even present in the system?". I have no good answer yet, besides the brute force attack. Anyway, it's a "feature" that should not exist I believe.

The other bug lies within the 4635, the voice mail system. When you call a party on the regular directory number from an outside line and a call gets forwarded to the voice mail system, caller's ID gets stored with the message you may leave in the voicemailbox. But if you call a voice mail system directly on it's assigned directory number, browse to you target voice mail box and leave a message, caller's ID is not identified, therefore marking it as an "outside call".

Let me repeat, written above qualifies for the country Slovenia and I allow a chance of being wrong and written above might be just a result of a poor system configuration.

I would love to get a feedback from you on this. Thank you!

arctus, SI

Arctus,

You have brought a good point for the caller using the company PBX to make an external phone call. I am not sure that we can consider this a a bug:

Public DID:
123.456.1000 - 2000

If the CO sends you the 10 digits, then you will put in your Default DID Translator:

External number: 123.456.1000
First internal number: 1000
Range: 1001
Unique number: no

NWhat you are saying here is that ANYBODY calling from outside will be able to reach ANY of those numbers IF only they are attribued. It is somehow logic that if you says 1111 is going to be my trunk seizure, that you can dial outside after that.

If you want to change that (I don't remember by heart, I would have to make a test in a lab), there is a parameter to change so incoming call cannot make outgoing calls on the trunl (somebody yell at me if I am wrong)...


Regarding the voicemail, it is interesting and I never really paid attention to that. I will try to check it out in a lab sometime..

Thank you for your input, and I am glad to see that we have people from Slovenia !

Frank.

To block the calls from going back out on the PSTN you could set the connection class of service to block this feature. The connection class of service is in the trunk class of service under external connections.