Giter VIP home page Giter VIP logo

rdpscan's Introduction

Windows download macOS download Linux download Follow Build

rdpscan for CVE-2019-0708 bluekeep vuln

This is a quick-and-dirty scanner for the CVE-2019-0708 vulnerability in Microsoft Remote Desktop. Right now, there are about 900,000 machines on the public Internet vulnerable to this vulnerability, so many are to expect a worm soon like WannaCry and notPetya. Therefore, scan your networks and patch (or at least, enable NLA) on vulnerable 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 https://github.com/zerosum0x0/CVE-2019-0708. I've simply 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(@erratarob) 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
  • VULNERABLE - if the target has been confirmed to be vulnerable
  • UNKNOWN - if the target doesn't respond or has some protocol failure

When nothing exists at a target IP address, the older versions pritned the message "UNKNOWN - connection timed out". When scanning large networks, this produces an overload of too much information about systems you don't care about. Therefore, the new version by default doesn't produce this information unless you add -v (for verbose) 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 vulnerable to the bug.
  • VULNERABLE: which means we've confirmed the target is vulnerable 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, VULNERABLE, and UNKNOWN, they contain additional text explaining the diagnosis. This section describes the various 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 vulnerable to begin with, like Windows 10 or Unix.
  • SAFE - CredSSP/NLA required This means that the target first requires Network Level Authentication 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 vulnerable 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/

VULNERABLE

This means we've confirmed the system is vulnerable to the bug.

  • VULNERABLE - got appid There is only one response when the system is vulnerable, this one.

UNKNOWN

There are a zillion variations 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 -v (verbose) 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 - receive timeout This is the third most common response, and happens when we've successfully established an RDP connection, but then the server stops responding to us. This is due to network errors and when the target system is overloaded for some reason. It could also be network errors on this end, such as when you are behind a NAT and overloading it with too many connections.
  • UNKNOWN - no connection - connection closed This means we've established 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 intervening 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 above, which 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 version), 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 gives limited 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 versions on the system. Some examples for versions of Linux I've tested 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've solved 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 have OpenSSL binaries installed, this doesn't mean you've got the development 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 versions 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 above, though, because I've installed 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 above gives 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 VULNERABLE, 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 - VULNERABLE - got appid
222.84.253.26 - SAFE - CredSSP/NLA required
144.35.133.109 - UNKNOWN - RDP protocol error - receive timeout
199.212.226.196 - UNKNOWN - RDP protocol error - receive timeout
183.134.58.152 - UNKNOWN - no connection - refused (RST)
83.162.246.149 - VULNERABLE - got appid

You can process this with additional unix commands like grep and cut. To get a list of just vulnerable 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 - version = 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 https://github.com/openssl/openssl

Windows

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

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

Next, you'll need a compiler. I use VisualStudio 2010. You can download the latest "Visual 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 VC-WIN32

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 versions.

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 everything is in your path. I copied nasm.exe to the a directory in the PATH. For Visual Studio 2010, I ran the program vcvars32.bat to setup the path variables 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 Developer 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.

rdpscan's People

Contributors

brendangrant avatar danijeljw avatar hrbrmstr avatar leonowski avatar robertdavidgraham avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

rdpscan's Issues

Timestamp in addition to scan result

As IP's are randomized, it would be nice/handy to put a timestamp (like "date -R") in front of each line to get something like

Wed, 29 May 2019 13:51:27 +0200 - 211.101.37.250 - SAFE - CredSSP/NLA required
Wed, 29 May 2019 13:52:21 +0200 - 106.12.74.155 - VULNERABLE - got appid

[-] fork() hit process limit

I was able to scan a few different IP ranges then I started get the fork error. I rebooted but that is all the troubleshooting steps I have taken.

Linux hostname 4.15.0-55-generic #60-Ubuntu SMP Tue Jul 2 18:22:20 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/issue
Ubuntu 18.04.2 LTS \n \l

Unencrypted connections, CentOS, timestamps

