rdpscan - A quick scanner for the CVE-2019-0708 "BlueKeep" v

项目说明

![Windows download]()
![macOS download]()
![Linux download]()
![Follow]()
![Build]()

rdpscan for C bluekeep vuln

This is a quick-and-dirty scanner for the C in Microsoft Remote Desktop.
Right now, there are about 900,000 machines on the public Internet to this ,
so many are to expect a worm soon like WannaCry and notPetya. Therefore, scan your networks and
patch (or at least, enable NLA) on systems.

This is a command-line tool. You can download the source and compile it
yourself, or you can download one of the pre-compiled binaries for
Windows or macOS from the link above.

This tool is based entirely on the rdesktop patch from
I' trimmed the code so that I can easily compile on macOS and Windows,
as well as added the ability to scan multiple targets.

Status

This is only a few days old and experimental. However, I am testing it by scanning
the entire Internet (with the help of masscan, so I'm working through a lot of problems
pretty quickly. You can try contacting me on twttier() for help/comments.

- 2019-05-38 - Better output result descriptions, as well as documentation what they mean (see below).
- 2019-05-27 - Windows and macOS binaries released (click on badges above).
- 2019-05-26 - fixing the Windows networking issues
- 2019-05-25 - Linux and macOS working well, Windows has a few network errors
- 2019-05-24 - works on Linux and macOS, Windows has a few compilation bugs
- 2019-05-23 - currently working on macOS within XCode

## Primary use

To scan a network, run it like the following:

rdpscan 192.168.1.1-192.168.1.255

This produces one of 3 results for each address:
- SAFE - if target has determined bot be *patched* or at least require *CredSSP/NLA*
- - if the target has been confirmed to be
- UNKNOWN - if the target doesn't respond or has some protocol failure

When nothing exists at a target IP address, the older pritned the
message "*UNKNOWN - connection timed out*". When scanning large networks,
this produces an o of too much information about systems you don't
care about. Therefore, the new by default doesn't produce this
information unless you add *-v* (for ) on the command-line.

You can increase the speed at which it scans large networks by increasing
the number of workers:

rdpscan --workers 10000 10.0.0.0/8

However, on my computer, it only produces about 1500 workers, because
of system limitations, no matter how high I configure this parameter.

You can increase the speed even more by using this in conjunction
with masscan, described in the second below.

Interpreting the results

There are three general responses:
- *SAFE* - which means the target is probably patched or otherwise
not to the bug.
- **: which means we' the target is
to this bug, and that when the worm hits, will likely get
infected.
- *UNKNOWN*: means we can't confirm either way, usually because
the target doesn't respond or isn't running RDP, which is
the vast majority of responses. Also, when targets are out
of resources or experiencing network problems, we'll get
a lot of these. Finally, protocol errors are responsble
for a lot.
While the three main responses are *SAFE*, **, and *UNKNOWN*,
they contain additional text explaining the diagnosis. This section
describes the strings you'll see.

SAFE

There are three main reaons we think a target is safe:
- *SAFE - Target appears patched*
This happens when the target doesn't respond to the triggering
request. This means it's a Windows system that's been patched,
or a system that wasn't to begin with, like Windows 10
or Unix.
- *SAFE - CredSSP/NLA required*
This means that the target first requires Network Le before
the RDP connection can be established. The tool cannot pass this point, without
leigitimate credentials, so cannot determine whether the target has been patched.
However, hackers can't continue past this point to exploit systems, either,
so you are likely "safe". However, when exploits appear, insiders with valid
usernames/passwords will be able to exploit the system if it's un-patched.
- *SAFE - not RDP*
This means the system is not RDP, but has some other service that happens to use
this same port, and produces a response that's clearly not RDP. Common examples are
HTTP and SSH. Note however that instead of an identifiable protocol, a server
may respond with a RST or FIN packet. These are identified as *UNKNOWN* instead
of *SAFE*/

This means we' the system is to the bug.
- * - got appid*
There is only one response when the system is , this one.

UNKNOWN

There are a zillion for unknown

- *UNKNOWN - no connection - timeout*
This is by far the most common response, and happens when the target
IP address makes no response whatsoever. In fact, it's so common that
when scanning large ranges of addresses, it's usually ommited. You
have to add the *-) flag in order to enable it.
- *UNKNOWN - no connection - refused (RST)*
This is by far the second most common response, and happens when
the target exists and responds to network traffic, but isn't running
RDP, so refuses the connection with a TCP RST packet.
- *UNKNOWN - RDP protocol error - recei*
This is the third most common response, and happens when we'
established an RDP connection, but then the ser responding
to us. This is due to network errors and when the target system is
o for some reason. It could also be network errors on this
end, such as when you are behind a NAT and o it with too
many connections.
- *UNKNOWN - no connection - connection closed*
This means we' a connection (TCP SYN-ACK), but then
the connection is immediately closed (with a RST or FIN). There are
many reasons this happen, which we cannot distinguish:
- It's running RDP, but for some reason closes the connection,
possibly because it's out-of-resources.
- It's not RDP, and doesn't like the RDP request we send it,
so instad of sending us a nice error message (which would
trigger *SAFE - not RDP*), it abruptly closes the connection.
- Some inter device, like an IPS, firewall, or NAT closed
the connection because it identified this as hostile, or
ran out of resources.
- Some other reason I haven't identified, there's a lot of
weird stuff happening when I scan the Internet.
- *UNKNOWN - no connection - host unreachable (ICMP error)*
The remote network reports the host cannot be reached or is not running.
Try again later if you think that host should be alive.
- *UNKNOWN - no connection - network unreachable (ICMP error)*
There is a (transient) network error on the far end, try again
later if you believe that network should be running.
- *UNKNOWN - RDP protocol error*
This means some corruption happened in the RDP protocol, either because
the remote side implents it wrong (not a Windows system), because it's
handling a transient network error badly, or something else.
- *UNKNOWN - SSL protocol error*
Since Windows Vista, RDP uses the STARTTLS protocol to run over SSL.
This layer has it's own problems like abo includes handling
underlying network errors badly, or trying to communicate with
systems that have some sort of incompatibility. If you get a very
long error message here (like SSL3_GET_RECORD:wrong ), it's
because the other side has a bug in SSL, or your own SSL library that
you are using has a bug.

