./snep-sqli

CVE-2020-25127

Hello guys, I am so proud to report my first CVE. This vulnerability is an unauthenticated SQLi, found in SNEP - 3.07

Snep 3

Snep is a cloud connected and multi layer telephony platform, built under the technological concept of micro services, a feature that allows it to be highly scalable, available and portable.

The Vulnerability

The vulnerability consists of an unauthenticated SQL Injection in any communication with the Database

Step-By-Step

Getting Info

I accessed the application and soon noticed a login form. Bearing in mind that the application will perform a query in the database, I use a single quotation mark as the user name.

Request with single quote

When reading the response we can see an error message telling us that there is a problem with the SQL syntax

Response showing SQL syntax error

Therefore, based on this, we can conclude that the login form is vulnerable to an unauthenticated SQL injection.

Very easy isn't it?

But, still not happy, I decided to go after the application code to understand the reason why the Injection happened.

Code Reviewing

I went in search of the source code of the application, and, because it is an open source, I found it easily in this BitBucket.

I remembered that the error message that the application showed us, when sending the single quotes, showed the exact path where the failure occurred. It's a good starting point.

Following the whole stack trace I arrived at a file that contained the following function:

public function getCaseSensitive($username) {

        $db = Zend_Registry::get('db');

        $select = $db->select()
                ->from('users')
                ->where("name = BINARY '$username'");

        $stmt = $db->query($select);
        $case = $stmt->fetch();

        return $case;
}

Here we can see that the username variable is passed directly to the query, so, by passing single quotes, we can break part of the query and inject the code we want.

->where("name = BINARY ''<PAYLOAD_HERE>");

Not only there, but other queries in the database are also susceptible to an SQL Injection

Like here:

if ($this->_request->getPost()) {
    $exten = $_POST['id'];
    $db = Zend_Registry::get('db');
    $sql = "SELECT * from peers where name = '$exten'";
    $stmt = $db->query($sql);
    $result = $stmt->fetch();
    $idExten = $result['id'];

Conclusion

The failure does not end there, there are many other places where the communication with the database is made in an insecure way. This was just a small demonstration. I encourage you to look and find your own flaws too :)

In this way, we were able to understand the whole process in which the failure occurred, and thus, I conclude the entire explanatory procedure regarding my first CVE.

I thank you all for reading this far. I hope to write again about new CVEs very soon.

DhelthaX.