It would be nice to see in the non-debug (aka regular) log,
whether a connection was done without SSL as this opens up
the vulnerabilty of being sniffed.

Furthermore it would be nice to enforce an unencrypted connection
to see, what systems still support that.

And 2¢ for CentOS: I had to add "-lrt" on that platform for linking.
(maybe one for the doc).

And, as my colleague already stated: timestamps in the logs are recommended.

System reboots when scanned

When scanning a bunch of systems we got a few that came back with the following.

10.xx.28.119 - UNKNOWN - RDP protocol error - receive timeout
10.xx.24.240 - UNKNOWN - RDP protocol error - receive timeout
10.xx.28.228 - UNKNOWN - RDP protocol error - receive timeout
10.xx.26.167 - UNKNOWN - RDP protocol error - receive timeout
10.xx.31.129 - UNKNOWN - RDP protocol error - receive timeout

Tried scanning these a second time and some report back the same while others show a patch status as hoped.

Unfortunately some reboot. Not cool.
Any ideas on how to help avoid this?

getaddrinfo

getaddrinfo() failed: Name or service not known
Debian 10 4.19.0-8-amd64

Memory leaks in rdpscan

It looks like there are a few memory leaks in rdpscan. Below are the the details when I build rdpscan with clang & gcc on Ubuntu.

jimi@woodstock:~/src/rdpscan$ lsb_release -sir
Ubuntu
18.04

jimi@woodstock:~/src/rdpscan$ gcc --version
gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

jimi@woodstock:~/src/rdpscan$ clang --version
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
jimi@woodstock:~/src/rdpscan$ gcc -g -O1 -fsanitize=address -fno-omit-frame-pointer *.c -lssl -lcrypto -o rdpscan
jimi@woodstock:~/src/rdpscan$ ./rdpscan 192.168.0.0/24
....
....
....
....
=================================================================
==30450==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 2056 byte(s) in 1 object(s) allocated from:
    #0 0x7f8a92dbaf40 in realloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xdef40)
    #1 0x55d6f7633eb5 in xrealloc /home/jimi/src/rdpscan/util-xmalloc.c:58
    #2 0x55d6f7618afd in main /home/jimi/src/rdpscan/main.c:488
    #3 0x7f8a9222ab96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

Direct leak of 1616 byte(s) in 1 object(s) allocated from:
    #0 0x7f8a92dbad38 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.4+0xded38)
    #1 0x55d6f763559f in spawn_workers /home/jimi/src/rdpscan/workers.c:671
    #2 0x55d6f76185a9 in main /home/jimi/src/rdpscan/main.c:501
    #3 0x7f8a9222ab96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x7f8a92d53538 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x77538)
    #1 0x55d6f7633e73 in xstrdup /home/jimi/src/rdpscan/util-xmalloc.c:41
    #2 0x55d6f7617ee4 in parse_commandline /home/jimi/src/rdpscan/main.c:417
    #3 0x55d6f7618485 in main /home/jimi/src/rdpscan/main.c:441
    #4 0x7f8a9222ab96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

Indirect leak of 3730 byte(s) in 256 object(s) allocated from:
    #0 0x7f8a92d53538 in strdup (/usr/lib/x86_64-linux-gnu/libasan.so.4+0x77538)
    #1 0x55d6f7633e73 in xstrdup /home/jimi/src/rdpscan/util-xmalloc.c:41
    #2 0x55d6f7618b53 in main /home/jimi/src/rdpscan/main.c:489
    #3 0x7f8a9222ab96 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

