CVE-2018-17562 – FaxFinder 5.0.5.8 < SQLite Injection Vulnerability

Hi everyone,

Today, I am going to be writing a PoC for a new CVE I found for versions of FaxFinder 5.0.5.8 and older that can be exploited with SQLite Injection. I have reported this flaw to the vendor and they have fixed this issue with the new release of FaxFinder version 5.1.6. This post is going to be used as the official source used to accredit CVE-2018-17562. I will also include the conversation thread I had with MultiTech when reporting this flaw.

CVE Founder: Max Segura
Vendor: Multitech
Software: FaxFinder
Version: 5.0.5.8 and older
Vulnerability: SQLite Injection
Reported: 11-22-17
Fixed: 9-25-18
National Vulnerability Database: https://nvd.nist.gov/vuln/detail/CVE-2018-17562

Intro

This vulnerability allows a remote or unauthenticated attacker to exploit an existing SQLite Injection vulnerability that lies under versions FaxFinder 5.0.5.8 and older. In order for this injection to work, a valid OID is needed for the injection. Upon exploitation, the attacker will gain access to the underlying database schema. The information on this post is intended to promote security awareness. Do not use this information to intentionally abuse a private computer system. You are responsible for your own actions; hacking is unlawful!

Proof of Concept

This section will contain step-by-step instructions on how to exploit this flaw. First, to prove that this flaw can be exploited by an unauthenticated user, let’s take a look at FaxFinder login page in either In-private Browsing or Incognito Mode.

Once the affected version has been identified, the next step would be to obtain a valid OID number from the fax server so we have an injection point. For example, take a look at the URL below:

https://site.com/status/call_details?oid=28807

The above image demonstrates that any user can enumerate the fax server for valid information. This can be done with ease through automated scripting. Now that we have a starting point, we can expose the flaw by tampering with the syntax used by the software. Inserting an ‘ (apostrophe) usually breaks the code’s syntax.

This is indicative of that the application can be exploited. The attack vector has been concealed to prevent unauthorized exploitation. If you need the attack vector to test your own systems, I may be able to disclose it privately.

The following information was extracted:

CREATE TABLE call_entry( oid INTEGER PRIMARY KEY, timestamp TEXT DEFAULT CURRENT_TIMESTAMP, rcpt_fax TEXT NOT NULL, direction TEXT NOT NULL, entrykey TEXT, remote_id TEXT NOT NULL, status TEXT NOT NULL, modem_nr INTEGER, size INTEGER, pages INTEGER, resolution TEXT NOT NULL, baud_rate TEXT NOT NULL, width TEXT NOT NULL, height TEXT NOT NULL, data_compression TEXT NOT NULL, error_correction TEXT NOT NULL, init_time TEXT NOT NULL, off_hook_time TEXT NOT NULL, connect_time TEXT NOT NULL, elapsed_time INTEGER, scan_line_time INTEGER, modem_trace_log TEXT, all_dtmf_digits TEXT NOT NULL )

This vector can be modified to inject other versions of FaxFinder up to the penultimate release of 5.0.5.8. Please upgrade to version 5.1.6 to patch this flaw.

Reporting Time Table

Here you can find my dialog with MultiTech to fix this vulnerability. This flaw was recognized in version 5.0.5.8 and the zero day was patched on 9-25-18.

As always, thanks for reading!

Advertisement
Privacy Settings

4 thoughts on “CVE-2018-17562 – FaxFinder 5.0.5.8 < SQLite Injection Vulnerability

  1. I am testing this vulnerability for one of our internal systems, and I believe it’s present. I’ve searched for other articles, but yours seems to be the one with the most info. I was able to determine a valid OID, as well as the presence of the vulnerability as expressed by the unrecognized token error. Can you provide the details of the exploit for version 5.0.5.8? I realize this post is years old at this point.

    • Hi!

      Due to the severity of this flaw and clients being exploited, I cannot publicly disclose the vector. However, if you are willing to provide me with your name and the company you work for, it will assure me that I am entrusting the vector to a responsible party and not just some script kiddie. Furthermore, it is possible, based on the events that proceed, that I may entirely reject giving you the exploit since it would be your sole responsibility to update your system knowing its exploitability. Generally, this is all stakeholders need to know.

      • Good morning. I am currently discussing with management whether they want the vulnerability exploit demonstrated or just written up. This was identified as part of an ongoing penetration test, so not sure if we’ll ultimately need to exploit it or not. Just trying to pre-plan. I’ll see what management says, and then if needed, I’ll reach back out. Frankly I wasn’t sure if anyone would actually respond to the post since it’s so old. In the meantime, thank you.

      • Hi again,

        No problem! Highlighting the attack surface should encourage upgrading – I don’t see the need of having to exploit the application.

        Some of my ramblings are old, but I keep a close eye on my blog. I have new content to post but my 9-5 as an engineer keeps me busy.

        Thanks for your comment, hopes it all works out. Have a great week ahead!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s