Using with masscan

This rdpscan tool is fairly slow, only scanning a few hundred targets per second.
You can instead use masscan to speed things up.
The masscan tool is roughly 1000 times faster, but only gi information
on the target.

The steps are:
* First scan the address ranges with masscan to quickly find hosts that
respond on port 3389 (or whatever port you use).
* Second feed the output of masscan into rdpscan, so it only has
to scan targets we know are active.

The simple way to run this is just to combine them on the command-line:

masscan 10.0.0.0/8 -p3389 | rdpscan --file -

The way I do it is in two steps:

masscan 10.0.0.0/8 -p3389 > ips.txt
rdpscan --file ips.txt --workers 10000 >results.txt

Building

The difficult part is getting the *OpenSSL* libraries installed, and not conflicting
with other on the system. Some examples for of Linux I' on
are the following, but they keep changing package names from one distribution to
the next. Also, there are many options for an OpenSSL-compatible API, such as BoringSSL
and LibreSSL.

$ sudo apt install libssl-dev
$ sudo yum install openssl-devel

Once you' that problem, you just compile all the .c files together
like this:

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

I've put a Makefile in the directory that does this, so you can likely do
just:

$ make

The code is written in C, so needs a C compiler installed, such as doing the following:

$ sudo apt install build-essential

Common build errors

This section describes the more obvious build errors.

ssl.h:24:25: fatal error: openssl/rc4.h: No such file or directory

This means you either don't have the OpensSSL headers installed, or they aren't
in a path somewhere. Remember that even if you ha binaries installed,
this doesn't mean you've got the de stuff installed. You need both
the headers and libraries installed.

To install these things on Debian, do:

$ sudo apt install libssl-dev

To fix the path issue, add a compilation flag -I/usr/local/include, or something
similar.