SUMMARY: AddressSanitizer: 7418 byte(s) leaked in 259 allocation(s).
jimi@woodstock:~/src/rdpscan$ clang -g -O1 -fsanitize=address -fno-omit-frame-pointer *.c -lssl -lcrypto -o rdpscan
jimi@woodstock:~/src/rdpscan$ ./rdpscan 192.168.0.0/24
....
....
....
....
=================================================================
==31018==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 2056 byte(s) in 1 object(s) allocated from:
    #0 0x4db8d0  (/home/jimi/src/rdpscan/rdpscan+0x4db8d0)
    #1 0x544a59  (/home/jimi/src/rdpscan/rdpscan+0x544a59)
    #2 0x52899a  (/home/jimi/src/rdpscan/rdpscan+0x52899a)
    #3 0x7f3098ee3b96  (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x437c70  (/home/jimi/src/rdpscan/rdpscan+0x437c70)
    #1 0x544a18  (/home/jimi/src/rdpscan/rdpscan+0x544a18)
    #2 0x528079  (/home/jimi/src/rdpscan/rdpscan+0x528079)
    #3 0x5285db  (/home/jimi/src/rdpscan/rdpscan+0x5285db)
    #4 0x7f3098ee3b96  (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

Indirect leak of 3730 byte(s) in 256 object(s) allocated from:
    #0 0x437c70  (/home/jimi/src/rdpscan/rdpscan+0x437c70)
    #1 0x544a18  (/home/jimi/src/rdpscan/rdpscan+0x544a18)
    #2 0x5289a6  (/home/jimi/src/rdpscan/rdpscan+0x5289a6)
    #3 0x7f3098ee3b96  (/lib/x86_64-linux-gnu/libc.so.6+0x21b96)

SUMMARY: AddressSanitizer: 5802 byte(s) leaked in 258 allocation(s).

TLSv1_client_method() issue when compiling

Hello Robert,
when compiling on KALI, I have received:
tcp.c: In function ‘tcp_tls_connect’:
tcp.c:412:3: warning: ‘TLSv1_client_method’ is deprecated [-Wdeprecated-declarations]
g_ssl_ctx = SSL_CTX_new(TLSv1_client_method());
^~~~~~~~~
In file included from /usr/include/openssl/e_os2.h:13,
from /usr/include/openssl/ssl.h:15,
from tcp.c:29:
/usr/include/openssl/ssl.h:1879:1: note: declared here
DEPRECATEDIN_1_1_0(__owur const SSL_METHOD *TLSv1_client_method(void))
^~~~~~~~~~~~~~~~~~

