CVE-2019-19781 poor man's ktrace(1) driven analysis

📆
🏷
, , ,

Recently I had the chance to get myself a copy of a malicious httpd executable used by an unknown party while exploiting CVE-2019-19781. Even though I do not have anything else but a layman’s understanding of forensics I still wanted to dig into it. This is my journal about a journey into looking into a malware as a noob. While I hope to encourage others to also try to look behind the curtain I also want to stress that this is all potentially dangerous and you should not do this from within a sensitive network.

As far as I understand the situation, CVE-2019-19781 is a path traversal vulnerability at it’s core. I don’t want to reiterate information that is already readily available via google and such. Especially as the best I can do is to replicate the information without changing even minor details. If you want to learn more about CVE-2019-19781 I have to ask you to use a search engine of your choice.

Lab setup

As mentioned above I wasn’t to eager about drilling into a malicious binary inside a production environment so I started to setup a lab for analysing it.

Lab Setup

The setup itself is pretty basic and is running on an ESXi host. While firewall is a piece of infrastructure in order to give me easy access to my target, freebi is the machine I am running the httpd on. In order to stop the malware from phoning home I setup a blocking rule on firewall which blocks and logs all outgoing traffic coming from freebi. Also I specifically chose 198.51.100.0/24 because it is reserved for documentation and it should not being routed on the internet. So even if the box phones home I am safe as long as I won’t accidentally NAT the traffic of the box. freebi itself is running a stock FreeBSD 8.4-RELEASE which gives me enough an environment to run httpd without fiddling with libraries and extra software:

root@freebi:~ # uname -a
FreeBSD freebi.my.domain 8.4-RELEASE FreeBSD 8.4-RELEASE #0 r251259: Sun Jun  2 21:26:57 UTC 2013 …

unbound DNS rebind protection

📆
🏷
, ,

While working on my DNS firewalling @home I was studying unbound.conf and found what I already had forgotten, unbound’s DNS rebinding protection.

DNS rebinding is a an attack where a malicious website is using your browser to resolve internal addresses (e.g. RFC1918) in order to get their hands on internal ressources like e.g. your routers admin interface. There have been attacks in the wild using that technique and I bet there still are. rebind.network is a site that actually tries to find some internal ressources on your network; the site needs javascript. Anywho and without further ado, here’s the setting that I am running on my unbound – courtesy of unbound.conf(5):

private-address: 10.0.0.0/8 
private-address: 172.16.0.0/12
private-address: 192.168.0.0/16
private-address: 169.254.0.0/16
private-address: fd00::/8
private-address: fe80::/10
private-domain: my.lan.domain

Open Source Threat Intelligence And Makeshift RPZ with Unbound

📆
🏷
, , , , ,

Update: Added some remarks about what DNS RPZ actually is, what my objective is and what the outcome will be.

A friend of mine and I tried to play w/ RPZ and knot yesterday and gravely failed. The fact that knot as well as RPZ had been new to us didn’t help. Discussing the failure later that night I remembered that I was already doing something similar at home for adblocking at the DNS level instead of every application on every client. In some way this is also DNS RPZ.

DNS RPZ is something that could be described as DNS firewalling and is described by wikipedia as follows:

Domain Name Service Response Policy Zones (DNS RPZ) is a method that allows a nameserver administrator to overlay custom information on top of the global DNS to provide alternate responses to queries. It is currently implemented in the ISC BIND nameserver (9.8 or later). Another generic name for the DNS RPZ functionality is “DNS firewall”.

My main objective is to block ad networks and malware sites (e.g. command and control) on the DNS level for all devices without them having to install adblockers or stuff. So if someone tries to access a blacklisted site, say domain.tld the client will get a NXDOMAIN as an answer instead of the real IP address. As I can’t keep up with the domains I also want to leverage some of the OSINT feeds available. Currently I have roughly 16k domains blacklisted.

So today I was incorporating some of my OSINT and PF work into my DNS setup at home. Just as a quick primer: I am using OpenBSD as the OS, unbound(8) as recursor and rcs(1) for local and simple version control. Nothing mentioned here is specific to OpenBSD besides the ftp(1) command that I use to fetch the feeds and the location of the files.

Setting up unbound

Setup is pretty simple, just add the following line to /var/unbound/etc/unbound.conf within the server: section of the file:

include: /var/unbound/zones/rpz

Then setup /var/unbound/zones/rpz w/ additional includes, e.g.

include: …

Open Source Threat Intelligence and pf(4)

📆
🏷
, , ,

I came up with the idea to utilize Open Source Threat Feeds, or OSINT on my private setup and quickly cooked up the shell script below in a rough, first try. The funny thing is that I more or less instantantly got hits from the 5346 IP addresses in the table:

@0 block drop log quick from <pf_osint:5346> to any
  [ Evaluations: 502       Packets: 20        Bytes: 800         States: 0     ]
  [ Inserted: uid 0 pid 68515 State Creations: 0     ]

🧐. The script is currently designed to run every 3 hours and to remove all IP addresses which had been added to the table after a day. I am not too happy about some of the parts right now, first of all: I’d like to seperate download and parsing out to a non-privileged process and feed one large junk of data to pfctl(8).

This will give me the flexibility to replace the table with the new values so I can act fast not only on additions but also on deletions from the list. No need to keep out somebody longer than neccessary.

Not sure on how to attack the first part. A shell script would be easier and faster to create. Privsep could be handled by doas for the part needing higher privileges and allow me to handle everything in a single script.

But as a start I am going to keep the script as is and see how it’s going to work out for me. So without further ado, here’s the script:

printf "zeustracker.abuse.ch badips "
ftp  -VMo- https://zeustracker.abuse.ch/blocklist.php?download=badips | \
        egrep "^([0-9]{1,3}\.){3}[0-9]{1,3}$" | \
        pfctl -t pf_osint -T add -f -

printf "feodotracker.abuse.ch ipblocklist "
ftp  -VMo- https://feodotracker.abuse.ch/blocklist/?download=ipblocklist | \
        egrep "^([0-9]{1,3}\.){3}[0-9]{1,3}$" | \
        pfctl -t pf_osint -T add -f -

printf "ransomwaretracker.abuse.ch "
ftp -VMo- https://ransomwaretracker.abuse.ch/feeds/csv/ | \
        egrep -o '([1-9]{1,3}\.){3}[1-9]{1,3}[^/"]*' | \
        tr '|' …