BlueKeep Vulnerability, Robert Graham – Paul’s Security Weekly #606

 

 

Paul Asadoorian and Robert Graham from Errata Security show you how to search for the BlueKeep vulnerability, or CVE-2019-0708, that has been affecting hundreds of thousands of systems!

You can download rdpscan from Rob’s Git repo which also includes some great documentation. Some notes on this vulnerability:

  • Microsoft Windows operating systems older than Windows 7 and Server 2008 are vulnerable (including Windows XP if you’re into that sorta thing)
  • While you can scan your network for RDP listeners, keep in mind users could enable RDP at any time with merely just a click of a radio button
  • By default, if the Windows firewall is enabled, your system is very likely still listening on port 3389 and accepting connections, unless you configure it otherwise (tested on Windows 7 Ultimate)
  • There are unsubstantiated claims that this vulnerability has existed for about a year and has been sold/traded on the dark web
  • Select security researchers have posted online claiming they have developed a PoC exploit (e.g. https://twitter.com/ValthekOn/status/1129583856636633088 and https://twitter.com/cBekrar/status/1128712967845961728). Also, I tend to believe this to be true as multiple sources have reported this.


I built rdpscan on a Pop_OS! 18.04 machine:

$ uname -a ; cat /etc/issue ; cat /etc/debian_version

Linux hostname 4.18.0-20-generic #21~18.04.1pop0-Ubuntu SMP Wed May 15 14:41:28 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Ubuntu 18.04.2 LTS \n \l

buster/sid

I installed libssl-dev, per the instructions:

$ sudo apt install libssl-dev

First, I tried the compile command listed on the Github page:

$ gcc *.c -lssl -lcrypto -o rdpscan

tcp.c: In function ‘tcp_tls_connect’:
tcp.c:471:3: warning: ‘TLSv1_client_method’ is deprecated [-Wdeprecated-declarations]
   g_ssl_ctx = SSL_CTX_new(TLSv1_client_method());
   ^19:20, 30 May 2019 (UTC)[[User:Paul Asadoorian|Paul Asadoorian]] ([[User talk:Paul Asadoorian|talk]])
In file included from /usr/include/openssl/ct.h:13:0,
                 from /usr/include/openssl/ssl.h:61,
                 from tcp.c:29:
/usr/include/openssl/ssl.h:1626:1: note: declared here
 DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_client_method(void)) /* TLSv1.0 */
 ^

Strange, I’ve installed the latest version of openssl, let’s check to see which version came from the package repo:

$ dpkg -l libssl-dev

Name                                       Version                    Architecture               Description
=============================================================================================================
ii  libssl-dev:amd64                           1.1.0g-2ubuntu4.3          amd64                      Secure Sockets Layer toolkit - development files

Now I am wondering where the library is installed because my potential solution is to install the older openssl library in a different location, then use the older version to build rdpscan. I used the “-L” flag with dpkg to list the files installed by the package:

$ dpkg -L libssl-dev

/.
/usr
/usr/include
/usr/include/openssl
/usr/include/openssl/aes.h
<snip>
<pre>

Okay, looks like all the include files are stored in /usr/include. Now I can safely install the older version (1.0) in a different location, as follows:

<pre>$ wget https://www.openssl.org/source/openssl-1.0.2s.tar.gz
$ tar zxvf openssl-1.0.2s.tar.gz 
$ cd openssl-1.02s

Stop! Before you enter the command below, make sure you are pointing to a different location. I don’t want to begin to theorize about the issues you could have if you stomp on your openssl libraries. Even though I double and triple checked it, I still had that Star Wars “I have a bad feeling about this” moment.

$ ./config --prefix=/opt/local --openssldir=/opt/local/openssl
$ make
$ sudo make install

Okay, now back to try to compile rdpscan, pointing to our new include directory (gcc will look in the current directory first, then directories specified with “-I” in order from left to right, then your system include directories):

$ cd rdpscan/src