An example linker problem is the following:

Undefined symbols for architecture x86_64:
"_OPENSSL_init_ssl", referenced from:
_tcp_tls_connect in tcp-fac73c.o
"_RSA_get0_key", referenced from:
_rdssl_rkey_get_exp_mod in ssl-d5fdf5.o
"_SSL_CTX_set_options", referenced from:
_tcp_tls_connect in tcp-fac73c.o
"_X509_get_X509_PUBKEY", referenced from:
_rdssl_cert_to_rkey in ssl-d5fdf5.o

I get this on macOS because there's multiple of OpenSSL. I fix this
by hard-coding the paths:

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

According to comments by others, the following command-line might work on macOS
if you've used Homebrew to install things. I still get the linking errors abo,
because I' other OpenSSL components that are conflicting.

gcc $(brew --prefix)/opt/openssl/lib/libssl.a $(brew --prefix)/opt/openssl/lib/libcrypto.a -o rdpscan *.c

Running

The section abo quickstart tips for running the program. This section gives
more in-depth help.

To scan a single target, just pass the address of the target:

./rdpscan 192.168.10.101

You can pass in IPv6 addresses and DNS names. You can pass in multiple targets.
An example of this would be:

./rdpscan 192.168.10.101 exchange.example.com 2001:0db8:85a3::1

You can also scan ranges of addresses, using either begin-end IPv4 addresses,
or IPv4 CIDR spec. IPv6 ranges aren't supported because they are so big.

./rdpscan 10.0.0.1-10.0.0.25 192.168.0.0/16

By default, it scans only 100 targets at a time. You can increase this number
with the --workers parameter. However, no matter how high you set this
parameter, in practice you'll get a max of around 500 to 1500 workers running
at once, depending upon your system.

./rdpscan --workers 1000 10.0.0.0/24

Instead of specifying targets on the command-line, you can load them
from a file instead, using the well-named --file parameter:

./rdpscan --file ips.txt

The format of the file is one address, name, or range per line. It can also
consume the text generated by masscan. Extra whitespace is trimmed,
blank lines ignored, any any comment lines are ignored. A *comment* is
a line starting with the # character, or // characters.

The output is sent to stdout giving the status of , SAFE,
or UNKNOWN. There could be additional reasons for each. These reasons
are described above.

211.101.37.250 - SAFE - CredSSP/NLA required
185.11.124.79 - SAFE - not RDP - SSH response seen
125.121.137.42 - UNKNOWN - no connection - refused (RST)
40.117.191.215 - SAFE - CredSSP/NLA required
121.204.186.182 - SAFE - CredSSP/NLA required
99.8.11.148 - SAFE - CredSSP/NLA required
121.204.186.114 - SAFE - CredSSP/NLA required
49.50.145.236 - SAFE - CredSSP/NLA required
106.12.74.155 - - got appid
222.84.253.26 - SAFE - CredSSP/NLA required
144.35.133.109 - UNKNOWN - RDP protocol error - recei
199.212.226.196 - UNKNOWN - RDP protocol error - recei
183.134.58.152 - UNKNOWN - no connection - refused (RST)
83.162.246.149 - - got appid

You can process this with additional unix commands like grep and cut.
To get a list of just machines:

./rdpscan 10.0.0.0/8 | grep 'VULN' | cut -f1 -d'-'

The parameter -dddd means *diagnostic* information, where the more ds you
add, the more details are printed. This is sent to stderr instead of stdout
so that you can separate the streams. Using bash this is done like this:

./rdpscan --file myips.txt -ddd 2> diag.txt 1> results.txt

Diagnostic info

Adding the -d parameter dumps diagnostic info on the connections to stderr.

./rdpscan 62.15.34.157 -d

[+] [62.15.34.157]:3389 - connecting...
[+] [62.15.34.157]:3389 - connected from [10.1.10.133]:49211
[+] [62.15.34.157]:3389 - SSL connection
[+] [62.15.34.157]:3389 - = v4.8
[+] [62.15.34.157]:3389 - Sending MS_T120 check packet
[-] [62.15.34.157]:3389 - Max sends reached, waiting...
62.15.34.157 - SAFE - Target appears patched

