Blog

Archive for 2019

Investigating an Odd DNS Query, (Thu, May 23rd)

I have been asked this question a few times, and figure it may be worthwhile to document this in a quick diary. This is typically the result of watching for odd DNS queries (and I highly recommend that). But not all DNS queries are created equal, and sometimes you will see odd, or even malicious, hostnames and domain names in your logs without any wrongdoing on your end.

The latest example I just ran into: faraisp.ir . IR being the country level domain for Iran, and I am currently not doing business with Iran, which certainly makes this a bit suspect if it bubbles up to the top of the “odd domain list”.

The queries for this domain came in at a rate of 100-150/5min in my Zeek logs:

Next, let’s break down all the queries for the “faraisp.ir” domain

You can click on the image to get a larger view. But the queries are essentially A/AAAA queries for ns[1-4].faraisp.ir. To add to this: they all came from my DNS server. Now the DNS server’s query log would usually be my next step. But in this case, the query log does not show any queries for *.faraisp.ir. I also didn’t see any queries from any of my hosts to the name server for *.faraisp.ir . The reason for these queries was that a prior query returned these hostnames as authority records. This triggered my name server to do a lookup for these hostnames. So I need to search for answers that contain faraisp.ir.

It turned out that a prior reverse lookup by the mail servers spam filter returned the authority record, and as a result, the name server then kept looking for ns[1-4].faraisp.ir. So why did the mail server try to reverse resolve the IP address over and over? My first guess was spam, but it turned out to be a brute force attack against the server:

May 23 16:47:35 mail postfix/smtpd[3420]: connect from unknown[185.137.111.145] May 23 16:47:42 mail postfix/smtpd[3420]: warning: unknown[185.137.111.145]: SASL LOGIN authentication failed: authentication failure May 23 16:47:42 mail postfix/smtpd[3420]: disconnect from unknown[185.137.111.145] May 23 16:47:58 mail postfix/smtpd[3420]: connect from unknown[185.137.111.44] May 23 16:48:05 mail postfix/smtpd[3420]: warning: unknown[185.137.111.44]: SASL LOGIN authentication failed: authentication failure May 23 16:48:05 mail postfix/smtpd[3420]: disconnect from unknown[185.137.111.44]

So at least not entirely a “false positive”, but also not terribly exciting. Mail servers are probably the main source of odd DNS queries. They tend to do a lot of reverse lookups for anti-spam, and they also use various DNS based anti-spam and email validation features that often look very much like data exfiltration. You will also see a lot of less common record types in DNS queries from mail servers (TXT, SPF..).


Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Do You Remember the SUBST Command?, (Sat, May 25th)

I had to test a program on Windows using a particular drive letter.

So I was thinking of mounting an ISO file, or a VeraCrypt volume, and have a drive with that particular drive letter on my machine. And then I remember something … old … really old.

Back in the early nineties, I often had to do something similar on MS DOS. I used the SUBST command.

It still exists on Windows. You provide an unused drive letter and a path on an existing drive, and voilà:

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Video: nmap Service Detection Customization, (Sun, May 26th)

In the following video, I show how to interpret nmap’s service fingerprint data for unknown services (using service detection -sV).

And, provided one knows how to identify a service nmap reports as unknown, I show how to update nmap’s service probe file to add detections for unknown services..

 

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

An Update on the Microsoft Windows RDP "Bluekeep" Vulnerability (CVE-2019-0708) [now with pcaps], (Wed, May 22nd)

[Please comment if you have any feedback / suggested additions/corrections. You can also use our comment form ]

The most notable vulnerabilities patched by Microsoft last week addressed an input validation flaw in the Remote Desktop Service. To exploit the vulnerability, an attacker would send a specially crafted Remote Desktop Protocol (RDP) request to the Remote Desktop Service. The vulnerability is notable for several reasons:

  • The exploitation of the vulnerability does not require authentication.
  • An exploit may lead to arbitrary code execution.
  • (too) many organizations are exposing RDP to the Internet.
  • Windows 7 / 2008 and older are affected, going back to Windows XP.

Current Exploit Development Status

Several security vendors stated publicly that they developed exploits internally that will at least trigger a denial of service condition (blue screen). Currently, there are at least two public partial exploits [1][2].  One triggers the “vulnerable path” without triggering a blue screen or causing any other damage. It can be adjusted to play with the “channel” parameter to create normal and exploit traffic. The second one also triggers the vulnerability without any intended ill effect. The second exploit has been made available in the form of a stand-alone vulnerability scanner.