$ gcc *.c -I/opt/local/include -lssl -lcrypto -o rdpscan
/tmp/cck7y0jM.o: In function `tcp_tls_connect':
tcp.c:(.text+0xc30): undefined reference to `SSL_load_error_strings'
tcp.c:(.text+0xc35): undefined reference to `SSL_library_init'
collect2: error: ld returned 1 exit status

Oops, forgot to also include the “-L” for the new libraries we installed in /opt, which is why it failed to link:

$ gcc *.c -L/opt/local/lib -I/opt/local/include -lssl -lcrypto -o rdpscan

/opt/local/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_globallookup':
dso_dlfcn.c:(.text+0x11): undefined reference to `dlopen'
dso_dlfcn.c:(.text+0x24): undefined reference to `dlsym'
dso_dlfcn.c:(.text+0x2f): undefined reference to `dlclose'
/opt/local/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_func':
dso_dlfcn.c:(.text+0x364): undefined reference to `dlsym'
dso_dlfcn.c:(.text+0x422): undefined reference to `dlerror'
/opt/local/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_bind_var':
dso_dlfcn.c:(.text+0x497): undefined reference to `dlsym'
dso_dlfcn.c:(.text+0x552): undefined reference to `dlerror'
/opt/local/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_load':
dso_dlfcn.c:(.text+0x5b8): undefined reference to `dlopen'
dso_dlfcn.c:(.text+0x61d): undefined reference to `dlclose'
dso_dlfcn.c:(.text+0x655): undefined reference to `dlerror'
/opt/local/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_pathbyaddr':
dso_dlfcn.c:(.text+0x701): undefined reference to `dladdr'
dso_dlfcn.c:(.text+0x766): undefined reference to `dlerror'
/opt/local/lib/libcrypto.a(dso_dlfcn.o): In function `dlfcn_unload':
dso_dlfcn.c:(.text+0x7c2): undefined reference to `dlclose'
collect2: error: ld returned 1 exit status

Hrm, now we are missing another library. Google told me to add “-ldl”, so I did:

$ gcc *.c -L/opt/local/lib -I/opt/local/include -lssl -lcrypto -ldl -o rdpscan

And it compiled! Part of me misses compiling C from source, and part of me really appreciates apt packages.

Now let’s do some scanning!

$ ./rdpscan 

---- https://github.com/robertdavidgraham/rdpscan ----
This program scans for the Microsoft Remote Desktop vuln CVE-2019-0708
Usage:
 rdpscan <addr> [<addr> ...]
 rdpscan --file <filename>
This will scan for the addresses specified, either on the command-line
or from a file. Some additional parameters are:
 -p <n> or --port <n>
  The port number (default 3389)
 -d or -dd or -ddd
  Print diagnostic information to stderr
 -q quiet, don't print result for non-existent systems (default=many addresses)
 -v verbose, do print result for non-existent systems (default=single address)

I did not find anything interesting on my local subnets, but code runs and very fast!

$ ./rdpscan 172.16.1.0/24

172.16.1.49 - UNKNOWN - no connection - refused (RST)
172.16.1.79 - UNKNOWN - no connection - refused (RST)
172.16.1.24 - UNKNOWN - no connection - refused (RST)
172.16.1.11 - UNKNOWN - no connection - refused (RST)
172.16.1.96 - UNKNOWN - no connection - refused (RST)
172.16.1.9 - UNKNOWN - no connection - refused (RST)
172.16.1.35 - UNKNOWN - no connection - refused (RST)
172.16.1.12 - UNKNOWN - no connection - refused (RST)
172.16.1.18 - UNKNOWN - no connection - refused (RST)
172.16.1.103 - UNKNOWN - no connection - refused (RST)
172.16.1.21 - UNKNOWN - no connection - refused (RST)
172.16.1.159 - UNKNOWN - no connection - refused (RST)
172.16.1.0 - UNKNOWN - connect failed: Network is unreachable (101) [-1]
172.16.1.40 - UNKNOWN - no connection - refused (RST)
172.16.1.37 - UNKNOWN - no connection - host unreachable (ICMP error)
172.16.1.48 - UNKNOWN - no connection - host unreachable (ICMP error)
172.16.1.239 - UNKNOWN - no connection - host unreachable (ICMP error)
172.16.1.142 - UNKNOWN - no connection - host unreachable (ICMP error)
<snip>

Okay, now let’s get vulnerable:

$ ./rdpscan 192.168.56.101

192.168.56.101 - VULNERABLE - got appid

Cool, lets enable all debugging so we can see more information:

$ ./rdpscan -ddd 192.168.56.101

[+] [192.168.56.101]:3389 - connecting...
[+] [192.168.56.101]:3389 - connected from [192.168.56.1]:35190
[ ] [192.168.56.101]:3389 - subject = /CN=PWNME
[+] [192.168.56.101]:3389 - connection established: using SSL
[+] [192.168.56.101]:3389 - version = v4.8
[+] [192.168.56.101]:3389 - sending 1 channels
[+] [192.168.56.101]:3389 - Sending MS_T120 check packet
192.168.56.101 - VULNERABLE - got appid

Full Show Notes

Follow us on Twitter: https://www.twitter.com/securityweekly

Hosts

Joff Thyer
Joff Thyer – Security Analyst, Black Hills Information Security.
Paul Asadorian
Paul Asadorian – CTO, Security Weekly.
Larry Pesce
Larry Pesce – Senior Managing Consultant and Director of Research, InGuardians.