Changing line 412 in tcp.c to
g_ssl_ctx = SSL_CTX_new(TLS_client_method());
solved the issue (as per recommendation on https://www.openssl.org/docs/man1.1.0/man3/TLSv1_client_method.html.

Windows XP False Positives?

I'm seeing a discrepancy in the results between this rdpscan and the one put out by zerosum0x0.

This rdpscan seems to be reporting all Windows XP as vulnerable even after they are patched and rebooted. The rdpscan from zerosum0x0 reports the same Windows XP as patched. (rdpscan from zerosum0x0 had previously reported them as vulnerable before KB4500331 was applied to them)

I'm not sure what information I can provide to help solve this but let me know and I'll do what I can. I'd like to set this up as a scheduled task. Thanks

Option to output hostnames instead of IP addresses

I wrote a script that parses the output of this scanner and feeds the results into an inventory system. However, I had to write the script to call this scanner once per computer so it can keep track of which results go to which computer in order to feed the results correctly back into the system. If this scanner had the option to output the hostnames it was given, it would allow me to dramatically simplify my script 😄

https://github.com/Colby-PDQ/BlueKeep-Scanner-PS-Parser

Scan non default port

Please add functionality to test alternate ports for testing non-default RDP assignment

License is missing

Please add a license, whatever license you think would be the best for this software. Employees of bigger companies typically are not allowed to clone/download/use this software as long as it has no license.

VS2019编译问题。

1.需提前编译好openssl,并设置本工程的相关设置,如导入的头文件和库文件的位置。
2.需在\rdpscan\src\util-sockets.c的第一行添加:#define WIN32 1
3.需在\rdpscan\src\util-log.c的第八行添加:#define WIN32 1

这样方可编译通过。

false positives: Windows Server 2012 & 2016

It seems that a license handling error which was fixed at some point in the original rdesktop (possibly here: https://sourceforge.net/p/rdesktop/mailman/message/31932290/ ) is spoiling the vulnerability check against newer systems which are not affected by this vulnerability:

  • true positive (Windows 7):
...
[ ] [10.192.99.137]:3389 - STARTTLS starting TLS ...
[ ] [10.192.99.137]:3389 - subject = ***
[+] [10.192.99.137]:3389 - connection established: using SSL
[+] [10.192.99.137]:3389 - version = v4.8
[+] [10.192.99.137]:3389 - Sending MS_T120 check packet
10.192.99.137 - VULNERABLE - got appid
  • false positive (Windows Server 2016):
...
[ ] [10.221.128.60]:3389 - STARTTLS starting TLS ...
[ ] [10.221.128.60]:3389 - subject = ***
[+] [10.221.128.60]:3389 - connection established: using SSL
[+] [10.221.128.60]:3389 - version = v7.8
[ ] [10.221.128.60]:3389 - License error alert from server: Invalid client
10.221.128.60 - VULNERABLE - got appid

The false positive is missing the part "Sending MS_T120 check packet", i.e. that special request might not have been sent at all but instead the return code from the licensing error could be what triggers the detection result.
The original scanner by zerosum0x0 shows the same behaviour.

PS:
Thank you for the fast fix on issue #8.

Weird Results

Are we supposed to be getting valid appid's for server 2012 and xp embedded and just windows embedded in general I can privately share the results but I am on several occasions locating systems via your tool not said to be vuln unless I missed something or false positives are happening.

ubuntu: [-] fork() hit process limit - when run via system search path

Under "Ubuntu 18.04.2 LTS" the tool behaves normal when called with path prefix like "./rdpscan 10.1.2.0/24" or "/usr/local/bin/rdpscan 10.1.2.0/24".

When called without path prefix ("rdpscan 10.1.2.0/24") so that the binary is found via system search path then it endlessly forks child processes until the message "[-] fork() hit process limit" shows up and no new processes can be forked under any user anymore.
Running as root or giving the "--workers" parameter does not change this behaviour. It can be stopped with CTRL+C and all spawned processes cleanly disappear. Tcpdump shows that none of these processes actually starts sending out packets.

RDPSCAN never finishes

I am running a scan across 12717 IP addresses in my environment. Unfortunately, the scan never seems to finish the entire list of IP's.
I have let it go over night and still nothing. It chokes out around 10000 results.
I am running this on Windows 10 1809. I received the list of IP's from doing a masscan to all private IP space.

The output of my command are:

rdpscan.exe --file scanresults.txt --workers 10000 > results5.csv

During the scan i get some results into the CLI window that look like this:

[ ] [10.1.x.x]:3389 - SSL_read: 5 (A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
)
[ ] [10.x.x.x]:3389 - SSL_read: 5 (An existing connection was forcibly closed by the remote host.)

However, I don't think these are the issue, as it just never closes the window or completes the scan.

Compilation instructions

Hello,

Could you please update the readme file to instruct people using older versions of glibc to link the real-time library ("-lrt") when compiling rdpscan ? For example, under CentOS 6.10 :

gcc *.c -lssl -lcrypto -o rdpscan fails with the error message ./dev/rdpscan/src/util-time.c:28: undefined reference to 'clock_gettime'

When using gcc *.c -lssl -lcrypto -lrt -o rdpscan, it works like a charm

Best regards,
P.

2019

1>------ 已启动生成: 项目: rdpscan, 配置: Debug x64 ------
1>asn.c
1>c1: fatal error C1083: 无法打开源文件: “..\asn.c”: No such file or directory
1>bitmap.c
1>c1: fatal error C1083: 无法打开源文件: “..\bitmap.c”: No such file or directory
1>channels.c
1>c1: fatal error C1083: 无法打开源文件: “..\channels.c”: No such file or directory
1>iso.c
1>c1: fatal error C1083: 无法打开源文件: “..\iso.c”: No such file or directory
1>licence.c
1>c1: fatal error C1083: 无法打开源文件: “..\licence.c”: No such file or directory
1>main.c
1>c1: fatal error C1083: 无法打开源文件: “..\main.c”: No such file or directory
1>mcs.c
1>c1: fatal error C1083: 无法打开源文件: “..\mcs.c”: No such file or directory
1>mppc.c
1>c1: fatal error C1083: 无法打开源文件: “..\mppc.c”: No such file or directory
1>mst120.c
1>c1: fatal error C1083: 无法打开源文件: “..\mst120.c”: No such file or directory
1>orders.c
1>c1: fatal error C1083: 无法打开源文件: “..\orders.c”: No such file or directory
1>rand-blackrock.c
1>c1: fatal error C1083: 无法打开源文件: “..\rand-blackrock.c”: No such file or directory
1>ranges.c
1>c1: fatal error C1083: 无法打开源文件: “..\ranges.c”: No such file or directory
1>rdp.c
1>c1: fatal error C1083: 无法打开源文件: “..\rdp.c”: No such file or directory
1>rdp5.c
1>c1: fatal error C1083: 无法打开源文件: “..\rdp5.c”: No such file or directory
1>secure.c
1>c1: fatal error C1083: 无法打开源文件: “..\secure.c”: No such file or directory
1>ssl.c
1>c1: fatal error C1083: 无法打开源文件: “..\ssl.c”: No such file or directory
1>tcp.c
1>c1: fatal error C1083: 无法打开源文件: “..\tcp.c”: No such file or directory
1>util-genrand.c
1>c1: fatal error C1083: 无法打开源文件: “..\util-genrand.c”: No such file or directory
1>util-log.c
1>c1: fatal error C1083: 无法打开源文件: “..\util-log.c”: No such file or directory
1>util-sockets.c
1>c1: fatal error C1083: 无法打开源文件: “..\util-sockets.c”: No such file or directory
1>正在生成代码...
1>正在编译...
1>util-time.c
1>c1: fatal error C1083: 无法打开源文件: “..\util-time.c”: No such file or directory
1>util-xmalloc.c
1>c1: fatal error C1083: 无法打开源文件: “..\util-xmalloc.c”: No such file or directory
1>workers.c
1>c1: fatal error C1083: 无法打开源文件: “..\workers.c”: No such file or directory
1>正在生成代码...
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VC\v160\Microsoft.CppCommon.targets(429,5): error MSB6006: “CL.exe”已退出,代码为 2。
1>已完成生成项目“rdpscan.vcxproj”的操作 - 失败。
========== 生成: 成功 0 个,失败 1 个,最新 0 个,跳过 0 个 ==========

RDPScan from linux can only scan CREDSSP/NLA if enabled and not if its patched aka SAFE

When a client has CredSSP/NLA Enabled the output from rdpscan can only be "SAFE - CredSSP/NLA required" since the linux node you are scanning from is not in the domain of the scanned computer.
So in other words, when i patched the client i still got the result "SAFE - CredSSP/NLA required" since the node from where i am scanning is not in the domain.

Question: How can i have a reliable scan where i know the client is "SAFE" as opposed to "SAFE - CredSSP/NLA required"

Not an issue and an idea

Not An Issue :

Despite the fact that i already had cloned your git sometime ago , i did not remember it , so 30 minutes ago i was thinking in doing a script to scan the web with your masscan on port 3389 and then pass the open ips with the detection script on :
https://github.com/Ekultek/BlueKeep
after that i would parse the output to user interface .
It looks i dont need to do it anymore , great work and thank you for your time on this .

An Idea :

What about implementing this check code on masscan ?
Masscan already uses some nmap scripts , but something faster would be nice .
implementing a switch on masscan like "--bluekeep" would do the job .

Somehow thinking on why mix up codes :

Well , masscan is not only a fast open port scanner , since it uses nmap scripts then it would not make any difference to merge this one on it .

Thanks again

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.