It does appear non-trivial to develop a reliable remote code execution exploit for this vulnerability, which will hopefully get us a few more days until one is publicly available. However, exploit development is active, and I don’t think you have more than a week.

Detection

The NCC Group publicly released a Suricata signature to detect attacks taking advantage of the exploit [3].  It is difficult to estimate how good the signature is. Cisco released rules for snort as well. Note that RDP usually uses TLS, and all current partial exploits use TLS, making the value of these rules questionable.

What you need to do NOW

Remember, we are coming up on a long weekend in the US. I hope you are well into mitigating this vulnerability as you read this, but here are a few things to consider:

  • Do you have any systems running affected versions of Windows? Where are they located (e.g., are they confined to particular subnets)? Can you block port 3389 (RDP) inbound and possibly outbound?
  • Deploy IDS/IPS rules to detect the exploit (just in case, but note the TLS issue above).
  • Scan your network for open RDP. Do not just use the vulnerability scanner, but find out who is using RDP and why. RDP should not be exposed if possible.
  • Follow up the scan with the vulnerability scanner.
  • Patch! You want to patch this by Friday. For some organizations, the long weekend may provide a better patch window which is hopefully still ok.

Longer Term Fixes

Being vulnerable exposes two fundamental weaknesses in your network: You are still running Windows 7 (or XP??), and you are exposing RDP. Neither is good, and both issues need to be addressed. With this focus on RDP, there is a good chance that additional vulnerabilities will be found in the next few months. If this is true, then fire drills will continue until you can get these two issues resolved.

Upgrading from Windows 7 to 10, and upgrading from Windows Server 2008, should already be underway, so you may just accelerate what you are already doing. If you still run Windows XP: There better be a very good reason for it, and I hope that you have those systems adequately protected.

Eliminating RDP may be difficult for some organizations. But you can at least isolate it by requiring a VPN to connect to it, or by taking advantage of an RDP gateway supporting SSL. Take a look at some of the guidance offered by Microsoft [4]

Technical Details

Before authentication, RDP negotiates various parameters and capabilities. After initiating the connection with an X.224 connection request and having it confirmed by the server, the client will send a “Generic Conference Control (GCC) Conference Create Request.” Usually, this request defines three different channels. To trigger the exploit, an MS_T120 channel is added as a fourth channel. This channel should only bind to “channel 31”, but the exploit will bind it to another channel. The current signatures look for this particular artifact. McAfee’s blog offers an excellent summary of some of the details. [5]

I collected some packet captures from various normal and exploit tools. You can download the pcap files here: https://isc.sans.edu/diaryimages/BlueKeepPCAPs.tgz

[ note that some of the links below may trigger overly sensitive anti-malware scanners ]

[1] https://github.com/zerosum0x0/CVE-2019-0708
[2] https://github.com/n1xbyte/CVE-2019-0708/blob/master/poc.py
[3] https://github.com/nccgroup/Cyber-Defence/blob/master/Signatures/suricata/2019_05_rdp_cve_2019_0708.txt
[4] https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/welcome-to-rds
[5] https://securingtomorrow.mcafee.com/other-blogs/mcafee-labs/rdp-stands-for-really-do-patch-understanding-the-wormable-rdp-vulnerability-cve-2019-0708/


Johannes B. Ullrich, Ph.D., Dean of Research, SANS Technology Institute
Twitter|

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →

Using Shodan Monitoring, (Tue, May 21st)

Back in March, Shodan started a new service called Shodan Monitor(1). What this service does is notify you of ports that are open on the network you  specify. When you initially setup your network, you put in your CIDR to monitor and then select notification triggers where you will get emails for any of these categories that show up on the specified network.   In the notification emails, you get a link to be able to whitelist systems. I’m finding that the uncommon ports to be chatty for large networks, and tend to whitelist many of these.

 

 

 

They have a heat map that shows you what hosts has the most open ports.  You can hover over them and see what system have the largest footprint on the Internet.

 

 

 

The Initial dashboard shows you the top port breakdown, notable ports and possible vulnerabilities for your networks you are watching.

 

 

 

 

While this list could be useful, it’s only gathering these details based on banner information, which web applications have lots of backported patches which make this less valuable for web.

 

 

 

 

While you can and should script this within you organization using Nmap, this is great way to validate and see what attackers are seeing from outside with little effort. Has anyone found other cool uses of this service yet?

 

(1) https://monitor.shodan.io/

 

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Reposted from SANS. View original.

Posted in: SANS

Leave a Comment (0) →
Page 1 of 19 12345...»