Recorded May 30, 2019 at G-Unit Studios in Rhode Island!
- 1 Episode Audio
- 2 Announcements
- 3 Interview: Eric Butash, InnovateEdu & Mike Klein, Highlander Institute - 6:00 - 6:30PM
- 4 Tech Segment: Robert Graham, Errata Security & Paul Asadoorian - 6:30 - 7:00PM
- 5 Interview: Automate IT: Using Salt Open and SaltStack Enterprise - David Boucha, SaltStack - 7:30PM - 8:00PM
- 6 Security News - 8:30PM-9:30PM
- Join us at InfoSecWorld 2020 - March 30 - April 1, 2020 at the Disney Contemporary Resort! Security Weekly listeners save 15% off the InfoSec World Main Conference or World Pass! Visit securityweekly.com/ISW2020, click the register button to register with our discount code or the schedule button to sponsor a micro-interview!
- OSHEAN and the Pell Center are partnering together to present Cybersecurity Exchange Day on Wednesday, March 18th from 9am-3pm at Salve Regina University in the beautiful Newport, RI! Visit securityweekly.com/OSHEAN2020 to register for free and come join in the fun!
- We have officially migrated our mailing list to a new platform! Sign up for the list to receive invites to our virtual trainings, webcasts, and other content relative to your interests by visiting securityweekly.com/subscribe and clicking the button to join the list! You can also submit your suggestions for guests by going to securityweekly.com/guests and submitting the form! We'll review them monthly and reach out if they are a good fit!
- Our first-ever virtual training is happening on March 19th @11:00am ET, with Adam Kehler & Rob Harvey from Online Business Systems Risk, Security & Privacy Team. In this training you will learn how to generate a complex SHA-256 hashed password and then use password cracking tools to break it. Register for our upcoming trainings by visiting securityweekly.com, selecting the webcast/training drop down from the top menu bar and clicking registration.
Interview: Eric Butash, InnovateEdu & Mike Klein, Highlander Institute - 6:00 - 6:30PM
- What schools are doing to protect Student Data?
- How do we teach our student the importance of good digital hygiene if we don't have the proper education in place?
- What is Digital Citizenship?
- How is the Privacy playing a roll in our always-on youth?
Tech Segment: Robert Graham, Errata Security & Paul Asadoorian - 6:30 - 7:00PMhttps://blog.erratasec.com.
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
Interview: Automate IT: Using Salt Open and SaltStack Enterprise - David Boucha, SaltStack - 7:30PM - 8:00PM
Topic: We'll be talking about how Salt Open and SaltStack Enterprise can help you automate your infrastructure including servers (cloud, on-prem, virtual), network devices, and endpoints. From "day 0" provisioning to "day n" configuration drift management and compliance management, Salt can scale to automate all the most difficult and frustrating tasks.
Security News - 8:30PM-9:30PM
- Redditor can stay anonymous, court rules
- The industrys best-kept secret: why mobile ad fraud prevention is just too good to be true
- Spies with that? Police can snoop on McDonald's and Westfield wifi customers
- 8 Ways to Authenticate Without Passwords
- Flipboard Resets User Passwords in Response to Data Breach | SecurityWeek.Com
- Eternally Blue: Baltimore City leaders blame NSA for ransomware attack
- Docker Vulnerability Gives Arbitrary File Access to Host | SecurityWeek.Com
- Trends in Cybersecurity to Watch
- Majority of CISOs plan to ask for an increase in cybersecurity investment - Help Net Security
- Hackers actively exploit WordPress plugin flaw to send visitors to bad sites
- Virus-packed laptop sells as artwork for over RM5.5mil
- Technology is Not Our Problem | SecurityWeek.Com
- What a teen grade hackers confession can teach us
- The cryptominer that kept coming back
- InfoSec Handlers Diary Blog - Analyzing First Stage Shellcode
- Malware Found on PoS Systems at Checkers and Rally's Restaurants | SecurityWeek.Com
- High-Risk Flaws Found in Process Control Systems From B&R Automation | SecurityWeek.Com
- macOS Gatekeeper Bypass Exploits Trust on Network Shares | SecurityWeek.Com
- InfoSec Handlers Diary Blog - nmap Service Fingerprint
- Killer SecOps Skills: Soft Is the New Hard
- Old Threats Are New Again
- Researchers have discovered one million devices that are vulnerable to a “wormable” Microsoft flaw, which could open the door to a WannaCry-like cyberattack
- Researcher Filippo Cavallarin disclosed a bug in the macOS security feature Gatekeeper - Allows malicious code execution on systems running the most recent version of Mojave (10.14.0)
- Up to 50,000 servers were infected over the past four months as part of a high-profile cryptojacking campaign - Believed to orchestrated by Chinese-language adversaries
- Apple, Google, WhatsApp, Microsoft, along with 43 security experts and privacy advocates, have signed an open letter to the GCHQ calling out the UK spy agency's "ghost proposal.” - If they back down from one country, where will they draw the line?]
- Would your average Internet user be any more vigilant against phishing scams if he or she faced the real possibility of losing their job after falling for one too many of these emails? - Recently, I met someone at a conference who said his employer had in fact terminated employees for such repeated infractions. As this was the first time I’d ever heard of an organization actually doing this, I asked some phishing experts what they thought (spoiler alert: they’re not fans of this particular teaching approach)
- BlueKeep PoC