On macOS/Linux, you can redirect stdout and stderr separately to different
files in the usual manner:

./rdpscan --file ips.txt 2> diag.txt 1> results.txt

SOCKS5 and Tor lulz

So it includes SOCKS5 support:

./rdpscan --file ips.txt --socks5 localhost --socks5port 9050

It makes connection problems worse so you get a lot more "UNKNOWN" results.

Statically link OpenSSL

For releasing the Windows and macOS binaries attached as *releases* to this project
I statically link OpenSSL, so that it doesn't need to be included separately, and the
programs *just work*. This section describes some notes on how to do this, especially
since the description on OpenSSL's own page seems to be out of date.

Both these steps start with downloading the OpenSSL source and putting
it next to the rdpscan directory:

git clone

Windows

For Windows, you need to first install some of Perl. I use the one
from Acti.

Next, you'll need a special "assembler". I use the recommended one called
NASM)

Next, you'll need a compiler. I use 2010. You can download
the latest " Studio Community Edition" (which is 2019) instead from
Microsoft.

Now you need to build the makefile. This is done by going into the OpenSSL
directory and running the Configure Perl program:

perl Configure

I chose 32-bit for Windows because there's a lot of old Windows out there,
and I want to make the program as compaitble as possible with old .

I want a completely static build, including the C runtime. To do that, I opened
the resulting makefile in an editor, and changed the C compilation flag from
/MD (meaning use DLLs) to /MT. While I was there, I added the following
to the CPPFLAGS -D_WIN32_WINNT=0x501, which restrict OpenSSL to features that
work back on Windows XP and Server 2003. Otherwise, you get errors that bcrypt.dll
was not found if your run on those older systems.

Now you'll need to make sure e is in your path. I copied nasm.exe
to the a directory in the PATH. For Studio 2010, I ran the program
.bat to setup the path for the compiler.

At this point on the command-line, I typed:

nmake

This makes the libraries. The static ones are libssl_static.lib and libcrypto_static.lib,
which I use to link to in rdpscan.

macOS

First of all, you need to install a compiler. I use the De Tools from Apple, installing
XCode and the compiler. I think you can use Homebrew to install gcc instead.

Then go int othe source directory for OpenSSL and create a makefile:

perl Configure darwin64-x86_64-cc

Now simply make it:

make depend
make

At this point, it's created both dynamic (.dylib) and static (.lib) libraries. I deleted
the dynamic libraries so that it'll catch the static ones by default.

Now in rdpscan, just build the macOS makefile:

make -f Makefile.macos

This will compile all the rdpscan source files, then link to the OpenSSL libraries
in the directory ../openssl that you just built.

This should produce a 3-megabyte exexeutable. If you instead only got a
200-kilobyte executable, then you made a mistake and linked to the dynamic libraries
instead.

项目信息

开发语言：C

Star 数：921

技术要点

该项目属于安全软件方向的开源资源，代码结构清晰，适合安全研究人员学习参考。项目围绕A quick scanner for the CVE-2019-0708 "BlueKeep" vulnerability.展开，提供了可运行的实现，对理解相关安全机制、工具原理与攻防技术具有较高的研究价值。

从技术实现角度看，此类项目的核心在于对底层原理的深入理解与工程化落地。开发者在研究过程中可以结合官方文档与社区讨论，梳理项目的初始化流程、核心模块职责与数据流转，逐步掌握其中的技术细节与设计思路。

使用与学习建议

1. 下载源码压缩包，解压到本地环境。

2. 根据项目类型准备对应的运行环境与依赖。

3. 按照 README 中的步骤完成配置与部署。

4. 在隔离的测试环境中运行验证，避免影响生产系统。

免责声明

本资源来源于开源社区，仅供安全研究、技术学习与合法授权范围内的攻防演练使用，请勿用于任何非法或侵害他人权益的用途。使用本项目产生的一切后果由使用者自行承担。